diff --git a/docs/fints-def/FinTS_3.0_Formals_2017-10-06_final_version.md b/docs/fints-def/FinTS_3.0_Formals_2017-10-06_final_version.md new file mode 100644 index 0000000..c15e7bc --- /dev/null +++ b/docs/fints-def/FinTS_3.0_Formals_2017-10-06_final_version.md @@ -0,0 +1,23487 @@ + + + + +# FinTS Financial Transaction Services + +Schnittstellenspezifikation + +Formals + +Herausgeber: + +Bundesverband deutscher Banken e.V., Berlin + +Deutscher Sparkassen- und Giroverband e.V., Bonn/Berlin + +Bundesverband der Deutschen Volksbanken und Raiffeisenbanken e.V., Berlin +Bundesverband Öffentlicher Banken Deutschlands e.V., Berlin + + + + + + + + +Die vorliegende Schnittstellenspezifikation für eine automatisiert nutzbare multibankfähige +Banking-Schnittstelle (im Folgenden: Schnittstellenspezifikation) wurde im Auftrag der Deut- +schen Kreditwirtschaft entwickelt. Sie wird hiermit zur Implementation in Kunden- und Kredit- +institutssysteme freigegeben. + +Die Schnittstellenspezifikation ist urheberrechtlich geschützt. Zur Implementation in Kunden- +und Kreditinstitutssysteme wird interessierten Herstellern unentgeltlich ein einfaches Nut- +zungsrecht eingeräumt. Im Rahmen des genannten Zwecks darf die Schnittstellenspezifika- +tion auch - in unveränderter Form - vervielfältigt und zu den nachstehenden Bedingungen +verbreitet werden. + +Umgestaltungen, Bearbeitungen, Übersetzungen und jegliche Änderung der Schnittstellen- +spezifikation sind untersagt. Kennzeichnungen, Copyright-Vermerke und Eigentumsangaben +dürfen in keinem Fall geändert werden. + +Im Hinblick auf die Unentgeltlichkeit des eingeräumten Nutzungsrechts wird keinerlei Ge- +währleistung oder Haftung für Fehler der Schnittstellenspezifikation oder die ordnungsge- +mäße Funktion der auf ihr beruhenden Produkte übernommen. Die Hersteller sind aufgefor- +dert, Fehler oder Auslegungsspielräume der Spezifikation, die die ordnungsgemäße Funkti- +on oder Multibankfähigkeit von Kundenprodukten behindern, der Deutschen Kreditwirtschaft +zu melden. Es wird weiterhin ausdrücklich darauf hingewiesen, dass Änderungen der +Schnittstellenspezifikation durch Die Deutsche Kreditwirtschaft jederzeit und ohne vorherige +Ankündigung möglich sind. + +Eine Weitergabe der Schnittstellenspezifikation durch den Hersteller an Dritte darf nur un- +entgeltlich, in unveränderter Form und zu den vorstehenden Bedingungen erfolgen. + +Dieses Dokument kann im Internet abgerufen werden unter http://www.fints.org. + + + + +## Versionsführung + +Das vorliegende Dokument wurde von folgenden Personen erstellt bzw. geändert: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
NameOrgani- sationDatumVersi- onDokumenteAnmerkungen
SteinSIZ22.11.19961.0hbci10.docErste vom ZKA verab- schiedete Version
SteinSIZ24.07.19972.0hbci20a.docÄnderungen und Fehler-
hbci20b.dockorrekturen sowie neue
hbci20c.docGeschäftsvorfälle
hbci20d.doc
SteinSIZ02.02.19982.0.1hbci201a.docÄnderungen und Fehler-
hbci201b.dockorrekturen zur Version
hbci201c.doc2.0
hbci201d.doc
SteinSIZ02.03.19992.1hbci21a.docÄnderungen und neue
hbci21b.docGeschäftsvorfälle (Wert-
hbci21c.docpapiergeschäft)
hbci21d.doc
SteinSIZ10.05.20002.2hbci22a.docNeue Geschäftsvorfälle
hbci22b.docund inhaltliche Korrektu-
hbci22c.docren (keine Änderungen
hbci22d.docan der Basiskomponen- te)
SteinSIZ15.11.20023.0FinTS 3.0 Formals.docDieses Dokument ent- spricht dem Teil A der bisherigen HBCI- Spezifikation
Haubnerfür SIZ12.11.20103.0FinTS 3.0 Formals Rel. 2010-11-12 final ver- sion.docExtrahieren des Kapitels zur Bedeutung der Rückmeldungscodes
Haubnerfür SIZ14.06.20113.0FinTS 3.0 Formals Rel. 2011-06-14 final ver- sion.docFehler und Klarstellun- gen P1 bis P5, Integrati- on RAH-Verfahren
Haubnerfür SIZ11.05.20173.0-FVFinTS 3.0 Formals Rel. 2017-05-11 final ver- sion.docUPD-Erweiterung und - Prozesse; Anpassungen für starke Kun- denauthentifizierung nach PSD2 / RTS
Haubnerfür SIZ06.10.20173.0FinTS 3.0 Formals Rel. 2017-10-06 final ver- sion.docKlarstellungen zur star- ken Kundenauthentifizie- rung
+ + + + + +## Änderungen gegenüber der Vorversion: + +Hinzufügungen und Änderungen sind im Dokument in dieser Farbe und zusätzlich +durch Unterstreichung und einen Randbalken markiert. Löschungen sind aufgrund +der besseren Übersichtlichkeit nur durch einen Randbalken markiert. Hypertextlinks +sind je nach Überarbeitungsversion in unterschiedlichen Farben markiert. Falls sich +die Kapitelnummerierung geändert hat, bezieht sich die Kapitelangabe auf die neue +Nummerierung. Aufgrund der umfangreichen Textumstellungen wurden nicht alle +Änderungen markiert. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
lfd. Nr.KapitelKapitel- nummerKen- nung
1		Art2Beschreibung
1Allgemeines-KErsetzung von DM durch Euro in Text und Beispielen
2131ÄUmwandlung von GD und GDG in DE bzw. DEG.
3NachrichtenaufbauB.3.1131ÄEinführung des Status „C“ (konditional); Umwandlung des Status ,,K" in ,O“ (opti- onal)
4B.4.2166ÄEinführung des Formats ,code' für Da- tenelemente, deren Inhalt durch eine Schlüsseltabelle definiert wird (diese Änderung ist lediglich deskriptiv und hat keine Auswirkungen auf den physischen Nachrichtenaufbau und die Segment- versionen)
5DialogspezifikationC.3 C.8162ÄDas Segment HKISA kann bis zu 3-mal in die Dialoginitialisierung eingestellt werden
6C.9149ELife-Indikator-Nachricht hinzugefügt
7C. 10171EKapitel bzgl. Unterstützung beliebiger Geschäftsvorfallversionen hinzugefügt
8Bankparameter- datenD.2149ÄAufnahme von Feldern zur Angabe des Timeout-Wertes in die Bankparameter- daten
9D.5190ÄErmöglichung von Komprimierung (de- flate/GZIP als zwingend vorgeschriebe- ner Algorithmus
10Userparameter- datenE.1134KKlarstellung, welche Konten für Berech- tigungsprüfung herangezogen werden
11E.2 E.3172ÄAufnahme des Feldes ,,Benutzername“ in das Segment HIUPA und des Feldes ,Kontoart" in das Segment HIUPD
12E.3134ÄDE Kontoverbindung erhält Status „opti- onal" um auch nicht kontogebundene Geschäftsvorfälle angeben zu können
13Data-DictionaryF.131ÄTrennung der semantischen Daten- beschreibung vom Geschäftsvorfalls- modell (Einführung eines Data Dictio- naries)
+ +1 +nur zur internen Zuordnung + +2 +F = Fehler; Ä = Änderung; K = Klarstellung; E = Erweiterung + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
lfd. Nr.KapitelKapitel- nummerKen- nung
1		Art2Beschreibung
14Code-BedeutungenF.ÄDE ,,Kommunikationsadresse": ,https' als möglicher Wert hinzugefügt
15Β.7.5.3P6KVerlagern des Kapitels ,,Bedeutung der Rückmeldungscodes“ in ein separates Dokument [RM-Codes].
16EinleitungAKEntfernen der Kontaktinformationen und stattdessen Verweis auf fints.org.
17EinleitungAEErgänzen der Begriffsdefinitionen für ,HBCI" und ,FinTS"
18Transportmedien- spezifische Festle- gungenH.4EEntfernen des Kommunikationsdienstes BtxFIF aus der Spezifikation
19StatusprotokollC.7P5ÄEntfall der kreditinstitutsseitigen Ver- pflichtung zur Unterstützung des Sta- tusprotokolls
20UPDC.2P4KVerhalten bei UPD=0
21Verarbeitungsvor- bereitungC.3.1.3P3ERückmeldecodes für den Schlüssel- wechsel von RDH-1 auf RDH-2
22UPDEP2EErgänzen der Datenelemente „Erweite- rung. Allgemein" und ,Erweiterung, kon- tobezogen“
23UPDE.3P1KLängenanpassung bei den Datenele- menten ,,Name des Kontoinhabers 1 und 2"
24UPDE.3KLängenanpassung beim Datenelement ,IBAN" von ..35 auf ..34.
25DiverseEErgänzen des RAH-Verfahrens
26UPD, FinTS- ProzesseD.3.1 und E0461EBeschreibung von Inhalten und Prozes- sen der UPD-Erweiterung, kontobezo- gen (ohne Revisionsmarkierungen)
27DialoginitialisierungB.30480EBerücksichtigung der starken Authentifi- zierung
+ + +## Releasedatum 06.10.2017 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
lfd. Nr.KapitelKapitel- nummerKen- nung
3		Art4Beschreibung
1Verarbeitungsvor- bereitungC.3.1.30496ÄÄndern der Segmentversion auf 3.
2SegmenteI.1.30496EErgänzen fehlender Segmente
3AnlagenI.2.10496EHinzufügen von HKTAN/HITAN bei Auf- tragsnachrichten
4Diverse0496EEinfügen der Spalte „Version“ in allen Syntaxtabellen.
Nachpflegen von fehlenden Änderungen aus den ,,Changes" unter fints.org.
+ + + + + + + +## Dokumentenstruktur + +Das vorliegende Dokument steht in folgendem Bezug zu den anderen Bänden der +FinTS V3.0 Spezifikation: + + +![Hauptdokument Formals Rückmeldungen SCPA Messages Geschäftsvorfälle Messages Finanzdatenformate IZV Messages Geschäftsvorfälle Security HBCI Security PIN/TAN Security Secoder ☐ 1 5 2 3 4 1 5 2 3 4 6 0 8 9 7 6 7 0 DK- Signaturkarte 8 9 C R C R Secoder chipTAN mobile TAN Secoder](figures/7.1) + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: A
Dokument:Formals
Kapitel:EinleitungStand: 06.10.2017Seite: 1
+ + +## Inhaltsverzeichnis + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
A. Einleitung7
B. Nachrichtenaufbau9
B.1 Zeichensatz9
B.2 Nachrichtenelemente9
B.3 Festlegungen10
B.3.1 Status und Anzahl10
B.3.2 Restriktionen11
B.3.3 Längenangaben12
B.3.4 Transparente Daten12
B.3.5 Datum und Uhrzeit12
B.4 Datenformate13
B.4.1 Basisformate13
B.4.2 Abgeleitete Formate14
B.5 Steuerstrukturen15
B.5.1 Segmentkopf15
B.5.2 Nachrichtenkopf15
B.5.3 Nachrichtenabschluss15
B.6 Kundennachrichten allgemein17
B.6.1 Allgemeiner Nachrichtenaufbau17
B.6.2 Aufträge 19
B.6.3 Abholauftrag19
B.7 Kreditinstitutsnachrichten allgemein23
B.7.1 Allgemeiner Nachrichtenaufbau23
B.7.2 Rückmeldungen zur Gesamtnachricht24
B.7.3 Rückmeldungen zu Segmenten25
B.7.4 Datensegmente26
B.7.5 Rückmeldungscodes27
B.7.5.1 Grundkonzept27
B.7.5.2 Reaktionsvorschriften27
B.7.5.3 Code-Bedeutungen30
B.7.6 Dialogabbruchnachricht31
+ + + + + + + + + + + + + + + + +
Kapitel:
A		Version: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite: 2Stand: 06.10.2017Kapitel: Einleitung
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
B.8 8 Allgemeiner Nachrichtenaufbau bei Verschlüsselung33
C. Dialogspezifikation35
C.1 Allgemeines35
C.1.1 Begriffsbestimmung35
C.1.2 Dialogabfolge37
C.1.3 Verschlüsselung des Dialoges beim Sicherheitsverfahren HBCI39
C.2 Abfolge von Operationen40
C.3 Dialoginitialisierung41
C.3.1 Kundennachricht41
C.3.1.1 Nachrichtenformat41
C.3.1.2 Segment: Identifikation43
C.3.1.3 Segment: Verarbeitungsvorbereitung45
C.3.1.4 Segment: Anforderung eines öffentlichen Schlüssels47
C.3.2 Kreditinstitutsnachricht48
C.3.2.1 Nachrichtenformat48
C.3.2.2 Segmentfolge: Bankparameterdaten49
C.3.2.3 Segmentfolge: Userparameterdaten50
C.3.2.4 Segment: Übermittlung eines öffentlichen Schlüssels51
C.3.2.5 Segment: Kreditinstitutsmeldung52
C.4 Dialogbeendigung53
C.4.1 Ausnahmen zur Dialogbeendigung53
C.4.2 Kundennachricht53
C.4.2.1 Nachrichtenformat53
C.4.2.2 Segment: Dialogende54
C.4.3 Kreditinstitutsnachricht54
C.5 Anonymer Zugang55
C.5.1 Dialoginitialisierung55
C.5.2 Auftragsnachricht57
C.5.3 Dialogbeendigung57
C.6 Verbindungsabbruch59
C.7 Statusprotokoll63
C.8 Synchronisierung66
C.8.1 Kundennachricht67
C.8.1.1 Nachrichtenformat67
C.8.1.2 Segment: Synchronisierung68
C.8.2 Kreditinstitutsnachricht69
C.8.2.1 Nachrichtenformat69
C.8.2.2 Segment: Synchronisierungsantwort69
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: A
Dokument:Formals
Kapitel:EinleitungStand: 06.10.2017Seite: 3
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
C.9 Life-Indikator-Nachricht71
C.10 Unterstützung von Geschäftsvorfallversionen74
D. Bankparameterdaten (BPD)77
D.1 Allgemeines77
D.2 Bankparameter allgemein79
D.3 Kommunikationszugang80
D.4 Sicherheitsverfahren81
D.5 Komprimierungsverfahren82
D.6 Geschäftsvorfallparameter83
D.7 Parameterdaten84
E. Userparameterdaten (UPD)85
E.1 Allgemeines85
E.2 Userparameter allgemein87
E.3 Kontoinformation88
E.3.1 Aufbau der UPD-Erweiterung, kontobezogen89
E.3.1.1 Belegungsvorschriften für die einzelnen JSON-Elemente93
E.3.1.2 Beispiel für die Verwendung der UPD-Erweiterung zur Bestandsoptimierung97
F. FinTS Prozesse99
F.1 Versionsverwaltung99
F.2 Generelle Festlegungen100
F.3 Spezielle Prozesse101
F.3.1 Abruf von Umsätzen102
F.3.2 Abruf von Salden102
F.3.3 Abruf von Beständen103
F.3.4 Abruf von SEPA-Kontoverbindungsdaten103
F.3.5 Anzeige der verfügbaren TAN-Medien104
G. Data Dictionary105
A105
B106
D109
E110
F111
G112
Η112
+ + + + + + + + + + + + + + + + +
Kapitel:
A		Version: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite: 4Stand: 06.10.2017Kapitel: Einleitung
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
I113
K113
L117
M118
N120
P121
R121
S123
U126
V129
W129
H. Syntax131
H.1 Nachrichtensyntax131
H.1.1 Syntaxzeichen131
H.1.2 Nachrichtenaufbau131
H.1.3 Entwertung132
H.1.4 Binäre Daten133
H.1.5 Auslassen von Datenstrukturen133
H.2 Beispiele135
H.2.1 Datenelementgruppen135
H.2.2 Segmente135
H.2.3 Segmentfolgen154
H.2.4 Dialog 156
H.2.4.1 Nachricht ,,Dialoginitialisierung"156
H.2.4.2 Nachricht „SEPA-Einzelüberweisung“159
H.2.4.3 Nachricht ,,Saldenabfrage“160
H.2.4.4 Nachricht ,,Dialogbeendigung“162
I. Anlagen165
I.1 Übersicht der FinTS-Elemente165
I.1.1 Nachrichten165
I.1.2 Segmentfolgen166
I.1.3 Segmente167
I.2 Übersicht Nachrichtenaufbau169
I.2.1 Standarddialog170
I.2.2 Anonymer Dialog172
I.2.3 Synchronisierung173
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument: Formals3.0-FVA
Kapitel:
Einleitung		Stand: 06.10.2017Seite: 5
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
I.2.4 Kommunikationszugang174
I.2.5 Änderung eines öffentlichen Schlüssels des Kunden (HBCI RAH und RDH)175
I.2.6 Erstmalige Anforderung der öffentlichen Schlüssel des Kreditinstituts (HBCI RAH und RDH)176
I.2.7 Erstmalige Übermittlung der öffentlichen Schlüssel des Kunden (HBCI RAH und RDH)177
I.2.8 Schlüsselsperrung durch den Kunden (HBCI RAH und RDH)178
I.2.9 Schlüsselsperrung durch den Kunden (HBCI DDV)179
I.3FinTS-Basiszeichensätze180
I.3.1 ISO 8859-1 Subset Deutsch180
I.3.2 ISO 8859-1 Subset Englisch180
I.3.3 ISO 8859-1 Subset Französisch181
I.4Transportmedienspezifische Festlegungen183
I.4.1 TCP/IP184
I.4.1.1 Internet (WWW)184
I.5Abruf von Kommunikationszugangsdaten185
Kapitel:
A		Version: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
6		Stand: 06.10.2017Kapitel: Einleitung
+ + +## Abbildungsverzeichnis + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Abbildung 1: Übersicht der Schnittstellenbeziehungen7
Abbildung 2: Nachrichtenaufbau10
Abbildung 3: Logischer Nachrichtenaufbau18
Abbildung 6: Dialogabfolge37
Abbildung 7: Einzelbenutzer38
Abbildung 8: Mehrere Benutzer38
Abbildung 9: Verbindungsabbruch Fall 160
Abbildung 10: Verbindungsabbruch Fall 260
Abbildung 11: Verbindungsabbruch Fall 361
Abbildung 12: Verbindungsabbruch Fall 461
Abbildung 13: Funktionsweise des Life-Indikators71
Abbildung 14: Beispielhafter Aufbau der UPD-Erweiterung, kontobezogen (Tabelle)90
Abbildung 15: Beispielhafter Aufbau der UPD-Erweiterung, kontobezogen (JSON)91
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:
Formals		3.0-FVA
Kapitel:
Einleitung		Stand: 06.10.2017Seite: 7
+ + +### A. EINLEITUNG + +Die vorliegende Spezifikation bildet die Grundlage für eine automatisiert nutzbare +multibankfähige Onlinebanking-Schnittstelle. Eine parallele Nutzung anderer Kredit- +institutszugänge (z. B. „Browserbanking“) bleibt hiervon unberührt. + +Mit der Version 3.0 fand eine Namensänderung von „HBCI" nach ,,FinTS" statt. +HBCI bezeichnet in diesem Kontext ausschließlich das Sicherheitsverfahren wäh- +rend FinTS als Bezeichnung für das gesamte Protokoll steht. Im Dokument wurden +die Begriffe wo immer möglich in diesem Sinn verwendet. Wird jedoch auf konkrete +Protokollstrukturen (z. B. ,,HBCI-Version") oder ältere Spezifikationsversionen wie +,HBCI V2.2" verwiesen, so bezeichnet der Begriff ,,HBCI" in diesen Fällen auch das +Protokoll und ist gleichbedeutend mit ,,FinTS". + +Beschrieben wird die Schnittstelle zwischen Kundenprodukt und Kreditinstituts- +system. Um die Multibankfähigkeit zu gewährleisten, ist zusätzlich eine Beschrei- +bung der Schnittstelle zwischen Kundenprodukt und Sicherheitsmedium erforderlich. +Daher findet sich in [HBCI] eine Spezifikation der Schnittstelle zwischen einem +FinTS-Kundenprodukt und einer Chipkarte bzw. einer Diskette. Zur Abwicklung des +PIN/TAN-Verfahrens findet sich die Schnittstellenspezifikation in [PINTAN]. + + +Abbildung 1: Übersicht der Schnittstellenbeziehungen + +![Sicherheitsverfahren HBCI USB-Stick Chipkarte FinTS Benutzer FinTS Kreditinstitut Sicherheitsverfahren PIN/TAN chipTAN mobile TAN](figures/15.1) + + +Im Rahmen dieser Schnittstellenbeschreibung findet grundsätzlich keine Spezi- +fikation von Kunden- oder Kreditinstitutssystemen statt. Lediglich werden an einigen +gekennzeichneten Stellen Empfehlungen für die Präsentation im Kundenprodukt + + + + + + + + + + + + + + + +
Kapitel:
A		Version: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
8		Stand: 06.10.2017Kapitel: Einleitung
+ + +bzw. für die Verarbeitung im Kreditinstitutssystem gegeben.1 Diese Ausführungen +sind jedoch nicht als Teil der eigentlichen Schnittstellenspezifikation zu verstehen. + +Grundsätzlich ist die Schnittstellenbeschreibung Plattform- und Endgeräte unabhän- +gig. Ein Teil dieser Empfehlungen erfordert jedoch intelligente Endgeräte mit lokaler +Speicherintelligenz. + +Die Spezifikation ist als Schichtenstruktur aufgebaut und somit grundsätzlich unab- +hängig vom zugrunde liegenden Transportmedium. Um eine einheitliche und mult- +ibankfähige Schnittstelle zu gewährleisten, werden jedoch hierzu in den Anlagen +(Kap. I.4) einige grundsätzliche Festlegungen getroffen. + +Für einzelne Teile der Schnittstelle (z. B. Signatur, Verschlüsselung und Standard- +Finanzdatenformate) wird in den Anlagen in [Master] auf weitere allgemein zugäng- +liche Spezifikationen verwiesen. + +In [Messages] ist eine Vielfalt von Geschäftsvorfällen zwischen Kunde und Kreditin- +stitut beschrieben. Da hiermit jedoch nicht sämtliche Anforderungen aller beteiligten +Kreditinstitute abgebildet werden können, steht es den Verbänden der Deutschen +Kreditwirtschaft frei, eigene Geschäftsvorfälle, die in diesem Dokument nicht enthal- +ten sind, zu definieren und anzubieten. Die Klassifizierung in DK-weit definierte und +verbands- bzw. institutsspezifische Geschäftsvorfälle erfolgt dabei über die erste +Stelle der jeweiligen Segmentkennung (s. Kap. B.5.1). + +Es werden folgende Segmentkennungen reserviert: + +'Hxxxx': +DK-weit verabschiedete Geschäftsvorfälle + +'Bxxxx': + +Geschäftsvorfälle für den Bundesverband deutscher Banken e.V. + +'Dxxxx': + +Geschäftsvorfälle für den Deutschen Sparkassen- und Giroverband e.V. + +'Gxxxx': +Geschäftsvorfälle für den Bundesverband der Deutschen Volksbanken +und Raiffeisenbanken e.V. + +'Vxxxx': +Geschäftsvorfälle für den Bundesverband Öffentlicher Banken e.V. + +'Xxxxx': + +Bilateral vereinbarte Geschäftsvorfälle anderer Verbände/Institutionen + +'Ixxxx': +Intern verwendete Segmente (Diese Segmente dürfen nur für die Pro- +grammierung von Kunden- und Bankprodukten verwendet werden. Sie +dürfen keinesfalls im Rahmen von FinTS-Nachrichten gesendet wer- +den). + +Die Vergabe und Koordination der mit 'H' und 'X' beginnenden Kennungen über- +nimmt die DK. Die Vergabe und Koordination der übrigen Kennungen übernehmen +die jeweiligen Verbände. I-Segmente können von Herstellern bei Bedarf beliebig +verwendet werden. Kennungen, die diesen Definitionen nicht entsprechen, sind +nicht zulässig. + +Für weitere Fragen und Informationen zu FinTS wenden Sie sich bitte an die unter +[www.fints.org](http://www.fints.org/) in der Rubrik ,Impressum" angegebenen Adressen. + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: B
Dokument:Formals
Kapitel:
Abschnitt:		Nachrichtenaufbau ZeichensatzStand: 06.10.2017Seite: 9
+ + +### B. NACHRICHTENAUFBAU + + +#### B.1 Zeichensatz + +Der HBCI-Basiszeichensatz baut auf dem international normierten Zeichensatz +ISO 8859 auf. Im DE ,Unterstützte Sprachen“ in die Bankparameterdaten (s. Kap. +D.2) stellt das Kreditinstitut das jeweiligen Codeset des ISO 8859 ein.1 Ferner wird +in die BPD das sprachen-spezifische Subset des ISO 8859 eingestellt. Codeset und +Subset definieren gemeinsam den FinTS-Basiszeichensatz. Dieser gilt grundsätzlich +für sämtliche nicht-binären Datenelemente. Sofern hiervon aufgrund von Verarbei- +tungsrestriktionen abgewichen wird, ist dies bei der jeweiligen Formatbeschreibung +vermerkt. Für transparente Daten gilt der jeweilige Zeichensatz des Fremdformats. + +Kreditinstitutsseitig ist jeweils der vollständige erlaubte Zeichensatz zu unterstützen. +FinTS-Syntaxzeichen (s. Kap. H.1.1) bleiben von den Zeichensatzvorgaben unbe- +rührt (d. h. sind stets erforderlich und mit fester Codierung vorgegeben). + +Wird ein Auftrag an ein Kreditinstitut übermittelt, der hinsichtlich Zeichensatz und +Codierung nicht den Richtlinien entspricht, so ist dieser abzuweisen. Eine kreditinsti- +tutsseitige Korrektur der Auftragsdaten erfolgt nicht. + + +#### B.2 Nachrichtenelemente + + +##### ◆ Datenelemente + +Datenelemente (DE) sind die kleinsten syntaktischen Informationseinheiten. + + +##### . Datenelementgruppen + +Zusammengehörende Daten können zu einer syntaktischen Einheit zusammenge- +fasst werden. Diese Datenelementgruppen (DEG) bestehen wiederum aus Daten- +elementen. Jede DEG kann beliebig viele DE enthalten. Datenelementgruppen kön- +nen nur unter bestimmten Bedingungen Bestandteil einer Datenelementgruppe sein +(s. Kap. H.1)). + + +##### . Segmente + +Datenelemente und Datenelementgruppen setzen sich zu Segmenten (SEG) zu- +sammen. Jedes Segment enthält bestimmte zusammengehörige Informationen (z. +B. Steuerinformationen, Nutzdaten oder Signatur). Die Segmente werden aus- +schlieBlich in der angegebenen Reihenfolge eingestellt, sofern eine Reihenfolge +vorgegeben ist. + + +##### . Segmentfolgen + +Eine Segmentfolge (SF) beschreibt eine Gruppe von Segmenten, die nur gemein- +sam auftreten dürfen. Dabei handelt es sich nicht um eine syntaktische, sondern nur +um eine logische Einheit. + + +##### . Nachrichten + +Die Kommunikation zwischen Kunde und Kreditinstitut erfolgt bei FinTS über Nach- +richten. Nachrichten setzen sich aus einer vorgegebenen Segmentabfolge zusam- +men (s. Abbildung). Ausnahmslos alle Nachrichten (Kunde an Kreditinstitut und um- +gekehrt) enthalten je ein Kopf- und ein Abschlusssegment. Alle weiteren Nachrich- + + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
10		Stand: 06.10.2017Kapitel: Nachrichtenaufbau
Abschnitt: Festlegungen
+ + +teninhalte werden ebenfalls in Segmente, die vom Aufbau her dem allgemeinen fes- +ten Segmentformat entsprechen, eingestellt. Der allgemeine Nachrichtenaufbau +(Segmentabfolge) ist in den jeweiligen Kapiteln zu Kunden- und Kreditinstitutsnach- +richten (B.6, B.7) beschrieben. + + +Abbildung 2: Nachrichtenaufbau + +![Nachrichtenkopf Segmentkopf DE 1 Segment 1 DE 1 (DEG 1) . . Nachricht . . DEG 2 (DE 2) . . . . Segment n . . Nachrichten- abschluss DE n (DEG n) DE n](figures/18.1) + + +#### Β.3 Festlegungen + + +##### B.3.1 Status und Anzahl + +Alle Datenstrukturen sind durch einen Existenzstatus beschrieben. Folgende Stati +sind möglich: + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBedeutungErläuterung
MMussDatenstruktur muss vorhanden sein und ist in- haltlich korrekt zu füllen
CKonditionalDatenstruktur ist konditional, d. h. der Status (M = Muss, O = optional, N = Nicht erlaubt) ist von einer Bedingung (condition) abhängig
OOptionalDatenstruktur ist optional
Nnicht erlaubt (not allowed)Datenstruktur darf nicht vorhanden sein. Dieser Status ist nur im Zusammenhang mit dem Status ,Konditional' erlaubt.
+ + +In Zusammenhang mit der Angabe zur Anzahl des Auftretens ergeben sich folgende +Bedeutungen: + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: B
Dokument:Formals
Kapitel:
Abschnitt:		Nachrichtenaufbau FestlegungenStand: 06.10.2017Seite: 11
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Sta- tusAn- zahlBedeutung
O1Das Element kann einmal auftreten oder entfallen
OmDas Element kann bis zu m-mal auftreten oder entfallen
OnDas Element kann unbegrenzt oft auftreten oder entfallen
Cnabhängig von der jeweiligen Regel
M1Das Element muss genau einmal auftreten
MmDas Element muss genau m-mal auftreten (m>1)
MnDas Element kann unbegrenzt oft auftreten, muss aber mindestens 1-mal auftreten
Ml..mDas Element kann bis zu m-mal, muss aber mindestens l-mal auftreten
+ + +Die Stati beziehen sich jeweils auf die beschriebene Syntaxebene. Stati übergeord- +neter Syntaxebenen sind hiervon unbenommen. + +Beispiel: +Eine DEG hat den Status 'Optional', ihre DE haben den Status 'Muss'. + +Bedeutung: Die DEG kann optional eingestellt werden. Wenn sie jedoch eingestellt +wird, müssen alle DE, die den Status 'Muss' haben, gefüllt werden. + +Bei numerischen optionalen Elementen ist zwischen der Nichtbelegung und der Be- +legung mit dem Wert 0 zu unterscheiden. + +Beispiel: +Stellt das Kreditinstitut in das Kann-DE ,,Dispokredit" den Wert '0' ein, +bedeutet dies, dass dem Kunde kein Kredit zur Verfügung steht. Stellt +es dagegen das DE nicht ein, so ist keine Interpretation des Kreditrah- +mens möglich. + + +##### B.3.2 Restriktionen + +Durch Restriktionen können die Werte, die eine Datenstruktur annehmen kann, oder +die Bedingung, unter denen eine Datenstruktur auftreten kann, näher spezifiziert +werden. Restriktionen werden in der Datenstrukturtabelle beim jeweiligen Element +aufgeführt. Diese können sein: + +· Zulässige Werte (insb. beim Datentyp ,code') + +• Wertebereiche (z. B. > 100) + +. konditionale Belegungsregeln + +Konditionale Belegungsregeln treten in Verbindung mit dem Status „C“ (konditional) +auf. In diesem Fall beschreibt die Restriktion, unter welcher Bedingung das Element +welchen Status annimmt. + +Beispiel: + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Element1DEC1M: <Bedingung> N: sonst
+ + +Bedeutung: Falls die Bedingung vorliegt, muss das Element zwingend +auftreten. Andernfalls darf es nicht belegt werden. + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
12		Stand: 06.10.2017Kapitel: Nachrichtenaufbau
Abschnitt: Festlegungen
+ + +##### B.3.3 Längenangaben + +Die Zahlen in der Tabellenspalte "Länge" geben jeweils die Länge des Datenele- +mentes in Byte an. Die Angabe bezieht sich auf die Darstellung vor Entwertung (vgl. +Kap. H.1.3), d. h. in entwerteter Darstellung kann die Zeichenkette evtl. eine größere +Länge aufweisen. + +Es ist zwischen Maximal- und Festlängen zu unterscheiden. Sind der Längenanga- +be zwei Punkte '..' vorangestellt, so handelt es sich um eine Maximallänge. In die- +sem Fall darf das eingestellte Datenelement auch eine geringere Länge aufweisen. +Bei Festlängen dagegen führt jede Abweichung von der angegebenen Längenan- +gabe zu einem Syntaxfehler. + +Die Angabe '..' ohne Ziffern kennzeichnet ein Datenelement beliebiger Länge (z. B. +externe Datenformate). Bei abgeleiteten Datenformaten (z. B. Datum, Uhrzeit) ist +die maximale Länge durch die Formatdefinition vorgegeben. Dieser Fall ist durch ein +'#' im Längenfeld gekennzeichnet. DEG besitzen weder ein Längen- noch ein For- +matfeld, da sich die Länge einer DEG aus der Summe der Längen der zugehörigen +DE ergibt. Die Länge von Binärdaten wird im Segment durch ein vorangestelltes +Längenfeld angegeben. + + +#### B.3.4 Transparente Daten + +Im Rahmen dieser Schnittstelle werden gegebenenfalls Daten gemäß anderer +Standards und Formate (z. B. SEPA, camt) transparent eingestellt. Diese trans- +parent eingestellten Daten werden wie binäre Daten behandelt. Somit haben die Be- +legungs- und Formatregeln (auch Zeichensatzkonventionen) des FinTS-Standards +an dieser Stelle keinen Einfluss. An dessen Stelle treten die Belegungs- und For- +matregeln des jeweiligen Formatstandards. Institutsindividuelle Belegungen sind bei +transparenten Formaten nicht zugelassen. + + +#### B.3.5 Datum und Uhrzeit + +Generell besitzen Datums- und Uhrzeitangaben, die von Kundensystemen automa- +tisch generiert werden (z. B. Zeitpunkt der Signatur), keinen rechtsverbindlichen +Charakter, da nicht davon ausgegangen werden kann, dass Kundensysteme diese +Daten korrekt erzeugen. + +Datum und Uhrzeit, die vom Kundensystem gesendet werden, besitzen somit keine +verarbeitungstechnische Bedeutung, sondern lediglich dokumentarischen Charak- +ter. Dies bezieht sich nicht auf Datums- und Uhrzeitangaben, die vom Kunden selbst +eingegeben werden (z. B. Ausführungsdatum von terminierten Überweisungen). + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: B
Dokument:Formals
Kapitel: Abschnitt:Nachrichtenaufbau DatenformateStand: 06.10.2017Seite: 13
+ + +#### B.4 Datenformate + + +##### B.4.1 Basisformate + +Grundsätzlich sind Daten nicht durch Leerzeichen auf feste Längen aufzufüllen. Alle +Daten mit Ausnahme von Binärdaten müssen um führende und nachfolgende Leer- +zeichen gekürzt werden, bevor sie in die Nachricht eingestellt werden. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
NameKen- nungBeschreibung
AlphanumerischanEs gilt der FinTS-Basiszeichensatz ohne die Zeichen CR und LF.
TexttxtEs gilt der vollständige FinTS-Basiszeichensatz.
DTAUS-ZeichensatzdtaEs gilt der DTAUS-Zeichensatz mit der entsprechenden Co- dierung.
2
NumerischnumZulässig sind lediglich die Ziffern '0' bis '9'. Führende Nullen sind nicht zugelassen.
ZifferndigZulässig sind die Ziffern '0' bis '9'. Führende Nullen sind zu- gelassen.
Fließkommadar- stellungfloatEs gelten die Ausführungen zu numerischen Daten. Zusätz- lich ist als Dezimaltrennzeichen das Komma erlaubt. Es gelten folgende Regeln bzgl. der Bildung von Fließkom- mazahlen:
. Der Integer-Teil einer Fließkommazahl hat aus mindes- tens einem Zeichen zu bestehen.
. Nachkommastellen mit dem Wert 0 sind von rechts zu kürzen.
• Führende Nullen sind nicht zugelassen (Ausnahme: Werte mit dem Betrag kleiner 1 müssen eine führende Null ha- ben).
· Das Komma als Dezimaltrennzeichen ist obligatorisch.
Beispiele: 100,00 → 100, 100,20 → 100,2
4.567,89 → 4567,89
0 → 0,
0,50 → 0,5
BinärbinBinäre Daten werden unverändert in den FinTS-Datensatz eingestellt. Eine Umwandlung in eine Zeichendarstellung er- folgt nicht. Es ist zu beachten, dass der FinTS-Basiszeichen- satz für binäre Daten keine Gültigkeit besitzt. Ferner gelten die speziellen Syntaxregeln für binäre Daten (s. Kap. H.1.3).
Kapitel:Version:Financial Transaction Services (FinTS)
B3.0-FVDokument: Formals
Seite:Stand:Kapitel: Nachrichtenaufbau
1406.10.2017Abschnitt: Datenformate
+ + +##### B.4.2 Abgeleitete Formate + +Nachstehende aus den oben genannten Basisformaten abgeleitete Formate haben +stets den folgenden Aufbau: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
NameKen- nungBasis- formatLän- geBeschreibung
Ja/Neinjnan1Format: J bzw. N (in Großbuchstaben) Hat das DE den Status ,Kann", so gilt bei Auslassung der Standardwert ,,N“.
Codecodean#Es sind nur die jeweils aufgeführten Werte zulässig.
Datumdatnum8Format: JJJJMMTT gemäß ISO 8601 Erlaubt sind alle existenten Datumsangaben.
Virtuelles Datumvdatnum8Format: JJJJMMTT gemäß ISO 8601 Unabhängig vom Monat sind jeweils 31 Tage möglich (z. B. 31.04. als Valutadatum für Zinsabschlüsse oder Ausführungsdatum von Daueraufträgen).
Uhrzeittimdig6Format: hhmmss gemäß ISO 8601 Gültige Uhrzeit. Es ist immer Ortszeit des sendenden Systems einzustellen. Unter- schiedliche Zeitzonen werden nicht unter- stützt
Identifikationidan..30dient der eindeutigen Kennzeichnung von Objekten (z. B. Benutzerkennung, Kontonum- mer)
Länderkennzeichenctrdig3Kennzeichen gemäß ISO 3166-1 (numeri- scher Code)
Währungcuran3Kennzeichen gemäß ISO 4217 (alphabeti- scher Code) in Großbuchstaben4
Wertwrtfloat..15Fließkommabetrag (z. B. für Wertbeträge o- der Zinssätze)
+ + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: B
Dokument:Formals
Kapitel:
Abschnitt:		Steuerstrukturen
Nachrichtenaufbau		Stand: 06.10.2017Seite: 15
+ + +#### B.5 Steuerstrukturen + + +##### B.5.1 Segmentkopf + + +##### . Beschreibung + +Informationen, die jedem Segment als Kopfteil vorangestellt sind. Im Unterschied zu +Nachrichten enthalten Segmente jedoch keinen Abschlussteil, da das Segmentende +durch das Segmentende-Zeichen markiert ist. + +Im Segmentkopf stehen die Segmentkennung und Segmentversion unabhängig von +der FinTS-Version (s. DE ,,HBCI-Version") immer an derselben Stelle, damit ein +Segment auch in späteren FinTS-Versionen immer eindeutig als solches identifiziert +werden kann. + + +##### . Format + +siehe Data-Dictionary + + +#### B.5.2 Nachrichtenkopf + + +##### . Beschreibung + +Nachstehender Kopfteil führt alle Kunden- und Kreditinstitutsnachrichten an. + + +##### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Nachrichtenkopf
Typ:Segment
Segmentart:Administration
Kennung:HNHBK
Bezugssegment:-
Version:3
Sender:Kunde/Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Nachrichtengröße1DEdig12M1
3HBCI-Version1DEnum..3M1
4Dialog-ID1DEid#M1
5Nachrichtennum- mer1DEnum.4M1>0
6Bezugsnachricht1DEGC1M: bei Kreditinstitutsnach- richten N: bei Kundennachrichten
+ + +### . Belegungsrichtlinien + + +### HBCI-Version + +Für die in diesem Dokument beschriebene HBCI-Version muss der Wert +,300' (für Version 3.0) eingestellt werden. + + +### B.5.3 Nachrichtenabschluss + + +### . Beschreibung + +Dieses Segment beendet alle Kunden- und Kreditinstitutsnachrichten. + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
16		Stand: 06.10.2017Kapitel: Nachrichtenaufbau
Abschnitt: Steuerstrukturen
+ + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Nachrichtenabschluss
Typ:Segment
Segmentart:Administration
Kennung:HNHBS
Bezugssegment:-
Version:1
Sender:Kunde/Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Nachrichten- nummer1DEnum..4M1>0
+ + +### . Belegungsrichtlinien + + +### Nachrichtennummer + +Es ist die Nummer der Nachricht einzustellen, die auch im Nachrichtenkopf +eingestellt ist. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: B
Dokument:Formals
Kapitel:
Abschnitt:		Nachrichtenaufbau Kundennachrichten allgemeinStand: 06.10.2017Seite: 17
+ + +## B.6 Kundennachrichten allgemein + + +### B.6.1 Allgemeiner Nachrichtenaufbau + + +### . Beschreibung + +In einer Nachricht sind Aufträge beliebiger unterschiedlicher Geschäftsvorfallsarten +zugelassen (z. B. drei Segmente HKCCS und ein Segment HKSAL). Eine Ein- +schränkung ist mit Hilfe des Feldes „Anzahl Geschäftsvorfallsarten" im Segment +„Bankparameter allgemein“ möglich. + +Bezüglich der Reihenfolge der in die Nachricht einzustellenden Aufträge wird keine +Vorgabe getroffen. Da die Reihenfolge der Weiterleitung von Aufträgen an die Ver- +arbeitungssysteme institutsspezifisch ist, beeinflusst die Anordnung der Aufträge +nicht zwingend die Reihenfolge der Verarbeitung bzw. Ausführung. Insbesondere ist +daher auch keine kundenseitige Priorisierung der Aufträge durch deren Anordnung +in der Nachricht möglich. + + +![](figures/25.1) + + +Eine Priorisierung von Aufträgen könnte für den Kunden u. U. wün- +schenswert sein, wenn bei geringer Deckung des Kontos mehrere +Zahlungsaufträge mit unterschiedlicher Priorität ausgeführt werden +sollen. In diesem Fall sollten zuerst die wichtigen Aufträge ausge- +führt werden. Da die eingereichten Zahlungsaufträge nicht notwen- +digerweise in dieser Reihenfolge ausgeführt werden, könnte das +Kundenprodukt vor dem Versenden automatisch den Kontensaldo +(und ggf. Kontokorrentkredit) abfragen und mit der Summe der Zah- +lungsaufträge vergleichen. Sind alle Aufträge gedeckt, können sie +automatisch versendet werden. Bei mangelnder Deckung kann dies +dem Kunden mitgeteilt werden, damit er zunächst lediglich die Auf- +träge mit hoher Priorität einreicht. + +Werden in einer Nachricht Aufträge mit verschiedenen Signaturvorschriften ge- +mischt, so werden diejenigen Aufträge der Nachricht ausgeführt, für welche die Si- +gnatur ausreichend ist. + + +![](figures/25.2) + + +Falls der Kunde Aufträge verschiedener Geschäftsvorfallsarten oder +Signaturvorschriften formuliert und diese zusammen abschicken +möchte, so obliegt es dem Kundenprodukt, die Aufträge jeweils in +Nachrichten mit gleichem Geschäftsvorfall und Signatur aufzuteilen +und diese nacheinander zu verschicken. + +Das Kundenprodukt sollte grundsätzlich vor dem Senden des Auf- +trags anhand der in den UPD übermittelten Daten prüfen, ob der +vom Kunden gewählte Geschäftsvorfall für das angegebene Konto +zulässig ist. + + +#### . Format + + + + + + + + + + + + + + + + + + + +
Name:Kundennachricht allgemein
Typ:Nachricht
Version:4
Sender:Kunde
+ + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
18		Stand: 06.10.2017Kapitel: Nachrichtenaufbau
Abschnitt:
Kundennachrichten allgemein
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypKen- nungSta- tusAn- zahlAnmerkungen
1Nachrichtenkopf3SEGHNHBKM1
2Signaturkopf4SEGHNSHKM1..3s. [HBCI], Kap. B.5.1
3Aufträge2SF#M1
4Zwei-Schritt-TAN- Einreichung≥6SEGHKTANO1s. [PINTAN], Kap. B.3.3 und B.4
5Signaturabschluss2SEGHNSHAM1..3s. [HBCI], Kap. B.5.2
6Nachrichtenab- schluss1SEGHNHBSM1
+ + +### . Belegungsrichtlinien + + +#### Signaturkopf + +Je nach Nachrichtentyp ist hier die Signatur des Übermittlers bzw. Die Signa- +tur des Unterzeichners einzustellen. + +Der Signaturkopf darf nur bei Mehrfachsignaturen mehrfach eingestellt wer- +den. + + +#### Zwei-Schritt-TAN-Einreichung + +Zur Einleitung des Prozesses der Gewährleistung einer starken Kun- +denauthentifizierung gemäß [PSD2] muss bei TAN-Verfahren ein HKTAN- +Segment ab Segmentversion #6 eingestellt werden, wenn ein Kreditinstitut +die Verwendung von HKTAN#6 unterstützt (BPD). Ansonsten kann der Dialog +vom Institut mit dem Rückmeldungscode 9075 - Dialog abgebrochen +\- Starke Authentifizierung erforderlich abgewiesen werden. + + +#### Signaturabschluss + +Der Signaturabschluss darf nur bei Mehrfachsignaturen mehrfach eingestellt +werden. Die Anzahl der Signaturabschlusssegmente muss mit der Anzahl +der Signaturkopfsegmente übereinstimmen. + + +Abbildung 3: Logischer Nachrichtenaufbau + +![Nachricht Auftragsart Auftrag 1 Auftrag 2 Auftrag n](figures/26.1) + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: B
Dokument:Formals
Kapitel:
Abschnitt:		Nachrichtenaufbau Kundennachrichten allgemeinStand: 06.10.2017Seite: 19
+ + +## B.6.2 Aufträge + + +### . Beschreibung + +Die Segmentfolge enthält die in [Messages] definierten Auftragssegmente des Kun- +den. Jedes Segment kann dabei beliebig oft und in beliebiger Reihenfolge auftreten. +Das Kreditinstitut hat jedoch mit Hilfe der Bankparameterdaten die Möglichkeit, die +Art und Anzahl der erlaubten Segmente einzuschränken: + +. Die erlaubten Kundensegmente gibt das Kreditinstitut in den Geschäftsvorfallpa- +rametern an (s. Kap. D.6) + +· Die maximale Anzahl von Geschäftsvorfallssegmenten pro Nachricht kann mit +Hilfe des DE ,,Maximale Anzahl Aufträge“ eingestellt werden (s. Kap. D.6). + +• Die maximale Anzahl von Geschäftsvorfallsarten pro Nachricht kann mit Hilfe des +DE „Anzahl Geschäftsvorfallsarten" eingestellt werden (s. Kap. D.2). + + + + + + + + + + + + + + + + + + + + + + +
. Format
Name:Aufträge
Typ:Segmentfolge
Sender:Kunde
Version:2
+ + +## B.6.3 Abholauftrag + + +### . Beschreibung + +Abholaufträge werden an das Kreditinstitut gesendet, um die institutsseitige Gene- +rierung und Übermittlung von spezifischen Informationen einzuleiten (z. B. Konto- +umsätze, Börsenkurse). In Abgrenzung dazu haben Transaktionsaufträge nicht nur +einen Informationsfluss, sondern reale Transaktionen zur Folge (z. B. Überwei- +sungsauftrag). + +Falls im Abholauftrag keine Währung angegeben wird, entspricht die Währung, in +der die Kreditinstitutsantwort auf den Abholauftrag erfolgt, stets der Währung des +Kundenkontos. + + +### . Format + +Das Segmentformat ist beim jeweiligen Geschäftsvorfall spezifiziert. Die Erläute- +rungen beziehen sich auf die dort angegebenen Felder. + + +### ◆ Erläuterungen + + +### Kontoverbindung Auftraggeber + +Es ist diejenige Kontoverbindung des Kunden einzustellen, für die im Abhol- +auftrag Daten zurückgemeldet werden sollen. Falls der noch zur Ausführung +anstehende Auftrag nicht in Beziehung zu einem bestimmten Konto steht (z. +B. Abruf von Devisenkursen, Abruf des Statusprotokolls), so ist eine beliebi- +ge Kontoverbindung des Kunden einzustellen. Es darf nur ein Konto eines +Kreditinstituts angegeben werden, für das sich der Kunde im Rahmen der +Dialoginitialisierung legitimiert hat. + + +### Alle Konten + +Mit dieser Option kann gewählt werden, ob die angeforderten Informationen +(z. B. Salden, Umsätze) nur zu dem angegebenen oder zu allen Anlagekon- +ten des Kunden, für die er eine Zugriffsberechtigung besitzt, zurückgemeldet +werden sollen. + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
20		Stand: 06.10.2017Kapitel: Nachrichtenaufbau
Abschnitt: Kundennachrichten allgemein
+ + +![](figures/28.1) + + +Zur Zeit können Aufsetzpunkte evtl. nicht korrekt zugewiesen +werden, wenn mehrere Antwortsegmente gesendet werden. +Daher sollte die Option ,,Alle Konten" nur erlaubt werden, +wenn ein Aufsetzpunkt aufgrund der bankseitigen Verarbei- +tung nicht vorkommen kann. + + +## Von Datum, Bis Datum + +Mit Hilfe dieser Angaben kann die Menge der zurückzumeldenden Daten +(z. B. Buchungspositionen) anhand eines Zeitraums eingegrenzt werden. +Wird kein Zeitraum angegeben, so werden stets alle verfügbaren Einträge +zurückgemeldet. Wird ein Zeitraum angegeben, so werden nur diejenigen +Einträge zurückgemeldet, die im Zeitraum (einschließlich des Grenzdatums) +liegen. Die Eingabemöglichkeiten sind der nachfolgenden Tabelle zu ent- +nehmen. + +Falls der Zeitraum inkonsistent ist (Anfangsdatum größer als Enddatum), +wird der Auftrag abgelehnt. Ein Zeitraum darf nicht gleichzeitig mit einem +Kennungsbereich (s. u.) angegeben werden. + + +### Beispiele: + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Von DatumBis DatumBedeutung
01.07.201631.07.2016liefert alle Einträge, die im angegebenen Zeitraum liegen
01.07.2016leerliefert alle Einträge, die am 1.7.2016 oder danach angefallen sind
leer31.07.2016liefert alle Einträge, die am 31.7.2016 oder davor angefallen sind
leerleerliefert alle verfügbaren Einträge
+ + +## Von , Bis + +Hier kann der Abholbereich durch bankfachliche Informationen (z. B. Dauer- +auftrags-ID, Wertpapiernamen) eingegrenzt bzw. genauer spezifiziert wer- +den, sofern dies durch den betreffenden Geschäftsvorfall unterstützt wird. + +Falls die Informationen zu einer bestimmten Kennung (z. B. Kontonummer +xy) abgeholt werden sollen, so ist in beide Felder dieselbe Kennung einzu- +tragen. + +Im Übrigen gelten die Festlegungen zu den Feldern ,,Von Datum“ und ,Bis +Datum". + + +## Aufsetzpunkt + +Falls das Kreditinstitut den Kundenauftrag nicht in einem einzigen Auftrags- +segment beantworten kann, besteht die Möglichkeit, dass es die Beantwor- +tung an einem bestimmten Punkt kontrolliert beendet und dem Kunden in der +Antwortnachricht mit dem Rückmeldungscode einen Aufsetzpunkt mitteilt. +Hierzu ist der spezielle Rückmeldungscode 3040 (,Es liegen weitere Infor- +mationen vor") vorgesehen. Der Aufsetzpunkt kann ein beliebiger institutsin- +terner Ordnungsbegriff sein, der vom Kundenprodukt nicht interpretiert zu +werden braucht. Bei transparenten Daten kann die Fragmentierung beliebig + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: B
Dokument:Formals
Kapitel: Abschnitt:Nachrichtenaufbau Kundennachrichten allgemeinStand: 06.10.2017Seite: 21
+ + +(z. B. logisch oder binär) erfolgen. Es ist lediglich zu fordern, dass die Zu- +sammensetzung der Fragmente im Kundensystem problemlos möglich ist. + + +![](figures/29.1) + + +Grundsätzlich hat das Kreditinstitutssystem dafür Sorge zu +tragen, dass auch bei umfangreichen Abholaufträgen (z. B. +Abruf der Kontoumsätze der vergangenen drei Jahre oder +Abruf sämtlicher verfügbarer Börsenkurse) die komplette In- +formation in einem Antwortsegment übertragen wird. D .h. es +muss ausgeschlossen sein, dass als Antwort auf einen Ab- +holauftrag dem Kunden wegen zu großer Antwortnachricht +nur ein Teil der geforderten Informationen zurückgemeldet +wird. Seitens des Kreditinstituts besteht jedoch bei Über- +schreitung von Zeit- oder Volumengrenzen die Möglichkeit, +den Auftrag abzulehnen. + + +![](figures/29.2) + + +Falls das Kreditinstitut jedoch einen Aufsetzpunkt rückmel- +det, wird vom Kundenprodukt erwartet, dass es denselben +Abholauftrag unter Hinzufügung des Aufsetzpunktes erneut +schickt. In der Antwortnachricht erhält der Kunde den fol- +genden Teil der Informationen (evtl. inkl. eines erneuten Auf- +setzpunktes) rückgemeldet. Dieses Verfahren kann sich so- +lange wiederholen, bis die komplette Informationsmenge +übertragen wurde. Die Generierung der Folgenachrichten +sollte automatisch, d. h. ohne Einwirkung des Kunden, erfol- +gen. + +Ein Aufsetzpunkt darf vom Kundenprodukt nur dann einge- +stellt werden, wenn im selben Dialog ein Aufsetzpunkt vom +Kreditinstitut rückgemeldet wurde. Nach Beendigung des Di- +aloges verliert der Aufsetzpunkt seine Gültigkeit. + + +## Maximale Anzahl Einträge + +Dieser Parameter dient dazu, die maximale Anzahl zurück zu meldender Ein- +träge zu begrenzen. Diese Begrenzung kann auf Wunsch des Kunden erfol- +gen oder aus technischen Restriktionen des Kundensystems resultieren. So +wird Endgeräten, die aufgrund technischer Restriktionen nur eine begrenzte +Anzahl rückgemeldeter Einträge (z. B. Umsatzinformationen im Kontoaus- +zug) verarbeiten können, die Möglichkeit gegeben, den Umfang der Instituts- +nachrichten zu begrenzen. Falls der Kunde keine Begrenzung wünscht, wird +das DE ausgelassen. Der Wert 0 ist nicht zulässig. + +Falls im angegebenen Bereich weniger Einträge vorliegen als in „Maximale +Anzahl Einträge“ angegeben, werden nur die vorliegenden Einträge zurück +gemeldet. Falls mehr Einträge vorliegen, werden laut untenstehender Tabel- +le nur Einträge zurück gemeldet. In diesem Fall erhält das Kun- +densystem im Rückmeldungscode mitgeteilt, dass noch weitere Informa- +tionen vorliegen. Im Rückmeldungsparameter wird dem Kundensystem ein +Aufsetzpunkt (s. o.) zurückgemeldet, mit Hilfe dessen die über +hinausgehenden Einträge abgerufen werden können. + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite: 22Stand: 06.10.2017Kapitel: Nachrichtenaufbau
Abschnitt: Kundennachrichten allgemein
+ + +## Beispiel: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Von DatumBis DatumAnzahlBedeutung
01.07.201631.07.201610liefert die ersten 10 Einträge ab 1.7.2016 (sofern mindestens 10 Einträge vorhanden, sonst weniger)
01.07.2016leer10liefert die ersten 10 Einträge ab 1.7.2016
leer31.07.201610liefert die letzten 10 Einträge vor dem 31.07.2016
leerleer10liefert von allen verfügbaren Einträgen die letzten 10
+ + +![](figures/30.1) + + +Die Einträge werden dem Kunden stets in aufsteigender +Reihenfolge rückgemeldet. Eine hiervon abweichende Sor- +tierung (z. B. absteigend oder nach anderen Kriterien) kann +das Kundenprodukt bei Bedarf dem Kunden anbieten. + + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
3010Es liegen keine Einträge vor
3040Auftrag nur teilweise ausgeführt
3040Es liegen weitere Informationen vor
9210Keine gültige Kontoverbindung des Kunden
9210Zeitraum hier nicht erlaubt
9210Kennungen hier nicht erlaubt
9210Bereichende darf nicht vor Bereichanfang liegen
9210Aufsetzpunkt unbekannt
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: B
Dokument:Formals
Kapitel:
Abschnitt:		Nachrichtenaufbau Kreditinstitutsnachrichten allgemeinStand: 06.10.2017Seite: 23
+ + +## B.7 Kreditinstitutsnachrichten allgemein + + +### B.7.1 Allgemeiner Nachrichtenaufbau + + +### . Beschreibung + +Der nachfolgend beschriebene Nachrichtenaufbau bezieht sich auf unverschlüsselte +Nachrichten (Aufbau verschlüsselter Nachrichten vgl. Kap. B.8). + + +### . Format + + + + + + + + + + + + + + + + + + + +
Name:Kreditinstitutsnachricht allgemein
Typ:Nachricht
Version:4
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypKen- nungSta- tusAn- zahlAnmerkungen
1Nachrichtenkopf3SEGHNHBKM1
2Signaturkopf4SEGHNSHKO1s. [HBCI], Kap. B.5.1
3Rückmeldungen zur Gesamtnachricht2SEGHIRMGM1
4Rückmeldungen zu Segmenten2SEGHIRMSOn
5Datensegmente2SF#O1
6Zwei-Schritt-TAN- Einreichung≥6SEGHITANO1s. [PINTAN], Kap. B.3.3 und B.4
7Signaturabschluss2SEGHNSHAO1s. [HBCI], Kap. B.5.2
8Nachrichtenab- schluss1SEGHNHBSM1
+ + +### . Belegungsrichtlinien + + +### Signaturkopf + +Falls es das Kreditinstitut wünscht, kann es seine Nachrichten ebenfalls sig- +nieren. In diesem Fall hat es dasselbe Signaturverfahren anzuwenden wie +der Kunde. + +Es ist dem Kreditinstitut freigestellt, ob es als Signatur-ID (vgl. [HBCI]) die +vom Kunden gesendete ID verwendet oder einen eigenen Zähler verwaltet. + + +![](figures/31.1) + + +Falls Kreditinstitutsnachrichten signiert werden, hat das +Kundenprodukt deren Signatur verpflichtend zu prüfen. Falls +die Prüfung negativ ausfällt, hat es dem Kunden eine ent- +sprechende Rückmeldung zu geben und den Dialog zu be- +enden. Falls die Prüfung auch bei einem erneuten Dialog +negativ ausfällt, muss von einem Sicherheitsproblem ausge- +gangen werden. + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
24		Stand: 06.10.2017Kapitel: Nachrichtenaufbau
Abschnitt: Kreditinstitutsnachrichten allgemein
+ + +### B.7.2 Rückmeldungen zur Gesamtnachricht + + +#### . Beschreibung + +In diesem Segment werden Rückmeldungen übermittelt, die sich auf die gesamte +Nachricht und nicht auf ein spezifisches Segment beziehen (z. B. ,,Nachricht entge- +gengenommen", "Elektronische Signatur gesperrt"). + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Rückmeldungen zur Gesamtnachricht
Typ:Segment
Segmentart:Administration
Kennung:HIRMG
Bezugssegment:-
Version:2
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameFor- matTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Rückmeldung1DEGM1..99
+ + +## . Belegungsrichtlinien + + +## Rückmeldung + +Das DE ,,Bezugsdatenelement“ dieser DEG ist nicht zu belegen. + +Ein Erfolgscode (Rückmeldungscode der Klasse 0) darf nur eingestellt wer- +den, wenn alle Aufträge fehlerfrei sind, d. h. in den Segmenten „Rückmel- +dungen zu Segmenten“ dürfen in diesem Fall keine Fehlermeldungen ge- +sendet werden. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: B
Dokument:Formals
Kapitel:
Abschnitt:		Nachrichtenaufbau Kreditinstitutsnachrichten allgemeinStand: 06.10.2017Seite: 25
+ + +## B.7.3 Rückmeldungen zu Segmenten + + +### . Beschreibung + +Dieses Segment ist genau einmal für jedes Segment der Kundennachricht einzu- +stellen. Hier sind sämtliche Rückmeldungscodes aufzuführen, die sich auf das Kun- +densegment bzw. die zugehörigen Datenelemente und Datenelementgruppen be- +ziehen. Falls für das jeweilige Kundensegment keine Rückmeldungscodes erzeugt +wurden, kann das zugehörige Rückmeldesegment entfallen. Ist das jeweilige Kun- +densegment fehlerhaft, dann dürfen keine Datensegmente (s.u.) rückgemeldet wer- +den. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Rückmeldungen zu Segmenten
Typ:Segment
Segmentart:Administration
Kennung:HIRMS
Bezugssegment:abhängig von Kundensegment
Version:2
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Rückmeldung1DEGM1..99
+ + +### ◆ Erläuterungen + + +#### Segmentkopf + +Als Bezugssegment ist die Segmentnummer des Kundensegments, auf das +sich die Rückmeldungen beziehen, einzustellen. + + +#### Rückmeldung + +Hier sind diejenigen Rückmeldungscodes einzustellen, die sich auf das Se- +gment (Auftrag) bzw. die zugehörigen Datenelemente und Datenelement- +gruppen beziehen. + + + + + + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:Stand:Kapitel: Nachrichtenaufbau
2606.10.2017Abschnitt: Kreditinstitutsnachrichten allgemein
+ + +## B.7.4 Datensegmente + + +### . Beschreibung + +Hier werden die Daten für die Kreditinstitutsrückmeldung (z. B. Kontoumsätze) ein- +gestellt. Auf ein Kundensegment hin (z. B. ,Dauerauftragsbestand abrufen“) können +hier eine Vielzahl von Segmenten mit identischer Kennung (und somit identischem +Format jedoch unterschiedlichem Inhalt) zurückgeliefert werden (z. B. jedes Seg- +ment liefert die Daten eines Dauerauftrags). + + +![](figures/34.1) + + +Falls das Kreditinstitut mehrere Versionen eines Geschäftsvorfalls +unterstützt, hat es stets mit einem Segment derjenigen Version zu +antworten, die dem Auftragssegment der Kundennachricht ent- +spricht. + +Beispiel: Wenn das Kreditinstitut die Versionen 2, 3 und 4 unter- +stützt und das Kundenprodukt sendet einen Abholauftrag mit der +Segmentversion 3, so hat das Kreditinstitut ebenfalls ein Antwort- +segment der Segmentversion 3 zurückzumelden. + + + + + + + + + + + + + + + + + + + + + + +
. Format
Name:Datensegmente
Typ:Segmentfolge
Sender:Kreditinstitut
Version:2
+ + +### ◆ Erläuterungen + +Die Segmentfolge enthält die in [Messages] definierten Rückmeldungssegmente +des Kreditinstituts. Jedes Segment kann dabei beliebig oft auftreten. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: B
Dokument:Formals
Kapitel: Abschnitt:Nachrichtenaufbau Kreditinstitutsnachrichten allgemeinStand: 06.10.2017Seite: 27
+ + +## B.7.5 Rückmeldungscodes + + +### B.7.5.1 Grundkonzept + +Die Änderung und Ergänzung von Rückmeldungscodes erfolgt in Abstimmung mit +allen beteiligten Verbänden (Gewährleistung der Multibankfähigkeit). Änderungen +bestehender Codes implizieren darüber hinaus neue Versionsnummern der betref- +fenden Segmentformate. + +Institutsindividuelle Rückmeldungen (z. B. Konditionen, Werbung, Hinweise) sind +über den Codebereich "Kreditinstitutsindividuelle Rückmeldung" zu generieren. + + +![](figures/35.1) + + +Die Rückmeldungscodes sollen Kundensystemen automatisierte +Reaktionen auf Institutsnachrichten ermöglichen; z. B. kann bei der +Rückmeldung "BLZ falsch" das Kundensystem automatisiert zur +Korrektur der BLZ aus einer hinterlegten BLZ-Tabelle auffordern. + +Der „Rückmeldungstext“ dient dazu, den Kunden klartextliche In- +formationen zu übermitteln. Kundenprodukte sollten die kreditinsti- +tutsseitigen Rückmeldungen im vollständigen Klartext anzeigen. +Ebenso sollte der numerische Rückmeldungscode stets angezeigt +werden, um den Kreditinstituten eine einfachere Bearbeitung von +Kundenrückfragen zu spezifischen Rückmeldungstexten zu ermög- +lichen. + +Rückmeldungen beziehen sich auf unterschiedliche Datenstrukturen (Nachricht, +Segment, DEG, DE etc.). In Bezug auf eine Datenstruktur können mehrere Rück- +meldungen zurück geliefert werden. + + +![](figures/35.2) + + +Der Umfang der Online-Prüfung (z. B. nur physikalische Entgegen- +nahme der Nachricht oder auch Syntax- und bankfachliche Prüfung) +ist institutsindividuell. + + +![](figures/35.3) + + +### B.7.5.2 Reaktionsvorschriften + +Bei Erfolgsmeldungen (Klasse 0) wird die Nachricht bzw. der Auftrag stets ange- +nommen. Warnungen (Klasse 3) sind Hinweise auf mögliche Fehler, die jedoch +nicht zur Ablehnung führen. Bei Fehlermeldungen (Klasse 9) wird die zugehörige +syntaktische Einheit (Auftrag bzw. Nachricht) abgelehnt. + +Pro Auftrag (Segment) muss im Erfolgsfall genau eine Erfolgsmeldung und im Feh- +lerfall mindestens eine Fehlermeldung eingestellt werden. Warnungen und Hinweise +können darüber hinaus beliebig hinzugefügt werden. + +Nachfolgend sind die gültigen Kombinationen von FinTS-Rückmeldungen unter- +schiedlicher Meldungsklassen aufgeführt: + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
28		Stand: 06.10.2017Kapitel: Nachrichtenaufbau
Abschnitt: Kreditinstitutsnachrichten allgemein
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.Klasse 0 (Erfolg)Klasse 3 (Warnung/ Hinweis)Klasse 9 (Fehler)Ergebnis
11--Auftrag angenommen
211-98-Auftrag angenommen
3-1-Auftrag angenommen
4-2-99-Auftrag angenommen
5--1Auftrag abgelehnt
6-1-981Auftrag abgelehnt
7--2-99Auftrag abgelehnt
8-1-(99)1-(99)Auftrag abgelehnt
+ + +Weitere Hinweise zur Verwendung der Rückmeldungen: + +. Andere als die genannten Kombinationen dürfen für einen Geschäftsvorfall nicht +auftreten. + +· Das Senden einer Warnung ohne kombinierte Erfolgs- bzw. Fehlermeldung ist +nur für den Fall der Teilausführung sinnvoll, da andererseits der Status des Auf- +trags (angenommen bzw. abgelehnt) nicht eindeutig bestimmbar ist. + +· Es ist sinnvoll, die Rückmeldungen an Kunden auf ein überschaubares Maß zu +reduzieren (Kein Ausschöpfen der insgesamt 99 möglichen Meldungen) + +. Um Kundenprodukten die Auswertung zu erleichtern, soll die jeweils wichtigste +Meldung als erste in das Rückmeldungssegment eingestellt werden (Klasse 0 +oder 9, falls vorhanden) + +Auch wenn einzelne Aufträge einer Nachricht inkorrekt sind, müssen andere kor- +rekte Aufträge in derselben Nachricht vom Kreditinstitut ausgeführt werden. Dies gilt +auch für Syntaxfehler, sofern dieser nur Auswirkungen auf einen einzigen Auftrag +hat. D. h., bei Syntaxfehlern in administrativen Segmenten (Nachrichtenkopf, Signa- +turkopf etc.) ist stets die gesamte Nachricht abzulehnen. + + +#### Beispiel: + + + + + + + + + + + + + + + + + + + +
Code-BedeutungReaktion
DE im Auftrag syntaktisch ungültigNachricht ok, Auftrag nicht ok
DE im Nachrichtenkopf syntaktisch ungültigNachricht nicht ok, Auftrag nicht ok
Unbekannter NachrichtenaufbauNachricht nicht ok, Auftrag nicht ok
+ + +Verstöße gegen die syntaktischen Festlegungen in Kapitel H sind nicht zu tolerieren, +sondern führen zur Ablehnung des Auftrags bzw. der Nachricht. + +Folgende Voraussetzungen müssen erfüllt sein, damit die Nachricht als gültig er- +kannt wird: + +• Die Nachricht muss mit der Zeichenkette ,,HNHBK:1:" beginnen. + +· Die Nachricht muss in einzelne Segmente aufgeteilt werden können. + +· Ein Segment muss in einzelne Datenelemente zerlegt werden können. + +. Der Sender darf erst eine neue Nachricht schicken, nachdem er die Kreditinsti- +tutsantwortnachricht erhalten hat. + +• Die Länge der Nachricht darf nicht größer als die in den BPD angegebene maxi- +male Nachrichtengröße sein. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: B
Dokument:Formals
Kapitel:
Abschnitt:		Nachrichtenaufbau Kreditinstitutsnachrichten allgemeinStand: 06.10.2017Seite: 29
+ + +Eine Nachricht, bei der diese Voraussetzungen nicht zutreffen, muss nicht mit einer +Kreditinstitutsnachricht beantwortet werden. In diesem Fall darf das Kreditinstitut +von sich aus die Transportverbindung ohne Rückmeldung beenden. Ansonsten sind +Nachrichten, die gegen grundlegende FinTS-Aufbauvorschriften verstoßen, mit dem +Rückmeldungscode 9110 „Unbekannter Aufbau“ zu beantworten. + +Grundsätzlich werden dem Kunden alle auftretenden Meldungen mitgeteilt. + +Ausnahmen: + +. Tritt in einer Nachricht ein Fehler auf, der dazu führt, dass eine syntaktische Ein- +heit (z. B. Nachricht, Segment, DEG) komplett ungültig ist oder nachfolgende Tei- +le der syntaktischen Einheit ebenfalls fehlerhaft sind (Folgefehler), so kann die +Bearbeitung der syntaktischen Einheit nach diesem Fehler abgebrochen werden. + +· Zu nachgeordneten syntaktischen Einheiten brauchen keine Meldungen rückge- +meldet werden, falls deren Code derselbe ist wie der der übergeordneten syntak- +tischen Einheit (Bsp.: Falls die Nachricht insgesamt fehlerfrei ist, brauchen für die +einzelnen Segmente keine Erfolgsmeldungen rückgemeldet werden). + + +![](figures/37.1) + + +Wurde ein Auftrag abgelehnt, so ist darauf zu achten, dass nach der +Fehlerbehebung bei einem eventuellen neuen Senden durch das +Kundensystem die Nachricht neu aufgebaut wird, d. h. insbesonde- +re eine neue Signatur eingestellt wird. + +Bei Transaktionsaufträgen kann bei der institutsinternen Verarbei- +tung unter Umständen ein Fehler auftreten, bei dem für das rück- +meldende System nicht ersichtlich ist, ob der Fehler vor oder nach +der Verarbeitung des Auftrags aufgetreten ist. In diesem Fall wird +dem Kundenprodukt der Rückmeldungscode 9000 „Status indiffe- +rent" mitgeteilt. Das Kundenprodukt darf den Auftrag anschließend +nicht erneut einreichen, da er eventuell doppelt verarbeitet wird. +Stattdessen hat der Kunde den Status des Auftrags auf anderem +Wege in Erfahrung zu bringen. Das Kundenprodukt sollte dem Kun- +den einen entsprechenden Hinweis geben. + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
30		Stand: 06.10.2017Kapitel: Nachrichtenaufbau
Abschnitt: Kreditinstitutsnachrichten allgemein
+ + +### B.7.5.3 Code-Bedeutungen + +Die Bedeutung der einzelnen Rückmeldungscodes wurde in ein separates Doku- +ment ,,Financial Transaction Services (FinTS) - Rückmeldungscodes" [RM-Codes] +ausgelagert. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: B
Dokument:Formals
Kapitel:
Abschnitt:		Nachrichtenaufbau Kreditinstitutsnachrichten allgemeinStand: 06.10.2017Seite: 31
+ + +## B.7.6 Dialogabbruchnachricht + +In bestimmten Fällen kann es erforderlich sein, dass das Kreditinstitut aufgrund ei- +ner fehlerhaften Kundennachricht oder eines institutsinternen Problems den Dialog +abbrechen muss. + +Bei einem solchen Dialogabbruch muss unterschieden werden, ob es sich um eine +Dialoginitialisierungsnachricht oder um eine Auftragsnachricht handelt. Dabei muss +die Tatsache berücksichtigt werden, dass dem Kreditinstitutssystem evtl. bei Folge- +nachrichten nicht immer alle Daten wie Nachrichtennummer oder Dialog-ID zur Ver- +fügung stehen. In bestimmten Situationen kann dann das Kreditinstitut eine unver- +schlüsselte und nicht signierte Nachricht mit festem Aufbau an das Kundensystem +senden. + +Folgende Situationen sind u.a. denkbar: + +· Bank vorübergehend gesperrt (Release-Einsatz) + +. BLZ unbekannt (nach einer Fusion) + +. Fehlerhafter Nachrichtenkopf + +. Unbekannte HBCI-Version (wird nicht mehr unterstützt) + +• Nachrichtenlänge ungleich + +Die in Kap. B.7.5.2 beschriebene Möglichkeit eines unbeantworteten Dialogab- +bruchs bleibt hiervon unberührt. + + +### . Beschreibung + +Die Abbruchnachricht hat den folgenden festen Aufbau. Sie wird weder verschlüs- +selt noch signiert. + + +![](figures/39.1) + + +Das Kundenprodukt sollte in jedem Fall die Abbruchnachricht mit +dem Hinweistext entgegennehmen und dem Kunden anzeigen. + + +### . Format + + + + + + + + + + + + + + + + + + + +
Name:Abbruchnachricht
Typ:Nachricht
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypKen- nungSta- tusAn- zahlAnmerkungen
1Nachrichtenkopf3SEGHNHBKM1
2Rückmeldungen zur Gesamtnachricht2SEGHIRMGM1
3Nachrichtenab- schluss1SEGHNHBSM1
+ + +### . Belegungsrichtlinien + + +#### Nachrichtenkopf + +Der Nachrichtenkopf ist dabei wie folgt zu belegen: + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
32		Stand: 06.10.2017Kapitel: Nachrichtenaufbau
Abschnitt: Kreditinstitutsnachrichten allgemein
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FeldnameFehler tritt auf bei Dialo- ginitialisierungFehler tritt auf bei Auftrags- nachricht
NachrichtengrößeGröße der NachrichtGröße der Nachricht
HBCI-VersionWenn bekannt, einstellen, ansonsten die vom Institut unterstützte VersionWenn bekannt, einstellen, an- sonsten die vom Institut unter- stützte Version
Dialog-IDKonstante: ,,unbekannt"Wenn bekannt, die Dialog-ID Sonst Konstante: unbekannt
Nachrichtennummer„1“Wenn bekannt, Nachrichten- nummer Sonst Konstante: ,9999"
BezugsnachrichtZu belegen wie Siehe Dialog-ID bzw. NachrichtennummerZu belegen wie Siehe Dialog-ID bzw. Nachrich- tennummer
+ + +##### Rückmeldungen zur Gesamtnachricht + +Das Segment „Rückmeldungen zur Gesamtnachricht" ist mit einem Rück- +meldungscode und Text zu belegen, der den aufgetretenen Fehler möglichst +genau angibt. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: B
Dokument:Formals
Kapitel: Abschnitt:Nachrichtenaufbau Allgemeiner Nachrichtenaufbau bei VerschlüsselungStand: 06.10.2017Seite: 33
+ + +## B.8 Allgemeiner Nachrichtenaufbau bei Verschlüsselung + + +### . Beschreibung + +Beim Sicherheitsverfahren HBCI (s. [HBCI]) werden generell alle Kunden- und alle +Kreditinstitutsnachrichten verschlüsselt. Ausnahmen sind in Kap. C.1.3 aufgeführt. +Bei TAN-Verfahren (s. [PINTAN]) findet eine Transportverschlüsselung z. B. durch +TLS statt (vgl. Kap. I.4). + +Für den Aufbau von verschlüsselten Nachrichten ist folgendes Vorgehen einzuhal- +ten5: + +1\. Die Nachricht ist zunächst unverschlüsselt aufzubauen. + +2\. Das Segment „Verschlüsselungskopf" ist direkt hinter dem Nachrichtenkopf ein- +zustellen. + +3\. Die verschlüsselten Signatur- und Auftragssegmente sind in das Segment ,,Ver- +schlüsselte Daten“ einzustellen. + +Vor der Verschlüsselung weisen die Segmente eine kontinuierliche Nummerierung +auf (s. Abb. links). Um die Eindeutigkeit der Segmentnummern zu gewährleisten, +erhält das Segment „Verschlüsselungskopf“ die Segmentnummer 998 und das +Segment „Verschlüsselte Daten" die Segmentnummer 999 (s. Abb. rechts). Diese +beiden Segmentnummern dürfen daher vor der Verschlüsselung noch nicht verge- +ben worden sein. Bei der Entschlüsselung wird das Segment „Verschlüsselungs- +kopf" entfernt und das Segment „Verschlüsselte Daten“ in die Einzelsegmente auf- +gelöst, so dass die Nachricht wieder eine kontinuierliche Segmentnumerierung auf- +weist. + +Vor Verschlüsselung: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.Segmentname
1Nachrichtenkopf
2Signaturkopf
3Auftrag 1
4Auftrag 2
5Signaturabschluss
6Nachrichtenabschluss
+ + +Nach Verschlüsselung: + + + + + + + + + + + + + + + + + + + + + + + +
Nr.Segmentname
1Nachrichtenkopf
998Verschlüsselungskopf
999Verschlüsselte Daten (enthält: 2 Signaturkopf
3 Auftrag 1
4 Auftrag 2
5 Signaturabschluss)
6Nachrichtenabschluss
+ + +. Format + + + + + + + + + + + + + + + + + + + +
Name:Verschlüsselte Nachricht
Typ:Nachricht
Version:3
Sender:Kunde/Kreditinstitut
+ + + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
34		Stand: 06.10.2017Kapitel: Nachrichtenaufbau
Abschnitt: Allgemeiner Nachrichtenaufbau bei Verschlüsselung
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypKen- nungSta- tusAn- zahlAnmerkungen
1Nachrichtenkopf3SEGHNHBKM1
2Verschlüsselungs- kopf3SEGHNVSKM1s. [HBCI], Kap. B.5.4
3Verschlüsselte Da- ten1SEGHNVSDM1s. [HBCI], Kap. B.5.5
4Nachrichtenab- schluss1SEGHNHBSM1
+ + +### . Belegungsrichtlinien + + +#### Verschlüsselte Daten + +In dieses Segment sind die verschlüsselten Signatur- und Auftragssegmente +einzustellen. + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: C
Dokument:Formals3.0-FV
Kapitel:
Abschnitt:		Dialogspezifikation AllgemeinesStand: 06.10.2017Seite: 35
+ + +# C. DIALOGSPEZIFIKATION + + +## C.1 Allgemeines + + +### C.1.1 Begriffsbestimmung + +Die Identifizierung des Kunden sowie die Festlegung der Rechte, die einem Kunden +im Rahmen eines FinTS-Dialoges offen stehen, erfolgt in FinTS anhand der Begriffe +'Benutzer' und 'Kunde' bzw. anhand der zugeordneten Identifikationsmerkmale 'Be- +nutzerkennung' und 'Kunden-ID'. Hierzu sind folgende Unterscheidungen zu treffen: + + +### Benutzer + +Ein Benutzer ist eine natürliche Person, die als Inhaber oder Berechtigter +(z. B. Bevollmächtigter) eines Kontos über ein Kundenprodukt/-endgerät am +FinTS-Verfahren teilnimmt. Jeder Benutzer kann von seinem Kreditinstitut +Userparameterdaten erhalten, in denen er über seine Rechte im Rahmen +des FinTS-Verfahrens informiert wird. Dem Kreditinstitut gegenüber tritt der +Benutzer als Inhaber eines Sicherheitsmediums auf. + +Die Identifizierung des Benutzers erfolgt anhand des DE Benutzerkennung. + + +### Kunde + +Neben dem allgemeinen Gebrauch des Kundenbegriffs in Abgrenzung zum +Kreditinstitut kann der Begriff 'Kunde' optional dazu verwendet werden, eine +institutsindividuelle Differenzierung eines Benutzers zu ermöglichen, um die +Rolle, in der er auftritt, zu spezifizieren. So lässt sich zum Beispiel unter- +scheiden, ob ein Benutzer den Dialog in der Eigenschaft als Privatperson +oder als Bevollmächtigter einer Firma führen möchte (s. Abbildung 4). Durch +die Rolle werden die Rechte festgelegt, die dem Benutzer im FinTS-Dialog +zur Verfügung stehen. + +Die Identifizierung des 'Kunden', bzw. der Rolle, in der der Kunde auftritt, +kann anhand des DE Kunden-ID erfolgen. + +Es steht dem Kreditinstitut jedoch frei, dem Benutzer für jede Rolle eine ei- +gene Benutzerkennung (Sicherheitsmedium) zur Verfügung zu stellen. Diese +Rolle muss nicht zwingend über eine eigene Kunden-ID im FinTS-System +festgelegt werden. Bei Gleichheit von Benutzerkennung und Kunden-ID im +FinTS-System wird die Rolle des Kunden im nachgelagerten operativen Sys- +tem festgelegt. Sie entscheidet sich durch die Verknüpfungen zwischen Be- +nutzerkennung und 'interner' Kundennummer und den dazugehörigen Kon- +ten mit ihren jeweiligen Vollmachten. + +Der Kundenbezug gilt immer für den gesamten Dialogkontext, d. h. für sämt- +liche Benutzer, die im Rahmen des Dialoges als Signierende auftreten (d. h. +auch für eventuelle Zweit- und Drittsignierende). + + +![](figures/43.1) + + +Da Kunden-ID und Benutzerkennung voneinander abweichen +können, ist im Kundenprodukt eine Eingabemöglichkeit für die +Kunden-ID vorzusehen. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
36		Stand: 06.10.2017Kapitel: Dialogspezifikation
Abschnitt: Allgemeines
+ + +Im Einzelnen sind folgende Belegungsvarianten für Benutzerkennung und Kunden- +ID möglich: + +· Benutzerkennung und Kunden-ID sind identisch: + +In diesem Fall wird institutsseitig keine logische Differenzierung zwischen Kunde +und Benutzer vorgenommen. Die Benutzerkennung wird in das Feld 'Kunden-ID' +eingestellt. Die Rolle des Benutzers ergibt sich, wie oben dargestellt, erst im nach +gelagerten System. + +· Benutzerkennung und Kunden-ID sind nicht identisch: + +Es wird institutsseitig eine logische Differenzierung zwischen Kunde und Benut- +zer vorgenommen, um die Rolle festzulegen, in der der Benutzer auftritt. + +Die folgenden Abbildungen gelten für den Fall, dass die Kunden-ID genutzt wird, um +die Rolle des Benutzers festzulegen: + + +Abbildung 4: Benutzer, mehreren Kunden zugeordnet + +![Benutzerkennung: 26314255 Ernst Müller Rolle: Prokurist Rolle: Privatperson Zugriff auf Konten: 345678 345679 Zugriff auf Konten: 1234 345680 Kunden-ID: 28515199 Kunden-ID: 26314255 Firma Meyer & Co. Ernst Müller Hat Konten: Hat Konten: 1234 345678 345679 345680](figures/44.1) + + +Abbildung 5: Kunde, mehreren Benutzern zugeordnet + +![Benutzerkennung: 83637129 Benutzerkennung: 26314255 Eva Schulze Ernst Müller Rolle: Sekretärin Rolle: Prokurist Zugriff auf Konten: Zugriff auf Konten: 345678 Kunden-ID: 28515199 345678 345679 345679 Firma Meyer & Co. 345680 Hat Konten: 345678 345679 345680](figures/44.2) + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: C
Dokument:Formals3.0-FV
Kapitel:
Abschnitt:		Dialogspezifikation AllgemeinesStand: 06.10.2017Seite: 37
+ + +## C.1.2 Dialogabfolge + +Die Initiierung eines Dialogs geht stets vom Kunden aus. Auf eine Kundennachricht +wird stets mit einer genau definierten Kreditinstitutsnachricht unmittelbar geantwor- +tet. Erst wenn der Kunde diese Kreditinstitutsnachricht vollständig erhalten hat, darf +er die nächste Nachricht an das Kreditinstitut übermitteln (Ausnahme: Nach einem +Verbindungsabbruch sendet der Kunde im nächsten Dialog eine Nachricht an das +Kreditinstitut, ohne vorher eine vollständige Antwortnachricht erhalten zu haben). +Sowohl Kunde als auch Kreditinstitut dürfen jeweils nur eine Nachricht auf einmal +übermitteln. Das Kundensystem hat die Pflicht, solange zu warten, bis das Kredit- +institut die entsprechende Antwortnachricht übermittelt hat. + + +Abbildung 6: Dialogabfolge + +![Aufbau der physikalischen Verbindung Dialoginitialisierung Kreditinstitut K Antwort auf Dialoginitialisierung Auftragnachricht 1 K Antwortnachricht u . n . d n . e Auftragnachricht n Antwortnachricht t Dialogendenachricht Antwortnachricht Abbau der physikalischen Verbindung](figures/45.1) + + +Jeder Dialog beginnt mit einer Dialoginitialisierungsnachricht. Erst wenn das Kun- +densystem die Bestätigungsnachricht erhalten hat, darf die erste Auftragsnachricht +gesendet werden. Sollen keine weiteren Auftragsnachrichten mehr gesendet wer- +den, so hat das Kundensystem eine Dialogendenachricht zu senden. Mit der Rück- +meldung auf diese Nachricht erhält das Kundensystem die Dialogendebestätigung +des Kreditinstituts. + +Im Ausnahmefall kann das Kreditinstitut den Dialog auch von sich aus beendigen +(z. B. bei wiederholter ungültiger Authentisierung des Kunden). Hierzu sendet es in +der Antwort auf eine Kundennachricht den Rückmeldungscode 9800 („Dialog abge- +brochen"). Danach kann es die Transportverbindung abbauen. Das Kundenprodukt +hat den Dialog in diesem Fall als beendet anzusehen und darf keine Dialogende- +nachricht mehr schicken. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
38		Stand: 06.10.2017Kapitel: Dialogspezifikation
Abschnitt: Allgemeines
+ + +Abbildung 7: Einzelbenutzer + +![Aufbau der physikalischen Verbindung Dialoginitialisierung für Benutzerkennung 12345 Kreditinstitut K Antwort auf Dialoginitialisierung Einzelüberweisung für Konto 1111 K Antwortnachricht u n d e Kontostandabfrage für Konto 2222 n Antwortnachricht S t i Dialogendenachricht t Antwortnachricht u t Abbau der physikalischen Verbindung](figures/46.1) + + +Sollen Aufträge für mehrere Benutzer gesendet werden, ohne dass die physikali- +sche Verbindung unterbrochen wird, so ist für jede neue Benutzerkennung eine +neue Dialoginitialisierung durchzuführen (s. Abbildung 8). + + +Abbildung 8: Mehrere Benutzer + +![Aufbau der physikalischen Verbindung Dialoginitialisierung für Benutzerkennung 12345 Antwort auf Dialoginitialisierung K Sammelüberweisung für Konto 1111 r e Antwortnachricht d K u Dialogendenachricht i t Antwortnachricht n d e i Dialoginitialisierung für Benutzerkennung 54321 n Antwort auf Dialoginitialisierung s t i Kontostandabfrage für Konto 3333 Antwortnachricht t u Dialogendenachricht t Antwortnachricht Abbau der physikalischen Verbindung](figures/46.2) + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: C
Dokument:Formals
Kapitel: Abschnitt:Dialogspezifikation AllgemeinesStand: 06.10.2017Seite: 39
+ + +## C.1.3 Verschlüsselung des Dialoges beim Sicherheitsverfahren HBCI + +Grundsätzlich sind beim Sicherheitsverfahren HBCI alle Kunden- und alle Kreditin- +stitutsnachrichten eines Dialoges zu verschlüsseln. Von dieser Regel ausgenom- +men sind die folgenden Dialogarten: + +. Anonymer Zugang (vgl. Kap. C.5) + +· Erstmalige Anforderung der öffentlichen Schlüssel des Kreditinstituts (vgl. [HBCI], +Kap. B.6.2.2) + +· Schlüsselsperrung durch den Kunden (vgl. [HBCI], Kap. B.6.2.4)1 + +· Kommunikationszugang anfordern (vgl. Kap. 1.5) + +. Life-Indikator-Nachricht (vgl. Kap. C.9) + + +![](figures/47.1) + + +Unverschlüsselte Nachrichten, die keiner der oben genannten +Ausnahmen zuzuordnen sind, sind vom empfangenden Sys- +tem abzulehnen. + + +![](figures/47.2) + + +Alle Kundennachrichten eines Dialoges sind vom Übermittler der Nachricht zu ver- +schlüsseln. Alle Kreditinstitutsnachrichten sind mit dem Chiffrierschlüssel des Kredit- +instituts zu verschlüsseln. + +Kunde und Kreditinstitut haben stets dasselbe Verschlüsselungsverfahren anzuwen- +den. Der Kunde gibt im Verschlüsselungskopf ([HBCI], Kap. B.5.4) den von ihm ver- +wendeten Verschlüsselungsalgorithmus an und bestimmt damit ebenfalls den Algo- +rithmus, den das Kreditinstitut anzuwenden hat. Weder Kunde noch Kreditinstitut +dürfen das Verfahren während des Dialoges wechseln. Der Kunde darf nur ein Ver- +fahren wählen, das vom Kreditinstitut unterstützt wird. Die vom Kreditinstitut unter- +stützten Verfahren werden dem Kundensystem in den Bankparameterdaten im +Segment ,,Sicherheitsverfahren“ (Kap. D.4) bzw. ,,Komprimierungsverfahren“ (Kap. +D.5) mitgeteilt. + + +![](figures/47.3) + + +Falls das Kreditinstitut das vom Kunden gewählte Verschlüsse- +lungsverfahren nicht unterstützt, ist dem Kunden eine entsprechen- +de Rückmeldung zu geben und der Dialog zu beenden. Das Kun- +denprodukt wird diese Nachricht nicht entschlüsseln können, da es +das Verschlüsselungsverfahren des Kreditinstituts nicht unterstützt. +Das Kundenprodukt hat in diesem Fall dem Verschlüsselungskopf +der Kreditinstitutsnachricht zu entnehmen, dass es ein dem Kredit- +institut nicht bekanntes Verschlüsselungsverfahren verwendet. In +diesem Fall hat der Kunde über den (unverschlüsselten) anonymen +Zugang die aktuellen Bankparameterdaten anzufordern, in denen +die Verschlüsselungsverfahren des Kreditinstituts angegeben sind. + + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
40		Stand: 06.10.2017Kapitel: Dialogspezifikation
Abschnitt: Abfolge von Operationen
+ + +## C.2 Abfolge von Operationen + +Bei der Erstellung einer Nachricht sind die Arbeitsschritte in folgender Reihenfolge +auszuführen (Arbeitsschritte teils optional): + +1\. Zusammenstellung der Informationen im System des Senders + +2\. Aufbau der Nachricht. Aus den Informationen werden die zu übertragenden Se- +gmente bis auf ggf. erforderliche Signatur-Segmente aufgebaut, wobei beim Ein- +stellen der Informationen in die Nachricht Syntaxzeichen entwertet werden. + +3\. Bildung der elektronischen Signatur (optional) + +. Erstellung des Signaturkopfes + +. Berechnung der elektronischen Signatur über Signaturkopf und Auftrags- +segmente + +. Erstellung des Signaturabschlusses und Einstellung der Daten in das ent- +sprechende Feld + +4\. Wiederholung von Schritt 3 für weitere Signaturen (optional) + +5\. Komprimierung + +6\. Verschlüsselung (Ausnahme: nicht verschlüsselungspflichtige Nachrichten) + +Beim Empfänger einer Nachricht erfolgen die Verarbeitungsschritte entsprechend in +umgekehrter Reihenfolge: + +1\. Entschlüsselung (Ausnahme: unverschlüsselte Nachrichten) + +2\. Dekomprimierung + +3\. Syntaxprüfung + +4\. Prüfung der elektronischen Signatur (optional) + +. Berechnung der elektronischen Signatur über Signaturkopf und Auftrags- +segmente gemäß Parametern im Signaturkopf + +. Extrahieren des Signaturwertes aus dem Signaturabschluss + +· Vergleich des berechneten und des extrahierten Signaturwertes + +5\. Wiederholung von Schritt 4 für weitere Signaturen (optional) + +6\. Zerlegung der übrigen Datensegmente, dabei Entfernung von Entwertungs- +zeichen + +7\. Bereitstellung der Informationen zur Verarbeitung im System des Empfängers + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: C
Dokument:Formals3.0-FV
Kapitel:DialogspezifikationStand:Seite:
Abschnitt:Dialoginitialisierung06.10.201741
+ + +## C.3 Dialoginitialisierung + +Die Dialoginitialisierung dient folgenden Zwecken: + +1\. Prüfung, ob der Kommunikationspartner ein sendeberechtigter Benutzer ist + +2\. Festlegung der Dialog-ID + +3\. Prüfung auf Aktualität der im Kundensystem vorhandenen BPD und UPD sowie +ggf. deren Aktualisierung + +4\. Prüfung auf Aktualität der öffentlichen Schlüssel des Kreditinstituts sowie ggf. de- +ren Aktualisierung (nur bei asymmetrischen Verfahren) + +5\. Übermittlung vorbereitender Informationen für die kunden- und kreditinstituts- +seitige Verarbeitung + +6\. Übertragung von Kreditinstitutsmeldungen + +Bei Verwendung der starken Authentifizierung gelten zusätzlich die entsprechenden +Abläufe, wie sie in [PINTAN] beschrieben sind. Während Auftragsnachrichten von +dem bzw. den jeweiligen Signaturpflichtigen zu signieren sind, wird die Dialoginitiali- +sierung von demjenigen Benutzer signiert, der sich im Rahmen der Dialoginitialisie- +rung anmeldet. Im Regelfall ist dieser Benutzer auch Auftraggeber der nachfolgen- +den Aufträge, d. h. identisch mit dem Kunden. Während eines Dialoges dürfen nur +Aufträge für Auftraggeberkonten gesendet werden, die der bei der Dialoginitialisie- +rung angegebenen Kunden-ID zugeordnet sind. + +Darüber hinaus darf die Dialoginitialisierung auch von einem Benutzer signiert wer- +den, der für die nachfolgenden Auftraggeberkonten bevollmächtigt ist. Dies gilt auch +bei Aufträgen für Konten mit Mehrfachunterschrift. Die Auftragsnachrichten müssen +jedoch weiterhin von den Signaturpflichtigen signiert werden. Der Umfang der Be- +vollmächtigung ist Inhalt einer Vereinbarung zwischen Kunde und Kreditinstitut. + + +## C.3.1 Kundennachricht + + +### C.3.1.1 Nachrichtenformat + +Realisierung Bank: verpflichtend + +Realisierung Kunde: verpflichtend + + +## . Beschreibung + +Da der Kunde die Dialogsprache erst in dieser Nachricht mitteilt, muss zur Bildung +der Dialoginitialisierungsnachricht der mit der Standardsprache des Kreditinstituts +festgelegte Zeichensatz herangezogen werden. Dieser ist dem Feld ,Standardspra- +che" des Kommunikationszugangs zu entnehmen. Die Antwort des Kreditinstituts er- +folgt dann in der vom Kunden gewünschten Sprache (Zeichensatz). + +. Format + + + + + + + + + + + + + + + + + + + +
Name:Dialoginitialisierung
Typ:Nachricht
Version:4
Sender:Kunde
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite: 42Stand: 06.10.2017Kapitel: Dialogspezifikation
Abschnitt: Dialoginitialisierung
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypKen- nungSta- tusAn- zahlAnmerkungen
1Nachrichtenkopf3SEGHNHBKM1
2Signaturkopf4SEGHNSHKM1s. [HBCI], Kap. B.5.1
3Identifikation2SEGHKIDNM1
4Verarbeitungsvor- bereitung3SEGHKVVBM1
5Zwei-Schritt-TAN- Einreichung≥6SEGHKTANO1s. [PINTAN], Kap. B.3.3
6Anforderung eines öffentlichen Schlüs- sels3SEGHKISAC3M: bei RAH und RDH N: bei DDV und PIN/TAN
7Signaturabschluss2SEGHNSHAM1s. [HBCI], Kap. B.5.2
8Nachrichtenab- schluss1SEGHNHBSM1
+ + +## . Belegungsrichtlinien + + +### Zwei-Schritt-TAN-Einreichung + +Zur Einleitung des Prozesses der Gewährleistung einer starken Kun- +denauthentifizierung gemäß [PSD2] muss bei TAN-Verfahren ein HKTAN- +Segment ab Segmentversion #6 eingestellt werden, wenn ein Kreditinstitut +die Verwendung von HKTAN ≥ #6 unterstützt (BPD). Wenn HKTAN ≥ #6 +nicht gesendet wird, kann der Dialog vom Institut mit dem Rückmeldungs- +code 9075 - Dialog abgebrochen - Starke Authentifizierung +erforderlich abgewiesen werden. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: C
Dokument:Formals
Kapitel: Abschnitt:Dialogspezifikation DialoginitialisierungStand: 06.10.2017Seite: 43
+ + +### C.3.1.2 Segment: Identifikation + + +#### . Beschreibung + +Das Identifikations-Segment enthält Kontextinformationen, die für den gesamten Di- +alog Gültigkeit haben. Anhand dieser Daten wird die Sendeberechtigung des Benut- +zers geprüft. Eine Prüfung der transportmedienspezifischen Kennung des Benutzers +erfolgt nicht. + +Falls dem Benutzer die Berechtigung zum Senden weiterer Nachrichten nicht erteilt +werden kann, ist ein entsprechender Rückmeldungscode in die Kreditinstituts- +antwort einzustellen. Es steht Kreditinstituten frei, in bestimmten Fällen auf eine +Identifizierung des Kunden zu verzichten. Dies ist zum Beispiel für den anonymen +Zugang (s.u.) erforderlich, wo mit einem Nichtkunden kommuniziert wird. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
. Format
Name:Identifikation
Typ:Segment
Segmentart:Administration
Kennung:HKIDN
Bezugssegment:-
Version:2
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kreditinstitutsken- nung1DEGkik#M1
3Kunden-ID1DEid#M1
4Kundensystem-ID1DEid#M1
5Kundensystem- Status1DEcode1M10, 1
+ + +#### . Belegungsrichtlinien + + +##### Kreditinstitutskennung + +Es ist die Kennung des Kreditinstituts anzugeben, zu dem der Zugang ge- +wünscht wird. In nachfolgenden Auftragsnachrichten dürfen nur Auftragge- +berkonten dieses Institutbereichs angegeben werden. + + +##### Kunden-ID + +Es ist diejenige Kunden-ID des Benutzers einzustellen, die die Rolle festlegt, +in der er im Rahmen des Dialoges auftritt (s. Kap. C.1.1). Diese Kunden-ID +gilt ebenso für eventuelle Zweit- und Drittsignierende. + + +## Kundensystem-ID + +Die Kundensystem-ID ist beim RAH- / RDH- sowie beim PIN/TAN-Verfahren +erforderlich. Beim DDV-Verfahren ist dieses DE mit dem Wert 0 zu belegen. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite: 44Stand: 06.10.2017Kapitel: Dialogspezifikation
Abschnitt: Dialoginitialisierung
+ + +![](figures/52.1) + + +Bevor ein Benutzer bei Verwendung des RAH- / RDH- bzw. +PIN/TAN-Verfahrens von einem neuen Kundensystem Auf- +träge erteilen kann, hat er im Wege einer Synchronisierung +eine Kundensystem-ID für dieses System anzufordern (s. +Kap. C.8). + +Bei der Verwendung von RAH-/RDH-Chipkarten ab Sicher- +heitsprofil-Version 3 wird anstatt der Kundensystem-ID die +CID der gesteckten Karte verwendet. + + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Informationen fehlerfrei entgegengenommen
9210Unbekannter Kunde
9210Ungültige Kundensystem-ID
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: C
Dokument:Formals
Kapitel:
Abschnitt:		Dialogspezifikation
Dialoginitialisierung		Stand: 06.10.2017Seite: 45
+ + +### C.3.1.3 Segment: Verarbeitungsvorbereitung + + +#### . Beschreibung + +Dieses Segment dient der Übermittlung von Informationen über das Kundensystem, +mit Hilfe derer das Kreditinstitut individuell auf Anforderungen des Kunden reagieren +kann. + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Verarbeitungsvorbereitung
Typ:Segment
Segmentart:Administration
Kennung:HKVVB
Bezugssegment:-
Version:3
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2BPD-Version1DEnum..3M1
3UPD-Version1DEnum..3M1
4Dialogsprache2DEcode..3M10, 1, 2, 3
5Produktbezeich- nung1DEan.25M1
6Produktversion1DEan..5M1
+ + +## . Belegungsrichtlinien + + +### BPD-Version + +Es ist die aktuelle Version der im Kundenprodukt vorliegenden BPD einzu- +stellen. Falls noch keine BPD vorliegen, ist der Wert ,,0" einzustellen. Anhand +dieser Information prüft das Kreditinstitut, ob der Kunde über die aktuelle +BPD-Version verfügt. + + +## Dialogsprache + +Der Kunde darf lediglich ein Sprachkennzeichen einstellen, das im Rahmen +der BPD vom Kreditinstitut an das Kundensystem übermittelt wurde. + +Wenn noch keine BPD vorliegen, sollte das Kundenprodukt mit Hilfe eines +anonymen Dialogs die aktuelle BPD des Instituts ermitteln und die Standard- +sprache des Instituts einstellen, die in den Bankparameterdaten mitgeteilt +wird. Falls die BPD nicht abgerufen werden kann, ist der Wert ,0" ein- +zustellen. Das Kreditinstitut antwortet in diesem Fall in seiner Standardspra- +che. + + +## Produktbezeichnung, Produktversion + +Beide Datenelemente sind verpflichtend mit aussagekräftigen Informationen +über das verwendete Kundenprodukt, nicht eine ggf. verwendete interne +FinTS-/HBCI-Bibliothek, zu füllen, um Support-Anfragen leichter beantworten +zu können. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
46		Stand: 06.10.2017Kapitel: Dialogspezifikation
Abschnitt: Dialoginitialisierung
+ + +Kundenprodukte, die nach dem durch die Deutsche Kreditwirtschaft festge- +legten Verfahren registriert sind, müssen in dieses DE die vergebene Pro- +duktregistrierungsnummer einstellen. + + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Informationen fehlerfrei entgegengenommen
3050BPD nicht mehr aktuell. Aktuelle Version folgt
3050UPD nicht mehr aktuell. Aktuelle Version folgt
3075Starke Authentifizierung ab dem ... erforderlich
3340RDH-2-Kundenschlüssel neu generieren und einreichen. Wird noch ... Tage akzeptiert
3345Sicherheitsprofilwechsel auf RDH-2 durchführen. RDH-2-Kundenschlüssel neu generieren und einreichen. RDH-1 wird noch ... Tage akzeptiert.
9075Dialog abgebrochen - starke Authentifizierung erforderlich
9185HBCI-/FinTS-Version wird nicht unterstützt
9210Sprache wird nicht unterstützt
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: C
Dokument:Formals3.0-FV
Kapitel:DialogspezifikationStand:Seite:
Abschnitt:Dialoginitialisierung06.10.201747
+ + +### C.3.1.4 Segment: Anforderung eines öffentlichen Schlüssels + + +#### . Beschreibung + +Bei asymmetrischen HBCI Signatur- bzw. Verschlüsselungsverfahren muss dieses +Segment eingestellt werden, da hiermit bei jeder Dialoginitialisierung der eventuell +zwischenzeitlich geänderte öffentliche Chiffrierschlüssel des Kreditinstituts angefor- +dert wird. Falls eine kreditinstitutsseitige Signierung der Nachrichten vorgesehen ist, +muss dieses Segment zusätzlich auch zur Anforderung des öffentlichen Signier- +schlüssels eingestellt werden. + +Bei symmetrischen HBCI-Verfahren und TAN-Verfahren unter Verwendung von +HKTAN > Segmentversion #4 darf dieses Segment nicht eingestellt werden. + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Anforderung eines öffentlichen Schlüssels
Typ:Segment
Segmentart:Administration
Kennung:HKISA
Bezugssegment:-
Version:s. [HBCI], Kap. B.6.1.2
Sender:Kunde
Format:s. [HBCI], Kap. B.6.1.2
+ + +◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel
0020Angegebener Schlüssel ist noch aktuell
0020Angegebener Schlüssel ist nicht mehr aktuell. Der neue Schlüssel wird mitgeteilt
9010Sicherheitsverfahren unterstützt keine öffentlichen Schlüssel
9030Schlüsselversion nicht mehr aktuell
9210Angegebener Schlüssel ist im Kreditinstitut unbekannt
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite: 48Stand: 06.10.2017Kapitel: Dialogspezifikation
Abschnitt: Dialoginitialisierung
+ + +##### C.3.2 Kreditinstitutsnachricht + + +###### C.3.2.1 Nachrichtenformat + +Realisierung Bank: verpflichtend + +Realisierung Kunde: verpflichtend + + +####### . Beschreibung + +Sofern die Dialoginitialisierungsnachricht des Kunden fehlerhaft ist, darf die Kredit- +institutsnachricht nur dazu genutzt werden, dem Kunden die betreffenden Rückmel- +decodes mitzuteilen. Es dürfen in diesem Fall keine Datensegmente (z. B. BPD, +UPD) rückgemeldet werden. + + +#### . Format + + + + + + + + + + + + + + + + + + + +
Name:Antwort auf Dialoginitialisierung
Typ:Nachricht
Version:4
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypKen- nungSta- tusAn- zahlAnmerkungen
1Nachrichtenkopf3SEGHNHBKM1
2Signaturkopf4SEGHNSHKO1s. [HBCI], Kap. B.5.1
3Rückmeldungen zur Gesamtnachricht2SEGHIRMGM1
4Rückmeldungen zu Segmenten2SEGHIRMSOn
5Bankparameterda- ten3SF#O1
6Userparameterda- ten3SF#O1
7Übermittlung eines öffentlichen Schlüs- sels3SEGHIISAC3O: bei RAH und RDH N: bei DDV und PIN/TAN2
8Kreditinstitutsmel- dung2SEGHIKIMOn
9Zwei-Schritt-TAN- Einreichung≥6SEGHITANO1s. [PINTAN], Kap. B.3.3
10Signaturabschluss2SEGHNSHAO1s. [HBCI], Kap. B.5.2
11Nachrichtenab- schluss1SEGHNHBSM1
+ + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + +
CodeBeispiel
0020Dialoginitialisierung erfolgreich
9800Dialogabbruch
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: C
Dokument:Formals3.0-FV
Kapitel:DialogspezifikationStand:Seite:
Abschnitt:Dialoginitialisierung06.10.201749
+ + +### C.3.2.2 Segmentfolge: Bankparameterdaten + + +#### . Beschreibung + +Entspricht die vom Kunden übermittelte BPD-Version nicht der aktuellen im Kredit- +institut gespeicherten Version, so erhält der Kunde automatisch die aktuellen Bank- +parameterdaten. Dies gilt auch, wenn ihm zu einem früheren Zeitpunkt bereits die- +selben BPD gesendet wurden. Die BPD werden sofort aktiv, d. h. sie sollten dann +vom Kundenprodukt unmittelbar verwendet werden. + +Die Bankparameterdaten müssen stets komplett übertragen werden, d. h. das Aus- +lassen einzelner Segmente ist nicht zulässig. Zu einem späteren Zeitpunkt ist denk- +bar, dass nur die geänderten BPD-Segmente übertragen werden. + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + +
Name:Bankparameterdaten
Typ:Segmentfolge
Sender:Kreditinstitut
Format:s. Kap. D
Version:3
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
50		Stand: 06.10.2017Kapitel: Dialogspezifikation
Abschnitt: Dialoginitialisierung
+ + +##### C.3.2.3 Segmentfolge: Userparameterdaten + + +###### . Beschreibung + +Entspricht die vom Kunden übermittelte UPD-Version nicht der aktuellen im Kredit- +institut gespeicherten Version, so erhält der Kunde automatisch die aktuellen User- +parameterdaten. Dies gilt auch, wenn ihm zu einem früheren Zeitpunkt bereits die- +selben UPD gesendet wurden. Die UPD werden sofort aktiv, d. h. sie sollten dann +vom Kundenprodukt unmittelbar verwendet werden. + +Die Userparameterdaten müssen stets komplett übertragen werden, d. h. das Aus- +lassen einzelner Segmente ist nicht zulässig. Zu einem späteren Zeitpunkt ist denk- +bar, dass nur die geänderten UPD-Segmente übertragen werden. + + +![](figures/58.1) + + +Es ist zu beachten, dass lediglich die Userparameterdaten des sich +anmeldenden Benutzers aktualisiert werden. Falls mehrere Benut- +zer an der Erstellung der Aufträge beteiligt sind (z. B. bei Mehrfach- +signaturen), so ist sicherzustellen, dass auch für die passiven Be- +nutzer, die die Aufträge nicht versenden, sondern lediglich signie- +ren, stets die aktuellen UPD vorliegen. + +Hierzu haben sich die passiven Benutzer in regelmäßigen Abstän- +den beim Kreditinstitut mit einer Dialoginitialisierung anzumelden, +damit ggf. ihre Userparameterdaten aktualisiert werden können. +Dieses Verfahren kann vom Kundenprodukt durch eine automati- +sche Aufforderung unterstützt werden. + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + +
Name:Userparameterdaten
Typ:Segmentfolge
Sender:Kreditinstitut
Format:s. Kap. E
Version:3
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: C
Dokument:Formals
Kapitel:
Abschnitt:		Dialogspezifikation DialoginitialisierungStand: 06.10.2017Seite: 51
+ + +### C.3.2.4 Segment: Übermittlung eines öffentlichen Schlüssels + + +#### . Beschreibung + +Falls bei asymmetrischen HBCI Signatur- bzw. Verschlüsselungsverfahren einer der +öffentlichen Schlüssel des Kreditinstituts aktualisiert wurde, wird dem Kunden dieser +in diesem Segment zurückgemeldet. Das Segment kann sowohl für den Signier- +schlüssel als auch für den Chiffrierschlüssel eingestellt werden. Hat sich der jewei- +lige Schlüssel nicht geändert, so wird das Segment nicht gesendet. + +Zur Verifizierung der Richtigkeit des öffentlichen Schlüssels muss entweder die Dia- +loginitialisierungs-Antwortnachricht signiert sein oder es muss auf alternativem Weg +(z. B. Brief) ein neuer Hashwert übermittelt werden. + +Bei symmetrischen HBCI-Verfahren und TAN-Verfahren unter Verwendung von +HKTAN > Segmentversion #4 darf dieses Segment nicht eingestellt werden. + +Zwangsweiser Wechsel der Schlüssel des Kunden + +Mit dem Rückmeldungscode 3340 kann das Kreditinstitut dem Kundensystem signa- +lisieren, dass es die RDH-2-Kundenschlüssel neu generieren soll. Dies kann z. B. +bei einer Aufhebung der Einschränkungen bezüglich der maximalen Schlüssellän- +gen des Bankenprofils (s. [HBCI], Kap. B.1.1) erforderlich sein. Die neu generierten +öffentlichen RDH-2-Schlüssel des Kunden müssen anschließend mit dem Ge- +schäftsvorfall "Änderung eines öffentlichen Schlüssels des Kunden einreichen" (s. +[HBCI], Kap. B.6.2.1) an das Kreditinstitut übermittelt werden. + +Wechsel des Sicherheitsprofils von RDH-1 auf RDH-2 + +Mit dem Rückmeldungscode 3345 kann das Kreditinstitut dem Kundensystem signa- +lisieren, dass es einen Sicherheitsprofilwechsel von RDH-1 auf RDH-2 durchführen +soll. Dazu muss das Kundensystem ein neues RDH-2- Sicherheitsmedium erzeugen +und die RDH-2-Kundenschlüssel neu generieren. Die neu generierten öffentlichen +RDH-2-Schlüssel des Kunden müssen anschließend mit dem Geschäftsvorfall "Än- +derung eines öffentlichen Schlüssels des Kunden einreichen" (s. [HBCI], Kap. +B.6.2.1) an das Kreditinstitut übermittelt werden. + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Übermittlung eines öffentlichen Schlüssels
Typ:Segment
Segmentart:Administration
Kennung:HIISA
Bezugssegment:HKISA
Version:s. [HBCI], Kap. B.6.1.3
Sender:Kreditinstitut
Format:s. [HBCI], Kap. B.6.1.3
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
52		Stand: 06.10.2017Kapitel: Dialogspezifikation
Abschnitt: Dialoginitialisierung
+ + +##### C.3.2.5 Segment: Kreditinstitutsmeldung + + +###### . Beschreibung + +Kreditinstitutsmeldungen können z. B. Werbenachrichten oder auch kundenrele- +vante Informationen zu Geschäftsvorfällen, die nicht in Rückmeldungscodes abge- +bildet werden können, beinhalten. Diese werden dem Kunden automatisch im Rah- +men der Dialoginitialisierungsantwortnachricht übermittelt. Dadurch wird gewähr- +leistet, dass die Zustellung dieser Meldungen nicht auf Initiative des Kunden erfol- +gen muss. + +Es ist lediglich die Übermittlung von unformatierten Textnachrichten möglich. + + +![](figures/60.1) + + +Kreditinstitutsmeldungen können dem Kunden unmittelbar nach Er- +halt, d. h. z. B. während im Hintergrund der Dialog abläuft, ange- +zeigt werden. + +Hersteller von Kundenprodukten sollten darüber hinaus eine Mög- +lichkeit zur Verwaltung von Kreditinstitutsmeldungen vorsehen. Falls +mehrere Meldungen gleichzeitig vorliegen, sollte der Kunde die +Möglichkeit haben, die Meldungen nacheinander zu bearbeiten +(Funktionen „Nächste lesen“, „Vorherige lesen“). Ferner sollten Kre- +ditinstitutsmeldungen gespeichert, gelöscht und ausgedruckt wer- +den können. + + +###### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kreditinstitutsmeldung
Typ:Segment
Segmentart:Administration
Kennung:HIKIM
Bezugssegment:-
Version:2
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Betreff1DEan..35M1
3Freitextmeldung1DEtxt..
2048		M1
+ + +###### . Belegungsrichtlinien + + +###### Freitextmeldung + +Die Daten dürfen nicht um führende oder nachfolgende Leerzeichen gekürzt +werden. + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: C
Dokument:Formals3.0-FV
Kapitel:DialogspezifikationStand:Seite:
Abschnitt:Dialogbeendigung06.10.201753
+ + +## C.4 Dialogbeendigung + +Jeder Dialog ist durch eine Dialogendenachricht zu beenden (Ausnahmen s. Kap. +C.4.1). Das Senden der Dialogbeendigung hat zwei Funktionen: Zum einen teilt der +Kunde mit, dass keine weiteren Nachrichten folgen und die Verbindung zum Kredit- +institut beendet werden soll. Zum anderen bestätigt der Kunde hiermit implizit den +Erhalt aller vorangegangenen Kreditinstitutsnachrichten des Dialoges. + +Nach Erhalt der Kreditinstitutsantwortnachricht ist der Dialog logisch beendet. An- +schließend muss das Kundenprodukt entweder die Kommunikation physisch been- +den oder einen neuen Dialog für diesen Benutzer beginnen. Falls der Kunde keine +Dialogbeendigung sendet, wird der Dialog kreditinstitutsseitig nach einem trans- +portmedienabhängigen Timeout beendet. + +Der Dialog kann auch bereits direkt nach der Dialoginitialisierung beendet werden, +sofern der Kunde bspw. lediglich seine BPD und UPD aktualisieren möchte. + +Realisierung Bank: verpflichtend + +Realisierung Kunde: verpflichtend + + +## C.4.1 Ausnahmen zur Dialogbeendigung + +Im Fall eines impliziten Dialogendes bei Verwendung von starker Authentifizierung +(s. [PINTAN], Kap. B.3.3) wird ein Dialog nicht durch eine explizite Dialogendenach- +richt des Benutzers / Kreditinstituts beendet. + + +## C.4.2 Kundennachricht + + +### C.4.2.1 Nachrichtenformat + + +#### . Beschreibung + +Die Nachricht muss signiert und verschlüsselt werden (Ausnahmen s. Kap. C.4.1) +und wird mit einer Standard-Kreditinstitutsnachricht beantwortet. Die Nachricht ist +von demjenigen Benutzer zu signieren, der auch die Dialoginitialisierung signiert +hat. + + +##### . Format + + + + + + + + + + + + + + + + + + + +
Name:Dialogbeendigung
Typ:Nachricht
Version:3
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypKen- nungSta- tusAn- zahlAnmerkungen
1Nachrichtenkopf3SEGHNHBKM1
2Signaturkopf4SEGHNSHKM1s. [HBCI], Kap. B.5.1
3Dialogende1SEGHKENDM1
4Signaturabschluss2SEGHNSHAM1s. [HBCI], Kap. B.5.2
5Nachrichtenab- schluss1SEGHNHBSM1
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
54		Stand: 06.10.2017Kapitel: Dialogspezifikation
Abschnitt: Dialogbeendigung
+ + +### C.4.2.2 Segment: Dialogende + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
. Format
Name:Dialogende
Typ:Segment
Segmentart:Administration
Kennung:HKEND
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Dialog-ID1DEid#M1
+ + +#### . Belegungsrichtlinien + + +#### Dialog-ID + +Es ist die Dialog-ID des zu beendigenden Dialoges einzustellen. + + +## C.4.3 Kreditinstitutsnachricht + + +### . Beschreibung + +Das Kreditinstitut bestätigt die Dialogbeendigung mit dem Rückmeldungscode 0100 +(,,Dialog beendet“). + + +### . Format + + + + + + + + + + + + + + + +
Name:Kreditinstitutsnachricht allgemein
Typ:Nachricht
Format:s. Kap. B.7.1
+ + +### ◆ Erläuterungen + +Es werden keine Datensegmente zurückgemeldet. + + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0100Dialog beendet
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: C
Dokument:Formals
Kapitel: Abschnitt:Dialogspezifikation Anonymer ZugangStand: 06.10.2017Seite: 55
+ + +## C.5 Anonymer Zugang + +Um Kunden die Möglichkeit zu geben, sich anonym anzumelden, um sich bspw. +über die angebotenen Geschäftsvorfälle fremder Kreditinstitute (von denen sie keine +BPD besitzen) zu informieren bzw. nicht-signierungspflichtige Aufträge bei fremden +Kreditinstituten einreichen zu können, kann sich der Kunde anonym (als Gast) an- +melden. + +Die Zugangsdaten zu den Fremdinstituten erhält der Kunde über den Abruf der +Kommunikationszugänge (s. Anlagen). + +Bei anonymen Dialogen werden Nachrichten weder signiert, noch können sie ver- +schlüsselt und komprimiert werden. + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +## C.5.1 Dialoginitialisierung + + +### a) Kundennachricht + +. Format + + + + + + + + + + + + + + + + + + + +
Name:Dialoginitialisierung bei anonymem Zugang
Typ:Nachricht
Version:3
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypKen- nungSta- tusAn- zahlAnmerkungen
1Nachrichtenkopf3SEGHNHBKM1
2Identifikation2SEGHKIDNM1
3Verarbeitungsvor- bereitung3SEGHKVVBM1
4Nachrichtenab- schluss1SEGHNHBSM1
+ + +### . Belegungsrichtlinien + + +#### Identifikation + +Die Datenelemente des Identifikationssegments sind wie folgt zu belegen: + +· Kreditinstitutskennung: Ländercode und BLZ des gewünschten Instituts + +. Kunden-ID: +99999999993 + +. Kundensystem-ID: +0 + +. Kundensystem-Status: +0 + + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
56		Stand: 06.10.2017Kapitel: Dialogspezifikation
Abschnitt: Anonymer Zugang
+ + +## Verarbeitungsvorbereitung + +Mit diesem Segment fordert der Kunde die Bankparameterdaten des Kredit- +instituts an. + +Sofern schon von einem früheren anonymen Zugang Bank- oder Userpara- +meterdaten dieses Kreditinstituts vorliegen, ist die jeweilige Versionsnummer +anzugeben. + + +## b) Kreditinstitutsnachricht + +. Format + + + + + + + + + + + + + + + + + + + +
Name:Antwort auf anonyme Dialoginitialisierung
Typ:Nachricht
Version:3
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypKen- nungSta- tusAn- zahlAnmerkungen
1Nachrichtenkopf3SEGHNHBKM1
2Rückmeldungen zur Gesamtnachricht2SEGHIRMGM1
3Rückmeldungen zu Segmenten2SEGHIRMSOn
4Bankparameterda- ten3SF#O1
5Userparameterda- ten3SF#O1
6Kreditinstitutsmel- dung2SEGHIKIMOn
7Nachrichtenab- schluss1SEGHNHBSM1
+ + +## . Belegungsrichtlinien + + +## Bankparameterdaten + +Die BPD bei einem anonymen Zugang sind identisch mit denen bei einem +Zugang als Kunde. + + +## Userparameterdaten + +In den Gast-UPD sind im DE „Erlaubte Geschäftsvorfälle“ diejenigen Ge- +schäftsvorfälle aufgeführt, die der Gast ausführen darf. Dies können jedoch +nur Geschäftsvorfälle sein, für die keine Signatur erforderlich ist, wie z. B. +der Abruf von Börsenkursen oder die Sendung einer Gastmeldung (Die Fest- +legung, für welche Geschäftsvorfälle eine Signatur erforderlich ist, ist insti- +tutsspezifisch). + +Als Benutzerkennung wird in den Gast-UPD eine Standardkennung einge- +tragen, indem das Feld mit der Ziffer '9' aufgefüllt wird. Diese Kennung darf +daher nicht an tatsächliche Benutzer vergeben werden. In der Kontoverbin- +dung sind Kreditinstitutskennung und Länderkennzeichen mit den Werten +des Kreditinstituts zu belegen. Als Kontonummer wird ebenfalls eine Stan- +dardkennung eingegeben, die in derselben Weise wie die Benutzerkennung +zu bilden ist. Kunden-ID ist der Wert ,,9999999999", wie in der Kundennach- +richt. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: C
Dokument:Formals
Kapitel:
Abschnitt:		Dialogspezifikation Anonymer ZugangStand: 06.10.2017Seite: 57
+ + +## Kreditinstitutsmeldung + +Bei den Meldungen kann es sich lediglich um allgemeine, d. h. nicht benut- +zerspezifische Informationen handeln. + + +## C.5.2 Auftragsnachricht + + +### a) Kundennachricht + + +#### . Format + + + + + + + + + + + + + + + + + + + +
Name:Kundennachricht allgemein bei anonymem Zugang
Typ:Nachricht
Version:4
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypKen- nungSta- tusAn- zahlAnmerkungen
1Nachrichtenkopf3SEGHNHBKM1
2Aufträge2SF#O1
3Nachrichtenab- schluss1SEGHNHBSM1
+ + +### . Belegungsrichtlinien + + +#### Aufträge + +Es dürfen lediglich nicht-signierungspflichtige Geschäftsvorfälle (z. B. Abruf +von Börsenkursen, Gastmeldung) eingestellt werden. Welche Geschäftsvor- +fälle signierungspflichtig sind, bestimmt das Kreditinstitut in der UPD des +Kunden. + +Die Auftraggeberkontonummer ist jeweils mit dem Wert „9999999999" zu be- +legen. + + +## b) Kreditinstitutsnachricht + +Format + + + + + + + + + + + + + + + +
Name:Kreditinstitutsnachricht allgemein
Typ:Nachricht
Format:s. Kap. B.7.1
+ + +## C.5.3 Dialogbeendigung + + +## a) Kundennachricht + +. Format + + + + + + + + + + + + + + + + + + + +
Name:Dialogbeendigung bei anonymem Zugang
Typ:Nachricht
Version:3
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypKen- nungSta- tusAn- zahlAnmerkungen
1Nachrichtenkopf3SEGHNHBKM1
2Dialogende1SEGHKENDM1
3Nachrichtenab-1SEGHNHBSM1
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
58		Stand: 06.10.2017Kapitel: Dialogspezifikation
Abschnitt: Anonymer Zugang
+ + + + + + + + + + + + + +
schluss
+ + +## b) Kreditinstitutsnachricht + + +### . Format + + + + + + + + + + + + + + + +
Name:Kreditinstitutsnachricht allgemein
Typ:Nachricht
Format:s. Kap. B.7.1
+ + +### ◆ Erläuterungen + +Es werden keine Datensegmente zurückgemeldet. + + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0100Dialog beendet
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: C
Dokument:Formals
Kapitel:
Abschnitt:		Dialogspezifikation VerbindungsabbruchStand: 06.10.2017Seite: 59
+ + +## C.6 Verbindungsabbruch + +Im Unterschied zu einigen derzeit aktuellen Transportmedien erfolgt in keinem Fall +kreditinstitutsseitig ein Abbruch der Übertragung von Kundennachrichten; auch dann +nicht, wenn kreditinstitutsseitig bereits ein Fehler in der Nachricht während der +Übertragung festgestellt wird. Der Abbruch wird aus Gründen der Einheitlichkeit +nicht durchgeführt, weil entsprechende Funktionalitäten nicht bei allen Kommunikati- +onsdiensten zur Verfügung stehen. + +Bzgl. Verbindungsstörungen bzw. Abbrüchen sind aus Sicht des Kreditinstituts fol- +gende Fälle zu unterscheiden: + + +## Fall 1: Abbruch während der Kunde eine Dialoginitialisierung an das Kredit- institut sendet + +Der Kunde konnte in diesem Fall nicht identifiziert werden. Die Legitimation +konnte dem gemäß nicht erteilt werden. + +Fall 2: Abbruch nachdem der Kunde eine Dialoginitialisierung an das Kredit- +institut gesendet hat + +Die Nachricht wurde erhalten. Anschließend wurde der Kunde identifiziert +und die Legitimation erteilt. Das Kreditinstitut erwartet eine Auftragsnach- +richt. Diese kann jedoch nicht eintreffen, da der Kunde die Antwortnachricht +nicht erhalten hat. + +Fall 3: Abbruch während der Kunde eine Auftragsnachricht an das Kredit- +institut sendet + +In diesem Fall ignoriert das Kreditinstitut das erhaltene Nachrichtenfragment. + +Fall 4: Abbruch nachdem der Kunde eine Auftragsnachricht an das Kredit- +institut gesendet hat + +Der Abbruch erfolgt hierbei bevor oder während das Kreditinstitut die Ant- +wortnachricht an den Kunden sendet. In diesem Fall wird die erhaltene +Nachricht vom Kreditinstitut bearbeitet. + +Bei einem Abbruch konnte der Dialog nicht ordnungsgemäß beendet werden. So +fehlt z. B. die ordnungsgemäße Dialogbeendigung oder es fehlen bei einem Ab- +bruch während der Dialoginitialisierung die Auftragsnachrichten. Das Kreditinstitut +hat dennoch den Dialog als abgeschlossen zu betrachten, da der Kunde einen neu- +en Dialog beginnen muss, um sich über den Status der abgebrochenen Nachricht +zu informieren. + + +![](figures/67.1) + + +Verhalten auf Kundenseite: + +Erfolgt der Abbruch während oder nach der Dialoginitialisierung (Fall +1 und 2), ist der Dialog auf jeden Fall mit einer erneuten Dialoginitia- +lisierung zu beginnen. + + + + + + + + + + + + + + + +
Kapitel:
C		Version: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite: 60Stand: 06.10.2017Kapitel: Dialogspezifikation
Abschnitt: Verbindungsabbruch
+ + +Abbildung 9: Verbindungsabbruch Fall 1 + +![Nach- richten- nr. Sig- natur- ID Dialog- referenzen K Sig- natur- ID 1 5 Initialisierung 1 ohne Auftragsteil Be-Ref1 r 4 e B d e i t n u Be-Ref2 2 6 Initialisierung 2 i 4 → 6 t Antwortnachricht 1 n z Be-Ref2 / Kr-Ref1 s e t 2 7 r Benutzernachricht 3 Be-Ref2 / Kr-Ref1 i 6 → 7 t Antwortnachricht 2 u t Be-Ref2 / Kr-Ref1](figures/68.1) + + +Abbildung 10: Verbindungsabbruch Fall 2 + +![Nach- richten- nr. Sig- natur- ID Dialog- referenzen K Sig- natur- ID 1 5 Initialisierung 1 ohne Auftragsteil Be-Ref1 r 4 → 5 Antwortnachricht 1 e B d e Be-Ref1 / Kr-Ref1 i t n 2 6 u Initialisierung 2 Be-Ref2 i t 5 → 6 Antwortnachricht 2 n z Be-Ref2 / Kr-Ref2 s e t 2 7 r Benutzernachricht 3 Be-Ref2 / Kr-Ref2 i 6 → 7 Antwortnachricht 3 t Be-Ref2 / Kr-Ref2 u t](figures/68.2) + + +Im Falle eines Abbruch während oder nach dem Senden einer Auf- +tragsnachricht (Fall 3 und 4) ist für das Kundenprodukt im Regelfall +nicht nachvollziehbar, zu welchem dieser beiden Zeitpunkte der Ab- +bruch erfolgt ist. Diese Kenntnis ist jedoch erforderlich, um zu ent- +scheiden, ob die Auftragsnachricht erneut gesendet werden muss. + +Das Kundenprodukt sendet hierzu eine Synchronisierungsnachricht. + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: C
Dokument:Formals3.0-FV
Kapitel:
Abschnitt:		Dialogspezifikation VerbindungsabbruchStand: 06.10.2017Seite: 61
+ + +In der Antwortnachricht erhält es die letzte Nachrichtennummer der +Kundennachricht, die im abgebrochenen Dialog noch verarbeitet +wurde. Anhand dieser Information ist für das Kundenprodukt ersicht- +lich, welche Auftragsnachrichten noch gesendet werden müssen. + + +Abbildung 11: Verbindungsabbruch Fall 3 + +![Nach- richten- nr. Sig- natur- ID Dialog- referenzen Sig- natur- ID Benutzernachricht mit Initialisierung Be-Ref1 1 5 K Antwortnachricht 1 4 → 5 r Be-Ref1 / Kr-Ref1 e B 2 6 Benutzernachricht mit Auftragsteil 1 Be-Ref1 / Kr-Ref1 d e i n Be-Ref2 t 1 7 u Synchronisierung i 5 → 7 t Antwortnachricht 2 (# = 1) Be-Ref2 / Kr-Ref2 n z s e Benutzernachricht mit Initialisierung Be-Ref3 t 1 8 r Antwortnachricht 3 i 7 → 8 Be-Ref3 / Kr-Ref3 t Be-Ref3 / Kr-Ref3 u 2 9 Benutzernachricht mit Auftragsteil 1 t 8 → 9 Antwortnachricht 4 Be-Ref3 / Kr-Ref3](figures/69.1) + + +![Nach- richten- nr. Sig- natur- ID Dialog- referenzen Sig- natur- ID K Benutzernachricht mit Initialisierung Be-Ref1 r 1 5 Antwortnachricht 1 4 → 5 e B Be-Ref1 / Kr-Ref1 d e i n Benutzernachricht mit Auftragsteil 1 Be-Ref1 / Kr-Ref1 t 2 6 u Antwortnachricht 2 i 5 → 6 t Be-Ref1 / Kr-Ref1 n z s e t 1 7 r Synchronisierung Be-Ref2 i t 6 → 7 Antwortnachricht 3 (# = 2) Be-Ref2 / Kr-Ref2 u t Abbildung 12: Verbindungsabbruch Fall 4](figures/69.2) + + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
62		Stand: 06.10.2017Kapitel: Dialogspezifikation
Abschnitt: Verbindungsabbruch
+ + +Eine erneut zu sendende Nachricht darf nicht unverändert (bit- +identisch) gesendet werden, da sie aufgrund der nicht mehr aktuel- +len Signatur-ID (s. [HBCI] Kap. B.4) als Doppeleinreichung abgelehnt +würde. Daher muss diese Nachricht im Signaturkopf und -abschluss +eine neue Signatur-ID und folglich auch eine neue elektronische +Signatur erhalten. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: C
Dokument:Formals
Kapitel: Abschnitt:Dialogspezifikation StatusprotokollStand: 06.10.2017Seite: 63
+ + +# C.7 Statusprotokoll + +Um dem Kunden bzw. dem Kundensystem die Möglichkeit zu geben, den Verarbei- +tungsstatus von Nachrichten abzufragen, kann kreditinstitutsseitig ein Statusproto- +koll geführt werden, in dem die Status aller Aufträge aufgeführt sind. Die kreditinsti- +tutsseitige Unterstützung des Statusprotokolls ist optional. Es ist also zulässig, dass +ein Kreditinstitut den Geschäftsvorfall „Statusprotokoll anfordern" in der BPD nicht +anbietet. Ein FinTS-Kundenprodukt muss das Statusprotokoll zwingend unterstüt- +zen. + +Dies ist beispielsweise sinnvoll, um Kunden die Ausführung ihrer Aufträge mitzutei- +len, da online im Regelfall lediglich der Empfang der Aufträge bestätigt werden kann +und die weitere Verarbeitung offline erfolgt. Ferner dient das Statusprotokoll dazu, +nach einem Verbindungsabbruch den Status der übermittelten Aufträge zu erfahren, +insbesondere wenn durch das Kundensystem eine Nachricht vollständig an das +Kreditinstitut übermittelt wurde, beim Senden der Antwort seitens des Kreditinstituts +jedoch ein Fehler auftrat. + +Grundsätzlich erzeugen sämtliche als Geschäftsvorfall gekennzeichneten Segmente +von Kundennachrichten (s. Kap. I.1.3) einen Eintrag in das Statusprotokoll. Beim +anonymen Zugang (s. o.) wird kein Statusprotokoll erzeugt. + +Meldungen im Statusprotokoll sind identisch mit den Rückmeldungen zu Aufträgen +in Kreditinstitutsnachrichten (s. Segment HIRMS). Daher kann ein Auftrag im Sta- +tusprotokoll durch 1 bis n Segmente beschrieben sein. Das Statusprotokoll enthält +jeweils die letzte für den Kunden bestimmte(n) Rückmeldung(en) in Bezug auf einen +Auftrag bzw. eine Rückmeldung, die den Abschluss der Bearbeitung beschreibt. +Somit ist zu jedem Zeitpunkt der Verarbeitungsstatus eines Auftrages durch genau +einen Status definiert. Ferner enthält das Statusprotokoll sämtliche Meldungen, die +in das Segment „Rückmeldungen zur Gesamtnachricht" (HIRMG) eingestellt wer- +den. + +Die Festlegung, welcher Teil der Rückmeldungen im Rahmen der Online-Prüfung (z. +B. ,Auftrag entgegengenommen") und welcher Teil durch die Offline-Prüfung (z. B. +„Auftrag ausgeführt“) generiert wird, ist kreditinstitutsspezifisch. + +Da Meldungen, die erst bei der Weiterverarbeitung generiert werden, identisch mit +den Online-Meldungen sind, kann das Kundenprodukt auch bei asynchroner Ver- +arbeitung wie beim Onlinebetrieb auf Meldungen des Kreditinstituts reagieren. + +Statusmeldungen werden stets dem Absender des Auftrags zugeordnet, d. h. Stati +sind benutzerbezogen und nicht kontenbezogen. + +Die Frage, wie detailliert der Kunde über das Fortschreiten der kreditinstitutsinternen +Verarbeitung informiert werden soll, wird institutsindividuell gehandhabt. + +Stati müssen im Protokoll als Abgleichhilfe mindestens bis zum Ablauf von 2 Bu- +chungstagen nach dem nächsten Dialog, jedoch höchstens 6 Monate, vorgehalten +werden. Auf diese Weise ist sichergestellt, dass dem Kunden keine Statusmel- +dungen verloren gehen (z. B. bei längerem Urlaub etc.). Gleichzeitig wird das kredit- +institutsseitig vorzuhaltende Datenvolumen minimiert, indem die Stati bereits 2 Tage +nach dem nächsten Dialog gelöscht werden können. + + +![](figures/71.1) + + +Das Kundenprodukt sollte über ein Journal verfügen, in das sämtli- +che Statusmeldungen chronologisch eingetragen werden, um auch +zu einem späteren Zeitpunkt die Rückverfolgung von Aufträgen zu +gewährleisten. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
64		Stand: 06.10.2017Kapitel: Dialogspezifikation
Abschnitt: Statusprotokoll
+ + + + + + + + + + + +
Realisierung Bank:verpflichtend
Realisierung Kunde:optional
+ + +## a) Kundenauftrag + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Statusprotokoll anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKPRO
Bezugssegment:-
Version:4
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Von Datum1DEdat#O1
3Bis Datum1DEdat#O1
4Maximale Anzahl Einträge1DEnum..4O1>0
5Aufsetzpunkt1DEan..35C1M: vom Kreditinstitut wurde ein Aufsetzpunkt rückge- meldet (s. Kap. B.6.3). N: sonst
+ + +## . Belegungsrichtlinien + + +### Von Datum, Bis Datum + +Werden beide Felder nicht belegt, werden automatisch alle aktuellen Stati (d. +h. die neuen Stati und zusätzlich die Stati, die aufgrund der 2-Tage-Regel +noch nicht gelöscht wurden) zurückgemeldet. + + +![](figures/72.1) + + +Das Kundenprodukt muss damit rechnen, dass aufgrund der +2-Tage-Regel derselbe Status u.U. mehrfach vom Kreditinsti- +tut gesendet wird. + + +# b) Kreditinstitutsrückmeldung + + +## . Beschreibung + +Für jeden Auftrag, für den ein Statusprotokoll verfügbar ist, ist ein Segment bzw. +mehrere Segmente mit nachfolgendem Format in die Antwortnachricht einzustellen. + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Statusprotokoll rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIPRO
Bezugssegment:HKPRO
Version:4
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: C
Dokument:Formals
Kapitel: Abschnitt:Dialogspezifikation StatusprotokollStand: 06.10.2017Seite: 65
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Bezugsnachricht1DEGM1
3Bezugssegment1DEnum..3C1>=1
M: Statusmeldung bezieht sich auf einen Auftrag N: Statusmeldung bezieht sich auf die Gesamtnach- richt
4Datum1DEdat#M1
5Uhrzeit1DEtim#M1
6Rückmeldung1DEGM1
+ + +## . Belegungsrichtlinien + + +### Bezugsnachricht + +Einzustellen ist die Referenz auf die Kundennachricht, auf die sich die Sta- +tusmeldung bezieht. + + +## c) Bankparameterdaten + + +### . Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Statusprotokoll Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIPROS
Bezugssegment:HKVVB
Version:4
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
66		Stand: 06.10.2017Kapitel: Dialogspezifikation
Abschnitt: Synchronisierung
+ + +# C.8 Synchronisierung + +Eine Synchronisierung ist erforderlich, wenn + +· für das vom Kunden verwendete Endgerät noch keine Kundensystem-ID verge- +ben wurde. Dies ist nur bei Verwendung des HBCI RAH- / RDH- und PIN/TAN- +Verfahrens erforderlich, da bei symmetrischen Signatur- und Verschlüs- +selungsverfahren kreditinstitutsseitig keine Verwaltung respektive Generierung +einer Kundensystem-ID erfolgt. Bei der Verwendung von RAH-/RDH-Chipkarten +ab Sicherheitsprofil-Version 3 wird anstatt der Kundensystem-ID die CID der ge- +steckten Karte verwendet. Im Rahmen der Dialoginitialisierungs-Antwortnachricht +erhält das entsprechende Kundensystem eine neue Kundensystem-ID mitgeteilt. + + +![](figures/74.1) + + +Bevor ein Benutzer bei Verwendung des HBCI RAH- / RDH- bzw. +des PIN/TAN-Verfahrens von einem neuen Kundensystem Auf- +träge erteilen kann, hat er im Wege einer Synchronisierung eine +Kundensystem-ID für dieses System anzufordern (Ausnahme: +bei Verwendung einer RAH-/RDH-Chipkarte ab Sicherheitsprofil- +Version 3). Diese ID ist im Folgenden stets anzugeben, wenn der +Benutzer von diesem Kundensystem aus Nachrichten sendet. +Wenn eine Synchronisierung der Kundensystem-ID durchgeführt +wird, ist das DE ,Kundensystem-ID" mit dem Wert '0' zu belegen. +Das DE "Identifizierung der Partei" im Signaturkopf in der DEG +"Sicherheitsidentifikation, Details" ist mit dem Wert ,0' zu bele- +gen. + +Kundensystem-IDs, die länger als 6 Monate nicht beim Kredit- +institut eingereicht wurden, können im Kreditinstitut gelöscht +werden. Meldet sich der Kunde mit dieser Kundensystem-ID er- +neut an, wird keine Legitimierung zum Senden von Auftragsnach- +richten erteilt. Der Kunde hat in diesem Fall eine erneute Syn- +chronisierung durchzuführen. + +Da jedes Kreditinstitut die Kundensystem-ID unabhängig von an- +deren Kreditinstituten vergibt, muss das Kundenprodukt in der +Lage sein, für jeden Kreditinstitutszugang eine eigene Kunden- +system-ID zu verwalten. + +. aufgrund eines Verbindungsabbruchs nicht ersichtlich ist, welche Nachrichten +vom Kreditinstitut bereits entgegengenommen wurden. In diesem Fall wird dem +Kunden in der Antwort die Nummer der im vorangegangenen Dialog vom Kredit- +institut zuletzt verarbeiteten Nachricht zurückgemeldet (s. auch Kap. C.6 ,,Verbin- +dungsabbruch"). Eine Synchronisierung der Nachrichtennummer ist daher nur für +den letzten Auftragsdialog des sendenden Benutzers möglich. Eine abge- +brochene Synchronisierungsnachricht überschreibt die letzte Nachrichtennummer +nicht. + + +![](figures/74.2) + + +Das Kundensystem sollte die Synchronisierung von Nachrichten +nicht automatisieren, da bei längeren Ausfallzeiten betroffene +Aufträge evtl. bereits auf anderem Wege beim Kreditinstitut ein- +gereicht wurden. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: C
Dokument:Formals
Kapitel: Abschnitt:Dialogspezifikation SynchronisierungStand: 06.10.2017Seite: 67
+ + +. bei Verwendung des HBCI RAH- oder RDH-Verfahrens die Signatur-ID abhand- +engekommen ist (z. B. durch Festplattendefekt). Da bei fehlender Signatur-ID +keine ordnungsgemäße Signatur erzeugt werden kann, ist in diesem Fall als Sig- +natur-ID der reservierte Wert '9999999999999999' zu verwenden.4 In der Ant- +wortnachricht wird die bisher höchste vom Benutzer bei diesem Kreditinstitut ein- +gereichte Signatur-ID zurückgemeldet.5 Bei symmetrischen HBCI Signatur- +Verfahren und TAN-Verfahren unter Verwendung von HKTAN > Segmentversion +#4 ist diese Option nicht zulässig. + + +![](figures/75.1) + + +Da die Signatur-ID multibankfähig ist, muss im Fall des Verlusts +der Signatur-ID bei jedem Kreditinstitut, bei dem der Benutzer +Signaturen eingereicht hat, eine Synchronisierung vorgenommen +werden. Für zukünftige Signaturen ist dann der höchste aller zu- +rückgemeldeten Werte inkrementiert um 1 zu verwenden. + +Bestehende Aufträge, die noch nicht abgeschickt wurden, sind +nach der Synchronisierung der Signatur-ID neu zu signieren, da +ansonsten neu erfasste Aufträge aufgrund einer Doppeleinrei- +chung abgelehnt würden. + + +![](figures/75.2) + + +Bei einer Synchronisierung der Kundensystem-ID oder der Signa- +tur-ID sollte für die Synchronisierungsnachricht keine Doppelein- +reichungskontrolle durchgeführt werden soll. + +Falls eine Synchronisierungsnachricht gesendet wird, dürfen anschließend keine +Auftragsnachrichten gesendet werden. Hierzu hat das Kundensystem nach dem Er- +halt der Antwortnachricht den Dialog durch Senden einer Dialogendenachricht zu +beenden. Um Auftragsnachrichten zu schicken, muss das Kundenprodukt anschlie- +Bend eine neue Dialoginitialisierung für diesen Benutzer senden. + + +## C.8.1 Kundennachricht + + +### C.8.1.1 Nachrichtenformat + +. Format + + + + + + + + + + + + + + + + + + + +
Name:Synchronisierungsnachricht
Typ:Nachricht
Version:4
Sender:Kunde
+ + + + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite: 68Stand: 06.10.2017Kapitel: Dialogspezifikation
Abschnitt: Synchronisierung
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypKen- nungSta- tusAn- zahlAnmerkungen
1Nachrichtenkopf3SEGHNHBKM1
2Signaturkopf4SEGHNSHKM1s. [HBCI], Kap. B.5.1
3Identifikation2SEGHKIDNM1
4Verarbeitungsvor- bereitung3SEGHKVVBM1
5Zwei-Schritt-TAN- Einreichung≥6SEGHKTANO1s. [PINTAN], Kap. B.3.3
6Anforderung eines öffentlichen Schlüs- sels3SEGHKISAC3O: bei HBCI RAH und RDH N: bei HBCI DDV oder TAN-Verfahren
7Synchronisierung3SEGHKSYNM1
8Signaturabschluss2SEGHNSHAM1s. [HBCI], Kap. B.5.2
9Nachrichtenab- schluss1SEGHNHBSM1
+ + +### C.8.1.2 Segment: Synchronisierung + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
. Format
Name:Synchronisierung
Typ:Segment
Segmentart:Administration
Kennung:HKSYN
Bezugssegment:-
Version:3
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Synchronisierungs- modus2DEcode1M10, 1, 2
+ + +#### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
9210Kundensystem-ID wird vom Kreditinstitut nicht unterstützt
9210Synchronisierung der Signatur-ID ist nicht zulässig
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: C
Dokument:Formals
Kapitel:
Abschnitt:		Dialogspezifikation SynchronisierungStand: 06.10.2017Seite: 69
+ + +## C.8.2 Kreditinstitutsnachricht + + +### C.8.2.1 Nachrichtenformat + + +#### . Beschreibung + +Das Kreditinstitut meldet dem Kundensystem je nach Kundenanforderung entweder +die neu zugeteilte Kundensystem-ID, die zuletzt erhaltene Nachrichtennummer des +vorangegangenen Dialoges oder die aktuelle Signatur-ID (Sicherheitsreferenznum- +mer) zurück. + + +#### . Format + + + + + + + + + + + + + + + + + + + +
Name:Synchronisierungsantwortnachricht
Typ:Nachricht
Version:4
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypKen- nungSta- tusAn- zahlAnmerkungen
1Nachrichtenkopf3SEGHNHBKM1
2Signaturkopf4SEGHNSHKO1s. [HBCI], Kap. B.5.2
3Rückmeldungen zur Gesamtnachricht2SEGHIRMGM1
4Rückmeldungen zu Segmenten2SEGHIRMSOn
5Bankparameterda- ten3SF#O1
6Userparameterda- ten3SF#O1
7Übermittlung eines öffentlichen Schlüs- sels3SEGHIISAC3O: bei HBCI RAH und RDH N: bei HBCI DDV- oder TAN-Verfahren
8Synchronisierungs- antwort4SEGHISYNM1
9Kreditinstitutsmel- dung2SEGHIKIMOn
10Signaturabschluss2SEGHNSHAO1s. [HBCI], Kap. B.5.3
11Nachrichtenab- schluss1SEGHNHBSM1
+ + +### C.8.2.2 Segment: Synchronisierungsantwort + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Synchronisierungsantwort
Typ:Segment
Segmentart:Administration
Kennung:HISYN
Bezugssegment:HKSYN
Version:4
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite: 70Stand: 06.10.2017Kapitel: Dialogspezifikation
Abschnitt: Synchronisierung
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kundensystem-ID1DEid#C1M: Synchronisierungsmo- dus = 0 N: sonst
3Nachrichtennum- mer1DEnum..4C1>0
M: Synchronisierungsmo- dus = 1 N: sonst
4Sicherheitsrefe- renznummer für Signierschlüssel1DEnum.. 16C1M: Synchronisierungsmo- dus = 2 N: sonst
5Sicherheitsrefe- renznummer für Di- gitale Signatur1DEnum.. 16C1M: Synchronisierungsmo- dus = 2 und Sicherheits- profil = RAH-7,RDH-3, RDH-6 oder RDH-7 N: sonst
+ + +# . Belegungsrichtlinien + + +## Sicherheitsreferenznummer für Digitale Signatur + +Es ist die Signatur-ID des Schlüssels für Digitale Signaturen (Schlüsselart +,,D") anzugeben. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: C
Dokument:Formals
Kapitel:
Abschnitt:		Dialogspezifikation Life-Indikator-NachrichtStand: 06.10.2017Seite: 71
+ + +## C.9 Life-Indikator-Nachricht + +Falls in einem laufenden Dialog über einen längeren Zeitraum keine weiteren Kun- +dennachrichten mehr geschickt werden, ist es für ein Kreditinstitutssystem nicht er- +sichtlich, ob der Kunde noch weitere Nachrichten senden wird oder den Dialog be- +reits abgebrochen hat. + +Insbesondere für Kundenprodukte, die im Online-Modus arbeiten (d. h. der Dialog +wird nach dem Senden der Aufträge nicht automatisch beendet), steht daher mit der +Life-Indikator-Nachricht eine Möglichkeit zur Verfügung, dem Kreditinstitutssystem +anzuzeigen, dass der Kundendialog aufrecht erhalten werden soll und somit eine +Dialogbeendigung aufgrund eines Timeouts durch das Kreditinstitutssystem vermie- +den wird. + +Das Kreditinstitut in den Bankparameterdaten einen minimalen und einen maxima- +len Timeout-Wert mitteilen, der dem Kundensystem eine Information darüber gibt, +nach welchem Zeitraum eine Life-Indikator-Nachricht frühestens gesendet werden +darf bzw. nach welchem Zeitraum das Kreditinstitut den Dialog voraussichtlich be- +enden wird + + +Abbildung 13: Funktionsweise des Life-Indikators + +![Letzte Nachricht KeepAlive- Nachricht t t0 tmin tmax Dialogendenachricht, Auftragsnachricht oder weiter KeepAlive- Nachricht t t0 tmin tmax](figures/79.1) + + +Das Senden einer Life-Indikator-Nachricht führt jedoch nicht zwingend zur Aufrecht- +erhaltung eines Dialoges. Unabhängig von gesendeten Life-Indikator-Nachrichten +und dem Timeout-Wert in den Bankparameterdaten hat das Kreditinstitut jederzeit +die Möglichkeit den Dialog abzubrechen. + +Die Life-Indikator-Nachricht ist sowohl für Kunde als auch für Kreditinstitut optional. +Das Kreditinstitut teilt durch Angabe des Timeout-Wertes in den BPD dem Kunden- +system mit, dass es die Life-Indikator-Nachricht unterstützt. Sind beide Werte dage- +gen nicht angegeben, so muss das Kundenprodukt davon ausgehen, dass das Kre- +ditinstitut die Life-Indikator-Nachricht nicht unterstützt. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
72		Stand: 06.10.2017Kapitel: Dialogspezifikation
Abschnitt: Life-Indikator-Nachricht
+ + +Das Life-Indikator-Segment darf nur in der speziell hierfür vorgesehenen Nachricht +gesendet werden. Diese Nachricht darf nicht auBerhalb der Dialogschrittfolge ge- +sendet werden, d. h. nicht, wenn noch die Beantwortung eines Auftrags durch das +Kreditinstitut aussteht. Obwohl die Nachricht bei personalisierten Dialogen innerhalb +eines signierten und verschlüsselten Dialoges gesendet wird, ist sie unsigniert und +unverschlüsselt. + +Das Senden einer Life-Indikator-Nachricht hat keine Auswirkungen auf die aktuelle +Nachrichtennummer. Der Inhalt des Feldes ,,Nachrichtennummer“ ist beliebig befüll- +bar und wird vom Kreditinstitut ignoriert. Auch wird die Nummer einer Life-Indikator- +Nachricht nie bei einer Synchronisierung der Nachrichtennummer zurückgeliefert. + +Das Segment enthält mit Ausnahme des Segmentkopfes keine Datenelemente. + + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Life-Indikator
Typ:Segment
Segmentart:Administration
Kennung:HKLIF
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
+ + +### a) Kundennachricht + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + +
Name:Life-Indikator-Nachricht
Kennung:N21
Typ:Nachricht
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypKen- nungSta- tusAn- zahlAnmerkungen
1Nachrichtenkopf3SEGHNHBKM1
2Life-Indikator1SEGHKLIFM1
3Nachrichtenab- schluss1SEGHNHBSM1
+ + +#### . Belegungsrichtlinien + + +#### Nachrichtenkopf + +Es muss die Dialog-ID des zugrunde liegenden Dialoges angegeben werden. + + +#### b) Kreditinstitutsnachricht + + +#### . Beschreibung + +Das Kreditinstitut antwortet auf die Life-Indikator-Nachricht mit einer allgemeinen +Kreditinstitutsnachricht und informiert mit dem Rückmeldungscode das Kundensys- + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: C
Dokument:Formals
Kapitel:
Abschnitt:		Dialogspezifikation
Life-Indikator-Nachricht		Stand: 06.10.2017Seite: 73
+ + +tem, ob es dem Wunsch nach Aufrechterhaltung des Dialoges entspricht oder die- +sen ablehnt. Wie auch die Kundennachricht ist die Antwortnachricht nicht signiert +und nicht verschlüsselt. + + +### . Format + + + + + + + + + + + + + + + + + + + +
Typ:Nachricht
Name:Kreditinstitutsnachricht allgemein
Typ:Nachricht
Format:s. Kap. B.7.1
+ + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Dialog wird fortgeführt
9800Dialog wird nicht fortgeführt
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
74		Stand: 06.10.2017Kapitel: Dialogspezifikation
Abschnitt: Unterstützung von Geschäftsvorfallversionen
+ + +# C.10 Unterstützung von Geschäftsvorfallversionen + +Die Geschäftsvorfallversion (Segmentversion) ist unabhängig von der FinTS- +Version, d. h. grundsätzlich können alternativ oder zusätzlich zu den in [Messages] +beschriebenen Geschäftsvorfallversionen in allen FinTS-Versionen beliebige andere +existierende Versionen eines Geschäftsvorfalls unterstützt werden. Einzige Bedin- +gung ist, dass der Geschäftsvorfall einer älteren Version auch aus Anwendungsge- +sichtspunkten noch zulässig ist. So sind folgende Segmentversionen von dieser Re- +gelung ausgenommen: + +. Segmentversionen aus FinTS-Versionen vor Version 2.0.1 + +· Segmentversionen von Geschäftsvorfällen, die aufgrund geänderter rechtli- +cher Rahmenbedingungen nicht mehr gültig sind, z. B. Geschäftsvorfälle des +ehemaligen Inlands-Zahlungsverkehrs. + +. Segmentversionen von Geschäftsvorfällen, die Fremdformate enthalten, die +nicht mehr unterstützt werden (z. B. aufgrund fehlender Euro-Fähigkeit) + +Die konkret zulässigen Segmentversionen sind der Tabelle in Anhang von [Messa- +ges] zu entnehmen. In den Spalten sind zum einen je Geschäftsvorfall die in den +bisher veröffentlichten FinTS-Versionen definierten Segmentversionen angegeben. +In der Spalte ,gültig“ sind diejenigen Segmentversionen des Geschäftsvorfalls an- +gegeben, die in allen der angegeben FinTS-Versionen grundsätzlich zulässig sind. +Sofern neue FinTS-Versionen veröffentlicht werden, wird diese Tabelle entspre- +chend erweitert. + + +## Beispiele: + +Eine FinTS-Implementierung auf Basis FinTS 3.0 kann den Geschäftsvorfall AOM in +den Versionen 1 oder 2 anbieten, obwohl dieser Geschäftsvorfall in der Spezifikati- +on dieser FinTS-Version unbekannt ist. + +In den Bankparameterdaten sind immer alle bankseitig unterstützten Segmentversi- +onen eines Geschäftsvorfalls anzugeben (d. h. das Parametersegment ist für jede +unterstützte Segmentversion einzeln einzustellen, s. Kap. D.6), also auch derjenigen +Segmentversionen, die nicht mehr zum Umfang der aktuellen FinTS-Version gehö- +ren. Die Angabe einer Segmentversion in den BPD setzt die Unterstützung der +Segmentversion sowohl durch die FinTS-Implementierung als auch durch die jewei- +lige fachliche Anwendung voraus. Die bankseitig unterstützten Segmentversionen +sind unabhängig von der FinTS-Version stets eine Teilmenge (oder die Gesamtheit) +der in der Spalte ,,gültig“ angegebenen Segmentversionen. + +Aufgrund der genannten Änderungen kann ein Kundensystem nicht davon ausge- +hen, dass die zur jeweils ausgehandelten FinTS-Version gehörigen Segmentversio- +nen bankseitig auch unterstützt werden. Kundenprodukte sollten daher nach Mög- +lichkeit mehrere Versionen eines Geschäftsvorfalls unterstützen, um die Gefahr zu +minimieren, dass eine Kommunikation aufgrund unterschiedlicher Versionsunter- +stützung nicht zustande kommt. Sofern von beiden Seiten mehrere gemeinsame +Versionen unterstützt werden, so sollte die Kommunikation auf Basis der höchsten +gemeinsamen Version erfolgen. + + +## Beispiel: + +Ein Kundensystem unterstützt die Versionen 4, 5 und 6 eines Geschäftsvorfalls. An- +hand der Bankparameterdaten erfährt das Kundensystem, dass bankseitig die Ver- + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: C
Dokument:Formals3.0-FV
Kapitel:DialogspezifikationStand:Seite:
Abschnitt:Unterstützung von Geschäftsvorfallversionen06.10.201775
+ + +sionen 3, 4 und 5 des Geschäftsvorfalls verarbeitet werden können. Daher sollte +das Kundensystem den Auftrag gemäß Segmentversion 5 senden. + +Diese Vereinbarungen gelten ausdrücklich nur für Geschäftsvorfallsegmente und +nicht für administrative Segmente. Es handelt sich lediglich um verbale Klarstellun- +gen, die keine Änderungen an bestehenden FinTS-Formaten und Abläufen bedin- +gen. Die Unterstützung dieser Funktionalität durch FinTS-Implementierungen ist +nicht verpflichtend. + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: D
Dokument:Formals
Kapitel:
Abschnitt:		Bankparameterdaten (BPD) AllgemeinesStand: 06.10.2017Seite: 77
+ + +# D. BANKPARAMETERDATEN (BPD) + + +## D.1 Allgemeines + + +### . Beschreibung + +Die Bankparameterdaten dienen zum einen der automatisierten kreditinstitutsspezi- +fischen Konfiguration von Kundensystemen und zum anderen der dynamischen An- +passung an institutsseitige Vorgaben hinsichtlich der Auftragsgenerierung. + +Des Weiteren ist es mit Hilfe der BPD möglich, bestimmte Fehler bereits auf der +Kundenseite zu erkennen, was sich wiederum positiv auf die institutsseitige Verar- +beitung der Auftragsdaten auswirkt. + + +#### Beispiel: + +Zur Einreichung einer terminierten SEPA-Überweisung bei einem Kreditinstitut ent- +halten die BPD-Parameter die minimale und maximale Vorlaufzeit für das ge- +wünschte Datum der Ausführung. + +Bei korrekter Nutzung durch das Kundensystem verhindert dieser Mechanismus +somit, dass Informationen an die Kreditinstitute gesendet werden, die diese nicht +darstellen bzw. verarbeiten können. + + +![](figures/85.1) + + +Da auf Schnittstellenebene nicht gewährleistet werden kann, dass +das Kundenprodukt die Bankparameterdaten korrekt auswertet, hat +auf jeden Fall eine entsprechende kreditinstitutsseitige Prüfung +stattzufinden. + +Bei kreditinstitutsseitigen Änderungen werden die aktualisierten Bankparameterda- +ten dem Kunden beim nächsten Dialog automatisch im Rahmen der Dialoginitiali- +sierung übermittelt. Die neuen BPD werden sofort, d. h. schon für den laufenden Di- +alog, aktiv. + + +![](figures/85.2) + + +Intelligente Kundenprodukte können in diesem Fall im laufenden Di- +alog die Einhaltung der BPD prüfen und die Auftragsnachrichten wie +geplant senden, falls die BPD-Änderungen keine Auswirkung auf +die zur Versendung anstehenden Aufträge haben. Steht diese Intel- +ligenz nicht zur Verfügung, so muss nach Erhalt der neuen BPD der +laufende Dialog vom Kunden (Kundenprodukt) beendet, die Aufträ- +ge geprüft bzw. neu erfasst und dann ein neuer Dialog begonnen +werden. + +In Abgrenzung zu den UPD enthalten die BPD ausschließlich Daten, die für das je- +weilige Kreditinstitut spezifisch sind, und damit eher seltener geändert werden müs- +sen. + +Ist zur Belegung von DEs keine Angabe gemacht (z. B. Signaturverfahren etc.), er- +folgt die Belegung wie in der entsprechenden Nachricht/Segment. + +Realisierung Bank: verpflichtend + +Realisierung Kunde: verpflichtend + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
78		Stand: 06.10.2017Kapitel: Bankparameterdaten (BPD)
Abschnitt: Allgemeines
+ + +![](figures/86.1) + + +Werden Bankparameterdaten in einer Form übergeben, die +eine Dateibenennung erfordert (z. B. auf Diskette), ist als Na- +me für Bankparameterdaten "\*.bpd" zu wählen, wobei +"\*" +durch die jeweilige Kreditinstitutskennung (Bankleitzahl) zu er- +setzen ist.1 + +Über die Angebote fremder Kreditinstitute kann sich der Kun- +de mit Hilfe derer BPD informieren. Es wird empfohlen, Kun- +denprodukte standardmäßig mit einer Auswahl von Bankpa- +rameterdaten gängiger Kreditinstitute auszustatten. Falls die- +se nicht auf dem Kundensystem verfügbar sind, muss ein Dia- +log mit dem Fremdinstitut geführt werden, während dessen die +aktuellen BPD automatisch übertragen werden. Zur erstmali- +gen Verbindungsaufnahme mit dem Fremdinstitut sind dessen +Zugangsdaten erforderlich. Diese erhält das Kundenprodukt +entweder durch den Abruf der Kommunikationszugangsdaten +(s. Kap. 1.5) oder auf anderem Wege (z. B. direkt von seinem +Institut). Im letzteren Fall müssen die Zugangsdaten manuell +eingegeben werden. + + +### . Format + +Name: +Bankparameterdaten +Typ: +Segmentfolge +Sender: +Kreditinstitut +Version: +3 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypKen- nungSta- tusAn- zahlAnmerkungen
1Bankparameter all- gemein3SEGHIBPAM1
2Kommunikations- zugang rückmelden1SEGHIKOMO1
3Sicherheitsverfah- ren3SEGHISHVO1
4Komprimierungs- verfahren1SEGHIKPVO1
5Parameterdaten2SF#O1
+ + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: D
Dokument:Formals
Kapitel:
Abschnitt:		Bankparameterdaten (BPD) Bankparameter allgemeinStand: 06.10.2017Seite: 79
+ + +## D.2 Bankparameter allgemein + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Bankparameter allgemein
Typ:Segment
Segmentart:Administration
Kennung:HIBPA
Bezugssegment:HKVVB
Version:3
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2BPD-Version1DEnum..3M1
3Kreditinstitutsken- nung1DEGkik#M1
4Kreditinstitutsbe- zeichnung1DEan..60M1
5Anzahl Geschäfts- vorfallsarten1DEnum..3M1
6Unterstützte Spra- chen2DEGM1
7Unterstützte HBCI- Versionen2DEGM1
8Maximale Nachrich- tengröße1DEnum..4O1
9Minimaler Timeout- Wert1DEnum..4O1
10Maximaler Timeout- Wert1DEnum..4O1
+ + +## . Belegungsrichtlinien + + +## Kreditinstitutskennung + +Es ist die Institutskennung des Kreditinstituts einzustellen, auf das sich die +nachfolgenden Bankparameterdaten beziehen. + + +## Maximale Nachrichtengröße + + +![](figures/87.1) + + +Sollte dieses DE belegt sein, hat das Kundenprodukt bei der +Zusammenstellung der Nachricht diese Restriktion zu beach- +ten. Zu große Nachrichten dürfen nicht zur Versendung frei- +gegeben werden. Eventuell hat das Kundenprodukt Nach- +richten, die aus mehreren Aufträgen bestehen, in mehrere +kleinere Nachrichten mit je einem Auftrag aufzuteilen. Kann +die Nachrichtengröße bei umfangreichen Einzelaufträgen (z. +B. Sammelüberweisungen) nicht verringert werden, so ist der +Auftrag anwendungsseitig zu verkleinern. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
80		Stand: 06.10.2017Kapitel: Bankparameterdaten (BPD)
Abschnitt: Kommunikationszugang
+ + +## D.3 Kommunikationszugang + + +### . Beschreibung + +Dieses Segment enthält transportmedienspezifische Informationen, die für den Zu- +gang zum Kreditinstitut erforderlich sind. + + +![](figures/88.1) + + +Für den Erstzugang oder den anonymen Zugang ist die Einstellung +dieser Informationen in den BPD nicht hilfreich, da in diesem Fall +zum Zeitpunkt des Zugangs die entsprechenden BPD noch nicht +vorliegen. Die vom Kundenprodukt benötigten Zugangsinformati- +onen sollten daher durch den Abruf der Kommunikationszugangs- +daten (s. Kap. I.5) angefordert werden. + +Die Einstellung dieser Daten erfolgt dennoch redundant in den BPD, +um einerseits dem Kundenprodukt Änderungen der Zugangspara- +meter direkt online mitzuteilen und andererseits den Zugang auch +zu ermöglichen, sofern das Kundenprodukt die BPD bereits vorlie- +gen hat (bspw. auf CD). + + +![](figures/88.2) + + +Grundsätzlich gelten für alle Kommunikationszugänge eines Insti- +tuts dieselben Bankparameterdaten (BPD). Möchte das Kreditinsti- +tut seine Angebote (z. B. die erlaubten Geschäftsvorfälle) abhängig +vom Kommunikationsmedium gestalten, so besteht die Möglichkeit, +für bestimmte Kommunikationszugänge eine eigene, noch nicht be- +legte BLZ zu vergeben. + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kommunikationszugang rückmelden
Typ:Segment
Segmentart:Administration
Kennung:HIKOM
Bezugssegment:HKVVB
Version:s. Kap. I.5
Sender:Kreditinstitut
Format:s. Kap. I.5
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: D
Dokument:Formals
Kapitel:
Abschnitt:		Bankparameterdaten (BPD) SicherheitsverfahrenStand: 06.10.2017Seite: 81
+ + +## D.4 Sicherheitsverfahren + + +### . Beschreibung + +Es sind die Sicherheitsverfahren, d. h. Signatur- und Verschlüsselungsalgorithmen, +anzugeben, die das Kreditinstitut unterstützt. + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Sicherheitsverfahren
Typ:Segment
Segmentart:Administration
Kennung:HISHV
Bezugssegment:HKVVB
Version:3
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Mischung zulässig1DEjn#M1
3Unterstützte Si- cherheitsverfahren3DEGM1..9
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
82		Stand: 06.10.2017Kapitel: Bankparameterdaten (BPD)
Abschnitt: Komprimierungsverfahren
+ + +## D.5 Komprimierungsverfahren + + +### . Beschreibung + +Es sind die Komprimierungsverfahren anzugeben, die das Kreditinstitut unterstützt. + +Falls das Kreditinstitut Komprimierung unterstützt, ist der deflate- oder auch GZIP- +Algorithmus gemäß RFC 1951 [RFC 1951] zwingend anzubieten. Die anderen Algo- +rithmen können zusätzlich optional angeboten werden. Zum deflate-Algorithmus gibt +es eine freie, auch in kommerziellen Produkten einsetzbare Referenzimplementie- +rung sowohl in Source-Form als auch als binäre Bibliothek für alle gängigen Platt- +formen [(http://www.gzip.org/zlib).](http://www.gzip.org/zlib) + +Das Kreditinstitut darf nur komprimiert antworten, wenn das Kundensystem (z. B. +ein Smartphone) auch komprimiert gesendet hat. Damit wird vermieden, dass ein +Kundensystem eine komprimierte Nachricht erhält und diese ggf. nicht verarbeiten +kann. + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Komprimierungsverfahren
Typ:Segment
Segmentart:Administration
Kennung:HIKPV
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Unterstützte Kom- primierungs- verfahren2DEGM1..9
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: D
Dokument:Formals
Kapitel:
Abschnitt:		Bankparameterdaten (BPD) GeschäftsvorfallparameterStand: 06.10.2017Seite: 83
+ + +## D.6 Geschäftsvorfallparameter + + +### . Beschreibung + +Dieses Segment beschreibt anhand von Parametern die konkrete kreditinstitutsindi- +viduelle Ausgestaltung eines Geschäftsvorfalls. + +Das Segment ist für jeden Geschäftsvorfall einzustellen, den das Kreditinstitut unter- +stützt. Geschäftsvorfälle sind hierbei alle Auftragssegmente mit der Segmentart ,,Ge- +schäftsvorfall“. Bei Nichtunterstützung eines Geschäftsvorfalls entfällt das Segment. +Falls mehrere Versionen des Geschäftsvorfalls unterstützt werden, ist das Segment +für jede Segmentversion einzustellen. Die Zuordnung der Geschäftsvorfallparameter +zur jeweiligen Version des Geschäftsvorfalls erfolgt hierbei durch die im Segment- +kopf angegebene Segmentversion (s. Kap. B.5.1). + + +![](figures/91.1) + + +Da ein Kreditinstitut neben den in der DK standardisierten Ge- +schäftsvorfällen auch verbandseigene Transaktionen unterstützen +kann2, die dem Kundenprodukt u. U. nicht bekannt sind, darf ein +Kundenprodukt Segmente mit einer ihm unbekannten Segmentken- +nung nicht als Syntaxfehler ablehnen, sondern darf diese nicht in- +terpretieren. + + +![](figures/91.2) + + +Es ist dem Kreditinstitut freigestellt, ob es in den Bankparameterda- +ten grundsätzlich alle Segmentversionen eines Geschäftsvorfalls +einstellt, die es unterstützt oder nur diejenigen, die in Abhängigkeit +von der FinTS-Version, die der Kunde in der Dialoginitialisierung +mitteilt, im aktuellen Dialog als gültig entgegengenommen würden. + + +### . Format + +Typ: + +Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter1DEG#1
+ + + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
84		Stand: 06.10.2017Kapitel: Bankparameterdaten (BPD)
Abschnitt: Parameterdaten
+ + +## D.7 Parameterdaten + + +### . Beschreibung + +Die Segmentfolge ,,Parameterdaten“ enthält die in [Messages] beschriebenen Pa- +rametersegmente. + + + + + + + + + + + + + + + + + + + + + + +
. Format
Name:Parameterdaten
Typ:Segmentfolge
Sender:Kreditinstitut
Version:2
+ + +### ◆ Erläuterungen + +Die Reihenfolge der Segmente ist nicht erheblich. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: E
Dokument:Formals
Kapitel:
Abschnitt:		Userparameterdaten (UPD) AllgemeinesStand: 06.10.2017Seite: 85
+ + +# E. USERPARAMETERDATEN (UPD) + + +## E.1 Allgemeines + + +### . Beschreibung + +Die Userparameterdaten, die kreditinstitutsseitig benutzerbezogen generiert und +vorgehalten werden, erlauben eine automatisierte und dynamische Konfiguration +von Kundensystemen. In Abgrenzung zu den BPD enthalten die UPD ausschließlich +kunden- und kontenspezifische Informationen und sind somit häufigeren Modifikati- +onen unterworfen. + +Während die Bankparameterdaten die grundsätzlich vom Kreditinstitut angebotenen +Geschäftsvorfälle angeben, gestatten die Userparameterdaten kontenbezogene Be- +rechtigungsprüfungen im Kundenprodukt. So kann das Kundenprodukt mit Hilfe der +Userparameterdaten prüfen, ob der Kunde für die Ausführung eines der in den +Bankparameterdaten angegebenen Geschäftsvorfälle in Verbindung mit einem be- +stimmten Konto berechtigt ist. + +Das Konto, das im jeweiligen Geschäftsvorfall für die Berechtigungsprüfung heran- +zuziehen ist, ist im Regelfall entweder das Auftraggeberkonto oder das Depotkonto +bei Wertpapieraufträgen oder das Anlagekonto bei Festgeldanlagen. In den Fällen, +in denen es sich um ein hiervon abweichendes Konto handelt, ist dies in der Ge- +schäftsvorfallbeschreibung vermerkt. Bei Geschäftsvorfällen ohne Kontenbezug (z. +B. Informationsbestellung) findet keine Berechtigungsprüfung statt. + +Bei Änderungen werden die Userparameterdaten im Rahmen der Dialoginitialisie- +rung für den sich anmeldenden Benutzer automatisch aktualisiert. Die aktualisierten +UPD werden sofort aktiv (s. hierzu die Ausführungen zu den BPD). + +Realisierung Bank: verpflichtend + +Realisierung Kunde: verpflichtend + + +![](figures/93.1) + + +Da auf Schnittstellenebene nicht gewährleistet werden kann, dass +das Kundenprodukt die Userparameterdaten korrekt auswertet, hat +auf jeden Fall eine entsprechende kreditinstitutsseitige Prüfung +stattzufinden. + +Obwohl die Einstellung der Kontoinformationen für das Kreditinstitut +nicht verpflichtend ist, sollte es im Interesse einer einfachen und +komfortablen Kontenverwaltung für den Kunden, diese Informatio- +nen für alle Konten des Kunden bereitstellen. + + + + + + + + + + + + + + + +
Kapitel: EVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
86		Stand: 06.10.2017Kapitel: Userparameterdaten (UPD)
Abschnitt: Allgemeines
+ + +![](figures/94.1) + + +(s. auch Hinweise bei „Bankparameterdaten“) Die Nutzung der UPD +erfordert eine entsprechende Unterstützung durch das Kunden- +produkt. Dateiname (sofern erforderlich) ist "\*.upd", wobei "\*" durch +eine eindeutige Kennung, die den Benutzer angibt, zu ersetzen ist.1 + +Da die Einstellung der Kontoinformationen für das Kreditinstitut nicht +verpflichtend ist, sollte das Kundenprodukt die Möglichkeit der ma- +nuellen Kontenerfassung vorsehen. + + + + + + + + + + + + + + + + + + + + + + +
. Format
Name:Userparameterdaten
Typ:Segmentfolge
Sender:Kreditinstitut
Version:3
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypKennungSta- tusAn- zahlAnmerkungen
1Userparameter all- gemein4SEGHIUPAM1
2Kontoinformation6SEGHIUPDOn
+ + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: E
Dokument:Formals
Kapitel:
Abschnitt:		Userparameterdaten (UPD)
Userparameter allgemein		Stand: 06.10.2017Seite: 87
+ + +## E.2 Userparameter allgemein + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Userparameter allgemein
Typ:Segment
Segmentart:Administration
Kennung:HIUPA
Bezugssegment:HKVVB
Version:4
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Benutzerkennung1DEid#M1
3UPD-Version1DEnum..3M1
4UPD-Verwendung2DEcode1M10, 1
5Benutzername1DEan..35O1
6Erweiterung, allge- mein1DEan.204 8O1
+ + +## . Belegungsrichtlinien + + +### Benutzerkennung + +Es ist die Benutzerkennung des Benutzers anzugeben, auf den sich die +Userparameterdaten beziehen (s. Kap. C.1.1). + + +### UPD-Version + +Antwortet ein Kreditinstitut auf das Kundensegment HKVVB und der UPD- +Version=0 im Segment HIUPA ebenfalls mit einer UPD-Version=0, so müs- +sen im aktuellen Dialog diese übermittelten UPD verwendet werden; die +UPD sind dann nur für diesen Dialog gültig. + + +### Erweiterung, allgemein + +Die innere Struktur dieses Parameterfeldes ist nicht weiter spezifiziert und +kann von den Partnern bilateral verwendet werden. Zur Selektion dieses +neuen Datenelementes muss HKVVB (Verarbeitungsvorbereitung) mindes- +tens in der Segmentversion 3 gesendet werden. + + + + + + + + + + + + + + + +
Kapitel: EVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
88		Stand: 06.10.2017Kapitel: Userparameterdaten (UPD)
Abschnitt: Kontoinformation
+ + +## E.3 Kontoinformation + + +### . Beschreibung + +Das Segment ,,Kontoinformation“ sollte für jedes Konto, für das der Benutzer beim +betreffenden Kreditinstitut eine Verfügungsberechtigung besitzt, eingestellt werden. + +Darüber hinaus kann auch ein Eintrag für nicht kontogebundene Geschäftsvorfälle +(z. B. Informationsbestellung) eingestellt werden. Hierbei handelt es sich im Regel- +fall um Geschäftsvorfälle, die auch über den anonymen Zugang genutzt werden +können. In diesem Fall sind die Felder für die Kontoverbindung und die übrigen kon- +tobezogenen Angaben nicht zu belegen. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
. Format
Name:Kontoinformation
Typ:Segment
Segmentart:Administration
Kennung:HIUPD
Bezugssegment:HKVVB
Version:6
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung2DEGktv#C1N: bei Geschäftsvorfällen ohne Kontenbezug M: sonst
3IBAN1DEan..34O1
4Kunden-ID1DEid#M1
5Kontoart1DEnum..2O1
6Kontowährung1DEcur#O1
7Name des Kontoin- habers 11DEan..27M1
8Name des Kontoin- habers 21DEan..27O1
9Kontoproduktbe- zeichnung1DEan..30O1
10Kontolimit2DEGO1
11Erlaubte Ge- schäftsvorfälle2DEGO999
12Erweiterung, konto- bezogen1DEan.204 8O1
+ + +## . Belegungsrichtlinien + + +## IBAN + +Das Feld "IBAN" ist in FinTS V3.0 im Band „Multibankfähige Geschäftsvorfäl- +le" mit ..34 Stellen definiert. Die ursprüngliche Definition des HIUPD#6 sah +irrtümlicherweise eine maximale Länge von 35 Stellen vor. Falls ein Kreditin- +stitut in HIUPD IBANs mit 35 Stellen senden sollte, kann die Stelle 35 abge- +schnitten werden. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: E
Dokument:Formals
Kapitel:
Abschnitt:		Userparameterdaten (UPD) KontoinformationStand: 06.10.2017Seite: 89
+ + +## Name Kontoinhaber 1 und 2 + +Die Felder "Name des Kontoinhabers 1" und "Name des Kontoinhabers 2" +sind in FinTS V3.0 mit ..27 Stellen definiert. Da diese Felder in anderem +Kontext maximal 35 Stellen lang sein können, wird auch für diese beiden +UPD-Felder eine Maximallänge von 35 Stellen zugelassen. Bestehende Im- +plementierungen sollten damit keine Probleme bekommen und evtl. überzäh- +lige Stellen (>27) ggf. abschneiden. + + +## Erweiterung, kontobezogen + +Die innere Struktur dieses Parameterfeldes ist in Abschnitt E.3.1 spezifiziert. +Zur Selektion dieses neuen Datenelementes muss HKVVB (Verarbeitungs- +vorbereitung) in der Segmentversion 3 gesendet werden. + +Mit Einführung dieser neuen Struktur innerhalb des DE Erweiterung, +kontobezogen ist keine individuelle Nutzung dieses Datenelements mehr +zugelassen. + + +## E.3.1 Aufbau der UPD-Erweiterung, kontobezogen + +Das Datenelement Erweiterung, kontobezogen wird in JSON-Notation (Ja- +vascript Object Notation) verwendet und enthält Informationen zur Steuerung von +FinTS-Kundenprodukten, deren Reaktionen im Kapitel F ,,FinTS Prozesse" be- +schrieben sind. + +Einige Institute nutzen dieses Datenelement bereits bilateral zur Übermittlung eines +Timestamp des letzten bereitgestellten Umsatzes (Version ,00.00"). Eine multibank- +fähige Definition wird jedoch erst ab Version 01.00 spezifiziert. + +In der vorliegenden Beschreibung wird auch bei JSON-Notation von ,Datenelemen- +ten" bzw. ,Elementen" gesprochen. + +Beispielhafter Aufbau der JSON-Struktur der „Version 00.00“ + +{ +"umsltzt": "2014-11-24-15.06.38.253985" +} + + + + + + + + + + + + + + + + +
Beispielhafter Aufbau der JSON-Struktur ab Version 01.00
Kapitel: EVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
90		Stand: 06.10.2017Kapitel: Userparameterdaten (UPD)
Abschnitt: Kontoinformation
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Abbildung 14: Beispielhafter Aufbau der UPD-Erweiterung, kontobezogen (Tabelle)
Ver"01.00"
AcctBal
CurEUR
CurValBal
<> DebCrdD
《) Val1476,98
<> Date20151124
<> Time"021533"
InclPendTransBal
<> DebCrdD
() Val1476,98
<> Date20151124
<> Time"063825"
<> OverDraftLim5000,00
<> AvailFunds1000,00
(> AlrdyDrwnOnBal385,00
< > OverDraft500,00
BookTime
<> Date20151124
<> Time"021533"
<> MatDate20151124
BalCompletetrue
BalStatAccttrue
AcctStatNext
<> Date20151125
Time110000
Inventory
HKKAZ2015-11-24-15.06.38.2539850000
() HKCAZ2015-11-24-15.06.38.2539850000
(> HKEKA2015-11-23-23.17.22.1234560000
(> HKECA2015-11-23-23.17.22.1234560000
() HKCSB
() HKCDBMBLTJ4bAa5kCLCglcFGuWdVZoPKuBE
<> BICSSKMDEMM
<> SEPAFmttrue
SEPANameR2FicmllbGUgTXVzdGVybWFubg==
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: E
Dokument:Formals
Kapitel:
Abschnitt:		Userparameterdaten (UPD)
Kontoinformation		Stand: 06.10.2017Seite: 91
+ + +Abbildung 15: Beispielhafter Aufbau der UPD-Erweiterung, kontobezogen (JSON) + +![{ "Ver": "01.00", "AcctBal": { "Cur": "EUR", "CurValBal": { "DebCrd": "D", "Val": "1476,98", "Date": 20151124, "Time": "021533" }, "InclPendTransBal": { "DebCrd": "D", "Val": "1476,98", "Date": 20151124, "Time": "063825" }, "OverDraftLim": "5000,00", "AvailFunds": "1000,00", "AlrdyDrwnOnBal": "385,00", "OverDraft": "500,00", "BookTime": { "Date": 20151124, "Time": "021533" }, "MatDate": 20151124 }, "BalComplete": true, "BalStatAcct": true, "AcctStatNext":{ "Date": 20151125, "Time": 110000 }, "Inventory": { "HKKAZ": "2015-11-24-15.06.38.2539850000", "HKCAZ": "2015-11-24-15.06.38.2539850000", "HKEKA": "2015-11-23-23.17.22.1234560000", "HKECA": "2015-11-23-23.17.22.1234560000", "HKCSB": "", "HKCDB": "MBLTJ4bAa5kCLCglcFGuWdVZoPKuBE" }, "BIC": "SSKMDEMM", "SEPAFmt":true, "SEPAName": "R2FicmllbGUgTXVzdGVybWFubg==" }](figures/99.1) + + + + + + + + + + + + + + + + +
Kapitel: EVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite: 92Stand: 06.10.2017Kapitel: Userparameterdaten (UPD)
Abschnitt: Kontoinformation
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
NameBedeutungTypLän- geSta tusAn- zahlRestriktion / Bemerkung
VerVersionString5M1Aufbau: 00.00
AcctBalSaldoObject#O0-1analog MVE Saldo
CurWährungString3M1
CurValBalGeb. SaldoObject#O0-1
DebCrdSoll/HabenString1M1
ValWertString.15M1
DateDatumdat#M1jjjjmmtt
TimeUhrzeittim#O0-1hhmmss
InclPend TransBalVorgem. Um- sätzeObject#O0-1
DebCrdSoll/HabenString1M1
ValWertString.15M1
DateDatumdat#M1jjjjmmtt
TimeUhrzeittim#O0-1hhmmss
OverdraftLimKreditlinieString..15O0-1
AvailFundsVerfügbarer BetragString.. 15O0-1
AlrdyDrwn OnBalBereits verfüg- ter BetragString.. 15O0-1
OverdraftÜberziehungString..15O0-1
BookTimeBuchungszeit- punktObject#O0-1
DateDatumdat#M1jjjjmmtt
TimeUhrzeittim#O0-1hhmmss
MatDateFälligkeitdat#O0-1jjjjmmtt
BalCompleteKompletter HISAL?Bool#O0-1Wenn AcctBal enthalten
BalStatAcctUmsatzsaldo aktuell?Bool1O0-1Wenn Inventory Umsatzda- ten enthält
AcctStatNextZeitpunkt nächste Um- sätzeObject#O0-1Wenn Inventory Umsatzda- ten enthält
DateDatumdat#M1jjjjmmtt
TimeUhrzeittim#O0-1hhmmss
InventoryBeständeObject#O0-n
SegIDSegmentken- nungString5M1-n
IDIDString30O0-n
BICString.11O1
SEPAFmtFormat des SEPA-Namensbool1O1
SEPANameString bzw. base64..70 bzw. .100O1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: E
Dokument:Formals
Kapitel:
Abschnitt:		Userparameterdaten (UPD) KontoinformationStand: 06.10.2017Seite: 93
+ + +![](figures/101.1) + + +Ein Kundenprodukt kann bei Belegung des Datenelements „Erweite- +rung, kontobezogen" anhand des ersten JSON-Elements erkennen, +ob es sich um die ,,Version 00.00" (mit erstem Datenelement +umsltzt) oder eine Version ab V01.00 (mit erstem Datenelement +Ver) handelt. + +In beiden Fällen sollten die enthaltenen Inhalte entsprechend inter- +pretiert und berücksichtigt werden. + +Für das JSON-Format String gilt der FinTS-Zeichensatz und -Zeichenvorrat. + +Als Zeitzone für die Elemente umsltzt, Date und Time wird UTC+01:00 ange- +nommen. + +Für die einzelnen JSON-Elemente gelten die im Folgenden beschriebenen +Festlegungen. Als Rahmenbedingung gilt, dass die in der JSON-Struktur +verwendeten Geschäftsvorfälle sowohl in den BPD als auch in den UPD unter Er- +laubte Geschäftsvorfälle enthalten sind. + + +### E.3.1.1 Belegungsvorschriften für die einzelnen JSON-Elemente + +Im Folgenden werden die Belegungsvorschriften für die einzelnen JSON-Elemente +der Erweiterung, kontobezogen beschrieben. Bzgl. der konkreten Hand- +lungsoptionen gelten die detaillierteren Aussagen in Kapitel F ,,FinTS Prozesse“). + + + + + + + + + + + + + + + + + + + +
ElementBelegungsvorschriften und Festlegungen
VerVersion der JSON-Struktur
Mit Ausnahme der ,,Version 00.00“ beginnt jede JSON-Struktur mit der Versionskennzeichnung Ver. Es sind nur die in den FinTS Formals veröffentlichten Versionen und deren Inhalte gül- tig.
AcctBalSaldo (Aufbau analog HISAL in der Segmentversion #7)
Das Kreditinstitut liefert in diesem Objekt Saldeninformationen. Das Format leitet sich aus dem in FinTS spezifizierten MVE ab; daher gelten auch die entsprechenden Belegungen.
Erforderliche Reaktion des Kundenprodukts:
Liefert das Kreditinstitut mit diesem Element den aktuellen Sal- do, so sollte das Kundenprodukt keine separate Abfrage des ak- tuellen Saldo einreichen.
BalCompleteSaldeninformationen analog HISAL komplett enthalten
AcctBal enthält alle Informationen, die auch in HISAL bereitge- stellt werden. Ein separater Abruf von HKSAL liefert also keine zusätzlichen Informationen.
Erforderliche Reaktion des Kundenprodukts:
Das Kundenprodukt sollte keine separate Saldenabfrage einrei- chen.
+ + + + + + + + + + + + + + + + +
Kapitel: EVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite: 94Stand: 06.10.2017Kapitel: Userparameterdaten (UPD)
Abschnitt: Kontoinformation
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ElementBelegungsvorschriften und Festlegungen
BalStatAcctSaldo in der Umsatzliste aktuell
Dieses Element darf nur belegt werden, wenn sich in Invento- ry entsprechende Geschäftsvorfälle für Umsatzabfragen befin- den (vgl. Kapitel F.3.1).
Mit diesem Element wird darüber informiert, ob der gebuchte Saldo bzw. der Saldo der vorgemerkten Umsätze dem aktuellen Saldo entspricht. Dies wird durch die Existenz dieses JSON- Elements in der UPD-Erweiterung, kontobezogen ausge- drückt.
Erforderliche Reaktion des Kundenprodukts:
Wird der gelieferte Saldo der bereitgestellten Umsätze als aktu- ell gekennzeichnet, sollte das Kundenprodukt keine separate Abfrage zum Erhalt des aktuellen Saldo bzw. des Saldo der vor- gemerkten Umsätze einreichen.
AcctStatNextDatum und Uhrzeit der nächsten Umsatzbereitstellung
Dieses Objekt darf nur belegt werden, wenn sich in Inventory entsprechende Geschäftsvorfälle für Umsatzabfragen befinden (vgl. Kapitel F.3.1).
Das Kreditinstitut stellt den Zeitpunkt der nächsten Umsatzbe- reitstellung zur Verfügung.
Erforderliche Reaktion des Kundenprodukts:
Stellt das Kreditinstitut den Zeitpunkt der nächsten Umsatzbe- reitstellung zur Verfügung, sollte das Kundenprodukt vor diesem Zeitpunkt keine weiteren Umsatzabfragen durchführen.
InventoryFür den Benutzer angelegte Bestände
Für jeden für den Benutzer unterstützten Bestand wird vom Kre- ditinstitut die entsprechende Segmentkennung des Abholauf- trags und ggf. die zugehörige ID geliefert.
Diese Segmentkennungen müssen in der BPD und in den UPD unter Erlaubte Geschäftsvorfälle enthalten sein.
Es lassen sich folgende Zustände unterscheiden;
in UPD
Seg- ID
ID
Bedeutung
[Z1]NNNFür diesen GV ist der Benutzer nicht berechtigt.
[Z2]JNNFür diesen GV bietet das Institut keine Information zur Aktualität des Bestandes an.
[Z3]JJNFür diesen GV bietet das Institut ein Information über die Aktualität des Bestands, aber der Benutzer hat keinen Bestand.
[Z4]JJJFür diesen GV bietet das Institut
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: E
Dokument:Formals
Kapitel: Abschnitt:Userparameterdaten (UPD) KontoinformationStand: 06.10.2017Seite: 95
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
ElementBelegungsvorschriften und Festlegungen
[Z1]
[Z2]
[Z3]
[Z4]
Erforderliche Reaktion
Es sollte kein
Es kann ein
Es sollte kein
Ein Bestandsabruf
wenn die ID
Bestands		eine Information über die Aktuali- tät des Bestands, der Benutzer führt einen solchen Bestand, die ID kennzeichnet die Aktualität des Bestandes.
des Kundenprodukts:
Bestandsabruf durchgeführt werden.
Bestandsabruf durchgeführt werden.
Bestandsabruf durchgeführt werden.
sollte nur durchgeführt werden,
sich von der ID des lokal gespeicherten
unterscheidet.
Inventory (SegID)Segmentkennung des Abholauftrags
Für jeden für den Benutzer angelegten Bestand wird die Seg- mentkennung des zugehörigen Abholauftrags eingestellt.
Gültig sind folgende Segmentkennungen:
HKKAZ: Umsatzbestand (MT940), impliziert HKKAN
HKCAZ: Umsatzbestand (camt), impliziert HKCAN
HKKIF: Bestand Kontoinformationen
ΗΚΕΚΑ: Bestand elektronischer Kontoauszüge ( MT940,PDF )
HKECA:
Bestand elektronischer Kontoauszüge (camt)
ΗΚΕΚP:
Bestand elektronischer Kontoauszüge (PDF)
HKFGB:
Bestand Festgeld
HKWPD:
Bestand Depotaufstellung
HKWDU:
Bestand Depotumsätze
HKFRD:
Bestand Freistellungsdaten
HKFDL:
Bestand Finanzdatenformate
HKPPE:
Bestand Daueraufträge Prepaid-Laden
HKPOF:
Bestand Postfachnachrichten
HKCSB:
Bestand terminierter SEPA-Einzelüberweisungen
HKCMB:
Bestand terminierter SEPA-Sammelüberw.
HKCDB:
Bestand SEPA-Daueraufträge
HKCVB:
Bestand vorbereiteter SEPA-Überweisungen
HKDSB:
Bestand rückgabefähiger SEPA-Lastschriften
Kapitel: EVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
96		Stand: 06.10.2017Kapitel: Userparameterdaten (UPD)
Abschnitt: Kontoinformation
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
ElementBelegungsvorschriften und Festlegungen
HKDBS:
Bestand SEPA-Einzellastschriften (CORE/COR1)
HKDMB:
Bestand terminierter SEPA-Sammellastschriften
HKBBS:
Bestand SEPA-Firmeneinzellastschriften (B2B)
HKBMB:
Bestand term. SEPA-Firmensammellastschriften
HKDDB:
Bestand SEPA-Dauerlastschriften
HKCUB:
Bestand Empfängerkonten für SEPA-Übertrag
HKSSR:
SEPA-Statusreport
HKTAB:
TAN-Medien anzeigen
Belegung: Gültige FinTS Segmentkennungen für Benutzernach- richten.
Inventory[1] (ID)ID für die jeweilige Bestandsart pro Segmentkennung
Vom Kreditinstitut wird optional eine maximal 30-stellige ID des letzten Bestandsabrufs geliefert.
Format: analog FinTS-Format ID.
Erforderliche Reaktion des Kundenprodukts:
Lokal gespeicherte Bestände sollten mit einem entsprechenden ID-Element versehen werden. Bei lokalem Vorhandensein eines Umsatzes mit identischer ID sollte kein erneuter Bestandsabruf erfolgen.
BICBIC
Das Kreditinstitut teilt in diesem Element den BIC zu dem ge- wählten Konto mit. Dadurch kann in vielen Fällen die Verwen- dung des HKSPA - SEPA Kontoverbindung anfordern obsolet werden. Handelt es sich bei dem betroffenen Konto um ein SEPA-fähiges Konto, soll das Element BIC möglichst vom Institut belegt werden. Sollte aus anderen Gründen HKSPA ver- wendet werden, so hat der dort übermittelte BIC Vorrang.
SEPAFmtFormat des SEPA-Namens
Durch dieses Element wird gesteuert, ob das Element SEPA- Name base64-kodiert ist oder nicht:
0: SEPAName wird im FinTS-Zeichensatz, maximal 70-stellig eingestellt
1: SEPAName wird im UTF-8-Zeichensatz, base64-kodiert mit maximal 100 Zeichen eingestellt.
SEPANameSEPA-konformer Name des Kontoinhabers
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: E
Dokument:Formals
Kapitel: Abschnitt:Userparameterdaten (UPD) KontoinformationStand: 06.10.2017Seite: 97
+ + + + + + + + + + + + + + + +
ElementBelegungsvorschriften und Festlegungen
Im Rahmen der Umsetzung zur Geldtransferverordnung (GTVO) muss zukünftig ein SEPA-konformer, bis zu 70-stelliger Name (Länge ggf. vor der base64-Kodierung) des Kontoinhabers ba- sierend auf dem KWG24c-Namen verwendet werden. Lt. Artikel 4 ff. der Verordnung (EG) Nr. 1781/2006 (GTVO) gehört es zur Pflicht des Zahlungsdienstleisters des Auftraggebers sicherzu- stellen, dass die vollständigen Informationen über den Auftrag- geber weitergeleitet werden. Auftraggeber ist ausschließlich der Kontoinhaber. Das Format des SEPA-Namens wird durch das Element SEPAFmt festgelegt. Bei SEPA-fähigen Konten sollte das Institut den SEPA-Namen möglichst mitliefern. Sendet ein Kreditinstitut für ein Konto das Element SEPAName, so muss der hier übermittelte SEPA-Name im Sinn der o. g. Verordnung vom Kundenprodukt verwendet werden.
umsltztTimestamp des letzten Umsatzabrufs (nur bei ,,Version 00.00")
Vom Kreditinstitut wird der Timestamp des letzten Umsatzabrufs im Format ,,yyyy-mm-tt-hh.mm.ss.mmmmmm" geliefert.
Erforderliche Reaktion des Kundenprodukts:
Lokal gespeicherte Umsätze sollten mit einem entsprechenden Timestamp (hier: Spezialfall der ID) versehen werden. Bei loka- lem Vorhandensein eines Umsatzes mit identischem Timestamp darf kein erneuter Umsatzabruf erfolgen.
+ + +## E.3.1.2 Beispiel für die Verwendung der UPD-Erweiterung zur Bestandsoptimierung + +Das folgende Beispiel soll die Verwendung der Elemente Inventory, SegID und +ID zeigen. + +Alle im Beispiel genannten Geschäftsvorfälle befinden sich in den BPD. + +In den UPD finden sich unter Erlaubte Geschäftsvorfälle die Segmentken- +nungen HKKAZ, HKCAZ, HKKIF, HKEKA, HKECA, HKCSB und HKCDB. + +Beispiel für den fachlichen Inhalt von Inventory: + +SegID + +ID + +HKKAZ + +2015-11-24-15.06.38.2539850000 + +HKCAZ + +2015-11-24-15.06.38.2539850000 + +HKEKA + +HKECA + +HKCDB + +MBLTJ4bAa5kCLCglcFGuWdVZoPKuBE + +Bedeutung analog der Definition der Zustände: + +[Z2] der in den UPD des Benutzers gelistete Geschäftsvorfall HKCSB ist in der + + + + + + + + + + + + + + + +
Kapitel: EVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
98		Stand: 06.10.2017Kapitel: Userparameterdaten (UPD)
Abschnitt: Kontoinformation
+ + +UPD-Erweiterung, kontobezogen nicht gelistet. Für diesen GV bietet das +Kreditinstitut keine Information zur Aktualität des Bestands an. +Es kann ein Bestandsabruf durchgeführt werden. + +[Z3] Der Benutzer besitzt keine Bestände für die Abholaufträge HKEKA und +HKECA. Für diese Bestände sollten keine Abholaufträge gesendet werden. + +[Z4] Für die Abholaufträge HKKAZ, HKCAZ und HKCDB sind aktuelle IDs vorhan- +den. Bestände sollten nur abgerufen werden, wenn die IDs sich von den lokal ge- +speicherten IDs unterscheiden. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: F
Dokument:Formals
Kapitel:
Abschnitt:		FinTS Prozesse Buchstabe AStand: 06.10.2017Seite: 99
+ + +# F. FINTS PROZESSE + +FinTS ist als offene Schnittstelle zwischen Benutzer und Kreditinstitut konzipiert und +spezifiziert Schnittstellenprotokoll, Daten und Sicherheitsverfahren. Dem Gedanken +der offenen Schnittstelle widerspricht allerdings, dass jede von einem Kundenpro- +dukt ausgelöste FinTS-Nachricht beim empfangenden Rechenzentrum Kosten ver- +ursacht, die durch das Kreditinstitut zu tragen sind. Viele dieser Kosten sind jedoch +vermeidbar, da z. B. immer auf gleiche Datenbestände zugegriffen wird, die sich +zwischen den Abrufen nicht geändert haben oder Bestände abgefragt werden, über +die der Benutzer gar nicht verfügt. + +Daher enthält dieses Kapitel idealtypische Abläufe und Rahmenbedingungen, die +von Kreditinstituten und Kundenprodukten teils verpflichtend einzuhalten oder als +Empfehlung anzusehen sind. Aufgrund der Dringlichkeit des Themas und der Ver- +meidung unnötiger Kosten sind die im Folgenden dargestellten Prozesse mit Veröf- +fentlichung auch als verbindlich anzusehen. + +Bei der Beschreibung der Prozesse werden folgende Abstufungen und Begrifflich- +keiten verwendet: + +Verpflichtung + +Das beschriebene Verhalten ist zwingend vorgeschrieben. Bei +Nicht-Einhaltung der Vorgabe ist die Gegenseite berechtigt, die +Kommunikation mit einer entsprechenden Fehlermeldung zu +beenden, auch wenn die eingereichten Nachrichten / Segmente +syntaktisch fehlerfrei sind. + +In der Beschreibung werden die Begriffe MUSS, IST ZU bzw. +DARF NICHT verwendet. + +Empfehlung + +Das Verhalten hat Empfehlungscharakter, sollte aber nach Mög- +lichkeit eingehalten werden. Eine Ablehnung einer Kommunika- +tion bei Verstoß gegen diese Empfehlung findet jedoch nicht +statt. + +In der Beschreibung werden die Begriffe SOLL / SOLLTE bzw. +SOLL / SOLLTE NICHT verwendet. + +Option +Das Verhalten ist wahlfrei einzusetzen. Eine Verpflichtung für +die Unterstützung des Prozesses besteht nicht. Falls der Ablauf +jedoch unterstützt wird, dann genau in der beschriebenen Form. +Eine Ablehnung der Kommunikation findet nicht bzw. nur bei +Abweichen von dem beschriebenen Verhalten statt. + +In der Beschreibung werden die Begriffe KANN bzw. MUSS +NICHT verwendet. + + +## F.1 Versionsverwaltung + +Soweit diese Abläufe in Zusammenhang mit den Vorgaben aus einer neuen Version +der UPD-Erweiterung, kontobezogen (vgl. Kapitel E.3.1) stehen, werden die +jeweiligen Übergangsfristen durch die Deutsche Kreditwirtschaft frühzeitig bekannt- +gegeben. + + + + + + + + + + + + + + + +
Kapitel: FVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
100		Stand: 06.10.2017Kapitel: FinTS Prozesse
Abschnitt: Buchstabe A
+ + +Gleiches gilt für die Abkündigung von Versionen der UPD-Erweiterung, kon- +tobezogen. Als Ziel wird verfolgt, jeweils zwei aktive Versionen gleichzeitig zu un- +terstützen. + +Diese Mechanismen zum gezielten Bestandsabruf gelten im Allgemeinen nur für die +FinTS-Kommunikation, nicht für den Abruf über andere Vertriebskanäle wie z. B. +EBICS. + + +## F.2 Generelle Festlegungen + +Dieser Abschnitt enthält generelle Prozessfestlegungen zum Umgang mit dem +FinTS-Protokoll, die unabhängig von den nachfolgenden Einzelprozessen eingehal- +ten werden sollten, dort jedoch nicht verfeinert werden: + +Generelle Festlegungen für die Institutsseite + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.Festlegung
[IF1]Das Datenelement Erweiterung, kontobezogen soll vom Institut be- legt werden.
[IF2]Es können die JSON-Struktur der ,,Version 00.00" oder ab Version 01.00 verwendet werden.
[IF3]Bietet ein Institut die Belegung des Elements UPD-Version an, so muss bei jeder Änderung eines UPD-Elementes und im Speziellen der UPD- Erweiterung inkl. der JSON-Struktur die UPD-Version hochgezählt und ei- ne neue UPD bereitgestellt werden. Gleiches gilt bei der Verwendung von UPD-Version=0.
![](figures/108.1)
Ein Kundenprodukt muss bei einem wrap around den Sprung von UPD-Version=999 auf UPD-Version=1 korrekt verarbeiten können.
[IF4]Es darf immer nur eine JSON-Struktur in das Datenelement Erweite- rung, kontobezogen eingestellt werden.
[IF4]Jede Segmentkennung und die zugehörige optionale ID darf in einer JSON-Struktur nur einmal auftreten.
[IF5]Es dürfen nur in der vorliegenden Spezifikation veröffentlichte Versionen verwendet werden. Im Rahmen der FinTS Formals wird auch festgelegt, welche Versionen zugelassen sind. Im Maximum sollen zwei Versionen parallel unterstützt werden. Dies wird über die Versionsverwaltung gere- gelt.
[IF6]Verbands- oder institutsspezifische Versionen und Belegungen sind nicht vorgesehen.
[IF7]Optionale JSON-Elemente können weggelassen werden.
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: F
Dokument:Formals
Kapitel:
Abschnitt:		FinTS Prozesse Buchstabe AStand: 06.10.2017Seite: 101
+ + +### Generelle Festlegungen für die Kundenseite + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.Festlegung
[KF1]Ein vom Kreditinstitut belegtes Erweiterung, kontobezogen soll in- terpretiert und entsprechend den Vorgaben und Prozessen in Abschnitt F verarbeitet werden.
[KF2]Ein Kundenprodukt soll aktuell die JSON-Struktur der ,,Version 00.00" so- wie die im Rahmen der FinTS Formals spezifizierten JSON-Strukturen der Version 01.00 korrekt verarbeiten können.
[KF3]Auch wenn einzelne JSON-Elemente vom Institut nicht bereitgestellt wer- den, müssen die vorhandenen Elemente korrekt verarbeitet werden. Wird bei der Interpretation der UPD-Erweiterung ein Syntaxfehler festgestellt, wird der Inhalt der gesamten UPD-Erweiterung ignoriert.
[KF4]Ein Kundenprodukt sollte nur durch den Benutzer manuell initiierte FinTS-Dialoge durchführen. Es kann Möglichkeiten zum zeitgesteuerten Abruf von Informationen anbieten, jedoch sollten Zeitintervalle so gewählt werden, dass die Anzahl der Anfragen auf ein Minimum reduziert ist.
[KF5]Ein Kundenprodukt darf Abholaufträge und Bestandsabfragen nur einrei- chen, wenn dies ausdrücklich mit dem Benutzer vereinbart ist. Hierzu gehören auch mit dem Benutzer vereinbarte zeitlich automatisierte Abru- fe. Die Zeitintervalle sollten in Abstimmung mit dem Kunden so gewählt werden, dass die Anzahl der Anfragen auf ein Minimum reduziert ist.
[KF6]Ein Kundenprodukt muss wo immer möglich für den Einsatzzweck opti- male Abfragetechniken nutzen und darf generalisierte Abholaufträge nur einreichen, wenn dies vom Nutzer ausdrücklich gewünscht ist. Ausge- nommen hiervon sind technisch bedingte Abrufe z. B. bei Timeouts.
[KF7]Ein Kundenprodukt soll keine separaten Abfragen des aktuellen Saldo durchführen, wenn der aktuelle Saldo bereits in den Umsätzen enthalten ist.
[KF8]Die Aussagen beziehen sich jeweils nur auf eine spezifische Installation eines Kundenproduktes. Betreibt ein Benutzer mehrere Installationen mit getrennter Bestandshaltung, so gelten die Festlegungen pro Bestands- haltung.
[KF9]Führt ein Kundenprodukt keine lokalen Bestände, so gelten nur die Fest- legungen [KF4] bis [KF7].
[KF10]Bei technischen Problemen wie z. B. Timeouts können Bestände auch ohne Berücksichtigung der Angaben in der UPD-Erweiterung, kon- tobezogen abgeholt werden.
+ + +## F.3 Spezielle Prozesse + +Die folgenden speziellen Prozesse verfeinern die in den generellen Prozessfestle- +gungen definierten Regeln anhand der Informationen, die über das Datenelement +,,Erweiterung, kontobezogen" vom Kreditinstitut geliefert werden. + + + + + + + + + + + + + + + +
Kapitel: FVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
102		Stand: 06.10.2017Kapitel: FinTS Prozesse
Abschnitt: Buchstabe A
+ + +### F.3.1 Abruf von Umsätzen + +Umsatzabrufe dienen dazu, dem Kundenprodukt aktuell und lückenlos alle Konto- +bewegungen mitzuteilen. Im Idealfall sollte jeder Umsatz pro Kundenprodukt nur +einmal abgerufen und dann lokal im Kundenprodukt gespeichert werden (falls das +Kundenprodukt eine Speicherung zulässt). + +Zum Umsatzabruf werden folgende Geschäftsvorfälle verwendet: + +HKKAZ: Kontoumsätze/Zeitraum (MT940) + +HKKAN: Kontoumsätze/Neue Umsätze (MT940) + +HKCAZ: Kontoumsätze/Zeitraum (camt) + +HKCAN: Kontoumsätze/Neue Umsätze (camt) + +Ein Kundenprodukt muss die folgenden Informationen aus dem Datenelement „Er- +weiterung, kontobezogen“ berücksichtigen: + +Version 00.00: umsltzt + +Version 01:00: BalStatAct, AcctStatNext, Inventory + +Basierend auf diesen Informationen muss ein Kundenprodukt folgendermaßen rea- +gieren: + + + + + + + + + + + +
umsltzt, InventoryWenn der Benutzer eine Umsatzabfrage initiiert muss in der Dialoginitialisierungsantwort die übermittelte ID mit der des letzten lokal gespeicherten Umsatzes ver- glichen werden. Bei Gleichheit darf das Kundenprodukt keine Umsatzabfrage starten, sondern muss den Be- nutzer in geeigneter Weise informieren, dass keine neuen Umsätze vorliegen.
AcctStatNextHat ein Kundenprodukt beim vorherigen Abruf den Zeitpunkt der nächsten Umsatzbereitstellung erhalten, darf es vor diesem Zeitpunkt keinen Dialog zum Zweck der Umsatzabfrage aufbauen und innerhalb eines Dia- loges, z. B. um eine Überweisung einzureichen, auch keinen Umsatzabruf starten.
+ + +### F.3.2 Abruf von Salden + +Saldenabrufe sollten in zwei Situationen verwendet werden: + +(a) Abfragen eines aktuellen Saldo ohne Umsatzabruf, wenn das Kreditinstitut aktu- +elle Saldeninformationen anbietet + +(b) Abfragen von Zusatzinformationen wie z. B. dem verfügbaren Betrag, wenn das +Institut die Saldeninformationen nicht in der UPD-Erweiterung, kontobezo- +gen im Element AcctBal komplett liefert. Dies wird durch das Institut auch +durch das Flag BalComplete gekennzeichnet. + +Zum Saldenabruf wird folgender Geschäftsvorfall verwendet: + +HKSAL: Saldenabfrage + +Ein Kundenprodukt soll die folgende Information aus dem Datenelement ,Erweite- +rung, kontobezogen“ berücksichtigen: + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: F
Dokument:Formals
Kapitel:
Abschnitt:		FinTS Prozesse Buchstabe AStand: 06.10.2017Seite: 103
+ + +Version 01:00: BalStatAct + +Basierend auf dieser Information muss ein Kundenprodukt folgendermaßen reagie- +ren: + + + + + + + +
BalStatActWird über dieses Element mitgeteilt, dass der aktuelle Saldo in den übermittelten Umsätzen dem gebuchten Saldo bzw. dem Saldo der vorgemerkten Umsätze ent- spricht, darf das Kundenprodukt keine separate Sal- denabfrage einreichen, um den aktuellen Saldo noch- mals zu erhalten. Ausnahme: die Saldenabfrage wird benötigt, um andere der in HKSAL definierten Werte zu ermitteln, die nicht in AcctBal der UPD-Erweiterung geliefert werden.
+ + +### F.3.3 Abruf von Beständen + +Bestandsabrufe sollten nur beim erstmaligen Einrichten eines Kundenprodukts, bei +Änderungen in den Beständen oder auf expliziten Wunsch eines Benutzers durch- +geführt werden. + +Die einzelnen Bestände sind mit Ihren Segmentkennungen im Element Inventory +definiert. + +Ein Kundenprodukt soll die folgende Information aus dem Datenelement Erweite- +rung, kontobezogen berücksichtigen: + +Version 01:00: Inventory + +Basierend auf dieser Information muss ein Kundenprodukt folgendermaßen reagie- +ren: + + + + + + + +
InventoryEin Kreditinstitut kann hiermit eine Liste der vorhande- nen Bestände eines Benutzers an das Kundenprodukt melden.
Ein Kundenprodukt darf nur Bestandsgeschäftsvorfälle einreichen, für die auch aktive Bestände gemeldet sind.
Ausnahmen: es soll z. B. die Änderung oder Löschung in einem Bestand durchgeführt werden; dann ist die Abholung des aktuellen Bestands durch die Spezifikati- on als obligatorisch festgelegt. Gleiches gilt auch bei technischen Problemen wie z. B. Timeouts.
+ + +## F.3.4 Abruf von SEPA-Kontoverbindungsdaten + +Der Abruf von SEPA-Kontoverbindungen wird benötigt, um IBAN und BIC zu einer +nationalen Kontoverbindung zu erhalten. Mit HIUPD#6 kann die IBAN zu einer Kon- +toverbindung einfacher mitgeteilt werden. Da der BIC der Auftraggeber- +Kontoverbindung in der UPD-Erweiterung, kontobezogen verpflichtend enthal- +ten ist, wird der Geschäftsvorfall SEPA-Kontoverbindung anfordern (HKSPA) +für die Abfrage nicht mehr benötigt. + +In diesem Fall sollte ein Kreditinstitut den HKSPA aus der Liste der erlaubten Ge- +schäftsvorfälle in den UPD des Benutzers entfernen. + + + + + + + + + + + + + + + +
Kapitel: FVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
104		Stand: 06.10.2017Kapitel: FinTS Prozesse
Abschnitt:
Buchstabe A
+ + +Das Parametersegment HISPAS kann jedoch in den BPD erhalten bleiben, um z. B. +die zugelassenen pain messages beschreiben zu können. + +Ein Kundenprodukt muss den BIC aus der UPD-Erweiterung entsprechend berück- +sichtigen. Weitere Vorgaben bestehen nicht, da der HKSPA ohne Eintrag in den UPD +ohnehin nicht mehr eingereicht werden darf. + + +## F.3.5 Anzeige der verfügbaren TAN-Medien + +Ein Abruf der TAN-Medien erfolgt, um die benötigten Parameter zur Unterstützung +eines Sicherheitsverfahrens zu erhalten. + +Zum Abruf der TAN-Medien wird folgender Geschäftsvorfall verwendet: + +Anzeige der verfügbaren TAN-Medien (HKTAB) + +Ein Kundenprodukt sollte bei einem generellen Bestandsabruf das Datenelement +„TAN-Medium-Klasse“ mit A = Alle Medien belegen, um nicht unnötigerweise +mehrere HKTAB-Geschäftsvorfälle einreichen zu müssen. + +HKTAB ist auch in der Bestandsverwaltung Inventory enthalten, so dass ein Kun- +denprodukt ggf. informiert wird, falls die TAN-Medien sich ändern. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: F
Dokument:Formals
Kapitel:
Abschnitt:		Buchstabe A
Data Dictionary		Stand:
06.10.2017		Seite: 105
+ + +# G. DATA DICTIONARY + +A + + +## Anzahl benötigter Signaturen + +Anzahl der Signaturen, die zur Ausführung eines Geschäftsvorfalls als erfor- +derlich definiert ist. + +Falls 0 angegeben ist, handelt es sich um einen nicht signierungspflichtigen +Geschäftsvorfall, der auch über einen anonymen Zugang ohne Signierungs- +möglichkeit ausgeführt werden kann. + +Falls die Anzahl der benötigten Signaturen größer als 1 ist, bedeutet dies, +dass dieser Geschäftsvorfall zusätzlich von mindestens einem anderen be- +rechtigten Benutzer signiert werden muss, über dessen Identität in den UPD +jedoch nichts ausgesagt wird. + +In bestimmten Fällen ist die Anzahl der Signaturen durch die Art des Ge- +schäftsvorfalls vorgegeben (z. B. sind bei Keymanagement-Aufträgen nicht +mehrere Signaturen möglich). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..2
Version:1
+ + +## Anzahl Geschäftsvorfallsarten + +Maximale Anzahl an Geschäftsvorfallsarten, die pro Nachricht zulässig ist. + +Der Wert ,0' gibt an, dass keine Restriktionen bzgl. der Anzahl an Ge- +schäftsvorfallsarten bestehen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..3
Version:1
+ + +## Anzahl Signaturen mindestens + +Mindestanzahl der Signaturen, die für einen Geschäftsvorfall als erforderlich +definiert ist. + +Vom Kreditinstitut wird immer die Minimalanforderung an einen Geschäfts- +vorfall mitgeteilt, d. h. '0', wenn der Geschäftsvorfall auch über den anony- +men Zugang angeboten wird, ansonsten mindestens '1', da Aufträge von +Kunden immer signiert werden müssen. + +Die für Kunden jeweils genaue Angabe der Signaturanzahl ergibt sich in den +UPD aus dem DE ,,Anzahl benötigter Signaturen“. Dabei muss die in den +UPD angegebene Signaturanzahl größer oder gleich der in den BPD ange- +gebene Anzahl sein. Für Institute, die keine UPD unterstützen, bedeutet +dies, dass der Eintrag '0' in den BPD nur für Nichtkunden gilt und für Kunden +als 'mindestens 1' zu interpretieren ist. + +Der Wert gilt für alle Signaturverfahren. + + + + + + + + + + + + + + + +
Kapitel: FVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
106		Stand:
06.10.2017		Kapitel: Data Dictionary
Abschnitt: Buchstabe B
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:1
Version:1
+ + +## Aufsetzpunkt + +Information darüber, wie die Beantwortung des Kundenauftrags an einem +bestimmten Punkt kontrolliert beendet und aufgesetzt werden kann, falls die +Rückmeldung des Kreditinstituts nicht in einem einzigen Auftragssegment er- +folgen kann (s. Kap. B.6.3). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:1
+ + +# B + + +## Benutzerkennung + +Eindeutig vergebene Kennung, anhand deren die Identifizierung des Benut- +zers erfolgt. Die Vergabe obliegt dem Kreditinstitut. Das Kreditinstitut hat zu +gewährleisten, dass die Benutzerkennung institutsweit eindeutig ist. Sie kann +beliebige Informationen enthalten, darf aber bei Verwendung des RAH- oder +RDH-Verfahrens aus Sicherheitsgründen nicht aus benutzer- oder kreditinsti- +tutsspezifischen Merkmalen hergeleitet werden. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:id
Länge:#
Version:1
+ + +## Benutzername + +Name des Benutzers. Diese Information dient insbesondere dazu, den Be- +nutzer im Kundenprodukt mit seinem Namen persönlich ansprechen zu kön- +nen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:1
+ + +## Betreff + +Thema einer Textnachricht (Betreffzeile). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: F
Dokument:Formals
Kapitel: Abschnitt:Data Dictionary Buchstabe BStand: 06.10.2017Seite: 107
+ + +### Bezugsdatenelement + +Die Position des Datenelements bzw. Gruppendatenelements, auf das sich +der Rückmeldungscode bezieht (z. B. die Position des fehlerhaften Elemen- +tes bei Syntaxfehlern). + +Bei Rückmeldecodes, die sich auf eine Nachricht oder ein Segment (Auftrag) +beziehen, darf dieses DE nicht belegt werden. + + +![](figures/115.1) + + +Die Angabe des Bezugsdatenelements erlaubt u.U. eine au- +tomatische Reaktion des Kundenproduktes. So kann bspw. +bei fehlerhaften Eingaben des Kunden direkt auf das betref- +fende Eingabefeld positioniert werden. + + +#### Die Referenzierung erfolgt + +• bei DE durch die Position + +· bei GD durch die Position der DEG und die Position des GD (die beiden +Werte sind durch Komma getrennt) + + +#### Position des DE: + +Position des DE = Anzahl der vorstehenden DE-Trennzeichen + 1. + +Die Anzahl der vorstehenden DE-Trennzeichen ist gleich der Anzahl der vor- +stehenden DE + Anzahl der vorstehenden DEGs (GD sind nicht separat zu +zählen, sondern gehen in die DEGs ein). Entwertete Pluszeichen sind nicht +zu zählen. + + +##### Position des GD innerhalb einer DEG: + +Position des GD = Anzahl der vorstehenden GD-Trennzeichen innerhalb der +DEG + 1 + + +##### Beispiele: + +Segmentkopf+DE+GD:GD:GD:GD+DE+GD:GD' : 4 + +Segmentkopf+DE+GD:GD:GD:GD+DE+GD:GD' : 3,4 + +Segmentkopf+DE+GD:GD:GD:GD+DE+GD:GD' : 5,2 + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..7
Version:1
+ + +## Bezugsnachricht + +Eindeutige Referenz für Kundennachrichten. Die eindeutige Referenzierung +erfolgt anhand der Dialog-ID und der Nachrichtennummer der Kundennach- +richt. Falls auf eine Dialoginitialisierungsnachricht des Kunden referenziert +werden soll, ist nicht die vom Kunden übermittelte Dialog-ID (0), sondern die +vom Kreditinstitut neu vergebene Dialog-ID einzustellen. + + + + + + + + + + + + + + + +
Kapitel: FVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
108		Stand: 06.10.2017Kapitel: Data Dictionary
Abschnitt: Buchstabe B
+ + +Es darf nur auf Nachrichten des dialogführenden Benutzers referenziert wer- +den. Eine explizite Angabe der Benutzerkennung als Referenzierungskriteri- +um ist nicht erforderlich, da diese bereits im Signaturkopf spezifiziert wurde. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Dialog-ID1DEid#M1
2Nachrichten- nummer1DEnum..4M1>0
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +# Bezugssegment + +Sofern sich ein Kreditinstitutssegment auf ein bestimmtes Kundensegment +bezieht (z. B. Antwortrückmeldung auf einen Kundenauftrag) hat das Kredit- +institut die Segmentnummer des Segments der Kundennachricht einzustel- +len, auf das sich das aktuelle Segment bezieht (s. DE ,,Segmentnummer“). In +Zusammenhang mit den Angaben zur Bezugsnachricht aus dem Nachrich- +tenkopf ist hierdurch eine eindeutige Referenz auf das Segment einer Kun- +dennachricht möglich. + +Falls die Angabe eines Bezugssegments erforderlich ist, ist dieses bei der +Formatbeschreibung eines Kreditinstitutsegments angegeben. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..3
Version:1
+ + +# Bis Datum + +Endedatum eines Zeitraums. + +Durch die Eingabe von Von- und Bis-Datum kann ein Zeitraum eingegrenzt +werden, für den Informationseinträge vom Kreditinstitut rückzumelden sind. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dat
Länge:#
Version:1
+ + +## Bis Kreditinstitutskennung + +Ende eines Bereichs von Kreditinstitutskennungen (s. auch „Von Kreditinsti- +tutskennung“) + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: F
Dokument:Formals
Kapitel:
Abschnitt:		Data Dictionary Buchstabe DStand: 06.10.2017Seite: 109
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:kik
Länge:#
Version:2
+ + +### BPD-Version + +Es handelt sich um eine kreditinstitutsseitig vergebene Versionsnummer der +Bankparameterdaten (BPD), die den jeweiligen Stand der instituts- +spezifischen Unterstützung des Systems kennzeichnet (bei jeder für das +Kundensystem relevanten Änderung des Kreditinstitutssystems werden neue +BPD mit einer neuen BPD-Versionsnummer kreditinstitutsseitig bereitge- +stellt). + +Diese BPD-Versionsnummer ist unabhängig von der Version des BPD- +Nachrichtenformats, die im Nachrichtenkopf eingestellt ist und lediglich das +syntaktische Format der Nachricht, nicht jedoch deren Inhalt kennzeichnet. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..3
Version:1
+ + +D + + +# Datum + +Datumsangabe, zur Bestimmung eines Zeitpunktes. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dat
Länge:#
Version:1
+ + +# Dialog-ID + +Die Dialog-ID dient der eindeutigen Zuordnung einer Nachricht zu einem +FinTS-Dialog. Die erste Kundennachricht (Dialoginitialisierung) enthält als Di- +alog-ID den Wert 0. In der ersten Antwortnachricht wird vom Kreditinstitut ei- +ne Dialog-ID vorgegeben, die für alle nachfolgenden Nachrichten dieses Dia- +logs einzustellen ist. Es ist Aufgabe des Kreditinstituts, dafür zu sorgen, dass +diese Dialog-ID dialogübergreifend und systemweit eindeutig ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:id
Länge:#
Version:1
+ + +# Dialogsprache + +Über dieses DE spezifiziert der Kunde die Sprache, in der er im laufenden +Dialog mit dem Kreditinstitut kommunizieren möchte. Rückmeldungen und +Kreditinstitutsmeldungen werden (soweit kreditinstitutsseitig unterstützt) in +der zuvor spezifizierten Sprache an den Kunden übermittelt. Damit ver- +bunden wird ein zugehöriger FinTS-Basiszeichensatz (s. Kap. B.1), der sich +durch einen ISO 8859-Codeset und einen ISO 8859-Subset definiert, aus- +gewählt. Die Definition des Subsets ist den Anlagen (Kap. I.3) zu entneh- + + + + + + + + + + + + + + + +
Kapitel: FVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
110		Stand: 06.10.2017Kapitel: Data Dictionary
Abschnitt:
Buchstabe E
+ + +men. Der Codeset soll ermöglichen, zu einem späteren Zeitpunkt evtl. auch +nicht-lateinische Zeichensätze zuzulassen. + +Codierung: + +0: Standard + +1: Deutsch, Code ,de' (German), Subset Deutsch, Codeset 1 (Latin 1) + +2: Englisch, Code ,en' (English), Subset Englisch, Codeset 1 (Latin 1) + +3: Französisch, Code ,fr' (French), Subset Französisch, Codeset 1 (Latin 1) + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:..3
Version:2
+ + +E + + +## Erlaubte Geschäftsvorfälle + +Information darüber, ob der Kunde zur Ausführung des jeweiligen Ge- +schäftsvorfalls zugelassen ist und wie viele Signaturen hierzu mindestens er- +forderlich sind. Ferner können für jeden Geschäftsvorfall Einzelauftragslimite +angegeben werden, sofern dies bankfachlich möglich ist. Die Reihenfolge +der Geschäftsvorfälle ist unerheblich. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Geschäftsvorfall1DEan..6M1
2Anzahl benötig- ter Signaturen1DEnum..2M10, 1, 2, 3
3Limitart2DEcode1O1E, T, W, M, Z
4Limitbetrag1DEGbtg#C1O: Limitart <> „Z“ N: sonst
5Limit-Tage1DEnum..3C1>0
O: Limitart = ,,Z" N: sonst
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:2
+ + +### Erweiterung, allgemein + +Zwischen Kreditinstitut und Kunde bilateral vereinbarte Erweiterung der all- +gemeinen Userparameter. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: F
Dokument:Formals
Kapitel:
Abschnitt:		Buchstabe F
Data Dictionary		Stand: 06.10.2017Seite: 111
+ + +Typ: + +DE + + + + + + + + + + + + + + + +
Format:an
Länge:..2048
Version:1
+ + +## Erweiterung, kontobezogen + +Das Datenelement wurde ursprünglich als bilateral zwischen Kreditinstitut +und Kunde vereinbarte Erweiterung der kontobezogenen Userparameter +vorgesehen. Diese Verwendung ist mit Einführung der DK-weit einheitlichen +Festlegung nicht mehr zulässig. Es wird stattdessen auf eine definierte +Struktur verwiesen (vgl. Kapitel E.3.1ff). + +Für die Struktur wird je Version eine eigene JSON Schema-Datei definiert, +mit deren Hilfe automatisiert Wandlungen durchgeführt werden können. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..2048
Version:1
+ + +F + + +### Freitextmeldung + +Inhalt einer Freitextinformation + +Die maximale Länge der Freitextmeldung ist den BPD zu entnehmen. Mel- +dungen, deren Länge diesen Wert übersteigen, werden abgelehnt. Die Daten +dürfen nicht um führende oder nachfolgende Leerzeichen gekürzt werden. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:txt
Länge:.2048
Version:1
+ + +### Filterfunktion + +Falls das Übertragungsverfahren eine Umwandlung der Nachricht in eine +7 Bit-Zeichendarstellung erfordert (z. B. Internet), so ist hier das anzuwen- +dende Filterverfahren anzugeben. Die Nachricht ist stets komplett zu filtern, +auch wenn eine Filterung nicht notwendig wäre, da bspw. keine binären Da- +ten enthalten sind. Ein Kreditinstitut darf jeweils nur eine Filterfunktion unter- +stützen. + +Codierung: + +MIM: MIME Base 64 + +UUE: Uuencode/Uudecode + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:3
Version:1
+ + + + + + + + + + + + + + + + +
Kapitel: FVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
112		Stand:
06.10.2017		Kapitel: Data Dictionary
Abschnitt:
Buchstabe G
+ + +G + + +### Geschäftsvorfall + +Geschäftsvorfälle, für deren Ausführung der Benutzer berechtigt ist. Hierzu +gehören neben den Auftragssegmenten mit der Segmentart „Geschäftsvor- +fall" auch die Segmente der Key-Management-Nachrichten. Einzustellen ist +jeweils die Segmentkennung des Kundensegments. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..6
Version:1
+ + +H + + +### HBCI-Version + +Version der HBCI-/FinTS-Schnittstellenspezifikation, die der jeweiligen Rea- +lisierung zugrunde liegt. + +HBCI- bzw. FinTS-Versionen, die vor Version 2.0.1 veröffentlicht wurden, +werden kreditinstitutsseitig nicht unterstützt. + +Ein geregelter Dialog ist nur zwischen Systemen möglich, die mit derselben +HBCI-/FinTS-Version arbeiten. Stimmt die vom Kunden übermittelte HBCI- +/FinTS-Version nicht mit einer der vom Kreditinstitut in den BPD mitgeteilten +unterstützten HBCI-/FinTS-Versionen überein, so muss der Dialog vom Kre- +ditinstitut beendet werden. Innerhalb eines Dialoges dürfen nicht Nachrichten +unterschiedlicher HBCI-/FinTS-Versionen gesendet werden. + +Segment- und HBCI-/FinTS-Versionen werden unabhängig voneinander ge- +führt. Innerhalb eines HBCI-/FinTS-Dialoges dürfen nur Versionen administ- +rativer Segmente gesendet werden, die der angegebenen HBCI-/FinTS- +Version entsprechen. Im Rahmen einer HBCI-/FinTS-Version wird eine Liste +der zugehörigen Segmentversionen veröffentlicht (s. [Messages], Anlagen). +Weiterhin werden in dieser Liste auch die zusätzlich noch unterstützten Se- +gmentversionen genannt. + +Der Zeitpunkt der Unterstützung einer neuen HBCI-/FinTS-Version kann zwi- +schen den Kreditinstituten variieren. + +Zulässige Werte: + +Version 2.0.1 : 201 (Spezifikationsstatus: obsolet) + +Version 2.1 : 210 (Spezifikationsstatus: obsolet) + +Version 2.2 : 220 (Spezifikationsstatus: obsolet) + +Version 3.0 : 300 + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..3
Version:1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: F
Dokument:Formals
Kapitel:
Abschnitt:		Data Dictionary
Buchstabe I		Stand: 06.10.2017Seite: 113
+ + + + + +# IBAN + +IBAN + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..34
Version:1
+ + +K + + +## Kommunikationsadresse + +Beim Zugang über T-Online ist die Gateway-Seite als numerischer Wert (oh- +ne die Steuerzeichen * und #) einzustellen. + +Beim Zugang über TCP/IP ist die IP-Adresse als alphanumerischer Wert (z. +B. '123.123.123.123') einzustellen. + +Beim Zugang über https ist die Adresse des Servlets als alphanumerischer +Wert (z. B. [,,https://www.xyz.de:7000/Servlet"](https://www.xyz.de:7000/Servlet)) einzustellen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..512
Version:1
+ + +## Kommunikationsadressenzusatz + +Beim Zugang über T-Online ist der Regionalbereich einzustellen (,00' für ein +bundesweites Angebot). Beim Zugang über TCP/IP und https wird das Feld +nicht belegt. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..512
Version:1
+ + +## Kommunikationsdienst + +Unterstütztes Kommunikationsverfahren (Protokollstack). + +Zur Zeit unterstützte Kommunikationsverfahren: + +1: T-Online (mit FinTS V3.0 nicht mehr unterstützt) + +2: TCP/IP (Protokollstack SLIP/PPP) + +3: https1 (verwendet im Sicherheitsverfahren PIN/TAN) + + + + + + + + + + + + + + + + +
Kapitel: FVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
114		Stand: 06.10.2017Kapitel: Data Dictionary
Abschnitt: Buchstabe K
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:..2
Version:2
+ + +# Kommunikationsparameter + +Die Kommunikationsparameter enthalten Informationen für den Aufbau der +Transportverbindung. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Kommunikati- onsdienst2DEnum..2M11,2,3
2Kommunikati- onsadresse1DEan..512M1
3Kommunikati- onsadres- senzusatz1DEan..512C1M: ,Kommunikations- dienst = 1 N: sonst
4Filterfunktion1DEan3C1MIM, UUE M: ,Kommunikations- dienst = 2 N: sonst
5Version der Fil- terfunktion1DEnum..3C1O: ,Filterfunktion' belegt N: sonst
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:2
+ + +## Kontoart + +Klassifizierung der Konten. Innerhalb der vorgegebenen Codebereiche sind +kreditinstitutsindividuell bei Bedarf weitere Kontoarten möglich. + +Codierung: + +1 - 9: Kontokorrent-/Girokonto + +10 - 19: Sparkonto + +20-29: Festgeldkonto (Termineinlagen) + +30 - 39: Wertpapierdepot + +40 - 49: Kredit-/Darlehenskonto + +50 - 59: Kreditkartenkonto + +60 - 69: Fonds-Depot bei einer Kapitalanlagegesellschaft + +70 - 79: Bausparvertrag + +80 - 89: Versicherungsvertrag + +90 - 99: Sonstige (nicht zuordenbar) + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: F
Dokument:Formals
Kapitel:
Abschnitt:		Buchstabe K
Data Dictionary		Stand: 06.10.2017Seite: 115
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..2
Version:1
+ + +# Kontolimit + +Kontobezogenes Limit für Verfügungen am Konto. + +Die Angabe eines Kontolimits ist kreditinstitutsseitig optional, so dass für den +Kunden ein Limit bestehen kann, auch wenn dieses nicht in die UPD einge- +stellt wurde. Ein kontobezogenes Limit darf nicht gleichzeitig mit geschäfts- +vorfallbezogenen Limiten angegeben werden. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Limitart2DEcode1M1E, T, W, M, Z
2Limitbetrag1DEGbtg#C1O: Limitart <> ,Z" N: sonst
3Limit-Tage1DEnum..3C1>0
O: Limitart = ,,Z" N: sonst
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:2
+ + +# Kontoproduktbezeichnung + +Produktbezeichnung des Kontos. Diese Bezeichnung ist vom Kreditinstitut +frei wählbar. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..30
Version:1
+ + +# Kontoverbindung + +Deutsche oder internationale Kontoverbindung, die im Rahmen der Abwick- +lung eines Auftrags benötigt wird. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Formatkennung:ktv
Länge:#
Version:2
+ + +# Kontowährung + +Angabe der Währung, in der ein Konto geführt wird. Die Währung wird als +ISO-Währungscode angegeben. + +Bei Depotkonten kann auf die Angabe der Kontowährung verzichtet werden. + + + + + + + + + + + + + + + +
Kapitel: FVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
116		Stand:
06.10.2017		Kapitel: Data Dictionary
Abschnitt:
Buchstabe K
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:cur
Länge:#
Version:1
+ + +# Kreditinstitutsbezeichnung + +Bezeichnung des Kreditinstituts, die vom Kreditinstitut frei wählbar ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..60
Version:1
+ + +# Kreditinstitutskennung + +Kennung eines Kreditinstituts. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Formatkennungkik
Länge:#
Version:1
+ + +# Kunden-ID + +Institutsweit eindeutige Identifikation des Kunden. Die Vergabe obliegt dem +Kreditinstitut. Die Kunden-ID kann beliebige Informationen enthalten. Es +steht dem Kreditinstitut frei, ob es jedem Kunden genau eine Kunden-ID zu- +ordnet oder dem Kunden in Abhängigkeit vom Benutzer jeweils eine unter- +schiedliche Kunden-ID zuordnet. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:id
Länge:#
Version:1
+ + +# Kundensystem-ID + +Eindeutige Kennzeichnung des Kundensystems, die in Kombination mit der +Signatur-ID die Validität (Eindeutigkeit) der Signatur sichert. + +Die Kundensystem-ID ist nicht eindeutig für das Endgerät (PC), sondern für +die Anwendung auf einem Endgerät, d. h., wenn der Kunde auf einem End- +gerät mit mehreren Homebanking-Anwendungen arbeitet, muss für jede An- +wendung eine eigene Kundensystem-ID geführt werden. + +Die Kundensystem-ID ist beim HBCI RAH- / RDH- sowie dem PIN/TAN- +Verfahren erforderlich. Bei der Verwendung von RAH-/RDH-Chipkarten ab +Sicherheitsprofil-Version 3 wird anstatt der Kundensystem-ID die CID der +gesteckten Karte verwendet. Beim HBCI DDV-Verfahren und bei TAN- +Verfahren ist dieses DE mit dem Wert 0 zu belegen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:id
Länge:#
Version:1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: F
Dokument:Formals
Kapitel:
Abschnitt:		Data Dictionary Buchstabe LStand: 06.10.2017Seite: 117
+ + +# Kundensystem-Status + +Information darüber, ob die Kundensystem-ID erforderlich ist: + +Codierung: + +0: +Kundensystem-ID wird nicht benötigt (HBCI DDV-Verfahren und +chipkartenbasierte Verfahren ab Sicherheitsprofil-Version 3) + +1: +Kundensystem-ID wird benötigt (sonstige HBCI RAH- / +RDH- und PIN/TAN-Verfahren) + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:2
+ + +L + + +## Limitart + +Information über die Art des geschäftsvorfallbezogenen Limits. + +Ein geschäftsvorfallbezogenes Limit kann nur eingestellt werden, wenn nicht +gleichzeitig ein kontobezogenes Limit angegeben wurde. Die Angabe eines +Limits ist kreditinstitutsseitig optional. Daher kann für den Kunden ein Limit +bestehen, auch wenn dieses nicht in die UPD eingestellt wurde. + +Codierung: + +E: Einzelauftragslimit + +T: Tageslimit + +W: Wochenlimit + +M: Monatslimit + +Z: Zeitlimit + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:2
+ + +## Limitbetrag + +Betrag für Userlimit. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:btg
Länge:#
Version:1
+ + +## Limit-Tage + +Anzahl Tage für rollierendes Zeitlimit (Limitart 'Z'). + + + + + + + + + + + + + + + +
Kapitel: FVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
118		Stand:
06.10.2017		Kapitel: Data Dictionary
Abschnitt: Buchstabe M
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..3
Version:1
+ + +M + + +# Maximale Anzahl Aufträge + +Höchstens zulässige Anzahl an Segmenten der jeweiligen Auftragsart je +Kundennachricht. Übersteigt die Anzahl der vom Kunden übermittelten Seg- +mente pro Auftragsart die zugelassene Maximalanzahl, so wird die gesamte +Nachricht abgelehnt. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..3
Version:1
+ + +# Maximale Anzahl Einträge + +Maximale Anzahl rückzumeldender Einträge bei Abholaufträgen, Kreditinsti- +tutsangeboten oder -informationen (vgl. Kap. B.6.3). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..4
Version:1
+ + +# Maximale Nachrichtengröße + +Obergrenze in Kilobyte (=1024 Byte) für die Nachrichtengröße. Dies kann +kreditinstitutsindividuell je nach technischen Restriktionen bzgl. der Verarbei- +tung umfangreicher Kundennachrichten vorgegeben werden. + +Der Wert ,0' gibt an, dass keine Restriktionen bzgl. der Nachrichtengröße +bestehen. + +Eingehende Nachrichten, die dekomprimiert und entschlüsselt diese Grenze +überschreiten, können dann abgelehnt werden. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..4
Version:1
+ + +# Maximaler Timeout-Wert + +Zeitraum, nach dem das Kreditinstitut einen Dialog voraussichtlich beenden +wird, sofern keine weiteren Kundennachrichten gesendet wurden. Die Anga- +be erfolgt in Sekunden. Liegt keine Begrenzung vor, kann der Wert ,0' ange- +geben werden. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: F
Dokument:Formals
Kapitel:
Abschnitt:		Data Dictionary Buchstabe MStand: 06.10.2017Seite: 119
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..4
Version:1
+ + +## Minimaler Timeout-Wert + +Zeitraum, nach dem frühestens eine weitere Life-Indikator-Nachricht gesen- +det werden darf. Die Angabe erfolgt in Sekunden. Liegt keine Begrenzung +vor, kann der Wert ,0' angegeben werden. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..4
Version:1
+ + +## Mischung zulässig + +Kennzeichen dafür, ob das Kreditinstitut die Mischung von Sicherheitsverfah- +ren zulässt, sofern es mehrere Sicherheitsverfahren anbietet. Hierunter ist zu +verstehen, + +· dass eine Nachricht von mehreren Benutzern mit unterschiedlichen Ver- +fahren signiert wird. + +• dass ein Benutzer die Nachrichten eines Dialoges mit verschiedenen Ver- +fahren signiert. + +· dass Signatur und Verschlüsselung einer Nachricht mit verschiedenen +Verfahren durchgeführt werden. + +. dass zwischen den folgenden Gruppen gemischt werden soll: + +\- RAH-7, RAH-9, RDH-3, RDH-5, RDH-6, RDH-7, RDH-8 und RDH-9 + +\- RAH-10, RDH-2 und RDH-10 + +\- DDV + +\- PIN + +Eine Verwendung von Sicherheitsverfahren innerhalb dieser Gruppen gilt +nicht als Mischung. + +Ist hier 'N' eingestellt, so sind die genannten Fälle nicht zulässig, d. h. alle +Signaturen und Verschlüsselungen eines Dialoges müssen mit demselben +Sicherheitsverfahren bzw. mit Verfahren aus der gleichen Gruppe vorge- +nommen werden. Ist 'J' eingestellt, so müssen kreditinstitutsseitig alle vorge- +nannten Fälle unterstützt werden. + +Falls das Kreditinstitut nur ein Sicherheitsverfahren anbietet, ist 'N' einzustel- +len. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + + + + + + + + + + + + + + + +
Kapitel: FVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
120		Stand:
06.10.2017		Kapitel: Data Dictionary
Abschnitt:
Buchstabe N
+ + +N + + +## Nachrichtengröße + +Größe der Nachricht (nach Verschlüsselung und Komprimierung) in Byte. +Das DE ist mit führenden Nullen auf die vorgegebene feste Länge aufzufül- +len. Dies ist erforderlich, damit die Nachrichtenlänge nicht mit der Länge des +DE variiert. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dig
Länge:12
Version:1
+ + +### Nachrichtennummer + +Information zur Referenzierung von Nachrichten innerhalb eines Dialoges. In +Zusammenhang mit der Dialog-ID und der Kundensystem-ID können Nach- +richten über die Nachrichtennummer auch dialogübergreifend eindeutig refe- +renziert werden. Eine Doppeleinreichungskontrolle ist mit Hilfe der Nachrich- +tennummer nicht möglich. + +Mit Hilfe der Nachrichtennummer nummerieren sowohl das Kundensystem +als auch das Kreditinstitutssystem seine Nachrichten unabhängig von- +einander innerhalb eines Dialoges in Einerschritten streng monoton aufstei- +gend. Die Nummerierung beginnt sowohl beim Kunden- als auch beim Kre- +ditinstitutssystem mit der Dialoginitialisierungsnachricht bei '1'. Nachrichten, +deren Nummerierung nicht streng monoton aufsteigend erfolgt ist, werden +institutsseitig bzw. kundenseitig abgelehnt. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..4
Version:1
+ + +### Name des Kontoinhabers 1 + +Name des Kontoinhabers. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:.27
Version:1
+ + +### Name des Kontoinhabers 2 + +Zusätzliche Angaben zum Kontoinhaber. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..27
Version:1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: F
Dokument:Formals
Kapitel:
Abschnitt:		Data Dictionary Buchstabe PStand: 06.10.2017Seite: 121
+ + + + + +### Produktbezeichnung + +Name des Kundenproduktes, mit dem kundenseitig die Nachrichten erzeugt +wurden. Diese Angabe dient dem Kreditinstitut, um Kundenprodukthersteller +gezielt unterstützen zu können. + +Die Produktbezeichnung ist verpflichtend mit aussagekräftigen Informationen +über das verwendete Kundenprodukt, nicht eine ggf. verwendete interne +FinTS-/HBCI-Bibliothek, zu füllen, um Support-Anfragen leichter beantworten +zu können. + +Kundenprodukte, die nach dem durch die Deutsche Kreditwirtschaft festge- +legten Verfahren registriert sind, müssen in dieses DE die vergebene Pro- +duktregistrierungsnummer einstellen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..25
Version:1
+ + +### Produktversion + +Version des Kundenproduktes, mit dem kundenseitig die Nachrichten er- +zeugt wurden. + +Die Produktversion ist verpflichtend mit aussagekräftigen Informationen über +das verwendete Kundenprodukt, nicht eine ggf. verwendete interne FinTS- +/HBCI-Bibliothek, zu füllen, um Support-Anfragen leichter beantworten zu +können. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..5
Version:1
+ + +R + + +## Rückmeldung + +Rückmeldung des Kreditinstitutes. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Rückmel- dungscode1DEdig4M1
2Bezugsdaten- element1DEan..7C1O: bei Verwendung im Segment HIRMS N: bei Verwendung im Segment HIRMG
3Rückmel- dungstext1DEan.80M1
4Rückmel- dungspara- meter1DEan..35O10
+ + + + + + + + + + + + + + + + +
Kapitel: FVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
122		Stand:
06.10.2017		Kapitel: Data Dictionary
Abschnitt: Buchstabe R
+ + + + + + + + + + + + + + + +
Format:
Länge:
Version:1
+ + +### Rückmeldungscode + +Strukturierte Information, die die Rückmeldung genau spezifiziert. + +Die erste Ziffer des Codes beschreibt die Meldungsklasse: + +Codierung der 1. Ziffer: + +0: Erfolg + +3: Warnung + +9: Fehler + +Die restlichen drei Ziffern geben den Inhalt der Meldung an. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dig
Länge:4
Version:1
+ + +### Rückmeldungsparameter + +Informationen, die die Art der Meldung weiter spezifizieren, um z. B. einen +Fehler weiter eingrenzen zu können und eine automatische Reaktion des +Kundenprodukts zu ermöglichen. Es dürfen nur die zum jeweiligen Rück- +meldungscode angegebenen Parameter eingestellt werden. + +Es ist zu beachten, dass die einzustellenden Daten den Formatvorschriften +entsprechen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:1
+ + +### Rückmeldungstext + +Inhalt der Rückmeldung im Klartext. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..80
Version:1
+ + +![へ](figures/130.1) + + +Der in die Rückmeldung einzustellende Text kann vom Kre- +ditinstitut frei gewählt werden. So können diese Texte an in- +dividuelle Anforderungen der einzelnen Institute angepasst +werden, um z. B. institutsspezifische Besonderheiten zu be- +rücksichtigen. Anstatt eines frei definierten Textes kann das +Institut auch den in der Spalte „Code-Bedeutung“ definierten +Text einstellen. Es ist zu beachten, dass der einzustellende +Text den Formatvorschriften entspricht. + +Typ: + +DEG + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: F
Dokument:Formals
Kapitel:Data DictionaryStand:Seite:
Abschnitt:Buchstabe S06.10.2017123
+ + +Das Kreditinstitut hat den Rückmeldungstext in einer Form +einzustellen, dass dieser unverändert im Kundenprodukt an- +gezeigt werden kann. Insbesondere ist der Text in der vom +Kunden mit dem Sprachkennzeichen gewählten Sprache und +unter Berücksichtigung der jeweiligen landesspezifischen Be- +sonderheiten (z. B. Formatierung des Datums) darzustellen. + +Bei Syntaxfehlern ist es ausreichend, dem Kunden den Text +„Syntaxfehler“ ohne weitere Erläuterung zurückzumelden, da +der Fehler im Regelfall vom Kundenprodukt verursacht wurde +und nicht von Kunden behoben werden kann. + +S + + +### Segmentkennung + +Segmentspezifische Kennung, die jedem Segment bzw. Auftrag zugeordnet +ist (z. B. "HKCCS" für "SEPA Einzelüberweisung"). Die Angabe hat in Groß- +schreibung zu erfolgen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..6
Version:1
+ + +### Segmentkopf + +Informationen, die jedem Segment als Kopfteil vorangestellt sind. Im Unter- +schied zu Nachrichten enthalten Segmente jedoch keinen Abschlussteil, da +das Segmentende durch das Segmentende-Zeichen markiert ist. + +Im Segmentkopf stehen die Segmentkennung und Segmentversion unab- +hängig von der HBCI-Version (s. DE HBCI-Version) immer an derselben +Stelle, damit ein Segment auch in späteren HBCI-Versionen immer eindeutig +als solches identifiziert werden kann. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segment- kennung1DEan..6M1
2Segmentnum- mer1DEnum..3M1>=1
3Segment- version1DEnum..3M1
4Bezugsseg- ment1DEnum..3C1>=1
O: Verwendung in Kre- ditinstitutsnachricht N: Verwendung in Kun- dennachricht
+ + + + + + + + + + + + + + + + +
Kapitel: FVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
124		Stand:
06.10.2017		Kapitel: Data Dictionary
Abschnitt: Buchstabe S
+ + + + + + + + + + + + + + + +
Format:
Länge:
Version:1
+ + +### Segmentnummer + +Information zur eindeutigen Identifizierung eines Segments innerhalb einer +Nachricht. Die Segmente einer Nachricht werden in Einerschritten streng +monoton aufsteigend nummeriert. Die Nummerierung beginnt mit 1 im ersten +Segment der Nachricht (Nachrichtenkopf). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..3
Version:1
+ + +### Segmentversion + +Versionsnummer zur Dokumentation von Änderungen eines Segmentfor- +mats. + +Die Segmentversion von administrativen Segmenten (die Segmentart 'Admi- +nistration' bzw. 'Geschäftsvorfall' ist bei jeder Segmentbeschreibung ange- +geben) wird bei jeder Änderung des Segmentformats inkrementiert. + +Bei Geschäftsvorfallssegmenten wird die Segmentversion auf logischer Ebe- +ne verwaltet, d. h. sie ist für das Auftrags-, das Antwort- und das Parame- +tersegment des Geschäftsvorfalls stets identisch und wird inkrementiert, +wenn sich das Format von mindestens einem der drei Segmente ändert. + +Dieses Verfahren gilt bei Standardsegmenten einheitlich für alle Kreditinsti- +tute. Bei verbandsindividuellen Segmenten obliegt die Versionssteuerung +dem jeweiligen Verband. Der Zeitpunkt der Unterstützung einer neuen Seg- +mentversion kann jedoch zwischen den Verbänden variieren. + +Die für die jeweilige HBCI-Version gültige Segmentversion ist bei der jeweili- +gen Segmentbeschreibung vermerkt. + +Falls der Kunde ein Segment mit einer veralteten Versionsnummer einreicht, +sollte ihm in einer entsprechenden Warnung rückgemeldet werden, dass +sein Kundenprodukt aktualisiert werden sollte. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..3
Version:1
+ + +### Sicherheitsklasse + +Die Sicherheitsklasse gibt für jede Signatur den erforderlichen Sicherheits- +dienst an. Als Sicherheitsdienst gelten derzeit ,,Authentikation" und ,Non- +Repudiation". + +Der Sicherheitsdienst ,,Authentikation" erfordert die Signatur mit der Schlüs- +selart ,S“ (Schlüssel auf Kundenseite: Sk.CH.AUT c/s). Der Sicherheitsdienst +,Non-Repudiation“ erfordert die Signatur mit der Schlüsselart „D“ (Schlüssel +auf Kundenseite: SK.CH.DS). + +Typ: + +DEG + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: F
Dokument:Formals
Kapitel:Data DictionaryStand:Seite:
Abschnitt:Buchstabe S06.10.2017125
+ + +Derzeit sind folgende Sicherheitsklassen zulässig: + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBedeutung
0kein Sicherheitsdienst erforderlich
1Sicherheitsdienst ,,Authentikation“
2Sicherheitsdienst ,,Authentikation" mit fortgeschrittener elektronischer Signatur gemäß §2, SigG und optionaler Zertifikatsprüfung unter Ver- wendung des S-Schlüssels (Schlüssel Sk.CH.AUTc/s)
3Sicherheitsdienst ,,Non-Repudiation" mit fortgeschrittener elektronischer Signatur gemäß §2, SigG und optionaler Zertifikatsprüfung unter Ver- wendung des DS-Schlüssels (Sk.CH.DS)
4Sicherheitsdienst ,,Non-Repudiation" mit fortgeschrittener elektronischer Signatur gemäß §2, SigG und zwingender Zertifikatsprüfung unter Ver- wendung des DS-Schlüssels (SK.CH.DS)
+ + +Zu einem späteren Zeitpunkt kann die Notwendigkeit einer weiteren Sicher- +heitsklasse überprüft werden, die qualifizierte Signaturen mit zwingender +Zertifikatsprüfung erfordert. + +Weitere Informationen hierzu befinden sich im Band [HBCI]. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:1
+ + +### Sicherheitsreferenznummer für Digitale Signatur + +(s. Sicherheitsreferenznummer) Signatur-ID des Schlüssels für Digitale Sig- +naturen (Schlüsselart „D“). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:.. 16
Version:1
+ + +### Sicherheitsreferenznummer für Signierschlüssel + +(s. Sicherheitsreferenznummer) Signatur-ID des Signierschlüssels (Schlüs- +selart „S“). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:.. 16
Version:1
+ + +### Standardsprache + +Es ist ein Sprachkennzeichen einzustellen, welches Standardsprache +und -zeichensatz des Kreditinstituts festlegt (s. auch DE ,,Dialogsprache“). +Dieses Kennzeichen bestimmt, mit welchem Zeichensatz die Dialoginitialisie- +rungsnachricht des Kunden gebildet werden muss. Nach dieser Nachricht +verliert die Standardsprache ihre Gültigkeit, da der Kunde in der Dialoginitia- +lisierung die Dialogsprache wählt, welche evtl. von der Standardsprache ab- +weicht. + +Codierung: + + + + + + + + + + + + + + + +
Kapitel: FVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
126		Stand:
06.10.2017		Kapitel: Data Dictionary
Abschnitt:
Buchstabe U
+ + +1: Deutsch, Code ,de' (German), Subset Deutsch, Codeset 1 (Latin 1) + +2: Englisch, Code ,en' (English), Subset Englisch, Codeset 1 (Latin 1) + +3: Französisch, Code ,fr' (French), Subset Französisch, Codeset 1 (Latin 1) + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:..3
Version:2
+ + +### Synchronisierungsmodus + +Information über den Synchronisierungsmodus. + +Codierung: + +0: Neue Kundensystem-ID zurückmelden + +1: Letzte verarbeitete Nachrichtennummer zurückmelden + +2: Signatur-ID zurückmelden + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:2
+ + +U + + +### Uhrzeit + +Uhrzeit eines Ereignisses (meist zusammen mit „Datum“ verwendet). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:tim
Länge:#
Version:1
+ + +#### Unterstützte HBCI-Version + +HBCI-Version, die das Kreditinstitut für den Aufbau der Nachrichten akzep- +tiert. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..3
Version:2
+ + +#### Unterstützte HBCI-Versionen + +Alle HBCI-/FinTS-Versionen, die das Kreditinstitut akzeptiert. + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Unterstützte HBCI-Version2DEnum..3M1..9
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: F
Dokument:Formals
Kapitel:
Abschnitt:		Data Dictionary Buchstabe UStand: 06.10.2017Seite: 127
+ + +Typ: + +DEG + + + + + + + + + + + + + + + +
Format:
Länge:
Version:2
+ + +##### Unterstützte Komprimierungsverfahren + +Information über das kreditinstitutsseitig unterstützte Komprimierungs- +verfahren. + +Die Definition der Felder ist in [HBCI] enthalten. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Komprimierungs- funktion1DEcode..3M10,1,2,3,4,5,6,7,999
2Komprimie- rungsversion1DEnum..3M1..9
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:2
+ + +### Unterstützte Sicherheitsverfahren + +Information über die kreditinstitutsseitig unterstützten Sicherheitsverfahren. +Anhand der Kombination der beiden Elemente ,,Sicherheitsverfahren“ und +,Version" wird das Sicherheitsprofil (z. B. RAH-7) bestimmt. + +Die Definition der Felder ist in [HBCI] enthalten. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Sicherheitsver- fahren, Code1DEcode3M1DDV, RAH, RDH und PIN
2Version des Si- cherheitsverfah- rens1DEnum..3M1..91, 2, 3, 4, 5, 6, 7, 8, 9, 10
+ + +![](figures/135.1) + + +Um Multibankfähigkeit zu gewährleisten, ist die Unterstüt- +zung eines der Verfahren RAH-9 bzw. übergangsweise +RDH-9 kunden- und kreditinstitutsseitig verpflichtend. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:3
+ + +### Unterstützte Sprache + +Information darüber, in welcher Sprache der Kunde mit dem Kreditinstitut +kommunizieren kann. Die derzeit gültigen Sprachkennzeichen sind beim +Element ,,Dialogsprache“ aufgeführt. + +Codierung : s. „Dialogsprache“ + + + + + + + + + + + + + + + +
Kapitel: FVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
128		Stand:
06.10.2017		Kapitel: Data Dictionary
Abschnitt:
Buchstabe U
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:..3
Version:2
+ + +#### Unterstützte Sprachen + +Information darüber, in welchen Sprachen der Kunde mit dem Kreditinstitut +kommunizieren kann. + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Unterstützte Sprache2DEcode..3M1..91, 2, 3
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:2
+ + +![](figures/136.1) + + +Bei Bedarf kann das Kundenprodukt auf dieses Kennzeichen +reagieren und die Sprache des Kundenproduktes entspre- +chend automatisiert anpassen. + + +##### UPD-Version + +Versionsnummer der Userparameterdaten (UPD). Bei jeder kreditinstitutssei- +tigen Änderung wird die Version inkrementiert. (S. auch DE BPD-Version). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..3
Version:1
+ + +##### UPD-Verwendung + +Kennzeichen dafür, wie diejenigen Geschäftsvorfälle zu interpretieren sind, +die bei der Beschreibung der Kontoinformationen nicht unter den erlaubten +Geschäftsvorfällen aufgeführt sind. + + +###### Codierung: + +0: Die nicht aufgeführten Geschäftsvorfälle sind gesperrt (die aufgeführten +Geschäftsvorfälle sind zugelassen). + +1: Bei den nicht aufgeführten Geschäftsvorfällen ist anhand der UPD keine +Aussage darüber möglich, ob diese erlaubt oder gesperrt sind. Diese Prü- +fung kann nur online vom Kreditinstitutssystem vorgenommen werden. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: F
Dokument:Formals
Kapitel:
Abschnitt:		Data Dictionary
Buchstabe V		Stand: 06.10.2017Seite: 129
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:2
+ + +V + + +####### Version der Filterfunktion + +Version der Filterfunktion. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..3
Version:1
+ + +######## Von Datum + +Anfangsdatum eines Zeitraums (s. Kap. B.6.3). + +Durch die Eingabe von Von- und Bis-Datum kann ein Zeitraum eingegrenzt +werden, für den Informationseinträge vom Kreditinstitut rückzumelden sind. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dat
Länge:#
Version:1
+ + +######## Von Kreditinstitutskennung + +Start eines Bereichs von Kreditinstitutskennungen (s. auch „Bis Kredit- +institutskennung") + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:kik
Länge:#
Version:2
+ + +W + + +######## Währung + +Angabe der Währung im Format ISO 4217. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:cur
Länge:#
Version:1
+ + +######## Wert + +Monetärer Wert z. B. als Bestandteil eines Geldbetrags. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:wrt
Länge:#
Version:1
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: G
Dokument:Formals
Kapitel:SyntaxStand:Seite:
Abschnitt:Nachrichtensyntax06.10.2017131
+ + +# H. SYNTAX + + +## H.1 Nachrichtensyntax + + +### H.1.1 Syntaxzeichen + +Es wird eine Trennzeichensyntax mit Freigabezeichen verwendet. + +Folgende Syntaxzeichen werden vereinbart: + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ZeichenBedeutung
+Trennzeichen zwischen Datenelementen
:Trennzeichen zwischen Datenelementen innerhalb einer DEG
'Segmentende-Zeichen
?Freigabezeichen
@Binärdatenkennzeichen
+ + +## H.1.2 Nachrichtenaufbau + + +### ◆ Datenelemente + +Datenelemente werden durch das DE-Trennzeichen '+' syntaktisch getrennt. + +...+DE+DE+DE+... + + +### . Datenelementgruppen + +Datenelemente innerhalb einer Datenelementgruppe werden durch das Trenn- +zeichen ':' getrennt. Die Datenelementgruppe wird vom vorausgehenden und nach- +folgenden Element durch das Trennzeichen ,,+" getrennt. + +. .+DE+DE : DE : DE : DE+DE+... + + +### . Segmente + +Jedes Segment wird mit der DEG ,,Segmentkopf" (s. u.) eingeleitet. Das Ende eines +Segmentes wird stets durch das Segmentende-Zeichen (') signalisiert. Vor dem ers- +ten und nach dem letzten DE eines Segments darf kein DE-Trennzeichen erschei- +nen. + +Segmentkopf+DE+DE+...+DE' + + +### . Nachrichten + +Die Kommunikation zwischen Kunde und Kreditinstitut erfolgt über Nachrichten. +Nachrichten setzen sich aus einer vorgegebenen Segmentabfolge zusammen (s. +Abb. 2). Ausnahmslos alle Nachrichten (Kunde an Kreditinstitut und umgekehrt) +enthalten je ein Kopf- und ein Abschlusssegment. Alle weiteren Nachrichteninhalte +werden ebenfalls in Segmente, die vom Aufbau her dem allgemeinen festen Seg- +mentformat entsprechen, eingestellt. Der allgemeine Nachrichtenaufbau (Segment- +abfolge) ist in den jeweiligen Kapiteln zu Kunden- und Kreditinstitutsnachrichten be- +schrieben. + + + + + + + + + + + + + + + +
Kapitel: GVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
132		Stand: 06.10.2017Kapitel: Syntax Abschnitt: Nachrichtensyntax
+ + +## . Sonderfall: Verwendung von Datenelementgruppen innerhalb von Datenele- mentgruppen + +DEGs (z. B. mehrfach verwendete Elemente) können im Ausnahmefall auch wiede- +rum in Datenelementgruppen eingestellt werden. In diesem Fall dürfen sie nicht +durch Auslassen von Kann-Elementen gekürzt werden. + +Beispiel: MVE ,,Saldo" innerhalb einer DEG + +Girokonto: C:1000,:EUR:20020701::Beschreibung + + +## . Sonderfall: Mehrfach auftretende optionale Datenstrukturen + +Wenn DE bzw. DEG mit dem Status ,,Optional" mehrfach auftreten können (Anzahl +\> 1), sollten sie als letztes Element der jeweiligen syntaktischen Einheit eingestellt +werden, da ansonsten die Struktur u.U. nicht eindeutig zugeordnet werden kann. +Falls sie innerhalb der syntaktischen Einheit auftreten sollen, dürfen keine Auslas- +sungen von Syntaxzeichen vorgenommen werden. + +Beispiel: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2DE11DEO5
3DE21DEO4
+ + +DE1 und DE2 sollen jeweils genau 2 mal belegt werden: + ++DE1+DE1++++DE2+DE2' + + +## H.1.3 Entwertung + +Kommen Syntaxzeichen in einzustellenden Daten vor, sind diese durch Voranstel- +lung des Freigabezeichens '?' zu entwerten. Die Entwertung hat bei allen einzustel- +lenden Daten, außer bei binären Daten zu erfolgen. + +Beispiel 1: + +vor Entwertung: + +Taschengeld für Hans + Franz + +nach Entwertung: + +Taschengeld für Hans ?+ Franz + + +### Beispiel 2: + +vor Entwertung: + +Ist das so richtig?? + +nach Entwertung: + +Ist das so richtig???? + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: G
Dokument:Formals3.0-FV
Kapitel:SyntaxStand:Seite:
Abschnitt:Nachrichtensyntax06.10.2017133
+ + +## H.1.4 Binäre Daten + +Für binäre Daten gilt eine besondere Syntaxregelung: Das Auftreten dieser Daten +wird eingeleitet mit dem Binärdatenkennzeichen (@). Anschließend folgt die Län- +genangabe zu den binären Daten und der binäre Wert selbst, der ebenfalls mit dem +Binärdatenkennzeichen eingeleitet wird. Die Länge wird angegeben in Byte (nicht +die Länge der darstellbaren Zeichen). Hierzu muss sichergestellt sein, dass der bi- +näre Datenstrom in vollen Byte dargestellt werden kann (binäre Daten, die nicht im +Byteformat vorliegen, können nicht über FinTS transportiert werden). Syntaxzei- +chen, die in binären Daten auftreten, dürfen nicht als solche interpretiert werden. + +Bei Elementen, die entsprechende Zeichen enthalten können (z. B. DE „SEPANa- +me) ist eine base64-Kodierung in der Spezifikation vorzusehen. + +...+DE+@@+DE... + + +## H.1.5 Auslassen von Datenstrukturen + + +### . Auslassen von Segmenten + +Kann-Segmente, die keine Daten enthalten, werden einschließlich ihres Segment- +kopfes ausgelassen. + + +### . Auslassen von Datenelementen + +DE werden anhand ihrer Reihenfolge innerhalb des Segmentes identifiziert. DE für +die kein Inhalt vorhanden ist, können, sofern sie den Status ,,Kann" haben, aus- +gelassen werden. Ihre Position wird, sofern noch signifikante (mit Inhalt gefüllte) DE +folgen, durch ein DE-Trennzeichen dargestellt. + +Beispiel 1: + +Segmentkopf+DE+DE+++DE+DE+DE' + +Die DE 3 und 4 nach dem Segmentkopf wurden ausgelassen. + + +### . Auslassen von Datenelementen durch Abschneiden + +Ist für DE, die am Ende eines Segments stehen, kein Inhalt vorhanden, können sie +ausgelassen werden. In diesem Fall wird das Segmentende-Zeichen unmittelbar +nach dem letzten mit Inhalt belegten DE angegeben. + +Beispiel 2: + +Segmentkopf+DE+DE+++DE' + +In Fortführung von Beispiel 1 wurden die letzten beiden DE (6. und 7. DE nach dem +Segmentkopf) abgeschnitten. + + +![](figures/141.1) + + +![](figures/141.2) + + +Da das Abschneiden von Datenelementen nicht verpflichtend ist, +sollte das empfangende System sowohl die abgeschnittene als +auch die nicht abgeschnittene Variante entgegennehmen können. +Dies gilt ebenso auch für das Abschneiden von Gruppendatenele- +menten. + + +### ◆ Auslassen von Gruppendatenelementen + +Es gelten analog die Ausführungen zur Auslassung von Datenelementen. + + + + + + + + + + + + + + + +
Kapitel: GVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite: 134Stand: 06.10.2017Kapitel: Syntax
Abschnitt: Nachrichtensyntax
+ + +Beispiel 3: + +Segmentkopf+DE+GD : GD+GD: : : GD' + +In der letzten Datenelementgruppe wurden zwei GD ausgelassen. + + +### . Auslassen von Gruppendatenelementen durch Abschneiden + +Falls ein oder mehrere GD am Ende einer DEG ausgelassen werden, können sie +durch das DE-Trennzeichen abgeschnitten werden. Stehen sie als letzte im Se- +gment, wird das Segmentende-Zeichen unmittelbar nach dem letzten mit Inhalt be- +legten GD angegeben. + +Beispiel 4: + +Segmentkopf+DE+GD+GD' + +In Fortführung von Beispiel 3 wurde das letzte GD im zweiten DE (erste DEG) nach +dem Segmentkopf unterdrückt. Die letzten drei GD in der letzten DEG wurden ab- +geschnitten. + +Kann-DE sollten am Ende des Segmentes stehen, um eine Reduzierung des Da- +tenvolumens durch Abschneiden zu ermöglichen, sofern dies keine Auswirkungen +auf die logische Reihenfolge der Daten hat. Ebenso sollten Kann-GD am Ende einer +DEG stehen. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: G
Dokument:Formals
Kapitel: Abschnitt:Syntax BeispieleStand: 06.10.2017Seite: 135
+ + +## H.2 Beispiele + + +### H.2.1 Datenelementgruppen + + +#### . Adresse + +Ernst Müller::Bahnhofstr. 17:12345:Berlin:280:03 +0/1234-567 + + +#### . Betrag + +4567,89:EUR + +. Hashalgorithmus + +1:999:1 + + +#### . Kontoverbindung + +1234567:EUR:280:10020030 + +. Kreditinstitutskennung + +280:10020030 + + +#### ◆ Saldo + +C:1000, :EUR:20020710:123015 + + +#### . Segmentkopf + +HIKAZ:5:1:3 + + +#### . Signaturalgorithmus + +6:10:16 + + +#### ◆ Verschlüsselungsalgorithmus + +2:2:13:@96@:6:1 + + +### H.2.2 Segmente + + +#### . Anforderung eines öffentlichen Schlüssels + +HKISA:8:3+2+124+RDH:3+280:10020030:12345:D:1:1' + + +#### ◆ Auslandsüberweisung + +HKAUB:3:6+1234567::280:10020030+@1280@' + + +#### ◆ Auslandsüberweisung ohne Meldeteil + +HKAOM:4:2+1234567::280:10020030+MUSTERMANN AG, 1 +2345 BERLIN++GB14742398061542312341+BANK OF SCOT +LAND, EDINBURGH+JOHN SMITH, PO BOX 1234, EDINBUR +GH, UK+1000,:GBP+1+INVOICE NR. 765-4321' + + + + + + + + + + + + + + + +
Kapitel: GVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite: 136Stand: 06.10.2017Kapitel: Syntax Abschnitt: Beispiele
+ + +## ◆ Auslandsüberweisung ohne Meldeteil Parameter + +HIAOMS:18:2:5+1+2+2+J:250;24;23;24;64;15000,; EUR +:826; 18; 14;18; 18; ; ;6500,;GBP:756;96;22;96;140; ; ; +500000,;CHF:380;70;23;99140;5500,;EUR:724;70;20; +70;105;3000,;EUR' + + +## ◆ Auslandsüberweisung Parameter + +HIAUBS:31:6:5+1+2+2+0' + + +## . Bankparameter allgemein + +HIBPA:3:3:7+3+280:10020030+Musterbank in Musters +tadt+1+1:2:3+201:210:220:300+100' + + +## . Bearbeitungsstatus Finanzdatenformat anfordern + +HKFDB:4:2+1234567::280:10020030+123456789' + + +## . Bearbeitungsstatus Finanzdatenformat Parameter + +HIFDBS:4:2:5+1+2+1' + + +## . Bearbeitungsstatus Finanzdatenformat rückmelden + +HIFDB:4:2:4+1:509:9909+@176@+20021013:14 +3725' + + +## ◆ Bestätigung der Schlüsselsperrung + +HISSP:8:3:8+1+4711+2+231+280:10020030:12345:S:1: +1+501+6:20020611:111734' + + +## . Depotaufstellung anfordern + +HKWPD:3:7+23456::280:10020030+USD+2' + + +## . Depotaufstellung Parameter + +HIWPDS:31:7:5+1+2+1+J:N:J' + + +## ◆ Depotaufstellung rückmelden + +HIWPD:3:6:3+@318@' + +HIWPD:3:7:3+@356@' + + +## ◆ Depotumsätze anfordern + +HKWDU:4:6+1357924::280:10020030+N+1:723600+20020 +527+20020712' + +◆ Depotumsätze Parameter + +HIWDUS:6:6:5+1+2+60' + + +## ◆ Depotumsätze rückmelden + +HIWDU:5:5:4+@287@' + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: G
Dokument:Formals
Kapitel:SyntaxStand:Seite:
Abschnitt:Beispiele06.10.2017137
+ + +HIWDU:5:6:4+@324@' + + +## . Devisenkurse anfordern + +HKDVK:3:2+CHF+EUR' + + +## . Devisenkurse Parameter + +HIDVKS:27:2:5+1+0+0+J:N' + + +## ◆ Devisenkurse rückmelden + +Preisnotierung: 1 EUR = 0,8675/0,8840 CHF + +HIDVK:3:2:3+CHF+Schweizer Franken+1+1+0,8675:EUR ++0,884: EUR::20020701' + +Mengennotierung: 100 BEF = 1,1275/1,1275 EUR + +HIDVK:3:2:3+BEF+Belgische Franken+100+2+1,1275+1 +,1275+EUR+20020701' + + +## . Dialogende + +HKEND:11:1+4711' + + +## ◆ Einreichung Zeichnung bestätigen + +HINEZ:5:2:4+J+1234567+++2' + + +## . Empfangsquittung + +HKQTG:3:1+@12@' + + +## . Empfangsquittung Parameter + +HIQTGS:6:1:3+1+2+1' + + +## ◆ Festgeld ändern Parameter + +HIFGAS:28:4:5+1+2+2+N:J:J:J:N' + + +## ◆ Festgeldänderung bestätigen + +HIFGA:3:4:3+7654322::280:10020030+124+7654321::2 +80:10020030+123' + + +## ◆ Festgeldanlage ändern + +HKFGA:4:4+7654321::280:10020030+123+10000,:EUR+2 +0020701:20020831:3,25: A:10000,: EUR:19999, : EUR:4: +60 Tage, 3,25%+1234567::280:10020030+J+2+1+12345 +67::280:10020030' + + +## . Festgeldanlage prolongieren + +HKFGP:3:4+7654321::280:10020030+123+10000,:EUR+2 +0020701:20020831:3,25: A:10000,: EUR:19999, : EUR:4: +60 Tage, 3,25%+1234567::280:10020030+J+1+1+12345 +67::280:10020030+++++30:10000,:EUR:1' + + + + + + + + + + + + + + + +
Kapitel: GVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite: 138Stand: 06.10.2017Kapitel: Syntax Abschnitt: Beispiele
+ + +## . Festgeldbestand anfordern + +HKFGB:3:4+7654321::280:10020030+123+N' + + +## . Festgeldbestand Parameter + +HIFGBS:30:4:5+1+2+1' + + +## ◆ Festgeldbestand rückmelden + +HIFGB:3:4:3+7654321::280:10020030+123+10000, : EUR ++20020701:20020831: 3,25: A:10000,:EUR:19999, :EUR: +4:60 Tage, 3,25%+1234567::280:10020030+J+1+1+123 +4567::280:10020030+++345,67:EUR+1+30:10000,:EUR: +1' + + +## . Festgeldkonditionen anfordern + +HKFGK:3:3+EUR' + + +## . Festgeldkonditionen Parameter + +HIFGKS:26:3:5+1+0+0+EUR:CHF:FRF' + + +## ◆ Festgeldkonditionen rückmelden + +HIFGK:3:3:3+38516:20020701:152245+20020701:20020 +731:3,: A:10000,: EUR:19999,:EUR:1:30 Tage, 3%+200 +20701:20020731:3,125: A:20000,: EUR: 29999,: EUR: 2:3 +0 Tage, 3,125%+20020701:20020731:3,25: A:30000,:E +UR:::3:30 Tage, 3,25%+20020701:20020831:3, 25: A:1 +0000,:EUR: 19999,:EUR:4:60 Tage, 3,25%+20020701:2 +0020831:3,375: A:20000, : EUR:29999, : EUR:5:60 Tage, +3,375%+20020701:20020831:3,5: A:30000,: EUR: ::6:6 +0 Tage, 3,5%+20020701:20020930: 3,5: A:10000,:EUR: +19999, :EUR:7:90 Tage, 3,5%+20020701:20020930:3,7 +5:A:20000,:EUR:29999,:EUR:8:90 Tage, 3,75%+20020 +701:20020930:3,875: A:30000,:EUR:::9:90 Tage, 3,8 +75%' + + +## . Festgeldneuanlage + +HKFGN:3:4+++10000,:EUR+20020701:20020831:3,25: A: +10000,:EUR:19999,:EUR:4:60 Tage, 3,25%+1234567:: +280:10020030+J+1+1+1234567::280:10020030++38516: +20020701:152245' + + +## ◆ Festgeldneuanlage bestätigen + +HIFGN:3:4:3+7654321::280:10020030+123' + + +## . Festgeldneuanlage Parameter + +HIFGNS:27:4:5+1+2+2+N:J:J:1' + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: G
Dokument:Formals
Kapitel: Abschnitt:Syntax BeispieleStand: 06.10.2017Seite: 139
+ + +## . Festgeldneuanlage widerrufen + +HKFGW:3:4+7654321::280:10020030+123+10000,:EUR+2 +0020701:20020831:3,25: A:10000,: EUR:19999, : EUR:4: +60 Tage, 3,25%+1234567::280:10020030+J+1+1+12345 +67::280:10020030++38516:20020701:152245' + + +## . Festgeldneuanlage widerrufen Parameter + +HIFGWS:31:4:5+1+2+2' + + +## ◆ Festgeldprolongation bestätigen + +HIFGP:3:4:3+7654322::280:10020030+124+7654321::2 +80:10020030+123' + + +## . Festgeldprolongation Parameter + +HIFGPS:29:4:5+1+2+2' + + +## . Festgeldprolongation widerrufen + +HKFPW:3:4+7654321::280:10020030+123+10000,:EUR+2 +0020701:20020831:3,25: A:10000,: EUR:19999, : EUR:4: +60 Tage, 3,25%+1234567::280:10020030+J+1+1+12345 +67::280:10020030+++++30:10000,:EUR:1' + + +## . Festgeldprolongation widerrufen Parameter + +HIFPWS:32:4:5+1+2+2' + + +## . Festpreisangebote anfordern + +HKWFP:4:3+Renten' + + +## . Festpreisangebote Parameter + +HIWFPS:6:3:5+1+0+0+Aktien:Renten:Optionen: Bundes +obligationen:Bundesschatzbriefe' + + +## ◆ Festpreisangebote rückmelden + +HIWFP:5:3:4+12345+2:620597+Stadtsparkasse Köln I +nhaberschuldverschrei- +bung Serie 63+IHS+100,+1000, :EUR+0101+5000, :EUR+ +2+100,75+20031025+1000,+5,46' + + +## . Festpreisorder + +HKFPO:4:2+1234567::280:10020030+++@378@+1 +234567++1::20021012:1+2:Aktien:20021012:1' + + +## . Festpreisorder Parameter + +HIFPOS:6:2:5+1+2+2+J:2:J:J:10000,:EUR' + + +## . Festpreisordereinreichung bestätigen + +HIFPO:5:2:4+N+1234567+++6' + + + + + + + + + + + + + + + +
Kapitel: GVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite: 140Stand: 06.10.2017Kapitel: Syntax Abschnitt: Beispiele
+ + +## . Finanzdatenformat anfordern + +HKFDA:4:2+1234567::280:10020030+1:950:9909+20021 +013' + + +## . Finanzdatenformat anfordern Parameter + +HIFDAS:4:2:5+1+2+1+1;950;9810:1;950;9909:1;951;9 +810' + + +## ◆ Finanzdatenformat rückmelden + +HIFDA:4:2:4+1:950:9909+@2048@+20021013:1 +43725' + + +## . Finanzdatenformat senden + +HKFDS:5:2+1234567::280:10020030+1:101:9810+@768@ ++20020712:163045' + + +## . Finanzdatenformat senden Parameter + +HIFDSS:4:2:5+1+2+2+1;100;9810:1;101;9901' + + +## . Finanzdatenformatliste anfordern + +HKFDL:4:2+1234567::280:10020030' + + +## . Finanzdatenformatliste anfordern Parameter + +HIFDLS:4:2:5+1+2+1' + + +## ◆ Finanzdatenformatliste rückmelden + +HIFDL:4:2:4+1:950:9810+20021013:143725' + + +## . Fondsorder einreichen + +HKWFO:4:2+1234567::280:10020030+++@378@+1 +234568::280:10020030+N+1::20021012:1+2:Aktien:20 +021012:1' + + +## . Fondsorder Parameter + +HIWFOS:6:2:5+1+2+2+J:2:J:N:J:123456;123457;12345 +8:10000, :EUR: MAKT; LMTO ' + + +## . Fondsordereinreichung bestätigen + +HIWFO:5:2:4+J+1234567+++2' + + +## . Freistellungsdaten abfragen + +HKFRD:3:2+280:10020030+1234567+2002+2003' + + +## . Freistellungsdaten Parameter + +HIFRDS:13:2:5+1+2+1' + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: G
Dokument:Formals
Kapitel: Abschnitt:Syntax BeispieleStand: 06.10.2017Seite: 141
+ + +## ◆ Freistellungsdaten rückmelden + +HIFRD:3:2+280:10020030+20020101+20021231+300,:EU +R+200, :EUR+20020110' + + +## . Gastmeldung + +HKGAM:4:4++Bitte schicken Sie mir Informationen +zu Ihrem Leistungsspektrum. Danke Ernst Müller++ +Ernst Müller::Bahnhofstr. 17:12345:Berlin' + + +## . Gastmeldung Parameter + +HIGAMS: 48:4:5+1+0+0+512' + + +## . Identifikation + +HKIDN:5:2+280:10020030+12345+2+1' + + +## . Informationen anfordern + +HKINF:3:4+3511:3512:3513:5110+Ernst Müller::Bahn +hofstr. 17:12345:Berlin' + + +## ◆ Informationen rückmelden + +HIINF:3:4:3+5110:Der Zinssatz für Immobilienkred +i- + +te bei 10-jähriger Laufzeit beträgt aktuell 6,75 +응. ' + + +## . Informationsanforderung Parameter + +HIINFS:50:4:5+1+2+1' + + +## . Kartenanzeige + +HIAZK:3:2:3+10+ec-Karte+1234567890+1+Franz Meier ++20020101+20031231' + +HIAZK:4:2:3+11+Service-Card+9876543210++Franz Me +ier++20021231+10000, :EUR' + + +## . Kartenanzeige anfordern + +HKAZK:3:2+1234567::280:10020030' + + +## . Kartenanzeige Parameter + +HIAZKS:22:2:5+1+2+1' + + +## . Kartensperre beantragen + +HKKAS:3:2+1234567::280:10020030+1+123456789+++20 +021231' + + + + + + + + + + + + + + + +
Kapitel: GVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite: 142Stand: 06.10.2017Kapitel: Syntax Abschnitt: Beispiele
+ + +## . Kartensperre beantragen Parameter + +HIKASS:22:2:5+1+2+2+10;ec-Karte:11;Service-Card: +12; Kreditkarte' + + +## . Kommunikationszugang anfordern + +Alle Kommunikationszugänge: +HKKOM:2:4' + +Kommunikationszugänge für BLZ 100 200 30: + +HKKOM:2:4+280:10020030+280:10020030 + + +## . Kommunikationszugang Parameter + +HIKOMS: 11:4:5+1+0+0' + + +## ◆ Kommunikationszugang rückmelden + +HIKOM:3:4:2+280:10020030+1+1:12345678:00+2:123.1 +23.123.123: :UUE:1+2:www.bankname.de:: UUE:1' + +HIKOM:4:4:2+280:20030040+1+1:54321:00' + +HIKOM:5:4:2+280:30040050+2+1:12345:22' + + +## . Komprimierungsverfahren + +HIKPV:6:1:7+0:0' + + +## . Kontoauszug + +HIEKA:4:1:3+1+20021101:20021130+@362@' + + +## . Kontoauszug anfordern + +HKEKA:3:1+1234567::280:10020030+1+15' + + +## . Kontoauszug Parameter + +HIEKAS:12:1:5+1+2+2+J:N:N:1:2' + + +## . Kontoinformation + +HIUPD:15:5:7+1234567::280:10020030+12345+1+EUR+E +rnst Müller++Giro Spezial+T:2000, :EUR+HKPRO:1+HK +SAK:1+HKISA:1+HKSSP:1+HKCCS:1+HKLAS: 1+HKKAN :1+HK +KAZ:1+HKSAL:1' + +HIUPD:16:5:7+1234568::280:10020030+12345+10+EUR+ +Ernst Müller++Sparkonto 2000++HKPRO:1+HKSAK:0+HK +ISA:1+HKSSP:0+HKCCS:2:Z:1000,: EUR:7+HKKAN: 1+HKKA +Z:1+HKSAL:2' + + +## . Kontoinformationen anfordern + +HKKIF:3:2+1234567::280:10020030+J' + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: G
Dokument:Formals
Kapitel: Abschnitt:Syntax BeispieleStand: 06.10.2017Seite: 143
+ + +# . Kontoinformationen Parameter + +HIKIFS:14:2:5+1+2+1' + + +## ◆ Kontoinformationen rückmelden + +HIKIF:3:2:6+1234567::280:10020030+1+Ernst Müller +++Giro 2000+EUR+200242105+8, 75+0, 5+12, 5+5000, :EU +R++Ernst Müller::Bahnhofstraße 17:12345:Berlin+2 +++Geschäftskonto+Ernst Müller::1:2:10000,:EUR:2+ +Gisela Müller::2:2:2000,:EUR:4' + +HIKIF:4:2:6+7654321::280:10020030+30+Ernst Mülle +r++Depot 2000+EUR+20020410+++++1234567::280:1002 +0030++1+3+Bewertung zu 60%' + + +## ◆ Kontoumsätze anfordern/neue Umsätze + +HKKAN:3:6+1234567::280:10020030+J' + + +## ◆ Kontoumsätze anfordern/Zeitraum + +HKKAZ:3:6+1234567::280:10020030+N+20020701+20020 +730' + + +## ◆ Kontoumsätze rückmelden/neue Umsätze + +HIKAN:4:6:3+@362@+@102@' + + +## ◆ Kontoumsätze rückmelden/Zeitraum + +HIKAZ:4:6:3+@362@+@102@' + + +## ◆ Kontoumsätze/neu Parameter + +HIKANS:12:6:5+1+2+1+60:J:N' + + +## ◆ Kontoumsätze/Zeitraum Parameter + +HIKAZS:11:6:5+1+2+1+60:J:J' + + +## . Kreditinstitutsangebote anfordern + +HKKIA:4:4' + + +## . Kreditinstitutsangebote Parameter + +HIKIAS:49:4:5+1+0+0' + + +## . Kreditinstitutsangebote rückmelden + +HIKIA:5:4:5+3500 : Lebensversicherungen:T+3510 : All +gemei- + +nes: T+3511: Infos zur Lebensversicherung: S+3512: T +ari- + +fe für Lebensversicherungen:S+TDDSG:Unterrichtun +g über die Verarbeitung personenbezogener Daten +gemäß TDDSG:F' + + + + + + + + + + + + + + + +
Kapitel: GVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite: 144Stand: 06.10.2017Kapitel: Syntax Abschnitt: Beispiele
+ + +## . Kreditinstitutsmeldung + +HIKIM:10:2+ec-Karte+Ihre neue ec-Karte liegt zur +Abholung bereit.' + +HIKIM:11:2+Dispokredit+Ihr Dispokredit wurde auf +5.000 Euro erhöht.' + + +## . Kundenmeldung + +HKKDM:4:5++Bitte schicken Sie mir Ihre Allgemein +en Geschäftsbedingungen. Danke Ernst Müller' + +HKKDM:5:5+1234567::280:10020030+Bitte erhöhen Si +e den Dispokredit meines Kontos auf 5.000 Euro+D +ispokre- +dit+Herr Meier, Geschäftstelle Hauptstraße' + + +## . Kundenmeldung Parameter + +HIKDMS:47:5:5+1+2+1+1024' + + +## . Laden GeldKarte abmelden + +HKLGA:4:2+280:1234567::10020030+@22@' + + +## . Laden GeldKarte abmelden Parameter + +HILGAS: 12:2:5+1+2+1' + + +## ◆ Laden GeldKarte bestätigen + +HKLGB:4:2+1234567890+@24@' + + +## ◆ Laden GeldKarte bestätigen Antwort + +HILGB:4:2+1234567890+@8@' + + +## ◆ Laden GeldKarte bestätigen Parameter + +HILGBS:12:2:5+1+0+0' + + +## . Laden GeldKarte durchführen + +HKLGD:4:2+1234567890+@80@' + + +## . Laden GeldKarte durchführen Antwort + +HILGD:4:2+1234567890+@72@' + + +## ◆ Laden GeldKarte durchführen Parameter + +HILGDS:12:2:5+1+0+0' + + +## . Laden GeldKarte einleiten + +HKLGE:4:2+1234567890+@16@' + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: G
Dokument:Formals
Kapitel: Abschnitt:Syntax BeispieleStand: 06.10.2017Seite: 145
+ + +## . Laden GeldKarte einleiten Antwort + +HILGE:4:2+1234567890+@56@' + +. Laden GeldKarte einleiten Parameter + +HILGES:12:2:5+1+0+0' + +. Laden GeldKarte registrieren + +HKLGR:4:2+280:1234567::10020030+@22@' + + +## . Laden GeldKarte registrieren Parameter + +HILGRS:12:2:5+1+2+1' + +. Laden GeldKarte Status + +HILGS: 4:2+7+Ladevorgang abgeschlossen' + + +## . Laden GeldKarte Statusanfrage + +HKLGS:4:2+HEIMGAA0815+@22@+@33@' + + +## . Laden GeldKarte Statusanfrage Parameter + +HILGSS:12:2:5+1+2+1' + + +## . Laden GeldKarte Storno bestätigen + +HKLGX:4:2+1234567890+@24@' + + +## . Laden GeldKarte Storno bestätigen Parameter + +HILGXS:12:2:5+1+0+0' + +. Laden GeldKarte Storno Bestätigung + +HILGX:4:2+1234567890+@8@' + + +## . Laden GeldKarte Storno durchführen + +HKLGT:4:2+1234567890+@80@' + + +## . Laden GeldKarte Storno durchführen Antwort + +HILGT:4:2+1234567890+@72@' + +. Laden GeldKarte Storno durchführen Parameter + +HILGTS:12:2:5+1+0+0' + + +## . Laden GeldKarte Storno vorbereiten + +HKLGO:4:2+1234567890+@16@' + + +## . Laden GeldKarte Storno vorbereiten Antwort + +HILGO:4:2+1234567890+@56@' + + + + + + + + + + + + + + + +
Kapitel: GVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite: 146Stand: 06.10.2017Kapitel: Syntax Abschnitt: Beispiele
+ + +# . Laden GeldKarte Storno vorbereiten Parameter + +HILGOS: 12:2:5+1+0+0' + + +## . Laden GeldKarte vorbereiten + +HKLGV:4:2+1234567::280:10020030+@22@+200, :DEM+HEIMGAA0815+@1@+ +@16@' + + +## . Laden GeldKarte vorbereiten Antwort + +HILGV:4:2+1234567890+@16@' + + +## . Laden GeldKarte vorbereiten Parameter + +HILGVS:12:2:5+1+0+0' + + +## . Life-Indikator + +HKLIF:2:1' + + +## . Liste Neuemissionen + +HINEA:5:2:4+2:666111+NeuerBörsenwert AG+2+J+EUR+ +1+N+Maschinenbau+B+29, 9:EUR+voraussichtlich+Nenn +wertlo- + +se Stückaktie mit Stimmrecht+20021121:120000+200 +21126:120000++20021122:120000++20021215++100000 +Stück+5%+1+22,1:EUR+25,4:EUR++100++5, +X-Bank AG+ +vo- + +rauss. 01.12.2002++Der Emittent haftet nicht für +die Richtigkeit der angegebene Informationen+ht +tp?://www.NeuerBoersenwert. com+XFRA : EUR:5, : :1+XD +US: EUR:10,::1' + + +## . Liste Neuemissionen anfordern + +HKNEA:4:2+1234567::280:10020030+1:2:3' + + +## . Liste Neuemissionen Parameter + +HINEAS:6:2:5+1+0+0+1:2:3' + + +## . Nachrichtenabschluss + +HNHBS:5:1+3' + + +## . Nachrichtenkopf + +HNHBK:1:3+000000000319+300+4711+3+4711:3' + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: G
Dokument:Formals
Kapitel: Abschnitt:Syntax BeispieleStand: 06.10.2017Seite: 147
+ + +## . Neuemission zeichnen + +HKNEZ:4:2+1234567::280:10020030+1234567++@565@+Gerda Müller::Bahnhofstraße 17:12345:Berl +in+19581024++1::20021125:1+2:Aktien:20021125:1+2 +: Neuemissionen : 20021126:2' + + +## . Neuemission zeichnen Parameter + +HINEZS:6:2:5+1+2+2+J:N:1:J:N:10000,:EUR' + + +## . Orderanzeige + +HIOAN:5:2:4+1234567::280:10020030+@512@+N ++J+1234567++20020210:125430' + + +## . Orderanzeige anfordern + +HKOAN:4:2+1234567::280:10020030+N+1234567' + + +## . Orderanzeige Parameter + +HIOANS:6:2:5+1+2+1+J:180' + + +## . Orderstatus + +HIWSO:5:3:4+1234567::280:10020030+6+N+J+1234567+ +++20000215:103025+@512@' + +HIWSO:6:3:4+1234567::280:10020030+6+N+N+1234568+ +3456789++20000217:163158++@346@' + + +## . Orderstatus anfordern + +HKWSO:4:3+1234567::280:10020030+N+J+N+++20021001 ++20021010+1:2:3:4' + + +### . Orderstatus Parameter + +HIWSOS:6:3:5+1+2+1+J:180:1:2:3:4:5:6' + + +#### ◆ PIN ändern + +HKPAE:4:1+04321' + + +#### ◆ PIN ändern Parameter + +HIPAES:4:1:5+1+1+0' + + +#### . PIN sperren + +HKPSP:4:1' + + +### . PIN sperren Parameter + +HIPSPS:4:1:5+1+2+0' + + +### . PIN-Sperre aufheben + +HKPSA:4:1' + + + + + + + + + + + + + + + +
Kapitel: GVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite: 148Stand: 06.10.2017Kapitel: Syntax Abschnitt: Beispiele
+ + +# . PIN-Sperre aufheben Parameter + +HIPSAS:4:1:5+1+2+0' + + +# . PIN/TAN-spezifische Informationen + +HIPINS:4:1:5+1+1+5:6:6:Kunden-Nr aus dem TAN-Bri +ef: :HKCCS:J:HKKAN:N:HKSAL:J:HKPAE:J:HKTLA:J:HKTL +F:J' + + +# ◆ Rückmeldung zu Segmenten + +HIRMS:4:2:5+0010::Auftrag entgegengenommen ' + +HIRMS:5:2:6+9210:15:Kontonummer existiert nicht' + + +# ◆ Rückmeldung zur Gesamtnachricht + +HIRMG:3:2+0010::Nachricht entgegengenommen ' + +HIRMG:3:2+9110::Unbekannter Nachrichtenaufbau' + + +# . Saldenabfrage + +HKSAL:3:6+1234567::280:10020030+N' + + +## . Saldenabfrage Parameter + +HISALS:13:6:5+1+2+1' + + +## ◆ Saldenrückmeldung + +HISAL:4:6:3+1234567::280:10020030+Giro Spezial+E +UR+C:1000, :EUR:20020701+D:500, :EUR:20020701+5000 +, : EUR+7138,35 : EUR+1476,98:EUR++20020501:121545' + + +## ◆ Schlüsseländerung + +HKSAK:8:3+2+112+280:10020030:12345:S:1:1+6:16:10 +:@12@:12:@3@:13' + + +# ◆ Schlüsselsperrung + +HKSSP:8:3+2+130+280:10020030:12345:D:1:1+501' + + +# . Sicherheitsverfahren + +HISHV:5:3:7+N+RDH: 3' + + +# . Signaturabschluss + +Sicherheitsverfahren HBCI: +HNSHA:8:2+654321+@96@' + +Sicherheitsverfahren PIN/TAN: + +HNSHA:8:2+654321++83427:954378' + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: G
Dokument:Formals
Kapitel: Abschnitt:Syntax BeispieleStand: 06.10.2017Seite: 149
+ + +# . Signaturkopf + +HNSHK:2:4+1+654321+1+1+1::2+3234+1:20020605:1111 +44+1:999:1+6:10:16+280:10020030:12345:S:1:1' + + +# . Sorten- und Reisescheckbestellung + +HKSRB:4:2+1234567::280:10020030+2+1.0.2+2+Ernst +Mül- + +ler::Bahnhofstr. 17:12345:Berlin++20020504+300,: +CHF::50,+1000,:USD:1' + + +# . Sorten- und Reisescheckbestellung Parameter + +HISRBS:28:2:5+1+2+2+J:2:60:N:1;2;3:2;1;2;3' + + +# . Sorten- und Reisescheckkonditionen anfordern + +HKSRK:3:2+2+CHF+EUR' + + +# . Sorten- und Reisescheckkonditionen Parameter + +HISRKS:27:2:5+1+0+0+J:N:1:2' + + +# . Sorten- und Reisescheckkonditionen rückmelden + +HISRK:3:2:3+2+CHF+Schweizer Franken Reiseschecks ++1+1+121, 147:EUR::20020901+122,243:EUR::20020901 ++3+50, : CHF+50, : CHF+1+10000,:CHF+0++N+500,:200,:1 +00,:50,+1:2:3+1.0.1:1::::10:EUR+1.0.2: 2::::7,5: E +UR' + + +# . Statusprotokoll anfordern + +HKPRO:3:4+20020101+20020115' + + +# . Statusprotokoll Parameter + +HIPROS:11:4:5+1+1+1' + + +# . Statusprotokoll rückmelden + +HIPRO:4:4:3+4711:3+4+20020210+113025+0020: :Auftr +ag ausgeführt' + +HIPRO:5:4:3+4711:3+5+20020210+113025+9210:3,1: Ko +ntonummer ungültig' + + +# . Synchronisierung + +HKSYN:8:2+1' + + +# . Synchronisierungsantwort + +HISYN:10:3:8+2' + +HISYN:10:3:8++3' + + + + + + + + + + + + + + + +
Kapitel: GVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite: 150Stand: 06.10.2017Kapitel: Syntax Abschnitt: Beispiele
+ + +# . TAN-Verbrauchsinformationen anfordern + +HKTAZ:4:1' + + +## . TAN-Verbrauchsinformationen Parameter + +HITAZS:4:1:5+1+2+0' + + +## . TAN-Verbrauchsinformationen rückmelden + +HITAZ:4:1+A+4711+20010102+50+2+8:TAN1:20010509:1 +03020+5:TAN2:20010619:114010+0+0' + + +## . Terminvereinbarung + +HKTMV:4:3+1234567::280:10020030+20020701+160000+ ++Herr Schulze+0228-1234567++Wertpapierberatung' + + +### . Terminvereinbarung Parameter + +HITMVS:51:3:5+1+2+1' + + +### ◆ Übermittlung eines öffentlichen Schlüssels + +HIISA:8:3:8+1+4711+1+224+280:10020030:12345:D:1: +1+6:17:10:@12@:12:@3@:13' + + +### . Userparameter allgemein + +HIUPA:14:3:7+12345+4+0+Herr Meier' + + +#### . Verarbeitungsvorbereitung + +HKVVB:7:2+2+3+1+Homebanking Plus+3.0' + + +#### ◆ Verschlüsselte Daten + +HNVSD:999:1+@348@' + + +#### ◆ Verschlüsselungskopf + +HNVSK:998:3+4+1+1::1+1:20020610:102044+2:18:13:@ +96@:6:1+280:10020030:123 +45:V:1:1+0' + + +#### . Vordruckbestellung + +HKVDB:3:3+1234567::280:10020030+2+10+20+N+Ernst +Müller::Bahnhofstr. 17:12345:Berlin' + + +### . Vordruckbestellung Parameter + +HIVDBS:34:3:5+1+2+2+10:ec-Scheck:N:11:Barscheck: +J:12:Verrechnungsscheck:J:13:Überweisungsformula +r : J' + + +### . Wertpapierinformationen anfordern + +HKWPI:4:3++2:723600' + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: G
Dokument:Formals
Kapitel: Abschnitt:Syntax BeispieleStand: 06.10.2017Seite: 151
+ + +# . Wertpapierinformationen Parameter + +HIWPIS:6:3:5+1+2+1+J' + + +## ◆ Wertpapierinformationen rückmelden + +HIWPI:5:3:4+2:723600+Siemens+Wertentwicklung der +letz- +ten 12 Monate+jpg+@485@+http?://www.siem +ens.de' + + +## . Wertpapierkurse anfordern + +HKWPK:4:3++2:723600+XFRA' + + +## . Wertpapierkurse Parameter + +HIWPKS:6:3:5+1+2+1+N : J : XFRA;XDUS; XISE; XNYS ; XTKS : +DAX-Werte:REX-Werte' + + +## . Wertpapierkurse rückmelden + +HIWPK:5:3:4+2:723600+Siemens AG Stammaktie+XFRA+ +1+1+340569,+123, 6 : EUR:b:20021112:112357+123,1:EU +R: :20021112+123,5:EUR::20021112+123,9:EUR::20021 +112+124, 1:EUR::20021112+129, 8:EUR::20021111+143, +9: EUR::20020605+105,1: EUR::20020317' + + +## . Wertpapierorder einreichen + +HKWPO:4:3+1234567::280:10020030+++@378@+1 +234568::280:10020030+1::20021012:1+2:Aktien:2002 +1012:1' + + +### . Wertpapierorder Parameter + +HIWPOS:6:3:5+1+2+2+0:J:2:J:N:XFRA;XDUS; XISE;XNYS +; XTKS; OTCO : 180: 2:10000, : EUR: MAKT; LMTO; STLI: ALNO; +CARE; FIKI : GTMO; GTHD; CLOS; OPEN' + + +### ◆ Wertpapierorderänderung + +HKWOA:4:3+1234567::280:10020030++7654321+LMTO+13 +5,:EUR+++++030/1234567+1::20021012:1+2:Aktien:20 +021012:1' + + +### ◆ Wertpapierorderänderung bestätigen + +HIWOA:5:3:4+N+2345678+1234567+++1' + + +### ◆ Wertpapierorderänderung Parameter + +HIWOAS:6:3:5+1+2+2+J:MAKT;LMTO :J:J:GTMO; GTHD ; CLO +S; OPEN: N:1:J:J:J:10000, :EUR' + + + + + + + + + + + + + + + +
Kapitel: GVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite: 152Stand: 06.10.2017Kapitel: Syntax Abschnitt: Beispiele
+ + +### . Wertpapierordereinreichung bestätigen + +HIWPO:5:3:4+J+1234567+++6' + + +### . Wertpapierorderhistorie anfordern + +HKWOH:4:3+1234567::280:10020030+N++7654321' + + +### . Wertpapierorderhistorie Parameter + +HIWOHS:6:3:5+1+2+1+J:60' + + +### ◆ Wertpapierorderhistorie rückmelden + +HIWOH:5:3:4+2+N+@372@+1234567++20020712:1 +11837' + +HIWOH:5:3:5+2+N+@372@+1234567++20020713:1 +52142' + + +### . Wertpapierorderstreichung + +HKWPS:4:3+1234567::280:10020030++7654321+1::2002 +1012:1+2:Aktien:20021012:1' + + +#### . Wertpapierorderstreichung bestätigen + +HIWPS:5:3:4+J+1234567++7' + + +#### . Wertpapierorderstreichung Parameter + +HIWPSS:6:3:5+1+2+2+J:N' + + +#### . Wertpapierreferenznummern anfordern + +HKWPR:4:3+Si+0+Aktien:Renten+N+N+XFRA' + + +#### . Wertpapierreferenznummern Parameter + +HIWPRS:6:3:5+1+0+0+J:J:N:N:XFRA;XDUS ; XISE; XNYS; X +TKS:Aktien:Renten:Optionen' + + +#### . Wertpapierreferenznummern rückmelden + +HIWPR:5:3:3+Siemens Stamm+J+J+J+1: 123456789012+2 +:723600' + +HIWPR:6:3:3+Siemens Vorzüge+J+J+N+1:123456789013 ++2:723601' + + +#### . Wertpapierstammdaten anfordern + +HKWSD:4:3++2:723600' + + +#### . Wertpapierstammdaten Parameter + +HIWSDS:6:3:5+1+2+1+N : A; Inland DAX : B; Inland Sonst +ige: C; Ausland Europa : D; Ausland Sonstige' + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: G
Dokument:Formals
Kapitel: Abschnitt:Syntax BeispieleStand: 06.10.2017Seite: 153
+ + +# ◆ Wertpapierstammdaten rückmelden + +HIWSD:5:3:4+2:723600+Siemens AG Stammaktie+1+1+5 +22+03+Deutsche Inhaberaktien (Stücknotiz) +EUR+EU +R+3+B+555555++XFRA:50,:1:2000000,: EUR:7,:2002021 +5++++XFRA: EUR: ::5,: :1+XDUS: EUR: ::10,: :1' + + +# . Wichtige Informationen anfordern + +HKWPH:4:3+1234567::280:10020030+1234567++1::2000 +0215:1+2:Aktien:20000217:2' + + +# . Wichtige Informationen Parameter + +HIWPHS:5:3:5+1+2+1+1+N:J:Aktien:Renten:Optionen' + + +# ◆ Wichtige Informationen rückmelden + +HIWPH:5:3:4+1::20000218:1:Keine besonderen Hinwe +ise+2:Aktien:20000218:1:18.02.00?1: DaimlerChrysl +er?: Heute Veröffentlichung des Quartalsergebnis +ses+2:Renten:20000217:1:17.02.00?: Bundesbank be +schließt Leitzinssenkung' + + + + + + + + + + + + + + + + +
Kapitel: GVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite: 154Stand: 06.10.2017Kapitel: Syntax Abschnitt: Beispiele
+ + +## H.2.3 Segmentfolgen + + +### ◆ Aufträge + +HKKAZ:4:6+1234567::280:10020030+20020701+2002073 +0' + +HKSAL:5:6+1234567::280:10020030+N' + + +### . Bankparameterdaten + +HIBPA:4:3:4+3+280:10020030+Musterbank in Musters +tadt+1+1:2:3+201:210:220:300+100' + +HIKOM:5:4:4+280:10020030+1+1:12345678:00+2:12345 +679:00+3:123.123.123.123 : :UUE:1' + +HISHV:6:3:4+N+RDH:3' + +HICSES:7:4:4+1+2+7:51:53:54:67:69' + +HICSES:8:5:4+1+2+2+14:51:53:54:67:69' + +HILASS:9:5:4+1+2+2+14:04:05' + +HISUBS:10:6:4+1+2+2+999:14:51:53:54' + +HISLAS:11:6:4+1+2+2+99:14:04:05' + +HIKAZS:12:6:4+1+2+1+60:J' + +HIKANS:13:6:4+1+2+1+60:J' + +HISALS:14:6:4+1+2+1' + + +### . Datensegmente + +HIKAZ:4:6:3+@362@+@102@' + +HISAL:5:6:4+1234567::280:10020030+Giro Spezial+E +UR+C:1000, :EUR:20020701+D:500, :EUR:20020701+5000 +, : EUR+7138,35 : EUR+1476,98 : EUR' + +HIDAB:6:4:5+1234567::280:10020030+7654321::280:2 +0030040+MEIER FRANZ++1000,:EUR+52+000+MIETE : UND +NEBENKOSTEN+20020901+00001+20020701:M:1:1:200306 +01+N: ::3' + + +#### . Parameterdaten + +HICSES:6:4:5+1+2+7:51:53:54:67:69' + +HICSES:7:5:5+1+2+2+14:51:53:54:67:69' + +HIKAZS:8:6:5+1+2+1+60:J' + +HISALS:9:6:5+1+2+1' + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: G
Dokument:Formals
Kapitel: Abschnitt:Syntax BeispieleStand: 06.10.2017Seite: 155
+ + +# . Userparameterdaten + +HIUPA:15:3:4+12345+4+0+Herr Meier' + +HIUPD:16:5:4+1234567:280:10020030+12345+1+EUR+Er +nst Müller++Giro Spezial+T:2000, :EUR+HKPRO : 1+HKS +AK:1+HKISA:1+HKSSP: 1+HKCCS:1+HKLAS:1+HKKAN: 1+HKK +AZ:1+HKSAL:1' + +HIUPD:17:5:4+1234568:280:10020030+12345+10+EUR+E +rnst Müller++Sparkonto 2000++HKPRO:1+HKSAK: 0+HKI +SA:1+HKSSP:0+HKKAN:1+HKKAZ:1+HKSAL:2' + + + + + + + + + + + + + + + +
Kapitel: GVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite: 156Stand: 06.10.2017Kapitel: Syntax Abschnitt: Beispiele
+ + +## H.2.4 Dialog + +Im Beispiel arbeitet der Kunde mit einem Sicherheitsmedium, das asymmetrische +Sicherheitsverfahren (RDH) unterstützt. + + +### H.2.4.1 Nachricht ,,Dialoginitialisierung" + + +#### a) Kundennachricht + +Die Kundennachricht wird von dem Benutzer mit der Kennung '12345' signiert. +Segment: Nachrichtenkopf2 + +HNHBK:1:3+000000000323+300+0+1' + +Segment: Verschlüsselungskopf + +HNVSK:998:2+4+1+1::2+1:20020610:102044+2:18:13:@ +8@:5:1+280:10020030: +12345:V:1:1+0' + +Segment: Verschlüsselte Daten + +HNVSD:999:1+@348@13 + +Segment: Signaturkopf + +HNSHK:2:4+2+654321+1+1+1::2+3234+1:20020701:1111 +44+1:999:1+6:10:17+280:10020030:12345:S:1:1' + +Segment: Identifikation + +HKIDN:3:2+280:10020030+12345+2+1' + +Segment: Verarbeitungsvorbereitung + +HKVVB:4:2+2+3+1+Homebanking Plus+3.0' + +Segment: Zwei-Schritt-TAN-Einreichung + +HKTAN:5:6+4+HKIDN+++1234567890ABCDEF' + +Segment: Anforderung eines öffentlichen Schlüssels (Signierschlüssel) + +HKISA:6:3+2+124+RDH:3+280:10020030:11111:D:1:1' + +Segment: Anforderung eines öffentlichen Schlüssels (Authentikationsschlüssel) + +HKISA:7:3+2+124+RDH:3+280:10020030:11111:S :1:1' + +Segment: Anforderung eines öffentlichen Schlüssels (Chiffrierschlüssel) + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: G
Dokument:Formals
Kapitel:SyntaxStand:Seite:
Abschnitt:Beispiele06.10.2017157
+ + +HKISA:8:3+2+124+RDH:3+280:10020030:11111:V:1:1' + +Segment: Signaturabschluss + +HNSHA:9:1+654321+@96@' + +Segment: Nachrichtenabschluss + +HNHBS : 10:1+1' + + +#### b) Kreditinstitutsnachricht + +Der Kunde erhält zusätzlich jeweils die aktuellen Bankparameterdaten, Userpara- +meterdaten und den aktuellen Signierschlüssel. + +Segment: Nachrichtenkopf + +HNHBK:1:3+000000000932+300+4711+1+4711:1' + +Segment: Verschlüsselungskopf + +HNVSK:998:2+4+1+1::2+1:20020610:102044+2:18:13:@ +8@:5:1+280:10020030: +12345:V:1:1+0' + +Segment: Verschlüsselte Daten + +HNVSD:999:1+@348@' + +Segment: Signaturkopf + +HNSHK:2:4+2+123456+1+1+1::2+3234+1:20020701:1111 +45+1:999:1+6:10:17+280:10020030:1:S:1:1' + +Segment: Rückmeldungen zur Gesamtnachricht + +HIRMG:3:2+0010::Nachricht entgegengenommen ' + +Segment: Rückmeldungen zu Segmenten + + +#### Segmentfolge: Bankparameterdaten + +HIBPA:4:3:4+3+280:10020030+Musterbank in Musters +tadt+1+1:2:3+201:210:220:300+100' + +HIKOM:5:4:2+280:10020030+1+1:12345678:00+2:123.1 +23.123.123::UUE:1+2:www.bankname.de:: UUE:1' + +HISHV:6:3:4+N+RDH: 3' + +HICSES:7:4:4+1+2+7:51:53:54:67:69' + +HICSES:8:5:4+1+2+2+14:51:53:54:67:69' + +HILASS:9:5:4+1+2+2+14:04:05' + +HISUBS:10:6:4+1+2+2+999:14:51:53:54' + + + + + + + + + + + + + + + +
Kapitel: GVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite: 158Stand: 06.10.2017Kapitel: Syntax Abschnitt: Beispiele
+ + +HISLAS:11:6:4+1+2+2+99:14:04:05' + +HIKAZS:12:6:4+1+2+1+60:J' + +HIKANS:13:6:4+1+2+1+60:J' + +HISALS:14:6:4+1+2+1' + + +##### Segmentfolge: Userparameterdaten + +HIUPA:15:3:4+12345+4+0+Herr Meier' + +HIUPD:16:5:4+1234567:280:10020030+12345+1+EUR+Er +nst Müller++Giro Spezial+T:2000, :EUR+HKPRO : 1+HKS +AK:1+HKISA:1+HKSSP:1+HKLAS: 1+HKKAN:1+HKKAZ:1+HKS +AL:1' + +HIUPD:17:5:4+1234568:280:10020030+12345+10+EUR+E +rnst Müller++Sparkonto 2000++HKPRO:1+HKSAK:0+HKI +SA:1+HKSSP:0+HKKAN:1+HKKAZ:1+HKSAL:2' + + +##### Segment: Übermittlung eines öffentlichen Schlüssels (DS-Schlüssel) + +HIISA:18:3:5+1+333+1+224+280:10020030:11111:D:1: +1+6:17:10:@96@:12:@5@:13' + +Segment: Übermittlung eines öffentlichen Schlüssels (Signierschlüssel) + +HIISA:19:3:5+1+333+1+224+280:10020030:11111:S:1: +1+6:17:10:@96@:12:@5@:13' + +Segment: Übermittlung eines öffentlichen Schlüssels (Chiffrierschlüssel)4 + + +##### Segment: Kreditinstitutsmeldung + +HIKIM:20:2+Bausparförderung+Informieren Sie sich +über die neue Bausparförderung. ' + +Segment: Signaturabschluss + +HNSHA:21:2+123456+@96@' + +Segment: Nachrichtenabschluss + +HNHBS:22:1+1' + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: G
Dokument:Formals
Kapitel: Abschnitt:Syntax BeispieleStand: 06.10.2017Seite: 159
+ + +### H.2.4.2 Nachricht ,,SEPA-Einzelüberweisung“ + + +#### a) Kundennachricht + +Diese Nachricht wird sowohl von Benutzer '12345' als auch von Benutzer '76543' +signiert. + +Segment: Nachrichtenkopf + +HNHBK:1:3+000000000523+300+4711+2' + +Segment: Verschlüsselungskopf + +HNVSK:998:2+4+1+1::2+1:20020610:102044+2:18:13:@ +8@:5:1+280:10020030: +12345:V:1:1+0' + +Segment: Verschlüsselte Daten + +HNVSD:999:1+@348@' + +Segment: Signaturkopf für Benutzer '76543' + +HNSHK:2:4+1+765432+1+1+1::2+3234+1:20020701:1111 +46+1:999:1+6:10:17+280:10020030:76543:D:1:1' + +Segment: Signaturkopf für Benutzer '12345' + +HNSHK:3:4+1+654321+1+1+1::2+3234+1:20020701:1111 +47+1:999:1+6:10:17+280:10020030:12345:D:1:1' + +Segment: SEPA-Einzelüberweisung + +HKCCS:4:1+1234567+Depp100200300987654321+urn?:is +o?:std?:iso?:20022?:tech?:xsd?:pain.001.001.03+@ +lll@' + +Segment: Signaturabschluss für Benutzer '12345' + +HNSHA:5:2+654321+@96@' + +Segment: Signaturabschluss für Benutzer '76543' + +HNSHA:6:2+765432+@96@' + +Segment: Nachrichtenabschluss + +HNHBS : 7:1+2' + + +#### b) Kreditinstitutsnachricht + +Segment: Nachrichtenkopf +HNHBK:1:3+000000000140+300+4711+2+4711:2' + + + + + + + + + + + + + + + +
Kapitel: GVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite: 160Stand: 06.10.2017Kapitel: Syntax Abschnitt: Beispiele
+ + +##### Segment: Verschlüsselungskopf + +HNVSK:998:2+4+1+1::2+1:20020610:102044+2:18:13:@ +8@:5:1+280:10020030: +12345:V:1:1+0' + +Segment: Verschlüsselte Daten + +HNVSD:999:1+@348@' + +Segment: Signaturkopf + +HNSHK:2:4+1+123457+1+1+1::2+3234+1:20020701:1111 +48+1:999:1+6:10:17+280:10020030:1:S:1:1' + +Segment: Rückmeldungen zur Gesamtnachricht + +HIRMG:3:2+0010::Nachricht entgegengenommen ' + +Segment: Rückmeldungen zu Segmenten + +HIRMS:4:2:4+0010::Auftrag entgegengenommen' + +Segment: Datensegmente + +Segment: Signaturabschluss + +HNSHA:5:2+123457+@96@' + +Segment: Nachrichtenabschluss + +HNHBS:6:1+2' + + +### H.2.4.3 Nachricht ,,Saldenabfrage" + + +#### a) Kundennachricht + +Die Kundennachricht wird nur von Benutzer '12345' signiert. + +Segment: Nachrichtenkopf + +HNHBK:1:3+000000000257+300+4711+3' + +Segment: Verschlüsselungskopf + +HNVSK:998:2+4+1+1::2+1:20020610:102044+2:18:13:@ +8@:5:1+280:10020030: +12345:V:1:1+0' + +Segment: Verschlüsselte Daten +HNVSD:999:1+@348@' + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: G
Dokument:Formals
Kapitel: Abschnitt:Syntax BeispieleStand: 06.10.2017Seite: 161
+ + +##### Segment: Signaturkopf + +HNSHK:2:4+1+654321+1+1+1::2+3234+1:20020701:1111 +49+1:999:1+6:10:17+280:10020030:12345:S:1:1' + +Segment: Saldenabfrage + +HKSAL:3:6+1234567::280:10020030+N' + +Segment: Signaturabschluss + +HNSHA:4:2+654321+@96@' + +Segment: Nachrichtenabschluss + +HNHBS:5:1+3' + + +#### b) Kreditinstitutsnachricht + +Segment: Nachrichtenkopf + +HNHBK:1:3+000000000213+300+4711+3+4711:3' + +Segment: Verschlüsselungskopf + +HNVSK:998:2+4+1+1::2+1:20020610:102044+2:18:13:@ +8@:5:1+280:10020030: +12345:V:1:1+0' + +Segment: Verschlüsselte Daten + +HNVSD:999:1+@348@' + +Segment: Signaturkopf + +HNSHK:2:4+1+123458+1+1+1::2+3234+1:20020701:1111 +50+1:999:1+6:10:17+280:10020030:1:S:1:1' + +Segment: Rückmeldungen zur Gesamtnachricht + +HIRMG:3:2+0010::Nachricht entgegengenommen' + +Segment: Rückmeldungen zu Segmenten + +HIRMS:4:2:3+0020::Auftrag ausgeführt' + +Segment: Datensegmente + +HISAL:5:6:3+1234567::280:10020030+Giro Spezial+E + +UR+C:1000, :EUR:20020701+D:500,:EUR:20020701+5000 +, : EUR+7138,35: EUR+1476,98 : EUR' + +Segment: Signaturabschluss + +HNSHA:6:2+123458+@96@' + + + + + + + + + + + + + + + +
Kapitel: GVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite: 162Stand: 06.10.2017Kapitel: Syntax Abschnitt: Beispiele
+ + +Segment: Nachrichtenabschluss + +HNHBS : 7:1+3' + + +### H.2.4.4 Nachricht ,,Dialogbeendigung" + + +#### a) Kundennachricht + +Segment: Nachrichtenkopf + +HNHBK:1:3+0000000000475+300+4711+4' + +Segment: Verschlüsselungskopf + +HNVSK:998:2+4+1+1::2+1:20020610:102044+2:18:13:@ +8@:5:1+280:10020030: +12345:V:1:1+0' + +Segment: Verschlüsselte Daten + +HNVSD:999:1+@348@' + +Segment: Signaturkopf + +HNSHK:2:4+2+654321+1+1+1::2+3234+1:20020701:1111 +51+1:999:1+6:10:17+280:10020030:12345:S:1:1' + +Segment: Dialogende + +HKEND:3:1+4711' + +Segment: Signaturabschluss + +HNSHA:4:2+654321+@96@' + +Segment: Nachrichtenabschluss + +HNHBS:5:1+4' + + +#### b) Kreditinstitutsnachricht + +Segment: Nachrichtenkopf +HNHBK:1:3+000000000385+300+4711+4+4711:4' + +Segment: Verschlüsselungskopf + +HNVSK:998:2+4+1+1::2+1:20020610:102044+2:18:13:@ +8@:5:1+280:10020030: +12345:V:1:1+0' + +Segment: Verschlüsselte Daten + +HNVSD:999:1+@348@' + +Segment: Signaturkopf + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: G
Dokument:Formals
Kapitel:SyntaxStand:Seite:
Abschnitt:Beispiele06.10.2017163
+ + +HNSHK:2:4+2+123459+1+1+1::2+3234+1:20020701:1111 +51+1:999:1+6:10:17+280:10020030:1:S:1:1' + +Segment: Rückmeldungen zur Gesamtnachricht + +HIRMG:3:2+0100::Dialog beendet' + +Segment: Rückmeldungen zu Segmenten + +HIRMS:4:2:3+0020::Auftrag ausgeführt' + +Segment: Datensegmente + +Segment: Signaturabschluss + +HNSHA:5:2+123459+@96@' + +Segment: Nachrichtenabschluss +HNHBS : 6:1+4' + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: H
Dokument:Formals
Kapitel:AnlagenStand:Seite:
Abschnitt:Übersicht der FinTS-Elemente06.10.2017165
+ + +# I. ANLAGEN + + +## I.1 Übersicht der FinTS-Elemente + + +### I.1.1 Nachrichten + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameKen- nungSenderVersion
1AbbruchnachrichtN21I1
2Änderung eines öffentlichen Schlüssels des KundenN1K4
3Antwort auf DialoginitialisierungN2I4
4Antwort auf anonyme DialoginitialisierungN3I3
5Antwort auf KommunikationszugangN4I4
6Bestätigung der Schlüsselsperrung durch das Kreditinsti- tutN5I4
7DialoginitialisierungN6K4
8Dialoginitialisierung bei anonymem ZugangN7K3
9DialogbeendigungN8K3
10Dialogbeendigung bei anonymem ZugangN9K3
11Erstmalige Anforderung der Schlüssel des KreditinstitutsN10K4
12Erstmalige Übermittlung der Schlüssel des KreditinstitutsN11I4
13Erstmalige Übermittlung der Schlüssel des KundenN12K4
14KommunikationszugangN13K4
15Kreditinstitutsnachricht allgemeinN14I4
16Kundennachricht allgemeinN15K4
17Kundennachricht allgemein bei anonymem ZugangN16K4
18Life-Indikator-NachrichtN22K1
19Sperrung eines Schlüssels durch den KundenN17K4
20SynchronisierungsnachrichtN18K4
21SynchronisierungsantwortnachrichtN19I4
22Verschlüsselte NachrichtN20K/I3
+ + + + + + + + + + + + + + + + + +
Kapitel: HVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
166		Stand: 06.10.2017Kapitel: Anlagen
Abschnitt: Übersicht der FinTS-Elemente
+ + +### I.1.2 Segmentfolgen + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameSender2Version
1AufträgeK2
2BankparameterdatenI3
3DatensegmenteI2
4ParameterdatenI2
5UserparameterdatenI3
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: H
Dokument:Formals
Kapitel:AnlagenStand:Seite:
Abschnitt:Übersicht der FinTS-Elemente06.10.2017167
+ + +### I.1.3 Segmente + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.SegmentnameKennungSen- der3Version
1Anforderung eines öffentlichen SchlüsselsHKISAK3
2Bankparameter allgemeinHIBPAI3
3Bestätigung der SchlüsselsperrungHISSPI3
4DialogendeHKENDK1
5Zwei-Schritt-TAN-VerfahrenHKTANK/I6
6IdentifikationHKIDNK2
7KomprimierungsverfahrenHIKPVI1
8Kommunikationszugang anfordernHKKOMK4
9Kommunikationszugang rückmeldenHIKOMI4
10KontoinformationHIUPDI6
11KreditinstitutsmeldungHIKIMI2
12Life-IndikatorHKLIFK1
13NachrichtenkopfHNHBKK/I3
14NachrichtenabschlussHNHBSK/I1
15NachrichtenkopfHNHBKK/I3
16Rückmeldung zu SegmentenHIRMSI2
17Rückmeldungen zur GesamtnachrichtHIRMGI2
18SchlüsseländerungHKSAKK3
19SchlüsselsperrungHKSSPK3
20SicherheitsverfahrenHISHVI3
21SignaturabschlussHNSHAK/I2
22SignaturkopfHNSHKK/I4
23SynchronisierungHKSYNK3
24SynchronisierungsantwortHISYNI4
25Übermittlung eines öffentlichen SchlüsselsHIISAI3
26Userparameter allgemeinHIUPAI4
27VerarbeitungsvorbereitungHKVVBK3
28Verschlüsselte DatenHNVSDK/I1
29VerschlüsselungskopfHNVSKK/I3
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: H
Dokument:Formals
Kapitel:AnlagenStand:Seite:
Abschnitt:Übersicht Nachrichtenaufbau06.10.2017169
+ + +## I.2 Übersicht Nachrichtenaufbau + +In den Tabellen ist zu den folgenden Dialogtypen jeweils die Reihenfolge und An- +zahl der möglichen Nachrichten und Segmente dargestellt: + +. Standarddialog + +. Anonymer Dialog + +. Synchronisierung + +· Kommunikationszugänge abholen + +· Änderung eines öffentlichen Schlüssels des Kunden (HBCI RAH,RDH) + +· Erstmalige Anforderung der öffentlichen Schlüssel des Kreditinstituts (HBCI RAH, +RDH) + +· Erstmalige Übermittlung der öffentlichen Schlüssel des Kunden (HBCI RAH, +RDH) + +· Schlüsselsperrung durch den Kunden (HBCI RAH, RDH) + +· Schlüsselsperrung durch den Kunden (HBCI DDV) + +Schreibweise in den Tabellen: + +n: Beliebige Anzahl + +m: Summe der Segmente der Kundennachricht + +n/m: n gilt für symmetrische und m für asymmetrische Verfahren + +Ob die Nachricht verschlüsselt wird, wird durch das Vorhandensein der Segmente +HNVSK und HNVSD angezeigt. In diesem Fall sind die verschlüsselten Segmente +eingerückt. + + + + + + + + + + + + + + + +
Kapitel: HVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite: 170Stand: 06.10.2017Kapitel: Anlagen Abschnitt: Übersicht Nachrichtenaufbau
+ + +### I.2.1 Standarddialog + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
SegmentNachricht
DialoginitialisierungAuftragsnachrichtDialogbeendigung
KundeKredit-KundeKredit-KundeKredit-
N6N2N15N14N8N14
Nachricht110-n0-n11
HNHBK111111
HNVSK111111
HNVSD111111
HNSHK10-11-30-110-1
HIRMG-1-1-1
HIRMS-0-m-0-m-0-m
HKIDN1-----
HKVVB1-----
HKTAN0/11-0/1---
HITAN0/1-0/1--
HKISA0/1-3-----
HKSYN------
HIBPA-0-1----
HIKOM-0-1----
HISHV-0-1----
HIKPV-0-1----
HICSES-0-n----
2
...		-0-n----
HIUPA-0-1----
HIUPD-0-n----
HIISA-0/0-3----
HISYN------
HIKIM-0-n----
HKSAL3--1---
HISAL---0-n--
...------
HKPRO--0-1---
HIPRO---0-n--
HKSAK------
HKSSP------
HISSP------
HKKOM------
HIKOM------
+ +1 +Abhängig davon, ob für eine Auftragsnachricht eine starke Kundenauthentifizierung erforderlich ist, +sind die Segmente HKTAN und HITAN in der Nachricht enthalten. + +2 +Hier sind für die weiteren unterstützten Geschäftsvorfälle die entsprechenden Parameter-Segmente +einzustellen. + +3 +Exemplarisch wird hier der Geschäftsvorfall „Saldenabfrage“ angenommen. + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: H
Dokument:Formals
Kapitel:AnlagenStand:Seite:
Abschnitt:Übersicht Nachrichtenaufbau06.10.2017171
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
SegmentNachricht
DialoginitialisierungAuftragsnachrichtDialogbeendigung
KundeKredit-KundeKredit-KundeKredit-
N6N2N15N14N8N14
HKEND----1-
HNSHA10-11-30-110-1
HNHBS111111
+ + + + + + + + + + + + + + + + +
Kapitel: HVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite: 172Stand: 06.10.2017Kapitel: Anlagen Abschnitt: Übersicht Nachrichtenaufbau
+ + +### I.2.2 Anonymer Dialog + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
SegmentNachricht
DialoginitialisierungAuftragsnachrichtDialogbeendigung
KundeKredit- institutKundeKredit- institutKundeKredit- institut
N7N3N16N14N9N14
Nachricht110-n0-n11
HNHBK111111
HNSHK------
HIRMG-1-1-1
HIRMS-0-m-0-m-0-m
HKIDN1-----
HKVVB1-----
HKISA------
HKSYN------
HIBPA-0-1----
HIKOM-0-1----
HISHV-0-1----
HIKPV-0-1----
HICSES-0-n----
...-0-n----
HIUPA-0-1----
HIUPD-0-n----
HIISA------
HISYN------
HIKIM-0-n----
HKSAL4------
HISAL------
...--0-n0-n--
HKPRO------
HIPRO------
HKSAK------
HKSSP------
HISSP------
HKKOM------
HIKOM------
HKEND----1-
HNSHA------
HNHBS111111
+ +4 +Der Kunde kann hier nicht-signierungspflichtige Auftragssegmente senden. Diese Geschäftsvorfälle +teilt das Kreditinstitut dem anonymen Kunden in der Gast-UPD mit. + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: H
Dokument:Formals
Kapitel:AnlagenStand:Seite:
Abschnitt:Übersicht Nachrichtenaufbau06.10.2017173
+ + +### I.2.3 Synchronisierung + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
SegmentNachricht
DialoginitialisierungAuftragsnachrichtDialogbeendigung
KundeInstitutKundeInstitutKundeInstitut
N18N19N8N14
Nachricht110011
HNHBK11--11
HNVSK11--11
HNVSD11--11
HNSHK10-1--10-1
HIRMG-1---1
HIRMS-0-m---0-m
HKIDN1-----
HKVVB1-----
HKTAN0/15-----
HITAN-0/1----
HKISA0/1-3-----
HKSYN1-----
HIBPA-0-1----
HIKOM-0-1----
HISHV-0-1----
HIKPV-0-1----
HICSES-0-n----
...-0-n----
HIUPA-0-1----
HIUPD-0-n----
HIISA-0/0-3----
HISYN-1----
HIKIM-0-n----
HKSAL------
HISAL------
...------
HKPRO------
HIPRO------
HKSAK------
HKSSP------
HISSP------
HKKOM------
HIKOM------
HKEND----1-
HNSHA10-1--10-1
HNHBS11--11
+ +5 +5 Abhängig davon, ob für die Synchronisation eine starke Kundenauthentifizierung erforderlich ist, sind +die Segmente HKTAN und HITAN in der Nachricht enthalten. + + + + + + + + + + + + + + + + +
Kapitel: HVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite: 174Stand: 06.10.2017Kapitel: Anlagen Abschnitt: Übersicht Nachrichtenaufbau
+ + +### I.2.4 Kommunikationszugang + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
SegmentNachricht
DialoginitialisierungAuftragsnachrichtDialogbeendigung
KundeKredit- institutKundeKredit- institutKundeKredit- institut
N7N3N13N4N9N14
Nachricht111111
HNHBK111111
HNSHK------
HIRMG-1-1-1
HIRMS-0-m-0-m-0-m
HKIDN1-----
HKVVB1-----
HKISA------
HKSYN------
HIBPA-0-1----
HIKOM-0-1----
HISHV-0-1----
HIKPV-0-1----
HICSES-0-n----
...-0-n----
HIUPA-0-1----
HIUPD-0-n----
HIISA------
HISYN------
HIKIM-0-n----
HKSAL------
HISAL------
...------
HKPRO------
HIPRO------
HKSAK------
HKSSP------
HISSP------
HKKOM--1---
HIKOM---0-n--
HKEND----1-
HNSHA------
HNHBS111111
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: H
Dokument:Formals
Kapitel:AnlagenStand:Seite:
Abschnitt:Übersicht Nachrichtenaufbau06.10.2017175
+ + +### I.2.5 Änderung eines öffentlichen Schlüssels des Kunden (HBCI RAH und RDH) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
SegmentNachricht
DialoginitialisierungAuftragsnachrichtDialogbeendigung
KundeKredit- institutKundeKredit- institutKundeKredit- institut
N6N2N1N14N8N14
Nachricht111111
HNHBK111111
HNVSK111111
HNVSD111111
HNSHK10-110-110-1
HIRMG-1-1-1
HIRMS-0-m-0-m-0-m
HKIDN1-----
HKVVB1-----
HKISA0/1-3-----
HKSYN------
HIBPA-0-1----
HIKOM-0-1----
HISHV-0-1----
HIKPV-0-1----
HICSES-0-n----
...-0-n----
HIUPA-0-1----
HIUPD-0-n----
HIISA-0/0-3----
HISYN------
HIKIM-0-n----
HKSAL------
HISAL------
...------
HKPRO------
HIPRO------
HKSAK--1-3---
HKSSP------
HISSP------
HKKOM------
HIKOM------
HKEND----1-
HNSHA10-110-110-1
HNHBS111111
+ + + + + + + + + + + + + + + + +
Kapitel: HVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite: 176Stand: 06.10.2017Kapitel: Anlagen Abschnitt: Übersicht Nachrichtenaufbau
+ + +## I.2.6 Erstmalige Anforderung der öffentlichen Schlüssel des Kreditinstituts (HBCI RAH und RDH) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
SegmentNachricht
DialoginitialisierungAuftragsnachrichtDialogbeendigung
KundeKredit- institutKundeKredit- institutKundeKredit- institut
N10N11N9N14
Nachricht110011
HNHBK11--11
HNSHK-0-1---0-1
HIRMG-1---1
HIRMS-0-m---0-m
HKIDN1-----
HKVVB1-----
HKISA3-----
HKSYN------
HIBPA-0-1----
HIKOM-0-1----
HISHV-0-1----
HIKPV-0-1----
HICSES-0-n----
...-0-n----
HIUPA------
HIUPD------
HIISA-1-3----
HISYN------
HIKIM-0-n----
HKSAL------
HISAL------
...------
HKPRO------
HIPRO------
HKSAK------
HKSSP------
HISSP------
HKKOM------
HIKOM------
HKEND----1-
HNSHA-0-1---0-1
HNHBS11--11
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: H
Dokument:Formals
Kapitel:AnlagenStand:Seite:
Abschnitt:Übersicht Nachrichtenaufbau06.10.2017177
+ + +## I.2.7 Erstmalige Übermittlung der öffentlichen Schlüssel des Kunden (HBCI RAH und RDH) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
SegmentNachricht
DialoginitialisierungAuftragsnachrichtDialogbeendigung
KundeKredit- institutKundeKredit- institutKundeKredit- institut
N12N14N8N14
Nachricht110011
HNHBK11--11
HNVSK11--11
HNVSD11--11
HNSHK10-1---0-1
HIRMG-1---1
HIRMS-0-m---0-m
HKIDN1-----
HKVVB------
HKISA------
HKSYN------
HIBPA------
HIKOM------
HISHV------
HIKPV------
HICSES------
...------
HIUPA------
HIUPD------
HIISA------
HISYN------
HIKIM------
HKSAL------
HISAL------
...------
HKPRO------
HIPRO------
HKSAK2-3-----
HKSSP------
HISSP------
HKKOM------
HIKOM------
HKEND----1-
HNSHA10-1---0-1
HNHBS11--11
+ + + + + + + + + + + + + + + + +
Kapitel: HVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite: 178Stand: 06.10.2017Kapitel: Anlagen Abschnitt: Übersicht Nachrichtenaufbau
+ + +## I.2.8 Schlüsselsperrung durch den Kunden (HBCI RAH und RDH) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
SegmentNachricht
DialoginitialisierungAuftragsnachrichtDialogbeendigung
KundeKredit- institutKundeKredit- institutKundeKredit- institut
N6, N7N2, N3N17N5N8, N9N14
Nachricht111111
HNHBK111111
HNVSK0-10-10-1-0-1-
HNVSD0-10-10-1-0-1-
HNSHK0-10-10-10-1-0-1
HIRMG-1-1-1
HIRMS-0-m-0-m-0-m
HKIDN1-----
HKVVB1-----
HKISA1-3-----
HKSYN------
HIBPA-0-1----
HIKOM-0-1----
HISHV-0-1----
HIKPV-0-1----
HICSES-0-n----
...-0-n----
HIUPA-0-1----
HIUPD-0-n----
HIISA-0-3----
HISYN------
HIKIM-0-n----
HKSAL------
HISAL------
...------
HKPRO------
HIPRO------
HKSAK------
HKSSP--1---
HISSP---1--
HKKOM------
HIKOM------
HKEND----1-
HNSHA0-10-10-10-1-0-1
HNHBS111111
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: H
Dokument:Formals
Kapitel:AnlagenStand:Seite:
Abschnitt:Übersicht Nachrichtenaufbau06.10.2017179
+ + +## I.2.9 Schlüsselsperrung durch den Kunden (HBCI DDV) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
SegmentNachricht
DialoginitialisierungAuftragsnachrichtDialogbeendigung
KundeKredit- institutKundeKredit- institutKundeKredit- institut
N6, N7N2, N3N17N5N8, N9N14
Nachricht111111
HNHBK111111
HNVSK0-10-10-1---
HNVSD0-10-10-1---
HNSHK0-10-10-1---
HIRMG-1-1-1
HIRMS-0-m-0-m-0-m
HKIDN1-----
HKVVB1-----
HKISA------
HKSYN------
HIBPA-0-1----
HIKOM-0-1----
HISHV-0-1----
HIKPV-0-1----
HICSES-0-n----
...-0-n----
HIUPA-0-1----
HIUPD-0-n----
HIISA------
HISYN------
HIKIM-0-n----
HKSAL------
HISAL------
...------
HKPRO------
HIPRO------
HKSAK------
HKSSP--1---
HISSP---1--
HKKOM------
HIKOM------
HKEND----1-
HNSHA0-10-10-1---
HNHBS111111
+ + + + + + + + + + + + + + + + +
Kapitel: ΗVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
180		Stand: 06.10.2017Kapitel: Anlagen Abschnitt: FinTS-Basiszeichensätze
+ + +## 1.3 FinTS-Basiszeichensätze + +Die FinTS-Basiszeichensätze sind Subsets des ISO 8859. Erlaubt sind nur druckba- +re Zeichen des ISO 8859-Zeichensatzes, d. h. die Bereiche X'20' bis X'7E' und +X'A1' bis X'FF' sowie zusätzlich die Zeichen X'0A' (line feed) und X'OD' (carriage re- +turn): + + +## 1.3.1 ISO 8859-1 Subset Deutsch + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
0123456789ABCDEF
0LFCR
1
2SP!"#$%&1()*+,-./
30123456789:;<=>?
4@ABCDEFGHIJKLMNO
5PQRSTUVWXYZ[1]1-
61abCdefghijkImnO
7pbrStuVWXyZ{|}~
8
9
Ai¢£¥§©a«-®-
B0±23,μ.110»1/41/23/4?
CÀÁÂÃÄÅÆÇÈÉÊЁÌÍÎÏ
DĐÑÒÓÔÕÖ×ØÙÚÛÜÝÞB
EàáâãäåæÇèéêëìíÎÏ
FðñÒóÔÕÖØùúûÜýþӰ
+ + +## 1.3.2 ISO 8859-1 Subset Englisch + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
0123456789ABCDEF
0LFCR
1
2SP!"#$%&1()*+,-./
30123456789:;<=>?
4@ABCDEFGHIJKLMNO
5PQRSTUVWXYZ[1]1-
61abCdefghİjkImn0
7pqrStuVWXyZ{|}~
8
9
Aİ¢£a¥§Ca«7-®-
B0±23.μ.د10»1/41/23/4?
CÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏ
DĐÑÒÓÔÕÖ×ØÙÚÛÜÝÞß
EàáâãäåæÇèéêëìíÎÏ
FðñÒÓÔÕÖØùúûüýþӱ
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: Η
Dokument:Formals
Kapitel:AnlagenStand:Seite:
Abschnitt:FinTS-Basiszeichensätze06.10.2017181
+ + +## 1.3.3 ISO 8859-1 Subset Französisch + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
0123456789ABCDEF
0LFCR
1
2SP!"#$%&1()*+,-./
30123456789:;<=>?
4@ABCDEFGHIJKLMNO
5PQRSTUVWXYZ[1]1-
61abCdefghijkImn0
7pqrStuVWXyZ{|}~
8
9
Ai¢£□¥§©a«-®-
B0±23,μ.د10»1/41/23/4?
CÀÁÂÃÄÅÆÇÈÉÊЁìÍÎÏ
DĐÑÒÓÔÕÖ×ØÙÚÛÜÝÞß
EàáâãäåæÇèéêëìíÎÏ
FðñÒÓÔÕÖØùúûüýþÿ
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: H
Dokument:Formals3.0-FV
Kapitel:AnlagenStand:Seite:
Abschnitt:Transportmedienspezifische Festlegungen06.10.2017183
+ + +### I.4 Transportmedienspezifische Festlegungen + +Obwohl FinTS grundsätzlich unabhängig von darunter liegenden Kommunikations- +schichten ist, müssen doch bestimmte Festlegungen für die zu liefernden Netze ge- +troffen werden, um FinTS multibankfähig und einheitlich zu definieren. + +Hierbei handelt es sich um folgende Aspekte: + +· Einschränkung der Kombinationsmöglichkeit von Protokollen, die für die gesi- +cherte Übertragung von FinTS-Datenströmen zugelassen werden. + +. Festlegung von verwendeten Parametern. + +· Abbilden von FinTS-Dialogabläufen auf die darunter liegenden Strukturen. + +Zurzeit wird nur TCPIP als Transportdienst unterstützt: + + + + + + + + + + + + + + + +
Kapitel: HVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
184		Stand: 06.10.2017Kapitel: Anlagen Abschnitt: Transportmedienspezifische Festlegungen
+ + +## I.4.1 TCP/IP + + + + + + + + + + + +
Realisierung Bank:alternativ verpflichtend (es muss entweder der T-Online- oder der TCP/IP-Zugang realisiert werden)
Realisierung Kunde:verpflichtend (sofern keine hardwaretechnischen Restriktionen vorliegen)
+ + +Das ,Transport Control Protocol" (TCP) stellt eine Anwendungsschnittstelle zur Ver- +fügung, auf der Applikationen aufsetzen können, um FinTS-Nachrichten auf gesi- +chertem Weg zwischen Kunde und Kreditinstitut zu übertragen. Da TCP/IP selbst +keinen Dialogbezug zwischen den einzelnen FinTS-Nachrichten herstellen kann, +muss dies durch ein auf TCP/IP aufsetzendes Dialogprotokoll sichergestellt werden. + +Es ist darauf zu achten, dass nur der in RFC793 beschriebene Mindestumfang an +Protokollkommandos zum Einsatz kommt, um eine möglichst hohe Kompatibilität zu +erreichen. + +Als zu verwendende Port Nummer wurde die Adresse 3000 bei der ,,Internet Assig- +ned Numbers Authority" (IANA) registriert. Als Schnittstelle zwischen dem TCP/IP- +Protokoll als Kommunikationspfad und dem FinTS-Kreditinstitutssystem auf der An- +wendungsseite ist ausschließlich die Verwendung von Streamsockets1 bzw. einer zu +der Socketschnittstelle 100% kompatiblen Netzwerkschnittstelle zulässig. Diese +Forderung ist hinsichtlich der bereits zu Anfang des Kapitels geschilderten Rah- +menbedingungen bezüglich der Einheitlichkeit und Multibankfähigkeit von FinTS auf +der Seite der Kommunikationsschnittstelle des Kunden erforderlich. + +Der TCP/IP-Zugang kann verwendet werden, um einen FinTS-Zugang zum Internet +oder einen direkten Kreditinstitutszugang zu ermöglichen. + + +### I.4.1.1 Internet (WWW) + +Das Sicherheitsverfahren FinTS ist unabhängig von der verwendeten Komponente +aus der Liste der Internet-Anwendungen (z. B. World Wide Web, FTP, Telnet). Zu +berücksichtigen ist allerdings die Transparenz des verwendeten Internet-Service, d. +h. es muss evtl. eine Filterfunktion eingesetzt werden. + +Aufgrund der beim Sicherheitsverfahren HBCI verwendeten Sicherheitsmechanis- +men wird auf die Verwendung von Internet-spezifischen Sicherheitsprotokollen (z. B. +Transport Layer Security - TLS) bewusst verzichtet. + +Im Fall des Sicherheitsverfahrens PIN/TAN wird das Vorhandensein einer alter- +nativen Transportsicherungskomponente wie z. B. TLS vorausgesetzt. Bei TLS wird +in gängigen Marktprodukten aktuell die Version 3.0 mit Clientzertifikaten unterstützt. +Dabei ist zwingend eine Schlüssellänge von mindestens 128 bit zu verwenden. + +SSL (Secure Socket Layer) wird von HBCI / FinTS nicht mehr unterstützt. + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: H
Dokument:Formals
Kapitel: Abschnitt:Anlagen Abruf von KommunikationszugangsdatenStand: 06.10.2017Seite: 185
+ + +## I.5 Abruf von Kommunikationszugangsdaten + +Für den Aufbau einer Verbindung zu einem Kreditinstitut sind bestimmte netz- und +dienstspezifische Zugangsdaten erforderlich. Diese Daten müssen dem Kundensys- +tem bereits vorliegen, bevor es die Verbindung aufbauen kann. Mit Hilfe dieses Auf- +trags wird dem Kunden die Möglichkeit gegeben, sich einen Zugangsdatenbestand +anzulegen bzw. diesen zu aktualisieren. + + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +## a) Kundenauftrag + + +### . Beschreibung + +Eine Dialoginitialisierung als anonymer Benutzer ist erforderlich. AnschlieBend an +die Dialoginitialisierung darf nur eine Nachricht mit dem Segment „Kommunika- +tionszugang anfordern" folgen. Nach Erhalt der Antwortnachricht wird der Dialog in +jedem Fall beendet. Die Anforderung der Kommunikationszugänge darf nicht wäh- +rend eines „regulären“ FinTS-Dialogs erfolgen. Der Auftrag wird in diesem Fall ab- +gelehnt. + + +### . Format + + + + + + + + + + + + + + + + + + + +
Name:Kommunikationszugang
Typ:Nachricht
Version:4
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypKennungSta- tusAn- zahlAnmerkungen
1Nachrichtenkopf3SEGHNHBKM1
2Kommunikations- zugang anfordern4SEGHKKOMM1
3Nachrichtenab- schluss1SEGHNHBSM1
+ + +## . Beschreibung + +Es kann ein Bereich von Kreditinstitutskennungen eingestellt werden, um die ge- +wünschten Kommunikationszugänge einzugrenzen. Wird kein Bereich eingestellt, so +werden alle verfügbaren Kommunikationszugänge rückgemeldet. Wenn ein Bereich +angegeben wird, muss das Länderkennzeichen des Bereichsanfangs und -endes +identisch sein. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kommunikationszugang anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKKOM
Bezugssegment:-
Version:4
Sender:Kunde
+ + + + + + + + + + + + + + + + +
Kapitel: HVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite: 186Stand: 06.10.2017Kapitel: Anlagen Abschnitt: Abruf von Kommunikationszugangsdaten
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Von Kreditinstituts- kennung2DEGkik#O1
3Bis Kreditinstituts- kennung1DEGkik#O1
4Maximale Anzahl Einträge1DEnum..4O1>0
5Aufsetzpunkt1DEan..35C1M: vom Kreditinstitut wurde ein Aufsetzpunkt rückge- meldet (s. Kap. B.6.3). N: sonst
+ + +## b) Kreditinstitutsrückmeldung + + +### . Beschreibung + +Für jedes der vom Kunden angeforderten Kreditinstitute wird ein Segment des For- +mats „Kommunikationszugang rückmelden“ in die Kreditinstitutsnachricht eingestellt. +Für jedes Institut können wiederum bis zu 9 Zugänge angegeben werden. + +Die Einstellung von Zeiten, während derer das Kreditinstitut erreichbar ist, erfolgt +nicht, da diese häufigeren Änderungen unterworfen sein können. Grundsätzlich ist +eine 24-stündige Erreichbarkeit anzustreben. + + +![](figures/194.1) + + +Falls das Kreditinstitut für einen Kommunikationsdienst mehr als +einen Zugang anbietet und über den vom Kundensystem ange- +wählten Zugang keine Verbindung hergestellt werden kann, so +sollte das Kundensystem auch die anderen Zugänge auspro- +bieren. + + +### . Format + + + + + + + + + + + + + + + +
Name:Antwort auf Kommunikationszugang
Typ:Nachricht
Version:4
+ + +Sender: + +Kreditinstitut + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypKennungSta- tusAn- zahlAnmerkungen
1Nachrichtenkopf3SEGHNHBKM1
2Rückmeldungen zur Gesamtnachricht2SEGHIRMGM1
3Rückmeldungen zu Segmenten2SEGHIRMSO1
4Kommunikations- zugang rückmelden4SEGHIKOMOn
5Nachrichtenab- schluss1SEGHNHBSM1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: H
Dokument:Formals
Kapitel: Abschnitt:Anlagen Abruf von KommunikationszugangsdatenStand: 06.10.2017Seite: 187
+ + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kommunikationszugang rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIKOM
Bezugssegment:HKKOM
Version:4
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kreditinstitutsken- nung1DEGkik#M1
3Standardsprache2DEnum..3M11,2,3
4Kommunikationspa- rameter2DEGM1..9
+ + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
3010Es liegen keine Einträge vor
3040Auftrag nur teilweise ausgeführt
9210Bereichende darf nicht vor Bereichanfang liegen
+ + +### c) Bankparameterdaten + + +#### . Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kommunikationszugang Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIKOMS
Bezugssegment:HKVVB
Version:4
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + + + + + + + + + + + + + + + +
Kapitel: HVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Formals
Seite:
188		Stand: 06.10.2017Kapitel: Anlagen
Abschnitt: Abruf von Kommunikationszugangsdaten
+ + +![](figures/196.1) + + +Das Anfordern der Kommunikationszugänge ist insbesondere für +den Erstzugang erforderlich. Weiterhin werden Zugangsdaten für +den anonymen Zugang (Gastzugang) benötigt. Kommunikations- +zugänge sind keinen ständigen Änderungen unterworfen und müs- +sen daher nur in großen Zeitabständen aktualisiert werden. Eine Ak- +tualisierung kann auch automatisch erfolgen, sofern ein Verbin- +dungsaufbau aufgrund veralteter Zugangsdaten fehlschlägt. + +Die Zugangsdaten sollten für spätere Zugänge im Kundenprodukt +gespeichert werden. Aus Effizienzgründen kann diese Zugangsda- +tenbank im Kundenprodukt mit einer lokalen Bankleitzahlendatei +verknüpft werden. + +Es ist zu berücksichtigen, dass die Kommunikationsadresse, unter +der die Zugangsdaten abgerufen werden, im Regelfall nicht iden- +tisch ist mit der Adresse des Kreditinstituts, zu dem der Zugang auf- +gebaut werden soll, so dass u.U. nach dem Aktualisieren der Zu- +gangsdaten die physikalische Verbindung erst beendet und dann +mit den neuen Zugangsdaten erneut aufgebaut werden muss. + +Jeder Verband pflegt die Zugangsdaten seiner angeschlossenen In- +stitute und bietet sie an zentraler Stelle zum Abruf an. Die jeweilige +Abrufadresse kann bei den in der Einleitung dieses Dokumentes +genannten Ansprechpartnern erfragt werden. diff --git a/docs/fints-def/FinTS_3.0_Formals_2017-10-06_final_version.pdf b/docs/fints-def/FinTS_3.0_Formals_2017-10-06_final_version.pdf new file mode 100644 index 0000000..742e931 Binary files /dev/null and b/docs/fints-def/FinTS_3.0_Formals_2017-10-06_final_version.pdf differ diff --git a/docs/fints-def/FinTS_3.0_Messages_Geschaeftsvorfaelle_2015-08-07_final_version.md b/docs/fints-def/FinTS_3.0_Messages_Geschaeftsvorfaelle_2015-08-07_final_version.md new file mode 100644 index 0000000..ff79754 --- /dev/null +++ b/docs/fints-def/FinTS_3.0_Messages_Geschaeftsvorfaelle_2015-08-07_final_version.md @@ -0,0 +1,143564 @@ + + + + + + +# FinTS Financial Transaction Services + +Schnittstellenspezifikation + +Messages +Multibankfähige Geschäftsvorfälle + +Herausgeber: + +Bundesverband deutscher Banken e.V., Berlin + +Deutscher Sparkassen- und Giroverband e.V., Bonn/Berlin + +Bundesverband der Deutschen Volksbanken und Raiffeisenbanken e.V., Berlin +Bundesverband Öffentlicher Banken Deutschlands e.V., Berlin + + + + + + +Die vorliegende Schnittstellenspezifikation für eine automatisiert nutzbare multibankfähige +Banking-Schnittstelle (im Folgenden: Schnittstellenspezifikation) wurde im Auftrag der Deut- +schen Kreditwirtschaft entwickelt. Sie wird hiermit zur Implementation in Kunden- und Kredit- +institutssysteme freigegeben. + +Die Schnittstellenspezifikation ist urheberrechtlich geschützt. Zur Implementation in Kunden- +und Kreditinstitutssysteme wird interessierten Herstellern unentgeltlich ein einfaches Nut- +zungsrecht eingeräumt. Im Rahmen des genannten Zwecks darf die Schnittstellenspezifika- +tion auch - in unveränderter Form - vervielfältigt und zu den nachstehenden Bedingungen +verbreitet werden. + +Umgestaltungen, Bearbeitungen, Übersetzungen und jegliche Änderung der Schnittstellen- +spezifikation sind untersagt. Kennzeichnungen, Copyright-Vermerke und Eigentumsangaben +dürfen in keinem Fall geändert werden. + +Im Hinblick auf die Unentgeltlichkeit des eingeräumten Nutzungsrechts wird keinerlei Ge- +währleistung oder Haftung für Fehler der Schnittstellenspezifikation oder die ordnungsge- +mäße Funktion der auf ihr beruhenden Produkte übernommen. Die Hersteller sind aufgefor- +dert, Fehler oder Auslegungsspielräume der Spezifikation, die die ordnungsgemäße Funkti- +on oder Multibankfähigkeit von Kundenprodukten behindern, der Deutschen Kreditwirtschaft +zu melden. Es wird weiterhin ausdrücklich darauf hingewiesen, dass Änderungen der +Schnittstellenspezifikation durch Die Deutsche Kreditwirtschaft jederzeit und ohne vorherige +Ankündigung möglich sind. + +Eine Weitergabe der Schnittstellenspezifikation durch den Hersteller an Dritte darf nur unent- +geltlich, in unveränderter Form und zu den vorstehenden Bedingungen erfolgen. + +Dieses Dokument kann im Internet abgerufen werden unter http://www.fints.org. + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015 - FVKapitel: E
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:EinleitungStand:Seite:
Abschnitt:Betrag07.08.20153
+ + +## Versionsführung + +Das vorliegende Dokument wurde von folgenden Personen erstellt bzw. geändert: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
NameOrgani- sationDatumVersi- onDokumenteAnmerkungen
SteinSIZ15.11.20023.0FinTS 3.0 Messages - Geschaeftsvorfaelle.docDas Dokument wurde in früheren Versionen im Rahmen der HBCI- Spezifikation veröffent- licht
Mind- nichSIZ29.02.20083.0FinTS_3.0_Messages_Ge schaeftsvorfaelle_2008- 02-29_final_version.docEinarbeitung aller veröf- fentlichter Änderungen und Korrekturen bis zum 16.11.2007, Ergänzung HKSPA_2
Haub- ner, Mind- nichSIZ01.07.20093.0FinTS_3.0_Messages_Ge schaeftsvorfaelle_2009- 07-01_final_version.docEinarbeitung aller veröf- fentlichter Änderungen und Korrekturen bis zum 29.05.2009, Ergänzung SEPA-Geschäftsvorfälle
Haub- ner, Mind- nichSIZ06.08.20103.0FinTS_3.0_Messages_Ge schaeftsvorfaelle_2010- 08-06_final_version.docEinarbeitung aller veröf- fentlichter Änderungen und Korrekturen bis zum 06.08.2010
Mind- nichSIZ28.05.20133.0FinTS_3.0_Messages_Ge schaeftsvorfaelle_2013- 05-28_final_version.docxEinarbeitung aller veröf- fentlichter Änderungen und Korrekturen bis zum 28.05.2013
Mind- nichSIZ07.08.20153.0FinTS_3.0_Messages_Ge schaeftsvorfaelle_2015- 08-07_final_version.docxEinarbeitung aller veröf- fentlichter Änderungen und Korrekturen bis zum 07.08.2015
+ + + + + +## Änderungen gegenüber der Vorversion: + +Hypertextlinks sind in dieser Farbe markiert. Falls sich die Kapitelnummerierung ge- +ändert hat, bezieht sich die Kapitelangabe auf die neue Nummerierung. Aufgrund +der umfangreichen Ergänzugen und Tabellenerweiterungen war eine Markierung +der Änderungen im Dokument nicht möglich. + +Veränderungen zum Spezifikationsdokument FinTS V3.0 Releasestand 28.05.2013: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
lfd. Nr.KapitelKapitel- nummerKen- nung1Art2Beschreibung
1Gesamtdokument-FRedaktionell Anpassungen
2Konto- und Um- satzinformationenC.2.1.1.4.2CR467KKlarstellung zur Verwendung der „Über- sicht Kontoauszüge“ in Segmentversion 2 auch für andere Kontoauszugsformate
C.2.2.6CR407EGeschäftsvorfall „Kontoinformation“ in der Segmentversion 7 eingefügt
C2.3.1.1.1CR434 CR445KHerstellerhinweise eingefügt zur Electronic Sequence Number sowie zur Belegung der camt.52 Nachricht.
C.2.4.2CR473KGeschäftsvorfall „Übersicht institutsver- walteter Aufträge“ in der Segmentversi- on 2 eingefügt
C.2.5.1CR460KGeschäftsvorfall „Elektronischer Konto- auszug PDF" in eigenes Unterkapitel ausgelagert; Herstellerhinweis zur base64-Kodierung bei einigen Imple- mentierungen
C.2.5.2CR460KGeschäftsvorfall „Elektronischer Konto- auszug PDF" in der Segmentversion 2 eingefügt
3WertpapiereC.4.2.2.3CR448EGeschäftsvorfall „Orderstatus" in der Segmentversion 5 eingefügt
C.4.4.2.2CR448EGeschäftsvorfall „Wertpapierstammda- ten“ in der Segmentversion 4 eingefügt
4Zahlungsverkehr AuslandC.5.1.4CR474EGeschäftsvorfall „Zahlungsauftrag im AuBenwirtschaftsverkehr“ in der Seg- mentversion 9 eingefügt
5SonstigesC.9.7-EKapitelstruktur geändert
C.9.7.2CR455EDiverse Geschäftsvorfälle zu „Dauerauf- trag Prepaidkarte Laden“ eingefügt
C.9.10CR427 CR443 CR464EDiverse Geschäftsvorfälle zu „Elektroni- sches Postfach“ eingefügt
6SEPA- ZahlungsverkehrC.10.2CR457KHerstellerhinweise eingefügt zur Ver- wendung des BatchBooking- Kennzeichens bei SEPA Einzelaufträgen
C.10.2.2.3.2CR450EGeschäftsvorfall „Bestand terminierter SEPA-Überweisungen anfordern“ in der Segmentversion 2 eingefügt
+ +1 +nur zur internen Zuordnung + +2 +F = Fehler; Ä = Änderung; K = Klarstellung; E = Erweiterung + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015 - FVKapitel: E
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:EinleitungStand:Seite:
Abschnitt:Betrag07.08.20155
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
lfd. Nr.KapitelKapitel- nummerKen- nungArt2Beschreibung
C.10.2.5.3CR438EBelegungsrichtlinie zu DE ,,Widerufen“ im HIDSBS_1 gelöscht.
C.10.2.5.4.2CR466EGeschäftsvorfall „Terminierte SEPA- Einzellastschrift einreichen" in der Seg- mentversion 2 eingefügt
C.10.2.5.4.6CR450EGeschäftsvorfall „Bestand terminierter SEPA-Einzellastschriften anfordern" in der Segmentversion 2 eingefügt
C.10.2.6.2.2CR466EGeschäftsvorfall „Einreichung terminier- ter SEPA-Firmeneinzellastschriften“ in der Segmentversion 2 eingefügt
C.10.2.6.2.5CR450EGeschäftsvorfall „Bestand terminierter SEPA-Firmeneinzellastschriften abrufen“ in der Segmentversion 2 eingefügt
C.10.3CR444KKlarstellungzu ,,Kontrollsumme verpflich- tend" laut BPD
C.10.3.2.2.2CR466EGeschäftsvorfall „Einreichung terminier- ter SEPA-Sammellastschrift" in der Segmentversion 2 eingefügt
C.10.3.2.2.3CR438FRestriktion zu ,,Summenfeld benötigt“ von N=J auf M=J korrigiert
C.10.3.3.2.2CR466EGeschäftsvorfall „Einreichung terminier- ter SEPA-Firmensammellastschrift“ in der Segmentversion 2 eingefügt
C.10.4CR450EGeschäftsvorfälle zu „C- Transaktionen“ eingefügt
Diverse
C.10.5CR471EGeschäftsvorfall „SEPA Card Clearing Nachricht einreichen“ eingefügt
7Data-DictionaryD.-EEinfügen und ergänzen diverser DEG und DE
8AnlagenE.1-ÄTabelle der je HBCI-Version gültigen Segmentversionen ergänzt
E.2-ÄTabelle der Geschäftsvorfallsunterstüt- zung ergänzt
E.7CR445EBeispiele für die eindeutige Belegung von camt.052-messages im HKCAZ ein- gefügt
+ + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel:
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:InhaltsverzeichnisStand: 07.08.2015Seite: 7
+ + +## Inhaltsverzeichnis + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
A. Einleitung1
B. Mehrfach verwendete Elemente3
B.1 Betrag3
B.2 Kreditinstitutskennung3
B.3 Kontoverbindung3
B.3.1 Kontoverbindung4
B.3.2 Kontoverbindung international5
B.3.3 Kontoverbindung ZV international6
B.4 Saldo6
B.5 Adresse7
B.6 Zeitstempel7
B.7 Börsenkurs8
C. Geschäftsvorfälle9
C.1 Zahlungsverkehr Inland9
C.2 Konto- und Umsatz-Informationen10
C.2.1 Umsatz-Informationen (SWIFT MT-Formate)10
C.2.1.1 Kontoumsätze10
C.2.1.1.1 Kontoumsätze/Zeitraum10
C.2.1.1.1.1 Segmentversion 610
C.2.1.1.1.2 Segmentversion 7 (SEPA)14
C.2.1.1.2 Kontoumsätze/neue Umsätze17
C.2.1.1.2.1 Segmentversion 617
C.2.1.1.2.2 Segmentversion 7 (SEPA)19
C.2.1.1.3 Kontoauszug21
C.2.1.1.3.1 Segmentversion 121
C.2.1.1.3.2 Segmentversion 224
C.2.1.1.3.3 Segmentversion 327
C.2.1.1.3.4 Segmentversion 4 (SEPA)30
C.2.1.1.3.5 Segmentversion 533
C.2.1.1.4 Übersicht Kontoauszüge36
C.2.1.1.4.1 Segmentversion 136
C.2.1.1.4.2 Segmentversion 2 (SEPA)39
C.2.1.1.5 Vormerkposten anfordern42
C.2.1.2 Saldenabfrage44
C.2.1.2.1 Segmentversion 644
C.2.1.2.2 Segmentversion 7 (SEPA)47
+ + + + + + + + + + + + + + + + +
Kapitel:Version: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
8		Stand: 07.08.2015Kapitel: Inhaltsverzeichnis
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
C.2.2 Kontoinformationen51
C.2.2.1 Segmentversion 251
C.2.2.2 Segmentversion 3 (SEPA)53
C.2.2.3 Segmentversion 4 (SEPA)56
C.2.2.4 Segmentversion 5 (SEPA)59
C.2.2.5 Segmentversion 662
C.2.2.6 Segmentversion 765
C.2.3 Umsatz-Informationen (camt)69
C.2.3.1.1 Kontoumsätze69
C.2.3.1.1.1 Kontoumsätze/Zeitraum (camt)69
C.2.3.1.1.2 Kontoumsätze/neue Umsätze (camt)72
C.2.3.1.2 Kontoauszug75
C.2.3.1.2.1 Elektronischer Kontoauszug (camt)75
C.2.4 Übersicht institutsverwalteter Aufträge78
C.2.4.1 Segmentversion 178
C.2.4.2 Segmentversion 281
C.2.5 Elektronischer Kontoauszug PDF84
C.2.5.1 Segmentversion 184
C.2.5.2 Segmentversion 286
C.3 Termineinlagen90
C.3.1 Festgeldkonditionen91
C.3.2 Festgeldneuanlage93
C.3.3 Festgeldänderung96
C.3.4 Festgeldprolongation99
C.3.5 Festgeldbestandsabfrage102
C.3.6 Widerruf einer Festgeldneuanlage105
C.3.7 Widerruf einer Festgeldprolongation107
C.4 Wertpapiere109
C.4.1 Wertpapierorder113
C.4.1.1 Wichtige Informationen anfordern113
C.4.1.2 Wertpapierorder116
C.4.1.2.1 Segmentversion 3116
C.4.1.2.2 Segmentversion 4122
C.4.1.3 Orderänderung129
C.4.1.3.1 Segmentversion 3129
C.4.1.3.2 Segmentversion 4133
C.4.1.4 Orderstreichung139
C.4.1.5 Fondsorder142
C.4.2 Statusinformationen145
C.4.2.1 Orderanzeige145
C.4.2.1.1 Segmentversion 2145
C.4.2.1.2 Segmentversion 3147
C.4.2.1.3 Segmentversion 4149
C.4.2.2 Orderstatus153
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel:
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:InhaltsverzeichnisStand: 07.08.2015Seite: 9
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
C.4.2.2.1 Segmentversion 3153
C.4.2.2.2 Segmentversion 4156
C.4.2.2.3 Segmentversion 5159
C.4.2.3 Orderhistorie163
C.4.3 Depotinformationen166
C.4.3.1 Depotaufstellung166
C.4.3.2 Depotumsätze168
C.4.4 Wertpapierinformationen170
C.4.4.1 Abfrage von Wertpapierreferenznummern170
C.4.4.2 Wertpapierstammdaten173
C.4.4.2.1 Segmentversion 3173
C.4.4.2.2 Segmentversion 4175
C.4.4.3 Wertpapierkurse179
C.4.4.4 Wertpapierinformationen183
C.4.5 Sonstiges185
C.4.5.1 Festpreisgeschäft185
C.4.5.1.1 Festpreisangebote185
C.4.5.1.2 Festpreisorder188
C.4.5.2 Neuemissionen191
C.4.5.2.1 Neuemissionen anzeigen191
C.4.5.2.2 Neuemission zeichnen195
C.5 Zahlungsverkehr Ausland199
C.5.1 Zahlungsauftrag im AuBenwirtschaftsverkehr199
C.5.1.1 Segmentversion 6199
C.5.1.2 Segmentversion 7203
C.5.1.3 Segmentversion 8206
C.5.1.4 Segmentversion 9210
C.5.2 Euro-STP-Zahlung214
C.5.2.1 Segmentversion 1214
C.5.2.2 Segmentversion 2216
C.5.2.3 Segmentversion 3218
C.5.3 Auslandsüberweisung ohne Meldeteil222
C.5.4 EU-Standardüberweisung225
C.5.5 Euro-Eilüberweisung228
C.6 Karten, Schecks und Formulare231
C.6.1 Bestellung231
C.6.1.1 Vordruckbestellung231
C.6.2 Kartenanzeige233
C.6.3 Sperre 235
C.6.3.1 Kartensperre		235
C.7 Sorten, Devisen und Reiseschecks237
C.7.1 Devisenkurse237
C.7.2 Sorten- und Reisescheckkonditionen anfordern240
C.7.3 Sorten- und Reisescheckbestellung243
+ + + + + + + + + + + + + + + + +
Kapitel:Version: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 10Stand: 07.08.2015Kapitel: Inhaltsverzeichnis
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
C.8 Informationen247
C.8.1 Freitextmeldungen247
C.8.1.1 Kundenmeldung247
C.8.1.2 Gastmeldung249
C.8.2 Formatierte Meldungen251
C.8.2.1 Kreditinstitutsangebote abholen251
C.8.2.2 Informationsbestellung254
C.8.2.3 Terminvereinbarung256
C.9 Sonstiges259
C.9.1 Freistellung von Zinserträgen259
C.9.1.1 Abfrage Freistellungsdaten259
C.9.1.1.1 Segmentversion 2259
C.9.1.1.2 Segmentversion 3261
C.9.1.1.3 Segmentversion 4264
C.9.1.2 Freistellungsauftrag anlegen267
C.9.1.3 Freistellungsdaten ändern271
C.9.1.4 Freistellungsdaten löschen274
C.9.2 Dateitransfer276
C.9.2.1 Finanzdatenformat/Dokument senden276
C.9.2.1.1 Finanzdatenformat senden276
C.9.2.1.2 Dokument senden278
C.9.2.2 Bearbeitungsstatus Finanzdatenformat/Dokument anfordern
C.9.2.2.1 Bearbeitungsstatus Finanzdatenformat anfordern		281
281
C.9.2.2.2 Bearbeitungsstatus Dokument anfordern282
C.9.2.3 Liste der bereitgestellten Finanzdatenformat/Dokumente anfordern 285
C.9.2.3.1 Liste der bereitgestellten Finanzdatenformate anfordern285
C.9.2.3.2 Liste der bereitgestellten Dokumente anfordern286
C.9.2.4 Finanzdatenformat/Dokument anfordern289
C.9.2.4.1 Finanzdatenformat anfordern289
C.9.2.4.2 Dokument anfordern291
C.9.3 Geldkartentransaktionen294
C.9.3.1 An-/Abmeldung einer GeldKarte294
C.9.3.1.1 Registrierung einer GeldKarte294
C.9.3.1.2 Abmeldung einer GeldKarte296
C.9.3.2 Laden der GeldKarte298
C.9.3.2.1 Laden GeldKarte vorbereiten299
C.9.3.2.2 Laden GeldKarte einleiten301
C.9.3.2.3 Laden GeldKarte durchführen304
C.9.3.2.4 Laden GeldKarte bestätigen307
C.9.3.3 Laden GeldKarte Status310
C.9.3.4 Laden GeldKarte Storno312
C.9.3.4.1 Laden GeldKarte Storno vorbereiten312
C.9.3.4.2 Laden GeldKarte Storno durchführen314
C.9.3.4.3 Laden GeldKarte Storno bestätigen317
C.9.4 Empfangsquittung319
C.9.5 Serverzeit321
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel:
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:InhaltsverzeichnisStand:" 07.08.2015Seite: 11
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
C.9.6 Kundendaten323
C.9.6.1 Anzeige Kundendaten323
C.9.6.2 Adressänderung324
C.9.7 Laden Prepaidkarten326
C.9.7.1 Prepaidkarte laden326
C.9.7.1.1 Segmentversion 1326
C.9.7.1.2 Segmentversion 2327
C.9.7.2 Dauerauftrag Prepaidkarte laden329
C.9.7.2.1 Dauerauftrag Prepaidkarte laden einrichten330
C.9.7.2.2 Bestandsabfrage der Daueraufträge Prepaidkarte laden 333
C.9.7.2.3 Löschen Dauerauftrag Prepaidkarte laden335
C.9.8 Willenserklärung des Kunden337
C.9.9 Elektronischen Kontoauszug beantragen340
C.9.10 Elektronisches Postfach342
C.9.10.1 Postfach Nachrichtentypen anfordern342
C.9.10.2 Auswahl Postfach-Nachrichtentypen343
C.9.10.3 Postfach-Nachrichtenliste anfordern345
C.9.10.4 Postfach-Nachricht abrufen347
C.9.10.5 Postfach-Kontoauszug erstellen350
C.9.10.6 Postfach-Nachricht löschen351
C.10 SEPA-Zahlungsverkehr353
C.10.1 SEPA-Kontoverbindung anfordern354
C.10.1.3 Segmentversion 1354
C.10.1.4 Segmentversion 2356
C.10.1.5 Segmentversion 3359
C.10.2 SEPA-Einzelaufträge363
C.10.2.1 Einzelüberweisung363
C.10.2.2 Terminierte SEPA-Überweisung365
C.10.2.2.1 Einreichung terminierter SEPA-Überweisungen366
C.10.2.2.2 Änderung terminierter SEPA-Überweisungen369
C.10.2.2.3 Bestand terminierter SEPA-Überweisungen abrufen 372
C.10.2.2.3.1 Segmentversion 1372
C.10.2.2.3.2 Segmentversion 2374
C.10.2.2.4 Löschung terminierter SEPA-Überweisungen378
C.10.2.3 SEPA-Dauerauftrag380
C.10.2.3.1 SEPA-Dauerauftragseinrichtung382
C.10.2.3.2 SEPA-Dauerauftragsänderung384
C.10.2.3.3 SEPA-Dauerauftragsaussetzung388
C.10.2.3.4 SEPA-Dauerauftragsbestand abrufen391
C.10.2.3.5 SEPA-Dauerauftragsänderungsvormerkungen abrufen 394
C.10.2.3.6 SEPA-Dauerauftragslöschung397
C.10.2.4 Vorbereitete SEPA-Überweisungen400
C.10.2.4.1 Vorbereitete SEPA-Überweisung anlegen401
C.10.2.4.2 Vorbereitete SEPA-Überweisung ändern403
+ + + + + + + + + + + + + + + + +
Kapitel:Version: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 12Stand: 07.08.2015Kapitel: Inhaltsverzeichnis
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
C.10.2.4.3 Bestand vorbereiteter SEPA-Überweisungen anzeigen405
C.10.2.4.4 Vorbereitete SEPA-Überweisung löschen407
C.10.2.5 SEPA-Einzellastschriften409
C.10.2.5.1 Einreichung SEPA-Einzellastschrift409
C.10.2.5.2 SEPA-Lastschriftwiderspruch410
C.10.2.5.3 Bestand rückgabefähiger SEPA-Lastschriften413
C.10.2.5.4 Terminierte SEPA-Lastschrift416
C.10.2.5.4.1 Einreichung terminierter SEPA- Einzellastschriften (Segmentversion 1)416
C.10.2.5.4.2 Einreichung terminierter SEPA- Einzellastschriften (Segmentversion 2)418
C.10.2.5.4.3 Einreichung terminierter SEPA-COR1- Einzellastschriften420
C.10.2.5.4.4 Änderung terminierter SEPA- Einzellastschriften423
C.10.2.5.4.5 Bestand terminierter SEPA-Einzellastschriften abrufen (Segmentversion 1)425
C.10.2.5.4.6 Bestand terminierter SEPA-Einzellastschriften abrufen (Segmentversion 2)428
C.10.2.5.4.7 Löschung terminierter SEPA- Einzellastschriften430
C.10.2.6 SEPA-Firmeneinzellastschriften433
C.10.2.6.1 Einreichung SEPA-Firmeneinzellastschriften433
C.10.2.6.2 Terminierte SEPA- Firmeneinzellastschriften433
C.10.2.6.2.1 Einreichung terminierter SEPA- Firmeneinzellastschriften (Segmentversion 1) 434
C.10.2.6.2.2 Einreichung terminierter SEPA- Firmeneinzellastschriften (Segmentversion 2) 436
C.10.2.6.2.3 Änderung terminierter SEPA- Firmeneinzellastschriften438
C.10.2.6.2.4 Bestand terminierter SEPA- Firmeneinzellastschriften abrufen (Segmentversion 1)440
C.10.2.6.2.5 Bestand terminierter SEPA- Firmeneinzellastschriften abrufen (Segmentversion 2)443
C.10.2.6.2.6 Löschung terminierter SEPA- Firmeneinzellastschrift446
C.10.2.7 SEPA-Dauereinzellastschrift449
C.10.2.7.1 SEPA-Dauereinzellastschrifteinrichtung450
C.10.2.7.2 SEPA-Dauereinzellastschriftänderung452
C.10.2.7.3 SEPA-Dauereinzellastschriftaussetzung456
C.10.2.7.4 SEPA-Dauereinzellastschriftbestand abrufen458
C.10.2.7.5 SEPA-
Dauereinzellastschriftänderungsvormerkungen abrufen 461
C.10.2.7.6 SEPA-Dauereinzellastschriftlöschung464
C.10.2.8 Sonderformen von SEPA-Einzelaufträgen466
C.10.2.8.1 Eilzahlung (Urgent Payment)466
C.10.2.8.2 SEPA-Übertrag468
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel:
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:InhaltsverzeichnisStand: 07.08.2015Seite: 13
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
C.10.2.8.2.1 Bestand der möglichen Empfängerkonten abrufen468
C.10.2.8.2.2 SEPA-Überweisung auf ein Empfängerkonto..470
C.10.3 SEPA-Sammelaufträge474
C.10.3.1 SEPA-Sammelüberweisungen475
C.10.3.1.1 SEPA-Sammelüberweisung einreichen475
C.10.3.1.2 Terminierte SEPA-Sammelüberweisung478
C.10.3.1.2.1 Einreichung terminierter SEPA- Sammelüberweisungen478
C.10.3.1.2.2 Bestand terminierter SEPA- Sammelüberweisungen abrufen (Segmentversion 1)480
C.10.3.1.2.3 Löschung terminierter SEPA- Sammelüberweisungen484
C.10.3.2 SEPA-Sammellastschriften486
C.10.3.2.1 SEPA-Sammellastschrift einreichen486
C.10.3.2.2 Terminierte SEPA-Sammellastschriften487
C.10.3.2.2.1 Einreichung terminierter SEPA- Sammellastschrift (Segmentversion 1)487
C.10.3.2.2.2 Einreichung terminierter SEPA- Sammellastschrift (Segmentversion 2)490
C.10.3.2.2.3 Einreichung terminierter SEPA-COR1- Sammellastschrift492
C.10.3.2.2.4 Bestand terminierter SEPA- Sammellastschriften abrufen (Segmentversion 1)495
C.10.3.2.2.5 Löschung terminierter SEPA- Sammellastschriften498
C.10.3.3 SEPA-Firmensammellastschrift499
C.10.3.3.1 SEPA-Firmensammellastschrift einreichen500
C.10.3.3.2 Terminierte SEPA-Firmensammellastschrift
C.10.3.3.2.1 Einreichung terminierter SEPA- Firmensammellastschrift (Segmentversion 1)		.501
501
C.10.3.3.2.2 Einreichung terminierter SEPA- Firmensammellastschrift (Segmentversion 2).504
C.10.3.3.2.3 Bestand terminierter SEPA- Firmensammellastschriften abrufen (Segmentversion 1)507
C.10.3.3.2.4 Löschung terminierter SEPA- Firmensammellastschriften510
C.10.3.4 Sonderformen von SEPA-Sammelaufträgen512
C.10.3.4.1 Sammeleilzahlung (Urgent Payment)512
C.10.4 C-Transaktionen514
C.10.4.1 Auftragsdetails für C-Transaktionen514
C.10.4.2 Auslösen von C-Transaktionen516
C.10.4.3 SEPA-Statusreport517
C.10.5 SEPA Card Clearing Nachricht einreichen520
+ + + + + + + + + + + + + + + + +
Kapitel:Version: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 14Stand: 07.08.2015Kapitel: Inhaltsverzeichnis
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
D. Data Dictionary522
A522
B545
C554
D555
E560
F571
G577
H585
I587
J596
K597
L612
M616
N627
0636
P639
Q710
R711
S715
T729
U734
V739
W746
Z758
E. Anlagen1
E.1 Übersicht der Segmente1
E.2 Geschäftsvorfallunterstützung14
E.3 Berechnung der Prüfziffer für interne Zuordnungsdaten (Kunden- Referenznummer)21
E.3.1 Rechengang21
E.3.2 Beispiel 22
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel:
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:InhaltsverzeichnisStand: 07.08.2015Seite: 15
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
E.4 Länderkennzeichen und Währungscodes23
E.5 Europäische Kontenadressierung24
E.6 Liste der für SEPA integrierten Geschäftsvorfälle29
E.7 7 Beispiele für die eindeutige Belegung von camt.052-messages im HKCAZ33
E.7.1 HKCAZ ohne Aufsetzpunkt ohne vorgemerkte Umsätze34
E.7.2 HKCAZ mit Aufsetzpunkt in einem Buchungstag ohne vorgemerkte Umsätze37
E.7.3 HKCAZ mit Aufsetzpunkt zwischen den Buchungstagen inkl. vorgemerkter Umsätze40
+ + + + + + + + + + + + + + + + +
Kapitel:Version: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 16Stand: 07.08.2015Kapitel: Abbildungsverzeichnis
+ + +## Abbildungsverzeichnis + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Abbildung 1: Lebenszyklus Festgeld90
Abbildung 2: Verwendung von S.W.I.F.T.-Formaten im Wertpapiergeschäft109
Abbildung 3: Beispiel für den bankfachlichen Ablauf einer Wertpapierorder117
Abbildung 4: Beispiel für den bankfachlichen Ablauf einer Wertpapierorder123
Abbildung 5: Abfrage von Wertpapierinformationen.170
Abbildung 6: Abläufe bei terminierten SEPA-Überweisungen366
Abbildung 7: Lebenszyklus SEPA-Dauerauftrag380
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel:
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:AbkürzungenStand: 07.08.2015Seite: 17
+ + +## Abkürzungen + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
AbkürzungBedeutung
BPDBankparameterdaten
BZÜBeleggebundenes Zahlscheinüberweisungsformular
CDatenstruktur ist konditional
CRCarriage-Return (Wagenrücklauf)
DEDatenelement
DEGDatenelementgruppe
DKDie Deutsche Kreditwirtschaft (vormals ZKA)
DTAs. DTAUS
DTAUSDatensatzformat für den Inlandszahlungsverkehr (veröffentlicht in den Bedingungen für die Beteiligung von Kunden am beleglosen Daten- trägeraustausch mittels Disketten)
DTAZVDatensatzformat für den Auslandszahlungsverkehr
EDIFACTElectronic Data Interchange for Administration, Commerce and Transport
EWWUEuropäische Wirtschafts- und Währungsunion
GDGattungsdaten der Wertpapiermitteilungen
GDGruppendatenelement
GDGGruppendatenelementgruppe
HBCIHomebanking Computer Interface
IInformation (z.B. Schlüsselart)
IDIdentifikationsmerkmal (Nummer oder alphanumerischer Code)
ISINInternational Securities Identification Number
ISOInternational Organisation for Standardisation
LFLine-Feed (neue Zeile)
MDatenstruktur muss vorhanden sein und ist inhaltlich korrekt zu füllen
NNachricht
NNicht erlaubt (not allowed) (Datenstruktur darf nicht vorhanden sein)
ODatenstruktur ist optional
RFCRequest for Comment
SEGSegment
SEPASingle Euro Payments Area
SEQSequenznummer
SFSegmentfolge
S.W.I.F.T.Society for Worldwide Interbanking Financial Communication
TTransaktion (z.B. Schlüsselart)
UN/EDIFACTs. EDIFACT
UPDUserparameterdaten
+ + + + + + + + + + + + + + + + +
Kapitel:Version: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
18		Stand: 07.08.2015Kapitel: Abkürzungen
+ + + + + + + + + + + + + + + + + + + + + + + +
AbkürzungBedeutung
WMWertpapiermitteilungen
WKNWertpapierkennummer
WpHGWertpapierhandelsgesetz
ZKAZentraler Kreditausschuss (siehe DK)
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel:
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:LiteraturhinweiseStand: 07.08.2015Seite: 19
+ + +## Literaturhinweise + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
[Formals]Financial Transaction Services (FinTS) - Formals (Allgemeine Festlegungen für multibankfähige Online-Verfahren der deutschen Kreditwirtschaft), Version 3.0, 14.06.2011, Zentraler Kreditaus- schuss
[Messages]Financial Transaction Services (FinTS) - Messages (Multibankfä- hige Geschäftsvorfälle), Version 3.0, xx.xx.2015, Die Deutsche Kreditwirtschaft
[Messages-IZV]Financial Transaction Services (FinTS) - Messages-IZV (Mult- ibankfähige Geschäftsvorfälle für den Zahlungsverkehr Inland), Version 3.0, 28.05.2013, Die Deutsche Kreditwirtschaft
[Datenformate]siehe [Datenformate] in Financial Transaction Services (FinTS)- Hauptdokument, Version 4.1 final version, (zur Zeit in Erstellung), Die Deutsche Kreditwirtschaft
[DFÜ-Abkommen] Anlage 3 der Schnittstellenspezifikation für die Datenfernübertra- gung zwischen Kunde und Kreditinstitut gemäß DFÜ-Abkommen „Spezifikation der Datenformate“, in der jeweils höchsten Version, derzeit Version 2.8 - Die Deutsche Kreditwirtschaft
[HBCI]Financial Transaction Services (FinTS) - Security (Sicherheitsver- fahren HBCI), Version 3.0, 18.07.2013, Zentraler Kreditausschuss
[PIN/TAN]Financial Transaction Services (FinTS) - Security (Sicherheitsver- fahren PIN/TAN), Version 3.0, 27.10.2010, Zentraler Kredit- ausschuss
[Secoder]Financial Transaction Services (FinTS) - Security (Alternative Si- cherheitsverfahren), Version 3.0, 22.01.2013, Zentraler Kredit- ausschuss
[ISO 3166]ISO 3166-1:1996: Code for the representation of names of coun- tries and their subdivisions - Part 1: Country code [(http://www.din.de/gremien/nas/nabd/iso3166ma/](http://www.din.de/gremien/nas/nabd/iso3166ma/) oder http://www.unece.org/trade/lcode/loc99.zip)
[ISO 4217]ISO 4217:1995: Codes for the representation of currencies and funds
[Richtl. ZV]Richtlinien für einheitliche Zahlungsverkehrsvordrucke und Merk- blätter für neutrale Zahlungsverkehrsvordrucke
[ISO 6166]ISO 6166: International Securities Numbering System
[ISO 9362]ISO 9362: Bank Identifier Code (BIC)
+ + + + + + + + + + + + + + + + +
Kapitel:Version: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
20		Stand: 07.08.2015Kapitel: Literaturhinweise
+ + +[ISO 10383] + +ISO 10383: Market Identifier Code (MIC) + +[ISO 15022-1] + +ISO 15022-1:1999 Securities - Scheme for messages (Data Field +Dictionary) - Part 1: Data field and message design rules and +guidelines [(http://www.iso15022.org)](http://www.iso15022.org/) + +[ISO 15022-2] + +ISO 15022-2:1999 Securities - Scheme for messages (Data Field +Dictionary) - Part 2: Maintenance of the Data Field Dictionary and +Catalogue of Messages [(http://www.iso15022.org)](http://www.iso15022.org/) + +[TR 201] + +Register of European Account Numbers, Technical Report TR 201, +Version 2.1, hrsg. v. European Committee for Banking Standards, +September 1999 (http://www.ecbs.org/download/tr201v2.1.pdf) + +[IPI] +International Payment Instruction (IPI), Electronic Banking Stand- +ard EBS 206, Version 1.4, hrsg. v. European Committee for Bank- +ing Standards, November 1999 +([http://www.ecbs.org/download/ebs206v1.4.pdf)](http://www.ecbs.org/download/ebs206v1.4.pdf) + +[Laden GK] +HBCI - Homebanking Computer Interface - Laden der GeldKarte, +Konzept - Version 1.0, Zentraler Kreditausschuss, 17. Juli 2002 + +[ISIS/MTT] + +ISIS/MTT (Industrial Signature Interoperability and MailTrusT +Specification / MailTrusT) Version 1 - Part 1: Certificate and CRL +Profiles. + +[KT-KONZEPT] +Schnittstellenspezifikation für die ZKA-Chipkarte, Konzept für die +Unterstützung der Signatur-Anwendung der ZKA-Chipkarte durch +das Internet-Kundenterminal, Version 0.911.0, 30. November +200115. Februar 2002 + +[KT-SIG] +Schnittstellenspezifikation für die ZKA-Chipkarte, Spezifikation des +Internet-Kundenterminals für die Unterstützung der Signatur- +Anwendung der ZKA-Chipkarte (ZKA-SIG-API), Version Entwurf +1.093, 8047. JanuarJuliOktober 2002 + +[SCC] +Einreichen von Umsätzen im SCC-Format, Ergänzung zum Tech- +nischen Anhang zum Vertrag über die Zulassung als Netzbetreiber +im electronic cash-System der deutschen Kreditwirtschaft; in der +jeweils gültigen Version, derzeit 18.08.2014 + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel:
A
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:EinleitungStand: 07.08.2015Seite: 1
+ + +### A. EINLEITUNG + +Dieses Dokument beschreibt Geschäftsvorfälle zwischen Kunde und Bank, die in +multibankfähigen Online-Verfahren der deutschen Kreditwirtschaft zur Anwendung +kommen können. Dies sind z.Zt. + +• das Sicherheitsverfahren HBCI [HBCI], + +· Alternative Sicherheitsverfahren (Secoder) [Secoder] + +· und das Sicherheitsverfahren PIN/TAN [PIN/TAN]. + +Die syntaktische Abbildung dieser Geschäftsvorfälle ist von der konkreten Schnitt- +stelle abhängig und dort beschrieben. In den jeweiligen Schnittstellenspezifikationen +befinden sich Beispiele zur Abbildung der Geschäftsvorfälle in eine konkrete Syntax. + +Die Datenbeschreibungskonventionen (z.B. Datentypen) sind in [Formals] erläutert. + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: B
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Mehrfach verwendete Elemente
Betrag		Stand: 07.08.2015Seite: 3
+ + +### B. MEHRFACH VERWENDETE ELEMENTE + +Um wiederholt auftretende Strukturen von Datenelementen definieren zu können, +werden diese zu 'mehrfach verwendeten Elementen' (MVE) zusammengefasst. + +Es ist zu beachten, dass es sich bei den mehrfach verwendeten Elementen nicht um +syntaktische Elemente (z.B. Datenelementgruppen) handelt. Vielmehr treten diese +lediglich in identischer Reihenfolge und Formatierung stets gemeinsam auf. + + +#### B.1 Betrag + + +##### . Beschreibung + +Jeder Wertbetrag wird zusammen mit einem Währungskennzeichen gemäß ISO +4217 (alphabetischer Code) übertragen. + + +##### . Format + + + + + + + + + + + + + + + + + + + +
Name:Betrag
Typ:Mehrfach verwendetes Element
Kennung:btg
Version:1
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Wert1DEwrt#M1
2Währung1DEcur#M1
+ + +#### B.2 Kreditinstitutskennung + + +##### . Beschreibung + +Anhand dieses Formats können sowohl deutsche als auch internationale Kreditinsti- +tute identifiziert werden. + + +##### . Format + + + + + + + + + + + + + + + + + + + +
Name:Kreditinstitutskennung
Typ:Mehrfach verwendetes Element
Kennung:kik
Version:1
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Länderkennzeichen1DEctr#M1
2Kreditinstitutscode1DEan.30C1M: Im angegebenen Land existieren Kreditinsti- tutscodes N: sonst
+ + +#### B.3 Kontoverbindung + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
4		Stand: 07.08.2015Kapitel: Mehrfach verwendete Elemente
Abschnitt: Kontoverbindung
+ + +##### B.3.1 Kontoverbindung + + +###### . Beschreibung + +Anhand dieses Formats können sowohl deutsche als auch internationale Bankver- +bindungen beschrieben werden. Die Belegung für wichtige europäische Länder ist +dem Kapitel E.5 zu entnehmen. + +Falls bei einem Institut unter einer Kontonummer verschiedene Konten mit unter- +schiedlichen Merkmalen geführt werden (z.B. verschiedene Währungen oder Fest- +geldanlagen), wird von diesem Institut in den UPD zu jeder dieser Kontonummern +zur Unterscheidung zusätzlich ein ,,Unterkontomerkmal" angegeben. Dieser ist dann +bei jeder Auftraggeberkontoverbindung anzugeben. + + +![](figures/24.1) + + +Den Herstellern von Kundensystemen wird empfohlen, eine Bank- +leitzahlendatenbank zu hinterlegen, um eine Plausibilitätsprüfung +von Bankleitzahlen und eventuell auch Kontonummern zu ermög- +lichen und den Kunden ggf. Bankleitzahlen über Auswahl des Kre- +ditinstitutnamens ermitteln zu lassen. + + +###### . Format + + + + + + + + + + + + + + + + + + + +
Name:Kontoverbindung
Typ:Mehrfach verwendetes Element
Kennung:ktv
Version:3
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Konto- /Depotnummer1DEid#M1
2Unterkontomerkmal1DEid#C1M: bei ,,Kontoverbindung Auftraggeber", wenn vom Institut in den UPD ange- geben N: sonst
3Kreditinstitutsken- nung1DEGkik#M1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: B
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Kontoverbindung
Mehrfach verwendete Elemente		Stand: 07.08.2015Seite: 5
+ + +##### B.3.2 Kontoverbindung international + +Die Kontoverbindung international dient zur Verwendung von IBAN und BIC sowie +auch der nationalen Elemente Kreditinstitutskennung und Konto-/Depotnummer mit +optionalem Unterkontomerkmal, strukturell angelehnt an das Aggregate ,,Account" in +ISO20022. + +. Format + + + + + + + + + + + + + + + + + + + +
Name:Kontoverbindung international
Typ:Mehrfach verwendetes Element
Kennung:kti
Version:1
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1IBAN1DEan.34O1
2BIC1DEan..11O1
3Konto- /Depotnummer1DEid#O1
4Unterkontomerkmal1DEid#O1
5Kreditinstitutsken- nung1DEGkik#O1
+ + +### . Belegungsrichtlinien + + +#### Kontoverbindung international + +Abhängig vom Geschäftsvorfall gelten entweder die Vorgaben, welche durch +HKSPA zuvor ermittelt wurden oder das Kundenprodukt kann frei auswählen (z. B. +bei fremden Konten, für die internationale und / oder die nationale Kontoverbindung +zur Verfügung steht). + +Folgende Belegungen sind möglich: + +1\. Internationale Kontoverbindung + +Falls das Datenelement IBAN belegt ist, so muss auch das Daten- +element BIC belegt sein. + +2\. Nationale Kontoverbindung + +In diesem Fall sind die Datenelemente Kreditinstitutskennung und +Konto-/Depotnummer zu belegen; das DE Unterkontomerkmal ist op- +tional belegbar. + +3\. Internationale und nationale Kontoverbindung + +Hier gelten die unter 1. und 2. gemachten Belegungsrichtlinien im +übertragenen Sinn. + +Ist der BPD-Parameter ,,Nationale Kontoverbindung erlaubt" in HISPAS mit ,,N" be- +legt, so darf nur die internationale Kontoverbindung durch IBAN und BIC verwendet +werden. + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
6		Stand: 07.08.2015Kapitel: Mehrfach verwendete Elemente
Abschnitt: Saldo
+ + +## B.3.3 Kontoverbindung ZV international + +Die Kontoverbindung ZV international dient zur Verwendung von IBAN und BIC im +Bereich der SEPA-Zahlungsverkehrsinstrumente sowie - über BPD-Parameter +steuerbar - auch der nationalen Elemente Kreditinstitutskennung und Konto- +/Depotnummer mit optionalem Unterkontomerkmal. + + +### . Format + + + + + + + + + + + + + + + + + + + +
Name:Kontoverbindung ZV international
Typ:Mehrfach verwendetes Element
Kennung:ktz
Version:1
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVers- ionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Kontoverwendung SEPA1DEjn#M1
2IBAN1DEan..34C1M: wenn ,,Kontoverwendung SEPA“=“J“ „leer": sonst
3BIC1DEan..11C1M: wenn ,,Kontoverwendung SEPA"="J" „leer“: sonst
4Konto- /Depotnummer1DEid#M1
5Unterkontomerkmal1DEid#C1M: wenn ,,vom Institut in den UPD angegeben „N“: sonst
6Kreditinstitutsken- nung1DEGkik#M1
+ + +![](figures/26.1) + + +![](figures/26.2) + + +Bei Verwendung des Unterkontomerkmals in Kontoverbindungen +muss Konsistenz sichergestellt sein: Ein Unterkontomerkmal muss +auf einheitliche Weise in den UPD und in HKSPA / HISPA enthal- +ten sein. + + +## B.4 Saldo + + +### . Beschreibung + +Kontostand zum aktuellen oder zu einem vergangenen Zeitpunkt, welcher sich als +Unterschiedsbetrag zwischen der Soll- und Haben-Seiten des Kontos bis dato +ergibt. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: B
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Mehrfach verwendete Elemente
Adresse		Stand: 07.08.2015Seite: 7
+ + +### . Format + + + + + + + + + + + + + + + + + + + +
Name:Saldo
Typ:Mehrfach verwendetes Element
Kennung:sdo
Version:2
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Soll-Haben- Kennzeichen2DEcode1M1C, D
2Betrag1DEGbtg#M1
3Datum1DEdat#M1
4Uhrzeit1DEtim#O1
+ + +## B.5 Adresse + + +### . Format + + + + + + + + + + + + + + + + + + + +
Name:Adresse
Typ:Mehrfach verwendetes Element
Kennung:addr
Version:2
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Name 11DEan.35M1
2Name 21DEan.35O1
3Straße/Postfach1DEan..35M1
4PLZ1DEan.10M1
5Ort1DEan..35M1
6Land1DEctr#O1
7Telefon1DEan.35O1
8Telefax-Nummer1DEan..35O1
9Email-Adresse1DEan..35O1
+ + +## B.6 Zeitstempel + + +### . Beschreibung + +Diese Struktur enthält eine Zeitangabe, bestehend aus Datum und optional Uhrzeit. + +. Format + + + + + + + + + + + + + + + + + + + +
Name :Zeitstempel
Typ:Mehrfach verwendetes Element
Kennung:tsp
Version:1
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Datum1DEdat#M1
2Uhrzeit1DEtim#O1
+ + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
8		Stand: 07.08.2015Kapitel: Mehrfach verwendete Elemente
Abschnitt: Börsenkurs
+ + +## B.7 Börsenkurs + +. Format + + + + + + + + + + + + + + + + + + + +
Name :Börsenkurs
Typ:Mehrfach verwendetes Element
Kennung:rate
Version:1
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Kurs1DEwrt#M1
2Währung der Kurs- notierung1DEcur#C1M: bei betragsnotierten Pa- pieren
N: bei prozentnotierten Pa- pieren
3Kurszusatz1DEan.5O1
4Datum1DEdat#M1
5Uhrzeit1DEtim#O1
6Börsenplatz1DEan4O1
+ + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Geschäftsvorfälle Zahlungsverkehr InlandStand: 07.08.2015Seite: 9
+ + +## C. GESCHÄFTSVORFÄLLE + + +### C.1 Zahlungsverkehr Inland + +Die Beschreibung des Inlandszahlungsverkehrs findet sich im Band [Messages- +IZV]. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
10		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Konto- und Umsatz-Informationen
+ + +### C.2 Konto- und Umsatz-Informationen + + +#### C.2.1 Umsatz-Informationen (SWIFT MT-Formate) + + +![](figures/30.1) + + +Hinweis zur Verwendung der erweiterten MT94x-Formate: + +Die SEPA-Erweiterungen der MT94x-Formate (s. [Datenformate]) +gilt für alle derzeit gültigen Segmentversionen, um alte Kundenpro- +dukte SEPA-konform erreichen zu können. Es kann nur bei un- +strukturierter Verwendung des Feld :86: zu 100% sichergestellt +werden, dass keine Probleme bei alten Kundenprodukten auftreten +können. Eine Verwendung der strukturierten Belegung kann trotz +durchgeführter intensiver Tests mit älteren Versionen in einigen +Fällen zu Fehlverhalten führen. + + +#### C.2.1.1Kontoumsätze + +Kontoumsätze werden als S.W.I.F.T. MT 940 bzw. MT 942 ausgestellt. Es wird drin- +gend empfohlen, die in [Datenformate] aufgeführten Belegungsrichtlinien zu ver- +wenden. Auf die Verwendung des vom HBCI-Zeichensatz abweichenden S.W.I.F.T.- +Zeichensatzes ist zu achten. + +Neben Kontokorrentkonten können diese Formate auch zur Anzeige der Umsätze +anderer Kontoarten (z.B. Sparkonten, Kreditkartenkonten, Währungskonten) genutzt +werden. + + +![](figures/30.2) + + +Das Kundenprodukt muss damit rechnen, dass Umsätze auch in +Fremdwährung (nicht EUR) geliefert werden können (z.B. bei der +Abfrage von Währungskonten). + + +#### C.2.1.1.1 Kontoumsätze/Zeitraum + + +##### C.2.1.1.1.1 Segmentversion 6 + +Realisierung Bank: +verpflichtend, falls auch ,Kontoumsätze/neue Umsätze“ ange- +boten wird, sonst optional + +Realisierung Kunde: +verpflichtend, falls auch "Kontoumsätze/neue Umsätze“ ange- +boten wird, sonst optional + + +### a) Kundenauftrag + + +### . Beschreibung + +Die Lösung bietet dem Kunden die Möglichkeit, auf seinem System verlorengegan- +gene Buchungen erneut zu erhalten. + +Die maximale Anzahl der rückzumeldenden Buchungspositionen kann begrenzt +werden. Eine Buchungsposition besteht aus einem :61:/:86:-Block eines MT 940- +Formats. Es muss davon unabhängig immer ein gültiges MT 940-Format zurückge- + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle Konto- und Umsatz-InformationenStand: 07.08.2015Seite: 11
+ + +meldet werden, d.h. die Felder :20: bis :60: und :62: bis :86: sind obligatorischer Be- +standteil der Rückmeldung. + +Der maximale Zeitraum, für den rückwirkend Buchungen beim Kreditinstitut gespei- +chert sind, wird in den Bankparameterdaten übermittelt. + + +![](figures/31.1) + + +Mit Hilfe der Option ,,Alle Konten" kann im Kundenprodukt ein Fi- +nanzstatus des Kunden (Überblick über alle Geld- und Finanzan- +lagen) realisiert werden. Zu diesem Finanzstatus zählen jedoch +nur diejenigen Konten, die im Kreditinstitut für diesen Kunden ge- +führt werden und zu denen ein Saldo angegeben werden kann. In +der Praxis zählen jedoch oftmals bestimmte Konten für den Kun- +den nicht zum Finanzstatus (z.B. Konten, für die der Kunde ledig- +lich bevollmächtigt ist), andere fehlen jedoch, wie z.B. Konten zu +denen kein Saldo existiert (Wertpapierkonten) oder Konten, die bei +anderen Instituten geführt werden. + +In diesem Fall kann der Finanzstatus vom Kundenprodukt durch +Hintereinanderschaltung mehrerer Saldenabfragen zu jeweils ein- +zelnen Konten erzeugt werden. Dieser Finanzstatus kann auch +Konten verschiedener Kreditinstitute umfassen, indem mehrere +HBCI-Dialoge mit verschiedenen Instituten automatisch nachei- +nander durchgeführt werden. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoumsätze anfordern/Zeitraum
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKKAZ
Bezugssegment:-
Version:6
Sender:Kunde
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
12		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt:
Konto- und Umsatz-Informationen
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung Auftraggeber2DEGktv#M1
3Alle Konten1DEjn#M1
4Von Datum1DEdat#O1
5Bis Datum1DEdat#O1
6Maximale Anzahl Einträge1DEnum..4C1>0
O: ,,Eingabe Anzahl Ein- träge erlaubt“ (BPD) = „J“ N: sonst
7Aufsetzpunkt1DEan..35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +### . Belegungsrichtlinien + + +#### Kontoverbindung Auftraggeber + +Falls unter einer Kontonummer verschiedene Währungskonten geführt wer- +den, kann im Feld „Unterkontomerkmal" durch Angabe des ISO- +Währungscodes eine Einschränkung erfolgen, um das entsprechende Konto +zu identifizieren. + +Falls die Option ,,Alle Konten" gewählt wird, ist eine beliebige Konto- +verbindung des Kunden einzustellen. + + +### b) Kreditinstitutsrückmeldung + + +#### . Beschreibung + +Die Online-Antwort des Kreditinstituts enthält unmittelbar die gemäß Anfragezeit- +raum zusammengestellten Kontoumsätze. Eine erst spätere Bereitstellung der Kon- +toumsätze ist wegen der dazu erforderlichen erneuten Anwahl nicht praktikabel. + +Es werden stets sämtliche Umsätze des Starttages "Von Datum" in die Kontoumsät- +ze eingestellt, auch wenn diese ganz oder teilweise mit einem vorangegangenen +Auszug abgeholt wurden. Dies ermöglicht eine fehlerfreie Eliminierung von mehr- +fach abgeholten Buchungen durch das Kundensystem. + +Falls der Kunde ,,Alle Konten" gewählt hat, wird das Segment für jedes Konto, für +das Umsätze angegeben werden können, jeweils einmal eingestellt. + + +![](figures/32.1) + + +Es ist zu beachten, dass im Falle einer Umstellung der Kontowäh- +rung, die in den Abrufzeitraum fällt, innerhalb einer Umsatzabfrage +sowohl Umsätze in der bisherigen Währung als auch Umsätze in +der neuen Währung (getrennt nach Buchungstagen) zurückgemel- +det werden können. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle Konto- und Umsatz-InformationenStand: 07.08.2015Seite: 13
+ + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoumsätze rückmelden/Zeitraum
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIKAZ
Bezugssegment:HKKAZ
Version:6
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Gebuchte Umsätze1DEbin..M1
3Nicht gebuchte Umsätze1DEbin..O1
+ + +### . Belegungsrichtlinien + + +#### Gebuchte Umsätze + +Es ist das S.W.I.F.T.-Format MT 940 in der Version ,,SRG 2001" (s. [Daten- +formate]) einzustellen. + + +#### Nicht Gebuchte Umsätze + +Es ist das S.W.I.F.T.-Format MT 942 in der Version ,,SRG 2001" (s. [Daten- +formate]) einzustellen. + + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
3010Es liegen keine Einträge vor
3040Auftrag nur teilweise ausgeführt
9210Bereichende darf nicht vor Bereichanfang liegen
9210Datum muss in der Vergangenheit liegen
9210Keine gültige Kontoverbindung des Kunden
+ + +### c) Bankparameterdaten + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoumsätze/Zeitraum Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIKAZS
Bezugssegment:HKVVB
Version:6
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
14		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt:
Konto- und Umsatz-Informationen
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Konto- umsätze/Zeitraum2DEGM1
+ + +##### C.2.1.1.1.2 Segmentversion 7 (SEPA) + + + + + + + + + + + +
Realisierung Bank:verpflichtend, falls auch ,,Kontoumsätze/neue Umsätze“ ange- boten wird, sonst optional
Realisierung Kunde:verpflichtend, falls auch ,Kontoumsätze/neue Umsätze“ ange- boten wird, sonst optional
+ + +### a) Kundenauftrag + + +#### . Beschreibung + +Die Lösung bietet dem Kunden die Möglichkeit, auf seinem System verlorengegan- +gene Buchungen erneut zu erhalten. + +Die maximale Anzahl der rückzumeldenden Buchungspositionen kann begrenzt +werden. Eine Buchungsposition besteht aus einem :61:/:86:-Block eines MT 940- +Formats. Es muss davon unabhängig immer ein gültiges MT 940-Format zurückge- +meldet werden, d.h. die Felder :20: bis :60: und :62: bis :86: sind obligatorischer Be- +standteil der Rückmeldung. + +Der maximale Zeitraum, für den rückwirkend Buchungen beim Kreditinstitut gespei- +chert sind, wird in den Bankparameterdaten übermittelt. + + +![](figures/34.1) + + +Mit Hilfe der Option ,,Alle Konten" kann im Kundenprodukt ein Fi- +nanzstatus des Kunden (Überblick über alle Geld- und Finanzan- +lagen) realisiert werden. Zu diesem Finanzstatus zählen jedoch +nur diejenigen Konten, die im Kreditinstitut für diesen Kunden ge- +führt werden und zu denen ein Saldo angegeben werden kann. In +der Praxis zählen jedoch oftmals bestimmte Konten für den Kun- +den nicht zum Finanzstatus (z.B. Konten, für die der Kunde ledig- +lich bevollmächtigt ist), andere fehlen jedoch, wie z.B. Konten zu +denen kein Saldo existiert (Wertpapierkonten) oder Konten, die bei +anderen Instituten geführt werden. + +In diesem Fall kann der Finanzstatus vom Kundenprodukt durch +Hintereinanderschaltung mehrerer Saldenabfragen zu jeweils ein- +zelnen Konten erzeugt werden. Dieser Finanzstatus kann auch +Konten verschiedener Kreditinstitute umfassen, indem mehrere +HBCI-Dialoge mit verschiedenen Instituten automatisch nachei- +nander durchgeführt werden. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle
Konto- und Umsatz-Informationen		Stand: 07.08.2015Seite: 15
+ + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoumsätze anfordern/Zeitraum
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKKAZ
Bezugssegment:-
Version:7
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3Alle Konten1DEjn#M1
4Von Datum1DEdat#O1
5Bis Datum1DEdat#O1
6Maximale Anzahl Einträge1DEnum.4C1>0
O: ,,Eingabe Anzahl Ein- träge erlaubt“ (BPD) = „J“ N: sonst
7Aufsetzpunkt1DEan..35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +### . Belegungsrichtlinien + + +#### Kontoverbindung international + +Falls unter einer Kontonummer verschiedene Währungskonten geführt werden, +kann im Feld ,,Unterkontomerkmal" durch Angabe des ISO-Währungscodes eine +Einschränkung erfolgen, um das entsprechende Konto zu identifizieren. + +Falls die Option „Alle Konten“ gewählt wird, ist eine beliebige Kontoverbindung des +Kunden einzustellen. + + +### b) Kreditinstitutsrückmeldung + + +### . Beschreibung + +Die Online-Antwort des Kreditinstituts enthält unmittelbar die gemäß Anfragezeit- +raum zusammengestellten Kontoumsätze. Eine erst spätere Bereitstellung der Kon- +toumsätze ist wegen der dazu erforderlichen erneuten Anwahl nicht praktikabel. + +Es werden stets sämtliche Umsätze des Starttages "Von Datum" in die Kontoumsät- +ze eingestellt, auch wenn diese ganz oder teilweise mit einem vorangegangenen +Auszug abgeholt wurden. Dies ermöglicht eine fehlerfreie Eliminierung von mehr- +fach abgeholten Buchungen durch das Kundensystem. + +Falls der Kunde ,,Alle Konten" gewählt hat, wird das Segment für jedes Konto, für +das Umsätze angegeben werden können, jeweils einmal eingestellt. + + +![](figures/35.1) + + +Es ist zu beachten, dass im Falle einer Umstellung der Kontowäh- +rung, die in den Abrufzeitraum fällt, innerhalb einer Umsatzabfrage +sowohl Umsätze in der bisherigen Währung als auch Umsätze in +der neuen Währung (getrennt nach Buchungstagen) zurückgemel- +det werden können. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
16		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Konto- und Umsatz-Informationen
+ + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoumsätze rückmelden/Zeitraum
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIKAZ
Bezugssegment:HKKAZ
Version:7
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Gebuchte Umsätze1DEbin.M1
3Nicht gebuchte Umsätze1DEbin..O1
+ + +### . Belegungsrichtlinien + + +#### Gebuchte Umsätze + +Es ist das S.W.I.F.T.-Format MT 940 in der Version ,SRG 2001" (s. [Datenformate]) +mit den beschriebenen Belegungen für SEPA einzustellen. + + +#### Nicht Gebuchte Umsätze + +Es ist das S.W.I.F.T.-Format MT 942 in der Version ,,SRG 2001“ (s. [Datenformate]) +mit den beschriebenen Belegungen für SEPA einzustellen. + + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
3010Es liegen keine Einträge vor
3040Auftrag nur teilweise ausgeführt
9210Bereichende darf nicht vor Bereichanfang liegen
9210Datum muss in der Vergangenheit liegen
9210Keine gültige Kontoverbindung des Kunden
+ + +### c) Bankparameterdaten + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoumsätze/Zeitraum Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIKAZS
Bezugssegment:HKVVB
Version:7
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer-TypFor-Län-Sta-An-Restriktionen
sionmatgetuszahl
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Geschäftsvorfälle Konto- und Umsatz-InformationenStand: 07.08.2015Seite: 17
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Konto- umsätze/Zeitraum2DEGM1
+ + +##### C.2.1.1.2 Kontoumsätze/neue Umsätze + + +###### C.2.1.1.2.1 Segmentversion 6 + +Realisierung Bank: + +optional + +Realisierung Kunde: optional + + +### a) Kundenauftrag + + +#### . Beschreibung + +Das Abholen der neuen Kontoumsätze bietet gegenüber dem Abholen per Zeitrau- +mangabe den Vorteil, dass sichergestellt ist, dass im Kundensystem Buchungen +nicht doppelt erfasst werden. Zudem wird die kreditinstitutsseitig vorzuhaltende Da- +tenmenge minimiert. Grundlage für die Bestimmung, welche Umsätze als 'neu' zu +betrachten sind, ist stets der letzte Umsatzabruf, der auf Basis des Geschäftsvorfalls +„Kontoumsätze/neue Umsätze“ vorgenommen wurde. + +Dieser Geschäftsvorfall stellt eine Übergangslösung bis zur Verfügbarkeit des HGB- +konformen ,,Elektronischen Kontoauszugs“ dar. + +Der maximale Zeitraum, für den rückwirkend Buchungen beim Kreditinstitut gespei- +chert sind, wird in den Bankparameterdaten übermittelt. + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoumsätze anfordern/neue Umsätze
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKKAN
Bezugssegment:-
Version:6
Sender:Kunde
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
18		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt:
Konto- und Umsatz-Informationen
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Kontoverbindung Auftraggeber2DEGktv#M1
3Alle Konten1DEjn#M1
4Maximale Anzahl Einträge1DEnum..4C1>0
O: ,,Eingabe Anzahl Ein- träge erlaubt“ (BPD) = „J“ N: sonst
5Aufsetzpunkt1DEan..35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +### . Belegungsrichtlinien + + +#### Kontoverbindung Auftraggeber + +Falls unter einer Kontonummer verschiedene Währungskonten geführt wer- +den, kann im Feld „Unterkontomerkmal" durch Angabe des ISO- +Währungscodes eine Einschränkung erfolgen, um das entsprechende Konto +zu identifizieren. + +Falls die Option ,,Alle Konten" gewählt wird, ist eine beliebige Konto- +verbindung des Kunden einzustellen. + + +### b) Kreditinstitutsrückmeldung + + +#### . Beschreibung + +Falls der Kunde ,,Alle Konten" gewählt hat, wird das Segment für jedes Konto, für +das Umsätze angegeben werden können, jeweils einmal eingestellt. + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoumsätze rückmelden/neue Umsätze
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIKAN
Bezugssegment:HKKAN
Version:6
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Gebuchte Umsätze1DEbin..M1
3Nicht gebuchte Umsätze1DEbin..O1
+ + +#### . Belegungsrichtlinien + + +#### Gebuchte Umsätze + +Es ist das S.W.I.F.T.-Format MT 940 in der Version ,,SRG 2001" (s. [Daten- +formate]) einzustellen. + + +#### Nicht Gebuchte Umsätze + +Es ist das S.W.I.F.T.-Format MT 942 in der Version ,,SRG 2001" (s. [Daten- +formate]) einzustellen. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Geschäftsvorfälle Konto- und Umsatz-InformationenStand: 07.08.2015Seite: 19
+ + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
3010Es liegen keine Einträge vor
3040Auftrag nur teilweise ausgeführt
9210Keine gültige Kontoverbindung des Kunden
+ + +### c) Bankparameterdaten + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoumsätze/neu Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIKANS
Bezugssegment:HKVVB
Version:6
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Konto- umsätze/neu1DEGM1
+ + +##### C.2.1.1.2.2 Segmentversion 7 (SEPA) + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +### a) Kundenauftrag + + +#### . Beschreibung + +Das Abholen der neuen Kontoumsätze bietet gegenüber dem Abholen per Zeitrau- +mangabe den Vorteil, dass sichergestellt ist, dass im Kundensystem Buchungen +nicht doppelt erfasst werden. Zudem wird die kreditinstitutsseitig vorzuhaltende Da- +tenmenge minimiert. Grundlage für die Bestimmung, welche Umsätze als 'neu' zu +betrachten sind, ist stets der letzte Umsatzabruf, der auf Basis des Geschäftsvorfalls +„Kontoumsätze/neue Umsätze" vorgenommen wurde. + +Dieser Geschäftsvorfall stellt eine Übergangslösung bis zur Verfügbarkeit des HGB- +konformen ,,Elektronischen Kontoauszugs" dar. + +Der maximale Zeitraum, für den rückwirkend Buchungen beim Kreditinstitut gespei- +chert sind, wird in den Bankparameterdaten übermittelt. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
20		Stand:
07.08.2015		Kapitel: Geschäftsvorfälle
Abschnitt: Konto- und Umsatz-Informationen
+ + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoumsätze anfordern/neue Umsätze
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKKAN
Bezugssegment:-
Version:7
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3Alle Konten1DEjn#M1
4Maximale Anzahl Einträge1DEnum..4C1>0
O: ,,Eingabe Anzahl Ein- träge erlaubt“ (BPD) = „J“ N: sonst
5Aufsetzpunkt1DEan..35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +### . Belegungsrichtlinien + + +#### Kontoverbindung international + +Falls unter einer Kontonummer verschiedene Währungskonten geführt werden, +kann im Feld ,,Unterkontomerkmal“ durch Angabe des ISO-Währungscodes eine +Einschränkung erfolgen, um das entsprechende Konto zu identifizieren. + +Falls die Option „Alle Konten“ gewählt wird, ist eine beliebige Kontoverbindung des +Kunden einzustellen. + + +### b) Kreditinstitutsrückmeldung + + +#### . Beschreibung + +Falls der Kunde ,,Alle Konten" gewählt hat, wird das Segment für jedes Konto, für +das Umsätze angegeben werden können, jeweils einmal eingestellt. + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoumsätze rückmelden/neue Umsätze
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIKAN
Bezugssegment:HKKAN
Version:7
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle Konto- und Umsatz-InformationenStand: 07.08.2015Seite: 21
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Gebuchte Umsätze1DEbin..M1
3Nicht gebuchte Umsätze1DEbin..O1
+ + +### . Belegungsrichtlinien + + +#### Gebuchte Umsätze + +Es ist das S.W.I.F.T.-Format MT 940 in der Version ,,SRG 2001“ (s. [Datenformate]) +mit den beschriebenen Belegungen für SEPA einzustellen. + + +#### Nicht Gebuchte Umsätze + +Es ist das S.W.I.F.T.-Format MT 942 in der Version ,,SRG 2001“ (s. [Datenformate]) +mit den beschriebenen Belegungen für SEPA einzustellen. + + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
3010Es liegen keine Einträge vor
3040Auftrag nur teilweise ausgeführt
9210Keine gültige Kontoverbindung des Kunden
+ + +### c) Bankparameterdaten + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoumsätze/neu Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIKANS
Bezugssegment:HKVVB
Version:7
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Konto- umsätze/neu1DEGM1
+ + +# C.2.1.1.3 Kontoauszug + + +## C.2.1.1.3.1 Segmentversion 1 + +Dieser Geschäftsvorfall eignet sich beim Homebanking zur Realisierung des ,,Elek- +tronischen Kontoauszugs". Die rechtlichen und geschäftspolitischen Voraussetzun- +gen für den ,,Elektronischen Kontoauszug" sind ggf. in separaten Dokumenten zu +beschreiben. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
22		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Konto- und Umsatz-Informationen
+ + +Der Kontoauszug enthält alle Umsätze, die seit dem letzten Ausdruck eines Konto- +auszugs (am Kontoauszugdrucker bzw. als elektronischer Kontoauszug) für das je- +weilige Konto angefallen sind. Im Gegensatz zu den Kontoumsätzen (s. Kap. +C.2.1.1.1 u. C.2.1.1.1.2) enthält der Kontoauszug keine nicht-gebuchten Umsätze. + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +### a) Kundenauftrag + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoauszug anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKEKA
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung Auftraggeber2DEGktv#M1
3Kontoauszugsfor- mat3DEcode1O1gemäß BPD zugelassene Formate
4Kontoauszugs- nummer1DEnum..5O1
5Maximale Anzahl Einträge1DEnum..4C1>0
O: ,,Eingabe Anzahl Ein- träge erlaubt“ (BPD) = „J“ N: sonst
6Aufsetzpunkt1DEan.35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +### . Belegungsrichtlinien + + +#### Kontoauszugsformat + +Falls das Kreditinstitut laut Bankparameterdaten mehrere Kontoauszugfor- +mate anbietet, kann der Kunde das gewünschte Format wählen. + + +#### Kontoauszugsnummer + +Falls das Kreditinstitut den Abruf historischer Kontoauszüge unterstützt, kann +der Kunde hier die Nummer eines bereits gedruckten Auszugs angeben, um +den Auszug erneut zu erhalten. Bleibt das Feld leer, so wird stets der aktuel- +le Auszug angefordert. Falls die Auszugsnummer nicht existiert, wird der +Auftrag abgelehnt. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle
Konto- und Umsatz-Informationen		Stand: 07.08.2015Seite: 23
+ + +##### b) Kreditinstitutsrückmeldung + + +###### . Format + +Name: +Kontoauszug +Typ: +Segment +Segmentart: +Geschäftsvorfall +Kennung: +HIEKA +Bezugssegment: +HKEKA +Version: +1 +Anzahl: +1 +Sender: +Kreditinstitut + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoauszugsfor- mat3DEcode1M11, 2, 3
3Berichtszeitraum1DEGM1
4Gebuchte Umsätze1DEbin..M1
5Informationen zum Rechnungsab- schluss1DEtxt.٠
2048		O1
6Informationen zu Kundenbedingun- gen2DEtxt.٠ 2048O1
7Werbetext1DEtxt" 2048O1
8Quittungscode1DEbin..O1
+ + +###### ◆ Erläuterungen + + +####### Gebuchte Umsätze + +Die gebuchten Umsätze sind im vom Kunden gewählten Format einzustellen. +Bei Einstellung im Format MT 940 ist die Version ,,SRG 2001" (s. [Daten- +formate]) zu verwenden. + + +###### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
3010Es liegen keine Einträge vor
3040Auftrag nur teilweise ausgeführt
9210Keine gültige Kontoverbindung des Kunden
+ + +##### c) Bankparameterdaten + + +###### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoauszug Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIEKAS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
24		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Konto- und Umsatz-Informationen
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Konto- auszug2DEGM1
+ + +## C.2.1.1.3.2 Segmentversion 2 + +Dieser Geschäftsvorfall eignet sich beim Homebanking zur Realisierung des ,,Elek- +tronischen Kontoauszugs". Die rechtlichen und geschäftspolitischen Voraussetzun- +gen für den „Elektronischen Kontoauszug" sind ggf. in separaten Dokumenten zu +beschreiben. + +Der Kontoauszug enthält alle Umsätze, die seit dem letzten Ausdruck eines Konto- +auszugs (am Kontoauszugdrucker bzw. als elektronischer Kontoauszug) für das je- +weilige Konto angefallen sind. Im Gegensatz zu den Kontoumsätzen enthält der +Kontoauszug keine nicht-gebuchten Umsätze. + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +### a) Kundenauftrag + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoauszug anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKEKA
Bezugssegment:-
Version:2
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle Konto- und Umsatz-InformationenStand: 07.08.2015Seite: 25
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung Auftraggeber2DEGktv#M1
3Kontoauszugsfor- mat3DEcode1O1gemäß BPD zugelassene Formate
4Kontoauszugs- nummer1DEnum..5O1
5Maximale Anzahl Einträge1DEnum..4C1>0
O: ,,Eingabe Anzahl Ein- träge erlaubt“ (BPD) = „J“ N: sonst
6Aufsetzpunkt1DEan.35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +### . Belegungsrichtlinien + + +#### Kontoauszugsformat + +Falls das Kreditinstitut laut Bankparameterdaten mehrere Kontoauszugformate an- +bietet, kann der Kunde das gewünschte Format wählen. + + +#### Kontoauszugsnummer + +Falls das Kreditinstitut den Abruf historischer Kontoauszüge unterstützt, kann der +Kunde hier die Nummer eines bereits gedruckten Auszugs angeben, um den Aus- +zug erneut zu erhalten. Bleibt das Feld leer, so wird stets der aktuelle Auszug ange- +fordert. Falls die Auszugsnummer nicht existiert, wird der Auftrag abgelehnt. + + +### b) Kreditinstitutsrückmeldung + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoauszug
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIEKA
Bezugssegment:HKEKA
Version:2
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
26		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Konto- und Umsatz-Informationen
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFormatLängeSta- tusAnzahlRestriktionen
1Segmentkopf1DEGM1
2Kontoauszugsfor- mat3DEcode1M11, 2, 3
3Berichtszeitraum1DEGM1
4Gebuchte Umsätze1DEbin..M1
5Informationen zum Rechnungsab- schluss2DEtxt.65536O1
6Informationen zu Kundenbedingun- gen3DEtxt.65536O1
7Werbetext2DEtxt.65536O1
8IBAN Konto1DEan..34O1
9BIC Konto1DEan..11O1
10Auszugsname 11DEan.35O1
11Auszugsname 21DEan.35O1
12Namenszusatz1DEan.35O1
13Quittungscode1DEbin..O1
+ + +### ◆ Erläuterungen + + +#### Gebuchte Umsätze + +Die gebuchten Umsätze sind im vom Kunden gewählten Format einzustellen. + +Bei Einstellung im Format MT 940 ist die Version „SRG 2001“ (s. [Datenformate]) zu +verwenden. + + +#### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
3010Es liegen keine Einträge vor
3040Auftrag nur teilweise ausgeführt
9210Keine gültige Kontoverbindung des Kunden
+ + +### c) Bankparameterdaten + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoauszug Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIEKAS
Bezugssegment:HKVVB
Version:2
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle Konto- und Umsatz-InformationenStand: 07.08.2015Seite: 27
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Konto- auszug2DEGM1
+ + +## C.2.1.1.3.3 Segmentversion 3 + +Dieser Geschäftsvorfall eignet sich beim Homebanking zur Realisierung des ,,Elek- +tronischen Kontoauszugs". Die rechtlichen und geschäftspolitischen Voraussetzun- +gen für den „Elektronischen Kontoauszug" sind ggf. in separaten Dokumenten zu +beschreiben. + +Der Kontoauszug enthält alle Umsätze, die seit dem letzten Ausdruck eines Konto- +auszugs (am Kontoauszugdrucker bzw. als elektronischer Kontoauszug) für das je- +weilige Konto angefallen sind. Im Gegensatz zu den Kontoumsätzen enthält der +Kontoauszug keine nicht-gebuchten Umsätze. + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +### a) Kundenauftrag + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoauszug anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKEKA
Bezugssegment:-
Version:3
Sender:Kunde
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
28		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Konto- und Umsatz-Informationen
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Kontoverbindung Auftraggeber2DEGktv#M1
3Kontoauszugsfor- mat3DEcode1O1gemäß BPD zugelassene Formate
4Kontoauszugs- nummer1DEnum..5C1>0
O: ,Kontoauszugsnummer erlaubt" (BPD) = ,J" N: sonst
5Kontoauszugsjahr1DEnum4C1>0
O: ,Kontoauszugsnummer erlaubt“ (BPD) = ,J" N: sonst
6Maximale Anzahl Einträge1DEnum..4C1>0
O: ,,Eingabe Anzahl Ein- träge erlaubt“ (BPD) = „J“ N: sonst
7Aufsetzpunkt1DEan.35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +### . Belegungsrichtlinien + + +#### Kontoauszugsformat + +Falls das Kreditinstitut laut Bankparameterdaten mehrere Kontoauszugfor- +mate anbietet, kann der Kunde das gewünschte Format wählen. + + +#### Kontoauszugsnummer + +Falls das Kreditinstitut den Abruf historischer Kontoauszüge unterstützt, kann +der Kunde hier die Nummer eines bereits gedruckten Auszugs angeben, um +den Auszug erneut zu erhalten. Bleibt das DE leer, so wird stets der aktuelle +Auszug angefordert. Falls die Kontoauszugsnummer - ggf. in Kombination +mit dem Kontoauszugsjahr - nicht existiert, wird der Auftrag abgelehnt. + + +#### Kontoauszugsjahr + +Falls das Kreditinstitut den Ablauf historischer Kontoauszüge unterstützt und +im Jahresturnus die Kontoauszugsnummer neu zu zählen beginnt, muss das +DE Kontoauszugsjahr belegt werden, um historische Kontoauszüge eindeu- +tig kennzeichnen zu können. Bleibt das DE leer, wird vom aktuellen Kalen- +derjahr ausgegangen. Falls die Kontoauszugsnummer – ggf. in Kombination +mit dem Kontoauszugsjahr - nicht existiert, wird der Auftrag abgelehnt. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle
Konto- und Umsatz-Informationen		Stand: 07.08.2015Seite: 29
+ + +### b) Kreditinstitutsrückmeldung + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoauszug
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIEKA
Bezugssegment:HKEKA
Version:3
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoauszugsfor- mat3DEcode1M11, 2, 3
3Berichtszeitraum2DEGM1
4Gebuchte Umsätze1DEbin. .M1
5Informationen zum Rechnungsab- schluss2DEtxt.655 36O1
6Informationen zu Kundenbedingun- gen3DEtxt.655 36O1
7Werbetext2DEtxt..655 36O1
8IBAN Konto1DEan..34O1
9BIC Konto1DEan..11O1
10Auszugsname 11DEan.35O1
11Auszugsname 21DEan..35O1
12Namenszusatz1DEan..35O1
13Quittungscode1DEbin. .O1
+ + +### ◆ Erläuterungen + + +#### Gebuchte Umsätze + +Die gebuchten Umsätze sind im vom Kunden gewählten Format einzustellen. +Bei Einstellung im Format MT 940 ist die Version ,,SRG 2001" (s. [Daten- +formate]) zu verwenden. + + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
3010Es liegen keine Einträge vor
3040Auftrag nur teilweise ausgeführt
9210Keine gültige Kontoverbindung des Kunden
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
30		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Konto- und Umsatz-Informationen
+ + +### c) Bankparameterdaten + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoauszug Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIEKAS
Bezugssegment:HKVVB
Version:3
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Konto- auszug2DEGM1
+ + +## C.2.1.1.3.4 Segmentversion 4 (SEPA) + +Dieser Geschäftsvorfall eignet sich beim Homebanking zur Realisierung des ,Elek- +tronischen Kontoauszugs". Die rechtlichen und geschäftspolitischen Voraussetzun- +gen für den „Elektronischen Kontoauszug" sind ggf. in separaten Dokumenten zu +beschreiben. + +Der Kontoauszug enthält alle Umsätze, die seit dem letzten Ausdruck eines Konto- +auszugs (am Kontoauszugdrucker bzw. als elektronischer Kontoauszug) für das je- +weilige Konto angefallen sind. Im Gegensatz zu den Kontoumsätzen enthält der +Kontoauszug keine nicht-gebuchten Umsätze. + +Realisierung Bank: +optional + +Realisierung Kunde: optional + + +### a) Kundenauftrag + + +#### . Format + +Name: +Kontoauszug anfordern +Typ: +Segment +Segmentart: +Geschäftsvorfall +Kennung: +HKEKA +Bezugssegment: +\- +Version: +4 +Sender: +Kunde + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Geschäftsvorfälle Konto- und Umsatz-InformationenStand: 07.08.2015Seite: 31
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3Kontoauszugsfor- mat3DEcode1O1gemäß BPD zugelassene Formate
4Kontoauszugs- nummer1DEnum..5C1>0
O: ,Kontoauszugsnummer erlaubt" (BPD) = ,J" N: sonst
5Kontoauszugsjahr1DEnum4C1>0
O: ,Kontoauszugsnummer erlaubt" (BPD) = ,J" N: sonst
6Maximale Anzahl Einträge1DEnum..4C1>0
O: „Eingabe Anzahl Einträge erlaubt" (BPD) = ,J" N: sonst
7Aufsetzpunkt1DEan..35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +### . Belegungsrichtlinien + + +#### Kontoauszugsformat + +Falls das Kreditinstitut laut Bankparameterdaten mehrere Kontoauszugformate an- +bietet, kann der Kunde das gewünschte Format wählen. + + +#### Kontoauszugsnummer + +Falls das Kreditinstitut den Abruf historischer Kontoauszüge unterstützt, kann der +Kunde hier die Nummer eines bereits gedruckten Auszugs angeben, um den Aus- +zug erneut zu erhalten. Bleibt das DE leer, so wird stets der aktuelle Auszug ange- +fordert. Falls die Kontoauszugsnummer - ggf. in Kombination mit dem Kontoaus- +zugsjahr - nicht existiert, wird der Auftrag abgelehnt. + + +#### Kontoauszugsjahr + +Falls das Kreditinstitut den Ablauf historischer Kontoauszüge unterstützt und im Jah- +resturnus die Kontoauszugsnummer neu zu zählen beginnt, muss das DE Konto- +auszugsjahr belegt werden, um historische Kontoauszüge eindeutig kennzeichnen +zu können. Bleibt das DE leer, wird vom aktuellen Kalenderjahr ausgegangen. Falls +die Kontoauszugsnummer – ggf. in Kombination mit dem Kontoauszugsjahr – nicht +existiert, wird der Auftrag abgelehnt. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
32		Stand:
07.08.2015		Kapitel: Geschäftsvorfälle
Abschnitt: Konto- und Umsatz-Informationen
+ + +### b) Kreditinstitutsrückmeldung + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
. Format
Name:Kontoauszug
Typ: Segment
Segmentart:Geschäftsvorfall
Kennung:HIEKA
Bezugssegment:HKEKA
Version:4
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoauszugsfor- mat3DEcode1M11, 2, 3
3Berichtszeitraum2DEGM1
4Gebuchte Umsätze1DEbin. .M1
5Informationen zum Rechnungsab- schluss2DEtxt.65
536		O1
6Informationen zu Kundenbedingun- gen3DEtxt.65 536O1
7Werbetext2DEtxt..65 536O1
8IBAN Konto1DEan..34O1
9BIC Konto1DEan.. 11O1
10Auszugsname 11DEan..35O1
11Auszugsname 21DEan..35O1
12Namenszusatz1DEan..35O1
13Quittungscode1DEbinO1
+ + +#### ◆ Erläuterungen + + +##### Gebuchte Umsätze + +Die gebuchten Umsätze sind im vom Kunden gewählten Format einzustellen. + +Bei Einstellung im Format MT 940 ist die Version ,,SRG 2001“ (s. [Datenformate]) +mit den beschriebenen Belegungen für SEPA zu verwenden. + + +#### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
3010Es liegen keine Einträge vor
3040Auftrag nur teilweise ausgeführt
9210Keine gültige Kontoverbindung des Kunden
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle
Konto- und Umsatz-Informationen		Stand: 07.08.2015Seite: 33
+ + +#### c) Bankparameterdaten + + +##### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoauszug Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIEKAS
Bezugssegment:HKVVB
Version:4
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Konto- auszug2DEGM1
+ + +## C.2.1.1.3.5 Segmentversion 5 + +Dieser Geschäftsvorfall eignet sich beim Online-Banking zur Realisierung des ,Elek- +tronischen Kontoauszugs". Die rechtlichen und geschäftspolitischen Voraussetzun- +gen für den „Elektronischen Kontoauszug" sind ggf. in separaten Dokumenten zu +beschreiben. + +Der Kontoauszug enthält alle Umsätze, die seit dem letzten Ausdruck eines Konto- +auszugs (am Kontoauszugdrucker bzw. als elektronischer Kontoauszug) für das je- +weilige Konto angefallen sind. Darüber hinaus ist es möglich Kreditinstitutsseitig be- +reits erstellte, aber bislang noch nicht abgerufene, ältere Kontoauszüge gleichzeitig +abzurufen. Im Gegensatz zu den Kontoumsätzen enthält der Kontoauszug keine +nicht-gebuchten Umsätze. + +Realisierung Bank: +optional + +Realisierung Kunde: optional + + +### a) Kundenauftrag + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoauszug anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKEKA
Bezugssegment:-
Version:5
Sender:Kunde
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
34		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Konto- und Umsatz-Informationen
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3Kontoauszugsfor- mat3DEcode1O1gemäß BPD zugelassene Formate
4Kontoauszugs- nummer1DEnum..5C1>0
O: ,Kontoauszugsnummer erlaubt" (BPD) = ,J" N: sonst
5Kontoauszugsjahr1DEnum4C1>0
O: ,Kontoauszugsnummer erlaubt" (BPD) = ,J" N: sonst
6Maximale Anzahl Einträge1DEnum..4C1>0
O: „Eingabe Anzahl Einträge erlaubt" (BPD) = ,J" N: sonst
7Aufsetzpunkt1DEan..35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +### . Belegungsrichtlinien + + +#### Kontoauszugsformat + +Falls das Kreditinstitut laut Bankparameterdaten mehrere Kontoauszugformate an- +bietet, kann der Kunde das gewünschte Format wählen. + + +#### Kontoauszugsnummer + +Falls das Kreditinstitut den Abruf historischer Kontoauszüge unterstützt, kann der +Kunde hier die Nummer eines bereits gedruckten Auszugs angeben, um den Aus- +zug erneut zu erhalten. Bleibt das DE leer, so werden alle bislang nicht abgerufenen +Kontoauszüge geliefert. Falls die Kontoauszugsnummer - ggf. in Kombination mit +dem Kontoauszugsjahr – nicht existiert, wird der Auftrag abgelehnt. + + +#### Kontoauszugsjahr + +Falls das Kreditinstitut den Ablauf historischer Kontoauszüge unterstützt und im Jah- +resturnus die Kontoauszugsnummer neu zu zählen beginnt, muss das DE Konto- +auszugsjahr belegt werden, um historische Kontoauszüge eindeutig kennzeichnen +zu können. Bleibt das DE leer, wird vom aktuellen Kalenderjahr ausgegangen. Falls +die Kontoauszugsnummer – ggf. in Kombination mit dem Kontoauszugsjahr – nicht +existiert, wird der Auftrag abgelehnt. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle
Konto- und Umsatz-Informationen		Stand: 07.08.2015Seite: 35
+ + +### b) Kreditinstitutsrückmeldung + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
. Format
Name:Kontoauszug
Typ: Segment
Segmentart:Geschäftsvorfall
Kennung:HIEKA
Bezugssegment:HKEKA
Version:5
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoauszugsfor- mat3DEcode1M11, 2, 3
3Berichtszeitraum2DEGM1
4Erstellungsdatum Kontoauszug1DEdat#O1
5Kontoauszugsjahr1DEnum4O1
6Kontoauszugs- nummer1DEnum.5O1
7Gebuchte Umsätze1DEbin. .M1
8Informationen zum Rechnungsab- schluss2DEtxt..65 536O1
9Informationen zu Kundenbedingun- gen3DEtxt.65 536O1
10Werbetext2DEtxt..65 536O1
11IBAN Konto1DEan..34O1
12BIC Konto1DEan.. 11O1
13Auszugsname 11DEan..35O1
14Auszugsname 21DEan.35O1
15Namenszusatz1DEan..35O1
16Quittungscode1DEbin..O1
+ + +### ◆ Erläuterungen + + +#### Kontoauszugsnummer + +Die Kontoauszugsnummer muss der Kontoauszugsnummer im Feld 28C des MT +940 entsprechen (s. [Datenformate]), der gleichzeitig im Kreditinstitutssegment über- +tragen wird. Die Kontoauszugsnummer dient dabei der Zuordnung der nachfolgen- +den Textfelder zum dazugehörigen Kontoauszug. + + +#### Gebuchte Umsätze + +Die gebuchten Umsätze sind im vom Kunden gewählten Format einzustellen. + +Bei Einstellung im Format MT 940 ist die Version ,SRG 2001" (s. [Datenformate]) +mit den beschriebenen Belegungen für SEPA zu verwenden. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
36		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Konto- und Umsatz-Informationen
+ + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
3010Es liegen keine Einträge vor
3040Auftrag nur teilweise ausgeführt
9210Keine gültige Kontoverbindung des Kunden
+ + +### c) Bankparameterdaten + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoauszug Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIEKAS
Bezugssegment:HKVVB
Version:5
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Konto- auszug2DEGM1
+ + +## C.2.1.1.4 Übersicht Kontoauszüge + + +### C.2.1.1.4.1 Segmentversion 1 + +Mit Hilfe dieses Geschäftsvorfalls kann der Kunde sich einen Überblick über die für +ein Konto erstellten Kontoauszüge machen. Mit diesen Informationen erhält er nicht +nur einen Überblick über die bisher erstellten Kontoauszüge, sondern zusätzlich +auch Informationen über Auszüge, die nach der Abholung noch nicht quittiert wur- +den sowie über historische Auszüge, die der Kunde erneut per Geschäftsvorfall +HKEKA anfordern kann. + +Diese Übersicht kann auch unabhängig vom Geschäftsvorfall HKEKA angeboten +werden. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Konto- und Umsatz-Informationen
Geschäftsvorfälle		Stand: 07.08.2015Seite: 37
+ + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +#### a) Kundenauftrag + + +##### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Übersicht Kontoauszüge
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKKAU
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung Auftraggeber2DEGktv#M1
3Maximale Anzahl Einträge1DEnum..4C1>0
O: ,,Eingabe Anzahl Ein- träge erlaubt“ (BPD) = „J“ N: sonst
4Aufsetzpunkt1DEan..35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
38		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Konto- und Umsatz-Informationen
+ + +#### b) Kreditinstitutsrückmeldung + + +##### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Übersicht Kontoauszüge
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIKAU
Bezugssegment:HKKAU
Version:1
Anzahln
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoauszugs- nummer1DEnum..5M1
3Quittierung1DEcode1M1
4Abholung möglich J/N1DEjn#M1
5Jahr1DEnum4O1
6Datum der Erstel- lung1DEdat#O1
7Uhrzeit der Erstel- lung1DEtim#O1
8Erstellart1DEan..30O1
+ + +#### . Belegungsrichtlinien + + +##### Kontoauszugsnummer + +Es ist die vom Institut zugeordnet Kontoauszugsnummer einzustellen. Diese ist ggf. +nur in Verbindung mit dem Kontoauszugsjahr eindeutig, wenn das Institut beim Jah- +reswechsel neu ab „1“ zu zählen beginnt. + + +##### Kontoauszugsjahr + +Falls ein Institut beim Jahreswechsel die Kontoauszugsnummer neu ab „1“ zu zäh- +len beginnt, muss das Kontoauszugsjahr mitgeschickt werden, um einen Kontoaus- +zug eindeutig zu kennzeichnen. + + +#### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
3010Es liegen keine Einträge vor
9210Keine gültige Kontoverbindung des Kunden
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Konto- und Umsatz-Informationen
Geschäftsvorfälle		Stand: 07.08.2015Seite: 39
+ + +##### c) Bankparameterdaten + +Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Übersicht Kontoauszüge Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIKAUS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + +### C.2.1.1.4.2 Segmentversion 2 (SEPA) + +Mit Hilfe dieses Geschäftsvorfalls kann der Kunde sich einen Überblick über die für +ein Konto erstellten Kontoauszüge machen. Mit diesen Informationen erhält er nicht +nur einen Überblick über die bisher erstellten Kontoauszüge, sondern zusätzlich +auch Informationen über Auszüge, die nach der Abholung noch nicht quittiert wur- +den sowie über historische Auszüge, die der Kunde erneut per Geschäftsvorfall +HKEKAKontoauszugsabruf anfordern kann. + +Diese Übersicht kann auch unabhängig vom Geschäftsvorfall HKEKAvon Ge- +schäftsvorfällen zum Kontoauszugsabruf angeboten werden. + + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +#### a) Kundenauftrag + + +##### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Übersicht Kontoauszüge
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKKAU
Bezugssegment:-
Version:2
Sender:Kunde
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
40		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Konto- und Umsatz-Informationen
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3Maximale Anzahl Einträge1DEnum..4O1>0
4Aufsetzpunkt1DEan.35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Konto- und Umsatz-Informationen
Geschäftsvorfälle		Stand: 07.08.2015Seite: 41
+ + +#### b) Kreditinstitutsrückmeldung + + +##### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Übersicht Kontoauszüge
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIKAU
Bezugssegment:HKKAU
Version:2
Anzahln
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoauszugs- nummer1DEnum..5M1
3Quittierung1DEcode1M1
4Abholung möglich J/N1DEjn#M1
5Jahr1DEnum4O1
6Datum der Erstel- lung1DEdat#O1
7Uhrzeit der Erstel- lung1DEtim#O1
8Erstellart1DEan..30O1
+ + +#### ◆ Erläuterungen + + +##### Kontoauszugsnummer + +Es ist die vom Institut zugeordnet Kontoauszugsnummer einzustellen. Diese ist ggf. +nur in Verbindung mit dem Kontoauszugsjahr eindeutig, wenn das Institut beim Jah- +reswechsel neu ab „1“ zu zählen beginnt. + + +##### Kontoauszugsjahr + +Falls ein Institut beim Jahreswechsel die Kontoauszugsnummer neu ab „1“ zu zäh- +len beginnt, muss das Kontoauszugsjahr mitgeschickt werden, um einen Kontoaus- +zug eindeutig zu kennzeichnen. + + +#### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
3010Es liegen keine Einträge vor
9210Keine gültige Kontoverbindung des Kunden
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
42		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Konto- und Umsatz-Informationen
+ + +##### c) Bankparameterdaten + +Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Übersicht Kontoauszüge Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIKAUS
Bezugssegment:HKVVB
Version:2
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + +### C.2.1.1.5 Vormerkposten anfordern + + +#### a) Kundenauftrag + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Vormerkposten anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKVMK
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung Auftraggeber2DEGktv#M1
3Alle Konten1DEjn#M1
4Maximale Anzahl Einträge1DEnum..4C1>0
O: ,,Eingabe Anzahl Ein- träge erlaubt“ (BPD) = „J“ N: sonst
5Aufsetzpunkt1DEan.35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +#### . Belegungsrichtlinien + + +#### Kontoverbindung Auftraggeber + +Falls unter einer Kontonummer verschiedene Währungskonten geführt werden, +kann im Feld ,,Unterkontomerkmal" durch Angabe des ISO-Währungscodes eine +Einschränkung erfolgen, um das entsprechende Konto zu identifizieren + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle Konto- und Umsatz-InformationenStand: 07.08.2015Seite: 43
+ + +Falls die Option ,,Alle Konten" gewählt wird, ist eine beliebige Kontoverbindung des +Kunden einzustellen. + + +#### b) Kreditinstitutsrückmeldung + + +##### . Beschreibung + +Die Online-Antwort des Kreditinstituts enthält unmittelbar die gemäß Anfragezeit- +raum zusammengestellten Vormerkposten. Eine erst spätere Bereitstellung der +Vormerkposten ist wegen der dazu erforderlichen erneuten Anwahl nicht praktika- +bel. + +Es werden stets sämtliche Vormerkposten des Tages eingestellt, auch wenn diese +ganz oder teilweise bereits vorher abgeholt wurden. Dies ermöglicht eine fehlerfreie +Eliminierung von mehrfach abgeholten Buchungen durch das Kundensystem. + +Falls der Kunde ,,Alle Konten" gewählt hat, wird das Segment für jedes Konto, für +das Vormerkposten angegeben werden können, jeweils einmal eingestellt. + + +![](figures/63.1) + + +Es ist zu beachten, dass im Falle einer Umstellung der Kontowäh- +rung, die in den Abrufzeitraum fällt, innerhalb einer Vormerkpos- +tenabfrage sowohl Vormerkposten in der bisherigen Währung als +auch Vormerkposten in der neuen Währung zurückgemeldet wer- +den können. + + +##### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Vormerkposten anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIVMK
Bezugssegment:HKVMK
Version:1
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Nicht gebuchte Umsätze1DEbin..M1
+ + +##### . Belegungsrichtlinien + + +##### Nicht Gebuchte Umsätze + +Es ist das S.W.I.F.T.-Format MT 942 in der Version ,,SRG 2001“ (s. [Datenformate]) +einzustellen. + + +##### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
3010Es liegen keine Einträge vor
3040Auftrag nur teilweise ausgeführt
9210Bereichende darf nicht vor Bereichanfang liegen
9210Datum muss in der Vergangenheit liegen
9210Keine gültige Kontoverbindung des Kunden
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
44		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Konto- und Umsatz-Informationen
+ + +#### c) Bankparameterdaten + + +##### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Vormerkposten anfordern Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIVMKS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Vor- merkposten anfor- dern1DEGM1
+ + +## C.2.1.2Saldenabfrage + + +### C.2.1.2.1 Segmentversion 6 + +Die Saldenabfrage liefert für das angegebene Konto bzw. für alle Konten des Kun- +den den aktuellen Saldo sowie weitere Saldeninformationen zurück. + + +![](figures/64.1) + + +Das Kundenprodukt muss damit rechnen, dass Salden auch in +Fremdwährung (nicht EUR) geliefert werden können (z.B. bei der +Abfrage von Währungskonten). + + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +#### a) Kundenauftrag + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Saldenabfrage
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKSAL
Bezugssegment:-
Version:6
Sender:Kunde
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Geschäftsvorfälle Konto- und Umsatz-InformationenStand: 07.08.2015Seite: 45
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Kontoverbindung Auftraggeber2DEGktv#M1
3Alle Konten1DEjn#M1
4Maximale Anzahl Einträge1DEnum..4O1>0
5Aufsetzpunkt1DEan.35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +#### . Belegungsrichtlinien + + +## Kontoverbindung Auftraggeber + +Wählt der Kunde die Option „Alle Konten“, so ist eine beliebige gültige Kon- +toverbindung des Kunden einzustellen. + + +## b) Kreditinstitutsrückmeldung + + +### . Beschreibung + +Das Kreditinstitut hat in jedem Fall den „gebuchten Saldo“ zurückzumelden. Falls im +Kreditinstitut verfügbar, können auch die anderen Kontoinformationen rückgemeldet +werden. Die Währung, in der die Beträge rückgemeldet werden, entspricht stets der +Kontenwährung. + +Beispiele zur Verwendung der Felder in der Saldeninformation: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Beispiel 1Beispiel 2Beispiel 3
Gebuchter Saldo:1000 EUR-300 EUR-800 EUR
Kreditlinie (Dispo):500 EUR500 EUR500 EUR
Verfügbarer Betrag:1500 EUR200 EUR0 EUR
Überziehung:0 EUR0 EUR300 EUR
+ + +Falls der Kunde ,,Alle Konten" gewählt hat, ist das Segment „Saldenrückmeldung“ +für jedes Konto jeweils einmal einzustellen. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Saldenrückmeldung
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HISAL
Bezugssegment:HKSAL
Version:6
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
46		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Konto- und Umsatz-Informationen
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung Auftraggeber2DEGktv#M1
3Kontoproduktbe- zeichnung1DEan..30M1
4Kontowährung1DEcur#M1
5Gebuchter Saldo2DEGsdo#M1
6Saldo der vorge- merkten Umsätze2DEGsdo#O1
7Kreditlinie1DEGbtg#O1
8Verfügbarer Betrag1DEGbtg#O1
9Bereits verfügter Betrag1DEGbtg#O1
10Überziehung1DEGbtg#O1
11Buchungszeitpunkt1DEGtsp#O1
12Fälligkeit1DEdat#C1O: bei Kreditkartenkonten N: sonst
+ + +## . Belegungsrichtlinien + + +### Überziehung + +Dieses Feld darf nur belegt werden, wenn der verfügbare Betrag Null ist (s. +auch Beispiel). + + +### Buchungszeitpunkt + +Datum, an dem der Saldo (DEG ,,Gebuchter Saldo") gebucht wurde. Dieses +Datum muss nicht mit dem Datum der Übertragung des Saldos, das in die +DEG ,,Gebuchter Saldo" eingestellt wird, identisch sein. + + +![](figures/66.1) + + +Die vom Kreditinstitut übermittelten Daten kann das Kundenprodukt +dazu verwenden, dem Kunden beliebige abgeleitete Informationen +zu seinem Konto (z.B. Disposaldo, offener Saldo, Verfügungsrah- +men, Limit) zu errechnen und zur Verfügung zu stellen. + + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
3040Auftrag nur teilweise ausgeführt
9210Keine gültige Kontoverbindung des Kunden
9210Konto hat keinen Saldo, da Depotkonto
+ + +### c) Bankparameterdaten + + +## . Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle Konto- und Umsatz-InformationenStand: 07.08.2015Seite: 47
+ + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Saldenabfrage Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HISALS
Bezugssegment:HKVVB
Version:6
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + +# C.2.1.2.2 Segmentversion 7 (SEPA) + +Die Saldenabfrage liefert für das angegebene Konto bzw. für alle Konten des Kun- +den den aktuellen Saldo sowie weitere Saldeninformationen zurück. + + +![](figures/67.1) + + +Das Kundenprodukt muss damit rechnen, dass Salden auch in +Fremdwährung (nicht EUR) geliefert werden können (z.B. bei der +Abfrage von Währungskonten). + + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +## a) Kundenauftrag + + +### Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Saldenabfrage
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKSAL
Bezugssegment:-
Version:7
Sender:Kunde
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
48		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Konto- und Umsatz-Informationen
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3Alle Konten1DEjn#M1
4Maximale Anzahl Einträge1DEnum..4C1>0
O: ,,Eingabe Anzahl Ein- träge erlaubt“ (BPD) = „J“ N: sonst
5Aufsetzpunkt1DEan..35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +## . Belegungsrichtlinien + + +### Kontoverbindung international + +Wählt der Kunde die Option „Alle Konten“, so ist eine beliebige gültige Kontoverbin- +dung des Kunden einzustellen. + + +### b) Kreditinstitutsrückmeldung + + +#### . Beschreibung + +Das Kreditinstitut hat in jedem Fall den „gebuchten Saldo“ zurückzumelden. Falls im +Kreditinstitut verfügbar, können auch die anderen Kontoinformationen rückgemeldet +werden. Die Währung, in der die Beträge rückgemeldet werden, entspricht stets der +Kontenwährung. + +Beispiele zur Verwendung der Felder in der Saldeninformation: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Beispiel 1Beispiel 2Beispiel 3
Gebuchter Saldo:1000 EUR-300 EUR-800 EUR
Kreditlinie (Dispo):500 EUR500 EUR500 EUR
Verfügbarer Betrag:1500 EUR200 EUR0 EUR
Überziehung:0 EUR0 EUR300 EUR
+ + +Falls der Kunde „Alle Konten“ gewählt hat, ist das Segment „Saldenrückmeldung“ +für jedes Konto jeweils einmal einzustellen. + + +#### . Format + +Name: +Saldenrückmeldung +Typ: +Segment +Segmentart: +Geschäftsvorfall +Kennung: +HISAL +Bezugssegment: +HKSAL +Version: +7 +Anzahl: +n +Sender: +Kreditinstitut + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Geschäftsvorfälle Konto- und Umsatz-InformationenStand: 07.08.2015Seite: 49
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3Kontoproduktbe- zeichnung1DEan.30M1
4Kontowährung1DEcur#M1
5Gebuchter Saldo2DEGsdo#M1
6Saldo der vorge- merkten Umsätze2DEGsdo#O1
7Kreditlinie1DEGbtg#O1
8Verfügbarer Betrag1DEGbtg#O1
9Bereits verfügter Betrag1DEGbtg#O1
10Überziehung1DEGbtg#O1
11Buchungszeitpunkt1DEGtsp#O1
12Fälligkeit1DEdat#C1O: bei Kreditkartenkonten N: sonst
+ + +### . Belegungsrichtlinien + + +#### Überziehung + +Dieses Feld darf nur belegt werden, wenn der verfügbare Betrag Null ist (s. auch +Beispiel). + + +#### Buchungszeitpunkt + +Datum, an dem der Saldo (DEG ,,Gebuchter Saldo") gebucht wurde. Dieses Datum +muss nicht mit dem Datum der Übertragung des Saldos, das in die DEG ,,Gebuchter +Saldo" eingestellt wird, identisch sein. + + +![](figures/69.1) + + +Die vom Kreditinstitut übermittelten Daten kann das Kundenprodukt +dazu verwenden, dem Kunden beliebige abgeleitete Informationen +zu seinem Konto (z.B. Disposaldo, offener Saldo, Verfügungsrah- +men, Limit) zu errechnen und zur Verfügung zu stellen. + + +#### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
3040Auftrag nur teilweise ausgeführt
9210Keine gültige Kontoverbindung des Kunden
9210Konto hat keinen Saldo, da Depotkonto
+ + +#### c) Bankparameterdaten + + +##### . Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
50		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Konto- und Umsatz-Informationen
+ + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Saldenabfrage Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HISALS
Bezugssegment:HKVVB
Version:7
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1SegmentkopfDEGM1
2Maximale Anzahl AufträgeDEnum..3M1
3Anzahl Signaturen mindestensDEnum1M10, 1, 2, 3
4SicherheitsklasseDEcode1M10, 1, 2, 3, 4
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Geschäftsvorfälle Konto- und Umsatz-InformationenStand: 07.08.2015Seite: 51
+ + +# C.2.2 Kontoinformationen + + +## C.2.2.1Segmentversion 2 + +Zum angegebenen Konto werden die allgemeinen Stamm-/Vertragsdaten rückge- +meldet. Hierzu gehören weder Umsatz- und Saldeninformationen noch kontoartspe- +zifische Informationen. Bei Angabe von ,alle Konten“ wird für jedes Konto des Kun- +den ein Segment zurückgemeldet: + + +![](figures/71.1) + + +Es bleibt der Entscheidung des Kreditinstituts überlassen, ob die +Kontoinformationen nur dem Kontoinhaber oder auch den Verfü- +gungsberechtigten angezeigt werden sollen. + + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +### a) Kundenauftrag + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoinformationen anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKKIF
Bezugssegment:-
Version:2
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung Auftraggeber2DEGktv#M1
3Alle Konten1DEjn#M1
4Maximale Anzahl Einträge1DEnum..4O1>0
5Aufsetzpunkt1DEan..35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +### . Belegungsrichtlinien + + +### Kontoverbindung Auftraggeber + +Wählt der Kunde die Option „Alle Konten“, so ist eine beliebige gültige Kon- +toverbindung des Kunden einzustellen. + + +### b) Kreditinstitutsrückmeldung + + +#### . Beschreibung + +Falls der Kunde ,,Alle Konten" angegeben hat, wird für jedes Konto bzw. Depot des +Kunden ein Segment nachfolgenden Formats in die Rückmeldenachricht eingestellt. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 52Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Konto- und Umsatz-Informationen
+ + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoinformationen rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIKIF
Bezugssegment:HKKIF
Version:2
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung2DEGktv#M1
3Kontoart1DEnum..2M1
4Name Kontoinhaber 11DEan..35M1
5Name Kontoinhaber 21DEan..35O1
6Kontoproduktbe- zeichnung1DEan.30O1
7Kontowährung1DEcur#O1
8Eröffnungsdatum1DEdat#O1
9Sollzins1DEwrt#O1
10Habenzins1DEwrt#O1
11Überziehungszins1DEwrt#O1
12Kreditlinie1DEGbtg#O1
13Referenzkonto3DEGktv#O1
14Briefanschrift1DEGaddr#O1
15Versandart Konto- auszug2DEcode1O10, 1, 2, 3, 4
16Turnus Kontoaus- zug2DEcode1O11, 2, 3, 4, 5, 6
17Weitere Informatio- nen1DEtxt.. 2048O1
18Verfügungsberech- tigte2DEGO0..9
+ + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
9210Keine gültige Kontoverbindung des Kunden
+ + +### c) Bankparameterdaten + + +#### . Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle
Konto- und Umsatz-Informationen		Stand: 07.08.2015Seite: 53
+ + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoinformationen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIKIFS
Bezugssegment:HKVVB
Version:2
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + +## C.2.2.2Segmentversion 3 (SEPA) + +Zum angegebenen Konto werden die allgemeinen Stamm-/Vertragsdaten rückge- +meldet. Hierzu gehören weder Umsatz- und Saldeninformationen noch kontoartspe- +zifische Informationen. Bei Angabe von „alle Konten“ wird für jedes Konto des Kun- +den ein Segment zurückgemeldet: + + +![](figures/73.1) + + +Es bleibt der Entscheidung des Kreditinstituts überlassen, ob die +Kontoinformationen nur dem Kontoinhaber oder auch den Verfü- +gungsberechtigten angezeigt werden sollen. + + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +### a) Kundenauftrag + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoinformationen anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKKIF
Bezugssegment:-
Version:3
Sender:Kunde
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
54		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Konto- und Umsatz-Informationen
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3Alle Konten1DEjn#M1
4Maximale Anzahl Einträge1DEnum..4O1>0
5Aufsetzpunkt1DEan..35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +### . Belegungsrichtlinien + + +#### Kontoverbindung international + +Wählt der Kunde die Option „Alle Konten“, so ist eine beliebige gültige Kontoverbin- +dung des Kunden einzustellen. + + +### b) Kreditinstitutsrückmeldung + + +### . Beschreibung + +Falls der Kunde ,,Alle Konten" angegeben hat, wird für jedes Konto bzw. Depot des +Kunden ein Segment nachfolgenden Formats in die Rückmeldenachricht eingestellt. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoinformationen rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIKIF
Bezugssegment:HKKIF
Version:3
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Geschäftsvorfälle Konto- und Umsatz-InformationenStand: 07.08.2015Seite: 55
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3Kontoart1DEnum..2M1
4Name Kontoinhaber 11DEan.35M1
5Name Kontoinhaber 21DEan.35O1
6Kontoproduktbe- zeichnung1DEan..30O1
7Kontowährung1DEcur#O1
8Eröffnungsdatum1DEdat#O1
9Sollzins1DEwrt#O1
10Habenzins1DEwrt#O1
11Überziehungszins1DEwrt#O1
12Kreditlinie1DEGbtg#O1
13Referenzkonto3DEGktv#O1
14Briefanschrift1DEGaddr#O1
15Versandart Konto- auszug2DEcode1O10, 1, 2, 3, 4
16Turnus Kontoaus- zug2DEcode1O11, 2, 3, 4, 5, 6
17Weitere Informatio- nen1DEtxt.. 2048O1
18Verfügungsberech- tigte2DEGO0..9
+ + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
9210Keine gültige Kontoverbindung des Kunden
+ + +### c) Bankparameterdaten + + +#### . Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoinformationen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIKIFS
Bezugssegment:HKVVB
Version:3
Sender:Kreditinstitut
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
56		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Konto- und Umsatz-Informationen
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1SegmentkopfDEGM1
2Maximale Anzahl AufträgeDEnum..3M1
3Anzahl Signaturen mindestensDEnum1M10, 1, 2, 3
4SicherheitsklasseDEcode1M10, 1, 2, 3, 4
+ + +## C.2.2.3Segmentversion 4 (SEPA) + +Zum angegebenen Konto werden u.A. die allgemeinen Stamm-/Vertragsdaten rück- +gemeldet. Bei Angabe von ,,alle Konten" wird für jedes Konto des Kunden ein Seg- +ment zurückgemeldet: + + +![](figures/76.1) + + +Es bleibt der Entscheidung des Kreditinstituts überlassen, ob die +Kontoinformationen nur dem Kontoinhaber oder auch den Verfü- +gungsberechtigten angezeigt werden sollen. + + +![](figures/76.2) + + +![](figures/76.3) + + +Es ist darauf zu achten, dass in der Kreditinstitutsantwort die DEG +"Verfügungsberechtigte" - wenn auch leer - immer 9 mal eingestellt +wird und somit eine klare Abgrenzung zum DE "Verwendungs- +zweckkonto" besteht. + + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +### a) Kundenauftrag + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoinformationen anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKKIF
Bezugssegment:-
Version:4
Sender:Kunde
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle Konto- und Umsatz-InformationenStand: 07.08.2015Seite: 57
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3Alle Konten1DEjn#M1
4Maximale Anzahl Einträge1DEnum..4O1>0
5Aufsetzpunkt1DEan.35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +### . Belegungsrichtlinien + + +#### Kontoverbindung international + +Wählt der Kunde die Option „Alle Konten“, so ist eine beliebige gültige Kontoverbin- +dung des Kunden einzustellen. + + +### b) Kreditinstitutsrückmeldung + + +### . Beschreibung + +Falls der Kunde ,,Alle Konten" angegeben hat, wird für jedes Konto bzw. Depot des +Kunden ein Segment nachfolgenden Formats in die Rückmeldenachricht eingestellt. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoinformationen rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIKIF
Bezugssegment:HKKIF
Version:4
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 58Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Konto- und Umsatz-Informationen
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3Kontoart1DEnum..2M1
4Name Kontoinhaber 11DEan.35M1
5Name Kontoinhaber 21DEan.35O1
6Kontoproduktbe- zeichnung1DEan..30O1
7Kontowährung1DEcur#O1
8Eröffnungsdatum1DEdat#O1
9Sollzins1DEwrt#O1
10Habenzins1DEwrt#O1
11Überziehungszins1DEwrt#O1
12Kreditlinie1DEGbtg#O1
13Referenzkonto4DEGkti#O1
14Briefanschrift1DEGaddr#O1
15Versandart Konto- auszug2DEcode1O10, 1, 2, 3, 4
16Turnus Kontoaus- zug2DEcode1O11, 2, 3, 4, 5, 6
17Weitere Informatio- nen1DEtxt.. 2048O1
18Verfügungsberech- tigte2DEGO0..9
19Verwendungszweck Konto1DEan..30O1
20Stand1DEGtsp#O1
21Information Spar- konten1DEGC1O: Kontoart 10-19 N: sonst
22Information Fest- geldkon- ten/Termineinlagen1DEGC1O: Kontoart 20-29 N: sonst
23Information Kredit- /Darlehenskonten1DEGC1O: Kontoart 40-99 N: sonst
+ + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + +Code +Beispiel für Rückmeldungstext + +9210 +Keine gültige Kontoverbindung des Kunden + + +### c) Bankparameterdaten + + +#### . Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle Konto- und Umsatz-InformationenStand: 07.08.2015Seite: 59
+ + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoinformationen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIKIFS
Bezugssegment:HKVVB
Version:4
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Konto- informationen1DEGM1
+ + +## C.2.2.4Segmentversion 5 (SEPA) + +Zum angegebenen Konto werden u.A. die allgemeinen Stamm-/Vertragsdaten rück- +gemeldet. Bei Angabe von ,,alle Konten" wird für jedes Konto des Kunden ein Seg- +ment zurückgemeldet: + + +![](figures/79.1) + + +Es bleibt der Entscheidung des Kreditinstituts überlassen, ob die +Kontoinformationen nur dem Kontoinhaber oder auch den Verfü- +gungsberechtigten angezeigt werden sollen. + + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +### a) Kundenauftrag + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoinformationen anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKKIF
Bezugssegment:-
Version:5
Sender:Kunde
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
60		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Konto- und Umsatz-Informationen
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3Alle Konten1DEjn#M1
4Maximale Anzahl Einträge1DEnum..4O1>0
5Aufsetzpunkt1DEan.35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +### . Belegungsrichtlinien + + +#### Kontoverbindung international + +Wählt der Kunde die Option „Alle Konten“, so ist eine beliebige gültige Kontoverbin- +dung des Kunden einzustellen. + + +### b) Kreditinstitutsrückmeldung + + +### . Beschreibung + +Falls der Kunde ,,Alle Konten" angegeben hat, wird für jedes Konto bzw. Depot des +Kunden ein Segment nachfolgenden Formats in die Rückmeldenachricht eingestellt. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoinformationen rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIKIF
Bezugssegment:HKKIF
Version:5
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Geschäftsvorfälle Konto- und Umsatz-InformationenStand: 07.08.2015Seite: 61
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3Kontoart1DEnum..2M1
4Name Kontoinhaber 11DEan.35M1
5Name Kontoinhaber 21DEan.35O1
6Kontoproduktbe- zeichnung1DEan..30O1
7Kontowährung1DEcur#O1
8Eröffnungsdatum1DEdat#O1
9Überziehung1DEGO1
10Habenzins1DEwrt#O1
11Aufstellung Sollzins1DEGO1
12Referenzkonto4DEGkti#O1
13Briefanschrift1DEGaddr#O1
14Versandart Konto- auszug2DEcode1O10, 1, 2, 3, 4
15Turnus Kontoaus- zug2DEcode1O11, 2, 3, 4, 5, 6
16Weitere Informatio- nen1DEtxt.٠ 2048O1
17Verfügungsberech- tigte2DEGO0..9
18Verwendungszweck Konto1DEan..30O1
19Stand1DEGtsp#O1
20Information Spar- konten1DEGC1O: Kontoart 10-19 N: sonst
21Information Fest- geldkon- ten/Termineinlagen1DEGC1O: Kontoart 20-29 N: sonst
22Information Kredit- /Darlehenskonten1DEGC1O: Kontoart 40-49 N: sonst
+ + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + +Code +Beispiel für Rückmeldungstext + +9210 +Keine gültige Kontoverbindung des Kunden + + +### c) Bankparameterdaten + + +#### . Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
62		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Konto- und Umsatz-Informationen
+ + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoinformationen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIKIFS
Bezugssegment:HKVVB
Version:5
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Konto- informationen1DEGM1
+ + +# C.2.2.5Segmentversion 6 + +Zum angegebenen Konto werden u.A. die allgemeinen Stamm-/Vertragsdaten rück- +gemeldet. Bei Angabe von ,,alle Konten" wird für jedes Konto des Kunden ein Seg- +ment zurückgemeldet: + + +![](figures/82.1) + + +Es bleibt der Entscheidung des Kreditinstituts überlassen, ob die +Kontoinformationen nur dem Kontoinhaber oder auch den Verfü- +gungsberechtigten angezeigt werden sollen. + + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +## a) Kundenauftrag + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoinformationen anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKKIF
Bezugssegment:-
Version:6
Sender:Kunde
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle Konto- und Umsatz-InformationenStand: 07.08.2015Seite: 63
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3Alle Konten1DEjn#M1
4Maximale Anzahl Einträge1DEnum..4O1>0
5Aufsetzpunkt1DEan.35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +## . Belegungsrichtlinien + + +### Kontoverbindung international + +Wählt der Kunde die Option „Alle Konten“, so ist eine beliebige gültige Kontoverbin- +dung des Kunden einzustellen. + + +## b) Kreditinstitutsrückmeldung + + +## . Beschreibung + +Falls der Kunde ,,Alle Konten" angegeben hat, wird für jedes Konto bzw. Depot des +Kunden ein Segment nachfolgenden Formats in die Rückmeldenachricht eingestellt. + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoinformationen rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIKIF
Bezugssegment:HKKIF
Version:6
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 64Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Konto- und Umsatz-Informationen
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3Kontoart1DEnum..2M1
4Name Kontoinhaber 11DEan.35M1
5Name Kontoinhaber 21DEan.35O1
6Kontoproduktbe- zeichnung1DEan..30O1
7Kontowährung1DEcur#O1
8Eröffnungsdatum1DEdat#O1
9Aufstellung Über- ziehungen1DEGO1
10Aufstellung Haben- /Bonuszinsen1DEGO1
11Aufstellung Sollzins1DEGO1
12Referenzkonto4DEGkti#O1
13Briefanschrift1DEGaddr#O1
14Versandart Konto- auszug2DEcode1O10, 1, 2, 3, 4
15Turnus Kontoaus- zug2DEcode1O11, 2, 3, 4, 5, 6
16Weitere Informatio- nen2DEtxt.. 6553 6O1
17Verfügungsberech- tigte2DEGO0..9
18Verwendungszweck Konto1DEan..30O1
19Stand1DEGtsp#O1
20Information Spar- konten1DEGC1O: Kontoart 10-19 N: sonst
21Information Fest- geldkon- ten/Termineinlagen1DEGC1O: Kontoart 20-29 N: sonst
22Information Kredit- /Darlehenskonten1DEGC1O: Kontoart 40-49 N: sonst
+ + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + +Code Beispiel für Rückmeldungstext + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle
Konto- und Umsatz-Informationen		Stand: 07.08.2015Seite: 65
+ + +9210 +Keine gültige Kontoverbindung des Kunden + + +### c) Bankparameterdaten + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoinformationen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIKIFS
Bezugssegment:HKVVB
Version:6
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Konto- informationen1DEGM1
+ + +##### C.2.2.6Segmentversion 7 + +Zum angegebenen Konto werden u.A. die allgemeinen Stamm-/Vertragsdaten rück- +gemeldet. Bei Angabe von ,,alle Konten" wird für jedes Konto des Kunden ein Seg- +ment zurückgemeldet: + + +![](figures/85.1) + + +Es bleibt der Entscheidung des Kreditinstituts überlassen, ob die +Kontoinformationen nur dem Kontoinhaber oder auch den Verfü- +gungsberechtigten angezeigt werden sollen. + + + + + + + + + + + + + +
RealisierungBank:optional
RealisierungKunde:optional
+ + +#### d)a) Kundenauftrag + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoinformationen anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKKIF
Bezugssegment:-
Version:77
Sender:Kunde
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
66		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Konto- und Umsatz-Informationen
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3Alle Konten1DEjn#M1
4Maximale Anzahl Einträge1DEnum..4O1>0
5Aufsetzpunkt1DEan.35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +## . Belegungsrichtlinien + + +### Kontoverbindung international + +Wählt der Kunde die Option „Alle Konten“, so ist eine beliebige gültige Kontoverbin- +dung des Kunden einzustellen. + + +# e)b) Kreditinstitutsrückmeldung + + +## . Beschreibung + +Falls der Kunde ,,Alle Konten" angegeben hat, wird für jedes Konto bzw. Depot des +Kunden ein Segment nachfolgenden Formats in die Rückmeldenachricht eingestellt. + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoinformationen rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIKIF
Bezugssegment:HKKIF
Version:77
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Geschäftsvorfälle Konto- und Umsatz-InformationenStand: 07.08.2015Seite: 67
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3Kontoart1DEnum..2M1
4Name Kontoinha- ber 11DEan.35M1
5Name Kontoinha- ber 21DEan.35O1
6Kontoproduktbe- zeichnung1DEan..30O1
7Kontowährung1DEcur#O1
8Eröffnungsdatum1DEdat#O1
9Aufstellung Über- ziehungen1DEGO1
10Aufstellung Ha- ben-/Bonuszinsen1DEGO1
11Aufstellung Soll- zins1DEGO1
12Referenzkonto4DEGkti#O1
13Briefanschrift1DEGaddr#O1
14Versandart Kon- toauszug2DEcode1O10, 1, 2, 3, 4
15Turnus Kontoaus- zug2DEcode1O11, 2, 3, 4, 5, 6
16Weitere Informati- onen2DEtxt.. 6553 6O1
17Verfügungsbe- rechtigte2DEGO0..9
18Verwendungs- zweck Konto1DEan..30O1
19Stand1DEGtsp#O1
20Information Spar- konten22DEGC1O: Kontoart 10-19 N: sonst
21Information Fest- geldkon- ten/Termineinlage n1DEGC1O: Kontoart 20-29 N: sonst
22Information Kredit- /Darlehenskonten1DEGC1O: Kontoart 40-49 N: sonst
23Gebühren und EntgelteGebühren und Entgelte14DEG DEGnA
+ + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + +Code Beispiel für Rückmeldungstext + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
68		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Konto- und Umsatz-Informationen
+ + +9210 +Keine gültige Kontoverbindung des Kunden + + +### f)c) Bankparameterdaten + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoinformationen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIKIFS
Bezugssegment:HKVVB
Version:77
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Konto- informationen1DEGM1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle Konto- und Umsatz-InformationenStand: 07.08.2015Seite: 69
+ + +# C.2.3 Umsatz-Informationen (camt) + + +## C.2.3.1.1 Kontoumsätze + + +## C.2.3.1.1.1 Kontoumsätze/Zeitraum (camt) + + + + + + + + + + + +
Realisierung Bank:verpflichtend, falls auch ,Kontoumsätze/neue Umsätze (camt)“ angeboten wird, sonst optional
Realisierung Kunde:verpflichtend, falls auch ,,Kontoumsätze/neue Umsätze (camt)" angeboten wird, sonst optional
+ + +### a) Kundenauftrag + + +#### . Beschreibung + +Die Lösung bietet dem Kunden die Möglichkeit, alle Buchungen über einen definier- +ten Zeitraum zu erhalten. Mit dieser Methode können z. B. fehlende Buchungssätze +in einer Finanzmanagementsoftware ergänzt werden. + +Die maximale Anzahl der rückzumeldenden Buchungspositionen kann begrenzt +werden. Eine Buchungsposition besteht aus einem Entry innerhalb einer +camt.052 message (s. [DFÜ-Abkommen]). Es muss davon unabhängig immer eine +gültige camt.052 message zurückgeliefert werden. + +Der maximale Zeitraum, für den rückwirkend Buchungen beim Kreditinstitut gespei- +chert sind, wird in den Bankparameterdaten übermittelt. + + +![](figures/89.1) + + +Mit Hilfe der Option ,,Alle Konten" kann im Kundenprodukt ein Fi- +nanzstatus des Kunden (Überblick über alle Geld- und Finanzan- +lagen) realisiert werden. Zu diesem Finanzstatus zählen jedoch +nur diejenigen Konten, die im Kreditinstitut für diesen Kunden ge- +führt werden und zu denen ein Saldo angegeben werden kann. In +der Praxis zählen jedoch oftmals bestimmte Konten für den Kun- +den nicht zum Finanzstatus (z.B. Konten, für die der Kunde ledig- +lich bevollmächtigt ist), andere fehlen jedoch, wie z.B. Konten zu +denen kein Saldo existiert (Wertpapierkonten) oder Konten, die bei +anderen Instituten geführt werden. + +In diesem Fall kann der Finanzstatus vom Kundenprodukt durch +Hintereinanderschaltung mehrerer Saldenabfragen zu jeweils ein- +zelnen Konten erzeugt werden. Dieser Finanzstatus kann auch +Konten verschiedener Kreditinstitute umfassen, indem mehrere +FinTS-Dialoge mit verschiedenen Instituten automatisch nachei- +nander durchgeführt werden. + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoumsätze anfordern/Zeitraum camt
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKCAZ
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
70		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt:
Konto- und Umsatz-Informationen
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3Unterstützte camt- messages1DEGM1gemäß BPD zugelassene Formate
4Alle Konten1DEjn#M1
5Von Datum1DEdat#O1
6Bis Datum1DEdat#O1
7Maximale Anzahl Einträge1DEnum..4C1>0
O: ,,Eingabe Anzahl Ein- träge erlaubt“ (BPD) = „J“ N: sonst
8Aufsetzpunkt1DEan..35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +## . Belegungsrichtlinien + + +### Kontoverbindung international + +Falls unter einer Kontonummer verschiedene Währungskonten geführt werden, +kann im Feld ,,Unterkontomerkmal" durch Angabe des ISO-Währungscodes eine +Einschränkung erfolgen, um das entsprechende Konto zu identifizieren. + +Falls die Option „Alle Konten“ gewählt wird, ist eine beliebige Kontoverbindung des +Kunden einzustellen. + + +### Unterstützte camt-messages + +Es sind mindestens eine gültige camt.052 message laut Vorgabe der BPD einzustel- +len. + + +## b) Kreditinstitutsrückmeldung + + +### . Beschreibung + +Die Online-Antwort des Kreditinstituts enthält unmittelbar die gemäß Anfragezeit- +raum zusammengestellten Kontoumsätze. + +Es werden stets sämtliche Umsätze des Starttages "Von Datum" in die Kontoumsät- +ze eingestellt, auch wenn diese ganz oder teilweise mit einem vorangegangenen +Auszug abgeholt wurden. Dies ermöglicht ggf. eine fehlerfreie Eliminierung von +mehrfach abgeholten Buchungen durch das Kundensystem. + +Falls der Kunde ,,Alle Konten" gewählt hat, wird das Segment für jedes Konto, für +das Umsätze angegeben werden können, eingestellt. + + +![](figures/90.1) + + +Es ist zu beachten, dass im Falle einer Umstellung der Kontowäh- +rung, die in den Abrufzeitraum fällt, innerhalb einer Umsatzabfrage +sowohl Umsätze in der bisherigen Währung als auch Umsätze in +der neuen Währung (getrennt nach Buchungstagen) zurückgemel- +det werden können. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Konto- und Umsatz-Informationen
Geschäftsvorfälle		Stand: 07.08.2015Seite: 71
+ + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoumsätze rückmelden/Zeitraum camt
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HICAZ
Bezugssegment:HKCAZ
Version:1
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3camt-Descriptor1DEan.256M1
4Gebuchte camt- Umsätze1DEGM1
5Nicht gebuchte camt-Umsätze1DEbin..O1
+ + +## . Belegungsrichtlinien + + +### Gebuchte camt-Umsätze + +Es ist eine gültige camt.052 message laut Anlage 3 des DFÜ-Abkommens einzustel- +len (s. [DFÜ-Abkommen]). Die verwendete camt.052 message muss der im „camt- +Descriptor" genannten Schema-Version entsprechen. + + +### Nicht gebuchte camt-Umsätze + +Es ist eine gültige camt.052 message laut Anlage 3 des DFÜ-Abkommens einzustel- +len (s. [DFÜ-Abkommen]). Die verwendete camt.052 message muss der im ,,camt- +Descriptor" genannten Schema-Version entsprechen. + + +![](figures/91.1) + + +Sofern die Electronic-Sequence-Number belegt +ist, ist der Inhalt kundenproduktseitig zu ignorieren. + + +![](figures/91.2) + + +Zur Verdeutlichung der Belegung des camt.052 bei der Verwen- +dung von Aufsetzpunkten und vorgemerkten Umsätzen finden +sich Beispiele in Kapitel E.7 "Beispiele für die eindeutige Bele- +gung von camt.052-messages im HKCAZ". + + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + +Code Beispiel für Rückmeldungstext + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
72		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Konto- und Umsatz-Informationen
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
0020Auftrag ausgeführt
3010Es liegen keine Einträge vor
3040Auftrag nur teilweise ausgeführt
9210Bereichende darf nicht vor Bereichanfang liegen
9210Datum muss in der Vergangenheit liegen
9210Keine gültige Kontoverbindung des Kunden
+ + +## c) Bankparameterdaten + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoumsätze/Zeitraum camt Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HICAZS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Konto- umsätze/Zeitraum camt1DEGM1
+ + +# C.2.3.1.1.2 Kontoumsätze/neue Umsätze (camt) + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +## a) Kundenauftrag + + +### . Beschreibung + +Das Abholen der neuen Kontoumsätze bietet gegenüber dem Abholen per Zeitrau- +mangabe den Vorteil, dass sichergestellt ist, dass im Kundensystem Buchungen +nicht doppelt erfasst werden. Zudem wird die kreditinstitutsseitig vorzuhaltende Da- +tenmenge minimiert. Grundlage für die Bestimmung, welche Umsätze als 'neu' zu +betrachten sind, ist stets der letzte Umsatzabruf, der auf Basis des Geschäftsvorfalls +„Kontoumsätze/neue Umsätze“ vorgenommen wurde. + +Der maximale Zeitraum, für den rückwirkend Buchungen beim Kreditinstitut gespei- +chert sind, wird in den Bankparameterdaten übermittelt. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle
Konto- und Umsatz-Informationen		Stand: 07.08.2015Seite: 73
+ + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoumsätze anfordern/neue Umsätze camt
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKCAN
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3Unterstützte camt- messages1DEGM1gemäß BPD zugelassene Formate
4Alle Konten1DEjn#M1
5Maximale Anzahl Einträge1DEnum..4C1>0
O: ,,Eingabe Anzahl Ein- träge erlaubt“ (BPD) = „J“ N: sonst
6Aufsetzpunkt1DEan..35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +## ◆ Belegungsrichtlinien + + +### Kontoverbindung international + +Falls unter einer Kontonummer verschiedene Währungskonten geführt werden, +kann im Feld ,,Unterkontomerkmal“ durch Angabe des ISO-Währungscodes eine +Einschränkung erfolgen, um das entsprechende Konto zu identifizieren. + +Falls die Option „Alle Konten“ gewählt wird, ist eine beliebige Kontoverbindung des +Kunden einzustellen. + + +### Unterstützte camt-messages + +Es sind mindestens eine gültige camt.052 message laut Vorgabe der BPD einzustel- +len. + + +### b) Kreditinstitutsrückmeldung + + +#### . Beschreibung + +Falls der Kunde ,,Alle Konten" gewählt hat, wird das Segment für jedes Konto, für +das Umsätze angegeben werden können, eingestellt. + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoumsätze rückmelden/neue Umsätze camt
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HICAN
Bezugssegment:HKCAN
Version:1
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
74		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Konto- und Umsatz-Informationen
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3camt-Descriptor1DEan.256M1
4Gebuchte camt- Umsätze1DEGM1
5Nicht gebuchte camt-Umsätze1DEbin..O1
+ + +## . Belegungsrichtlinien + + +### Gebuchte camt-Umsätze + +Es ist eine gültige camt.052 message laut Anlage 3 des DFÜ-Abkommens einzustel- +len (s. [DFÜ-Abkommen]). Die verwendete camt.052 message muss der im ,,camt- +Descriptor" genannten Schema-Version entsprechen. + + +### Nicht gebuchte camt-Umsätze + +Es ist eine gültige camt.052 message laut Anlage 3 des DFÜ-Abkommens einzustel- +len (s. [DFÜ-Abkommen]). Die verwendete camt.052 message muss der im ,,camt- +Descriptor" genannten Schema-Version entsprechen. + + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
3010Es liegen keine Einträge vor
3040Auftrag nur teilweise ausgeführt
9210Keine gültige Kontoverbindung des Kunden
+ + +## c) Bankparameterdaten + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoumsätze/neu camt Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HICANS
Bezugssegment:HKVVB
Version:7
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Konto- umsätze/neu camt1DEGM1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle Konto- und Umsatz-InformationenStand: 07.08.2015Seite: 75
+ + +# C.2.3.1.2 Kontoauszug + + +## C.2.3.1.2.1 Elektronischer Kontoauszug (camt) + +Dieser Geschäftsvorfall eignet sich beim Online-Banking zur Realisierung des ,Elek- +tronischen Kontoauszugs". Die rechtlichen und geschäftspolitischen Voraussetzun- +gen für den „Elektronischen Kontoauszug" sind ggf. in separaten Dokumenten zu +beschreiben. + +Der Kontoauszug enthält alle Umsätze, die seit dem letzten Ausdruck eines Konto- +auszugs (am Kontoauszugdrucker bzw. als elektronischer Kontoauszug) für das je- +weilige Konto angefallen sind. Darüber hinaus ist es möglich Kreditinstitutsseitig be- +reits erstellte, aber bislang noch nicht abgerufene, ältere Kontoauszüge gleichzeitig +abzurufen. Im Gegensatz zu den Kontoumsätzen enthält der Kontoauszug keine +nicht-gebuchten Umsätze. + +Realisierung Bank: +optional + +Realisierung Kunde: optional + + +### a) Kundenauftrag + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoauszug camt anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKECA
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3Unterstützte camt- messages1DEGM1gemäß BPD zugelassene Formate
4Kontoauszugs- nummer1DEnum..5C1>0
O: ,Kontoauszugsnummer erlaubt“ (BPD) = ,J“ N: sonst
5Kontoauszugsjahr1DEnum4C1>0
O: ,Kontoauszugsnummer erlaubt“ (BPD) = ,J" N: sonst
6Maximale Anzahl Einträge1DEnum..4C1>0
O: „Eingabe Anzahl Einträge erlaubt“ (BPD) = ,J“ N: sonst
7Aufsetzpunkt1DEan.35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
76		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Konto- und Umsatz-Informationen
+ + +### . Belegungsrichtlinien + + +#### Unterstützte camt-messages + +Es sind mindestens eine gültige camt.053 message laut Vorgabe der BPD einzustel- +len. + + +#### Kontoauszugsnummer + +Falls das Kreditinstitut den Abruf historischer Kontoauszüge unterstützt, kann der +Kunde hier die Nummer eines bereits gedruckten Auszugs angeben, um den Aus- +zug erneut zu erhalten. Bleibt das DE leer, so werden alle bislang nicht abgerufene +Kontoauszüge geliefert. Falls die Kontoauszugsnummer - ggf. in Kombination mit +dem Kontoauszugsjahr - nicht existiert, wird der Auftrag abgelehnt. + + +#### Kontoauszugsjahr + +Falls das Kreditinstitut den Ablauf historischer Kontoauszüge unterstützt und im Jah- +resturnus die Kontoauszugsnummer neu zu zählen beginnt, muss das DE Konto- +auszugsjahr belegt werden, um historische Kontoauszüge eindeutig kennzeichnen +zu können. Bleibt das DE leer, wird vom aktuellen Kalenderjahr ausgegangen. Falls +die Kontoauszugsnummer – ggf. in Kombination mit dem Kontoauszugsjahr – nicht +existiert, wird der Auftrag abgelehnt. + + +### b) Kreditinstitutsrückmeldung + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoauszug camt
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIECA
Bezugssegment:HKECA
Version:1
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2camt-Descriptor1DEan.25 6M1
3Berichtszeitraum2DEGM1
4Erstellungsdatum Kontoauszug1DEdat#O1
5Kontoauszugsjahr1DEnum4O1
6Kontoauszugs- nummer1DEnum..5O1
7Gebuchte Umsätze1DEbin..M1
8Informationen zum Rechnungsab- schluss2DEtxt..65 536O1
9Informationen zu Kundenbedingun- gen3DEtxt.65 536O1
10Werbetext2DEtxt..65O1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Konto- und Umsatz-Informationen
Geschäftsvorfälle		Stand: 07.08.2015Seite: 77
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
536
11IBAN Konto1DEan..34O1
12BIC Konto1DEan.. 11O1
13Auszugsname 11DEan..35O1
14Auszugsname 21DEan.35O1
15Namenszusatz1DEan..35O1
16Quittungscode1DEbin..O1
+ + +### ◆ Erläuterungen + + +#### Kontoauszugsnummer + +Die Kontoauszugsnummer muss der Kontoauszugsnummer im Feld LegalSe- +quence-Number der camt.053 message entsprechen (s. [Daten- +formate]), die gleichzeitig im Kreditinstitussegment übertragen wird. Die Kontoaus- +zugsnummer dient dabei der Zuordnung der nachfolgenden Textfelder zum dazuge- +hörigen Kontoauszug. + + +#### Gebuchte Umsätze + +Es ist eine gültige camt.053 message laut Anlage 3 des DFÜ-Abkommens einzustel- +len (s. [DFÜ-Abkommen]). Die verwendete camt.053 message muss der im „camt- +Descriptor" genannten Schema-Version entsprechen. + +. + + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
3010Es liegen keine Einträge vor
3040Auftrag nur teilweise ausgeführt
9210Keine gültige Kontoverbindung des Kunden
+ + +### c) Bankparameterdaten + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoauszug camt Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIECAS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Konto- auszug camt1DEGM1
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
78		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Konto- und Umsatz-Informationen
+ + +## C.2.4 Übersicht institutsverwalteter Aufträge + + +### C.2.4.1Segmentversion 1 + +Es werden zu allen institutsverwalteten Aufträgen die Basisdaten geliefert. + +Realisierung Bank: +optional + +Realisierung Kunde: optional + + +## a) Kundenauftrag + + +### Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Übersicht institutsverwalteter Aufträge anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKUTA
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3Alle Konten1DEjn#M1
4von Datum1DEdat#O1
5bis Datum1DEdat#O1
6Maximale Anzahl Einträge1DEnum..4C1>0
O: „Eingabe Anzahl Einträ- ge erlaubt“ (BPD) = ,J“ N: sonst
7Aufsetzpunkt1DEan.35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +## Belegungsrichtlinien + + +## Kontoverbindung international + +Wählt der Kunde die Option „Alle Konten“, so ist eine beliebige gültige Kontoverbin- +dung des Kunden einzustellen. + + +## b) Kreditinstitutsrückmeldung + + +## Beschreibung + +Falls der Kunde ,,Alle Konten" angegeben hat, wird für jedes Konto des Kunden ein +Segment nachfolgenden Formats in die Rückmeldenachricht eingestellt. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Geschäftsvorfälle Konto- und Umsatz-InformationenStand: 07.08.2015Seite: 79
+ + +## Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Übersicht institutsverwalteter Aufträge rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIUTA
Bezugssegment:HKUTA
Version:1
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Auftragsidentifikati- onDEan.99M1
3Kontoverbindung international1DEGkti#M1
4Angaben instituts- verwalteter Auftrag1DEGM1
5Einreichungsdatum1DEdat#M1
6Ausführungsdatum1DEdat#M1
7Betrag2DEGbtg#C1M: Art des terminierten Auf- trags= 1-5 N: sonst
8Name Empfän- ger/Zahlungspflichti ger 11DEan..35C1O: Art des terminierten Auf- trags= 1-5 N: sonst
9Name Empfän- ger/Zahlungspflichti ger 21DEan..35CO: „Name Empfän- ger/Zahlungspflichtiger 1" belegt N: sonst
10Verwendungszweck3DEGC1O: Art des terminierten Auf- trags= 1-5 N: sonst
11Anzahl der Aufträge1DEnum..5C1M: Art des terminierten Auf- trags=6-10 N: sonst
12Summe der Beträ- ge1DEGbtg#C1M: Art des terminierten Auf- trags=6-10 N: sonst
+ + +## Ausgewählte Beispiele für Rückmeldungscodes + +Code Beispiel für Rückmeldungstext + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
80		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Konto- und Umsatz-Informationen
+ + +9210 +Keine gültige Kontoverbindung des Kunden + + +## c) Bankparameterdaten + + +### Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Übersicht institutsverwalteter Aufträge Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIUTAS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Über- sicht institutsver- walteter Aufträge anfordern1DEGM1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle
Konto- und Umsatz-Informationen		Stand: 07.08.2015Seite: 81
+ + +# C.2.4.2Segmentversion 2 + +Es werden zu allen institutsverwalteten Aufträgen die Basisdaten geliefert. + +Realisierung Bank: +optional + +Realisierung Kunde: +optional + + +# d)a) Kundenauftrag + + +## Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Übersicht institutsverwalteter Aufträge anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKUTA
Bezugssegment:-
Version:42
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3Alle Konten1DEjn#M1
4von Datum1DEdat#O1
5bis Datum1DEdat#O1
6Maximale Anzahl Einträge1DEnum.4C1>0
O: „Eingabe Anzahl Einträ- ge erlaubt“ (BPD) = ,J“ N: sonst
7Aufsetzpunkt1DEan.35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +# Belegungsrichtlinien + + +## Kontoverbindung international + +Wählt der Kunde die Option „Alle Konten“, so ist eine beliebige gültige Kontoverbin- +dung des Kunden einzustellen. + + +# e)b) Kreditinstitutsrückmeldung + + +# Beschreibung + +Falls der Kunde ,,Alle Konten" angegeben hat, wird für jedes Konto des Kunden ein +Segment nachfolgenden Formats in die Rückmeldenachricht eingestellt. + + +## Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Übersicht institutsverwalteter Aufträge rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIUTA
Bezugssegment:HKUTA
Version:42
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 82Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Konto- und Umsatz-Informationen
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Auftragsidentifikati- onDEan.99M1
3Kontoverbindung international1DEGkti#M1
4Angaben instituts- verwalteter Auftrag1DEGM1
5Einreichungsdatum1DEdat#M1
6Ausführungsdatum1DEdat#M1
7Betrag2DEGbtg#C1M: Art des terminierten Auf- trags= 1-5 N: sonst
8Name Empfän- ger/Zahlungspflichti ger 11DEan..35C1O: Art des terminierten Auf- trags= 1-5 N: sonst
9Name Empfän- ger/Zahlungspflichti ger 21DEan.35CO: „Name Empfän- ger/Zahlungspflichtiger 1" belegt N: sonst
10Verwendungszweck SEPA31DEGan..140C1O: Art des terminierten Auf- trags= 1-5 N: sonst
11Anzahl der Aufträge1DEnum..5C1M: Art des terminierten Auf- trags=6-10 N: sonst
12Summe der Beträ- ge1DEGbtg#C1M: Art des terminierten Auf- trags=6-10 N: sonst
13Informationen zum Einzelauftrag1DEGOn
SEPA-C-Code1DEcode#O11, 2, 3
Status SEPA Auftrag1DEcode#O11, 2, 3, 4, 5
+ + +### Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
9210Keine gültige Kontoverbindung des Kunden
+ + +### f)c) Bankparameterdaten + +Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle Konto- und Umsatz-InformationenStand: 07.08.2015Seite: 83
+ + +#### Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Übersicht institutsverwalteter Aufträge Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIUTAS
Bezugssegment:HKVVB
Version:42
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Über- sicht institutsver- walteter Aufträge anfordern24DEGM1
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
84		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Konto- und Umsatz-Informationen
+ + +#### C.2.5 Elektronischer Kontoauszug PDF + + +##### C.2.5.1Segmentversion 1 + +Dieser Geschäftsvorfall eignet sich beim Online-Banking zur Realisierung des ,Elek- +tronischen Kontoauszugs". Die rechtlichen und geschäftspolitischen Voraussetzun- +gen für den „Elektronischen Kontoauszug" sind ggf. in separaten Dokumenten zu +beschreiben. + +Der Kontoauszug enthält alle Umsätze, die seit dem letzten Ausdruck eines Konto- +auszugs (am Kontoauszugdrucker bzw. als elektronischer Kontoauszug) für das je- +weilige Konto angefallen sind. Darüber hinaus ist es möglich Kreditinstitutsseitig be- +reits erstellte, aber bislang noch nicht abgerufene, ältere Kontoauszüge gleichzeitig +abzurufen. Im Gegensatz zu den Kontoumsätzen enthält der Kontoauszug keine +nicht-gebuchten Umsätze. + +Realisierung Bank: +optional + +Realisierung Kunde: optional + + +##### a) Kundenauftrag + + +###### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoauszug PDF anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKEKP
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3Kontoauszugs- nummer1DEnum..5C1>0
O: ,Kontoauszugsnummer erlaubt“ (BPD) = ,J“ N: sonst
4Kontoauszugsjahr1DEnum4C1>0
O: ,Kontoauszugsnummer erlaubt“ (BPD) = ,J“ N: sonst
5Maximale Anzahl Einträge1DEnum..4C1>0 O: „Eingabe Anzahl Einträge erlaubt" (BPD) = ,J" N: sonst
6Aufsetzpunkt1DEan..35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +##### . Belegungsrichtlinien + + +##### Kontoauszugsnummer + +Falls das Kreditinstitut den Abruf historischer Kontoauszüge unterstützt, kann der +Kunde hier die Nummer eines bereits gedruckten Auszugs angeben, um den Aus- + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle Konto- und Umsatz-InformationenStand: 07.08.2015Seite: 85
+ + +zug erneut zu erhalten. Bleibt das DE leer, so werden alle bislang nicht abgerufenen +Kontoauszüge geliefert. Falls die Kontoauszugsnummer - ggf. in Kombination mit +dem Kontoauszugsjahr - nicht existiert, wird der Auftrag abgelehnt. + + +#### Kontoauszugsjahr + +Falls das Kreditinstitut den Ablauf historischer Kontoauszüge unterstützt und im Jah- +resturnus die Kontoauszugsnummer neu zu zählen beginnt, muss das DE Konto- +auszugsjahr belegt werden, um historische Kontoauszüge eindeutig kennzeichnen +zu können. Bleibt das DE leer, wird vom aktuellen Kalenderjahr ausgegangen. Falls +die Kontoauszugsnummer – ggf. in Kombination mit dem Kontoauszugsjahr – nicht +existiert, wird der Auftrag abgelehnt. + + +# b) Kreditinstitutsrückmeldung + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoauszug PDF
Typ: Segment
Segmentart:Geschäftsvorfall
Kennung:HIEKP
Bezugssegment:HKEKP
Version:1
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Gebuchte Umsätze1DEbin..M1
3Quittungscode1DEbin. .O1
+ + +## ◆ Erläuterungen + + +### Gebuchte Umsätze + +Die gebuchten Umsätze sind als PDF einzustellen. + + +![](figures/105.1) + + +Kreditinstitutsseitig werden die Daten entgegen der Festlegung im +Data Dictionary in diesem speziellen Fall (!) base64-kodiert ein- +gestellt. Dies wird in einer geplanten neuen Segmentversion wie- +der korrigiert werden. + + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
3010Es liegen keine Einträge vor
3040Auftrag nur teilweise ausgeführt
9210Keine gültige Kontoverbindung des Kunden
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
86		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Konto- und Umsatz-Informationen
+ + +# c) Bankparameterdaten + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoauszug PDF Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIEKPS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Konto- auszug PDF1DEGM1
+ + +### C.2.5.2Segmentversion 2 + +Dieser Geschäftsvorfall eignet sich beim Online-Banking zur Realisierung des ,,Elek- +tronischen Kontoauszugs". Die rechtlichen und geschäftspolitischen Voraussetzun- +gen für den „Elektronischen Kontoauszug" sind ggf. in separaten Dokumenten zu +beschreiben. + +Der Kontoauszug enthält alle Umsätze, die seit dem letzten Ausdruck eines Konto- +auszugs (am Kontoauszugdrucker bzw. als elektronischer Kontoauszug) für das je- +weilige Konto angefallen sind. Darüber hinaus ist es möglich Kreditinstitutsseitig be- +reits erstellte, aber bislang noch nicht abgerufene, ältere Kontoauszüge gleichzeitig +abzurufen. Im Gegensatz zu den Kontoumsätzen enthält der Kontoauszug keine +nicht-gebuchten Umsätze. + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +#### a) Kundenauftrag + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoauszug PDF anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKEKP
Bezugssegment:-
Version:22
Sender:Kunde
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Geschäftsvorfälle Konto- und Umsatz-InformationenStand: 07.08.2015Seite: 87
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3Kontoauszugs- nummer1DEnum.5C1>0
O: ,Kontoauszugsnummer erlaubt“ (BPD) = ,J“ N: sonst
4Kontoauszugsjahr1DEnum4C1>0
O: ,Kontoauszugsnummer erlaubt“ (BPD) = ,J“ N: sonst
5Maximale Anzahl Einträge1DEnum..4C1>0
O: „Eingabe Anzahl Einträge erlaubt“ (BPD) = ,J“ N: sonst
6Aufsetzpunkt1DEan.35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +# . Belegungsrichtlinien + + +## Kontoauszugsnummer + +Falls das Kreditinstitut den Abruf historischer Kontoauszüge unterstützt, kann der +Kunde hier die Nummer eines bereits gedruckten Auszugs angeben, um den Aus- +zug erneut zu erhalten. Bleibt das DE leer, so werden alle bislang nicht abgerufenen +Kontoauszüge geliefert. Falls die Kontoauszugsnummer - ggf. in Kombination mit +dem Kontoauszugsjahr – nicht existiert, wird der Auftrag abgelehnt. + + +## Kontoauszugsjahr + +Falls das Kreditinstitut den Ablauf historischer Kontoauszüge unterstützt und im Jah- +resturnus die Kontoauszugsnummer neu zu zählen beginnt, muss das DE Konto- +auszugsjahr belegt werden, um historische Kontoauszüge eindeutig kennzeichnen +zu können. Bleibt das DE leer, wird vom aktuellen Kalenderjahr ausgegangen. Falls +die Kontoauszugsnummer - ggf. in Kombination mit dem Kontoauszugsjahr - nicht +existiert, wird der Auftrag abgelehnt. + + +## b) Kreditinstitutsrückmeldung + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
. Format
Name:Kontoauszug PDF
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIEKP
Bezugssegment:HKEKP
Version:22
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
88		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Konto- und Umsatz-Informationen
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Gebuchte Umsätze1DEbin..M1
3Berichtszeit- raumBerichtszeitrau m22DEG DEGM414
4Erstellungsdatum Kontoaus- zugErstellungsdatu m Kontoauszug14DED Edat- dat14
5Kontoauszugs- jahrKontoauszugsja hr14DED Enum num4414
6Kontoauszugs- nummerKontoaus- zugsnummer14DED Enum num..5..514
7IBAN KontoIBAN Konto11DED Eanan..34.- 3414
8BIC KontoBIC Kon-14DED Eanan..11.- 1114
9Auszugsname 1Auszugsname 114DED Eanan..35- 3514
10Auszugsname 2Auszugsname 214DED Eanan..35- 3514
11Namenszu- satzNamenszusatz14DED Eanan..35.- 3514
12Dateina- meDateiname14DED Eanan256- .25614
13Quittungscode1DEbin..O1
+ + +## ◆ Erläuterungen + + +### Gebuchte Umsätze + +Die gebuchten Umsätze sind als PDF einzustellen. Abhängig von der Belegung des +BPD-Datenelementes ,base64 kodiert" ist das PDF-Dokument nach base64 kodiert +oder nicht. Abhängig von der Belegung des BPD-Datenelementes ,,base64 kodiert" +ist das PDF-Dokument nach base64 kodiert oder nicht. + +◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
3010Es liegen keine Einträge vor
3040Auftrag nur teilweise ausgeführt
9210Keine gültige Kontoverbindung des Kunden
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle
Konto- und Umsatz-Informationen		Stand: 07.08.2015Seite: 89
+ + +# c) Bankparameterdaten + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kontoauszug PDF Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIEKPS
Bezugssegment:HKVVB
Version:22
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Konto- auszug PDF22DEGM1
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
90		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Termineinlagen
+ + +### C.3 Termineinlagen + +Derzeit ist nur die Festgeldanlage vorgesehen. Die Anlage von Kündigungsgeldern +ist nicht möglich. + +Für die Festgeldanlage sind die folgenden Geschäftsvorfälle vorgesehen: + +· Abfrage der z.Zt. gültigen Konditionen + +• Auftrag zur Neuanlage eines Festgeldes + +· Ändern vorhandener Festgelder + +. Prolongation bestehender Festgeldanlagen + +. Anzeige des Festgeldbestandes eines Kunden + +. Widerruf einer vorgemerkten Festgeldneuanlage + +. Widerruf einer Festgeldprolongation + +Der Abruf von Umsätzen (Nachträgen) ist online nicht vorgesehen. Die Abbildung +zeigt die Abfolge der Geschäftsvorfälle: + + +Abbildung 1: Lebenszyklus Festgeld + +![Festgeldkonditionen anfordern Festgeldkonditionen rückmelden Festgeldneuanlage Kreditinstitut K Festgeldneuanlage bestätigen Festgeldneuanlage widerrufen K u (kein Datensegment) n d e Festgeldanlage ändern Festgeldänderung bestätigen Festgeldanlage prolongieren Festgeldprolongation bestätigen n S t i t u t Festgeldprolongation widerrufen (kein Datensegment) Festgeldbestand abrufen Festgeldbestand rückmelden](figures/110.1) + + +Im Rahmen der Festgeldanlage werden verschiedene Konten spezifiziert (Anlage- +konto, Belastungskonto etc.). Welches dieser Konten jeweils zur Berechtigungsprü- +fung herangezogen wird, kann kreditinstitutsindividuell entschieden werden. + +Folgende Datenformate sind für die Festgeldanlage vorgesehen. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Geschäftsvorfälle TermineinlagenStand: 07.08.2015Seite: 91
+ + +#### C.3.1 Festgeldkonditionen + + +![](figures/111.1) + + +Die abgerufenen Festgeldkonditionen können dem Kundenprodukt +auch dazu dienen, Modell- oder Beispielrechnungen im Offline- +Betrieb auf der Basis aktueller Daten durchzuführen. + + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +## a) Kundenauftrag + + +### . Beschreibung + +Die Standardkonditionen werden betrags- und laufzeitabhängig ermittelt. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Festgeldkonditionen anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKFGK
Bezugssegment:-
Version:3
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Währung der Kon- ditionen1DEcur#M1
3Maximale Anzahl Einträge1DEnum..4O1>0
4Aufsetzpunkt1DEan.35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +## b) Kreditinstitutsrückmeldung + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Festgeldkonditionen rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIFGK
Bezugssegment:HKFGK
Version:3
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Version der Kondi- tionen1DEGM1
3Festgeldkondition3DEGM1..99
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
92		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Termineinlagen
+ + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
3010Information wird zur Zeit nicht angeboten
+ + +## c) Bankparameterdaten + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Festgeldkonditionen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIFGKS
Bezugssegment:HKVVB
Version:3
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Fest- geldkonditionen1DEGM1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle TermineinlagenStand: 07.08.2015Seite: 93
+ + +#### C.3.2 Festgeldneuanlage + +Ein Auftrag zur Festgeldanlage bedingt im Regelfall die Eröffnung eines Festgeld- +kontos. Da mit einer Kontoeröffnung üblicherweise administrative Vorgänge (z.B. +Bonitätsprüfung) verbunden sind, deren Umfang einerseits davon abhängig ist, ob +der Kunde bereits ein Konto beim betreffenden Institut führt, und andererseits davon +abhängt, inwieweit diese Vorgänge einer manuellen Bearbeitung bedürfen, ist die +kreditinstitutsseitige Reaktion auf einen Auftrag zur Festgeldanlage institutsindividu- +ell verschieden. Eine weitgehend problemlose Bearbeitung des Auftrags ist insbe- +sondere dann möglich, wenn der dialogführende Kunde Inhaber des Belastungskon- +tos ist. Eine Festgeldanlage zugunsten Dritter ist online nicht vorgesehen. Die Fra- +ge, auf welchen Namen ein Festgeldkonto eröffnet werden soll, ist rein bankfachli- +cher Natur und somit nicht Aufgabe der Schnittstelle, sondern des Kreditinstituts. + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +##### a) Kundenauftrag + + +###### . Beschreibung + + +![](figures/113.1) + + +Änderungen der Festgeldkonditionen können sehr kurzfristig erfol- +gen. Daher hat der Kunde vor der Versendung eines Festgeldauf- +trages die aktuellen Konditionen abzurufen (s.o.). Falls der Kunde +im Besitz eines veralten Konditionsbestandes ist, kann der Auftrag +abgewiesen werden. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Festgeldneuanlage
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKFGN
Bezugssegment:-
Version:4
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Anlagekonto3DEGktv#C1O: , Bestehendes Anlage- konto erlaubt" (BPD) = ,J" N: sonst
3Kontraktreferenz1DEid#O1
4Anlagebetrag1DEGbtg#M1
5Festgeldkondition3DEGM1
6Belastungskonto3DEGktv#M1
7Eigene Rechnung1DEjn#M1
8Wiederanlagekenn- zeichen2DEcode1M11,2
9Kontoauszugskenn- zeichen2DEcode1O11,2
10Ausbuchungskonto3DEGktv#C1O: ,,Abweichendes Ausbu- chungskonto erlaubt" (BPD)
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
94		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Termineinlagen
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
= „J“ N: sonst
11Zinsgutschriftkonto3DEGktv#C1O: ,,Abweichendes Zinsgut- schriftkonto erlaubt" (BPD) = „J“ N: sonst
12Version der Kondi- tionen1DEGM1
+ + +# . Belegungsrichtlinien + + +## Anlagekonto + +Das Anlagekonto ist nur anzugeben, wenn auf ein bereits bestehendes An- +lagekonto ein weiteres Festgeld (weitere Tranche) angelegt werden soll. + + +## Anlagebetrag + +Der Anlagebetrag muss größer oder gleich dem in den Festgeldkonditionen +mitgeteilten Mindestanlagebetrag sein. + + +## Ausbuchungskonto + +Wird kein Ausbuchungskonto angegeben, so erfolgt die Ausbuchung auf das +Belastungskonto. + + +## Zinsgutschriftkonto + +Wird kein Zinsgutschriftkonto angegeben, so erfolgt die Zinsgutschrift auf +dem Belastungskonto. + + +## b) Kreditinstitutsrückmeldung + + +## . Beschreibung + + +![](figures/114.1) + + +Falls das Kreditinstitut schon bei der Einreichung das Anlagekonto +zurückmelden kann, sollte diese Möglichkeit genutzt werden. + +Andernfalls muss das Kundensystem nach einer Festgeldneu- +anlage zunächst die betreffende Anlagekontonummer in Erfahrung +bringen, bevor der Kunde eine Modifikation seiner Anlage (Ände- +rung, Prolongation) vornehmen kann. Hierzu ist zunächst ein Abruf +des gesamten Festgeldbestandes (s. Kap. C.3.5) vorzunehmen, +wobei das DE ,,Alle Konten" auf 'J' gesetzt ist. In der Antwortnach- +richt wird dem Kunden für jede Anlage die entsprechende Anla- +gekontonummer (Kontoverbindung) zurückgemeldet. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle
Termineinlagen		Stand: 07.08.2015Seite: 95
+ + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Festgeldneuanlage bestätigen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIFGN
Bezugssegment:HKFGN
Version:4
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Anlagekonto3DEGktv#O1
3Kontraktreferenz1DEid#O1
+ + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
0020Auftrag ausgeführt
9210Festgeldkonditionen sind nicht aktuell; bitte erst aktualisieren
9210Betrag zu niedrig
9210Kontoverbindung existiert nicht
9210Keine gültige Kontoverbindung des Kunden
+ + +### c) Bankparameterdaten + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Festgeldneuanlage Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIFGNS
Bezugssegment:HKVVB
Version:4
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Fest- geldneuanlage3DEGM1
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
96		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Termineinlagen
+ + +##### C.3.3 Festgeldänderung + +Mit Hilfe der Festgeldänderung können Änderungen für bestehende Festgeldanla- +gen während der Laufzeit durchgeführt werden. Betrags- und Laufzeitänderungen +sind nicht zugelassen. Die Änderungen werden sofort wirksam. Es können nur akti- +ve Festgeldanlagen geändert werden. Die Änderung von vorgemerkten Anlagen ist +nicht möglich. + +Welche Daten änderbar sind, bestimmt das Kreditinstitut in den Bankparameter- +daten. Grundsätzlich änderbar sind die folgenden Daten: + +. Belastungskonto + +. Wiederanlagekennzeichen + +. Kontoauszugskennzeichen + +. Ausbuchungskonto + +. Zinsgutschriftkonto + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +###### a) Kundenauftrag + + +####### . Beschreibung + +Für alle laut Bankparameterdaten änderbaren Felder sind die neuen Werte einzu- +stellen, d.h. für die Felder, die änderbar sind, jedoch nicht geändert werden sollen, +sind die bisherigen Werte einzutragen. Dies ist erforderlich, um ein Feld auf 'nicht +belegt' ändern zu können (bspw. erforderlich beim Zinsgutschriftkonto). + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Festgeldanlage ändern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKFGA
Bezugssegment:-
Version:4
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Anlagekonto3DEGktv#O1
3Kontraktreferenz1DEid#C1M: ,Kontraktreferenz“ wurde vom Institut erteilt N: sonst
4Anlagebetrag1DEGbtg#M1
5Festgeldkondition3DEGM1
6Belastungskonto3DEGktv#C1M: „Belastungskonto än- derbar" (BPD) ="J" N: sonst
7Eigene Rechnung1DEjn#M1
8Wiederanlagekenn- zeichen2DEcode1C11,2
M: ,,Wiederanlagekennzei-
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle TermineinlagenStand: 07.08.2015Seite: 97
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
chen änderbar“ (BPD) =“J“ N: sonst
9Kontoauszugskenn- zeichen2DEcode1C11,2
M: ,,Kontoauszugskennzei- chen änderbar“ (BPD) =“J“ N: sonst
10Ausbuchungskonto3DEGktv#C1M: „Ausbuchungskonto än- derbar" (BPD) ="J" N: sonst
11Zinsgutschriftkonto3DEGktv#C1M: „Zinsgutschriftkonto än- derbar" (BPD) ="J" N: sonst
+ + +###### . Belegungsrichtlinien + + +####### Anlagebetrag + +Der Anlagebetrag muss größer oder gleich dem in den Festgeldkonditionen +mitgeteilten Mindestanlagebetrag sein. + + +###### b) Kreditinstitutsrückmeldung + + +####### . Beschreibung + +Bei der Rückmeldung sind die für diese Festgeldanlage aktuell gültige Anlagekonto- +daten (Anlagekonto, evtl. Kontraktreferenz) anzugeben. Wurde der Änderungsauf- +trag bankseitig durch eine Löschung und Neueinreichung realisiert, so sind aus Zu- +ordnungsgründen die bisherigen Anlagekontodaten mitzuteilen. + + +![](figures/117.1) + + +Falls eine neue Anlagekontoverbindung vergeben wurde, ist der +lokale Bestand im Kundenprodukt zu aktualisieren. + + +####### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Festgeldänderung bestätigen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIFGA
Bezugssegment:HKFGA
Version:4
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Anlagekonto3DEGktv#M1
3Kontraktreferenz1DEid#O1
4Anlagekonto alt3DEGktv#C1M: Anlagekonto wurde vom Institut geändert N: sonst
5Kontraktreferenz alt1DEid#O1
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
98		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Termineinlagen
+ + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
0020Festgeldanlage geändert
9210Festgeldkonto existiert nicht
9210Konto ist kein Festgeldkonto
9210Keine gültige Kontoverbindung des Kunden
+ + +## c) Bankparameterdaten + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Festgeld ändern Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIFGAS
Bezugssegment:HKVVB
Version:4
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Festgeld ändern2DEGM1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle
Termineinlagen		Stand: 07.08.2015Seite: 99
+ + +#### C.3.4 Festgeldprolongation + +Mit Hilfe der Prolongation sind Änderungen einer bestehenden Festgeldanlage für +die nächste Anlageperiode möglich. Eine Prolongation kann nur für eine bereits be- +stehende Festgeldanlage durchgeführt werden. Die Datenelemente sind mit gültigen +Daten der Festgeldanlage zu belegen, damit Plausibilitätsprüfungen erfolgen kön- +nen. + +Die Rahmendaten der Anlage (z.B. Belastungskonto) werden bei der Neuanlage +festgelegt und können im Rahmen der Prolongation nicht verändert werden. + +Falls bei der Festgeldneuanlage mit Hilfe des Wiederanlagekennzeichens festgelegt +wurde, dass die Anlage bei ihrer Fälligkeit prolongiert werden soll, ist keine explizite +Prolongation erforderlich. Ein Prolongationsauftrag ist vom Kunden lediglich dann zu +senden, wenn: + +• die bei der Neuanlage getroffene Entscheidung, dass die Anlage nach ihrer Fäl- +ligkeit ausgebucht werden soll, revidiert werden soll (In diesem Fall wird das bei +der Neuanlage festgelegte Wiederanlagekennzeichen überschrieben). + +· für den nächsten Anlagezeitraum die Laufzeit oder der Anlagebetrag geändert +werden soll. + + +![](figures/119.1) + + +Prolongation bedeutet nicht zwingend, dass die in der aktuellen An- +lageperiode gültigen Konditionen weiterhin gelten. Der Kunde kann +zum Zeitpunkt der Prolongation nicht wissen, zu welchem Zinssatz +er prolongiert, da für die Prolongation derjenige Zinssatz herange- +zogen wird, der zum Zeitpunkt des Inkrafttretens der Prolongation +aktuell gültig ist. Der Kunde ist an geeigneter Stelle (z.B. Kunden- +bedingungen) auf diesen Sachverhalt hinzuweisen. + +Der Kunde kann einen Prolongationsauftrag ändern, indem er einen zweiten Prolon- +gationsauftrag schickt und damit den bestehenden Auftrag überschreibt. Dies gilt je- +doch nur, sofern der erste Auftrag noch nicht wirksam geworden ist. + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +##### a) Kundenauftrag + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Festgeldanlage prolongieren
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKFGP
Bezugssegment:-
Version:4
Sender:Kunde
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 100Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Termineinlagen
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Anlagekonto3DEGktv#O1
3Kontraktreferenz1DEid#C1M: ,Kontraktreferenz" wurde vom Institut erteilt N: sonst
4Anlagebetrag1DEGbtg#M1
5Festgeldkondition3DEGM1
6Belastungskonto3DEGktv#M1
7Eigene Rechnung1DEjn#M1
8Wiederanlagekenn- zeichen2DEcode1M11,2
9Kontoauszugskenn- zeichen2DEcode1O11,2
10Ausbuchungskonto3DEGktv#O1
11Zinsgutschriftkonto3DEGktv#O1
12Version der Kondi- tionen1DEGO1
13Prolongation2DEGM1
+ + +##### b) Kreditinstitutsrückmeldung + + +###### . Beschreibung + +s. „Festgeldänderung“ + + +![](figures/120.1) + + +Falls eine neue Anlagekontoverbindung vergeben wurde, ist der +lokale Bestand im Kundenprodukt zu aktualisieren. + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Festgeldprolongation bestätigen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIFGP
Bezugssegment:HKFGP
Version:4
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Anlagekonto3DEGktv#M1
3Kontraktreferenz1DEid#O1
4Anlagekonto alt3DEGktv#C1M: Anlagekonto wurde vom Institut geändert N: sonst
5Kontraktreferenz alt1DEid#O1
6Festgeldkondition3DEGO1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle TermineinlagenStand: 07.08.2015Seite: 101
+ + +###### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
0020Festgeldanlage prolongiert
9210Festgeldkonto existiert nicht
9210Konto ist kein Festgeldkonto
9210Laufzeit und Anlagebetrag entsprechen nicht den aktuellen Festgeldkonditionen
9210Anlagebetrag geringer als Mindestaufstockungsbetrag
+ + +##### c) Bankparameterdaten + + +###### . Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + +###### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Festgeldprolongation Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIFGPS
Bezugssegment:HKVVB
Version:4
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
102		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Termineinlagen
+ + +#### C.3.5 Festgeldbestandsabfrage + + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +# a) Kundenauftrag + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Festgeldbestand anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKFGB
Bezugssegment:-
Version:4
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Anlagekonto3DEGktv#M1
3Kontraktreferenz1DEid#O1
4Alle Konten1DEjn#M1
5Maximale Anzahl Einträge1DEnum..4O1>0
6Aufsetzpunkt1DEan.35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +# . Belegungsrichtlinien + + +## Anlagekonto + +Falls die Option ,,Alle Konten" gewählt wird, ist ein beliebiges Anlagekonto +des Kunden einzustellen. Falls noch keine Anlagekontonummer bekannt ist +(s.o.), muss ersatzweise ein Kontokorrentkonto des Kunden eingestellt wer- +den. + + +## b) Kreditinstitutsrückmeldung + + +### . Beschreibung + +Es sind jeweils die für die gegenwärtige Anlageperiode gültigen Daten der Festgeld- +anlage einzustellen, damit Plausibilitätsprüfungen erfolgen können. + +Falls der Kunde „Alle Konten“ gewählt hat, ist das Segment für jede Festgeldanlage +jeweils einmal einzustellen. Falls der Kunde ein Anlagekonto angibt, so ist das +Segment für jeden unter diesem Konto angelegten Kontrakt einzustellen, es sei +denn, im Kundenauftrag wurde eine spezielle Kontraktreferenz angegeben. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle
Termineinlagen		Stand: 07.08.2015Seite: 103
+ + +# . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Festgeldbestand rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIFGB
Bezugssegment:HKFGB
Version:4
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Anlagekonto3DEGktv#M1
3Kontraktreferenz1DEid#O1
4Anlagebetrag1DEGbtg#M1
5Festgeldkondition3DEGM1
6Belastungskonto3DEGktv#M1
7Eigene Rechnung1DEjn#M1
8Wiederanlagekenn- zeichen2DEcode1M11,2
9Kontoauszugskenn- zeichen2DEcode1O11,2
10Ausbuchungskonto3DEGktv#O1
11Zinsgutschriftkonto3DEGktv#O1
12Version der Kondi- tionen1DEGO1
13Zinsertrag voraus- sichtlich1DEGbtg#O1
14Festgeldstatus2DEcode1M11,2
15Prolongation2DEGC1M: Prolongation wurde für den nächsten Anlagezeit- raum beantragt N: sonst
+ + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
3010Es liegen keine Festgeldanlagen vor
9210Angegebenes Konto ist kein Festgeldkonto
+ + +# c) Bankparameterdaten + + +## . Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
104		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Termineinlagen
+ + +# . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Festgeldbestand Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIFGBS
Bezugssegment:HKVVB
Version:4
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle TermineinlagenStand: 07.08.2015Seite: 105
+ + +## C.3.6 Widerruf einer Festgeldneuanlage + +Dieser Geschäftsvorfall darf nur bei vorgemerkten Festgeldanlagen, d.h. terminier- +ten Anlagen, die noch nicht wirksam geworden sind, gesendet werden. Bei aktiven +Festgeldanlagen wird dieser Auftrag abgelehnt. + +Dieser Auftrag ist nur möglich, wenn dem Kunden bei der Neuanlage eine Anlage- +kontonummer mitgeteilt wurde, mit der die zu widerrufende Festgeldanlage identifi- +ziert werden kann. + +Realisierung Bank: +optional + +Realisierung Kunde: optional + + +# a) Kundenauftrag + + +## . Beschreibung + +Die Datenelemente sind mit gültigen Daten der Festgeldanlage zu belegen, damit +Plausibilitätsprüfungen erfolgen können. + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Festgeldneuanlage widerrufen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKFGW
Bezugssegment:-
Version:4
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Anlagekonto3DEGktv#M1
3Kontraktreferenz1DEid#C1M: Kontraktreferenz wurde vom Institut erteilt N: sonst
4Anlagebetrag1DEGbtg#M1
5Festgeldkondition3DEGM1
6Belastungskonto3DEGktv#M1
7Eigene Rechnung1DEjn#M1
8Wiederanlagekenn- zeichen2DEcode1M11,2
9Kontoauszugskenn- zeichen2DEcode1O11,2
10Ausbuchungskonto3DEGktv#O1
11Zinsgutschriftkonto3DEGktv#O1
12Version der Kondi- tionen1DEGO1
+ + +# b) Kreditinstitutsrückmeldung + + +## . Beschreibung + +Es werden keine Datensegmente zurückgemeldet. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
106		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Termineinlagen
+ + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
0020Festgeldanlage storniert
9210Widerruf nicht mehr möglich, da Festgeldanlage schon erfolgt ist
+ + +# c) Bankparameterdaten + + +## . Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Festgeldneuanlage widerrufen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIFGWS
Bezugssegment:HKVVB
Version:4
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle TermineinlagenStand: 07.08.2015Seite: 107
+ + +### C.3.7 Widerruf einer Festgeldprolongation + +Mit Hilfe dieses Geschäftsvorfall kann ein noch nicht wirksam gewordener Auftrag +für eine Festgeldprolongation storniert werden. + + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +# a) Kundenauftrag + + +## . Beschreibung + +Die Datenelemente sind mit gültigen Daten der Festgeldanlage zu belegen, damit +Plausibilitätsprüfungen erfolgen können. + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Festgeldprolongation widerrufen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKFPW
Bezugssegment:-
Version:4
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Anlagekonto3DEGktv#M1
3Kontraktreferenz1DEid#C1M: Kontraktreferenz wurde vom Institut erteilt N: sonst
4Anlagebetrag1DEGbtg#M1
5Festgeldkondition3DEGM1
6Belastungskonto3DEGktv#M1
7Eigene Rechnung1DEjn#M1
8Wiederanlagekenn- zeichen2DEcode1M11,2
9Kontoauszugskenn- zeichen2DEcode1O11,2
10Ausbuchungskonto3DEGktv#O1
11Zinsgutschriftkonto3DEGktv#O1
12Version der Kondi- tionen1DEGO1
13Prolongation2DEGM1
+ + +## . Belegungsrichtlinien + + +## Prolongation + +Es sind die Daten anzugeben, die der Kunde im Prolongationsauftrag ange- +geben hat. + + +## b) Kreditinstitutsrückmeldung + + +## . Beschreibung + +Es werden keine Datensegmente zurückgemeldet. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
108		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Termineinlagen
+ + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
0020Festgeldprolongation storniert
9210Für diese Festgeldanlage wurde keine Prolongation eingereicht
9210Widerruf nicht mehr möglich, da Festgeldanlage schon prolongiert wurde
+ + +## c) Bankparameterdaten + + +### . Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Festgeldprolongation widerrufen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIFPWS
Bezugssegment:HKVVB
Version:4
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle WertpapiereStand: 07.08.2015Seite: 109
+ + +# C.4 Wertpapiere + +Generell werden für das Wertpapiergeschäft S.W.I.F.T.-Formate zugrunde gelegt, +um eine automatisierte Verarbeitung (,,straight through processing“) zu ermöglichen. +Die Nutzung des S.W.I.F.T.-Zeichensatzes innerhalb der S.W.I.F.T.-Formate ist +verbindlich. Es werden die jeweils aktuellen Message Types verwendet. Sobald die +auf EDIFACT beruhenden Formate für das Wertpapiergeschäft spezifiziert und ver- +abschiedet sind, werden diese ebenfalls auf Anwendbarkeit geprüft. + + +Abbildung 2: Verwendung von S.W.I.F.T.-Formaten im Wertpapiergeschäft + +![Kunde Kreditinstitut Wichtige Informationen Wertpapierorder MT 502 Orderänderung Orderstreichung Orderanzeige MT 502 Orderstatus MT 513 MT 515 Orderhistorie MT 502 Depotaufstellung MT 535 Depotumsätze MT 536 Festpreisorder MT 502 Neuemission zeichnen MT 502](figures/129.1) + + +Die Realisierung des Wertpapiergeschäftes ist optional. Falls das Kundensystem +Werte lokal speichern kann, kann eine Auftragsidentifikation als Antwort auf die +Wertpapierorder übermittelt werden, mit Hilfe derer der Kunde den Status eines be- +stimmten Auftrags erfragen oder Änderungen gezielter Aufträge durchführen kann. +Falls dem Kundensystem diese Auftragsidentifikation nicht vorliegt, hat es zunächst +mit Hilfe des Geschäftsvorfalls ,,Orderstatus" oder ,,Orderanzeige" die aktuelle Auf- +tragsidentifikation zu erfragen, bevor er Operationen an seinem Bestand vornehmen +kann. + +Es ist beim Wertpapiergeschäft auf die Unterscheidung zwischen Auftrag und Order +zu achten. Order ist der vom Ordersystem des Kreditinstitutes zur Ausführung an- +genommene Kundenauftrag. Auftrag ist die Auslösung eines Geschäftsvorfalles sei- +tens des Kunden. Für diese Aufträge vergibt das Kreditinstitut eine Auftragsidentifi- +kation. Diese technische Auftragsidentifikation kann sich von der bankfachlichen + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
110		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Wertpapiere
+ + +Ordernummer unterscheiden. Zur Identifikation der Order in der Kommunikation mit +dem Kundensystem können beide wahlweise genutzt werden. Es muss jedoch eine +von beiden belegt sein. Im Rahmen der Geschäftsvorfälle "Orderänderung" und +"Orderstreichung" existieren zwei Auftragsidentifikationen: die der Ursprungsorder +sowie die des Änderungs- bzw. Streichungsauftrages. + +Es ist zu beachten, dass ein Benutzer nicht unbedingt uneingeschränkte Berechti- +gung für alle Geschäftsvorfälle des Wertpapiergeschäfts besitzt. Falls der Benutzer +in mehreren unterschiedlichen Rollen mit jeweils eigenem Berechtigungsprofil auf- +tritt, so hat er u.U. zwischen der Ausführung unterschiedlicher Aufträge den Dialog +zu beenden und sich in einer Dialoginitialisierung in einer neuen Rolle zu legitimie- +ren. + + +![](figures/130.1) + + +Im Rahmen des Wertpapiergeschäfts (insb. Fondsgeschäft) sollten +Kundenprodukte bei Eingaben von Fließkommawerten wie z.B. +Stückzahlen und Zinssätzen mindestens drei Nachkommastellen +verarbeiten und anzeigen können sowie bei Kundeneingaben zulas- +sen. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle WertpapiereStand: 07.08.2015Seite: 111
+ + +![](figures/131.1) + + +Aus den MiFID-Anforderungen ergeben sich verschiedene Auswirkungen +auf die FinTSGeschäftsvorfälle, + +welche durch einen Herstellerhinweis kommuniziert werden müssen. + + +![](figures/131.2) + + +## 1. Best Execution: + +Die MiFID-Vorgaben sehen vor, dass jedes Kreditinstitut eigene Ausfüh- +rungsgrundsätze aufzustellen hat, nach denen ein Kundenauftrag im +bestmöglichen Interesse des Kunden (Best-Execution) ausgeführt wer- +den kann. Bestimmt werden hier in der Regel für verschiedene Wertpa- +piergattungen einzelne Börsenplätze, die in der Regel eine +bestmögliche Ausführung gewährleisten. Eine Order-by-Order-Prüfung +ist nicht notwendig; Weisungen des Kunden gehen immer vor. Im Online- +Banking werden viele Kreditinstitute solche Weisungen des Kunden ein- +holen. Sollte dennoch beim Senden einer limitierten Order +keine Weisung erteilt worden sein, kann es dazu kommen, dass die +Ausführungsgrundsätzen des jeweiligen Kreditinstituts (KI) auch auslän- +dische Börsenplätze vorsehen, an denen nicht in Euro gehandelt wird., +Es wird daher empfohlen vor einer Wertpapierorder grundsätzlich eine +Wertpapierstammdatenabfrage (HKWSD) durchzuführen. Im Rahmen +dieser der Order vorgeschalteten Stammdatenabfrage kann dem Kun- +denprodukt ebenfalls der Best Execution Börsenplatz im MIC-Code For- +mat am Anfang des Feldes "weitere Informationen" mitgeteilt werden. +Sollen daher weisungslose Orders unter FinTS angeboten werden, so +kann dies im Rahmen der verschiedenen MT 502-Versionen folgender- +maßen geschehen. + +SWIFT Standardreleaseguide 2002: + +Im MT 502 wird im Feld:94B: der Qualifier "FREE" (Börsenplatz soll vom +ausführenden Institut bestimmt werden) belegt. Es gelten die dort zusätz- +lich beschriebenen Belegungsrichtlinien, die sich aus der Belegung mit +"FREE" ergeben, jedoch fällt die Einschränkung hinsichtlich des Heimat- +marktes weg. + +Ist der Best Execution Börsenplatz aus einer vorangestellten Stammda- +tenabfrage nicht bekannt, können limitierte Orders nicht eindeutig erteilt +werden, da die Währung des Limits nicht eindeutig ist. Sollte eine Limitie- +rung erfolgen, kann sie nur in EUR erfolgen. Bei einer + +Weiterleitung an einen Handelsplatz mit abweichender Währung kann +die Order vom Abwickler nur abgewiesen werden. + +Ist der Best Execution Börsenplatz aus einer vorangestellten Stammda- +tenabfrage bekannt, soll bereits im Feld:94B: der Börsenplatz (wie bis- +her) zusammen mit dem Qualifier "FREE" eingestellt werden. Da die +Handelswährung bekannt ist, kann bei limitierten Orders die Handels- +währung des Limits korrekt eingestellt werden. + +Die Geschäftsvorfälle zu den Statusinformationen sollten institutsseitig +ebenfalls auf den SRG 2002 angehoben werden, um Informationsverlust +zu vermeiden, müssen es aber nicht zwingend. + +Für SRG 2002 ist bei der Rückmeldung der Ursprungsorder der be- +reits in der Ursprungsorder eingestellte oder der vom Abwickler +ermittelte Börsenplatz, wie bei einer Weisungsorder, im Feld:94B: +zusammen mit dem Qualifier "FREE" einzustellen. + +Die in der BPD verfügbaren Börsenplätze sollten mit den Börsenplätzen +der Best Execution Policy übereinstimmen. + + +### 2. Angemessenheit: + +Eine Order darf zukünftig nur dann direkt im Online-Banking ausgeführt +werden, wenn die laut WpHG vorgeschriebenen Angaben des Kunden zu + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
112		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Wertpapiere
+ + +seinen Kenntnissen und Erfahrungen vorliegen und die gewünschte Or- +der für den Kunden angemessen ist, d.h. er in der Lage ist, die Risiken +seiner Anlageentscheidung zu verstehen. Ist dies nicht der Fall, muss der +Kunde gewarnt werden. . Dies erfolgt durch das Einstellen des Wertes ,J' +im Feld ,Erneutes Senden erforderlich', der Beschreibung des Mangels in +dem Feld ,,Auftragsbezogene Informationen" und einer Auftragsidentifika- +tion im durch den WP-Abwickler gesendeten Antwortsegmenten der be- +troffenen Geschäftsvorfällen. Es wird zur Kenntlichmachung ein eindeuti- +ger Rückmeldecode definiert (3060 "Zunächst Wertpapierinformationen +lesen und dann ggf. den + +Auftrag erneut senden"). Das Kundenprodukt hat den Auftrag nach Be- +stätigung des Kunden unverändert erneut einzureichen. + +Erst durch explizite Bestätigung der Order durch die erneute Ein- +reichung derselben Order mit der dazugehörigen Auftragsidentifika- +tion darf der Auftrag ausgeführt werden. Dies betrifft die Geschäfts- +vorfälle HKWPO, HKWOA, HKWPS, HKWFO, HKFPO, HKNEZ. + + +![](figures/132.1) + + +Laut OGAW-IV-Umsetzungsgesetz wird ab 1.7.2011 das zur Ver- +fügung stellen des Verkaufsprospekts für Investmentfonds vor Auf- +tragserteilung und TAN-Eingabe gefordert. + + +![](figures/132.2) + + +In der DE "weitere Informationen" wird im Anhang an die bereits +bisher dort übertragenen Daten zwischen den Tags und + eine vollständige URL übertragen, die direkt durch ei- +nen Browser verwendet werden kann. + +Diese aktuell verfügbaren Verkaufsunterlagen sollen dem Kunden +zum Download bei der Investmentfondsorder über die FinTS- +Geschäftsvorfälle HKWFO und HKWPO vor der TAN-Eingabe an- +geboten werden. + +Der Kunde muss vor der TAN-Eingabe (z.B. über eine Checkbox) +bestätigen, dass er die Möglichkeit zur Ansicht der aktuellen Ver- +kaufsunterlagen zur Kenntnis genommen hat. Bestätigt er dies +nicht, darf die Order nicht erteilt und somit durch das Kundenpro- +dukt nicht versendet werden. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle WertpapiereStand: 07.08.2015Seite: 113
+ + +#### C.4.1 Wertpapierorder + + +##### C.4.1.1 Wichtige Informationen anfordern + +Realisierung Bank: +optional + +Realisierung Kunde: verpflichtend, wenn mindestens einer der Geschäftsvorfälle +„Wertpapierorder“, „Orderänderung“ oder ,,Orderstreichung" +vom Kundensystem unterstützt wird + +Mit Hilfe dieses Geschäftsvorfalls wird dem Kreditinstitut die Möglichkeit gegeben, +gemäß WpHG dem Kunden wichtige Wertpapierinformationen, die für die Ent- +scheidung des Kunden von Relevanz sind, vor der Ordererteilung sowie auch vor +der Änderung oder Streichung einer Order zukommen zu lassen. + +Es wird unterschieden zwischen allgemeinen wichtigen Informationen und speziel- +len wichtigen Informationen zu einzelnen Wertpapieren. Die wichtigen Informationen +werden über eine Versionsnummer referenziert. + + +![](figures/133.1) + + +Es sollten dem Kunden nur aktuelle Informationen übermittelt wer- +den. Welcher Zeitraum hierfür benötigt wird, kann vom Kreditinstitut +selbst festgelegt werden. + +Es bleibt dem Kreditinstitut überlassen, welche Informationen es +dem Kunden übermitteln möchte und woher diese Informationen +stammen. + + +![](figures/133.2) + + +Das Kundenprodukt muss diesen Geschäftsvorfall unterstützen, so- +fern es die Geschäftsvorfälle Wertpapierorder, Orderänderung oder +Orderstreichung anbietet + +Liegen wichtige Informationen vor, so müssen sie dem Kunden an- +gezeigt und vom Kunden explizit bestätigt werden (z.B. durch +Mausklick). + +Der Kunde sollte zusätzlich darauf hingewiesen werden, dass durch +die betreffenden Informationen nicht die Anlageberatungspflicht des +Instituts ersetzt wird, sondern lediglich die selbständige Anlageent- +scheidung des Kunden erleichtert werden soll. + +Falls die Wertpapierhinweise im Kundenprodukt gespeichert wer- +den, muss zur Versionsführung eine Kreditinstitutskennung mitge- +führt werden, da sich die Hinweise nach Art und Inhalt je Kreditinsti- +tut unterscheiden können. + + +###### Beispiel: + +In diesem Beispiel zählt das Kreditinstitut die wichtigen Informationen pro Tag und +pro Kategorie hoch. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
114		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Wertpapiere
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ArtKate- gorieDatumVer- sionHinweis
Dem Kunden liegt vor:1-200002151,15.02.00: Kurseinbrüche in Südostasien“
2Aktien200002172,16.02.00: Siemens-Hauptver- sammlung beschließt höhere Dividende
17.02.00: Bayer: Gewinnerwar- tungen wurden erhöht“
Der Kunden fordert am 18.02.2000 an:1-200002151
2Aktien200002172
Der Kunde erhält vom Kreditinstitut:1-200002181,Keine besonderen Hinweise"
2Aktien200002181,18.02.00: DaimlerChrysler: Heute Veröffentlichung des Quartalsergebnisses“
2Renten200002171,17.02.00: Bundesbank be- schließt Leitzinssenkung“
+ + +# a) Kundenauftrag + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Wichtige Informationen anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKWPH
Bezugssegment:-
Version:3
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Depot3DEGktv#M1
3Auftragsidentifikati- on1DEan.99C1O: „Auftragsidentifikation er- laubt" (BPD) ="J" N: sonst
4Ordernummer1DEan.99C1O: ,,Ordernummer erlaubt" (BPD) ="J" N: sonst
5Referenz auf wich- tige Informationen2DEGO99
+ + +## . Belegungsrichtlinien + + +## Auftragsidentifikation + +Sofern dies vom Kreditinstitut zugelassen wird, kann die Auftragsidentifikati- +on für einen bestimmten Auftrag angegeben werden, um die Möglichkeit zu +geben, gezielt wichtige Informationen zu einem Auftrag abzufragen. + + +## Ordernummer + +Sofern dies vom Kreditinstitut zugelassen wird, kann die Ordernummer für +einen bestimmten Auftrag angegeben werden, um die Möglichkeit zu geben, +gezielt wichtige Informationen zu einem Auftrag abzufragen.. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle WertpapiereStand: 07.08.2015Seite: 115
+ + +### Referenz auf wichtige Informationen + +Der Kunde kann zur Anforderung wichtiger Informationen die Referenzen auf +die jeweils letzten Versionen aller ihm auf seinem Kundensystem vorliegen- +den Arten und Kategorien der wichtigen Informationen angeben. + +Falls der Kunde lediglich bestimmte Kategorien anfordern möchte, stellt er +nur die Referenzen dieser Kategorien ein. In diesem Fall ist aber zu berück- +sichtigen, dass eine Order evtl. abgewiesen werden kann, falls hierzu be- +stimmte Hinweise zur Kenntnis genommen werden müssen, die der Kunde +nicht angefordert hat. + +Falls allgemeine Informationen abgerufen werden sollen, darf das DE „Kate- +gorie der wichtigen Informationen" nicht belegt werden. Falls spezielle Infor- +mationen abgerufen werden, muss im DE ,Kategorie der wichtigen Informa- +tionen" eine Wertpapierkategorie angegeben werden. + +Sofern das Senden der wichtigen Informationen nicht verpflichtend ist oder +das Kundenprodukt noch keine wichtigen Informationen vorliegen hat, ist die +DEG nicht zu belegen. + + +#### b) Kreditinstitutsrückmeldung + + +##### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Wichtige Informationen rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIWPH
Bezugssegment:HKWPH
Version:3
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Wichtige Informati- onen2DEGO99
+ + +##### . Belegungsrichtlinien + + +##### Wichtige Informationen + +Wird die Kreditinstitutsrückmeldung zur Übermittlung einer neuen Version +der wichtigen Informationen verwendet, so muss das DE ,,Wertpapier- +hinweis" dieser DEG belegt sein. + + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
3060Es liegt keine neue Version der wichtigen Informationen vor
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
116		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Wertpapiere
+ + +# c) Bankparameterdaten + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Wichtige Informationen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIWPHS
Bezugssegment:HKVVB
Version:3
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Wichtige Informationen2DEGM1
+ + +## C.4.1.2 Wertpapierorder + + +### C.4.1.2.1 Segmentversion 3 + + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +Abhängig von der Art des Wertpapiers stehen verschiedene Geschäftsvorfälle für +die Ausführung einer Order zur Verfügung: + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Segment- kennungNameWertpapierart
HKWPOWertpapierorderAktien, Renten, Optionsscheine
HKWFOFondsorderFonds
HKFPOFestpreisorderEigenhandel
HKNEZNeuemission zeichnenNeuemissionen
+ + +Bietet ein Kreditinstitut den Geschäftsvorfall „Fondsorder“ nicht an, so kann dieses +Geschäft auch über den Geschäftsvorfall „Wertpapierorder“ abgewickelt werden. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Geschäftsvorfälle WertpapiereStand: 07.08.2015Seite: 117
+ + +Abbildung 3: Beispiel für den bankfachlichen Ablauf einer Wertpapierorder + +![HBCI-Auftrag Wertpapierorder MT 502 Erneutes Senden erforderlich = 'Ja' Auftrag syntaktisch ok? Nein Ja Liegt die aktuelle Version der wichtigen Inf. vor? Nein Ja Ist der Auftrag inhaltlich ok? Nein Ja Erneutes Senden erforderlich = 'Nein' Auftrags- bestätigung](figures/137.1) + + +Das Kundenprodukt muss die Möglichkeit vorsehen, wichtige Informationen des +Kreditinstitutes vor der Erteilung der Wertpapierorder abzufragen. Stimmt die Ver- +sionsnummer in der Wertpapierorder des Kundensystems nicht mit der Versions- +nummer beim Kreditinstitut überein oder liegen dem Kunden keine wichtigen Infor- +mationen vor, kann das Kreditinstitut die Annahme des Auftrags aussetzen und zu- +nächst die aktuelle Version der wichtigen Informationen an das Kundensystem +übermitteln. Dem Kunden müssen diese dann angezeigt und z.B. durch Mausklick +bestätigt werden. Danach kann der Kunde die Wertpapierorder nochmals an das +Kreditinstitut senden, das bei Vorliegen derselben Versionsnummer den Auftrag zur +weiteren Verarbeitung annehmen kann. Die inhaltliche Prüfung des Kundenauftra- +ges bleibt hiervon unberührt. + +Diese Vorgehensweise ist für das Kreditinstitut optional. + +Jede Gattung kann an einem oder mehreren Börsenplätzen in jeweils definierter +Währung gehandelt werden. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
118		Stand:
07.08.2015		Kapitel: Geschäftsvorfälle
Abschnitt: Wertpapiere
+ + +# a) Kundenauftrag + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Wertpapierorder einreichen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKWPO
Bezugssegment:-
Version:3
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Depot3DEGktv#M1
3Auftragsidentifikati- on1DEan..99O1
4Ordernummer1DEan.99O1
5Wertpapierorder1DEbin..O1
6Verrechnungskonto3DEGktv#C1M: ,,Verrechnungskonto verpflichtend“ (BPD) = ,J“ O: sonst
7Referenz auf wich- tige Informationen2DEGC99M: ,Wichtige Informationen verpflichtend“ (BPD) = ,J“ und wichtige Informationen liegen vor N: sonst
+ + +# . Belegungsrichtlinien + + +## Depot + +Das Feld muss identisch sein mit dem Depotkonto im Feld B2:97A:, Qualifier +,SAFE", des MT 502 (DE ,,Wertpapierorder“). + + +# Auftragsidentifikation + +Hier muss die Auftragsidentifikation eingestellt werden, wenn ein erneutes +Senden der Wertpapierorder nach Zurückweisung aufgrund fehlender oder +nicht aktueller wichtiger Informationen erforderlich ist und das Kreditinstitut +den ursprünglichen Auftrag nicht löscht. Beim erstmaligen Senden der Wert- +papierorder bleibt das Feld leer. + + +# Ordernummer + +Wird trotz der Zurückweisung des Kundenauftrages aufgrund fehlender oder +nicht aktueller wichtiger Informationen der ursprüngliche Auftrag nicht ge- +löscht und eine Ordernummer vergeben und zurückgemeldet, so kann diese +hier eingestellt werden. + + +# Wertpapierorder + +Beim erstmaligen Senden der Wertpapierorder wird das S.W.I.F.T.-Format +MT 502 in der Version ,,SRG 2002" (s. [Datenformate]) eingestellt. Liegt die +Referenznummer des Wertpapiers (WKN bzw. ISIN) nicht vor, so muss sie +zuvor mit Hilfe des Geschäftsvorfalls ,,Abfrage von Wertpapierreferenz- +nummern" (Kap. C.4.4.1) erfragt werden. + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle3.0 Rel 2015, FV
Kapitel:
Abschnitt:		Geschäftsvorfälle WertpapiereStand: 07.08.2015Seite: 119
+ + +Falls unklar ist, ob die Angabe in den Feldern B:36B: und B1:90a: in Stück +oder als Nennwert erfolgt, sollten zunächst die Stammdaten des Wertpapiers +abgerufen werden (s. Kap. C.4.4.2). + +Sieht das Kreditinstitut die Abweisung des Auftrages bei nicht aktueller Ver- +sion der wichtigen Informationen vor und stellt es in seiner Kreditinsti- +tutsrückmeldung im DE „Erneutes Senden erforderlich" den Wert „J“ ein, +muss mit der Bestätigung erneut ein MT 502 gesendet werden. Beim Wert +"N" kann das Feld bei der Bestätigung leer bleiben. Das DE "Auftrags- +identifikation" oder das DE "Ordernummer" muss in diesem Fall gefüllt sein. + +Es gelten die folgenden Belegungsvorschriften: + +1 In Feld A:23G" darf nicht ,/COPY" gesendet werden. + +2 In Feld A:22F" ist der Transaktionstyp „TRAD“ anzugeben“. + +. B2:70C: Qualifier ,INCE" (Incentive-Merkmal) darf nicht belegt werden + + +# Verrechnungskonto + +Geldkonto; Dieses muss identisch mit dem Feld B2:97A:, Qualifier „CASH“, +sein. + + +# Referenz auf wichtige Informationen + +In den Bankparameterdaten teilt das Kreditinstitut mit, ob die Bekanntgabe +der aktuell beim Kunden vorliegenden wichtigen Informationen bei der Or- +dereinreichung verpflichtend ist. In diesem Fall hat der Kunde die Referen- +zen auf die letzten Versionen aller vorliegenden Arten und Kategorien der +Wertpapierhinweise einzustellen. + +Sofern das Senden der wichtigen Informationen nicht verpflichtend ist oder +das Kundenprodukt noch keine wichtigen Informationen vorliegen hat, ist die +DEG nicht zu belegen. + + +# b) Kreditinstitutsrückmeldung + + +## . Beschreibung + +Als unmittelbare Antwort auf die Wertpapierorder erhält der Kunde eine Kreditin- +stitutsrückmeldung. In dieser können die aktuellen wichtigen Informationen oder die +im Zusammenhang mit der Auftragsannahme relevanten Informationen übermittelt +werden. Dem Kunden kann eine Auftragsidentifikation mitgeteilt werden, unter der +Ausführungsanzeige und Wertpapierabrechnung mit dem Geschäftsvorfall „Order- +status" oder ,,Orderanzeige" abgerufen werden können. Diese Auftragsidentifikation +ist optional und wird sich in der Regel von der Ordernummer des Abrechnungssys- +tems unterscheiden. Alle weiteren Geschäftsvorfälle innerhalb des Wertpapierge- +schäftes werden dem Kunden zur Abholung bereitgestellt. + +Der Status des Auftrages nach Eingang beim Kreditinstitut ist abhängig von der in- +stitutsindividuellen Vorgehensweise bei Nichtvorliegen einer aktuellen Version der +Hinweise. + +Ist die eingestellte Version der Hinweise "0" bzw. liegt beim Kreditinstitut eine aktu- +ellere Version als die vom Kundensystem eingestellte vor, so erhält der Kunde als +Kreditinstitutsrückmeldung eine aktuelle Version. Abhängig von der Vorgehensweise +des Kreditinstitutes muss ein Kennzeichen gesetzt werden, ob der Auftrag als Gan- +zes neu gesendet werden muss oder eine Bestätigung des Erhaltes genügt. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
120		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Wertpapiere
+ + +# . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Wertpapierordereinreichung bestätigen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIWPO
Bezugssegment:HKWPO
Version:3
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Erneutes Senden erforderlich1DEjn#M1
3Auftragsidentifikati- on1DEan..99O1
4Ordernummer1DEan..99O1
5Ordernummer Split- ting1DEan.99O1
6Wertpapierordersta- tus2DEcode..2O10-11
7Auftragsbezogene Informationen1DEtxt.. 2048O1
8Ausführungsanzei- ge1DEbin..C1O: Auftrag wurde ausge- führt bzw. teilausgeführt N: sonst
9Wertpapierabrech- nung1DEbin..C1O: Auftrag wurde abgerech- net
N: sonst
10Wichtige Informati- onen2DEGO99
+ + +# . Belegungsrichtlinien + + +## Ausführungsanzeige + +Falls eine Ausführungsanzeige vorliegt, kann diese im Format MT 513 in +Version „SRG 1998" (s. [Datenformate]) eingestellt werden. + + +## Wertpapierabrechnung + +Falls eine Wertpapierabrechnung bereits vorliegt (z.B. bei Festpreisgeschäf- +ten), kann diese im Format MT 515 in Version ,,SRG 1998" (s. [Daten- +formate]) eingestellt werden. + + +## Wichtige Informationen + +Wird die Kreditinstitutsrückmeldung zur Übermittlung einer neuen Version +der wichtigen Informationen verwendet, so muss diese DEG belegt sein. + + +![](figures/140.1) + + +Liegen wichtige Informationen vor, so müssen sie dem Kun- +den angezeigt und vom Kunden explizit bestätigt werden +(z.B. durch Mausklick). + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle WertpapiereStand: 07.08.2015Seite: 121
+ + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag zur Ausführung vorgemerkt
0010Auftrag zur Ausführung angenommen
3060Zunächst Wertpapierinformationen lesen und dann ggf. den Auftrag erneut senden
3820Prüfen Sie zu gegebener Zeit den Orderstatus
9010Auftrag abgelehnt - Annahme aus technischen Gründen z. Z. nicht möglich
9010Auftragsidentifikation ist falsch
9210Order abgelehnt - inhaltlich ungültig
9210Auftrag abgelehnt, da wichtige Informationen nicht beachtet
9210Kein gültiger Börsenplatz
9220Wertpapier ist nicht im Depot
9220Wertpapierkennnummer existiert nicht
9220Verrechnungskonto existiert nicht
9220Gültigkeit nicht zulässig
9220Währungskennzeichen falsch
9230Unzureichendes Guthaben des Verrechnungskontos
+ + +![](figures/141.1) + + +Nach der Übermittlung einer Wertpapierorder, die mit dem Rück- +meldungscode "3820 - Prüfen Sie zu gegebener Zeit den Ordersta- +tus" beantwortet wurde, sollte vom Kundensystem ein Flag gesetzt +werden, der bei der nächsten Dialoginitialisierung einen Hinweis +auslöst, dass eine Statusabfrage erfolgen soll. + + +### c) Bankparameterdaten + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Wertpapierorder Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIWPOS
Bezugssegment:HKVVB
Version:3
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
122		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Wertpapiere
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Wertpa- pierorder3DEGM1
+ + +### . Belegungsrichtlinien + + +#### Parameter Wertpapierorder + +Im DE „Zulässige Börsenplätze“ hat das Kreditinstitut immer die handelbaren +Börsenplätze anzugeben. Nur für den Fall, dass das Institut alle denkbaren +Börsenplätze unterstützt, kann das Feld leer bleiben. + + +#### C.4.1.2.2 Segmentversion 4 + +Realisierung Bank: optional + +Realisierung Kunde: optional + +Abhängig von der Art des Wertpapiers stehen verschiedene Geschäftsvorfälle für +die Ausführung einer Order zur Verfügung: + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Segment- kennungNameWertpapierart
HKWPOWertpapierorderAktien, Renten, Optionsscheine
HKWFOFondsorderFonds
HKFPOFestpreisorderEigenhandel
HKNEZNeuemission zeichnenNeuemissionen
+ + +Bietet ein Kreditinstitut den Geschäftsvorfall „Fondsorder“ nicht an, so kann dieses +Geschäft auch über den Geschäftsvorfall „Wertpapierorder“ abgewickelt werden. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Geschäftsvorfälle WertpapiereStand: 07.08.2015Seite: 123
+ + +Abbildung 4: Beispiel für den bankfachlichen Ablauf einer Wertpapierorder + +![HBCI-Auftrag Wertpapierorder MT 502 Erneutes Senden erforderlich = 'Ja' Auftrag syntaktisch ok? Nein Ja Liegt die aktuelle Version der wichtigen Inf. vor? Nein Ja Ist der Auftrag inhaltlich ok? Nein Ja Erneutes Senden erforderlich = 'Nein' Auftrags- bestätigung](figures/143.1) + + +Das Kundenprodukt muss die Möglichkeit vorsehen, wichtige Informationen des +Kreditinstitutes vor der Erteilung der Wertpapierorder abzufragen. Stimmt die Ver- +sionsnummer in der Wertpapierorder des Kundensystems nicht mit der Versions- +nummer beim Kreditinstitut überein oder liegen dem Kunden keine wichtigen Infor- +mationen vor, kann das Kreditinstitut die Annahme des Auftrags aussetzen und zu- +nächst die aktuelle Version der wichtigen Informationen an das Kundensystem +übermitteln. Dem Kunden müssen diese dann angezeigt und z.B. durch Mausklick +bestätigt werden. Danach kann der Kunde die Wertpapierorder nochmals an das +Kreditinstitut senden, das bei Vorliegen derselben Versionsnummer den Auftrag zur +weiteren Verarbeitung annehmen kann. Die inhaltliche Prüfung des Kundenauftra- +ges bleibt hiervon unberührt. + +Diese Vorgehensweise ist für das Kreditinstitut optional. + +Jede Gattung kann an einem oder mehreren Börsenplätzen in jeweils definierter +Währung gehandelt werden. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
124		Stand:
07.08.2015		Kapitel: Geschäftsvorfälle
Abschnitt: Wertpapiere
+ + +##### a) Kundenauftrag + + +###### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Wertpapierorder einreichen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKWPO
Bezugssegment:-
Version:4
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Depot3DEGktv#M1
3Auftragsidentifikati- on1DEan.99O1
4Ordernummer1DEan.99O1
5Wertpapierorder1DEbin..O1
6Verrechnungskonto4DEGkti#C1M: ,,Verrechnungskonto verpflichtend“ (BPD) = ,J“ O: sonst
7Referenz auf wich- tige Informationen2DEGC99M: ,,Wichtige Informationen verpflichtend“ (BPD) = ,J“ und wichtige Informationen liegen vor N: sonst
+ + +##### . Belegungsrichtlinien + + +![](figures/144.1) + + +![](figures/144.2) + + +Aufgrund neuer Ordertypen und anderer Anforderungen wurde das +bisherige S.W.I.F.T.-Format MT 502 ,,SRG 2002" so modifiziert, +dass diese abgebildet werden können. Die betreffende Version fin- +det sich im Band Finanzdatenformate [Datenformate] unter ,,MT +502 (erweitert)" beschrieben. + + +##### Depot + +Das Feld muss identisch sein mit dem Depotkonto im Feld B2:97A:, Qualifier +,SAFE", des MT 502 (erweitert) (DE „Wertpapierorder“). + + +##### Auftragsidentifikation + +Hier muss die Auftragsidentifikation eingestellt werden, wenn ein erneutes +Senden der Wertpapierorder nach Zurückweisung aufgrund fehlender oder +nicht aktueller wichtiger Informationen erforderlich ist und das Kreditinstitut +den ursprünglichen Auftrag nicht löscht. Beim erstmaligen Senden der Wert- +papierorder bleibt das Feld leer. + + +##### Ordernummer + +Wird trotz der Zurückweisung des Kundenauftrages aufgrund fehlender oder +nicht aktueller wichtiger Informationen der ursprüngliche Auftrag nicht ge- + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle WertpapiereStand: 07.08.2015Seite: 125
+ + +löscht und eine Ordernummer vergeben und zurückgemeldet, so kann diese +hier eingestellt werden. + + +##### Wertpapierorder + +Beim erstmaligen Senden der Wertpapierorder wird das S.W.I.F.T.-Format +MT 502 (erweitert) in der Version ,,SRG 2002" (s. [Datenformate]) einge- +stellt. Liegt die Referenznummer des Wertpapiers (WKN bzw. ISIN) nicht vor, +so muss sie zuvor mit Hilfe des Geschäftsvorfalls „Abfrage von Wertpapierre- +ferenznummern“ (Kap. C.4.4.1) erfragt werden. + +Falls unklar ist, ob die Angabe in den Feldern B:36B: und B1:90a: in Stück +oder als Nennwert erfolgt, sollten zunächst die Stammdaten des Wertpapiers +abgerufen werden (s. Kap. C.4.4.2). + +Sieht das Kreditinstitut die Abweisung des Auftrages bei nicht aktueller Ver- +sion der wichtigen Informationen vor und stellt es in seiner Kreditinsti- +tutsrückmeldung im DE „Erneutes Senden erforderlich" den Wert ,J“ ein, +muss mit der Bestätigung erneut ein MT 502 (erweitert) gesendet werden. +Beim Wert "N" kann das Feld bei der Bestätigung leer bleiben. Das DE "Auf- +tragsidentifikation" oder das DE "Ordernummer" muss in diesem Fall gefüllt +sein. + +Es gelten die folgenden Belegungsvorschriften: + +3 In Feld A:23G" darf nicht ,/COPY" gesendet werden. + +4 In Feld A:22F" ist der Transaktionstyp „TRAD“ anzugeben“. + +. B2:70C: Qualifier ,INCE" (Incentive-Merkmal) darf nicht belegt werden + + +##### Verrechnungskonto + +Geldkonto; Dieses muss identisch mit dem Feld B2:97A:, Qualifier „CASH“, +sein. + + +##### Referenz auf wichtige Informationen + +In den Bankparameterdaten teilt das Kreditinstitut mit, ob die Bekanntgabe +der aktuell beim Kunden vorliegenden wichtigen Informationen bei der Or- +dereinreichung verpflichtend ist. In diesem Fall hat der Kunde die Referen- +zen auf die letzten Versionen aller vorliegenden Arten und Kategorien der +Wertpapierhinweise einzustellen. + +Sofern das Senden der wichtigen Informationen nicht verpflichtend ist oder +das Kundenprodukt noch keine wichtigen Informationen vorliegen hat, ist die +DEG nicht zu belegen. + + +##### b) Kreditinstitutsrückmeldung + + +###### . Beschreibung + +Als unmittelbare Antwort auf die Wertpapierorder erhält der Kunde eine Kreditin- +stitutsrückmeldung. In dieser können die aktuellen wichtigen Informationen oder die +im Zusammenhang mit der Auftragsannahme relevanten Informationen übermittelt +werden. Dem Kunden kann eine Auftragsidentifikation mitgeteilt werden, unter der +Ausführungsanzeige und Wertpapierabrechnung mit dem Geschäftsvorfall „Order- +status" oder ,,Orderanzeige" abgerufen werden können. Diese Auftragsidentifikation +ist optional und wird sich in der Regel von der Ordernummer des Abrechnungssys- +tems unterscheiden. Alle weiteren Geschäftsvorfälle innerhalb des Wertpapierge- +schäftes werden dem Kunden zur Abholung bereitgestellt. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
126		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Wertpapiere
+ + +Der Status des Auftrages nach Eingang beim Kreditinstitut ist abhängig von der in- +stitutsindividuellen Vorgehensweise bei Nichtvorliegen einer aktuellen Version der +Hinweise. + +Ist die eingestellte Version der Hinweise "0" bzw. liegt beim Kreditinstitut eine aktu- +ellere Version als die vom Kundensystem eingestellte vor, so erhält der Kunde als +Kreditinstitutsrückmeldung eine aktuelle Version. Abhängig von der Vorgehensweise +des Kreditinstitutes muss ein Kennzeichen gesetzt werden, ob der Auftrag als Gan- +zes neu gesendet werden muss oder eine Bestätigung des Erhaltes genügt. + + +##### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Wertpapierordereinreichung bestätigen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIWPO
Bezugssegment:HKWPO
Version:4
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Erneutes Senden erforderlich1DEjn#M1
3Auftragsidentifikati- on1DEan..99O1
4Ordernummer1DEan..99O1
5Ordernummer Split- ting1DEan..99O1
6Wertpapierordersta- tus2DEcode..2O10-11
7Auftragsbezogene Informationen1DEtxt.. 2048O1
8Ausführungsanzei- ge1DEbin.٠C1O: Auftrag wurde ausge- führt bzw. teilausgeführt N: sonst
9Wertpapierabrech- nung1DEbin..C1O: Auftrag wurde abgerech- net
N: sonst
10Wichtige Informati- onen2DEGO99
+ + +##### . Belegungsrichtlinien + + +# Ausführungsanzeige + +Falls eine Ausführungsanzeige vorliegt, kann diese im Format MT 513 in +Version „SRG 1998" (s. [Datenformate]) eingestellt werden. + + +# Wertpapierabrechnung + +Falls eine Wertpapierabrechnung bereits vorliegt (z.B. bei Festpreisgeschäf- +ten), kann diese im Format MT 515 in Version ,,SRG 1998" (s. [Daten- +formate]) eingestellt werden. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle WertpapiereStand: 07.08.2015Seite: 127
+ + +## Wichtige Informationen + +Wird die Kreditinstitutsrückmeldung zur Übermittlung einer neuen Version +der wichtigen Informationen verwendet, so muss diese DEG belegt sein. + + +![](figures/147.1) + + +Liegen wichtige Informationen vor, so müssen sie dem Kun- +den angezeigt und vom Kunden explizit bestätigt werden +(z.B. durch Mausklick). + + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag zur Ausführung vorgemerkt
0010Auftrag zur Ausführung angenommen
3060Zunächst Wertpapierinformationen lesen und dann ggf. den Auftrag erneut senden
3820Prüfen Sie zu gegebener Zeit den Orderstatus
9010Auftrag abgelehnt - Annahme aus technischen Gründen z. Z. nicht möglich
9010Auftragsidentifikation ist falsch
9210Order abgelehnt - inhaltlich ungültig
9210Auftrag abgelehnt, da wichtige Informationen nicht beachtet
9210Kein gültiger Börsenplatz
9220Wertpapier ist nicht im Depot
9220Wertpapierkennnummer existiert nicht
9220Verrechnungskonto existiert nicht
9220Gültigkeit nicht zulässig
9220Währungskennzeichen falsch
9230Unzureichendes Guthaben des Verrechnungskontos
+ + +![](figures/147.2) + + +Nach der Übermittlung einer Wertpapierorder, die mit dem Rück- +meldungscode "3820 - Prüfen Sie zu gegebener Zeit den Ordersta- +tus" beantwortet wurde, sollte vom Kundensystem ein Flag gesetzt +werden, der bei der nächsten Dialoginitialisierung einen Hinweis +auslöst, dass eine Statusabfrage erfolgen soll. + + +### c) Bankparameterdaten + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Wertpapierorder Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIWPOS
Bezugssegment:HKVVB
Version:4
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
128		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Wertpapiere
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Wertpa- pierorder3DEGM1
+ + +### . Belegungsrichtlinien + + +#### Parameter Wertpapierorder + +Im DE „Zulässige Börsenplätze“ hat das Kreditinstitut immer die handelbaren +Börsenplätze anzugeben. Nur für den Fall, dass das Institut alle denkbaren +Börsenplätze unterstützt, kann das Feld leer bleiben. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle WertpapiereStand: 07.08.2015Seite: 129
+ + +## C.4.1.3 Orderänderung + + +### C.4.1.3.1 Segmentversion 3 + +Realisierung Bank: optional +Realisierung Kunde: optional + +Die Ausführung der Änderung einer Wertpapierorder kann nur dann direkt durch die +Kundenanfrage ausgelöst werden, wenn das Kreditinstitut direkt auf die Basis- +systeme zugreifen kann. Der abgerufene Stand der Stati kann ansonsten bereits +überholt sein, da die im Basissystem enthaltenen Order jederzeit ausgeführt werden +können. Die Änderung einer Order ist deshalb nur unter dem Vorbehalt der zwi- +schenzeitlichen Ausführung möglich. Die Kreditinstitutsrückmeldung enthält aus die- +sem Grund einen entsprechenden Hinweis. + +Die zu ändernde Order ist entweder auf dem Kundensystem abgelegt oder kann +durch den Geschäftsvorfall „Orderstatus" oder ,,Orderanzeige" auf das Kundensys- +tem übertragen werden. + +Es sind nur bestimmte Änderungen an einer bestehenden Order möglich. Die än- +derbaren Details teilt das Kreditinstitut in den Bankparameterdaten mit. Alle anderen +Änderungen können dann nur durch Streichung und Erteilung einer neuen Order er- +folgen. + +Generell gilt jedoch: ein Stop-Limit kann nicht über diesen Geschäftsvorfall, sondern +nur durch Streichung und Neueinreichung geändert werden. Ebenso kann ein Preis- +limit nicht in ein Stop-Limit geändert werden. + + +#### a) Kundenauftrag + + +##### . Beschreibung + +Es sind nur diejenigen Felder zu belegen, die tatsächlich geändert werden sollen. + + +##### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Wertpapierorderänderung
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKWOA
Bezugssegment:-
Version:3
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Depot3DEGktv#M1
3Auftragsidentifikati- on1DEan.99C1M: ,,Ordernummer" leer O: sonst
4Ordernummer1DEan.99C1M: „Auftragsidentifikation“ leer O: sonst
5Art des Limits1DEan4O1
6Preislimit2DEGbtg#C1O: ,,Prozentlimit" leer N: sonst
7Prozentlimit1DEwrt#C1O: ,,Preislimit" leer
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
130		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt:
Wertpapiere
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
N: sonst
8Art des Zeitlimits1DEan4O1
9Zeitlimit1DEdat#O1
10Verrechnungskonto3DEGktv#O1
11Nominale1DEwrt#O1
12Telefon1DEan..35C1M: ,Telefonnummer ver- pflichtend“ (BPD) = ,J“ O: sonst
13Referenz auf wich- tige Informationen2DEGO99
+ + +#### . Belegungsrichtlinien + + +##### Auftragsidentifikation + +Es kann die Auftragsidentifikation aus der Rückmeldung auf die Ordereinrei- +chung bzw. aus der Orderstatusanzeige angegeben werden. + + +##### Ordernummer + +Es kann die Ordernummer aus der Rückmeldung auf die Ordereinreichung +bzw. aus der Orderstatusanzeige angegeben werden. + + +##### Telefon + +Es ist eine Telefonnummer für Rückfragen anzugeben. + + +##### Referenz auf wichtige Informationen + +s. ,Wertpapierorder“. + + +#### b) Kreditinstitutsrückmeldung + + +##### . Beschreibung + +Analog zur Wertpapierorder kann das Kreditinstitut vor der Annahme zur Ausfüh- +rung erst eine Versionsprüfung der wichtigen Informationen vornehmen und eine ak- +tuelle Version an das Kundensystem übermitteln. + +Der Kunde erhält eine Kreditinstitutsrückmeldung, in der dem Kundensystem eine +Auftragsidentifikation mitgeteilt wird sowie den Status 01 = "Auftrag zur Ausführung +vorgemerkt". + + +![](figures/150.1) + + +Falls eine neue Auftragsidentifikation oder Ordernummer vergeben +wurde, ist der lokale Bestand im Kundenprodukt zu aktualisieren. + + +##### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Wertpapierorderänderung bestätigen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIWOA
Bezugssegment:HKWOA
Version:3
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:GeschäftsvorfälleStand:Seite:
Abschnitt:Wertpapiere07.08.2015131
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Erneutes Senden erforderlich1DEjn#M1
3Auftragsidentifikati- on1DEan..99C1M: „Auftragsidentifikation“ geändert O: sonst
4Auftragsidentifikati- on alt1DEan..99C1M: „Auftragsidentifikation“ belegt und geändert N: sonst
5Ordernummer1DEan..99C1M: „Ordernummer“ geän- dert O: sonst
6Ordernummer alt1DEan.99C1M: ,,Ordernummer" belegt und geändert N: sonst
7Wertpapierordersta- tus2DEcode..2O10-11
8Auftragsbezogene Informationen1DEtxt.. 2048O1
9Wichtige Informati- onen2DEGO99
+ + +#### . Belegungsrichtlinien + + +##### Auftragsidentifikation, Auftragsidentifikation alt + +In der Regel wird die Auftragsidentifikation einer Wertpapierorder durch ei- +nen Änderungsauftrag nicht modifiziert. Dies ist jedoch möglich, wenn z.B. +die Änderung kreditinstitutsseitig durch eine Löschung und Neueinreichung +realisiert wird. In diesem Fall muss dem Kundensystem im DE "Auftrags- +identifikation" die neu vergebene und im DE "Auftragsidentifikation alt" aus +Zuordnungsgründen die bisherige Auftragsidentifikation mitgeteilt werden. + + +##### Ordernummer, Ordernummer alt + +s. ,Auftragsidentifikation“, ,Auftragsidentifikation alt“ + + +##### Wichtige Informationen + +Wird die Kreditinstitutsrückmeldung zur Übermittlung einer neuen Version +der wichtigen Informationen verwendet, so muss diese DEG belegt sein. + + +![](figures/151.1) + + +Liegen wichtige Informationen vor, so müssen sie dem Kun- +den angezeigt und vom Kunden explizit bestätigt werden +(z.B. durch Mausklick). + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
132		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Wertpapiere
+ + +#### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
3060Zunächst Wertpapierinformationen lesen und dann ggf. den Auftrag erneut senden
3070Auftrag zur Ausführung vorgemerkt – Prüfen Sie zu gegebener Zeit den Orderstatus
3070Auftrag zur Ausführung angenommen – Prüfen Sie zu gegebener Zeit den Ordersta- tus
9010Referenznummer existiert nicht
9010Änderung ist nicht möglich, da Ausführung bereits eingeleitet wurde
9210Server offline, Änderung kann nicht ausgeführt werden. Setzen Sie sich bitte mit Ih- rem Berater in Verbindung
9210keine gültige Depotnummer des Kunden
9210inhaltlich ungültig: Wert nicht änderbar
9210Kein Börsenplatz angegeben, verpflichtend bei Angabe der Währung des Limits
+ + +![](figures/152.1) + + +Die Auftragsstati "Auftrag zur Ausführung vorgemerkt" und "Auf- +trag zur Ausführung angenommen" müssen jeweils erläutert wer- +den, da die Vormerkung und die Annahme nicht bedeuten, dass +die Ursprungsorder tatsächlich gestrichen wurde. Die Definitionen +dazu finden sich im Kapitel C.4.1.2 "Wertpapierorder". + +Nach der Übermittlung eines Auftrages zur Streichung, die mit +dem Rückmeldungscode "3820 – Prüfen Sie zu gegebener Zeit +den Orderstatus" beantwortet wurde, sollte vom Kundensystem +ein Flag gesetzt werden, der bei der nächsten Dialoginitialisierung +einen Hinweis auslöst, dass eine Statusabfrage erfolgen soll. + + +#### c) Bankparameterdaten + + +##### . Beschreibung + +Für Änderungen der Wertpapierorder gelten dieselben kreditinstitutsseitigen Ein- +schränkungen wie für die Wertpapierorder selbst. Zusätzlich können Bedingungen +für die zulässigen Änderungen definiert werden. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle WertpapiereStand: 07.08.2015Seite: 133
+ + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Wertpapierorderänderung Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIWOAS
Bezugssegment:HKVVB
Version:3
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Wertpa- pierorderänderung3DEGM1
+ + +### C.4.1.3.2 Segmentversion 4 + +Realisierung Bank: optional + +Realisierung Kunde: optional + +Die Ausführung der Änderung einer Wertpapierorder kann nur dann direkt durch die +Kundenanfrage ausgelöst werden, wenn das Kreditinstitut direkt auf die Basis- +systeme zugreifen kann. Der abgerufene Stand der Stati kann ansonsten bereits +überholt sein, da die im Basissystem enthaltenen Order jederzeit ausgeführt werden +können. Die Änderung einer Order ist deshalb nur unter dem Vorbehalt der zwi- +schenzeitlichen Ausführung möglich. Die Kreditinstitutsrückmeldung enthält aus die- +sem Grund einen entsprechenden Hinweis. + +Die zu ändernde Order ist entweder auf dem Kundensystem abgelegt oder kann +durch den Geschäftsvorfall „Orderstatus" oder ,,Orderanzeige" auf das Kundensys- +tem übertragen werden. + +Es sind nur bestimmte Änderungen an einer bestehenden Order möglich. Die än- +derbaren Details teilt das Kreditinstitut in den Bankparameterdaten mit. Alle anderen +Änderungen können dann nur durch Streichung und Erteilung einer neuen Order er- +folgen. + +Generell gilt jedoch: ein Preislimit kann nicht in ein Stop-Limit geändert werden. + + +#### a) Kundenauftrag + + +##### . Beschreibung + +Es sind nur diejenigen Felder zu belegen, die tatsächlich geändert werden sollen. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
134		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Wertpapiere
+ + +# . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Wertpapierorderänderung
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKWOA
Bezugssegment:-
Version:4
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Depot3DEGktv#M1
3Auftragsidentifikati- on1DEan.99C1M: ,,Ordernummer" leer O: sonst
4Ordernummer1DEan.99C1M: „Auftragsidentifikation“ leer O: sonst
5Art des Limits1DEan4O1
6Limitwährung1DEcur#CM: ,,Prozentlimit" leer und ,Preislimit, Wert“, „Stoplimit, Wert", ,,2. Preislimit" oder ,Trailingabstand, Wert" be- legt N: sonst
7Preislimit, Wert1DEwrt#C1O: ,,Prozentlimit" leer N: sonst
8Stopplimit, Wert1DEwrt#C1O: ,Stoplimit, Prozent" leer N: sonst
9Zweites Preislimit, Wert1DEwrt#C1O: ,,Zweites Preislimit, Pro- zent" leer N: sonst
10Trailingabstand, Wert1DEwrt#C1O: ,Trailingabstand, Pro- zent" leer N: sonst
11Prozentlimit1DEwrt#C1O: ,,Preislimit , Wert" leer N: sonst
12Stopplimit, Prozent1DEwrt#C1O: ,,Stoplimit, Wert" leer N: sonst
13Zweites Preislimit, Prozent1DEwrt#C1O: ,Zweites Preislimit, Wert" leer N: sonst
14Trailingabstand, Prozent1DEwrt#C1O: ,Trailingabstand, Wert" leer N: sonst
15Art des Zeitlimits1DEan4O1
16Zeitlimit1DEdat#O1
17Verrechnungskonto4DEGkti#O1
18Nominale1DEwrt#O1
19Telefon1DEan.35C1M: ,,Telefonnummer ver- pflichtend“ (BPD) = „J“ O: sonst
20Referenz auf wich-2DEGO99
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle WertpapiereStand: 07.08.2015Seite: 135
+ + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
tige Informationen
+ + +# . Belegungsrichtlinien + + +## Auftragsidentifikation + +Es kann die Auftragsidentifikation aus der Rückmeldung auf die Ordereinrei- +chung bzw. aus der Orderstatusanzeige angegeben werden. + + +## Ordernummer + +Es kann die Ordernummer aus der Rückmeldung auf die Ordereinreichung +bzw. aus der Orderstatusanzeige angegeben werden. + +Telefon + +Es ist eine Telefonnummer für Rückfragen anzugeben. + + +## Referenz auf wichtige Informationen + +s. „Wertpapierorder“. + + +## b) Kreditinstitutsrückmeldung + + +### . Beschreibung + +Analog zur Wertpapierorder kann das Kreditinstitut vor der Annahme zur Ausfüh- +rung erst eine Versionsprüfung der wichtigen Informationen vornehmen und eine ak- +tuelle Version an das Kundensystem übermitteln. + +Der Kunde erhält eine Kreditinstitutsrückmeldung, in der dem Kundensystem eine +Auftragsidentifikation mitgeteilt wird sowie den Status 01 = "Auftrag zur Ausführung +vorgemerkt". + + +![](figures/155.1) + + +Falls eine neue Auftragsidentifikation oder Ordernummer vergeben +wurde, ist der lokale Bestand im Kundenprodukt zu aktualisieren. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Wertpapierorderänderung bestätigen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIWOA
Bezugssegment:HKWOA
Version:4
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 136Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Wertpapiere
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Erneutes Senden erforderlich1DEjn#M1
3Auftragsidentifikati- on1DEan.99C1M: „Auftragsidentifikation“ geändert O: sonst
4Auftragsidentifikati- on alt1DEan.99C1M: „Auftragsidentifikation“ belegt und geändert N: sonst
5Ordernummer1DEan.99C1M: „Ordernummer“ geän- dert O: sonst
6Ordernummer alt1DEan..99C1M: ,,Ordernummer" belegt und geändert N: sonst
7Wertpapierordersta- tus2DEcode..2O10-11
8Auftragsbezogene Informationen1DEtxt.. 2048O1
9Wichtige Informati- onen2DEGO99
+ + +### . Belegungsrichtlinien + + +#### Auftragsidentifikation, Auftragsidentifikation alt + +In der Regel wird die Auftragsidentifikation einer Wertpapierorder durch ei- +nen Änderungsauftrag nicht modifiziert. Dies ist jedoch möglich, wenn z.B. +die Änderung kreditinstitutsseitig durch eine Löschung und Neueinreichung +realisiert wird. In diesem Fall muss dem Kundensystem im DE "Auftrags- +identifikation" die neu vergebene und im DE "Auftragsidentifikation alt" aus +Zuordnungsgründen die bisherige Auftragsidentifikation mitgeteilt werden. + + +#### Ordernummer, Ordernummer alt + +s. „Auftragsidentifikation“, „Auftragsidentifikation alt“ + + +#### Wichtige Informationen + +Wird die Kreditinstitutsrückmeldung zur Übermittlung einer neuen Version +der wichtigen Informationen verwendet, so muss diese DEG belegt sein. + + +![](figures/156.1) + + +Liegen wichtige Informationen vor, so müssen sie dem Kun- +den angezeigt und vom Kunden explizit bestätigt werden +(z.B. durch Mausklick). + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle WertpapiereStand: 07.08.2015Seite: 137
+ + +##### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
3060Zunächst Wertpapierinformationen lesen und dann ggf. den Auftrag erneut senden
3070Auftrag zur Ausführung vorgemerkt – Prüfen Sie zu gegebener Zeit den Orderstatus
3070Auftrag zur Ausführung angenommen – Prüfen Sie zu gegebener Zeit den Ordersta- tus
9010Referenznummer existiert nicht
9010Änderung ist nicht möglich, da Ausführung bereits eingeleitet wurde
9210Server offline, Änderung kann nicht ausgeführt werden. Setzen Sie sich bitte mit Ih- rem Berater in Verbindung
9210keine gültige Depotnummer des Kunden
9210inhaltlich ungültig: Wert nicht änderbar
9210Kein Börsenplatz angegeben, verpflichtend bei Angabe der Währung des Limits
+ + +![](figures/157.1) + + +Die Auftragsstati "Auftrag zur Ausführung vorgemerkt" und "Auf- +trag zur Ausführung angenommen" müssen jeweils erläutert wer- +den, da die Vormerkung und die Annahme nicht bedeuten, dass +die Ursprungsorder tatsächlich gestrichen wurde. Die Definitionen +dazu finden sich im Kapitel C.4.1.2 "Wertpapierorder". + +Nach der Übermittlung eines Auftrages zur Streichung, die mit +dem Rückmeldungscode "3820 - Prüfen Sie zu gegebener Zeit +den Orderstatus" beantwortet wurde, sollte vom Kundensystem +ein Flag gesetzt werden, der bei der nächsten Dialoginitialisierung +einen Hinweis auslöst, dass eine Statusabfrage erfolgen soll. + + +##### c) Bankparameterdaten + + +###### . Beschreibung + +Für Änderungen der Wertpapierorder gelten dieselben kreditinstitutsseitigen Ein- +schränkungen wie für die Wertpapierorder selbst. Zusätzlich können Bedingungen +für die zulässigen Änderungen definiert werden. + + +###### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Wertpapierorderänderung Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIWOAS
Bezugssegment:HKVVB
Version:4
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
138		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Wertpapiere
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Wertpa- pierorderänderung4DEGM1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Wertpapiere
Geschäftsvorfälle		Stand: 07.08.2015Seite: 139
+ + +#### C.4.1.4Orderstreichung + + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +Die Ausführung der Streichung einer Wertpapierorder kann nur dann direkt durch +die Kundenanfrage ausgelöst werden, wenn das Kreditinstitut direkt auf die Basis- +systeme zugreifen kann. Der abgerufene Stand der Stati kann ansonsten bereits +überholt sein, da die im Basissystem enthaltenen Order jederzeit ausgeführt werden +können. Die Streichung einer Order ist deshalb nur unter dem Vorbehalt der zwi- +schenzeitlichen Ausführung möglich. Die Kreditinstitutsrückmeldung enthält aus die- +sem Grund einen entsprechenden Hinweis. + +Die Referenz auf die zu streichende Order (Auftragsidentifikation bzw. Ordernum- +mer) ist entweder auf dem Kundensystem abgelegt oder kann durch den Geschäfts- +vorfall ,,Orderstatus" oder ,Orderanzeige" angefordert werden. + + +##### a) Kundenauftrag + + +###### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Wertpapierorderstreichung
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKWPS
Bezugssegment:-
Version:3
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Depot3DEGktv#C1M: ,Depot erforderlich" (BPD) = „J“ O: sonst
3Auftragsidentifikati- on1DEan.99C1M: ,,Ordernummer" leer O: sonst
4Ordernummer1DEan.99C1M: „Auftragsidentifikation“ leer O: sonst
5Referenz auf wich- tige Informationen2DEGC99M: „Wichtige Informationen verpflichtend“ (BPD) = ,J“ und wichtige Informationen liegen vor N: sonst
+ + +##### . Belegungsrichtlinien + + +##### Depot + +Abhängig von der Angabe in den BPD ist hier diejenige Depotverbindung +einzustellen, zugunsten oder zu Lasten derer die Wertpapierorder getätigt +wurde. + + +###### Referenz auf wichtige Informationen + +s. ,,Wertpapierorder“. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
140		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Wertpapiere
+ + +## b) Kreditinstitutsrückmeldung + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Wertpapierorderstreichung bestätigen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIWPS
Bezugssegment:HKWPS
Version:3
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Erneutes Senden erforderlich1DEjn#M1
3Auftragsidentifikati- on1DEan.99O1
4Ordernummer1DEan.99O1
5Wertpapierordersta- tus2DEcode..2O10-11
6Auftragsbezogene Informationen1DEtxt٠٠ 2048O1
7Wichtige Informati- onen2DEGO99
+ + +### . Belegungsrichtlinien + +s. ,,Wertpapierorder“ + + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag angenommen
0010Auftrag zur Ausführung angenommen
0010Auftrag zur Ausführung vorgemerkt
0020Auftrag gestrichen
3060Prüfen Sie zu gegebener Zeit den Orderstatus
3060Zunächst Wertpapierinformationen lesen und dann ggf. Auftrag erneut senden
9010Referenznummer falsch
9010Streichung bzw. Änderung nicht möglich, da Order bereits ausgeführt wurde
9210Server offline. Setzen Sie sich bitte mit Ihrem Berater in Verbindung
9210Keine gültige Depotnummer des Kunden
+ + +![](figures/160.1) + + +Die Auftragsstati "Auftrag zur Ausführung vorgemerkt" und "Auftrag +zur Ausführung angenommen" müssen jeweils erläutert werden, da +die Vormerkung und die Annahme nicht bedeuten, dass die Ur- +sprungsorder tatsächlich gestrichen wurde. Die Definitionen dazu +finden sich im Kapitel C.4.1.2 "Wertpapierorder". + +Nach der Übermittlung eines Auftrages zur Streichung, die mit dem +Rückmeldungscode "3820 - Prüfen Sie zu gegebener Zeit den Or- +derstatus" beantwortet wurde, sollte vom Kundensystem ein Flag + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Wertpapiere
Geschäftsvorfälle		Stand: 07.08.2015Seite: 141
+ + +gesetzt werden, der bei der nächsten Dialoginitialisierung einen +Hinweis auslöst, dass eine Statusabfrage erfolgen soll. + + +### c) Bankparameterdaten + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Wertpapierorderstreichung Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIWPSS
Bezugssegment:HKVVB
Version:3
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Wertpa- pierorderstreichung2DEGM1
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
142		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Wertpapiere
+ + +#### C.4.1.5Fondsorder + +Realisierung Bank: optional + +Realisierung Kunde: optional + +Die Abwicklung des Fondsgeschäfts (Kapitalanlagegeschäft) erfolgt weitgehend +analog zum Wertpapiergeschäft (siehe Kap.C.4.1.2C.4.1.2). Dieser Geschäftsvorfall +trägt eine eigene Segmentkennung, um dem Kreditinstitut zu ermöglichen, Fondsor- +der direkt an eine spezielle Abwicklungsinstanz routen zu können. + +Wird dieser Geschäftsvorfall kreditinstitutsseitig nicht angeboten, kann auch die +Wertpapierorder (Kap. C.4.1.2) verwendet werden. + + +## a) Kundenauftrag + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Fondsorder einreichen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKWFO
Bezugssegment:-
Version:2
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Depot3DEGktv#M1
3Auftragsidentifikati- on1DEan..99O1
4Ordernummer1DEan..99O1
5Wertpapierorder1DEbin..O1
6Verrechnungskonto3DEGktv#C1M: , Verrechnungskonto verpflichtend“ (BPD) =,J“ O: sonst
7Wiederanlagerabatt1DEjn#C1M: ,Wiederanlagerabatt möglich“ (BPD) = „J“ N: sonst
8Referenz auf wich- tige Informationen2DEGC99M: ,,Wichtige Informationen verpflichtend“ (BPD) = ,J“ und wichtige Informationen liegen vor N: sonst
+ + +## . Belegungsrichtlinien + +zu den nicht aufgeführten DE's s. VII.4.1.2 ,,Wertpapierorder" + + +## Wertpapierorder + +Die Order ist im Format MT 502 in Version „SRG 2002" (s. [Datenformate]) +einzustellen. Es gelten die folgenden Belegungsvorschriften: + +. In Feld A:23G" darf nicht ,/COPY" gesendet werden. + +. In Feld A:22F" ist der Transaktionstyp „TRAD“ anzugeben“. + +• B:94B: Der Börsenplatz ist mit ,,OTCO" zu belegen. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Geschäftsvorfälle WertpapiereStand: 07.08.2015Seite: 143
+ + +. B1: Die Sequenz ,,Preis" darf nur belegt werden, wenn die Limitierung +kreditinstitutsseitig erlaubt ist. + +. B:22F:, Qualifier ,,TOOR" (Indikator für Art des Limits): Falls kreditinstituts- +seitig keine Limitierung erlaubt ist, ist nur der Indikator ,,MAKT“ zulässig. + +. B:22F:, Qualifier ,,TOOR" (Sonderbedingungen) darf nicht belegt werden + +. B:22F:, Qualifier ,,TILI" (Indikator für Zeitlimit) darf nur mit ,,GTCA" belegt +werden + +. B:98A: (Verfallsdatum der Order) darf nicht belegt werden + +. B2:70C: Qualifier ,INCE" (Incentive-Merkmal) darf nicht belegt werden + +. B:36B: Im Subfeld ,,Typ" ist nur „UNIT“ zulässig. + + +## Verrechnungskonto + +Geldkonto; Dieses muss identisch mit dem Feld B2:97A:, Qualifier ,CASH", +sein. + + +# b) Kreditinstitutsrückmeldung + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Fondsordereinreichung bestätigen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIWFO
Bezugssegment:HKWFO
Version:2
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Erneutes Senden erforderlich1DEjn#M1
3Auftragsidentifikati- on1DEan..99O1
4Ordernummer1DEan.99O1
5Ordernummer Split- ting1DEan.99O1
6Wertpapierordersta- tus2DEcode..2O10-11
7Auftragsbezogene Informationen1DEtxt.٠ 2048O1
8Wichtige Informati- onen2DEGO99
+ + +## . Belegungsrichtlinien + +s. ,Wertpapierorder“ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 144Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Wertpapiere
+ + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag zur Ausführung vorgemerkt
0010Auftrag zur Ausführung angenommen
0010Auftrag entgegengenommen, Ausführungskurs steht noch aus
3060Zunächst Wertpapierinformationen lesen und dann ggf. den Auftrag erneut senden
3060Zunächst Verkaufsprospekt lesen und dann ggf. den Auftrag erneut senden
3820Prüfen Sie zu gegebener Zeit den Orderstatus
9010Auftrag abgelehnt - Annahme aus technischen Gründen z. Z. nicht möglich
9010Auftragsidentifikation ist falsch
9210Order abgelehnt - inhaltlich ungültig
9210Auftrag abgelehnt, da wichtige Informationen nicht beachtet
9220Wertpapier ist nicht im Depot
9220Wertpapierkennnummer existiert nicht
9220Verrechnungskonto existiert nicht
9220Gültigkeit nicht zulässig
9220Währungskennzeichen falsch
9230Unzureichendes Guthaben des Verrechnungskontos
+ + +## c) Bankparameterdaten + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Fondsorder Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIWFOS
Bezugssegment:HKVVB
Version:2
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Fonds- order2DEGM1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Wertpapiere
Geschäftsvorfälle		Stand: 07.08.2015Seite: 145
+ + +#### C.4.2 Statusinformationen + + +##### C.4.2.1Orderanzeige + + +###### C.4.2.1.1 Segmentversion 2 + +Mit diesem Geschäftsvorfall kann der Kunde eine Kopie des aktuellen Standes der +einer bestimmten Order abrufen. + +Der Geschäftsvorfall kann ebenfalls dazu benutzt werden, die Auftragsidentifikation +bzw. Ordernummer für diejenigen Kundensysteme, die diese Nummer nicht lokal +ablegen können, zu übermitteln, um diesen diese Möglichkeit zu geben, den Auftrag +bei einer Änderung oder Streichung zu referenzieren. + +Realisierung Bank: +optional + +Realisierung Kunde: optional + + +####### a) Kundenauftrag + + +######## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Orderanzeige anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKOAN
Bezugssegment:-
Version:2
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Depot3DEGktv#M1
3Alle Depots1DEjn#M1
4Auftragsidentifikati- on1DEan.99O1
5Ordernummer1DEan..99O1
6Maximale Anzahl Einträge1DEnum..4O1>0
7Aufsetzpunkt1DEan..35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +## . Belegungsrichtlinien + + +## Depot + +Hier ist die Nummer des Depots einzustellen, für das die Orderanzeige ein- +geholt werden sollen. Wird die Abfrage über alle Depots gestellt, so ist ein +beliebiges gültiges Depot des Kunden anzugeben. + + +## Auftragsidentifikation, Ordernummer + +Es ist die Identifikationsnummer/Ordernummer des Auftrags anzugeben, für +den die Orderanzeige abgerufen werden soll. Falls keine Identifikations- +nummer/Ordernummer angegeben wird, werden alle offenen Aufträge abge- +fragt. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
146		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Wertpapiere
+ + +# b) Kreditinstitutsrückmeldung + + +## . Beschreibung + +Für jede Order und für jede Teilausführung wird ein Segment zurückgemeldet. Das +Feld ,,Wertpapierorder" wird mit einer Kopie des aktuellen Standes der Order im +Format MT 502 in Version ,,SRG 2002" (s. [Datenformate]) belegt. + +Dieser Geschäftsvorfall dient gleichzeitig als Splittinginformation. Wurde der Auftrag +vom Ordersystem in mehrere Einzelorder gesplittet, werden auf diesem Weg die je- +weilige Orderreferenz sowie die zugehörigen Informationen übermittelt. + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Orderanzeige
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIOAN
Bezugssegment:HKOAN
Version:2
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Depot3DEGktv#M1
3Wertpapierorder1DEbin. .M1
4Wertpapierordersta- tus2DEcode.2O10-11
5Ordersplitt1DEjn#M1
6Order änderbar1DEjn#O1
7Auftragsidentifikati- on1DEan.99C1M: ,,Ordernummer" leer O: sonst
8Ordernummer1DEan.99C1M: „Auftragsidentifikation“ leer
O: sonst
9Gültigkeitszeitpunkt1DEGtsp#O1
+ + +## . Belegungsrichtlinien + + +### Wertpapierorder + +Die Order ist im Format MT 502 in Version ,,SRG 2002" (s. [Datenformate]) +einzustellen. Es gelten die folgenden abweichenden Belegungsvorschriften: + +. A:23G: Es ist ,,/COPY" anzugeben. + + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
9010Referenznummer unbekannt
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle
Wertpapiere		Stand: 07.08.2015Seite: 147
+ + +# c) Bankparameterdaten + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Orderanzeige Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIOANS
Bezugssegment:HKVVB
Version:2
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Order- anzeige2DEGM1
+ + +### C.4.2.1.2 Segmentversion 3 + +Mit diesem Geschäftsvorfall kann der Kunde eine Kopie des aktuellen Standes einer +bestimmten Order abrufen. + +Der Geschäftsvorfall kann ebenfalls dazu benutzt werden, die Auftragsidentifikation +bzw. Ordernummer für diejenigen Kundensysteme, die diese Nummer nicht lokal +ablegen können, zu übermitteln, um diesen diese Möglichkeit zu geben, den Auftrag +bei einer Änderung oder Streichung zu referenzieren. + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +# a) Kundenauftrag + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Orderanzeige anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKOAN
Bezugssegment:-
Version:3
Sender:Kunde
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
148		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt:
Wertpapiere
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Depot3DEGktv#M1
3Alle Depots1DEjn#M1
4Nur selbst erteilte Aufträge1DEjn#M1
5Auftragsidentifikati- on1DEan..99O1
6Ordernummer1DEan..99O1
7Maximale Anzahl Einträge1DEnum..4O1>0
8Aufsetzpunkt1DEan..35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +# . Belegungsrichtlinien + + +## Depot + +Hier ist die Nummer des Depots einzustellen, für das die Orderanzeige eingeholt +werden sollen. Wird die Abfrage über alle Depots gestellt, so ist ein beliebiges gülti- +ges Depot des Kunden anzugeben. + + +## Auftragsidentifikation, Ordernummer + +Es ist die Identifikationsnummer/Ordernummer des Auftrags anzugeben, für den die +Orderanzeige abgerufen werden soll. Falls keine Identifikationsnum- +mer/Ordernummer angegeben wird, werden alle offenen Aufträge abgefragt. + + +## b) Kreditinstitutsrückmeldung + + +## . Beschreibung + +Für jede Order und für jede Teilausführung wird ein Segment zurückgemeldet. Das +Feld ,,Wertpapierorder" wird mit einer Kopie des aktuellen Standes der Order im +Format MT 502 in Version ,,SRG 2002" (s. [Datenformate]) belegt. + +Dieser Geschäftsvorfall dient gleichzeitig als Splittinginformation. Wurde der Auftrag +vom Ordersystem in mehrere Einzelorder gesplittet, werden auf diesem Weg die je- +weilige Orderreferenz sowie die zugehörigen Informationen übermittelt. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
. Format
Name:Orderanzeige
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIOAN
Bezugssegment:HKOAN
Version:3
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameTypFor- matLän- geSta- tusAn- zahlRestriktionen
1SegmentkopfDEGM1
2DepotDEGktv#M1
3WertpapierorderDEbin..M1
4WertpapierorderstatusDEcode..2O10-11
5OrdersplittDEjn#M1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle WertpapiereStand: 07.08.2015Seite: 149
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
6Order änderbarDEjn#O1
7AuftragsidentifikationDEan.99C1M: ,,Ordernummer" leer O: sonst
8OrdernummerDEan.99C1M: „Auftragsidentifikation“ leer
O: sonst
9GültigkeitszeitpunktDEGtsp#O1
+ + +# . Belegungsrichtlinien + + +## Wertpapierorder + +Die Order ist im Format MT 502 in Version ,,SRG 2002" (s. [Datenformate]) +einzustellen. Es gelten die folgenden abweichenden Belegungsvorschriften: + +. A:23G: Es ist ,,/COPY" anzugeben. + +◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
9010Referenznummer unbekannt
+ + +# c) Bankparameterdaten + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Orderanzeige Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIOANS
Bezugssegment:HKVVB
Version:3
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Order- anzeige2DEGM1
+ + +## C.4.2.1.3 Segmentversion 4 + +Mit diesem Geschäftsvorfall kann der Kunde eine Kopie des aktuellen Standes einer +bestimmten Order abrufen. + +Der Geschäftsvorfall kann ebenfalls dazu benutzt werden, die Auftragsidentifikation +bzw. Ordernummer für diejenigen Kundensysteme, die diese Nummer nicht lokal +ablegen können, zu übermitteln, um diesen diese Möglichkeit zu geben, den Auftrag +bei einer Änderung oder Streichung zu referenzieren. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
150		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt:
Wertpapiere
+ + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +# a) Kundenauftrag + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Orderanzeige anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKOAN
Bezugssegment:-
Version:4
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Depot3DEGktv#M1
3Alle Depots1DEjn#M1
4Nur selbst erteilte Aufträge1DEjn#M1
5Auftragsidentifikati- on1DEan..99O1
6Ordernummer1DEan..99O1
7Maximale Anzahl Einträge1DEnum..4O1>0
8Aufsetzpunkt1DEan..35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +# . Belegungsrichtlinien + + +## Depot + +Hier ist die Nummer des Depots einzustellen, für das die Orderanzeige eingeholt +werden sollen. Wird die Abfrage über alle Depots gestellt, so ist ein beliebiges gülti- +ges Depot des Kunden anzugeben. + + +## Auftragsidentifikation, Ordernummer + +Es ist die Identifikationsnummer/Ordernummer des Auftrags anzugeben, für den die +Orderanzeige abgerufen werden soll. Falls keine Identifikationsnum- +mer/Ordernummer angegeben wird, werden alle offenen Aufträge abgefragt. + + +## b) Kreditinstitutsrückmeldung + + +### . Beschreibung + +Für jede Order und für jede Teilausführung wird ein Segment zurückgemeldet. Das +Feld ,,Wertpapierorder" wird mit einer Kopie des aktuellen Standes der Order im +Format MT 502 in Version ,,SRG 2002" (s. [Datenformate]) belegt. + +Dieser Geschäftsvorfall dient gleichzeitig als Splittinginformation. Wurde der Auftrag +vom Ordersystem in mehrere Einzelorder gesplittet, werden auf diesem Weg die je- +weilige Orderreferenz sowie die zugehörigen Informationen übermittelt. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle
Wertpapiere		Stand: 07.08.2015Seite: 151
+ + +# . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Orderanzeige
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIOAN
Bezugssegment:HKOAN
Version:4
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameTypFor- matLän- geSta- tusAn- zahlRestriktionen
1SegmentkopfDEGM1
2DepotDEGktv#M1
3WertpapierorderDEbin..M1
4WertpapierorderstatusDEcode..2O10-11
5OrdersplittDEjn#M1
6Order änderbarDEjn#O1
7AuftragsidentifikationDEan.99C1M: ,,Ordernummer" leer O: sonst
8OrdernummerDEan.99C1M: „Auftragsidentifikation“ leer
O: sonst
9GültigkeitszeitpunktDEGtsp#O1
+ + +# . Belegungsrichtlinien + + +![](figures/171.1) + + +![](figures/171.2) + + +Aufgrund neuer Ordertypen und anderer Anforderungen wurde das +bisherige S.W.I.F.T.-Format MT 502 ,,SRG 2002" so modifiziert, +dass diese abgebildet werden können. Die betreffende Version fin- +det sich im Band Finanzdatenformate [Datenformate] unter „MT +502 (erweitert)" beschrieben. + + +## Wertpapierorder + +Die Order ist im Format MT 502 in Version „SRG 2002“ (erweitert) (s. [Daten- +formate]) einzustellen. Es gelten die folgenden abweichenden Belegungs- +vorschriften: + +. A:23G: Es ist ,,/COPY" anzugeben. + + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
9010Referenznummer unbekannt
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
152		Stand:
07.08.2015		Kapitel: Geschäftsvorfälle
Abschnitt: Wertpapiere
+ + +# c) Bankparameterdaten + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Orderanzeige Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIOANS
Bezugssegment:HKVVB
Version:4
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Order- anzeige2DEGM1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle WertpapiereStand: 07.08.2015Seite: 153
+ + +## C.4.2.2Orderstatus + + +### C.4.2.2.1 Segmentversion 3 + +Mit diesem Geschäftsvorfall kann der Kunde die Stati aller Order zu seinen Depots, +für die er legitimiert ist, abfragen. Es können sowohl die Order zu einem oder zu al- +len Depots abgefragt werden. Es ist dem Kreditinstitut freigestellt, ob es nur offene +oder auch abgerechnete Order zurückmeldet. + +Es wird eine genaue Eingrenzung der vom Kunden gewünschten Information er- +möglicht. Mit dem Auftragsfilter kann z.B. spezifiziert werden, zu welchen konkreten +Ordern Informationen angefordert werden, der Zeitraum kann eingegrenzt oder die +Auswahl kann unter dem Gesichtspunkt bestimmter Stati gesteuert werden. + +Der Geschäftsvorfall kann ebenfalls dazu benutzt werden, die Auftragsidentifikation +bzw. Ordernummer für diejenigen Kundensysteme, die diese Nummer nicht lokal +ablegen können, zu übermitteln, um diesen diese Möglichkeit zu geben, den Auftrag +bei einer Änderung oder Streichung zu referenzieren. + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +#### a) Kundenauftrag + +Durch die Angabe von vorgesehenen Kriterien (z.B. Auftragsidentifikation, Zeitraum, +Auftragsfilter) lassen sich die anzufordenden Orders weiter einschränken. + + +##### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Orderstatus anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKWSO
Bezugssegment:-
Version:3
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Depot3DEGktv#M1
3Alle Depots1DEjn#M1
4Weitere Informatio- nen gewünscht1DEjn#M1
5Nur selbst erteilte Aufträge1DEjn#M1
6Auftragsidentifikati- on1DEan.99O1
7Ordernummer1DEan.99O1
8Zeitraum von1DEdat#O1
9Zeitraum bis1DEdat#O1
10Auftragsfilter3DEGO1
11Maximale Anzahl Einträge1DEnum.4O1>0
12Aufsetzpunkt1DEan..35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
154		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Wertpapiere
+ + + + + + + + + + + + + + +
N: sonst
+ + +#### . Belegungsrichtlinien + + +##### Depot + +Hier ist die Nummer des Depots einzustellen, für das die Orderanzeige ein- +geholt werden soll. Wird die Abfrage über alle Depots gestellt, so ist ein be- +liebiges gültiges Depot des Kunden anzugeben. + + +#### b) Kreditinstitutsrückmeldung + + +##### . Beschreibung + +Dieser Geschäftsvorfall dient gleichzeitig als Splittinginformation. Wird der Auftrag +vom Ordersystem in mehrere Einzelorder gesplittet, werden auf diesem Weg die je- +weilige Orderreferenz sowie die zugehörigen Informationen übermittelt. + +Für jede Order und für jede Teilausführung wird ein Segment zurückgemeldet. + + +##### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Orderstatus
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIWSO
Bezugssegment:HKWSO
Version:3
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Depot3DEGktv#M1
3Wertpapierordersta- tus2DEcode..2M10-11
4Ordersplitt1DEjn#M1
5Order änderbar1DEjn#M1
6Auftragsidentifikati- on1DEan.99C1M: ,,Ordernummer" leer O: sonst
7Ordernummer1DEan.99C1M: „Auftragsidentifikation“ leer O: sonst
8Vormerkungszeit- punkt1DEGtsp#O1
9Gültigkeitszeitpunkt1DEGtsp#O1
10Ausführungsanzei- ge1DEbin..C1O: Auftrag wurde ausge- führt bzw. teilausgeführt N: sonst
11Wertpapierabrech- nung1DEbin. .C1O: Auftrag wurde abgerech- net N: sonst
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle WertpapiereStand: 07.08.2015Seite: 155
+ + +#### . Belegungsrichtlinien + + +##### Auftragsidentifikation + +Es kann die Auftragsidentifikation aus der Rückmeldung auf die Ordereinrei- +chung angegeben werden. + + +##### Ordernummer + +Es kann die Ordernummer aus der Rückmeldung auf die Ordereinreichung +angegeben werden. + + +##### Ausführungsanzeige + +Ausführungsanzeige im Format MT 513 in Version ,,SRG 1998" (s. [Daten- +formate]) + + +![](figures/175.1) + + +Das Kundensystem muss damit rechnen, dass mit identi- +scher Referenz des Senders (Feld :20C: in Folge A) eine +weitere Ausführungsanzeige bzw. Wertpapierabrechnung mit +anderer Uhrzeit in Feld :98C: der Folge A empfangen wer- +den kann, wobei es sich um eine Korrektur der ursprüngli- +chen Nachricht handelt. + + +##### Wertpapierabrechnung + +Wertpapierabrechnung im Format MT 515 in Version „SRG 1998“ (s. [Daten- +formate]) + + +#### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
9010Referenznummer falsch
9220Es liegen keine Informationen für Order vor
+ + +#### c) Bankparameterdaten + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
. Format
Name:Orderstatus Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIWSOS
Bezugssegment:HKVVB
Version:3
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Order- status2DEGM1
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
156		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Wertpapiere
+ + +### C.4.2.2.2 Segmentversion 4 + +Mit diesem Geschäftsvorfall kann der Kunde die Stati aller Order zu seinen Depots, +für die er legitimiert ist, abfragen. Es können sowohl die Order zu einem oder zu al- +len Depots abgefragt werden. Es ist dem Kreditinstitut freigestellt, ob es nur offene +oder auch abgerechnete Order zurückmeldet. + +Es wird eine genaue Eingrenzung der vom Kunden gewünschten Information er- +möglicht. Mit dem Auftragsfilter kann z.B. spezifiziert werden, zu welchen konkreten +Ordern Informationen angefordert werden, der Zeitraum kann eingegrenzt oder die +Auswahl kann unter dem Gesichtspunkt bestimmter Stati gesteuert werden. + +Der Geschäftsvorfall kann ebenfalls dazu benutzt werden, die Auftragsidentifikation +bzw. Ordernummer für diejenigen Kundensysteme, die diese Nummer nicht lokal +ablegen können, zu übermitteln, um diesen diese Möglichkeit zu geben, den Auftrag +bei einer Änderung oder Streichung zu referenzieren. + +Realisierung Bank: +optional + +Realisierung Kunde: optional + + +#### a) Kundenauftrag + +Durch die Angabe von vorgesehenen Kriterien (z.B. Auftragsidentifikation, Zeitraum, +Auftragsfilter) lassen sich die anzufordenden Orders weiter einschränken. + + +##### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Orderstatus anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKWSO
Bezugssegment:-
Version:4
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Depot3DEGktv#M1
3Alle Depots1DEjn#M1
4Orderauskunft ge- wünschtDEjn#C1M: ,,Orderauskunft ge- wünscht erlaubt“ BPD = J N: sonst
5Weitere Informatio- nen gewünscht1DEjn#M1
6Nur selbst erteilte Aufträge1DEjn#M1
7Auftragsidentifikati- on1DEan.99O1
8Ordernummer1DEan.99O1
9Zeitraum von1DEdat#O1
10Zeitraum bis1DEdat#O1
11Auftragsfilter3DEGO1
12Maximale Anzahl Einträge1DEnum..4O1>0
13Aufsetzpunkt1DEan..35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle
Wertpapiere		Stand: 07.08.2015Seite: 157
+ + + + + + + + + + + + + + +
N: sonst
+ + +#### . Belegungsrichtlinien + + +##### Depot + +Hier ist die Nummer des Depots einzustellen, für das die Orderanzeige ein- +geholt werden soll. Wird die Abfrage über alle Depots gestellt, so ist ein be- +liebiges gültiges Depot des Kunden anzugeben. + + +#### b) Kreditinstitutsrückmeldung + + +##### . Beschreibung + +Dieser Geschäftsvorfall dient gleichzeitig als Splittinginformation. Wird der Auftrag +vom Ordersystem in mehrere Einzelorder gesplittet, werden auf diesem Weg die je- +weilige Orderreferenz sowie die zugehörigen Informationen übermittelt. + +Für jede Order und für jede Teilausführung wird ein Segment zurückgemeldet. + + +##### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Orderstatus
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIWSO
Bezugssegment:HKWSO
Version:4
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Depot3DEGktv#M1
3Wertpapierordersta- tus2DEcode..2M10-11
4Ordersplitt1DEjn#M1
5Order änderbar1DEjn#M1
6Auftragsidentifikati- on1DEan.99C1M: ,,Ordernummer" leer O: sonst
7Ordernummer1DEan.99C1M: „Auftragsidentifikation“ leer O: sonst
8Vormerkungszeit- punkt1DEGtsp#O1
9Gültigkeitszeitpunkt1DEGtsp#O1
10Orderanzeigeinfor- mation1DEGC1M: ,,Orderauskunft ge- wünscht“ = J N: sonst
11Ausführungsanzei- ge1DEbin..C1O: Auftrag wurde ausge- führt bzw. teilausgeführt N: sonst
12Wertpapierabrech- nung1DEbin..C1O: Auftrag wurde abgerech- net N: sonst
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
158		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Wertpapiere
+ + +#### . Belegungsrichtlinien + + +![](figures/178.1) + + +![](figures/178.2) + + +Aufgrund neuer Ordertypen und anderer Anforderungen wurde das +bisherige S.W.I.F.T.-Format MT 502 ,,SRG 2002" so modifiziert, +dass diese abgebildet werden können. Die betreffende Version fin- +det sich im Band Finanzdatenformate [Datenformate] unter „MT +502(erweitert)" beschrieben. + + +##### Auftragsidentifikation + +Es kann die Auftragsidentifikation aus der Rückmeldung auf die Ordereinrei- +chung angegeben werden. + + +##### Ordernummer + +Es kann die Ordernummer aus der Rückmeldung auf die Ordereinreichung +angegeben werden. + + +##### Orderanzeigeinformation + +Die Wertpapierorder ist im Format MT 502 (erweitert) in Version „SRG 2002“ +(s. [Datenformate]) einzustellen. Es gelten die folgenden abweichenden Be- +legungsvorschriften: + +. A:23G: Es ist ,,/COPY" anzugeben. + + +##### Ausführungsanzeige + +Ausführungsanzeige im Format MT 513 in Version ,,SRG 1998" (s. [Daten- +formate]) + + +![](figures/178.3) + + +Das Kundensystem muss damit rechnen, dass mit identi- +scher Referenz des Senders (Feld :20C: in Folge A) eine +weitere Ausführungsanzeige bzw. Wertpapierabrechnung mit +anderer Uhrzeit in Feld :98C: der Folge A empfangen wer- +den kann, wobei es sich um eine Korrektur der ursprüngli- +chen Nachricht handelt. + + +##### Wertpapierabrechnung + +Wertpapierabrechnung im Format MT 515 in Version „SRG 1998" (s. [Daten- +formate]) + + +##### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
9010Referenznummer falsch
9220Es liegen keine Informationen für Order vor
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Wertpapiere
Geschäftsvorfälle		Stand: 07.08.2015Seite: 159
+ + +# c) Bankparameterdaten + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Orderstatus Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIWSOS
Bezugssegment:HKVVB
Version:4
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Order- status3DEGM1
+ + +### C.4.2.2.3 Segmentversion 5 + +Mit diesem Geschäftsvorfall kann der Kunde die Stati aller Order zu seinen Depots, +für die er legitimiert ist, abfragen. Es können sowohl die Order zu einem oder zu al- +len Depots abgefragt werden. Es ist dem Kreditinstitut freigestellt, ob es nur offene +oder auch abgerechnete Order zurückmeldet. + +Es wird eine genaue Eingrenzung der vom Kunden gewünschten Information er- +möglicht. Mit dem Auftragsfilter kann z.B. spezifiziert werden, zu welchen konkreten +Ordern Informationen angefordert werden, der Zeitraum kann eingegrenzt oder die +Auswahl kann unter dem Gesichtspunkt bestimmter Stati gesteuert werden. + +Der Geschäftsvorfall kann ebenfalls dazu benutzt werden, die Auftragsidentifikation +bzw. Ordernummer für diejenigen Kundensysteme, die diese Nummer nicht lokal +ablegen können, zu übermitteln, um diesen diese Möglichkeit zu geben, den Auftrag +bei einer Änderung oder Streichung zu referenzieren. + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +#### d)a) Kundenauftrag + +Durch die Angabe von vorgesehenen Kriterien (z.B. Auftragsidentifikation, Zeitraum, +Auftragsfilter) lassen sich die anzufordenden Orders weiter einschränken. + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Orderstatus anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKWSO
Bezugssegment:-
Version:55
Sender:Kunde
+ + + + + + + + + + + + + + +
Nr.NameVer-TypFor-Län-Sta-An-Restriktionen
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 160Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Wertpapiere
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
sionmatgetuszahl
1Segmentkopf1DEGM1
2Depot3DEGktv#M1
3Alle Depots1DEjn#M1
4Orderauskunft ge- wünschtDEjn#C1M: ,,Orderauskunft ge- wünscht erlaubt“ BPD = J N: sonst
5Weitere Informatio- nen gewünscht1DEjn#M1
6Nur selbst erteilte Aufträge1DEjn#M1
7Auftragsidentifikati- on1DEan..99O1
8Ordernummer1DEan.99O1
9Zeitraum von1DEdat#O1
10Zeitraum bis1DEdat#O1
11Auftragsfilter V444DEGO1
12Maximale Anzahl Einträge1DEnum..4O1>0
13Aufsetzpunkt1DEan..35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +#### . Belegungsrichtlinien + + +## Depot + +Hier ist die Nummer des Depots einzustellen, für das die Orderanzeige ein- +geholt werden soll. Wird die Abfrage über alle Depots gestellt, so ist ein be- +liebiges gültiges Depot des Kunden anzugeben. + + +## e)b) Kreditinstitutsrückmeldung + + +### . Beschreibung + +Dieser Geschäftsvorfall dient gleichzeitig als Splittinginformation. Wird der Auftrag +vom Ordersystem in mehrere Einzelorder gesplittet, werden auf diesem Weg die je- +weilige Orderreferenz sowie die zugehörigen Informationen übermittelt. + +Für jede Order und für jede Teilausführung wird ein Segment zurückgemeldet. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Orderstatus
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIWSO
Bezugssegment:HKWSO
Version:55
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Depot3DEGktv#M1
3Wertpapierordersta-33DEcode..2M10-1717
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:GeschäftsvorfälleStand:Seite:
Abschnitt:Wertpapiere07.08.2015161
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
tusWertpapierorder status
4Ordersplitt1DEjn#M1
5Order änderbar1DEjn#M1
6Auftragsidentifikati- on1DEan..99C1M: ,,Ordernummer" leer O: sonst
7Ordernummer1DEan.99C1M: „Auftragsidentifikation“ leer O: sonst
8Vormerkungszeit- punkt1DEGtsp#O1
9Gültigkeitszeitpunkt1DEGtsp#O1
10Orderanzeigeinfor- mation1DEGC1M: ,,Orderauskunft ge- wünscht“ = J N: sonst
11Ausführungsanzei- ge1DEbin..C1O: Auftrag wurde ausge- führt bzw. teilausgeführt N: sonst
12Wertpapierabrech- nung1DEbin..C1O: Auftrag wurde abgerech- net N: sonst
+ + +# . Belegungsrichtlinien + + +![](figures/181.1) + + +![](figures/181.2) + + +Aufgrund neuer Ordertypen und anderer Anforderungen wurde das +bisherige S.W.I.F.T.-Format MT 502 ,,SRG 2002" so modifiziert, +dass diese abgebildet werden können. Die betreffende Version fin- +det sich im Band Finanzdatenformate [Datenformate] unter „MT +502(erweitert)" beschrieben. + + +## Auftragsidentifikation + +Es kann die Auftragsidentifikation aus der Rückmeldung auf die Ordereinrei- +chung angegeben werden. + + +## Ordernummer + +Es kann die Ordernummer aus der Rückmeldung auf die Ordereinreichung +angegeben werden. + + +## Orderanzeigeinformation + +Die Wertpapierorder ist im Format MT 502 (erweitert) in Version „SRG 2002“ +(s. [Datenformate]) einzustellen. Es gelten die folgenden abweichenden Be- +legungsvorschriften: + +. A:23G: Es ist ,,/COPY" anzugeben. + + +## Ausführungsanzeige + +Ausführungsanzeige im Format MT 513 in Version ,,SRG 1998" (s. [Daten- +formate]) + + +![](figures/181.3) + + +Das Kundensystem muss damit rechnen, dass mit identi- +scher Referenz des Senders (Feld :20C: in Folge A) eine +weitere Ausführungsanzeige bzw. Wertpapierabrechnung mit + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
162		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Wertpapiere
+ + +anderer Uhrzeit in Feld :98C: der Folge A empfangen wer- +den kann, wobei es sich um eine Korrektur der ursprüngli- +chen Nachricht handelt. + + +## Wertpapierabrechnung + +Wertpapierabrechnung im Format MT 515 in Version „SRG 1998" (s. [Daten- +formate]) + + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
9010Referenznummer falsch
9220Es liegen keine Informationen für Order vor
+ + +## f)c) Bankparameterdaten + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Orderstatus Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIWSOS
Bezugssegment:HKVVB
Version:55
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Order- status3DEGM1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Wertpapiere
Geschäftsvorfälle		Stand: 07.08.2015Seite: 163
+ + +## C.4.2.3Orderhistorie + +Die Asynchronität von Auftragserteilung und Auftragsausführung beim Wertpapier- +geschäft macht es erforderlich, sich über den Status der Änderungen und Strei- +chungen einer bestimmten Order informieren zu können. + + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +# a) Kundenauftrag + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Wertpapierorderhistorie anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKWOH
Bezugssegment:-
Version:3
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Depot3DEGktv#M1
3Alle Depots1DEjn#M1
4Auftragsidentifikati- on1DEan.99C1M: ,,Ordernummer" leer O: sonst
5Ordernummer1DEan.99C1M: „Auftragsidentifikation“ leer O: sonst
6Maximale Anzahl Einträge1DEnum..4O1>0
7Aufsetzpunkt1DEan..35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +## . Belegungsrichtlinien + +Depot + +Wird die Abfrage über alle Depots gestellt, so ist ein beliebiges gültiges De- +pot des Kunden anzugeben. + + +## Auftragsidentifikation, Ordernummer + +Es ist die eindeutige Referenz des Auftrags anzugeben. + + +## b) Kreditinstitutsrückmeldung + + +## . Beschreibung + +Für den Ursprungsauftrag sowie für jede Änderung und Streichung wird jeweils ein +Segment übermittelt. Wird die Order gesplittet, so ist das Segment für jeden Teilauf- +trag zu übermitteln. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
164		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Wertpapiere
+ + +# . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Wertpapierorderhistorie rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIWOH
Bezugssegment:HKWOH
Version:3
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Wertpapierordersta- tus2DEcode..2M10-11
3Ordersplitt1DEjn#M1
4Wertpapierorder1DEbin..M1
5Auftragsidentifikati- on1DEan.99C1M: ,,Ordernummer" leer O: sonst
6Ordernummer1DEan.99C1M: „Auftragsidentifikation“ leer
O: sonst
7Gültigkeitszeitpunkt1DEGtsp#O1
+ + +# . Belegungsrichtlinien + + +## Wertpapierorder + +Es wird eine Kopie des Auftrages im S.W.I.F.T.-Format MT 502 in Version +„SRG 2002“ (s. [Datenformate]) übermittelt, so wie dieser zum angegebenen +Zeitpunkt gültig war. In Feld A:23G: ist ,/COPY" anzugeben. + + +## Auftragsidentifikation, Ordernummer + +Es ist die eindeutige Referenz des Auftrags anzugeben. + + +# c) Bankparameterdaten + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Wertpapierorderhistorie Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIWOHS
Bezugssegment:HKVVB
Version:3
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle WertpapiereStand: 07.08.2015Seite: 165
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Wertpa- pierorderhistorie1DEGM1
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
166		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Wertpapiere
+ + +# C.4.3 Depotinformationen + + +## C.4.3.1Depotaufstellung + +Realisierung Bank: +optional + +Realisierung Kunde: +optional + + +## a) Kundenauftrag + + +### . Beschreibung + +Die Depotaufstellung kann beliebige Papiere, auch in Fremdwährungen, umfassen. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Depotaufstellung anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKWPD
Bezugssegment:-
Version:6
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Depot3DEGktv#M1
3Währung der De- potaufstellung1DEcur#C1O: „Währung der Depotauf- stellung wählbar“ (BPD) = „J“ N: sonst
4Kursqualität2DEcode1C11,2 O: „Kursqualität wählbar“ (BPD) = „J“ N: sonst
5Maximale Anzahl Einträge1DEnum..4C1>0
O: ,,Eingabe Anzahl Ein- träge erlaubt“ (BPD) = „J“ N: sonst
6Aufsetzpunkt1DEan.35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +## b) Kreditinstitutsrückmeldung + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Depotaufstellung rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIWPD
Bezugssegment:HKWPD
Version:6
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:GeschäftsvorfälleStand:Seite:
Abschnitt:Wertpapiere07.08.2015167
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Depotaufstellung1DEbin..M1
+ + +## . Belegungsrichtlinien + + +### Depotaufstellung + +Es ist das S.W.I.F.T.-Format MT 535 in der Version ,,SRG 1998" (s. [Daten- +formate]) einzustellen. + +Auf die Verwendung des vom HBCI-Zeichensatz abweichenden S.W.I.F.T.- +Zeichensatzes1 ist zu achten. + + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
3010Es liegen keine Einträge vor
9210Keine gültige Kontonummer des Kunden
9210Konto ist kein Depotkonto
+ + +## c) Bankparameterdaten + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Depotaufstellung Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIWPDS
Bezugssegment:HKVVB
Version:6
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Depot- aufstellung2DEGM1
+ + + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
168		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Wertpapiere
+ + +## C.4.3.2Depotumsätze + +Realisierung Bank: +optional + +Realisierung Kunde: + +optional + +Wertpapierorder stellen nur eine Teilmenge der Depotumsätze dar. Umsätze kön- +nen auch durch Übertragungen aus anderen Depots desselben oder anderer Kun- +den, Ausgabe von Gratisaktien, Herabsetzungen des Grundkapitals usw. entstehen. + + +## a) Kundenauftrag + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Depotumsätze anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKWDU
Bezugssegment:-
Version:5
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Depot3DEGktv#M1
3Alle Depots1DEjn#M1
4Wertpapierreferenz2DEGO1
5Zeitraum von1DEdat#O1
6Zeitraum bis1DEdat#O1
7Maximale Anzahl Einträge1DEnum..4O1>0
8Aufsetzpunkt1DEan.35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +## . Belegungsrichtlinien + +Depot + +Wird die Abfrage über alle Depots gestellt, so ist ein beliebiges gültiges De- +pot des Kunden anzugeben. + + +## b) Kreditinstitutsrückmeldung + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Depotumsätze rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIWDU
Bezugssegment:HKWDU
Version:5
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle WertpapiereStand: 07.08.2015Seite: 169
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Umsatzauskunft1DEbin..M1
+ + +## . Belegungsrichtlinien + + +### Umsatzauskunft + +Es ist das S.W.I.F.T.-Format MT 536 in der Version ,,SRG 1998" (s. [Daten- +formate]) einzustellen. + + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
3010Es liegen keine Umsätze vor
9210keine gültige Depotnummer des Kunden
+ + +## c) Bankparameterdaten + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Depotumsätze Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIWDUS
Bezugssegment:HKVVB
Version:5
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Depo- tumsätze1DEGM1
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
170		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Wertpapiere
+ + +# C.4.4 Wertpapierinformationen + +Es können kreditinstitutsseitig verschiedene Arten von Wertpapierinformationen be- +reitgestellt werden, bspw. Stammdaten, Kurse oder Researchdaten. + +Sofern die Referenznummer des Wertpapiers, für das die entsprechenden Informa- +tionen erfragt werden sollen, nicht vorliegt, muss diese zunächst mit Hilfe des Ge- +schäftsvorfalls „Abfrage von Wertpapierreferenznummern“ angefordert werden. + + +Abbildung 5: Abfrage von Wertpapierinformationen + +![Abfrage von Wertpapier- Stammdaten Abfrage von Wertpapier- referenznummern Abfrage von Wertpapier- kursen Abfrage von Wertpapier- informationen](figures/190.1) + + +## C.4.4.1Abfrage von Wertpapierreferenznummern + +Realisierung Bank: +optional + +Realisierung Kunde: optional + +Mit Hilfe dieses Geschäftsvorfalls lassen sich anhand verschiedener Selektionskrite- +rien die Referenznummern (ISIN bzw. WKN) zu einzelnen Wertpapieren erfragen, +die für weiterführende Abfragen bzw. Transaktionen (Order, Kursabfrage etc.) benö- +tigt werden. Ferner wird mitgeteilt, ob für dieses Wertpapier Kurse, Stammdaten o- +der weitere Informationen abrufbar sind. + + +### a) Kundenauftrag + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Wertpapierreferenznummern anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKWPR
Bezugssegment:-
Version:3
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle WertpapiereStand: 07.08.2015Seite: 171
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Wertpapierbezeich- nung Suchbegriff2DEan..99C1O : "Suchbegriff erlaubt" (BPD) = "J" N : sonst
3Region2DEcode1M10, 1, 2
4Wertpapiergruppen1DEGO1
5Nur Standardange- bot1DEjn#M1
6Nur Neuemissionen1DEjn#M1
7Börsenplatz1DEan4O1
8Maximale Anzahl Einträge1DEnum..4O1>0
9Aufsetzpunkt1DEan..35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +### . Belegungsrichtlinien + + +#### Börsenplatz + +Die Selektion kann hiermit auf die an einem bestimmten Börsenplatz gehan- +delten Wertpapiere eingeschränkt werden. Die zulässigen Börsenplätze wer- +den in den Bankparameterdaten mitgeteilt. + + +### b) Kreditinstitutsrückmeldung + + +#### . Beschreibung + +Für jede Wertpapierreferenz wird ein Segment zurückgemeldet. + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Wertpapierreferenznummern rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIWPR
Bezugssegment:HKWPR
Version:3
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Wertpapierbezeich- nung2DEan.99M1
3Stammdaten liefer- bar1DEjn#M1
4Kursdaten lieferbar1DEjn#M1
5Wertpapierinforma- tionen lieferbar1DEjn#M1
6Wertpapierreferenz2DEGM1..9
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
172		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Wertpapiere
+ + +### c) Bankparameterdaten + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Wertpapierreferenznummern Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIWPRS
Bezugssegment:HKVVB
Version:3
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Wertpa- pier- referenznummern2DEGM1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Geschäftsvorfälle WertpapiereStand: 07.08.2015Seite: 173
+ + +# C.4.4.2Wertpapierstammdaten + + +## C.4.4.2.1 Segmentversion 3 + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +![](figures/193.1) + + +Die Stammdaten sind so definiert, dass sie direkt vom liefernden +Unternehmen (z.B. WM) übernommen werden können. Dabei ist +kreditinstitutsseitig zu berücksichtigen, dass evtl. lizenzrechtliche +Probleme bestehen können, falls diese Daten an Kunden weiterge- +geben werden. + + +### a) Kundenauftrag + + +#### . Beschreibung + +Es können pro Segment nur die Stammdaten eines Wertpapiers erfragt werden. +Falls die Stammdaten mehrerer Wertpapiere gewünscht werden, ist je Wertpapierre- +ferenz ein Segment in die Nachricht einzustellen. + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Wertpapierstammdaten anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKWSD
Bezugssegment:-
Version:3
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Depot3DEGktv#C1M: ,Depot erforderlich" (BPD) = „J" O: sonst
3Wertpapierreferenz2DEGM1
+ + +### . Belegungsrichtlinien + + +#### Wertpapierreferenz + +Es ist die Referenznummer des gewünschten Wertpapiers anzugeben. Falls +dem Kunden für dasselbe Wertpapier mehrere verschiedene Referenzen +(z.B. WKN und ISIN) mitgeteilt wurden, so ist es dem Kunden freigestellt, +welche Referenz er angibt. + + +### b) Kreditinstitutsrückmeldung + + +#### . Beschreibung + +Dem Kreditinstitut ist freigestellt, in welchem Umfang es dem Kunden Stammdaten +zur Verfügung stellt. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
174		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Wertpapiere
+ + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Wertpapierstammdaten rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIWSD
Bezugssegment:HKWSD
Version:3
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Wertpapierreferenz2DEGM1
3Wertpapierbezeich- nung2DEan.99M1
4Einheit der Effek- tennotiz2DEcode1M11, 2, 3, 4, 9
5Wertpapierkatego- rie2DEcode1M11, 2, 3, 4
6Wertpapierart1DEnum..3O1
7Wertpapiergruppe2DEan..2O1
8Wertpapierart, Text1DEan.99O1
9Depotwährung1DEcur#O1
10Abrechnungswäh- rung1DEcur#O1
11Ordern möglich2DEcode1O10, 1, 2, 3, 4
12Risikoklasse des Wertpapiers1DEan..2O1
13Emittent1DEnum6O1
14Weitere Informatio- nen1DEtxt.. 2048O1
15Stammdaten Aktien2DEGC1M: „Wertpapierkategorie"=1 N: sonst
16Stammdaten Ren- ten2DEGC1M: ,Wertpapierkategorie"=2 N: sonst
17Stammdaten Fonds1DEGC1M: ,Wertpapierkategorie"=3 N: sonst
18Stammdaten Opti- onsscheine1DEGC1M: „Wertpapierkategorie“=4 N: sonst
19Börsenplatzinfor- mation3DEGO99
+ + +### . Belegungsrichtlinien + + +### Wertpapierreferenz + +Es wird dem Kunden diejenige Referenz zurückgemeldet, die er im Auftrag +angegeben hat. Somit dient diese Information nur zur Zuordnung vom Auf- +trag zur Antwort und nicht der Übermittlung weiterer Referenzarten, wie +bspw. bei der Abfrage der Referenznummern (vgl. Kap. C.4.4.1). + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle WertpapiereStand: 07.08.2015Seite: 175
+ + +# Einheit der Effektennotiz + +Die Angabe ist verpflichtend, damit bei der Wertpapierorder die Information +vorhanden ist, ob die Angabe in Feld B2:36B: in Stück („UNIT") oder als +Nennwert (,,FAMT") erfolgen muss. + + +# Weitere Informationen + +Besonderer Belegung wegen gesetzlicher Anforderungen (siehe Hersteller- +hinweise unter C.4) + + +# c) Bankparameterdaten + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Wertpapierstammdaten Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIWSDS
Bezugssegment:HKVVB
Version:3
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Wertpa- pierstammdaten1DEGM1
+ + +### C.4.4.2.2 Segmentversion 44 + +Realisierung Bank: +optional + +Realisierung Kunde: optional + + +![](figures/195.1) + + +Die Stammdaten sind so definiert, dass sie direkt vom liefernden +Unternehmen (z.B. WM) übernommen werden können. Dabei ist +kreditinstitutsseitig zu berücksichtigen, dass evtl. lizenzrechtliche +Probleme bestehen können, falls diese Daten an Kunden weiterge- +geben werden. + + +# d)a) Kundenauftrag + + +## . Beschreibung + +Es können pro Segment nur die Stammdaten eines Wertpapiers erfragt werden. +Falls die Stammdaten mehrerer Wertpapiere gewünscht werden, ist je Wertpapierre- +ferenz ein Segment in die Nachricht einzustellen. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
176		Stand:
07.08.2015		Kapitel: Geschäftsvorfälle
Abschnitt: Wertpapiere
+ + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Wertpapierstammdaten anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKWSD
Bezugssegment:-
Version:44
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Depot3DEGktv#C1M: ,Depot erforderlich" (BPD) = „J“ O: sonst
3Wertpapierreferenz2DEGM1
+ + +## . Belegungsrichtlinien + + +### Wertpapierreferenz + +Es ist die Referenznummer des gewünschten Wertpapiers anzugeben. Falls +dem Kunden für dasselbe Wertpapier mehrere verschiedene Referenzen +(z.B. WKN und ISIN) mitgeteilt wurden, so ist es dem Kunden freigestellt, +welche Referenz er angibt. + + +### e)b) Kreditinstitutsrückmeldung + + +#### . Beschreibung + +Dem Kreditinstitut ist freigestellt, in welchem Umfang es dem Kunden Stammdaten +zur Verfügung stellt. + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Wertpapierstammdaten rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIWSD
Bezugssegment:HKWSD
Version:4
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle WertpapiereStand: 07.08.2015Seite: 177
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Wertpapierreferenz2DEGM1
3Wertpapierbezeich- nung2DEan..99M1
4Einheit der Effek- tennotiz2DEcode1M11, 2, 3, 4, 9
5Wertpapierkatego- rie2DEcode1M11, 2, 3, 4
6Wertpapierart1DEnum..3O1
7Wertpapiergruppe2DEan..2O1
8Wertpapierart, Text1DEan.99O1
9Kennzeichen kom- plexes zinstru- mentKennzeichen komplexes Finan- zinstrument14DED Ecode- de- code1414J,K,NJ,K,N
10Best-Execution- BörsenplatzBest- Execution- Börsenplatz14DED Eanan4414
11DepotDepot33DEG DEGktvkt v14
12Kennzeichen Exe- cution-Only- DepotKennzeichen Execution Only Depot14DED Ejnjn14
13Direkthandel- DepotDirekthandel- Depot14DED Ejnjn14
14Depotwährung1DEcur#O1
15Abrechnungswäh- rung1DEcur#O1
16Ordern möglich2DEcode1O10, 1, 2, 3, 4
17Risikoklasse des Wertpapiers1DEan..2O1
18Emittent1DEnum6O1
19Weitere Informatio- nen1DEtxt..
2048		O1
20Stammdaten Aktien2DEGC1M: ,,Wertpapierkategorie"=1 N: sonst
21Stammdaten Ren- ten2DEGC1M: ,,Wertpapierkategorie"=2 N: sonst
22Stammdaten FondsStammdaten Fonds22DEGC1M: ,Wertpapierkategorie"=3 N: sonst
23Stammdaten Opti- onsscheine1DEGC1M: ,,Wertpapierkategorie"=4 N: sonst
24Börsenplatzinfor- mation3DEGO99
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
178		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Wertpapiere
+ + +# . Belegungsrichtlinien + + +## Wertpapierreferenz + +Es wird dem Kunden diejenige Referenz zurückgemeldet, die er im Auftrag +angegeben hat. Somit dient diese Information nur zur Zuordnung vom Auf- +trag zur Antwort und nicht der Übermittlung weiterer Referenzarten, wie +bspw. bei der Abfrage der Referenznummern (vgl. Kap. xyz). + + +## Einheit der Effektennotiz + +Die Angabe ist verpflichtend, damit bei der Wertpapierorder die Information +vorhanden ist, ob die Angabe in Feld B2:36B: in Stück (,UNIT") oder als +Nennwert (,,FAMT") erfolgen muss. + + +## Kennzeichen komplexes Finanzinstrument + +Ist das Feld nicht oder mit ,,K“ belegt, so ist nicht ermittelbar, ob es sich um +ein komplexes Finanzinstrument handelt. + + +## Kennzeichen komplexes Finanzinstrument + +Ist das Feld nicht oder mit ,,K" belegt, so ist nicht ermittelbar, ob es sich um +ein komplexes Finanzinstrument handelt. + + +## Weitere Informationen + +Besonderer Belegung wegen gesetzlicher Anforderungen (siehe Hersteller- +hinweise unter C.4) + + +## f)c) Bankparameterdaten + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Wertpapierstammdaten Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIWSDS
Bezugssegment:HKVVB
Version:44
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Wertpa- pierstammdaten1DEGM1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle WertpapiereStand: 07.08.2015Seite: 179
+ + +## C.4.4.3Wertpapierkurse + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +## a) Kundenauftrag + + +### . Beschreibung + +Die Abfrage der Kursdaten eines bestimmten Wertpapiers erfolgt über die jeweilige +Wertpapierreferenz. Liegt diese nicht vor, so ist zunächst eine Abfrage der Wertpa- +pierreferenznummern (Kap. C.4.4.1) durchzuführen. Alternativ können Standard- +angebote des Kreditinstituts auch ohne Kenntnis der zugehörigen Referenznum- +mern angefordert werden. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Wertpapierkurse anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKWPK
Bezugssegment:-
Version:3
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Depot3DEGktv#C1M: ,Depot erforderlich" (BPD) = „J“ O: sonst
3Wertpapierreferenz2DEGC1M: ,Kurspaket“ leer N: sonst
4Börsenplatz1DEan4O1
5Kurspaket1DEan.30C1M: „Wertpapierreferenz“ leer N: sonst
6Kursqualität2DEcode1C11,2 O: „Kursqualität wählbar“ (BPD) = „J“ N: sonst
7Maximale Anzahl Einträge1DEnum..4O1>0
8Aufsetzpunkt1DEan.35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +## . Belegungsrichtlinien + + +## Wertpapierreferenz + +Es ist die Referenznummer des Wertpapiers anzugeben, für das die Kursda- +ten angefordert werden. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
180		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Wertpapiere
+ + +## Börsenplatz + +Die angeforderten Kursdaten können hier auf einen Börsenplatz beschränkt +werden. Es dürfen nur Börsenplätze angegeben werden, die in den Bankpa- +rameterdaten als zulässig mitgeteilt wurden. Falls kein Börsenplatz angege- +ben wird, kann das Kreditinstitut den Börsenplatz selbst bestimmen. Der +Börsenplatz ist gemäß ISO 10383 („Market Identifier Code“) zu kodieren (s. +[Datenformate], Anlagen). + + +## Kurspaket + +Falls ein Kurspaket gewählt wird, erhält der Kunde in jedem Fall das ge- +wünschte Kurspaket - unabhängig von den Angaben in den anderen Selekti- +onsfeldern. + + +![](figures/200.1) + + +Auch im Kundensystem können Kurspakete zusammenge- +stellt werden, indem aus einer zuvor zusammengestellten +Liste von Wertpapieren jeweils Kursanforderungssegmente +erzeugt und in einer Nachricht verschickt werden. + +Im Gegensatz zu den Kreditinstitutsseitig erzeugten Kurs- +paketen kann hierbei der Kunde die Zusammenstellung des +Kurspaketes selbst beeinflussen (z.B. Kurse zu allen im +Depot enthaltenen Wertpapieren). + + +## b) Kreditinstitutsrückmeldung + + +### . Beschreibung + +Für jedes Wertpapier wird ein Segment zurückgemeldet. Pro Wertpapier können +auch mehrere Segmente zurückgemeldet werden, wenn Kurse unterschiedlicher +Börsenplätze angefordert wurden. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Wertpapierkurse rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIWPK
Bezugssegment:HKWPK
Version:3
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Wertpapierreferenz2DEGM1
3Wertpapierbezeich- nung2DEan.99M1
4Börsenplatz1DEan4M1
5Einheit der Effek- tennotiz2DEcode1M11, 2, 3, 4, 9
6Zeitbezug2DEcode1O11,2
7Wertpapierumsatz1DEwrt#O1
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:GeschäftsvorfälleStand:Seite:
Abschnitt:Wertpapiere07.08.2015181
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
8Kassakurs2DEGrate#O1
9Vorbörse2DEGrate#O1
10Eröffnungskurs2DEGrate#O1
11Letzter Kurs2DEGrate#O1
12Nachbörse2DEGrate#O1
13Vortageskurs2DEGrate#O1
14Jahreshöchststand2DEGrate#O1
15Jahrestiefststand2DEGrate#O1
16Ausgabepreis2DEGrate#C1O: beim Wertpapier handelt es sich um einen Fonds N: sonst
17Rücknahmepreis1DEGrate#C1O: beim Wertpapier handelt es sich um einen Fonds N: sonst
+ + +### . Belegungsrichtlinien + + +#### Einheit der Effektennotiz + +Die Angabe ist verpflichtend, damit bei der Wertpapierorder die Information +vorhanden ist, ob die Angabe in Feld B2:36B: in Stück (,UNIT") oder als +Nennwert (,,FAMT") erfolgen muss. + +◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
3010Information wird z.Zt. nicht angeboten
9220Wertpapierkennnummer existiert nicht
9220Keine Kursdaten zu dem gewünschten Börsenplatz lieferbar
+ + +### c) Bankparameterdaten + + +#### . Beschreibung + +Die kreditinstitutsseitig lieferbaren Kursarten werden wegen des hohen Datenvolu- +mens nicht in die BPD eingestellt. Statt dessen erfährt das Kundensystem durch die +Kreditinstitutsrückmeldung, welche Kursarten lieferbar sind. + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Wertpapierkurse Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIWPKS
Bezugssegment:HKVVB
Version:3
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
182		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Wertpapiere
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Wertpa- pierkurse2DEGM1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle WertpapiereStand: 07.08.2015Seite: 183
+ + +## C.4.4.4Wertpapierinformationen + +Realisierung Bank: optional + +Realisierung Kunde: optional + +Zusätzlich zu den standardisierten Wertpapierstammdaten können vom Kunden +auch institutsindividuelle Informationen zu bestimmten Wertpapieren angefordert +werden. Dieses können Angaben sein, die das Institut durch eigenes Research er- +mittelt oder speziell aufbereitet hat. Da die Art der Information nicht standardisiert +ist, wird sie als Freitext an das Kundensystem übermittelt. + +Zur Vermeidung der Übermittlung zu großer Datenvolumina müssen die Informa- +tionen gezielt für ein bestimmtes Wertpapier angefordert werden. + + +![](figures/203.1) + + +Der Kunde sollte darauf hingewiesen werden, dass durch die betref- +fenden Informationen nicht die Anlageberatungspflicht des Instituts +ersetzt wird, sondern lediglich die selbständige Anlageentscheidung +des Kunden erleichtert werden soll. + + +### a) Kundenauftrag + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Wertpapierinformationen anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKWPI
Bezugssegment:-
Version:3
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Depot3DEGktv#C1M: ,Depot erforderlich" (BPD) = „J“ O: sonst
3Wertpapierreferenz2DEGM1
+ + +### b) Kreditinstitutsrückmeldung + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Wertpapierinformationen rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIWPI
Bezugssegment:HKWPI
Version:3
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
184		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Wertpapiere
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Wertpapierreferenz2DEGM1
3Wertpapierbezeich- nung2DEan.99O1
4Wertpapierinforma- tion1DEtxt.. 2048O1
5Grafikformat1DEan..15O1
6Grafik1DEbin..O1
7Web-Link1DEan.256O1
+ + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
3010Zu diesem Wertpapier liegen z.Zt. keine Informationen vor
9220Wertpapierreferenz existiert nicht
+ + +### c) Bankparameterdaten + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Wertpapierinformationen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIWPIS
Bezugssegment:HKVVB
Version:3
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Wertpa- pierinformationen1DEGM1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle WertpapiereStand: 07.08.2015Seite: 185
+ + +## C.4.5 Sonstiges + + +### C.4.5.1Festpreisgeschäft + +Im Rahmen des Festpreisgeschäftes kann der Kunde aus einem festgelegten An- +gebot des Kreditinstitutes auswählen. Das Wertpapier muss nicht erst an der Börse +gehandelt werden. In diesem Fall stellt die Wertpapierorder des Kunden den Auftrag +zur Annahme des Geschäftes dar. + + +### C.4.5.1.1 Festpreisangebote + +Realisierung Bank: optional + +Realisierung Kunde: optional + +Es muss damit gerechnet werden, dass die auf der Kreditinstitutsseite vorgehalte- +nen Angebote bereits verkauft wurden oder die Abrechnung nicht sofort zur Verfü- +gung gestellt wird. + +Als Reaktion auf die Festpreisangebote kann der Kunde seine Annahme eines oder +mehrerer Angebote mit jeweils einer Wertpapierorder (siehe Kapitel C.4.1.2) im For- +mat MT 502 übersenden. + + +## a) Kundenauftrag + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Festpreisangebote anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKWFP
Bezugssegment:-
Version:3
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Wertpapiergruppe, Text1DEan.35O1
3Maximale Anzahl Einträge1DEnum..4O1>0
4Aufsetzpunkt1DEan..35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +## . Belegungsrichtlinien + + +## b) Kreditinstitutsrückmeldung + + +### . Beschreibung + +Es wird je Festpreisangebot ein Segment zurückgemeldet. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
186		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Wertpapiere
+ + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Festpreisangebote rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIWFP
Bezugssegment:HKWFP
Version:3
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Festpreisangebots- nummer1DEid#M1
3Wertpapierreferenz2DEGM1
4Wertpapierbezeich- nung2DEan.99O1
5Wertpapiergruppe, Text1DEan..35O1
6Nominalzinssatz1DEwrt#O1
7Nennwert1DEGbtg#O1
8Zinstermin1DEdig4O1
9Mindestabnahme- betrag1DEGbtg#O1
10Einheit der Effek- tennotiz2DEcode1O11, 2, 3, 4, 9
11Kurs1DEwrt#O1
12Ende der Laufzeit1DEdat#O1
13Einlösungskurs1DEwrt#O1
14Rendite1DEwrt#O1
15Kontingentinforma- tion1DEan.15O1
+ + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
3010Es liegen zur Zeit keine Festpreisangebote vor
+ + +## c) Bankparameterdaten + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Festpreisangebote Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIWFPS
Bezugssegment:HKVVB
Version:3
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle WertpapiereStand: 07.08.2015Seite: 187
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Fest- preisangebote3DEGM1
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
188		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Wertpapiere
+ + +### C.4.5.1.2 Festpreisorder + +Die Festpreisorder erfolgt analog zur Wertpapierorder (s. Kap. C.4.1.2). Zusätzlich +muss jedem Auftrag die Referenznummer auf das jeweilige Festpreisangebot mit- +gegeben werden, die der Kunde mit Hilfe des Geschäftsvorfalls ,Festpreisangebote“ +(s. Kap. C.4.5.1.1) erhält. + + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +#### a) Kundenauftrag + + +##### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Festpreisorder
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKFPO
Bezugssegment:-
Version:2
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Depot3DEGktv#M1
3Auftragsidentifikati- on1DEan..99O1
4Ordernummer1DEan.99O1
5Wertpapierorder1DEbin..O1
6Festpreisangebots- nummer1DEid#O1
7Verrechnungskonto3DEGktv#C1M: , Verrechnungskonto verpflichtend" (BPD) = ,J" O: sonst
8Referenz auf wich- tige Informationen2DEGC1..99M: ,Wichtige Informationen verpflichtend“ (BPD) = „J“ und wichtige Informationen liegen vor N: sonst
+ + +#### . Belegungsrichtlinien + +siehe VII.4.1.2 ,,Wertpapierorder“ + + +#### Wertpapierorder + +Bei einem Festpreisgeschäft ist der MT 502 in Version ,,SRG 2002" (s. [Da- +tenformate]) zu senden und wie folgt zu belegen: + +1 +In Feld A:23G" darf nicht ,/COPY" gesendet werden. + +2 +In Feld A:22F" ist der Transaktionstyp ,TRAD“ anzugeben“. + +3 +In Feld B:94B: ist der Börsenplatz mit „OTCO“ zu belegen. + +4 In Feld B1:90a: ist zur Angabe des Preises der Qualifier ,,DEAL" (Abschluss- +kurs) zu wählen. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Wertpapiere
Geschäftsvorfälle		Stand: 07.08.2015Seite: 189
+ + +5 In Feld B.22H:, Qualifier ,,BUSE“ (Indikator für Kauf/Verkauf) darf nur ,BUYI" +gewählt werden. + +6 In Feld B.22F:, Qualifier ,,TOOR" (Indikator für Art des Limits) darf nur +„LMTO“ gewählt werden. Abweichend davon wird - wenn in den Fest- +preisangeboten keine Preisinformation geliefert wird (z.B. bei einigen Daueremis- +sionen des Bundes) - der Indikator ,,MAKT" eingestellt. + +. B2:70C: Qualifier ,,SKDE" (Depotschlüssel) darf nicht belegt werden + +. B2:70C: Qualifier ,INCE" (Incentive-Merkmal) darf nicht belegt werden + + +#### Festpreisangebotsnummer + +Hier ist die Nummer des jeweiligen Angebotes anzugeben, sofern die Order +für ein Festpreisangebot gilt. + + +#### Verrechnungskonto + +Geldkonto; Dieses muss identisch mit dem Feld B2:97A:, Qualifier ,CASH", +sein. + + +#### b) Kreditinstitutsrückmeldung + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Festpreisordereinreichung bestätigen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIFPO
Bezugssegment:HKFPO
Version:2
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Erneutes Senden erforderlich1DEjn#M1
3Auftragsidentifikati- on1DEan.99O1
4Ordernummer1DEan..99O1
5Ordernummer Split- ting1DEan..99O1
6Wertpapierordersta- tus2DEcode..2O10-11
7Auftragsbezogene Informationen1DEtxt..
2048		O1
8Ausführungsanzei- ge1DEbin..C1O: Auftrag wurde ausge- führt bzw. teilausgeführt N: sonst
9Wertpapierabrech- nung1DEbin..C1O: Auftrag wurde abgerech- net
N: sonst
10Wichtige Informati- onen2DEGO99
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 190Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Wertpapiere
+ + +## . Belegungsrichtlinien + +siehe VII.4.1.2 ,,Wertpapierorder“ + + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag zur Ausführung vorgemerkt
0010Auftrag zur Ausführung angenommen
9210Auftrag abgelehnt, da Festpreisangebot unbekannt
+ + +## c) Bankparameterdaten + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Festpreisorder Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIFPOS
Bezugssegment:HKVVB
Version:2
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Fest- preisorder2DEGM1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Wertpapiere
Geschäftsvorfälle		Stand: 07.08.2015Seite: 191
+ + +## C.4.5.2Neuemissionen + +Die nachfolgend beschriebenen Geschäftsvorfälle beziehen sich in erster Linie auf +Aktienemissionen als Kommissionsgeschäft, d.h. nicht primär Rentenemissionen +etc. + + +### C.4.5.2.1 Neuemissionen anzeigen + + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +## a) Kundenauftrag + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Liste Neuemissionen anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKNEA
Bezugssegment:-
Version:2
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Depot3DEGktv#O1
3Filter Neuemissio- nen1DEGO1
4Maximale Anzahl Einträge1DEnum..4O1>0
5Aufsetzpunkt1DEan..35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +## . Belegungsrichtlinien + + +### Filter Neuemissionen + +Der Kunde kann hiermit die gewünschten Emissionen einschränken. Wird +das Feld nicht belegt, kann das Kreditinstitut selbst entscheiden, welche +Emissionen dem Kunden angezeigt werden. Die zulässigen Werte kann das +Kreditinstitut mit Hilfe der Bankparameterdaten einschränken. + + +## b) Kreditinstitutsrückmeldung + + +## . Beschreibung + +Für jede Emission wird ein Segment zurückgemeldet. + + +![](figures/211.1) + + +Da zum einen die Kreditinstitute die Vielfalt der angebotenen Felder +unterschiedlich nutzen werden und zum anderen Emissionen selbst +strukturell sehr unterschiedlich sein können, wird Kundenprodukten +empfohlen, die nicht belegten Felder auszublenden, um die Über- +sichtlichkeit für den Kunden zu erhöhen. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
192		Stand:
07.08.2015		Kapitel: Geschäftsvorfälle
Abschnitt: Wertpapiere
+ + +Die einzelnen Datensätze sollten anhand der Zeichnungsfrist sor- +tiert werden. + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Liste Neuemissionen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HINEA
Bezugssegment:HKNEA
Version:2
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Wertpapierreferenz2DEGC1M: „Zeichnung möglich“ = J O: sonst
3Wertpapierbezeich- nung2DEan.99O1
4Emissionsstatus2DEcode1O11, 2, 3, 4
5Zeichnung möglich1DEjn#M1
6Emissionswährung1DEcur#O1
7Zeichnungsverfah- ren1DEcode1O11, 2, 3
8Incentive-Merkmal zulässig1DEjn#M1
9Zeichnungserläute- rung1DEtxt.200O1
10Branche1DEan..35O1
11Risikoklasse des Wertpapiers1DEan..2O1
12Emissionspreis1DEGbtg#O1
13Emissionspreis, Er- läuterung1DEtxt..80O1
14Wertpapierart, Text1DEan.99O1
15Zeichnungsfrist von1DEGtsp#O1
16Zeichnungsfrist bis1DEGtsp#O1
17Zeichnungsfrist, Er- läuterung1DEtxt.80O1
18Early-Order-Frist bis1DEGtsp#O1
19Early-Order-Frist bis, Erläuterung1DEtxt..80O1
20Erster Handelstag1DEdat#O1
21Erster Handelstag, Erläuterung1DEtxt..80O1
22Emissionsvolumen1DEan..50O1
23Greenshoe1DEan.50O1
24Einheit der Effek- tennotiz2DEcode1O11, 2, 3, 4, 9
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:GeschäftsvorfälleStand:Seite:
Abschnitt:Wertpapiere07.08.2015193
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
25Preisspanne von3DEGbtg#O1
26Preisspanne bis3DEGbtg#O1
27Preisspanne, Erläu- terung1DEtxt..80O1
28Mindestzeichnung, Stück1DEwrt.. 15O1
29Mindestzeichnung. Betrag3DEGbtg#O1
30Zulässige Li- mitschritte1DEwrt..15O1
31Konsortialführer1DEtxt.200O1
32Angaben zur Wert- stellung1DEan..35O1
33Weitere Zeich- nungsinformationen1DEtxt.. 2048O1
34Besondere Hinwei- se1DEtxt.. 200O1
35Web-Link1DEan.256O1
36Börsenplatzinfor- mation3DEGO99
+ + +## . Belegungsrichtlinien + + +### Wertpapierreferenz + +Es ist die eindeutige Referenznummer einzustellen, unter der das Wertpapier +gezeichnet werden kann. Falls noch keine allgemeingültige Referenz (WKN +oder ISIN) vergeben wurde, kann auch eine institutsinterne Referenz (Code +,3") angegeben werden. Die Belegung kann unterbleiben, falls es sich ledig- +lich um eine Ankündigung handelt und aus diesem Grund noch keine Wert- +papierreferenz verfügbar ist. + + +### Emissionswährung + +Die Emissionswährung sollte insbesondere angegeben werden, wenn kein +Emissionspreis angegeben ist, da ansonsten die Währung der Emission +nicht ermittelbar ist. + + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
3010Es liegen zur Zeit keine Neuemissionen vor
+ + +### c) Bankparameterdaten + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Liste Neuemissionen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HINEAS
Bezugssegment:HKVVB
Version:2
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
194		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Wertpapiere
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Liste Neuemissionen1DEGM1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Geschäftsvorfälle WertpapiereStand: 07.08.2015Seite: 195
+ + +#### C.4.5.2.2 Neuemission zeichnen + +Es sollte nur die Zeichnung derjenigen Emissionen möglich sein, die der Kunde uch +über den Auftrag „Liste Neuemissionen“ abrufen kann. + +Die Änderung einer eingereichten Zeichnung ist nicht möglich. Die Streichung er- +folgt über den Geschäftsvorfall ,,Orderstreichung". Informationen über den Status +seiner Zeichnung kann der Kunde über den Geschäftsvorfall „Orderstatus“ abrufen. + + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +## a) Kundenauftrag + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
. Format
Name:Neuemission zeichnen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKNEZ
Bezugssegment:-
Version:2
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Depot3DEGktv#M1
3Auftragsidentifikati- on1DEan.99O1
4Ordernummer1DEan.99O1
5Wertpapierorder1DEbin..O1
6Begünstigter1DEGaddr#C1O: „Begünstigter möglich“ (BPD) = J" N: sonst
7Geburtsdatum Be- günstigter1DEdat#C1O: „Begünstigter“ belegt N: sonst
8Verrechnungskonto3DEGktv#C1M: ,Verrechnungskonto verpflichtend“ (BPD) = ,J“ O: sonst
9Referenz auf wich- tige Informationen2DEGC1..99M: ,Wichtige Informationen verpflichtend“ (BPD) = „J“ und wichtige Informationen liegen vor N: sonst
+ + +## . Belegungsrichtlinien + +zu den nicht aufgeführten Feldern siehe Kap. C.4.1.2 a) Wertpapierorder + + +## Wertpapierorder + +Die Order ist im Format MT 502 in Version ,,SRG 2002" (s. [Datenformate]) +einzustellen. Es gelten die folgenden abweichenden Belegungsvorschriften: + +In Feld A:23G" darf nicht ,/COPY" gesendet werden. + + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
196		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Wertpapiere
+ + +. A:22F: Das Feld ist mit dem Wert ,:TRTR/ZEKR/SUBS“ zu belegen. + +. B:94B: Im Feld ,,Ort" ist ,OTCO" anzugeben. + +. B1:90a: Als Qualifier ist nur ,,LIMI" zugelassen. Falls der Auftrag nicht limi- +tiert wird, ist die Subfolge B1 nicht zu senden. + +. B:22H:, Qualifier ,,BUSE" (Indikator für Kauf/Verkauf) muss mit ,,BUYI" be- +legt sein + +. B:22F:, Qualifier ,,TOOR" (Indikator für Art des Limits): Es sind nur die In- +dikatoren ,,MAKT" und ,LMTO“ zulässig. + +. B:22F:, Qualifier ,TOOR" (Sonderbedingungen) darf nicht belegt werden + +. B:22F:, Qualifier ,,TILI" (Indikator für Zeitlimit) darf nur mit ,GTCA" belegt +werden + +. B:98A: (Verfallsdatum der Order) darf nicht belegt werden + +. B2:70C: Qualifier ,,SKDE" (Depotschlüssel) darf nicht belegt werden + +. B2:70C: Qualifier ,INCE" (Incentive-Merkmal) kann belegt werden, sofern +dies im Feld ,,Incentive-Merkmal zulässig“ Im Segment „Liste Neuemissio- +nen" erlaubt ist + + +## Verrechnungskonto + +Geldkonto; Dieses muss identisch mit dem Feld B2:97A:, Qualifier „CASH“, +sein. + + +## Referenz auf wichtige Informationen + +Damit der Kunde vor der Zeichnung auf aktuelle Marktrisiken hingewiesen +werden kann, kann das Kreditinstitut analog zum Geschäftsvorfall „Wert- +papierorder" den vorherigen Abruf wichtiger Informationen (s. Kap. C.4.1.1) +fordern. + +Hier kann z.B. auch eine eigene Kategorie für Zeichnungsinformationen ein- +gerichtet werden. + + +## b) Kreditinstitutsrückmeldung + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Einreichung Zeichnung bestätigen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HINEZ
Bezugssegment:HKNEZ
Version:2
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle WertpapiereStand: 07.08.2015Seite: 197
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Erneutes Senden erforderlich1DEjn#M1
3Auftragsidentifikati- on1DEan..99O1
4Ordernummer1DEan.99O1
5Ordernummer Split- ting1DEan.99O1
6Wertpapierordersta- tus2DEcode..2O10-11
7Auftragsbezogene Informationen1DEtxt.. 2048O1
8Wichtige Informati- onen2DEGO99
+ + +## . Belegungsrichtlinien + +siehe Kap. C.4.1.2 b) Wertpapierorder. + + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
+ + +## c) Bankparameterdaten + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Neuemission zeichnen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HINEZS
Bezugssegment:HKVVB
Version:2
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Neu- emission zeichnen2DEGM1
+ + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Geschäftsvorfälle Zahlungsverkehr AuslandStand: 07.08.2015Seite: 199
+ + +## C.5 Zahlungsverkehr Ausland + +In den Instituten der deutschen Kreditwirtschaft werden im Euro- und Auslandszah- +lungsverkehr aktuell die Geschäftsvorfälle + +. „HKAUB“ als Auslandsüberweisung mit und ohne Meldeteil sowie als EU- +Standardüberweisung, + +. „HKAOM“ als Auslandsüberweisung ohne Meldeteil sowie als EU-Standard- +überweisung und + +• „HKSTP“ nur für die EU-Standardüberweisung unterstützt, welcher jedoch durch +die SEPA-Einzelüberweisung ,,HKCCS“ abgelöst wird. + +In der DK wurde erkannt, dass es aus Gründen der Multibankfähigkeit nicht zielfüh- +rend ist, weitere Geschäftsvorfälle, die für den Auslandszahlungsverkehr spezifiziert +werden sollen (z. B. terminierte Auslandsüberweisungen und Auslandsüberweisung +als Dauerauftrag), sowohl als Fremdformat (DTAZV) als auch als Eigenformat +(FinTS) bereitzustellen. Daher besteht das Ziel, den Auslandszahlungsverkehr mit- +telfristig auf ein einheitliches Format zu konsolidieren. + +Aus diesem Grunde werden für den Auslandszahlungsverkehr strategisch nur noch +Fremdformate, wie aktuell das Datensatzformat ,,DTAZV" verwendet. Somit werden +zukünftig nur noch der Geschäftsvorfall „HKAUB“, der bereits die Auslandsüberwei- +sung mit und ohne Meldeteil abdeckt, und der „HKEUE“ für die Euro-Eilüberweisung +unterstützt werden. + +Der während einer Übergangsphase noch gültige Geschäftsvorfall ,,HKAOM" wird - +abgesehen von gesetzlichen Anpassungen - nicht mehr im FinTS-Standard weiter +gepflegt werden. Der ,HKESU" und ,,HKSTP" verbleiben aus Dokumentationszwe- +cken im Dokument. + + +## C.5.1 Zahlungsauftrag im Außenwirtschaftsverkehr + + +### C.5.1.1 Segmentversion 6 + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +## a) Kundenauftrag + + +### . Beschreibung + +Der Datenaustausch im Auslandszahlungsverkehr ist durch das DTAZV-Format1 +standardisiert. Das DTAZV-Format ist transparent in ein Datenelement einzustellen. + +Bei Aufträgen, die den Meldepflichtgrenzbetrag überschreiten (derzeit 12.500 Euro), +ist die Meldepflicht an die Deutsche Bundesbank (Meldesätze V und W) zu beach- +ten. Zahlungen in EWWU-Länder sind ebenfalls meldepflichtig. Bei Aufträgen, die +nicht der Meldepflicht unterliegen, können diese Datensätze entfallen. + + +![](figures/219.1) + + +Kundenprodukthersteller sollten zum Test der von ihrem Produkt er- +stellten Meldesätze mit der Deutschen Bundesbank Kontakt auf- + + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
200		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Zahlungsverkehr Ausland
+ + +nehmen. + +Der Umfang der Plausibilitätsprüfung bei Auftragsannahme ist kreditinstitutsspezi- +fisch. Die Prüfung auf vollständige Datenübertragung erfolgt anhand des Z-Satzes. + + +![](figures/220.1) + + +Die Präsentation der Eingabemaske ist Aufgabe des Herstellers des +Kundenprodukts. So kann die Eingabe für den Kunden im Regelfall +auf die unabdingbar notwendigen Eingabefelder begrenzt werden. +Beispielsweise wäre daher auch die Anzeige des Euroüberwei- +sungsformulars als Eingabemaske möglich. Es ist auf jeden Fall da- +rauf zu achten, dass die Eingaben des Kunden vom Kundenprodukt +in das gültige DTAZV-Format konvertiert werden. + +Je nach Geschäftsvorfall sind unterschiedliche Kann- und Muss- +Felder anzugeben. Im T-Satz sind im aktuellen DTAZV-Format fol- +gende Felder Muss-Felder: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Feldnummer: Beschreibung:
1Satzlänge
2Satzart
3BLZ (Auftraggeber)
4aISO-Währungscode
4bKontonummer (Auftraggeber)
10aLänderkennziffer (Empfänger)
10bName (Empfänger/Begünstigter)
13Auftragswährung (Auftraggeber)
14aBetrag (Vorkommastellen)
14bBetrag (Nachkommastellen)
21Kostenverrechnungsschlüssel
22Kennzeichnung der Zahlungsart
+ + +Ebenfalls werden im Rahmen dieser Schnittstelle keine Vorgaben +über die Erzeugung der Meldesätze an die Deutsche Bundesbank +gemacht. Dem Kundenprodukt stehen hier folgende Möglichkeiten +offen: + +• automatische Erzeugung der Meldesätze + +• Hinweis auf Meldepflicht an den Kunden + +• Beschränkung auf nicht-meldepflichtige Auslandsüberweisungen + + +![](figures/220.2) + + +Es gelten die Maßgaben der nationalen Regelungen zur Umsetzung +der EU-Richtlinie 2007/64/EG über Zahlungsdienste. + +Im ,,Gesetz zur Umsetzung der Verbraucherkreditrichtlinie, des zivil- +rechtlichen Teils der Zahlungsdiensterichtlinie sowie zur Neuord- +nung der Vorschriften über das Widerrufs- und Rückgaberecht“ wird +für die Entgeltberechung als Regelfall definiert, dass der auftragge- +bende Kunde alle Kosten selbst trägt (sog. "OUR-Regel"). Abwei- +chende Entgeltvereinbarungen mit dem Auftraggeber sind weiterhin +möglich. Daraus ergibt sich, dass der Kunde bei der Auftragsertei- +lung per Homebanking explizit erklären muss, ob alle Gebühren zu + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:GeschäftsvorfälleStand:Seite:
Abschnitt:Zahlungsverkehr Ausland07.08.2015201
+ + +Lasten des Auftraggebers oder alle Gebühren zu Lasten des Emp- +fängers gehen oder ob eine Gebührenteilung erfolgen soll. Macht +der Kunde keine Angaben, so ist die OUR-Regelung anzuwenden. + +Die Kundensoftware sollte sicherstellen, dass der Kunde zu einer +eindeutigen Weisung der von ihm gewünschten Entgeltverteilung +aufgefordert wird und das Feld T21 des DTAZV-Datensatzes ent- +sprechend belegen. + +Bei EU- und Auslandsüberweisungen ist - sofern keine Währungs- +konvertierung notwendig ist - im Feld 21 "Entgeltregelung" des +DTAZV-Formates nur die Option "00" zugelassen. In diesem Fall +dürfen dem Kunden im Rahmen der Benutzerführung keine Aus- +wahlmöglichkeiten angeboten werden. + + +![](figures/221.1) + + +Ab dem 1.7.2013 entfällt die Weiterleitung der Z4-Meldung über die +Hausbank des Meldpfichtigen und muss direkt vom Meldepflichtich- +tigen bei der Bundesbank eingereicht werden. Kreditinstitutsseitig +wird die Zahlung zwar ausgeführt, die Meldung jedoch gelöscht. Der +Kunde wird dabei durch den Rückmeldecode 3710 informiert, dass +er die Meldevorschriften beachten muss. Auskünfte gibt die Bun- +desbank unter [www.Bundesbank.de](http://www.bundesbank.de/) ->Meldewesen -> Außenwirt- +schaft + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Auslandsüberweisung
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKAUB
Bezugssegment:-
Version:6
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung Auftraggeber2DEGktv#M1
3DTAZV-Datensatz1DEbin. .M1
+ + +## . Belegungsrichtlinien + + +## Kontoverbindung Auftraggeber + +Die Kontoverbindung muss mit der Auftraggeberkontoverbindung in Feld T3 +und T4b übereinstimmen. + + +## DTAZV-Datensatz + +Datensatz gemäß Spezifikation in [Datenformate] in Version „gültig ab +01.07.2003“ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
202		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Zahlungsverkehr Ausland
+ + +![](figures/222.1) + + +Hinsichtlich etwaiger Festlegung, die nicht das eigentliche übertrage- +ne Datenformat betreffen, sondern aus der Anpassung des Rahmen- +werks an gesetzliche Vorgaben resultieren gelten, die Vorgaben des +DTAZV-Formats gemäß Spezifikation in (Datenformate) in Version +"gültig ab 31.10.2009. + + +## b) Kreditinstitutsrückmeldung + + +### . Beschreibung + +Es werden keine Datensegmente zurückgemeldet. + +◆ Ausgewählte Beispiele für Rückmeldungscodes + +Es gelten die Rückmeldungscodes der Einzelüberweisung. Zusätzlich gelten: + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
9210Ungültiges Format
+ + +## c) Bankparameterdaten + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Auslandsüberweisung Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIAUBS
Bezugssegment:HKVVB
Version:6
Sender:Kreditinstitut
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:GeschäftsvorfälleStand:Seite:
Abschnitt:Zahlungsverkehr Ausland07.08.2015203
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Aus- landsüberweisung1DEGM1
+ + +## C.5.1.2 Segmentversion 7 + +Realisierung Bank: +optional + +Realisierung Kunde: optional + + +## a) Kundenauftrag + + +### . Beschreibung + +Der Datenaustausch im Auslandszahlungsverkehr ist durch das DTAZV-Format2 +standardisiert. Das DTAZV-Format ist transparent in ein Datenelement einzustellen. + +Bei Aufträgen, die den Meldepflichtgrenzbetrag überschreiten (derzeit 12.500 Euro), +ist die Meldepflicht an die Deutsche Bundesbank (Meldesätze V und W) zu beach- +ten. Zahlungen in EWWU-Länder sind ebenfalls meldepflichtig. Bei Aufträgen, die +nicht der Meldepflicht unterliegen, können diese Datensätze entfallen. + + +![](figures/223.1) + + +Kundenprodukthersteller sollten zum Test der von ihrem Produkt er- +stellten Meldesätze mit der Deutschen Bundesbank Kontakt auf- +nehmen + +Der Umfang der Plausibilitätsprüfung bei Auftragsannahme ist kreditinstitutsspezi- +fisch. Die Prüfung auf vollständige Datenübertragung erfolgt anhand des Z-Satzes. + + +![](figures/223.2) + + +Die Präsentation der Eingabemaske ist Aufgabe des Herstellers des +Kundenprodukts. So kann die Eingabe für den Kunden im Regelfall +auf die unabdingbar notwendigen Eingabefelder begrenzt werden. +Beispielsweise wäre daher auch die Anzeige des Euroüberwei- +sungsformulars als Eingabemaske möglich. Es ist auf jeden Fall da- +rauf zu achten, dass die Eingaben des Kunden vom Kundenprodukt +in das gültige DTAZV-Format konvertiert werden. + +Je nach Geschäftsvorfall sind unterschiedliche Kann- und Muss- +Felder anzugeben. Im T-Satz sind im aktuellen DTAZV-Format fol- +gende Felder Muss-Felder: + + + + + + + + + + + + + + + + + + + + + + + +
Feldnummer:Beschreibung:
1Satzlänge
2Satzart
3BLZ (Auftraggeber)
4aISO-Währungscode
+ + + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
204		Stand:
07.08.2015		Kapitel: Geschäftsvorfälle
Abschnitt: Zahlungsverkehr Ausland
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
4bKontonummer (Auftraggeber)
10aLänderkennziffer (Empfänger)
10bName (Empfänger/Begünstigter)
13Auftragswährung (Auftraggeber)
14aBetrag (Vorkommastellen)
14bBetrag (Nachkommastellen)
21Kostenverrechnungsschlüssel
22Kennzeichnung der Zahlungsart
Ebenfalls werden im Rahmen dieser Schnittstelle keine Vorgaben über die Erzeugung der Meldesätze an die Deutsche Bundesbank gemacht. Dem Kundenprodukt stehen hier folgende Möglichkeiten offen:
• automatische
• Hinweis		Erzeugung der Meldesätze
auf Meldepflicht an den Kunden
+ + +• Beschränkung auf nicht-meldepflichtige Auslandsüberweisungen + + +![](figures/224.1) + + +# Es gelten die Maßgaben der nationalen Regelungen zur Umsetzung der EU-Richtlinie 2007/64/EG über Zahlungsdienste. + +Im ,,Gesetz zur Umsetzung der Verbraucherkreditrichtlinie, des zivil- +rechtlichen Teils der Zahlungsdiensterichtlinie sowie zur Neuord- +nung der Vorschriften über das Widerrufs- und Rückgaberecht“ wird +für die Entgeltberechung als Regelfall definiert, dass der auftragge- +bende Kunde alle Kosten selbst trägt (sog. "OUR-Regel"). Abwei- +chende Entgeltvereinbarungen mit dem Auftraggeber sind weiterhin +möglich. Daraus ergibt sich, dass der Kunde bei der Auftragsertei- +lung per Homebanking explizit erklären muss, ob alle Gebühren zu +Lasten des Auftraggebers oder alle Gebühren zu Lasten des Emp- +fängers gehen oder ob eine Gebührenteilung erfolgen soll. Macht +der Kunde keine Angaben, so ist die OUR-Regelung anzuwenden. + +Die Kundensoftware sollte sicherstellen, dass der Kunde zu einer +eindeutigen Weisung der von ihm gewünschten Entgeltverteilung +aufgefordert wird und das Feld T21 des DTAZV-Datensatzes ent- +sprechend belegen. + +Bei EU- und Auslandsüberweisungen ist - sofern keine Währungs- +konvertierung notwendig ist - im Feld 21 "Entgeltregelung" des +DTAZV-Formates nur die Option "00" zugelassen. In diesem Fall +dürfen dem Kunden im Rahmen der Benutzerführung keine Aus- +wahlmöglichkeiten angeboten werden. + + +![](figures/224.2) + + +Ab dem 1.7.2013 entfällt die Weiterleitung der Z4-Meldung über die +Hausbank des Meldpfichtigen und muss direkt vom Meldepflichtich- +tigen bei der Bundesbank eingereicht werden. Kreditinstitutsseitig +wird die Zahlung zwar ausgeführt, die Meldung jedoch gelöscht. Der +Kunde wird dabei durch den Rückmeldecode 3710 informiert, dass +er die Meldevorschriften beachten muss. Auskünfte gibt die Bun- + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:GeschäftsvorfälleStand:Seite:
Abschnitt:Zahlungsverkehr Ausland07.08.2015205
+ + +desbank unter [www.Bundesbank.de](http://www.bundesbank.de/) ->Meldewesen -> Außenwirt- +schaft + + +# . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Auslandsüberweisung
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKAUB
Bezugssegment:-
Version:7
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung Auftraggeber2DEGktv#M1
3DTAZV-Datensatz1DEbin..M1
+ + +# . Belegungsrichtlinien + + +## Kontoverbindung Auftraggeber + +Die Kontoverbindung muss mit der Auftraggeberkontoverbindung in Feld T3 +und T4b übereinstimmen. + + +## DTAZV-Datensatz + +Datensatz gemäß Spezifikation in [Datenformate] in Version „gültig ab +01.05.2004“ + + +![](figures/225.1) + + +Hinsichtlich etwaiger Festlegung, die nicht das eigentliche übertrage- +ne Datenformat betreffen, sondern aus der Anpassung des Rahmen- +werks an gesetzliche Vorgaben resultieren gelten, die Vorgaben des +DTAZV-Formats gemäß Spezifikation in (Datenformate) in Version +"gültig ab 31.10.2009. + + +### b) Kreditinstitutsrückmeldung + +. Beschreibung + +Es werden keine Datensegmente zurückgemeldet. + +◆ Ausgewählte Beispiele für Rückmeldungscodes + +Es gelten die Rückmeldungscodes der Einzelüberweisung. Zusätzlich gelten: +Code Beispiel für Rückmeldungstext + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
206		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Zahlungsverkehr Ausland
+ + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
9210Ungültiges Format
+ + +# c) Bankparameterdaten + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Auslandsüberweisung Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIAUBS
Bezugssegment:HKVVB
Version:7
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Aus- landsüberweisung1DEGM1
+ + +# C.5.1.3Segmentversion 8 + +Realisierung Bank: +optional + +Realisierung Kunde: optional + + +# a) Kundenauftrag + + +## . Beschreibung + +Der Datenaustausch im Auslandszahlungsverkehr ist durch das DTAZV-Format3 +standardisiert. Das DTAZV-Format ist transparent in ein Datenelement einzustellen. + +Bei Aufträgen, die den Meldepflichtgrenzbetrag überschreiten, ist die Meldepflicht an +die Deutsche Bundesbank zu beachten. Zahlungen in EWWU-Länder sind ebenfalls +meldepflichtig. Bei Aufträgen, die nicht der Meldepflicht unterliegen, können diese +Datensätze entfallen. + + +![](figures/226.1) + + +Kundenprodukthersteller sollten zum Test der von ihrem Produkt er- +stellten Meldesätze mit der Deutschen Bundesbank Kontakt auf- +nehmen. + +Der Umfang der Plausibilitätsprüfung bei Auftragsannahme ist kreditinstitutsspezi- +fisch. Die Prüfung auf vollständige Datenübertragung erfolgt anhand des Z-Satzes. + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:GeschäftsvorfälleStand:Seite:
Abschnitt:Zahlungsverkehr Ausland07.08.2015207
+ + +![](figures/227.1) + + +Die Präsentation der Eingabemaske ist Aufgabe des Herstellers des +Kundenprodukts. So kann die Eingabe für den Kunden im Regelfall +auf die unabdingbar notwendigen Eingabefelder begrenzt werden. +Beispielsweise wäre daher auch die Anzeige des Euroüberwei- +sungsformulars als Eingabemaske möglich. Es ist auf jeden Fall da- +rauf zu achten, dass die Eingaben des Kunden vom Kundenprodukt +in das gültige DTAZV-Format konvertiert werden. + +Ebenfalls werden im Rahmen dieser Schnittstelle keine Vorgaben +über die Erzeugung der Meldesätze an die Deutsche Bundesbank +gemacht. Dem Kundenprodukt stehen hier folgende Möglichkeiten +offen: + +• automatische Erzeugung der Meldesätze + +• Hinweis auf Meldepflicht an den Kunden + +• Beschränkung auf nicht-meldepflichtige Auslandsüberweisungen + + +![](figures/227.2) + + +Der Kunde muss bei Verwendung des Geschäftsvorfalls als EU- +Standardüberweisung (Zahlungsart 13) darauf hingewiesen werden, dass +er bei Überschreitung der Meldegrenze von derzeit 12.500,- EUR eine +Meldung an die Bundesbank machen muss. + +Ein Meldeteil darf mit Zahlungsart 13 nicht gesendet werden. Soll ein +Meldeteil gesendet werden, ist die Zahlungsart 00 zu verwenden. + +Für zukünftige Versionen des DTAZV-Handbuches gelten die dort be- +schriebenen Vorgaben. + + +![](figures/227.3) + + +### Es gelten die Maßgaben der nationalen Regelungen zur Umsetzung der EU-Richtlinie 2007/64/EG über Zahlungsdienste. + +Im „Gesetz zur Umsetzung der Verbraucherkreditrichtlinie, des zivil- +rechtlichen Teils der Zahlungsdiensterichtlinie sowie zur Neuord- +nung der Vorschriften über das Widerrufs- und Rückgaberecht“ wird +für die Entgeltberechung als Regelfall definiert, dass der auftragge- +bende Kunde alle Kosten selbst trägt (sog. "OUR-Regel"). Abwei- +chende Entgeltvereinbarungen mit dem Auftraggeber sind weiterhin +möglich. Daraus ergibt sich, dass der Kunde bei der Auftragsertei- +lung per Homebanking explizit erklären muss, ob alle Gebühren zu +Lasten des Auftraggebers oder alle Gebühren zu Lasten des Emp- +fängers gehen oder ob eine Gebührenteilung erfolgen soll. Macht +der Kunde keine Angaben, so ist die OUR-Regelung anzuwenden. + +Die Kundensoftware sollte sicherstellen, dass der Kunde zu einer +eindeutigen Weisung der von ihm gewünschten Entgeltverteilung +aufgefordert wird und das Feld T21 des DTAZV-Datensatzes ent- +sprechend belegen. + +Bei EU- und Auslandsüberweisungen ist - sofern keine Währungs- + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
208		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Zahlungsverkehr Ausland
+ + +konvertierung notwendig ist - im Feld 21 "Entgeltregelung" des +DTAZV-Formates nur die Option "00" zugelassen. In diesem Fall +dürfen dem Kunden im Rahmen der Benutzerführung keine Aus- +wahlmöglichkeiten angeboten werden. + + +![](figures/228.1) + + +Ab dem 1.7.2013 entfällt die Weiterleitung der Z4-Meldung über die +Hausbank des Meldpfichtigen und muss direkt vom Meldepflichtich- +tigen bei der Bundesbank eingereicht werden. Kreditinstitutsseitig +wird die Zahlung zwar ausgeführt, die Meldung jedoch gelöscht. Der +Kunde wird dabei durch den Rückmeldecode 3710 informiert, dass +er die Meldevorschriften beachten muss. Auskünfte gibt die Bun- +desbank unter [www.Bundesbank.de](http://www.bundesbank.de/) ->Meldewesen -> Außenwirt- +schaft + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Auslandsüberweisung
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKAUB
Bezugssegment:-
Version:8
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung Auftraggeber2DEGktv#M1
3DTAZV-Handbuch1DEnum4M1
4DTAZV-Datensatz1DEbin..M1
+ + +## . Belegungsrichtlinien + + +### Kontoverbindung Auftraggeber + +Die Kontoverbindung muss mit der Auftraggeberkontoverbindung in Feld T3 +und T4b übereinstimmen. + + +### DTAZV-Handbuch + +Das dem folgenden DTAZV Datensatz zugrunde liegende Handbuch. Die +Handbuch-Version muss mit einer der in den Bankparameter-Daten vorge- +gebenen Versionen übereinstimmen. + + +### DTAZV-Datensatz + +Datensatz gemäß den Festlegungen der in ,,DTAZV-Handbuch“ übermittelten +DTAZV-Version. + + +![](figures/228.2) + + +Hinsichtlich etwaiger Festlegung, die nicht das eigentliche übertrage- +ne Datenformat betreffen, sondern aus der Anpassung des Rahmen- +werks an gesetzliche Vorgaben resultieren gelten, die Vorgaben des + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:GeschäftsvorfälleStand:Seite:
Abschnitt:Zahlungsverkehr Ausland07.08.2015209
+ + +#### DTAZV-Formats gemäß Spezifikation in (Datenformate) in Version "gültig ab 31.10.2009. + + +##### b) Kreditinstitutsrückmeldung + + +###### . Beschreibung + +Es werden keine Datensegmente zurückgemeldet. + + +###### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + +![](figures/229.1) + + +Bei Überschreitung der Meldegrenzen ist der Kunde auf die Melde- +vorschriften der deutschen Bundesbank hinzuweisen. + +Es gelten die Rückmeldungscodes der Einzelüberweisung. Zusätzlich gelten: + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
3710Betrag liegt über Meldegrenze (12.500 EUR). Beachten Sie die Meldevorschriften.
9210Ungültiges Format
+ + +###### c) Bankparameterdaten + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Auslandsüberweisung Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIAUBS
Bezugssegment:HKVVB
Version:8
Sender:Kreditinstitut
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 210Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Zahlungsverkehr Ausland
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Aus- landsüberweisung2DEGM1
+ + +##### C.5.1.4Segmentversion 89 + +Realisierung Bank: + +optional + +Realisierung Kunde: optional + + +##### a) Kundenauftrag + + +###### . Beschreibung + +Der Datenaustausch im Auslandszahlungsverkehr ist durch das DTAZV-Format4 +standardisiert. Das DTAZV-Format ist transparent in ein Datenelement einzustellen. + +Bei Aufträgen, die den Meldepflichtgrenzbetrag überschreiten, ist die Meldepflicht an +die Deutsche Bundesbank zu beachten. Zahlungen in EWWU-Länder sind ebenfalls +meldepflichtig. Bei Aufträgen, die nicht der Meldepflicht unterliegen, können diese +Datensätze entfallen. + + +![](figures/230.1) + + +Kundenprodukthersteller sollten zum Test der von ihrem Produkt er- +stellten Meldesätze mit der Deutschen Bundesbank Kontakt auf- +nehmen. + +Der Umfang der Plausibilitätsprüfung bei Auftragsannahme ist kreditinstitutsspezi- +fisch. Die Prüfung auf vollständige Datenübertragung erfolgt anhand des Z-Satzes. + + +![](figures/230.2) + + +Die Präsentation der Eingabemaske ist Aufgabe des Herstellers des +Kundenprodukts. So kann die Eingabe für den Kunden im Regelfall +auf die unabdingbar notwendigen Eingabefelder begrenzt werden. +Beispielsweise wäre daher auch die Anzeige des Euroüberwei- +sungsformulars als Eingabemaske möglich. Es ist auf jeden Fall da- +rauf zu achten, dass die Eingaben des Kunden vom Kundenprodukt +in das gültige DTAZV-Format konvertiert werden. + +Ebenfalls werden im Rahmen dieser Schnittstelle keine Vorgaben +über die Erzeugung der Meldesätze an die Deutsche Bundesbank +gemacht. Dem Kundenprodukt stehen hier folgende Möglichkeiten +offen: + +• automatische Erzeugung der Meldesätze + +. Hinweis auf Meldepflicht an den Kunden + +• Beschränkung auf nicht-meldepflichtige Auslandsüberweisungen + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Geschäftsvorfälle Zahlungsverkehr AuslandStand: 07.08.2015Seite: 211
+ + +![](figures/231.1) + + +Der Kunde muss bei Verwendung des Geschäftsvorfalls als EU- +Standardüberweisung (Zahlungsart 13) darauf hingewiesen werden, dass +er bei Überschreitung der Meldegrenze von derzeit 12.500,- EUR eine +Meldung an die Bundesbank machen muss. + +Ein Meldeteil darf mit Zahlungsart 13 nicht gesendet werden. Soll ein +Meldeteil gesendet werden, ist die Zahlungsart 00 zu verwenden. + +Für zukünftige Versionen des DTAZV-Handbuches gelten die dort be- +schriebenen Vorgaben. + + +![](figures/231.2) + + +Es gelten die Maßgaben der nationalen Regelungen zur Umsetzung +der EU-Richtlinie 2007/64/EG über Zahlungsdienste. + +Im ,,Gesetz zur Umsetzung der Verbraucherkreditrichtlinie, des zivil- +rechtlichen Teils der Zahlungsdiensterichtlinie sowie zur Neuord- +nung der Vorschriften über das Widerrufs- und Rückgaberecht“ wird +für die Entgeltberechung als Regelfall definiert, dass der auftragge- +bende Kunde alle Kosten selbst trägt (sog. "OUR-Regel"). Abwei- +chende Entgeltvereinbarungen mit dem Auftraggeber sind weiterhin +möglich. Daraus ergibt sich, dass der Kunde bei der Auftragsertei- +lung per Homebanking explizit erklären muss, ob alle Gebühren zu +Lasten des Auftraggebers oder alle Gebühren zu Lasten des Emp- +fängers gehen oder ob eine Gebührenteilung erfolgen soll. Macht +der Kunde keine Angaben, so ist die OUR-Regelung anzuwenden. + +Die Kundensoftware sollte sicherstellen, dass der Kunde zu einer +eindeutigen Weisung der von ihm gewünschten Entgeltverteilung +aufgefordert wird und das Feld T21 des DTAZV-Datensatzes ent- +sprechend belegen. + +Bei EU- und Auslandsüberweisungen ist - sofern keine Währungs- +konvertierung notwendig ist - im Feld 21 "Entgeltregelung" des +DTAZV-Formates nur die Option "00" zugelassen. In diesem Fall +dürfen dem Kunden im Rahmen der Benutzerführung keine Aus- +wahlmöglichkeiten angeboten werden. + + +![](figures/231.3) + + +Ab Seit dem 1.7.2013 entfällt die Weiterleitung der Z4-Meldung über +die Hausbank des Meldpfichtigen und muss direkt vom Melde- +pflichtichtigen bei der Bundesbank eingereicht werden. Kreditinsti- +tutsseitig wird die Zahlung zwar ausgeführt, die Meldung jedoch ge- +löscht. Der Kunde wird dabei durch den Rückmeldecode 3710 in- +formiert, dass er die Meldevorschriften beachten muss. Auskünfte +gibt die Bundesbank unter [www.Bundesbank.de](http://www.bundesbank.de/) ->Meldewesen -> +AuBenwirtschaft + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
212		Stand:
07.08.2015		Kapitel: Geschäftsvorfälle
Abschnitt: Zahlungsverkehr Ausland
+ + +##### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Auslandsüberweisung
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKAUB
Bezugssegment:-
Version:
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung Auftragge berKontoverbindun g Auftragge berKontoverbindun
g international		21DEGkti¥#M1
3DTAZV-Handbuch1DEnum4M1
4DTAZV-Datensatz1DEbin..M1
+ + +##### . Belegungsrichtlinien + + +###### Kontoverbindung Auftraggeberinternational + +Die Kontoverbindung muss mit der Auftraggeberkontoverbindung in Feld T3 +(BLZ) und T4b (Kontonummer) übereinstimmen. Ggf. ist hierfür institutsseitig +eine Konvertierung der IBAN / BIC durchzuführen. + + +###### DTAZV-Handbuch + +Das dem folgenden DTAZV Datensatz zugrunde liegende Handbuch. Die +Handbuch-Version muss mit einer der in den Bankparameter-Daten vorge- +gebenen Versionen übereinstimmen. + + +###### DTAZV-Datensatz + +Datensatz gemäß den Festlegungen der in „DTAZV-Handbuch“ übermittelten +DTAZV-Version. + + +![](figures/232.1) + + +Hinsichtlich etwaiger Festlegung, die nicht das eigentliche übertrage- +ne Datenformat betreffen, sondern aus der Anpassung des Rahmen- +werks an gesetzliche Vorgaben resultieren, gelten die Vorgaben des +DTAZV-Formats gemäß Spezifikation in (Datenformate) in Version +"gültig ab 31.10.2009. + + +# b) Kreditinstitutsrückmeldung + + +## . Beschreibung + +Es werden keine Datensegmente zurückgemeldet. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Geschäftsvorfälle Zahlungsverkehr AuslandStand: 07.08.2015Seite: 213
+ + +# ◆ Ausgewählte Beispiele für Rückmeldungscodes + + +![](figures/233.1) + + +Bei Überschreitung der Meldegrenzen ist der Kunde auf die Melde- +vorschriften der deutschen Bundesbank hinzuweisen. + +Es gelten die Rückmeldungscodes der Einzelüberweisung. Zusätzlich gelten: + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
3710Betrag liegt über Meldegrenze (12.500 EUR). Beachten Sie die Meldevorschriften.
9210Ungültiges Format
+ + +# c) Bankparameterdaten + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Auslandsüberweisung Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIAUBS
Bezugssegment:HKVVB
Version:
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Aus- landsüberweisung2DEGM1
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
214		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Zahlungsverkehr Ausland
+ + +### C.5.2 Euro-STP-Zahlung + + +![](figures/234.1) + + +Dieser Geschäftsvorfall wird nicht mehr zur Umsetzung empfohlen +(siehe C.5), verbleibt aber aus Dokumentationszwecken im Doku- +ment. + + +![](figures/234.2) + + +#### C.5.2.1Segmentversion 1 + +Realisierung Bank: +optional + +Realisierung Kunde: optional + + +# a) Kundenauftrag + + +## . Beschreibung + +Um die Abwicklung des Auslandszahlungsverkehrs in der Euro-Zone zu vereinfa- +chen, hat die Deutsche Bundesbank eine Ergänzung der Belegungsrichtlinien für +den DTAZV-Datensatz veröffentlicht, um STP-Zahlungen5 zu ermöglichen. Voraus- +setzung für die Behandlung einer Zahlung als Euro-STP-Zahlung ist, dass das Ziel- +land zu den für Euro-STP-Zahlungen zulässigen Ländern gehören (s. DTAZV, An- +hang 4). + + +![](figures/234.3) + + +Der Kunde sollte darauf hingewiesen werden, dass der Auftrag u.U. +abgelehnt wird, wenn die für die Ausführung benötigten Anforderun- +gen nicht erfüllt sind. + +Es wird empfohlen, dem Kunden eine spezielle Eingabemaske an- +zubieten, die dem von Kreditinstituten hierfür vorgesehenen Formu- +lar für papierhafte Aufträge nachempfunden ist und nur die erforder- +lichen und zulässigen Angaben enthält. + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Euro-STP-Zahlung
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKSTP
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:GeschäftsvorfälleStand:Seite:
Abschnitt:Zahlungsverkehr Ausland07.08.2015215
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung Auftraggeber2DEGktv#M1
3DTAZV-Datensatz1DEbin..M1
+ + +# . Belegungsrichtlinien + + +## Kontoverbindung Auftraggeber + +Die Bankleitzahl und Kontonummer der Kontoverbindung müssen mit der +Auftraggeberkontoverbindung in Feld T3 und T4b übereinstimmen. + + +## DTAZV-Datensatz + +Datensatz gemäß Spezifikation in [Datenformate] in Version „gültig ab +01.07.2003“ + +In einem DTAZV-STP-Datensatz dürfen nur STP-Zahlungen enthalten sein. +Im Datensatz T gelten folgende besonderen Belegungsrichtlinien: + +· Feld 4a: Nur „EUR“ zulässig + +. Feld 8: Bank Identifier Code (BIC) (=SWIFT-Adresse) ist Pflicht. Institut +muss in einem der Länder gemäß Anhang 4 des DTAZV ansässig sein. + +. Feld 10b: Angabe eines Scheckempfängers nicht möglich + +· Feld 12: Nur IBAN zulässig + +· Feld 13: Nur „EUR“ zulässig + +· Feld 14a: Nur Beträge bis maximal 12.500 EUR zulässig + +. Feld 21: Nur ,,00" zugelassen + +• Feld 22: Nur Zahlungsartschlüssel ,13' aus Anhang 1, DTAZV zulässig + + +![](figures/235.1) + + +Hinsichtlich etwaiger Festlegung, die nicht das eigentliche übertrage- +ne Datenformat betreffen, sondern aus der Anpassung des Rahmen- +werks an gesetzliche Vorgaben resultieren gelten, die Vorgaben des +DTAZV-Formats gemäß Spezifikation in (Datenformate) in Version +"gültig ab 31.10.2009. + + +### b) Kreditinstitutsrückmeldung + + +#### . Beschreibung + +Es werden keine Datensegmente zurückgemeldet. + +◆ Ausgewählte Beispiele für Rückmeldungscodes + +Es gelten die Rückmeldungscodes der Einzelüberweisung. Zusätzlich gelten: + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
9010Auftrag entspricht nicht den STP-Richtlinien
9210Ungültiges Format
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
216		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Zahlungsverkehr Ausland
+ + +### c) Bankparameterdaten + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Euro-STP-Zahlung Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HISTPS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Euro- STP-Zahlung1DEGM1
+ + +## C.5.2.2 Segmentversion 2 + +Realisierung Bank: +optional + +Realisierung Kunde: +optional + + +# a) Kundenauftrag + + +## . Beschreibung + +Um die Abwicklung des Auslandszahlungsverkehrs in der Euro-Zone zu vereinfa- +chen, hat die Deutsche Bundesbank eine Ergänzung der Belegungsrichtlinien für +den DTAZV-Datensatz veröffentlicht, um STP-Zahlungen6 zu ermöglichen. Voraus- +setzung für die Behandlung einer Zahlung als Euro-STP-Zahlung ist, dass das Ziel- +land zu den für Euro-STP-Zahlungen zulässigen Ländern gehören (s. DTAZV, An- +hang 4). + + +![](figures/236.1) + + +Der Kunde sollte darauf hingewiesen werden, dass der Auftrag u.U. +abgelehnt wird, wenn die für die Ausführung benötigten Anforderun- +gen nicht erfüllt sind. + +Es wird empfohlen, dem Kunden eine spezielle Eingabemaske an- +zubieten, die dem von Kreditinstituten hierfür vorgesehenen Formu- +lar für papierhafte Aufträge nachempfunden ist und nur die erforder- +lichen und zulässigen Angaben enthält. + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:GeschäftsvorfälleStand:Seite:
Abschnitt:Zahlungsverkehr Ausland07.08.2015217
+ + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Euro-STP-Zahlung
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKSTP
Bezugssegment:-
Version:2
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung Auftraggeber2DEGktv#M1
3DTAZV-Datensatz1DEbin..M1
+ + +## . Belegungsrichtlinien + + +### Kontoverbindung Auftraggeber + +Die Bankleitzahl und Kontonummer der Kontoverbindung müssen mit der +Auftraggeberkontoverbindung in Feld T3 und T4b übereinstimmen. + + +### DTAZV-Datensatz + +Datensatz gemäß Spezifikation in [Datenformate] in Version „gültig ab +01.05.2004“ + +In einem DTAZV-STP-Datensatz dürfen nur STP-Zahlungen enthalten sein. +Im Datensatz T gelten folgende besonderen Belegungsrichtlinien: + +· Feld 4a: Nur „EUR“ zulässig + +. Feld 8: Bank Identifier Code (BIC) (=SWIFT-Adresse) ist Pflicht. Institut +muss in einem der Länder gemäß Anhang 4 des DTAZV ansässig sein. + +. Feld 10b: Angabe eines Scheckempfängers nicht möglich + +· Feld 12: Nur IBAN zulässig + +· Feld 13: Nur „EUR“ zulässig + +· Feld 14a: Nur Beträge bis maximal 12.500 EUR zulässig + +. Feld 21: Nur ,,00" zugelassen + +• Feld 22: Nur Zahlungsartschlüssel ,13' aus Anhang 1, DTAZV zulässig + + +![](figures/237.1) + + +Hinsichtlich etwaiger Festlegung, die nicht das eigentliche übertrage- +ne Datenformat betreffen, sondern aus der Anpassung des Rahmen- +werks an gesetzliche Vorgaben resultieren gelten, die Vorgaben des +DTAZV-Formats gemäß Spezifikation in (Datenformate) in Version +"gültig ab 31.10.2009. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 218Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Zahlungsverkehr Ausland
+ + +# b) Kreditinstitutsrückmeldung + + +## . Beschreibung + +Es werden keine Datensegmente zurückgemeldet. + + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + +Es gelten die Rückmeldungscodes der Einzelüberweisung. Zusätzlich gelten: + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
9010Auftrag entspricht nicht den STP-Richtlinien
9210Ungültiges Format
+ + +# c) Bankparameterdaten + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Euro-STP-Zahlung Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HISTPS
Bezugssegment:HKVVB
Version:2
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Euro- STP-Zahlung1DEGM1
+ + +### C.5.2.3 Segmentversion 3 + + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +# a) Kundenauftrag + + +## . Beschreibung + +Um die Abwicklung des Auslandszahlungsverkehrs in der Euro-Zone zu vereinfa- +chen, hat die Deutsche Bundesbank eine Ergänzung der Belegungsrichtlinien für +den DTAZV-Datensatz veröffentlicht, um STP-Zahlungen7 zu ermöglichen. Voraus- +setzung für die Behandlung einer Zahlung als Euro-STP-Zahlung ist, dass das Ziel- +land zu den für Euro-STP-Zahlungen zulässigen Ländern gehören (s. DTAZV, An- +hang 4). + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle Zahlungsverkehr AuslandStand: 07.08.2015Seite: 219
+ + +![](figures/239.1) + + +Der Kunde muss darauf hingewiesen werden, dass er bei +Überschreitung der Meldegrenze von derzeit 12.500,- eine Meldung an +die Bundesbank machen muss. Die Adresse zum Download für das Z4- +Formular lautet: +http.//www.bundesbank.de/meldewesen/mw_aussenwirtschaft.php + +Für zukünftige Versionen des DTAZV-Handbuches gelten die dort be- +schriebenen Vorgaben. + + +![](figures/239.2) + + +Der Kunde sollte darauf hingewiesen werden, dass der Auftrag u.U. +abgelehnt wird, wenn die für die Ausführung benötigten Anforderun- +gen nicht erfüllt sind. + +Es wird empfohlen, dem Kunden eine spezielle Eingabemaske an- +zubieten, die dem von Kreditinstituten hierfür vorgesehenen Formu- +lar für papierhafte Aufträge nachempfunden ist und nur die erforder- +lichen und zulässigen Angaben enthält. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
. Format
Name:Euro-STP-Zahlung
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKSTP
Bezugssegment:-
Version:3
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung Auftraggeber2DEGktv#M1
3DTAZV-Handbuch1DEnum4M1
4DTAZV-Datensatz1DEbin. .M1
+ + +## . Belegungsrichtlinien + + +## Kontoverbindung Auftraggeber + +Die Bankleitzahl und Kontonummer der Kontoverbindung müssen mit der Auftrag- +geberkontoverbindung in Feld T3 und T4b übereinstimmen. + + +## DTAZV-Handbuch + +Das dem folgenden DTAZV Datensatz zugrunde liegende Handbuch. Die Hand- +buch-Version muss mit einer der in den Bankparameter-Daten vorgegebenen Versi- +onen übereinstimmen. + + +## DTAZV-Datensatz + +Datensatz gemäß Spezifikation der Festlegungen der in ,,DTAZV-Handbuch“ über- +mittelten DTAZV-Version. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
220		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Zahlungsverkehr Ausland
+ + +In einem DTAZV-STP-Datensatz dürfen nur STP-Zahlungen enthalten sein. + +Im Datensatz T gelten folgende besonderen Belegungsrichtlinien: + +· Feld 4a: Nur „EUR“ zulässig + +. Feld 8: Bank Identifier Code (BIC) (=SWIFT-Adresse) ist Pflicht. Institut +muss in einem der Länder gemäß Anhang 4 des DTAZV ansässig sein. + +. Feld 10b: Angabe eines Scheckempfängers nicht möglich + +· Feld 12: Nur IBAN zulässig + +· Feld 13: Nur „EUR“ zulässig + +· Feld 14a: Nur Beträge bis maximal 50.000 EUR zulässig + +. Feld 21: Nur ,,00" zugelassen + +• Feld 22: Nur Zahlungsartschlüssel ,13' aus Anhang 1, DTAZV zulässig + + +![](figures/240.1) + + +Hinsichtlich etwaiger Festlegung, die nicht das eigentliche übertrage- +ne Datenformat betreffen, sondern aus der Anpassung des Rahmen- +werks an gesetzliche Vorgaben resultieren gelten, die Vorgaben des +DTAZV-Formats gemäß Spezifikation in (Datenformate) in Version +"gültig ab 31.10.2009. + + +# b) Kreditinstitutsrückmeldung + +. Beschreibung + +Es werden keine Datensegmente zurückgemeldet. + +◆ Ausgewählte Beispiele für Rückmeldungscodes + + +![](figures/240.2) + + +Bei Überschreitung der Meldegrenzen ist der Kunde auf die Melde- +vorschriften der deutschen Bundesbank hinzuweisen. + +Es gelten die Rückmeldungscodes der Einzelüberweisung. Zusätzlich gelten: + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
3710Betrag liegt über Meldegrenze (12.500 EUR). Beachten Sie die Meldevorschriften.
9010Auftrag entspricht nicht den STP-Richtlinien
9210Ungültiges Format
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:GeschäftsvorfälleStand:Seite:
Abschnitt:Zahlungsverkehr Ausland07.08.2015221
+ + +## c) Bankparameterdaten + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Euro-STP-Zahlung Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HISTPS
Bezugssegment:HKVVB
Version:3
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Euro- STP-Zahlung2DEGM1
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
222		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Zahlungsverkehr Ausland
+ + +### C.5.3 Auslandsüberweisung ohne Meldeteil + +Auslandsüberweisungen ohne Meldeteil (,,EURO-Zahlungsauftrag") zeichnen sich +dadurch aus, dass die Zahlung nur in bestimmte (i.d.R. europäische) Zielländer er- +folgen darf. Diese Zielländer stellt das Kreditinstitut in die BPD ein. Ferner darf der +zu überweisende Betrag die Meldegrenze an die Deutsche Bundesbank gemäß +AWG in Höhe von derzeit 12.500 Euro bzw. den Gegenwert in Fremdwährung nicht +überschreiten. Eine darüber hinausgehende Verwendung der Auslandsüberweisung +ohne Meldeteil für meldepflichtige Überweisungen von derzeit bis 50.000,- EUR in- +nerhalb der EWWU ist zwar zulässig, allerdings ist dann eine separate Meldung auf +Basis des Z4-Formulars der Bundesbank durch den Kunden vorzunehmen. + + +![](figures/242.1) + + +Der Kunde muss darauf hingewiesen werden, dass er bei +Überschreitung der Meldegrenze von derzeit 12.500,- eine Meldung an +die Bundesbank machen muss. Die Adresse zum Download für das Z4- +Formular lautet: + +http://www.bundesbank.de/meldewesen/mw_aussenwirtschaft.php + +Für Zahlungen in alle anderen Länder sowie für Zahlungen, die den Höchstbetrag +überschreiten, ist der „Zahlungsauftrag im AuBenwirtschaftsverkehr (Z1)" (s. Kap. +C.5.1) zu verwenden. Für Zahlungen innerhalb Deutschlands ist die Einzelüberwei- +sung (Kap. C.1.1.1) zu benutzen. + +Nicht konforme Überweisungen (z.B. Betrag größer als Höchstbetrag) werden zu- +rückgewiesen. + + +![](figures/242.2) + + +Das Kundenprodukt hat vor dem Absenden des Auftrages zu prü- +fen, ob die Voraussetzungen für die Anwendung der Auslandsüber- +weisung ohne Meldeteil vorliegen. + +Falls der Geschäftsvorfall nicht angeboten wird, kann eine derartige +Überweisung auch mittels „Zahlungsauftrag im Außenwirtschafts- +verkehr (Z1)" (s. Kap. C.5.1) eingereicht werden, wobei die Melde- +sätze V und W unterbleiben. + +Das Kundenprodukt sollte die Einhaltung der in den Parametern +mitgeteilten Längenbegrenzungen prüfen. + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +## a) Kundenauftrag + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Auslandsüberweisung ohne Meldeteil
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKAOM
Bezugssegment:-
Version:2
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:GeschäftsvorfälleStand:Seite:
Abschnitt:Zahlungsverkehr Ausland07.08.2015223
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung Auftraggeber2DEGktv#M1
3Auftraggebername, AZV1DEan.140M1
4Kontoverbindung Empfänger3DEGktv#C1M: „IBAN Empfänger“ leer N: sonst
5IBAN Empfänger1DEan..34C1M: „IBAN-Angabe möglich“ (BPD) = ,J" und ,Kontover- bindung Empfänger“ leer N: sonst
6Institutsname Emp- fänger, AZV1DEan.140M1
7Empfängername, AZV1DEan.140M1
8Betrag2DEGbtg#M1
9Kostenträger2DEcode1M11, 2, 3
10Verwendungs- zweck, AZV1DEan.140O1
+ + +## b) Kreditinstitutsrückmeldung + + +### . Format + +Allgemeine Kreditinstitutsnachricht ohne Datensegmente + +◆ Ausgewählte Beispiele für Rückmeldungscodes + + +![](figures/243.1) + + +Bei Überschreitung der Meldegrenzen bei der Verwendung des +Geschäftsvorfalles im EWWU-Zahlungsverkehr ist der Kunde auf +die Meldevorschriften der deutschen Bundesbank hinzuweisen. + +Es gelten die Rückmeldungscodes der Einzelüberweisung. Zusätzlich gelten: + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
3710Betrag liegt über Meldegrenze (12.500 EUR). Beachten Sie die Meldevorschriften.
9210Ungültiges Zielland
9210Ungültiges Format
+ + +### c) Bankparameterdaten + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Auslandsüberweisung ohne Meldeteil Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIAOMS
Bezugssegment:HKVVB
Version:2
Sender:Kreditinstitut
+ + + + + + + + + + + + + + +
Nr.NameVer-TypFor-Län-Sta-An-Restriktionen
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
224		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Zahlungsverkehr Ausland
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
sionmatgetuszahl
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Aus- landsüberweisung ohne Meldeteil2DEGM1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Geschäftsvorfälle Zahlungsverkehr AuslandStand: 07.08.2015Seite: 225
+ + +# C.5.4 EU-Standardüberweisung + + +![](figures/245.1) + + +Dieser Geschäftsvorfall wird nicht mehr zur Umsetzung empfohlen +(siehe C.5), verbleibt aber aus Dokumentationszwecken im Doku- +ment. + + +![](figures/245.2) + + +Dieser Geschäftsvorfall kann alternativ zur Euro-STP-Zahlung (Kap. C.5.2) verwen- +det werden. Im Gegensatz hierzu wird nicht das DTAV-Format, sondern ein dem +Papierformular entsprechendes Eigenformat genutzt. + +Die EU-Standardüberweisung darf nur in bestimmte europäische Zielländer erfol- +gen. Diese können bspw. dem Anhang 4 des DTAZV 2003-Datensatzes entnom- +men werden. Der zu überweisende Betrag darf 12.500 Euro nicht überschreiten. +Auftraggeber und Begünstigter müssen zwingend mit der IBAN identifiziert werden. +Zusätzlich ist der BIC (SWIFT-Code) des Kreditinstituts des Begünstigten anzuge- +ben. Die Auswahl des Kostenträgers ist nicht möglich; es findet immer Kostenteilung +(SHA) statt. + +Zur Abgrenzung der verschiedenen Geschäftsvorfälle im Auslandszahlungsverkehr +soll nachfolgende Abbildung dienen: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ZielländerBetragWährungFormat
Zahlungsauftrag im Außenwirtschaftsver- kehrinternationalunbegrenztbeliebigDTAZV
Auslandsüberweisung ohne MeldeteilEuropa und ggf. weiterebis 12.500 € bzw. Gegenwert in FremdwährungEuro bzw. Währung des Ziellandeswie Formular
Euro-STP-ZahlungEuropabis 12.500 €EuroDTAZV
EU- StandardüberweisungEuropabis 12.500 €Eurowie Formular
+ + +Nicht konforme Überweisungen (z.B. Betrag größer als Höchstbetrag) werden zu- +rückgewiesen. + + +![](figures/245.3) + + +Das Kundenprodukt hat vor dem Absenden des Auftrages zu prü- +fen, ob die Voraussetzungen für die Anwendung der EU- +Standardüberweisung vorliegen. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
226		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Zahlungsverkehr Ausland
+ + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +## a) Kundenauftrag + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:EU-Standardüberweisung
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKESU
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2IBAN Auftraggeber1DEan..34M1
3Auftraggebername, AZV kurz1DEan..27M1
4IBAN Empfänger1DEan..34M1
5BIC Empfän- gerbank1DEan..11M1
6Empfängername, AZV kurz1DEan.35M1
7Betrag2DEGbtg#M1als Währung nur EUR gül- tig;
Betrag <= 12.500 EUR
8Verwendungs- zweck, AZV kurz1DEan.35O2
+ + +## b) Kreditinstitutsrückmeldung + + +### . Beschreibung + +Allgemeine Kreditinstitutsnachricht ohne Datensegmente. + +◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
9210Betrag höher als 12.500 Euro
+ + +### c) Bankparameterdaten + + +#### . Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:GeschäftsvorfälleStand:Seite:
Abschnitt:Zahlungsverkehr Ausland07.08.2015227
+ + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:EU-Standardüberweisung Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIESUS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
228		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Zahlungsverkehr Ausland
+ + +# C.5.5 Euro-Eilüberweisung + + +![](figures/248.1) + + +Die Segmentversion 1 wurde nicht veröffentlicht. + + +![](figures/248.2) + + + + + + + + + + + + + +
RealisierungBank:optional
RealisierungKunde:optional
+ + +## a) Kundenauftrag + + +### . Beschreibung + +Bei Euro-Eilüberweisungen ersetzt der Datensatz T-EUE den Datensatz T (s. +[DTAZV]). + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Euro-Eilüberweisung
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKEUE
Bezugssegment:-
Version:2
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung Auftraggeber2DEGktv#M1
3DTAZV-Handbuch1DEnum4M1
4DTAZV-Datensatz1DEbin. .M1
+ + +### . Belegungsrichtlinien + + +### Kontoverbindung Auftraggeber + +Die Kontoverbindung muss mit der Auftraggeberkontoverbindung in Feld T3 und +T4b übereinstimmen. + + +### DTAZV-Datensatz + +Datensatz gemäß Spezifikation der Festlegungen der in ,,DTAZV-Handbuch“ über- +mittelten DTAZV-Version. + +In einem DTAZV-EUE-Datensatz dürfen nur EUE-Sätze enthalten sein. + +Im Datensatz T gelten folgende besonderen Belegungsrichtlinien: + +· Feld 4a: Nur „EUR“ zulässig + +· Feld 7a: Nur „EUR“ zulässig + +. Feld 8: Bank Identifier Code (BIC) ist Pflicht + +• Feld 9a „Länderkennziffer Bank des Begünstigten“: Nicht zu belegen + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:GeschäftsvorfälleStand:Seite:
Abschnitt:Zahlungsverkehr Ausland07.08.2015229
+ + +. Feld 10b: Angabe eines Scheckempfängers nicht möglich + +· Feld 12: Nur IBAN zulässig + +· Feld 13: Nur „EUR“ zulässig + +. Feld 16, 17, 18, 19: Nur Weisungsschlüssel ,10', ,11' und ,12' aus DTAZV, +Anhang 2 zulässig + +. Feld 20: Nur bei Weisungsschlüssel , 10' aus DTAZV, Anhang 2 zulässig + +• Feld 22: Nur Zahlungsartschlüssel ,11' aus DTAZV, Anhang 1 zulässig + + +![](figures/249.1) + + +Hinsichtlich etwaiger Festlegung, die nicht das eigentliche übertrage- +ne Datenformat betreffen, sondern aus der Anpassung des Rahmen- +werks an gesetzliche Vorgaben resultieren gelten, die Vorgaben des +DTAZV-Formats gemäß Spezifikation in (Datenformate) in Version +"gültig ab 31.10.2009. + + +## b) Kreditinstitutsrückmeldung + + +### . Beschreibung + +Es werden keine Datensegmente zurückgemeldet. + +◆ Ausgewählte Beispiele für Rückmeldungscodes + + +![](figures/249.2) + + +Bei Überschreitung der Meldegrenzen ist der Kunde auf die Melde- +vorschriften der deutschen Bundesbank hinzuweisen. + +Es gelten die Rückmeldungscodes der Einzelüberweisung. Zusätzlich gelten: + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
3710Betrag liegt über Meldegrenze (12.500 EUR). Beachten Sie die Meldevorschriften.
9210Ungültiges Format
+ + +### c) Bankparameterdaten + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Euro-Eilüberweisung Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIEUES
Bezugssegment:HKVVB
Version:2
Sender:Kreditinstitut
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
230		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Zahlungsverkehr Ausland
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Euro- Eilüberweisung2DEGM1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Geschäftsvorfälle Karten, Schecks und FormulareStand: 07.08.2015Seite: 231
+ + +# C.6 Karten, Schecks und Formulare + + +## C.6.1 Bestellung + + +### C.6.1.1Vordruckbestellung + +Art und Umfang der vom Kunden zu bestellenden Vordrucke/Formulare variiert von +Kreditinstitut zu Kreditinstitut. Angeboten werden können bspw. Überweisungs-, +Lastschrift- oder Dauerauftragsformulare sowie insbesondere Formulare zu Ge- +schäftsvorfällen, die zur Zeit noch nicht über HBCI unterstützt werden. + +Die Bestellung von Zahlungsverkehrsvordrucken und Schecks ist identisch, da aus +sicherheitstechnischer Sicht kein Unterschied besteht. Lediglich für die Bestellung +von Reiseschecks ist ein separater Geschäftsvorfall vorgesehen. + +Generell sollte für Kunden, die am Homebanking-Verfahren teilnehmen, jedoch das +Einreichen von Aufträgen per Vordruck nicht mehr erforderlich sein. Daher soll die +Formularbestellung durch den Kunden per Homebanking nur im Einzelfall erfolgen. + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +# a) Kundenauftrag + + +## . Beschreibung + +Die Zusendung der Schecks und Vordrucke erfolgt standardmäßig an die Adresse, +die kreditinstitutsseitig als Anschrift zum angegebenen Konto gespeichert ist. + +Die Prüfung, wie viele Schecks des Kunden jeweils im Umlauf sind, und ggf. eine +Sperrung weiterer Scheckbestellungen obliegt dem jeweiligen Kreditinstitut. + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Vordruckbestellung
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKVDB
Bezugssegment:-
Version:3
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung Auftraggeber2DEGktv#M1
3Auslieferung2DEcode1M11,2
4Formularcode1DEnum..2M1
5Gewünschte Anzahl1DEnum..3O1>0
6Adressaufdruck1DEjn#O1
7Adresse2DEGaddr#C1O: „Auslieferung“ = 2 N: sonst
+ + +## . Belegungsrichtlinien + +Adresse + +Zieladresse des Kunden, die von der Standardadresse abweicht. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
232		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Karten, Schecks und Formulare
+ + +# b) Kreditinstitutsrückmeldung + + +## . Beschreibung + +Es werden keine Datensegmente zurückgemeldet. + +◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
9010Kunde besitzt keine Scheckkarte
9010Die Scheckkarte ist gesperrt
9010Die maximale Anzahl ausgegebener Formulare wurde überschritten
9210Keine gültige Kontonummer des Kunden
9210Formular wird nicht angeboten
9210Adressaufdruck nicht möglich
+ + +## c) Bankparameterdaten + + +### . Beschreibung + +Hier legt das Kreditinstitut diejenigen Formulare fest, die vom Kunden bestellt wer- +den können. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Vordruckbestellung Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIVDBS
Bezugssegment:HKVVB
Version:3
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Vor- druckbestellung1DEGM1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Karten, Schecks und Formulare
Geschäftsvorfälle		Stand: 07.08.2015Seite: 233
+ + +# C.6.2 Kartenanzeige + +Mit Hilfe dieses Geschäftsvorfalls können die momentan an den Benutzer ausgege- +benen Karten mit entsprechenden Informationen angezeigt werden. Damit ist es +z.B. möglich, Sperren durchzuführen, ohne im Besitz der zur Sperrung notwendigen +Karteninformationen zu sein. + +Der Geschäftsvorfall ist benutzerbezogen, d.h. Karten von Ehepartnern, Bevoll- +mächtigten etc., werden nicht angezeigt. + + +## a) Kundennachricht + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kartenanzeige anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKAZK
Bezugssegment:-
Version:2
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.BeschreibungVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung Auftraggeber2DEGktv#M1
+ + +## b) Kreditinstitutsnachricht + + +### . Beschreibung + +Für jede Karte wird ein Segment zurückgemeldet. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kartenanzeige
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIAZK
Bezugssegment:HKAZK
Version:2
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.BeschreibungVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kartenart1DEnum..2M1
3Kartenbezeichnung1DEan..35M1
4Kartennummer1DEid#M1
5Kartenfolgenummer1DEid#O1
6Name Karteninha- ber2DEan.35O1
7Gültig ab1DEdat#O1
8Gültig bis1DEdat#O1
9Kartenlimit3DEGbtg#O1
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
234		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Karten, Schecks und Formulare
+ + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.BeschreibungVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
10Bemerkungen1DEtxt.. 2048O1
+ + +## . Belegungsrichtlinien + +Gültig ab, Gültig bis + +Die übliche Angabe im Format JJMM muss in diesem Fall auf ein existieren- +des Datumsformat umgesetzt werden (z.B. Gültig bis ,,9912“ wird umgesetzt +in ,19991231“). + + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
3010Benutzer besitzt keine Karten
+ + +## c) Bankparameterdaten + + +### . Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kartenanzeige Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIAZKS
Bezugssegment:HKVVB
Version:2
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Geschäftsvorfälle Karten, Schecks und FormulareStand: 07.08.2015Seite: 235
+ + +# C.6.3 Sperre + + +## C.6.3.1 Kartensperre + +Dieser Geschäftsvorfall sollte vom Kreditinstitut nur angeboten werden, wenn eine +durchgängig automatisierte Bearbeitung des Sperrauftrags sichergestellt ist. Eine +manuelle Bearbeitung ist aus Zeitgründen für den Kunden nicht akzeptabel. Dem +Kunden sollte die erfolgreiche Sperrung in der Rückmeldung mitgeteilt werden. + +Sollten die für die Sperre notwendigen Kartendaten nicht vorliegen, kann der Kunde +diese mit Hilfe des Geschäftsvorfalls ,Kartenanzeige“ abrufen. Es ist nur die Ge- +samtsperre vorgesehen. Die Sperrung einzelner Anwendungen einer Karte ist nicht +möglich. Die Kartensperre kann nur vom Kreditinstitut selbst aufgehoben werden. + + +![](figures/255.1) + + +Der Kunde sollte auf jeden Fall die Möglichkeit haben, seine Karte +zu sperren, auch wenn das Kreditinstitutssystem nicht erreichbar ist +oder die zur Sperrung erforderlichen Daten nicht vorliegen. Aus die- +sem Grund sollte das Kundenprodukt dem Kunden zusätzlich die +zentrale Telefonnummer des Sperrannahmedienstes 01805/021021 +anzeigen. + + +### a) Kundenauftrag + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kartensperre beantragen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKKAS
Bezugssegment:-
Version:2
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.BeschreibungVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung Auftraggeber2DEGktv#M1
3Kartenart1DEnum..2M1
4Kartennummer1DEid#M1
5Kartenfolgenummer1DEid#O1
6Name Karteninha- ber2DEan.35O1
7Gültig bis1DEdat#O1
+ + +### . Belegungsrichtlinien + + +### Kontoverbindung Auftraggeber + +Es ist die Nummer des Kontos anzugeben, zu dem die Scheckkarte gesperrt +werden soll. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
236		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Karten, Schecks und Formulare
+ + +## Kartennummer, Kartenfolgenummer + +Falls die Kartennummer nicht bekannt ist, kann sie über den Geschäftsvorfall +,Kartenanzeige“ erfragt werden. Falls eine Kartenfolgenummer existiert und +bekannt ist, ist diese ebenfalls anzugeben. + + +## b) Kreditinstitutsrückmeldung + + +### . Format + +Allgemeine Kreditinstitutsnachricht ohne Datensegmente + + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Schecksperre erfolgreich
9210Kontonummer existiert nicht
9210Scheckkarte existiert nicht
+ + +## c) Bankparameterdaten + + +### . Beschreibung + +Hier legt das Kreditinstitut diejenigen Kartentypen fest, die vom Kunden über HBCI +gesperrt werden können. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kartensperre beantragen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIKASS
Bezugssegment:HKVVB
Version:2
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Karten- sperre2DEGM1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Geschäftsvorfälle Sorten, Devisen und ReiseschecksStand: 07.08.2015Seite: 237
+ + +## C.7 Sorten, Devisen und Reiseschecks + +Welche Arten von Sorten und in welchen Währungen Reiseschecks vom Kunden +bestellt werden können, ist kreditinstitutsindividuell. Es können unterschiedliche +Währungen für Sorten und Reiseschecks angeboten werden. Dem Kunden kann +angeboten werden, selbst eine Stückelung der bestellten Sorten und Reiseschecks +zusammenzustellen. Sonst wird der Kunde auf sogenannte Haushaltsmischungen +festgelegt. + +Für Sorten und Reiseschecks sind die folgenden Geschäftsvorfälle vorgesehen: + +• Informationen über zur Zeit gültige Devisenkurse + +· Informationen über zur Zeit gültige Bestellkonditionen für Sorten und Reise- +schecks + +. Auftrag zur Bestellung von Sorten und Reiseschecks + + +## C.7.1 Devisenkurse + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +## a) Kundenauftrag + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Devisenkurse anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKDVK
Bezugssegment:-
Version:2
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Fremdwährung1DEcur#O1
3Abrechnungswäh- rung1DEcur#M1
4Maximale Anzahl Einträge1DEnum..4O1>0
5Aufsetzpunkt1DEan..35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +## . Belegungsrichtlinien + + +## Fremdwährung + +Wird keine Fremdwährung angegeben, soll das Kreditinstitut zu allen Wäh- +rungen des jeweiligen Produktes Informationen zurückliefern. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 238Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Sorten, Devisen und Reiseschecks
+ + +## b) Kreditinstitutsrückmeldung + + +### . Beschreibung + +Für jede rückgemeldete Währung wird ein Segment in die Rückmeldungsnachricht +eingestellt. + + +![](figures/258.1) + + +Bei der Umrechnung von Währungskursen und der Verwendung +von Mengennotierung beziehungsweise Preisnotierung sind die +Richtlinien der DK zu beachten. + + +![](figures/258.2) + + +Bei Anzeige der Kurse ist vom Kundensystem darauf hinzuweisen, +dass die Kurse freibleibend sind und nicht vom Kreditinstitut garan- +tiert werden. Das Kreditinstitut wird in der Regel in dem Rückmel- +dungstext darauf hinweisen. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Devisenkurse rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIDVK
Bezugssegment:HKDVK
Version:2
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Fremdwährung1DEcur#M1
3Währungsbezeich- nung1DEan.35O1
4Standardeinheit1DEnum..4M11,100,1000
5Kursnotierungsart2DEcode1M11,2
6Geldkurs1DEGrate#O1
7Briefkurs1DEGrate#M1
+ + +◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt; Kurse sind freibleibend
3010Zur Zeit sind keine Angebote abrufbar
9210Keine zulässige Abrechnungswährung
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle
Sorten, Devisen und Reiseschecks		Stand: 07.08.2015Seite: 239
+ + +## c) Bankparameterdaten + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Devisenkurse Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIDVKS
Bezugssegment:HKVVB
Version:2
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Devi- senkurse1DEGM1
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
240		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Sorten, Devisen und Reiseschecks
+ + +## C.7.2 Sorten- und Reisescheckkonditionen anfordern + + + + + + + + + + + +
Realisierung Bank:optional; verpflichtend, wenn Sorten- und Reisescheckbestel- lung angeboten wird
Realisierung Kunde:optional; verpflichtend, wenn Sorten- und Reisescheckbestel- lung angeboten wird
+ + +## a) Kundenauftrag + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Sorten- und Reisescheckkonditionen anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKSRK
Bezugssegment:-
Version:2
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Produktart Sorten, Reiseschecks2DEcode1M11, 2, 3
3Fremdwährung1DEcur#O1
4Abrechnungswäh- rung1DEcur#M1
5Maximale Anzahl Einträge1DEnum..4O1>0
6Aufsetzpunkt1DEan.35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +## b) Kreditinstitutsrückmeldung + +Für jede rückgemeldete Währung wird ein Segment in die Rückmeldungsnachricht +eingestellt. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Sorten- und Reisescheckkonditionen rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HISRK
Bezugssegment:HKSRK
Version:2
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:GeschäftsvorfälleStand:Seite:
Abschnitt:Sorten, Devisen und Reiseschecks07.08.2015241
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Produktart Sorten, Reiseschecks2DEcode1M11, 2, 3
3Fremdwährung1DEcur#M1
4Währungsbezeich- nung1DEan..35O1
5Standardeinheit1DEnum..4M11,100,1000
6Kursnotierungsart2DEcode1M11,2
7Geldkurs1DEGrate#O1
8Briefkurs1DEGrate#M1
9Erlaubte Stücke- lungsart2DEcode1O11, 2, 3
10Kleinster Betrag3DEGbtg#O1
11Kleinster Schritt3DEGbtg#O1
12Art des Einfuhrlimits2DEcode1O10, 1, 2, 3
13Einfuhrlimit3DEGbtg#C1O: ,,Art des Einfuhrlimits"=1 N: sonst
14Art des Ausfuhrli- mits2DEcode1O10, 1, 2, 3
15Ausfuhrlimit3DEGbtg#C1O: ,Art des Ausfuhrlimits"=1 N: sonst
16Seltene Währung1DEjn#O1
17Nennwerte1DEGO1
18Stückelungsmög- lichkeiten1DEGO1
19Bestellkonditionen2DEGO99
+ + +## . Belegungsrichtlinien + + +## Briefkurs + +Durch die bei Euro-Währungen fehlende Differenz zwischen Geld- und Brief- +kurs können keine impliziten Gebühren dargestellt werden. Deshalb können +in der DE "Bestellkonditionen" eine Kommission oder ein Bearbeitungspreis +angegeben werden. + + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt; Kurse sind freibleibend
3010Zur Zeit sind keine Angebote abrufbar
9210Keine zulässige Abrechnungswährung
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
242		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Sorten, Devisen und Reiseschecks
+ + +## c) Bankparameterdaten + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Sorten- und Reisescheckkonditionen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HISRKS
Bezugssegment:HKVVB
Version:2
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Sorten- und Reisescheck- konditionen2DEGM1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Sorten, Devisen und Reiseschecks
Geschäftsvorfälle		Stand: 07.08.2015Seite: 243
+ + +# C.7.3 Sorten- und Reisescheckbestellung + +Die Zusendung der Sorten und Reiseschecks erfolgt standardmäßig an die Adresse, +die kreditinstitutsseitig als Anschrift zum angegebenen Konto gespeichert ist. Es ist +aber auch möglich, diese Adresse zu ändern, so dass der Kunde die bestellten Sor- +ten und Reiseschecks auch zu einer anderen Adresse (z.B. Büro) liefern lassen +kann. + +Wenn vom Kreditinstitut angeboten, kann der Kunde eine bestimmte Stückelung der +Sorten oder Reiseschecks anfordern. + +Der Zeitpunkt der Abrechnung der Sorten beziehungsweise Reiseschecks ist kredit- +institutsindividuell. + + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +# a) Kundenauftrag + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Sorten- und Reisescheckbestellung
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKSRB
Bezugssegment:-
Version:2
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung Auftraggeber2DEGktv#M1
3Produktart Sorten, Reiseschecks2DEcode1M11, 2, 3
4Konditionenversion1DEan..10C1M: ,Bestellkonditionen be- nötigt“ (BPD) = „J“ O: sonst
5Auslieferungsart2DEcode1C11, 2, 3, 4
O: ,Konditionenversion" leer N: sonst
6Abweichende Lie- feradresse1DEGaddr#O1
7Abweichende Ge- schäftsstelle1DEan..35C1M: „Auslieferungsart“ = 2 N: sonst
8Gewünschtes Aus- führungsdatum1DEdat#C1O: „Gewünschtes Ausfüh- rungsdatum erlaubt" (BPD) = „J“ N: sonst
9Bestellung2DEGM..99
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
244		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Sorten, Devisen und Reiseschecks
+ + +# . Belegungsrichtlinien + + +## Konditionenversion + +Falls die Angabe der Konditionen gemäß Bankparameterdaten verpflichtend +ist, muss der Kunde die gewünschte Konditionenversion einstellen, die er +durch den Geschäftsvorfall „Sorten- und Reisescheckkonditionen" erhalten +hat. + + +![](figures/264.1) + + +Das Kreditinstitut muss selbst sicherstellen, dass die Angabe +bzw. Nichtangabe einer abweichenden Lieferadresse sich im +Einklang mit der Konditionenversion befindet. + + +## Auslieferungsart + +Falls die Angabe des DE ,Konditionenversion" unterbleibt, kann der Kunde +einen gemäß Bankparameterdaten zulässigen Code für das DE ,,Ausliefe- +rungsart" angeben. Falls auch diese Angabe unterbleibt, bestimmt das Kre- +ditinstitut die Art der Auslieferung. + + +## b) Kreditinstitutsrückmeldung + + +### . Format + +Allgemeine Kreditinstitutsnachricht ohne Datensegmente + + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag zur Ausführung vorgemerkt
0020Bestellte Beträge werden in Ihrer Geschäftsstelle für Sie reserviert
9210Betrag zu groß für Sorten- oder Reisescheckbestellung
9210Betrag muss größer als 0 sein
9210Bitte Stückelung angeben
9210Keine gültige Kontoverbindung des Kunden
9210BLZ existiert nicht
9210Gesamtbetrag unterscheidet sich von bestellter Stückelung
9210Währung wird nicht angeboten
9210Bestellkonditionen sind nicht aktuell; bitte erst aktualisieren
9230Unzureichendes Guthaben des Kontos
+ + +## c) Bankparameterdaten + + +### . Beschreibung + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Sorten- und Reisescheckbestellung Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HISRBS
Bezugssegment:HKVVB
Version:2
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:GeschäftsvorfälleStand:Seite:
Abschnitt:Sorten, Devisen und Reiseschecks07.08.2015245
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Sorten- und Reisescheck- bestellung1DEGM1
+ + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Geschäftsvorfälle InformationenStand: 07.08.2015Seite: 247
+ + +# C.8 Informationen + + +## C.8.1 Freitextmeldungen + + +### C.8.1.1Kundenmeldung + +Dem Kunden wird die Möglichkeit gegeben, eine unstrukturierte, unformatierte Mel- +dung (Freitext) an das Kreditinstitut zu senden. Gegenstand der Freitextmeldung +können alle Aufträge sein, zu denen (noch) keine expliziten Geschäftsvorfälle exis- +tieren. Ferner können per Kundenmeldung beliebige Informationen ohne Auftrags- +charakter an das Kreditinstitut übermittelt werden. + +Da der Kunde auch Aufträge in der Meldung übermitteln kann, ist die allgemeine +Kundenmeldung stets zu signieren. + +Die Behandlung der Meldung sowie die Reaktion auf die Meldung sind kreditinsti- +tutsspezifisch und den entsprechenden Bedingungen des Kunde-Bank-Verhältnis- +ses zu entnehmen. Insbesondere sollten mit Hilfe der Freitextmeldung keine zeitkri- +tischen Aufträge gesendet werden. + + +![](figures/267.1) + + +Die Kundenmeldung soll nicht die Funktionalität eines Email- +Dienstes (Adressierung, Anhängen von Anlagen, Formatierungs- +möglichkeiten etc.) bieten, sondern diesen ergänzen. Es ist dem +Kundenprodukt freigestellt, über die Kundenmeldung hinaus zusätz- +lich die Mailkomponente des jeweiligen Online-Dienstes anzubieten. + +Kundenmeldungen sollten im Kundenprodukt gespeichert werden, +um dem Kunden auch zu einem späteren Zeitpunkt einen Zugriff auf +seine Meldungen zu ermöglichen. + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +#### a) Kundenauftrag + + +##### . Beschreibung + +Der Kunde erhält lediglich eine Bestätigung des Eingangs seiner Meldung, jedoch +keine Rückmeldung bzgl. der Bearbeitung oder Ausführung (sofern es sich um ei- +nen Auftrag handelt). Ebenso sind keine weiteren Informationen über den Verarbei- +tungsvorgang im Statusprotokoll abrufbar. + + +##### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kundenmeldung
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKKDM
Bezugssegment:-
Version:5
Sender:Kunde
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
248		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt:
Informationen
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung Auftraggeber2DEGktv#O1
3Freitextmeldung1DEtxt.. 2048M1
4Betreff1DEan..35O1
5Empfängerangaben1DEan..35O1
+ + +#### . Belegungsrichtlinien + + +##### Kontoverbindung Auftraggeber + +Das Feld ist dann zu belegen, wenn sich die Kundenmeldung auf ein konkre- +tes Konto des Kunden bezieht. Wenn es sich um eine nicht-kontenbezogene +Meldung handelt (z.B. Adressänderung, Informationsanforderung) kann die +Belegung entfallen. + + +#### b) Kreditinstitutsrückmeldung + + +##### . Beschreibung + +Es werden keine Datensegmente zurückgemeldet. + + +##### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Meldung entgegengenommen
9140Freitextmeldung zu lang
9210Keine gültige Kontonummer des Kunden
+ + +#### c) Bankparameterdaten + + +##### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kundenmeldung Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIKDMS
Bezugssegment:HKVVB
Version:5
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Kun- denmeldung1DEGM1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Geschäftsvorfälle InformationenStand: 07.08.2015Seite: 249
+ + +## C.8.1.2Gastmeldung + +Um auch Nichtkunden die Möglichkeit zu geben, mit einem bestimmten Kreditinstitut +zu kommunizieren (z.B. zur Anforderung von Informationen über das Leistungs- +spektrum, Angebote oder Preise), steht dieser Geschäftsvorfall zur Verfügung. Für +das Format und die Beantwortung des Auftrages gilt dasselbe wie für den Ge- +schäftsvorfall „Kundenmeldung“ (s.o.). + +Die Angabe der/einer Kontoverbindung ist optional. Eine Signatur des Auftrages ist +nicht erforderlich. + +Realisierung Bank: +optional + +Realisierung Kunde: optional + + +## a) Kundenauftrag + + +### . Beschreibung + +Es kann eine Adresse angegeben werden, um dem Kunden angeforderte Informati- +onen auf dem Postweg zusenden zu können. + + +### . Format + +Name: +Gastmeldung +Typ: +Segment +Segmentart: +Geschäftsvorfall +Kennung: +HKGAM +Bezugssegment: +\- +Version: +4 +Sender: +Kunde + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung Auftraggeber2DEGktv#O1
3Freitextmeldung1DEtxt.. 2048M1
4Betreff1DEan.35O1
5Adresse2DEGaddr#O1
+ + +## b) Kreditinstitutsrückmeldung + + +### . Beschreibung + +Es werden keine Datensegmente zurückgemeldet. + + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
9140Freitextmeldung länger als Vorgabe in der BPD
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
250		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Informationen
+ + +## c) Bankparameterdaten + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Gastmeldung Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIGAMS
Bezugssegment:HKVVB
Version:4
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Gast- meldung1DEGM1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Geschäftsvorfälle InformationenStand: 07.08.2015Seite: 251
+ + +# C.8.2 Formatierte Meldungen + + +## C.8.2.1Kreditinstitutsangebote abholen + +Um Informationen zu bestimmten Themen anzufordern zu können, muss der Kunde +zunächst ein Verzeichnis der lieferbaren Informationen von seinem Kreditinstitut ab- +rufen. Diese Informationen können sowohl als Schriftdokumente als auch in Datei- +form vorliegen. + + +![](figures/271.1) + + +Um zu vermeiden, dass für das Abholen der Angebote und das da- +rauffolgende Bestellen der Informationen nicht jeweils die physikali- +sche Verbindung erneut aufgebaut werden muss, sollten diese bei- +den Aufträge im Online-Modus erfolgen. + + +![](figures/271.2) + + +![](figures/271.3) + + +Im Rahmen von § 3 Abs. 5 des Teledienste-Datenschutzgesetzes +(TDDSG) ist der Benutzer bei automatisierten Verfahren, die eine +spätere Identifizierung des Benutzers ermöglichen, über Art, Um- +fang, Ort und Zwecke der Erhebung, Verarbeitung und Nutzung per- +sonenbezogener Daten zu unterrichten. Der Inhalt dieser Unterrich- +tung muss für den Benutzer jederzeit abrufbar sein. + +Um eine multibankfähige Realisierung dieser Informationspflicht zu +ermöglichen, wird hierzu der Informationscode ,,TDDSG" definiert (s. +Beispiel), der von allen Kreditinstituten, die dieser Informations- +pflicht unterliegen, anzubieten ist. Die Information ist als Freitext an- +zubieten. Es bleibt dem Kreditinstitut unbenommen, diese Informati- +on parallel auch in der kreditinstitutseigenen Systematik anzubieten. + + +![](figures/271.4) + + +Durch § 675a BGB wird gefordert, dass für regelmäßig anfallende +standardisierte Geschäftsvorgänge schriftlich - in geeigneten Fällen +auch elektronisch - Informationen über Entgelte und Auslagen der +Geschäftsbesorgung zur Verfügung gestellt werden. + + +![](figures/271.5) + + +Kreditinstitute erhalten über diesen Geschäftsvorfall die Möglichkeit, +dem Kunden entsprechende Preis- und Leistungsverzeichnisse zum +Abruf bereitzustellen. Hierfür wird der multibankfähige Informations- +code "PLV" definiert, der nicht anderweitig vergeben werden darf. +Das Institut kann wählen, ob es dem Kunden diese Informationen +elektronisch als Fließtext oder Datei oder als Papierdokument per +Post zusendet. + +Realisierung Bank: optional + +Realisierung Kunde: optional + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
252		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Informationen
+ + +### a) Kundenauftrag + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kreditinstitutsangebote anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKKIA
Bezugssegment:-
Version:4
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Einträge1DEnum..4O1>0
3Aufsetzpunkt1DEan..35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +### b) Kreditinstitutsrückmeldung + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kreditinstitutsangebote rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIKIA
Bezugssegment:HKKIA
Version:4
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Informationen3DEGO999
+ + +#### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
3010Z.Zt. sind keine Angebote abrufbar
9210Keine gültige Kontonummer des Kunden
+ + +#### c) Bankparameterdaten + + +##### . Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle InformationenStand: 07.08.2015Seite: 253
+ + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kreditinstitutsangebote Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIKIAS
Bezugssegment:HKVVB
Version:4
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
254		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Informationen
+ + +## C.8.2.2Informationsbestellung + +Dem Kunden wird die Möglichkeit geboten, schriftliche Informationen zu bestimmten +Themen strukturiert anzufordern. Zum Abholen von in Dateiform vorliegender Infor- +mationen dient dagegen zukünftig der Geschäftsvorfall „Datei abholen“. + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +## a) Kundenauftrag + + +### . Beschreibung + +Um eine Übersicht der aktuell lieferbaren Informationen zu erhalten, hat der Kunde +zunächst den Auftrag „Kreditinstitutsangebote abholen“ auszuführen. Die Informati- +onen werden dem Kunden in der Regel auf dem Postweg zugeschickt. Empfänger- +adresse ist die im Kreditinstitut gespeicherte Kundenadresse. Optional kann eine +hiervon abweichende Empfängeradresse angegeben werden. Bei Nichtkunden +muss eine Empfängeradresse angegeben werden. + +Bei Bestellung von Schriftdokumenten erhält der Kunde lediglich eine Bestätigung +des Eingangs seiner Meldung. Ebenso sind keine Informationen über den Verarbei- +tungsvorgang im Statusprotokoll abrufbar. + +Der Kunde hat kein Anrecht auf Zustellung der gewünschten Informationen, da die- +se evtl. momentan nicht vorrätig sind. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Informationen anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKINF
Bezugssegment:-
Version:4
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Informationscodes1DEGM1
3Adresse2DEGaddr#O1
+ + +## b) Kreditinstitutsrückmeldung + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Informationen rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIINF
Bezugssegment:HKINF
Version:4
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle InformationenStand: 07.08.2015Seite: 255
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Freitextinformatio- nen1DEGO99
+ + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
9210Keine gültige Kontonummer des Kunden
9210Informationscode wird nicht angeboten
+ + +## c) Bankparameterdaten + + +### . Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Informationsanforderung Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIINFS
Bezugssegment:HKVVB
Version:4
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
256		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt:
Informationen
+ + +# C.8.2.3Terminvereinbarung + +Dem Kunden wird die Möglichkeit geboten, einen strukturierten Terminwunsch für +ein Beratungsgespräch an das Kreditinstitut zu senden. Eine Online-Rückmeldung +des Kreditinstituts, d.h. eine Terminbestätigung, erfolgt nicht. Der Kunde erhält le- +diglich eine Bestätigung des Eingangs seiner Meldung. Ebenso sind keine Informa- +tionen über den Verarbeitungsvorgang im Statusprotokoll abrufbar. + +Die Angaben sind weder für den Kunden noch für das Kreditinstitut verbindlich. Der +Termin gilt erst nach schriftlicher oder telefonischer Bestätigung durch das Kreditin- +stitut als vereinbart. + +Realisierung Bank: +optional + +Realisierung Kunde: optional + + +# a) Kundenauftrag + + +## . Beschreibung + +Wird kein Datum bzw. keine Uhrzeit angegeben, so geht das Kreditinstitut von ei- +nem Beratungswunsch ohne konkreten Terminvorschlag aus. Das Kreditinstitut soll- +te sich daraufhin mit dem Kunden in Verbindung setzen, um einen konkreten Termin +zu vereinbaren. + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Terminvereinbarung
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKTMV
Bezugssegment:-
Version:3
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung Auftraggeber2DEGktv#M1
3Terminwunsch1DEGtsp#O1
4Geschäftsstelle1DEan..35O1
5Kundenberater1DEan..35O1
6Telefonnummer für Bestätigung1DEan..35O1
7Informationscode1DEan..10O1
8Thema1DEan.200O1
+ + +## b) Kreditinstitutsrückmeldung + + +## . Beschreibung + +Es werden keine Datensegmente zurückgemeldet. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle InformationenStand: 07.08.2015Seite: 257
+ + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
9210Datum liegt zu weit in der Zukunft
9210Datum liegt nicht in der Zukunft
9210Keine gültige Kontonummer des Kunden
+ + +## c) Bankparameterdaten + + +### . Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Terminvereinbarung Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HITMVS
Bezugssegment:HKVVB
Version:3
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SonstigesStand: 07.08.2015Seite: 259
+ + +# C.9 Sonstiges + + +## C.9.1 Freistellung von Zinserträgen + +Bei Ehepartnern ist bei der Anlage, Änderung oder Löschung des Freistellungsauf- +trags eine zweite Unterschrift einzuholen. Dies ist in der Regel nicht über elektroni- +sche Medien ohne weiteres möglich. Die Geschäftsvorfälle sollten daher nur im Ein- +klang mit den aktuell gültigen Regelungen des Bundesministeriums für Finanzen +eingesetzt werden. + +Diese besagen derzeit, dass die Transaktion bei gemeinsamer steuerlicher Veran- +lagung zwar von nur einem Ehepartner (dem der sich legitimiert hat, somit der +,Erstgenannte“) ausgeführt werden dürfen, allerdings nur unter der Voraussetzung, +dass ein entsprechendes Feld eingeführt wird, in dem der Ausführende explizit +durch Aktivierung dessen bestätigen muss, dass er im Einverständnis des Partners +handelt. Weiter muss dem vertretenen Partner per Papierpost oder per E-Mail eine +Mitteilung über die Änderung oder Einrichtung und der neue geänderte Freistel- +lungsauftrag zugehen. + + +## C.9.1.1Abfrage Freistellungsdaten + + +### C.9.1.1.1 Segmentversion 2 + +Es können Daten bezüglich der von der Zinsabschlagsteuer freigestellten Beträge +abgerufen werden. Die Freistellungsdaten beziehen diejenigen Konten ein, die über +die im Dialog genutzte Kunden-ID geführt werden. + + +![](figures/279.1) + + +Die Abfrage der Freistellungsdaten ist i.d.R. nur durch den Kontoin- +haber zulässig. Die entsprechenden UPD-Einträge sollten im Be- +rechtigungsprofil des Kreditinstitutssystems abgebildet werden kön- +nen. + + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +#### a) Kundenauftrag + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Freistellungsdaten abfragen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKFRD
Bezugssegment:-
Version:2
Sender:Kunde
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
260		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Sonstiges
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Kreditinstitutsken- nung1DEGkik#O1
3Konto- /Depotnummer1DEid#O1
4Jahr der Gültigkeit1DEnum4O9
+ + +#### . Belegungsrichtlinien + + +##### Kreditinstitutskennung + +Wenn der Kunde Konten/Verträge verschiedener Institute besitzt, hat er die +Möglichkeit, das gewünschte Institut zu selektieren. + + +##### Konto-/Depotnummer + +Wenn der Kunde Bevollmächtigter ist, hat er die Möglichkeit, Freistellungs- +aufträge, die sich auf andere Konten beziehen, anzuzeigen. + + +##### Jahr der Gültigkeit + +Falls das Feld nicht belegt wird, werden Informationen für alle vorhandenen +Jahre geliefert. + + +#### b) Kreditinstitutsrückmeldung + + +##### . Beschreibung + +Es werden die vorhandenen Freistellungsdaten in die Kreditinstitutsrückmeldung +eingestellt. Für jedes Jahr wird ein Segment zurückgeliefert. Falls unterjährig Ände- +rungen stattgefunden haben, können pro Jahr auch mehrere Segmente zurück- +gemeldet werden. + + +##### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Freistellungsdaten rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIFRD
Bezugssegment:HKFRD
Version:2
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kreditinstitutsken- nung1DEkik#O1
3Gültig ab1DEdat#M1
4Gültig bis1DEdat#M1
5Freistellungsbetrag3DEGbtg#M1
6Restfreistellungsbe- trag3DEGbtg#O1
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:GeschäftsvorfälleStand:Seite:
Abschnitt:Sonstiges07.08.2015261
+ + + + + + + + + + + + + + + + + + + + + + + + + +
7Einreichungsdatum1DEdat#O1
8Kontoverbindung2DEGktv#O99
+ + +# . Belegungsrichtlinien + + +## Kontoverbindung + +Es können diejenigen Kontoverbindungen angegeben werden, auf die sich +der Freistellungsauftrag bezieht. + +In den folgenden Fällen kann dies sinnvoll sein: + +\- Der Benutzer kann für Konten berechtigt sein, von denen er nicht Konto- +inhaber ist. In diesem Fall sollte dem Benutzer deutlich gemacht werden, +dass der Freistellungsauftrag nicht für diese Konten greift. + +\- Es sind nicht alle Konten des Benutzers für Online-Banking freigeschaltet. +In diesem Fall sollte dem Benutzer deutlich gemacht werden, dass der +Freistellungsauftrag auch noch für andere Konten (z.B. die des Ehe- +partners) greift. + +◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
3010Es liegen keine Einträge vor
3040Auftrag teilweise ausgeführt
+ + +## c) Bankparameterdaten + + +### . Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Freistellungsdaten Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIFRDS
Bezugssegment:HKVVB
Version:2
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + +#### C.9.1.1.2 Segmentversion 3 + +Es können Daten bezüglich der von der Zinsabschlagsteuer freigestellten Beträge +abgerufen werden. Die Freistellungsdaten beziehen sich auf alle Konten bei einem +Institut. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
262		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt:
Sonstiges
+ + +![](figures/282.1) + + +Die Abfrage der Freistellungsdaten ist i.d.R. nur durch den ange- +meldeten Benutzer für seine Konten und bei gemeinsamer steuerli- +cher Veranlagung ggf. zusätzlich für die gemeinsamen Konten zu- +lässig. Die entsprechenden UPD-Einträge sollten im Berech- +tigungsprofil des Kreditinstitutssystems abgebildet werden können. + + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +## a) Kundenauftrag + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Freistellungsdaten abfragen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKFRD
Bezugssegment:-
Version:3
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kreditinstitutsken- nung1DEGkik#O1
3Konto- /Depotnummer1DEid#C1O: ,"Konto-/Depotnummer erlaubt" (BPD) ,,J" N: sonst
4Jahr der Gültigkeit1DEnum4O9
+ + +## . Belegungsrichtlinien + + +### Kreditinstitutskennung + +Wenn der Kunde Konten/Verträge verschiedener Institute besitzt, hat er die +Möglichkeit, das gewünschte Institut zu selektieren. + + +### Konto-/Depotnummer + +Wenn der Kunde Bevollmächtigter ist, hat er die Möglichkeit, Freistellungs- +aufträge, die sich auf andere Konten beziehen, anzuzeigen. + + +### Jahr der Gültigkeit + +Falls das Feld nicht belegt wird, werden Informationen für alle vorhandenen +Jahre geliefert. + + +## b) Kreditinstitutsrückmeldung + + +## . Beschreibung + +Es werden die vorhandenen Freistellungsdaten in die Kreditinstitutsrückmeldung +eingestellt. Für jedes Jahr wird ein Segment zurückgeliefert. Falls unterjährig Ände- +rungen stattgefunden haben, können pro Jahr auch mehrere Segmente zurück- +gemeldet werden. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SonstigesStand: 07.08.2015Seite: 263
+ + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Freistellungsdaten rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIFRD
Bezugssegment:HKFRD
Version:3
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kreditinstitutsken- nung1DEkik#O1
3Gültig ab1DEdat#M1
4Gültig bis1DEdat#O1
5Freistellungsbetrag3DEGbtg#M1
6Familienstand Frei- stellungsauftrag1DEcode1O11, 2, 3, 4, 5, 6
7Restfreistellungsbe- trag3DEGbtg#O1
8Inanspruchnahme1DEGbtg#O1
9Einreichungsdatum1DEdat#O1
10Auftragsidentifikati- on1DEan.99O1
11Kontoverbindung2DEGktv#On
+ + +## . Belegungsrichtlinien + + +### Kontoverbindung + +Es können diejenigen Kontoverbindungen angegeben werden, auf die sich +der Freistellungsauftrag nicht bezieht. In den folgenden Fällen kann dies +sinnvoll sein: + +\- Der Benutzer kann für Konten berechtigt sein, von denen er nicht Konto- +inhaber ist. In diesem Fall sollte dem Benutzer deutlich gemacht werden, +dass der Freistellungsauftrag nicht für diese Konten greift. + +\- Es gibt Konten, die vom Freistellungsauftrag durch den Kunden ausge- +schlossen wurden. + +Gültig bis + +Falls die Befreiung nicht befristet ist, gilt sie „bis auf Widerruf“. + + +#### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
3010Es liegen keine Einträge vor
3040Auftrag teilweise ausgeführt
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 264Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Sonstiges
+ + +## c) Bankparameterdaten + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Freistellungsdaten Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIFRDS
Bezugssegment:HKVVB
Version:3
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Freistel- lungsdaten1DEGM1
+ + +#### C.9.1.1.3 Segmentversion 4 + +Es können Daten bezüglich der von der Abgeltungssteuer freigestellten Beträge ab- +gerufen werden. Die Freistellungsdaten beziehen sich auf alle Konten bei einem +Institut. + + +![](figures/284.1) + + +Die Abfrage der Freistellungsdaten ist i.d.R. nur durch den ange- +meldeten Benutzer für seine Konten und bei gemeinsamer steuerli- +cher Veranlagung ggf. zusätzlich für die gemeinsamen Konten zu- +lässig. Die entsprechenden UPD-Einträge sollten im Berech- +tigungsprofil des Kreditinstitutssystems abgebildet werden können. + + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +## a) Kundenauftrag + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Freistellungsdaten abfragen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKFRD
Bezugssegment:-
Version:4
Sender:Kunde
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:GeschäftsvorfälleStand:Seite:
Abschnitt:Sonstiges07.08.2015265
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Kreditinstitutsken- nung1DEGkik#O1
3Institutskennzei- chen1DEnum..2O1Lt. ,Institutsmerkmale" (BPD)
4Alle Institute1DEjn#C1O: ,Alle Institute erlaubt“ (BPD) = „J“ N: sonst
5Konto- /Depotnummer1DEid#C1O: ,"Konto-/Depotnummer erlaubt“ (BPD) ,J“ N: sonst
6Maximale Anzahl Einträge1DEnum..4C1>0
O: ,,Eingabe Anzahl Ein- träge erlaubt“ (BPD) = „J“ N: sonst
7Jahr der Gültigkeit1DEnum4O..9
8Aufsetzpunkt1DEan.35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +## . Belegungsrichtlinien + + +### Kreditinstitutskennung + +Wenn der Kunde Konten/Verträge verschiedener Institute besitzt, hat er die +Möglichkeit, das gewünschte Institut zu selektieren. + + +### Konto-/Depotnummer + +Wenn der Kunde Bevollmächtigter ist, hat er die Möglichkeit, Freistellungs- +aufträge, die sich auf andere Konten beziehen, anzuzeigen. + + +### Jahr der Gültigkeit + +Falls das Feld nicht belegt wird, werden Informationen für alle vorhandenen +Jahre geliefert. + + +## b) Kreditinstitutsrückmeldung + + +## . Beschreibung + +Es werden die vorhandenen Freistellungsdaten in die Kreditinstitutsrückmeldung +eingestellt. Für jedes Jahr wird ein Segment zurückgeliefert. Falls unterjährig Ände- +rungen stattgefunden haben, können pro Jahr auch mehrere Segmente zurück- +gemeldet werden. + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Freistellungsdaten rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIFRD
Bezugssegment:HKFRD
Version:4
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 266Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Sonstiges
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Kreditinstitutsken- nung1DEkik#O1
3Institutskennzei- chen1DEnum..2O1Lt. ,Institutsmerkmale" (BPD)
4Kennzeichen FSA/NV1DEcode1M1F,N
5Gültig ab1DEdat#M1
6Gültig bis1DEdat#O1
7Freistellungsbetrag3DEGbtg#C1M: ,"Kennzeichen FSA/NV" (BPD) ,,F" N: sonst
8Familienstand Frei- stellungsauftrag1DEcode1O11, 2, 3, 4, 5, 6
9Restfreistellungsbe- trag3DEGbtg#O1
10Inanspruchnahme1DEGbtg#O1
11Ordnungsnummer Finanzamt1DEan..16O1
12Einreichungsdatum1DEdat#O1
13Auftragsidentifikati- on1DEan.99O1
14Kontoverbindung2DEGktv#On
+ + +# . Belegungsrichtlinien + + +## Kontoverbindung + +Es können diejenigen Kontoverbindungen angegeben werden, auf die sich +der Freistellungsauftrag nicht bezieht. In den folgenden Fällen kann dies +sinnvoll sein: + +\- Der Benutzer kann für Konten berechtigt sein, von denen er nicht Konto- +inhaber ist. In diesem Fall sollte dem Benutzer deutlich gemacht werden, +dass der Freistellungsauftrag nicht für diese Konten greift. + +\- Es gibt Konten, die vom Freistellungsauftrag durch den Kunden ausge- +schlossen wurden. + + +## Gültig bis + +Falls die Befreiung nicht befristet ist, gilt sie „bis auf Widerruf“. + + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
3010Es liegen keine Einträge vor
3040Auftrag teilweise ausgeführt
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle
Sonstiges		Stand: 07.08.2015Seite: 267
+ + +# c) Bankparameterdaten + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Freistellungsdaten Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIFRDS
Bezugssegment:HKVVB
Version:4
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Freistel- lungsdaten2DEGM1
+ + +# C.9.1.2Freistellungsauftrag anlegen + +Die Freistellungsdaten beziehen sich auf alle Konten bei einem Institut. + + +![](figures/287.1) + + +Das Kreditinstitut hat dafür Sorge zu tragen, dass ein eventuell vor- +handener Ehepartner über die Anlage des Freistellungsauftrags auf +geeignetem Wege benachrichtigt wird. + +Realisierung Bank: + +optional + +Realisierung Kunde: +optional + + +## a) Kundenauftrag + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Freistellungsauftrag anlegen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKFRA
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
268		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Sonstiges
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameTypFor- matLän- geSta- tusAn- zahlRestriktionen
1SegmentkopfDEGM1
2KreditinstitutskennungDEkik#O1
3Gültig abDEdat#M1
4Gültig bisDEdat#O1
5FreistellungsbetragDEGbtg#M1
6Familienstand Freistel- lungsauftragDEcode1M11, 2, 3, 4, 5, 6
7Einverständnis des Part- nersDEjn#C1M: ,Familienstand Freistel- lungsauftrag“=2 N: sonst
+ + +## . Belegungsrichtlinien + + +### Kreditinstitutskennung + +Wenn der Kunde Konten/Verträge verschiedener Institute besitzt, hat er die +Möglichkeit, das gewünschte Institut zu selektieren. + + +### Gültig bis + +Falls die Befreiung nicht befristet ist, gilt sie „bis auf Widerruf“. + + +### Einverständnis des Partners + + +![](figures/288.1) + + +Dem Kunden muss zur Eingabe ein Feld zur Aktivierung vorgege- +ben werden. Bei gemeinschaftlicher steuerlicher Veranlagung des +Kunden muss er durch die Aktivierung („J“) explizit mitteilen, dass er +im Einverständnis des Partners handelt. + + +### b) Kreditinstitutsrückmeldung + + +#### . Beschreibung + +Es werden die Konten zurückgeliefert, die von der Anlage des Freistellungsauftrags +betroffen sind. + + +![](figures/288.2) + + +Falls das Kreditinstitut schon bei der Einreichung eine Auf- +tragsidentifikation zurückmelden kann, sollte diese Möglich- +keit genutzt werden. Andernfalls hat das Kundensystem vor +einer Änderung oder Löschung den gesamten Bestand abzu- +rufen, um in den Besitz der Auftragsidentifikation zu gelan- +gen. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle
Sonstiges		Stand: 07.08.2015Seite: 269
+ + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Einreichung Freistellungsauftrag bestätigen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIFRA
Bezugssegment:HKFRA
Version:1
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Auftragsidentifikati- on1DEan.99O1
3Freistellungsbetrag3DEGbtg#O1
4Kontoverbindung2DEGktv#On
+ + +#### . Belegungsrichtlinien + + +##### Kontoverbindung + +Es können diejenigen Kontoverbindungen angegeben werden, auf die sich +der Freistellungsauftrag nicht bezieht. + +In den folgenden Fällen kann dies sinnvoll sein: + +\- Der Benutzer kann für Konten berechtigt sein, von denen er nicht Konto- +inhaber ist. In diesem Fall sollte dem Benutzer deutlich gemacht werden, +dass der Freistellungsauftrag nicht für diese Konten greift. + +\- Es gibt Konten, die durch den Kunden von Freistellungsaufträgen ausge- +schlossen wurden. + + +###### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
+ + +###### c) Bankparameterdaten + + +####### . Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + +####### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Freistellungsauftrag anlegen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIFRAS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer-TypFor-Län-Sta-An-Restriktionen
sionmatgetuszahl
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 270Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Sonstiges
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SonstigesStand: 07.08.2015Seite: 271
+ + +# C.9.1.3Freistellungsdaten ändern + +Die Identifikation der zu ändernden Freistellungsdaten erfolgt anhand der Auftragsi- +dentifikation. + + +![](figures/291.1) + + +Vor der Änderung sollte eine Abholung des aktuellen Bestandes +beim Kreditinstitut (s.u.) erfolgen, um sicherzustellen, dass der Kun- +de auf Basis des korrekten Bestandes operiert. Das Kundenprodukt +sollte auf Basis der Bestandabfrage Prüfungen vornehmen: z.B. +hinsichtlich des Freistellungsbetrages und der Inanspruchnahme, +um den Kunden bereits vorab auf einen eventuell zu gering gewähl- +ten Freistellungsbetrag hinweisen zu können + + +![](figures/291.2) + + +Falls dieser Geschäftsvorfall kreditinstitutsseitig oder vom Kunden- +produkt nicht angeboten wird, kann durch den Kunden eine Ände- +rung erreicht werden, indem er den Freistellungsauftrag löscht und +anschließend neu einreicht. + + +![](figures/291.3) + + +Dieser Geschäftsvorfall darf vom Kreditinstitut nur angeboten wer- +den, wenn es eine Auftragsidentifikation unterstützt, da ansonsten +die Identifikation des zu ändernden Freistellungsauftrags nicht mög- +lich ist. + + +![](figures/291.4) + + +Das Kreditinstitut hat dafür Sorge zu tragen, dass ein eventuell vor- +handener Ehepartner über die Änderung des Freistellungsauftrags +auf geeignetem Wege benachrichtigt wird. + +Realisierung Bank: +optional + +Realisierung Kunde: +optional + + +## a) Kundenauftrag + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Freistellungsdaten ändern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKFRN
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
272		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Sonstiges
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kreditinstitutsken- nung1DEkik#M1
3Gültig ab1DEdat#C1M: „Gültig bis“ nicht belegt O: sonst
4Gültig bis1DEdat#O1
5Freistellungsbetrag3DEGbtg#O1
6Einreichungsdatum1DEdat#O1
7Familienstand Frei- stellungsauftrag1DEcode1M11, 2, 3, 4, 5, 6
8Einverständnis des Partners1DEjn#C1M: ,Familienstand Freistel- lungsauftrag"=2 N: sonst
9Auftragsidentifikati- on1DEan.99M1
+ + +## ◆ Belegungsrichtlinien + + +### Kreditinstitutskennung + +Wenn der Kunde Konten/Verträge verschiedener Institute besitzt, hat er die +Möglichkeit, das gewünschte Institut zu selektieren. + + +### Gültig bis + +Falls die Befreiung nicht befristet ist, gilt sie „bis auf Widerruf“. + + +### Einverständnis des Partners + + +![](figures/292.1) + + +Dem Kunden muss zur Eingabe ein Feld zur Aktivierung vorgege- +ben werden. Bei gemeinschaftlicher steuerlicher Veranlagung des +Kunden muss er durch die Aktivierung („J“) explizit mitteilen, dass er +im Einverständnis des Partners handelt. + + +### b) Kreditinstitutsrückmeldung + + +#### . Beschreibung + +Es werden keine Datensegmente zurückgemeldet. + + +#### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
3010Es liegen keine Einträge vor
+ + +#### c) Bankparameterdaten + + +##### . Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SonstigesStand: 07.08.2015Seite: 273
+ + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Freistellungsdaten ändern Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIFRNS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
274		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Sonstiges
+ + +# C.9.1.4Freistellungsdaten löschen + +Die Identifikation der zu löschenden Freistellungsdaten erfolgt anhand der Auf- +tragsidentifikation. Der Kunde hat die gültigen Daten des Freistellungsauftrags ein- +zustellen. Diese dienen zu Plausibilitätsprüfungen. + + +![](figures/294.1) + + +Vor der Löschung sollte eine Abholung des aktuellen Bestandes +beim Kreditinstitut (s.u.) erfolgen, um sicherzustellen, dass der Kun- +de auf Basis des korrekten Bestandes operiert. + + +![](figures/294.2) + + +Dieser Geschäftsvorfall darf vom Kreditinstitut nur angeboten wer- +den, wenn es eine Auftragsidentifikation unterstützt, da ansonsten +die Identifikation des zu löschenden Freistellungsauftrags nicht +möglich ist. + + +![](figures/294.3) + + +Das Kreditinstitut hat dafür Sorge zu tragen, dass ein eventuell vor- +handener Ehepartner über die Löschung des Freistellungsauftrags +auf geeignetem Wege benachrichtigt wird. + + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +## a) Kundenauftrag + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Freistellungsdaten löschen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKFRL
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kreditinstitutsken- nung1DEkik#M1
3Gültig ab1DEdat#M1
4Gültig bis1DEdat#O1
5Freistellungsbetrag3DEGbtg#O1
6Einreichungsdatum1DEdat#O1
7Familienstand Frei- stellungsauftrag1DEcode1M11, 2, 3, 4, 5, 6
8Einverständnis des Partners1DEjn#C1M: ,Familienstand Freistel- lungsauftrag“=2 N: sonst
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SonstigesStand: 07.08.2015Seite: 275
+ + + + + + + + + + + + + + +
9Auftragsidentifikati- on1DEan.99M1
+ + +## . Belegungsrichtlinien + + +### Kreditinstitutskennung + +Wenn der Kunde Konten/Verträge verschiedener Institute besitzt, hat er die +Möglichkeit, das gewünschte Institut zu selektieren. + + +### Gültig bis + +Falls die Befreiung nicht befristet ist, gilt sie ,,bis auf Widerruf“. + + +### Einverständnis des Partners + + +![](figures/295.1) + + +Dem Kunden muss zur Eingabe ein Feld zur Aktivierung vorgege- +ben werden. Bei gemeinschaftlicher steuerlicher Veranlagung des +Kunden muss er durch die Aktivierung („J“) explizit mitteilen, dass er +im Einverständnis des Partners handelt. + + +### b) Kreditinstitutsrückmeldung + + +#### . Beschreibung + +Es werden keine Datensegmente zurückgemeldet. + + +#### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
3010Es liegen keine Einträge vor
+ + +### c) Bankparameterdaten + + +#### . Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Freistellungsdaten löschen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIFRLS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
276		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Sonstiges
+ + +# C.9.2 Dateitransfer + +Mit Hilfe der nachfolgenden Geschäftsvorfälle ist es möglich, S.W.I.F.T.-Finanz- +datenformate, die nicht als HBCI-Geschäftsvorfall spezifiziert worden sind, an ein +Kreditinstitut zu senden bzw. von einem Kreditinstitut zu empfangen. + +Mit Hilfe der nachfolgenden Geschäftsvorfälle (Segmentversion 3) ist es ebenso +möglich, beliebige Dokumente an ein Kreditinstitut zu senden bzw. von einem Kre- +ditinstitut zu empfangen. Dies können z. B. S.W.I.F.T.-Formate sein, die nicht als +FinTS-Geschäftsvorfall spezifiziert worden sind. + + +![](figures/296.1) + + +Das Angebot dieser Geschäftsvorfälle ist nur sinnvoll im Rahmen +spezieller Kundenprodukte für ausgewählte Benutzerkreise (i.d.R. +Firmenkunden). + + +![](figures/296.2) + + +# C.9.2.1Finanzdatenformat/Dokument senden + + +## C.9.2.1.1 Finanzdatenformat senden + +Welche Nachrichtentypen das Kreditinstitut entgegennehmen kann, teilt es in den +Bankparameterdaten mit. Pro Segment kann jeweils nur ein Finanzdatenformat ge- +sendet werden. + + +![](figures/296.3) + + +Falls mit Hilfe dieses Geschäftsvorfalls Zahlungsaufträge übertra- +gen werden, ist zu beachten, dass eventuell vorhandene Limite vom +Kundenprodukt nicht geprüft werden können, da diese je nach Fi- +nanzdatenformat unterschiedlich sein können. Das Kundenprodukt +sollte daher beachten, dass ein derart eingereichter Auftrag wegen +Limitüberschreitung nachträglich abgelehnt werden kann. + + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +### a) Kundenauftrag + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Finanzdatenformat senden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKFDS
Bezugssegment:-
Version:2
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:GeschäftsvorfälleStand:Seite:
Abschnitt:Sonstiges07.08.2015277
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung2DEGktv#M1
3Formatinformation2DEGM1
4Finanzdatenformat1DEbin..M1
5Finanzdatenformat Bezugszeitpunkt1DEGtsp#O1
+ + +### b) Kreditinstitutsrückmeldung + + +#### . Beschreibung + +Allgemeine Kreditinstitutsnachricht ohne Datensegmente + + +#### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
0010Auftrag entgegengenommen. Auftrag wird unter Referenz xxx1 verarbeitet
3070Auftrag wird unter Referenz xxx verarbeitet2
9010Format wird nicht unterstützt
+ + +### c) Bankparameterdaten + + +#### . Beschreibung + +Das Kreditinstitut gibt in den Bankparameterdaten an, welche Finanzdatenformate +es entgegennehmen kann. Werden mehrere Versionen eines Datenformats unter- +stützt, so ist dieses mehrfach einzustellen. + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Finanzdatenformat senden Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIFDSS
Bezugssegment:HKVVB
Version:2
Sender:Kreditinstitut
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
278		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Sonstiges
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Finanz- datenformat senden2DEGM1
+ + +## C.9.2.1.2 Dokument senden + +Welche Dokumentformate und -typen das Kreditinstitut entgegennehmen kann, teilt +es in den Bankparameterdaten mit. Pro Segment kann jeweils nur ein Dokument- +format gesendet werden. + + +![](figures/298.1) + + +Falls mit Hilfe dieses Geschäftsvorfalls Zahlungsaufträge übertra- +gen werden, ist zu beachten, dass eventuell vorhandene Limite vom +Kundenprodukt nicht geprüft werden können, da diese je nach Da- +tenformat unterschiedlich sein können. Das Kundenprodukt sollte +daher beachten, dass ein derart eingereichter Auftrag wegen Limit- +überschreitung nachträglich abgelehnt werden kann. + + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +### a) Kundenauftrag + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
. Format
Name:Dokument senden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKFDS
Bezugssegment:-
Version:3
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung2DEGktv#M1
3Formatinformation2DEGM1
4Dokument1DEbin..M1
5Bezugszeitpunkt1DEGtsp#O1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Sonstiges
Geschäftsvorfälle		Stand: 07.08.2015Seite: 279
+ + +#### b) Kreditinstitutsrückmeldung + + +##### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Bearbeitungsstatus Dokument rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIFDS
Bezugssegment:HKFDS
Version:3
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Dokument-ID1DEid#O1
+ + +#### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
0010Auftrag entgegengenommen. Auftrag wird unter Referenz xxx3 verarbeitet
3070Auftrag wird unter Referenz xxx verarbeitet4
9010Format wird nicht unterstützt
+ + +### c) Bankparameterdaten + + +#### . Beschreibung + +Das Kreditinstitut gibt in den Bankparameterdaten an, welche Datenformate es ent- +gegennehmen kann. Werden mehrere Versionen eines Datenformats unterstützt, so +ist dieses mehrfach einzustellen. + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Dokument senden Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIFDSS
Bezugssegment:HKVVB
Version:3
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
280		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Sonstiges
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Doku- ment senden1DEGM1
+ + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SonstigesStand: 07.08.2015Seite: 281
+ + +# C.9.2.2Bearbeitungsstatus Finanzdatenformat/Dokument anfordern + + +## C.9.2.2.1 Bearbeitungsstatus Finanzdatenformat anfordern + +Mit Hilfe dieses Geschäftsvorfalls kann der Kunde sich anhand einer bei der Einrei- +chung mitgeteilten Referenznummer über den Bearbeitungsstatus eines eingereich- +ten Finanzdatenformats bzw. den Bearbeitungsstatus eines Auftrags innerhalb eines +multiplen Finanzdatenformats erkundigen. Als Antwort erhält der Kunde ebenfalls +ein Finanzdatenformat. + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +### a) Kundenauftrag + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Bearbeitungsstatus Finanzdatenformat anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKFDB
Bezugssegment:-
Version:2
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung2DEGktv#M1
3Referenznummer1DEid#O1
4Maximale Anzahl Einträge1DEnum..4O1>0
5Aufsetzpunkt1DEan..35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +### . Belegungsrichtlinien + + +#### Referenznummer + +Es ist die Referenznummer anzugeben, die dem Kunden bei der Einreichung +des Finanzdatenformats mitgeteilt wurde. Wird keine Referenznummer an- +gegeben, so erhält der Kunde den Bearbeitungsstatus aller offenen Aufträge +mitgeteilt. + + +#### b) Kreditinstitutsrückmeldung + + +##### . Beschreibung + +Es ist ein Finanzdatenformat einzustellen, das eine Statusinformation über den an- +geforderten Auftrag enthält (z.B. S.W.I.F.T. MT 509) + +Das Segment ist für jeden rückgemeldeten Bearbeitungsstatus einmal einzustellen. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
282		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Sonstiges
+ + +##### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Bearbeitungsstatus Finanzdatenformat rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIFDB
Bezugssegment:HKFDB
Version:2
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Formatinformation2DEGM1
3Finanzdatenformat1DEbin..M1
4Finanzdatenformat Bezugszeitpunkt1DEGtsp#O1
+ + +##### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
3010Es liegen keine Statusinformationen zu diesem Auftrag vor
+ + +##### c) Bankparameterdaten + + +###### . Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Bearbeitungsstatus Finanzdatenformat Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIFDBS
Bezugssegment:HKVVB
Version:2
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + +## C.9.2.2.2 Bearbeitungsstatus Dokument anfordern + +Mit Hilfe dieses Geschäftsvorfalls kann der Kunde sich anhand einer bei der Einrei- +chung mitgeteilten Referenznummer über den Bearbeitungsstatus eines eingereich- +ten Dokuments bzw. den Bearbeitungsstatus eines Auftrags innerhalb eines multip- +len Dokuments erkundigen. Als Antwort erhält der Kunde ein Dokument, das eine +Statusinformation über den angeforderten Auftrag enthält (z.B. S.W.I.F.T. MT 509). + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle
Sonstiges		Stand: 07.08.2015Seite: 283
+ + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +# a) Kundenauftrag + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Bearbeitungsstatus Dokument anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKFDB
Bezugssegment:-
Version:3
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung2DEGktv#M1
3Dokument-ID1DEid#O1
4Maximale Anzahl Einträge1DEnum..4O1>0
5Aufsetzpunkt1DEan..35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +# . Belegungsrichtlinien + + +## Dokument-ID + +Es ist die Identifikationsnummer anzugeben, die dem Kunden bei der Einrei- +chung des Dokuments mitgeteilt wurde. Wird keine ID angegeben, so erhält +der Kunde den Bearbeitungsstatus aller offenen Dokumente mitgeteilt. + + +# b) Kreditinstitutsrückmeldung + + +## . Beschreibung + +Es ist ein Dokument einzustellen, das eine Statusinformation über den angeforder- +ten Auftrag enthält (z.B. S.W.I.F.T. MT 509). + +Das Segment ist für jeden rückgemeldeten Bearbeitungsstatus einmal einzustellen. + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Bearbeitungsstatus Dokument rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIFDB
Bezugssegment:HKFDB
Version:3
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
284		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Sonstiges
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Formatinformation2DEGM1
3Dokument1DEbin..M1
4Bezugszeitpunkt1DEGtsp#O1
+ + +◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
3010Es liegen keine Statusinformationen zu diesem Auftrag vor
+ + +# c) Bankparameterdaten + + +## . Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Bearbeitungsstatus Dokument Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIFDBS
Bezugssegment:HKVVB
Version:3
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Sonstiges
Geschäftsvorfälle		Stand: 07.08.2015Seite: 285
+ + +### C.9.2.3Liste der bereitgestellten Finanzdatenformat/Dokumente anfordern + + +#### C.9.2.3.1 Liste der bereitgestellten Finanzdatenformate anfordern + +Mit Hilfe dieses Geschäftsvorfalls kann der Kunde eine Liste von Finanzdaten an- +fordern, die für ihn zur Abholung bereitgestellt wurden.5 Die Abholung erfolgt über +den Auftrag ,,Finanzdatenformat anfordern“. + +Realisierung Bank: +optional + +Realisierung Kunde: optional + + +##### a) Kundenauftrag + + +###### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Finanzdatenformatliste anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKFDL
Bezugssegment:-
Version:2
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung2DEGktv#M1
3Maximale Anzahl Einträge1DEnum.4O1>0
4Aufsetzpunkt1DEan..35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +##### b) Kreditinstitutsrückmeldung + + +###### . Beschreibung + +Für jedes vorliegende Finanzdatenformat wird ein Segment in die Antwortnachricht +eingestellt. + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Finanzdatenformatliste rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIFDL
Bezugssegment:HKFDL
Version:2
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
286		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Sonstiges
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Formatinformation2DEGM1
3Finanzdatenformat Bezugszeitpunkt1DEGtsp#O1
+ + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
3010Es liegen keine Dateien vor
+ + +## c) Bankparameterdaten + + +### . Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Finanzdatenformatliste anfordern Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIFDLS
Bezugssegment:HKVVB
Version:2
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + +#### C.9.2.3.2 Liste der bereitgestellten Dokumente anfordern + +Mit Hilfe dieses Geschäftsvorfalls kann der Kunde eine Liste von Dokumenten an- +fordern, die für ihn zur Abholung bereitgestellt wurden.6 Die Abholung erfolgt über +den Auftrag ,,Dokument anfordern“. + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Sonstiges
Geschäftsvorfälle		Stand: 07.08.2015Seite: 287
+ + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +# a) Kundenauftrag + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Dokumentliste anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKFDL
Bezugssegment:-
Version:3
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung2DEGktv#M1
3Von Datum1DEdat#O1
4Bis Datum1DEdat#O1
5Dokumentenart1DEan..30O1
6Formatinformation2DEGC1O: ,,Dokumentenart" = ,Fi- nanzdatenformat“ N: sonst
7Maximale Anzahl Einträge1DEnum..4O1>0
8Aufsetzpunkt1DEan..35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +# . Belegungsrichtlinien + + +## Dokumentenart + +Durch die Angabe der Dokumentenart kann der Kunde die Auswahl auf eine +bestimmte Dokumentenart einschränken. Falls keine Dokumentenart ange- +geben wird, werden sämtliche zur Abholung bereitgestellten Dokumente zu- +rückgemeldet. + + +## Formatinformation + +Hiermit kann die Auswahl auf einen bestimmten Formattyp begrenzt werden. +Falls keine Formatinformation angegeben wird, werden sämtliche zur Abho- +lung bereitgestellten Dokumente zurückgemeldet. + + +## b) Kreditinstitutsrückmeldung + + +### . Beschreibung + +Für jedes vorliegende Dokument wird ein Segment in die Antwortnachricht einge- +stellt. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 288Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Sonstiges
+ + +# . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Dokumentliste rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIFDL
Bezugssegment:HKFDL
Version:3
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Dokument-ID1DEid#M1
3Betreff1DEan..35M1
4Dokumentenart1DEan..30M1
5Formatinformation2DEGC1M: ,Dokumentenart" = ,Fi- nanzdatenformat“ N: sonst
6Bezugszeitpunkt1DEGtsp#O1
7Bereitstellungsda- tum1DEdat#O1
8Dokumentgröße1DEnum.10O1
9Zusatzinformatio- nen1DEtxt. .
1024		O1
+ + +# ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
3010Es liegen keine Dateien vor
+ + +# c) Bankparameterdaten + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Dokumentliste anfordern Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIFDLS
Bezugssegment:HKVVB
Version:3
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Doku- mentliste1DEGM1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Sonstiges
Geschäftsvorfälle		Stand: 07.08.2015Seite: 289
+ + +### C.9.2.4Finanzdatenformat/Dokument anfordern + + +#### C.9.2.4.1 Finanzdatenformat anfordern + +Es werden entweder sämtliche zur Abholung bereitgestellten Finanzdatenformate +zurückgemeldet oder alle bereitgestellten Formate des vom Kunden angegebenen +Typs.7 + +Realisierung Bank: +optional + +Realisierung Kunde: +optional + + +##### a) Kundenauftrag + + +###### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Finanzdatenformat anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKFDA
Bezugssegment:-
Version:2
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung2DEGktv#M1
3Formatinformation2DEGO1
4Finanzdatenformat Bezugszeitpunkt1DEGtsp#O1
5Maximale Anzahl Einträge1DEnum.4O1>0
6Aufsetzpunkt1DEan..35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +##### . Belegungsrichtlinien + + +##### Formatinformation + +Falls keine Formatinformation angegeben wird, werden sämtliche zur Abho- +lung bereitgestellten Formate zurückgemeldet. + + +##### b) Kreditinstitutsrückmeldung + + +## . Beschreibung + +Für jedes vorliegende Finanzdatenformat wird ein Segment in die Antwortnachricht +eingestellt. + + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
290		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Sonstiges
+ + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Finanzdatenformat rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIFDA
Bezugssegment:HKFDA
Version:2
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Formatinformation2DEGM1
3Finanzdatenformat1DEbin. .M1
4Finanzdatenformat Bezungszeitpunkt1DEGtsp#O1
+ + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
3010Es liegen keine Dateien vor
+ + +# c) Bankparameterdaten + + +## . Beschreibung + +Das Kreditinstitut gibt in den Bankparameterdaten an, welche Finanzdatenformate +es grundsätzlich zur Abholung bereitstellen kann. Werden mehrere Versionen eines +Datenformats unterstützt, so ist dieses mehrfach einzustellen. + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Finanzdatenformat anfordern Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIFDAS
Bezugssegment:HKVVB
Version:2
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:GeschäftsvorfälleStand:Seite:
Abschnitt:Sonstiges07.08.2015291
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Finanz- datenformat anfor- dern2DEGM1
+ + +### C.9.2.4.2 Dokument anfordern + +Es werden entweder sämtliche zur Abholung bereitgestellten Dokumente zurück- +gemeldet oder alle bereitgestellten Dokumente des vom Kunden angegebenen +Typs.8 + +Realisierung Bank: +optional + +Realisierung Kunde: optional + + +# a) Kundenauftrag + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Dokument anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKFDA
Bezugssegment:-
Version:3
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung2DEGktv#M1
3Dokument-ID1DEid#O1
4Maximale Anzahl Einträge1DEnum..4O1>0
5Aufsetzpunkt1DEan..35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +## . Belegungsrichtlinien + + +## Dokument-ID + +Es ist die Identifikationsnummer des gewünschten Dokumentes anzugeben. +Diese wird durch die Bestandsabfrage ermittelt. Falls keine Dokument-ID +angegeben wird, werden sämtliche zur Abholung bereitgestellten Dokumente +zurückgemeldet. + + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
292		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Sonstiges
+ + +# b) Kreditinstitutsrückmeldung + + +## . Beschreibung + +Für jedes vorliegende Dokument wird ein Segment in die Antwortnachricht einge- +stellt. + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Dokument rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIFDA
Bezugssegment:HKFDA
Version:3
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Dokument-ID1DEid#M1
3Formatinformation2DEGM1
4Bezugszeitpunkt1DEGtsp#O1
5Dokument1DEbin..M1
+ + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
3010Es liegen keine Dateien vor
+ + +# c) Bankparameterdaten + + +## . Beschreibung + +Das Kreditinstitut gibt in den Bankparameterdaten an, welche Datenformate es +grundsätzlich zur Abholung bereitstellen kann. Werden mehrere Versionen eines +Datenformats unterstützt, so ist dieses mehrfach einzustellen. + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Dokument anfordern Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIFDAS
Bezugssegment:HKVVB
Version:3
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:GeschäftsvorfälleStand:Seite:
Abschnitt:Sonstiges07.08.2015293
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Doku- ment anfordern1DEGM1
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
294		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Sonstiges
+ + +### C.9.3 Geldkartentransaktionen + +Das folgende Kapitel spezifiziert den Nachrichtenaufbau des Geschäftsvorfalls für +das Laden einer GeldKarte im Rahmen des HBCI-Protokolls. Hierbei wird die Lade- +variante ,Laden gegen andere Zahlungsmittel" genutzt. Im vorliegenden Kapitel +werden lediglich die hierzu notwendigen HBCI-Transaktionen beschrieben, nicht +aber die Abläufe im Endgerät sowie im Banksystem. Das Realisierungskonzept [La- +den GK] ist gegen Unterzeichnung einer Vertraulichkeitserklärung über die HBCI- +Leitstelle erhältlich. + + +![](figures/14.1) + + +Das Laden einer GeldKarte über HBCI ist nur in Kombination mit ei- +nem Internet-Kundenterminal gemäß ZKA-Spezifikation (s. [KT- +KONZEPT], [KT-SIG] zulässig. + + +#### C.9.3.1An-/Abmeldung einer GeldKarte + + +##### C.9.3.1.1 Registrierung einer GeldKarte + +Sofern der Kunde eine andere GeldKarte über HBCI laden möchte, als diejenige, +die ihm vom Kreditinstitut, bei dem das Laden erfolgen soll, ausgehändigt wurde9, +muss sie hierfür einmalig kreditinstititutsseitig freigeschaltet werden. Dabei teilt der +Kunde die eindeutige Kennung der zu ladenden GeldKarte sowie das Belastungs- +konto des Ladevorgangs mit. + +Diese Registrierung kann entweder auf dem Schriftwege, d.h. über eine separate +Kundenvereinbarung, die der Kunde in der Filiale unterschreibt, oder mittels des +nachfolgenden HBCI-Geschäftsvorfalls erfolgen. + +Ob die elektronische Übermittlung von einem Ini-Brief begleitet werden muss, kann +kreditinstitutsindividuelle entschieden werden. In diesem Fall kommt ein Verfahren +ähnlich dem Ini-Brief-Austausch beim RDH-Verfahren zum Einsatz, d.h. parallel zur +elektronischen Übermittlung wird von der Kundensoftware ein Ini-Brief ausgedruckt, +der die Kartenidentifikationsdaten und ggf. einen Hashwert über diese Daten ent- +hält. Der Kunde muss die Angaben auf dem Ini-Brief mit seiner Unterschrift bestäti- +gen. Nach Eingang dieses Briefes im Kreditinstitut und Prüfung gegen die elektro- +nisch übermittelten Daten kann die GeldKarte zum Laden über HBCI freigeschaltet +werden. + +Realisierung Bank: verpflichtend, wenn der Geschäftsvorfall ,Laden GeldKarte +vorbereiten“ unterstützt wird + +Realisierung Kunde: verpflichtend, wenn der Geschäftsvorfall ,Laden GeldKarte +vorbereiten“ unterstützt wird + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle
Sonstiges		Stand: 07.08.2015Seite: 295
+ + +###### a) Kundenauftrag + + +####### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Laden GeldKarte registrieren
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKLGR
Bezugssegment:-
Version:2
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung Auftraggeber2DEGktv#M1
3Kartenidentifikati- onsdaten1DEbin22M1
+ + +###### b) Kreditinstitutsrückmeldung + + +####### . Beschreibung + +Es werden keine Datensegmente zurückgemeldet. + + +####### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010GeldKarte wird nach Eingang des Ini-Briefs freigeschaltet
0020GeldKarte wurde registriert
9100Registrierung der GeldKarte nicht möglich
+ + +###### c) Bankparameterdaten + + +####### . Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + +####### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Laden Geldkarte registrieren Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HILGRS
Bezugssegment:HKVVB
Version:2
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
296		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Sonstiges
+ + +##### C.9.3.1.2 Abmeldung einer GeldKarte + +Dieser Geschäftsvorfall ist erforderlich, um eine GeldKarte zum Laden über HBCI +abzumelden, um z.B. eine neue GeldKarte zu registrieren. + +Realisierung Bank: + +verpflichtend, wenn der Geschäftsvorfall ,,Laden GeldKarte +vorbereiten“ unterstützt wird + +Realisierung Kunde: +verpflichtend, wenn der Geschäftsvorfall ,,Laden GeldKarte +vorbereiten“ unterstützt wird + + +###### a) Kundenauftrag + + +####### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Laden GeldKarte abmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKLGA
Bezugssegment:-
Version:2
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung Auftraggeber2DEGktv#M1
3Kartenidentifikati- onsdaten1DEbin22M1
+ + +###### b) Kreditinstitutsrückmeldung + + +####### . Beschreibung + +Es werden keine Datensegmente zurückgemeldet. + + +####### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020GeldKarte wurde abgemeldet
9100Abmeldung der GeldKarte nicht möglich
+ + +####### c) Bankparameterdaten + + +######## . Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + +######## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Laden Geldkarte abmelden Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HILGAS
Bezugssegment:HKVVB
Version:2
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:GeschäftsvorfälleStand:Seite:
Abschnitt:Sonstiges07.08.2015297
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
298		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Sonstiges
+ + +##### C.9.3.2 Laden der GeldKarte + +Für die Durchführung des Ladevorgangs gelten einige Besonderheiten, die von den +übrigen HBCI-Geschäftsvorfällen abweichen: + +• Für den Ladevorgang ist die Abwicklung der vier folgenden Transaktionsschritte +erforderlich: + +\- Laden GeldKarte vorbereiten + +\- Laden GeldKarte einleiten + +\- Laden GeldKarte durchführen + +\- Laden GeldKarte bestätigen + +. Ein Kundenprodukt oder ein Kreditinstitutssystem, das den Geschäftsvorfall „La- +den GeldKarte" unterstützt, muss immer alle vier Transaktionsschritte unterstüt- +zen. Das Kreditinstitut muss somit in den BPD alle vier Parametersegmente an- +bieten. + +. Es wird empfohlen, anschließend den Geschäftsvorfall ,Laden GeldKarte Sta- +tus“ durchzuführen. + +• Die Transaktionsschritte müssen in der festgelegten Reihenfolge erfolgen. + +. Der erste Transaktionsschritt (,,Laden GeldKarte vorbereiten") erfolgt im Rahmen +eines üblichen HBCI-Dialoges. Bei den folgenden Transaktionsschritten wird +der anonyme Zugang genutzt, d.h. der personalisierte Dialog ist zu beenden und +im Anschluss ein anonymer Dialog zu öffnen. + +. Durch die Nutzung des anonymen Dialoges steht die standardmäßige Ver- +schlüsselung von HBCI nicht mehr zur Verfügung. Daher wird ein Sessions- +chlüssel in Form einer Zufallszahl von der Chipkarte generiert und im Endgerät +im Klartext (skey1) gespeichert. Dieser wird für die Verschlüsselung der Daten in +den weiteren HBCI-Nachrichten verwendet. Damit die Kreditinstitutsseite eben- +falls über den Sessionschlüssel skey1 verfügt, wird dieser im nächsten Schritt +HBCI-gesichert übertragen. + +Realisierung Bank: optional + +Realisierung Kunde: optional + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle
Sonstiges		Stand: 07.08.2015Seite: 299
+ + +###### C.9.3.2.1 Laden GeldKarte vorbereiten + + + + + + + + + + + + + +
RealisierungBank:optional
RealisierungKunde:optional
+ + +####### a) Kundenauftrag + + +######## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Laden GeldKarte vorbereiten
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKLGV
Bezugssegment:-
Version:2
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung Auftraggeber2DEGktv#M1
3Kartenidentifikati- onsdaten1DEbin22C1M: für GeldKarte und HBCI werden nicht die selbe Kar- te benutzt N: sonst
4Ladebetrag1DEGbtg#M1>0
5Kundensystem-ID1DEid#M1
6Geldkartenstatus1DEbin1M1
7Sessionschlüssel skey11DEbin16M1
+ + +####### . Belegungsrichtlinien + + +######## Kontoverbindung Auftraggeber + +Von diesem Konto soll der Ladebetrag abgebucht werden. Das heißt, dass +der Ladebetrag an diesem Konto autorisiert werden muss. + + +####### Kundensystem-ID + +Die Kundensystem-ID wird in der Ladeanwendung dazu benutzt, den Endge- +rät-spezifischen Schlüssel KTRANS aus dem Masterschlüssel KGKTRANS abzu- +leiten. Außerdem muss eine eindeutige Identifikation des Endgerätes gelie- +fert werden, weil in der Ladeanfrage an die Ladezentrale eine eindeutige +Terminal-ID und der Standort des Ladeterminals mit zu übermitteln ist. + + +####### b) Kreditinstitutsrückmeldung + + +######## . Beschreibung + +Für die verschlüsselte Übertragung der Daten zum Endgerät in den nächsten Schrit- +ten wird ein weiterer Sessionschlüssel skey2 benötigt. Dieser wird von der Ladean- +wendung generiert und bis zum Abschluss des Ladevorgangs gespeichert. Hierzu +wird folgende HBCI-Antwortnachricht aufgebaut. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 300Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Sonstiges
+ + +####### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Laden GeldKarte vorbereiten Antwort
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HILGV
Bezugssegment:HKLGV
Version:2
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Sessionnummer1DEnum.10M1
3Sessionschlüssel skey21DEbin16M1
+ + +####### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
9010Autorisierungssystem nicht erreichbar
9120Vorgang mit selber GeldKarte noch offen
9130Kontodaten falsch
9210Konto nicht vorhanden
9210Ladebetrag muss größer 0 sein
9210Kundensystem-ID nicht zugelassen oder falsch
9210Kartendaten falsch
9210Sessionschlüssel skey1 fehlerhaft oder schwach
9230Unzureichendes Guthaben des Kontos
9380GeldKarte zum Laden von diesem Konto nicht zugelassen
+ + +####### c) Bankparameterdaten + + +######## . Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + +######## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Laden GeldKarte vorbereiten Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HILGVS
Bezugssegment:HKVVB
Version:2
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SonstigesStand: 07.08.2015Seite: 301
+ + +###### C.9.3.2.2 Laden GeldKarte einleiten + +Es wird eine HBCI-Nachricht zum Einleiten des Ladens aufgebaut und zum Bank- +system gesendet. Ziel dieser Nachricht ist es, das Geldkarten-Kommando "Laden +Einleiten" vom Banksystem generieren zu lassen und abzuholen. + +Realisierung Bank: verpflichtend, wenn der Geschäftsvorfall ,Laden GeldKarte +vorbereiten“ unterstützt wird + +Realisierung Kunde: verpflichtend, wenn der Geschäftsvorfall ,Laden GeldKarte +vorbereiten“ unterstützt wird + + +####### a) Kundenauftrag + + +######## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Laden GeldKarte einleiten
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKLGE
Bezugssegment:-
Version:2
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Sessionnummer1DEnum..10M1
3Geldkartenkom- mando1DEbin.256M1
+ + +####### . Belegungsrichtlinien + + +######## Geldkartenkommando + +CBC-Triple-DES-Chiffre (16 Byte) mit skey1 über den folgenden Daten: + +Nachrichtennummer: Es ist nur der Wert ,1' zulässig, der anzeigt, dass dies +die zweite Nachricht (erste Nachricht des anonymen Zugangs) des Ladens +der GeldKarte ist. + +Zufallszahl (binär, 8 Byte): Die für die externe Authentikation notwendige Zu- +fallszahl der GeldKarte RND1 muss übertragen werden, damit ein korrektes +Geldkarten-Kommando "Laden Einleiten" vom HBCI-Hintergrundsystem er- +zeugt werden kann. + +Filler: Es kann nur verschlüsselt werden, wenn die Anzahl der zu verschlüs- +selnden Bytes ein ganzzahliges Vielfaches von 8 ist (in diesem Fall 16). Die +fehlenden 7 Bytes werden mit '00' aufgefüllt. + + +######## b) Kreditinstitutsrückmeldung + + +######### . Beschreibung + +Die Antwortnachricht enthält das Geldkartenkommando "Laden Einleiten". + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
302		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Sonstiges
+ + +####### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Laden GeldKarte einleiten Antwort
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HILGE
Bezugssegment:HKLGE
Anzahl:1
Version:2
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Sessionnummer1DEnum.10M1
3Geldkartenkom- mando1DEbin256M1
+ + +####### . Belegungsrichtlinien + + +######## Geldkartenkommando + +CBC-Triple-DES-Chiffre (56 Byte) mit skey2 über den folgenden Daten: + +Nachrichtennummer: Es ist nur der Wert ,1' zulässig, die anzeigt, dass dies +die zweite Nachricht (erste Nachricht des anonymen Zugangs) des Ladens +der GeldKarte ist. + +Geldkartenkommando ,,Laden einleiten“ (binär, 51 Byte): Das Datenfeld ent- +hält das komplette Kommando "Laden Einleiten", dass ohne weitere Modifi- +kationen an die GeldKarte weitergegeben werden kann. + +Filler: Es kann nur verschlüsselt werden, wenn die Anzahl der zu verschlüs- +selnden Bytes ein ganzzahliges Vielfaches von 8 ist (in diesem Fall 56). Die +fehlenden 4 Bytes werden mit '00' aufgefüllt. + + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
9010Ladevorgang abgebrochen
9030Fehler bei der Entschlüsselung
9120Vorgang mit dieser GeldKarte noch nicht geöffnet
9120Falsche Reihenfolge der Nachrichten
+ + +## c) Bankparameterdaten + + +### . Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Laden GeldKarte einleiten Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HILGES
Bezugssegment:HKVVB
Version:2
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SonstigesStand: 07.08.2015Seite: 303
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
304		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Sonstiges
+ + +#### C.9.3.2.3 Laden GeldKarte durchführen + + + + + + + + + + + + + + + +
Realisierung Bank:verpflichtend, wenn der Geschäftsvorfall
vorbereiten“ unterstützt wird		,,LadenGeldKarte
Realisierung Kunde:verpflichtend, wenn der Geschäftsvorfall
vorbereiten“ unterstützt wird		,,LadenGeldKarte
+ + +##### a) Kundenauftrag + + +###### . Beschreibung + +Das nächste Chipkartenkommando "Laden" muss vom Kreditinstitutssystem ange- +fordert werden. + + +###### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Laden GeldKarte durchführen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKLGD
Bezugssegment:-
Version:2
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Sessionnummer1DEnum..10M1
3Geldkartenkom- mando1DEbin.256M1
+ + +###### . Belegungsrichtlinien + + +###### Geldkartenkommando + +CBC-Triple-DES-Chiffre (80 Byte) mit skey1 über den folgenden Daten: + +Nachrichtennummer: Es ist nur der Wert ,2' zulässig, die anzeigt, dass dies +die dritte Nachricht (2. Nachricht des anonymen Zugangs) des Ladens der +GeldKarte ist. + +Geldkartendaten (binär, 66 Byte): Die Antwortdaten des in Schritt 12 ausge- +führten Geldkarten-Kommandos "Laden Einleiten" müssen zur Ladezentrale +übermittelt werden. Der Returncode der GeldKarte braucht nicht mit übermit- +telt zu werden. + +Zufallszahl (binär, 8 Byte): Die für die externe Authentikation notwendige Zu- +fallszahl der GeldKarte RND3 muss übertragen werden, damit ein korrektes +Geldkarten-Kommando "Laden" vom HBCI-Hintergrundsystem erzeugt wer- +den kann. + +Filler: Es kann nur verschlüsselt werden, wenn die Anzahl der zu verschlüs- +selnden Bytes ein ganzzahliges Vielfaches von 8 ist (in diesem Fall 80). Die +fehlenden 5 Bytes werden mit '00' aufgefüllt. + + +## b) Kreditinstitutsrückmeldung + + +### . Beschreibung + +Das Geldkarten-Kommando wird in eine HBCI-Antwortnachricht integriert. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SonstigesStand: 07.08.2015Seite: 305
+ + +# . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Laden GeldKarte durchführen Antwort
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HILGD
Bezugssegment:HKLGD
Version:2
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Sessionnummer1DEnum..10M1
3Geldkartenkom- mando1DEbin.256M1
+ + +# . Belegungsrichtlinien + + +## Geldkartenkommando + +CBC-Triple-DES-Chiffre (72 Byte) mit skey2 über den folgenden Daten: + +Nachrichtennummer: Es ist nur der Wert ,2' zulässig, die anzeigt, dass dies +die dritte Nachricht (2. Nachricht des anonymen Zugangs) des Ladens der +GeldKarte ist. + +Geldkartenkommando (binär, 66 Byte): Das Datenfeld enthält das komplette +Kommando "Laden", dass ohne weitere Modifikationen an die GeldKarte wei- +tergegeben werden kann. + +Filler: Es kann nur verschlüsselt werden, wenn die Anzahl der zu verschlüs- +selnden Bytes ein ganzzahliges Vielfaches von 8 ist (in diesem Fall 72). Die +fehlenden 5 Bytes werden mit '00' aufgefüllt. + + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeRückmeldungstext
0020Auftrag ausgeführt
9010Zuständiges AS nicht erreichbar
9010Zuständiges AS nicht verfügbar
9030Fehler bei der Entschlüsselung
9120Vorgang mit dieser GeldKarte noch nicht geöffnet
9120Falsche Reihenfolge der Nachrichten
9210Ladebetrag abweichend
9210Kartendaten abweichend
9340Fehler in BMP 62, insbesondere MAC-Fehler
9340Daten der GeldKarte falsch
9390Sequenzfehler in BMP 62
9400Die Karte ist nicht zugelassen
9400Karte aus Sicherheitsgründen abweisen
9400Gültigkeitsdauer überschritten oder Karte nicht aktiviert
9400Entschlüsselte Kartendaten unbekannt oder fehlerhaft
9400Die Karte ist gesperrt
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
306		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Sonstiges
+ + +# c) Bankparameterdaten + + +## . Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Laden GeldKarte durchführen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HILGDS
Bezugssegment:HKVVB
Version:2
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SonstigesStand: 07.08.2015Seite: 307
+ + +### C.9.3.2.4 Laden GeldKarte bestätigen + +Um zu überprüfen, ob das Laden erfolgreich durchgeführt werden konnte, wird die +Antwort der GeldKarte an das Kreditinstitutssystem gesendet. Dazu wird die folgen- +de HBCI-Nachricht aufgebaut. + +Realisierung Bank: verpflichtend, wenn der Geschäftsvorfall ,Laden GeldKarte +vorbereiten“ unterstützt wird + +Realisierung Kunde: verpflichtend, wenn der Geschäftsvorfall ,Laden GeldKarte +vorbereiten“ unterstützt wird + + +## a) Kundenauftrag + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Laden GeldKarte bestätigen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKLGB
Bezugssegment:-
Version:2
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Sessionnummer1DEnum..10M1
3Geldkartenkom- mando1DEbin.256M1
+ + +## . Belegungsrichtlinien + + +### Geldkartenkommando + +CBC-Triple-DES-Chiffre (24 Byte) mit skey1 über den folgenden Daten: + +Nachrichtennummer: Es ist nur der Wert ,3' zulässig, der anzeigt, dass dies +die vierte Nachricht (3. Nachricht des anonymen Zugangs) des Ladens der +GeldKarte ist. + +Geldkartendaten (binär, 18 Byte): Die Antwortdaten des GeldKarten- +Kommandos "Laden" (insbesondere der KLT-MAC der GeldKarte) müssen +vom HBCI-Hintergrundsystem in seiner Eigenschaft als Ladeterminal über- +prüft werden. + +Filler: Es kann nur verschlüsselt werden, wenn die Anzahl der zu verschlüs- +selnden Bytes ein ganzzahliges Vielfaches von 8 ist (in diesem Fall 24). Die +fehlenden 5 Bytes werden mit '00' aufgefüllt. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
308		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Sonstiges
+ + +# b) Kreditinstitutsrückmeldung + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Laden GeldKarte bestätigen Antwort
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HILGB
Bezugssegment:HKLGB
Version:2
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Sessionnummer1DEnum..10M1
3Geldkartenkom- mando1DEbin.256M1
+ + +## . Belegungsrichtlinien + + +### Geldkartenkommando + +CBC-Triple-DES-Chiffre (8 Byte) mit skey2 über die Nachrichtennummer. Als +Nachrichtennummer ist der Wert ,3' anzugeben, da dies die dritte Nachricht +des anonymen Zugangs des Ladens der GeldKarte ist.. Da nur verschlüsselt +werden kann, wenn die Anzahl der zu verschlüsselnden Bytes ein ganzzahli- +ges Vielfaches von 8 ist, werden die fehlenden 7 Bytes mit '00' aufgefüllt. + + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeRückmeldungstext
0020Auftrag ausgeführt
3010Laden nicht erfolgreich, Storno einleiten
9030Fehler bei der Entschlüsselung
9120Vorgang mit dieser GeldKarte noch nicht geöffnet
9120Falsche Reihenfolge der Nachrichten
9130Kontodaten falsch
9210Geldkartendaten abweichend
9210Nachrichten-ID falsch
+ + +## c) Bankparameterdaten + + +### . Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Laden GeldKarte bestätigen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HILGBS
Bezugssegment:HKVVB
Version:2
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SonstigesStand: 07.08.2015Seite: 309
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
310		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Sonstiges
+ + +#### C.9.3.3 Laden GeldKarte Status + +Das Laden der GeldKarte über HBCI beinhaltet eine komplexe Ablauflogik. Durch +die vielen Dialogschritte ist die Wahrscheinlichkeit, dass ein Ladevorgang fehl- +schlägt, nicht zu vernachlässigen. Besonders nachteilig ist die Tatsache, dass Ab- +brüche in Situationen auftreten können, in denen für das Endgerät und damit für den +Benutzer der Status des Ladevorgangs unklar ist. Daher können mit dem nachfol- +genden Geschäftsvorfall die entsprechenden Hintergrundsysteme abgefragt und der +Zustand des Ladevorgangs sowie die daraus für den Benutzer resultierenden Kon- +sequenzen in einer verständlichen Form angezeigt werden. + +Realisierung Bank: verpflichtend, wenn der Geschäftsvorfall ,Laden GeldKarte +vorbereiten“ unterstützt wird + +Realisierung Kunde: verpflichtend, wenn der Geschäftsvorfall ,Laden GeldKarte +vorbereiten“ unterstützt wird + + +##### a) Kundenauftrag + + +###### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Laden GeldKarte Statusanfrage
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKLGS
Bezugssegment:-
Version:2
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Terminal-ID1DEid#M1
3Kartenidentifikati- onsdaten1DEbin22C1M: für die Applikationen ,GeldKarte' und ,HBCI' wer- den verschiedene Karten verwendet O: sonst
4Geldkartenladein- formation1DEbin33M1
+ + +# b) Kreditinstitutsrückmeldung + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Laden GeldKarte Status
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HILGS
Bezugssegment:HKLGS
Version:2
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SonstigesStand: 07.08.2015Seite: 311
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Geldkartenladesta- tus1DEnum..2M1
3Geldkartenladesta- tus, Text1DEan..80O1
+ + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Ladevorgang erfolgreich
9201Ladevorgang abgebrochen, Ladebetrag wird nicht eingezogen
9201Ladevorgang abgebrochen, Ladebetrag wird aus Sicherheitsgründen eingezogen
+ + +# c) Bankparameterdaten + + +## . Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Laden Geldkarte Statusanfrage Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HILGSS
Bezugssegment:HKVVB
Version:2
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
312		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Sonstiges
+ + +### C.9.3.4Laden GeldKarte Storno + + +#### C.9.3.4.1 Laden GeldKarte Storno vorbereiten + + +##### a) Kundenauftrag + + +###### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Laden GeldKarte Storno vorbereiten
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKLGO
Bezugssegment:-
Version:2
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Sessionnummer1DEnum..10M1
3Geldkartenkom- mando1DEbin.256M1
+ + +##### . Belegungsrichtlinien + + +###### Geldkartenkommando + +CBC-Triple-DES-Chiffre (16 Byte) mit skey1 über den folgenden Daten: + +Nachrichtennummer: Es ist nur der Wert ,4' zulässig, die anzeigt, dass dies +die erste Nachricht (4. Nachricht des anonymen Zugangs) des Stornos ist. + +Zufallszahl (binär, 8 Byte): Die für die externe Authentikation notwendige Zu- +fallszahl der GeldKarte RND5 muss übertragen werden, damit ein korrektes +Geldkarten-Kommando "Laden Einleiten" vom HBCI-Hintergrundsystem er- +zeugt werden kann. + +Filler: Es kann nur verschlüsselt werden, wenn die Anzahl der zu verschlüs- +selnden Bytes ein ganzzahliges Vielfaches von 8 ist (in diesem Fall 16). Die +fehlenden 7 Bytes werden mit '00' aufgefüllt. + + +###### b) Kreditinstitutsrückmeldung + + +####### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Laden GeldKarte Storno vorbereiten Antwort
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HILGO
Bezugssegment:HKLGO
Version:2
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Sessionnummer1DEnum.10M1
3Geldkartenkom-1DEbin.256M1
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:GeschäftsvorfälleStand:Seite:
Abschnitt:Sonstiges07.08.2015313
+ + + + + + + + + + + + + + +
mando
+ + +# . Belegungsrichtlinien + + +## Geldkartenkommando + +CBC-Triple-DES-Chiffre (56 Byte) mit skey2 über folgende Daten: + +Nachrichtennummer: Es ist nur der Wert ,4' zulässig, der anzeigt, dass dies +die erste Nachricht (4. Nachricht des anonymen Zugangs) des Stornos ist. + +Geldkarten-Kommando (binär, 51 Byte): Das Datenfeld enthält das komplette +Kommando "Laden Einleiten", dass ohne weitere Modifikationen an die +GeldKarte weitergegeben werden kann. + +Filler: Es kann nur verschlüsselt werden, wenn die Anzahl der zu verschlüs- +selnden Bytes ein ganzzahliges Vielfaches von 8 ist (in diesem Fall 56). Die +fehlenden 4 Bytes werden mit '00' aufgefüllt. + + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
9030Fehler bei der Entschlüsselung
9120Vorgang mit dieser GeldKarte noch nicht geöffnet
9120Vorgang mit dieser GeldKarte bereits abgeschlossen
9120Falsche Reihenfolge der Nachrichten
+ + +## c) Bankparameterdaten + + +### . Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Laden GeldKarte Storno vorbereiten Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HILGOS
Bezugssegment:HKVVB
Version:2
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
314		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Sonstiges
+ + +#### C.9.3.4.2 Laden GeldKarte Storno durchführen + + +##### a) Kundenauftrag + + +###### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Laden GeldKarte Storno durchführen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKLGT
Bezugssegment:-
Version:2
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
Segmentkopf1DEGM1
Sessionnummer1DEnum..10M1
Geldkartenkom- mando1DEbin.256M1
+ + +### . Belegungsrichtlinien + + +#### Geldkartenkommando + +CBC-Triple-DES-Chiffre (80 Byte) mit skey1 über den folgenden Daten: + +Nachrichtennummer (1 Byte): Es ist nur der Wert ,5' zulässig, der anzeigt, +dass dies die zweite Nachricht (5. Nachricht des anonymen Zugangs) des +Stornos ist. + +Geldkartendaten (binär, 66 Byte): Die Antwortdaten des in Schritt 12 ausge- +führten Geldkarten-Kommandos "Laden Einleiten" müssen zur Ladezentrale +übermittelt werden. Der Returncode der GeldKarte braucht nicht mit übermit- +telt zu werden. + +Zufallszahl (binär, 8 Byte): Die für die externe Authentikation notwendige +Zufallszahl der GeldKarte RND7 muss übertragen werden, damit ein korrek- +tes Geldkarten-Kommando "Laden" vom HBCI-Hintergrundsystem erzeugt +werden kann. + +Filler: Es kann nur verschlüsselt werden, wenn die Anzahl der zu verschlüs- +selnden Bytes ein ganzzahliges Vielfaches von 8 ist (in diesem Fall 80). Die +fehlenden 5 Bytes werden mit '00' aufgefüllt. + + +## b) Kreditinstitutsrückmeldung + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Laden GeldKarte Storno durchführen Antwort
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HILGT
Bezugssegment:HKLGT
Version:2
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:GeschäftsvorfälleStand:Seite:
Abschnitt:Sonstiges07.08.2015315
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Sessionnummer1DEnum..10M1
3Geldkartenkom- mando1DEbin.256M1
+ + +# . Belegungsrichtlinien + + +## Geldkartenkommando + +CBC-Triple-DES-Chiffre (72 Byte) mit skey2 über folgende Daten: + +Nachrichtennummer: Es ist nur der Wert ,5' zulässig, der anzeigt, dass dies +die zweite Nachricht (5. Nachricht des anonymen Zugangs) des Stornos ist. + +Geldkartenkommando (binär, 66 Byte): Das Datenfeld enthält das komplette +Kommando "Laden", dass ohne weitere Modifikationen an die GeldKarte wei- +tergegeben werden kann. + +Filler: Es kann nur verschlüsselt werden, wenn die Anzahl der zu verschlüs- +selnden Bytes ein ganzzahliges Vielfaches von 8 ist (in diesem Fall 72). Die +fehlenden 5 Bytes werden mit '00' aufgefüllt. + + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
9010Zuständiges AS nicht erreichbar
9010Zuständiges AS nicht verfügbar
9030Fehler bei der Entschlüsselung
9120Vorgang mit dieser GeldKarte noch nicht geöffnet
9120Falsche Reihenfolge der Nachrichten
9210Ladebetrag abweichend
9210Kartendaten abweichend
9340Fehler in BMP 62, insbesondere MAC-Fehler
9340Daten der GeldKarte falsch
9390Sequenzfehler in BMP 62
9400Die Karte ist nicht zugelassen
9400Karte aus Sicherheitsgründen abweisen
9400Gültigkeitsdauer überschritten oder Karte nicht aktiviert
9400Entschlüsselte Kartendaten unbekannt oder fehlerhaft
9400Die Karte ist gesperrt
+ + +### c) Bankparameterdaten + + +#### . Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
316		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Sonstiges
+ + +# . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Laden GeldKarte Storno durchführen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HILGTS
Bezugssegment:HKVVB
Version:2
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle
Sonstiges		Stand: 07.08.2015Seite: 317
+ + +## C.9.3.4.3 Laden GeldKarte Storno bestätigen + + +### a) Kundenauftrag + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Laden GeldKarte Storno bestätigen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKLGX
Bezugssegment:-
Version:2
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Sessionnummer1DEnum..10M1
3Geldkartenkom- mando1DEbin.256M1
+ + +# . Belegungsrichtlinien + + +## Geldkartenkommando + +CBC-Triple-DES-Chiffre mit skey1 über den folgenden Daten: + +Nachrichtennummer: Es ist nur der Wert ,6' zulässig, der anzeigt, dass dies +die dritte Nachricht (6. Nachricht des anonymen Zugangs) des Stornos ist. + +GeldKarten-Daten (binär, 18 Byte): Wenn der gesamte Stornodialog von +Schritt 1 bis hierher abgearbeitet wurde, müssen die Antwortdaten des in +Schritt 11 ausgeführten Geldkartenkommandos "Laden" (insbesondere der +KLT-MAC der GeldKarte) vom HBCI-Hintergrundsystem in seiner Eigenschaft +als Ladeterminal überprüft werden. Muss nur der autorisierte Ladebetrag +storniert werden, sind keine Geldkartendaten vorhanden; dieses Feld kann +dann leer bleiben. + +Filler: Es kann nur verschlüsselt werden, wenn die Anzahl der zu verschlüs- +selnden Bytes ein ganzzahliges Vielfaches von 8 ist (in diesem Fall 24 bzw. +8). Die fehlenden 5 bzw. 7 Bytes werden mit '00' aufgefüllt. + + +### b) Kreditinstitutsrückmeldung + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Laden GeldKarte Storno Bestätigung
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HILGX
Bezugssegment:HKLGX
Version:2
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
318		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Sonstiges
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Sessionnummer1DEnum..10M1
3Geldkartenkom- mando1DEbin.256M1
+ + +# . Belegungsrichtlinien + + +## Geldkartenkommando + +CBC-Triple-DES-Chiffre (8 Byte) mit skey2 über folgende Daten: + +Nachrichtennummer: Es ist nur der Wert ,6' zulässig, der anzeigt, dass dies +die dritte Nachricht (6. Nachricht des anonymen Zugangs) des Stornos ist. + +Filler: Es kann nur verschlüsselt werden, wenn die Anzahl der zu verschlüs- +selnden Bytes ein ganzzahliges Vielfaches von 8 ist (in diesem Fall 8). Die +fehlenden 7 Bytes werden mit '00' aufgefüllt. + + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
9010Storno nicht erfolgreich
9010Ladebetrag kann nicht erstattet werden
9030Fehler bei der Entschlüsselung
9120Vorgang mit dieser GeldKarte noch nicht geöffnet
9120Falsche Reihenfolge der Nachrichten
9130Kontodaten falsch
9210GeldKarten-Daten abweichend
9210Nachrichten-ID falsch
+ + +### c) Bankparameterdaten + + +#### . Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Laden GeldKarte Storno bestätigen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HILGXS
Bezugssegment:HKVVB
Version:2
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Sonstiges
Geschäftsvorfälle		Stand: 07.08.2015Seite: 319
+ + +##### C.9.4 Empfangsquittung + +Durch das Senden dieses Segmentes bestätigt der Kunde, dass eine Antwortnach- +richt (z.B. ein Kontoauszug) ordnungsgemäß erhalten wurde. Die Quittung bezieht +sich immer auf die unmittelbar vorangegangene Kreditinstitutsantwortnachricht in- +nerhalb eines Dialoges. Optional kann die Quittierung durch einen Quittungscode +ergänzt werden, der ein zusätzlichen Rückschluss auf den zu quittierenden Ge- +schäftsvorfall gewährt. + +Geschäftsvorfälle, für die prinzipiell die Möglichkeit einer Empfangsquittierung be- +steht, weisen in den Bankparameterdaten ein entsprechendes Kennzeichen auf. +Durch das Setzen dieses Kennzeichens teilt das Kreditinstitut mit, dass eine derarti- +ge Quittierung erforderlich ist. + + + + + + + + + + + +
Realisierung Bank:verpflichtend, wenn Geschäftsvorfälle unterstützt werden, die eine Quittierung erfordern
Realisierung Kunde:verpflichtend, wenn Geschäftsvorfälle unterstützt werden, die eine Quittierung erfordern
+ + +###### a) Kundenauftrag + + +####### . Format + +Name: +Empfangsquittung +Typ: +Segment +Segmentart: +Geschäftsvorfall +Kennung: +HKQTG +Bezugssegment: +\- +Version: +1 +Sender: +Kunde + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Quittungscode1DEbin..C1M: vom Kreditinstitut wurde ein Quittungscode gesendet N: sonst
+ + +###### b) Kreditinstitutsrückmeldung + + +####### . Beschreibung + +Allgemeine Kreditinstitutsnachricht ohne Datensegmente + +◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Empfangsquittung erhalten
9210Falsches Codewort
+ + +####### c) Bankparameterdaten + + +####### . Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
320		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Sonstiges
+ + +# . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Empfangsquittung Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIQTGS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SonstigesStand: 07.08.2015Seite: 321
+ + +## C.9.5 Serverzeit + +Dieser Geschäftsvorfall dient dazu, dem Kunden die Möglichkeit zu geben sich über +die aktuelle Zeit des verarbeitenden Systems zu informieren. Diese Möglichkeit ist +zum Beispiel in Hinblick auf Auslandsgeschäfte von Wichtigkeit. + + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +### a) Kundenauftrag + + +#### . Format + +Name: +Serverzeitabfrage +Typ: +Segment +Segmentart: +Geschäftsvorfall +Kennung: +HKSZT +Bezugssegment: +\- +Version: +1 +Sender: +Kunde + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
+ + +### b) Kreditinstitutsrückmeldung + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
. Format
Name:Serverzeit
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HISZT
Bezugssegment:-
Version:1
Sender:Institut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Serverzeit1DEGtsp#M1
3Zeitzone1DEan..4M1
+ + +### . Belegungsrichtlinien + +Serverzeit: + +Die Uhrzeit in der DEG Serverzeit muss für diesen Geschäftsvorfall belegt werden. + +◆ Ausgewählte Beispiele für Rückmeldungscodes + +Code Beispiel für Rückmeldungstext + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
322		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Sonstiges
+ + +0010 +Auftrag entgegengenommen + + +# c) Bankparameterdaten + + +## . Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + +## . Format + +Name: +Serverzeit Parameter +Typ: +Segment +Segmentart: +Geschäftsvorfall +Kennung: +HISZTS +Bezugssegment: +HKVVB +Version: +1 +Sender: +Kreditinstitut + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SonstigesStand: 07.08.2015Seite: 323
+ + +### C.9.6 Kundendaten + + +#### C.9.6.1Anzeige Kundendaten + +Es können Personen- und Adressdaten des auftraggebenden Kunden und - bei Be- +rechtigung - dessen Ehepartners abgerufen werden. + +Realisierung Bank: optional +Realisierung Kunde: optional + + +#### a) Kundenauftrag + + +##### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kundendaten abfragen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKKDD
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung Auftraggeber2DEGktv#M1
+ + +#### b) Kreditinstitutsrückmeldung + + +##### . Beschreibung + +Es wird je ein Segment für einen Stammdatensatz (abfragender Kunde, Ehepartner, +etc.) bei Berechtigung zurückgemeldet. Es können mehrere Adressen zu einem +Stammdatensatz (abfragender Kunde, Ehepartner, etc.) übermittelt werden, z.B. ei- +ne Wohnadresse und eine optionale Versandanschrift. + + +##### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kundendaten rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIKDD
Bezugssegment:HKKDD
Version:1
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kundenstammda- tenart1DEcode1O11, 2, 3, 4, 5, 9
3Personendaten2DEGO1
4Adressdaten1DEGOn
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
324		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Sonstiges
+ + +#### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
3010Es liegen keine Einträge vor
3040Auftrag teilweise ausgeführt
+ + +#### c) Bankparameterdaten + + +##### . Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + +##### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Kundendaten Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIKDDS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + +#### C.9.6.2Adressänderung + +Je nach Angabe in den Adressdaten kann die Privat-, Versand- oder die Ge- +schäftsadresse geändert werden. + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +## a) Kundenauftrag + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
. Format
Name:Adressänderung
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKADR
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung Auftraggeber2DEGktv#M1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SonstigesStand: 07.08.2015Seite: 325
+ + + + + + + + + + + + + + +
3Adressdaten1DEGM1
+ + +## b) Kreditinstitutsrückmeldung + + +### . Format + +Allgemeine Kreditinstitutsnachricht ohne Datensegmente + +◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
0020Änderung ausgeführt
+ + +## c) Bankparameterdaten + + +### . Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Adressänderung Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIADRS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
326		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Sonstiges
+ + +#### C.9.7 Laden Prepaidkarten + + +##### C.9.7.1Prepaidkarte laden + + +###### C.9.7.1.1 Segmentversion 1 + +Das Guthaben von Handy-Prepaidkarten kann über eine Ladetransaktion aufgela- +den werden. Hierzu wird ein entsprechender Ladevorgang beim Mobilfunkbetreiber +initiiert. + + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +####### a) Kundenauftrag + + +######## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Prepaidkarte laden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKPPD
Bezugssegment:-
Segmentversion:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung Auftraggeber2DEGktv#M1
3Mobilfunk-Provider1DEnum..2M1
4Mobilfunknummer1DEan..35M1
5Ladebetrag Prepaid1DEGbtg#M1
+ + +####### . Belegungsrichtlinien + + +######## Nr. 3: Mobilfunk-Provider + +Die vom Kreditinstitut unterstützten Provider werden dem Kundenprodukt in +den Bankparameterdaten mitgeteilt. + + +######## Nr. 4: Mobilfunknummer + +Es sind nur Ziffern inklusive führender Nullen erlaubt und es gilt die nationale +Schreibweise für Telefonnummern, z. B. 0170/1234567 oder (0170) +1234567. + + +######## Nr. 5: Ladebetrag Prepaid + +Die vom Kreditinstitut unterstützten Ladebeträge werden dem Kundenpro- +dukt in den Bankparameterdaten mitgeteilt. Es sind nur ganzzahlige Euro- +Beträge ohne Nachkommastellen zulässig. + + +######## b) Kreditinstitutsrückmeldung + + +######### ◆ Erläuterungen + +Es werden keine Datensegmente zurückgemeldet. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SonstigesStand: 07.08.2015Seite: 327
+ + +######## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag zur Ausführung vorgemerkt
0020Auftrag ausgeführt
3010Ausführung ungewiss, bitte prüfen
9210Gleicher Auftrag bereits ausgeführt
9210Konto nicht vorhanden
9210Aufladung für diese Karte/Telefonnummer nicht möglich
9210Aufladeobergrenze erreicht
9210Abbruch der Aufladung, nicht erfolgreich
9210Ladebetrag wird nicht unterstützt.
9210Telefonnummer ist nicht korrekt.
9230Unzureichendes Guthaben des Kontos
+ + +######## c) Bankparameterdaten + + +######### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Prepaidkarte laden Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIPPDS
Bezugssegment:HKVVB
Segmentversion:1
Sender:Kreditinstitut
Format:Geschäftsvorfallparameter
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Prepaid- karte laden1DEGM1
+ + +###### C.9.7.1.2 Segmentversion 2 + +Das Guthaben von Handy-Prepaidkarten kann über eine Ladetransaktion aufgela- +den werden. Hierzu wird ein entsprechender Ladevorgang beim Mobilfunkbetreiber +initiiert. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
328		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Sonstiges
+ + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +# a) Kundenauftrag + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Prepaidkarte laden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKPPD
Bezugssegment:-
Segmentversion:2
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3Mobilfunk-Provider1DEnum..2M1
4Mobilfunknummer1DEan..35M1
5Ladebetrag Prepaid1DEGbtg#M1
+ + +# . Belegungsrichtlinien + + +## Nr. 3: Mobilfunk-Provider + +Die vom Kreditinstitut unterstützten Provider werden dem Kundenprodukt in +den Bankparameterdaten mitgeteilt. + + +## Nr. 4: Mobilfunknummer + +Es sind nur Ziffern inklusive führender Nullen erlaubt und es gilt die nationale +Schreibweise für Telefonnummern, z. B. 0170/1234567 oder (0170) +1234567. + + +## Nr. 5: Ladebetrag Prepaid + +Die vom Kreditinstitut unterstützten Ladebeträge werden dem Kundenpro- +dukt in den Bankparameterdaten mitgeteilt. Es sind nur ganzzahlige Euro- +Beträge ohne Nachkommastellen zulässig. + + +## b) Kreditinstitutsrückmeldung + + +### ◆ Erläuterungen + +Es werden keine Datensegmente zurückgemeldet. + + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag zur Ausführung vorgemerkt
0020Auftrag ausgeführt
3010Ausführung ungewiss, bitte prüfen
9210Gleicher Auftrag bereits ausgeführt
9210Konto nicht vorhanden
9210Aufladung für diese Karte/Telefonnummer nicht möglich
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SonstigesStand: 07.08.2015Seite: 329
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
9210Aufladeobergrenze erreicht
9210Abbruch der Aufladung, nicht erfolgreich
9210Ladebetrag wird nicht unterstützt.
9210Telefonnummer ist nicht korrekt.
9230Unzureichendes Guthaben des Kontos
+ + +# c) Bankparameterdaten + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Prepaidkarte laden Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIPPDS
Bezugssegment:HKVVB
Segmentversion:2
Sender:Kreditinstitut
Format:Geschäftsvorfallparameter
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Prepaid- karte laden1DEGM1
+ + +# C.9.7.2Dauerauftrag Prepaidkarte laden + +Folgende Geschäftsvorfälle sind vorgesehen: + +· Einrichten eines Dauerauftrags für Prepaidkarte laden + +. Bestandsabfrage der Daueraufträge für Prepaidkarte laden + +· Löschen eines Dauerauftrags für Prepaidkarte laden + +Von den hier dargestellten Aufträgen zu unterscheiden sind vom +Kundenprodukt verwaltete Daueraufträge, d. h. Einzelaufträge vom +Typ ,Prepaidkarte laden (HKPPD)", bei denen das Kundensystem +die Terminverwaltung und regelmäßige Versendung übernimmt. +Diese können für den Kunden insbesondere dann eine Alternative +darstellen, falls entweder das Kundenprodukt oder das Kreditinstitut +keine Dauerauftragsverwaltung für Prepaidkartenzahlungen anbie- +tet. + + +![](figures/49.1) + + +Vor dem Löschen eines Dauerauftrages hat eine Abholung des ak- +tuellen Bestandes beim Kreditinstitut (s. u.) zu erfolgen, um sicher- +zustellen, dass der Kunde auf korrekter Basis operiert. Nur so ist + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
330		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Sonstiges
+ + +gewährleistet, dass zwischenzeitliche Bestandsänderungen auf an- +derem Wege (z. B. schriftlich oder per Selbstbedienungsterminal) +von der Kundensoftware berücksichtigt werden. + +Das Datenformat für Daueraufträge Prepaidkarte laden entspricht dem Format für +den Einzelauftrag ,,Prepaidkarte laden (HKPPD)". Es wird ergänzt um Dauerauftrag +spezifische Informationen. + + +## C.9.7.2.1 Dauerauftrag Prepaidkarte laden einrichten + +Das Guthaben von Handy-Prepaidkarten kann über eine wiederkehrende La- +detransaktion im Sinne eines Dauerauftrags aufgeladen werden. Hierzu werden die +relevanten Daten für einen Ladevorgang beim Mobilfunkbetreiber erfasst und in ent- +sprechenden Beständen geführt. Abhängig von den zeitlichen Festlegungen für den +Dauerauftrag wird dann die jeweilige Ladetransaktion initiiert. + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +## a) Kundenauftrag + + +### Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Dauerauftrag Prepaidkarte laden einrichten
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKPPE
Bezugssegment:-
Segmentversion:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3Mobilfunk-Provider1DEnum..2M1
4Mobilfunknummer1DEan..35M1
5Ladebetrag Prepaid1DEGbtg#M1
6Dauerauftragdetails3DEGM1
+ + +## Belegungsrichtlinien + + +### Nr. 3: Mobilfunk-Provider + +Die vom Kreditinstitut unterstützten Provider werden dem Kundenprodukt in +den Bankparameterdaten mitgeteilt. + + +### Nr. 4: Mobilfunknummer + +Es sind nur Ziffern inklusive führender Nullen erlaubt und es gilt die nationale +Schreibweise für Telefonnummern, z. B. 0170/1234567 oder (0170) +1234567. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SonstigesStand: 07.08.2015Seite: 331
+ + +### Nr. 5: Ladebetrag Prepaid + +Die vom Kreditinstitut unterstützten Ladebeträge werden dem Kundenpro- +dukt in den Bankparameterdaten mitgeteilt. Es sind nur ganzzahlige Euro- +Beträge ohne Nachkommastellen zulässig. + + +### b) Kreditinstitutsrückmeldung + + +#### Beschreibung + + +![](figures/51.1) + + +Falls das Kreditinstitut schon bei der Einrichtung eine Auf- +tragsidentifikation zurückmelden kann, sollte diese Möglichkeit ge- +nutzt werden. Andernfalls hat das Kundensystem vor einer Ände- +rung oder Löschung den gesamten Bestand abzurufen (s. +C.9.7.2.2 ,,Bestandsabfrage der Dauerauftrage Prepaidkarte_la- +den"), um in den Besitz der Auftragsidentifikation zu gelangen. + + +#### Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Dauerauftrag Prepaidkarte laden bestätigen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIPPE
Bezugssegment:HKPPE
Version:1
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Auftragsidentifikati- on1DEan..99O1
+ + +#### Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag zur Ausführung vorgemerkt
0020Auftrag ausgeführt
3010Ausführung ungewiss, bitte prüfen
9210Gleicher Auftrag bereits ausgeführt
9210Konto nicht vorhanden
9210Aufladung für diese Karte/Telefonnummer nicht möglich
9210Aufladeobergrenze erreicht
9210Abbruch der Aufladung, nicht erfolgreich
9210Ladebetrag wird nicht unterstützt.
9210Telefonnummer ist nicht korrekt.
9210Der angegebene Turnus ist kein Ausführungsturnus
9230Unzureichendes Guthaben des Kontos
+ + +#### c) Bankparameterdaten + + +##### Format + +Name: +Dauerauftrag Prepaidkarte laden einrichten Parameter + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
332		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Sonstiges
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIPPES
Bezugssegment:HKVVB
Segmentversion:1
Sender:Kreditinstitut
Format:Geschäftsvorfallparameter
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Dauer- auftrag Prepaidkar- te laden einrichten1DEGM1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SonstigesStand: 07.08.2015Seite: 333
+ + +###### C.9.7.2.2 Bestandsabfrage der Daueraufträge Prepaidkarte laden + +Für jeden Dauerauftrag wird ein Segment "Dauerauftrag Prepaidkarte laden rück- +melden" als Datensegment in der Rückmeldungsnachricht übermittelt. Der Dauer- +auftrag wird so angezeigt, wie er zum nächsten Termin ausgeführt würde. + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +#### a) Kundenauftrag + + +##### Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Bestand Daueraufträge Prepaidkarte laden anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKPPB
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3Auftragsidentifikati- on1DEan..99O1
4Maximale Anzahl EinträgeDEnum..4C1>0
O: ,,Eingabe Anzahl Ein- träge erlaubt“ (BPD) = ,J“ N: sonst
5AufsetzpunktDEan..35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +#### . Belegungsrichtlinien + +Auftragsidentifikation + +Wird das DE ,,Auftragsidentifikation" belegt, wird der entsprechende Dauerauftrag +angezeigt. Wird dieses Feld leer gelassen, kommen alle Daueraufträge Prepaidkar- +te laden des Kontos zur Anzeige. + + +#### b) Kreditinstitutsrückmeldung + + +#### Beschreibung + +Für jeden Dauerauftrag Prepaidkarte laden wird ein Segment zurückgemeldet. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 334Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Sonstiges
+ + +#### Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Bestand Daueraufträge Prepaidkarte laden rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIPPB
Bezugssegment:HKPPB
Version:1
Sender:Kreditinstitut
Anzahl:n
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3Mobilfunknummer1DEan..35M1
4Ladebetrag Prepaid1DEGbtg#M1
5Auftragsidentifikati- on1DEan..99M1
6Dauerauftragdetails3DEGM1
7Auftrag löschbar1DEjn#O1
18Providermerkmale1DEGM..99
+ + +#### Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
3010Es liegen keine Einträge vor
9210Bereichende darf nicht vor Bereichanfang liegen
+ + +#### c) Bankparameterdaten + + +##### Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Bestand Daueraufträge Prepaidkarte laden Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIPPBS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Bestand Daueraufträge Pre- paidkarte laden1DEGM1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SonstigesStand: 07.08.2015Seite: 335
+ + +# C.9.7.2.3 Löschen Dauerauftrag Prepaidkarte laden + +Löschungen gelten, sofern nichts anderes bestimmt ist, ab sofort. Daruber hinaus +kann das Kreditinstitut in der BPD festlegen, ob es zusatzlich terminierte Löschun- +gen erlaubt. Die Eingabe einer terminierten Löschung überschreibt einen evtl. vor- +her eingegebenen terminierten Löschauftrag. + + +![](figures/55.1) + + +Bei Daueraufträgen Prepaidkarte laden muss zwingend eine Auf- +tragsidentifikation unterstützt werden, da ansonsten die Identifikati- +on des zu löschenden Dauerauftrags Prepaidkarte laden nicht mög- +lich ist. + +Realisierung Bank: +optional + +Realisierung Kunde: optional + + +## a) Kundenauftrag + + +### . Beschreibung + +Es sind die gültigen Daten des Dauerauftrags Prepaidkarte laden einzustellen. Die- +se dienen zu Plausibilitätsprüfungen. + +Format + +Name: + +Löschen Dauerauftrag Prepaidkarte laden + +Typ: +Segment + +Segmentart: +Geschäftsvorfall + +Kennung: +HKPPL + +Bezugssegment: +\- + +Version: +1 + +Sender: + +Kunde + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3AusführungsdatumDEdat#C1O: DE „Löschung terminier- bar" (BPD) = ,,J" N: sonst
4Auftragsidentifikati- on1DEan..99C1M: Auftragsidentifikation wurde vom Institut erteilt N: sonst
+ + +## Belegungsrichtlinien + +Ausführungsdatum + +Falls terminierte Loschungen erlaubt sind (s. DE ,,Loschung terminierbar" in den +Bankparameterdaten), ist hier ist das Löschdatum einzustellen. Es muss sich dabei +um ein Datum handeln, zu dem eine Ausführung stattfinden würde. Der Dauerauf- +trag wird an dem angegebenen Datum nicht mehr ausgeführt. Ist das DE nicht ein- +gestellt, so wird die Löschung sofort wirksam. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
336		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Sonstiges
+ + +### b) Kreditinstitutsrückmeldung + + +#### . Beschreibung + +Es werden keine Datensegmente zurückgemeldet. + +◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Dauerauftrag Prepaidkarte laden zur Löschung vorgemerkt
0020Dauerauftrag Prepaidkarte laden gelöscht
9010Dauerauftrag Prepaidkarte laden bereits zur Löschung vorgemerkt
9160Auftragsidentifikation fehlt
9210Datum liegt zu weit in der Zukunft
9210Datum liegt nicht in der Zukunft
9210Auftrag existiert nicht, Auftragsidentifikation unbekannt
9210Kontoverbindung des Auftraggebers stimmt nicht überein
9210Das angegebene Datum ist kein Ausführungsdatum
+ + +#### c) Bankparameterdaten + +Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Löschen Dauerauftrag Prepaidkarte laden Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIPPLS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Löschen Dauerauftrag Pre- paidkarte laden1DEGM1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SonstigesStand: 07.08.2015Seite: 337
+ + +# C.9.8 Willenserklärung des Kunden + +Mit diesem Geschäftsvorfall ist es möglich, ein zuvor übertragenes Datenelement +„Bestätigungstext“ eines Bezugs-Geschäftsvorfalls durch eine bewusste Interaktion +des Kunden als Willenserklärung bestätigen zu lassen. Die rechtliche Wirksamkeit +dieser Willenserklärung ist abhängig vom verwendeten Sicherheitsverfahren. + +Der GV ,,Willenserklärung des Kunden“ kann nicht eigenständig ausgeführt werden, +sondern muss auf einen anderen Bezugs-Geschäftsvorfall (z. B. ,,Elektronischen +Kontoauszug beantragen" (HKEKB), vgl. Abschnitt C.9.9) folgen, bei dem in der +Kreditinstitutsnachricht das Datenelement „Bestätigungstext“ und ggf. ein entspre- +chender Bestätigungscode und auch eine Auftragsreferenz übertragen wird. Auf +diese Angaben (z. B. in HIEKB) bezieht sich die Willenserklärung des Kunden, die +dann mit HKWEK eingereicht wird. + +Die Willenserklärung bezieht sich immer auf die unmittelbar vorangegangene Kredit- +institutsantwortnachricht innerhalb eines Dialoges. + +Geschäftsvorfälle, für die prinzipiell die Möglichkeit einer Willenserklärung besteht, +weisen in den Bankparameterdaten ein entsprechendes Kennzeichen „Willenserklä- +rung erforderlich" auf. Durch das Setzen dieses Kennzeichens teilt das Kreditinstitut +mit, dass eine derartige Willenerklärung erforderlich ist. + + +![](figures/57.1) + + +Ein Kundenprodukt sollte dem Kunden den „Bestätigungstext“ an- +zeigen und ihm die Möglichkeit geben, diesen z. B. mit Hilfe einer +Checkbox zu bestätigen. Der Kunde sollte darauf hingewiesen wer- +den, dass er durch Absenden dieser Maske dem angezeigten Text +ausdrücklich zustimmt. + + + + + + + + + + + +
Realisierung Bank:verpflichtend, wenn Geschäftsvorfälle unterstützt werden, die eine Willenserklärung erfordern
Realisierung Kunde:verpflichtend, wenn Geschäftsvorfälle unterstützt werden, die eine Willenserklärung erfordern
+ + +## a) Kundenauftrag + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Willenserklärung des Kunden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKWEK
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
338		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Sonstiges
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Ergebnis Kundenin- teraktion1DEcode1M1
3Bestätigungstext1DEan.655 35C1M: wenn DE „Bestätigungs- code" im Bezugs-GV nicht belegt ist. N: sonst
4Bestätigungscode1DEbin..C1M: wenn DE „Bestätigungs- code" im Bezugs-GV belegt ist.
O: sonst
5Auftragsreferenz1DEan..35C1M: wenn DE ,,Auftragsrefe- renz" im Bezugs-GV belegt ist.
O: sonst
+ + +## . Belegungsrichtlinien + + +### Bestätigungstext + +Falls das Datenelement „Bestätigungscode“ in der Kreditinstitutsantwort des Be- +zugs-Geschäftsvorfalls belegt war, darf der Bestätigungstext selbst in HKWEK nicht +belegt werden, da das Institut keine erneute Übertragung wünscht, sondern die Ein- +deutigkeit der zu bestätigenden Daten über den Bestätigungscode herstellt. + + +### b) Kreditinstitutsrückmeldung + + +#### . Beschreibung + +Es werden keine Datensegmente zurückgemeldet. + + +#### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
+ + +### c) Bankparameterdaten + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Willenserklärung des Kunden Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIWEKS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:GeschäftsvorfälleStand:Seite:
Abschnitt:Sonstiges07.08.2015339
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Willens erklärung des Kunden1DEGM1
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
340		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Sonstiges
+ + +# C.9.9 Elektronischen Kontoauszug beantragen + +Mit Hilfe dieses Geschäftsvorfalls kann ein Kunde dem Kreditinistitut mitteilen, dass +er zukünftig seine Kontoauszüge auf elektronischem Weg und nicht mehr papierhaft +erhalten möchte. Diese Möglichkeit gilt bisher ausschließlich für Privatkunden. Die +rechtlichen und geschäftspolitischen Voraussetzungen für den ,Elektronischen Kon- +toauszug" sind ggf. in separaten Dokumenten zu entnehmen. + +Für die Bestätigung der Beantragung des elektronischen Kontoauszugs durch den +Kunden wird der Geschäftsvorfall „Willenserklärung des Kunden (HKWEK)" verwen- +det. + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +# a) Kundenauftrag + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Elektronischen Kontoauszug beantragen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKEKB
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
+ + +## . Belegungsrichtlinien + + +### Kontoverbindung international + +Es ist eine gültige Kontoverbindung des Kunden einzustellen. Falls der elektroni- +sche Kontoauszug für mehrere Konten beantragt werden soll, ist für jede Kontover- +bindung ein separater Auftrag inklusive der Bestätigung durch den Geschäftsvorfall +„Willenserklärung des Kunden (HKWEK)“ zu senden. + + +## b) Kreditinstitutsrückmeldung + + +### . Beschreibung + +Die Datenelemente „Bestätigungstext“, „Bestätigungscode“ (optional) und Auftrags- +referenz (optional) werden für die Willenserklärung des Kunden mit Hilfe des Ge- +schäftsvorfalls HKWEK benötigt. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Bestätigung Elektronischer Kontoauszug beantragen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIEKB
Bezugssegment:HKEKB
Version:1
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SonstigesStand: 07.08.2015Seite: 341
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Bestätigungstext1DEan.655 35M1
3Bestätigungscode1DEbin..O1
4Auftragsreferenz1DEan.35O1
+ + +◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
9210Keine gültige Kontoverbindung des Kunden
+ + +# c) Bankparameterdaten + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Elektronischen Kontoauszug beantragen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIEKBS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Elektro- nischen Kontoaus- zug beantragen1DEGM1
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 342Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Sonstiges
+ + +## C.9.10Elektronisches Postfach + + +### C.9.10.1 Postfach Nachrichtentypen anfordern + +Mit Hilfe dieses Geschäftsvorfalls können die generell möglichen Nachrichtentypen +zum elektronischen Postfach angezeigt werden. + +Realisierung Bank: +optional + +Realisierung Kunde: optional + + +### a) Kundenauftrag + +Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Postfach-Nachrichtentypen anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKPNA
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Ein- träge1DEnum..4C1O: ,,Eingabe Anzahl Ein- träge erlaubt“ (BPD) = „J“ N: sonst
3Aufsetzpunkt1DEan..35C1M: vom Institut wurde ein Aufsetzpunkt rück- gemeldet N: sonst
+ + +### b) Kreditinstitutsrückmeldung + +Format + +Name: +Postfach-Nachrichtentypen rückmelden +Typ: +Segment +Segmentart: +Geschäftsvorfall +Kennung: +HIPNA +Bezugssegment: +HKPΝΑ +Version: +1 +Anzahl: +1 +Sender: +Kreditinstitut + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:GeschäftsvorfälleStand:Seite:
Abschnitt:Sonstiges07.08.2015343
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Nachrichtentypinforma- tion1DEGMn
+ + +### Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
3010Keine Nachrichtentypen vorhanden
+ + +### c) Bankparameterdaten + + +#### Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Postfach-Nachrichtentypen anfordern Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIPNAS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Auf- träge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Postfach Nachrichtentypen an- fordern1DEGM1
+ + +### C.9.10.2 Auswahl Postfach-Nachrichtentypen + +Mit Hilfe dieses Geschäftsvorfalls können die zuvor mit dem Geschäftsvorfall „Post- +fach Nachrichtentypen anfordern" abgefragten moglichen Nachrichtentypen zum +elektronischen Postfach vom Kunden zur Anzeige eingeschränkt bzw. verwaltet +werden. + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +### a) Kundenauftrag + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 344Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Sonstiges
+ + +### Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Postfach-Nachrichtentypen auswählen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKAPN
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Nachrichtentyp1DEan..3Mn
+ + +### Belegungsrichtlinien + +Nachrichtentyp + +Es sind nur die möglichen Nachrichtentypen aus dem Geschäftsvorfall „Postfach +Nachrichtentypen anfordern" zulässig. Im Geschäftsvorfall ,,Postfach Nachrichtenlis- +te anfordern" werden aufgrund der Auswahl in diesem Geschäftsvorfall nur die vor- +handenen Mitteilungen bzw. Nachrichten zu diesen Nachrichtentypen zurückgemel- +det. Es ist jeweils der vollständige Satz der gewünschten Nachrichtentypen einzu- +stellen. Nicht übermittelte Nachrichtentypen werden dem Kunden nicht angezeigt. + + +### b) Kreditinstitutsrückmeldung + + +#### Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Auswahl Postfach-Nachrichtentypen rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIAPN
Bezugssegment:HKAPN
Version:1
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Bestätigungstext1DEan.655 35M1
3Bestätigungscode1DEbinO1
4Auftragsreferenz1DEan..35O1
+ + +### Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
3010Keine Nachrichtentypen vorhanden
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SonstigesStand: 07.08.2015Seite: 345
+ + +### c) Bankparameterdaten + + +#### Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Postfach-Nachrichtentypen auswählen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIAPNS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Auf- träge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Postfach Nachrichtentypen auswählen1DEGM1
+ + +### C.9.10.3 Postfach-Nachrichtenliste anfordern + +Mit Hilfe dieses Geschäftsvorfalls kann die momentan für den Benutzer vorliegende +Liste der Mitteilungen bzw. Nachrichten angezeigt werden. + +Der Geschäftsvorfall ist benutzerbezogen, d. h. Mitteilungen bzw. Nachrichten für +Ehepartner, Bevollmächtigten etc. werden nicht angezeigt. + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +### a) Kundenauftrag + +Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Postfach-Nachrichtenliste anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKPOF
Bezugssegment:-
Version:1
Sender:Kunde
+ + +![Nr. Name Ver- sion Typ For- mat Län- ge Sta- tus An- zahl Restriktionen](figures/65.1) + + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
346		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Sonstiges
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Nachrichtentyp1DEan..3C1O: ,,Nachrichtentyp er- laubt“=J N: sonst
3Maximale Anzahl Ein- träge1DEnum..4C1O: ,,Eingabe Anzahl Ein- träge erlaubt“ (BPD) = „J“ N: sonst
4Aufsetzpunkt1DEan..35C1M: vom Institut wurde ein Aufsetzpunkt rück- gemeldet
N: sonst
+ + +### Belegungsrichtlinien + +Nachrichtentyp + +Falls die Option ,,Nachrichtentyp" gewählt wird, ist ein It. BPD unterstützter Nach- +richtentyp einzustellen. In der Kreditinstitutsantwort werden dann nur die vorhande- +nen Mitteilungen bzw. Nachrichten zu diesem Nachrichtentyp zurückgemeldet. Wird +das Datenelement nicht belegt wird die Liste aller vorhandenen Mitteilungen bzw. +Nachrichten erstellt. + + +### b) Kreditinstitutsrückmeldung + + +#### Beschreibung + +Je vorhandener Mitteilung bzw. Nachricht wird ein Antwortsegment eingestellt. + +Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Postfach-Nachrichtenliste rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIPOF
Bezugssegment:HKPOF
Version:1
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:GeschäftsvorfälleStand:Seite:
Abschnitt:Sonstiges07.08.2015347
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Dokument-ID2DEan.256M1
3Nachrichtentyp1DEan..3O1
4Betrefftext1DEan.80M1
5Bereitstellungsdatum1DEdat#M1
6Nachricht abgerufen1DEin#M1
7Nachricht abgerufen am1DEdat#O1
8Quittierung1DEcode#M10,1,2
9Quittierung bis1DEdat#O1
10Quittierung am1DEdat#O1
11EKA Kontoverbindung1DEGkti#O1
12Aufbewahrungszeit- raum1DEdat#O1
13Formatinformation3DEGO..9
+ + +### Ausgewahlte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
3010Keine Nachrichten vorhanden
+ + +### c) Bankparameterdaten + + +#### Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Postfach-Nachrichtenliste anfordern Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIPOFS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTvpFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Auf- träge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Postfach Nachrichtenliste anfor- dern1DEGM1
+ + +# C.9.10.4 Postfach-Nachricht abrufen + +Nach vorhergehender Abfrage der Postfach-Nachrichtenliste kann eine bestimmte +Nachricht bzw. Mitteilung mit Hilfe dieses Geschäftsvorfalls abgefragt werden. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 348Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Sonstiges
+ + +Realisierung Bank: +optional + +Realisierung Kunde: + +optional + + +## a) Kundenauftrag + + +### Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Postfach-Nachricht abrufen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKKAA
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Dokument-ID2DEan.256C1M: ,,Alle Dokumente" = leer N: sonst
3Formattyp3DEcode1C11-7,9
O: ,Formattyp erlaubt"=J N: sonst
4Alle Dokumente1DEcode1C11,2 M: ,,Alle Dokumente er- laubt" (BPD) = ,J" und "Dokument-ID" = leer N: sonst
5Maximale Anzahl Einträge1DEnum..4C1O: "Eingabe Anzahl Ein- träge erlaubt“ (BPD) = ,J“ N: sonst
6Aufsetzpunkt1DEan..35C1M: vom Institut wurde ein Aufsetzpunkt rückgemel- det N: sonst
+ + +## Belegungsrichtlinien + + +### Dokument-ID + +Falls durch einen vorhergehenden Geschäftsvorfall ,,Postfach-Nachrichtenliste an- +fordern" eine Dokument-ID zu einer bestimmten Nachricht vorliegt, muss diese bei +der Abfrage von einzelnen Nachrichten verwendet werden. + + +### Formattyp + +Falls die Option ,,Formattyp" erlaubt ist und gewählt wird, ist ein It. BPD unterstützter +Formattyp einzustellen. Es ist zu berücksichtigen, dass lediglich ein Formattyp ge- +wählt werden kann in dem das Dokument laut des Geschäftsvorfalls „Postfach +Nachrichtenliste anfordern" vorliegt. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle
Sonstiges		Stand: 07.08.2015Seite: 349
+ + +# b) Kreditinstitutsrückmeldung + + +## . Beschreibung + +Je vorhandener Mitteilung bzw. Nachricht wird ein Antwortsegment eingestellt. + +Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Postfach-Nachricht rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIKAA
Bezugssegment:HKKAA
Version:1
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Dokument-ID2DEan.256M1
3Formattyp3DEcode1M11-7, 9
4Dokument1DEbinM1
5Dateiname1DEan.256O1
6Bezugszeitpunkt1DEtsp#O1
7EKA Kontoverbindung1DEGkti#O1
8Quittungscode1DEbinO1
+ + +## Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
9160Dokument-ID fehlt
9160Dokument-ID existiert nicht
+ + +# c) Bankparameterdaten + +Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Postfach-Nachricht abrufen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIKAAS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Auf- träge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Postfach- Nachricht abrufen1DEGM1
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 350Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Sonstiges
+ + +## C.9.10.5 Postfach-Kontoauszug erstellen + +Auf Basis des Bestandes aus der „Übersicht Kontoauszüge“ können einzelne Kon- +toauszüge zur Ablage im Postfach erstellt werden. + +Realisierung Bank: +optional + +Realisierung Kunde: optional + + +### a) Kundenauftrag + + +#### Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Postfach-Kontoauszug erstellen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKAPE
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung in- ternational1DEGM1
3Kontoauszugsnum- mer1DEnum..5M1
4Kontoauszugsjahr1DEnum..4O1
+ + +### Belegungsrichtlinien + +Kontoauszugsjahr + +Falls ein Institut beim Jahreswechsel die Kontoauszugsnummer neu ab „1“ zu zäh- +len beginnt, muss das Kontoauszugsjahr mitgeschickt werden, um einen Kontoaus- +zug eindeutig zu kennzeichnen. + + +## b) Kreditinstitutsrückmeldung + + +### Beschreibung + +Es wird eine Dokument-ID zurückgemeldet, die bei Folgeaktionen (Postfach- +Nachricht abrufen) angegeben werden muss. + +Format + +Name: +Erstellung Postfach-Kontoauszug bestätigen +Typ: +Segment +Segmentart: +Geschäftsvorfall +Kennung: +HIAPE +Bezugssegment: +HKAPE +Version: +1 +Anzahl: +1 +Sender: +Kreditinstitut + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SonstigesStand: 07.08.2015Seite: 351
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Dokument-ID2DEan.256O1
+ + +# Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Der Auszug wurde im elektronischen Postfach bereitgestellt
9010Der Auszug konnte im elektronischen Postfach nicht bereitgestellt werden
+ + +# c) Bankparameterdaten + + +## Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + +Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Postfach-Kontoauszug erstellen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIAPES
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Auf- träge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + +# C.9.10.6 Postfach-Nachricht löschen + +Nach vorhergehender Abfrage der Postfach-Nachrichtenliste kann eine bestimmte +Nachricht bzw. Mitteilung mit Hilfe dieses Geschäftsvorfalls gelöscht werden. Es +bleibt dem Kreditinstitut überlassen, ob auch ungelesene Nachrichten gelöscht wer- +den dürfen. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 352Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: Sonstiges
+ + +Realisierung Bank: +optional + +Realisierung Kunde: + +optional + + +## a) Kundenauftrag + + +### Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Postfach-Nachricht löschen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKPNL
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Dokument-ID2DEan256Mn
+ + +## b) Kreditinstitutsrückmeldung + + +### Beschreibung + +Es werden keine Datensegmente zurückgemeldet. + + +### Ausgewahlte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Nachricht gelöscht
9160Dokument-ID fehlt
9160Dokument-ID existiert nicht
+ + +### c) Bankparameterdaten + + +#### Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Postfach-Nachricht löschen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIPNLS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Auf- träge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Postfach- Nachricht löschen1DEGM1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 353
+ + +# C.10 SEPA-Zahlungsverkehr + +Es gelten die Belegungsvorschriften für pain.001 - SEPA-Überweisung Kunde-Bank +sowie für pain.008 - SEPA-Lastschrifteinreichung Kunde-Bank laut Anlage 3 des +DFÜ-Abkommens. [DFÜ-Abkommen] + +Generell wird für den SEPA-Zahlungsverkehr der SEPA-Zeichensatz für Text- +Elemente zugrunde gelegt, damit die Aufträge ohne Zeichenkonvertierung in die +SEPA-Verarbeitung übernommen werden können (vgl. [DFÜ-Abkommen], Kapitel +2). + + +![](figures/73.1) + + +Sofern Zahlungsaufträge nicht im Kundenprodukt selbst erzeugt, +sondern importiert worden sind, ist vom Kundenprodukt durch ge- +eignete Importroutinen sicherzustellen, dass die FinTS- +Belegungsrichtlinien der jeweiligen Geschäftsvorfälle eingehalten +werden. + + +![](figures/73.2) + + +Falls im Kundenprodukt für die Dateneingabe ein nachempfundener +Zahlungsverkehrsvordruck verwendet wird, so hat sich die optische +Gestaltung der Bildschirmmaske am Aussehen des Belegs zur +€uro-Überweisung in der jeweils aktuellen Fassung zu richten. + + +![](figures/73.3) + + +Für die Berechnung der IBAN wurde vom ECBS ein Verfahren zur +Erzeugung und Validierung von IBAN-Prüfziffern festgesetzt [IBAN], +welches es vermeiden soll, dass Zahlendreher und andere Fehler in +der IBAN bei Zahlungsaufträgen zu Fehlleitungen führen. + +Die korrekte Angabe der IBAN des Zahlungsempfängers/Zah- +lungspflichtigen sollte deshalb vom Kundenprodukt durch eine ge- +sonderte Prüfroutine unterstützt werden. Falls diese Prüfung fehl- +schlägt, sollte das Kundenprodukt den Kunden auffordern, die ein- +gegebene IBAN zu korrigieren. Bei erneutem Fehlschlagen der +Prüfziffernkontrolle kann der Zahlungsauftrag dennoch an das Kre- +ditinstitut übermittelt werden. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
354		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + +# C.10.1SEPA-Kontoverbindung anfordern + + +## C.10.1.3 Segmentversion 1 + +Mit Hilfe dieses Geschäftsvorfalls wird einerseits über die BPD dem Kundenpro- +dukt/Kunden mitgeteilt, dass das Institut SEPA-Geschäftsvorfälle generell unter- +stützt, andererseits kann mit diesem Geschäftsvorfall das Kundenprodukt die für +den Kunden zugelassenen Konten mit IBAN/BIC anfordern. Die IBAN bzw. der BIC +können entweder für bestimmte Konten oder – abhängig vom BPD-Parameter ,,Ein- +zelkontenabruf erlaubt“ - für alle Konten des Kunden angefordert werden. + + +![](figures/74.1) + + +Wenn das Kundenprodukt in der Dialoginitialisierungsantwort eine +neue UPD erhält, muss das Kundenprodukt durch Abgleich mit den +lokal gespeicherten Informationen ermitteln, ob zusätzlich SEPA- +Informationen abgerufen werden müssen, um die aktuellen Informa- +tionen über IBAN/BIC zu erhalten. Der Aufbau der UPD selbst wur- +de für die Integration vom SEPA in FinTS nicht geändert. + + +![](figures/74.2) + + +![](figures/74.3) + + +Bei Verwendung des Unterkontomerkmals in Kontoverbindungen +muss Konsistenz sichergestellt sein: Ein Unterkontomerkmal muss +auf einheitliche Weise in den UPD und in HKSPA / HISPA enthal- +ten sein. + + +![](figures/74.4) + + +Die unterstützten SEPA-Datenformate (pain messages), die laut +HISPAS an das Kundenprodukt übermittelt werden, gelten nur, +wenn nicht besondere Angaben über unterstütze Datenformate in +den Bankparameterdaten eines Geschäftsvorfalls mitgeliefert wer- +den. In diesem Fall sind nur die Angaben in den Bankparameterda- +ten des Geschäftsvorfalls für den jeweiligen Geschäftsvorfall rele- +vant. + + +![](figures/74.5) + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle
SEPA-Zahlungsverkehr		Stand: 07.08.2015Seite: 355
+ + +Wird kreditinstitutsseitig festgestellt, dass es sich bei einem Konto um kein Zah- +lungsverkehrskonto handelt, wird durch die Belegung ,Kontoverbindung SEPA" = +„N" im MVE ktz mitgeteilt. + +Der Geschäftsvorfall „SEPA-Kontoverbindung anfordern" kann nicht anonym ver- +wendet werden. + +Realisierung Bank: verpflichtend, wenn SEPA unterstützt wird +Realisierung Kunde: verpflichtend, wenn SEPA angeboten wird + + +## a) Kundenauftrag + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:SEPA-Kontoverbindung anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKSPA
Bezugssegment:-
Segmentversion:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung2DEGktv#O.999
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 356Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + +## b) Kreditinstitutsrückmeldung + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:SEPA-Kontoverbindung rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HISPA
Bezugssegment:HKSPA
Version:1
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2SEPA- Kontoverbindung1DEGktz#O.999
+ + +◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
3010Es liegen keine Kontoverbindungen vor
9210Keine gültige Kontoverbindung des Kunden
+ + +## c) Bankparameterdaten + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:SEPA-Kontoverbindung anfordern, Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HISPAS
Bezugssegment:HKVVB
Segmentversion:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter SEPA- Kontoverbindung anfordern1DEGM1
+ + +# C.10.1.4 Segmentversion 2 + +Mit Hilfe dieses Geschäftsvorfalls wird einerseits über die BPD dem Kundenpro- +dukt/Kunden mitgeteilt, dass das Institut SEPA-Geschäftsvorfälle generell unter- +stützt, andererseits kann mit diesem Geschäftsvorfall das Kundenprodukt die für +den Kunden zugelassenen Konten mit IBAN/BIC anfordern. Die IBAN bzw. der BIC + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 357
+ + +können entweder für bestimmte Konten oder – abhängig vom BPD-Parameter ,,Ein- +zelkontenabruf erlaubt“ - für alle Konten des Kunden angefordert werden. + + +![](figures/77.1) + + +Wenn das Kundenprodukt in der Dialoginitialisierungsantwort eine +neue UPD erhält, muss das Kundenprodukt durch Abgleich mit den +lokal gespeicherten Informationen ermitteln, ob zusätzlich SEPA- +Informationen abgerufen werden müssen, um die aktuellen Informa- +tionen über IBAN/BIC zu erhalten. Der Aufbau der UPD selbst wur- +de für die Integration vom SEPA in FinTS nicht geändert. + + +![](figures/77.2) + + +Bei Verwendung des Unterkontomerkmals in Kontoverbindungen +muss Konsistenz sichergestellt sein: Ein Unterkontomerkmal muss +auf einheitliche Weise in den UPD und in HKSPA / HISPA enthal- +ten sein. + + +![](figures/77.3) + + +![](figures/77.4) + + +Die unterstützten SEPA-Datenformate (pain messages), die laut +HISPAS an das Kundenprodukt übermittelt werden, gelten nur, +wenn nicht besondere Angaben über unterstütze Datenformate in +den Bankparameterdaten eines Geschäftsvorfalls mitgeliefert wer- +den. In diesem Fall sind nur die Angaben in den Bankparameterda- +ten des Geschäftsvorfalls für den jeweiligen Geschäftsvorfall rele- +vant. + + +![](figures/77.5) + + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
358		Stand:
07.08.2015		Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + +Wird kreditinstitutsseitig festgestellt, dass es sich bei einem Konto um kein Zah- +lungsverkehrskonto handelt, wird durch die Belegung ,Kontoverbindung SEPA" = +„N“ im MVE ktz mitgeteilt. + +Der Geschäftsvorfall „SEPA-Kontoverbindung anfordern" kann nicht anonym ver- +wendet werden. + +Realisierung Bank: verpflichtend, wenn SEPA unterstützt wird +Realisierung Kunde: verpflichtend, wenn SEPA angeboten wird + + +## a) Kundenauftrag + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:SEPA-Kontoverbindung anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKSPA
Bezugssegment:-
Segmentversion:2
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung2DEGktv#O.999
3Maximale Anzahl Einträge1DEnum..4C1>0
O: ,,Eingabe Anzahl Ein- träge erlaubt“ (BPD) = „J“ N: sonst
4Aufsetzpunkt1DEan..35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle
SEPA-Zahlungsverkehr		Stand: 07.08.2015Seite: 359
+ + +# b) Kreditinstitutsrückmeldung + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:SEPA-Kontoverbindung rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HISPA
Bezugssegment:HKSPA
Version:1
Anzahl:2
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2SEPA- Kontoverbindung1DEGktz#O.999
+ + +◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
3010Es liegen keine Kontoverbindungen vor
9210Keine gültige Kontoverbindung des Kunden
+ + +# c) Bankparameterdaten + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:SEPA-Kontoverbindung anfordern, Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HISPAS
Bezugssegment:HKVVB
Segmentversion:2
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter SEPA- Kontoverbindung anfordern2DEGM1
+ + +# C.10.1.5 Segmentversion 3 + +Mit Hilfe dieses Geschäftsvorfalls wird einerseits über die BPD dem Kundenpro- +dukt/Kunden mitgeteilt, dass das Institut SEPA-Geschäftsvorfälle generell unter- +stützt, andererseits kann mit diesem Geschäftsvorfall das Kundenprodukt die für +den Kunden zugelassenen Konten mit IBAN/BIC anfordern. Die IBAN bzw. der BIC + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
360		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + +können entweder für bestimmte Konten oder – abhängig vom BPD-Parameter ,,Ein- +zelkontenabruf erlaubt“ – für alle Konten des Kunden angefordert werden. + + +![](figures/80.1) + + +Wenn das Kundenprodukt in der Dialoginitialisierungsantwort eine +neue UPD erhält, muss das Kundenprodukt durch Abgleich mit den +lokal gespeicherten Informationen ermitteln, ob zusätzlich SEPA- +Informationen abgerufen werden müssen, um die aktuellen Informa- +tionen über IBAN/BIC zu erhalten. Der Aufbau der UPD selbst wur- +de für die Integration vom SEPA in FinTS nicht geändert. + + +![](figures/80.2) + + +Bei Verwendung des Unterkontomerkmals in Kontoverbindungen +muss Konsistenz sichergestellt sein: Ein Unterkontomerkmal muss +auf einheitliche Weise in den UPD und in HKSPA / HISPA enthal- +ten sein. + + +![](figures/80.3) + + +![](figures/80.4) + + +Die unterstützten SEPA-Datenformate (pain messages), die laut +HISPAS an das Kundenprodukt übermittelt werden, gelten nur, +wenn nicht besondere Angaben über unterstütze Datenformate in +den Bankparameterdaten eines Geschäftsvorfalls mitgeliefert wer- +den. In diesem Fall sind nur die Angaben in den Bankparameterda- +ten des Geschäftsvorfalls für den jeweiligen Geschäftsvorfall rele- +vant. + + +![](figures/80.5) + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle
SEPA-Zahlungsverkehr		Stand:
07.08.2015		Seite: 361
+ + +Wird kreditinstitutsseitig festgestellt, dass es sich bei einem Konto um kein Zah- +lungsverkehrskonto handelt, wird durch die Belegung ,,Kontoverbindung SEPA" = +„N“ im MVE ktz mitgeteilt. + +Der Geschäftsvorfall „SEPA-Kontoverbindung anfordern" kann nicht anonym ver- +wendet werden. + +Realisierung Bank: verpflichtend, wenn SEPA unterstützt wird +Realisierung Kunde: verpflichtend, wenn SEPA angeboten wird + + +## a) Kundenauftrag + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:SEPA-Kontoverbindung anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKSPA
Bezugssegment:-
Segmentversion:3
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung2DEGktv#O.999
3Maximale Anzahl Einträge1DEnum..4C1>0
O: ,,Eingabe Anzahl Ein- träge erlaubt“ (BPD) = „J“ N: sonst
4Aufsetzpunkt1DEan..35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
362		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + +## b) Kreditinstitutsrückmeldung + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:SEPA-Kontoverbindung rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HISPA
Bezugssegment:HKSPA
Version:1
Anzahl:3
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2SEPA- Kontoverbindung1DEGktz#O.999
+ + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
3010Es liegen keine Kontoverbindungen vor
9210Keine gültige Kontoverbindung des Kunden
+ + +## c) Bankparameterdaten + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:SEPA-Kontoverbindung anfordern, Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HISPAS
Bezugssegment:HKVVB
Segmentversion:3
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter SEPA- Kontoverbindung anfordern3DEGM1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 363
+ + +# C.10.2 SEPA-Einzelaufträge + +Der SEPA-Zahlungsverkehr ist von seinem Aufbau her nicht auf Einzelaufträge zu- +geschnitten. Für Einzelüberweisungsaufträge auf Basis der pain.001.001.02 ist nur +die Grouping Option ,,Grouped" mit genau einer Einzeltransaktion CreditTransfer- +TransactionInformation bzw. DirectDebitTransactionInformation + zugelassen. + +Bei allen anderen pain messages, also ab pain.001.002.02 bzw. pain.008.002.01 +fällt die Gouping Option „Grouped" weg und es gelten für die Belegung einer even- +tuell vorhandenen Grouping Option die Festlegungen, wie sie im jeweils gültigen +DFÜ-Abkommen beschrieben sind (vgl. aktuell [DFÜ-Abkommen], Kapitel 2). Nichts +desto trotz darf in FinTS der Payment-Information-Block nur einmal vorkommen. +Gleiches gilt für den Transaction-Information-Block. Im Falle von Einzelaufträgen ist +somit dort weiterhin im nur eine Einzeltransaktion CreditTransferTransactionInfor- +mation bzw. DirectDebitTransactionInformation zuge- +lassen. + + +![](figures/83.1) + + +Für das BatchBooking-Kennzeichens ergeben sich +drei mögliche Ausprägungen lt. [DFÜ-Abkommen]: + + +![](figures/83.2) + + +· SEPA-Aufträge können BatchBooking = TRUE enthalten + +· Bei Nichtvorhandensein des BatchBooking-Kennzeichens wird +TRUE angenommen + +· BatchBooking = FALSE darf nur verwendet werden, wenn ei- +ne entsprechende Vereinbarung des Kreditinstituts mit dem Kunden +besteht. + +SEPA-Einzelaufträgen unter FinTS werden grundsätzlich als Ein- +zelbuchung zur Anzeige im Kontoauszug aufgefasst und somit un- +abhängig vom BatchBooking-Kennzeichen verabeitet. Eine Bele- +gung von BatchBooking ist somit nicht notwendig. Insbesondere +darf keine Belegung mit FALSE erfolgen, wenn keine Vereinbarung +zwischen Kreditinstitut und Kunde dazu besteht. + + +## C.10.2.1 Einzelüberweisung + + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +### a) Kundenauftrag + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:SEPA Einzelüberweisung
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKCCS
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
364		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt:
SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3SEPA Descriptor1DEan.256M1
4SEPA pain messa- ge1DEbin..M1
+ + +### . Belegungsrichtlinien + + +#### Kontoverbindung international + +IBAN und BIC müssen der IBAN in DebtorAccount bzw. der +BIC in DebtorAgent entsprechen. + + +#### SEPA pain message + +Erlaubtes „SEPA Überweisung Kunde-Bank"-Schema It. HISPAS. + +In das Mussfeld RequestedExecutionDate ist der 1999-01-01 ein- +zustellen. + + +![](figures/84.1) + + +Für nicht terminierte Aufträge darf dem Kunden kein Eingabefeld zur +Eingabe eines Termins angeboten werden. + + +![](figures/84.2) + + +Enthält das Feld RequestedExecutionDate bei nicht +terminierten Aufträgen einen anderen Wert als ,,1999-01-01" so ist +der Auftrag mit der Rückmeldung „9150 - Ausführungsdatum darf +nicht belegt werden“ abzulehnen. + + +![](figures/84.3) + + +Wird die SEPA-pain-message aus einer fremden Quelle importiert, +so ist darauf zu achten, dass ein eventuell abweichendes Datum im +Feld RequestedExecutionDate auf den Wert „1999- +01-01“ geändert wird. + + +### b) Kreditinstitutsrückmeldung + + +#### . Beschreibung + +Es werden keine Datensegmente zurückgemeldet. + + +#### ◆ Ausgewählte Beispiele für Rückmeldungscodes + +Der Code 3070 kann verwendet werden, um dem Kunden eine Bearbeitungs- +referenznummer z.B. für Reklamationsfälle mitzuteilen. Die Referenznummer wird +dabei als Parameter des Rückmeldungscodes angegeben (s. [Formals]). + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag zur Ausführung vorgemerkt
3020BIC veraltet. Die neue BIC lautet
3070Auftrag wird unter Referenz xxx verarbeitet
9150Ausführungsdatum darf nicht belegt werden
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 365
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
9150Identifikationsnr. darf nicht belegt werden
9210Betrag zu groß für Überweisung
9210Betrag muss größer als 0 sein
9210Empfänger-IBAN existiert nicht
9210Keine Berechtigung für dieses Konto
9210Falscher Textschlüssel
9210Keine gültige Kontoverbindung des Kunden
9210BIC existiert nicht
9230Unzureichendes Guthaben des Kontos
+ + +### c) Bankparameterdaten + + +#### . Beschreibung + +Geschäftsvorfallsspezifische Parameter existieren nicht. + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:SEPA Einzelüberweisung Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HICCSS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + +## C.10.2.2 Terminierte SEPA-Überweisung + +Die terminierte SEPA-Überweisung unterscheidet sich von der nicht-terminierten +SEPA-Einzelüberweisung durch die Angabe eines in der Zukunft liegenden Ausfüh- +rungsdatums in Feld RequestedExecutionDate . Der Einreicher be- +stimmt, dass zu diesem Datum der in der SEPA-Überweisung enthaltene Einzelauf- +trag ausgeführt werden soll. + +Folgende Geschäftsvorfälle sind vorgesehen: + +. Einreichung terminierter SEPA-Überweisungen + +· Änderung terminierter SEPA-Überweisungen + +· Bestand terminierter SEPA-Überweisungen abrufen + +· Löschung terminierter SEPA-Überweisungen + +Die Abbildung zeigt die Abfolge der Geschäftsvorfälle: + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
366		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + +Abbildung 6: Abläufe bei terminierten SEPA-Überweisungen + +![Terminierte SEPA-Überweisung einreichen Einreichung terminierter SEPA-Überweisung bestätigen K r K u n d e Terminierte SEPA-Überweisung ändern Änderung terminierter SEPA-Überweisung bestätigen e d i t i n s t i Bestand terminierter SEPA-Überweisungen anfordern Bestand terminierter SEPA-Überweisungen rückmelden Terminierte SEPA-Überweisung löschen t (kein Datensegment) u t](figures/86.1) + + +### C.10.2.2.1 Einreichung terminierter SEPA-Überweisungen + +Realisierung Bank: +optional + +Realisierung Kunde: +optional + + +#### a) Kundenauftrag + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Terminierte SEPA-Überweisung einreichen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKCSE
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3SEPA Descriptor1DEan.256M1
4SEPA pain messa- ge1DEbin..M1
+ + +. Belegungsrichtlinien + +Kontoverbindung international +IBAN und BIC müssen der IBAN in DebtorAccount bzw. der +BIC in DebtorAgent entsprechen. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 367
+ + +## SEPA pain message + +Erlaubtes „SEPA Überweisung Kunde-Bank"-Schema It. HISPAS. + + +## b) Kreditinstitutsrückmeldung + + +### . Beschreibung + + +![](figures/87.1) + + +Falls das Kreditinstitut schon bei der Einreichung eine Auftragsiden- +tifikation zurückmelden kann, sollte diese Möglichkeit genutzt wer- +den. Andernfalls hat das Kundensystem vor einer Änderung oder +Löschung den gesamten Bestand abzurufen (s. VII.x.x.x.x „Bestand +terminierter SEPA-Überweisungen abrufen"), um in den Besitz der +Auftragsidentifikation zu gelangen. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Einreichung terminierter SEPA-Überweisung bestätigen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HICSE
Bezugssegment:HKCSE
Version:1
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Auftragsidentifika- tion1DEan.99O1
+ + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + +Zusätzlich zu den Rückmeldungscodes der Einzelüberweisung gelten: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
0020Auftrag zur Ausführung vorgemerkt
3030Datum ist kein Bankgeschäftstag. Der Auftrag wird ausgeführt am ...
9210Mindestzeitraum bis zum Ausführungstermin überschritten
9210Datum liegt nicht in der Zukunft
9210Datum liegt zu weit in der Zukunft
9210Datum ist kein Buchungstag
+ + +## c) Bankparameterdaten + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Terminierte SEPA-Überweisung einreichen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HICSES
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
368		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter termi- nierte SEPA- Überweisung ein- reichen1DEGM1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 369
+ + +# C.10.2.2.2 Änderung terminierter SEPA-Überweisungen + + +![](figures/89.1) + + +Dieser Geschäftsvorfall darf vom Kreditinstitut nur angeboten wer- +den, wenn es eine Auftragsidentifikation unterstützt, da ansonsten +die Identifikation der zu ändernden Überweisung nicht möglich ist. + + +![](figures/89.2) + + +Vor der Änderung einer terminierten SEPA-Überweisung hat eine +Abholung des aktuellen Bestandes beim Kreditinstitut (s.u.) zu er- +folgen, um sicherzustellen, dass der Kunde auf Basis des korrekten +Bestandes operiert. Nur so ist gewährleistet, dass zwischenzeitliche +Änderungen auf anderem Wege (z.B. schriftlich oder per Selbstbe- +dienungsterminal) von der Kundensoftware berücksichtigt werden. +In der Kundennachricht muss zwingend das gleiche pain message- +Schema verwendet werden, welches zuvor in der Bestandsabfrage +durch das Kreditinstitut geliefert wurde. + + +![](figures/89.3) + + +Falls dieser Geschäftsvorfall kreditinstitutsseitig oder vom Kunden- +produkt nicht angeboten wird, kann durch den Kunden eine Ände- +rung erreicht werden, indem er die terminierte SEPA-Überweisung +löscht und anschließend neu einreicht. + + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +## a) Kundenauftrag + + +### . Beschreibung + +Die Felder sind so zu belegen, wie die terminierte SEPA-Überweisung nach der Än- +derung ausgeführt werden soll, d.h. es sind nicht nur die zu ändernden Felder zu +belegen. Die gleichzeitige Änderung mehrerer Felder ist möglich. Um die Referen- +zierung auf den Ursprungsauftrag zu ermöglichen, ist in das Element ,Auftragsiden- +tifikation" das vom Kreditinstitut mitgeteilte Identifikationsmerkmal einzustellen. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Terminierte SEPA-Überweisung ändern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKCSA
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
370		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3SEPA Descriptor1DEan.256M1
4SEPA pain messa- ge1DEbin..M1
5Auftragsidentifikati- on1DEan..99M1
+ + +## . Belegungsrichtlinien + + +### Kontoverbindung international + +IBAN und BIC müssen der IBAN in DebtorAccount bzw. der +BIC in DebtorAgent entsprechen. + + +### SEPA pain message + +Erlaubtes „SEPA Überweisung Kunde-Bank"-Schema It. HISPAS. + + +## b) Kreditinstitutsrückmeldung + + +## . Beschreibung + + +![](figures/90.1) + + +Falls eine neue Auftragsidentifikation vergeben wurde, ist der loka- +le Bestand im Kundenprodukt zu aktualisieren. + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Änderung terminierter SEPA-Überweisung bestätigen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HICSA
Bezugssegment:HKCSA
Version:1
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Auftragsidentifika- tion1DEan.99M1
3Auftragsidentifika- tion alt1DEan.99O1
+ + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
0020Auftrag ausgeführt
9010Auftrag zur Zeit nicht änderbar
9010Auftrag bereits zur Löschung vorgemerkt
9010Auftrag inkonsistent
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 371
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
9160Auftragsidentifikation fehlt
9210Datum liegt zu weit in der Zukunft
9210Datum liegt nicht in der Zukunft
9210Auftrag existiert nicht, Auftragsidentifikation unbekannt
9210IBAN des Auftraggebers darf nicht geändert werden
9210Das angegebene Datum ist kein Ausführungsdatum
+ + +## c) Bankparameterdaten + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Terminierte SEPA-Überweisung ändern Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HICSAS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter termi- nierte SEPA- Überweisung än- dern1DEGM1
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 372Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + +# C.10.2.2.3 Bestand terminierter SEPA-Überweisungen abrufen + + +## C.10.2.2.2.2C.10.2.2.3.1 Segmentversion 1 + +Der Kunde ruft die im Kreditinstitut zu einem Konto hinterlegten terminierten Aufträ- +ge ab, die noch zur Ausführung anstehen. Für jeden terminierten SEPA- +Überweisungsauftrag wird ein entsprechendes Datensegment in die Rückmel- +dungsnachricht eingestellt. + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +### a) Kundenauftrag + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Bestand terminierter SEPA-Überweisungen anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKCSB
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3Unterstützte SEPA pain messages1DEGM1
4Von Datum1DEdat#C1O: „Zeitraum möglich“ (BPD) „J“ N: sonst
5Bis Datum1DEdat#C1O: „Zeitraum möglich“ (BPD) „J“ N: sonst
6Maximale Anzahl Einträge1DEnum..4C1>0
O: ,,Eingabe Anzahl Ein- träge erlaubt“ (BPD) = „J“ N: sonst
7Aufsetzpunkt1DEan..35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +### b) Kreditinstitutsrückmeldung + + +![](figures/92.1) + + +Falls der Rückmeldecode 3041 gesendet wird, muss direkt im An- +schluss ein Bestandsabruf des korrespondierenden Nicht-SEPA- +Bestandes durchgeführt werden. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle
SEPA-Zahlungsverkehr		Stand: 07.08.2015Seite: 373
+ + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Bestand terminierter SEPA-Überweisungen rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HICSB
Bezugssegment:HKCSB
Version:1
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3SEPA Descriptor1DEan.256M1
4SEPA pain messa- ge1DEbin. .M1
5Auftragsidentifikati- on1DEan.99C1M: vom Institut wurde Auf- tragsidentifikation erteilt N: sonst
6Auftrag löschbar1DEjn#O1
7Auftrag änderbar1DEjn#O1
+ + +#### . Belegungsrichtlinien + +SEPA pain message + +„SEPA Überweisung Kunde-Bank"-Schema It. HISPAS. + + +#### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
3010Es liegen keine Einträge vor
3041ein weiterer Bestand liegt vor HKTUB
3042kein weiterer Bestand liegt vor HKTUB
3043keine Informationen über weitere Bestände HKTUB
9210Bereichende darf nicht vor Bereichanfang liegen
9210Datum liegt nicht in der Zukunft
9210Keine gültige IBAN des Kunden
+ + +#### c) Bankparameterdaten + + +##### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Bestand terminierter SEPA-Überweisungen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HICSBS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + +
Nr.NameVer-TypFor-Län-Sta-An-Restriktionen
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
374		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
sionmatgetuszahl
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Bestand terminierter SEPA- Überweisungen1DEGM1
+ + +## C.10.2.2.2.3C.10.2.2.3.2 Segmentversion 24 + +Der Kunde ruft die im Kreditinstitut zu einem Konto hinterlegten terminierten Aufträ- +ge ab, die noch zur Ausführung anstehen. Für jeden terminierten SEPA- +Überweisungsauftrag wird ein entsprechendes Datensegment in die Rückmel- +dungsnachricht eingestellt. + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +### a) Kundenauftrag + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Bestand terminierter SEPA-Überweisungen anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKCSB
Bezugssegment:-
Version:22
Sender:Kunde
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 375
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3Unterstützte SEPA pain messages1DEGM1
4Von Datum1DEdat#C1O: „Zeitraum möglich“ (BPD) „J“ N: sonst
5Bis Datum1DEdat#C1O: „Zeitraum möglich“ (BPD) „J“ N: sonst
6Maximale Anzahl Einträge1DEnum..4C1>0
O: ,,Eingabe Anzahl Ein- träge erlaubt“ (BPD) = „J“ N: sonst
7Aufsetzpunkt1DEan..35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +### b) Kreditinstitutsrückmeldung + + +![](figures/95.1) + + +Falls der Rückmeldecode 3041 gesendet wird, muss direkt im An- +schluss ein Bestandsabruf des korrespondierenden Nicht-SEPA- +Bestandes durchgeführt werden. + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Bestand terminierter SEPA-Überweisungen rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HICSB
Bezugssegment:HKCSB
Version:22
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 376Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3SEPA Descriptor1DEan.256M1
4SEPA pain messa- ge1DEbin..M1
5Auftragsidentifikati- on1DEan.99C1M: vom Institut wurde Auf- tragsidentifikation erteilt N: sonst
6SEPA-C- CodeSEPA C Code14DED Ecode- de- code141, 2, 31, 2, 3
7Auftrag änderbar1DEjn#O1
8Status SEPA- AuftragStatus SEPA-Auftrag14DED Ecode- de- code141, 2, 3, 4, 51, 2, 3, 4, 5
+ + +### . Belegungsrichtlinien + + +#### SEPA pain message + +„SEPA Überweisung Kunde-Bank"-Schema It. HICSBS bzw. HICSBS bzw. HISPAS. + + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
3010Es liegen keine Einträge vor
3041ein weiterer Bestand liegt vor HKTUB
3042kein weiterer Bestand liegt vor HKTUB
3043keine Informationen über weitere Bestände HKTUB
9210Bereichende darf nicht vor Bereichanfang liegen
9210Datum liegt nicht in der Zukunft
9210Keine gültige IBAN des Kunden
+ + +### c) Bankparameterdaten + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Bestand terminierter SEPA-Überweisungen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HICSBS
Bezugssegment:HKVVB
Version:22
Sender:Kreditinstitut
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 377
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Bestand terminierter SEPA- Überweisungen22DEGM1
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
378		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + +## C.10.2.2.3C.10.2.2.4 Löschung terminierter SEPA-Überweisungen + +Die zu löschende SEPA-Überweisung wird über eine Auftragsidentifikation, die beim +Abruf des Bestandes mitübertragen wird, bestimmt. Neben der Auftragsidentifikation +müssen auch die restlichen Auftragsdaten eingestellt werden, wenn dies kreditinsti- +tutsseitig in den BPD gefordert ist. Diese dienen dann z.B. zu Plausibilitätsprüfun- +gen. + + +![](figures/98.1) + + +Dieser Geschäftsvorfall darf vom Kreditinstitut nur angeboten wer- +den, wenn es eine Auftragsidentifikation unterstützt, da ansonsten +die Identifikation der zu löschenden SEPA-Überweisung nicht mög- +lich ist. + +Zu löschende terminierte Aufträge liegen immer in der Zukunft. Eine minimale Vor- +laufzeit für die Einreichung des Löschauftrags ist nicht vorgesehen. Es können je- +doch nur Aufträge gelöscht werden, die auch im Bestand aufgeführt werden. + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +### a) Kundenauftrag + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Terminierte SEPA-Überweisung löschen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKCSL
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 379
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3SEPA Descriptor1DEan.256C1M: ,"Senden der Auftrags- daten erforderlich" (BPD) „J“ O: sonst
4SEPA pain messa- ge1DEbin..C1M: ,"Senden der Auftrags- daten erforderlich" (BPD) „J“ O: sonst
5Auftragsidentifikati- on1DEan.99M1
+ + +### . Belegungsrichtlinien + + +#### Kontoverbindung international + +IBAN und BIC müssen der IBAN in DebtorAccount bzw. der +BIC in DebtorAgent entsprechen. + + +#### SEPA pain message + +Erlaubtes „SEPA Überweisung Kunde-Bank"-Schema It. HISPAS. + + +![](figures/99.1) + + +Muss die SEPA pain message in der Kundennachricht eingestellt +werden, so muss zwingend das gleiche pain message-Schema +verwendet werden, welches zuvor in der Bestandsabfrage durch +das Kreditinstitut geliefert wurde. + + +### b) Kreditinstitutsrückmeldung + + +#### . Beschreibung + +Es werden keine Datensegmente zurückgemeldet. + + +#### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag zur Löschung vorgemerkt
0020Auftrag gelöscht
9010Löschung nicht mehr möglich, da Auftrag bereits zur Löschung vorgemerkt
9010Auftragsidentifikation stimmt nicht mit Auftragsdaten überein
9210Auftrag existiert nicht bzw. wurde bereits ausgeführt
+ + +#### c) Bankparameterdaten + + +##### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Terminierte SEPA-Überweisung löschen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HICSLS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
380		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Lö- schung terminierter SEPA- Überweisungen1DEGM1
+ + +## C.10.2.3SEPA-Dauerauftrag + +Folgende Geschäftsvorfälle sind vorgesehen: + +. Einrichtung eines SEPA-Dauerauftrags + +· Ändern eines SEPA-Dauerauftrags + +· SEPA-Dauerauftragsaussetzung (gegebenenfalls mit vorübergehend geänder- +tem Betrag) + +. SEPA-Dauerauftragsbestandsabfrage + +· Abruf von SEPA-Dauerauftragsänderungsvormerkungen + +• SEPA-Dauerauftragslöschung + + +Die Abbildung zeigt die Abfolge der Geschäftsvorfälle im Dauerauftragsbereich: + +![SEPA-Dauerauftrag einrichten SEPA-Dauerauftragseinrichtung bestätigen SEPA-Dauerauftragsbestand anfordern K SEPA-Dauerauftragsbestand rückmelden r e SEPA-Dauerauftrag ändern SEPA-Dauerauftragsänderung bestätigen d K u i t i n SEPA-Dauerauftrag aussetzen d SEPA-Dauerauftragsaussetzung bestätigen n e s t i t SEPA-DA-änderungsvormerkungen anfordern SEPA-DA-änderungsvormerkungen rückmelden u t SEPA-Dauerauftrag löschen (kein Datensegment)](figures/100.1) + + +Abbildung 7: Lebenszyklus SEPA-Dauerauftrag + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 381
+ + +Die umfangreiche Komplexität sämtlicher Dauerauftragsmodalitäten kann im Rah- +men dieser Schnittstelle nicht abgebildet werden. Derartige Verarbeitungsvorgänge +können stattdessen evtl. durch die Steuerung des Kundenprodukts abgewickelt wer- +den. + + +![](figures/101.1) + + +Von den hier dargestellten Aufträgen zu unterscheiden sind vom +Kundenprodukt verwaltete Daueraufträge, d.h. Einzelaufträge, bei +denen das Kundensystem die Terminverwaltung und regelmäßige +Versendung übernimmt. Diese können für den Kunden insbesonde- +re dann eine Alternative darstellen, falls entweder das Kundenpro- +dukt oder das Kreditinstitut keine Dauerauftragsverwaltung anbietet. + + +![](figures/101.2) + + +Die Geschäftsvorfälle „SEPA-Dauerauftragsänderung“, „SEPA- +Dauerauftragsaussetzung“ +und +„SEPA- +Dauerauftragsänderungsvormerkungen abrufen“ dürfen vom Kre- +ditinstitut nur angeboten werden, wenn es eine Auftragsidentifikation +unterstützt, da ansonsten die Identifikation des zu ändernden Dau- +erauftrags nicht möglich ist. + + +![](figures/101.3) + + +Vor der Modifikation eines Dauerauftrages (Änderung, Aussetzung) +hat eine Abholung des aktuellen Bestandes bzw. der Änderungs- +vormerkungen beim Kreditinstitut (s.u.) zu erfolgen, um sicher- +zustellen, dass der Kunde auf Basis des korrekten Bestandes ope- +riert. Nur so ist gewährleistet, dass zwischenzeitliche Änderungen +auf anderem Wege (z.B. schriftlich oder per Selbstbedie- +nungsterminal) von der Kundensoftware berücksichtigt werden. + +Das Datenformat für SEPA-Daueraufträge entspricht dem Format für SEPA- +Einzelaufträge. Es wird ergänzt um dauerauftragspezifische Informationen. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
382		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + +## C.10.2.3.1 SEPA-Dauerauftragseinrichtung + + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +### a) Kundenauftrag + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:SEPA-Dauerauftrag einrichten
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKCDE
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3SEPA Descriptor1DEan.256M1
4SEPA pain messa- ge1DEbin..M1
5Dauerauftragdetails3DEGM1
+ + +### . Belegungsrichtlinien + + +#### Kontoverbindung international + +IBAN und BIC müssen der IBAN in DebtorAccount bzw. der +BIC in DebtorAgent entsprechen. + + +#### SEPA pain message + +Erlaubtes „SEPA Überweisung Kunde-Bank"-Schema It. HISPAS. + + +### b) Kreditinstitutsrückmeldung + +. Beschreibung + + +![](figures/102.1) + + +Falls das Kreditinstitut schon bei der Einreichung eine Auf- +tragsidentifikation zurückmelden kann, sollte diese Möglichkeit ge- +nutzt werden. Andernfalls hat das Kundensystem vor einer Ände- +rung oder Löschung den gesamten Bestand abzurufen (s. +C.10.2.5.4 „SEPA-Dauerauftragsbestand abrufen"), um in den Be- +sitz der Auftragsidentifikation zu gelangen. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle
SEPA-Zahlungsverkehr		Stand: 07.08.2015Seite: 383
+ + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:SEPA-Dauerauftragseinrichtung bestätigen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HICDE
Bezugssegment:HKCDE
Version:1
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
43Segmentkopf1DEGM1
24Auftragsidentifikati- on1DEan.99O1
+ + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + +Es sind sämtliche Rückmeldungscodes des Geschäftsvorfalls „SEPA-Einzelüber- +weisungen" und ,,Einreichung terminierter SEPA-Überweisung“ möglich: Zusätzlich +gelten: + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
9210Der angegebene Turnus ist kein Ausführungsturnus
+ + +### c) Bankparameterdaten + + +#### . Beschreibung + +Das Kreditinstitut gibt die monatlich bzw. wöchentlich erlaubten Ausführungs- +rythmen an. In den Datenelementen 4 bis 6 sind die unterstützten Werte in aufstei- +gender Reihenfolge als Kette 2-stelliger Zahlen einzustellen. Die DE-Länge von 62 +würde somit die Eingabe aller Tage eines Monats erlauben. + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:SEPA-Dauerauftrag einrichten Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HICDES
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter SEPA- Dauerauftrag ein- richten1DEGM1
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
384		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + +## C.10.2.3.2 SEPA-Dauerauftragsänderung + +Das Kreditinstitut teilt in den BPD mit, welche Felder durch den Kunden änderbar +sind. Die Auftragsidentifikation und die Auftraggeberkontoverbindung sind grund- +sätzlich nicht änderbar. + +Änderungen gelten, sofern nichts anderes bestimmt ist, zum nächsten Ausführungs- +termin. Darüber hinaus kann das Kreditinstitut in den BPD festsetzen, ob es zusätz- +lich terminierte Änderungen erlaubt. In diesem Fall ist weiterhin möglich, dass das +Kreditinstitut nur eine oder mehrere terminierte Änderungen gleichzeitig zulässt. + + +![](figures/104.1) + + +Falls dieser Geschäftsvorfall kreditinstitutsseitig oder vom Kunden- +produkt nicht angeboten wird, kann durch den Kunden eine Ände- +rung erreicht werden, indem er den SEPA-Dauerauftrag löscht und +anschließend neu einreicht. Dasselbe gilt für den Fall, dass die Än- +derung eines nicht änderbaren Feldes erforderlich ist. + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +### a) Kundenauftrag + + +#### . Beschreibung + +Bei jeder Änderung ist eine vollständige neue SEPA pain message einzureichen. + +Liegen bereits terminierte Änderungen im Falle einer nicht terminierten Änderung +vor, so ist der Kunde darauf hinzuweisen. Im Zweifel ist die Anzahl der terminierten +Änderungen auf maximal eine Änderung einzuschränken. Anhand der mitgelieferten +anderen Daten der vollständigen pain message können kreditinstitutsseitig Plausibi- +litätsprüfungen durchgeführt werden. Dies ist erforderlich, um Fehldeutungen des +Kundenwunsches zu vermeiden. + +Beispiel: + +Der Kunde richtet am 1.1. einen Dauerauftrag über 100 Euro zugunsten des Kontos +12345 ein. Am 1.2. sendet er einen terminierten Änderungsauftrag, da er weiß, dass +sich der Überweisungsbetrag am 1.7. auf 110 Euro ändern wird. Am 1.3. erhält er +die Information, dass sich die Empfänger-Kontonummer auf 12346 geändert hat und +ändert dementsprechend den Dauerauftrag sofort. Sofern der Kunde in seinem ers- +ten Änderungsauftrag sämtliche Auftragsdaten sendet, wird am 1.7. die Konto- +nummer wieder auf die alte Nummer 12345 zurückgesetzt, d.h. der Kundenwunsch +wird falsch interpretiert. + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:SEPA-Dauerauftrag ändern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKCDN
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + +
Nr.NameVer-TypFor-Län-Sta-An-Restriktionen
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 385
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
sionmatgetuszahl
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3SEPA Descriptor1DEan.256M1
4SEPA pain messa- ge1DEbin..M1
5AusführungsdatumDEdat#C1O: „Anzahl term. Änderun- gen" (BPD) >=1 N: sonst
6Auftragsidentifikati- on1DEan..99C1M: Auftragsidentifikation wurde vom Institut erteilt N: sonst
7Dauerauftragdetails3DEGC1M: „Anzahl term. Änderun- gen" (BPD) <=1 ODER „Anzahl term. Änderungen“ (BPD) >1 und Dauerauf- tragsdetails nicht änderbar ODER „Anzahl term. Ände- rungen“ (BPD) >1 und Dauerauftragsdetails än- derbar und Dauerauftrag- details sollen geändert wer- den N: sonst
+ + +### ◆ Belegungsrichtlinien + + +#### Kontoverbindung international + +IBAN und BIC müssen der IBAN in DebtorAccount bzw. der +BIC in DebtorAgent entsprechen. + + +#### SEPA pain message + +Erlaubtes „SEPA Überweisung Kunde-Bank"-Schema It. HISPAS. + + +![](figures/105.1) + + +In der Kundennachricht muss zwingend das gleiche pain messa- +ge-Schema verwendet werden, welches zuvor in der Bestandsab- +frage durch das Kreditinstitut geliefert wurde. + + +### b) Kreditinstitutsrückmeldung + + +### . Beschreibung + + +![](figures/105.2) + + +Falls eine neue Auftragsidentifikation vergeben wurde, ist der loka- +le Bestand im Kundenprodukt zu aktualisieren. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 386Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:SEPA-Dauerauftragsänderung bestätigen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HICDN
Bezugssegment:HKCDN
Version:1
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Auftragsidentifikati- on1DEan.99M1
3Auftragsidentifikati- on alt1DEan.99O1
+ + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
0020SEPA-Dauerauftrag geändert
9010SEPA-Dauerauftrag zur Zeit nicht änderbar
9010Änderung bei diesem Dauerauftragstyp nicht möglich
9010SEPA-Dauerauftrag bereits zur Löschung vorgemerkt
9010Auftrag inkonsistent
9160Auftragsidentifikation fehlt
9210Aussetzungszeitraum zu groß
9210Datum liegt zu weit in der Zukunft
9210Datum liegt nicht in der Zukunft
9210SEPA-Dauerauftrag existiert nicht, Auftragsidentifikation unbekannt
9210IBAN des Auftraggebers darf nicht geändert werden
+ + +### c) Bankparameterdaten + + +#### . Beschreibung + +Es ist zu beachten, dass sich die Parameter von denen der SEPA-Dauerauftrags- +einrichtung unterscheiden können. + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:SEPA-Dauerauftrag ändern Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HICDNS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 387
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter SEPA- Dauerauftrag än- dern1DEGM1
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
388		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + +## C.10.2.3.3 SEPA-Dauerauftragsaussetzung + +Aussetzungen gelten, sofern nichts anderes bestimmt ist, zum nächsten Ausfüh- +rungstermin. Darüber hinaus kann das Kreditinstitut in der BPD festsetzen, ob es +zusätzlich terminierte Aussetzungen erlaubt. + + +![](figures/108.1) + + +Ein Widerruf einer einmal eingereichten Aussetzung ist im Regelfall +nicht möglich. + +Falls keine weiteren terminierten Änderungen oder Aussetzungen +vorliegen, kann der Kunde eine bereits gemeldete Aussetzung jedoch +widerrufen, indem das Kundenprodukt eine weitere Aussetzung für +denselben Zeitraum sendet, bei der der ,Abweichende Betrag" mit +dem Originalbetrag belegt ist. + + +![](figures/108.2) + + +Falls dieser Geschäftsvorfall vom Kreditinstitut oder vom Kunden- +produkt nicht angeboten wird, kann eine Aussetzung auch durch Lö- +schung und terminierte Neueinreichung erreicht werden. + + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +### a) Kundenauftrag + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:SEPA-Dauerauftrag aussetzen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKCDU
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3SEPA Descriptor1DEan.256M1
4SEPA pain messa- ge1DEbin."M1
5Ausführungsdatum1DEdat#C1O: ,,Anzahl term. Ausset- zungen" (BPD) >=1 N: sonst
6Auftragsidentifikati- on1DEan.99C1M: Auftragsidentifikation wurde vom Institut erteilt N: sonst
7Dauerauftragdetails3DEGM1
8Aussetzung3DEGM1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 389
+ + +### . Belegungsrichtlinien + + +#### Kontoverbindung international + +IBAN und BIC müssen der IBAN in DebtorAccount bzw. der +BIC in DebtorAgent entsprechen. + +SEPA pain message + +Erlaubtes „SEPA Überweisung Kunde-Bank"-Schema It. HISPAS. + + +![](figures/109.1) + + +In der Kundennachricht muss zwingend das gleiche pain messa- +ge-Schema verwendet werden, welches zuvor in der Bestandsab- +frage durch das Kreditinstitut geliefert wurde. + + +### b) Kreditinstitutsrückmeldung + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:SEPA-Dauerauftragsaussetzung bestätigen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HICDU
Bezugssegment:HKCDU
Version:1
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Auftragsidentifikati- on1DEan.99M1
3Auftragsidentifikati- on alt1DEan.99O1
+ + +#### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
0020SEPA-Dauerauftrag ausgesetzt
9010SEPA-Dauerauftrag zur Zeit nicht änderbar
9010Auftrag bereits zur Löschung vorgemerkt
9160Auftragsidentifikation fehlt
9210Aussetzungszeitraum zu groß
9210Datum liegt zu weit in der Zukunft
9210Datum liegt nicht in der Zukunft
9210Auftrag existiert nicht, Auftragsidentifikation unbekannt
9210Kontonummer des Auftraggebers darf nicht geändert werden
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
390		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + +### c) Bankparameterdaten + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:SEPA-Dauerauftrag aussetzen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HICDUS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter SEPA- Dauerauftrag aus- setzen1DEGM1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Geschäftsvorfälle		Stand: 07.08.2015Seite: 391
+ + +# C.10.2.3.4 SEPA-Dauerauftragsbestand abrufen + +Für jeden Dauerauftrag wird ein Segment "Dauerauftrag" als Datensegment in der +Rückmeldungsnachricht übermittelt. Der Dauerauftrag wird so angezeigt, wie er zum +nächsten Termin ausgeführt würde. + + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +## a) Kundenauftrag + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:SEPA-Dauerauftragsbestand anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKCDB
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
16Segmentkopf1DEGM1
27Kontoverbindung international1DEGkti#M1
38Unterstützte SEPA pain messages1DEGM1
49Auftragsidentifikati- on1DEan.99O1
510Maximale Anzahl EinträgeDEnum..4C1>0
O: ,,Eingabe Anzahl Ein- träge erlaubt“ (BPD) = „J“ N: sonst
611AufsetzpunktDEan.35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +## . Belegungsrichtlinien + + +### Auftragsidentifikation + +Wird das DE ,,Auftragsidentifikation" belegt, wird der entsprechende Dauerauftrag +angezeigt. Wird dieses Feld leer gelassen, kommen alle Daueraufträge des Kontos +zur Anzeige. + + +### b) Kreditinstitutsrückmeldung + + +#### . Beschreibung + +Für jeden Dauerauftrag wird ein Segment zurückgemeldet. + + +![](figures/111.1) + + +Falls der Rückmeldecode 3041 gesendet wird, muss direkt im An- +schluss ein Bestandsabruf des korrespondierenden Nicht-SEPA- +Bestandes durchgeführt werden. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 392Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:SEPA-Dauerauftragsbestand rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HICDB
Bezugssegment:HKCDB
Version:1
Sender:Kreditinstitut
Anzahl:n
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
29Segmentkopf1DEGM1
310Kontoverbindung international1DEGkti#M1
411SEPA Descriptor1DEan.256M1
512SEPA pain messa- ge1DEbin.٠M1
613Auftragsidentifikati- on1DEan.99O1
714Dauerauftragdetails3DEGM1
815Aussetzung3DEGO1
916Auftrag änderbar1DEjn#O1
1017Auftrag aussetzbar1DEjn#O1
1118Auftrag löschbar1DEjn#O1
+ + +## . Belegungsrichtlinien + + +### Kontoverbindung international + +IBAN und BIC müssen der IBAN in DebtorAccount bzw. der +BIC in DebtorAgent entsprechen. + + +### SEPA pain message + +Erlaubtes „SEPA Überweisung Kunde-Bank"-Schema It. HISPAS. + + +### Auftragsidentifikation + + +![](figures/112.1) + + +Soll ein SEPA-Dauerauftrag lediglich anhand einer Auftragsidentifi- +kation gelöscht werden können, so muss das Kreditinstitut dem +Kundenprodukt eine Auftragsidentifikation mitteilen. + + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
3010Es liegen keine Einträge vor
3041ein weiterer Bestand liegt vor HKDAB
3042kein weiterer Bestand liegt vor HKDAB
3043keine Informationen über weitere Bestände HKDAB
9210Bereichende darf nicht vor Bereichanfang liegen
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 393
+ + +## c) Bankparameterdaten + + +### . Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:SEPA-Dauerauftragsbestand Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HICDBS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
16Segmentkopf1DEGM1
27Maximale Anzahl Aufträge1DEnum..3M1
38Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
49Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
510Parameter SEPA- Dauerauftragsbe- stand1DEGM1
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
394		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + +# C.10.2.3.5 SEPA-Dauerauftragsänderungsvormerkungen abrufen + + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +## a) Kundenauftrag + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:SEPA-Dauerauftragsänderungsvormerkungen anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKCDA
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#C1
3Unterstützte SEPA pain messages1DEGM1
4Auftragsidentifikati- on1DEan..99M1
5Maximale Anzahl Einträge1DEnum..4C1>0
O: ,,Eingabe Anzahl Ein- träge erlaubt“ (BPD) = „J“ N: sonst
6Aufsetzpunkt1DEan..35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +## b) Kreditinstitutsrückmeldung + + +### . Beschreibung + +Für den ausgewählten Dauerauftrag wird je noch nicht ausgeführtem Änderungs- +bzw. Aussetzungsauftrag ein Segment "Dauerauftrag" übermittelt. Das erste Daten- +segment enthält den Stand, der zum nächsten Ausführungstermin gültig ist. Liegen +keine terminierten Änderungen bzw. Aussetzungen für diesen Dauerauftrag vor, +werden keine weiteren Segmente gesendet. + + +![](figures/114.1) + + +Es bleibt dem Kreditinstitut überlassen, ob es Änderungs-/Ausset- +zungsaufträge oder Änderungs-/Aussetzungstermine1 zurückmeldet. +D.h. zu einem Termin können u.U. mehrere Aufträge zurückgemel- +det werden, von denen aber nur jeweils der letzte ausgeführt wird. + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle
SEPA-Zahlungsverkehr		Stand: 07.08.2015Seite: 395
+ + +Für den ausgewählten Dauerauftrag wird je noch nicht ausgeführtem Änderungs- +bzw. Aussetzungsauftrag ein Datensegment übermittelt, wobei das erste Daten- +segment diejenige Vormerkung beinhaltet, die den nächsten Ausführungstermin +(eingestellt in DE „Ausführungsdatum Dauerauftragsänderungsvormerkung") auf- +weist. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:SEPA-Dauerauftragsänderungsvormerkungen rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HICDA
Bezugssegment:HKCDA
Version:1
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3SEPA Descriptor1DEan.256M1
4SEPA pain messa- ge1DEbin..M1
5Auftragsidentifikati- on1DEan.99O1
6Dauerauftragdetails3DEGM1
7Aussetzung3DEGO1
+ + +### . Belegungsrichtlinien + + +#### Kontoverbindung international + +IBAN und BIC müssen der IBAN in DebtorAccount bzw. der +BIC in DebtorAgent entsprechen. + + +#### SEPA pain message + +Erlaubtes „SEPA Überweisung Kunde-Bank"-Schema It. HISPAS. + + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
9160Auftragsidentifikation fehlt
9210Auftrag existiert nicht, Auftragsidentifikation unbekannt
+ + +### c) Bankparameterdaten + + +### . Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
396		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:SEPA-Dauerauftragsänderungsvormerkungen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HICDAS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter SEPA- Dauerauftragsände- rungs- vormerkungen1DEGM1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 397
+ + +# C.10.2.3.6 SEPA-Dauerauftragslöschung + +Löschungen gelten, sofern nichts anderes bestimmt ist, ab sofort. Darüber hinaus +kann das Kreditinstitut in der BPD festlegen, ob es zusätzlich terminierte Löschun- +gen erlaubt. Die Eingabe einer terminierten Löschung überschreibt einen evtl. vor- +her eingegebenen terminierten Löschauftrag. + + +![](figures/117.1) + + +Im Gegensatz zur SEPA-Dauerauftragsänderung und -aussetzung +ist eine Löschung auch möglich, wenn das Kreditinstitut keine Auf- +tragsidentifikation für den Dauerauftrag vergibt und im Löschauftrag +die gültigen Daten des Auftrags mitgeteilt werden, die dem Kreditin- +stitut eine eindeutige Identifizierung des Auftrags ermöglichen. Dür- +fen jedoch die Auftragsdaten laut Bankparameterdaten nicht gesen- +det werden, so muss zwingend eine Auftragsidentifikation unter- +stützt werden, da ansonsten die Identifikation des zu löschenden +SEPA-Dauerauftrags nicht möglich ist. + + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +## a) Kundenauftrag + + +### . Beschreibung + +Es sind die gültigen Daten des SEPA-Dauerauftrags einzustellen. Diese dienen zu +Plausibilitätsprüfungen. + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:SEPA-Dauerauftrag löschen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKCDL
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
398		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt:
SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
15Segmentkopf1DEGM1
26Kontoverbindung international1DEGkti#M1
37SEPA Descriptor1DEan.256C1M: ,"Senden der Auftrags- daten erforderlich" (BPD) „J“ O: sonst
48SEPA pain messa- ge1DEbin..C1M: ,"Senden der Auftrags- daten erforderlich" (BPD) „J“ O: sonst
59AusführungsdatumDEdat#C1O: DE „Löschung terminier- bar“ (BPD) = „J“ N: sonst
610Auftragsidentifikati- on1DEan.99C1M: Auftragsidentifikation wurde vom Institut erteilt N: sonst
711Dauerauftragdetails3DEGM1
+ + +## . Belegungsrichtlinien + + +### Kontoverbindung international + +IBAN und BIC müssen der IBAN in DebtorAccount bzw. der +BIC in DebtorAgent entsprechen. + + +### SEPA pain message + +Erlaubtes „SEPA Überweisung Kunde-Bank"-Schema It. HISPAS. + + +![](figures/118.1) + + +Muss die SEPA pain message in der Kundennachricht eingestellt +werden, so muss zwingend das gleiche pain message-Schema +verwendet werden, welches zuvor in der Bestandsabfrage durch +das Kreditinstitut geliefert wurde. + + +### Ausführungsdatum + +Falls terminierte Löschungen erlaubt sind (s. DE „Löschung terminierbar" in den +Bankparameterdaten), ist hier ist das Löschdatum einzustellen. Es muss sich dabei +um ein Datum handeln, zu dem eine Ausführung stattfinden würde. Der SEPA- +Dauerauftrag wird an dem angegebenen Datum nicht mehr ausgeführt. Ist das DE +nicht eingestellt, so wird die Löschung sofort wirksam. + + +### b) Kreditinstitutsrückmeldung + + +#### . Beschreibung + +Es werden keine Datensegmente zurückgemeldet. + + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + +Code Beispiel für Rückmeldungstext + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 399
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
0010SEPA-Dauerauftrag zur Löschung vorgemerkt
0020SEPA-Dauerauftrag gelöscht
9010SEPA-Dauerauftrag zur Zeit nicht änderbar
9010SEPA-Dauerauftrag bereits zur Löschung vorgemerkt
9160Auftragsidentifikation fehlt
9210Aussetzungszeitraum zu groß
9210Datum liegt zu weit in der Zukunft
9210Datum liegt nicht in der Zukunft
9210Auftrag existiert nicht, Auftragsidentifikation unbekannt
9210Kontonummer des Auftraggebers darf nicht geändert werden
9210Das angegebene Datum ist kein Ausführungsdatum
+ + +## c) Bankparameterdaten + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:SEPA-Dauerauftrag löschen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HICDLS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
16Segmentkopf1DEGM1
27Maximale Anzahl Aufträge1DEnum..3M1
38Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
49Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
510Parameter SEPA- Dauerauftrag lö- schen1DEGM1
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
400		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + +# C.10.2.4 Vorbereitete SEPA-Überweisungen + +Vorbereitete SEPA-Überweisungen gelangen nicht direkt zur Ausführung, sondern +werden im Kreditinstitut für eine spätere Verwendung gespeichert. Im Gegensatz zu +den Festlegungen in den pain messages sind lediglich der Name des Empfängers +sowie die Empfängerkontonummer Pflichtfelder, sodass die pain messages nicht di- +rekt verwendet werden können. Stattdessen kommt ein sogenanntes XML-Skeleton +zum Einsatz. Dieses unterscheidet sich von der eigentlichen pain message vor allen +Dingen dadurch, dass die für einen vorbereitete Überweisung relevanten Felder op- +tional sind. Falls der Kunde eine Überweisung ausführen möchte (z.B. auf Basis der +Geschäftsvorfälle SEPA-Einzelüberweisung oder terminierte SEPA-Überweisung), +kann er aus den vorliegenden vorbereiteten SEPA-Überweisungen eine passende +aussuchen, die er entweder direkt versendet oder vorher abändert. Der Kunde kann +somit oft wiederkehrende SEPA-Überweisungen (z.B. Miete) schnell und bequem +erfassen. Vorbereitete SEPA-Überweisungen bleiben solange im Bestand, bis sie +gelöscht werden. + + +![](figures/120.1) + + +Im Rahmen von Homebanking-Kundenprodukten wird diese Funkti- +onalität in der Regel durch eine lokale Empfängerdatenbank abge- +bildet. + +Vorbereitete Überweisungen eignen sich daher insbesondere für +browserbasierte Anwendungen, bei denen keine Möglichkeit für ei- +ne lokale Datenspeicherung besteht. Ebenso kann diese Funktiona- +lität genutzt werden, wenn der Kunde häufig verschiedene Endgerä- +te oder Vertriebswege (SB-Geräte, öffentliche Homebanking-Termi- +nals) nutzt und so stets Zugriff auf dieselben vorbereiteten Überwei- +sungen hat. + +Folgende Geschäftsvorfälle sind vorgesehen: + +. Einreichung vorbereiteter SEPA-Überweisungen + +· Änderung vorbereiteter SEPA-Überweisungen + +· Bestand vorbereiteter SEPA-Überweisungen abrufen + +· Löschung vorbereiteter SEPA-Überweisungen + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle
SEPA-Zahlungsverkehr		Stand: 07.08.2015Seite: 401
+ + +# C.10.2.4.1 Vorbereitete SEPA-Überweisung anlegen + + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +## a) Kundenauftrag + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Vorbereitete SEPA-Überweisung anlegen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKCVE
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3SEPA Descriptor1DEan.256M1
4SEPA pain messa- ge Skeleton1DEbin..M1
+ + +## . Belegungsrichtlinien + + +### Kontoverbindung international + +IBAN und BIC müssen der IBAN in DebtorAccount bzw. der +BIC in DebtorAgent entsprechen. + + +### SEPA pain message Skeleton + +XML-Skeleton eines „SEPA Überweisung Kunde-Bank“-Schemas lt. HISPAS. + + +## b) Kreditinstitutsrückmeldung + + +## . Beschreibung + +Es wird eine Auftragsidentifikation zurück gemeldet, die bei Folgeaktionen (Ände- +rung, Löschung) angegeben werden muss. + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Anlage vorbereiteter SEPA-Überweisung bestätigen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HICVE
Bezugssegment:HKCVE
Version:1
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Auftragsidentifikati-1DEan.99O1
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
402		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + +
on
+ + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + +Es ist dem Kreditinstitut überlassen, ob es die eingereichten Überweisungen unge- +prüft ablegt oder bankfachlich prüft. Falls eine fachliche Prüfung stattfindet, können +dieselben Rückmeldungscodes wie bei einer SEPA-Einzelüberweisung gesendet +werden. + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
+ + +## c) Bankparameterdaten + + +### . Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Vorbereitete SEPA-Überweisung anlegen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HICVES
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Geschäftsvorfälle		Stand: 07.08.2015Seite: 403
+ + +# C.10.2.4.2 Vorbereitete SEPA-Überweisung ändern + +Die Änderung erfolgt in der Weise, dass die unter der angegebenen Auftragsidenti- +fikation gespeicherten Daten mit den vom Kunden im Rahmen des Änderungs- +auftrages gesendeten Daten überschrieben werden. + + +![](figures/123.1) + + +Vor der Änderung sollte eine Abholung des aktuellen Bestandes +beim Kreditinstitut (s.u.) erfolgen, um sicherzustellen, dass der Kun- +de auf Basis des korrekten Bestandes operiert. In der Kundennach- +richt muss zwingend das gleiche pain message-Schema verwendet +werden, welches zuvor in der Bestandsabfrage durch das Kreditin- +stitut geliefert wurde. + + +![](figures/123.2) + + +Falls dieser Geschäftsvorfall kreditinstitutsseitig oder vom Kunden- +produkt nicht angeboten wird, kann durch den Kunden eine Ände- +rung erreicht werden, indem er die vorbereitete Überweisung löscht +und anschließend neu einreicht. + + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +## a) Kundenauftrag + + +### . Beschreibung + +Es können grundsätzlich alle Felder geändert werden. + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Vorbereitete SEPA-Überweisung ändern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKCVA
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3SEPA Descriptor1DEan.256M1
4SEPA pain messa- ge Skeleton1DEbin..M1
5Auftragsidentifikati- on1DEan.99M1
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
404		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + +## . Belegungsrichtlinien + + +### Kontoverbindung international + +IBAN und BIC müssen der IBAN in DebtorAccount bzw. der +BIC in DebtorAgent entsprechen. + + +### SEPA pain message Skeleton + +XML-Skeleton eines erlaubten „SEPA Überweisung Kunde-Bank"-Schemas It. +HISPAS. + + +## b) Kreditinstitutsrückmeldung + + +### . Beschreibung + +Es werden keine Datensegmente zurückgemeldet. + + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
0020Vorbereitete SEPA-Überweisung wurde geändert
9010Vorbereitete SEPA-Überweisung ist zur Zeit nicht änderbar
9160Auftragsidentifikation fehlt
9160Auftragsidentifikation existiert nicht
+ + +## c) Bankparameterdaten + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Vorbereitete SEPA-Überweisung ändern Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HICVAS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Geschäftsvorfälle		Stand: 07.08.2015Seite: 405
+ + +# C.10.2.4.3 Bestand vorbereiteter SEPA-Überweisungen anzeigen + + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +## a) Kundenauftrag + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Bestand vorbereiteter SEPA-Überweisungen abfragen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKCVB
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3Unterstützte SEPA pain messages1DEGM1
4Maximale Anzahl EinträgeDEnum..4C1>0
O: ,,Eingabe Anzahl Ein- träge erlaubt“ (BPD) = „J“ N: sonst
5Aufsetzpunkt1DEan..35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +## b) Kreditinstitutsrückmeldung + + +### . Beschreibung + +Für jede vorliegende vorbereitete Überweisung wird ein Segment zurück gemeldet. + + +![](figures/125.1) + + +Falls der Rückmeldecode 3041 gesendet wird, muss direkt im An- +schluss ein Bestandsabruf des korrespondierenden Nicht-SEPA- +Bestandes durchgeführt werden. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Bestand vorbereiteter SEPA-Überweisungen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HICVB
Bezugssegment:HKCVB
Version:1
Anzahl:n
Sender:Kunde
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
406		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3SEPA Descriptor1DEan.256M1
4SEPA pain messa- ge Skeleton1DEbin..M1
5Auftragsidentifikati- on1DEan..99M1
+ + +## . Belegungsrichtlinien + + +### Kontoverbindung international + +IBAN und BIC müssen der IBAN in DebtorAccount bzw. der +BIC in DebtorAgent entsprechen. + + +### SEPA pain message Skeleton + +XML-Skeleton eines erlaubten ,,SEPA Überweisung Kunde-Bank"-Schemas It. +HISPAS. + + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
3010Es liegen keine Einträge vor
3041ein weiterer Bestand liegt vor HKVUB
3042kein weiterer Bestand liegt vor HKVUB
3043keine Informationen über weitere Bestände HKVUB
9210Keine gültige Kontonummer des Kunden
+ + +## c) Bankparameterdaten + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Bestand vorbereiteter SEPA-Überweisungen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HICVBS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Bestand vorbereitete SEPA- Überweisungen1DEGM1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Geschäftsvorfälle		Stand: 07.08.2015Seite: 407
+ + +# C.10.2.4.4 Vorbereitete SEPA-Überweisung löschen + +Realisierung Bank: +optional + +Realisierung Kunde: optional + + +## a) Kundenauftrag + + +### . Beschreibung + +Die Identifikation der zu löschenden Überweisung erfolgt anhand der Auftrags- +identifikation. Der Kunde hat die gültigen Daten der vorbereiteten Überweisung ein- +zustellen, wenn dies kreditinstitutsseitig in den BPD gefordert ist. Diese dienen dann +z. B. zu Plausibilitätsprüfungen. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Vorbereitete SEPA-Überweisung löschen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKCVL
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3SEPA Descriptor1DEan.256C1M: ,"Senden der Auftrags- daten erforderlich" (BPD) „J“
O: sonst
4SEPA pain messa- ge Skeleton1DEbin..C1M: ,"Senden der Auftrags- daten erforderlich" (BPD) “ل„
O: sonst
5Auftragsidentifikati- on1DEan.99M1
+ + +## . Belegungsrichtlinien + + +### Kontoverbindung international + +IBAN und BIC müssen der IBAN in DebtorAccount bzw. der +BIC in DebtorAgent entsprechen. + + +### SEPA pain message Skeleton + +XML-Skeleton eines erlaubten ,,SEPA Überweisung Kunde-Bank"-Schemas It. +HISPAS. + + +![](figures/127.1) + + +Muss die SEPA pain message in der Kundennachricht eingestellt +werden, so muss zwingend das gleiche pain message-Schema +verwendet werden, welches zuvor in der Bestandsabfrage durch +das Kreditinstitut geliefert wurde. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
408		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + +## b) Kreditinstitutsrückmeldung + + +### . Beschreibung + +Es werden keine Datensegmente zurückgemeldet. + + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
0020Vorbereitete Überweisung wurde gelöscht
3020BIC veraltet. Die neue BIC lautet
9010Vorbereitete Überweisung kann zur Zeit nicht gelöscht werden
9160Auftragsidentifikation fehlt
9210Keine Berechtigung für dieses Konto
+ + +## c) Bankparameterdaten + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Vorbereitete SEPA-Überweisung löschen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HICVLS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter vorberei- tete SEPA- Überweisung lö- schen1DEGM1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 409
+ + +# C.10.2.5 SEPA-Einzellastschriften + +Es gelten die Festlegungen zur SEPA-Basislastschrift sowie SEPA-COR1- +Lastschrift laut DFÜ-Abkommen (vgl. [DFÜ-Abkommen], Kapitel 2). + + +![](figures/129.1) + + +Zur Bearbeitung von SEPA-Lastschriften ist der vorherige Ab- +schluss einer entsprechenden Inkassovereinbarung zwischen Kun- +de und Kreditinstitut erforderlich, mit der der Kunde (Zahlungsemp- +fänger) zum SEPA-Lastschriftverfahren zugelassen wird und in de- +ren Rahmen er sich verpflichtet hat, nur solche Lastschriften zum +Einzug einzureichen, für die ihm eine schriftliche Einzugsermächti- +gung des Zahlungspflichtigen (Mandat) vorliegt. Sofern diese Vo- +raussetzung nicht gegeben ist, ist dem Kunden in den UPD die Aus- +führung dieses Geschäftsvorfalls nicht zu gestatten. + + +# C.10.2.5.1 Einreichung SEPA-Einzellastschrift + +Gelöscht + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
410		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + +# C.10.2.5.2 SEPA-Lastschriftwiderspruch + +Bei SEPA-Lastschriften ist der Kunde grundsätzlich berechtigt, innerhalb definierter +Fristen Widerspruch einzulegen. Eine Ausnahme hiervon bildet die B2B-Direct De- +bit, welche durch das EPC definiert wird und speziellen Regelungen unterliegt. + +Neben SEPA-Lastschriften, die das Kundenprodukt mit Hilfe des Geschäftsvorfalls +„Bestand rückgabefähiger SEPA-Lastschriften" erhalten hat, sollte auch bei SEPA- +Lastschriften, die nicht elektronisch sondern bspw. als Kontoauszug vorliegen, ein +Widerspruch möglich sein. In diesem Fall müssen dem Kunden jedoch die für den +Geschäftsvorfall notwendigen Angaben zur Buchung vorliegen. + + +![](figures/130.1) + + +Unterstützt die Bank den Abruf eines SEPA-Lastschriftwider- +spruchbestandes und kann im Rahmen dieser Bestandsanzeige ein +Auftrag durch eine eindeutige Auftragsidentifikation identifiziert wer- +den, wird empfohlen, im Rahmen eines SEPA- +Lastschriftwiderspruchs die Auftragsidentifikation zu verwenden. +Der Kunde sollte darauf hingewiesen werden, dass ein SEPA- +Lastschriftwiderspruch für den Einreicher i.d.R. gebührenpflichtig ist. + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +## a) Kundenauftrag + + +### . Beschreibung + +Um eine eindeutige Identifizierung der SEPA-Lastschrift zu ermöglichen, sollten +möglichst viele Daten der Buchung angegeben werden (z.B. auch die Primanoten- +nummer). + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:SEPA-Lastschriftwiderspruch einreichen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKDSW
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 411
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international Kunde1DEGkti#C1M: ,"Senden der Auftrags- daten erforderlich" (BPD) „J“
O: sonst
3Buchungszeitpunkt1DEGtsp#C1M: ,"Senden der Auftrags- daten erforderlich" (BPD) „J“
O: sonst
4Betrag2DEGbtg#C1>0; M: ,"Senden der Auf- tragsdaten erforderlich" (BPD) „J“ O: sonst
5Kontoverbindung international Zah- lungsempfänger1DEGkti#C1M: ,"Senden der Auftrags- daten erforderlich" (BPD) „J“ O: sonst
6Name Zahlungs- empfänger1DEan..70C1M: ,"Senden der Auftrags- daten erforderlich" (BPD) „J“
O: sonst
7Code zur Identifizie- rung des Geschäfts1DEan..35O1
8Ende-zu-Ende- Identifikation1DEan.35O1
9Mandatsreferenz1DEan..35O1
10Gläubiger-ID1DEan..35O1
11Rückgabegrund1DEcode4O1
12Verwendungszweck SEPA1DEan..140O1
13Auftragsidentifikati- on1DEan..99C1O: ,"Senden der Auftrags- daten erforderlich" (BPD) „J“ M: sonst
+ + +## . Belegungsrichtlinien + + +### Kontoverbindung international Kunde + +Kontoverbindung des Kunden, auf der die Lastschrift verbucht wurde (Zahlungs- +pflichtiger). + + +### Buchungszeitpunkt + +Das Datum darf auch in der Zukunft liegen und kann somit zur Rückgabe vor Bu- +chung (SDD-Refusal) genutzt werden. + + +### Kontoverbindung international Zahlungsempfänger + +Kontoverbindung des Empfängers, welcher die betroffene Lastschrift ursprünglich +ausgelöst hatte. + + +### Name Zahlungsempfänger + +Name des Auftraggebers der Lastschrift (Zahlungsempfänger) + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
412		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + +## b) Kreditinstitutsrückmeldung + + +### . Format + +Allgemeine Kreditinstitutsnachricht ohne Datensegmente + + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
9010Angegebene SEPA-Lastschrift existiert nicht
9010Angegebene Buchung ist keine SEPA-Lastschrift
9010Rückgabefrist überschritten
9010SEPA-Lastschrift ist nicht rückgabefähig
9010SEPA-Lastschrift ist nicht eindeutig identifizierbar
+ + +### c) Bankparameterdaten + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:SEPA-Lastschriftwiderspruch Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIDSWS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter SEPA- Lastschriftwider- spruch1DEGM1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:SEPA-Zahlungsverkehr
Geschäftsvorfälle		Stand: 07.08.2015Seite: 413
+ + +# C.10.2.5.3 Bestand rückgabefähiger SEPA-Lastschriften + + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +## a) Kundenauftrag + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Bestand SEPA-Lastschriftwiderspruch anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKDSB
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1[Segmentkopf](file:///D:/Benutzerprofile/mindnich/Desktop/FINTS%2030%20Release%202012/Lastschrift%20Bestand%20und%20Rückgabe%20mit%20Rückgabegrund%20und%20Gläubiger-ID%20Korrektur.docx%23Segmentkopf)1DEGM1
2[Kontoverbindung](file:///D:/Benutzerprofile/mindnich/Desktop/FINTS%2030%20Release%202012/Lastschrift%20Bestand%20und%20Rückgabe%20mit%20Rückgabegrund%20und%20Gläubiger-ID%20Korrektur.docx%23Kontoverbindung_international_Kunde) [international Kunde](file:///D:/Benutzerprofile/mindnich/Desktop/FINTS%2030%20Release%202012/Lastschrift%20Bestand%20und%20Rückgabe%20mit%20Rückgabegrund%20und%20Gläubiger-ID%20Korrektur.docx%23Kontoverbindung_international_Kunde)1DEGkti#M1
3[Von Datum](file:///D:/Benutzerprofile/mindnich/Desktop/FINTS%2030%20Release%202012/Lastschrift%20Bestand%20und%20Rückgabe%20mit%20Rückgabegrund%20und%20Gläubiger-ID%20Korrektur.docx%23Von_Datum)1DEdat#C1O: "Zeitraum möglich“
(BPD) „J" N: sonst
4[Bis Datum](file:///D:/Benutzerprofile/mindnich/Desktop/FINTS%2030%20Release%202012/Lastschrift%20Bestand%20und%20Rückgabe%20mit%20Rückgabegrund%20und%20Gläubiger-ID%20Korrektur.docx%23Bis_Datum)1DEdat#C1O: "Zeitraum möglich“
(BPD) „J" N: sonst
5[Maximale](file:///D:/Benutzerprofile/mindnich/Desktop/FINTS%2030%20Release%202012/Lastschrift%20Bestand%20und%20Rückgabe%20mit%20Rückgabegrund%20und%20Gläubiger-ID%20Korrektur.docx%23Maximale_Anzahl_Einträge) [Anzahl](file:///D:/Benutzerprofile/mindnich/Desktop/FINTS%2030%20Release%202012/Lastschrift%20Bestand%20und%20Rückgabe%20mit%20Rückgabegrund%20und%20Gläubiger-ID%20Korrektur.docx%23Maximale_Anzahl_Einträge) [Einträge](file:///D:/Benutzerprofile/mindnich/Desktop/FINTS%2030%20Release%202012/Lastschrift%20Bestand%20und%20Rückgabe%20mit%20Rückgabegrund%20und%20Gläubiger-ID%20Korrektur.docx%23Maximale_Anzahl_Einträge)1DEnum..4C1>0
O: ,,Eingabe Anzahl Ein- träge erlaubt“ (BPD) = „J“ N: sonst
6[Aufsetzpunkt](file:///D:/Benutzerprofile/mindnich/Desktop/FINTS%2030%20Release%202012/Lastschrift%20Bestand%20und%20Rückgabe%20mit%20Rückgabegrund%20und%20Gläubiger-ID%20Korrektur.docx%23Aufsetzpunkt)1DEan..35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +## . Belegungsrichtlinien + + +### Kontoverbindung international Kunde + +Die Kontoverbindung des Kunden, auf der die Lastschrift verbucht wurde. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
414		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + +#### b) Kreditinstitutsrückmeldung + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Bestand SEPA-Lastschriftwiderspruch rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIDSB
Bezugssegment:HKDSB
Version:1
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international Kunde1DEGkti#M1
3Buchungszeitpunkt1DEGtsp#M1
4Betrag2DEGbtg#M1>0
5Kontoverbindung international Zah- lungsempfänger1DEGkti#M1
6Name Zahlungs- empfänger1DEan..70M1
7Code zur Identifizie- rung des Geschäfts1DEan..35O1
8Ende-zu-Ende- Identifikation1DEan..35O1
9Mandatsreferenz1DEan..35O1
10Gläubiger-ID1DEan..35O1
11Verwendungszweck SEPA1DEan.140O1
12Auftragsidentifikati- on1DEan.99O1
13Valuta1DEdat#O1
14Widerrufen1DEjn#M1
15Datum Widerrufen1DEdat#O1
+ + +## . Belegungsrichtlinien + + +### Kontoverbindung international Kunde + +Kontoverbindung des Kunden, auf der die Lastschrift verbucht wurde + + +### Buchungszeitpunkt + +Das Datum darf auch in der Zukunft liegen und kann somit zur Darstellung von Pre- +Avis genutzt werden. + + +### Kontoverbindung international Zahlungsempfänger + +Kontoverbindung des Empfängers, welcher die betroffene Lastschrift ursprünglich +ausgelöst hatte. Es wird zusätzlich auch der Name dieses Lastschrifteinreichers (/- +kontos) zur Verfügung gestellt. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 415
+ + +### Auftragsidentifikation + +eindeutige Zuordnung zu einem Lastschriftauftrag; Diese Auftragsidentifikation kann +für den Widerspruch einer Lastschrift zu deren Identifikation verwendet werden +(HKLSW - Lastschriftwiderspruch einreichen). + + +### Widerrufen + +gibt an, ob die gemeldete Lastschrift widerrufen werden kann oder nicht. Damit steht +dem Benutzer eine Kontrolle und Historie der widerrufenen Lastschriften zur Verfü- +gung. + + +### Datum Widerrufen + +In Falle eines Widerrufs kann hier das Datum des Widerrufs angegeben werden. + + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
3010Es liegen keine Einträge vor
3041ein weiterer Bestand liegt vor HKLWB
3042kein weiterer Bestand liegt vor HKLWB
3043keine Informationen über weitere Bestände HKLWB
9010Bereichende darf nicht vor Bereichanfang liegen
9010Datum liegt nicht in der Zukunft
9010Keine gültige Kontonummer des Kunden
+ + +## c) Bankparameterdaten + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Bestand Lastschriftwiderspruch Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIDSBS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Bestand SEPA- Lastschriftwider- spruch1DEGM1
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
416		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + +# C.10.2.5.4 Terminierte SEPA-Lastschrift + +Bei der terminierten SEPA-Lastschrift bestimmt der Einreicher durch Angabe eines +in der Zukunft liegenden Fälligkeitsdatums in Feld RequestedCollectionDate , dass zu diesem Datum der in der SEPA-Lastschrift enthaltene Einzel- +auftrag auf dem Konto des Bezogenen belastet werden soll. + +Folgende Geschäftsvorfälle sind vorgesehen: + +. Einreichung terminierter SEPA-Einzellastschriften + +. Einreichung terminierter SEPA-COR1-Einzellastschriften + +· Änderung terminierter SEPA-Einzellastschriften + +. Bestand terminierter SEPA-Einzellastschriften abrufen + +· Löschung terminierter SEPA-Einzellastschriften + + +## C.10.2.5.4.1 Einreichung terminierter SEPA-Einzellastschriften (Segmentversion 1) + + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +### a) Kundenauftrag + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Terminierte SEPA-Einzellastschrift einreichen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKDSE
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3SEPA Descriptor1DEan256M1
4SEPA pain messa- ge1DEbin..M1
+ + +### . Belegungsrichtlinien + + +### Kontoverbindung international + +IBAN und BIC müssen der IBAN in CreditorAccount bzw. der +BIC in CreditorAgent entsprechen. + + +### SEPA pain message + +Erlaubtes ,,SEPA Lastschrift Kunde-Bank"-Schema It. HISPAS. Als Locallnstru- +mentSEPACode ist lediglich CORE für die SEPA-Basislastschrift +erlaubt. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Geschäftsvorfälle		Stand: 07.08.2015Seite: 417
+ + +## b) Kreditinstitutsrückmeldung + + +### . Beschreibung + + +![](figures/137.1) + + +Falls das Kreditinstitut schon bei der Einreichung eine Auftragsiden- +tifikation zurückmelden kann, sollte diese Möglichkeit genutzt wer- +den. Andernfalls hat das Kundensystem vor einer Änderung oder +Löschung den gesamten Bestand abzurufen (s. C.10.2.5.4.5 „Be- +stand terminierter SEPA-Einzellastschriften abrufen“), um in den Be- +sitz der Auftragsidentifikation zu gelangen. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Einreichung terminierter SEPA-Einzellastschrift bestätigen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIDSE
Bezugssegment:HKDSE
Version:1
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Auftragsidentifika- tion1DEan.99O1
+ + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
0020Auftrag zur Ausführung vorgemerkt
3030Datum ist kein Bankgeschäftstag. Der Auftrag wird ausgeführt am ...
3070Auftrag wird unter Referenz xxx verarbeitet
9010Keine Berechtigung für SEPA-Lastschriftverfahren
9210Mindestzeitraum bis zum Ausführungstermin überschritten
9210Datum liegt nicht in der Zukunft
9210Datum liegt zu weit in der Zukunft
9210Datum ist kein Buchungstag
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
418		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + +### c) Bankparameterdaten + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Terminierte SEPA-Einzellastschrift einreichen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIDSES
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter termi- nierte SEPA- Einzellastschrift ein- reichen1DEGM1
+ + +##### C.10.2.5.4.2 Einreichung terminierter SEPA-Einzellastschriften (Segmentversion 22) + + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +### a) Kundenauftrag + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Terminierte SEPA-Einzellastschrift einreichen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKDSE
Bezugssegment:-
Version:22
Sender:Kunde
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 419
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3SEPA Descriptor1DEan.256M1
4SEPA pain messa- ge1DEbin..M1
+ + +### . Belegungsrichtlinien + + +#### Kontoverbindung international + +IBAN und BIC müssen der IBAN in CreditorAccount bzw. der +BIC in CreditorAgent entsprechen. + + +#### SEPA pain message + +Erlaubtes ,,SEPA Lastschrift Kunde-Bank"-Schema It. HISPAS. Es gelten die Vorga- +ben aus der BPD zu den unterstützten SEPA Lastschriftarten zur Belegung des Fel- +des Es gelten die Vorgaben aus der BPD zu den unterstützten SEPA- +Lastschriftarten zur Belegung des Feldes LocalInstrumentSEPACode +. + + +## b) Kreditinstitutsrückmeldung + + +### . Beschreibung + + +![](figures/139.1) + + +Falls das Kreditinstitut schon bei der Einreichung eine Auftragsiden- +tifikation zurückmelden kann, sollte diese Möglichkeit genutzt wer- +den. Andernfalls hat das Kundensystem vor einer Änderung oder +Löschung den gesamten Bestand abzurufen (s. C.10.2.5.4.5 „Be- +stand terminierter SEPA-Einzellastschriften abrufen“), um in den Be- +sitz der Auftragsidentifikation zu gelangen. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Einreichung terminierter SEPA-Einzellastschrift bestätigen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIDSE
Bezugssegment:HKDSE
Version:22
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Auftragsidentifika- tion1DEan.99O1
+ + +◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
420		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
0020Auftrag zur Ausführung vorgemerkt
3030Datum ist kein Bankgeschäftstag. Der Auftrag wird ausgeführt am ...
3070Auftrag wird unter Referenz xxx verarbeitet
9010Keine Berechtigung für SEPA-Lastschriftverfahren
9210Mindestzeitraum bis zum Ausführungstermin überschritten
9210Datum liegt nicht in der Zukunft
9210Datum liegt zu weit in der Zukunft
9210Datum ist kein Buchungstag
+ + +### c) Bankparameterdaten + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Terminierte SEPA-Einzellastschrift einreichen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIDSES
Bezugssegment:HKVVB
Version:22
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter termi- nierte SEPA- Einzellastschrift ein- reichen22DEGM1
+ + +# C.10.2.5.4.3 Einreichung terminierter SEPA-COR1-Einzellastschriften + +Bei der terminierten SEPA-COR1-Einzellastschrift ist die Vorlaufzeit auf einen Tag +verkürzt. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Geschäftsvorfälle		Stand: 07.08.2015Seite: 421
+ + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +## a) Kundenauftrag + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Terminierte SEPA-COR1-Einzellastschrift einreichen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKDSC
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3SEPA Descriptor1DEan.256M1
4SEPA pain messa- ge1DEbin..M1
+ + +## . Belegungsrichtlinien + + +### Kontoverbindung international + +IBAN und BIC müssen der IBAN in CreditorAccount bzw. der +BIC in CreditorAgent entsprechen. + + +### SEPA pain message + +Erlaubtes ,,SEPA Lastschrifteinreichung Kunde-Bank"-Schema It. HISPAS. + +Als LocalInstrumentSEPACode ist lediglich COR1 für die SEPA- +COR1-Lastschrift erlaubt. + + +## b) Kreditinstitutsrückmeldung + +. Beschreibung + + +![](figures/141.1) + + +Falls das Kreditinstitut schon bei der Einreichung eine Auftragsiden- +tifikation zurückmelden kann, sollte diese Möglichkeit genutzt wer- +den. Andernfalls hat das Kundensystem vor einer Änderung oder +Löschung den gesamten Bestand abzurufen (s. C.10.2.5.4.5 „Be- +stand terminierter SEPA-Einzellastschriften abrufen“), um in den Be- +sitz der Auftragsidentifikation zu gelangen. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
422		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + +## . Format + +Name: + +Einreichung terminierter SEPA-COR1-Einzellastschrift bestä- +tigen + +Typ: + +Segment + +Segmentart: + +Geschäftsvorfall + +Kennung: + +HIDSC + +Bezugssegment: + +HKDSC + +Version: + +1 + +Anzahl: + +1 + +Sender: + +Kreditinstitut + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Auftragsidentifika- tion1DEan.99O1
+ + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
0020Auftrag zur Ausführung vorgemerkt
3030Datum ist kein Bankgeschäftstag. Der Auftrag wird ausgeführt am ...
3070Auftrag wird unter Referenz xxx verarbeitet
9010Keine Berechtigung für SEPA-Lastschriftverfahren
9210Mindestzeitraum bis zum Ausführungstermin überschritten
9210Datum liegt nicht in der Zukunft
9210Datum liegt zu weit in der Zukunft
9210Datum ist kein Buchungstag
+ + +## c) Bankparameterdaten + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Terminierte SEPA-COR1-Einzellastschrift Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIDSCS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 423
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter termi- nierte SEPA-COR1- Einzellastschrift1DEGM1
+ + +#### C.10.2.5.4.4 Änderung terminierter SEPA-Einzellastschriften + + +![](figures/143.1) + + +Dieser Geschäftsvorfall darf vom Kreditinstitut nur angeboten wer- +den, wenn es eine Auftragsidentifikation unterstützt, da ansonsten +die Identifikation der zu ändernden Lastschrift nicht möglich ist. + + +![](figures/143.2) + + +Vor der Änderung einer terminierten SEPA- bzw. SEPA-COR1- +Einzellastschrift hat eine Abholung des aktuellen Bestandes beim +Kreditinstitut (s.u.) zu erfolgen, um sicherzustellen, dass der Kunde +auf Basis des korrekten Bestandes operiert. Nur so ist gewährleis- +tet, dass zwischenzeitliche Änderungen auf anderem Wege (z.B. +schriftlich oder per Selbstbedienungsterminal) von der Kundensoft- +ware berücksichtigt werden. In der Kundennachricht muss zwingend +das gleiche pain message-Schema verwendet werden, welches zu- +vor in der Bestandsabfrage durch das Kreditinstitut geliefert wurde. + + +![](figures/143.3) + + +Falls dieser Geschäftsvorfall kreditinstitutsseitig oder vom Kunden- +produkt nicht angeboten wird, kann durch den Kunden eine Ände- +rung erreicht werden, indem er die terminierte SEPA- bzw. SEPA- +COR1-Einzellastschriften löscht und anschließend neu einreicht. + + +![](figures/143.4) + + +Eine minimale Vorlaufzeit für die Einreichung des Änderungsauf- +trags einer terminierten SEPA-COR1-Einzellastschrift ist nicht vor- +gesehen. Es können jedoch nur Aufträge geändert werden, die auch +im Bestand aufgeführt werden. + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +## a) Kundenauftrag + + +### . Beschreibung + +Die Felder sind so zu belegen, wie die terminierte SEPA- bzw. SEPA-COR1- +Einzellastschriften nach der Änderung ausgeführt werden soll, d.h. es sind nicht nur +die zu ändernden Felder zu belegen. Die gleichzeitige Änderung mehrerer Felder ist +möglich. Um die Referenzierung auf den Ursprungsauftrag zu ermöglichen, ist in + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
424		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + +das Element ,,Auftragsidentifikation" das vom Kreditinstitut mitgeteilte Iden- +tifikationsmerkmal einzustellen. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Terminierte SEPA-Einzellastschrift ändern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKDSA
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3SEPA Descriptor1DEan.256M1
4SEPA pain messa- ge1DEbin..M1
5Auftragsidentifikati- on1DEan.99M1
+ + +### . Belegungsrichtlinien + + +#### Kontoverbindung international + +IBAN und BIC müssen der IBAN in CreditorAccount bzw. der +BIC in CreditorAgent entsprechen. + + +#### SEPA pain message + +Erlaubtes ,,SEPA Lastschrift Kunde-Bank"-Schema It. HISPAS. + + +#### b) Kreditinstitutsrückmeldung + + +#### . Beschreibung + + +![](figures/144.1) + + +Falls eine neue Auftragsidentifikation vergeben wurde, ist der loka- +le Bestand im Kundenprodukt zu aktualisieren. + + +##### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Änderung terminierter SEPA-Einzellastschrift bestätigen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIDSA
Bezugssegment:HKDSA
Version:1
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 425
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Auftragsidentifika- tion1DEan.99M1
3Auftragsidentifika- tion alt1DEan.99O1
+ + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
0020Auftrag ausgeführt
9010Auftrag zur Zeit nicht änderbar
9010Auftrag bereits zur Löschung vorgemerkt
9010Auftrag inkonsistent
9160Auftragsidentifikation fehlt
9210Datum liegt zu weit in der Zukunft
9210Datum liegt nicht in der Zukunft
9210Auftrag existiert nicht, Auftragsidentifikation unbekannt
9210IBAN des Auftraggebers darf nicht geändert werden
9210Das angegebene Datum ist kein Ausführungsdatum
+ + +## c) Bankparameterdaten + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Terminierte SEPA-Einzellastschriften ändern Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIDSAS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter termi- nierte SEPA- Einzellastschrift än- dern1DEGM1
+ + +# C.10.2.5.4.5 Bestand terminierter SEPA-Einzellastschriften abrufen (Segmentversion 1) + +Der Kunde ruft die im Kreditinstitut zu einem Konto hinterlegten terminierten Aufträ- +ge ab, die noch zur Ausführung anstehen. Für jeden terminierten SEPA- bzw. +SEPA-COR1-Einzellastschriftauftrag wird ein entsprechendes Datensegment in die +Rückmeldungsnachricht eingestellt. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 426Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +## a) Kundenauftrag + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Bestand terminierter SEPA-Einzellastschriften anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKDBS
Bezugssegment:-
Version:1
+ + +Sender: + +Kunde + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3Unterstützte SEPA pain messages1DEGM1
4Von Datum1DEdat#C1O: „Zeitraum möglich“ (BPD) „J“ N: sonst
5Bis Datum1DEdat#C1O: „Zeitraum möglich“ (BPD) „J“ N: sonst
6Maximale Anzahl Einträge1DEnum..4C1>0
O: ,,Eingabe Anzahl Ein- träge erlaubt“ (BPD) = „J“ N: sonst
7Aufsetzpunkt1DEan..35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +## b) Kreditinstitutsrückmeldung + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Bestand terminierter SEPA-Einzellastschriften rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIDBS
Bezugssegment:HKDBS
Version:1
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 427
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3SEPA Descriptor1DEan.256M1
4SEPA pain messa- ge1DEbin..M1
5Auftragsidentifikati- on1DEan.99C1M: vom Institut wurde Auf- tragsidentifikation erteilt N: sonst
6Auftrag löschbar1DEjn#O1
7Auftrag änderbar1DEjn#O1
+ + +### . Belegungsrichtlinien + +SEPA pain message + +,SEPA Lastschrift Kunde-Bank"-Schema It. HISPAS. + + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
3010Es liegen keine Einträge vor
9210Bereichende darf nicht vor Bereichanfang liegen
9210Datum liegt nicht in der Zukunft
9210Keine gültige IBAN des Kunden
+ + +### c) Bankparameterdaten + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Bestand terminierter SEPA-Einzellastschriften Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIDBSS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Bestand terminierter SEPA- Einzellastschriften1DEGM1
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
428		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + +# C.10.2.5.4.6 Bestand terminierter SEPA-Einzellastschriften abrufen (Segmentversion 2) + +Der Kunde ruft die im Kreditinstitut zu einem Konto hinterlegten terminierten Aufträ- +ge ab, die noch zur Ausführung anstehen. Für jeden terminierten SEPA- bzw. +SEPA-COR1- Einzellastschriftauftrag wird ein entsprechendes Datensegment in die +Rückmeldungsnachricht eingestellt. + +Realisierung Bank: +optional + +Realisierung Kunde: +optional + + +## a) Kundenauftrag + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Bestand terminierter SEPA-Einzellastschriften anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKDBS
Bezugssegment:-
Version:22
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3Unterstützte SEPA pain messages1DEGM1
4Von Datum1DEdat#C1O: „Zeitraum möglich“ (BPD) „J“ N: sonst
5Bis Datum1DEdat#C1O: „Zeitraum möglich“ (BPD) „J“ N: sonst
6Maximale Anzahl Einträge1DEnum..4C1>0
O: ,,Eingabe Anzahl Ein- träge erlaubt“ (BPD) = „J“ N: sonst
7Aufsetzpunkt1DEan..35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +## b) Kreditinstitutsrückmeldung + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 429
+ + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Bestand terminierter SEPA-Einzellastschriften rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIDBS
Bezugssegment:HKDBS
Version:22
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3SEPA Descriptor1DEan.256M1
4SEPA pain messa- ge1DEbin..M1
5Auftragsidentifikati- on1DEan..99C1M: vom Institut wurde Auf- tragsidentifikation erteilt N: sonst
6SEPA-C- CodeSEPA-C-Code14DED Ecode- de- code141, 2, 31, 2, 3
7Auftrag änderbar1DEjn#O1
8Status SEPA- AuftragStatus SEPA Auftrag14DED Ecode- de- code141, 2, 3, 4, 51, 2, 3, 4, 5
+ + +### . Belegungsrichtlinien + +SEPA pain message + +,SEPA Lastschrift Kunde-Bank"-Schema It. HIDBSS bzw. HIDBSS bzw. HISPAS. + + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
3010Es liegen keine Einträge vor
9210Bereichende darf nicht vor Bereichanfang liegen
9210Datum liegt nicht in der Zukunft
9210Keine gültige IBAN des Kunden
+ + +### c) Bankparameterdaten + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Bestand terminierter SEPA-Einzellastschriften Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIDBSS
Bezugssegment:HKVVB
Version:22
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
430		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Bestand terminierter SEPA- Einzellastschriften22DEGM1
+ + +# C.10.2.5.4.7 Löschung terminierter SEPA-Einzellastschriften + +Die zu löschende SEPA- bzw. SEPA-COR1-Einzellastschrift wird über eine Auf- +tragsidentifikation, die beim Abruf des Bestandes mitübertragen wird, bestimmt. Ne- +ben der Auftragsidentifikation müssen auch die restlichen Auftragsdaten eingestellt +werden, wenn dies kreditinstitutsseitig in den BPD gefordert ist. Diese dienen dann +z.B. zu Plausibilitätsprüfungen. + + +![](figures/150.1) + + +Dieser Geschäftsvorfall darf vom Kreditinstitut nur angeboten wer- +den, wenn es eine Auftragsidentifikation unterstützt, da ansonsten +die Identifikation der zu löschenden SEPA- bzw. SEPA-COR1- Ein- +zellastschriften nicht möglich ist. + +Zu löschende terminierte Aufträge liegen immer in der Zukunft. Eine minimale Vor- +laufzeit für die Einreichung des Löschauftrags ist nicht vorgesehen. Es können je- +doch nur Aufträge gelöscht werden, die auch im Bestand aufgeführt werden. + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +## a) Kundenauftrag + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Terminierte SEPA-Einzellastschrift löschen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKDSL
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 431
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3SEPA Descriptor1DEan.256C1M: ,"Senden der Auftrags- daten erforderlich" (BPD) „J“ O: sonst
4SEPA pain messa- ge1DEbin..C1M: ,"Senden der Auftrags- daten erforderlich" (BPD) „J“ O: sonst
5Auftragsidentifikati- on1DEan.99M1
+ + +## . Belegungsrichtlinien + + +### Kontoverbindung international + +IBAN und BIC müssen der IBAN in CreditorAccount bzw. der +BIC in CreditorAgent entsprechen. + + +### SEPA pain message + +Erlaubtes ,,SEPA Lastschrift Kunde-Bank"-Schema It. HISPAS. + + +![](figures/151.1) + + +Muss die SEPA pain message in der Kundennachricht eingestellt +werden, so muss zwingend das gleiche pain message-Schema +verwendet werden, welches zuvor in der Bestandsabfrage durch +das Kreditinstitut geliefert wurde. + + +### b) Kreditinstitutsrückmeldung + + +#### . Beschreibung + +Es werden keine Datensegmente zurückgemeldet. + +◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag zur Löschung vorgemerkt
0020Auftrag gelöscht
9010Löschung nicht mehr möglich, da Auftrag bereits zur Löschung vorgemerkt
9010Auftragsidentifikation stimmt nicht mit Auftragsdaten überein
9210Auftrag existiert nicht bzw. wurde bereits ausgeführt
+ + +#### c) Bankparameterdaten + + +##### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Terminierte SEPA-Einzellastschrift löschen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIDSLS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + +
Nr.NameVer-TypFor-Län-Sta-An-Restriktionen
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 432Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
sionmatgetuszahl
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Lö- schung terminierter SEPA- Einzellastschrift1DEGM1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 433
+ + +# C.10.2.6 SEPA-Firmeneinzellastschriften + +Es gelten die Festlegungen zur SEPA-Firmenlastschrift laut DFÜ-Abkommen (vgl. +[DFÜ-Abkommen], Kapitel 2). + + +![](figures/153.1) + + +Zur Bearbeitung von SEPA-Firmeneinzellastschriften ist der vorhe- +rige Abschluss einer entsprechenden Inkassovereinbarung zwi- +schen Kunde und Kreditinstitut erforderlich, mit der der Kunde (Zah- +lungsempfänger) zum SEPA-Lastschriftverfahren zugelassen wird +und in deren Rahmen er sich verpflichtet hat, nur solche Lastschrif- +ten zum Einzug einzureichen, für die ihm eine schriftliche Einzugs- +ermächtigung des Zahlungspflichtigen (Mandat) vorliegt. Sofern die- +se Voraussetzung nicht gegeben ist, ist dem Kunden in den UPD +die Ausführung dieses Geschäftsvorfalls nicht zu gestatten. + + +# C.10.2.6.1 Einreichung SEPA-Firmeneinzellastschriften + +Gelöscht + + +## C.10.2.6.2 Terminierte SEPA- Firmeneinzellastschriften + +Bei der terminierten SEPA-Firmeneinzellastschrift bestimmt der Einreicher durch die +Angabe eines in der Zukunft liegenden Fälligkeitsdatums in Feld RequestedCollec- +tionDate , dass zu diesem Datum der in der SEPA-Lastschrift ent- +haltene Einzelauftrag auf dem Konto des Bezogenen belastet werden soll. + +Folgende Geschäftsvorfälle sind vorgesehen: + +· Einreichung terminierter SEPA-Firmeneinzellastschriften + +· Änderung terminierter SEPA-Firmeneinzellastschriften + +. Bestand terminierter SEPA-Firmeneinzellastschriften abrufen + +· Löschung terminierter SEPA- Firmeneinzellastschriften + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
434		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + +## C.10.2.6.2.1 Einreichung terminierter SEPA-Firmeneinzellastschriften (Segmentver- sion 1) + + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +### a) Kundenauftrag + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Terminierte SEPA-Firmeneinzellastschrift einreichen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKBSE
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3SEPA Descriptor1DEan256M1
4SEPA pain messa- ge1DEbin..M1
+ + +### . Belegungsrichtlinien + + +#### Kontoverbindung international + +IBAN und BIC müssen der IBAN in CreditorAccount bzw. der +BIC in CreditorAgent entsprechen. + +SEPA pain message + +Erlaubtes ,,SEPA Lastschrift Kunde-Bank"-Schema It. HISPAS. Als Locallnstru- +mentSEPACode ist lediglich B2B für die SEPA-Firmenlastschrift +erlaubt. + + +### b) Kreditinstitutsrückmeldung + +. Beschreibung + + +![](figures/154.1) + + +Falls das Kreditinstitut schon bei der Einreichung eine Auftragsiden- +tifikation zurückmelden kann, sollte diese Möglichkeit genutzt wer- +den. Andernfalls hat das Kundensystem vor einer Änderung oder +Löschung den gesamten Bestand abzurufen (s. C.10.2.6.2.4 „Be- +stand terminierter SEPA-Firmeneinzellastschrift abrufen“), um in den +Besitz der Auftragsidentifikation zu gelangen. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 435
+ + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Einreichung terminierter SEPA-Firmeneinzellastschrift bestäti-
gen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIBSE
Bezugssegment:HKBSE
Version:1
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Auftragsidentifika- tion1DEan.99O1
+ + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + +Zusätzlich zu den Rückmeldungscodes der Einzellastschrift gelten: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
0020Auftrag zur Ausführung vorgemerkt
3030Datum ist kein Bankgeschäftstag. Der Auftrag wird ausgeführt am ...
9210Mindestzeitraum bis zum Ausführungstermin überschritten
9210Datum liegt nicht in der Zukunft
9210Datum liegt zu weit in der Zukunft
9210Datum ist kein Buchungstag
+ + +### c) Bankparameterdaten + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Terminierte SEPA-Firmeneinzellastschrift einreichen Parame- ter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIBSES
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter termi- nierte SEPA- Firmeneinzellast- schrift einreichen1DEGM1
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
436		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + +## C.10.2.6.2.2 Einreichung terminierter SEPA-Firmeneinzellastschriften (Segmentver- sion 22) + + + + + + + + + + + + + +
RealisierungBank:optional
RealisierungKunde:optional
+ + +### a) Kundenauftrag + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Terminierte SEPA-Firmeneinzellastschrift einreichen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKBSE
Bezugssegment:-
Version:22
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3SEPA Descriptor1DEan.256M1
4SEPA pain messa- ge1DEbin..M1
+ + +### . Belegungsrichtlinien + + +#### Kontoverbindung international + +IBAN und BIC müssen der IBAN in CreditorAccount bzw. der +BIC in CreditorAgent entsprechen. + +SEPA pain message + +Erlaubtes ,,SEPA Lastschrift Kunde-Bank"-Schema It. HISPAS. Als Locallnstru- +mentSEPACode ist lediglich B2B für die SEPA-Firmenlastschrift +erlaubt. + + +### b) Kreditinstitutsrückmeldung + +. Beschreibung + + +![](figures/156.1) + + +Falls das Kreditinstitut schon bei der Einreichung eine Auftragsiden- +tifikation zurückmelden kann, sollte diese Möglichkeit genutzt wer- +den. Andernfalls hat das Kundensystem vor einer Änderung oder +Löschung den gesamten Bestand abzurufen (s. C.10.2.6.2.4 „Be- +stand terminierter SEPA-Firmeneinzellastschrift abrufen“), um in den +Besitz der Auftragsidentifikation zu gelangen. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle
SEPA-Zahlungsverkehr		Stand: 07.08.2015Seite: 437
+ + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Einreichung terminierter SEPA-Firmeneinzellastschrift bestäti-
gen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIBSE
Bezugssegment:HKBSE
Version:22
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Auftragsidentifika- tion1DEan.99O1
+ + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + +Zusätzlich zu den Rückmeldungscodes der Einzellastschrift gelten: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
0020Auftrag zur Ausführung vorgemerkt
3030Datum ist kein Bankgeschäftstag. Der Auftrag wird ausgeführt am ...
9210Mindestzeitraum bis zum Ausführungstermin überschritten
9210Datum liegt nicht in der Zukunft
9210Datum liegt zu weit in der Zukunft
9210Datum ist kein Buchungstag
+ + +### c) Bankparameterdaten + + +#### Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Terminierte SEPA-Firmeneinzellastschrift einreichen Parame- ter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIBSES
Bezugssegment:HKVVB
Version:22
Sender:Kreditinstitut
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 438Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt:
SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter termi- nierte SEPA- Firmeneinzellast- schrift einreichen22DEGM1
+ + +## C.10.2.6.2.3 Änderung terminierter SEPA-Firmeneinzellastschriften + + +![](figures/158.1) + + +Dieser Geschäftsvorfall darf vom Kreditinstitut nur angeboten wer- +den, wenn es eine Auftragsidentifikation unterstützt, da ansonsten +die Identifikation der zu ändernden Lastschrift nicht möglich ist. + + +![](figures/158.2) + + +Vor der Änderung einer terminierten SEPA-Firmeneinzellastschrift +hat eine Abholung des aktuellen Bestandes beim Kreditinstitut (s.u.) +zu erfolgen, um sicherzustellen, dass der Kunde auf Basis des kor- +rekten Bestandes operiert. Nur so ist gewährleistet, dass zwischen- +zeitliche Änderungen auf anderem Wege (z.B. schriftlich oder per +Selbstbedienungsterminal) von der Kundensoftware berücksichtigt +werden. In der Kundennachricht muss zwingend das gleiche pain +message-Schema verwendet werden, welches zuvor in der Be- +standsabfrage durch das Kreditinstitut geliefert wurde. + + +![](figures/158.3) + + +Falls dieser Geschäftsvorfall kreditinstitutsseitig oder vom Kunden- +produkt nicht angeboten wird, kann durch den Kunden eine Ände- +rung erreicht werden, indem er die terminierte SEPA- +Firmeneinzellastschrift löscht und anschließend neu einreicht. + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +### a) Kundenauftrag + + +#### . Beschreibung + +Die Felder sind so zu belegen, wie die terminierte SEPA-Firmeneinzellastschrift +nach der Änderung ausgeführt werden soll, d.h. es sind nicht nur die zu ändernden +Felder zu belegen. Die gleichzeitige Änderung mehrerer Felder ist möglich. Um die +Referenzierung auf den Ursprungsauftrag zu ermöglichen, ist in das Element ,,Auf- +tragsidentifikation" das vom Kreditinstitut mitgeteilte Identifikationsmerkmal einzu- +stellen. + +I + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle
SEPA-Zahlungsverkehr		Stand: 07.08.2015Seite: 439
+ + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Terminierte SEPA-Firmeneinzellastschrift ändern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKBSA
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3SEPA Descriptor1DEan.256M1
4SEPA pain messa- ge1DEbin..M1
5Auftragsidentifikati- on1DEan.99M1
+ + +### . Belegungsrichtlinien + +Kontoverbindung international + +IBAN und BIC müssen der IBAN in CreditorAccount bzw. der +BIC in CreditorAgent entsprechen. + + +#### SEPA pain message + +Erlaubtes ,,SEPA Lastschrift Kunde-Bank"-Schema It. HISPAS. + + +#### b) Kreditinstitutsrückmeldung + + +##### . Beschreibung + + +![](figures/159.1) + + +Falls eine neue Auftragsidentifikation vergeben wurde, ist der loka- +le Bestand im Kundenprodukt zu aktualisieren. + + +##### . Format + +Name: + +Änderung terminierter SEPA-Firmeneinzellastschrift bestäti- +gen + +Typ: + +Segment + +Segmentart: + +Geschäftsvorfall + +Kennung: + +HIBSA + +Bezugssegment: + +HKBSA + +Version: + +1 + +Anzahl: + +1 + +Sender: + +Kreditinstitut + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 440Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Auftragsidentifika- tion1DEan.99M1
3Auftragsidentifika- tion alt1DEan.99O1
+ + +##### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
0020Auftrag ausgeführt
9010Auftrag zur Zeit nicht änderbar
9010Auftrag bereits zur Löschung vorgemerkt
9010Auftrag inkonsistent
9160Auftragsidentifikation fehlt
9210Datum liegt zu weit in der Zukunft
9210Datum liegt nicht in der Zukunft
9210Auftrag existiert nicht, Auftragsidentifikation unbekannt
9210IBAN des Auftraggebers darf nicht geändert werden
9210Das angegebene Datum ist kein Ausführungsdatum
+ + +##### c) Bankparameterdaten + + +###### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Terminierte SEPA-Firmeneinzellastschrift ändern Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIBSAS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter termi- nierte SEPA- Firmeneinzellast- schrift ändern1DEGM1
+ + +## C.10.2.6.2.4 Bestand terminierter SEPA-Firmeneinzellastschriften abrufen (Segment- version 1) + +Der Kunde ruft die im Kreditinstitut zu einem Konto hinterlegten terminierten Aufträ- +ge ab, die noch zur Ausführung anstehen. Für jeden terminierten SEPA- +Firmeneinzellastschriftsauftrag wird ein entsprechendes Datensegment in die +Rückmeldungsnachricht eingestellt. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle
SEPA-Zahlungsverkehr		Stand: 07.08.2015Seite: 441
+ + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +### a) Kundenauftrag + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Bestand terminierter SEPA-Firmeneinzellastschriften anfor- dern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKBBS
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3Unterstützte SEPA pain messages1DEGM1
4Von Datum1DEdat#C1O: „Zeitraum möglich“ (BPD) „J“ N: sonst
5Bis Datum1DEdat#C1O: „Zeitraum möglich“ (BPD) „J“ N: sonst
6Maximale Anzahl Einträge1DEnum.4C1>0
O: ,,Eingabe Anzahl Ein- träge erlaubt“ (BPD) = „J“ N: sonst
7Aufsetzpunkt1DEan.35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +### b) Kreditinstitutsrückmeldung + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Bestand terminierter SEPA-Firmeneinzellastschriften rückmel- den
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIBBS
Bezugssegment:HKBBS
Version:1
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 442Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3SEPA Descriptor1DEan.256M1
4SEPA pain messa- ge1DEbin..M1
5Auftragsidentifikati- on1DEan.99C1M: vom Institut wurde Auf- tragsidentifikation erteilt N: sonst
6Auftrag löschbar1DEjn#O1
7Auftrag änderbar1DEjn#O1
+ + +#### . Belegungsrichtlinien + +SEPA pain message + +,SEPA Lastschrift Kunde-Bank"-Schema It. HISPAS. + + +#### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
3010Es liegen keine Einträge vor
9210Bereichende darf nicht vor Bereichanfang liegen
9210Datum liegt nicht in der Zukunft
9210Keine gültige IBAN des Kunden
+ + +#### c) Bankparameterdaten + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Bestand terminierter SEPA-Firmeneinzellastschriften Parame- ter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIBBSS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 443
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Bestand terminierter SEPA- Firmeneinzellast- schriften1DEGM1
+ + +## C.10.2.6.2.5 Bestand terminierter SEPA-Firmeneinzellastschriften abrufen (Segment- version 22) + +Der Kunde ruft die im Kreditinstitut zu einem Konto hinterlegten terminierten Aufträ- +ge ab, die noch zur Ausführung anstehen. Für jeden terminierten SEPA- +Firmeneinzellastschriftsauftrag wird ein entsprechendes Datensegment in die +Rückmeldungsnachricht eingestellt. + + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +### a) Kundenauftrag + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Bestand terminierter SEPA-Firmeneinzellastschriften
dern		anfor-
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKBBS
Bezugssegment:-
Version:22
Sender:Kunde
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 444Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3Unterstützte SEPA pain messages1DEGM1
4Von Datum1DEdat#C1O: „Zeitraum möglich“ (BPD) „J“ N: sonst
5Bis Datum1DEdat#C1O: „Zeitraum möglich“ (BPD) „J“ N: sonst
6Maximale Anzahl Einträge1DEnum..4C1>0
O: ,,Eingabe Anzahl Ein- träge erlaubt“ (BPD) = „J“ N: sonst
7Aufsetzpunkt1DEan..35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +### b) Kreditinstitutsrückmeldung + +. Format + +Name: + +Bestand terminierter SEPA-Firmeneinzellastschriften rückmel- +den + +Typ: + +Segment + +Segmentart: + +Geschäftsvorfall + +Kennung: + +HIBBS + +Bezugssegment: + +HKBBS + +Version: + +22 + +Anzahl: + +n + +Sender: + +Kreditinstitut + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 445
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3SEPA Descriptor1DEan.256M1
4SEPA pain messa- ge1DEbin..M1
5Auftragsidentifikati- on1DEan.99C1M: vom Institut wurde Auf- tragsidentifikation erteilt N: sonst
6SEPA-C- CodeSEPA C Code14DED Ecode- de- code141, 2, 31, 2, 3
7Auftrag änderbar1DEjn#O1
8Status SEPA- AuftragStatus SEPA-Auftrag14DED Ecode- de- code141, 2, 3, 4, 51, 2, 3, 4, 5
+ + +#### . Belegungsrichtlinien + +SEPA pain message + +,SEPA Lastschrift Kunde-Bank"-Schema It. HIBBSS bzw. HIBBSS bzw. HISPAS. + +◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
3010Es liegen keine Einträge vor
9210Bereichende darf nicht vor Bereichanfang liegen
9210Datum liegt nicht in der Zukunft
9210Keine gültige IBAN des Kunden
+ + +#### c) Bankparameterdaten + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Bestand terminierter SEPA-Firmeneinzellastschriften Parame- ter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIBBSS
Bezugssegment:HKVVB
Version:22
Sender:Kreditinstitut
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 446Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Bestand terminierter SEPA- Firmeneinzellast- schriften22DEGM1
+ + +## C.10.2.6.2.6 Löschung terminierter SEPA-Firmeneinzellastschrift + +Die zu löschende SEPA-Firmeneinzellastschrift wird über eine Auftragsidentifikation, +die beim Abruf des Bestandes mitübertragen wird, bestimmt. Neben der Auftragsi- +dentifikation müssen auch die restlichen Auftragsdaten eingestellt werden, wenn +dies kreditinstitutsseitig in den BPD gefordert ist. Diese dienen dann z.B. zu Plausi- +bilitätsprüfungen. + + +![](figures/166.1) + + +Dieser Geschäftsvorfall darf vom Kreditinstitut nur angeboten wer- +den, wenn es eine Auftragsidentifikation unterstützt, da ansonsten +die Identifikation der zu löschenden SEPA-Firmeneinzellastschrift +nicht möglich ist. + +Zu löschende terminierte Aufträge liegen immer in der Zukunft. Eine minimale Vor- +laufzeit für die Einreichung des Löschauftrags ist nicht vorgesehen. Es können je- +doch nur Aufträge gelöscht werden, die auch im Bestand aufgeführt werden. + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +### a) Kundenauftrag + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Terminierte SEPA-Firmeneinzellastschrift löschen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKBSL
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 447
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3SEPA Descriptor1DEan.256C1M: ,"Senden der Auftrags- daten erforderlich" (BPD) „J“ O: sonst
4SEPA pain messa- ge1DEbin..C1M: ,"Senden der Auftrags- daten erforderlich" (BPD) „J“ O: sonst
5Auftragsidentifikati- on1DEan.99M1
+ + +### . Belegungsrichtlinien + + +#### Kontoverbindung international + +IBAN und BIC müssen der IBAN in CreditorAccount bzw. der +BIC in CreditorAgent entsprechen. + + +#### SEPA pain message + +Erlaubtes ,,SEPA Lastschrift Kunde-Bank"-Schema It. HISPAS. + + +![](figures/167.1) + + +Muss die SEPA pain message in der Kundennachricht eingestellt +werden, so muss zwingend das gleiche pain message-Schema +verwendet werden, welches zuvor in der Bestandsabfrage durch +das Kreditinstitut geliefert wurde. + + +### b) Kreditinstitutsrückmeldung + + +#### . Beschreibung + +Es werden keine Datensegmente zurückgemeldet. + +◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag zur Löschung vorgemerkt
0020Auftrag gelöscht
9010Löschung nicht mehr möglich, da Auftrag bereits zur Löschung vorgemerkt
9010Auftragsidentifikation stimmt nicht mit Auftragsdaten überein
9210Auftrag existiert nicht bzw. wurde bereits ausgeführt
+ + +#### c) Bankparameterdaten + + +##### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Terminierte SEPA-Firmeneinzellastschrift löschen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIBSLS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
448		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Lö- schung terminierter SEPA- Firmeneinzellast- schriften1DEGM1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 449
+ + +## C.10.2.7 SEPA-Dauereinzellastschrift + +Folgende Geschäftsvorfälle sind vorgesehen: + +· Einrichtung einer SEPA-Dauereinzellastschrift + +· Ändern einer SEPA-Dauereinzellastschrift + +· SEPA-Dauereinzellastschriftaussetzung (gegebenenfalls mit vorübergehend ge- +ändertem Betrag) + +· SEPA-Dauereinzellastschriftbestandsabfrage + +. Abruf von SEPA-Dauereinzellastschriftänderungsvormerkungen + +· SEPA-Dauereinzellastschriftlöschung + + +Die Abbildung zeigt die Abfolge der Geschäftsvorfälle im Dauerlastschriftbereich: + +![SEPA-Dauerlastschrift einrichten SEPA-Dauerlastschrifteinrichtung bestätigen SEPA-Dauerlastschriftbestand anfordern K SEPA-Dauerlastschriftbestand rückmelden r e i t i SEPA-Dauerlastschrift ändern SEPA-Dauerlastschriftänderung bestätigen d K u n SEPA-Dauerlastschrift aussetzen d e n SEPA-Dauerlastschriftaussetzung bestätigen s t i SEPA-DL-änderungsvormerkungen anfordern t SEPA-DL-änderungsvormerkungen rückmelden u t SEPA - Dauereinzellastschrift löschen (kein Datensegment)](figures/169.1) + + +Abbildung 8: Lebenszyklus SEPA-Dauerlastschrift + +Die umfangreiche Komplexität sämtlicher Dauereinzellastschriftmodalitäten kann im +Rahmen dieser Schnittstelle nicht abgebildet werden. Derartige Verarbeitungsvor- +gänge können stattdessen evtl. durch die Steuerung des Kundenprodukts abgewi- +ckelt werden. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
450		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + +![](figures/170.1) + + +Von den hier dargestellten Aufträgen zu unterscheiden sind vom +Kundenprodukt verwaltete SEPA-Dauereinzellastschriften, d.h. Ein- +zelaufträge, bei denen das Kundensystem die Terminverwaltung +und regelmäßige Versendung übernimmt. Diese können für den +Kunden insbesondere dann eine Alternative darstellen, falls entwe- +der das Kundenprodukt oder das Kreditinstitut keine Dauereinzel- +lastschriftverwaltung anbietet. + + +![](figures/170.2) + + +Die Geschäftsvorfälle +„SEPA-Dauereinzellastschriftänderung“, +„SEPA-Dauereinzellastschriftaussetzung“ und „SEPA- +Dauereinzellastschriftänderungsvormerkungen abrufen“ dürfen vom +Kreditinstitut nur angeboten werden, wenn es eine Auftragsidentifi- +kation unterstützt, da ansonsten die Identifikation der zu ändernden +SEPA-Dauereinzellastschrift nicht möglich ist. + + +![](figures/170.3) + + +Vor der Modifikation einer SEPA-Dauereinzellastschrift (Änderung, +Aussetzung) hat eine Abholung des aktuellen Bestandes bzw. der +Änderungsvormerkungen beim Kreditinstitut (s.u.) zu erfolgen, um +sicherzustellen, dass der Kunde auf Basis des korrekten Bestandes +operiert. Nur so ist gewährleistet, dass zwischenzeitliche Ände- +rungen auf anderem Wege (z.B. schriftlich oder per Selbstbedie- +nungsterminal) von der Kundensoftware berücksichtigt werden. + +Das Datenformat für SEPA-Dauereinzellastschrift entspricht dem Format für SEPA- +Einzelaufträge. Es wird ergänzt um dauereinzellastschriftspezifische Informationen. + + +## C.10.2.7.1 SEPA-Dauereinzellastschrifteinrichtung + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +### a) Kundenauftrag + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:SEPA-Dauereinzellastschrift einrichten
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKDDE
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 451
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3SEPA Descriptor1DEan.256M1
4SEPA pain messa- ge1DEbin..M1
5SEPA- Dauereinzellast- schriftdetails1DEGM1
+ + +### . Belegungsrichtlinien + + +#### Kontoverbindung international + +IBAN und BIC müssen der IBAN in CreditorAccount bzw. der +BIC in CreditorAgent entsprechen. + + +#### SEPA pain message + +Erlaubtes ,,SEPA Lastschrift Kunde-Bank"-Schema It. HISPAS. + + +#### b) Kreditinstitutsrückmeldung + + +##### . Beschreibung + + +![](figures/171.1) + + +Falls das Kreditinstitut schon bei der Einreichung eine Auf- +tragsidentifikation zurückmelden kann, sollte diese Möglichkeit ge- +nutzt werden. Andernfalls hat das Kundensystem vor einer Ände- +rung oder Löschung den gesamten Bestand abzurufen (s. C.xxx +„SEPA-Dauereinzellastschriftbestand abrufen"), um in den Besitz +der Auftragsidentifikation zu gelangen. + + +##### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:SEPA-Dauereinzellastschrifteinrichtung bestätigen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIDDE
Bezugssegment:HKDDE
Version:1
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Auftragsidentifikati- on1DEan.99O1
+ + +##### ◆ Ausgewählte Beispiele für Rückmeldungscodes + +Es sind sämtliche Rückmeldungscodes des Geschäftsvorfalls ,,Einreichung ter- +minierter SEPA-Einzellastschrift“ möglich. Zusätzlich gelten: + +Code Beispiel für Rückmeldungstext + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
452		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
9210Der angegebene Turnus ist kein Ausführungsturnus
+ + +##### c) Bankparameterdaten + + +###### . Beschreibung + +Das Kreditinstitut gibt die monatlich bzw. wöchentlich erlaubten Ausführungs- +rythmen an. In den Datenelementen 4 bis 6 sind die unterstützten Werte in aufstei- +gender Reihenfolge als Kette 2-stelliger Zahlen einzustellen. Die DE-Länge von 62 +würde somit die Eingabe aller Tage eines Monats erlauben. + + +###### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:SEPA-Dauereinzellastschrift einrichten Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIDDES
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter SEPA- Dauereinzellast- schrift einrichten1DEGM1
+ + +# C.10.2.7.2 SEPA-Dauereinzellastschriftänderung + +Das Kreditinstitut teilt in den BPD mit, welche Felder durch den Kunden änderbar +sind. Die Auftragsidentifikation und die Auftraggeberkontoverbindung sind grund- +sätzlich nicht änderbar. + +Änderungen gelten, sofern nichts anderes bestimmt ist, zum nächsten Ausführungs- +termin. Darüber hinaus kann das Kreditinstitut in den BPD festsetzen, ob es zusätz- +lich terminierte Änderungen erlaubt. In diesem Fall ist weiterhin möglich, dass das +Kreditinstitut nur eine oder mehrere terminierte Änderungen gleichzeitig zulässt. + + +![](figures/172.1) + + +Falls dieser Geschäftsvorfall kreditinstitutsseitig oder vom Kunden- +produkt nicht angeboten wird, kann durch den Kunden eine Ände- +rung erreicht werden, indem er die SEPA-Dauereinzellastschrift +löscht und anschließend neu einreicht. Dasselbe gilt für den Fall, +dass die Änderung eines nicht änderbaren Feldes erforderlich ist. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 453
+ + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +## a) Kundenauftrag + + +### . Beschreibung + +Bei jeder Änderung ist eine vollständige neue SEPA pain message einzureichen. + +Liegen bereits terminierte Änderungen im Falle einer nicht terminierten Änderung +vor, so ist der Kunde darauf hinzuweisen. Im Zweifel ist die Anzahl der terminierten +Änderungen auf maximal eine Änderung einzuschränken. Anhand der mitgelieferten +anderen Daten der vollständigen pain message können kreditinstitutsseitig Plausibi- +litätsprüfungen durchgeführt werden. Dies ist erforderlich, um Fehldeutungen des +Kundenwunsches zu vermeiden. + + +#### Beispiel: + +Der Kunde richtet am 1.1. eine SEPA-Dauereinzellastschrift über 100 Euro zulasten +des Kontos 12345 ein. Am 1.2. sendet er einen terminierten Änderungsauftrag, da +er weiß, dass sich der Lastschriftbetrag am 1.7. auf 110 Euro ändern wird. Am 1.3. +erhält er die Information, dass sich die Empfänger-Kontonummer auf 12346 geän- +dert hat und ändert dementsprechend die Dauereinzellastschrift sofort. Sofern der +Kunde in seinem ersten Änderungsauftrag sämtliche Auftragsdaten sendet, wird am +1.7. die Kontonummer wieder auf die alte Nummer 12345 zurückgesetzt, d.h. der +Kundenwunsch wird falsch interpretiert. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:SEPA-Dauereinzellastschrift ändern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKDDN
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 454Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt:
SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3SEPA Descriptor1DEan.256M1
4SEPA pain messa- ge1DEbin..M1
5AusführungsdatumDEdat#C1O: „Anzahl term. Änderun- gen" (BPD) >=1 N: sonst
6Auftragsidentifikati- on1DEan.99C1M: Auftragsidentifikation wurde vom Institut erteilt N: sonst
7SEPA- Dauereinzellast- schriftdetails1DEGC1M: „Anzahl term. Änderun- gen" (BPD) <=1 ODER „Anzahl term. Änderungen“ (BPD) >1 und SEPA- Dauereinzellastschriftdetails nicht änderbar ODER „An- zahl term. Änderungen“ (BPD) >1 und SEPA- Dauereinzelastschriftdetails änderbar und SEPA- Dauereinzelastschriftdetails sollen geändert werden N: sonst
+ + +### . Belegungsrichtlinien + + +#### Kontoverbindung international + +IBAN und BIC müssen der IBAN in CreditorAccount bzw. der +BIC in CreditorAgent entsprechen. + + +#### SEPA pain message + +Erlaubtes ,,SEPA Lastschrift Kunde-Bank"-Schema It. HISPAS. + + +![](figures/174.1) + + +In der Kundennachricht muss zwingend das gleiche pain messa- +ge-Schema verwendet werden, welches zuvor in der Bestandsab- +frage durch das Kreditinstitut geliefert wurde. + + +## b) Kreditinstitutsrückmeldung + +. Beschreibung + + +![](figures/174.2) + + +Falls eine neue Auftragsidentifikation vergeben wurde, ist der loka- +le Bestand im Kundenprodukt zu aktualisieren. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 455
+ + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:SEPA-Dauereinzellastschriftänderung bestätigen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIDDN
Bezugssegment:HKDDN
Version:1
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Auftragsidentifikati- on1DEan.99M1
3Auftragsidentifikati- on alt1DEan..99O1
+ + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
0020SEPA-Dauereinzellastschrift geändert
9010SEPA-Dauereinzellastschrift zur Zeit nicht änderbar
9010Änderung bei diesem Dauereinzellastschrifttyp nicht möglich
9010SEPA-Dauereinzellastschrift bereits zur Löschung vorgemerkt
9010Auftrag inkonsistent
9160Auftragsidentifikation fehlt
9210Aussetzungszeitraum zu groß
9210Datum liegt zu weit in der Zukunft
9210Datum liegt nicht in der Zukunft
9210SEPA-Dauereinzellastschrift existiert nicht, Auftragsidentifikation unbekannt
9210IBAN des Auftraggebers darf nicht geändert werden
+ + +## c) Bankparameterdaten + + +### . Beschreibung + +Es ist zu beachten, dass sich die Parameter von denen der SEPA- +Dauereinzellastschrifteinrichtung unterscheiden können. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:SEPA-Dauereinzellastschrift ändern Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIDDNS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 456Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter SEPA- Dauereinzellast- schrift ändern1DEGM1
+ + +# C.10.2.7.3 SEPA-Dauereinzellastschriftaussetzung + +Aussetzungen gelten, sofern nichts anderes bestimmt ist, zum nächsten Ausfüh- +rungstermin. Darüber hinaus kann das Kreditinstitut in der BPD festsetzen, ob es +zusätzlich terminierte Aussetzungen erlaubt. + + +![](figures/176.1) + + +Ein Widerruf einer einmal eingereichten Aussetzung ist im Regelfall +nicht möglich. + +Falls keine weiteren terminierten Änderungen oder Aussetzungen +vorliegen, kann der Kunde eine bereits gemeldete Aussetzung jedoch +widerrufen, indem das Kundenprodukt eine weitere Aussetzung für +denselben Zeitraum sendet, bei der der ,Abweichende Betrag" mit +dem Originalbetrag belegt ist. + + +![](figures/176.2) + + +Falls dieser Geschäftsvorfall vom Kreditinstitut oder vom Kunden- +produkt nicht angeboten wird, kann eine Aussetzung auch durch Lö- +schung und terminierte Neueinreichung erreicht werden. + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +## a) Kundenauftrag + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:SEPA-Dauereinzellastschrift aussetzen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKDDU
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 457
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3SEPA Descriptor1DEan.256M1
4SEPA pain messa- ge1DEbin..M1
5Ausführungsdatum1DEdat#C1O: ,,Anzahl term. Ausset- zungen" (BPD) >=1 N: sonst
6Auftragsidentifikati- on1DEan..99C1M: Auftragsidentifikation wurde vom Institut erteilt N: sonst
7SEPA- Dauereinzellast- schriftdetails1DEGM1
8Aussetzung3DEGM1
+ + +## . Belegungsrichtlinien + + +### Kontoverbindung international + +IBAN und BIC müssen der IBAN in CreditorAccount bzw. der +BIC in CreditorAgent entsprechen. + + +### SEPA pain message + +Erlaubtes ,,SEPA Lastschrift Kunde-Bank"-Schema It. HISPAS. + + +![](figures/177.1) + + +In der Kundennachricht muss zwingend das gleiche pain messa- +ge-Schema verwendet werden, welches zuvor in der Bestandsab- +frage durch das Kreditinstitut geliefert wurde. + + +#### b) Kreditinstitutsrückmeldung + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:SEPA-Dauereinzellastschriftaussetzung bestätigen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIDDU
Bezugssegment:HKDDU
Version:1
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
458		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Auftragsidentifikati- on1DEan.99M1
3Auftragsidentifikati- on alt1DEan..99O1
+ + +◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
0020SEPA-Dauereinzellastschrift ausgesetzt
9010SEPA-Dauereinzellastschrift zur Zeit nicht änderbar
9010Auftrag bereits zur Löschung vorgemerkt
9160Auftragsidentifikation fehlt
9210Aussetzungszeitraum zu groß
9210Datum liegt zu weit in der Zukunft
9210Datum liegt nicht in der Zukunft
9210Auftrag existiert nicht, Auftragsidentifikation unbekannt
9210IBAN des Auftraggebers darf nicht geändert werden
+ + +## c) Bankparameterdaten + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:SEPA-Dauereinzellastschrift aussetzen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIDDUS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter SEPA- Dauereinzellast- schrift aussetzen1DEGM1
+ + +# C.10.2.7.4 SEPA-Dauereinzellastschriftbestand abrufen + +Für jede SEPA-Dauereinzellastschrift wird ein Segment "SEPA- +Dauereinzellastschrift" als Datensegment in der Rückmeldungsnachricht übermittelt. +Die SEPA-Dauereinzellastschrift wird so angezeigt, wie sie zum nächsten Termin +ausgeführt würde. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Geschäftsvorfälle		Stand: 07.08.2015Seite: 459
+ + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +## a) Kundenauftrag + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:SEPA-Dauereinzellastschriftbestand anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKDDB
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3Unterstützte SEPA pain messages1DEGM1
4Auftragsidentifikati- on1DEan..99O1
5Maximale Anzahl EinträgeDEnum..4C1>0
O: ,,Eingabe Anzahl Ein- träge erlaubt“ (BPD) = „J“ N: sonst
6AufsetzpunktDEan.35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +#### Belegungsrichtlinien + + +##### Auftragsidentifikation + +Wird das DE ,,Auftragsidentifikation" belegt, wird die entsprechende SEPA- +Dauereinzellastschrift angezeigt. Wird dieses Feld leer gelassen, kommen alle +SEPA-Dauereinzellastschriften des Kontos zur Anzeige. + + +### b) Kreditinstitutsrückmeldung + + +### . Beschreibung + +Für jede SEPA-Dauereinzellastschrift wird ein Segment zurückgemeldet. + + +![](figures/179.1) + + +Falls der Rückmeldecode 3041 gesendet wird, muss direkt im An- +schluss ein Bestandsabruf des korrespondierenden Nicht-SEPA- +Bestandes durchgeführt werden. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 460Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:SEPA-Dauereinzellastschriftbestand rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIDDB
Bezugssegment:HKDDB
Version:1
Sender:Kreditinstitut
Anzahl:n
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3SEPA Descriptor1DEan.256M1
4SEPA pain messa- ge1DEbin٠٠M1
5Auftragsidentifikati- on1DEan.99O1
6SEPA- Dauereinzellast- schriftdetails1DEGM1
7Aussetzung3DEGO1
+ + +### . Belegungsrichtlinien + + +#### Kontoverbindung international + +IBAN und BIC müssen der IBAN in CreditorAccount bzw. der +BIC in CreditorAgent entsprechen. + + +#### SEPA pain message + +Erlaubtes ,,SEPA Lastschrift Kunde-Bank"-Schema It. HISPAS. + + +#### Auftragsidentifikation + + +![](figures/180.1) + + +Soll eine SEPA-Dauereinzellastschrift lediglich anhand einer Auf- +tragsidentifikation gelöscht werden können, so muss das Kreditinsti- +tut dem Kundenprodukt eine Auftragsidentifikation mitteilen. + + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
3010Es liegen keine Einträge vor
3041ein weiterer Bestand liegt vor ,,Dauereinzellastschriftbestand abrufen“
3042kein weiterer Bestand liegt vor ,,Dauereinzellastschriftbestand abrufen“
3043keine Informationen über weitere Bestände „Dauereinzellastschriftbestand abrufen"
9210Bereichende darf nicht vor Bereichanfang liegen
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle
SEPA-Zahlungsverkehr		Stand: 07.08.2015Seite: 461
+ + +## c) Bankparameterdaten + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:SEPA-Dauereinzellastschriftbestand Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIDDBS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter SEPA- Dauereinzellast- schriftbestand1DEGM1
+ + +#### C.10.2.7.5 SEPA-Dauereinzellastschriftänderungsvormerkungen abrufen + + + + + + + + + + + + + +
RealisierungBank:optional
RealisierungKunde:optional
+ + +### a) Kundenauftrag + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:SEPA-Dauereinzellastschriftänderungsvormerkungen
dern		anfor-
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKDDA
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
462		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3Unterstützte SEPA pain messages1DEGM1
4Auftragsidentifikati- on1DEan..99M1
5Maximale Anzahl Einträge1DEnum..4C1>0
O: ,,Eingabe Anzahl Ein- träge erlaubt“ (BPD) = „J“ N: sonst
6Aufsetzpunkt1DEan.35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +## b) Kreditinstitutsrückmeldung + + +### . Beschreibung + +Für die ausgewählte SEPA-Dauereinzellastschrift wird je noch nicht ausgeführtem +Änderungs- bzw. Aussetzungsauftrag ein Segment "SEPA-Dauereinzellastschrift" +übermittelt. Das erste Datensegment enthält den Stand, der zum nächsten Ausfüh- +rungstermin gültig ist. Liegen keine terminierten Änderungen bzw. Aussetzungen für +diese SEPA-Dauereinzellastschrift vor, werden keine weiteren Segmente gesendet. + + +![](figures/182.1) + + +Es bleibt dem Kreditinstitut überlassen, ob es Änderungs-/Ausset- +zungsaufträge oder Änderungs-/Aussetzungstermine1 zurückmeldet. +D.h. zu einem Termin können u.U. mehrere Aufträge zurückgemel- +det werden, von denen aber nur jeweils der letzte ausgeführt wird. + +Für die ausgewählte SEPA-Dauereinzellastschrift wird je noch nicht ausgeführtem +Änderungs- bzw. Aussetzungsauftrag ein Datensegment übermittelt, wobei das ers- +te Datensegment diejenige Vormerkung beinhaltet, die der nächste Ausführungs- +termin aufweist. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:SEPA-Dauereinzelastschriftänderungsvormerkungen meldenrück-
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIDDA
Bezugssegment:HKDDA
Version:1
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + +
Nr.NameVer-TypFor-Län-Sta-An-Restriktionen
+ + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 463
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
sionmatgetuszahl
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3SEPA Descriptor1DEan.256M1
4SEPA pain messa- ge1DEbin..M1
5Auftragsidentifikati- on1DEan..99O1
6SEPA- Dauereinzellast- schriftdetails1DEGM1
7Aussetzung3DEGO1
+ + +### Belegungsrichtlinien + + +#### Kontoverbindung international + +IBAN und BIC müssen der IBAN in CreditorAccount bzw. der +BIC in CreditorAgent entsprechen. + + +#### SEPA pain message + +Erlaubtes ,,SEPA Lastschrift Kunde-Bank"-Schema It. HISPAS. + + +#### Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
9160Auftragsidentifikation fehlt
9210Auftrag existiert nicht, Auftragsidentifikation unbekannt
+ + +### c) Bankparameterdaten + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:SEPA-Dauereinzellastschriftänderungsvormerkungen meterPara-
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIDDAS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 464Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter SEPA- Dauereinzellast- schriftänderungs- vormerkungen1DEGM1
+ + +# C.10.2.7.6 SEPA-Dauereinzellastschriftlöschung + +Löschungen gelten, sofern nichts anderes bestimmt ist, ab sofort. Darüber hinaus +kann das Kreditinstitut in der BPD festlegen, ob es zusätzlich terminierte Löschun- +gen erlaubt. Die Eingabe einer terminierten Löschung überschreibt einen evtl. vor- +her eingegebenen terminierten Löschauftrag. + + +![](figures/184.1) + + +Im Gegensatz zur SEPA-Dauereinzellastschriftänderung +und -aussetzung ist eine Löschung auch möglich, wenn das Kredit- +institut keine Auftragsidentifikation für die SEPA- +Dauereinzellastschrift vergibt und im Löschauftrag die gültigen Da- +ten des Auftrags mitgeteilt werden, die dem Kreditinstitut eine ein- +deutige Identifizierung des Auftrags ermöglichen. Dürfen jedoch die +Auftragsdaten laut Bankparameterdaten nicht gesendet werden, so +muss zwingend eine Auftragsidentifikation unterstützt werden, da +ansonsten die Identifikation der zu löschenden SEPA- +Dauereinzellastschrift nicht möglich ist. + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +## a) Kundenauftrag + + +### . Beschreibung + +Es sind die gültigen Daten der SEPA-Dauereinzellastschrift einzustellen. Diese die- +nen zu Plausibilitätsprüfungen. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:SEPA-Dauereinzellastschrift löschen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKDDL
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 465
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3SEPA Descriptor1DEan.256C1M: ,"Senden der Auftrags- daten erforderlich" (BPD) „J“ O: sonst
4SEPA pain messa- ge1DEbin..C1M: ,"Senden der Auftrags- daten erforderlich" (BPD) „J“ O: sonst
5AusführungsdatumDEdat#C1O: DE „Löschung terminier- bar" (BPD) = ,J" N: sonst
6Auftragsidentifikati- on1DEan..99C1M: Auftragsidentifikation wurde vom Institut erteilt N: sonst
7SEPA- Dauereinzellast- schriftdetails1DEGM1
+ + +## . Belegungsrichtlinien + + +### Kontoverbindung international + +IBAN und BIC müssen der IBAN in CreditorAccount bzw. der +BIC in CreditorAgent entsprechen. + + +### SEPA pain message + +Erlaubtes ,,SEPA Lastschrift Kunde-Bank"-Schema It. HISPAS. + + +![](figures/185.1) + + +Muss die SEPA pain message in der Kundennachricht eingestellt +werden, so muss zwingend das gleiche pain message-Schema +verwendet werden, welches zuvor in der Bestandsabfrage durch +das Kreditinstitut geliefert wurde. + + +### Ausführungsdatum + +Falls terminierte Löschungen erlaubt sind (s. DE ,Löschung terminierbar" in den +Bankparameterdaten), ist hier ist das Löschdatum einzustellen. Es muss sich dabei +um ein Datum handeln, zu dem eine Ausführung stattfinden würde. Die SEPA- +Dauereinzellastschrift wird an dem angegebenen Datum nicht mehr ausgeführt. Ist +das DE nicht eingestellt, so wird die Löschung sofort wirksam. + + +### b) Kreditinstitutsrückmeldung + + +#### . Beschreibung + +Es werden keine Datensegmente zurückgemeldet. + +◆ Ausgewählte Beispiele für Rückmeldungscodes + +Code Beispiel für Rückmeldungstext + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 466Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
0010SEPA-Dauereinzellastschrift zur Löschung vorgemerkt
0020SEPA-Dauereinzellastschrift gelöscht
9010SEPA-Dauereinzellastschrift bereits zur Löschung vorgemerkt
9160Auftragsidentifikation fehlt
9210Datum liegt zu weit in der Zukunft
9210Datum liegt nicht in der Zukunft
9210Auftrag existiert nicht, Auftragsidentifikation unbekannt
9210Das angegebene Datum ist kein Ausführungsdatum
+ + +## c) Bankparameterdaten + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:SEPA-Dauereinzellastschrift löschen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIDDLS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter SEPA- Dauereinzellast- schrift löschen1DEGM1
+ + +# C.10.2.8 Sonderformen von SEPA-Einzelaufträgen + + +## C.10.2.8.1 Eilzahlung (Urgent Payment) + +Realisierung Bank: +optional + +Realisierung Kunde: optional + + +### a) Kundenauftrag + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Eilzahlung einreichen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKCSU
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 467
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3SEPA Descriptor1DEan.256M1
4SEPA pain messa- ge1DEbin..M1
+ + +### . Belegungsrichtlinien + + +#### Kontoverbindung international + +IBAN und BIC müssen der IBAN in DebtorAccount bzw. der +BIC in DebtorAgent entsprechen. + + +#### SEPA pain message + +Erlaubtes „SEPA Überweisung Kunde-Bank"-Schema It. HISPAS. + +Es gelten die Festlegungen zu Eilzahlungen unter Verwendung des pain.001- +Formats laut Anlage 3 des DFÜ-Abkommens. [DFÜ-Abkommen]. + +In das Mussfeld RequestedExecutionDate ist der 1999-01-01 ein- +zustellen. + + +![](figures/187.1) + + +Für nicht terminierte Aufträge darf dem Kunden kein Eingabefeld zur +Eingabe eines Termins angeboten werden. + + +![](figures/187.2) + + +Enthält das Feld RequestedExecutionDate bei nicht +terminierten Aufträgen einen anderen Wert als ,,1999-01-01" so ist +der Auftrag mit der Rückmeldung „9150 - Ausführungsdatum darf +nicht belegt werden“ abzulehnen. + + +![](figures/187.3) + + +Wird die SEPA-pain-message aus einer fremden Quelle importiert, +so ist darauf zu achten, dass ein eventuell abweichendes Datum im +Feld RequestedExecutionDate auf den Wert „1999- +01-01“ geändert wird. + + +### b) Kreditinstitutsrückmeldung + + +#### . Beschreibung + +Es werden keine Datensegmente zurückgemeldet. + + +#### ◆ Ausgewählte Beispiele für Rückmeldungscodes + +Der Code 3070 kann verwendet werden, um dem Kunden eine Bearbeitungs- +referenznummer z.B. für Reklamationsfälle mitzuteilen. Die Referenznummer wird +dabei als Parameter des Rückmeldungscodes angegeben (s. [Formals]). + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag zur Ausführung vorgemerkt
3020BIC veraltet. Die neue BIC lautet
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
468		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
3070Auftrag wird unter Referenz xxx verarbeitet
9150Ausführungsdatum darf nicht belegt werden
9150Identifikationsnr. darf nicht belegt werden
9210Betrag zu groß für Überweisung
9210Betrag muss größer als 0 sein
9210Empfänger-IBAN existiert nicht
9210Keine Berechtigung für dieses Konto
9210Falscher Textschlüssel
9210Keine gültige Kontoverbindung des Kunden
9210BIC existiert nicht
9230Unzureichendes Guthaben des Kontos
+ + +### c) Bankparameterdaten + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
. Format
Name:Eilzahlung Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HICSUS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Eilzah- lung1DEGM1
+ + +## C.10.2.8.2 SEPA-Übertrag + + +### C.10.2.8.2.1 Bestand der möglichen Empfängerkonten abrufen + +Dieser Geschäftsvorfall liefert den aktuellen Bestand der möglichen Empfängerkon- +ten, die zu einem bestimmten Kundenkonto beim Kreditinstitut hinterlegt sind. + +Realisierung Bank: optional; verpflichtend, wenn der Geschäftsvorfall „SEPA- +Übertrag“ angeboten wird. + +Realisierung Kunde: optional; verpflichtend, wenn der Geschäftsvorfall „SEPA- +Übertrag“ angeboten wird. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle
SEPA-Zahlungsverkehr		Stand: 07.08.2015Seite: 469
+ + +#### a) Kundenauftrag + + +##### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Bestand Empfängerkonten anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKCUB
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3Maximale Anzahl Einträge1DEnum..4C1>0
O: ,,Eingabe Anzahl Ein- träge erlaubt“ (BPD) = „J“ N: sonst
4Aufsetzpunkt1DEan..35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +#### b) Kreditinstitutsrückmeldung + + +##### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Empfängerkontenbestand rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HICUB
Bezugssegment:HKCUB
Version:1
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3Angaben zu Emp- fängerkonten1DEGMn
+ + +##### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
3010Es liegen keine Empfängerkonten vor
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
470		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
9210Keine gültige Kontoverbindung des Kunden
+ + +#### c) Bankparameterdaten + + +##### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Empfängerkontenbestand Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HICUBS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Emp- fängerkontenbe- stand anfordern1DEGM1
+ + +### C.10.2.8.2.2 SEPA-Überweisung auf ein Empfängerkonto + +Mit diesem Geschäftsvorfall können nur Überweisungen auf Konten getätigt werden, +die auch im Empfängerkontenbestand aufgeführt werden. + + +![](figures/190.1) + + +Vor der Überweisung auf ein Empfängerkonto hat eine Abholung des ak- +tuellen Bestandes zu erfolgen, um sicherzustellen, dass der Kunde nur +aktuell gültige Empfängerkonten verwendet. Nur so ist gewährleistet, dass +zwischenzeitliche Änderungen auf anderem Wege (z.B. schriftlich oder +per Selbstbedienungsterminal) auf Kundenseite berücksichtigt werden. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle
SEPA-Zahlungsverkehr		Stand: 07.08.2015Seite: 471
+ + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +# a) Kundenauftrag + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:SEPA-Überweisung auf ein Empfängerkonto
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKCUM
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3SEPA Descriptor1DEan.256M1
4SEPA pain messa- ge1DEbin..M1
+ + +# Belegungsrichtlinien + + +## Kontoverbindung international + +IBAN und BIC müssen der IBAN in DebtorAccount bzw. der +BIC in DebtorAgent entsprechen. + + +## SEPA pain message + +Es dürfen nur IBAN und BIC in der IBAN in CreditorAccount +bzw. der BIC in CreditorAgent eingestellt werden, die den Werten +für Empfängerkonten entsprechen, die mit dem Geschäftsvorfall ,,Bestand der Emp- +fängerkonten abrufen“ als Empfängerkonten zurückgeliefert wurden. + +In das Mussfeld RequestedExecutionDate ist der 1999-01-01 ein- +zustellen. + + +![](figures/191.1) + + +Für nicht terminierte Aufträge darf dem Kunden kein Eingabefeld zur +Eingabe eines Termins angeboten werden. + + +![](figures/191.2) + + +Enthält das Feld RequestedExecutionDate bei nicht +terminierten Aufträgen einen anderen Wert als ,,1999-01-01" so ist +der Auftrag mit der Rückmeldung „9150 - Ausführungsdatum darf +nicht belegt werden" abzulehnen. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
472		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + +![](figures/192.1) + + +Wird die SEPA-pain-message aus einer fremden Quelle importiert, +so ist darauf zu achten, dass ein eventuell abweichendes Datum im +Feld RequestedExecutionDate auf den Wert „1999- +01-01“ geändert wird. + + +# b) Kreditinstitutsrückmeldung + + +## . Beschreibung + +Es werden keine Datensegmente zurückgemeldet. + + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + +Der Code 3070 kann verwendet werden, um dem Kunden eine Bearbeitungs- +Empfängernummer z.B. für Reklamationsfälle mitzuteilen. Die Empfängernummer +wird dabei als Parameter des Rückmeldungscodes angegeben (s. [Formals]). + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag zur Ausführung vorgemerkt
3020BIC veraltet. Die neue BIC lautet
3070Auftrag wird unter Empfänger xxx verarbeitet
9150Ausführungsdatum darf nicht belegt werden
9150Identifikationsnr. darf nicht belegt werden
9210Betrag zu groß für Überweisung
9210Betrag muss größer als 0 sein
9210Empfänger-IBAN ist kein Empfängerkonto
9210Empfänger-IBAN existiert nicht
9210Keine Berechtigung für dieses Konto
9210Falscher Textschlüssel
9210Keine gültige Kontoverbindung des Kunden
9210BIC existiert nicht
9230Unzureichendes Guthaben des Kontos
+ + +## c) Bankparameterdaten + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:SEPA-Überweisung auf ein Empfängerkonto Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HICUMS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 473
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter SEPA- Überweisung auf ein Empfängerkon- to1DEGM1
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
474		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + +# C.10.3 SEPA-Sammelaufträge + +Für SEPA-Sammelüberweisungsaufträge auf Basis der pain.001.001.02 ist nur die +Grouping Option ,,Grouped" mit mindestens einer Einzeltransaktion CreditTransfer- +TransactionInformation bzw. DirectDebitTransactionInformation + zugelassen. + +Bei allen anderen pain messages, also ab pain.001.002.02 bzw. pain.008.002.01 +fällt die Gouping Option „Grouped" weg und es gelten für die Belegung einer even- +tuell vorhandenen Grouping Option die Festlegungen, wie sie im jeweils gültigen +DFÜ-Abkommen beschrieben sind (vgl. aktuell [DFÜ-Abkommen], Kapitel 2). Nichts +desto trotz darf in FinTS der Payment-Information-Block nur einmal vorkommen. + +Im Falle von Sammelaufträgen ist mindestens eine Einzeltransaktion CreditTrans- +ferTransactionInformation bzw. DirectDebitTransactionInformation + einzustellen. + +Die kreditinstitutsseitige Prüfung erfolgt, wie in allen anderen Fällen ebenfalls, stets +auf das Segment als ganzes bezogen. Enthält der SEPA-Sammelauftrag Fehler, die +bei der kreditinstitutsseitigen Prüfung sofort feststellbar sind, so ist das Institut be- +rechtigt den Auftrag zurückzuweisen, sofern dem Kunden dies unmittelbar innerhalb +desselben Dialoges mitgeteilt werden kann. Dies dient zur Vermeidung von Zuord- +nungsproblemen im Kundensystem. + +Für den Fall, dass ein oder mehrere Einzelaufträge fehlerhaft sind und nicht bear- +beitet werden, sollte der Code 3060 "Teilweise liegen Warnungen/Hinweise vor" als +Rückmeldung zur Gesamtnachricht gemeldet werden. Für den Auftrag sollten die +Rückmeldungscodes 3210 (Auftrag angenommen, fehlerhafte Einzelpositionen) +bzw. 3220 (Auftrag ausgeführt, fehlerhafte Einzelpositionen) genutzt werden. Dabei +können als Parameter zum Rückmeldungscode die PaymentIdentification +der fehlerhaften CreditTransferTransactionInformation bzw. Direct +DebitTransactionInformation eingestellt werden. + +Die Weiterverarbeitung des SEPA-Sammelauftrags (z.B. die bankfachliche Prüfung) +kann dagegen institutsindividuell gehandhabt werden. Falls dabei festgestellt wird, +dass einzelne CreditTransferTransactionInformation bzw. Direct Debi- +tTransactionInformation syntaktisch oder bankfachlich fehlerhaft +sind, so sind diese abzulehnen, die korrekten Einzeltransaktionen jedoch zur Aus- +führung zu bringen. Falls hingegen festgestellt wird, dass die Konsistenz der SEPA- +Sammelauftrags verletzt ist (z.B. Nichtübereinstimmung der Anzahl der Aufträge +oder der Kontrollsumme ControlSum im Group Header und der Summe +der Einzeltransaktionen), so muss der komplette Sammelauftrag abgelehnt werden, +unabhängig davon, ob die Einzeltransaktionen korrekt sind. + + +![](figures/194.1) + + +Falls in der BPD die Kontrollsumme als verpflichtend gekennzeichnet +ist, bezieht sich dies auch auf die in der pain message enthaltenen +Summenwerte. Einige Institute behalten sich vor, Aufträge ohne Kon- +trollsummen in der pain message zurückzuweisen. + + +![](figures/194.2) + + +Da die bankfachliche Korrektheit von Sammelaufträgen meist erst off- +line geprüft werden kann, erhält der Kunde die Information über eine +eventuelle Nichtausführung im Regelfall erst über den Kontoauszug +oder das Statusprotokoll. Im Statusprotokoll sollen dem Kunden die + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 475
+ + +# PaymentIdentification der fehlerhaften Einzelaufträge mitge- teilt werden. + + +![](figures/195.1) + + +Das Kundenprodukt hat vor dem Versenden eine Konsitenzprüfung +der SEPA-Nachricht durchzuführen. + +Eine kreditinstitutsseitige Disposition kann anhand der ggf. mitgelieferten Betrags- +umme der Gesamtdatei erfolgen. Wird eine Disposition durchgeführt und schlägt +diese fehl, so wird immer der gesamte Auftrag zurückgegeben. Teilausführungen +aufgrund nicht ausreichender Disposition erfolgen nicht. + + +## C.10.3.1 SEPA-Sammelüberweisungen + + +### C.10.3.1.1 SEPA-Sammelüberweisung einreichen + +Realisierung Bank: +optional + +Realisierung Kunde: optional + + +#### a) Kundenauftrag + + +##### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:SEPA-Sammelüberweisung
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKCCM
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3Summenfeld1DEGbtg#C1M: „Summenfeld benötigt“ (BPD) = „J“ O: sonst
4Einzelbuchung ge- wünscht1DEjn#C1O: ,,Einzelbuchung erlaubt" (BPD) = „J" N: sonst
5SEPA Descriptor1DEan.256M1
6SEPA pain messa- ge1DEbin..M1
+ + +#### . Belegungsrichtlinien + + +##### Kontoverbindung international + +IBAN und BIC müssen der IBAN in DebtorAccount bzw. der +BIC in DebtorAgent entsprechen + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 476Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + +## SEPA pain message + +Erlaubtes „SEPA Überweisung Kunde-Bank"-Schema It. HISPAS. + +In das Mussfeld RequestedExecutionDate ist der 1999-01-01 ein- +zustellen. + + +![](figures/196.1) + + +Für nicht terminierte Aufträge darf dem Kunden kein Eingabefeld zur +Eingabe eines Termins angeboten werden. + + +![](figures/196.2) + + +Enthält das Feld RequestedExecutionDate bei nicht +terminierten Aufträgen einen anderen Wert als ,,1999-01-01" so ist +der Auftrag mit der Rückmeldung „9150 - Ausführungsdatum darf +nicht belegt werden“ abzulehnen. + + +![](figures/196.3) + + +Wird die SEPA-pain-message aus einer fremden Quelle importiert, +so ist darauf zu achten, dass ein eventuell abweichendes Datum im +Feld RequestedExecutionDate auf den Wert ,,1999- +01-01“ geändert wird. + + +## b) Kreditinstitutsrückmeldung + + +### . Beschreibung + +Es werden keine Datensegmente zurückgemeldet. + + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + +s. Einzelüberweisung. Zusätzlich gelten: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
3210Auftrag angenommen, fehlerhafte Einzelpositionen
3220Auftrag ausgeführt, fehlerhafte Einzelpositionen
9130SEPA-Nachrichtenformat ungültig
9210Sammelauftrag wurde abgelehnt, da Disposition fehlerhaft
9210Ausführungsdatum hier nicht zugelassen
9220Einzelauftrag Nr. x wurde aufgrund eines Fehlers nicht ausgeführt
+ + +### c) Bankparameterdaten + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:SEPA-Sammelüberweisung Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HICCMS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 477
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter SEPA- Sammelüberwei- sung1DEGM1
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
478		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + +#### C.10.3.1.2 Terminierte SEPA-Sammelüberweisung + +Die terminierte SEPA-Sammelüberweisung unterscheidet sich von der nicht- +terminierten Sammelüberweisung durch die Angabe eines in der Zukunft liegenden +Ausführungsdatums in Feld RequestedExecutionDate . Der Einrei- +cher bestimmt, dass zu diesem Datum alle in der SEPA-Sammelüberweisung ent- +haltenen Einzeltransaktionen ausgeführt werden sollen. + +Folgende Geschäftsvorfälle sind vorgesehen: + +. Einreichung terminierter SEPA-Sammelüberweisungen + +. Bestand terminierter SEPA-Sammelüberweisungen abrufen + +· Löschung terminierter SEPA-Sammelüberweisungen + +Die Änderung einer bereits eingereichten terminierten SEPA-Sammelüberweisung +ist nur durch Löschung und anschließende Neuanlage möglich. + + +##### C.10.3.1.2.1 Einreichung terminierter SEPA-Sammelüberweisungen + +Realisierung Bank: +optional + +Realisierung Kunde: optional + + +### a) Kundenauftrag + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Terminierte SEPA-Sammelüberweisung einreichen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKCME
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 479
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3Summenfeld1DEGbtg#C1M: „Summenfeld benötigt“ (BPD) = „J" O: sonst
4Einzelbuchung ge- wünscht1DEjn#C1O: ,,Einzelbuchung erlaubt" (BPD) = „J" N: sonst
5SEPA Descriptor1DEan.256M1
6SEPA pain messa- ge1DEbin..M1
+ + +### . Belegungsrichtlinien + + +#### Kontoverbindung international + +IBAN und BIC müssen der IBAN in DebtorAccount bzw. der +BIC in DebtorAgent entsprechen. + + +#### SEPA pain message + +Erlaubtes „SEPA Überweisung Kunde-Bank"-Schema It. HISPAS. + +Das Feld ControlSum muss - zwecks späterer besser Identifikation der +SEPA-Sammelüberweisung bei einer Bestandsabfrage - befüllt sein. + + +### b) Kreditinstitutsrückmeldung + + +### . Beschreibung + + +![](figures/199.1) + + +Falls das Kreditinstitut schon bei der Einreichung eine Auf- +tragsidentifikation zurückmelden kann, sollte diese Möglich- +keit genutzt werden. Andernfalls hat das Kundensystem vor +einer Änderung oder Löschung den gesamten Bestand abzu- +rufen, um in den Besitz der Auftragsidentifikation zu gelan- +gen. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Einreichung terminierter SEPA-Sammelüberweisung bestäti-
gen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HICME
Bezugssegment:HKCME
Version:1
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
480		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Auftragsidentifikati- on1DEan.99O1
+ + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + +Zusätzlich zu den Rückmeldungscodes der nicht-terminierten Sammelüberweisung +gelten: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
0020Auftrag zur Ausführung vorgemerkt
3030Datum ist kein Bankgeschäftstag. Der Auftrag wird ausgeführt am ..
9210Mindestzeitraum bis zum Ausführungstermin überschritten
9210Datum liegt nicht in der Zukunft
9210Datum liegt zu weit in der Zukunft
9210Datum ist kein Buchungstag
+ + +### c) Bankparameterdaten + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Terminierte SEPA-Sammelüberweisung einreichen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HICMES
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter termi- nierte SEPA- Sammelüberwei- sung einreichen1DEGM1
+ + +##### C.10.3.1.2.2 Bestand terminierter SEPA-Sammelüberweisungen abrufen (Segment- version 1) + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +### a) Kundenauftrag + + +#### . Beschreibung + +Der Kunde ruft die im Kreditinstitut zu einem Konto hinterlegten terminierten SEPA- +Sammelaufträge ab, die noch zur Ausführung anstehen. + +In den BPD ist angegeben, ob ein Zeitraum angegeben werden darf. Falls kein Zeit- +raum angegeben wird, werden alle terminierten Aufträge zurückgemeldet, deren + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Geschäftsvorfälle		Stand: 07.08.2015Seite: 481
+ + +Ausführung im angegebenen Zeitraum ansteht. Falls ein Zeitraum angegeben wird, +werden nur die durch den Zeitraum angegebenen Aufträge übermittelt. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Bestand terminierter SEPA-Sammelüberweisungen anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKCMB
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3Von Datum1DEdat#C1O: „Zeitraum möglich“ (BPD) = „J“ N: sonst
4Bis Datum1DEdat#C1O: „Zeitraum möglich“ (BPD) = „J“ N: sonst
5Maximale Anzahl Einträge1DEnum..4C1>0
O: ,,Eingabe Anzahl Ein- träge erlaubt“ (BPD) = „J“ N: sonst
6Aufsetzpunkt1DEan..35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +### b) Kreditinstitutsrückmeldung + + +#### . Beschreibung + +Für jede noch nicht ausgeführte terminierte SEPA-Sammelüberweisung wird ein Da- +tensegment mit Informationen über den Sammelauftrag in die Rückmeldungsnach- +richt eingestellt. Aufgrund des Datenvolumens ist der Abruf der Einzelaufträge nicht +möglich. + + +![](figures/201.1) + + +Falls der Rückmeldecode 3041 gesendet wird, muss direkt im An- +schluss ein Bestandsabruf des korrespondierenden Nicht-SEPA- +Bestandes durchgeführt werden. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
482		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Bestand terminierter SEPA-Sammelüberweisungen rückmel- den
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HICMB
Bezugssegment:HKCMB
Version:1
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Auftragsidentifikati- on1DEan.99M1
3Kontoverbindung international1DEGkti#M1
4Einreichungsdatum1DEdat#M1
5Ausführungsdatum1DEdat#M1
6Anzahl der Aufträge1DEnum..6M1
7Summe der Beträ- ge2DEGbtg#M1
+ + +## . Belegungsrichtlinien + + +### Kontoverbindung international + +IBAN und BIC müssen der IBAN in DebtorAccount bzw. der +BIC in DebtorAgent entsprechen. + + +### Ausführungsdatum + +Das Ausführungsdatum entspricht dem Feld RequestedExecutionDate . + + +### Anzahl der Aufträge + +Die Anzahl der Aufträge entspricht dem Feld NumberOfTransactions . + + +### Summe der Beträge + +Die Summe der beträge entspricht der ControlSum . + + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
3010Es liegen keine Einträge vor
3041ein weiterer Bestand liegt vor HKTSB
3042kein weiterer Bestand liegt vor HKTSB
3043keine Informationen über weitere Bestände HKTSB
9210Bereichende darf nicht vor Bereichanfang liegen
9210Datum liegt nicht in der Zukunft
9210Keine gültige Kontoverbindung des Kunden
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle
SEPA-Zahlungsverkehr		Stand: 07.08.2015Seite: 483
+ + +#### c) Bankparameterdaten + + +##### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Bestand terminierter SEPA-Sammelüberweisungen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HICMBS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Bestand terminierter SEPA- Sammelüber- weisungen1DEGM1
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
484		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + +###### C.10.3.1.2.3 Löschung terminierter SEPA-Sammelüberweisungen + +Realisierung Bank: +optional + +Realisierung Kunde: +optional + + +####### a) Kundenauftrag + + +######## . Beschreibung + +Die zu löschende SEPA-Sammelüberweisung wird über die Auftragsidentifikation +identifiziert. Diese wird dem Kunden bei der Einreichung oder beim Abruf des Be- +standes mitgeteilt. Neben der Auftragsidentifikation müssen weitere Daten der +SEPA-Sammelüberweisung eingestellt werden, um kreditinstitutsseitige Plausibili- +tätsprüfungen zu ermöglichen. + + +![](figures/204.1) + + +Dieser Geschäftsvorfall darf vom Kreditinstitut nur angeboten wer- +den, wenn es eine Auftragsidentifikation unterstützt, da ansonsten +die Identifikation der zu löschenden Überweisung nicht möglich ist. + +Zu löschende terminierte Aufträge liegen immer in der Zukunft. Eine minimale Vor- +laufzeit für die Einreichung des Löschauftrags ist nicht vorgesehen. Es können je- +doch nur Aufträge gelöscht werden, die auch im Bestand aufgeführt werden. + + +######## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Terminierte SEPA-Sammelüberweisung löschen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKCML
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Auftragsidentifikati- on1DEan.99M1
3Kontoverbindung international1DEGkti#O1
4Einreichungsdatum1DEdat#O1
5Ausführungsdatum1DEdat#O1
6Anzahl der Aufträge1DEnum..6O1
7Summe der Beträ- ge2DEGbtg#O1
+ + +######## . Belegungsrichtlinien + + +######## Kontoverbindung international + +IBAN und BIC müssen der IBAN in DebtorAccount bzw. der +BIC in DebtorAgent entsprechen. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 485
+ + +####### Ausführungsdatum + +Das Ausführungsdatum entspricht dem Feld RequestedExecutionDate . + + +####### Anzahl der Aufträge + +Die Anzahl der Aufträge entspricht dem Feld NumberOfTransactions . + +Summe der Beträge + +Die Summe der beträge entspricht der ControlSum . + + +####### b) Kreditinstitutsrückmeldung + + +####### . Beschreibung + +Es werden keine Datensegmente zurückgemeldet. + + +####### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag zur Löschung vorgemerkt
0020Auftrag gelöscht
9010Löschung nicht mehr möglich, da Auftrag bereits zur Löschung vorgemerkt
9010Auftragsidentifikation stimmt nicht mit Auftragsdaten überein
9210Auftrag existiert nicht bzw. wurde bereits ausgeführt
+ + +####### c) Bankparameterdaten + + +######## . Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + +######## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Terminierte SEPA-Sammelüberweisung löschen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HICMLS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
486		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + +######### C.10.3.2 SEPA-Sammellastschriften + +Es gelten die Festlegungen zur SEPA-Basis-Lastschrift laut DFÜ-Abkommen (vgl. +[DFÜ-Abkommen], Kapitel 2). + + +![](figures/206.1) + + +Zur Bearbeitung von SEPA-Lastschriften ist der vorherige Ab- +schluss einer entsprechenden Inkassovereinbarung zwischen Kun- +de und Kreditinstitut erforderlich, mit der der Kunde (Zahlungsemp- +fänger) zum SEPA-Lastschriftverfahren zugelassen wird und in de- +ren Rahmen er sich verpflichtet hat, nur solche Lastschriften zum +Einzug einzureichen, für die ihm eine schriftliche Einzugsermächti- +gung des Zahlungspflichtigen (Mandat) vorliegt. Sofern diese Vo- +raussetzung nicht gegeben ist, ist dem Kunden in den UPD die Aus- +führung dieses Geschäftsvorfalls nicht zu gestatten. + + +########## C.10.3.2.1 SEPA-Sammellastschrift einreichen + +Gelöscht + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 487
+ + +########## C.10.3.2.2 Terminierte SEPA-Sammellastschriften + +Bei den terminierten SEPA-Lastschriften bestimmt der Einreicher durch die Angabe +eines in der Zukunft liegenden Fälligkeitssdatums in Feld RequestedCollectionDate +, dass zu diesem Datum alle in der SEPA-Sammellastschrift ent- +haltenen Einzeltransaktionen auf den Konten der Bezogenen belastet werden sol- +len. + +Folgende Geschäftsvorfälle sind vorgesehen: + +. Einreichung terminierter SEPA-Sammellastschrift + +. Einreichung terminierter SEPA-COR1-Sammellastschrift + +. Bestand terminierter SEPA-Sammellastschrift abrufen + +· Löschung terminierter SEPA-Sammellastschrift + +Die Änderung einer bereits eingereichten terminierten SEPA bzw. SEPA-COR1- +Sammellastschrift ist nur durch Löschung und anschließende Neuanlage möglich. + + +########## C.10.3.2.2.1 Einreichung terminierter SEPA-Sammellastschrift (Segmentversion 1) + + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +##### a) Kundenauftrag + + +###### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Terminierte SEPA-Sammellastschrift einreichen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKDME
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
488		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt:
SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3Summenfeld1DEGbtg#C1M: „Summenfeld benötigt“ (BPD) = „J“ O: sonst
4Einzelbuchung ge- wünscht1DEjn#C1O: ,,Einzelbuchung erlaubt" (BPD) = „J“ N: sonst
5SEPA Descriptor1DEan.256M1
6SEPA pain messa- ge1DEbin..M1
+ + +##### . Belegungsrichtlinien + + +###### Kontoverbindung international + +IBAN und BIC müssen der IBAN in CreditorAccount bzw. der +BIC in CreditorAgent entsprechen + + +###### SEPA pain message + +Erlaubtes ,,SEPA Lastschrifteinreichung Kunde-Bank"-Schema It. HISPAS. Als Lo- +callnstrumentSEPACode ist lediglich CORE für die SEPA- +Basislastschrift erlaubt. + +Das Feld ControlSum muss - zwecks späterer besser Identifikation der +SEPA-Sammellastschrift bei einer Bestandsabfrage - befüllt sein. + + +## b) Kreditinstitutsrückmeldung + + +### . Beschreibung + + +![](figures/208.1) + + +Falls das Kreditinstitut schon bei der Einreichung eine Auftragsi- +dentifikation zurückmelden kann, sollte diese Möglichkeit genutzt +werden. Andernfalls hat das Kundensystem vor einer Änderung +oder Löschung den gesamten Bestand abzurufen, um in den Be- +sitz der Auftragsidentifikation zu gelangen. + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Einreichung terminierter SEPA-Sammellastschrift bestätigen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIDME
Bezugssegment:HKDME
Version:1
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 489
+ + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Auftragsidentifikati- on1DEan.99O1
+ + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + +Zusätzlich zu den Rückmeldungscodes der nicht-terminierten +SEPA- +Sammellastschrift gelten: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
0020Auftrag zur Ausführung vorgemerkt
3030Datum ist kein Bankgeschäftstag. Der Auftrag wird ausgeführt am
9210Mindestzeitraum bis zum Ausführungstermin überschritten
9210Datum liegt nicht in der Zukunft
9210Datum liegt zu weit in der Zukunft
9210Datum ist kein Buchungstag
+ + +### c) Bankparameterdaten + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Terminierte SEPA-Sammellastschrift einreichen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIDMES
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter termi- nierte SEPA- Sammellastschrift einreichen1DEGM1
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
490		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + +##### C.10.3.2.2.2 Einreichung terminierter SEPA-Sammellastschrift (Segmentversion 22) + + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +### a) Kundenauftrag + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Terminierte SEPA-Sammellastschrift einreichen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKDME
Bezugssegment:-
Version:22
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3Summenfeld1DEGbtg#C1M: „Summenfeld benötigt“ (BPD) = „J“ O: sonst
4Einzelbuchung ge- wünscht1DEjn#C1O: ,,Einzelbuchung erlaubt" (BPD) = ,,J" N: sonst
5SEPA Descriptor1DEan.256M1
6SEPA pain messa- ge1DEbin..M1
+ + +### . Belegungsrichtlinien + + +## Kontoverbindung international + +IBAN und BIC müssen der IBAN in CreditorAccount bzw. der +BIC in CreditorAgent entsprechen + +SEPA pain message + +Erlaubtes ,,SEPA Lastschrifteinreichung Kunde-Bank"-Schema It. HISPAS. Es gelten +die Vorgaben aus der BPD zu den unterstützten SEPA Lastschriftarten zur Bele- +gung des Feldes Es gelten die Vorgaben aus der BPD zu den unterstützten SEPA- +Lastschriftarten zur Belegung des Feldes LocalInstrumentSEPACode +. + +Das Feld ControlSum muss - zwecks späterer besserer Identifikation +der SEPA-Sammellastschrift bei einer Bestandsabfrage - befüllt sein. + + +### b) Kreditinstitutsrückmeldung + + +#### . Beschreibung + + +![](figures/210.1) + + +Falls das Kreditinstitut schon bei der Einreichung eine Auftragsi- +dentifikation zurückmelden kann, sollte diese Möglichkeit genutzt +werden. Andernfalls hat das Kundensystem vor einer Änderung + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle
SEPA-Zahlungsverkehr		Stand: 07.08.2015Seite: 491
+ + +oder Löschung den gesamten Bestand abzurufen, um in den Be- +sitz der Auftragsidentifikation zu gelangen. + + +##### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Einreichung terminierter SEPA-Sammellastschrift bestätigen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIDME
Bezugssegment:HKDME
Version:22
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Auftragsidentifikati- on1DEan.99O1
+ + +##### ◆ Ausgewählte Beispiele für Rückmeldungscodes + +Zusätzlich +zu den +Rückmeldungscodes +der +nicht-terminierten +SEPA- +Sammellastschrift gelten: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
0020Auftrag zur Ausführung vorgemerkt
3030Datum ist kein Bankgeschäftstag. Der Auftrag wird ausgeführt am ...
9210Mindestzeitraum bis zum Ausführungstermin überschritten
9210Datum liegt nicht in der Zukunft
9210Datum liegt zu weit in der Zukunft
9210Datum ist kein Buchungstag
+ + +##### c) Bankparameterdaten + + +###### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Terminierte SEPA-Sammellastschrift einreichen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIDMES
Bezugssegment:HKVVB
Version:22
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter termi- nierte SEPA-22DEGM1
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
492		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + +
Sammellastschrift einreichen
+ + +####### C.10.3.2.2.3 Einreichung terminierter SEPA-COR1-Sammellastschrift + +Bei der SEPA-COR1-Sammellastschrift ist die Vorlaufzeit auf einen Tag verkürzt. + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +######## a) Kundenauftrag + + +######### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Terminierte SEPA-COR1-Sammellastschrift einreichen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKDMC
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3Summenfeld1DEGbtg#C1M M: ,,Summenfeld benö- tigt“ (BPD) = „J“ O: sonst
4Einzelbuchung ge- wünscht1DEjn#C1O: ,,Einzelbuchung erlaubt" (BPD) = „J“ N: sonst
5SEPA Descriptor1DEan.256M1
6SEPA pain messa- ge1DEbin."M1
+ + +#### . Belegungsrichtlinien + + +##### Kontoverbindung international + +IBAN und BIC müssen der IBAN in CreditorAccount bzw. der +BIC in CreditorAgent entsprechen. + + +##### SEPA pain message + +Erlaubtes ,,SEPA Lastschrifteinreichung Kunde-Bank"-Schema It. HISPAS. Als Lo- +calInstrumentSEPACode ist lediglich COR1 für die SEPA-COR1- +Sammellastschrift erlaubt. + + +##### b) Kreditinstitutsrückmeldung + + +###### . Beschreibung + + +![](figures/212.1) + + +Falls das Kreditinstitut schon bei der Einreichung eine Auftragsiden- +tifikation zurückmelden kann, sollte diese Möglichkeit genutzt wer- +den. Andernfalls hat das Kundensystem vor einer Änderung oder +Löschung den gesamten Bestand abzurufen (s. C.10.2.5.4.5 „Be- + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle
SEPA-Zahlungsverkehr		Stand: 07.08.2015Seite: 493
+ + +# stand terminierter SEPA-Einzellastschriften abrufen“), um in den Be- sitz der Auftragsidentifikation zu gelangen. + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Einreichung terminierter SEPA-COR1-Sammellastschrift be- stätigen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIDMC
Bezugssegment:HKDMC
Version:1
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Auftragsidentifika- tion1DEan.99O1
+ + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
0020Auftrag zur Ausführung vorgemerkt
3030Datum ist kein Bankgeschäftstag. Der Auftrag wird ausgeführt am ...
3070Auftrag wird unter Referenz xxx verarbeitet
3210Auftrag angenommen, fehlerhafte Einzelpositionen
3220Auftrag ausgeführt, fehlerhafte Einzelpositionen
9010Keine Berechtigung für SEPA-Lastschriftverfahren
9130SEPA-Format ungültig
9210Mindestzeitraum bis zum Ausführungstermin überschritten
9210Datum liegt nicht in der Zukunft
9210Datum liegt zu weit in der Zukunft
9210Datum ist kein Buchungstag
9210Ausführungsdatum hier nicht zugelassen
9220Einzelauftrag Nr. x wurde aufgrund eines Fehlers nicht ausgeführt
+ + +## c) Bankparameterdaten + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Terminierte SEPA-COR1-Sammellastschrift Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIDMCS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 494Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter termi- nierte SEPA-COR1- Sammellastschrift1DEGM1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:SEPA-Zahlungsverkehr
Geschäftsvorfälle		Stand: 07.08.2015Seite: 495
+ + +# C.10.3.2.2.4 Bestand terminierter SEPA-Sammellastschriften abrufen (Segmentversi- on 1) + +Realisierung Bank: +optional + +Realisierung Kunde: optional + + +## a) Kundenauftrag + + +### . Beschreibung + +Der Kunde ruft die im Kreditinstitut zu einem Konto hinterlegten terminierten SEPA- +bzw. SEPA-COR1-Sammellastschriften ab, die noch zur Ausführung anstehen. + +In den BPD ist angegeben, ob ein Zeitraum angegeben werden darf. Falls kein Zeit- +raum angegeben wird, werden alle terminierten Aufträge zurückgemeldet, deren +Ausführung im angegebenen Zeitraum ansteht. Falls ein Zeitraum angegeben wird, +werden nur die durch den Zeitraum angegebenen Aufträge übermittelt. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Bestand terminierter SEPA-Sammellastschriften anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKDMB
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3Von Datum1DEdat#C1O: „Zeitraum möglich“ (BPD) = „J“ N: sonst
4Bis Datum1DEdat#C1O: „Zeitraum möglich“ (BPD) = „J“ N: sonst
5Maximale Anzahl Einträge1DEnum..4C1>0
O: ,,Eingabe Anzahl Ein- träge erlaubt“ (BPD) = „J“ N: sonst
6Aufsetzpunkt1DEan..35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +## b) Kreditinstitutsrückmeldung + + +### . Beschreibung + +Für jede noch nicht ausgeführte terminierte SEPA- bzw. SEPA-COR1- +Sammellastschrift wird ein Datensegment mit Informationen über den Sammelauf- +trag in die Rückmeldungsnachricht eingestellt. Aufgrund des Datenvolumens ist der +Abruf der Einzelaufträge nicht möglich. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
496		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + +![](figures/216.1) + + +Falls der Rückmeldecode 3041 gesendet wird, muss direkt im An- +schluss ein Bestandsabruf des korrespondierenden Nicht-SEPA- +Bestandes durchgeführt werden. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Bestand terminierter SEPA-Sammellastschriften rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIDMB
Bezugssegment:HKDMB
Version:1
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Auftragsidentifikati- on1DEan..99M1
3Kontoverbindung international1DEGkti#M1
4Einreichungsdatum1DEdat#M1
5Ausführungsdatum1DEdat#M1
6Anzahl der Aufträge1DEnum..6M1
7Summe der Beträ- ge2DEGbtg#M1
+ + +### . Belegungsrichtlinien + + +#### Kontoverbindung international + +IBAN und BIC müssen der IBAN in CreditorAccount bzw. der +BIC in CreditorAgent entsprechen. + + +#### Ausführungsdatum + +Das Ausführungsdatum entspricht dem Feld RequestedCollectionDate . + + +#### Anzahl der Aufträge + +Die Anzahl der Aufträge entspricht dem Feld NumberOfTransactions . + + +#### Summe der Beträge + +Die Summe der Beträge entspricht der ControlSum . + + +#### ◆ Ausgewählte Beispiele für Rückmeldungscodes + +Code Beispiel für Rückmeldungstext + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 497
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
0020Auftrag ausgeführt
3010Es liegen keine Einträge vor
3041ein weiterer Bestand liegt vor HKSLB
3042kein weiterer Bestand liegt vor HKSLB
3043keine Informationen über weitere Bestände HKSLB
9210Bereichende darf nicht vor Bereichanfang liegen
9210Datum liegt nicht in der Zukunft
9210Keine gültige Kontoverbindung des Kunden
+ + +## c) Bankparameterdaten + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Bestand terminierter SEPA-Sammellastschriften Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIDMBS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Bestand terminierter SEPA- Sammellast- schriften1DEGM1
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
498		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + +# C.10.3.2.2.5 Löschung terminierter SEPA-Sammellastschriften + +Realisierung Bank: +optional + +Realisierung Kunde: optional + + +## a) Kundenauftrag + + +### . Beschreibung + +Die zu löschende SEPA- bzw. SEPA-COR1-Sammellastschrift wird über die Auf- +tragsidentifikation identifiziert. Diese wird dem Kunden bei der Einreichung oder +beim Abruf des Bestandes mitgeteilt. Neben der Auftragsidentifikation müssen wei- +tere Daten der SEPA- bzw. SEPA-COR1-Sammellastschrift eingestellt werden, um +kreditinstitutsseitige Plausibilitätsprüfungen zu ermöglichen. + + +![](figures/218.1) + + +Dieser Geschäftsvorfall darf vom Kreditinstitut nur angeboten wer- +den, wenn es eine Auftragsidentifikation unterstützt, da ansonsten +die Identifikation der zu löschenden SEPA- bzw. SEPA-COR1- +Sammellastschrift nicht möglich ist. + +Zu löschende terminierte Aufträge liegen immer in der Zukunft. Eine minimale Vor- +laufzeit für die Einreichung des Löschauftrags ist nicht vorgesehen. Es können je- +doch nur Aufträge gelöscht werden, die auch im Bestand aufgeführt werden. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Terminierte SEPA-Sammellastschrift löschen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKDML
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Auftragsidentifikati- on1DEan.99M1
3Kontoverbindung international1DEGkti#M1
4Einreichungsdatum1DEdat#M1
5Ausführungsdatum1DEdat#M1
6Anzahl der Aufträge1DEnum..6M1
7Summe der Beträ- ge2DEGbtg#M1
+ + +### . Belegungsrichtlinien + + +### Kontoverbindung international + +IBAN und BIC müssen der IBAN in CreditorAccount bzw. der +BIC in CreditorAgent entsprechen. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 499
+ + +## Ausführungsdatum + +Das Ausführungsdatum entspricht dem Feld RequestedCollectionDate . + + +## Anzahl der Aufträge + +Die Anzahl der Aufträge entspricht dem Feld NumberOfTransactions . + +Summe der Beträge + +Die Summe der Beträge entspricht der ControlSum . + + +## b) Kreditinstitutsrückmeldung + + +## . Beschreibung + +Es werden keine Datensegmente zurückgemeldet. + + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag zur Löschung vorgemerkt
0020Auftrag gelöscht
9010Löschung nicht mehr möglich, da Auftrag bereits zur Löschung vorgemerkt
9010Auftragsidentifikation stimmt nicht mit Auftragsdaten überein
9210Auftrag existiert nicht bzw. wurde bereits ausgeführt
+ + +## c) Bankparameterdaten + + +### . Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Terminierte SEPA-Sammellastschrift löschen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIDMLS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + +# C.10.3.3 SEPA-Firmensammellastschrift + +Es gelten die Festlegungen zur SEPA-Firmenlastschrift laut DFÜ-Abkommen (vgl. +[DFÜ-Abkommen], Kapitel 2). + + +![](figures/219.1) + + +Zur Bearbeitung von SEPA-Firmensammellastschriften ist der vor- +herige Abschluss einer entsprechenden Inkassovereinbarung zwi- +schen Kunde und Kreditinstitut erforderlich, mit der der Kunde (Zah- + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
500		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + +lungsempfänger) zum SEPA-Lastschriftverfahren zugelassen wird +und in deren Rahmen er sich verpflichtet hat, nur solche Lastschrif- +ten zum Einzug einzureichen, für die ihm eine schriftliche Einzugs- +ermächtigung des Zahlungspflichtigen (Mandat) vorliegt. Sofern die- +se Voraussetzung nicht gegeben ist, ist dem Kunden in den UPD +die Ausführung dieses Geschäftsvorfalls nicht zu gestatten. + + +## C.10.3.3.1 SEPA-Firmensammellastschrift einreichen + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 501
+ + +## C.10.3.3.2 Terminierte SEPA-Firmensammellastschrift + +Bei der terminierten SEPA-Firmensammellastschrift bestimmt der Einreicher durch +die Angabe eines in der Zukunft liegenden Fälligkeitsdatums in Feld RequestedCol- +lectionDate , dass zu diesem Datum alle in der SEPA- +Firmensammellastschrift enthaltenen Einzeltransaktionen auf den Konten der Bezo- +genen belastet werden sollen. Als LocalInstrumentSEPACode ist +lediglich B2B für die SEPA-Firmenlastschrift erlaubt. + +Folgende Geschäftsvorfälle sind vorgesehen: + +. Einreichung terminierter SEPA-Firmensammellastschrift + +. Bestand terminierter SEPA-Firmensammellastschrift abrufen + +· Löschung terminierter SEPA-Firmensammellastschrift + +Die Änderung einer bereits eingereichten terminierten Firmensammellastschrift ist +nur durch Löschung und anschließende Neuanlage möglich. + + +## C.10.3.3.2.1 Einreichung terminierter SEPA-Firmensammellastschrift (Segmentversi- on 1) + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +### a) Kundenauftrag + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Terminierte SEPA-Firmensammellastschrift einreichen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKBME
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
502		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt:
SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3Summenfeld1DEGbtg#C1M: „Summenfeld benötigt“ (BPD) = „J" O: sonst
4Einzelbuchung ge- wünscht1DEjn#C1O: ,,Einzelbuchung erlaubt" (BPD) = „J“ N: sonst
5SEPA Descriptor1DEan256M1
6SEPA pain messa- ge1DEbin..M1
+ + +### . Belegungsrichtlinien + + +#### Kontoverbindung international + +IBAN und BIC müssen der IBAN in CreditorAccount bzw. der +BIC in CreditorAgent entsprechen. + + +#### SEPA pain message + +Erlaubtes ,,SEPA Lastschrifteinreichung Kunde-Bank"-Schema It. HISPAS. Als Lo- +calInstrumentSEPACode + ist lediglich B2B für die SEPA- +Firmenlastschrift erlaubt. + +Das Feld ControlSum muss - zwecks späterer besser Identifikation der +SEPA-Firmensammellastschrift bei einer Bestandsabfrage - befüllt sein. + + +### b) Kreditinstitutsrückmeldung + + +#### . Beschreibung + + +![](figures/222.1) + + +Falls das Kreditinstitut schon bei der Einreichung eine Auftragsi- +dentifikation zurückmelden kann, sollte diese Möglichkeit genutzt +werden. Andernfalls hat das Kundensystem vor einer Änderung +oder Löschung den gesamten Bestand abzurufen, um in den Be- +sitz der Auftragsidentifikation zu gelangen. + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Einreichung terminierter SEPA-Firmensammellastschrift be- stätigen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIBME
Bezugssegment:HKBME
Version:1
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 503
+ + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Auftragsidentifikati- on1DEan.99O1
+ + +#### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
0020Auftrag zur Ausführung vorgemerkt
3030Datum ist kein Bankgeschäftstag. Der Auftrag wird ausgeführt am ...
9210Mindestzeitraum bis zum Ausführungstermin überschritten
9210Datum liegt nicht in der Zukunft
9210Datum liegt zu weit in der Zukunft
9210Datum ist kein Buchungstag
+ + +#### c) Bankparameterdaten + + +##### . Format + +Name: + +Terminierte SEPA-Firmensammellastschrift einreichen Para- +meter + +Typ: + +Segment + +Segmentart: + +Geschäftsvorfall + +Kennung: + +HIBMES + +Bezugssegment: + +HKVVB + +Version: + +1 + +Sender: + +Kreditinstitut + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter termi- nierte SEPA- Firmensammellast- schrift einreichen1DEGM1
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
504		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + +## C.10.3.3.2.2 Einreichung terminierter SEPA-Firmensammellastschrift (Segmentversi- on 22) + +Realisierung Bank: +optional + +Realisierung Kunde: +optional + + +### a) Kundenauftrag + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Terminierte SEPA-Firmensammellastschrift einreichen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKBME
Bezugssegment:-
Version:22
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3Summenfeld1DEGbtg#C1M: „Summenfeld benötigt“ (BPD) = „J" O: sonst
4Einzelbuchung ge- wünscht1DEjn#C1O: ,,Einzelbuchung erlaubt" (BPD) = „J“ N: sonst
5SEPA Descriptor1DEan.256M1
6SEPA pain messa- ge1DEbin..M1
+ + +### . Belegungsrichtlinien + + +#### Kontoverbindung international + +IBAN und BIC müssen der IBAN in CreditorAccount bzw. der +BIC in CreditorAgent entsprechen. + + +#### SEPA pain message + +Erlaubtes ,,SEPA Lastschrifteinreichung Kunde-Bank"-Schema It. HISPAS. Als Lo- +calInstrumentSEPACode + ist lediglich B2B für die SEPA- +Firmenlastschrift erlaubt. + +Das Feld ControlSum muss - zwecks späterer besser Identifikation der +SEPA-Firmensammellastschrift bei einer Bestandsabfrage - befüllt sein. + + +### b) Kreditinstitutsrückmeldung + +. Beschreibung + + +![](figures/224.1) + + +Falls das Kreditinstitut schon bei der Einreichung eine Auftragsi- +dentifikation zurückmelden kann, sollte diese Möglichkeit genutzt + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle
SEPA-Zahlungsverkehr		Stand: 07.08.2015Seite: 505
+ + +werden. Andernfalls hat das Kundensystem vor einer Änderung +oder Löschung den gesamten Bestand abzurufen, um in den Be- +sitz der Auftragsidentifikation zu gelangen. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Einreichung terminierter SEPA-Firmensammellastschrift be- stätigen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIBME
Bezugssegment:HKBME
Version:22
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Auftragsidentifikati- on1DEan.99O1
+ + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
0020Auftrag zur Ausführung vorgemerkt
3030Datum ist kein Bankgeschäftstag. Der Auftrag wird ausgeführt am ..
9210Mindestzeitraum bis zum Ausführungstermin überschritten
9210Datum liegt nicht in der Zukunft
9210Datum liegt zu weit in der Zukunft
9210Datum ist kein Buchungstag
+ + +### c) Bankparameterdaten + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Terminierte SEPA-Firmensammellastschrift einreichen Para- meter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIBMES
Bezugssegment:HKVVB
Version:22
Sender:Kreditinstitut
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
506		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter termi- nierte SEPA- Firmensammellast- schrift einreichen22DEGM1
+ + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 507
+ + +# C.10.3.3.2.3 Bestand terminierter SEPA-Firmensammellastschriften abrufen (Seg- mentversion 1) + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +## a) Kundenauftrag + + +### . Beschreibung + +Der Kunde ruft die im Kreditinstitut zu einem Konto hinterlegten terminierten SEPA- +Firmensammellastschriften ab, die noch zur Ausführung anstehen. + +In den BPD ist angegeben, ob ein Zeitraum angegeben werden darf. Falls kein Zeit- +raum angegeben wird, werden alle terminierten Aufträge zurückgemeldet, deren +Ausführung im angegebenen Zeitraum ansteht. Falls ein Zeitraum angegeben wird, +werden nur die durch den Zeitraum angegebenen Aufträge übermittelt. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3Von Datum1DEdat#C1O: „Zeitraum möglich“ (BPD) = „J“ N: sonst
4Bis Datum1DEdat#C1O: „Zeitraum möglich“ (BPD) = „J“ N: sonst
5Maximale Anzahl Einträge1DEnum..4C1>0
O: ,,Eingabe Anzahl Ein- träge erlaubt“ (BPD) = „J“ N: sonst
6Aufsetzpunkt1DEan.35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +## b) Kreditinstitutsrückmeldung + + +### . Beschreibung + +Für jede noch nicht ausgeführte terminierte Firmensammellastschrift wird ein Daten- +segment mit Informationen über den Sammelauftrag in die Rückmeldungsnachricht +eingestellt. Aufgrund des Datenvolumens ist der Abruf der Einzelaufträge nicht mög- +lich. + +Name: + +Bestand terminierter SEPA-Firmensammellastschriften anfor- +dern + +Typ: + +Segment + +Segmentart: + +Geschäftsvorfall + +Kennung: + +HKBMB + +Bezugssegment: + +\- + +Version: + +1 + +Sender: + +Kunde + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
508		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + +![](figures/228.1) + + +Falls der Rückmeldecode 3041 gesendet wird, muss direkt im An- +schluss ein Bestandsabruf des korrespondierenden Nicht-SEPA- +Bestandes durchgeführt werden. + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Bestand terminierter SEPA-Firmensammellastschriften rück- melden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIBMB
Bezugssegment:HKBMB
Version:1
Anzahl:n
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Auftragsidentifikati- on1DEan.99M1
3Kontoverbindung international1DEGkti#M1
4Einreichungsdatum1DEdat#M1
5Ausführungsdatum1DEdat#M1
6Anzahl der Aufträge1DEnum..6M1
7Summe der Beträ- ge2DEGbtg#M1
+ + +## . Belegungsrichtlinien + + +### Kontoverbindung international + +IBAN und BIC müssen der IBAN in CreditorAccount bzw. der +BIC in CreditorAgent entsprechen. + + +### Ausführungsdatum + +Das Ausführungsdatum entspricht dem Feld RequestedCollectionDate . + + +### Anzahl der Aufträge + +Die Anzahl der Aufträge entspricht dem Feld NumberOfTransactions . + + +### Summe der Beträge + +Die Summe der Beträge entspricht der ControlSum . + + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + +Code Beispiel für Rückmeldungstext + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 509
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
0020Auftrag ausgeführt
3010Es liegen keine Einträge vor
3041ein weiterer Bestand liegt vor HKSLB
3042kein weiterer Bestand liegt vor HKSLB
3043keine Informationen über weitere Bestände HKSLB
9210Bereichende darf nicht vor Bereichanfang liegen
9210Datum liegt nicht in der Zukunft
9210Keine gültige Kontoverbindung des Kunden
+ + +## c) Bankparameterdaten + + +### . Format + +Name: + +Bestand terminierter SEPA-Firmensammellastschriften Para- +meter + +Typ: + +Segment + +Segmentart: + +Geschäftsvorfall + +Kennung: + +HIBMBS + +Bezugssegment: + +HKVVB + +Version: + +1 + +Sender: + +Kreditinstitut + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Bestand terminierter SEPA- Firmensammellast- schriften1DEGM1
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
510		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + +# C.10.3.3.2.4 Löschung terminierter SEPA-Firmensammellastschriften + +Realisierung Bank: +optional + +Realisierung Kunde: optional + + +## a) Kundenauftrag + + +### . Beschreibung + +Die zu löschende SEPA-Firmensammellastschrift wird über die Auftragsidentifikation +identifiziert. Diese wird dem Kunden bei der Einreichung oder beim Abruf des Be- +standes mitgeteilt. Neben der Auftragsidentifikation müssen weitere Daten der +SEPA-Firmensammellastschrift eingestellt werden, um kreditinstitutsseitige Plausibi- +litätsprüfungen zu ermöglichen. + + +![](figures/230.1) + + +Dieser Geschäftsvorfall darf vom Kreditinstitut nur angeboten wer- +den, wenn es eine Auftragsidentifikation unterstützt, da ansonsten +die Identifikation der zu löschenden Überweisung nicht möglich ist. + +Zu löschende terminierte Aufträge liegen immer in der Zukunft. Eine minimale Vor- +laufzeit für die Einreichung des Löschauftrags ist nicht vorgesehen. Es können je- +doch nur Aufträge gelöscht werden, die auch im Bestand aufgeführt werden. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Terminierte SEPA-Firmensammellastschrift löschen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKBML
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Auftragsidentifikati- on1DEan.99M1
3Kontoverbindung international1DEGkti#M1
4Einreichungsdatum1DEdat#M1
5Ausführungsdatum1DEdat#M1
6Anzahl der Aufträge1DEnum..6M1
7Summe der Beträ- ge2DEGbtg#M1
+ + +### . Belegungsrichtlinien + + +### Kontoverbindung international + +IBAN und BIC müssen der IBAN in CreditorAccount bzw. der +BIC in CreditorAgent entsprechen. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 511
+ + +## Ausführungsdatum + +Das Ausführungsdatum entspricht dem Feld RequestedCollectionDate . + + +## Anzahl der Aufträge + +Die Anzahl der Aufträge entspricht dem Feld NumberOfTransactions . + +Summe der Beträge + +Die Summe der Beträge entspricht der ControlSum . + + +## b) Kreditinstitutsrückmeldung + + +## . Beschreibung + +Es werden keine Datensegmente zurückgemeldet. + + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag zur Löschung vorgemerkt
0020Auftrag gelöscht
9010Löschung nicht mehr möglich, da Auftrag bereits zur Löschung vorgemerkt
9010Auftragsidentifikation stimmt nicht mit Auftragsdaten überein
9210Auftrag existiert nicht bzw. wurde bereits ausgeführt
+ + +## c) Bankparameterdaten + + +### . Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + +### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Terminierte SEPA-Firmensammellastschrift löschen Parame- ter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIBMLS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
512		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + +# C.10.3.4 Sonderformen von SEPA-Sammelaufträgen + + +## C.10.3.4.1 Sammeleilzahlung (Urgent Payment) + +Realisierung Bank: +optional + +Realisierung Kunde: +optional + + +### a) Kundenauftrag + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Sammeleilzahlung einreichen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKCMU
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3Summenfeld1DEGbtg#C1M: „Summenfeld benötigt“ (BPD) = „J“ O: sonst
4Einzelbuchung ge- wünscht1DEjn#C1O: ,,Einzelbuchung erlaubt" (BPD) = „J“ N: sonst
5SEPA Descriptor1DEan.256M1
6SEPA pain messa- ge1DEbin..M1
+ + +### . Belegungsrichtlinien + + +#### Kontoverbindung international + +IBAN und BIC müssen der IBAN in DebtorAccount bzw. der +BIC in DebtorAgent entsprechen + + +#### SEPA pain message + +Erlaubtes „SEPA Überweisung Kunde-Bank"-Schema It. HISPAS. + +Es gelten die Festlegungen zu Eilzahlungen unter Verwendung des pain.001- +Formats laut Anlage 3 des DFÜ-Abkommens. [DFÜ-Abkommen]. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 513
+ + +In das Mussfeld RequestedExecutionDate ist der 1999-01-01 ein- +zustellen. + + +![](figures/233.1) + + +Für nicht terminierte Aufträge darf dem Kunden kein Eingabefeld zur +Eingabe eines Termins angeboten werden. + + +![](figures/233.2) + + +Enthält das Feld RequestedExecutionDate bei nicht +terminierten Aufträgen einen anderen Wert als „1999-01-01“ so ist +der Auftrag mit der Rückmeldung „9150 - Ausführungsdatum darf +nicht belegt werden“ abzulehnen. + + +![](figures/233.3) + + +Wird die SEPA-pain-message aus einer fremden Quelle importiert, +so ist darauf zu achten, dass ein eventuell abweichendes Datum im +Feld RequestedExecutionDate auf den Wert „1999- +01-01“ geändert wird. + + +## b) Kreditinstitutsrückmeldung + + +### . Beschreibung + +Es werden keine Datensegmente zurückgemeldet. + + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + +s. Einzelüberweisung. Zusätzlich gelten: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
3210Auftrag angenommen, fehlerhafte Einzelpositionen
3220Auftrag ausgeführt, fehlerhafte Einzelpositionen
9130SEPA-Nachrichtenformat ungültig
9210Sammelauftrag wurde abgelehnt, da Disposition fehlerhaft
9210Ausführungsdatum hier nicht zugelassen
9220Einzelauftrag Nr. x wurde aufgrund eines Fehlers nicht ausgeführt
+ + +### c) Bankparameterdaten + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Sammeleilzahlung Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HICMUS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 514Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Samme- leilzahlung1DEGM1
+ + +# C.10.4C-Transaktionen + + +## C.10.4.1 Auftragsdetails für C-Transaktionen + +Der Kunde ruft zu einer Auftragsidentifikation, die er im Rahmen der SEPA-Sammel- +Bestandsabfrage erhalten hat, eine Liste der Referenzen von Einzelaufträgen ab, für +die das Auslösen einer C-Transaktion (,,C" steht hierbei fur Cancellation) mit Hilfe +des Geschäftsvorfalls „Auslösen von C-Transaktionen“ möglich ist. + + +![](figures/234.1) + + +Wenn ein Kreditinstitut diesen Geschäftsvorfall anbietet, +muss es die Auftragsidentifikation zwingend unterstützen. + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +## a) Kundenauftrag + +Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Auftragsdetails für C-Transaktionen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKCTD
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Auftragsidentifikati- on1DEan..99M1
3Kontoverbindung international1DEGkti#M1
4Unterstützte SEPA pain messages1DEGM1
5Maximale Anzahl Einträge1DEnum..4C1O: ,,Eingabe Anzahl Ein- träge erlaubt“ (BPD) = „J“ N: sonst
6Aufsetzpunkt1DEan..35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle
SEPA-Zahlungsverkehr		Stand: 07.08.2015Seite: 515
+ + +## b) Kreditinstitutsrückmeldung + + +### Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Auftragsdetails für C-Transaktionen rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HICTD
Bezugssegment:HKCTD
Version:1
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3SEPA Descriptor1DEan256M1
4SEPA pain messa- ge1DEbinM1
5Auftragsidentifikati- on1DEan..99M1
6Liste derInformatio- nen zur Referenzen1DEGM1n
+ + +## Belegungsrichtlinien + +SEPA pain message + +,SEPA Überweisung Kunde-Bank"- bzw. ,,SEPA Lastschrift Kunde-Bank"-Schema It. +HICTDS. + + +## Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
9xxxAuftrag kann nicht per R-Code bearbeitet werden
9210Keine gültige IBAN des Kunden
+ + +## c) Bankparameterdaten + +Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Auftragsdetails für C-Transaktionen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HICTDS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
516		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Auf- tragsdetails für C- Transaktionen1DEGM1
+ + +# C.10.4.2 Auslösen von C-Transaktionen + +Der Kunde möchte C-Transaktionen (,,C" steht hierbei für Cancellation) für eine oder +mehrere Referenzen auslösen, die er ggf. über den Geschäftsvorfall ,,Auftragsdetails +für C-Transaktionen" ermittelt hat. Hierzu enthalt der Kundenauftrag eine entspre- +chendes ListeFeld, in welches die betroffenen Referenzen eingetragen sindwerden. +Das Kreditinstitut entscheidet, auf welche Weise je nach aktuellem Status die Rück- +holung erfolgen kann. + +Über eine erneute Bestandsabfrage und dem dort enthaltenen Element ,,Status +SEPA-Aufträge" kann ein Kunde die Information (konkret: ,C-Transaktion wurde +veranlasst") erhalten. + + +![](figures/236.1) + + +Wenn ein Kreditinstitut diesen Geschäftsvorfall anbietet, +muss es die Auftragsidentifikation zwingend unterstützen. + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +## a) Kundenauftrag + +Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Auslösen von C-Transaktionen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKCTA
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Auftragsidentifikati- on1DEan..99M1
3Kontoverbindung international1DEGkti#M1
4ReferenzListe der Referenzen11DED EGan..99OMn4
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 517
+ + +## b) Kreditinstitutsrückmeldung + +Es werden keine Kreditinstitutssegmente zurückgemeldet + + +### Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010R-Transaktion zur Ausführung vorgemerkt
9210Keine gültige IBAN des Kunden
+ + +## c) Bankparameterdaten + +Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Auslösen von C-Transaktionen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HICTAS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Auslö- sen von C- Transaktionen1DEGM1
+ + +# C.10.4.3 SEPA-Statusreport + +Der Kunde ruft zu einer Auftragsidentifikation oder einem Zeitraum SEPA- +Statusreports ab. + +Realisierung Bank: +optional + +Realisierung Kunde: optional + + +## a) Kundenauftrag + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Format
Name:SEPA-Statusreport
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKSSR
Bezugssegment:-
Version:1
Sender:Kunde
+ + +![Nr. Name Ver- sion Typ For- mat Län- ge Sta- tus An- zahl Restriktionen](figures/237.1) + + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 518Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Segmentkopf1DEGM1
2Auftragsidentifikati- on1DEan..99M1
3Kontoverbindung international1DEGkti#M1
4Von Datum1DEdat#C1O: „Zeitraum möglich“ (BPD) = ,,J" N: sonst
5Bis Datum1DEdat#C1O: „Zeitraum möglich“ (BPD) = ,J" N: sonst
6Unterstützte SEPA pain messages1DEGM1
7Maximale Anzahl Einträge1DEnum..4C1O: ,,Eingabe Anzahl Ein- träge erlaubt“ (BPD) = ,J“ N: sonst
8Aufsetzpunkt1DEan..35C1M: vom Institut wurde ein Aufsetzpunkt rückgemeldet N: sonst
+ + +## b) Kreditinstitutsrückmeldung + + +### Format + +Name: +SEPA-Statusreport rückmelden +Typ: +Segment +Segmentart: +Geschäftsvorfall +Kennung: +HISSR +Bezugssegment: +HKSSR +Version: +1 +Anzahl: +n +Sender: +Kreditinstitut + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3SEPA Descriptor1DEan256M1
4SEPA pain messa- ge1DEbinM1
5Auftragsidentifikati- on1DEan..99O1
+ + +### Belegungsrichtlinien + + +## SEPA pain message + +,SEPA Statusreport Kunde-Bank"-Schema It. HISSRS. Mögliche pain.002 messa- +ges sind der Anlage 3 des DFU-Abkommens +zu entnehmen (vgl. [DFU- +Abkommen1). + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 519
+ + +## Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
9210Keine gültige IBAN des Kunden
+ + +## c) Bankparameterdaten + +Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:SEPA-Statusreport Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HISSRS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter SEPA- Statusreport1DEGM1
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
520		Stand: 07.08.2015Kapitel: Geschäftsvorfälle
Abschnitt: SEPA-Zahlungsverkehr
+ + +### C.10.5SEPA Card Clearing Nachricht einreichen + +Im Normalfall werden electronic cash-Kartenzahlungen durch den Netzbetreiber im +Service-RZ-Verfahren bei der Zentralstelle des das Händlerkonto führenden Kredit- +instituts eingereicht. Im Gegensatz dazu dient dieser Geschäftsvorfall dazu, Karten- +zahlungen durch den Händler als SCC pain message (derzeit in der Version +pain.008.002.04) selbst einzureichen bzw. freizugeben. + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +### a) Kundenauftrag + +Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:SEPA Card Clearing Nachricht einreichen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKSCC
Bezugssegment:-
Version:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Kontoverbindung international1DEGkti#M1
3Summenfeld1DEGbtg#C1M: „Summenfeld benötigt“ (BPD) = „J" O: sonst
4SEPA Descriptor1DEan..256M1
5SEPA pain messa- ge1DEbinM1
+ + +## Belegungsrichtlinien + +Kontoverbindung international + +IBAN und BIC müssen der IBAN in CreditorAccount bzw. der +BIC in CreditorAgent entsprechen. + + +### SEPA pain message + +Erlaubtes SCC-Schema lt. HISCCS. Als LocalInstrumentSEPACode + ist lediglich CARD für SEPA Card Clearing erlaubt. In das Muss- +feld RequestedCollectionDate ist das aktuelle Tagesdatum einzu- +stellen. Generell gelten die technischen Vorgaben zum Einreichen von Umsätzen im +SCC-Format [SCC]. + + +## b) Kreditinstitutsrückmeldung + + +### Beschreibung + +Es werden keine Datensegmente zurückgemeldet. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: C
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Geschäftsvorfälle SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 521
+ + +## Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
0020Auftrag zur Ausführung vorgemerkt
3030Datum ist kein Bankgeschäftstag. Der Auftrag wird ausgeführt am
9210Mindestzeitraum bis zum Ausführungstermin überschritten
9210Datum liegt zu weit in der Zukunft
9210Datum ist kein Buchungstag
+ + +## c) Bankparameterdaten + + +### Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:SEPA Card Clearing Nachricht einreichen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HISCCS
Bezugssegment:HKVVB
Version:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter SEPA Card Clearing Nachricht einrei- chen1DEGM1
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
522		Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + +# D. DATA DICTIONARY + +A + + +## Abholung möglich J/N + +Gibt an, ob ein Kontoauszug erneut angefordert werden kann. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +## Ablaufdatum + +Endetermin (z.B. einer Geldanlage) + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dat
Länge:#
Version:1
+ + +## Abrechnungswährung + +Währung, in der Wertpapierpreise, -kurse, -limit oder -dividende angegeben +werden (entspricht z.B. WM GD 172). + +Es bleibt dem Kreditinstitut überlassen, ob es lediglich die Wahl zwischen +der Landeswährung und Euro vorsieht. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:cur
Länge:#
Version:1
+ + +## Abrechnungswährung Euro erlaubt + +Kennzeichen dafür, ob Euro als Abrechnungswährung erlaubt ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +## Abrechnungswährung Landeswährung erlaubt + +Kennzeichen dafür, ob die Landeswährung als Abrechnungswährung erlaubt +ist. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand:
07.08.2015		Seite: 523
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +## Abweichende Geschäftsstelle + +Bezeichnung der abweichenden Geschäftsstelle für die Lieferung von be- +stellten Artikeln (Sorten oder Karten), falls als Auslieferungsart ,Bereitlegung +in einer anderen Geschäftsstelle“ gewählt wurde. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:1
+ + +## Abweichende Lieferadresse + +Abweichende Zieladresse für die Lieferung von bestellten Artikeln (Sorten +oder Karten), falls als Auslieferungsart „Zusendung“ gewählt wurde. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:addr
Länge:#
Version:1
+ + +## Abweichender Betrag + +Vom Ursprungsauftrag abweichender Betrag. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:btg
Länge:#
Version:2
+ + +## Abweichender Betrag erlaubt + +Kennzeichen dafür, ob im Kundenauftrag die Einstellung eines vom Ur- +sprungsauftrag abweichenden Betrages erlaubt ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +## Abweichendes Ausbuchungskonto erlaubt + +Kennzeichen dafür, ob vom Kunden ein vom Referenzkonto abweichendes +Konto für die Ausbuchung (z.B. von Festgeldern) gewählt werden darf. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +# Abweichendes Verrechnungskonto erlaubt + +Kennzeichen dafür, ob im Format MT 502 im Feld B2:97A: ein von den De- +potstammdaten abweichendes Geldkonto angegeben werden darf und ob +dieses nur intern (beim depotführenden Institut) oder auch extern (bei Dritt- +institut) erlaubt ist. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
524		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + +## Codierung: + +0: +bei Kauf: nicht erlaubt +bei Verkauf: nicht erlaubt + +1: +bei Kauf: nicht erlaubt +bei Verkauf: intern + +2: +bei Kauf: nicht erlaubt +bei Verkauf: intern und extern + +3: +bei Kauf: intern +bei Verkauf: nicht erlaubt + +4: +bei Kauf: intern +bei Verkauf: intern + +5: +bei Kauf: intern +bei Verkauf: intern und extern + +6: +bei Kauf: intern und extern +bei Verkauf: nicht erlaubt + +7: +bei Kauf: intern und extern +bei Verkauf: intern + +8: +bei Kauf: intern und extern +bei Verkauf: intern und extern + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:2
+ + +## Abweichendes Zinsgutschriftkonto erlaubt + +Kennzeichen dafür, ob vom Kunden ein vom Referenzkonto abweichendes +Konto für Zinsgutschriften (z.B. von Festgeldern) gewählt werden darf. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +## Adressaufdruck + +Kennzeichen dafür, ob der Kunde einen Adressaufdruck auf seinen For- +mularen wünscht. + +Die für den Adressaufdruck notwendigen Daten werden den kreditinstituts- +seitigen Verarbeitungssystemen entnommen. Eine Änderung dieser Daten +durch den Kunden ist nicht möglich. + +Für welche Formularcodes der Adressaufdruck möglich ist, ist in den BPD +angegeben. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +### Adressaufdruck möglich + +Kennzeichen dafür, ob der Adressaufdruck für ein bestimmtes Formular +möglich ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +## Adresse + +Angaben zur Adresse einer natürlichen Person. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 525
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Formatkennung:addr
Länge:#
Version:2
+ + +# Adressdaten + +Angaben zu einer Adresse. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Adresstyp2DEcode1M11, 2, 3
2Straße2DEan.35O1
3Hausnummer2DEan.10O1
4Postfach2DEan..10O1
5PLZ1DEan.10M1
6Ort1DEan.35M1
7Ausländischer Postcode1DEan.2O1
8Länderkennzei- chen1DEctr#O1
9Telefonnummer dienstlich1DEan..35O1
10Telefonnummer privat1DEan..35O1
11Telefax-Nummer1DEan..35O1
12Email-Adresse1DEan.35O1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +## Adresstyp + +Kennzeichen dafür, ob es sich um eine Wohnadresse oder Postanschrift +handelt. + +Codierung: + +1: Privatadresse + +2: Versandadresse + +3: Geschäftsadresse + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:2
+ + +### Aktueller Bonussatz + +Bonussatz in Prozent. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:wrt
Länge:#
Version:1
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
526		Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + +# Alle Depots + +Kennzeichen dafür, ob die Abfrage über alle Depots des Kunden beim jewei- +ligen Kreditinstitut gilt, für die er eine Berechtigung besitzt. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +# Alle Dokumente + +Gibt an, in welchem Umfang eine globale Abfrage von Dokumenten beant- +wortet werden soll. + +Codierung: + +1= alle Dokumente + +2= nur aktuelle Dokument + +Typ: +DE + +Format: +code + +Länge: +1 + +Version: + +1 + + +# Alle Dokumente erlaubt + +Gibt an, ob eine globale Abholung von Dokumenten durch den Kunden er- +laubt ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:in
Länge:#
Version:1
+ + +# Alle Institute + +Kennzeichen, ob eine Abfrage bei allen Instituten (laut Liste in BPD) stattfin- +den soll.. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +# Alle Institute erlaubt + +Kennzeichen, ob eine Abfrage bei allen Instituten gleichzeitig erlaubt ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +# Alle Konten + +Mit dieser Option kann gewählt werden, ob die angeforderten Informationen +(z.B. Salden, Umsätze) nur zu dem angegebenen oder zu allen Anlagekon- +ten des Kunden, für die er eine Zugriffsberechtigung besitzt, zurückgemeldet +werden sollen. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 527
+ + + + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +## Alle Konten erlaubt + +Kennzeichen dafür, ob die Belegung des Feldes ,,Alle Konten" im Kunden- +auftrag zugelassen ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +## Angaben institutsverwalteter Auftrag + +Angaben zum institutsverwalteten Auftrag. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Art des insti- tutsverwalteten Auftrags1DEcode.2M11-10
2Kontoprodukt- bezeichnung1DEan..30O1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +## Angaben zu Empfängerkonten + +Angaben zu Empfängerkonten. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Kontoverbin- dung internatio- nal Empfänger1DEGkti#M1
2Name 1 Emp- fänger1DEan.35C1M: falls Kontoverbindung im gleichen Institut O: sonst
3Name 2 Emp- fänger1DEan..35C1O: falls ,,Name Empfänger 1“ belegt N: sonst
4Kontoart1DEnum..2O1
5Kontoprodukt- bezeichnung1DEan..30O1
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
528		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + +
Format:
Länge:
Version:1
+ + +# Angaben zur Wertstellung + +Datum der Wertstellung des Emissionsgeschäfts inkl. eventueller Zusätze +(z.B. ,,voraussichtlich“). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:1
+ + +## Anlagebetrag + +Betrag, auf den eine Geldanlage lautet. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:btg
Länge:#
Version:1
+ + +## Anlagebetrag bis + +Obergrenze des Betragsintervalls für den Anlagebetrag. Bei einem nach +oben offenen Intervall ist das DE nicht zu belegen. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:btg
Länge:#
Version:1
+ + +## Anlagebetrag bis, Währung + +Währung der Obergrenze des Betragsintervalls für den Anlagebetrag. Bei ei- +nem nach oben offenen Intervall ist das DE nicht zu belegen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:cur
Länge:#
Version:1
+ + +## Anlagebetrag bis, Wert + +Wert der Obergrenze des Betragsintervalls für den Anlagebetrag. Bei einem +nach oben offenen Intervall ist das DE nicht zu belegen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:wrt
Länge:#
Version:1
+ + +## Anlagebetrag neu + +Betrag, der für die nächste Anlageperiode gültig sein soll. Bei einer Erhö- +hung des Anlagebetrages wird das bei der Festgeldneuanlage angegebene +Belastungskonto bzw. bei einer Verminderung das Ausbuchungskonto her- +angezogen. + +Typ: + +DEG + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 529
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:btg
Länge:#
Version:1
+ + +## Anlagebetrag von + +Untergrenze des Betragsintervalls für den Anlagebetrag. Der jeweils nied- +rigste angegebene Betragswert zu einer Laufzeit stellt den Mindest- +anlagebetrag dar. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:btg
Länge:#
Version:1
+ + +## Anlagebetrag von, Währung + +Währung der Untergrenze des Betragsintervalls für den Anlagebetrag. Der +jeweils niedrigste angegebene Betragswert zu einer Laufzeit stellt den Min- +destanlagebetrag dar. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:cur
Länge:#
Version:1
+ + +## Anlagebetrag von, Wert + +Wert der Untergrenze des Betragsintervalls für den Anlagebetrag. Der je- +weils niedrigste angegebene Betragswert zu einer Laufzeit stellt den Min- +destanlagebetrag dar. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:wrt
Länge:#
Version:1
+ + +## Anlagedatum + +Datum, an dem der Startzeitpunkt der Anlage terminiert ist. + +In der Regel ist das Anlagedatum das Datum, zu dem der Abschluss und die +Valutierung der Festgeldanlage erfolgt, wenn der Anlageauftrag zu diesem +Zeitpunkt im Kreditinstitut eingehen würde. Nicht-Buchungstage sind hierbei +zu berücksichtigen. + +Die Laufzeit, die sich aus Anlage- und Ablaufdatum errechnet, hat dabei mit +der in den Festgeldkonditionen vorgegebenen Zinsmethode zu korrespondie- +ren. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dat
Länge:#
Version:1
+ + +## Anlagekonto + +Kontoverbindung des Anlagekontos. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
530		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:ktv
Länge:#
Version:3
+ + +# Anlagekonto alt + +Bisheriges Anlagekonto, das aus Zuordnungsgründen mit dem neu vergebe- +nen Anlagekonto mitgeteilt werden muss. Dies ist z.B. erforderlich, wenn z.B. +die Änderung eines Auftrags bankseitig durch eine Löschung und Neuein- +richtung realisiert wird. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:ktv
Länge:#
Version:3
+ + +## Anrede + +Kodierte Anrede als Teil der Personendaten. + +Codierung: + +0: keine Anrede + +1: Herr + +2: Herren + +3: Frau + +4: Fräulein + +5: Herr und Frau + +6: Firma + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:2
+ + +## Anzahl + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:4
Version:1
+ + +# Anzahl Aussetzungen + +Anzahl der gewünschten Aussetzungen eines Dauerauftrags. Die Angabe +der Anzahl Aussetzungen schließt die Angabe „Aussetzen bis“ aus. + + +## Beispiel: + +Der Dauerauftrag soll letztmalig am 1.6. ausgeführt werden. Die Ausführung +soll zum 1.10. wiederaufgenommen werden: + +Aussetzen von: 19960701 + +Anzahl Aussetzungen: 3 + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Data Dictionary
SEPA-Zahlungsverkehr		Stand:
07.08.2015		Seite: 531
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..2
Version:1
+ + +# Anzahl der Aufträge + +Anzahl der Aufträge. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..5
Version:1
+ + +# Anzahl reservierter Verwendungszweckstellen + +Anzahl der Stellen im SEPA Verwendungszweck (CreditorReferenceInforma- +tionSCT, insgesamt 4 x 35 = 140 Stellen), die für interne Verwendung - z. B. +Andrucken von Datum, Uhrzeit und verwendeter TAN - durch das Institut re- +serviert sind. Diese Stellen dürfen vom Kundenprodukt nicht für andereZwe- +cke verwendet werden. Die Anzahl wird vom Ende des letzten SEPA- +Elementes aus gezählt und darf den Wert 35 nicht überschreiten. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..2
Version:1
+ + +# Anzahl Signaturen mindestens + +Mindestanzahl der Signaturen, die für einen Geschäftsvorfall als erforderlich +definiert ist. + +Vom Kreditinstitut wird immer die Minimalanforderung an einen Geschäfts- +vorfall mitgeteilt, d.h. '0', wenn der Geschäftsvorfall auch über den anonymen +Zugang angeboten wird, ansonsten mindestens '1', da Aufträge von Kunden +immer signiert werden müssen. + +Die für Kunden jeweils genaue Angabe der Signaturanzahl ergibt sich in den +UPD aus dem DE ,,Anzahl benötigter Signaturen“. Dabei muss die in den +UPD angegebene Signaturanzahl größer oder gleich der in den BPD ange- +gebene Anzahl sein. Für Institute, die keine UPD unterstützen, bedeutet +dies, dass der Eintrag '0' in den BPD nur für Nichtkunden gilt und für Kunden +als 'mindestens 1' zu interpretieren ist. + +Der Wert gilt für alle Signaturverfahren. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:1
Version:1
+ + +# Anzahl terminierter Änderungen + +Maximale Anzahl terminierter Änderungen pro Dauerauftrag. + +Beispiele: + +0: Terminierte Änderungen sind nicht erlaubt + +1: Pro Dauerauftrag ist eine terminierte Änderung erlaubt + +5: Pro Dauerauftrag sind 5 terminierte Änderungen erlaubt + +9: Keine Beschränkung + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
532		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:1
Version:1
+ + +![](figures/252.1) + + +Bei komplexen terminierten Änderungsaufträgen ist es sinn- +voll, dass der Kunde mit Hilfe des Geschäftsvorfalls „Dauer- +auftragsänderungsvormerkungen abrufen“ prüft, ob das Kre- +ditinstitut seinen Änderungswunsch korrekt umgesetzt hat. + + +![](figures/252.2) + + +Falls der Kundenwunsch nicht eindeutig aus dem Auftrag +hervorgeht bzw. zu Inkonsistenzen in der Dauerauftragsver- +waltung führt, kann das Kreditinstitut den Auftrag im Zweifel +ablehnen. Wenn das Kreditinstitut inkonsistente Aufträge +dennoch annehmen möchte, dann darf stets nur der aktuells- +te Auftrag angenommen werden. Die vorherigen müssen in +diesem Fall verworfen werden. + + +## Anzahl terminierter Aussetzungen + +Maximale Anzahl terminierter Aussetzungen pro Dauerauftrag (s. auch DE +„Anzahl terminierter Änderungen“). + +Bei einer terminierten Aussetzung kann der Kunde den Startzeitpunkt für die +Aussetzung wählen. Eine nicht-terminierte Aussetzung gilt immer ab sofort. + +Falls eine einzige terminierte Aussetzung erlaubt ist, überschreibt die Einga- +be einer weiteren terminierten Aussetzung einen vorher eingereichten Aus- +setzungsauftrag. + +Beispiele: + +0: Terminierte Aussetzungen sind nicht erlaubt + +1: Pro Dauerauftrag ist eine terminierte Aussetzung erlaubt + +5: Pro Dauerauftrag sind 5 terminierte Aussetzungen erlaubt + +9: Keine Beschränkung + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:1
Version:1
+ + +## Art der wichtigen Informationen + +Information über die Art der wichtigen Informationen bei Wertpapieren. + +Codierung: + +1: allgemeine wichtige Informationen (Hier können generelle aktuelle Infor- +mationen zum Wertpapiergeschäft abgefragt werden.) + +2: spezielle wichtige Informationen (Hier können aktuelle Informationen zu +den einzelnen Wertpapierkategorien abgefragt werden.) + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 533
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:2
+ + +### Art des Ausfuhrlimits + +Kennzeichen dafür, ob die Ausfuhr einer Währung Beschränkungen unter- +liegt. + +Codierung: + +0: Limit unbekannt + +1: Limit = angegebener Betrag + +2: Limit = 0 (Ein-/Ausfuhr verboten) + +3: keine Begrenzung + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:2
+ + +#### Art des Einfuhrlimits + +Kennzeichen dafür, ob die Einfuhr einer Währung Beschränkungen unter- +liegt. + +Codierung s. ,,Art des Ausfuhrlimits“ + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:2
+ + +#### Art des institutsverwalteten Auftrags + +Gibt an, um welche Art eines terminierten Auftrags es sich handelt. + +Codierung: + +1: +Terminierte Einzelüberweisung Inland + +2: +Terminierte Einzellastschrift Inland + +3: +Terminierte SEPA-Einzelüberweisung + +4: +Terminierte SEPA-Einzellastschrift + +5: +Terminierte SEPA-Firmeneinzellastschrift + +6: +Terminierte Sammelüberweisung Inland + +7: +Terminierte Sammellastschrift Inland + +8: +Terminierte SEPA-Sammelüberweisung + +9: +Terminierte SEPA-Sammellastschrift + +10: +Terminierte SEPA-Firmensammellastschrift + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
534		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:..2
Version:1
+ + +#### Art des Limits + +Art des Limits einer Wertpapierorder gemäß der S.W.I.F.T.-Codierung. Es ist +der jeweilige S.W.I.F.T.-Qualifier aus dem Feld B:22F:, Qualifier TOOR „Indi- +kator für Art des Limits“ anzugeben. + +Mögliche Werte: + +„MAKT“ = billigst (bei Kauf) bzw. bestens (bei Verkauf) +„LMTO“ = Limitierte Order +„STOP“ = Stop Buy-Order (bei Kauf) bzw. Stop Loss-Order (bei Verkauf) +„STLI“ = Stop-Limit + +,MTLO" = Market-to-Limit-Order (Teil der Order wird ausgeführt und der Rest +limitiert) (nur XETRA) + +oder ein institutsindividueller Code im Format an4, sofern sich dieser nicht +mit den oben genannten Codes abbilden lässt. + + + + + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:4
Version:1
Referenz:ISO 15022, :22F:, Qualifier TOOR
+ + +#### Art des Limits änderbar + +Kennzeichen dafür, ob kreditinstitutsseitig eine Änderung des Limits bei einer +Wertpapierorderänderung zulässig ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +#### Art des Zeitlimits + +Art des Zeitlimits einer Wertpapierorder gemäß der S.W.I.F.T.-Codierung. Es +ist der S.W.I.F.T.-Qualifier aus dem Feld B:22F:, Qualifier TILI „Indikator für +Zeitlimit" anzugeben. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:4
Version:1
+ + +#### Art des Zeitlimits änderbar + +Kennzeichen dafür, ob kreditinstitutsseitig eine Änderung des Zeitlimits bei +einer Wertpapierorderänderung zulässig ist. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 535
+ + + + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +### Aufbewahrungszeitraum + +Gibt an, bis wann Dokumente zum Abruf vorgehalten werden. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dat
Länge:#
Version:1
+ + +#### Aufsetzpunkt + +Information darüber, wie die Beantwortung des Kundenauftrags an einem +bestimmten Punkt kontrolliert beendet und aufgesetzt werden kann, falls die +Rückmeldung des Kreditinstituts nicht in einem einzigen Auftragssegment er- +folgen kann (s. [Formals]). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:1
+ + +#### Aufstellung Haben-/Bonuszinsen + +Beinhaltet die aktuell gültigen Haben- bzw Bonuszinssätze (sofern nicht in +den Informationen zu den verschiednene Kontoarten mitgeliefert). + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Habenszinsatz/ Bonuszinssatz1DEGOn
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +##### Aufstellung Sollzins + +Beinhaltet die aktuell gültigen Zinssatz je Kreditlinie für einen Kreditvertrag. + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Sollzinssatz1DEGOn
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +#### Aufstellung Überziehungen + +Beinhaltet gültige Soll- und Überziehungszinssätze und Überziehungsbeträ- +ge. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
536		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt:
SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Überziehungs- zinssätze1DEGOn
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +##### Auftrag änderbar + + + + + + + + + + + + + + + + + + + +
Typ:DE
Formatjn
Länge#
Version1
+ + +![](figures/256.1) + + +Sonderformen von Daueraufträgen dürfen zwar gelöscht, +jedoch nicht geändert werden. Dies ist im Geschäftsvorfall +Dauerauftragsänderung entsprechend zu berücksichtigen. + + +#### Auftrag aussetzbar + + + + + + + + + + + + + + + + + + + +
Typ:DE
Formatjn
Länge#
Version1
+ + +#### Auftrag löschbar + + + + + + + + + + + + + + + + + + + +
TypDE
Formatjn
Länge#
Version1
+ + +### Auftraggebername, AZV + +Name bzw. Firmenname des Auftraggebers und dessen Adresse, die bei ei- +nem Auftrag im Auslandszahlungsverkehr anzugeben sind. + +Die Anzahl der maximal erlaubten Eingabezeichen ergibt sich aus den BPD. +Es sollten nur Zeichen aus dem S.W.I.F.T.-Zeichensatz verwendet werden. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Data Dictionary
SEPA-Zahlungsverkehr		Stand:
07.08.2015		Seite: 537
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:.. 140
Version:1
+ + +# Auftraggebername, AZV kurz + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:.27
Version:1
+ + +# Auftragsbezogene Informationen + +Beliebige auftragsbezogene Daten, die das Kreditinstitut dem Kunden bei +Wertpapiertransaktionen im Freitext mitteilen kann (z.B. ausmachender Be- +trag, Wertpapierbezeichnung, falls die Order nur per WKN erfolgt ist, etc.). + +Das Kreditinstitut hat auch die Möglichkeit, vom Kunden ein erneutes Sen- +den zu verlangen. In diesem Fall kann dieses DE einen Text enthalten, der +vom Kunden bestätigt werden muss, um der Beratungs- bzw. Informa- +tionspflicht des Kreditinstituts nachzukommen. Dieser Text könnte z.B. lau- +ten: „Ich bestätige, dass ich die gesetzlichen Verkaufsunterlagen (Verkaufs- +prospekt und Vertragsbedingungen) zur Kenntnis genommen habe." + +Falls der Auftrag nicht ausgeführt - oder zumindest teilausgeführt - wurde, +darf das DE nicht belegt werden. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:txt
Länge:.2048
Version:1
+ + +## Auftragsfilter + +Filter zur Einschränkung der Auswahl der Aufträge anhand deren Status. Es +gilt eine Oder-Verknüpfung, d.h. es werden alle Aufträge, die mindestens ei- +nem der angegebenen Stati entsprechen, zurückgemeldet. + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Status1DEcode..2M1..91-11
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:3
+ + +![](figures/257.1) + + +Das Kundensystem sollte dem Kunden die Statuscodes auf- +bereitet anzeigen: z.B. Offene Aufträge (Codes 1, 2, 4 und +5), ausgeführte Order, abgerechnete Order und gestrichene +Order. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
538		Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + +# Auftragsfilter + +Filter zur Einschränkung der Auswahl der Aufträge anhand deren Status. Es +gilt eine Oder-Verknüpfung, d.h. es werden alle Aufträge, die mindestens ei- +nem der angegebenen Stati entsprechen, zurückgemeldet. + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Wertpapierorder- status-Wertpa- pierorderstatus33DEcode..2M1..91-1717
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:44
+ + +![](figures/258.1) + + +Das Kundensystem sollte dem Kunden die Statuscodes auf- +bereitet anzeigen: z.B. Offene Aufträge (Codes 1, 2, 4 und +5), ausgeführte Order, abgerechnete Order und gestrichene +Order. + + +# Auftragsidentifikation + +Eindeutiges Identifikationsmerkmal eines Auftrages (z.B. Dauerauftragsnum- +mer), das vom Kreditinstitut bei Auftragserteilung mitgeteilt wird. Falls das +Kreditinstitut keine Auftragsidentifikation vergeben und mitgeteilt hat, ist das +DE nicht zu belegen. + +Die Angabe der Auftragsidentifikation dient dazu, gezielt für einen bereits er- +teilten Auftrag etwas vorzunehmen, z.B. bei Änderung, Streichung, Löschung +oder Anzeige eines bestimmten Auftrags. + +Wird die Auftragsidentifikation nicht angegeben, so soll generell die Aktion +für alle erteilten Aufträge gelten, z.B. bei Orderanzeige. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..99
Version:1
+ + +# Auftragsidentifikation alt + +Bisherige Auftragsidentifikation, die aus Zuordnungsgründen mit der neu +vergebenen Auftragsidentifikation mitgeteilt werden muss. Dies ist z.B. erfor- +derlich, wenn z.B. die Änderung eines Auftrags bankseitig durch eine Lö- +schung und Neueinrichtung realisiert wird. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..99
Version:1
+ + +## Auftragsidentifikation erlaubt + +Kennzeichen dafür, ob der Kunde im Kundenauftrag eine Auftragsidentifika- +tion angeben darf, auf die sich die wichtigen Informationen beziehen. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 539
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +### Auftragsreferenz + +Enthält die Referenz auf einen eingereichten Auftrag. Sie wird z. B. bei einer +Willenserklärung des Kunden oder im TAN-Zwei-Schritt-Verfahren bei der +späteren Einreichung der zugehörigen TANs (mittels HKTAN bei TAN- +Prozess=2 bzw. 3) zur Referenzierung des Auftrags verwendet. + + +![](figures/259.1) + + +Da die Auftragsreferenz immer eindeutig ist, sollten Kun- +denprodukte diese als zentrale Referenzierung verwenden +und dem Kunden auch zusammen mit den Auftragsdaten +präsentieren bzw. für die Problemverfolgung leicht zugäng- +lich machen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:1
+ + +#### Ausbuchungskonto + +Konto, auf das bei Fälligkeit der Anlage der Ausbuchungsbetrag gutge- +schrieben werden soll. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:ktv
Länge:#
Version:3
+ + +#### Ausbuchungskonto + +Konto, auf das bei Fälligkeit der Anlage der Ausbuchungsbetrag gutge- +schrieben werden soll. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:kti
Länge:#
Version:4
+ + +#### Ausbuchungskonto änderbar + +Kennzeichen dafür, ob das Ausbuchungskonto einer Geldanlage geändert +werden darf. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +#### Ausfuhrlimit + +Betrag, bis zu dem die Ausfuhr einer Währung zulässig ist. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
540		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:btg
Länge:#
Version:3
+ + +### Ausführungsanzeige + +Ausführungsanzeige eines Wertpapierauftrags im Format MT 513 (s. [Daten- +formate]). + +Bei einer Fondsorder wird i.d.R. keine Ausführungsanzeige, sondern nur ei- +ne Wertpapierabrechnung gesendet. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:bin
Länge:..
Version:1
+ + +#### Ausführungsdatum + +Ausführungsdatum eines Auftrags (z.B. bei terminierten Überweisungen und +Daueraufträgen). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dat
Länge:#
Version:1
+ + +#### Ausführungstag + +Angabe des regelmäßigen Kalendertags der Ausführung eines Auftrags (z.B. +Dauerauftrag) bei monatlichem Turnus bzw. des regelmäßigen Wochentags +der Ausführung bei wöchentlichem Turnus. + +Es dürfen nur vom Kreditinstitut erlaubte Ausführungstage gemäß BPD an- +gegeben werden. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..2
Version:1
+ + +#### Ausführungstag änderbar + +Kennzeichen dafür, ob der Ausführungstag des Auftrags (z.B. Dauerauftrag) +durch den Kunden änderbar ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +#### Ausführungstage pro Monat + +Vom Kreditinstitut für Daueraufträge zugelassene Ausführungstage pro Mo- +nat. Erlaubt sind 00 (alle) oder 01 bis 30 oder 97 (Ultimo-2), 98 (Ultimo-1) +und 99 (Ultimo). Der 31. eines Monats ist als Ultimo (99) zu kodieren. + +Beispiel: 01101520259899 (Ausführung am 1., 10., 15., 20. und 25. jeden +Monats, sowie zum Ultimo und Ultimo-1 möglich) + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Data Dictionary
SEPA-Zahlungsverkehr		Stand: 07.08.2015Seite: 541
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dig
Länge:..64
Version:1
+ + +### Ausführungstage pro Woche + +Angabe der Ausführungstage pro Woche. Erlaubt sind 0 (täglich) oder 1 +(montags) bis 7 (sonntags). + +Beispiel: 12345 (Ausführung an allen Werktagen möglich) + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dig
Länge:..7
Version:1
+ + +#### Ausgabeaufschlag + +Ausgabeaufschlag eines Fonds in Prozent vom Anteilwert. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:wrt
Länge:#
Version:1
+ + +#### Ausgabepreis + +Preis, zu dem ein Fondsanteil erworben werden kann. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:rate
Länge:#
Version:2
+ + +#### Ausländischer Postcode + +Angabe der Postleitzahl in der Adresse. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:.2
Version:1
+ + +#### Auslieferung + +Information darüber, ob das vom Kunden bestellte Material (z.B. Vordrucke) +in der zuständigen Geschäftsstelle hinterlegt oder per Post zugesendet wer- +den sollen. + +Codierung: + +1: Bereitlegung in der Geschäftsstelle + +2: Zusendung per Post + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
542		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:2
+ + +### Auslieferungsart + +Information darüber, wie dem Kunden die von ihm bestellten Artikel (Sorten, +Reiseschecks oder Karten) ausgeliefert werden können. + +Falls im Kundenauftrag die Angabe zur Auslieferungsart unterbleibt, be- +stimmt das Kreditinstitut die Art der Auslieferung. + +Hinweis: Reiseschecks müssen in der Geschäftsstelle bereitgelegt werden, +da sie dort unterschrieben werden müssen. + +Codierung: + +1: Bereitlegung in der kontoführenden Geschäftsstelle + +2: Bereitlegung in einer anderen Geschäftsstelle + +3: Zusendung (kostenpflichtig) + +4: Zusendung (kostenfrei) + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:2
+ + +#### Aussetzen bis + +Datum, zu dem der Dauerauftrag das letzte Mal nicht ausgeführt werden soll. +Es muss sich um ein gültiges Ausführungsdatum im Sinne des angegebenen +Turnus handeln. + +Beispiel: Der Dauerauftrag soll letztmalig am 1.6. ausgeführt werden. Die +Ausführung soll zum 1.10. wiederaufgenommen werden: + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Aussetzen von:19960701
Aussetzen bis:19960901
Typ:DE
Format:dat
Länge:#
Version:1
+ + +##### Aussetzen von + +Datum der erstmaligen Aussetzung des Dauerauftrages, falls terminierte +Aussetzungen erlaubt sind (s. BPD). Es muss sich dabei um ein gültiges Da- +tum handeln, zu dem eine Ausführung stattfinden würde. Ist das DE nicht +eingestellt, so wird der Dauerauftrag erstmalig zum nächsten Ausführungs- +termin ausgesetzt. + +Falls die Terminierung von Aussetzungen nicht erlaubt ist, darf das DE nicht +belegt werden. In diesem Fall gilt für die Änderung automatisch der nächst- +mögliche Ausführungstermin. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 543
+ + + + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dat
Länge:#
Version:1
+ + +###### Aussetzung + +Informationen zur Aussetzung eines Dauerauftrags. + +Soll der Dauerauftrag nicht ausgesetzt, sondern zeitweise mit einem abwei- +chenden Betrag ausgeführt werden, dann ist der abweichende Betrag anzu- +geben. + +Beispiel: Der Dauerauftrag soll letztmalig am 1.6. zum Originalbetrag ausge- +führt werden. Die Ausführung soll zum 1.10. mit dem Originalbetrag wieder- +aufgenommen werden. Zwischenzeitlich wird der Dauerauftrag mit dem ab- +weichenden Betrag 200 EUR ausgeführt. + + + + + + + + + + + + + + + + + + + +
Datenelement:Wert:
Aussetzen von20020701
Aussetzen bis20020901
Abweichender Betragswert200 EUR
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Aussetzung jährlich wie- derkehrend1DEjn#M1
2Aussetzen von1DEdat#O1
3Aussetzen bis1DEdat#C1M: ,,Anzahl Aussetzun- gen" leer N: sonst
4Anzahl Ausset- zungen1DEnum..2C1M: ,Aussetzen bis“ leer N: sonst
5Abweichender Betrag2DEGbtg#C1O: ,,Abweichender Be- trag erlaubt“ (BPD) = „J“ N: sonst
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:3
+ + +####### Aussetzung jährlich wiederkehrend + +Kennzeichen dafür, ob die Aussetzung jährlich wiederkehrend ausgeführt +werden soll (z.B. jedes Jahr von Februar bis August). Andernfalls wird die +Aussetzung nur einmalig ausgeführt. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
544		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +####### Aussetzung jährlich wiederkehrend erlaubt + +Kennzeichen dafür, ob der Kunde auch jährlich wiederkehrende Dauerauf- +tragsaussetzungen (z.B. jedes Jahr von Februar bis August) eingeben darf. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +####### Aussetzungseingabe + +Eingabeart für die Aussetzung eines Dauerauftrags. + +Codierung: + +1: Aussetzung erlaubt mit Angabe des Endtermins + +2: Aussetzung erlaubt mit Angabe der Anzahl der Aussetzungen + +3: Aussetzung erlaubt mit beiden Möglichkeiten + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:2
+ + +####### Auszugsname 1 + +Sollte der Name, der auf dem Kontoauszug abgedruckt wird, vom Namen +des Kontoinhabers abweichen, so kann dieser im Feld Auszugsname einge- +stellt werden + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:1
+ + +####### Auszugsname 2 + +Zusätzliche Angaben zum Feld Auszugsname. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:1
+ + +####### Avalbetrag + + + + + + + + + + + + + + + + + + + + + + +
Avalbetrag.
Typ:DEG
Format:btg
Länge:#
Version:1
+ + +####### Avalprovision + +Avalprovision in Prozent p.a.. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Data Dictionary
SEPA-Zahlungsverkehr		Stand:
07.08.2015		Seite: 545
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:wrt
Länge:#
Version:
1
+ + +B + + +######## base64 kodiert + +Das Kreditinstitut hat anzugeben, ob es sich bei dem Inhalt des binären Da- +tenelements „Gebuchte Umsätze" um PDF-Format (base64 = ,N") oder +base64-kodiertes PDF-Format handelt (base64 = ,J") handelt. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +######### Bearbeitungspreis + +Preis für die Bearbeitung von Aufträgen. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:btg
Länge:#
Version:2
+ + +######### Befristet bis + +Falls eine Befristung vorliegt, beinhaltet dieses Feld das Befristungsdatum. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dat
Länge:#
Version:1
+ + +######### Befristung + +Gibt an, ob ein Vertrag befristet bzw. unbefristet ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +######### Begünstigter + +Name und Adresse eines vom Depotinhaber abweichenden Begünstigten, +zugunsten dessen ein Geschäft erfolgt. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:addr
Länge:#
Version:1
+ + +######### Begünstigter möglich + +Kennzeichen dafür, ob kundenseitig ein abweichender Begünstigter angege- +ben werden kann. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
546		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +######### Belastungskonto + +Kontokorrentkonto des Kunden, auf dem Verfügungen zugunsten der Anlage +(Rückzahlungen, Einzahlungen, sonstige Gutschriften und Belastungen) vor- +genommen werden. Das Belastungskonto muss bei demselben Kreditinstitut +wie das Anlagekonto geführt werden. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:ktv
Länge:#
Version:3
+ + +######### Belastungskonto änderbar + +Kennzeichen dafür, ob das Belastungskonto geändert werden kann. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +######### Bemerkungen + +Beliebige Informationen im Freitext zu dem angebotenen Produkt, z.B. Aus- +schüttungsinformationen (Thesaurierung oder Ausschüttung), Ausschüt- +tungs- und Steuertermine, Informationen zu einem Sparvertrag. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:txt
Länge:2048
Version:1
+ + +######### Bereitstellungsdatum + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dat
Länge:#
Version:1
+ + +######### Bereits verfügter Betrag + +Betrag, über den der Kunde im Augenblick der Saldenrückmeldung bereits +verfügt hat. Die Ermittlung des bereits verfügten Betrags kann institutsspezi- +fisch differieren. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:btg
Länge:#
Version:1
+ + +######### Berichtszeitraum + +Anhand des Berichtszeitraums informiert das Kreditinstitut den Kunden, für +welchen zeitlichen Rahmen z.B. Umsätze angefallen sind. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 547
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Startdatum1DEdat#M1
2Endedatum1DEdat#M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +########## Berichtszeitraum + +Anhand des Berichtszeitraums informiert das Kreditinstitut den Kunden, für +welchen zeitlichen Rahmen z.B. Umsätze angefallen sind. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Startdatum1DEdat#M1
2Endedatum1DEdat#O1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:2
+ + +########### Beschreibung + +Beschreibende Informationen. + + + + + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:1
+ + +########### Besondere Hinweise + +Hinweise des Kreditinstituts an den Kunden auf besondere Umstände, z.B. +Beratungsverzicht bei Zeichnung oder Prospekthaftung. + + +![](figures/267.1) + + +Da es sich hierbei um haftungsrelevante Informationen han- +deln kann, sollte der Inhalt dieses Feldes dem Kunden auf +jeden Fall zur Anzeige gebracht werden. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:txt
Länge:200
Version:1
+ + +######### Best-Execution-Börsenplatz + +Gibt den Best-Execution-Börsenplatz als MIC-Code an. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
548		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + +Typ: + +DE + + + + + + + + + + + + + + + +
Format:an
Länge:4
Version:1
+ + +######## Bestätigungscode + +Enthält einen zum Bestätigungstext passenden Wert, der bei Vorhandensein +als Basis für die Referenzierung im Zuge der Willenserklärung des Kunden +verwendet wird. + +Der Bestätigungscode wird vom Kreditinstitut vorgegeben und kann z. B. ein +Hashwert über den Bestätigungswert oder aber auch eine Zufallszahl sein. + +Der Bestätigungscode für sich besitzt nicht den Stellenwert einer Signatur. +Daher muss er vom Kundenprodukt auch nicht verifiziert werden, sondern +dient nur als eindeutiger Bezeichner anstelle des Original- +Bestätigungstextes. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:bin
Länge:."
Version:1
+ + +###### Bestätigungstext + +Enthält den Text, der mit Hilfe des Geschäftsvorfalls „Willenserklärung des +Kunden (HKWEK)“ bestätigt werden soll. + +Ist der BPD-Parameter „Bestätigungstext strukturiert“ mit „J“ belegt, so kön- +nen im Text folgende Formatsteuerzeichen enthalten sein, die kundenseitig +entsprechend zu interpretieren sind. Eine Kaskadierung von Steuerzeichen +ist nicht erlaubt. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
<br>Zeilenumbruch
<p>Neuer Absatz
<b> …</b>Fettdruck
<i> ...</i>Kursivdruck
<u> …</u>Unterstreichen
<ul> …</ul>Beginn / Ende Aufzählung
<ol> …</ol>Beginn / Ende Nummerierte Liste
<li> ...</li>Listenelement einer Aufzählung bzw. einer nummerierten Liste
<a href="..."> Text </a>Link
+ + +Ist der BPD-Parameter „Bestätigungstext strukturiert“ mit „N“ belegt, so wird +der Bestätigungstext als Fließtext dargestellt und etwa enthaltene Steuerzei- +chen werden nicht interpretiert. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 549
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..65535
Version:1
+ + +####### Bestätigungstext strukuriert + +Der BPD-Parameter gibt an, ob eine strukturierte Darstellung des Bestäti- +gungstextes (Formatsteuerzeichen siehe dort) erlaubt ist, oder der Inhalt des +Datenelementes „Bestätigungstext“ als FlieBtext dargestellt werden soll. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:1
Version:1
+ + +######## Bestehendes Anlagekonto erlaubt + +Kennzeichen dafür, ob die Neuanlage auf ein schon bestehendes Anlage- +konto möglich ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +####### Bestellkonditionen + +Anhand der Bestellkonditionen kann das Kreditinstitut angeben, auf welche +Weise der Kunde die Produkte bestellen kann, und wie hoch die Kosten für +den Kunden sind. Die Bestellkonditionen werden für jede Auslieferungsart +geliefert. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Konditionenver- sion1DEan.. 10M1
2Konditionenart2DEcode1M11, 2, 3
3Auslieferungsart2DEcode1M11, 2, 3, 4
4Kommission1DEwrt#O1
5Mindestkommis- sionsbetrag1DEGbtg#O1
6Bearbeitungs- preis2DEGbtg#O1
7Versandkosten- anteil1DEGbtg#O1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:2
+ + +####### Bestellkonditionen benötigt + +Kennzeichen dafür, ob der Kunde vor einer Bestellung mit Hilfe des Ge- +schäftsvorfalls „Sorten- und Reisescheckkonditionen" eine Bestellkondition +auswählen muss. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
550		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +######## Bestellung + +Angaben dafür, für welchen Betrag und gegebenenfalls in welchen Grobstü- +cken Sorten und Reiseschecks bestellt werden, falls eine automatische Stü- +ckelung möglich ist. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Gesamtbestell- betrag1DEGbtg#M1
2Stückelungs- möglichkeit2DEcode1C11,2,3 M: „Stücknennwert“ leer N: sonst
3Stücknennwert1DEwrt#C1M: „Stückelungsmög- lichkeit“ leer N: sonst
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:2
+ + +######### Betrag + +Monetärer Wert zusammen mit dem zugehörigen Währungskennzeichen +gemäß ISO 4217 (alphabetischer Code). + +Für den Wert des Betrags ist maximal die gemäß ISO 4217 gültige Anzahl +Nachkommastellen der jeweiligen Währung (z.B. 2 bei Euro) einzustellen. +Eine höhere Anzahl führt in der Regel zu einer entsprechenden Fehlermel- +dung und zur Ablehnung des Auftrags. Die maximale Stellenzahl kann even- +tuell nicht in allen Währungen verarbeitet werden, obwohl der Betrag syntak- +tisch korrekt definiert wurde. In diesem Fall kann der Auftrag mit einer ent- +sprechenden Meldung abgelehnt werden. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Formatkennung:btg
Länge:#
Version:2
+ + +#### Betrag änderbar + +Kennzeichen dafür, ob der Betrag eines Auftrags nachträglich durch den +Kunden änderbar ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +#### Betreff + +Thema einer Textnachricht (Betreffzeile). + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Data Dictionary
SEPA-Zahlungsverkehr		Stand: 07.08.2015Seite: 551
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:1
+ + +#### Betrefftext + + + + + + + + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..80
Version:1
+ + +##### Bewilligter Betrag + +Bewilligter Betrag des Darlehens. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:btg
Länge:#
Version:1
+ + +#### [Bezeichnung](file:///D:/Benutzerprofile/mindnich/Desktop/FinTS%2030%20Release%202015/HKKIF_7_V01.doc%23KennzeicheArtderZinsaufstellung) Gebühr oder Entgelt + +Bezeichnung einer Gebühr oder eines Entgelts. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:txt
Länge:.99
Version:1
+ + +##### Bezugsverhältnis + +Bezugsverhältnis von Optionsscheinen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:1
+ + +##### Bezugszeitpunkt + +Datum und ggf. Uhrzeit, auf die sich ein Dokument bezieht (z.B. Kontoum- +sätze vom 29.04.1999). + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
552		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:tsp
Länge:#
Version:1
+ + +BIC + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..11
Version:1
+ + +###### BIC Empfängerbank + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:.. 11
Version:1
+ + +#### BIC Konto + +BIC zum Konto zu dem der Auszug erstellt wird. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:.. 11
Version:1
+ + +#### Bis Datum + +Endedatum eines Zeitraums (s. [Formals], Kap. B.6.3). + +Durch die Eingabe von Von- und Bis-Datum kann ein Zeitraum eingegrenzt +werden, für den Informationseinträge vom Kreditinstitut rückzumelden sind. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dat
Länge:#
Version:1
+ + +##### Börsenplatz + +Börsenplatz codiert als „Market Identifier Code“ (MIC) gemäß ISO 10383 (s. +[Datenformate], Anlagen). Der MIC entspricht den ersten 4 Stellen des BIC +(,Bank Identifier Code"), der in den Wertpapiermitteilungen (WM-Gattungs- +datei in Tabelle Z 09) veröffentlicht wird. Zusätzlich kann „OTCO" angegeben +werden, wenn das Wertpapier außerbörslich gehandelt wird (z.B. Invest- +mentfonds). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:4
Version:1
+ + +#### Börsenplatzinformation + +Börsenplatz der Markteinführung eines Wertpapiers. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Data Dictionary SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 553
+ + +Das Institut kann die Börsenplätze auf diejenigen beschränken, an denen es +selbst Order ausführt. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Börsenplatz1DEan4M1
2Handelswährung1DEcur#M1
3Handelstyp1DEan.2O1
4Handelstyp XETRA2DEcode.2O110,20,30,40,50,60,70
5Kleinste handel- bare Einheit1DEwrt#O1
6Marktsegment Ausland1DEan.80O1
7Marktsegment In- land2DEcode1O91,2,3,4,5,6,7,9,D,E,F,G,H ,I,N,O
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:3
+ + +#### Branche + +Angabe der Branche eines Unternehmens, z.B. von Wertpapieremittenten. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:1
+ + +#### Briefanschrift + +Anschrift, an die Benachrichtigungen für das Konto gesandt werden. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:addr
Länge:#
Version:1
+ + +#### Briefkurs + +Verkaufskurs bei Sorten und Devisenbriefkurs der betreffenden Währung bei +Reiseschecks, der pro Standardeinheit angegeben wird. Bei EWU-Wäh- +rungen sind Brief- und Geldkurs identisch. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:rate
Länge:#
Version:1
+ + +##### Buchungszeitpunkt + +Datum und ggf. Uhrzeit, an dem ein Umsatz, Saldo etc. gebucht wurde bzw. +wird. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
554		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:tsp
Länge:#
Version:1
+ + +C + + +##### camt-Descriptor + +Der camt-Descriptor beschreibt Ort, Name und Version einer camt Schema- +Definition als URN. Die korrekte Bezeichnung des URN ist der Anlage 3 des +DFÜ-Abkommens zu entnehmen. [DFÜ-Abkommen] + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:.256
Version:1
+ + +##### camt-Umsätze gebucht + +Umsätze, die auf dem Kundenkonto erfolgt sind und zum Zeitpunkt des Kun- +denauftrags vom Kreditinstitut bereits gebucht wurden. + +Gebuchte camt-Umsätze werden als camt.052 message für Umsatzabfragen +bzw. camt.053 message für den elektronischen Kontoauszug (s. [Datenfor- +mate]) bereitgestellt und werden als transparentes Datenformat im Sinne von +FinTS transportiert. + +Für gebuchte Umsätze gelten folgende Ergänzungen: + +Pro Buchungstag ist genau eine camt.052 bzw. camt.053 message einzu- +stellen. Es existiert kein Zusammenhang zwischen dem elektronischen +camt.053-Auszug und dem Papierauszug. Falls das Kreditinstitut möchte, +kann es allerdings das LegalSequence-Number belegen. + +Es ist nur höchstens ein Anfangs- und Schlusssaldo je camt message er- +laubt. Durch einen Anfangs- und Schlusssaldo ist genau ein Buchungstag +definiert. Zwischensalden können beliebig verwendet werden (z.B. bei +Wechsel der Auszugsnummer innerhalb eines Buchungstages). Generell +sind immer komplette Buchungstage in eine camt message einzustellen. +Hiervon abweichend kann das Kreditinstitut optional in den Satz des aktuel- +len Tages die bis dahin gebuchten Umsätze einstellen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:bin
Länge:..
Version:1
+ + +##### Creditor änderbar + +Kennzeichen dafür, ob die Angaben zum Empfängers (Creditor ) ei- +nes SEPA-Dauerauftrags durch den Kunden nachträglich änderbar ist. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 555
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +##### CreditorAccount/Agent änderbar + +Kennzeichen dafür, ob die Kontoverbindung des Empfängers (CreditorAc- +count und CreditorAgent ) eines SEPA-Dauerauftrags +durch den Kunden änderbar ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +##### Code zur Identifizierung des Geschäfts + +Als String verbunden mit "+" (muss entwertet werden): Vierstelliger SWIFT- +Transaction-Code+GVC+ Optional: Primanota-Nr. (maximal 10-stellig)+ +DTA-Textschlüsselergänzung, falls darstellbar. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:1
+ + +###### CutOff-Zeit + +Uhrzeit bis zu welcher ein Auftrag beim Institut spätestens vorliegen muss, +damit er zur Ausführung noch berücksichtigt wird. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:tim
Länge:#
Version:1
+ + +D + + +####### Dateiname + +Gibt den Dateinamen an, unter dem das Dokument abgespeichert werden +soll. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..256
Version:1
+ + +####### Datum + +Datumsangabe, zur Bestimmung eines Zeitpunktes. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dat
Länge:#
Version:1
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
556		Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + +######## Datum Bestätigung/Ablehnung + +Wurde der Auftrag angenommen oder abgelehnt, so kann hier ferner das +Datum der Annahme bzw. Ablehnung eingestellt werden. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dat
Länge:#
Version:1
+ + +######### Datum der Erstellung + +Datum der Erstellung eines Kontoauszuges. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dat
Länge:#
Version:1
+ + +######### Datum der Übermittlung + +Datum der Übermittlung der Konditionen. Diese Angabe wird bei einem Auf- +trag zur Festgeldanlage zurückgemeldet und dient kreditinstitutsseitig zu In- +formationszwecken. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dat
Länge:#
Version:1
+ + +######### Datum Widerrufen + +Angabe des Datums, an dem der Auftrag widerrufen wurde. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dat
Länge:#
Version:1
+ + +######### Dauerauftragdetails + +Detailinformationen zu einem Dauerauftrag. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Erstmals aus- führen am2DEvdat#M1
2Zeiteinheit2DEcode1M1M, W
3Turnus1DEnum..2M1>0
4Ausführungstag1DEnum.2M1>0
5Letztmals aus- führen am2DEvdat#O1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 557
+ + + + + + + + + + + + + + + +
Format:
Länge:
Version:3
+ + +![](figures/277.1) + + +Die Errechnung möglicher Ausführungsdaten bzw. die Prü- +fung auf Gültigkeit des vom Kunden eingegebenen Datums +kann vom Kundenprodukt übernommen werden. + + +##### Dauereinzellastschriftdetails + +Detailinformationen zu einer Dauereinzellastschrift. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Erstmals aus- führen am2DEvdat#M1
2Zeiteinheit2DEcode1M1M, W
3Turnus1DEnum..2M1>0
4Ausfüh- rungstag1DEnum..2M1>0
5Letztmals aus- führen am2DEvdat#O1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +![](figures/277.2) + + +Die Errechnung möglicher Ausführungsdaten bzw. die Prü- +fung auf Gültigkeit des vom Kunden eingegebenen Datums +kann vom Kundenprodukt übernommen werden. + + +##### Depot + +Depotkontoverbindung des Kunden. + +Es ist zu beachten, dass Depotnummern wie Kontonummern auch führende +Nullen beinhalten können, die bankfachlich relevant sind und nicht abge- +schnitten werden dürfen. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:ktv
Länge:#
Version:3
+ + +##### Depot erforderlich + +Kennzeichen dafür, ob die Angabe des Depots im Kundenauftrag erforderlich +ist. Das Depot muss z.B. angegeben werden, wenn durch die Abfrage Kos- +ten verursacht werden (z.B. Abfrage von Realtime-Kursen). + +Typ: + +DEG + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
558		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +##### Depotaufstellung + +Depotaufstellung im S.W.I.F.T.-Format MT 535 bzw. 571 gemäß Spezifikati- +on in [Datenformate]. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:bin
Länge:..
Version:1
+ + +##### Depotbankgebühr + +Jährliche Depotbankgebühr in Prozent. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:wrt
Länge:#
Version:1
+ + +##### Depotwährung + +Währung der Wertpapiergattung (z.B. WM GD 171), bei Aktien „XXX“ +(Stück). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:cur
Länge:#
Version:1
+ + +##### Direkthandel-Depot + +Gibt an, ob es sich um ein Direkthandel-Depot handelt. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:in
Länge:#
Version:1
+ + +##### Dividende + +Die letzte gemäß Hauptversammlung ausgezahlte Dividende. Die Währung +entspricht der Abrechnungswährung. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:wrt
Länge:#
Version:1
+ + +##### Dokument + + + + + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:bin
Länge:..
Version:1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 559
+ + +###### Dokumentenart + +Bezeichnet die Art des Dokumentes, die auch im Kundenprodukt direkt an- +gezeigt werden kann. Die Liste der gültigen Dokumentenarten wird bei Be- +darf erweitert werden. + +Gültige Werte: + +Finanzdatenformat + +Kontoauszug + +Vermögensbericht + +Wertpapierabrechnung + +Allgemeine Informationen + + + + + + + + + + + + + + + +
Format:an
Länge:.30
Version:1
+ + +###### Dokumentgröße + +Größe eines Dokumentes in Byte. + + + + + + + + + + + + + + + +
Format:num
Länge:..10
Version:1
+ + +#### Dokument-ID + +Eindeutige Identifikationsnummer eines Dokumentes. + + + + + + + + + + + + + + + +
Format:id
Länge:#
Version:1
+ + +#### Dokument-ID + +Eindeutige Identifikationsnummer eines Dokumentes. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..256
Version:2
+ + +#### DTA-Datensatz + +Datenformat für Sammelüberweisungen und Sammellastschriften (s. [Daten- +formate]). + +Die Anzahl der maximal einzustellenden C-Sätze ergibt sich aus dem vom +Kreditinstitut mitgeteilten DE „Maximale Anzahl C-Sätze“. Es ist der +DTAUS0-Zeichensatz zu verwenden. + +Bei Sammelüberweisungen und -lastschriften darf das Feld A 11b („Ausfüh- +rungsdatum") nicht belegt werden (Es ist mit X'20' zu füllen). Bei terminierten + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
560		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + +Sammelüberweisungen/-lastschriften ist die Angabe eines Ausführungsda- +tums hingegen zulässig. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:bin
Länge:..
Version:1
+ + +#### DTAZV-Datensatz + +Datenformat für Zahlungsaufträge im Außenwirtschaftsverkehr (s. [Daten- +formate]). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:bin
Länge:..
Version:1
+ + +##### DTAZV Handbuch + +Gibt die Jahreszahl des den folgenden Parametern zugrunde liegenden +DTAZV Handbuches an. (s. [DTAZV]). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:4
Version:1
+ + +E + + +##### Early-Order-Frist bis + +Endedatum und ggf. -uhrzeit der Early-Order-Frist. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:tsp
Länge:#
Version:1
+ + +##### Early-Order-Frist bis, Erläuterung + +Erläuterung zur Early-Order-Frist, z.B. Early-Order-Incentives. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:txt
Länge:.80
Version:1
+ + +##### Eigene Rechnung + +Kennzeichen dafür, ob der Kunde bei einer Geldanlage auf eigene oder auf +fremde Rechnung handelt. Diese Angabe ist im Rahmen des Geldwäsche- +gesetzes relevant. Wird hier mit ,,Nein" (d.h. fremde Rechnung) geantwortet, +ist i.d.R. eine manuelle Nachbearbeitung des Auftrags im Institut notwendig. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 561
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +![](figures/281.1) + + +Das Kundenprodukt sollte in der Eingabemaske die folgende +Formulierung verwenden: + +Der/Die Kontoinhaber handelt/handeln für eigene Rechnung: + +☐ +ja + +☐ +nein + + +##### Einfuhrlimit + +Betrag, bis zu dem die Einfuhr einer Währung zulässig ist. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:btg
Länge:#
Version:3
+ + +#### Eingabe Anzahl Einträge erlaubt + +Kennzeichen dafür, ob die Belegung des Feldes ,,Maximale Anzahl Einträge“ +im Kundenauftrag zugelassen ist. Falls ja, kann das Kundenprodukt die An- +zahl der maximal rückzumeldenden Buchungspositionen beschränken. + +Über das DE „Eingabe Anzahl Einträge erlaubt“ legt das Kreditinstitut fest, ob +es kundenseitig möglich ist, bei Aufträgen die Anzahl von Einträgen in der +Kreditinstitutsantwort zu beschränken. Ist die Option nicht zugelassen, gelten +die syntaktischen Maximalwerte. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +#### Einheit der Effektennotiz + +Einheit der Effektennotiz (entspricht WM GD 440). + +Codierung: + +1: Stücknotiz + +2: Prozentnotiz + +3: Promille + +4: Notierung in Punkten + +9: Sonstiges + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:2
+ + +### Einlösungsart + +Art der Einlösung (gemäß WM GD 841). + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
562		Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + +### Codierung: + +1: keine Tilgung (ewige Rente) + +2: planmäßig gesamtfällig + +3: planmäßige Ratentilgung + +4: Tilgung am Stück (Mantel)/Teilrückzahlung (mit Nennwertänderung) + +5: planmäßige Annuitätentilgung durch Verlosung/Rückkauf (deaktiviert zum +10.07.2000) + +6: über Tilgungsfonds (Sinking Fund) + +7: über Rückkauffonds (Purchase F.) + +8: unregelmäßige Tilgung (Gummi-T.) + +9: Sonstiges + +A: Tilgung nur durch Rückkauf + +B: Annuitätentilgung am Stück (ohne Nennwertänderung) + +C: Laufzeit unbefristet, Auslosung, Kündigung oder Rückkauf möglich + +D: Tilgung am Stück in nicht im voraus bestimmbaren Beträgen bei gleich- +bleibendem Nennwert + +E: Tilgung am Stück in im voraus bestimmten Beträgen bei gleichbleibendem +Nennwert + +F: Keine Tilgung/interest-only Stücke + +G: Tilgung auf Depotbestände gemäß Tilgungsquote + +H: Laufzeit unbegrenzt + +J: Laufzeit begrenzt, genauer Fälligkeitstermin offen + + + + + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:2
Referenz:WM GD 841
+ + +#### Einlösungskurs + +Rücknahmepreis (gemäß WM GD 861), der bei Papieren mit einer Endfällig- +keit angegeben werden kann. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:wrt
Länge:#
Version:1
+ + +##### Einreichungsdatum + +Datum der Einreichung eines Auftrags(z.B. Feld A7 im DTA Datensatz). + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 563
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dat
Länge:#
Version:1
+ + +##### Einverständnis des Partners + +Bei gemeinschaftlicher steuerlicher Veranlagung des Kunden muss dieser +explizit mitteilen, dass er im Einverständnis des Partners handelt. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +##### Einzelbuchung erlaubt + +Über das DE „Einzelbuchung erlaubt" legt das Kreditinstitut fest, ob es mög- +lich ist, Sammelaufträge im Kontoauszug als Einzel- oder Sammelposten an- +zudrucken. Ist die Option nicht zugelassen, werden für Sammelaufträge im +Kontoauszug nur Sammelposten gedruckt. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +##### Einzelbuchung gewünscht + +Hat das Kreditinstitut die Option der Einzelbuchung bei Sammelaufträgen +zugelassen (vgl. DE ,,Einzelbuchung erlaubt"), so kann das Kundenprodukt +mitteilen, ob die Ausgabe von Einzelposten im Kontoauszug gewünscht ist +oder nicht. Wird das DE in einer Kundennachricht nicht gesendet, so werden +nur Sammelposten gedruckt. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +##### Einzelkontoabruf erlaubt + +Über das DE „Einzelkontoabruf erlaubt" legt das Kreditinstitut fest, ob es +möglich ist, einzelne Kontoverbindungen gezielt abzurufen oder ob nur alle +relevanten Konten insgesamt bereitgestellt werden. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +##### EKA Kontoverbindung + +Zu einem elektronischen Kontoauszug gehörige Kontoverbindung. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:kti
Länge:#
Version:1
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
564		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt:
SEPA-Zahlungsverkehr
+ + +###### Email-Adresse + +Adresse für Internet-Kommunikation. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:1
+ + +####### Emissionsdatum + +Datum, zu dem eine Wertpapieremission emittiert wird bzw. wurde. Bei Neu- +emissionen kann das Datum in der Zukunft liegen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dat
Länge:#
Version:1
+ + +####### Emissionspreis + +Preis einer Neuemission. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:btg
Länge:#
Version:3
+ + +####### Emissionspreis, Erläuterung + +Erläuterung Emissionspreis (z.B. „liegt noch nicht vor“, „voraussichtlich“). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:txt
Länge:..80
Version:1
+ + +####### Emissionsstatus + +Status der Emission. + +Codierung: + +1: bereits zugeteilte Emissionen + +2: laufende Emissionen (innerhalb der Zeichnungsfrist) + +3: Emission geschlossen, noch keine Zuteilung + +4: vorgesehene Emissionen (für die Zukunft geplant) + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:2
+ + +##### Emissionsvolumen + +Informationen zum Emissionsvolumen (z.B. geplante Stückzahl oder Betrag) +inkl. Erläuterungen. Der angegebene Wert gilt inklusive ,,Greenshoe". + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 565
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..50
Version:1
+ + +###### Emissionswährung + +Währung einer Neuemission. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:cur
Länge:#
Version:1
+ + +####### Emittent + +Emittent eines Wertpapiers (z.B. WM GD 240 bzw. 245). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:6
Version:1
+ + +####### Empfängerangaben + +Nähere Angaben zum Empfänger, um eine Meldung gezielt an ein Kreditin- +stitut adressieren zu können (z.B. Geschäftsstelle. Filialnummer, Name des +Kundenbetreuers). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:1
+ + +####### Empfängername änderbar + +Kennzeichen dafür, ob der Name des Empfängers eines Auftrags durch den +Kunden nachträglich änderbar ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +####### Empfängername, AZV + +Name bzw. Firmenname des Empfängers und dessen Adresse, die bei ei- +nem Auftrag im Auslandszahlungsverkehr anzugeben sind. + +Die Anzahl der maximal erlaubten Eingabezeichen ergibt sich aus den BPD. +Es sollten nur Zeichen aus dem S.W.I.F.T.-Zeichensatz verwendet werden. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
566		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:. . 140
Version:1
+ + +####### Empfängername, AZV kurz + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:1
+ + +####### Ende der Laufzeit + +Ende der Laufzeit (z.B. von Festpreisangeboten). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dat
Länge:#
Version:1
+ + +####### Ende-zu-Ende-Identifikation + +Referenziert auf das Element der pain message als eindeuti- +ge ID des Auftraggebers (Kunde) bzw. Referenz des Begünstigten, der die +entsprechende Lastschrift erzeugt hat. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:1
+ + +####### Endedatum + +Ende einer Zeitraumangabe. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dat
Länge:#
Version:1
+ + +####### Ergebnis Kundeninteraktion + +Informiert, auf welche Weise der Kunde auf die Darstellung des Bestäti- +gungstextes reagiert hat. + +Codierung: + +1: +Kunde hat Bestätigungstext akzeptiert + +2: +Kunde hat Bestätigungstext abgelehnt + +3: +Kunde hat abgebrochen bzw. Fenster geschlossen + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Data Dictionary
SEPA-Zahlungsverkehr		Stand:
07.08.2015		Seite: 567
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:1
+ + +######## Erlaubte Bestellung + +Information darüber, welche Produktart und welche Auslieferungsart für eine +Bestellung kreditinstitutsseitig zugelassen sind. Die beiden Codes werden +mit Semikolon getrennt. + +Es dürfen an dieser Stelle nur Bestellungen auftreten, für die Konditionen +existieren und andererseits keine Bestellungen fehlen, für die Konditionen +laut zugehörigen Parameter vorhanden sind. + +Diese Angaben sind nur erforderlich, wenn für die Bestellung keine Kondi- +tionen benötigt werden. + +Produktart-Codierung s. ,,Produktart Sorten, Reiseschecks" + +Auslieferungsart-Codierung s. ,,Auslieferungsart“ + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:20
Version:1
+ + +######### Erlaubte SEPA-Auftragsart + +Gibt an, für welche SEPA-Auftagsart C-Transaktionen durchgeführt werden +können. + +Codierung: + +1: Überweisung + +2: Lastschrift + +3: Überweisung und Lastschrift + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:1
+ + +######### Erlaubte Stückelungsart + +Information darüber, ob die Stückelung der gewünschten Sorten bezie- +hungsweise Reiseschecks vom Kunden vorgegeben werden kann oder ob +es eine automatische Stückelung gibt oder ob beide Varianten erlaubt sind. + +Codierung: + +1: Nur automatische Stückelung erlaubt + +2: Nur kundendefinierte Stückelung erlaubt + +3: Automatische und kundendefinierte Stückelung erlaubt + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
568		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:2
+ + +####### Erlaubte Zahlungsarten + +Gibt die vom Kreditinstitut tatsächlich erlaubten Zahlungsarten des zugrunde +liegenden DTAZV-Handbuches an. Die verschiedenen Zahlungsarten wer- +den innerhalb des Datenelementes mit Semikolon getrennt. (s. [DTAZV]). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..64
Version:1
+ + +######## Erläuterungen + +Freitext, der die Art der Information näher erläutert. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:1
+ + +######## Erneutes Senden erforderlich + +Kennzeichen dafür, ob im Falle der Ablehnung der Auftrag durch Beachten +der Hinweise und erneutes Senden abgesetzt werden kann. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +![](figures/288.1) + + +Wenn dieses Flag gesetzt ist, sollte das Kundensystem die +Kommunikationsverbindung nicht abbauen, um dem Kunden +zu ermöglichen, ohne Neuaufbau eine Bestätigung zu sen- +den. + + +![](figures/288.2) + + +Dem Kreditinstitut ist freigestellt, ob es einen Kundenauftrag +akzeptiert (d.h. 'Erneutes Senden erforderlich' = Nein), auch +wenn die wichtigen Informationen oder die auftragsbezoge- +nen Informationen nicht zuvor angefordert wurden, oder ob +es den Auftrag solange ablehnt ('erneutes Senden erforder- +lich' = Ja) bis der Auftrag in korrekter Form vorliegt. + + +###### Eröffnungsdatum + +Eröffnungsdatum (z.B. eines Kontos). + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 569
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dat
Länge:#
Version:1
+ + +####### Eröffnungskurs + +Bei Beginn der Börse im variablen Handel festgestellter erster Börsenkurs. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:rate
Länge:#
Version:2
+ + +######## Erstellart + +Erstellart eines Kontoauszuges (z.B. Kontoauszugsdrucker, Internet, Bank) + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..30
Version:1
+ + +######## Erstellungsdatum Kontoauszug + +Datum an dem der Kontoauszug erstellt wurde. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dat
Länge:#
Version:1
+ + +######### Erster Handelstag + +Erster Handelstag eines Finanzinstruments (z.B. Neuemission). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dat
Länge:#
Version:1
+ + +######### Erster Handelstag, Erläuterung + +Erläuterung zum „Erster Handelstag" (z.B. ,,noch nicht bekannt“, „voraus- +sichtlich“). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:txt
Länge:..80
Version:1
+ + +######## Erster Zinstermin + +Erster Zinstermin (gemäß WM GD 322) + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
570		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dat
Länge:#
Version:1
+ + +######### Erstes Ausführungsdatum änderbar + +Kennzeichen dafür, ob das erste Ausführungsdatum eines Dauerauftrags +durch den Kunden änderbar ist. + +Sollte das Kreditinstitut die Änderung dieses Feldes zulassen, so ist zu un- +terscheiden, ob der Änderungsauftrag vor oder nach der ersten Ausführung +eingeht: Im Falle, dass der Dauerauftrag noch nie ausgeführt wurde, wird so- +fern dieses DE geändert wird, der erste Ausführungstermin auf den neuen +Termin verschoben. Falls der Dauerauftrag schon mindestens einmal ausge- +führt wurde, wird durch Änderung dieses Feldes der Ausführungstag bzw. - +wochentag geändert (s. DE „Erstmals ausführen am“). Es ist zu beachten, +dass sich dadurch auch der Ausführungsrhythmus ändern kann. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +######### Erstmals ausführen am + +Datum der erstmaligen Ausführung des Dauerauftrags. + +Dieses Datum muss einerseits ein gemäß BPD gültiges Ausführungsdatum +sein und andererseits zu den Angaben in den Feldern ,,Zeiteinheit" und ,Tur- +nus" konsistent sein, d.h. es muss sich um einen aus diesen Daten resultie- +renden Ausführungstermin handeln. + +Der mögliche Wertebereich wird durch die DE ,,Minimale Vorlaufzeit" und +,Maximale Vorlaufzeit“ aus der BPD vorgegeben. + +Beispiel 1: + +Zeiteinheit: M + +Turnus: 1 + +Ausführungstag: 15 + +Erstmals ausführen am: gültig z.B.: 19981015, 19981115, ungültig z.B.: +19981017 + +Beispiel 2: + +Zeiteinheit: W + +Turnus: 1 + +Ausführungstag: 1 + +Erstmals ausführen am: gültig z.B.: 19981019 (Montag), ungültig z.B.: +19981020 (Dienstag) + +Typ: +DE + +Format: + +vdat + +Länge: + +Version: +2 + + +![](figures/290.1) + + +Die Errechnung möglicher Ausführungsdaten bzw. die Prü- +fung auf Gültigkeit des vom Kunden eingegebenen Datums + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 571
+ + +kann vom Kundenprodukt übernommen werden. + +F + + +########## Fälligkeit + +Termin der nächsten Buchung auf das Referenzkonto bei Kreditkartenkonten +bzw. Rückzahlungs- oder Verfallsdatum eines Wertpapiers (Aktien, Renten +etc.) oder Fonds. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dat
Länge:#
Version:1
+ + +########### Fälligkeit Gesamtleistung + +Datum, wann die Gesamtleistung fällig wird. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dat
Länge:#
Version:1
+ + +########### Familienstand + +Angabe des Familienstands als Teil der Personendaten. + +Codierung: + +1: nicht verheiratet + +2: verheiratet + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:2
+ + +########## Familienstand Freistellungsauftrag + +Familienstand des Kunden. + +Codierung: + +1: ledig + +2: verheiratet (gemeinsame steuerliche Veranlagung) + +3: verheiratet (getrennte steuerliche Veranlagung) + +4: geschieden + +5: dauernd getrennt lebend + +6: verwitwet + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
572		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:1
+ + +###### Festgeldkondition + +Festgeldkondition, +zu +der +der +Kunde +den +Auftrag +(Festgeldneuanlage, -änderung, -prolongation) erteilen möchte. + +Falls Sonderkonditionen vereinbart wurden, lässt sich u.U. kein Betragsinter- +vall angeben. In diesem Fall ist die Angabe von ,,Anlagebetrag von" und ,An- +lagebetrag bis" nicht erforderlich. + +Kundenseitig ist die Kondition so einzustellen, wie sie vom Kreditinstitut beim +Abruf der Konditionen übermittelt wurde. Insbesondere ist die Konditionen- +identifikation anzugeben, sofern sie vom Kreditinstitut mitgeteilt wurde. + +Falls die Angaben in den Konditionen inkonsistent sind oder die Konditionen +nicht mehr aktuell sind, kann der Auftrag abgelehnt werden. + +Bei einer Prolongation ist seitens des Kreditinstituts die Kondition mitzuteilen, +zu der die Prolongation tatsächlich erfolgt, falls dies bei der Rückmeldung +schon bekannt ist. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Anlagedatum1DEdat#M1
2Ablaufdatum1DEdat#M1
3Zinssatz1DEwrt#M1
4Zinsmethode2DEcode1M1A, B, C, D, E, F, Z
5Anlagebetrag von1DEGbtg#O1
6Anlagebetrag bis1DEGbtg#O1
7Kondi- tionenidentifi- kation1DEid#O1
8Konditionenbe- zeichnung1DEan.30O1
+ + +![](figures/292.1) + + +Das Kundenprodukt sollte aus Anlage- und Ablaufdatum die +Laufzeit der Anlage berechnen, da dies dem Kunden i.d.R. +einen besseren Vergleich ermöglicht. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:3
+ + +####### Festgeldstatus + +Status der Festgeldanlage. + +Codierung: +1: aktiv + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Data Dictionary
SEPA-Zahlungsverkehr		Stand:
07.08.2015		Seite: 573
+ + +##### 2: vorgemerkt + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:2
+ + +###### Festpreisangebotsnummer + +Eindeutige Nummer eines Festpreisangebots, die bei einer Inanspruchnah- +me des Angebots in der entsprechenden Order anzugeben ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:id
Länge:#
Version:1
+ + +###### Filter Neuemissionen + +Angabe des Kunden zur Einschränkung der gewünschten Emissionen. Fehlt +diese Angabe, kann das Kreditinstitut selbst entscheiden, welche Emissio- +nen dem Kunden angezeigt werden. Die zulässigen Werte kann das Kredit- +institut mit Hilfe der Bankparameterdaten einschränken. + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Emissionsstatus2DEcode1M1..41, 2, 3, 4
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +##### Finanzdatenformat + +Finanzdatenformat (z.B. SWIFT-Message Type), das als Binärfeld transpa- +rent übertragen wird. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:bin
Länge:..
Version:1
+ + +##### Finanzdatenformat Bezugszeitpunkt + +Datum und ggf. Uhrzeit, auf die sich ein Finanzdatenformat bezieht (z.B. +Kontoumsätze vom 29.04.1999). + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:tsp
Länge:#
Version:1
+ + +##### Format der Information + +Informationen über das Format einer Datei (,GIF", ,JPG", ,RTF" etc.). + +Die Einstellung eines Formats gilt nur für die Informationsart „D“ und wird im +derzeitigen Stadium ignoriert. Zu einem späteren Zeitpunkt könnten hier In- +formationen über das Format der Datei (,GIF", ,JPG", ,RTF" etc.) eingestellt +werden. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
574		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..3
Version:1
+ + +###### Formatbezeichnung + +Eindeutige Bezeichnung eines Finanzdatenformats. Bei SWIFT-Message- +Types wird die Bezeichnung als 3-stelliger Wert ausgedrückt (z.B. „101“, +„940“). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:.. 10
Version:1
+ + +###### Formatinformation + +Information über das Finanzdatenformat, mit der der Kunde beispielsweise +gezielt ein bestimmtes Finanzdatenformat bei einer Sendung oder Abrufung +spezifizieren kann. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Formattyp2DEcode1M11,9
2Formatbezeich- nung1DEan.. 10M1
3Formatversion1DEan.. 10M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:2
+ + +####### Formatinformation + +Information über das Finanzdatenformat, mit der der Kunde beispielsweise +gezielt ein bestimmtes Finanzdatenformat bei einer Sendung oder Abrufung +spezifizieren kann. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Formattyp3DEcode1M11-7, 9
2Formatbezeich- nung1DEan..10M1
3Formatversion1DEan..10M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:3
+ + +##### Formatinformation, codiert + +Vom Kreditinstitut unterstützte Formatinformationen. Entsprechend der DEG +,Formatinformation" sind Formattyp, -bezeichnung und -version einzustellen. +Die Angaben sind durch Semikolon zu trennen. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 575
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..30
Version:2
+ + +##### Formatinformation, codiert + +Vom Kreditinstitut unterstützte Formatinformationen. Entsprechend der DEG +Formatinformation" Version 3 sind Formattyp, -bezeichnung und -version +einzustellen. Die Angaben sind durch Semikolon zu trennen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..23
Version:3
+ + +###### Formattyp + +Typ des Finanzdatenformats. + +Codierung: + +1: S.W.I.F.T. + +9: bilateral vereinbart + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:2
+ + +###### Formattyp + +Typ des Datenformats. + +Codierung: + +1: S.W.I.F.T. + +2: TEXT + +3: HTML + +4: PDF + +5: CAMT + +6: CSV + +7: ZIP + +9: bilateral vereinbart + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:3
+ + +##### Formattyp erlaubt + +Gibt an, ob eine Vorgabe des Formattyps durch den Kunden erlaubt ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:in
Länge:#
Version:1
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
576		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + +###### Formatversion + +Version eines Finanzdatenformats (bei SWIFT bspw. Datum des Standards +Releases im Format JJMM (z.B. 9810)). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:.. 10
Version:1
+ + +####### Formular + +Gibt diejenigen Formulare bzw. Schecks an, die von einem Kreditinstitut zur +Bestellung durch den Kunden angeboten werden. Diese werden dem Kun- +den über die BPD als zulässige (bestellbare) Formulare mitgeteilt. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Formularcode1DEnum..2M1
2Formularbe- zeichnung1DEan.35M1
3Adressaufdruck möglich1DEjn#M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +####### Formularbezeichnung + +Bezeichnung eines Formulars bzw. Schecks. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:1
+ + +####### Formularcode + +Kreditinstitutsspezifische Codes für Formulare bzw. Schecks, die dort zur +Bestellung durch den Kunden angeboten werden. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:.2
Version:1
+ + +####### Freie Betragswahl erlaubt + +Kennzeichen dafür, ob der Provider eine freie Betragswahl in einem be- +stimmten Rahmen zulässt oder nicht. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge#
Version:1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 577
+ + +####### Freistellungsbetrag + +Betrag, in dessen Höhe die Zinserträge von der Zinsabschlagsteuer für das +gesamte Jahr der Gültigkeit befreit sein sollen. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:btg
Länge:#
Version:3
+ + +####### Freitextinformationen + +Informationen, die im Textformat (entspricht Informationsart 'F') vorliegen. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Informationscode1DEan.. 10M1
2Freitextmeldung1DEtxt..
2048		M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +####### Freitextmeldung + +Inhalt einer Freitextinformationen. + +Die maximale Länge der Freitextmeldung ist den BPD zu entnehmen. Mel- +dungen, deren Länge diesen Wert übersteigen, werden abgelehnt. Die Daten +dürfen nicht um führende oder nachfolgende Leerzeichen gekürzt werden. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:txt
Länge:.2048
Version:1
+ + +####### Fremdwährung + +Währung, für die bei einem Auftrag zu Sorten, Devisen oder Reiseschecks +Informationen angezeigt werden. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:cur
Länge:#
Version:1
+ + +G + + +######## Gebuchte camt-Umsätze + +Jedes DE enthält je Buchungstag genau eine camt.052 message. + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
578		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt:
SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + +
1camt-Umsätze gebucht1DEbin..Mn
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +######### Gebuchte Umsätze + +Umsätze, die auf dem Kundenkonto erfolgt sind und zum Zeitpunkt des Kun- +denauftrags vom Kreditinstitut bereits gebucht wurden. + +Gebuchte Umsätze können entweder als MT 940 (s. [Datenformate]) oder im +druckaufbereiteten Format (optional bei Kontoauszügen) bereitgestellt wer- +den. + +Für gebuchte Umsätze im Format S.W.I.F.T. MT 940 gelten folgende Ergän- +zungen: + +Pro Buchungstag ist genau ein MT 940 einzustellen. Es existiert kein Zu- +sammenhang zwischen dem elektronischen MT 940-Auszug und dem Pa- +pierauszug. Falls das Kreditinstitut möchte, kann es allerdings das Feld 28 +belegen. Ob dabei die Auszugsnummer des Papierauszugs eingestellt wird, +bleibt dem Institut freigestellt. Bei Nichtnutzung ist der Wert '0' einzustellen, +wie im MT 940-Standard angegeben. + +Es ist nur höchstens ein Anfangs- und Schlusssaldo (60F, 62F) je MT 940 +erlaubt. Durch einen Anfangs- und Schlusssaldo ist genau ein Buchungstag +definiert. Zwischensalden können beliebig verwendet werden (z.B. bei +Wechsel der Auszugsnummer innerhalb eines Buchungstages). In ein DE +können mehrere MT 940 hintereinandergestellt werden. Dabei sind die ein- +zelnen SWIFT-Formate mit dem Nachrichtenabschluss <-> zu +trennen (s. [Datenformate]). + +Da jeder Buchungstag als einzelner Satz des MT 940 abgebildet werden +kann, kann dieses DE mehrere Buchungstage umfassen. Generell sind im- +mer komplette Buchungstage in einen MT 940-Satz einzustellen. Hiervon +abweichend kann das Kreditinstitut optional in den Satz des aktuellen Tages +die bis dahin gebuchten Umsätze einstellen. + +Es ist der S.W.I.F.T.-Zeichensatz (s. [Datenformate]) anzuwenden. Die Be- +tragsfelder sind in Kontowährung einzustellen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:bin
Länge:
Version:1
+ + +########## Gebuchter Saldo + +Saldo, der nur bereits gebuchte Positionen berücksichtigt, nicht jedoch in der +Schwebe befindliche Posten. Als Datum und Uhrzeit kann der Zeitpunkt der +Gültigkeit des Saldos angegeben werden (Dieser Zeitpunkt kann u.U. vom +Buchungszeitpunkt abweichen). + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 579
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:sdo
Länge:#
Version:2
+ + +####### Geburtsdatum + +Angabe des Geburtsdatums als Teil der Personendaten. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dat
Länge:#
Version:2
+ + +####### Geburtsdatum Begünstigter + +Geburtdatum des Begünstigten. Dies ist u.U. für die Zuteilung von Neuemis- +sionen relevant und kann deshalb bei einer Zeichnung angegeben werden. + +Typ: + +DE + +Format: + +dat + +Länge: + +\# + +Version: + +1 + + +####### Geburtsname + +Geburtsname als Teil der Personendaten. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..30
Version:2
+ + +####### Gebühr/Entgeltgruppe + +Bezeichnung gleichartiger Gebühren und Entgelte. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:txt
Länge:.99
Version:1
+ + +####### Gebühren und Entgelte + +Auflistung aller zu der entsprechenden Gruppe gehörenden Gebühren oder +Entgelte. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Gebühren- /Entgeltgruppe1DEtxt..99M1
2Gebühr/Entgelt1DEGMn
+ + +Typ: +DEG + +Format: + +Länge: + +Version: +1 + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 580Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + +######## Gebühr/Entgelt + +Angaben zu einer einzelnen Gebühr oder einem Entgelt. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Bezeichnung Gebühr oder Entgelt1DEtxt.99M1
2Betrag, Wert1DEwrt#C1M: ,Anzahl" nicht belegt N: sonst
3Betrag, Wäh- rung1DEcur#CM: ,Betrag, Wert" belegt N: sonst
4Anzahl1DEnum..4C1M: ,Betrag, Wert" nicht belegt N: sonst
+ + +Typ: +DEG + +Format: + +Länge: + +Version: +1 + + +######## Geldkartenkommando + +Kommando für die GeldKarte, CBC-Triple-DES-chiffriert. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:bin
Länge:256
Version:1
+ + +######## Geldkartenladeinformation + +Aktueller Zustand der GeldKarte und Informationen zum letzten Lade- +vorgang, beschrieben durch den Eintrag in Record 1 des karteninternen Log- +files EF_LLOG. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:bin
Länge:33
Version:1
+ + +######## Geldkartenladestatus + +Status des Ladevorgangs einer GeldKarte. Die möglichen Stati sind dem +Dokument [Laden GK] zu entnehmen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..2
Version:1
+ + +##### Geldkartenladestatus, Text + +Klartextmeldung der Ladeanwendung, die dem Benutzer am Endgerät ange- +zeigt werden soll + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 581
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..80
Version:1
+ + +# Geldkartenstatus + +Aktueller Zustand der GeldKarte, beschrieben durch das Statusbyte des letz- +ten Eintrags des karteninternen Logfiles EF_LLOG. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:bin
Länge:1
Version:1
+ + +# Geldkurs + +Ankaufskurs bei Sorten bzw. Devisengeldkurs bei Reiseschecks der betref- +fenden Währung pro Standardeinheit. Bei EWU-Währungen sind Brief- und +Geldkurs identisch. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:rate
Länge:#
Version:1
+ + +## Gesamtbestellbetrag + +Bestellbetrag in der Fremdwährung. Der Wert muss größer Null sein. Falls +der Kunde die Stückelung angegeben hat, muss die Summe der Stückelung +dem Betrag entsprechen. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:btg
Länge:#
Version:1
+ + +# Gesamtbetrag + +Gesamtbetrag inklusive Darlehenskosten. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:btg
Länge:#
Version:1
+ + +# Gesamtzins + +Summe aus Sollüberziehungszins und Überziehungszins. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:wrt
Länge:#
Version:1
+ + +# Geschäftsstelle + +Angabe einer Geschäftsstelle, in der der Kunde bei einer Terminvereinba- +rung das Gespräch führen möchte. Wird keine Geschäftsstelle genannt, so + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
582		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + +wird die dem Kunden über seine Kontonummer zugeordnete Geschäftsstelle +angenommen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:1
+ + +# Gewünschte Anzahl + +Vom Kunden gewünschte Anzahl eines Produktes (z.B. Formulare). + +Diesem Wunsch muss jedoch vom Kreditinstitut nicht entsprochen werden, +da die Anzahl abhängig von den institutsindividuellen Packungseinheiten ist. +Gibt der Kunde keinen Wert an, so wird ihm die (kreditinstitutspezifische) +Standardanzahl zugestellt. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..3
Version:1
+ + +# Gewünschtes Ausführungsdatum + +Gewünschtes Datum zur Abholung bzw. Auslieferung, falls das Kreditinstitut +die Angabe eines gewünschten Ausführungsdatums erlaubt. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dat
Länge:#
Version:1
+ + +# Gewünschtes Ausführungsdatum erlaubt + +Kennzeichen dafür, ob es die Angabe eines Datumswunsches zur Abholung +bzw. Auslieferung erlaubt. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +# Gläubiger-ID + +Entspricht dem Creditor Identifier (CI) (vgl. [DFÜ-Abkommen]). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:1
+ + +## Grafik + +Die Grafik als binäres Datenfeld entsprechend dem angegebenen Grafik- +format. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 583
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:bin
Länge:..
Version:1
+ + +# Grafikformat + +Information über das verwendete Grafikformat. Es sind die üblichen Format- +kürzel zu verwenden (z.B. jpg, gif, bmp). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:.. 15
Version:1
+ + +# Greenshoe + +Angabe zur Höhe des Greenshoe als Stückzahl, Betrag oder Prozentbetrag. +Der Greenshoe ist dabei eine Vereinbarung zwischen dem Emittenten und +dem Konsortialführer bzw. dem Konsortium bei Platzierungen im Bookbuil- +dung-Verfahren. Es handelt sich um eine Option, Mehrzuteilungen bei der +Emission durch weitere Aktien aus einer Kapitalerhöhung oder aus Bestän- +den von Altaktionären abzudecken. Dies geschieht i. d. R. dann, wenn die +Nachfrage nach den emittierten Stücken das vorgesehene Emissionsvolu- +men erheblich übersteigt. Der Platzierungspreis der Greenshoe-Aktien ent- +spricht dem für die übrigen Aktien aus der Emission. Der Greenshoe dient +auch der Kursstabilisierung im Zeitraum unmittelbar nach Aufnahme des +Börsenhandels der emittierten Aktien. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..50
Version:1
+ + +# Grenzwert ab, Währung + +Währung des Grenzwertes ab dem ein Zinssatz gültig ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:cur
Länge:#
Version:1
+ + +## Grenzwert ab, Wert + +Wert des Grenzwertes ab dem ein Zinssatz gültig ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:wrt
Länge:#
Version:1
+ + +## Guthabenzins + +Zinssatz (in Prozent p.a.), der ab der Annahme eines Grenzwertes anfällt +(die Anzahl der Nachkommastellen ist kreditinstitutsspezifisch). + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
584		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:wrt
Länge:#
Version:1
+ + +# Gutschrift bei Fälligkeit + +Endwert / Gutschriftsbetrag. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:btg
Länge:#
Version:1
+ + +# Gültig ab + +Datum, ab dem eine Vereinbarung oder Vertrag gilt (z.B. Gültigkeitsbeginn +einer an den Kunden ausgegebenen Karte). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dat
Länge:#
Version:1
+ + +# Gültig bis + +Datum, bis zu dem eine Vereinbarung oder Vertrag gilt (z.B. Verfalldatum ei- +ner an den Kunden ausgegebenen Karte). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dat
Länge:#
Version:1
+ + +# Gültigkeitsdauer Parkett + +Gültigkeitsdauer für den Parketthandel, bis zu der der Kunde seinen Auftrag +z.B. über die Eingabe eines Limitdatums maximal terminieren kann. Die An- +gabe erfolgt anhand der nachfolgenden Codes. + +Diese Angabe kann die vom Kunden wählbaren Limitoptionen in den Feldern +B:22F:TILI und B:98A:EXPI beeinflussen. + +Codierung: + +1: bis Monatsende + +2: bis Quartalsende + +3: bis Halbjahresende + +4: bis Jahresende + +5: 365 Tage + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 585
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:2
+ + +## Gültigkeitsdauer XETRA + +Gültigkeitsdauer für den XETRA-Handel, bis zu der der Kunde seinen Auf- +trag z.B. über die Eingabe eines Limitdatums maximal terminieren kann. Die +Angabe erfolgt in der Anzahl der Kalendertage. Diese Angabe kann die vom +Kunden wählbaren Limitoptionen im S.W.I.F.T.-Format in den Feldern +B:22F:TILI und B:98A:EXPI beeinflussen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..3
Version:1
+ + +### Gültigkeitszeitpunkt + +Zeitpunkt, zu dem ein Auftrag den angegebenen Status hat. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:tsp
Länge:#
Version:1
+ + +H + + +#### Habenzins + +Zinnsatz für Guthaben. Das DE darf nur bei bestimmten Kontoarten belegt +werden. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:wrt
Länge:#
Version:1
+ + +### Habenzinsatz/Bonuszinssatz + +Gültiger Zinssatz für Haben- bzw. Bonuszinsen. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Kennzeichen Haben- zins/Bonuszins1DEcode1O11,2
2Kennzeichen Art der Zinsauf- stellung1DEcode1O11,2,3
3Grenzwert ab, Wert1DEwrt#O1
4Grenzwert ab, Währung1DEcur#O1
5Guthabenzins1DEwrt#O1
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
586		Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + +Typ: + +DEG + + + + + + + + + + + + + + + +
Format:
Länge:
Version:1
+ + +### Handelstyp + +Handelstyp für Präsenzbörsen (entspricht WM GD 522x). + + + + + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..2
Version:1
Referenz:WM GD 522x
+ + +### Handelstyp XETRA + +Handelstyp für den Börsenplatz XETRA (entspricht WM GD 522WA). + +Codierung: + +10: Auktion (eine) + +20: Fortlaufender Handel, Eröffnungs- und Schlussauktion + +30: Fortlaufender Handel, Eröffnungsauktion, untertägige Auktion(en) und +Schlussauktion + +40: Auktionshandel (mehrere) + +50: Continuous Auction (High Quotation Volume) + +60: Continuous Auction (Standard Volume) + +70 : Block crossing + +Typ: +DE + +Format: + +code + +Länge: +.2 + +Version: + +2 + +Referenz: + +WM GD 522WA + + +### Handelswährung + +Währung, in der das Wertpapier an diesem Börsenplatz gehandelt wird (z.B. +WM GD 172). + + + + + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:cur
Länge:#
Version:1
Referenz:WM GD 172
+ + +# Hausnummer + +Angabe der Hausnummer in einer Adresse. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:.. 10
Version:2
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand:
07.08.2015		Seite: 587
+ + +## Heimatbörse + +Heimatbörse des Wertpapiers. Der Börsenplatz ist gemäß ISO 10383 („Mar- +ket Identifier Code“) zu kodieren (s. [Datenformate], Anlagen). + + + + + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:4
Version:1
Referenz:ISO 10383
+ + +### Höchstbetrag in Auslandswährung + +Grenzbetrag in der jeweiligen Währung des Ziellandes, bis zu dem ein Zah- +lungsauftrag für das jeweilige Zielland ausgestellt werden darf. + +Falls kein Höchstbetrag existiert, wird das DE nicht belegt. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:btg
Länge:#
Version:1
+ + +### Höchstbetrag in nationaler Währung + +Grenzbetrag, bis zu dem ein Zahlungsauftrag für das jeweilige Zielland aus- +gestellt werden darf, ausgedrückt in Währung des Ursprungslandes. + +Falls kein Höchstbetrag existiert, wird das DE nicht belegt. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:btg
Länge:#
Version:1
+ + +### HV-Termin + +Der Termin der nächsten Hauptversammlung der Aktien-Gesellschaft. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dat
Länge:#
Version:1
+ + +I + + +## IBAN + +IBAN + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..34
Version:1
+ + +### IBAN Auftraggeber + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
588		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..34
Version:1
+ + +#### IBAN Empfänger + +International Bank Account Number (IBAN) des Überweisungsempfängers, +die alternativ zur konventionellen Kontoverbindung insb. im Auslandzah- +lungsverkehr angegeben werden kann. + +Referenz: "International Bank Account Number" gemäß ECBS EBS 204 + +Aufbau: + +Pos. 1-2: Ländercode gemäß ISO 3166 + +Pos. 3-4: Prüfziffern + +Pos. 5-34: Länderspezifische Kontoidentifikation + +Beispiel: BE62510007547061, FR1420041010050500013M02606 + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..34
Version:1
+ + +#### IBAN-Angabe möglich + +Kennzeichen dafür, ob der Kunde bei einem Auftrag im Auslands- +zahlungsverkehr die IBAN des Zahlungsempfängers angeben darf. Falls +nicht, erfolgt die Angabe über „Kontoverbindung Empfänger“. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +#### IBAN Konto + +IBAN des Kontos zu dem der Auszug erstellt wird. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..34
Version:1
+ + +##### Im Sparjahr gezahlt + +Gesamtbetrag der im laufenden Sparjahr bereits auf einen Sparvertrag ein- +gezahlt wurde. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 589
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:btg
Länge:#
Version:1
+ + +##### Im Sparjahr zu zahlen + +Betrag der unter Zugrundelegung dervereinbarten Sparrate im laufenden +Sparjahr auf einen Sparvertrag noch zu einzuzahlen ist. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:btg
Länge:#
Version:1
+ + +##### Inanspruchnahme + +Gibt an, in welcher Höhe ein Freistellungsauftrag bereits in Anspruch ge- +nommen wurde. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:btg
Länge:#
Version:1
+ + +##### Incentive-Merkmal zulässig + +Information für den Kunden, ob die Angabe eines Incentive-Merkmals bei der +Zeichnung von Neuemissionen (in Feld 70C des MT 502) zulässig ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +##### Information Kredit-/Darlehenskonten + +Informationen zu Darlehenskonten und Avalen. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Bewilligter Be- trag1DEGbtg#O1
2noch verfügba- rer Betrag1DEGbtg#O1
3Gesamtbetrag1DEGbtg#O1
4Leistungsein- zugskonto1DEGkti#O1
5Zinssatz1DEwrt#O1
6Zinsbindungs- ende1DEdat#O1
7Zinsatz, nomi- nal1DEwrt#O1
8Zinsatz, effektiv1DEwrt#O1
9Tilgungssatz, Wert1DEwrt#O1
10Zahlungsrück- stand1DEGbtg#O1
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 590Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
11Vereinbarte Darlehensrate1DEGbtg#O1
12Monatliche Dar- lehensrate1DEGbtg#O1
13Vereinbarter Tilgungsbetrag1DEGbtg#O1
14Zahlungsperio- de1DEcode1O10,1,2,3,4,5,6,7,8,9,A,B,C ,D,E,F
15Zahlungster- mintermin1DEdig4O1
16Tilgungsperiode1DEcode1O10,1,2,3,4,5,6,7,8,9,A,B,C ,D,E,F
17Tilgungstermin1DEdig4O1
18Zinszahlungpe- riode1DEcode1O10,1,2,3,4,5,6,7,8,9,A,B,C ,D,E,F
19Zinszahlungs- termin1DEdig4O1
20Fälligkeit Ge- samtleistung1DEdat#O1
21Laufzeit in Mo- naten1DEnum..3O1
22Avalbetrag1DEGbtg#O1
23Gültig ab1DEdat#O1
24Avalprovision1DEwrt#O1
25Befristung1DEjn#O1
26Befristet bis1DEdat#C1M: „Befristung“ = J N: sonst
27Kontoverbin- dung Gläubiger1DEGkti#O1
28Name Gläubi- ger1DEan.35O1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +##### Information Festgeldkonten/Termineinlagen + +Informationen zu Festgeldkonto (Termineinlagen), Sparbriefe und Renten- +sparpläne. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Anlagebetrag1DEGbtg#O1
2Anlagedatum1DEdat#O1
3Ablaufdatum1DEdat#O1
4Zinssatz1DEwrt#O1
5Zinsmethode2DEcode1O1A, B, C, D, E, F, Z
6Wiederanlage- kennzeichen2DEcode1O11,2,3
7Zinsperiode2DEcode1O10,1,2,3,4,5,6,7,8,9,A,B, C,D,E,F
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 591
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
8Zinstermin1DEdig4O1
9Laufzeit in Mo- naten1DEnum.3O1
10Tilgungsbeginn1DEdat#O1
11Tilgungsperiode1DEcode1O10,1,2,3,4,5,6,7,8,9,A,B,C ,D,E,F
12Tilgungstermin1DEdig4O1
13Tilgungsbetrag1DEGbtg#O1
14Zeitwert1DEGbtg#O1
15Gutschrift bei Fälligkeit1DEGbtg#O1
16Ausbuchungs- konto4DEGkti#O1
17Zinsgutschrift- konto4DEGkti#O1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +###### Information Sparkonten + +Informationen zu Sparkonten. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Anlagedatum1DEdat#O1
2Ablaufdatum1DEdat#O1
3Vereinbarte Sparrate1DEGbtg#O1
4Im Sparjahr ge- zahlt1DEGbtg#O1
5Im Sparjahr zu zahlen1DEGbtg#O1
6Letzte Rate fäl- lig am1DEdat#O1
7Bemerkungen1DEtxt.204 8O1
8Aktueller Bo- nussatz1DEwrt#O1
9Kündigungsfrist1DEnum..2O1
10Kündigungs- sperrfrist1DEnum..2O1
11Staffelung Bo- nussatz1DEGC.99N : „Staffelung Konditio- nen" belegt O: sonst
12Staffelung Kon- ditionen1DEGC..99N : „Staffelung Bonus- satz" belegt O: sonst
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
592		Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + +Typ: + +DEG + + + + + + + + + + + + + + + +
Format:
Länge:
Version:1
+ + +####### Information Sparkonten + +Informationen zu Sparkonten. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Anlagedatum1DEdat#O1
2Ablaufdatum1DEdat#O1
3Vereinbarte Sparrate1DEGbtg#O1
4Im Sparjahr ge- zahlt1DEGbtg#O1
5Im Sparjahr zu zahlen1DEGbtg#O1
6Letzte Rate fäl- lig am1DEdat#O1
7Bemerkungen1DEtxt.204 8O1
8Aktueller Bo- nussatz1DEwrt#O1
9Kündigungsfrist1DEnum..2O1
10Kündigungs- sperrfrist1DEnum..2O1
11Vorschusszin- senVorschusszi nsen14DED Etxttxt99.- 9914
12Vorschusszins- freiVorschuss- zinsfrei14DEG DEGbtgbt g14
13Staffelung Bo- nussatz1DEGC.99N : „Staffelung Konditio- nen" belegt
O: sonst
14Staffelung Kon- ditionen1DEGC..99N : „Staffelung Bonus- satz" belegt O: sonst
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:22
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Data Dictionary
SEPA-Zahlungsverkehr		Stand: 07.08.2015Seite: 593
+ + +######## Informationen + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Informations- code1DEan.. 10M1
2Beschreibung1DEan.35M1
3Informationsart2DEcode1M1F, S, T
4Version der In- formation1DEdat#O1
5Format der In- formation1DEan..3C1O: ,Informationsart" = „D“
N: sonst
6Erläuterungen1DEan.35O5
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:3
+ + +######## Informationen zu Kundenbedingungen + +Angabe allgemeiner Hinweise zum Kontoauszug (z.B. Hinweis auf Kunden- +bedingungen, Informationen zur Haftung). Im allgemeinen entsprechen diese +Informationen dem Text auf der Rückseite des papiergebundenen Kontoaus- +zugs. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:txt
Länge:2048
Version:2
+ + +######## Informationen zu Kundenbedingungen + +Angabe allgemeiner Hinweise zum Kontoauszug (z.B. Hinweis auf Kunden- +bedingungen, Informationen zur Haftung). Im allgemeinen entsprechen diese +Informationen dem Text auf der Rückseite des papiergebundenen Kontoaus- +zugs. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:txt
Länge:..65536
Version:3
+ + +### Informationen zum Einzelauftrag + +Informationen zu einem Einzelauftrags. Handelt es dabei um einen Teil eines +SEPA-Sammelauftrags muss zur Unterscheidung die Referenz mitgegeben +werden. + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVerTypFor-Län-Sta-An-Restriktionen
sionmatgetuszahl
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 594Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Referenz1DEan..99M1M: Art des terminierten Auftrags=8-10 N: sonst
2SEPA-C-Code1DEcode#O11, 2, 3
3Status SEPA- Auftrag1DEcode#O11, 2, 3, 4, 5
+ + +Typ: +DEG + +Format: + +Länge: + +Version: + +1 + + +### Informationen zum Rechnungsabschluss + +Informationen zum Rechnungsabschluss (z.B. im Kontoauszug) + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:txt
Länge:2048
Version:1
+ + +### Informationen zum Rechnungsabschluss + +Informationen zum Rechnungsabschluss (z.B. im Kontoauszug) + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:txt
Länge:.65536
Version:2
+ + +### Liste derInformationen zur Referenzen + +Liste derInformationen zu einer Referenzen für die eines Einzelaufträgeags +innerhalb eines SEPA-Sammelauftrags. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Referenz1DEan.99M..999 91
2SEPA-C-Code1DEcode#O11, 2, 3
3Status SEPA- Auftrag1DEcode#O11, 2, 3, 4, 5
+ + +Typ: +DEG + +Format: + +Länge: + +Version: + +1 + + +## Informationsart + +Form, in der die Information vorliegt. + +Codierung: + +D: Datei (z.Zt. noch nicht zulässig) + +F: Freitext + +S: Schriftdokument + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand:
07.08.2015		Seite: 595
+ + +# T: Themenüberschrift + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:2
+ + +## Informationscode + +Code zur Strukturierung von Informationsangeboten, mit Hilfe dessen im +Kundenprodukt eine Sortierung nach Themengebieten etc. ermöglicht wird. + +Die Klassifizierung kann von jedem Kreditinstitut selbst gebildet werden. + +Beispiel: + +3500: Lebensversicherungen + +3510: Allgemeines + +3511: Informationen zu Lebensversicherungen + +3512: Konditionen für Lebensversicherungen + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:.. 10
Version:1
+ + +## Informationscodes + +Gültige Codes aus dem Angebotsverzeichnis des Kreditinstituts: + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Informationscode1DEan.. 10M1..9
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +### Institutsmerkmale + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Institutskennzeichen1DEnum.2M1
2Institutsname1DEan.100M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +### Institutskennzeichen + +Angabe zum Institut auf den sich der Kundenauftrag bezieht. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:.2
Version:1
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
596		Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + +## Institutsname + +Institutskurzbezeichnung + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:.100
Version:1
+ + +## Institutsname Empfänger, AZV + +Name des Kreditinstituts des Empfängers mit Ortsangabe als Angabe für ei- +nen Auftrag im Auslandszahlungsverkehr. + +Die Anzahl der maximal erlaubten Eingabezeichen ergibt sich aus den BPD. +Es sollten nur Zeichen aus dem S.W.I.F.T.-Zeichensatz verwendet werden. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:.140
Version:1
+ + +## InstructedAmount änderbar + +Kennzeichen dafür, ob der Betrag (InstructedAmount ) eines +SEPA-Dauerauftrags nachträglich durch den Kunden änderbar ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +J + +Jahr + +Jahreszahl. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:4
Version:1
+ + +# Jahr der Gültigkeit + +Jahr der Gültigkeit des Freistellungsbetrages bzw. das Jahr, für das Freistel- +lungsinformationen abgerufen werden können. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:4
Version:1
+ + +Jahr, ordinal + +Dient zur Aufzählung von Jahren. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 597
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..2
Version:1
+ + +## Jahreshöchststand + +Kurshöchststand im unmittelbar zurückliegenden Zeitraum eines Jahres. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:rate
Länge:#
Version:2
+ + +## Jahrestiefststand + +Kurstiefststand im unmittelbar zurückliegenden Zeitraum eines Jahres. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:rate
Länge:#
Version:2
+ + +# K + + +## Kapitalveränderungen + +Information über die Art der Kapitalveränderungen. + +Codierung: + +1: Kapitalheraufsetzung + +2: Kapitalherabsetzung + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:2
+ + +### Kartenart + +Angabe zur Kartenart der Karte, auf die der Kundenauftrag oder die Kredits- +instituts-Rückmeldung bezieht. + +Die je Kreditinstitut angebotenen Kartenarten sind in den BPD eingestellt. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..2
Version:1
+ + +### Kartenbezeichnung + +Institutsspezifische Bezeichnung einer Karte (z.B. ,,Eurocard Gold“, „Service- +karte“). + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
598		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:1
+ + +## Kartenbezeichnung/Produktname + +Kartenbezeichnung bzw. Produktname des jeweiligen Mobilfunkproviders. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:1
+ + +## Kartenfolgenummer + +Identifikationsnummer einer an den Kunden ausgegebenen Karte, die in Ab- +hängigkeit der Kartennummer zusätzlich vergeben wird. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:id
Länge:#
Version:1
+ + +## Kartenidentifikationsdaten + +Diese Daten dienen zur Ableitung des kartenindividuellen Schlüssels KLT aus +dem KGKLT. Sie können dem EF_ID der zu ladenden GeldKarte entnommen +werden. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:bin
Länge:22
Version:1
+ + +## Kartenlimit + +Betrag, bis zu dem mit der Karte Verfügungen getätigt werden können. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:btg
Länge:#
Version:3
+ + +## Kartennummer + +Identifikationsnummer einer an den Kunden ausgegebenen Karte. Zusam- +men mit der Kartenfolgennummer wird eine Karte eindeutig identifiziert. Die +Kartennummer und -folgenummer können über die Kontoverbindung, über +die die Karte ausgestellt wurde, ermittelt und angezeigt werden. Zur Sper- +rung einer Karte müssen die Kartennummer und -folgenummer angegeben +werden. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:id
Länge:#
Version:1
+ + +## Kassakurs + +Amtlich ermittelter Kurs einmal am Tag etwa zur Mitte der Börsensitzung. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 599
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:rate
Länge:#
Version:2
+ + +## Kategorie der wichtigen Informationen + +Kategorien (z.B. „Aktien“, „Renten“, „Optionen“), die zur internen Verwaltung +von speziellen wichtigen Informationen institutsindividuell gebildet werden. +Für allgemeine wichtige Informationen darf dieses DE nicht belegt werden. + +Die zulässigen Kategorien werden dem Kundensystem in den BPD mitge- +teilt. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..30
Version:1
+ + +## Kennzeichen Art der Zinsaufstellung + +Kennzeichen für die Art der Zinsaufstellung. + +Codierung: + +1: Einzelzins + +2: Staffelzins + +3: Stufenzins + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:1
+ + +## Kennzeichen Execution-Only-Depot + +Gibt an, ob es sich um ein Execution-Only-Depot handelt. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:in
Länge:#
Version:1
+ + +## Kennzeichen FSA/NV + +Kennzeichen, ob es sich um einen Freistellungsauftrag oder eine NV- +Bescheinigung handelt. + +Codierung: + +F: Freistellungsauftrag + +N: NV-Bescheinigung + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:1
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
600		Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + +# Kennzeichen Habenzins/Bonuszins + +Kennzeichen für die Art der Zinssätze. + +Codierung: + +1: Habenzins + +2: Bonuszins + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:1
+ + +## Kennzeichen komplexes Finanzinstrument + +Gibt an, ob es sich um ein komplexes Finanzinstrument handelt. + +Codierung: + +J: Ja + +K: Nicht ermittelbar + +N: Nein + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:1
+ + +## Kleinste handelbare Einheit + +Angabe bei Aktien in Stück und bei Rentenwerten nominal (entspricht bei in- +ländischen Wertpapieren WM GD 524x). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:wrt
Länge:#
Version:1
+ + +## Kleinster Betrag + +Kleinster bestellbarer Betrag. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:btg
Länge:#
Version:3
+ + +## Kleinster Schritt + +Information darüber, in welchen Schritten der bestellte Betrag erhöht werden +kann. Dieser Wert kann von der Stückelung der Währung und vom kleinsten +Betrag abhängen. Eine Währung mit Noten in Nennwerten von 20, 50 und +100 kann zum Beispiel ab einem kleinsten Betrag von 50 in Schritten von 10 +bestellt werden. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 601
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:btg
Länge:#
Version:3
+ + +# Kommission + +Kommission (Angabe in Prozent). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:wrt
Länge:#
Version:1
+ + +# Konditionenart + +Kennzeichen dafür, ob sich die Konditionen auf Ankauf oder Verkauf bezie- +hen. + +Codierung: + +1: Ankaufskonditionen + +2: Verkaufskonditionen + +3: An- und Verkaufskonditionen + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:2
+ + +# Konditionenbezeichnung + +Bezeichnung für die Konditionen bzw. die Festgeldanlage. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..30
Version:1
+ + +# Konditionenidentifikation + +Eindeutige Identifikation der angebotenen Kondition. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:id
Länge:#
Version:1
+ + +# Konditionenversion + +Version der angebotenen Kondition. Die Version muss eindeutig innerhalb +aller angebotenen Auslieferungsarten sein. Diese Version muss später bei +der Bestellung angegeben werden. + +Bei jeder Änderung der Konditionen (z.B. Festgeldkonditionen, Konditionen +für Sorten und Reiseschecks) ist die Version kreditinstitutsseitig zu aktuali- +sieren. Die Art der Versionsverwaltung (Versionsnummer oder Versionsda- +tum) kann vom Kreditinstitut frei gewählt werden. Falls keine Versionsverwal- +tung geführt wird, ist das aktuelle Tagesdatum einzustellen. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
602		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:.. 10
Version:1
+ + +# Konsortialführer + +Konsortialführer einer Wertpapierneuemission. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:txt
Länge:200
Version:1
+ + +# Kontingentinformation + +Höhe des kreditinstitutsseitig verfügbaren Kontingents. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:.. 15
Version:1
+ + +# Konto-/Depotnummer + +Identifikationsnummer des Kontos (Kontonummer, Depotnummer, Kredit- +kartennummer etc.). Das DE dient auch zur Aufnahme von internationalen +(alphanumerischen) Kontonummern und zukünftig 20-stelligen Kreditkarten- +kontonummern. + +Es ist zu beachten, dass Kontonummern auch führende Nullen beinhalten +können, die bankfachlich relevant sind und nicht abgeschnitten werden dür- +fen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:id
Länge:#
Version:1
+ + +# Konto-/Depotnummer erlaubt + +Gibt an, ob Abfragen durch Bevollmächtigte erlaubt ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +# Kontoart + +Klassifizierung der Konten. Innerhalb der vorgegebenen Codebereiche sind +kreditinstitutsindividuell bei Bedarf weitere Kontoarten möglich. + +Codierung: + +1 - 9: Kontokorrent-/Girokonto + +10 - 19: Sparkonto + +20-29: Festgeldkonto (Termineinlagen) + +30 - 39: Wertpapierdepot + +40 - 49: Kredit-/Darlehenskonto + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Data Dictionary
SEPA-Zahlungsverkehr		Stand:
07.08.2015		Seite: 603
+ + +50 - 59: Kreditkartenkonto + +60 - 69: Fonds-Depot bei einer Kapitalanlagegesellschaft + +70 - 79: Bausparvertrag + +80 - 89: Versicherungsvertrag + +90 - 99: Sonstige (nicht zuordenbar) + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..2
Version:1
+ + +# Kontoauszugsformat + +Das Feld gibt an, in welchem Format die Kontoauszugdaten geliefert wer- +den. Falls es sich um ein druckaufbereitetes Format handelt, ist der Inhalt +vom Kundenprodukt nicht zu interpretieren, sondern lediglich am Bildschirm +bzw. auf dem Drucker auszugeben. + +Codierung: + +1: S.W.I.F.T. MT 940 + +2: ISO 8583 + +3: Druckaufbereitetes Dateiformat (z.B. PDF) + +Für die Belegung des MT 940 gelten folgende Festlegungen: + +· Feld 28C (Auszugsnummer) muss mit einer gültigen Auszugs- und Blatt- +nummer belegt werden. + +. Feld 61 darf keine nicht-gebuchten Umsätze enthalten. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:3
+ + +# Kontoauszugsjahr + +Kalenderjahr, auf das sich die Kontoauszugsnummer bezieht. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:4
Version:1
+ + +# Kontoauszugskennzeichen + +Angabe zur Zustellungsart des Kontoauszugs in kodierter Form. Hierüber +kann im Kundenauftrag die gewünschte Zustellungsart gewählt werden, falls +das Kreditinstitut (gemäß den Bankparameterdaten) verschiedene Möglich- +keiten für die Zustellung des Kontoauszugs vorsieht. + +Codierung: + +1: Postzustellung + +2: Abholung (z.B. Kontoauszugdrucker) + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
604		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:2
+ + +# Kontoauszugskennzeichen änderbar + +Kennzeichen dafür, ob das Kontoauszugskennzeichen vom Kunden geän- +dert werden darf. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +# Kontoauszugsnummer + +Fortlaufende Nummer des Kontoauszugs. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..5
Version:1
+ + +# Kontoauszugsnummer erlaubt + +Das Kreditinstitut hat anzugeben, ob der Kunde anhand einer Auszugsnum- +mer historische Kontoauszüge anfordern kann. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:2
+ + +# Kontolimit + +Kontobezogenes Limit für Verfügungen am Konto. + +Die Angabe eines Kontolimits ist kreditinstitutsseitig optional, so dass für den +Kunden ein Limit bestehen kann, auch wenn dieses nicht in die UPD einge- +stellt wurde. Ein kontobezogenes Limit darf nicht gleichzeitig mit geschäfts- +vorfallbezogenen Limiten angegeben werden. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Limitart2DEcode1M1E, T, W, M, Z
2Limitbetrag1DEGbtg#C1O: Limitart <> „Z“ N: sonst
3Limit-Tage1DEnum..3C1>0 O: Limitart = ,Z" N: sonst
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 605
+ + +Typ: + +DEG + + + + + + + + + + + + + + + +
Format:
Länge:
Version:2
+ + +## Kontoproduktbezeichnung + +Produktbezeichnung des Kontos. Diese Bezeichnung ist vom Kreditinstitut +frei wählbar. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..30
Version:1
+ + +## Kontoverbindung + +Deutsche oder internationale Kontoverbindung, die im Rahmen der Abwick- +lung eines Auftrags benötigt wird. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Formatkennung:ktv
Länge:#
Version:2
+ + +## Kontoverbindung Auftraggeber + +Kontoverbindung des Auftraggebers, auf die sich der aktuelle Auftrag bezieht +(z.B. Kontoverbindung zu dem Umsätze angezeigt werden sollen). + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:ktv
Länge:#
Version:2
+ + +## Kontoverbindung Empfänger + +Kontoverbindung des Überweisungsempfängers. Diese muss einem deut- +schen Kreditinstitut zugeordnet sein. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:ktv
Länge:#
Version:3
+ + +## Kontoverbindung Empfänger änderbar + +Kennzeichen dafür, ob die Kontoverbindung des Empfängers des Dauerauf- +trags durch den Kunden änderbar ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +## Kontoverbindung Gläubiger + +Kontoverbindung des Gläubigers. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 606Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:kti
Länge:#
Version:1
+ + +# Kontoverbindung international + +Kontoverbindung des Auftraggebers. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:kti
Länge:#
Version:1
+ + +## Kontoverbindung international Auftraggeber + +Kontoverbindung des Empfängers, welcher die betroffene Lastschrift ur- +sprünglich ausgelöst hatte. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:kti
Länge:#
Version:1
+ + +## Kontoverbindung international Empfänger + +Kontoverbindung des Überweisungsempfängers. Diese muss einem deut- +schen Kreditinstitut zugeordnet sein. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:kti
Länge:#
Version:1
+ + +## Kontoverbindung international Kunde + +Kontoverbindung des Kunden, auf der die Lastschrift verbucht wurde. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:kti
Länge:#
Version:1
+ + +## Kontoverbindung international Zahlungsempfänger + +Kontoverbindung des Zahlungsempfängers einer Lastschrift. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:kti
Länge:#
Version:1
+ + +## Kontoverbindung Kunde + +Kontoverbindung des Kunden, auf die sich der aktuelle Auftrag bezieht. + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:Data DictionaryStand:Seite:
Abschnitt:SEPA-Zahlungsverkehr07.08.2015607
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:ktv
Länge:#
Version:3
+ + +## Kontoverbindung Zahlungspflichtiger + +Kontoverbindung des Zahlungspflichtigen einer Lastschrift. Diese muss ei- +nem deutschen Kreditinstitut zugeordnet sein. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:ktv
Länge:#
Version:2
+ + +## Kontoverbindung Zahlungspflichtiger änderbar + +Kennzeichen dafür, ob die Kontoverbindung des Zahlungspflichtigen einer +Lastschrift durch den Kunden änderbar ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +## Kontoverwendung SEPA + +Durch dieses Flag wird festgelegt, ob es sich innerhalb einer Kontoverbin- +dung um ein SEPA-fähiges Konto handelt, d. h. ob zu dieser Kontoverbin- +dung IBAN und BIC existieren. Dies ist z. B. bei Wertpapierdepots nicht der +Fall. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +## Kontowährung + +Angabe der Währung, in der ein Konto geführt wird. Die Währung wird als +ISO-Währungscode angegeben. + +Bei Depotkonten kann auf die Angabe der Kontowährung verzichtet werden. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:cur
Länge:#
Version:1
+ + +## Kontraktreferenz + +Zusätzliches Identifikationsmerkmal für die Festgeldanlage, wenn bspw. auf +einem Anlagekonto mehrere Festgelder angelegt werden können. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:id
Länge:#
Version:1
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
608		Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + +## Kontraktreferenz alt + +Bisherige Kontraktreferenz der Festgeldanlage, die zu Zuordnungszwecken +zusammen mit der neu vergebenen Kontraktreferenz angegeben wird. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:id
Länge:#
Version:1
+ + +# Kostenträger + +Information darüber, wer die Auftragskosten zu tragen hat. + + +## Codierung: + +1: Absender trägt Kosten („OUR“-Regelung; Gutschrift des Überweisungs- +betrages erfolgt kostenfrei für den Zahlungsempfänger) + +2: Kostenteilung + +3: Empfänger trägt Kosten (alle im Zielland anfallenden Preise sind vom Zah- +lungsempfänger zu tragen) + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:2
+ + +![](figures/28.1) + + +Das Kundenprodukt sollte den Kunden darauf hinweisen, +dass gemäß Überweisungsgesetz der Standardfall ist, dass +der Absender sämtliche Kosten trägt. + + +# Kreditinstitutscode + +Landesspezifische Kennung, die das Kreditinstitut eindeutig identifiziert. In +Deutschland wird die Bankleitzahl eingestellt. Bei Kreditinstituten, die in Län- +dern ohne Institutskennungssystem beheimatet sind, kann die Belegung ent- +fallen. Zu weiteren Informationen siehe Kap. E.5. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..30
Version:1
+ + +# Kreditinstitutskennung + +Kennung eines Kreditinstituts. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Formatkennungkik
Länge:#
Version:1
+ + +# Kreditlinie + +Limit für den Kontokorrentkredit. Die Ermittlung der Kreditlinie kann instituts- +spezifisch differieren. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 609
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:btg
Länge:#
Version:1
+ + +# Kreditlinie, Währung + +Währung des Limits für den Kontokorrentkredit. Die Ermittlung der Kreditlinie +kann institutsspezifisch differieren. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:cur
Länge:#
Version:1
+ + +## Kreditlinie, Wert + +Wert des Limits für den Kontokorrentkredit. Die Ermittlung der Kreditlinie +kann institutsspezifisch differieren. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:wrt
Länge:#
Version:1
+ + +## Kundenberater + +Information darüber, mit welchem Berater der Kunde Kontakt aufnehmen +möchte. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:1
+ + +## Kundenstammdatenart + +Art des Stammdatensatzes für Kundendaten. + +Codierung: + +1: Einzelperson + +2: Ehepartner + +3: Ehegemeinschaft + +4: Erbengemeinschaft + +5: Eigentümergemeinschaft + +9: Sonstige Gemeinschaft + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:1
+ + +# Kunden-ID + +Institutsweit eindeutige Identifikation des Kunden. Die Vergabe obliegt dem +Kreditinstitut. Die Kunden-ID kann beliebige Informationen enthalten. Es + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
610		Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + +steht dem Kreditinstitut frei, ob es jedem Kunden genau eine Kunden-ID zu- +ordnet oder dem Kunden in Abhängigkeit vom Benutzer jeweils eine unter- +schiedliche Kunden-ID zuordnet. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:id
Länge:#
Version:1
+ + +# Kurs + +Kurs des Wertpapiers, zu dem das Kreditinstitut das Wertpapier anbietet. Be- +trag bei Stücknotiz bzw. Prozentangabe bei Prozentnotiz. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:wrt
Länge:#
Version:1
+ + +# Kursdaten lieferbar + +Kennzeichen dafür, ob das Kreditinstitut mit dem Geschäftsvorfall "Wertpa- +pierkurse" Kursdaten zu diesem Wertpapier von mindestens einem Börsen- +platz liefern kann. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +# Kursnotierungsart + +Information darüber, wie die Kursnotierung erfolgt. + +Codierung: + +1: Preisnotierung + +2: Mengennotierung + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:2
+ + +# Kurspaket + +Kreditinstitutsseitige Zusammenfassung von Kursen zu bestimmten Stan- +dardangeboten (z.B. DAX-Werte). Die wählbaren Kurspakete werden dem +Kunden in den Bankparameterdaten mitgeteilt. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..30
Version:1
+ + +![](figures/30.1) + + +Auch im Kundensystem können Kurspakete zusammenge- +stellt werden, indem aus einer zuvor zusammengestellten +Liste von Wertpapieren jeweils Kursanforderungssegmente +erzeugt und in einer Nachricht verschickt werden. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 611
+ + +Im Gegensatz zu den Kreditinstitutsseitig erzeugten Kurs- +paketen kann hierbei der Kunde die Zusammenstellung des +Kurspaketes selbst beeinflussen (z.B. Kurse zu allen im +Depot enthaltenen Wertpapieren). + + +## Kursqualität + +Information über die Aktualität des übermittelten Kurses. + +Falls dies vom Kreditinstitut zugelassen wird, kann der Kunde die Kurs- +qualität für die Depotbewertung wählen. Dies stellt lediglich einen Wunsch +des Kunden dar. Wenn dem Kunden aufgrund seines Profils keine Realtime- +Kurse geliefert werden können, können ihm statt dessen Delayed-Kurse in- +klusive einer Hinweismeldung gesendet werden. + +Codierung: + +1: Delayed + +2: Realtime + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:2
+ + +## Kursqualität wählbar + +Kennzeichen dafür, ob der Kunde die Kursqualität (delayed oder realtime) +wählen darf. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +## Kurszusatz + +Zusatz eines Wertpapierkurses. Es sind die üblichen Kodierungen zu ver- +wenden ('b', 'B', 'exD' etc.). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..5
Version:1
+ + +## Kündigungsfrist + +Zeitraum in Monaten bis zum Ende eines Vertrags, der bei einer evtl. Kündi- +gung des Vertrags eingehalten werden muss. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:.2
Version:1
+ + +## Kündigungssperrfrist + +Zeitraum in Monaten, der vor einer evtl. Kündigung des Vertrags eingehalten +werden muss. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
612		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..2
Version:1
+ + +L + + +## Ladebetrag + +Mit diesem Betrag soll die GeldKarte geladen werden. Er muss größer 0 sein +und darf z.Zt. maximal 200 EUR betragen. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:btg
Länge:#
Version:1
+ + +### Ladebetrag Prepaid + +Höhe des vom Kunden gewünschten Handy-Ladebetrags + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:btg
Länge:#
Version:1
+ + +### Land + +Angabe eines Landes, codiert gemäß ISO 3166-1. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:ctr
Länge:#
Version:1
+ + +### Laufzeit in Monaten + +Laufzeit in Monaten. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..3
Version:1
+ + +## Länderinformation Auslandsüberweisung ohne Meldeteil + +Länderspezifische Informationen für jedes Zielland, in das das Versenden +einer Auslandsüberweisung ohne Meldeteil möglich ist. Die einzelnen Infor- +mationen sind per Semikolon voneinander zu trennen. Kann-Felder am Ende +des Formats können entfallen. + +Es kann ein Höchstwert in Euro oder alternativ in der Währung des Ziellan- +des angegeben werden. Werden beide Höchstwerte angegeben, so ist da- +rauf zu achten, dass die Werte nicht voneinander abweichen. + +Unabhängig von der Angabe des Höchstbetrages ist das Entfallen der Mel- +depflicht und damit die Voraussetzung für die Verwendung dieses Ge- + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Data Dictionary SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 613
+ + +schäftsvorfalls nur gegeben, wenn der Überweisungsbetrag die Meldepflicht- +grenze nicht übersteigt. + +Hinweis: Es ist zu beachten, dass die nachfolgende Tabelle kein HBCI- +Format darstellt, sondern lediglich die HBCI-Notation zur Beschreibung ver- +wendet. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Zulässiges Ziel- land1DEctr#M1
2Maximale Feld- länge für Auf- traggebername1DEnum..3M1
3Maximale Feld- länge für Insti- tutsname Emp- fänger1DEnum.3M1
4Maximale Feld- länge für Emp- fängername1DEnum..3M1
5Maximale Feld- länge für Ver- wendungszweck1DEnum..3M1
6Höchstbetrag in nationaler Wäh- rung1DEGbtg#O1
7Höchstbetrag in Auslands- währung1DEGbtg#O1
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..99
Version:2
+ + +# Länderinformation Euro-Eilüberweisung + +Länderspezifische Informationen für jedes Zielland, in das das Versenden +einer Euro-Eilüberweisung möglich ist. + +Es ist jeweils der ISO-alpha-Code des Ziellandes sowie optional eines +Höchstbetrages inkl. Währungskennzeichen anzugeben. Die einzelnen Fel- +der sind per Semikolon voneinander zu trennen. + +Beispiele: GB;GBP;10000, FR;EUR;12500, + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..99
Version:1
+ + +# Länderkennzeichen + +Länderkennzeichen gemäß ISO 3166-1 (numerischer Code) (s. Kap. E.4). +Für Deutschland wird der Code 280 verwendet da dieser im Kreditgewerbe +gebräuchlicher als der neue Code 276 ist. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
614		Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:ctr
Länge:#
Version:1
+ + +## Längster zurückliegender Zeitpunkt + +Einschränkung des Historie-Zeitraums, für den Stati und Orderauskünfte +eingeholt werden können. Eine lange Laufzeit einer Order ist insbesondere +bei Limitsetzung möglich. Es ist die Anzahl der Tage einzustellen, die den +Zeitraum bezeichnen, innerhalb dessen zurückliegende Information bereit- +gestellt werden. + +Typ: + +DE + +Format: + +num + +Länge: + +..3 + +Version: + +1 + + +### Leistungseinzugskonto + +Leistungseinzugskonto des Darlehens. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:kti
Länge:#
Version:1
+ + +#### Letzte Rate fällig am + +Datum der letzten Rate. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dat
Länge:#
Version:1
+ + +#### Letzter Kurs + +Letzter vorliegender Kurs (aktueller Kurs). + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:rate
Länge:#
Version:2
+ + +### Letztes Ausführungsdatum änderbar + +Kennzeichen dafür, ob das letzte Ausführungsdatum des Dauerauftrags +durch den Kunden änderbar ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +# Letztmals ausführen am + +Letzter Ausführungstermin eines Dauerauftrags. Dieses Datum muss einer- +seits ein gemäß BPD gültiges Ausführungsdatum sein und andererseits zu +den Angaben in den Feldern ,,Erstmals ausführen am“, ,Zeiteinheit“ und + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Data Dictionary
SEPA-Zahlungsverkehr		Stand:
07.08.2015		Seite: 615
+ + +,Turnus" konsistent sein, d.h. es muss sich um einen aus diesen Daten re- +sultierenden Ausführungstermin in der Zukunft handeln. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:vdat
Länge:
Version:2
+ + +# Limitart + +Information über die Art des geschäftsvorfallbezogenen Limits. + +Ein geschäftsvorfallbezogenes Limit kann nur eingestellt werden, wenn nicht +gleichzeitig ein kontobezogenes Limit angegeben wurde. Die Angabe eines +Limits ist kreditinstitutsseitig optional. Daher kann für den Kunden ein Limit +bestehen, auch wenn dieses nicht in die UPD eingestellt wurde. + +Codierung: + +E: Einzelauftragslimit + +T: Tageslimit + +W: Wochenlimit + +M: Monatslimit + +Z: Zeitlimit + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:2
+ + +## Limitbetrag + +Betrag für Userlimit. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:btg
Länge:#
Version:1
+ + +## Limitwährung + +Währung aller verschiedenen Limitangaben einer Wertpapierorder. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:cur
Länge:#
Version:1
+ + +## Limit-Tage + +Anzahl Tage für rollierendes Zeitlimit (Limitart 'Z'). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..3
Version:1
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
616		Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + +### Link Verkaufsunterlagen + +Internet-URL zu den Verkaufsunterlagen eines Fonds. Die Angabe erfolgt in- +klusive des Dienstbezeichners (z.B. 'http://'). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:txt
Länge:.2048
Version:1
+ + +### Löschung terminierbar + +Kennzeichen dafür, ob der Kunde einen Zeitpunkt für die Löschung eines +Auftrags (z.B. Dauerauftrag) wählen kann. Ist dies nicht der Fall, gilt die Lö- +schung immer ab sofort. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +#### Löschung ungelesener Nachrichten erlaubt + +Gibt an, ob eine Löschung ungelesener Nachrichten erlaubt ist. + +Typ: +DE + +Format: +in + +Länge: +\# + +Version: +1 + +M + + +##### Mandatsreferenz + +Referenziert auf das Element der pain message als eindeutige Re- +ferenz für das Mandat. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:1
+ + +###### Marktsegment Ausland + +Marktsegmente eines ausländischen Börsenplatzes als Freitext. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..80
Version:1
+ + +#### Marktsegment Inland + +Marktsegmente eines inländischen Börsenplatzes gemäß WM GD 521x. + +Codierung: + +1: Amtlicher Handel + +2: Geregelter Markt + +3: Freiverkehr + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Data Dictionary SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 617
+ + +4: Außerbörslich + +5: European Energy Exchange (EEX) + +6: Eurex-Bonds + +7: Neuer Markt + +9: Sonstiges + +D: Freiverkehr/EUWAX + +E: Freiverkehr/Prädikatsmarkt + +F: Freiverkehr/Newex/ NX.one + +G: Freiverkehr/Newex/ NX.plus + +H: Freiverkehr/Newex/ NX.sonstige Wertpapiere + +I: Geregelter Markt/StartUpMarket + +N: Geregelter Markt/Zobex + +O: Freiverkehr/Zobex + + + + + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:2
Referenz:WM GD 521x
+ + +## Maximal zulässiger Auftragswert + +Höchstgrenze für den Wert einer Kauforder. Bei Verkäufen hat dieser Wert +keine Relevanz. Der Wert ,0" bedeutet, dass keine Höchstgrenze existiert. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:btg
Länge:#
Version:2
+ + +## Maximale Anzahl Aufträge + +Höchstens zulässige Anzahl an Segmenten der jeweiligen Auftragsart je +Kundennachricht. Übersteigt die Anzahl der vom Kunden übermittelten Seg- +mente pro Auftragsart die zugelassene Maximalanzahl, so wird die gesamte +Nachricht abgelehnt. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..3
Version:1
+ + +# Maximale Anzahl der zugelassenen Weisungschlüssel + +Gibt die maximale Anzahl der gleichzeitig verwendbaren Weisungschlüssel +aus dem Datenelement ,,Zugelassenen Weisungschlüssel“ zugrunde liegen- +den DTAZV Handbuches an. (s. [DTAZV]). + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
618		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:1
Version:1
+ + +# Maximale Anzahl C-Sätze + +Maximale Anzahl der C-Sätze (Einzelüberweisungen), die in einen DTAUS- +Sammelüberweisungsauftrag eingestellt werden dürfen. Für eine unbegrenz- +te Anzahl ist der Wert ,,0" einzustellen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..6
Version:2
+ + +## Maximale Anzahl CreditTransferTransactionInformation + +Information darüber, wie viele Einzeltransaktionen in einer SEPA- +Sammelüberweisung eingestellt werden dürfen. Für eine unbegrenzte An- +zahl ist der Wert ,,0" einzustellen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..7
Version:1
+ + +# Maximale Anzahl DirectDebitTransferTransactionInformation + +Information darüber, wie viele Einzeltransaktionen in einer SEPA- +Sammellastschrift eingestellt werden dürfen. Für eine unbegrenzte Anzahl ist +der Wert ,,0" einzustellen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..7
Version:1
+ + +# Maximale Anzahl Einträge + +Maximale Anzahl rückzumeldender Einträge bei Abholaufträgen, Kreditinsti- +tutsangeboten oder -informationen (vgl. [Formals], Kap. B.6.3). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..4
Version:1
+ + +## Maximale Anzahl Referenzen + +Gibt an, wie viele einzelne Referenzen (siehe Element „Referenz“) in einer +DEG „Liste der Referenzen“ enthalten seinvom Kunden maximal angegeben +werden dürfen. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 619
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..5
Version:1
+ + +## Maximale Anzahl T-EUE-Sätze + +Information darüber, wie viele T-EUE-Sätze bei einer Euro-Eilüberweisung +maximal in ein DTAZV-Format eingestellt werden dürfen. Für eine unbe- +grenzte Anzahl ist der Wert ,,0“ einzustellen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..4
Version:1
+ + +## Maximale Anzahl T-Sätze + +Information darüber, wie viele T-Sätze bei einem Zahlungsauftrag im Au- +Benwirtschaftsverkehr maximal in ein DTAZV-Format eingestellt werden dür- +fen. Für eine unbegrenzte Anzahl ist der Wert ,,0" einzustellen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..4
Version:1
+ + +## Maximale Anzahl Verwendungszweckzeilen + +Maximale Anzahl der Verwendungszweckzeilen, die der Kunde im Rahmen +des jeweiligen Zahlungsauftrags belegen darf. Diese Anzahl hat sich an den +DTA-Richtlinien zu orientieren (z.Zt. 0-14). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:.2
Version:1
+ + +## Maximale Feldlänge für Auftraggebername + +Information darüber, wie viele Zeichen abhängig vom Zielland der Auslands- +überweisung als Eingabe für den Auftraggebernamen erlaubt sind. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..3
Version:1
+ + +# Maximale Feldlänge für Empfängername + +Information darüber, wie viele Zeichen abhängig vom Zielland der Auslands- +überweisung als Eingabe für den Empfängernamen erlaubt sind. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
620		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..3
Version:1
+ + +## Maximale Feldlänge für Institutsname Empfänger + +Information darüber, wie viele Zeichen abhängig vom Zielland der Auslands- +überweisung als Eingabe für den Institutsnamen des Empfängers erlaubt +sind. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..3
Version:1
+ + +## Maximale Feldlänge für Verwendungszweck + +Information darüber, wie viele Zeichen abhängig vom Zielland der Auslands- +überweisung als Eingabe für den Verwendungszweck erlaubt sind. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..3
Version:1
+ + +### Maximaler Ladebetrag Prepaid + +Maximaler zulässiger Betrag zum Aufladen einer Prepaidkarte in Euro +(ganzzahlig, ohne Nachkommastellen). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..3
Version:1
+ + +### Maximale Länge + +Maximale Länge der Freitextmeldung in Byte (=Zeichen). Freitextmeldungen, +die diese Länge überschreiten, werden abgewiesen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..4
Version:1
+ + +#### Maximale SEPA-Vorlaufzeit + +Maximale Vorlaufzeit für SEPA-Lastschriften. + +Zeitraum, den ein Auftrag maximal im Voraus erteilt werden kann. Die Anga- +be erfolgt in Kalendertagen. Wird hier z. B. "90" eingestellt, kann der Kunde +Aufträge für drei Monate im Voraus einreichen. Die maximale Vorlaufzeit +muss größer oder gleich der minimalen Vorlaufzeit sein. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand:
07.08.2015		Seite: 621
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:.4
Version:1
+ + +# Maximale Vorlaufzeit + +Zeitraum, den ein Auftrag maximal im voraus erteilt werden kann. Die Anga- +be erfolgt in Kalendertagen. Wird hier z.B. "90" eingestellt, kann der Kunde +Aufträge für drei Monate im voraus einreichen. Die maximale Vorlaufzeit +muss größer oder gleich der minimalen Vorlaufzeit sein. + +Bei terminierten Sammelaufträgen ist zu beachten, dass die maximale Vor- +laufzeit gemäß den DTA-Richtlinen höchstens 15 Tage nach dem Erstel- +lungsdatum betragen darf (s. [Datenformate], Kap. A.1.1, Feld A 11b). Falls +das Kreditinstitut jedoch auch längere Vorlaufzeiten akzeptiert, kann abwei- +chend zu den DTA-Richtlinien auch ein höherer Wert angegeben werden. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..4
Version:1
+ + +# Maximale Vorlaufzeit FNAL/RCUR + +Maximale Vorlaufzeit für die SequenceTypes ,,FNAL" und ,RCUR" +für SEPA-Lastschriften. + +Zeitraum, den ein Auftrag maximal im voraus erteilt werden kann. Die Anga- +be erfolgt in Kalendertagen. Wird hier z.B. "90" eingestellt, kann der Kunde +Aufträge für drei Monate im voraus einreichen. Die maximale Vorlaufzeit +muss größer oder gleich der minimalen Vorlaufzeit sein. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..4
Version:1
+ + +## Maximale Vorlaufzeit FRST/OOFF + +Maximale Vorlaufzeit für die SequenceTypes ,,FRST" und ,OOFF" +für SEPA-Lastschriften. + +Zeitraum, den ein Auftrag maximal im voraus erteilt werden kann. Die Anga- +be erfolgt in Kalendertagen. Wird hier z.B. "90" eingestellt, kann der Kunde +Aufträge für drei Monate im voraus einreichen. Die maximale Vorlaufzeit +muss größer oder gleich der minimalen Vorlaufzeit sein. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..4
Version:1
+ + +### Maximale Vorlaufzeit SEPA-Firmenlastschrift + +Spezifische Informationen für B2B-Lastschriften und den dazugehörigen Vor- +laufzeiten. Die Vorlaufzeiten können nach SequenceType global oder detail- + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
622		Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + +liert aufgeschlüsselt werden. Die einzelnen Informationen sind per Semikolon +voneinander zu trennen. + +Hinweis: Es ist zu beachten, dass die nachfolgende Tabelle kein FinTS- +Format darstellt, sondern lediglich die FinTS-Notation zur Beschrei- +bung verwendet. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Sequence Type, codiert1DEcode1M10,1,2
2Maximale SEPA- Vorlaufzeit1DEnum..4M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:.99
Version:1
+ + +#### Maximale Vorlaufzeit SEPA-Lastschrift + +Spezifische Informationen für verschiedene Lastschriftarten zu dazugehöri- +gen Vorlaufzeiten. Die Vorlaufzeiten können nach Lastschriftart und Se- +quenceType global oder detailliert aufgeschlüsselt werden. Die einzelnen In- +formationen sind per Semikolon voneinander zu trennen. + +Hinweis: Es ist zu beachten, dass die nachfolgende Tabelle kein FinTS- +Format darstellt, sondern lediglich die FinTS-Notation zur Beschrei- +bung verwendet. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Unterstützte SEPA- Lastschriftarten, codiert1DEcode1M10,1,2
2Sequence Type, codiert1DEcode1M10,1,2
3Maximale SEPA- Vorlaufzeit1DEnum..4M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..99
Version:1
+ + +#### Meldepflichtgrenzbetrag + +Gibt die Meldepflichtgrenze in EUR an oberhalb derer eine Meldung an die +Bundesbank zu erfolgen hat zugrunde liegenden DTAZV Handbuches an. (s. +[DTAZV]). + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 623
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:wrt
Länge:#
Version:1
+ + +# Mindestabnahmebetrag + +Mindestbetrag beim Abschluss von Festpreisgeschäften. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:btg
Länge:#
Version:1
+ + +# Mindestkommissionsbetrag + +Mindestbetrag für die Kommission. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:wrt
Länge:#
Version:1
+ + +# Mindestzeichnung, Betrag + +Betrag, unter dem bei einer Neuemission nicht gezeichnet werden kann. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:btg
Länge:#
Version:3
+ + +# Mindestzeichnung, Stück + +Stückzahl, unter der bei einer Neuemission nicht gezeichnet werden kann. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:wrt
Länge:.. 15
Version:1
+ + +# Minimale Vorlaufzeit + +Zeitraum, den ein Auftrag vor seiner Ausführung mindestens erteilt werden +muss. + +Zeitraum, den ein Dauerauftrag vor seiner nächsten Ausführung mindestens +eingereicht sein muss. Die Angabe erfolgt in Kalendertagen. Der minimale +Wert beträgt 0. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..4
Version:1
+ + +# Minimale Vorlaufzeit FNAL/RCUR + +Minimale Vorlaufzeit für die SequenceTypes ,,FNAL" und ,RCUR" +für SEPA-Lastschriften. + +Zeitraum, den ein Auftrag vor seiner Ausführung mindestens erteilt werden +muss. Die Angabe erfolgt in Bankarbeitstagen. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
624		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..4
Version:1
+ + +## Minimale Vorlaufzeit FRST/OOFF + +Minimale Vorlaufzeit für die SequenceTypes ,,FRST" und ,OOFF" +für SEPA-Lastschriften. + +Zeitraum, den ein Auftrag vor seiner Ausführung mindestens erteilt werden +muss. Die Angabe erfolgt in Bankarbeitstagen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..4
Version:1
+ + +### Minimaler Ladebetrag Prepaid + +Minimaler zulässiger Betrag zum Aufladen einer Prepaidkarte in Euro +(ganzzahlig, ohne Nachkommastellen). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..3
Version:1
+ + +### Minimale SEPA-Vorlaufzeit + +Minimale Vorlaufzeit für SEPA-Lastschriften. + +Zeitraum, den ein Auftrag vor seiner Ausführung mindestens erteilt werden +muss. Die Angabe erfolgt in Bankarbeitstagen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..4
Version:1
+ + +### Minimale Vorlaufzeit SEPA-Firmenlastschrift + +Spezifische Informationen für B2B-Lastschriften zu den dazugehörigen Vor- +laufzeiten. Die Vorlaufzeiten können nach SequenceType global oder detail- +liert aufgeschlüsselt werden. Die einzelnen Informationen sind per Semikolon +voneinander zu trennen. + +Hinweis: Es ist zu beachten, dass die nachfolgende Tabelle kein FinTS- +Format darstellt, sondern lediglich die FinTS-Notation zur Beschrei- +bung verwendet. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Sequence Type, codiert1DEcode1M10,1,2
2Minimale SEPA- Vorlaufzeit1DEnum..4M1
3CutOff-Zeit1DEtim#M1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Data Dictionary SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 625
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:.99
Version:1
+ + +# Beispiel: B2B + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FRSTRCURFNALOOFF
Fälligkeitstag D-D-1D-1D-1D-1
CutOff Regel InstitutD-21, 182:00UhrD-21, 182:00UhrD-21, 182:00UhrD-21, 182:00Uhr
CutOff-Beispiel Fällig: Fr 30.1.2015MiDo, 2829.1.2015, 182:00 UhrDo, 29Mi, 28.1.2015, 182:00 UhrDo, 29Mi, 28.1.2015, 182:00 UhrDo, 29Mi, 28.1.2015, 182:00 Uhr
Belegung FinTS BPD-Parameter0;12;1820000
+ + +# Minimale Vorlaufzeit SEPA-Lastschrift + +Spezifische Informationen für verschiedene Lastschriftarten zu dazugehöri- +gen Vorlaufzeiten. Die Vorlaufzeiten können nach Lastschriftart und Se- +quenceType global oder detailliert aufgeschlüsselt und ggf. kombiniert wer- +den. Die einzelnen Informationen sind per Semikolon voneinander zu tren- +nen. + +Hinweis: Es ist zu beachten, dass die nachfolgende Tabelle kein FinTS- +Format darstellt, sondern lediglich die FinTS-Notation zur Beschrei- +bung verwendet. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Unterstützte SEPA- Lastschriftarten, codiert1DEcode1M10,1,2
2Sequence Type, codiert1DEcode1M10,1,2
3Minimale SEPA- Vorlaufzeit1DEnum..4M1
4CutOff-Zeit1DEtim#M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..99
Version:1
+ + +## Beispiel: CORE + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 626Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FRSTRCURFNALOOFF
Fälligkeitstag D-D-5D-2D-2D-5
CutOff Regel InstitutD-65, 182:00UhrD-32, 182:00UhrD-32, 182:00UhrD-65, 182:00Uhr
CutOff-Beispiel Fällig: Fr 30.1.2015DeFr 223.1.2015, 182:00 UhrDiMi 278.1.2015, 182:00 UhrMi 28Di 27.1.2015, 182:00 UhrFr 23.De 22.1.2015, 182:00 Uhr
Belegung BPD- Parameter0;1;32;1820000;0;2;65;1820000
+ + +## Beispiel: COR1 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FRSTRCURFNALOOFF
Fälligkeitstag D-D-1D-1D-1D-1
CutOff Regel InstitutD-21, 182:00UhrD-21, 182:00UhrD-21, 182:00UhrD-21, 182:00Uhr
CutOff-Beispiel Fällig: Fr 30.1.2015MiDo, 2829.1.2015, 182:00 UhrDo, 29Mi, 28.1.2015, 182:00 UhrDo, 29Mi, 28.1.2015, 182:00 UhrDo, 29Mi, 28.1.2015, 182:00 Uhr
Belegung BPD- Parameter1;0;21;1820000
+ + +Belegung BPD-Parameter für CORE und COR1 kombiniert aus den beiden obigen +Beipielen: + +0;1;32;1820000;0;2;65;1820000;1;0;21;1820000 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Beispiel: CORE und COR1 (frühestens ab 20.11.2016)
FRSTRCURFNALOOFF
Fälligkeitstag D-D-1D-1D-1D-1
CutOff Regel InstitutD-21, 182:00UhrD-21, 182:00UhrD-21, 182:00UhrD-21, 182:00Uhr
CutOff-Beispiel Fällig: Fr 25.11.2016MiDo, 234.11.2016, 182:00 UhrDo, 24Mi, 23.11.2016, 182:00 UhrDo, 24Mi, 23.11.2016, 182:00 UhrDo, 24Mi, 23.11.2016, 182:00 Uhr
Belegung BPD- Parameter2;0;21;1820000
+ + +## Mobilfunk-Provider + +Angabe zum Mobilfunk-Provider, auf den sich der Kundenauftrag bezieht. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..2
Version:1
+ + +### Mobilfunknummer + +Mobilfunknummer des Kunden im nationalen Format, numerisch, inklusive +führender Nullen. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 627
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:1
+ + +# Monatliche Darlehensrate + +Monatliche Darlehensrate eines Laufzeitdarlehens. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:btg
Länge:#
Version:1
+ + +## Mögliche Ladebeträge + +Gibt mögliche Ladebeträge in Euro (ganzzahlig, ohne Nachkommastellen) +für eine Mobilfunk-Prepaidkarte vor. Die verschiedenen Ladebeträge werden +durch Semikolon getrennt. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..99
Version:1
+ + +N + + +## Nachricht abgerufen + +Gibt an, ob eine Nachricht bereits abgerufen wurde. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:in
Länge:#
Version:1
+ + +## Nachricht abgerufen am + +Gibt an, wann eine Nachricht bereits abgerufen wurde. + +Typ: +DE + +Format: +dat + +Länge: +\# + +Version: + +1 + + +## Nachrichtentyp + +Nachrichtentyp (entspricht der Codierung im BPD-Parameter ,,Nachrichten- +typ codiert") + +Typ: +DE + +Format: +an + +Länge: +..3 + +Version: + +1 + + +### Nachrichtentyp, codiert + +Vom Kreditinstitut unterstützte Nachrichtentypen. Es sind der codierte Nach- +richtentyp sowie die dazugehörige Bezeichnung einzustellen. Die Angaben +sind durch Semikolon zu trennen. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
628		Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:an
Länge:..64
Version:1
+ + +## Nachrichtentyp erlaubt + +Gibt an, ob eine Filterung der Nachrichtenabfrage nach Nachrichtentyp er- +laubt ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:in
Länge:#
Version:1
+ + +## Nachrichtentypbezeichnung + +Nachrichtentypbezeichnung (entspricht der Bezeichnung im BPD-Parameter +,Nachrichtentyp codiert") + +Typ: +DE + +Format: +codean + +Länge: + +..60 + +Version: + +1 + + +## Nachrichtentypinformation + +Vom Kreditinstitut unterstützte Nachrichtentypen. (entspricht dem BPD- +Parameter ,,Nachrichtentyp codiert" ohne Semikolon) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Nachrichtentyp1DEan..3M1
2Nachrichten- typbezeichnung1DEan..60M1
+ + +Typ: +DEG + +Format: + +Länge: + +Version: + +1 + + +## Nachbörse + +Börsenkurs im Nachbörse-Handel (meist über XETRA). + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:rate
Länge:#
Version:2
+ + +## Name + +Angabe des Namens als Teil der Personendaten. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..30
Version:3
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 629
+ + +## Name 1 + +Erste Namenszeile in einer Adresse. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:1
+ + +## Name 1 Empfänger + +Name des Empfängers. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:1
+ + +### Name 2 + +Zweite Namenszeile in einer Adresse. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:1
+ + +## Name 2 Empfänger + +Zusätzliche Angabe zum Namen des Empfängers. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:1
+ + +## Name Auftraggeber 1 + +Name des Auftraggebers. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..27
Version:1
+ + +## Name Auftraggeber 2 + +Zusätzliche Angabe zum Namen des Auftraggebers. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:.27
Version:1
+ + +## Name Auftraggeber dta 1 + +Name des Auftraggebers (Lastschrifteinreicher). Es ist der DTAUS0- +Zeichensatz mit der entsprechenden Codierung zu verwenden. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
630		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dta
Länge:..27
Version:1
+ + +## Name Auftraggeber_dta 1 + +Name des Auftraggebers (des Lastschrifteinreichers). Es ist der DTAUS0- +Zeichensatz mit der entsprechenden Codierung zu verwenden. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dta
Länge:.27
Version:2
+ + +## Name Auftraggeber dta 2 + +Zusätzliche Angaben zum Auftraggeber (Lastschrifteinreicher). Die Belegung +sollte jedoch möglichst unterbleiben. Es ist der DTAUS0-Zeichensatz mit der +entsprechenden Codierung zu verwenden. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dta
Länge:.27
Version:1
+ + +## Name Auftraggeber_dta 2 + +Zusätzliche Angaben zum Auftraggeber (Lastschrifteinreicher). Die Belegung +sollte jedoch möglichst unterbleiben. Es ist der DTAUSO-Zeichensatz mit der +entsprechenden Codierung zu verwenden. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dta
Länge:.27
Version:2
+ + +## Name Empfänger 1 + +Name des Überweisungsempfängers. Es ist der DTAUS0-Zeichensatz mit +der entsprechenden Codierung zu verwenden. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dta
Länge:.27
Version:2
+ + +## Name Empfänger 2 + +Zusätzliche Angaben zum Überweisungsempfänger. Die Belegung sollte je- +doch möglichst unterbleiben. Es ist der DTAUS0-Zeichensatz mit der ent- +sprechenden Codierung zu verwenden. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dta
Länge:..27
Version:2
+ + +## Name Empfänger/Zahlungspflichtiger 1 + +Gibt, abhängig von der Art des Auftrags, den Namen des Empfängers bzw. +Zahlungspflichtigen an.. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 631
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:1
+ + +## Name Empfänger/Zahlungspflichtiger 2 + +Zusätzliche Angaben zum Namen des Empfängers bzw. Zahlungspflichtigen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:1
+ + +## Name Gläubiger + +Namensangabe zu einem Gläubiger. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:1
+ + +## Name Karteninhaber + +Name des Inhabers einer vom Kreditinstitut ausgestellten Karte. Dabei muss +der Karteninhaber nicht notwendigerweise der Kontoinhaber sein. Auch die +Schreibweise des Namens muss nicht notwendigerweise mit dem auf der +Karte aufzudruckenden Namen übereinstimmen. + +Der Name des Karteninhabers und das Verfalldatum der Karte können bei +Kundenaufträgen als zusätzliche Identifizierungskriterien herangezogen wer- +den, wenn bspw. die Kartenfolgenummer nicht bekannt ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:2
+ + +## Name Kontoinhaber 1 + +Name des Kontoinhabers. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:1
+ + +## Name Kontoinhaber 2 + +Zusätzliche Angaben zum Kontoinhaber. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:1
+ + +## Name Mobilfunk-Provider + +Name des Mobilfunk-Providers. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
632		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:.35
Version:1
+ + +## Name Zahlungsempfänger + +Name des Auftraggebers einer SEPA-Lastschrift (Zahlungsempfänger). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:.70
Version:1
+ + +## Name Zahlungspflichtiger 1 + +Name des Zahlungspflichtigen der Lastschrift. Es ist der DTAUS0- +Zeichensatz mit der entsprechenden Codierung zu verwenden. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dta
Länge:..27
Version:2
+ + +## Name Zahlungspflichtiger 2 + +Zusätzliche Angaben zum Zahlungspflichtigen. Die Belegung sollte jedoch +möglichst unterbleiben. Es ist der DTAUSO-Zeichensatz mit der entspre- +chenden Codierung zu verwenden. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dta
Länge:.27
Version:2
+ + +## Name Zahlungspflichtiger änderbar + +Kennzeichen dafür, ob der Name des Zahlungspflichtigen einer Lastschrift +durch den Kunden änderbar ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +## Namenszusatz + +Namenszusatz (z.B. zu einem Auszugsnamen). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:1
+ + +## Nationale Kontoverbindung erlaubt + +Über das DE „Nationale Kontoverbindung erlaubt" legt das Kreditinstitut fest, +ob im Rahmen einer SEPA-Kontoverbindung auch die nationalen Elemente +Kreditinstitutskennung, Konto-/Depotnummer und Unterkontomerkmal zuge- +lassen sind. Bei „N“ dürfen nur IBAN und BIC verwendet werden. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 633
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +## Nennwert + +Nennwert des Wertpapiers (z.B. WM GD 460a) inkl. der Angabe der Wäh- +rung. Bei Stück-Notiz enthält dieses DE den Nennwert zu einem Stück in der +Währung des Feldes WM GD170 „Depot- und Abrechnungswährung“. Die +Währung entspricht der Abrechnungswährung. + +Bei nennwertlosen Papieren (Optionsscheine, Investmentzertifikate, Bezugs- +rechte etc.) erfolgt keine Angabe. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:btg
Länge:#
Version:1
+ + +## Nennwert, Wert + +Nennwert des Wertpapiers (z.B. WM GD 460a) ohne Angabe der Währung. +Bei Stück-Notiz enthält dieses DE den Nennwert zu einem Stück in der Wäh- +rung des Feldes WM GD170 ,,Depot- und Abrechnungswährung“. Die Wäh- +rung entspricht der Abrechnungswährung. + +Bei nennwertlosen Papieren (Optionsscheine, Investmentzertifikate, Bezugs- +rechte etc.) erfolgt keine Angabe. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:wrt
Länge:#
Version:1
+ + +# Nennwerte + +Information darüber, in welchen Stücken Sorten oder Reiseschecks bestellt +werden können, wenn eine kundendefinierte Stückelung möglich ist. + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Stücknennwert1DEwrt#M1..10
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +## Neuemissionen erlaubt + +Kennzeichen dafür, ob die Selektion nach Neuemissionen im Kundenauftrag +erlaubt ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
634		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + +# Nicht gebuchte camt-Umsätze + +Noch nicht gebuchte Umsätze, die dem Kunden im camt.052-Format zusätz- +lich rückgemeldet werden und zum Zeitpunkt des Kundenauftrags vom Kre- +ditinstitut noch nicht gebucht wurden. Nicht gebuchte Umsätze können nicht +auftreten, wenn der vom Kunden angegebene Zeitraum in der Vergangenheit +liegt. + +Nicht gebuchte camt-Umsätze werden als camt.052 message (s. [Datenfor- +mate]) bereitgestellt. + +Es ist genau eine camt.052 message einzustellen. + +Dieses Element transportiert eine camt.52 message als transparentes Da- +tenformat im Sinne von FinTS. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:bin
Länge:..
Version:1
+ + +# Nicht gebuchte Umsätze + +Noch nicht gebuchten Umsätze, die dem Kunden im Format S.W.I.F.T. +MT 942 zusätzlich rückgemeldet werden. Nicht gebuchte Umsätze können +nicht auftreten, wenn der vom Kunden angegebene Zeitraum in der Vergan- +genheit liegt. + +Ansonsten gelten die Anmerkungen zum DE „Gebuchte Umsätze“. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:bin
Länge:..
Version:1
+ + +# Noch verfügbarer Betrag + +Bewilligter aber noch nicht ausgezahlter Betrga eines Darlehens. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:btg
Länge:#
Version:1
+ + +# Nominale + +Nominale eines Wertpapiers. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:wrt
Länge:#
Version:1
+ + +## Nominale änderbar + +Kennzeichen dafür, ob kreditinstitutsseitig eine Änderung dieses Parameters +zulässig ist. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 635
+ + + + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +## Nominalwert der Kapitalveränderung + +Der Wert, um den das Kapital verändert wird. Die Währung entspricht der +Depotwährung. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:wrt
Länge:#
Version:1
+ + +## Nominalzinssatz + +Nominalzinssatz bestimmter Wertpapiere. + +Es ist zu beachten, dass hier Werte mit 3 oder mehr Nachkommastellen ein- +gestellt werden können. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:wrt
Länge:#
Version:1
+ + +## Nur Neuemissionen + +Kennzeichen dafür, dass das Kreditinstitut dem Kunden nur Neuemissionen +liefert. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +## Nur selbst erteilte Aufträge + +Filterkriterium zur Unterscheidung, ob alle Aufträge, die unter der Kunden-ID +erteilt wurden, abgefragt werden sollen oder nur die des aktuellen Benutzers. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +## Nur selbst erteilte Aufträge wählbar + +Kennzeichen dafür, ob das Institut die Einschränkung der abzufragenden +Aufträge auf diejenigen zulässt, die mit der Benutzerkennung des aktuellen +Nutzers erteilt wurden. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +## Nur Standardangebot + +Kennzeichen dafür, dass das Kreditinstitut dem Kunden ein Standardange- +bot an Wertpapierreferenzen liefert. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
636		Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +O + + +# Order änderbar + +Kennzeichen dafür, ob eine Änderung noch möglich ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +## Orderanzeigeinformation + +Falls der Kunde in seinem Auftrag eine Orderanzeige angefordert hat, so +wird dieses Feld mit einer Kopie der Ursprungsorder belegt. Die Orderanzei- +ge besteht aus einem MT 502 sowie aus Zeitstempeln. Wurde der Ur- +sprungsauftrag gesplittet, so erfolgt mit der Orderanzeige die Splitting- +information. + +Wurde der Auftrag angenommen oder abgelehnt, so kann hier ferner das +Datum und die Uhrzeit der Annahme bzw. Ablehnung eingestellt werden. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVersi- onTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Wertpapierorder1DEbin..M1
2Datum Bestäti- gung/Ablehnung1DEdat#K1
3Zeit Bestäti- gung/Ablehnung1DEtim#K1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:2
+ + +## Orderauskunft gewünscht + +Merkmal, ob neben einer Orderauskunft auch Informationen zur Order mitge- +teilt werden sollen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +## Orderauskunft gewünscht erlaubt + +Merkmal, ob neben einer Orderauskunft auch Informationen zur Order mitge- +teilt werden dürfen. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Data Dictionary
SEPA-Zahlungsverkehr		Stand:
07.08.2015		Seite: 637
+ + + + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +# Ordern möglich + +Information, ob das Kreditinstitut das Ordern des beschriebenen Wertpapiers +anbietet: + +Codierung: + +0: Das Wertpapier kann nicht gehandelt werden + +1: Das Wertpapier kann nur gekauft werden + +2: Das Wertpapier kann nur verkauft werden + +3: Das Wertpapier kann gekauft und verkauft werden + +4: Das Wertpapier kann auch über XETRA gehandelt werden + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:2
+ + +# Ordernummer + +Information über die zum angegebenen Zeitpunkt gültige eindeutige Refe- +renz auf einen Auftrag, die zusammen mit dem DE ,,Auftragsidentifikation“ +oder alternativ dazu angegeben wird. + +Sofern dies vom Kreditinstitut zugelassen wird, kann im Kundenauftrag die +Ordernummer für einen bestimmten Auftrag angegeben werden, um die +Möglichkeit zu geben, gezielt wichtige Informationen (z. B. bei Zurückwei- +sung des Kundenauftrages aufgrund fehlender oder nicht aktueller wichtiger +Informationen) zu einem Auftrag abzufragen. + +Wird trotz der Zurückweisung des Kundenauftrages aufgrund fehlender oder +nicht aktueller wichtiger Informationen der ursprüngliche Auftrag nicht ge- +löscht und eine Ordernummer vergeben, so kann diese dem Kunden zum +Referenzzweck zurückgemeldet werden. + +Falls der Auftrag gesplittet wurde, ist über das DE „Ordernummer“ bei der +Rückmeldung des Kreditinstituts die Identifikationsnummer des ersten Teil- +auftrags anzugeben. (s. auch DEG ,,Ordernummer Splitting“). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..99
Version:1
+ + +# Ordernummer alt + +Bisherige Ordnungsnummer, die aus Zuordnungsgründen mit der neu ver- +gebenen Ordnungsnummer mitgeteilt werden muss. Dies ist z.B. erforderlich, +wenn z.B. die Änderung eines Auftrags bankseitig durch eine Löschung und +Neueinrichtung realisiert wird. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
638		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..99
Version:1
+ + +# Ordernummer erlaubt + +Kennzeichen dafür, ob der Kunde im Kundenauftrag eine Ordernummer an- +geben darf, auf die sich die wichtigen Informationen beziehen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +# Ordernummer Splitting + +Identifikationsnummer des zweiten Teilauftrags, falls der Auftrag gesplittet +wurde. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..99
Version:1
+ + +# Ordersplitt + +Information, dass es sich bei der zurückgemeldeten Anzeige um eine gesplit- +tete Order handelt. + +Splitting findet im Gegensatz zur Teilausführung im Vorfeld der Ausführung +statt, d.h. nach einem Ordersplitt liegen mehrere eigenständige Aufträge an +der Börse vor. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +## Ordnungsnummer Finanzamt + +Ordnungs-Nr. des Finanzamtes der aktuellen NV-Bescheinigung. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:.. 16
Version:1
+ + +### Ort + +Angabe des Orts in einer Adresse. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Data Dictionary SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 639
+ + + + + +#### Parameter Auftragsdetails für C-Transaktionen + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Auftrags- +details für C-Transaktionen“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Eingabe Anzahl Einträge erlaubt1DEjn#M1
2Unterstützte SEPA- Datenformate1DEan.256O..9
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +##### Parameter ausgeführte Überweisungen + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Ausge- +führte Überweisungen“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Speicherzeit- raum1DEnum..4M1>0
2Eingabe Anzahl Einträge erlaubt1DEjn#M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +##### Parameter Auslandsüberweisung + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Ausland- +süberweisung“. + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Maximale An- zahl T-Sätze1DEnum..4M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +#### Parameter Auslandsüberweisung + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall ,,Ausland- +süberweisung“. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 640Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Parameter DTAZV- Version Aus- landüberwei- sung1DEGMn
+ + +Typ: + +DEG + +Format: + +Länge: + +Version: + +2 + + +# Parameter Auslösen von C-Transaktionen + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Auslösen +von C-Transaktionen". + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Erlaubte SEPA- Auftragsart1DEcode#M11,2,3
2Maximale An- zahl Referen- zen1DEnum..5O1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +# Parameter Auslandsüberweisung ohne Meldeteil + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Ausland- +süberweisung ohne Meldeteil“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1IBAN-Angabe möglich1DEjn#M1
2Länderinforma- tion Auslands- überweisung ohne Meldeteil2DEan.99O99
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:2
+ + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Data Dictionary SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 641
+ + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Eingabe Anzahl Einträge erlaubt1DEjn1M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +## Parameter Bestand Lastschriftwiderspruch + +Der Speicherzeitraum gibt an, wie viele Tage zurück der Lastschriftenbe- +stand zur Verfügung gestellt werden kann. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Zeitraum mög- lich1DEjn#M1
2Speicherzeit- raum1DEnum4M1>0
+ + +Typ: + +DEG + +Format: + +Länge: + +Version: + +1 + + +## Parameter Bestand Lastschriftwiderspruch + +Der Speicherzeitraum gibt an, wie viele Tage zurück der Lastschriftenbe- +stand zur Verfügung gestellt werden kann. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Zeitraum mög- lich1DEjn#M1
2Speicherzeit- raum1DEnum4M1>0
3Eingabe Anzahl Einträge erlaubt1DEjn#M1
+ + +Typ: + +DEG + +Format: + +Länge: + +Version: + +2 + + +# Parameter Bestand SEPA-Lastschriftwiderspruch + +Der Speicherzeitraum gibt an, wie viele Tage zurück der Lastschriftenbe- +stand zur Verfügung gestellt werden kann. + + + + + + + + + + + + + + +
Nr.NameVerTypFor-Län-Sta-An-Restriktionen
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 642Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
sionmatgetuszahl
1Eingabe Anzahl Einträge erlaubt1DEjn#M1
2Zeitraum mög- lich1DEjn#M1
3Speicherzeit- raum1DEnum..4M1>0
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +## Parameter Bestand terminierter Einzellastschriften + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall ,,Bestand +terminierter Einzellastschriften“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Zeitraum mög- lich1DEjn#M1
2Eingabe An- zahl Einträge erlaubt1DEjn#M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +### Parameter Bestand terminierter Sammellastschriften + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall ,,Bestand +terminierter Sammellastschriften“. + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Zeitraum mög- lich1DEjn#M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +### Parameter Bestand terminierter Sammelüberweisungen + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Bestand +terminierter Sammelüberweisungen“. + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Zeitraum mög- lich1DEjn#M1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Data Dictionary
SEPA-Zahlungsverkehr		Stand: 07.08.2015Seite: 643
+ + +Typ: + +DEG + + + + + + + + + + + + + + + +
Format:
Länge:
Version:1
+ + +## Parameter Bestand terminierter SEPA-Einzellastschriften + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall ,,Bestand +terminierter SEPA-Einzellastschriften“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Eingabe Anzahl Einträge erlaubt1DEjn#M1
2Zeitraum mög- lich1DEjn#M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +### Parameter Bestand terminierter SEPA-Einzellastschriften + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall ,,Bestand +terminierter SEPA-Einzellastschriften“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Eingabe Anzahl Einträge erlaubt1DEjn#M1
2Zeitraum mög- lich1DEjn#M1
3Unterstützte SEPA- Datenformate1DEan.256O..9
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:22
+ + +### Parameter Bestand terminierter SEPA-Firmeneinzellastschriften + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Bestand +terminierter SEPA-Firmeneinzellastschriften“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Eingabe Anzahl Einträge erlaubt1DEjn#M1
2Zeitraum mög- lich1DEjn#M1
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 644Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + +Typ: + +DEG + + + + + + + + + + + + + + + +
Format:
Länge:
Version:1
+ + +#### Parameter Bestand terminierter SEPA-Firmeneinzellastschriften + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall ,,Bestand +terminierter SEPA-Firmeneinzellastschriften“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Eingabe Anzahl Einträge erlaubt1DEjn#M1
2Zeitraum mög- lich1DEjn#M1
3Unterstützte SEPA- Datenformate Unterstützte SEPA- Datenformate14DE DEan an.256- .256..9..9
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:22
+ + +## Parameter Bestand terminierter SEPA-Firmensammellastschriften + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall ,,Bestand +terminierter SEPA-Firmensammellastschriften“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Eingabe Anzahl Einträge erlaubt1DEjn#M1
2Zeitraum mög- lich1DEjn#M1
+ + +Typ: + +DEG + +Format: + +Länge: + +Version: + +1 + + +### Parameter Bestand terminierter SEPA Sammellastschriften + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Bestand +terminierter SEPA-Sammellastschriften". + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Eingabe Anzahl Einträge erlaubt1DEjn#M1
2Zeitraum mög- lich1DEjn#M1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Data Dictionary SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 645
+ + +Typ: + +DEG + + + + + + + + + + + + + + + +
Format:
Länge:
Version:1
+ + +# Parameter Bestand terminierter SEPA-Sammelüberweisungen + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall ,,Bestand +terminierter SEPA-Sammelüberweisungen“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Eingabe Anzahl Einträge erlaubt1DEjn#M1
2Zeitraum mög- lich1DEjn#M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +# Parameter Bestand terminierter SEPA-Überweisungen + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall ,,Bestand +terminierter SEPA-Überweisungen“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Eingabe Anzahl Einträge erlaubt1DEjn#M1
2Zeitraum mög- lich1DEjn#M1
+ + +Typ: + +DEG + +Format: + +Länge: + +Version: + +1 + + +# Parameter Bestand terminierter SEPA-Überweisungen + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall ,,Bestand +terminierter SEPA-Überweisungen“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Eingabe Anzahl Einträge erlaubt1DEjn#M1
2Zeitraum mög- lich1DEjn#M1
3Unterstützte SEPA- Datenformate Unterstützte SEPA Datenformate14DE DEan an.256- .256.9.9
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 646Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + +Typ: + +DEG + +Format: + +Länge: + +Version: + +22 + + +# Parameter Bestand terminierter Überweisungen + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall ,,Bestand +terminierter Überweisungen“. + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Zeitraum mög- lich1DEjn#M1
+ + +Typ: + +DEG + +Format: + +Länge: + +Version: + +1 + + +## Parameter Bestand vorbereitete Überweisungen + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Bestand +vorbereitete Überweisungen“. + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Eingabe Anzahl Einträge erlaubt1DEjn#M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +## Parameter Bestand vorbereitete SEPA-Überweisungen + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall ,,Bestand +vorbereitete SEPA-Überweisungen“. + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Eingabe Anzahl Einträge erlaubt1DEjn#M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +## Parameter Dauerauftrag ändern + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall ,,Dauer- +auftrag ändern“. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Data Dictionary SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 647
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Anzahl termi- nierter Ände- rungen1DEnum1M1
2Minimale Vor- laufzeit1DEnum..4M1
3Maximale Vor- laufzeit1DEnum..4M1
4Kontoverbin- dung Empfän- ger änderbar1DEjn#M1
5Empfängerna- me änderbar1DEjn#M1
6Betrag änder- bar1DEjn#M1
7Textschlüssel und -ergänzung änderbar1DEjn#M1
8Verwendungs- zweck änderbar1DEjn#M1
9Erstes Ausfüh- rungsdatum änderbar1DEjn#M1
10Zeiteinheit än- derbar1DEjn#M1
11Turnus änder- bar1DEjn#M1
12Ausführungstag änderbar1DEjn#M1
13Letztes Ausfüh- rungsdatum änderbar1DEjn#M1
14Maximale An- zahl Verwen- dungszweck- zeilen1DEnum..2M1
15Turnus in Mo- naten1DEdig.24M1
16Ausführungsta- ge pro Monat1DEdig.64M1
17Turnus in Wo- chen1DEdig.104O1
18Ausführungsta- ge pro Woche1DEdig..7C1M: ,Turnus in Wochen" belegt N: sonst
19Zulässiger Textschlüssel1DEdig2M1..99
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 648Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + +Typ: + +DEG + + + + + + + + + + + + + + + +
Format:
Länge:
Version:2
+ + +# Parameter Dauerauftrag aussetzen + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall ,,Dauer- +auftrag aussetzen". + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Anzahl termi- nierter Aus- setzungen1DEnum1M1
2Minimale Vor- laufzeit1DEnum..4M1
3Maximale Vor- laufzeit1DEnum..4M1
4Aussetzungs- eingabe2DEcode1M11,2,3
5Aussetzung jährlich wie- derkehrend er- laubt1DEjn#M1
6Abweichender Betrag erlaubt1DEjn#M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:3
+ + +# Parameter Dauerauftrag einrichten + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Dauer- +auftrag einrichten". + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 649
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Maximale An- zahl Verwen- dungszweck- zeilen1DEnum..2M1
2Minimale Vor- laufzeit1DEnum..4M1
3Maximale Vor- laufzeit1DEnum..4M1
4Turnus in Mo- naten1DEdig.24M1
5Ausführungsta- ge pro Monat1DEdig.64M1
6Turnus in Wo- chen1DEdig.104O1
7Ausführungsta- ge pro Woche1DEdig..7C1M: ,Turnus in Wochen“ belegt N: sonst
8Zulässiger Textschlüssel1DEdig2M1..99
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:2
+ + +## Parameter Dauerauftrag löschen + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall ,,Dauer- +auftrag löschen“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Minimale Vor- laufzeit1DEnum..4M1
2Maximale Vor- laufzeit1DEnum..4M1
3Löschung ter- minierbar1DEjn#M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +## Parameter Dauerauftrag Prepaidkarte laden einrichten + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Dauer- +auftrag Prepaidkarte laden einreichen". + + +![Nr. Name Ver sion Typ For- mat Län- ge Sta- tus An- zahl Restriktionen](figures/69.1) + + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 650Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Minimale Vor- laufzeit1DEnum..4M1
2Maximale Vor- laufzeit1DEnum..4M1
3Turnus in Mo- naten1DEdig..24M1
4Ausfüh- rungstage pro Monat1DEdig..64M1
5Turnus in Wo- chen1DEdig.104O1
6Ausfüh- rungstage pro Woche1DEdig..7C1M: ,,Turnus in Wochen" belegt N: sonst
47Providermerk- male1DEGM..99
+ + +Typ: +DEG + +Format: + +Länge: + +Version: +1 + + +# Parameter Dauerauftrag Prepaidkarte laden löschen + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall ,SEPA- +Dauerauftrag Prepaidkarte laden löschen“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Minimale Vor- laufzeit1DEnum..4M1
2Maximale Vor- laufzeit1DEnum..4M1
3Löschung ter- minierbar1DEjn#M1
+ + +Typ: +DEG + +Format: + +Länge: + +Version: + +1 + + +# Parameter Dauereinzellastschriftbestand abrufen + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Dauer- +einzellastschriftbestand abrufen“. + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Eingabe An- zahl Einträge erlaubt1DEjn#M1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Data Dictionary
SEPA-Zahlungsverkehr		Stand: 07.08.2015Seite: 651
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +## Parameter Dauereinzellastschriftänderungsvormerkungen abrufen + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall ,,Dauer- +einzellastschriftänderungsvormerkungen abrufen“. + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Eingabe An- zahl Einträge erlaubt1DEjn#M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +### Parameter Dauereinzellastschrift ändern + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Dauer- +einzellastschrift ändern“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Anzahl termi- nierter Ände- rungen1DEnum1M1
2Minimale Vor- laufzeit1DEnum..4M1
3Maximale Vor- laufzeit1DEnum..4M1
4Kontoverbin- dung Zah- lungspflichtiger änderbar1DEjn#M1
5Name Zah- lungspflichtiger änderbar1DEjn#M1
6Betrag änder- bar1DEjn#M1
7Textschlüssel und -ergän- zung änderbar1DEjn#M1
8Verwendungs- zweck änder- bar1DEjn#M1
9Erstes Ausfüh- rungsdatum änderbar1DEjn#M1
10Zeiteinheit än- derbar1DEjn#M1
11Turnus änder-1DEjn#M1
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 652Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
bar
12Ausfüh- rungstag än- derbar1DEjn#M1
13Letztes Aus- führungsdatum änderbar1DEjn#M1
14Maximale An- zahl Verwen- dungszweck- zeilen1DEnum..2M1
15Turnus in Mo- naten1DEdig..24M1
16Ausfüh- rungstage pro Monat1DEdig.64M1
17Turnus in Wo- chen1DEdig..104O1
18Ausfüh- rungstage pro Woche1DEdig..7C1M: ,Turnus in Wochen" belegt N: sonst
19Zulässiger Textschlüssel1DEdig2M1..99
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +## Parameter Dauereinzellastschrift aussetzen + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Dauer- +einzellastschrift aussetzen“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Anzahl termi- nierter Aus- setzungen1DEnum1M1
2Minimale Vor- laufzeit1DEnum..4M1
3Maximale Vor- laufzeit1DEnum..4M1
4Aussetzungs- eingabe2DEcode1M11,2,3
5Aussetzung jährlich wie- derkehrend er- laubt1DEjn#M1
6Abweichender Betrag erlaubt1DEjn#M1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 653
+ + +Typ: + +DEG + + + + + + + + + + + + + + + +
Format:
Länge:
Version:1
+ + +### Parameter Dauereinzellastschrift einrichten + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Dauer- +einzellastschrift einrichten". + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Maximale An- zahl Verwen- dungszweck- zeilen1DEnum..2M1
2Minimale Vor- laufzeit1DEnum..4M1
3Maximale Vor- laufzeit1DEnum..4M1
4Turnus in Mo- naten1DEdig.24M1
5Ausfüh- rungstage pro Monat1DEdig..64M1
6Turnus in Wo- chen1DEdig.104O1
7Ausfüh- rungstage pro Woche1DEdig..7C1M: ,,Turnus in Wochen" belegt N: sonst
8Zulässiger Textschlüssel1DEdig2M1..99
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +### Parameter Dauereinzellastschrift löschen + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Dauer- +einzellastschrift löschen“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Minimale Vor- laufzeit1DEnum..4M1
2Maximale Vor- laufzeit1DEnum..4M1
3Löschung ter- minierbar1DEjn#M1
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
654		Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + +Typ: + +DEG + + + + + + + + + + + + + + + +
Format:
Länge:
Version:1
+ + +# Parameter Depotaufstellung + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Depot- +aufstellung“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Eingabe Anzahl Einträge erlaubt1DEjn#M1
2Währung der Depot- aufstellung wählbar1DEjn#M1
3Kursqualität wählbar1DEjn#M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:2
+ + +## Parameter Depotumsätze + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Depot- +umsätze“. + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Speicherzeit- raum1DEnum..4M1>0
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +## Parameter Devisenkurse + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall ,,Devisen- +kurse". + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Abrechnungs- währung Lan- deswährung er- laubt1DEjn#M1
2Abrechnungs- währung Euro erlaubt1DEjn#M1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Data Dictionary
SEPA-Zahlungsverkehr		Stand: 07.08.2015Seite: 655
+ + +Typ: + +DEG + + + + + + + + + + + + + + + +
Format:
Länge:
Version:1
+ + +# Parameter Dokument anfordern + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Doku- +ment anfordern". + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Formatinforma- tion, codiert2DEan..30M1..99
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +# Parameter Dokument senden + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall ,,Doku- +ment senden". + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Formatinforma- tion, codiert2DEan.30M1..99
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +# Parameter Dokumentliste + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Eingabe Anzahl Einträge erlaubt1DEjn#M1
2Speicherzeit- raum1DEnum.4O1>0
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +# Parameter DTAZV-Version Auslandüberweisung + +Parameter zur DTAZV Version, (s. [DTAZV]). + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1DTAZV Hand- buch1DEnum4M1
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 656Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
2Maximale An- zahl T-Sätze1DEnum..4M1
3Meldepflicht- grenzbetrag1DEwrt#M1
4Unterstützte Meldesätze1DEan.. 16O1Lt. DTAZV-Handbuch (z.B 2006: V; W)
5Zugelassene Weisungs- schlüssel1DEan..64O1Lt. DTAZV-Handbuch (z.B 2006: 02;04;06, 07;09;10;11;12;91)
6Maximale An- zahl der zuge- lassenen Wei- sungschlüssel1DEnum1O1
7Erlaubte Zah- lungsarten1DEan.64O1Lt. DTAZV-Handbuch (z.B 2006: 00;10;11;13; 15;20;21;22;23;30;31;32 ;33)
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +# Parameter DTAZV-Version Euro-Eilüberweisung + +Parameter zur DTAZV Version, (s. [DTAZV]). + +Da der Kreis der zulässigen Zielländer einer Euro-Eilüberweisung je Kredit- +institut abweichen kann und auch Änderungen unterworfen ist, ist für jedes +zulässige Zielland ein Datenelement „Länderinformation Euro- +Eilüberweisung“ einzustellen. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1DTAZV Hand- buch1DEnum4M1
2Maximale An- zahl T- EUE- Sätze1DEnum..4M1
3Meldepflicht- grenzbetrag1DEwrt#M1
4Unterstützte Meldesätze1DEan. 16O1Lt. DTAZV-Handbuch (z.B 2006: V; W)
5Zugelassene Weisungs- schlüssel1DEan..64O1Lt. DTAZV-Handbuch (z.B 2006: 10;11;12)
6Max. Anzahl der zugelasse- nen Weisung- schlüssel1DEnum1O1
7Länderinforma- tion Euro- Eilüberweisung1DEan.99O99
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Data Dictionary SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 657
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +# Parameter DTAZV-Version Euro-STP-Zahlung + +Parameter zur DTAZV Version, (s. [DTAZV]). + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1DTAZV Hand- buch1DEnum4M1
2Maximale An- zahl T-Sätze1DEnum..4M1
3STP- Höchstbetrag1DEwrt#M1
4Meldepflicht- grenzbetrag1DEwrt#M1
5Zulässiges Ziel- land Euro-STP- Zahlung1DEan..2O99
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +## Parameter Eilzahlung + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Eilzah- +lung (Urgent Payment)". + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Zulässige Pur- pose codes1DEan..409 6O1
2Unterstützte SEPADaten- formate1DEan.256O.9
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +# Parameter Einzelüberweisung + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Einzel- +überweisung“. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 658Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Maximale An- zahl Ver- wendungs- zweckzeilen1DEnum..2M1
2Zulässiger Textschlüssel1DEdig2M1..99
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +## Parameter Elektronischen Kontoauszug beantragen + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Elektroni- +schen Kontoauszug beantragen“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Bestätigungs- text strukturiert1DEjn#M1
2Willenserklä- rung erforder- lich1DEjn#M1
+ + +Typ: + +DEG + +Format: + +Länge: + +Version: + +1 + + +### Parameter Empfängerkontenbestand anfordern + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall ,,Bestand +der Empfängerkonten abrufen“. + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Eingabe Anzahl Einträge erlaubt1DEjn#M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +### Parameter Euro-Eilüberweisung + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Euro- +Eilüberweisung“. + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Parameter DTAZV-Version Euro- Eilüberweisung1DEGMn
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Data Dictionary SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 659
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:2
+ + +# Parameter Euro-STP-Zahlung + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Euro- +STP-Zahlung". + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Maximale An- zahl T-Sätze1DEnum..4M1
2Zulässiges Ziel- land Euro-STP- Zahlung1DEan..2O99
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +# Parameter Euro-STP-Zahlung + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Euro- +STP-Zahlung". + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Parameter DTAZV-Version Euro-STP- Zahlung1DEGMn
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:2
+ + +## Parameter Festgeld ändern + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall ,,Festgeld +ändern“. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 660Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Belastungskon- to änderbar1DEjn#M1
2Wiederanla- gekennzeichen änderbar1DEjn#M1
3Kontoauszugs- kennzeichen änderbar1DEjn#M1
4Ausbuchungs- konto änderbar1DEjn#M1
5Zinsgutschrift- konto änderbar1DEjn#M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:2
+ + +# Parameter Festgeldkonditionen + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Festgeld- +konditionen“. + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Währung der Konditionen1DEcur#M1..99
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +# Parameter Festgeldneuanlage + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Festgeld- +neuanlage". + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Bestehendes Anlagekonto er- laubt1DEjn#M1
2Abweichendes Ausbu- chungskonto er- laubt1DEjn#M1
3Abweichendes Zinsgut- schriftkonto er- laubt1DEjn#M1
4Kontoauszugs- kennzeichen2DEcode1O91,2
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 661
+ + +Typ: + +DEG + + + + + + + + + + + + + + + +
Format:
Länge:
Version:3
+ + +# Parameter Festpreisangebote + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Fest- +preisangebote“. + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Zulässige Wert- papiergruppe1DEan..35O1..99
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:3
+ + +# Parameter Festpreisorder + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Fest- +preisorder“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Wichtige Infor- mationen ver- pflichtend1DEjn#M1
2Abweichendes Ver- rechnungskonto erlaubt2DEcode1M10-8
3Verrechnungs- konto verpflich- tend1DEjn#M1
4Telefonnummer verpflichtend1DEjn#M1
5Maximal zuläs- siger Auftrags- wert2DEGbtg#O1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:2
+ + +# Parameter Finanzdatenformat anfordern + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Finanz- +datenformat anfordern". + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Formatinforma- tion, codiert2DEan.30M1..99
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
662		Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + +Typ: + +DEG + + + + + + + + + + + + + + + +
Format:
Länge:
Version:2
+ + +## Parameter Finanzdatenformat senden + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Finanz- +datenformat senden". + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Formatinforma- tion, codiert2DEan..30M1..99
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:2
+ + +## Parameter Fondsorder + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall ,,Fondsor- +der“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Wichtige Infor- mationen ver- pflichtend1DEjn#M1
2Abweichendes Ver- rechnungskonto erlaubt2DEcode1M10-8
3Verrechnungs- konto verpflich- tend1DEjn#M1
4Telefonnummer verpflichtend1DEjn#M1
5Wiederanlager- abatt möglich1DEjn#M1
6Zulässige Emit- tenten1DEan.200O1
7Maximal zuläs- siger Auftrags- wert2DEGbtg#O1
8Zulässige Li- mitarten1DEan.99O1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:2
+ + +# Parameter Freistellungsdaten + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Abfrage +Freistellungsdaten“. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Data Dictionary SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 663
+ + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Konto- /Depotnumme r erlaubt1DEGjn#M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +## Parameter Freistellungsdaten + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Abfrage +Freistellungsdaten“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Konto- /Depotnumme r erlaubt1DEjn#M1
2Alle Institute erlaubt1DEjn#M1
3Eingabe An- zahl Einträge erlaubt1DEjn#M1
4Institutsmerk- male1DEGO.99
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:2
+ + +## Parameter Gastmeldung + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Gastmel- +dung“. + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Maximale Län- ge1DEnum..4M1>0
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +## Parameter Kartensperre + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Karten- +sperre“. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
664		Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Zulässige Karte1DEan.40M1..99
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:2
+ + +### Parameter Kontoauszug + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Konto- +auszug“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Kontoauszugs- nummer erlaubt2DEjn#M1
2Quittierung be- nötigt2DEjn#M1
3Eingabe Anzahl Einträge erlaubt1DEjn#M1
4Unterstützte Kontoauszugs- formate2DEcode1M1..91, 2, 3
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:2
+ + +#### Parameter Kontoauszug camt + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Konto- +auszug“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Kontoauszugs- nummer erlaubt2DEjn#M1
2Quittierung be- nötigt2DEjn#M1
3Eingabe Anzahl Einträge erlaubt1DEjn#M1
4Unterstützte camt- Datenformate1DEan.256M.99
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +### Parameter Kontoauszug PDF + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Konto- +auszug PDF“. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Data Dictionary
SEPA-Zahlungsverkehr		Stand: 07.08.2015Seite: 665
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Kontoauszugs- nummer erlaubt2DEjn#M1
2Quittierung be- nötigt2DEjn#M1
3Eingabe Anzahl Einträge erlaubt1DEjn#M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +#### Parameter Kontoauszug PDF + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Konto- +auszug PDF". + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Kontoauszugs- nummer erlaubt2DEjn#M1
2Quittierung be- nötigt2DEjn#M1
3Eingabe Anzahl Einträge erlaubt1DEjn#M1
4base64 ko- diertbase64 ko diert14DED EjnjnMM14
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:2
+ + +#### Parameter Kontoinformationen + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall ,,Kontoin- +formationen“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Eingabe Anzahl Ein- träge erlaubtDEjn#M1
2Alle Konten erlaubtDEjn#M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +#### Parameter Kontoumsätze/neu + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Konto- +umsätze/neu“. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 666Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Speicherzeit- raum1DEnum..4M1>0
2Eingabe Anzahl Einträge erlaubt1DEjn#M1
3Alle Konten er- laubt1DEjn#M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +##### Parameter Kontoumsätze/neu camt + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall ,,Konto- +umsätze/neu (camt)“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Speicherzeit- raum1DEnum..4M1>0
2Eingabe Anzahl Einträge erlaubt1DEjn#M1
3Alle Konten er- laubt1DEjn#M1
4Unterstützte camt- Datenformate1DEan.256M.99
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +##### Parameter Kontoumsätze/Zeitraum + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Konto- +umsätze/Zeitraum“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Speicherzeit- raum1DEnum..4M1>0
2Eingabe Anzahl Einträge erlaubt1DEjn#M1
3Alle Konten er- laubt1DEjn#M1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 667
+ + +Typ: + +DEG + + + + + + + + + + + + + + + +
Format:
Länge:
Version:2
+ + +###### Parameter Kontoumsätze/Zeitraum camt + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Konto- +umsätze/Zeitraum (camt)“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Speicherzeit- raum1DEnum..4M1>0
2Eingabe Anzahl Einträge erlaubt1DEjn#M1
3Alle Konten er- laubt1DEjn#M1
4Unterstützte camt- Datenformate1DEan.256M.99
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +###### Parameter Kundenmeldung + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Kunden- +meldung". + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Maximale Län- ge1DEnum..4M1>0
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +####### Parameter Lastschrift + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Last- +schrift“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Maximale An- zahl Verwen- dungs- zweckzeilen1DEnum..2M1
2Zulässiger Textschlüssel1DEdig2M1..99
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
668		Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + +Typ: + +DEG + + + + + + + + + + + + + + + +
Format:
Länge:
Version:1
+ + +# Parameter Lastschriftwiderspruch + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Last- +schriftwiderspruch". + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Rückgabepreis1DEGbtg#O1
2Rückgabefähi- ge Textschlüs- sel1DEdig2M1..99
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +# Parameter Liste Neuemissionen + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Liste +Neuemissionen". + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Zulässige Emissionsfilter1DEnum1M1..9
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +# Parameter Löschung terminierter SEPA-Einzellastschrift + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Löschung +terminierter SEPA-Einzellastschriften“. + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Senden der Auftragsdaten erforderlich1DEjn#M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +# Parameter Löschung terminierter SEPA-Firmeneinzellastschrift + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Löschung +terminierter SEPA-Firmeneinzellastschriften“. + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:Data DictionaryStand:Seite:
Abschnitt:SEPA-Zahlungsverkehr07.08.2015669
+ + + + + + + + + + + + + + +
1Senden der Auftragsdaten erforderlich1DEjn#M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +## Parameter Löschung terminierter SEPA-Überweisungen + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Löschung +terminierter SEPA-Überweisungen“. + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Senden der Auftragsdaten erforderlich1DEjn#M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +## Parameter Neuemission zeichnen + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Neu- +emission zeichnen“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Wichtige Infor- mationen ver- pflichtend1DEjn#M1
2Begünstigter möglich1DEjn#M1
3Abweichendes Ver- rechnungskonto erlaubt2DEcode1M10-8
4Verrechnungs- konto verpflich- tend1DEjn#M1
5Telefonnummer verpflichtend1DEjn#M1
6Maximal zuläs- siger Auftrags- wert2DEGbtg#O1
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
670		Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + +Typ: + +DEG + + + + + + + + + + + + + + + +
Format:
Länge:
Version:2
+ + +# Parameter Orderanzeige + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Orderan- +zeige“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Nur selbst er- teilte Aufträge wählbar1DEjn#M1
2Längster zu- rückliegender Zeitpunkt1DEnum..3O1>1
3Zulässige Ab- fragen1DEnum..2C99N: keine Einschränkung der zulässigen Abfragen M: sonst
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:2
+ + +## Parameter Orderstatus + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Ordersta- +tus“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Nur selbst er- teilte Aufträge wählbar1DEjn#M1
2Längster zu- rückliegender Zeitpunkt1DEnum..3O1>1
3Zulässige Ab- fragen1DEnum..2C99N: keine Einschränkung der zulässigen Abfragen M: sonst
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:2
+ + +# Parameter Orderstatus + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Ordersta- +tus“. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Data Dictionary SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 671
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Nur selbst er- teilte Aufträge wählbar1DEjn#M1
2Orderauskunft gewünscht er- laubt1DEjn#M1
3Längster zu- rückliegender Zeitpunkt1DEnum..3O1>1
4Zulässige Ab- fragen1DEnum..2C99N: keine Einschränkung der zulässigen Abfragen M: sonst
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:3
+ + +## Parameter Postfach-Nachricht abrufen + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Postfach- +Nachricht abrufen". + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Eingabe Anzahl Einträge erlaubt1DEjn#M1
2Quittierung fall- weise benötigt1DEin#M1
3Formattyp er- laubt1DEjn#M1
4Alle Dokumente erlaubt1DEjn#M1
5Formatinforma- tion codiert3DEan.23M1-99
+ + +Typ: +DEG + +Format: + +Länge: + +Version: + +1 + + +### Parameter Postfach-Nachricht löschen + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Postfach- +Nachricht löschen“. + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Löschung unge- lesener Nach- richten erlaubt1DEjn#M1
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 672Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + +Typ: +DEG + +Format: + +Länge: + +Version: + +1 + + +#### Parameter Postfach-Nachrichtenliste anfordern + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Postfach- +Nachrichtenliste anfordern". + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Nachrichtentyp erlaubt1DEjn#M1
2Eingabe Anzahl Einträge erlaubt1DEin#M1
3Nachrichtentyp, codiert1DEan..64M1-99
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +#### Parameter Postfach-Nachrichtentypen anfordern + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Postfach- +Nachrichtentypen anfordern". + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Eingabe Anzahl Einträge erlaubt1DEjn#M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +#### Parameter Postfach-Nachrichtentypen auswählen + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Auswahl +Postfach-NachrichtentypenPostfach-Nachrichtentypen auswählen“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Bestätigungs- text strukturiert1DEjn#M1
2Willenserklä- rung erforder- lich1DEjn#M1
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:Data DictionaryStand:Seite:
Abschnitt:SEPA-Zahlungsverkehr07.08.2015673
+ + +Typ: +DEG + +Format: + +Länge: + +Version: + +1 + + +## Parameter Prepaidkarte laden + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Prepaid- +karte laden". + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Providermerk- male1DEGM.99
+ + +## Parameter Sammellastschrift + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Sammel- +lastschrift". + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Maximale An- zahl C-Sätze2DEnum..6M1
2Maximale An- zahl Ver- wendungs- zweckzeilen1DEnum..2M1
3Zulässiger Textschlüssel1DEdig2M1..99
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +## Parameter Sammelüberweisung + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Sammel- +überweisung“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Maximale An- zahl C-Sätze2DEnum..6M1
2Maximale An- zahl Ver- wendungs- zweckzeilen1DEnum..2M1
3Zulässiger Textschlüssel1DEdig2M1..99
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:2
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 674Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + +# Parameter terminierter SEPA-COR1-Einzellastschrift + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „terminier- +te SEPA-COR1- Einzellastschrift“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Minimale Vor- laufzeit FNAL/RCUR1DEnum..4M1>=1
2Maximale Vor- laufzeit FNAL/RCUR1DEnum..4M1
3Minimale Vor- laufzeit FRST/OOFF1DEnum..4M1>=1
4Maximale Vor- laufzeit FRST/OOFF1DEnum..4M1
5Zulässige Pur- pose codes1DEan.409 6O1
6Unterstützte SEPA- Datenformate1DEan256O..9
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +## Parameter terminierte SEPA-COR1-Sammellastschrift + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Termi- +nierte SEPA-COR1-Sammellastschrift". + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Data Dictionary SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 675
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Maximale An- zahl DirectDe- bitTransfer TransactionIn- formation1DEnum..7M1
2Summenfeld benötigt1DEjn1M1
3Einzelbuchung erlaubt1DEjn1M1
4Minimale Vor- laufzeit FNAL/RCUR1DEnum..4M1>=1
5Maximale Vor- laufzeit FNAL/RCUR1DEnum..4M1
6Minimale Vor- laufzeit FRST/OOFF1DEnum..4M1>=1
7Maximale Vor- laufzeit FRST/OOFF1DEnum..4M1
8Zulässige Pur- pose codes1DEan.409 6O1
9Unterstützte SEPA- Datenformate1DEan.256O..9
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +# Parameter SEPA Card Clearing Nachricht einreichen + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „SEPA +Card Clearing Nachricht einreichen“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Summenfeld benötigt1DEjn1M1
2CutOff-Zeit1DEtim#O1
3Unterstützte SEPA- Datenformate1DEan.256O..9
+ + +Typ: +DEG + +Format: + +Länge: + +Version: + +1 + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 676Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + +# Parameter SEPA-Dauerauftrag ändern + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „SEPA- +Dauerauftrag ändern“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Anzahl termi- nierter Ände- rungen1DEnum1M1
2Minimale Vor- laufzeit1DEnum..4M1
3Maximale Vor- laufzeit1DEnum..4M1
4CreditorAc- count/Agent änderbar1DEjn#M1
5Creditor änder- bar1DEjn#M1
6InstructedA- mount änderbar1DEjn#M1
7RemittanceIn- formation än- derbar1DEjn#M1
8Erstes Ausfüh- rungsdatum änderbar1DEjn#M1
9Zeiteinheit än- derbar1DEjn#M1
10Turnus änder- bar1DEjn#M1
11Ausführungstag änderbar1DEjn#M1
12Letztes Ausfüh- rungsdatum änderbar1DEjn#M1
13Turnus in Mo- naten1DEdig.24M1
14Ausführungsta- ge pro Monat1DEdig..64M1
15Turnus in Wo- chen1DEdig..104O1
16Ausführungsta- ge pro Woche1DEdig..7C1M: ,Turnus in Wochen" belegt N: sonst
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +# Parameter SEPA-Dauerauftrag aussetzen + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall ,SEPA- +Dauerauftrag aussetzen“. + + + + + + + + + + + + + + +
Nr.NameVer-TypFor-Län-Sta-An-Restriktionen
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Data Dictionary SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 677
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
sionmatgetuszahl
1Anzahl termi- nierter Aus- setzungen1DEnum1M1
2Minimale Vor- laufzeit1DEnum..4M1
3Maximale Vor- laufzeit1DEnum..4M1
4Aussetzungs- eingabe2DEcode1M11,2,3
5Aussetzung jährlich wie- derkehrend er- laubt1DEjn#M1
6Abweichender Betrag erlaubt1DEjn#M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +## Parameter SEPA-Dauerauftrag einrichten + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „SEPA- +Dauerauftrag einrichten“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Maximale An- zahl Verwen- dungszweck- zeilen1DEnum..2M1
2Minimale Vor- laufzeit1DEnum..4M1
3Maximale Vor- laufzeit1DEnum..4M1
4Turnus in Mo- naten1DEdig.24M1
5Ausfüh- rungstage pro Monat1DEdig..64M1
6Turnus in Wo- chen1DEdig.104O1
7Ausfüh- rungstage pro Woche1DEdig..7C1M: ,Turnus in Wochen" belegt N: sonst
+ + +![](figures/97.1) + + +Die DE" Maximale Anzahl Verwendungszweckzeilen“ ist +überflüssig und soll daher kundenproduktseitig nicht geprüft +werden. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
678		Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +### Parameter SEPA-Dauerauftrag löschen + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „SEPA- +Dauerauftrag löschen“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Minimale Vor- laufzeit1DEnum..4M1
2Maximale Vor- laufzeit1DEnum..4M1
3Löschung ter- minierbar1DEjn#M1
4Senden der Auftragsdaten erforderlich1DEjn#M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +### Parameter SEPA-Dauerauftragsbestand + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „SEPA- +Dauerauftragsbestand". + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Eingabe Anzahl Einträge erlaubt1DEjn1M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +### Parameter SEPA-Dauerauftragsänderungsvormerkungen + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „SEPA- +Dauerauftragsänderungsvormerkungen“. + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Eingabe Anzahl Einträge erlaubt1DEjn1M1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 679
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +# Parameter SEPA-Dauereinzellastschrift ändern + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „SEPA- +Dauereinzellastschrift ändern“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Anzahl termi- nierter Ände- rungen1DEnum1M1
2Minimale Vor- laufzeit1DEnum..4M1
3Maximale Vor- laufzeit1DEnum..4M1
4Kontoverbin- dung Zah- lungspflichtiger änderbar1DEjn#M1
5Name Zah- lungspflichtiger änderbar1DEjn#M1
6Betrag änder- bar1DEjn#M1
7Verwendungs- zweck änder- bar1DEjn#M1
8Erstes Ausfüh- rungsdatum änderbar1DEjn#M1
9Zeiteinheit än- derbar1DEjn#M1
10Turnus änder- bar1DEjn#M1
11Ausfüh- rungstag än- derbar1DEjn#M1
12Letztes Aus- führungsdatum änderbar1DEjn#M1
13Turnus in Mo- naten1DEdig.24M1
14Ausfüh- rungstage pro Monat1DEdig..64M1
15Turnus in Wo- chen1DEdig..104O1
16Ausfüh- rungstage pro Woche1DEdig..7C1M: ,Turnus in Wochen" belegt N: sonst
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 680Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
17Zulässige Pur- pose codes1DEan.409 6O1
18Unterstützte SEPA- Datenformate1DEan.256O.9
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +## Parameter SEPA-Dauereinzellastschrift aussetzen + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „SEPA- +Dauereinzellastschrift aussetzen“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Anzahl termi- nierter Aus- setzungen1DEnum1M1
2Minimale Vor- laufzeit1DEnum..4M1
3Maximale Vor- laufzeit1DEnum..4M1
4Aussetzungs- eingabe2DEcode1M11,2,3
5Aussetzung jährlich wie- derkehrend er- laubt1DEjn#M1
6Abweichender Betrag erlaubt1DEjn#M1
7Unterstützte SEPA- Datenformate1DEan.256O..9
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +# Parameter SEPA-Dauereinzellastschrift einrichten + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „SEPA- +Dauereinzellastschrift einrichten“. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Data Dictionary SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 681
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Unterstützte SEPA- Lastschriftarten1DEan..64M1
2Minimale Vor- laufzeit1DEnum..4M1
3Maximale Vor- laufzeit1DEnum..4M1
4Turnus in Mo- naten1DEdig.24M1
5Ausfüh- rungstage pro Monat1DEdig..64M1
6Turnus in Wo- chen1DEdig..104O1
7Ausfüh- rungstage pro Woche1DEdig..7C1M: ,,Turnus in Wochen" belegt N: sonst
8Zulässige Pur- pose codes1DEan.409 6O1
9Unterstützte SEPA- Datenformate1DEan.256O.9
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +## Parameter SEPA-Dauereinzellastschrift löschen + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „SEPA- +Dauereinzellastschrift löschen“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Minimale Vor- laufzeit1DEnum..4M1
2Maximale Vor- laufzeit1DEnum..4M1
3Löschung ter- minierbar1DEjn#M1
4Senden der Auftragsdaten erforderlich1DEjn#M1
5Unterstützte SEPA- Datenformate1DEan.256O..9
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 682Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + +Typ: + +DEG + + + + + + + + + + + + + + + +
Format:
Länge:
Version:1
+ + +## Parameter SEPA-Dauereinzellastschriftänderungsvormerkungen abrufen + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „SEPA- +Dauereinzellastschriftänderungsvormerkungen abrufen“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Eingabe An- zahl Einträge erlaubt1DEjn#M1
2Unterstützte SEPA- Datenformate1DEan.256O..9
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +## Parameter SEPA-Dauereinzellastschriftbestand abrufen + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „SEPA- +Dauereinzellastschriftbestand abrufen“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Eingabe An- zahl Einträge erlaubt1DEjn#M1
2Unterstützte SEPA- Datenformate1DEan.256O.9
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +## Parameter SEPA-Firmensammellastschrift + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „SEPA- +Firmensammellastschrift". + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Data Dictionary SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 683
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän geSta- tusAn- zahlRestriktionen
1Maximale An- zahl DirectDe- bitTransfer TransactionIn- formation1DEnum..7M1
2Summenfeld benötigt1DEjn1M1
3Einzelbuchung erlaubt1DEjn1M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +# Parameter SEPA-Kontoverbindung anfordern + +Mittels dieser DEG werden die Optionen für das Anfordern von SEPA- +Kontoverbindungen bestimmt. Außerdem werden die URIs der unterstützten +SEPA-Datenformate (pain messages) an das Kundenprodukt übermittelt. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Einzelkonten- abruf erlaubt1DEjn#M1
2Nationale Kon- toverbindung erlaubt1DEjn#M1
3Strukturierter Verwendungs- zweck erlaubt1DEjn#M1
4Unterstützte SEPA- Datenformate1DEan..25 6O.99
+ + +Typ: + +DEG + +Format: + +Länge: + +Version: + +1 + + +# Parameter SEPA-Kontoverbindung anfordern + +Mittels dieser DEG werden die Optionen für das Anfordern von SEPA- +Kontoverbindungen bestimmt. Außerdem werden die URIs der unterstützten +SEPA-Datenformate (pain messages) an das Kundenprodukt übermittelt. + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 684Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Einzelkonten- abruf erlaubt1DEjn#M1
2Nationale Kon- toverbindung erlaubt1DEjn#M1
3Strukturierter Verwendungs- zweck erlaubt1DEjn#M1
4Eingabe Anzahl Einträge erlaubt1DEjn#M1
5Unterstützte SEPA- Datenformate1DEan.25 6O.99
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:2
+ + +## Parameter SEPA-Kontoverbindung anfordern + +Mittels dieser DEG werden die Optionen für das Anfordern von SEPA- +Kontoverbindungen bestimmt. Außerdem werden die URIs der unterstützten +SEPA-Datenformate (pain messages) an das Kundenprodukt übermittelt. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Einzelkonten- abruf erlaubt1DEjn#M1
2Nationale Kon- toverbindung erlaubt1DEjn#M1
3Strukturierter Verwendungs- zweck erlaubt1DEjn#M1
4Eingabe Anzahl Einträge erlaubt1DEjn#M1
5Anzahl reser- vierter Verwen- dungszweck- stellen1DEnum..2M1
6Unterstützte SEPA- Datenformate1DEan.25 6O.99
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:3
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Data Dictionary SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 685
+ + +# Parameter SEPA-Lastschriftwiderspruch + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Senden der Auftragsdaten erforderlich1DEjn#M1
2Rückgabepreis1DEGbtg#O1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +## Parameter SEPA-Statusreport + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall ,,SEPA- +Statusreport". + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Eingabe Anzahl Einträge erlaubt1DEjn#M1
2Zeitraum mög- lich1DEjn#M1
3Unterstützte SEPA- Datenformate1DEan.256O..9
+ + +Typ: +DEG + +Format: + +Länge: + +Version: + +1 + + +## Parameter Sammeleilzahlung + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Samme- +leilzahlung“. + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 686Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Maximale An- zahl Cre- ditTransfer- TransactionIn- formation1DEnum..7M1
2Summenfeld benötigt1DEjn1M1
3Einzelbuchung erlaubt1DEjn1M1
4Zulässige Pur- pose codes1DEan.409 6O1
5Unterstützte SEPADaten- formate1DEan..256O..9
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +# Parameter SEPA-Sammellastschrift + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „SEPA- +Sammellastschrift". + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän geSta- tusAn- zahlRestriktionen
1Maximale An- zahl DirectDe- bitTransfer TransactionIn- formation1DEnum..7M1
2Summenfeld benötigt1DEjn1M1
3Einzelbuchung erlaubt1DEjn1M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +# Parameter SEPA-Sammelüberweisung + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „SEPA- +Sammelüberweisung“. + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:Data DictionaryStand:Seite:
Abschnitt:SEPA-Zahlungsverkehr07.08.2015687
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
6Maximale An- zahl Cre- ditTransfer- TransactionIn- formation1DEnum..7M1
7Summenfeld benötigt1DEjn1M1
8Einzelbuchung erlaubt1DEjn1M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +## Parameter SEPA-Überweisung auf ein Empfängerkonto + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „SEPA- +Überweisung auf ein Empfängerkonto“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Zulässige Pur- pose Codes1DEan..409 6M1
2Unterstützte SEPA Daten- formate1DEan.256O..9
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +## Parameter Sorten- und Reisescheckbestellung + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Sorten- +und Reisescheckbestellung“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Gewünschtes Ausführungs- datum erlaubt1DEjn#M1
2Minimale Vor- laufzeit1DEnum..4M1
3Maximale Vor- laufzeit1DEnum..4M1
4Bestellkonditio- nen benötigt1DEjn#M1
5Erlaubte Bestel- lung1DEan.20O1..99
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 688Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + +Typ: + +DEG + + + + + + + + + + + + + + + +
Format:
Länge:
Version:1
+ + +# Parameter Sorten- und Reisescheckkonditionen + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Sorten- +und Reisescheckkonditionen“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Abrechnungs- währung Lan- deswährung er- laubt1DEjn#M1
2Abrechnungs- währung Euro erlaubt1DEjn#M1
3Produktart Sor- ten, Reise- schecks2DEcode1M1..31, 2, 3
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:2
+ + +# Parameter terminierte Einzellastschrift ändern + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall "Termi- +nierte Einzellastschrift ändern". + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Minimale Vor- laufzeit1DEnum.4M1
2Maximale Vor- laufzeit1DEnum..4M1
3Maximale An- zahl Verwen- dungszweck- zeilen1DEnum..2M1
4Zulässiger Textschlüssel1DEdig2M1..99
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +# Parameter terminierte Einzellastschrift einreichen + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall "Termi- +nierte Einzellastschrift einreichen". + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Data Dictionary SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 689
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Minimale Vor- laufzeit1DEnum..4M1
2Maximale Vor- laufzeit1DEnum..4M1
3Maximale An- zahl Verwen- dungszweck- zeilen1DEnum..2M1
4Zulässiger Textschlüssel1DEdig2M1..99
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +## Parameter terminierte Sammellastschrift einreichen + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Termi- +nierte Sammellastschrift einreichen“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Minimale Vor- laufzeit1DEnum..4M1>=1
2Maximale Vor- laufzeit1DEnum..4M1
3Maximale An- zahl C-Sätze2DEnum..6M1
4Maximale An- zahl Verwen- dungszweck- zeilen1DEnum..2M1
5Zulässiger Textschlüssel1DEdig2M1..99
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:2
+ + +## Parameter terminierte SEPA-Einzellastschrift ändern + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Termi- +nierte SEPA-Einzellastschrift ändern“. + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 690Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Minimale Vor- laufzeit FNAL/RCUR1DEnum..4M1>=1
2Maximale Vor- laufzeit FNAL/RCUR1DEnum..4M1
3Minimale Vor- laufzeit FRST/OOFF1DEnum..4M1>=1
4Maximale Vor- laufzeit FRST/OOFF1DEnum..4M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +### Parameter terminierte SEPA-Einzellastschrift einreichen + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Termi- +nierte SEPA-Einzellastschrift einreichen". + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Minimale Vor- laufzeit FNAL/RCUR1DEnum..4M1>=1
2Maximale Vor- laufzeit FNAL/RCUR1DEnum..4M1
3Minimale Vor- laufzeit FRST/OOFF1DEnum..4M1>=1
4Maximale Vor- laufzeit FRST/OOFF1DEnum..4M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +### Parameter terminierter SEPA-Einzellastschrift einreichen + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Termi- +nierte SEPA-Einzellastschrift einreichen“. + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Data Dictionary SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 691
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Minimale Vor- laufzeit SEPA- Last- schriftMinimale Vorlaufzeit SEPA Lastschrift14DED Eanan.99.- 99M414
2Maximale Vor- laufzeit SEPA- Last- schriftMaximale Vorlaufzeit SEPA- Lastschrift14DED Eanan.99.- 99M414
3Zulässige Pur- pose codesZulässige Purpose codes14DED Eanan409 6..40 9614
4Unterstützte SEPA- Datenformate Unterstützte SEPA- Datenformate14DE DEan an256- .256..9.9
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:22
+ + +## Parameter terminierte SEPA-Firmeneinzellastschrift ändern + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Termi- +nierte SEPA-Firmeneinzellastschrift ändern“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Minimale Vor- laufzeit FNAL/RCUR1DEnum..4M1>=1
2Maximale Vor- laufzeit FNAL/RCUR1DEnum..4M1
3Minimale Vor- laufzeit FRST/OOFF1DEnum..4M1>=1
4Maximale Vor- laufzeit FRST/OOFF1DEnum..4M1
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 692Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + +Typ: + +DEG + + + + + + + + + + + + + + + +
Format:
Länge:
Version:1
+ + +### Parameter terminierte SEPA-Firmeneinzellastschrift einreichen + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall ,,Termi- +nierte SEPA-Firmeneinzellastschrift einreichen“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Minimale Vor- laufzeit FNAL/RCUR1DEnum..4M1>=1
2Maximale Vor- laufzeit FNAL/RCUR1DEnum..4M1
3Minimale Vor- laufzeit FRST/OOFF1DEnum..4M1>=1
4Maximale Vor- laufzeit FRST/OOFF1DEnum..4M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +#### Parameter terminierte SEPA-Firmeneinzellastschrift einreichen + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Termi- +nierte SEPA-Firmeneinzellastschrift einreichen“. + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:Data DictionaryStand:Seite:
Abschnitt:SEPA-Zahlungsverkehr07.08.2015693
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Minimale Vor- laufzeit SEPA- Firmenlast- schriftMinimale Vorlaufzeit SEPA Firmenlastschrift14DE DEanan..99.- 99MA414
2Maximale Vor- laufzeit SEPA- Firmenlast- schriftMaximale Vorlaufzeit SEPA- Firmenlastschrift14DE DEanan.99.- 99M414
3Zulässige Pur- pose codesZulässige Purpose codes14DE DEanan.409 6..40 9614
4Unterstützte SEPA- Datenformate Unterstützte SEPA Datenformate14DE DEan an.256- .256..9..9
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:22
+ + +#### Parameter terminierte SEPA-Firmensammellastschrift einreichen + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Termi- +nierte SEPA-Firmensammellastschrift einreichen". + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geStatusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 694Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Minimale Vor- laufzeit FNAL/RCUR1DEnum..4M1>=1
2Maximale Vor- laufzeit FNAL/RCUR1DEnum..4M1
3Minimale Vor- laufzeit FRST/OOFF1DEnum..4M1>=1
4Maximale Vor- laufzeit FRST/OOFF1DEnum..4M1
5Maximale Anzahl DirectDebi- tTransfer TransactionIn- formation1DEnum..7M1
6Summenfeld be- nötigt1DEjn1M1
7Einzelbuchung erlaubt1DEjn1M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +#### Parameter terminierte SEPA-Firmensammellastschrift einreichen + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall ,,Termi- +nierte SEPA-Firmensammellastschrift einreichen“. + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geStatusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Data Dictionary SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 695
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Minimale Vor- laufzeit SEPA- Firmenlast- schriftMinimale Vorlaufzeit SEPA Firmenlastschrift11DED Eanan99.- 99MM14
2Maximale Vor- laufzeit SEPA- Firmenlast- schriftMaximale Vorlaufzeit SEPA- Firmenlastschrift14DED Eanan99.- 99MM14
3Maximale Anzahl DirectDebi- tTransfer TransactionIn- formation1DEnum..7M1
4Summenfeld be- nötigt1DEjn1M1
5Einzelbuchung erlaubt1DEjn1M1
6Zulässige Purpo- se codesZulässige Purpose codes14DED Eanan409 6..40 9614
7Unterstützte SEPA- Datenformate Unterstützte SEPA- Datenformate14DE DEan an256 ..256..9..9
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:22
+ + +#### Parameter terminierte SEPA-Sammellastschrift einreichen + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Termi- +nierte SEPA-Sammellastschrift einreichen". + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geStatusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 696Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Minimale Vor- laufzeit FNAL/RCUR1DEnum..4M1>=1
2Maximale Vor- laufzeit FNAL/RCUR1DEnum..4M1
3Minimale Vor- laufzeit FRST/OOFF1DEnum..4M1>=1
4Maximale Vor- laufzeit FRST/OOFF1DEnum..4M1
5Maximale Anzahl DirectDebi- tTransfer TransactionIn- formation1DEnum..7M1
6Summenfeld be- nötigt1DEjn1M1
7Einzelbuchung erlaubt1DEjn1M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +#### Parameter terminierte SEPA-Sammellastschrift einreichen + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Termi- +nierte SEPA-Sammellastschrift einreichen“. + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Data Dictionary SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 697
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Minimale Vor- laufzeit SEPA- Lastschrift1DEan..99M1
2Maximale Vor- laufzeit SEPA- Lastschrift1DEan.99M1
13Maximale An- zahl -DirectDe- bitTransfer TransactionIn- formation1DEnum..7M1
24Summenfeld benötigt1DEjn1M1
35Einzelbuchung erlaubt1DEjn1M1
4Minimale Vor- laufzeit SEPA Lastschrift1DEan..99M1
5Maximale Vor laufzeit SEPA- Lastschrift1DEan..99M1
6Zulässige Pur- pose codesZulässige Purpose codes14DED Eanan409 6..40 9614
7Unterstützte SEPA- Datenformate Unterstützte SEPA- Datenformate14DE DEan an.256- .256..9..9
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:22
+ + +#### Parameter terminierte Sammelüberweisung einreichen + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Termi- +nierte Sammelüberweisung einreichen“. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 698Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Minimale Vor- laufzeit1DEnum..4M1>=1
2Maximale Vor- laufzeit1DEnum..4M1
3Maximale An- zahl C-Sätze2DEnum..6M1
4Maximale An- zahl Verwen- dungszweck- zeilen1DEnum..2M1
5Zulässiger Textschlüssel1DEdig2M1..99
+ + +Typ: + +DEG + +Format: + +Länge: + +Version: + +2 + + +### Parameter terminierte SEPA-Sammelüberweisung einreichen + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall ,,Termi- +nierte SEPA-Sammelüberweisung einreichen“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geStatusAn- zahlRestriktionen
1Minimale Vor- laufzeit1DEnum..4M1>=1
2Maximale Vor- laufzeit1DEnum..4M1
3Maximale Anzahl CreditTransfer- TransactionIn- formation1DEnum..7M1
4Summenfeld be- nötigt1DEjn1M1
5Einzelbuchung erlaubt1DEjn1M1
+ + +Typ: + +DEG + +Format: + +Länge: + +Version: + +1 + + +#### Parameter terminierte SEPA-Überweisung ändern + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall ,,Termi- +nierte SEPA-Überweisung ändern“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Minimale Vor- laufzeit1DEnum..4M1
2Maximale Vor- laufzeit1DEnum..4M1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 699
+ + +Typ: + +DEG + + + + + + + + + + + + + + + +
Format:
Länge:
Version:1
+ + +##### Parameter terminierte SEPA-Überweisung einreichen + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall ,,Termi- +nierte SEPA-Überweisung einreichen“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Minimale Vor- laufzeit1DEnum..4M1
2Maximale Vor- laufzeit1DEnum..4M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +##### Parameter terminierte Überweisung ändern + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall ,,Termi- +nierte Überweisung ändern“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Minimale Vor- laufzeit1DEnum..4M1
2Maximale Vor- laufzeit1DEnum..4M1
3Maximale An- zahl Verwen- dungszweck- zeilen1DEnum..2M1
4Zulässiger Textschlüssel1DEdig2M1..99
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +##### Parameter terminierte Überweisung einreichen + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Termi- +nierte Überweisung einreichen“. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 700Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Minimale Vor- laufzeit1DEnum..4M1
2Maximale Vor- laufzeit1DEnum..4M1
3Maximale An- zahl Verwen- dungszweck- zeilen1DEnum..2M1
4Zulässiger Textschlüssel1DEdig2M1..99
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +###### Parameter Übersicht institutsverwalteter Aufträge anfordern + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Übersicht +institutsverwalteter Aufträge“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Eingabe Anzahl Einträge erlaubt1DEjn#M1
2Alle Konten er- laubt1DEjn#M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +###### Parameter Übersicht institutsverwalteter Aufträge anfordern + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Übersicht +institutsverwalteter Aufträge“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLängeSta- tusAn- zahlRestriktionen
1Eingabe Anzahl Einträge erlaubt1DEjn#M1
2Alle Konten er- laubt1DEjn#M1
3Unterstützte SEPA- Datenformate1DEan.256O..9
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 701
+ + +Typ: + +DEG + +Format: + +Länge: + +Version: + +42 + + +### Parameter vorbereitete SEPA-Überweisung löschen + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „vorberei- +tete SEPA-Überweisung löschen“. + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Senden der Auf- tragsdaten erfor- derlich1DEjn#M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +#### Parameter Vordruckbestellung + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Vor- +druckbestellung“. + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Formular1DEGM1..99
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +#### Parameter Vormerkposten anfordern + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall ,,Vormerk- +posten anfordern". + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
6Eingabe Anzahl Einträge erlaubt1DEjn#M1
7Alle Konten er- laubt1DEjn#M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +### Parameter Wertpapierinformationen + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Wertpa- +pierinformationen“. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 702Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Depot erforder- lich1DEjn#M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +## Parameter Wertpapierkurse + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Wertpa- +pierkurse". + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Depot erforder- lich1DEjn#M1
2Kursqualität wählbar1DEjn#M1
3Zulässige Bör- senplätze2DEan.. 4096C1N: keine Einschränkung bzw. Selektion nach Börsenplätzen nicht zu- gelassen M: sonst
4Kurspaket1DEan..30O99
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:2
+ + +## Parameter Wertpapierorder + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Wertpa- +pierorder“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Region2DEcode1M10, 1, 2
2Wichtige Infor- mationen ver- pflichtend1DEjn#M1
3Abweichendes Ver- rechnungskonto erlaubt2DEcode1M10-8
4Verrechnungs- konto verpflich- tend1DEjn#M1
5Telefonnummer verpflichtend1DEjn#M1
6Zulässige Bör- senplätze2DEan. . 4096C1N: keine Einschränkung bzw. Selektion nach Börsenplätzen nicht zu- gelassen
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Data Dictionary
SEPA-Zahlungsverkehr		Stand: 07.08.2015Seite: 703
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
M: sonst
7Gültigkeitsdau- er XETRA1DEnum..3O1
8Gültigkeitsdau- er Parkett2DEcode1O11, 2, 3, 4, 5
9Maximal zuläs- siger Auftrags- wert2DEGbtg#O1
10Zulässige Li- mitarten1DEan.99M1
11Zulässige Or- derarten1DEan.99O1
12Zulässige Zeit- limits1DEan.99M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:3
+ + +### Parameter Wertpapierorderänderung + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Wertpa- +pierorderänderung“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Art des Limits änderbar1DEjn#M1
2Zulässige Li- mitarten1DEan.99C1M: „Art des Limits än- derbar" = J N: sonst
3Preislimit än- derbar1DEjn#M1
4Art des Zeitli- mits änderbar1DEjn#M1
5Zulässige Zeit- limits1DEan.99C1M: „Art des Zeitlimits än- derbar" = J N: sonst
6Zeitlimit änder- bar1DEjn#M1
7Verrechnungs- konto änderbar2DEcode1M10, 1, 2
8Telefonnummer verpflichtend1DEjn#M1
9Nominale än- derbar1DEjn#M1
10Wichtige Infor- mationen ver- pflichtend1DEjn#M1
11Maximal zuläs- siger Auftrags- wert2DEGbtg#O1
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
704		Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + +Typ: + +DEG + + + + + + + + + + + + + + + +
Format:
Länge:
Version:3
+ + +#### Parameter Wertpapierorderänderung + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Wertpa- +pierorderänderung“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Art des Limits änderbar1DEjn#M1
2Zulässige Li- mitarten1DEan.99C1M: „Art des Limits än- derbar" = J N: sonst
3Preislimit än- derbar1DEjn#M1
4Stopplimit än- derbar1DEjn#M1
5Zweites Preis- limit änderbar1DEjn#M1
6Trailingabstand änderbar1DEjn#M1
7Art des Zeitli- mits änderbar1DEjn#M1
8Zulässige Zeit- limits1DEan..99C1M: „Art des Zeitlimits än- derbar" = J N: sonst
9Zeitlimit änder- bar1DEjn#M1
10Verrechnungs- konto änderbar2DEcode1M10, 1, 2
11Telefonnummer verpflichtend1DEjn#M1
12Nominale än- derbar1DEjn#M1
13Wichtige Infor- mationen ver- pflichtend1DEjn#M1
14Maximal zuläs- siger Auftrags- wert2DEGbtg#O1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:4
+ + +#### Parameter Wertpapierorderhistorie + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Wertpa- +pierorderhistorie“. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Data Dictionary SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 705
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Nur selbst er- teilte Aufträge1DEjn#M1
2Längster zu- rückliegender Zeitpunkt1DEnum.3O1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +##### Parameter Wertpapierorderstreichung + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Wertpa- +pierorderstreichung". + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Depot erforder- lich1DEjn#M1
2Wichtige Infor- mationen ver- pflichtend1DEjn#M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:2
+ + +##### Parameter Wertpapierreferenznummern + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Wertpa- +pierreferenznummern“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Suchbegriff er- laubt1DEjn#M1
2Region erlaubt1DEjn#M1
3Standardange- bot erlaubt1DEjn#M1
4Neuemissionen erlaubt1DEjn#M1
5Zulässige Bör- senplätze2DEan.٠ 4096C1N: keine Einschränkung bzw. Selektion nach Börsenplätzen nicht zu- gelassen M: sonst
6Zulässige Wert- papiergruppe1DEan.35O99
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:2
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 706Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + +# Parameter Wertpapierstammdaten + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Wertpa- +pierstammdaten“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Depot erforder- lich1DEjn#M1
2Risikoklasse des Wert- papiers, Bedeu- tung1DEan.38M1..99
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +# Parameter Wichtige Informationen + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Wichtige +Informationen“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Auftragsidentifi- kation erlaubt1DEjn#M1
2Ordernummer erlaubt1DEjn#M1
3Zulässige Kate- gorien1DEan.30M1..99
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:2
+ + +## Parameter Willenserklärung des Kunden + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall ,,Willenser- +klärung des Kunden“. + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Bestätigungs- text strukturiert1DEjn#M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +## Personendaten + +Angaben zu einer natürlichen Person. + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:Data DictionaryStand:Seite:
Abschnitt:SEPA-Zahlungsverkehr07.08.2015707
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Anrede2DEcode1O10, 1, 2, 3, 4, 5, 6
2Titel2DEan.30O1
3Vorname2DEan..30O1
4Name3DEan.30M1
5Geburtsdatum2DEdat#O1
6Geburtsname2DEan.30O1
7Familienstand2DEcode1M11, 2, 3, 4
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:2
+ + +PLZ + +Postleitzahl in einer Adresse. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:.. 10
Version:1
+ + +### Postfach + +Angabe des Postfachs in der Adresse. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:.. 10
Version:2
+ + +#### Preislimit + +Limitangabe zu einer Wertpapierorder, ausgedrückt als Betrag. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:btg
Länge:#
Version:2
+ + +#### Preislimit änderbar + +Kennzeichen dafür, ob kreditinstitutsseitig eine Änderung dieses Parameters +zulässig ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +#### Preislimit, Wert + +Limitangabe zu einer Wertpapierorder, ausgedrückt als Wert. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
708		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:wrt
Länge:#
Version:1
+ + +# Preisspanne bis + +Endwert der Bookbuilding-Preisspanne. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:btg
Länge:#
Version:3
+ + +# Preisspanne von + +Anfangswert der Bookbuilding-Preisspanne. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:btg
Länge:#
Version:3
+ + +# Preisspanne, Erläuterung + +Erläuterung zur Preisspanne. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:txt
Länge:..80
Version:1
+ + +## Primanota + +Kennzeichnung einer Gruppe von zusammengehörigen Buchungssätzen. +Die Primanota dient als Zuordnungs- bzw. Zugriffsinformation. Sie wird +bspw. im Format MT 940 mitgeteilt. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:.. 10
Version:1
+ + +# Produktart Sorten, Reiseschecks + +Information über die kreditinstitutsseitig zugelassenen Möglichkeiten für den +Abruf von Sorten- und Reisescheckkonditionen. + +Codierung: + +1: Sorten + +2: Reiseschecks + +3: Reiseschecks für zwei Unterschriften + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:2
+ + +# Prolongation + +Daten, die für einen Prolongationsauftrag benötigt werden. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Data Dictionary
SEPA-Zahlungsverkehr		Stand: 07.08.2015Seite: 709
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Prolongations- laufzeit1DEnum.3M1
2Anlagebetrag neu1DEGbtg#M1
3Wiederanla- gekennzeichen bei Prolongati- on2DEcode1M11,2
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:2
+ + +## Prolongationslaufzeit + +Laufzeit der Prolongation, die gemäß der Konditionen zulässig ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..3
Version:1
+ + +## Providermerkmale + +Einzustellen sind die vom Kreditinstitut unterstützten Provider inklusive deren +Kartenbezeichnung sowie die Ladebeträge. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
710		Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Mobilfunk- Provider1DEnum..2M1
2Name Mobil- funk-Provider1DEan.35M1
3Kartenbezeich- nung/Produktna me1DEan..35M1
4Freie Betrags- wahl erlaubt1DEjn1M1
5Minimaler La- debetrag Pre- paid1DEnum..3C1M: DE ,,Freie Betrags- wahl erlaubt" = J N: sonst
6Maximaler La- debetrag Pre- paid1DEnum..3C1M: DE ,,Freie Betrags- wahl erlaubt" = J N: sonst
7Mögliche Lade- beträge1DEan..99C1M: DE ,,Freie Betrags- wahl erlaubt“ = N N: sonst
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +## Prozentlimit + +Limitangabe zu einer Wertpapierorder, ausgedrückt in Prozent für prozent- +notierte Papiere. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:wrt
Länge:#
Version:1
+ + +Q + + +### Quittierung + +Codierung: + +0: Nicht notwendig + +1: Quittiert + +2: Quittung offen + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:1
+ + +Quittierung am + +Gibt an, wann eine Nachricht quittiert wurde. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 711
+ + + + + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dat
Länge:#
Version:1
+ + +#### Quittierung benötigt + +Das Kreditinstitut hat anzugeben, ob der korrekte Empfang der Kreditinsti- +tutsnachricht vom Kunden mit einer Empfangsmeldung (Geschäftsvorfall +„Quittierung“) zu quittieren ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:2
+ + +#### Quittierung bis + +Gibt an, bis wann eine Nachricht quittiert werden soll. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dat
Länge:#
Version:1
+ + +#### Quittierung fallweise benötigt + +Das Kreditinstitut hat anzugeben, ob der korrekte Empfang der Kreditinsti- +tutsnachricht vom Kunden mit einer Empfangsmeldung (Geschäftsvorfall +,Quittierung") zu quittieren ist. Ob eine Quittierung notwendig ist, richtet sich +danach, ob in der Kreditinstitutsnachricht ein Quittungscode mitgeliefert wur- +de. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:in
Länge:#
Version:1
+ + +#### Quittungscode + +Dieses Merkmal (z.B. ein Hash) kann - wenn es vom Institut gefordert wird - +bei der Quittierung mit zurückgegeben werden, damit das Institut den zu quit- +tierenden Auftrag zuordnen kann. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:bin
Länge:..
Version:1
+ + +R + + +### Referenz + +Referenzen eines Einzelauftrags innerhalb eines SEPA-Sammelauftrags. +Basis sind die SEPA-Tags wie z. B. die , aus de- +nen das Kreditinstitut eine eindeutige Referenz aufbaut. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
712		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + +Typ: + +DE + + + + + + + + + + + + + + + +
Format:an
Länge:.99
Version:1
+ + +#### Referenz auf wichtige Informationen + +Information zur Referenzierung auf Wertpapierinformationen, die im Kunden- +system vorliegen und aktualisiert oder zum ersten Mal angefordert werden. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Art der wichti- gen Informatio- nen2DEcode1M11, 2
2Kategorie der wichtigen In- formationen1DEan..30O1
3Datum1DEdat#M1
4Versionsnum- mer1DEnum.3M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:2
+ + +##### Referenzart + +Art der Referenzierung auf Wertpapierinformationen. + +Codierung: + +1: ISIN + +2: WKN + +3: kreditinstitutsinterne Referenz + +4: Indexname + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:2
+ + +###### Referenzkonto + +Angabe des Referenzkontos, wenn für das Konto ein Referenzkonto besteht, +bspw. bei Kreditkartenkonten. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:ktv
Länge:#
Version:3
+ + +###### Referenzkonto + +Angabe des Referenzkontos, wenn für das Konto ein Referenzkonto besteht, +bspw. bei Kreditkartenkonten. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 713
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:kti
Länge:#
Version:4
+ + +##### Referenznummer + +Information zur Referenzierung auf einen Auftrag, die dem Kunden bei der +Einreichung des Finanzdatenformats mitgeteilt wurde. Diese kann der Kunde +angeben, um gezielt den Bearbeitungsstatus des zugehörigen Auftrags an- +zufordern. Gibt er keine Referenznummer an, so wird ihm der Bearbeitungs- +status aller offenen Aufträge mitgeteilt. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:id
Länge:#
Version:1
+ + +##### Region + +Information zur Einschränkung der zulässigen Börsenplätze auf eine Region. + +Sollen z.B. die zulässigen Wertpapiergeschäfte nur an inländischen Börsen- +plätzen möglich sein, so wird das Kennzeichen "1" gesetzt. Im Rahmen der +EWWU gelten alle Börsenplätze der an der EWWU teilnehmenden Länder +als Inland. Weitere Einschränkungen müssen durch die Wahl der zulässigen +Börsenplätze erfolgen. Entsprechend ist bei nur ausländischen Börsenplät- +zen das Kennzeichen ,,2" zu setzen. + +Für außerbörsliche Geschäfte ist diese Angabe nicht verbindlich. + +Codierung: + +0: keine Einschränkung + +1: nur Inland + +2: nur Ausland + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:2
+ + +##### Region erlaubt + +Kennzeichen dafür, ob die Einschränkung der Region im Kundenauftrag zu- +lässig ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +##### RemittanceInformation änderbar + +Kennzeichen dafür, ob der Verwendungszweck (RemittanceInformation +) eines SEPA-Dauerauftrags durch den Kunden änderbar ist. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
714		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +#### Rendite + +Rendite eines Wertpapiers in Prozent. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:wrt
Länge:#
Version:1
+ + +#### Restfreistellungsbetrag + +Information darüber, in welcher Höhe die Zinserträge für das noch verblei- +bende Jahr der Gültigkeit von der Zinsabschlagsteuer befreit sind. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:btg
Länge:#
Version:3
+ + +#### Risikoklasse des Benutzers + +Risikoklasse des Benutzers, die zu Informationszwecken angegeben werden +kann, falls es sich beim Konto um ein Wertpapierdepot handelt. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..2
Version:1
+ + +#### Risikoklasse des Wertpapiers + +Risikoklasse des Wertpapiers, mit der der Kunde z.B. prüfen kann, ob er die- +ses Wertpapier in Abhängigkeit von seiner eigenen Risikoklasse tatsächlich +zeichnen darf. Die Angabe erfolgt über ein numerisches oder alphanumeri- +sches Identifikationskennzeichen mit maximal 2 Zeichen. Die Risikoklassen- +systematik des Kreditinstituts wird in den Bankparameterdaten übermittelt. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..2
Version:1
+ + +#### Risikoklasse des Wertpapiers, Bedeutung + +Informationen zu den institutseigenen Risikoklassen und deren Bedeutung. +Die Angaben erfolgen über ein beliebiges numerisches oder alphanumeri- +sches Identifikationskennzeichen mit maximal 2 Zeichen für den Code der +Risikoklasse und mit maximal 35 Zeichen für die zugehörige institutsspezi- +fische Bezeichnung bzw. Bedeutung. Code und Bedeutung werden hinterei- +nander gestellt, per Semikolon getrennt und dürfen eine Gesamtlänge von +38 Zeichen nicht übersteigen. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 715
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..38
Version:1
+ + +# Rückgabefähige Textschlüssel + +Textschlüssel, bei denen ein Lastschriftwiderspruch möglich ist. Im Regelfall +ist ein Widerspruch nur beim „Einspruchsermächtigungsverfahren (Text- +schlüssel ,05') möglich. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dig
Länge:2
Version:1
+ + +## Rückgabegrund + +Grund für die Rückgabe bei Lastschriftwiderspruch. + +Codierung: + +MD01: kein Mandat vorhanden + +MD06: Widerspruch gegen eine autorisierte Lastschrift + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:4
Version:1
+ + +## Rückgabepreis + +Preis für den Lastschriftwiderspruch. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:btg
Länge:#
Version:1
+ + +## Rücknahmepreis + +Preis, zu dem ein Fondsanteil von der Investmentgesellschaft zurückge- +nommen wird. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:rate
Länge:#
Version:1
+ + +S + + +# Saldo der vorgemerkten Umsätze + +Saldo der noch nicht verbuchten Umsätze. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
716		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:sdo
Länge:#
Version:2
+ + +# Segmentkennung + +Segmentspezifische Kennung, die jedem Segment bzw. Auftrag zugeordnet +ist (z.B. "HKUEB" für "Einzelüberweisung"). Die Angabe hat in Großschrei- +bung zu erfolgen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..6
Version:1
+ + +# Segmentkopf + +Informationen, die jedem Segment als Kopfteil vorangestellt sind. Im Unter- +schied zu Nachrichten enthalten Segmente jedoch keinen Abschlussteil, da +das Segmentende durch das Segmentende-Zeichen markiert ist. + +Im Segmentkopf stehen die Segmentkennung und Segmentversion unab- +hängig von der HBCI-Version (s. DE HBCI-Version) immer an derselben +Stelle, damit ein Segment auch in späteren HBCI-Versionen immer eindeutig +als solches identifiziert werden kann. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segment- kennung1DEan..6M1
2Segmentnum- mer1DEnum..3M1>=1
3Segment- version1DEnum..3M1
4Bezugssegment1DEnum..3C1>=1
O: Verwendung in Kre- ditinstitutsnachricht N: Verwendung in Kun- dennachricht
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +# Segmentnummer + +Information zur eindeutigen Identifizierung eines Segments innerhalb einer +Nachricht. Die Segmente einer Nachricht werden in Einerschritten streng +monoton aufsteigend nummeriert. Die Nummerierung beginnt mit 1 im ersten +Segment der Nachricht (Nachrichtenkopf). + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Data Dictionary
SEPA-Zahlungsverkehr		Stand: 07.08.2015Seite:
717
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..3
Version:1
+ + +# Segmentversion + +Versionsnummer zur Dokumentation von Änderungen eines Segmentfor- +mats. + +Die Segmentversion von administrativen Segmenten (die Segmentart 'Admi- +nistration' bzw. 'Geschäftsvorfall' ist bei jeder Segmentbeschreibung ange- +geben) wird bei jeder Änderung des Segmentformats inkrementiert. + +Bei Geschäftsvorfallssegmenten wird die Segmentversion auf logischer Ebe- +ne verwaltet, d.h. sie ist für das Auftrags-, das Antwort- und das Parame- +tersegment des Geschäftsvorfalls stets identisch und wird inkrementiert, +wenn sich das Format von mindestens einem der drei Segmente ändert. + +Dieses Verfahren gilt bei Standardsegmenten einheitlich für alle Kreditinsti- +tute. Bei verbandsindividuellen Segmenten obliegt die Versionssteuerung +dem jeweiligen Verband. Der Zeitpunkt der Unterstützung einer neuen Seg- +mentversion kann jedoch zwischen den Verbänden variieren. + +Die für die jeweilige HBCI-Version gültige Segmentversion ist bei der jeweili- +gen Segmentbeschreibung vermerkt. + +Falls der Kunde ein Segment mit einer veralteten Versionsnummer einreicht, +sollte ihm in einer entsprechenden Warnung rückgemeldet werden, dass +sein Kundenprodukt aktualisiert werden sollte. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..3
Version:1
+ + +# Seltene Währung + +Kennzeichen dafür, ob die Währung schwierig zu beschaffen ist. Der Kunde +kann so gewarnt werden, dass die Beschaffung der Sorten länger dauern +kann als bei anderen Währungen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +## Senden der Auftragsdaten erforderlich + +Gibt an, ob im Falle von Löschungsaufträgen die gesamten Auftragsdaten +(z. B. pain messages) mit der Löschung eingereicht werden müssen. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
718		Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +## SEPA-C-Code + +SEPA C-Code (,,C" steht für Cancellation) gibt im Rahmen einer Bestandsab- +frage an, auf welche Weise die Ausführung eines Auftrags verhindert werden +kann. + +Codierung: + +1: Reversal + +2: Revocation + +3: Delete + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:1
+ + +## SEPA-Dauereinzellastschriftdetails + +Detailinformationen zu einer Dauereinzellastschrift. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Erstmals aus- führen am2DEvdat#M1
2Zeiteinheit2DEcode1M1M, W
3Turnus1DEnum.2M1>0
4Ausfüh- rungstag1DEnum.2M1>0
5Letztmals aus- führen am2DEvdat#O1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +![](figures/138.1) + + +Die Errechnung möglicher Ausführungsdaten bzw. die Prü- +fung auf Gültigkeit des vom Kunden eingegebenen Datums +kann vom Kundenprodukt übernommen werden. + + +## SEPA-Descriptor + +Der SEPA-Descriptor beschreibt Ort, Name und Version einer SEPA pain +message als URN. Die korrekte Bezeichnung des URN ist der Anlage 3 des +DFÜ-Abkommens zu entnehmen. [DFÜ-Abkommen] + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Data Dictionary
SEPA-Zahlungsverkehr		Stand: 07.08.2015Seite: 719
+ + +![](figures/139.1) + + +![](figures/139.2) + + +Für die pain messages der ersten Generation +("pain.00x.001.0y.xsd") sind weiterhin die bisherigen Rege- +lungen (Angabe der URI bzw. "sepade.pain.00x.001.0y.xsd") +zugelassen. Bestehende, lauffähige Implementierungen für +diese erste Schema-Generation müssen somit nicht ange- +passt werden. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:.256
Version:1
+ + +### SEPA-Kontoverbindung + +Über dieses Element werden SEPA-Kontoverbindungen an das Kundenpro- +dukt übermittelt. Pro DEG wird eine Kontoverbindung im Format „ktz“ zu- +rückgemeldet. + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Kontoverbin- dung ZV Inter- national1DEGktz#M1
+ + +#### SEPA pain message + +Dieses Element transportiert eine SEPA pain message als transparentes Da- +tenformat im Sinne von FinTS. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:bin
Länge:..
Version:1
+ + +##### SEPA pain message Skeleton + +XML-Skeleton eines „SEPA Überweisung Kunde-Bank“-Schemas. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:bin
Länge:-.
Version:1
+ + +##### SequenceType, codiert + +Gibt an für welche SequenceTypes Angaben gelten. Die verschiedenen Se- +quence Types analog der Belegung (s. [DFU-Abkommen]) werden +codiert. + +Codierung: + +0: FNAL, RCUR, FRST, OOFF + +1: FNAL, RCUR +2: FRST, OOFF + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
720		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:1
+ + +#### Serverzeit + +Gibt die aktuelle Zeit des verarbeitenden Banksystems an. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:tsp
Länge:#
Version:1
+ + +#### Sessionnummer + +Eindeutige Kennzeichnung des Dialoges, die benötigt wird, damit die Lade- +anwendung die nachfolgenden Schritte eindeutig dem in diesem Schritt ein- +geleiteten Vorgang zuordnen kann. Die Sessionnummer wird vom Kreditinsti- +tut in der Nachricht ,,Laden GeldKarte vorbereiten“ übermittelt. Die exakte +Belegung der Sessionnummer ist institutsspezifisch. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:.. 10
Version:1
+ + +#### Sessionschlüssel skey1 + +Chiffrierschlüssel, der zum Verschlüsseln der Daten des Endgerätes bzw. +der GeldKarte innerhalb des anonymen Zugangs benutzt wird. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:bin
Länge:16
Version:1
+ + +#### Sessionschlüssel skey2 + +Chiffrierschlüssel, der zum Verschlüsseln der Daten der Ladeanwendung +bzw. der Ladezentrale innerhalb des anonymen Zugangs benutzt wird. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:bin
Länge:16
Version:1
+ + +#### Sicherheitsklasse + +Die Sicherheitsklasse gibt für jeden Geschäftsvorfall den erforderlichen Si- +cherheitsdienst an. + +Der Sicherheitsdienst ,,Authentikation“ erfordert die Signatur mit dem Schlüs- +sel SK.CH.AUT/KE. Der Sicherheitsdienst ,,Non-Repudiation" erfordert die +Signatur mit dem Schlüssel SK.CH.DS. Die Sicherheitsklasse darf nur im +Falle der Sicherheitsverfahren RDH-3 und RDH-4 ausgewertet werden. + +Die Sicherheitsklasse wird von der Bank für jeden Geschäftsvorfall individuell +festgelegt und dem Kunden in den Bankparameterdaten des betreffenden +Geschäftsvorfalls mitgeteilt. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 721
+ + +## Codierung: + +0: kein Sicherheitsdienst erforderlich + +1: Authentikation + +2: Non-Repudiation mit fortgeschrittener elektronischer Signatur gemäß §2, +SigG + +3: Non-Repudiation mit fortgeschrittener elektronischer Signatur gemäß §2, +SigG und zwingender Zertifikatsprüfung + +4: Non-Repudiation mit qualifizierter elektronischer Signatur gemäß §2, SigG +und zwingender Zertifikatsprüfung + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:1
+ + +## Soll-Haben-Kennzeichen + +Kennzeichen für Soll (Debit) bzw. Haben (Credit). + +Codierung: + +C: Credit (Haben) + +D: Debit (Soll) + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:2
+ + +## Sollüberziehungszins + +Zinssatz (in Prozent p.a.), der bei der überschreitung einer eingeräumten +Kreditlinie anfällt (die Anzahl der Nachkommastellen ist kreditinstitutsspezi- +fisch). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:wrt
Länge:#
Version:1
+ + +### Sollzins + +Zinssatz, der für den vereinbarten Dispositionskredit gültig ist. Das DE darf +nur bei bestimmten Kontoarten belegt werden. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:wrt
Länge:#
Version:1
+ + +## Sollzinssatz + +Gültiger Zinssatz für einen Kredit. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 722Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Kennzeichen Art der Zinsauf- stellung1DEcode1O11,2,3
2Kreditlinie, Wert1DEwrt#O1
3Kreditlinie, Währung1DEcur#O1
4Zinssatz Soll- zins1DEwrt#O1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +## Speicherzeitraum + +Anzahl Tage, für die rückwirkend Einträge (z.B. Umsätze) vorgehalten wer- +den, unabhängig davon, ob diese bereits abgerufen wurden oder nicht. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..4
Version:1
+ + +## Staffelung Bonussatz + +Gültiger Zinssatz für bestimmte Anlagebeträge. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Jahr, ordinal1DEnum..2O1
2Zinssatz1DEwrt#O1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +## Staffelung Konditionen + +Gültiger Zinssatz für bestimmte Anlagebeträge. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Zinssatz1DEwrt#O1
2Anlagebetrag von, Wert1DEwrt#O1
3Anlagebetrag von, Währung1DEcur#C1M : „Anlagebetrag von, Wert" belegt N: sonst
4Anlagebetrag bis, Wert1DEwrt#O1
5Anlagebetrag bis, Währung1DEcur#C1M : „Anlagebetrag bis, Wert“ belegt N: sonst
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Data Dictionary
SEPA-Zahlungsverkehr		Stand: 07.08.2015Seite: 723
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +### Stammdaten Aktien + +Stammdaten für die Wertpapierkategorie „Aktien“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Heimatbörse1DEan4O
☒		1
2Nennwert, Wert1DEwrt#O
☒		1
3Kapitalverände- rungen2DEcode1O
☒		11,2
4Nominalwert der Kapital- veränderung1DEwrt#O
☒		1
5Dividende1DEwrt#☒
O		1
6HV-Termin1DEdat#O
☒		1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:2
+ + +#### Stammdaten Fonds + +Stammdaten für die Wertpapierkategorie ,,Fonds". + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Fälligkeit1DEdat#☒
O		1
2Wiederanlagera- batt von1DEdat#☒
O		1
3Wiederanlagera- batt bis1DEdat#☒
O		1
4Wiederanlagera- batt, Höhe1DEwrt#O
☒		1
5Ausgabeauf- schlag1DEwrt#O
☒		1
6Verwaltungsge- bühr1DEwrt#☒
O		1
7Depotbankge- bühr1DEwrt#O
☒		1
8Bemerkungen1DEtxt.. 2048☒
O		1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +### Stammdaten Fonds + +Stammdaten für die Wertpapierkategorie „Fonds“. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 724Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Fälligkeit1DEdat#O
☒		1
2Wiederanlagera- batt von1DEdat#O
☒		1
3Wiederanlagera- batt bis1DEdat#O
☒		1
4Wiederanlagera- batt, Höhe1DEwrt#O
☒		1
5Ausgabeauf- schlag1DEwrt#O
☒		1
6Verwaltungsge- bühr1DEwrt#O
☒		1
7Depotbankge- bühr1DEwrt#O
☒		1
8Bemerkungen1DEtxt.. 2048O
☒		1
9Link Verkaufsun- terlagenLink Ver- kaufsunterlagen14DED Etxttxt2048- . 204814
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:22
+ + +## Stammdaten lieferbar + +Kennzeichen dafür, ob das Kreditinstitut mit dem Geschäftsvorfall "Wertpa- +pierstammdaten" Stammdaten zu diesem Wertpapier liefern kann. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +## Stammdaten Optionsscheine + +Stammdaten für die Wertpapierkategorie „Optionsscheine“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Heimatbörse1DEan4O1
2Fälligkeit1DEdat#O1
3Underlying1DEan.35O1
4Bezugsverhältnis1DEan.35O1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +## Stammdaten Renten + +Stammdaten für die Wertpapierkategorie „Rentenpapiere“. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Data Dictionary
SEPA-Zahlungsverkehr		Stand: 07.08.2015Seite: 725
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Heimatbörse1DEan4O1
2Nominalzinssatz1DEwrt#O1
3Emissionsdatum1DEdat#O1
4Fälligkeit1DEdat#O1
5Erster Zinstermin1DEdat#O1
6Zinsperiode2DEcode1O10,1,2,3,4,5,6,7,8,9,A,B, C,D,E,F
7Einlösungskurs1DEwrt#O1
8Einlösungsart2DEcode1O11,2,3,4,6,7,8,9,A,B,C,D ,E,F,G,H,J
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:2
+ + +### Stand + +Datum und Uhrzeit der Abfrage. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:tsp
Länge:#
Version:1
+ + +#### Standardangebot erlaubt + +Kennzeichen dafür, ob die Einschränkung auf Standardangebote des Kredit- +instituts im Kundenauftrag zulässig ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +#### Standardeinheit + +International übliche Standardeinheiten für die Notierung einer Währung. +Z.B. wird der Kurs des USD gegenüber der DEM pro 1, der Kurs des ATS +gegenüber der DEM pro 100 und der Kurs der ITL gegenüber der DEM pro +1000 gerechnet. Ist der Preis in EUR gegeben, kann der Kurs im Verhältnis +zu 1 Euro angegeben werden (Mengennotiz). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..4
Version:1
+ + +#### Status SEPA-Auftrag + +Gibt im Rahmen einer Bestandsabfrage detaillierte Informationen zu jedem +Einzel-/Sammelauftrag zurück. + + +##### Codierung: + +1: in Terminierung + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
726		Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + +2: abgelehnt von erster Inkassostelle + +3: in Bearbeitung + +4: Creditoren-seitig verarbeitet, Buchung veranlasst + +5: R-Transaktion wurde veranlasst + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:1
+ + +###### Startdatum + +Beginn einer Zeitraumangabe. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dat
Länge:#
Version:1
+ + +####### Stopplimit änderbar + +Kennzeichen dafür, ob kreditinstitutsseitig eine Änderung dieses Parameters +zulässig ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +####### Stopplimit, Prozent + +Stoplimit zu einer Wertpapierorder, ausgedrückt als Prozentsatz. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:wrt
Länge:#
Version:1
+ + +####### Stopplimit, Wert + +Stoplimit zu einer Wertpapierorder, ausgedrückt als Wert. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:wrt
Länge:#
Version:1
+ + +####### STP-Höchstbetrag + +Gibt den Höchstbetrag in EUR für STP-Zahlungen des zugrunde liegenden +DTAZV Handbuches an. (s. [DTAZV]). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:wrt
Länge:#
Version:1
+ + +### StraBe + +Angabe der Straße in der Adresse. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 727
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:2
+ + +#### Straße/Postfach + +Angabe der Straße oder des Postfaches in einer Adresse. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:1
+ + +#### Strukturierter Verwendungszweck erlaubt + +Über diese Information legt das Kreditinstitut fest, ob bei SEPA- +Zahlungsverkehrsinstrumenten die Verwendung von strukturierten Verwen- +dungszweckinformationen (,StructuredRemittancelnformation") erlaubt ist +oder nicht. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +##### Stückelungsmöglichkeit + +Kennzeichen dafür, in welchen Grobstücken Sorten oder Reiseschecks be- +stellt werden können, falls eine automatische Stückelung möglich ist. + +Codierung: + +1: Große Stücke + +2: Kleine Stücke + +3: Gemischte Stücke + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:2
+ + +#### Stückelungsmöglichkeiten + +Gibt die vom Kreditinstitut angebotenen Stückelungsmöglichkeiten von Sor- +ten und Reiseschecks an. + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Stückelungsmög- lichkeit2DEcode1M1..31,2,3
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
728		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + +
Format:
Länge:
Version:1
+ + +## Stücknennwert + +Nennwert, der zu einer Stückelung angegeben wird. Der angegebene Nenn- +wert muss vom Kreditinstitut angeboten werden. Die Währung des Nennwer- +tes ist identisch mit der des Gesamtbetrages. Die bestellte Anzahl ergibt sich +aus dem Betragswert geteilt durch den Nennwert. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:wrt
Länge:#
Version:1
+ + +## Suchbegriff erlaubt + +Kennzeichen dafür, ob die Eingabe eines Suchbegriffs im Kundenauftrag zu- +lässig ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +## Summe der Beträge + +Summe der Beträge, die in einem DTA-Satz angegeben werden (Feld E 5/E +8). + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:btg
Länge:#
Version:2
+ + +### Summenfeld + +Entspricht der Summe der Beträge eines SEPA-Sammelauftrags (entspricht +somit ControlSum innerhalb der pain message). + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:btg
Länge:#
Version:1
+ + +## Summenfeld benötigt + +Gibt an, ob das Kundenprodukt die Summe der Beträge eines Sammelauf- +trags auch auBerhalb der pain message transportieren muss. + +Typ: + +DEG + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 729
+ + + + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +T + + +### Telefax-Nummer + +Angabe der Telefax-Nummer in einer Adresse. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:1
+ + +#### Telefon + +Telefonnummer, die in einer Adresse oder auch explizit für Rückfragen an- +zugeben ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:1
+ + +#### Telefonnummer dienstlich + +Angabe der dienstlichen Telefonnummer in der Adresse. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:1
+ + +#### Telefonnummer für Bestätigung + +Telefonnummer des Kunden, unter der er zwecks Bestätigung zu den ge- +wöhnlichen Banköffnungszeiten zu erreichen ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:1
+ + +#### Telefonnummer verpflichtend + +Kennzeichen dafür, ob bei einem Auftrag eine Telefonnummer für Rückfra- +gen angegeben werden muss. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +#### Telefonnummer privat + +Angabe der privaten Telefonnummer in der Adresse. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
730		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:1
+ + +## Terminal-ID + +Eindeutige Kennung des Geldkarten-Ladeterminals, die durch die Lade- +anwendung vergeben wird. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:id
Länge:#
Version:1
+ + +## Terminwunsch + +Datum und ggf. Uhrzeit des Terminwunsches eines Kunden. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:tsp
Länge:#
Version:1
+ + +## Textschlüssel + +Kennzeichnung der Zahlungsart, die bei der Einreichung eines Auftrags vom +Kunden angegeben werden kann. + +Zu den vom Kreditinstitut für den jeweiligen Geschäftsvorfall des Zahlungs- +verkehrs unterstützten Textschlüsseln gehören mindestens Textschlüssel 51 +(bei Überweisungsgutschrift), Textschlüssel 67 und 69 (für die Sonderformen +der Überweisung) sowie Textschlüssel 52 (bei Dauerauftrags-Gutschrift). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dig
Länge:2
Version:1
+ + +![](figures/150.1) + + +Die Einstellung zulässiger Textschlüssel erfolgt nicht kun- +den-, sondern kreditinstitutsbezogen. Daher kann im Einzel- +fall ein Auftrag abgelehnt werden, da ein nicht erlaubter +Textschlüssel eingereicht wurde, obwohl dieser laut BPD zu- +lässig ist. + +Beispiel: Kreditinstitutsseitig werden Lohn- und Gehaltsüber- +weisungen (Textschlüssel 53) zugelassen, diese Möglichkeit +soll jedoch nicht für Privatkunden angeboten werden. + + +## Textschlüssel und -ergänzung änderbar + +Kennzeichen dafür, ob der Textschlüssel und die Textschlüsselergänzung +des Dauerauftrags durch den Kunden änderbar sind. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 731
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +## Textschlüsselergänzung + +Ergänzung zum jeweiligen Textschlüssel. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dig
Länge:3
Version:1
+ + +### Thema + +Thema des Gesprächs im Klartext, das der Kunde bei einer Terminvereinba- +rung zusätzlich oder alternativ zum angegebenen Informationscode das +nennen kann, um dem Kundenberater eine Vorbereitung auf das Gespräch +zu ermöglichen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:.200
Version:1
+ + +### Tilgungsbeginn + +Datum des Tilgungsbeginns. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dat
Länge:#
Version:1
+ + +### Tilgungsbetrag + +Tilgungsbetrag. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:btg
Länge:#
Version:1
+ + +### Tilgungsperiode + +Tilgungsperiode (gemäß WM GD 811). + +Codierung: + +0: monatlich + +1: jährlich + +2: halbjährlich + +3: viermonatlich + +4: vierteljährlich + +5: neunmonatlich + +6: zweimonatlich + +7: zweijährlich + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
732		Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + +8: Tilgung am Laufzeitende + +9: keine Tilgungstermine + +A: fünfmonatlich + +B: siebenmonatlich + +C: achtmonatlich + +D: zehnmonatlich + +E: elfmonatlich + +F: fünfjährlich + + + + + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:1
Referenz:WM GD 811
+ + +### Tilgungssatz, Wert + +Vertraglich festgeschriebener Tilgungssatz, Angabe in Prozent + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:wrt
Länge:#
Version:1
+ + +### Tilgungstermin + +Nächster Tilgungstermin (im Format: MMTT). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dig
Länge:4
Version:1
+ + +#### Titel + +Angabe des Titels als Teil der Personendaten. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..30
Version:2
+ + +### Trailingabstand änderbar + +Kennzeichen dafür, ob kreditinstitutsseitig eine Änderung dieses Parameters +zulässig ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +#### Trailingabstand, Prozent + +Trailingabstand im Rahmen einer Trailingorder, ausgedrückt als Prozentsatz. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 733
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:wrt
Länge:#
Version:1
+ + +## Trailingabstand, Wert + +Trailingabstand im Rahmen einer Trailingorder, ausgedrückt als Wert. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:wrt
Länge:#
Version:1
+ + +### Turnus + +Anzahl der Zeiteinheiten, die zwischen 2 Ausführungen eines Dauerauftra- +ges liegen sollen. + +Wertebereich: + +Zeiteinheit M: 1 bis 12 + +Zeiteinheit W: 1 bis 52 + +Ein Turnus von mehr als einem Jahr ist nicht zulässig. Es darf nur ein gemäß +BPD zugelassener Wert eingestellt werden. Die Gültigkeit der Kombination +aus Zeiteinheit und Turnus ergibt sich aus den Vorgaben in der BPD. + +Beispiele: + +Zeiteinheit M, Turnus 1 (Monatliche Ausführung) + +Zeiteinheit M, Turnus 3 (Vierteljährliche Ausführung) + +Zeiteinheit M, Turnus 12 (Jährliche Ausführung) + +Zeiteinheit W, Turnus 1 (Wöchentliche Ausführung) + +Zeiteinheit W, Turnus 2 (Ausführung alle 2 Wochen) + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..2
Version:1
+ + +### Turnus änderbar + +Kennzeichen dafür, ob der Turnus des Dauerauftrags durch den Kunden än- +derbar ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +### Turnus in Monaten + +Angabe des monatlichen Ausführungsturnus von Daueraufträgen. Erlaubt +sind 00 (alle Möglichkeiten) oder 01 (monatlich) bis 12 (jährlich). + +Beispiel: + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
734		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + +0102030612 (Ausführung monatlich, 2-monatlich, vierteljährlich, halbjährlich +und jährlich möglich) + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dig
Länge:.24
Version:1
+ + +## Turnus in Wochen + +Angabe des wöchentlichen Ausführungsturnus von Daueraufträgen. Erlaubt +sind 00 (alle Möglichkeiten) oder 01 bis 52. + +Beispiel: + +01020408 (Ausführung wöchentlich, 2-wöchentlich, alle 4 Wochen und alle 8 +Wochen möglich) + +Wenn das DE nicht belegt ist, ist keine wöchentliche Ausführung möglich. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dig
Länge:..104
Version:1
+ + +## Turnus Kontoauszug + +Information darüber, wie oft Kontoauszüge für die Versandart Postzustellung +erstellt werden sollen. + +Codierung: + +1: Tagesauszug + +2: Wochenauszug + +3: Monatsauszug + +4: Quartalsauszug + +5: Halbjährlicher Auszug + +6: Jährlicher Auszug + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:2
+ + +U + + +## Überziehung + +Angabe des Betrages, um den der verfügbare Betrag eines Kontos über- +schritten wurde. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:btg
Länge:#
Version:1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel: Abschnitt:Data Dictionary SEPA-ZahlungsverkehrStand: 07.08.2015Seite: 735
+ + +### Überziehung + +Beinhaltet gültige Soll- und Überziehungszinssätze und Überziehungsbeträ- +ge. + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
2Überziehungs- zinssätze1DEGOn
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +### Überziehungszins + +Zinssatz, der bei überzogenem Dispositionskredit gütig ist. Das DE darf nur +bei bestimmten Kontoarten belegt werden. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:wrt
Länge:#
Version:1
+ + +### Überziehungszinsätze + +Aktuell gültiger Soll- und Überziehungszinssatz und Überziehungsbetrag. Die +Verwendung der verschiedenen Zinssätze ist kreditinstitutsspezifisch. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Kennzeichen Art der Zinsauf- stellung1DEcode1O11,2,3
2Kreditlinie, Wert1DEwrt#O1
3Kreditlinie, Währung1DEcur#O1
4Gesamtzins1DEwrt#O1
5Sollüberzie- hungszins1DEwrt#O1
6Überziehungs- zins1DEwrt#O1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +### Uhrzeit + +Uhrzeit eines Ereignisses (meist zusammen mit „Datum“ verwendet). + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
736		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:tim
Länge:#
Version:1
+ + +# Uhrzeit der Erstellung + +Uhrzeit der Erstellung eines Kontoauszuges. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:tim
Länge:#
Version:1
+ + +## Uhrzeit der Übermittlung + +Uhrzeit der Übermittlung von Daten zwischen Kunde und Kreditinstitut. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:tim
Länge:#
Version:1
+ + +## Umsatzauskunft + +Wertpapierumsätze im S.W.I.F.T.-Format MT 536 bzw. MT 572 gemäß Spe- +zifikation in [Datenformate]. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:bin
Länge:..
Version:1
+ + +# Underlying + +Underlying eines Optionsscheins. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:.35
Version:1
+ + +# Unterkontomerkmal + +Unterkontonummer, falls unter einer Kontonummer verschiedene Unterkon- +ten (z.B. Währungskonten) geführt werden. Anstatt einer Kontonummer kann +auch ein anderes identifizierendes Merkmal angegeben werden (z.B. der +entsprechende ISO-Währungscode bei Währungskonten). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:id
Länge:#
Version:1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 737
+ + +![](figures/157.1) + + +Das DE muss kundenseitig belegt werden, wenn das Kredit- +institut dies dem Kunden ausdrücklich mitgeteilt hat. + + +# Unterstützte camt-Datenformate + +Dieses DE beschreibt Ort, Name und Version einer camt message als URN. +Die korrekte Bezeichnung des URN ist der Anlage 3 des DFÜ-Abkommens +zu entnehmen (vgl. [DFÜ-Abkommen]). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:256
Version:1
+ + +# Unterstützte camt-messages + +Jedes DE enthält eine URN einer camt Schema-Definition. + +Wird verwendet, um die zur Verfügung stehenden camt Schema-Definitionen +bekannt zu geben und gibt bei Abfragen an, welche camt Schemata durch +das Kundenprodukt unterstützt werden. Diese müssen aus den vom Kredit- +institut unterstützten in der BPD übermittelten camt Schema-Definitionen +ausgewählt werden. + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1camt-Descriptor1DEan.256M..99
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +# Unterstützte Kontoauszugsformate + +Vom Kreditinstitut angebotene Kontoauszugsformate, die der Kunde anfor- +dern kann. + +Codierung: s. ,Kontoauszugformat“ + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:2
+ + +## Unterstützte Meldesätze + +Gibt die vom Kreditinstitut tatsächlich unterstützten Meldesätze des zugrun- +de liegenden DTAZV-Handbuches vor. Die verschiedenen Meldesätze wer- +den innerhalb des Datenelementes mit Semikolon getrennt. (s. [DTAZV]). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:.. 16
Version:1
+ + +### Unterstützte SEPA-Lastschriftarten + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
738		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + +Gibt an für welche Lastschriftart ein Geschaftsvorfall vom Kreditinstitut tat- +sächlich zugelassen ist. Die verschiedenen Lastschriftarten analog der Bele- +gung (s. [DFÜ-Abkommen]) werden innerhalb des Daten- +elementes mit Semikolon getrennt. . + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..64
Version:1
+ + +#### Unterstützte SEPA-Lastschriftarten, codiert + +Gibt an welche Lastschriftart vom Kreditinstitut tatsächlich zugelassen ist. +Die verschiedenen Lastschriftarten analog der Belegung +(s. [DFÜ-Abkommen]) werden codiert. + +Codierung: + +0: CORE + +1: COR1 + +2: CORE und COR1 + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:1
+ + +##### Unterstützte SEPA pain messages + +Jedes DE enthält eine URN eines SEPA-Datenformates. + + +![](figures/158.1) + + +![](figures/158.2) + + +Für die pain messages der ersten Generation +("pain.00x.001.0y.xsd") sind weiterhin die bisherigen Rege- +lungen (Angabe der URI bzw. "sepade.pain.00x.001.0y.xsd") +zugelassen. Bestehende, lauffähige Implementierungen für +diese erste Schema-Generation müssen somit nicht ange- +passt werden. + +Wird in HISPAS verwendet, um die zur Verfügung stehenden pain messages +bekannt zu geben und gibt z. B. bei Bestandsabfragen an, welche SEPA- +Datenformate durch das Kundenprodukt unterstützt werden. Diese müssen +aus den vom Kreditinstitut unterstützten SEPA-Datenformaten ausgewählt +werden, die im HISPAS übermittelt werden. + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Data Dictionary
SEPA-Zahlungsverkehr		Stand: 07.08.2015Seite: 739
+ + + + + + + + + + + + + + +
2SEPA Descriptor1DEan.256M.99
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +#### Unterstützte SEPA-Datenformate + +Dieses DE beschreibt Ort, Name und Version einer SEPA pain message als +URN. Die korrekte Bezeichnung des URN ist der Anlage 3 des DFÜ- +Abkommens zu entnehmen (vgl. [DFÜ-Abkommen]). + + +![](figures/159.1) + + +![](figures/159.2) + + +Für die pain messages der ersten Generation +("pain.00x.001.0y.xsd") sind weiterhin die bisherigen Rege- +lungen (Angabe der URI bzw. "sepade.pain.00x.001.0y.xsd") +zugelassen. Bestehende, lauffähige Implementierungen für +diese erste Schema-Generation müssen somit nicht ange- +passt werden. + + +![](figures/159.3) + + +![](figures/159.4) + + +Werden in den Bankparameterdaten eines bestimmten Ge- +schäftsvorfalls explizit unterstützte SEPA-Datenformate ge- +nannt, so sind die laut HISPAS global mitgeteilten unterstütz- +ten SEPA pain messages für den betreffenden Geschäfts- +vorfall nicht relevant. Es gelten lediglich die laut den Bankpa- +rameterdaten des Geschäftsvorfalls zugelassenen SEPA +pain messages. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:.256
Version:1
+ + +V + +Valuta + +Datum der Wertstellung. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dat
Länge:#
Version:1
+ + +##### Vereinbarte Darlehensrate + +Darlehensrate inkl. Zins und Tilgung. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
740		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:btg
Länge:#
Version:1
+ + +#### Vereinbarte Sparrate + +Betrag, der bei Ratensparverträgen pro Zahlungsintervall vom Belastungs- +konto abgebucht werden und auf das Sparkonto eingezahlt werden soll. Bei +anderen Sparverträgen handelt es sich um den (ersten) Einzahlungsbetrag. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:btg
Länge:#
Version:1
+ + +##### Vereinbarter Tilgungsbetrag + +Vereinbarter Tilgungsbetrag eines Darlehens. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:btg
Länge:#
Version:1
+ + +##### Verfügbarer Betrag + +Betrag, der im Augenblick der Saldenrückmeldung für den Kunden maximal +disponiert werden kann. Die Ermittlung des verfügbaren Betrags kann insti- +tutsspezifisch differieren. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:btg
Länge:#
Version:1
+ + +##### Verfügungsberechtigte + +Angaben über Verfügungsberechtigte. Diese sind nur informativ und haben +keine Auswirkungen auf die Berechtigung zur Ausführung von Aufträgen. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Name 11DEan.35M1
2Name 21DEan.35O1
3Verfügungsbe- rechtigter2DEcode1O11, 2, 3
4Verfügungsbe- rechtigung2DEcode1O10, 1, 2, 3
5Verfügungsbetrag1DEGbtg#O1
6Risikoklasse des Benutzers1DEan..2O1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:2
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:Data DictionaryStand:Seite:
Abschnitt:SEPA-Zahlungsverkehr07.08.2015741
+ + +##### Verfügungsberechtigter + +Kodierte Information über den Verfügungsberechtigten. + +Codierung: + +1: Kontoinhaber + +2: Bevollmächtigter + +3: Gläubiger + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:2
+ + +##### Verfügungsberechtigung + +Kodierte Information über die Verfügungsberechtigung. + +Codierung: + +0: Nur Leseberechtigung + +1: Alleinige Verfügungsberechtigung (bis zur Höhe des Verfügungsbetrages) + +2: Gemeinsame Verfügungsberechtigung mit einem anderen Verfügungsbe- +rechtigten der Kategorie 1,2 oder 3 bis zur Höhe des Verfügungsbetrages + +3: Gemeinsame Verfügungsberechtigung mit einem anderen Verfügungsbe- +rechtigten der Kategorie 1,2 oder 3 bis zur Höhe des Verfügungsbetrages +(wobei nicht zwei Berechtigte der Kategorie 3 gemeinsam verfügen kön- +nen) + + +###### 4: Botenfunktion + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:2
+ + +##### Verfügungsbetrag + +Betrag, über den ein Verfügungsberechtigter verfügen darf. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:btg
Länge:1
Version:1
+ + +##### Verrechnungskonto + +Kontoverbindung zur Gutschrift von Transaktionserlösen bzw. zum Einzug +von Transaktionskosten. (z.B. Geldkonto bei Wertpapieraufträgen). + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:ktv
Länge:#
Version:3
+ + +##### Verrechnungskonto + +Kontoverbindung zur Gutschrift von Transaktionserlösen bzw. zum Einzug +von Transaktionskosten. (z.B. Geldkonto bei Wertpapieraufträgen). + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
742		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:kti
Länge:#
Version:4
+ + +##### Verrechnungskonto änderbar + +Kennzeichen dafür, ob kreditinstitutsseitig eine Änderung des Verrechnungs- +kontos zulässig ist. + +Codierung: + +0: nicht änderbar + +1: Änderung nur intern erlaubt (beim depotführenden Institut) + +2: Änderung intern und extern erlaubt (bei Drittinstitut) + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:2
+ + +##### Verrechnungskonto verpflichtend + +Kennzeichen dafür, ob das Verrechnungskonto im Kundenauftrag angege- +ben werden muss. Die Angabe ist z.B. dann erforderlich, wenn eine +Dispositionsprüfung erfolgen soll, ohne dass die Information über das +Verrechnungskonto aus dem S.W.I.F.T.-Datensatz gelesen werden muss. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +# Versandart Kontoauszug + +Information darüber, wie Kontoauszüge versandt werden. + +Codierung: + +0: Kein Auszug + +1: Postzustellung + +2: Kontoauszugdrucker + +3: Abholung in der Geschäftsstelle + +4: Elektronische Übermittlung + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:2
+ + +## Versandkostenanteil + +Pauschalpreis für den Versand der Sorten oder Reiseschecks bei der Auslie- +ferungsart "Zusendung (kostenpflichtig)". + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Data Dictionary
SEPA-Zahlungsverkehr		Stand: 07.08.2015Seite: 743
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:btg
Länge:#
Version:1
+ + +# Version der Information + +Datum der letzten Änderung der Information, das als Versionsangabe ge- +nutzt wird. Falls keine Versionsverwaltung (d.h. keine Aktualisierung des Än- +derungsdatums) geführt wird, ist das aktuelle Tagesdatum einzustellen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dat
Länge:#
Version:1
+ + +# Version der Konditionen + +Version der aktuellen Festgeldkonditionen, die der Kunde mit dem Auftrag +,Festgeldkonditionen abfragen" erhält. Diese Information dient der Plausibili- +tätsprüfung, falls die vom Kunden übermittelte Anlagekondition ungültig ist. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Konditionenver- sion1DEan..10M1
2Datum der Übermittlung1DEdat#M1
3Uhrzeit der Übermittlung1DEtim#M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +# Versionsnummer + +Version der wichtigen Informationen, die das Kreditinstitut zur eindeutigen +Identifizierung mit dem Datum kombinieren kann, falls pro Tag mehrere Ver- +sionen der wichtigen Wertpapierinformationen herausgegeben werden. + +Das Kreditinstitut bestimmt die Vergabe der Versionsnummer selbst, d.h. es +legt fest, ob die Version kontinuierlich oder pro Tag mit ,1" beginnend hoch- +gezählt wird. Ferner legt es fest, ob für allgemeine und spezielle Versionen +und deren Kategorien nur ein einziger oder jeweils eigene Versionszähler +geführt werden. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..3
Version:1
+ + +# Verwaltungsgebühr + +Jährliche Verwaltungsgebühr in Prozent. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
744		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:wrt
Länge:#
Version:1
+ + +## Verwendungszweck + +Angabe zum Verwendungszweck bei einem Überweisungsauftrag. + +Die maximale Anzahl der Verwendungszweckzeilen ergibt sich aus den +BPD. Es ist der DTAUS0-Zeichensatz mit der entsprechenden Codierung zu +verwenden. + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Verwendungs- zweckzeile2DEdta..27O99
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:3
+ + +![](figures/164.1) + + +Das Kundenprodukt hat bei der Darstellung des Verwen- +dungszwecks die durch das Format vorgegebene Zeilen- +struktur beizubehalten. + + +![](figures/164.2) + + +Es ist zu beachten, dass die Regeln über das Abschneiden +führender und nachfolgender Leerzeichen (s. [Formals]) +auch für die Verwendungszweckzeilen gelten, d.h. Einrü- +ckungen etc. werden nicht an das Kreditinstitut übertragen. + + +## Verwendungszweck änderbar + +Kennzeichen dafür, ob der Verwendungszweck des Dauerauftrags durch den +Kunden änderbar ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +## Verwendungszweck Konto + +In dieses Datenelement können eventuell hinterlegte Verwendungszwecke +eines Kontos eingestellt werden (z.B. Haushaltskonto) . + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 745
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..30
Version:1
+ + +### Verwendungszweck, AZV + +Angabe zum Verwendungszweck bei einem Auftrag im Auslandszahlungs- +verkehr. + +Die Anzahl der maximal erlaubten Eingabezeichen ergibt sich aus den BPD. +Es sollten nur Zeichen aus dem S.W.I.F.T.-Zeichensatz verwendet werden. + +Typ: + +DE + +Format: + +an + +Länge: + +. . 140 + +Version: + +1 + + +#### Verwendungszweck, AZV kurz + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:1
+ + +#### Verwendungszweck SEPA + +Verwendungszweck einer SEPA Transaktion. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:.. 140
Version:1
+ + +#### Verwendungszweckzeile + +Teil der Angaben zum Verwendungszweck, der als Druckzeile portioniert +wird. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dta
Länge:.27
Version:2
+ + +#### Von Datum + +Anfangsdatum eines Zeitraums (s. [Formals], Kap. B.6.3). + +Durch die Eingabe von Von- und Bis-Datum kann ein Zeitraum eingegrenzt +werden, für den Informationseinträge vom Kreditinstitut rückzumelden sind. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dat
Länge:#
Version:1
+ + +#### Vorbörse + +Börsenkurs im Vorbörsenhandel. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
746		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:rate
Länge:#
Version:2
+ + +##### Vormerkungszeitpunkt + +Datum und Uhrzeit, zu dem ein Auftrag zur Ausführung vorgemerkt ist. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:tsp
Länge:#
Version:1
+ + +##### Vorname + +Angabe des Vornamens als Teil der Personendaten. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..30
Version:2
+ + +##### Vortageskurs + +Kurs des Wertpapiers vom Vortag. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:rate
Länge:#
Version:2
+ + +###### Vorschusszinsen + +Erläuterung zu Vorschusszinsen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:txt
Länge:99
Version:1
+ + +###### Vorschusszinsfrei + +Betrag über den ohne Fälligkeit von Vorschusszinsen verfügt werden kann. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:btg
Länge:#
Version:1
+ + +W + + +# Währung + +Angabe der Währung im Format ISO 4217. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand:
07.08.2015		Seite: 747
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:cur
Länge:#
Version:1
+ + +## Währung der Depotaufstellung + +Von DEM und EUR abweichende Fremdwährung, die der Kunde für die An- +zeige der Depotwerte angeben kann, falls dies vom Kreditinstitut zugelassen +wird. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:cur
Länge:#
Version:1
+ + +## Währung der Depotaufstellung wählbar + +Kennzeichen dafür, ob der Kunde eine von DEM und EUR abweichende De- +potwährung wählen darf. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +## Währung der Konditionen + +Information darüber, in welcher Währung die Festgeldanlagen geführt wer- +den sollen, zu denen der Kunde die Konditionen abrufen möchte. Die gülti- +gen Währungskennzeichen stellt das Kreditinstitut in die Bankparameterda- +ten ein. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:cur
Länge:#
Version:1
+ + +## Währung der Kursnotierung + +Schlüssel der Währung, in der die Kurse notiert sind, falls es sich um eine +Stücknotiz handelt. Diese Information darf nur in Zusammenhang mit dem +Wert „Stücknotiz“ bei der Einheit der Effektennotiz belegt werden. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:cur
Länge:#
Version:1
+ + +### Währungsbezeichnung + +Langbezeichnung der Währung. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:1
+ + +## Web-Link + +Internet-URL, z.B. für weiterführende Informationen. Die Angabe erfolgt in- +klusive des Dienstbezeichners (z.B. 'http://'). + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
748		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:.256
Version:1
+ + +## Weitere Informationen + +Informationen, die sich nicht strukturiert abbilden lassen (z.B. Stammdaten +zu Optionen oder Fonds). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:txt
Länge:2048
Version:1
+ + +## Weitere Informationen + +Informationen, die sich nicht strukturiert abbilden lassen (z.B. Stammdaten +zu Optionen oder Fonds). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:txt
Länge:65536
Version:2
+ + +## Weitere Informationen gewünscht + +Kennzeichen dafür, ob beim Anfordern des Orderstatus - sofern vorliegend - +die Ausführungsanzeige oder Abrechnung im jeweiligen S.W.I.F.T.-Format +zurückgemeldet wird. Es wird sonst nur das Statuskennzeichen zurück +übermittelt. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +## Weitere Zeichnungsinformationen + +Weitere Informationen zu einer Zeichnung, z.B. Verkaufsbeschränkungen, +Zuteilungsmodus (bei bereits zugeteilten Emissionen), Dividenden- +berechtigung oder ,,Research-Blackout". + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:txt
Länge:.2048
Version:1
+ + +## Werbetext + +Textinformationen ohne rechtlichen Charakter (z.B. im Kontoauszug). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:txt
Länge:..2048
Version:1
+ + +## Werbetext + +Textinformationen ohne rechtlichen Charakter (z.B. im Kontoauszug). + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 749
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:txt
Länge:..65536
Version:2
+ + +## Wert + +Monetärer Wert z.B. als Bestandteil eines Geldbetrags. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:wrt
Länge:#
Version:1
+ + +## Wertpapierabrechnung + +Wertpapierabrechnung im S.W.I.F.T.-Format MT 515. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:bin
Länge:..
Version:1
+ + +![](figures/169.1) + + +Die elektronische Wertpapierabrechnung dient nur zu Infor- +mationszwecken und ersetzt nicht die schriftliche Abrech- +nung. + + +## Wertpapierart + +Art des Wertpapiers. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..3
Version:1
+ + +### Wertpapierart, Text + +Klassifizierungsinformation des Wertpapiers (z.B. „nennwertlose Stückaktie“ +oder Text aus WM GD 190/195). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..99
Version:1
+ + +### Wertpapierbezeichnung + +Ausführliche Bezeichnung des Wertpapiers. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:.99
Version:2
+ + +## Wertpapierbezeichnung Suchbegriff + +Wertpapierbezeichnung als Suchbegriff für die Selektion des Wertpapiers. +Dabei ist die Eingabe von Teilstrings möglich (Beispiel: Der Suchbegriff +,Siemens“ liefert sowohl ,,Siemens Stammaktien" als auch ,Siemens Vor- + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
750		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + +zugsaktien"). Ob die Angabe eines Suchbegriffs erlaubt ist, wird dem Kun- +densystem in den Bankparameterdaten mitgeteilt. + +Es wird keine Unterscheidung bzgl. Groß-/Kleinschreibung getroffen. Ob der +Suchbegriff als Textbeginn interpretiert wird oder auch die Suche in der Mitte +oder am Ende von Texten zulässig ist, ist dem jeweiligen Kreditinstitut über- +lassen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..99
Version:2
+ + +## Wertpapiercode + +Wertpapiercode gemäß der Referenzart (DE „Referenzart“). Im Fall der ISIN +erfolgt die Angabe 12-stellig alphanumerisch, im Fall der WKN 6-stellig nu- +merisch (zukünftig auch alphanumerisch). + +Es wird dem Kunden diejenige Referenz zurückgemeldet, die er im Auftrag +angegeben hat. Somit dient diese Information nur zur Zuordnung vom Auf- +trag zur Antwort und nicht der Übermittlung weiterer Referenzarten, wie +bspw. bei der Abfrage der Referenznummern (vgl. Kap. C.4.4.1). Es können +auch mehrere Referenzen (z.B. sowohl ISIN als auch WKN) zurückgemeldet +werden, damit der Kunde die ihm geläufigere Referenz verwenden kann. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..30
Version:1
+ + +## Wertpapiergruppe + +Kreditsinstitutsindividuell kodierte Information, anhand deren vom Kreditinsti- +tut angebotene Wertpapiere in Gruppen (bspw. Aktien, Renten) eingeteilt +werden. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..2
Version:2
+ + +## Wertpapiergruppe, Text + +Kreditsinstitutsindividuelle Information, anhand deren vom Kreditinstitut an- +gebotene Wertpapiere in Gruppen (bspw. Aktien, Renten) eingeteilt werden. + +Mit Hilfe dieser Information kann die Auswahl der Festpreisangebote auf eine +bestimmte Wertpapiergruppe beschränkt werden. Sollen die Angebote ver- +schiedener Gruppen zurückgemeldet werden, so ist für jede Gruppe ein +Segment in die Nachricht einzustellen. Die vom Kreditinstitut angebotenen +Wertpapiergruppen werden dem Kunden in den Bankparameterdaten mitge- +teilt. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 751
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:1
+ + +## Wertpapiergruppen + +Angaben der Wertpapiergruppen, auf welche sich der Auftrag beziehen soll. +Die zulässigen Wertpapiergruppen werden in den Bankparameterdaten mit- +geteilt. + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Wertpapiergrup- pe, Text1DEan.35O99
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +### Wertpapierhinweis + +Textuelle Informationen zu einem Wertpapier (s. DEG Wichtige Informatio- +nen). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:txt
Länge:2048
Version:1
+ + +### Wertpapierinformation + +Informationen über das Wertpapier. Art und Umfang der Informationen (z.B. +Researchdaten) sind dem Kreditinstitut freigestellt. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:txt
Länge:2048
Version:1
+ + +### Wertpapierinformationen lieferbar + +Kennzeichen dafür, ob das Kreditinstitut mit dem Geschäftsvorfall "Wertpa- +pierinformationen anfordern" über die Stammdaten hinausgehende In- +formationen liefern kann. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +### Wertpapierkategorie + +Information über die Wertpapierkategorie. + +Codierung: + +1: Aktien + +2: Rentenpapiere, Genussscheine + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
752		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + +3: Fonds + +4: Optionsscheine + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:2
+ + +## Wertpapierorder + +Wertpapierorder im S.W.I.F.T.-Format MT 502. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:bin
Länge:..
Version:1
+ + +## Wertpapierorderstatus + +Status eines Wertpapierauftrages. + +Codierung: + +0: Nicht verfügbar (Der Status für den Auftrag mit der angegebenen Refe- +renz ist systemweit unbekannt.) + +1: Auftrag zur Ausführung vorgemerkt (Der Auftrag wurde in einem der vor- +gelagerten Kreditinstitutssysteme zwischengespeichert. Der Auftrag ist auf +dem Weg zum abwickelnden System, dessen Rückmeldung aber noch aus- +steht.) + +2: Auftrag zur Ausführung angenommen (Der Auftrag wurde vom abwickeln- +den System zur Ausführung angenommen. Achtung: Wenn der Auftrag eine +Änderung oder Streichung war, bedeutet dieser Status nicht, dass die Be- +zugsorder tatsächlich schon geändert bzw. gestrichen worden ist. Es kann +vorkommen, dass die Bezugsorder im Zeitpunkt der Änderungs- +/Streichungsannahme gerade an der Börse ausgeführt wird. Maßgeblich für +den Kunden ist immer der jeweilige Orderstatus.) + +3: Auftrag abgelehnt (Eines der Kreditinstitutssysteme hat aufgrund von Prü- +fungen den Auftrag abgelehnt. Auch im nachhinein sollte der Grund hierfür +rekonstruierbar sein. Informationen zu abgelehnten Aufträgen können mit +dem Geschäftsvorfall „Orderstatus“ oder ,,Orderanzeige" angefordert wer- +den.) + +4: Orderänderung vorgemerkt (Die Order wurde noch nicht ausgeführt. für +den Auftrag liegt eine Änderungsvormerkung vor.) + +5: Orderstreichung vorgemerkt (Die Order wurde noch nicht ausgeführt. für +den Auftrag liegt eine Streichungsvormerkung vor.) + +6: Order ausgeführt (Die Order wurde ausgeführt und kann daher nicht mehr +geändert oder gestrichen werden. Dies bedeutet, dass auch eine Ausfüh- +rungsanzeige (MT 513) abrufbar ist, wenn diese vom Kreditinstitut angebo- +ten wird.) + +7: Order teilausgeführt (In diesem Fall können dem Kunden weitere Informa- +tionen zur Teilausführung im DE ,,Auftragsbezogene Informationen“ mitgeteilt +werden. Bei Änderungen und Streichungen kann das Kreditinstitut den Auf- +trag unter Vorbehalt annehmen, indem es das Kennzeichen ,,Erneutes Sen- + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Data Dictionary
SEPA-Zahlungsverkehr		Stand: 07.08.2015Seite: 753
+ + +den erforderlich" setzt, um so vom Kunden eine Bestätigung der Teilausfüh- +rung zu erhalten.) + +8: Order abgerechnet (Die Order wurde abgerechnet. Dies bedeutet, dass +auch eine Abrechnung (MT 515) abrufbar ist, wenn diese vom Kreditinstitut +angeboten wird.) + +9: Order gemäß Kundenwunsch gestrichen (Die Order wurde vom Kunden +gestrichen.) + +10: Order gemäß Usancen gestrichen (Die Order wurde vom Kreditinstitut +bzw. von der Börse gelöscht.) + +11: Order abgelaufen (Die Order wurde gelöscht, da der maximale Gültig- +keitstermin der Order überschritten wurde.) + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:.2
Version:2
+ + +![](figures/173.1) + + +Welchen Informationsgehalt bzw. welche Rechtsfolgen die +jeweiligen Statusmeldungen für den Kunden haben, sollte +das Kreditinstitut in entsprechenden Kundenbedingungen +festlegen. + + +## Wertpapierorderstatus + +Status eines Wertpapierauftrages. + +Codierung: + +0: Nicht verfügbar (Der Status für den Auftrag mit der angegebenen Refe- +renz ist systemweit unbekannt.) + +1: Auftrag zur Ausführung vorgemerkt (Der Auftrag wurde in einem der vor- +gelagerten Kreditinstitutssysteme zwischengespeichert. Der Auftrag ist auf +dem Weg zum abwickelnden System, dessen Rückmeldung aber noch aus- +steht.) + +2: Auftrag zur Ausführung angenommen (Der Auftrag wurde vom abwickeln- +den System zur Ausführung angenommen. Achtung: Wenn der Auftrag eine +Änderung oder Streichung war, bedeutet dieser Status nicht, dass die Be- +zugsorder tatsächlich schon geändert bzw. gestrichen worden ist. Es kann +vorkommen, dass die Bezugsorder im Zeitpunkt der Änderungs- +/Streichungsannahme gerade an der Börse ausgeführt wird. Maßgeblich für +den Kunden ist immer der jeweilige Orderstatus.) + +3: Auftrag abgelehnt (Eines der Kreditinstitutssysteme hat aufgrund von Prü- +fungen den Auftrag abgelehnt. Auch im Nachhinein sollte der Grund hierfür +rekonstruierbar sein. Informationen zu abgelehnten Aufträgen können mit +dem Geschäftsvorfall „Orderstatus“ oder ,,Orderanzeige" angefordert wer- +den.) + +4: Orderänderung vorgemerkt (Die Order wurde noch nicht ausgeführt. für +den Auftrag liegt eine Änderungsvormerkung vor.) + +5: Orderstreichung vorgemerkt (Die Order wurde noch nicht ausgeführt. für +den Auftrag liegt eine Streichungsvormerkung vor.) + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
754		Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt:
SEPA-Zahlungsverkehr
+ + +6: Order ausgeführt (Die Order wurde ausgeführt und kann daher nicht mehr +geändert oder gestrichen werden. Dies bedeutet, dass auch eine Ausfüh- +rungsanzeige (MT 513) abrufbar ist, wenn diese vom Kreditinstitut angebo- +ten wird.) + +7: Order teilausgeführt (In diesem Fall können dem Kunden weitere Informa- +tionen zur Teilausführung im DE ,,Auftragsbezogene Informationen“ mitgeteilt +werden. Bei Änderungen und Streichungen kann das Kreditinstitut den Auf- +trag unter Vorbehalt annehmen, indem es das Kennzeichen „Erneutes Sen- +den erforderlich“ setzt, um so vom Kunden eine Bestätigung der Teilausfüh- +rung zu erhalten.) + +8: Order abgerechnet (Die Order wurde abgerechnet. Dies bedeutet, dass +auch eine Abrechnung (MT 515) abrufbar ist, wenn diese vom Kreditinstitut +angeboten wird.) + +9: Order gemäß Kundenwunsch gestrichen (Die Order wurde vom Kunden +gestrichen.) + +10: Order gemäß Usancen gestrichen (Die Order wurde vom Kreditinstitut +bzw. von der Börse gelöscht.) + +11: Order abgelaufen (Die Order wurde gelöscht, da der maximale Gültig- +keitstermin der Order überschritten wurde.) + +12: gelöschte Direkthandelsorders (Die Direkthandelsorder wurde durch den +,Market Maker" gestrichen.) + +13: Überprüfung Orderbuch Direkthandel (Der Auftrag (Quoteannahme) wur- +de seitens des Wertpapierabwicklers angenommen, konnte aber aufgrund +eines technischen Problems nicht beantwortet werden. Dem Kunden wird +empfohlen sein Orderbuch abzurufen.) + +14: alle Direkthandelsorders (Im Orderbuch werden alle Direkthandelsorders +nach Status ,,offen“, ,,ausgeführt“, ,,abgerechnet“ und ,,gelöscht“ ausgewie- +sen.) + +15: offene Direkthandelsorder (Im Orderbuch werden alle offenen Direkthan- +delsorders angezeigt.) + +16: ausgeführte Direkthandelsorder (Im Orderbuch werden alle ausgeführten +Direkthandelsorders angezeigt.) + +17: abgerechnete Direkthandelsorder (Im Orderbuch werden alle abgerech- +neten Direkthandelsorders angezeigt.) + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:..2
Version:33
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 755
+ + +![](figures/175.1) + + +Welchen Informationsgehalt bzw. welche Rechtsfolgen die +jeweiligen Statusmeldungen für den Kunden haben, sollte +das Kreditinstitut in entsprechenden Kundenbedingungen +festlegen. + + +## Wertpapierreferenz + +Wertpapierreferenz, über die z.B. eine Umsatzanfrage auf ein bestimmtes +Papier eingeschränkt werden kann. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Referenzart2DEcode1M11, 2, 3, 4
2Wertpapiercode1DEan.30M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:2
+ + +## Wertpapierumsatz + +Angabe in Stück bei Aktienpapieren. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:wrt
Länge:#
Version:1
+ + +## Wichtige Informationen + +Referenzen auf die letzten Versionen aller vorliegenden Arten und Katego- +rien der Wertpapierhinweise, die der Kunde mit der Order einzustellen hat, +falls das Kreditinstitut über die Bankparameterdaten mitteilt, dass diese In- +formationen bei der Ordereinreichung verpflichtend sind. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Art der wichti- gen Informatio- nen2DEcode1M11,2
2Kategorie der wichtigen In- formationen1DEan.30O1
3Datum1DEdat#M1
4Versionsnum- mer1DEnum..3M1
5Wertpapierhin- weis1DEtxt..
2048		M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:2
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
756		Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + +![](figures/176.1) + + +Liegen wichtige Informationen vor, so müssen sie dem +Kunden angezeigt und vom Kunden explizit bestätigt +werden (z.B. durch Mausklick). + + +## Wichtige Informationen verpflichtend + +Kennzeichen dafür, ob im Kundenauftrag das Senden der aktuellen im Kun- +denprodukt vorliegenden wichtigen Informationen für Wertpapiere verpflich- +tend ist. + +Falls wichtige Informationen für Wertpapiere verpflichtend sind, muss kredit- +institutsseitig der Geschäftsvorfall ,,Wichtige Informationen anfordern“ auch +angeboten werden. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +## Widerrufen + +gibt an, ob es sich bei der gemeldeten Lastschrift um eine bereits widerrufe- +ne Lastschrift handelt. Damit steht dem Benutzer eine Kontrolle und Historie +der widerrufenen Lastschriften zur Verfügung. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +## Wiederanlagekennzeichen + +Information darüber, wie die Festgeldanlage bei ihrer Fälligkeit behandelt +wird. + +Codierung: + +1: ausbuchen + +2: um den vereinbarten Zeitraum prolongieren + +3: auf Sparkonto mit 3-monatiger Kündigungsfrist umstellen + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:2
+ + +## Wiederanlagekennzeichen änderbar + +Information darüber, ob das Wiederanlagekennzeichen vom Kunden änder- +bar ist. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand:
07.08.2015		Seite: 757
+ + + + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +## Wiederanlagekennzeichen bei Prolongation + +Information darüber, wie die prolongierte Festgeldanlage bei ihrer Fälligkeit +behandelt wird. + + +### Codierung: + +1: ausbuchen + +2: um den vereinbarten Zeitraum prolongieren + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:2
+ + +## Wiederanlagerabatt + +Kennzeichen dafür, ob der Kunde einen Wiederanlagerabatt in Anspruch +nehmen möchte, falls ein Wiederanlagerabatt gemäß Bankparameterdaten +zulässig ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +## Wiederanlagerabatt bis + +Endedatum für einen Wiederanlagerabatt. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dat
Länge:#
Version:1
+ + +### Wiederanlagerabatt möglich + +Kennzeichen dafür, ob das Kreditinstitut einen Wiederanlagerabatt zulässt. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +## Wiederanlagerabatt von + +Anfangsdatum für einen Wiederanlagerabatt. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dat
Länge:#
Version:1
+ + +## Wiederanlagerabatt, Höhe + +Höhe des Wiederanlagerabatts. Angabe erfolgt in Prozent. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
758		Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:wrt
Länge:#
Version:1
+ + +## Willenserklärung erforderlich + +Das Kreditinstitut hat anzugeben, ob der korrekte Empfang der Kreditinsti- +tutsnachricht vom Kunden mit einer Empfangsmeldung (Geschäftsvorfall +„Willenserklärung des Kunden“) zu bestätigen ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +Z + + +## Zahlungsauftragsstatus + +Status eines Zahlungsauftrags. + +Codierung: + +0: noch nicht bearbeitet + +1: ausgeführt + +2: vorgemerkt + +3: abgelehnt + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:1
+ + +### Zahlungsperiode + +Zahlungsperiode (gemäß WM GD 811). + +Codierung: + +0: monatlich + +1: jährlich + +2: halbjährlich + +3: viermonatlich + +4: vierteljährlich + +5: neunmonatlich + +6: zweimonatlich + +7: zweijährlich + +8: Zahlung am Laufzeitende + +9: keine Zahlungstermine + +A: fünfmonatlich + +B: siebenmonatlich + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Data Dictionary
SEPA-Zahlungsverkehr		Stand: 07.08.2015Seite: 759
+ + +C: achtmonatlich + +D: zehnmonatlich + +E: elfmonatlich + +F: fünfjährlich + + + + + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:1
Referenz:WM GD 811
+ + +## Zahlungsrückstand + +Zahlungsrückstand eines Darlehens. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:btg
Länge:#
Version:1
+ + +## Zahlungstermin + +Nächster Zahlungstermin (im Format: MMTT). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dig
Länge:4
Version:1
+ + +## Zeichnung möglich + +Kennzeichen dafür, ob der Geschäftsvorfall „Neuemission zeichnen“ für die- +ses Wertpapier ausgeführt werden kann. Dabei sind jedoch kundenindividu- +elle Hinderungsgründe (z.B. Risikoklasse nicht ausreichend) nicht berück- +sichtigt. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +## Zeichnungserläuterung + +Erläuterung zur Zeichnung. Z.B. für den Fall, dass die Zeichnung nicht mög- +lich ist (z.B. ,,Zeichnungsfrist abgelaufen", ,,Prospekt liegt noch nicht vor"). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:txt
Länge:200
Version:1
+ + +## Zeichnungsfrist bis + +Datum und ggf. Uhrzeit des Endes der Zeichnungsfrist bei Neuemissionen. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
760		Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:tsp
Länge:#
Version:1
+ + +## Zeichnungsfrist von + +Datum und ggf. Uhrzeit des Anfangs der Zeichnungsfrist bei Neuemissionen. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:tsp
Länge:#
Version:1
+ + +## Zeichnungsfrist, Erläuterung + +Erläuterungen zur Zeichnungsfrist bei Neuemissionen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:txt
Länge:..80
Version:1
+ + +## Zeichnungsverfahren + +Gibt das Verfahren an, mit dem eine Neuemission gezeichnet werden kann. + +Codierung: + +1: Bookbuilding + +2: Auktion + +3: Festpreis + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:1
+ + +## Zeit Bestätigung/Ablehnung + +Wurde der Auftrag angenommen oder abgelehnt, so kann hier ferner der +Zeitpunkt der Annahme bzw. Ablehnung eingestellt werden. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:tim
Länge:#
Version:1
+ + +## Zeitbezug + +Zeitbezug für die Bestimmung des Jahreshöchststands und des Jahrestiefst- +stands. + +Codierung: + +1: letzte 12 Monate +2: seit 1.1. des Jahres + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 761
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:2
+ + +## Zeiteinheit + +Zeiteinheit, auf die sich die Angabe des Turnus bezieht. Es darf nur ein ge- +mäß BPD zugelassener Wert eingestellt werden. + +Codierung: + +M: Monat + +W: Woche + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:2
+ + +## Zeiteinheit änderbar + +Kennzeichen dafür, ob die Zeiteinheit des Dauerauftrags durch den Kunden +änderbar ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +## Zeitlimit + +Zeitlimit einer Wertpapierorder. + +Referenz: MT 502, Feld B:98A: + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dat
Länge:#
Version:1
+ + +### Zeitlimit änderbar + +Kennzeichen dafür, ob kreditinstitutsseitig eine Änderung des Zeitlimits zu- +lässig ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +### Zeitraum bis + +Endedatum eines Zeitraums. Durch die Angabe eines Von- und Bis-Datums +kann der Zeitraum eingeschränkt werden. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
762		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dat
Länge:#
Version:1
+ + +## Zeitraum möglich + +Kennzeichen dafür, ob der Kunde im Auftrag einen Zeitraum angeben kann. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +## Zeitraum von + +Anfangsdatum eines Zeitraums. Durch die Angabe eines Von- und Bis- +Datums kann der Zeitraum eingeschränkt werden. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dat
Länge:#
Version:1
+ + +## Zeitwert + +Aktueller Wert eines Sparbriefes. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:btg
Länge:#
Version:1
+ + +## Zeitzone + +Gibt die Zeitzone an. Bezugszeit ist immer UTC (Coordinated Universal Time +auch bekannt als GMT = Greenwich Main Time). Die verschiedenen Zeitzo- +nen werden durch hinzurechnen bzw. abziehen der Stunden von UTC ange- +geben. ,UTC" ist nicht mit anzugeben. Es ist darauf zu achten „+“ als Syn- +taxzeichen zu entwerten. + +Beispiele: + +Für MEZ: +1 + +Für MESZ: +2 + +Für CST: -6 + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..4
Version:1
+ + +## Zinsbindungsende + +Ablaufdatum Festzinssatz. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dat
Länge:#
Version:1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 763
+ + +# Zinsertrag voraussichtlich + +Erwarteter Zinsertrag der laufenden Anlageperiode. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:btg
Länge:#
Version:1
+ + +![](figures/183.1) + + +Der Kunde ist darauf hinzuweisen, dass diese Angabe nicht +rechtsverbindlich ist. + + +## Zinsgutschriftkonto + +Kennzeichen dafür, welchem Konto die Anlagezins gutgeschrieben werden +sollen, falls die Anlagezins nicht kapitalisiert, sondern ausgezahlt werden sol- +len. + +Falls die Zinsen kapitalisiert (d.h. am Ende der Anlageperiode dem Anlage- +konto gutgeschrieben) werden sollen, ist das DE nicht zu belegen. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:ktv
Länge:#
Version:3
+ + +## Zinsgutschriftkonto + +Kennzeichen dafür, welchem Konto die Anlagezinsen gutgeschrieben wer- +den sollen, falls die Anlagezinsen nicht kapitalisiert, sondern ausgezahlt +werden sollen. + +Falls die Zinsen kapitalisiert (d.h. am Ende der Anlageperiode dem Anlage- +konto gutgeschrieben) werden sollen, ist das DE nicht zu belegen. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:kti
Länge:#
Version:4
+ + +## Zinsgutschriftkonto änderbar + +Kennzeichen dafür, ob das Zinsgutschriftkonto vom Kunden geändert wer- +den kann. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +## Zinsmethode + +Zinsmethode, die den in den Konditionen angegebenen Zinssätzen zugrunde +liegt (Codierung gemäß SWIFT). + +Codierung: + +A: 30 Tage pro Monat, 360 Tage pro Jahr + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
764		Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + +B: 28-31 Tage pro Monat, 360 Tage pro Jahr + +C: 28-31 Tage pro Monat, 365/6 Tage pro Jahr + +D: 30 Tage pro Monat, 365/6 Tage pro Jahr + +E: 28-31 Tage pro Monat, 365 Tage pro Jahr + +F: 30 Tage pro Monat, 365 Tage pro Jahr + +Z: Sonstige (bilateral vereinbart) + + + + + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:2
Referenz:SWIFT
+ + +## Zinsperiode + +Zinsperiode, die den in den Konditionen angegebenen Zinssätzen zugrunde +liegt (gemäß WM GD 811). + +Codierung: + +0: monatlich + +1: jährlich + +2: halbjährlich + +3: viermonatlich + +4: vierteljährlich + +5: neunmonatlich + +6: zweimonatlich + +7: zweijährlich + +8: Zinsz. am Laufzeitende + +9: keine Zinstermine + +A: fünfmonatlich + +B: siebenmonatlich + +C: achtmonatlich + +D: zehnmonatlich + +E: elfmonatlich + +F: fünfjährlich + + + + + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:2
Referenz:WM GD 811
+ + +### Zinssatz + +Zinssatz für die Grundverzinsung der Anlage p.a. (die Anzahl der Nachkom- +mastellen ist kreditinstitutsspezifisch). + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 765
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:wrt
Länge:#
Version:1
+ + +## Zinssatz, effektiv + +Effektiver Zinssatz eines Laufzeitdarlehens in Prozent p.a. (die Anzahl der +Nachkommastellen ist kreditinstitutsspezifisch). + +Typ: DE + +Format: wrt + +Länge: # + +Version: 1 + + +## Zinssatz, nominal + +Nominaler Zinssatz eines Laufzeitdarlehens in Prozent p.m. (die Anzahl der +Nachkommastellen ist kreditinstitutsspezifisch). + +Typ: DE + +Format: wrt + +Länge: # + +Version: 1 + + +## Zinssatz Sollzins + +Zinssatz einer auf einem Kontokorrentkonto eingeräumten Kredits in Prozent +p.a. (die Anzahl der Nachkommastellen ist kreditinstitutsspezifisch). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:wrt
Länge:#
Version:1
+ + +## Zinstermin + +Nächster Zinstermin (im Format: MMTT). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dig
Länge:4
Version:1
+ + +## Zinszahlungsperiode + +Zahlungsperiode, die den in den Konditionen angegebenen Zinssätzen zu- +grunde +liegt (gemäß WM GD 811). + +Codierung: + +0: monatlich + +1: jährlich + +2: halbjährlich + +3: viermonatlich + +4: vierteljährlich + +5: neunmonatlich + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
766		Stand: 07.08.2015Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + +6: zweimonatlich + +7: zweijährlich + +8: Zinsz. am Laufzeitende + +9: keine Zinstermine + +A: fünfmonatlich + +B: siebenmonatlich + +C: achtmonatlich + +D: zehnmonatlich + +E: elfmonatlich + +F: fünfjährlich + + + + + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:1
Referenz:WM GD 811
+ + +## Zinszahlungstermin + +Nächster Zinszahlungstermin (im Format: MMTT). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dig
Länge:4
Version:1
+ + +## Zugelassene Weisungsschlüssel + +Gibt die vom Kreditinstitut tatsächlich zugelassenen Weisungsschlüssel des +zugrunde liegenden DTAZV-Handbuches vor. Die verschiedenen Weisungs- +schlüssel werden innerhalb des Datenelementes mit Semikolon getrennt. (s. +[DTAZV]). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..64
Version:1
+ + +## Zulässige Abfragen + +Information zur Einschränkung der Auswahl der Abfragen, wenn das Kredit- +institut einzelne Geschäftsvorfälle des Wertpapiergeschäftes nicht anbietet. +Dabei werden Kürzel für die Stati angegeben, die abfragbar sind. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Data Dictionary
SEPA-Zahlungsverkehr		Stand:
07.08.2015		Seite: 767
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..2
Version:1
+ + +## Zulässige Börsenplätze + +Börsenplätze, die für die Ausführung des betreffenden Wertpapiergeschäfts +zulässig sind. Die Börsenplätze werden als MIC kodiert (s. DE „Börsen- +platz“). Die einzelnen Codes werden durch ein Semikolon voneinander ge- +trennt. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..4096
Version:2
+ + +## Zulässige Emissionsfilter + +Vom Kreditinstitut unterstützte Filter für die Auswahl von Emissionen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:1
Version:1
+ + +## Zulässige Emittenten + +Fondsgesellschaften, bei denen der Kunde Fonds handeln kann. Die Kodie- +rung erfolgt gemäß WM GD 240 bzw. 245. + +Die einzelnen Codes werden durch ein Semikolon voneinander getrennt +(Beispiel: ,123456; 123457; 123458“). + +Findet keine Einschränkung statt, ist keine Angabe zu erfolgen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:200
Version:1
+ + +## Zulässige Karte + +Informationen zu den zulässigen Kartenarten und -bezeichnungen für die +Kartensperrung. Die Angaben werden jeweils per Semikolon getrennt. Die +Kartenart ist ein eindeutiges Identifikationskennzeichen (Format num..2). Die +Kartenbezeichnung (Format an..35) ist eine institutsspezifische Bezeichnung +(z.B. ,,Eurocard Gold", ,Servicekarte“). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..40
Version:1
+ + +### Zulässige Kategorien + +Vom Kreditinstitut definierte zulässige Kategorie wichtiger Wertpapier- +informationen (z.B. Aktien, Renten). + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
768		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..30
Version:1
+ + +## Zulässige Limitarten + +Codes für Limitarten, die der Kunde im S.W.I.F.T.-Format MT 502 in Feld +B:22F: (Indikator für Art des Limits) angeben darf. Mindestens ein Code ist +anzugeben. Die einzelnen Codes werden durch ein Semikolon voneinander +getrennt. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..99
Version:1
+ + +## Zulässige Limitschritte + +Limitschritte, z.B. bei der Zeichnung von Neuemissionen. Die Währung die- +ses Feldes entspricht der Währung des DE ,,Preisspanne“. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:wrt
Länge:#
Version:1
+ + +## Zulässige Orderarten + +Codes für Orderarten, die der Kunde im S.W.I.F.T.-Format MT 502 in Feld +B:22F: (Indikator für Art der Order) angeben darf. Die einzelnen Codes wer- +den durch ein Semikolon voneinander getrennt. + +Falls kein Code angegeben ist, darf der Kunde das Feld B:22F: (Indikator für +Art der Order) nicht belegen. Die Transaktionsbedingung ,,variabel" ist unab- +hängig von diesen Angaben immer zulässig. + +Abhängig vom Handelssystem hat der Code ,,NOHE" die folgende Bedeu- +tung: + +Parketthandel: + +Code gesendet: Kassa + +Code nicht gesendet: variabler Handel + +XETRA-Handel: + +Code gesendet: Auction only + +Code nicht gesendet: Continuous trading + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..99
Version:1
+ + +### Zulässige Purpose Codes + +Purpose codes, die für die Ausführung der betreffenden sepa pain message +zulässig sind. Die purpose codes werden ISO kodiert [DFÜ-Abkommen]. Die +einzelnen Codes werden durch ein Semikolon voneinander getrennt. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: D
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		SEPA-Zahlungsverkehr
Data Dictionary		Stand: 07.08.2015Seite: 769
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..4096
Version:1
+ + +## Zulässige Wertpapiergruppe + +Angaben der Wertpapiergruppen, die der Kunde in seinem Auftrag selektie- +ren darf. Die Bestimmung der Gruppen kann institutsspezifisch vorgenom- +men werden. Wird die Selektion nach Gruppen nicht zugelassen, ist diese +Angabe nicht zu erfolgen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:1
+ + +### Zulässige Zeitlimits + +Codes für Zeitlimits, die der Kunde im S.W.I.F.T.-Format MT 502 in Feld +B:22F: (Indikator für Zeitlimit) angeben darf, wenn die Art des Zeitlimits än- +derbar ist. + +Abhängig vom Handelssystem haben die folgenden Codes die nachstehen- +de Bedeutung: + +Parketthandel: + +OPEN: Ausführung zum Eröffnungskurs + +CLOS: Ausführung zum Schlusskurs + +XETRA-Handel: + +OPEN: Opening-Auction + +CLOS: Close-Auction + +Wenn die Änderung der Art des Zeitlimits nicht zulässig ist, ist keine Angabe +zu erfolgen. Wenn die Änderung der Art des Zeitlimits zulässig ist, ist min- +destens ein Code ist anzugeben. Die einzelnen Codes werden durch ein +Semikolon voneinander getrennt. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..99
Version:1
+ + +### Zulässiger Textschlüssel + +Textschlüssel, der vom Kreditinstitut zur Verwendung durch den Kunden zu- +gelassen ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dig
Länge:2
Version:1
+ + +### Zulässiges Zielland + +Länderkennzeichen des Ziellands gemäß dem Alpha-ISO -Code, in das das +Versenden einer Auslandsüberweisung ohne Meldeteil möglich ist. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
770		Stand:
07.08.2015		Kapitel: Data Dictionary
Abschnitt: SEPA-Zahlungsverkehr
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..2
Version:1
+ + +## Zulässiges Zielland Euro-STP-Zahlung + +Länderkennzeichen des Ziellands, in das das Versenden einer Euro-STP- +Zahlung möglich ist. Die für Euro-STP-Zahlungen zulässigen Zielländer sind +dem Anhang 4 des DTAZV-Datensatzes zu entnehmen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:ctr
Länge:#
Version:1
+ + +## Zusatzinformationen + +Zusätzliche Informationen als Freitext. + + + + + + + + + + + + + + + +
Format:txt
Länge:..1024
Version:1
+ + +## Zweites Preislimit änderbar + +Kennzeichen dafür, ob kreditinstitutsseitig eine Änderung dieses Parameters +zulässig ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +## Zweites Preislimit, Prozent + +Zweite Limitangabe im Rahmen einer One-Cancels-Other-Order, ausge- +drückt als Prozentsatz. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:wrt
Länge:#
Version:1
+ + +## Zweites Preislimit, Wert + +Zweite Limitangabe im Rahmen einer One-Cancels-Other-Order, ausge- +drückt als Wert. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:wrt
Länge:#
Version:1
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: E
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:AnlagenStand:Seite:
Abschnitt:Übersicht der Segmente07.08.20151
+ + +# E. ANLAGEN + + +## E.1 Übersicht der Segmente + +Die Segmente für Geschäftsvorfälle für den Zahlungsverkehr Inland [Messages-IZV] +befinden sich in einem eigenen Band und sind in der Aufstellung kursiv gekenn- +zeichnet. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.SegmentnameKennungSen- der1Ver- sion
1AdressänderungHKADRK1
2Adressänderung ParameterHIADRSI1
3Änderung terminierter Einzellastschrift bestätigenHITEAI1
4Änderung terminierter SEPA-Einzellastschriften bestätigenHIDSAI1
5Änderung terminierter SEPA-Firmeneinzellastschrift be- stätigenHIBSAI1
6Änderung terminierter SEPA-Überweisung bestätigenHICSAI1
7Änderung terminierter Überweisung bestätigenHITUAI4
8Anlage vorbereiteter SEPA-Überweisung bestätigenHICVEI1
9Anlage vorbereiteter Überweisung bestätigenHIVUEI1
10Auftragsdetails für C-TransaktionenHKCTDK1
11Auftragsdetails für C-Transaktionen ParameterHICTDSI1
12Auftragsdetails für C-Transaktionen rückmeldenHICTDI1
1013Ausgeführte Überweisungen anfordernHKAUEK1
1114Ausgeführte Überweisungen rückmeldenHIAUEI1
1215Ausgeführte Überweisungen ParameterHIAUESI1
1316AuslandsüberweisungHKAUBK6, 7, 8
1417Auslandsüberweisung ohne MeldeteilHKAOMK2
1518Auslandsüberweisung ohne Meldeteil ParameterHIAOMSI2
1619Auslandsüberweisung ParameterHIAUBSI6, 7, 8
20Auslösen von C-TransaktionenHKCTAK1
21Auslösen von C-Transaktionen ParameterHICTASI1
22Auswahl Postfach-Nachrichtentypen rückmeldenHIAPNI1
1723Bearbeitungsstatus Dokument anfordernHKFDBK2
1824Bearbeitungsstatus Dokument ParameterHIFDBSI2
1925Bearbeitungsstatus Dokument rückmeldenHIFDBI2
2026Bearbeitungsstatus Finanzdatenformat anfordernHKFDBK2
2127Bearbeitungsstatus Finanzdatenformat ParameterHIFDBSI2
2228Bearbeitungsstatus Finanzdatenformat rückmeldenHIFDBI2
29Bestand Daueraufträge Prepaidkarte laden anfordernHKPPBK1
30Bestand Daueraufträge Prepaidkarte laden ParameterHIPPBSI1
31Bestand Daueraufträge Prepaidkarte laden rückmeldenHIPPBI1
2332Bestand Empfängerkonten anfordernHKCUBK1
2433Bestand LastschriftwiderspruchHKLWBK1, 2
+ +1 +K: Kunde, I: Kreditinstitut + + + + + + + + + + + + + + + + +
Kapitel: EVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
2		Stand: 07.08.2015Kapitel: Anlagen
Abschnitt: Übersicht der Segmente
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.SegmentnameKennungSen- der1Ver- sion
2534Bestand LastschriftwiderspruchHILWBI1, 2
2635Bestand Lastschriftwiderspruch ParameterHIDSBSI1
2736Bestand Lastschriftwiderspruch ParameterHILWBSI1,2
2837Bestand SEPA-Lastschriftwiderspruch anfordernHKDSBK1
2938Bestand SEPA-Lastschriftwiderspruch rückmeldenHIDSBI1
3039Bestand terminierter Einzellastschriften anfordernHKTEBK1
3140Bestand terminierter Einzellastschriften ParameterHITEBSI1
3241Bestand terminierter Einzellastschriften rückmeldenHITEBI1
3342Bestand terminierter Sammellastschriften anfordernHKSLBK2
3443Bestand terminierter Sammellastschriften ParameterHISLBSI3
3544Bestand terminierter Sammellastschriften rückmeldenHISLBI3
3645Bestand terminierter Sammelüberweisungen anfordernHKTSBK3
3746Bestand terminierter Sammelüberweisungen ParameterHITSBSI3
3847Bestand terminierter Sammelüberweisungen rückmeldenHITSBI3
3948Bestand terminierter SEPA-Einzellastschriften anfordernHKDBSK1,2
4049Bestand terminierter SEPA-Einzellastschriften ParameterHIDBSSI1,2
4150Bestand terminierter SEPA-Einzellastschriften rückmeldenHIDBSI1,2
4251Bestand terminierter SEPA-Sammellastschriften anfordernHKDMBK1
4352Bestand terminierter SEPA-Firmeneinzellastschriften an- fordernHKBBSK1,2
4453Bestand terminierter SEPA-Firmeneinzellastschriften Pa- rameterHIBBSSI1,2
4554Bestand terminierter SEPA-Firmeneinzellastschriften rückmeldenHIBBSI1,2
4655Bestand terminierter SEPA-Firmensammellastschriften anfordernHKBMBK1
4756Bestand terminierter SEPA-Firmensammellastschriften ParameterHIBMBSI1
4857Bestand terminierter SEPA-Firmensammellastschriften rückmeldenHIBMBI1
4958Bestand terminierter SEPA-Sammellastschriften Parame- terHIDMBSI1
5059Bestand terminierter SEPA-Sammellastschriften rückmel- denHIDMBI1
5160Bestand terminierter SEPA-Sammelüberweisungen anfor- dernHKCMBK1
5261Bestand terminierter SEPA-Sammelüberweisungen Pa- rameterHICMBSI1
5362Bestand terminierter SEPA-Sammelüberweisungen rück- meldenHICMBI1
5463Bestand terminierter SEPA-Überweisungen anfordernHKCSBK1,2
5564Bestand terminierter SEPA-Überweisungen ParameterHICSBSI1,2
5665Bestand terminierter SEPA-Überweisungen rückmeldenHICSBI1,2
5766Bestand terminierter Überweisungen anfordernHKTUBK3
5867Bestand terminierter Überweisungen ParameterHITUBSI3
5968Bestand terminierter Überweisungen rückmeldenHITUBI3
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: E
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:AnlagenStand:Seite:
Abschnitt:Übersicht der Segmente07.08.20153
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.SegmentnameKennungSen- der1Ver- sion
6069Bestand vorbereiteter SEPA-ÜberweisungenHICVBI1
6170Bestand vorbereiteter SEPA-Überweisungen abfragenHKCVBK1
6271Bestand vorbereiteter SEPA-Überweisungen ParameterHICVBSI1
6372Bestand vorbereiteter ÜberweisungenHIVUBI1
6473Bestand vorbereiteter Überweisungen abfragenHKVUBK1
6574Bestand vorbereiteter Überweisungen ParameterHIVUBSI1
6675Bestätigung Einreichung garantierte ÜberweisungHIGUBI1
6776Dauerauftrag ändernHKDANK5
6877Bestätigung Elektronischer Kontoauszug beantragenHIEKBI1
6978Dauerauftrag ändern ParameterHIDANSI5
7079Dauerauftrag aussetzenHKDASK4
7180Dauerauftrag aussetzen ParameterHIDASSI4
7281Dauerauftrag einrichtenHKDAEK5
7382Dauerauftrag einrichten ParameterHIDAESI5
7483Dauerauftrag löschenHKDALK4
7584Dauerauftrag löschen ParameterHIDALSI4
85Dauerauftrag Prepaidkarte laden bestätigenHIPPEI1
86Dauerauftrag Prepaidkarte laden einrichtenHKPPEK1
87Dauerauftrag Prepaidkarte laden einrichten ParameterHIPPESI1
7688Dauerauftragsänderung bestätigenHIDANI5
7789Dauerauftragsänderungsvormerkungen anfordernHKDAAK4
7890Dauerauftragsänderungsvormerkungen ParameterHIDAASI4
7991Dauerauftragsänderungsvormerkungen rückmeldenHIDAAI4
8092Dauerauftragsaussetzung bestätigenHIDASI4
8193Dauerauftragsbestand anfordernHKDABK4, 5
8294Dauerauftragsbestand ParameterHIDABSI4, 5
8395Dauerauftragsbestand rückmeldenHIDABI4, 5
8496Dauerauftragseinrichtung bestätigenHIDAEI5
8597Dauereinzellastschrift ändernHKDEAK1
8698Dauereinzellastschrift ändern ParameterHIDEASI1
8799Dauereinzellastschrift aussetzenHKDEUK1
88100Dauereinzellastschrift aussetzen ParameterHIDEUSI1
89101Dauereinzellastschrift einrichtenHKDEEK1
90102Dauereinzellastschrift einrichten ParameterHIDEESI1
91103Dauereinzellastschrift löschenHKDELK1
92104Dauereinzellastschrift löschen ParameterHIDELSI1
93105Dauereinzellastschriftänderung bestätigenHIDEAI1
94106Dauereinzellastschriftaussetzung bestätigenHIDEUI1
95107Dauereinzellastschriftänderungsvormerkungen anfordernHKDEVK1
96108Dauereinzellastschriftänderungsvormerkungen anfordern ParameterHIDEVSI1
97109Dauereinzellastschriftänderungsvormerkungen rückmel- denHIDEVI1
98110Dauereinzellastschriftbestand anfordernHKDEBK1
99111Dauereinzellastschriftbestand ParameterHIDEBSI1
10011Dauereinzellastschriftbestand rückmeldenHIDEBI1
10111Dauereinzellastschrifteinrichtung bestätigenHIDEEI1
+ + + + + + + + + + + + + + + + +
Kapitel: EVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
4		Stand: 07.08.2015Kapitel: Anlagen
Abschnitt: Übersicht der Segmente
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.SegmentnameKennungSen- der1Ver- sion
10211Depotaufstellung anfordernHKWPDK6
10311Depotaufstellung ParameterHIWPDSI6
10411Depotaufstellung rückmeldenHIWPDI6
10511Depotumsätze anfordernHKWDUK5
10611Depotumsätze ParameterHIWDUSI5
10711Depotumsätze rückmeldenHIWDUI5
10812Devisenkurse anfordernHKDVKK2
10912Devisenkurse ParameterHIDVKSI2
11012Devisenkurse rückmeldenHIDVKI2
11112Dokument anfordernHKFDAK3
11212Dokument anfordern ParameterHIFDASI3
11312Dokument rückmeldenHIFDAI3
11412Dokument sendenHKFDSK3
11512Dokument senden ParameterHIFDSSI3
11612Dokumentliste anfordernHKFDLK3
11712Eilüberweisung (Einzel)HKEILK1
11813Eilüberweisung (Einzel) ParameterHIEILSI1
11913Eilüberweisung (Sammel)HKDTEK1
12013Eilüberweisung (Sammel) ParameterHIDTESI1
12113Eilzahlung einreichenHKCSUK1
12213Eilzahlung ParameterHICSUSI1
12313Einreichung Freistellungsauftrag bestätigenHIFRAI1
12413Einreichung terminierter Einzellastschrift bestätigenHITEEI1
12513Einreichung terminierter Sammellastschrift bestätigenHISLEI3
12613Einreichung terminierter Sammelüberweisung bestätigenHITSEI3
12713Einreichung terminierter SEPA-COR1-Einzellastschrift be- stätigenHIDSCI1
12814Einreichung terminierter SEPA-COR1-Sammellastschrift bestätigenHIDMCI1
12914Einreichung terminierter SEPA-Einzellastschrift bestätigenHIDSEI1,2
13014Einreichung terminierter SEPA-Firmeneinzellastschrift be- stätigenHIBSEI1,2
13114Einreichung terminierter SEPA-Firmensammellastschrift bestätigenHIBMEI1,2
13214Einreichung terminierter SEPA-Sammellastschrift bestäti- genHIDMEI1,2
13314Einreichung terminierter SEPA-Sammelüberweisung be- stätigenHICMEI1
13414Einreichung terminierter SEPA-Überweisung bestätigenHICSEI1
13514Einreichung terminierter Überweisung bestätigenHITUEI3
13614Einreichung Zeichnung bestätigenHINEZI2
13714EinzellastschriftHKLASK5
13815EinzelüberweisungHKUEBK5
13915Einzelüberweisung ParameterHIUEBSI5
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: E
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:AnlagenStand:Seite:
Abschnitt:Übersicht der Segmente07.08.20155
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.SegmentnameKennungSen- der1Ver- sion
14015Elektronischen Kontoauszug beantragenHKEKBK1
14115Elektronischen Kontoauszug beantragen ParameterHIEKBSI1
14215EmpfangsquittungHKQTGK1
14315Empfangsquittung ParameterHIQTGSI1
14415Empfängerkontenbestand ParameterHICUBSI1
14515Empfängerkontenbestand rückmeldenHICUBI1
158Erstellung Postfach-Kontoauszug bestätigenHIAPEI1
14615Euro-EilüberweisungHKEUEK1
14716Euro-Eilüberweisung ParameteHIEUESI1
14816Euro-STP-ZahlungHKSTPK1, 2, 3
14916Euro-STP-Zahlung ParameterHISTPSI1, 2, 3
15016EU-StandardüberweisungHKESUK1
15116EU-Standardüberweisung ParameterHIESUSI1
15216Festgeld ändern ParameterHIFGASI4
15316Festgeldänderung bestätigenHIFGAI4
15416Festgeldanlage ändernHKFGAK4
15516Festgeldanlage prolongierenHKFGPK4
15616Festgeldbestand anfordernHKFGBK4
15717Festgeldbestand ParameterHIFGBSI4
15817Festgeldbestand rückmeldenHIFGBI4
15917Festgeldkonditionen anfordernHKFGKK3
16017Festgeldkonditionen ParameterHIFGKSI3
16117Festgeldkonditionen rückmeldenHIFGKI3
16217FestgeldneuanlageHKFGNK4
16317Festgeldneuanlage bestätigenHIFGNI4
16417Festgeldneuanlage ParameterHIFGNSI4
16517Festgeldneuanlage widerrufenHKFGWK4
16617Festgeldneuanlage widerrufen ParameterHIFGWSI4
16718Festgeldprolongation bestätigenHIFGPI4
16818Festgeldprolongation ParameterHIFGPSI4
16918Festgeldprolongation widerrufenHKFPWK4
17018Festgeldprolongation widerrufen ParameterHIFPWSI4
17118Festpreisangebote anfordernHKWFPK3
17218Festpreisangebote ParameterHIWFPSI3
17318Festpreisangebote rückmeldenHIWFPI3
17418FestpreisorderHKFPOK2
17518Festpreisorder ParameterHIFPOSI2
17618Festpreisordereinreichung bestätigenHIFPOI2
17719Finanzdatenformat anfordernHKFDAK2
17819Finanzdatenformat anfordern ParameterHIFDASI2
17919Finanzdatenformat rückmeldenHIFDAI2
18019Finanzdatenformat sendenHKFDSK2
18119Finanzdatenformat senden ParameterHIFDSSI2
18219Finanzdatenformatliste anfordernHKFDLK2
18319Finanzdatenformatliste anfordern ParameterHIFDLSI2
18419Finanzdatenformatliste rückmeldenHIFDLI2
+ + + + + + + + + + + + + + + + +
Kapitel: EVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 6Stand: 07.08.2015Kapitel: Anlagen
Abschnitt: Übersicht der Segmente
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.SegmentnameKennungSen- der1Ver- sion
18519Fondsorder einreichenHKWFOK2
18619Fondsorder ParameterHIWFOSI2
18720Fondsordereinreichung bestätigenHIWFOI2
18820Freistellungsauftrag anlegenHKFRAK1
18920Freistellungsauftrag anlegen ParameterHIFRASI1
19020Freistellungsdaten abfragenHKFRDK2,3
19120Freistellungsdaten ändernHKFRNK1
19220Freistellungsdaten ändern ParameterHIFRNSI1
19320Freistellungsdaten löschenHKFRLK1
19420Freistellungsdaten löschen ParameterHIFRLSI1
19520Freistellungsdaten ParameterHIFRDSI2,3
19620Freistellungsdaten rückmeldenHIFRDI2,3
19721Garantierte ÜberweisungHKGUBK1
19821Garantierte Überweisung ParameterHIGUBSI1
19921GastmeldungHKGAMK4
20021Gastmeldung ParameterHIGAMSI4
20121Importierte SEPA Einzelüberweisung ParameterHICISSI1
20221Importierte SEPA-EinzelüberweisungHKCISK1
20321Importierte SEPA SammelüberweisungHKCIMK1
20421Importierte SEPA Sammelüberweisung ParameterHICIMS-
I		1
20521Informationen anfordernHKINFK4
20621Informationen rückmeldenHIINFI4
20722Informationsanforderung ParameterHIINFSI4
20822KartenanzeigeHIAZKI2
20922Kartenanzeige anfordernHKAZKK2
21022Kartenanzeige ParameterHIAZKSI2
21122Kartensperre beantragenHKKASK2
21222Kartensperre beantragen ParameterHIKASSI2
21322Kommunikationszugang anfordernHKKOMK4
21422Kommunikationszugang ParameterHIKOMSI4
21522Kommunikationszugang rückmeldenHIKOMI4
21622KontoauszugHIEKAI1, 2,
3, 4
21723Kontoauszug anfordernHKEKAK1, 2,
3, 4
21823Kontoauszug camtHIECAI1
21923Kontoauszug camt anfordernHKECAK1
22023Kontoauszug camt ParameterHIECASI1
22123Kontoauszug ParameterHIEKASI1, 2,
3, 4
22223Kontoauszug PDFHIEKPI1,2
22323Kontoauszug PDF anfordernHKEKPK1,2
22423Kontoauszug PDF ParameterHIEKPSI1,2
22523Kontoinformationen anfordernHKKIFK2, 3,
4, 5,
6, 7
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: E
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:AnlagenStand:Seite:
Abschnitt:Übersicht der Segmente07.08.20157
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.SegmentnameKennungSen- der1Ver- sion
22623Kontoinformationen ParameterHIKIFSI2, 3,
4, 5,
6, 7
22724Kontoinformationen rückmeldenHIKIFI2, 3,
4, 5,
6, 7
22824Kontoumsätze anfordern/neue UmsätzeHKKANK6, 7, 8
22924Kontoumsätze anfordern/neue Umsätze camtHKCANK1
23024Kontoumsätze anfordern/ZeitraumHKKAZK6. 7, 8
23124Kontoumsätze anfordern/Zeitraum camtHKCAZK1
23224Kontoumsätze rückmelden/neue UmsätzeHIKANI6, 7, 8
23324Kontoumsätze rückmelden/neue Umsätze camtHICANI1
23424Kontoumsätze rückmelden/ZeitraumHIKAZI6, 7, 8
23524Kontoumsätze rückmelden/Zeitraum camtHICAZI1
23624Kontoumsätze/neu camt ParameterHICANSI1
23725Kontoumsätze/neu ParameterHIKANSI6, 7, 8
23825Kontoumsätze/Zeitraum camt ParameterHICAZSI1
23925Kontoumsätze/Zeitraum ParameterHIKAZSI6, 7, 8
24025Kreditinstitutsangebote anfordernHKKIAK4
24125Kreditinstitutsangebote ParameterHIKIASI4
24225Kreditinstitutsangebote rückmeldenHIKIAI4
24325Kundendaten anfordernHKKDDK1
24425Kundendaten rückmeldenHIKDDI1
24525Kundendaten ParameterHIKDDSI1
24625KundenmeldungHKKDMK5
24726Kundenmeldung ParameterHIKDMSI5
24826Laden GeldKarte abmeldenHKLGAK2
24926Laden GeldKarte abmelden ParameterHILGASI2
25026Laden GeldKarte bestätigenHKLGBK2
25126Laden GeldKarte bestätigen AntwortHILGBI2
25226Laden GeldKarte bestätigen ParameterHILGBSI2
25326Laden GeldKarte durchführenHKLGDK2
25426Laden GeldKarte durchführen AntwortHILGDI2
25526Laden GeldKarte durchführen ParameterHILGDSI2
25626Laden GeldKarte einleitenHKLGEK2
25727Laden GeldKarte einleiten AntwortHILGEI2
25827Laden GeldKarte einleiten ParameterHILGESI2
25927Laden GeldKarte registrierenHKLGRK2
26027Laden GeldKarte registrieren ParameterHILGRSI2
26127Laden GeldKarte StatusHILGSI2
26227Laden GeldKarte StatusanfrageHKLGSK2
26327Laden GeldKarte Statusanfrage ParameterHILGSSI2
26427Laden GeldKarte Storno bestätigenHKLGXK2
26527Laden GeldKarte Storno BestätigungHILGXI2
26627Laden GeldKarte Storno bestätigen ParameterHILGXSI2
26728Laden GeldKarte Storno durchführenHKLGTK2
26828Laden GeldKarte Storno durchführen AntwortHILGTI2
+ + + + + + + + + + + + + + + + +
Kapitel: EVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 8Stand: 07.08.2015Kapitel: Anlagen
Abschnitt: Übersicht der Segmente
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.SegmentnameKennungSen- der1Ver- sion
26928Laden GeldKarte Storno durchführen ParameterHILGTSI2
27028Laden GeldKarte Storno vorbereitenHKLGOK2
27128Laden GeldKarte Storno vorbereiten AntwortHILGOI2
27228Laden GeldKarte Storno vorbereiten ParameterHILGOSI2
27328Laden GeldKarte vorbereitenHKLGVK2
27428Laden GeldKarte vorbereiten AntwortHILGVI2
27528Laden GeldKarte vorbereiten ParameterHILGVSI2
27628Lastschrift ParameterHICDSSI1
27729Lastschrift ParameterHILASSI5
27829Lastschriftwiderspruch beantragenHKLSWK1, 2
27929Lastschriftwiderspruch ParameterHILSWSI1, 2
28029Liste NeuemissionenHINEAI2
28129Liste Neuemissionen anfordernHKNEAK2
28229Liste Neuemissionen ParameterHINEASI2
296Löschen Dauerauftrag Prepaidkarte ladenHKPPLK1
297Löschen Dauerauftrag Prepaidkarte laden ParameterHIPPLSI1
28329Neuemission zeichnenHKNEZK2
28429Neuemission zeichnen ParameterHINEZSI2
28530OrderanzeigeHIOANI2, 3, 4
28630Orderanzeige anfordernHKOANK2, 3, 4
28730Orderanzeige ParameterHIOANSI2, 3, 4
28830OrderstatusHIWSOI3,4,5
28930Orderstatus anfordernHKWSOK3, 4, 5
29030Orderstatus ParameterHIWSOSI3,4,5
306Postfach-Kontoauszug erstellenHKAPEK1
307Postfach-Kontoauszug erstellen ParameterHIAPESI1
308Postfach-Nachricht abrufenHKKAAK1
309Postfach-Nachricht abrufen ParameterHIKAASI1
310Postfach-Nachricht löschenHKPNLK1
311Postfach-Nachricht löschen ParameterHIPNLSI1
312Postfach-Nachricht rückmeldenHIKAAI1
313Postfach-Nachrichtenliste anfordernHKPOFK1
314Postfach-Nachrichtenliste anfordern ParameterHIPOFSI1
315Postfach-Nachrichtenliste rückmeldenHIPOFI1
316Postfach-Nachrichtentypen anfordernΗΚΡΝΑK1
317Postfach-Nachrichtentypen anfordern ParameterHIPNASI1
318Postfach-Nachrichtentypen rückmeldenHIPNAI1
319Postfach-Nachrichtentypen auswählenHKAPNK1
320Postfach-Nachrichtentypen auswählen ParameterHIAPNSI1
29132Prepaidkarte ladenHKPPDK1,2
29232Prepaidkarte laden ParameterHIPPDSI1,2
29332SaldenabfrageHKSALK6, 7
29432Saldenabfrage ParameterHISALSI6, 7
29532SaldenrückmeldungHISALI6, 7
29632Sammeleilzahlung einreichenHKCMUK1
29732Sammeleilzahlung ParameterHICMUSI1
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: E
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:AnlagenStand:Seite:
Abschnitt:Übersicht der Segmente07.08.20159
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.SegmentnameKennungSen- der1Ver- sion
29832SammellastschriftHKSLAK6
29932Sammellastschrift ParameterHISLASI6
30033SammelüberweisungHKSUBK6
30133Sammelüberweisung ParameterHISUBSI6
332SEPA Card Clearing Nachricht einreichenHKSCCK1
333SEPA Card Clearing Nachricht einreichen ParameterHISCCSI1
30233SEPA EinzelüberweisungHKCCSK1
30333SEPA Einzelüberweisung ParameterHICCSSI1
30433SEPA-Dauerauftrag ändernHKCDNK1
30533SEPA-Dauerauftrag ändern ParameterHICDNSI1
30633SEPA-Dauerauftrag aussetzenHKCDUK1
30733SEPA-Dauerauftrag aussetzen ParameterHICDUSI1
30834SEPA-Dauerauftrag einrichtenHKCDEK1
30934SEPA-Dauerauftrag einrichten ParameterHICDESI1
31034SEPA-Dauerauftrag löschenHKCDLK1
31134SEPA-Dauerauftrag löschen ParameterHICDLSI1
31234SEPA-Dauerauftragsänderung bestätigenHICDNI1
31334SEPA-Dauerauftragsänderungsvormerkungen anfordernHKCDAK1
31434SEPA-Dauerauftragsänderungsvormerkungen ParameterHICDASI1
31534SEPA-Dauerauftragsänderungsvormerkungen rückmel- denHICDAI1
31634SEPA-Dauerauftragsaussetzung bestätigenHICDUI1
31734SEPA-Dauerauftragsbestand anfordernHKCDBK1
31835SEPA-Dauerauftragsbestand ParameterHICDBSI1
31935SEPA-Dauerauftragsbestand rückmeldenHICDBI1
32035SEPA-Dauerauftragseinrichtung bestätigenHICDEI1
32135SEPA-Dauereinzelastschriftänderungsvormerkungen rückmeldenHIDDAI1
32235SEPA-Dauereinzellastschrift ändernHKDDNK1
32335SEPA-Dauereinzellastschrift ändern ParameterHIDDNSI1
32435SEPA-Dauereinzellastschrift aussetzenHKDDUK1
32535SEPA-Dauereinzellastschrift aussetzen ParameterHIDDUSI1
32635SEPA-Dauereinzellastschrift einrichtenHKDDEK1
32735SEPA-Dauereinzellastschrift einrichten ParameterHIDDESI1
32836SEPA-Dauereinzellastschrift löschenHKDDLK1
32936SEPA-Dauereinzellastschrift löschen ParameterHIDDLSI1
33036SEPA-Dauereinzellastschriftänderung bestätigenHIDDNI1
33136SEPA-Dauereinzellastschriftänderungsvormerkungen an- fordernHKDDAK1
33236SEPA-Dauereinzellastschriftänderungsvormerkungen Pa- rameterHIDDASI1
33336SEPA-Dauereinzellastschriftaussetzung bestätigenHIDDUI1
33436SEPA-Dauereinzellastschriftbestand anfordernHKDDBK1
33536SEPA-Dauereinzellastschriftbestand ParameterHIDDBSI1
33636SEPA-Dauereinzellastschriftbestand rückmeldenHIDDBI1
33736SEPA-Dauereinzellastschrifteinrichtung bestätigenHIDDEI1
33837SEPA EinzellastschriftHKCDSK1
+ + + + + + + + + + + + + + + + +
Kapitel: EVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 10Stand: 07.08.2015Kapitel: Anlagen
Abschnitt: Übersicht der Segmente
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.SegmentnameKennungSen- der1Ver- sion
33937SEPA-FirmeneinzellastschriftHKBDSK1
34037SEPA Firmeneinzellastschrift ParameterHIBDSK1
34137SEPA-FirmensammellastschriftHKBDDK1
34237SEPA Firmensammellastschrift ParameterHIBDDSI1
34337SEPA-Kontoverbindung anfordernHKSPAK1, 2, 3
34437SEPA-Kontoverbindung anfordern, ParameterHISPASI1, 2, 3
34537SEPA-Kontoverbindung rückmeldenHISPAI1, 2, 3
34637SEPA-Lastschriftwiderspruch einreichenHKDSWK1
34737SEPA-Lastschriftwiderspruch ParameterHIDSWSI1
34838SEPA SammellastschriftHKCDDK1
34938SEPA Sammellastschrift ParameterHICDDSI1
35038SEPA-SammelüberweisungHKCCMK1
35138SEPA-Überweisung auf ein EmpfängerkontoHKCUMK1
35238SEPA-Überweisung auf ein Empfängerkonto ParameterHICUMSI1
35338SEPA-Sammelüberweisung ParameterHICCMSI1
386SEPA-StatusreportHKSSRK
387SEPA-Statusreport ParameterHISSRSI1
388SEPA-Statusreport rückmeldenHISSRI1
35438ServerzeitabfrageHKSZTK1
35539ServerzeitHISZTI1
35639Serverzeit ParameterHISZTSI1
35739Sorten- und ReisescheckbestellungHKSRBK2
35839Sorten- und Reisescheckbestellung ParameterHISRBSI2
35939Sorten- und Reisescheckkonditionen anfordernHKSRKK2
36039Sorten- und Reisescheckkonditionen ParameterHISRKSI2
36139Sorten- und Reisescheckkonditionen rückmeldenHISRKI2
36239Statusprotokoll anfordernHKPROK4
36339Statusprotokoll ParameterHIPROSI4
36439Statusprotokoll rückmeldenHIPROI4
36540Terminierte Einzellastschrift ändernHKTEAK1
36640Terminierte Einzellastschrift ändern ParameterHITEASI1
36740Terminierte Einzellastschrift einreichenHKTEEK1
36840Terminierte Einzellastschrift einreichen ParameterHITEESI1
36940Terminierte Einzellastschrift löschenHKTELK1
37040Terminierte Einzellastschrift löschen ParameterHITELSI1
37140Terminierte Sammellastschrift einreichenHKSLEK3
37240Terminierte Sammellastschrift einreichen ParameterHISLESI3
37340Terminierte Sammellastschrift löschenHKSLLK3
37440Terminierte Sammellastschrift löschen ParameterHISLLSI3
37541Terminierte Sammelüberweisung einreichenHKTSEK3
37641Terminierte Sammelüberweisung einreichen ParameterHITSESI3
37741Terminierte Sammelüberweisung löschenHKTSLK3
37841Terminierte Sammelüberweisung löschen ParameterHITSLSI3
37941Terminierte SEPA-COR1-EinzellastschriftHKDSCK1
38041Terminierte SEPA-COR1-Einzellastschrift ParameterHIDSCSI1
38141Terminierte SEPA-COR1-SammellastschriftHKDMCK1
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: E
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:AnlagenStand:Seite:
Abschnitt:Übersicht der Segmente07.08.201511
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.SegmentnameKennungSen- der1Ver- sion
38241Terminierte SEPA-COR1-Sammellastschrift ParameterHIDMCSI1
38341Terminierte SEPA-Einzellastschrift ändernHKDSAK1
38441Terminierte SEPA-Einzellastschrift ändern ParameterHIDSASI1
38542Terminierte SEPA-Einzellastschrift einreichenHKDSEK1,2
38642Terminierte SEPA-Einzellastschrift einreichen ParameterHIDSESI1,2
38742Terminierte SEPA-Einzellastschrift löschenHKDSLKI
38842Terminierte SEPA-Einzellastschrift löschen ParameterHIDSLSI1
38942Terminierte SEPA-Firmeneinzellastschrift ändernHKBSAK1
39042Terminierte SEPA-Firmeneinzellastschrift ändern Parame- terHIBSASI1
39142Terminierte SEPA-Firmeneinzellastschrift einreichenHKBSEK1,2
39242Terminierte SEPA-Firmeneinzellastschrift einreichen Pa- rameterHIBSESI1,2
39342Terminierte SEPA-Firmeneinzellastschrift löschenHKBSLK1
39442Terminierte SEPA-Firmeneinzellastschrift löschen Para- meterHIBSLSI1
39543Terminierte SEPA-Firmensammellastschrift einreichenHKBMEK1,2
39643Terminierte SEPA-Firmensammellastschrift einreichen Pa- rameterHIBMESI1,2
39743Terminierte SEPA-Firmenammellastschrift löschenHKBMLK1
39843Terminierte SEPA-Firmensammellastschrift löschen Pa- rameterHIBMLSI1
39943Terminierte SEPA-Sammellastschrift einreichenHKDMEK1,2
40043Terminierte SEPA-Sammellastschrift einreichen Parame- terHIDMESI1,2
40143Terminierte SEPA-Sammellastschrift löschenHKDMLK1
40243Terminierte SEPA-Sammellastschrift löschen ParameterHIDMLSI1
40343Terminierte SEPA-Sammelüberweisung einreichenHKCMEK1
40443Terminierte SEPA-Sammelüberweisung einreichen Para- meterHICMESI1
40544Terminierte SEPA-Sammelüberweisung löschenHKCMLK1
40644Terminierte SEPA-Sammelüberweisung löschen Parame- terHICMLSI1
40744Terminierte SEPA-Überweisung ändernHKCSAK1
40844Terminierte SEPA-Überweisung ändern ParameterHICSASI
I		1
40944Terminierte SEPA-Überweisung einreichenHKCSEK1
11044Terminierte SEPA-Überweisung einreichen ParameterHICSESI1
41144Terminierte SEPA-Überweisung löschenHKCSLK1
41244Terminierte SEPA-Überweisung löschen ParameterHICSLSI1
11344Terminierte Überweisung ändernHKTUAK4
41444Terminierte Überweisung ändern ParameterHITUASI4
41545Terminierte Überweisung einreichenHKTUEK4
11645Terminierte Überweisung einreichen ParameterHITUESI4
41745Terminierte Überweisung löschenHKTULK3
41845Terminierte Überweisung löschen ParameterHITULSI3
11945TerminvereinbarungHKTMVK3
42045Terminvereinbarung ParameterHITMVSI3
42145Übersicht institutsverwalteter Aufträge anfordernHKUTAI1,2
+ + + + + + + + + + + + + + + + +
Kapitel: EVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
12		Stand: 07.08.2015Kapitel: Anlagen
Abschnitt: Übersicht der Segmente
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.SegmentnameKennungSen- der1Ver- sion
42245Übersicht institutsverwalteter Aufträge ParameterHIUTASI1,2
42345Übersicht institutsverwalteter Aufträge rückmeldenHIUTAI1,2
42445Übersicht KontoauszügeHKKAUK1,2
42546Übersicht KontoauszügeHIKAUI1,2
42646Übersicht Kontoauszüge ParameterHIKAUSI1,2
42746UmbuchungHKUMBK2
42846Umbuchung ParameterHIUMBSI2
42946Vorbereitete SEPA-Überweisung ändernHKCVAK1
43046Vorbereitete SEPA-Überweisung ändern ParameterHICVASI1
43146Vorbereitete SEPA-Überweisung anlegenHKCVEK1
43246Vorbereitete SEPA-Überweisung anlegen ParameterHICVESI1
43346Vorbereitete SEPA-Überweisung löschenHKCVLK1
43446Vorbereitete SEPA-Überweisung löschen ParameterHICVLSI1
43547Vorbereitete Überweisung ändernHKVUAK1
43647Vorbereitete Überweisung ändern ParameterHIVUASI1
43747Vorbereitete Überweisung anlegenHKVUEK1
43847Vorbereitete Überweisung anlegen ParameterHIVUESI1
43947Vorbereitete Überweisung löschenHKVULK1
44047Vorbereitete Überweisung löschen ParameterHIVULSI1
44147VordruckbestellungHKVDBK3
44247Vordruckbestellung ParameterHIVDBSI3
44347Vormerkposten anfordernHKVMKK1
44447Vormerkposten anfordernHIVMKI1
44548Vormerkposten anfordern ParameterHIVMKSI1
44648Wertpapierinformationen anfordernHKWPIK3
44748Wertpapierinformationen ParameterHIWPISI3
44848Wertpapierinformationen rückmeldenHIWPII3
44948Wertpapierkurse anfordernHKWPKK3
15048Wertpapierkurse ParameterHIWPKSI3
15148Wertpapierkurse rückmeldenHIWPKI3
45248Wertpapierorder einreichenHKWPOK3, 4
45348Wertpapierorder ParameterHIWPOSI3, 4
45448WertpapierorderänderungHKWOAK3, 4
45549Wertpapierorderänderung bestätigenHIWOAI3, 4
45649Wertpapierorderänderung ParameterHIWOASI3, 4
15749Wertpapierordereinreichung bestätigenHIWPOI
I		3, 4
45849Wertpapierorderhistorie anfordernHKWOHK3
15949Wertpapierorderhistorie ParameterHIWOHSI3
46049Wertpapierorderhistorie rückmeldenHIWOHI3
46149WertpapierorderstreichungHKWPSK3
46249Wertpapierorderstreichung bestätigenHIWPSI3
46349Wertpapierorderstreichung ParameterHIWPSSI3
46449Wertpapierreferenznummern anfordernHKWPRK3
46550Wertpapierreferenznummern ParameterHIWPRSI3
46650Wertpapierreferenznummern rückmeldenHIWPRI3
46750Wertpapierstammdaten anfordernHKWSDK3,4
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: E
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:AnlagenStand:Seite:
Abschnitt:Übersicht der Segmente07.08.201513
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.SegmentnameKennungSen- der1Ver- sion
46850Wertpapierstammdaten ParameterHIWSDSI3,4
46950Wertpapierstammdaten rückmeldenHIWSDI3,4
47050Wichtige Informationen anfordernHKWPHK3
47150Wichtige Informationen ParameterHIWPHSI3
47250Wichtige Informationen rückmeldenHIWPHI3
47350Willenserklärung des KundenHKWEKK1
47450Willenserklärung des Kunden ParameterHIWEKSI1
+ + + + + + + + + + + + + + + + +
Kapitel: EVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
14		Stand: 07.08.2015Kapitel: Anlagen
Abschnitt: Geschäftsvorfallunterstützung
+ + +## E.2 Geschäftsvorfallunterstützung + +Die Geschäftsvorfälle für den Zahlungsverkehr Inland befinden sich in einem eige- +nen Band[Messages-IZV] und sind in der Aufstellung kursiv gekennzeichnet. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Ken- nungNameHBCI 2.0.1HBCI 2.1HBCI 2.2HBCI 3.0gültig
ADRAdressänderung---11
AOMAuslandsüberweisung ohne Melde- teil--121,2
APEPostfach-Kontoauszug erstellen---11
APNAuswahl Postfach-Nachrichtentypen---11
AUBZahlungsauftrag im Außenwirt- schaftsverkehr2,3456, 7, 83, 4, 5, 6, 7, 8
AUEEingereichte Aufträge anfordern---11
AZKKartenanzeige--121,2
BBSTerminierte SEPA- Firmeneinzellastschrift, Bestand---1,21,2
BDDSEPA Firmensammellastschrift---11
BDSSEPA-Firmeneinzellastschrift---11
BMBTerminierte SEPA- Firmensammellastschrift, Bestand---11
BMETerminierte SEPA- Firmensammellastschrift einreichen---1,21,2
BMLTerminierte SEPA- Firmensammellastschrift löschen---11
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: E
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:AnlagenStand:Seite:
Abschnitt:Geschäftsvorfallunterstützung07.08.201515
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Ken- nungNameHBCI 2.0.1HBCI 2.1HBCI 2.2HBCI 3.0gültig
BSATerminierte SEPA- Firmeneinzellastschrift ändern---11
BSETerminierte SEPA- Firmeneinzellastschrift einreichen---1,21,2
BSLTerminierte SEPA- Firmeneinzellastschrift löschen---11
CANKontoumsätze/neue Umsätze (camt)---11
CAZKontoumsätze/Zeitraum (camt)---11
CIMImportierte SEPA Sammelüberweisung---11
CISImportierte SEPA Einzelüberweisung---11
CCMSEPA Sammelüberweisung---11
CCSSEPA Einzelüberweisung---11
CDASEPA- Dauerauftragsänderungsvormerkung en---11
CDBSEPA-Dauerauftragsbestand abrufen---11
CDESEPA-Dauerauftragseinrichtung---11
CDLSEPA-Dauerauftragslöschung---11
CDD CDMSEPA Sammellastschrift---11
CDNSEPA-Dauerauftragsänderung---11
CDSSEPA Einzellastschrift---11
CDUSEPA-Dauerauftragsaussetzung---11
CMBTerminierte SEPA- Sammelüberweisung, Bestand---11
CMETerminierte SEPA- Sammelüberweisung einreichen---11
CMLTerminierte SEPA- Sammelüberweisung löschen---11
CMUSammeleilzahlung (Urgent Payment)---11
CSATerminierte SEPA-Überweisung ändern---11
CSBTerminierte SEPA-Überweisung, Bestand---1,21,2
CSETerminierte SEPA-Überweisung einreichen---11
CSLTerminierte SEPA-Überweisung löschen---11
CSUEilzahlung (Urgent Payment)---11
CTAAuslösen von C-Transaktionen---11
CTDAuftragsdetails für C-Transaktionen---11
CUBBestand der möglichen Empfänger- konten anfordern---11
CUMSEPA-Überweisung auf ein Empfängerkonto---11
CVAVorbereitete SEPA-Überweisung ändern---11
CVBVorbereitete SEPA-Überweisung, Bestand---11
+ + + + + + + + + + + + + + + + +
Kapitel: EVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 16Stand: 07.08.2015Kapitel: Anlagen
Abschnitt: Geschäftsvorfallunterstützung
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Ken- nungNameHBCI 2.0.1HBCI 2.1HBCI 2.2HBCI 3.0gültig
CVEVorbereitete SEPA-Überweisung anlegen---11
CVLVorbereitete SEPA-Überweisung löschen---11
DAADauerauftragsänderungsvormerkun- gen abrufen12341, 2, 3, 4
DABDauerauftragsbestand abrufen1234, 51, 2, 3, 4, 5
DAEDauerauftragseinrichtung23452, 3, 4, 5
DALDauerauftragslöschung12341, 2, 3, 4
DANDauerauftragsänderung23452, 3, 4, 5
DASDauerauftragsaussetzung12341, 2, 3, 4
DBSTerminierte SEPA-Einzellastschrift, Bestand---1,21,2
DDASEPA-Dauereinzellastschriftbestand anfordern---11
DDBSEPA-Dauereinzellastschrift einrich- ten---11
DDESEPA-Dauereinzellastschrift löschen---11
DDLSEPA-Dauereinzellastschrift ändern---11
DDNSEPA-Dauereinzellastschrift ausset- zen---11
DEADauereinzellastschriftänderung---11
DEBDauereinzellastschriftbestand abru- fen---11
DEEDauereinzellastschrifteinrichtung---11
DELDauereinzellastschriftlöschung---11
DEUDauereinzellastschriftaussetzung---11
DEVDauereinzellastschriftänderungsvor- merkungen abrufen---11
DMBTerminierte SEPA-Sammellastschrift, Bestand---11
DMCTerminierte SEPA-COR1- Sammellastschrift einreichen---11
DMETerminierte SEPA-Sammellastschrift einreichen---1,21,2
DMLTerminierte SEPA-Sammellastschrift löschen---11
DSATerminierte SEPA-Einzellastschrift, ändern---11
DSBBestand rückgabefähiger SEPA- Lastschriften---11
DSCTerminierte SEPA-COR1- Einzellastschrift einreichen---11
DSETerminierte SEPA-Einzellastschrift einreichen---1,21,2
DSLTerminierte SEPA-Einzellastschrift löschen---11
DSWSEPA-Lastschriftwiderspruch---11
DTEEilüberweisung (Sammel)---11
DVKDevisenkurse--121,2
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: E
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:AnlagenStand:Seite:
Abschnitt:Geschäftsvorfallunterstützung07.08.201517
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Ken- nungNameHBCI 2.0.1HBCI 2.1HBCI 2.2HBCI 3.0gültig
EILEilüberweisung (Einzel)---11
ECAElektronischer Kontoauszug (camt)---11
EKAKontoauszug---1, 2, 3, 41, 2, 3, 4
EKBElektronischen Kontoauszug bean- tragen---11
EKPElektronischer Kontoauszug PDF---11,2
ESUEU-Standardüberweisung---11
EUEEuro-Eilüberweisung---11
FDAFinanzdatenformat anfordern/ Dokument anfordern--12, 31, 2, 3
FDBBearbeitungsstatus Finanzdaten- format anfordern/ Bearbeitungsstatus Dokument an- fordern--12,31, 2, 3
FDLListe der bereitgestellten Finanzda- tenformate anfordern/ Liste der bereitgestellten Dokumnete anfordern--12,31, 2, 3
FDSFinanzdatenformat senden/ Dokument senden--12,31, 2, 3
FGAFestgeldänderung22342, 3, 4
FGBFestgeldbestandsabfrage22342, 3, 4
FGKFestgeldkonditionen11231, 2, 3
FGNFestgeldneuanlage22342, 3, 4
FGPFestgeldprolongation22342, 3, 4
FGWWiderruf einer Festgeldneuanlage22342, 3, 4
FPOFestpreisorder--121,2
FPWWiderruf einer Festgeldprolongation22342, 3, 4
FRAFreistellungsauftrag anlegen---11
FRDAbfrage Freistellungsdaten--12,31, 2, 3
FRLFreistellungsdaten löschen---11
FRNFreistellungsdaten ändern---11
GAMGastmeldung12341, 2, 3, 4
GUBGarantierte Überweisung---11
INFInformationsbestellung12341, 2, 3, 4
KAAPostfach-Nachricht abrufen---11
KANKontoumsätze/neue Umsätze3, 44564, 5, 6, 7, 8
KASKartensperre--121,2
KAUÜbersicht Kontoauszüge---1,21,2
KAZKontoumsätze /Zeitraum3, 44564, 5, 6, 7, 8
KDDAnzeige Kundendaten---11
KDMKundenmeldung23452, 3, 4, 5
KIAKreditinstitutsangebote abholen12341, 2, 3, 4
KIFKontoinformationen--12, 3,
4, 5,
6, 7		1, 2, 3, 4, 5, 6, 7
KOMAbruf von Kommunikationszugangs-23342, 3, 4
+ + + + + + + + + + + + + + + + +
Kapitel: EVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
18		Stand: 07.08.2015Kapitel: Anlagen
Abschnitt: Geschäftsvorfallunterstützung
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Ken- nungNameHBCI 2.0.1HBCI 2.1HBCI 2.2HBCI 3.0gültig
daten
LASEinzellastschrift23452, 3, 4, 5
LGALaden GeldKarte abmelden--121,2
LGBLaden GeldKarte bestätigen--121,2
LGELaden GeldKarte einleiten--121,2
LGDLaden GeldKarte durchführen--121,2
LGOLaden GeldKarte Storno vorbereiten--121,2
LGRLaden GeldKarte registrieren--121,2
LGSLaden GeldKarte Status--121,2
LGTLaden GeldKarte Storno durchführen--121,2
LGVLaden GeldKarte vorbereiten--121,2
LGXLaden GeldKarte Storno bestätigen--121,2
LSWLastschriftwiderspruch---1,21, 2
LWBBestand rückgabefähiger Lastschrif- ten---1,21,2
ΝΕΑNeuemissionen anzeigen--121,2
NEZNeuemission zeichnen--121,2
OANOrderanzeige--12, 3, 41, 2, 3, 4
PNAPostfach Nachrichtentypen anfordern---11
PNLPostfach-Nachricht löschen---11
POFPostfach-Nachrichtenliste anfordern---11
PPBBestand Daueraufträge Prepaidkarte laden anfordern---11
PPDPrepaidkarte laden---1,21,2
PPEDauerauftrag Prepaidkarte laden ein- richten---11
PPLLöschen Dauerauftrag Prepaidkarte laden---11
PROStatusprotokoll23342, 3, 4
QTGEmpfangsquittung---11
SALSaldenabfrage3456, 73, 4, 5, 6, 7
SCCSEPA Card Clearing Nachricht ein- reichen11
SLASammellastschrift2, 34563, 4, 5, 6
SLBBestand terminierter Sammellast- schriften anfordern-1231, 2, 3
SLETerminierte Sammellastschrift einrei- chen-1231, 2, 3
SLLTerminierte Sammellastschrift lö- schen-1231, 2, 3
SPASEPA-Kontoverbindung anfordern---1, 2, 31, 2, 3
SRBSorten- und Reisescheckbestellung--121,2
SRKSorten- und Reisescheckkonditionen anfordern--121,2
SSRSEPA-Statusreport---11
STPEuro-STP-Zahlung---1, 2, 31, 2, 3
SUBSammelüberweisung2, 34563, 4, 5, 6
SZTServerzeit---11
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: E
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:AnlagenStand:Seite:
Abschnitt:Geschäftsvorfallunterstützung07.08.201519
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Ken- nungNameHBCI 2.0.1HBCI 2.1HBCI 2.2HBCI 3.0gültig
TEAÄnderung terminierter Einzellast- schriften---11
TEBBestand terminierter Einzellastschrif- ten abrufen---11
TEETerminierte Einzellastschrift einrei- chen---11
TELLöschung terminierter Einzellast- schriften---11
TMVTerminvereinbarung11231, 2, 3
TSBBestand terminierter Sammelüber- weisungen abrufen-1231, 2, 3
TSEEinreichung terminierter Sammel- überweisungen-1231, 2, 3
TSLLöschung terminierter Sammelüber- weisungen-1231, 2, 3
TUAÄnderung terminierter Überweisun- gen22342, 3, 4
TUBBestand terminierter Überweisungen abrufen11231, 2, 3
TUEEinreichung terminierter Überweisun- gen22342, 3, 4
TULLöschung terminierter Überweisun- gen11231, 2, 3
UEBEinzelüberweisung23452, 3, 4, 5
UMBUmbuchung--121,2
UTAÜbersicht institutsverwalteter Aufträ- ge anfordern---11,2
VDBVordruckbestellung11231, 2, 3
VMKVormerkposten anfordern---11
VUAVorbereitete Überweisung ändern---11
VUBBestand vorbereiteter Überweisun- gen anzeigen---11
VUEVorbereitete Überweisung anlegen---11
VULVorbereitete Überweisung löschen---11
WDUDepotumsätze-1, 23, 451, 2, 3, 4, 5
WEKWillenserklärung des Kunden---11
WFOFondsorder--121,2
WFPFestpreisangebote-1231, 2, 3
WOAOrderänderung-123, 41, 2, 3, 4
WOHOrderhistorie-1231, 2, 3
WPDDepotaufstellung22,34, 562, 3, 4, 5, 6
WPHWichtige Informationen anfordern-1231, 2, 3
WPIWertpapierinformationen-1231, 2, 3
WPKWertpapierkurse-1231, 2, 3
WPOWertpapierorder-123, 41, 2, 3, 4
WPRAbfrage von Wertpapierreferenz- nummern-1231, 2, 3
WPSOrderstreichung-1231, 2, 3
WSDWertpapierstammdaten-1231, 2, 3, 4
+ + + + + + + + + + + + + + + + +
Kapitel: EVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
20		Stand: 07.08.2015Kapitel: Anlagen
Abschnitt: Geschäftsvorfallunterstützung
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Ken- nungNameHBCI 2.0.1HBCI 2.1HBCI 2.2HBCI 3.0gültig
WSOOrderstatus-123, 41, 2, 3, 4, 5
ZSTServerzeit---11
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel:
E
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Anlagen
Berechnung der Prüfziffer für interne Zuordnungsdaten		Stand: 07.08.2015Seite: 21
+ + +## E.3 Berechnung der Prüfziffer für interne Zuordnungsdaten (Kunden-Referenznummer)2 + +(nach DIN ISO 7064, MOD 11,10) + + +### E.3.1 Rechengang + +Die internen Zuordnungsdaten (Kunden-Referenznummer) bestehen aus 12 Ziffern +und einer einstelligen Prüfziffer, bilden also eine 13stellige Zeichenkette. Diese Ket- +te wird Zeichen für Zeichen von links nach rechts verarbeitet. + +Mit dem Index $j = 1 . . n$ (wobei $\mathrm { n }$ die Anzahl der Zeichen in der Kette einschließlich +Prüfziffer ist) und mit dem Anfangswert $P _ { 1 } = M$ für $j = 1$ berechnet man + +$$S _ { j } = P _ { j } | _ { \left( M + 1 \right) } + a _ { \left( n - j + 1 \right) }$$ +$$P _ { \left( j + 1 \right) } = S _ { j } I l _ { M } \times 2$$ + +Dabei ist + +IIM +der Rest nach Division durch $\mathrm { M }$ ; falls dieser gleich Null ist, ist statt dessen +Wert M einzusetzen. + +$$I _ { \left( M + 1 \right) }$$ +der Rest nach Division durch $\left( M + 1 \right)$ ; hier wird der Rest niemals gleich Null + +$$a _ { \left( n - j + 1 \right) }$$ +der Zeichenwert + +Bei der Prüfung gilt die Kette als richtig, wenn $S _ { n } = 1$ (mod M) ist. + +Zur Berechnung des Prüfzeichens wird $a _ { 1 }$ so gewählt, dass $P _ { n } | _ { \left( M + 1 \right) } + a _ { 1 } = 1 \left( m o d M \right)$ +ist. Mit dem für $a _ { 1 }$ gefundenen Wert werden die internen Zuordnungsdaten (Kunden- +Referenznummer) ergänzt. + + + + + + + + + + + + + + + + +
Kapitel: EVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
22		Stand:
07.08.2015		Kapitel: Anlagen
Abschnitt: Berechnung der Prüfziffer für interne Zuordnungsdaten
+ + +### E.3.2 Beispiel + +Die internen Zuordnungsdaten (Kunden-Referenznummer) lauten 100845456115. +Sie sind am rechten Ende zu ergänzen durch die Prüfziffer nach DIN ISO 7064, +MOD 11,10. + + +## . Rechnung + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Schritt
j		Über- tragenes Produkt
$$P _ { i } l _ { 1 1 }$$
+		nächster Zeichen- wert
$$a _ { \left( n - i + 1 \right) }$$		Zwischen- summe
$$= S _ { 1 }$$		Zwischen- +summe +$$\left( m o d 1 0 \right) \times 2$$
$$= P r o d u k t$$
$$S _ { i } | I \times 2 = P _ { \left( i + 1 \right) }$$		Produkt (mod 11) Übertrag
$$P _ { \left( 1 + 1 \right) } I _ { 1 1 }$$
1234
110
+		1= 11$$1 \times 2 = 2$$2
22
+		0= 2$$2 \times 2 = 4$$4
34
+		0= 4$$4 \times 2 = 8$$8
48
+		8= 16$$6 \times 2 = 1 2$$1
51
+		4= 5$$5 \times 2 = 1 0$$10
610
+		5= 15$$5 \times 2 = 1 0$$10
710
+		4= 14$$4 \times 2 = 8$$8
88
+		5= 13$$3 \times 2 = 6$$6
96
+		6= 12$$2 \times 2 = 4$$4
104
+		1= 5$$5 \times 2 = 1 0$$10
1110
+		1= 11$$1 \times 2 = 2$$2
122
+		5= 7$$7 \times 2 = 1 4$$3
133
+		8= 1
(mod 10)
+ + +Die gesuchte Prüfziffer ist 8. + + +## ◆ Erläuterungen + +Der Ausgangswert, auf den im 1. Schritt der 1. Zeichenwert addiert wird, ist immer +10. + + + + + + + + + + + + + + + +
Zwischensumme (mod 10):Das Ergebnis der Rechenoperation in Sp. 2 wird durch 10 dividiert; der Divisionsrest (Einerstelle des Ergeb- nisses) ergibt die Zwischensumme Sill10-
Ist dieser Wert = 0, ist statt dessen der Wert 10 zu set- zen.
Produkt (mod 11):Das Produkt in Sp. 3 wird durch 11 dividiert; der Divisi- onsrest ergibt den nächsten Berechnungsschritt.
Prüfziffer:Im letzten Berechnungsschritt ist der Übertrag auf den Wert 11 (= 1 (mod 10)) zu ergänzen. Der gefundene Zeichenwert ist die Prüfziffer. Ist der Übertrag aus Schritt 12 jedoch = 1, so ist die Prüfziffer = 0.
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: E
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:AnlagenStand:Seite:
Abschnitt:Länderkennzeichen und Währungscodes07.08.201523
+ + +## E.4 Länderkennzeichen und Währungscodes + +Nachfolgend sind für ausgewählte Länder jeweils der Ländercode laut ISO 3166-1 +sowie der Währungscode und die Anzahl der Währungsnachkommastellen laut ISO +4217 aufgelistet: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
LändernameLändercode (numerisch)Ländercode (Alpha-2)Währungs- codeNachkomma- stellen
Belgien056BEBEF0
Bulgarien100BGBGL2
Dänemark208DKDKK2
Deutschland2803DEDEM*2
Finnland246FIFIM*2
Frankreich250FRFRF*2
Griechenland300GRGRD*0
Großbritannien826GBGBP2
Irland372IEIEP*2
Island352ISISK2
Italien380ITITL*0
Japan392JPJPY0
Kanada124CACAD2
Kroatien191HRHRK2
Liechtenstein438LICHF2
Luxemburg442LULUF*0
Niederlande528NLNLG*2
Norwegen578NONOK2
Österreich040ATATS*2
Polen616PLPLN2
Portugal620PTPTE*0
Rumänien642ROROL2
Russische Föderation643RURUR2
Schweden752SESEK2
Schweiz756CHCHF2
Slowakei703SKSKK2
Slowenien705SISIT2
Spanien724ESESP*0
Tschechien203CZCZK2
Türkei792TRTRY2
Ungarn348HUHUF2
USA840USUSD2
Euro978EUEUR2
+ +\* +Die ab 01.01.2002 nicht mehr existierenden Währungscodes sind hier weiterhin aufgeführt, da sie +im Rahmen von z.B. auf diese Währungen lautenden Wertpapieranleihen noch übergangsweise +weiterhin gültig sind. + +3 +Der neue Code 276 wird derzeit noch nicht verwendet, da der Code 280 im Kreditgewerbe ge- +bräuchlicher ist. + + + + + + + + + + + + + + + + +
Kapitel:
E		Version: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
24		Stand: 07.08.2015Kapitel: Anlagen
Abschnitt: Europäische Kontenadressierung
+ + +## E.5 Europäische Kontenadressierung + +Die DEG ,,Kontoverbindung" (s. Kap. B.3) ist für wichtige europäische Zielländer wie +folgt zu belegen:4 + +Belgien: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Länderkennzeichen:056
Kreditinstitutscode:Das Feld wird nicht belegt (Der Bank-Code ist fester Bestandteil der Kontonummer).
Konto-/Depotnummer:Es ist die gesamte Ziffernfolge (genau 12-stellig) einzutragen.
![](figures/214.1)
3 n5
7 n
2 n
Bank-Code
No. Compte oder Rekeningnr.Check Digit
Dänemark:
Länderkennzeichen:208
Kreditinstitutscode:Das Feld wird mit dem S.W.I.F.T.-Code belegt.
8 bzw. 11 an
S.W.I.F.T.-Code
Konto-/Depotnummer:Der Bank-Code ist fester Bestandteil der Kontonum- mer. Es ist die gesamte Ziffernfolge (max. 14-stellig) einzutragen.
![](figures/214.2)
4 n
max. 9 n
1
Bank-Code
Konto
Check digit
Deutschland:
Länderkennzeichen:280
Kreditinstitutscode:Das Feld wird mit der Bankleitzahl belegt.
![](figures/214.3)
8 n
Bankleitzahl
Konto-/Depotnummer:Der Bank-Code ist kein fester Bestandteil der Kon- tonummer. Es ist die Kontonummer einzutragen.
10 n
![](figures/214.4)
Kontonummer
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: E
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:AnlagenStand:Seite:
Abschnitt:Europäische Kontenadressierung07.08.201525
+ + +## Finnland: + +Länderkennzeichen: + +246 + +Kreditinstitutscode: + +Das Feld wird nicht belegt (Der Bank-Code ist fester +Bestandteil der Kontonummer). + +Konto-/Depotnummer: + +Es ist die gesamte Ziffernfolge (max. 14-stellig) ein- +zutragen. + + +![6 n max. 7 n 1 Bank-Code Kontonummer Check Digit](figures/215.1) + + +## Frankreich: + + + + + + + + + + + + + + + +
Länderkennzeichen:250
Kreditinstitutscode:Das Feld wird nicht belegt.
Konto-/Depotnummer:Der RIB-Code ist eine Kombination aus Bank-Code und Kontonummer. Es ist die gesamte Ziffernfolge (genau 23 Stellen) einzutragen.
+ + +![5 n 5 n 11 an 2 n Code banque Code guichet No. de Compte Cié RIB](figures/215.2) + + +## Griechenland: + +Länderkennzeichen: + +300 + +Kreditinstitutscode: + +Das Feld wird mit dem S.W.I.F.T.-Code belegt. + + +![8 bzw. 11 an S.W.I.F.T.-Code](figures/215.3) + + +Konto-/Depotnummer: + +Der Bank-Code ist fester Bestandteil der Kontonum- +mer. Es ist die gesamte Ziffernfolge (genau 19 Zei- +chen) einzutragen. + +3 n +3n +12 n +1 n +Bank code +Branch code Account Number +Check digit +Großbritannien: +Länderkennzeichen: +826 +Kreditinstitutscode: +Das Feld wird mit dem Sort-Code belegt. +6 n +Sort-Code +Konto-/Depotnummer: +Es ist die Kontonummer einzutragen. +8 n +Account Number +Irland: +Länderkennzeichen: +372 +Kreditinstitutscode: +Das Feld wird mit dem Sort-Code belegt. + + +![](figures/215.4) + + +![](figures/215.5) + + +![](figures/215.6) + + + + + + + + + + + + + + + + +
Kapitel:
E		Version: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
26		Stand: 07.08.2015Kapitel: Anlagen
Abschnitt: Europäische Kontenadressierung
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Konto-/Depotnummer:Es ist die Kontonummer einzutragen.
Account Number 8 n
Island:
Länderkennzeichen:352
Kreditinstitutscode:Das Feld wird mit dem Bank-Code belegt. Alternativ kann auch der S.W.I.F.T.-Code angegeben werden.
4 n
Bankanúmer
Konto-/Depotnummer:Es ist die Kontonummer einzutragen. 18 n
Italien:Reikningsnúmer
Länderkennzeichen:380
Kreditinstitutscode:Das Feld wird mit dem S.W.I.F.T.-Code belegt.
8- bzw. 11 an
S.W.I.F.T.-Code
Konto-/Depotnummer:Der Coordinata Bancaria ist eine Kombination aus Bank-Code und Kontonummer. Es ist die gesamte Ziffernfolge (genau 23 Stellen) einzutragen.
1a5n
5 n		max. 12 x
![](figures/216.1)
CIN ABI Code
CAB Code
Numero di Conto
+ + +## Liechtenstein: + +Länderkennzeichen: + +438 + +Kreditinstitutscode: +Das Feld wird mit dem Bank-Code („SIC-Code) be- +legt. Alternativ kann auch der S.W.I.F.T.-Code an- +gegeben werden. + +max. 5 an + +SIC-Code + +Konto-/Depotnummer: + +Es ist die Kontonummer einzutragen. + +max. 16 an + +Kontonummer + +Sort-Code +6 n + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel:
E
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:AnlagenStand:Seite:
Abschnitt:Europäische Kontenadressierung07.08.201527
+ + +Luxemburg: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Länderkennzeichen:
Kreditinstitutscode:		442
Das Feld wird mit dem S.W.I.F.T.-Code belegt.
8- bzw. 11 an
![](figures/217.1)
S.W.I.F.T.-Code
Konto-/Depotnummer:Der Bank-Code ist ein fester Bestandteil der Konto- nummer (max. 14-stellig).
![](figures/217.2)
2 n 6 n
2 n
4 an
Bank- Numeró de Compte Code
Check Digit
bankinterne Kennziffer
Niederlande:
Länderkennzeichen:
Kreditinstitutscode:		528
Das Feld wird mit dem S.W.I.F.T.-Code belegt.
8- bzw. 11 an
![](figures/217.3)
S.W.I.F.T.-Code
Konto-/Depotnummer:Der Bank-Code ist ein fester Bestandteil der Konto- nummer (insgesamt max. 9-stellig, davon Bank- Code 2- bis 3-stellig und Kontonummer max. 7- stellig).
![](figures/217.4)
10 n
Rekeningnummer
Norwegen:
Länderkennzeichen:578
Kreditinstitutscode:Das Feld wird nicht belegt (Der Bank-Code ist ein fester Bestandteil der Kontonummer).
Konto-/Depotnummer:Es ist die Kontonummer (max. 11-stellig) einzutra- gen.
![](figures/217.5)
4 n
7 n
1 n
Registernummer Konto
Check digit
Österreich:
Länderkennzeichen:
Kreditinstitutscode:		040
Das Feld wird mit der Bank-Code belegt. Alternativ kann auch der S.W.I.F.T.-Code angegeben werden.
![](figures/217.6)
5 n
Bankleitzahl
Konto-/Depotnummer:Es ist die Kontonummer einzutragen.
11 n
Kontonummer
+ + + + + + + + + + + + + + + + +
Kapitel:
E		Version: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
28		Stand: 07.08.2015Kapitel: Anlagen
Abschnitt: Europäische Kontenadressierung
+ + +# Portugal: + +Länderkennzeichen: + +620 + +Kreditinstitutscode: + +Das Feld wird nicht belegt (Der Bank-Code ist ein +fester Bestandteil der Kontonummer). + +Konto-/Depotnummer: + +Es ist die gesamte Ziffernfolge (insgesamt max. 21 +Stellen) einzutragen. + + +![4 n 4 n 11 n 2 n National Bank Code Bank Branch Code Kontonummer Check Digit](figures/218.1) + + +## Schweden: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Länderkennzeichen:752
Kreditinstitutscode:Das Feld wird nicht belegt (Der Bank-Code ist ein fester Bestandteil der Kontonummer).
Konto-/Depotnummer:Es ist die Kontonummer (insgesamt max. 15-stellig, meist 11-stellig) anzugeben.
4 n6 n
1 n
Bank-Code![](figures/218.2)
Kontonummer
Check Digit
Schweiz:
Länderkennzeichen:756
Kreditinstitutscode:Der Bank-Code ist kein fester Bestandteil der Kon- tonummer. Alternativ kann auch der S.W.I.F.T.- Code angegeben werden.
max. 5 n
Clearingnummer
Konto-/Depotnummer:Es ist die Kontonummer einzutragen. max. 16 an
Kontonummer
Spanien:
Länderkennzeichen:724
Kreditinstitutscode:Das Feld wird nicht belegt (Der Bank-Code ist ein fester Bestandteil der Kontonummer).
Konto-/Depotnummer:Es ist die gesamte Ziffernfolge (genau 20-stellig) einzutragen.
4 n
4 n		![Código de entidad Código de oficina Dígitos Número de cuenta de control](figures/218.3)
2 n
10 n
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: E
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:AnlagenStand:Seite:
Abschnitt:Liste der für SEPA integrierten Geschäftsvorfälle07.08.201529
+ + +# E.6 Liste der für SEPA integrierten Geschäftsvorfälle + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FinTS-SegmentTitel / BemerkungFormat
Ist- Zustandneu
HKKAZHKKAZKontoumsätze anfordern, ZeitraumFinTS-Fremdformat, MT940, MT942
HKKANHKKANKontoumsätze anfordern, neue UmsätzeFinTS-Fremdformat, MT940, MT942
HKEKAHKEKAKontoauszugFinTS-Fremdformat, MT940, PDF
HKKAUHKKAUÜbersicht KontoauszügeFinTS-Eigenformat
HKUEBHKCCSSEPA EinzelüberweisungFinTS-SEPA- Standardformat
HKLASHKCDSSEPA-EinzellastschriftFinTS SEPA Standardformat
HKBDSSEPA FirmeneinzellastschriftFinTS SEPA Standardformat
HKSUBHKCCMSEPA SammelüberweisungFinTS-SEPA- Standardformat
HKSLAHKCDDSEPA SammellastschriftFinTS SEPA Standardformat
HKBDDSEPA FirmensammellastschriftFinTS SEPA Standardformat
HKTUEHKCSETerminierte SEPA-Überweisung einreichenFinTS-SEPA- Standardformat
HKTUBHKCSBTerminierte SEPA-Überweisung, BestandFinTS-SEPA- Standardformat
HKTUAHKCSATerminierte SEPA-Überweisung ändernFinTS-SEPA- Standardformat
HKTULHKCSLTerminierte SEPA-Überweisung löschenFinTS-SEPA- Standardformat
HKDSETerminierte SEPA-Einzellastschrift einreichenFinTS-SEPA- Standardformat
HKDBSTerminierte SEPA-Einzellastschrift, BestandFinTS-SEPA- Standardformat
HKDSATerminierte SEPA-Einzellastschrift ändernFinTS-SEPA- Standardformat
HKDSLTerminierte SEPA-Einzellastschrift löschenFinTS-SEPA- Standardformat
+ + + + + + + + + + + + + + + + +
Kapitel: EVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite: 30Stand: 07.08.2015Kapitel: Abschnitt:
Anlagen Liste der für SEPA integrierten Geschäftsvorfälle
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FinTS-SegmentTitel / BemerkungFormat
Ist- Zustandneu
HKBSETerminierte SEPA- Firmeneinzellastschrift einreichenFinTS-SEPA- Standardformat
HKBBSTerminierte SEPA- Firmeneinzellastschrift, BestandFinTS-SEPA- Standardformat
HKBSATerminierte SEPA- Firmeneinzellastschrift ändernFinTS-SEPA- Standardformat
HKBSLTerminierte SEPA- Firmeneinzellastschrift löschenFinTS-SEPA- Standardformat
HKTSEHKCMETerminierte SEPA-Sammelüberweisung einreichenFinTS-SEPA- Standardformat
HKTSBHKCMBTerminierte SEPA- Sammelüberweisung, BestandFinTS-Eigenformat
HKTSLHKCMLTerminierte SEPA-Sammelüberweisung löschenFinTS-Eigenformat
HKSLEHKDMETerminierte SEPA-Sammellastschrift einreichenFinTS-SEPA- Standardformat
HKSLBHKDMBTerminierte SEPA-Sammellastschrift, BestandFinTS-Eigenformat
HKSLLHKDMLTerminierte SEPA-Sammellastschrift löschenFinTS-Eigenformat
HKBMETerminierte SEPA- Firmensammellastschrift einreichenFinTS-SEPA- Standardformat
HKBMBTerminierte SEPA- Firmensammellastschrift, BestandFinTS-Eigenformat
HKBMLTerminierte SEPA- Firmensammellastschrift löschenFinTS-Eigenformat
HKLWBHKDSBBestand rückgabefähiger LastschriftenFinTS-Eigenformat
HKLSWHKDSWLastschriftwiderspruchFinTS-Eigenformat
HKVUEHKCVEVorbereitete SEPA-Überweisung anlegenFinTS-SEPA- Standardformat
HKVUAHKCVAVorbereitete SEPA-Überweisung ändernFinTS-SEPA- Standardformat
HKVUBHKCVBVorbereitete SEPA-Überweisung, BestandFinTS-SEPA- Standardformat
HKVULHKCVLVorbereitete SEPA-Überweisung löschenFinTS-SEPA- Standardformat
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: E
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:AnlagenStand:Seite:
Abschnitt:Liste der für SEPA integrierten Geschäftsvorfälle07.08.201531
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FinTS-SegmentTitel / BemerkungFormat
Ist- Zustandneu
HKDAEHKCDESEPA-DauerauftragseinrichtungFinTS-SEPA- Erweiterungsformat
HKDANHKCDNSEPA-DauerauftragsänderungFinTS-SEPA- Erweiterungsformat
HKDASHKCDUSEPA-DauerauftragsaussetzungFinTS-SEPA- Erweiterungsformat
HKDABHKCDBSEPA-Dauerauftragsbestand abrufenFinTS-SEPA- Erweiterungsformat
HKDAAHKCDASEPA- DauerauftragsänderungsvormerkungenFinTS-SEPA- Erweiterungsformat
HKDALHKCDLSEPA-DauerauftragslöschungFinTS-SEPA- Erweiterungsformat
HKKIFHKKIFKontoinformationenFinTS-Eigenformat
HKSALHKSALSaldenabfrageFinTS-Eigenformat
HKCIMImportierte SEPA-SammelüberweisungFinTS SEPA Standardformat
HKCISImportierte SEPA-EinzelüberweisungFinTS SEPA Standardformat
HKDTEHKCMUSEPA-SammeleilüberweisungFinTS-SEPA- Standardformat
HKEIL, HKEUEHKCSUSEPA-EilüberweisungFinTS-SEPA- Standardformat
HKCUBBestand Empfängerkonten anfordernFinTS-Eigenformat
HKCUMSEPA-Überweisung auf ein Empfänger- kontoFinTS-SEPA- Erweiterungsformat
HKDEVHKDDASEPA- Dauereinzellastschriftänderungsvor- merkungen anfordernFinTS-SEPA- Erweiterungsformat
HKDEBHKDDBSEPA-Dauereinzellastschriftbestand anfordernFinTS-SEPA- Erweiterungsformat
HKDEEHKDDESEPA-Dauereinzellastschrift einrichtenFinTS-SEPA- Erweiterungsformat
HKDELHKDDLSEPA-Dauereinzellastschrift löschenFinTS-SEPA- Erweiterungsformat
HKDEAHKDDNSEPA-Dauereinzellastschrift ändernFinTS-SEPA- Erweiterungsformat
+ + + + + + + + + + + + + + + + +
Kapitel: EVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
32		Stand: 07.08.2015Kapitel: Abschnitt:
Anlagen Liste der für SEPA integrierten Geschäftsvorfälle
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FinTS-SegmentTitel / BemerkungFormat
Ist- Zustandneu
HKDEUHKDDUSEPA-Dauereinzellastschrift aussetzenFinTS-SEPA- Erweiterungsformat
HKDMCSEPA-COR1-SammellastschriftFinTS-SEPA- Standardformat
HKDSCSEPA-COR1-EinzellastschriftFinTS-SEPA- Standardformat
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: E
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Anlagen Beispiele für die eindeutige Belegung von camt.052-Stand: 07.08.2015Seite: 33
+ + +# E.7 Beispiele für die eindeutige Belegung von camt.052-messages im HKCAZ + + + + + + + + + + + + + + + +
Kapitel: EVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
34		Stand: 07.08.2015Kapitel: Anlagen
Abschnitt: Beispiele für die eindeutige Belegung von camt.052-messages
+ + +## E.7.1 HKCAZ ohne Aufsetzpunkt ohne vorgemerkte Umsätze + +HKCAZ:3:1+DE06940594210000027227:TESTDETT421:::280:+urn?:iso?:std?:iso?:20022?:t +ech?:xsd?:camt.052.001.02+N+20131101+20131116' + +HIRMG:3:2+0010::Nachricht ist vollständig bearbeitet (HBMSG=10322)' + +HIRMS:4:2:3+0020::Der Auftrag wurde ausgeführt. +0020::Die gebuchten Umsätze wurden +übermittelt.+0020::Vormerkungen sind nicht vorhanden.' + +HICAZ:5:1:3+DE06940594210000027227:TESTDETT421:::280:+urn?:iso?:std?:iso?:20022? +:tech?:xsd?:camt.052.001.02 + +\+ + +@10426@ + + + +camt52 20131118101510 ONLINEBA2013- +11- +18T10:15:10+01:001true + +camt052 ONLINEBA00000201 +3-11- + +18T10:15:10+01:00DE06940594210000027227EURTESTDETT421SPK Test Abnah- +me12345678901234UmsStId + +PRCD44055838.96CRDT
2013-10- +31
 + +CLBD44049585.23CRDT
2013-11- +04
 + +[......]BOOK[......][......]BOOK[......][......]BOOK[......][......]BOOK[......][......] +BOOK[......][......]BOOK[......][......] +BOOK[......][......]BOOK[......][......]BOOK +[.....][......]BOOK[.....] + + + +: + +@4677@ + +camt52 _20131118101510 +ONLINEBA2013-11- + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: E
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:AnlagenStand:Seite:
Abschnitt:Beispiele für die eindeutige Belegung von camt.052-07.08.201535
+ + +18T10:15:10+01:001true + +camt052 ONLINEBA00000201 +3-11- + +18T10:15:10+01:00DE06940594210000027227EUR TESTDETT421SPK Test Ab- +nahme + +12345678901234UmsStId< +/Acct> + + +PRCD44049585.23CRDT
2013-11- +04
 + +CLBD44049601.67CRDT
2013-11- +05
 + +[......]BOOK[......][......]BOOK[......][......]BOOK[......][......]BOOK[......] + + + +: + +@2741@ + +camt52 20131118101510 + +ONLINEBA2013-11- + +18T10:15:10+01:001true + +camt052 ONLINEBA00000201 +3-11- + +18T10:15:10+01:00DE06940594210000027227EURTESTDETT421SPK Test Abnah- +me12345678901234UmsStId + +PRCD44049601.67CRDT
2013-11- +05
 + +CLBD44049618.33CRDT
2013-11- +06
 +[......]BOOK[......][......]BOOK[......] + + + +: + +@2031@ + +camt52 20131118101510 +ONLINEBA2013-11- + +18T10:15:10+01:001true + +camt052 ONLINEBA00000201 +3-11- +18T10:15:10+01:00DE06940594210000027227EURTESTDETT421SPK Test Abnah- +me12345678901234UmsStId + + +PRCD44049618.33CRDT
2013-11- +06
 + + +CLBD44049622.35CRDT
2013-11- +07
 + +[......]BOOK[......] + + + +: + +@2955@camt52 20131118101510 +ONLINEBA2013-11- + +18T10:15:10+01:001true + +camt052_ONLINEBA00000201 +3-11- + +18T10:15:10+01:00DE06940594210000027227EURTESTDETT421SPK Test Abnah- +me12345678901234UmsStId + + +PRCD44049622.35CRDT
2013-11- +07
 + + +CLBD44049624.34CRDT
2013-11- +13
 + +[......]BOOK[.....] + +[......]BOOK[.....] +' + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: E
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:
Abschnitt:		Anlagen Beispiele für die eindeutige Belegung von camt.052-Stand: 07.08.2015Seite: 37
+ + +## E.7.2 HKCAZ mit Aufsetzpunkt in einem Buchungstag ohne vorgemerkte Um- sätze + +HKCAZ:3:1+DE76940593100001009554:TESTDETT421:::280:+urn?:iso?:std?:iso?:20022?:t +ech?:xsd?:camt.052.001.02+N+20130822+20131120' + +HIRMG:3:2+3060::Teilweise liegen Warnungen oder Hinweise vor (HBMSG=10336)' + +HIRMS:4:2:3+0020::Der Auftrag wurde ausgeführt. +3040::Es liegen weitere Informationen + +vor.:0054-11-18-13.16.27.302113+0020::Die gebuchten Umsätze wurden übermit- + +telt.+0020::Vormerkungen sind nicht vorhanden.' + +HICAZ:5:1:3+DE06940594210000027227:TESTDETT310:::280:+urn?:iso?:std?:iso?:20022? +:tech?:xsd?:camt.052.001.02 + +\+ + +@10426@ + + + +camt52 20131120085516 ONLINEBA2013- +11- + +20T08:55:16+01:001true + +camt052_ONLINEBA00000201 +3-11- + +20T08:55:16+01:00DE76940593100001009554EURTESTDETT310Testumgebung322/1234/55TESTUmsStId + + +PRCD58.99DBIT
2013-08- +21
 + + +CLBD53.45DBIT
2013-09- +04
 + +[......]BOOK[......] + + + + + +: + +@4711@ + +camt52 20131120085516 ONLINEBA2013- +11- +20T08:55:16+01:001true + + + + + + + + + + + + + + + +
Kapitel: EVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
38		Stand: 07.08.2015Kapitel: Anlagen
Abschnitt:
Beispiele für die eindeutige Belegung von camt.052-messages
+ + +camt052 ONLINEBA00000201 +3-11- + +20T08:55:16+01:00DE76940593100001009554EURTESTDETT310I310 Testumge- +bung322/1234/55TESTUmsStId + + +PRCD53.45DBIT
2013-09- +04
 + + +CLBD52.45DBIT
2013-09- +10
 +[......]BOOK[......] + + +: + +@12712@ + + + +camt52 20131120085516 ONLINEBA2013- +11- +20T08:55:16+01:001false + +camt052 ONLINEBA00000201 +3-11- + +20T08:55:16+01:00DE76940593100001009554EUR TESTDETT310Testumgebung322/1234/55TEST + UmsStId + +PRCD52.45DBIT
2013-09- +10
 + +ITBD63.04DBIT
2013-10- +01
 + +[......]BOOK[......][......]BOOK[......][......]BOOK[......][......]BOOK[......][......] +BOOK[.....][......]BOOK[......] + +' + +HKCAZ:3:1+DE76940593100001009554:TESTDETT310:::280:+urn?:iso?:std?:iso?:20022?:t +ech?:xsd?:camt.052.001.02+N++++0054-11-18-13.16.27.302113' + +HIRMG:3:2+0010::Nachricht ist vollständig bearbeitet (HBMSG=10322)' + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: E
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:AnlagenStand:Seite:
Abschnitt:Beispiele für die eindeutige Belegung von camt.052-07.08.201539
+ + +HIRMS:4:2:3+0020::Der Auftrag wurde ausgeführt. +0020::Die gebuchten Umsätze wurden +übermittelt.+0020::Vormerkungen sind nicht vorhanden.' + +HICAZ:5:1:3+DE76940593100001009554:TESTDETT310:::280:+urn?:iso?:std?:iso?:20022? +:tech?:xsd?:camt.052.001.02 + +\+ + +@2741@: + + camt52 20131120085756 ONLINEBA +2013-11-20T08:57:56+01:00 2 +true + + camt052 ONLINEBA 00000 +2013-11-20T08:57:56+01:00 - - +DE76940593100001009554 EUR - - +TESTDETT310 Testumgebung - +322/1234/55TEST UmsStId + + ITBD63.04DBIT
2013-10- +01
 + +CLBD57.50 DBIT
2013-10- +01
 + +[......]BOOK[......] + +' +HNSHA:6:1+810000llortnoK' + + + + + + + + + + + + + + + +
Kapitel: EVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
40		Stand: 07.08.2015Kapitel: Anlagen
Abschnitt: Beispiele für die eindeutige Belegung von camt.052-messages
+ + +## E.7.3 HKCAZ mit Aufsetzpunkt zwischen den Buchungstagen inkl. vorgemerk- ter Umsätze + +HKCAZ:3:1+DE06940594210000027227:TESTDETT421:::280:+urn?:iso?:std?:iso?:20022?:t +ech?:xsd?:camt.052.001.02+N+20131101+20131118' + +HIRMG:3:2+3060::Teilweise liegen Warnungen oder Hinweise vor (HBMSG=10336)' + +HIRMS:4:2:3+0020::Der Auftrag wurde ausgeführt. +3040::Es liegen weitere Informationen +vor.:0054-11-18-13.16.27.302113+0020::Gebuchte Umsätze und Vormerkungen wurden +übermittelt.' + +HICAZ:5:1:3+DE06940594210000027227:TESTDETT421:::280:+urn?:iso?:std?:iso?:20022? +:tech?:xsd?:camt.052.001.02 + +\+ + +@10426@ + +camt52 20131118131627 ONLINEBA2013- +11- + +18T13:16:27+01:001true + +camt052_ONLINEBA00000201 +3-11- + +18T13:16:27+01:00DE06940594210000027227EURTESTDETT421Test- +Insti- + +tut12345678901234UmsStId + + +PRCD44055838.96CRDT
2013-10- +31
 + + +CLBD44049585.23CRDT
2013-11- +04
 + +[......]BOOK[......][......]BOOK[......][......]BOOK[......][......]BOOK[......][..... +.]BOOK[......][......]BOOK[......][......]BOOK[......][......]BOOK[......][......]BOO +K[......][......]BOOK[.....] + + + +: + +@4677@camt52 _20131118131627 +ONLINEBA2013-11- + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: E
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:AnlagenStand:Seite:
Abschnitt:Beispiele für die eindeutige Belegung von camt.052-07.08.201541
+ + +18T13:16:27+01:001true + +camt052 ONLINEBA00000201 +3-11- + +18T13:16:27+01:00DE06940594210000027227EURTESTDETT421Test- + +Insti- + +tut12345678901234UmsStId + + +PRCD44049585.23CRDT
2013-11- +04
 + + +CLBD44049601.67CRDT
2013-11- +05
 + +[......]BOOK[......][......]BOOK[......][......]BOOK[......][......]BOOK[......][..... +.]BOOK[......][......]BOOK[......][......]BOOK[......][......]BOOK[......][......]BOO +K[......][.....]BOOK[......] + + + +\+ + +@8187@camt52 20131118131627 +ONLINEBA2013-11- + +18T13:16:27+01:001true + +camt052 _ONLINEBA00000201 +3-11- + +18T13:16:27+01:00DE06940594210000027227EURTESTDETT421Test- + +Insti- + +tut12345678901234UmsStId + +[......]PDNG[......][......]PDNG[......][......]PDNG[......][......]PDNG[......][..... +.]PDNG[......][......]PDNG[......][......]PDNG[......][......]PDNG[......][....….]PDN +G[......][......]PDNG[.....] + +' + +HKCAZ:3:1+DE06940594210000027227:TESTDETT421:::280:+urn?:iso?:std?:iso?:20022?:t +ech?:xsd?:camt.052.001.02+N++++0054-11-18-13.16.27.302113' + + + + + + + + + + + + + + + +
Kapitel: EVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
42		Stand: 07.08.2015Kapitel: Anlagen
Abschnitt: Beispiele für die eindeutige Belegung von camt.052-messages
+ + +HIRMG:3:2+0010::Nachricht ist vollständig bearbeitet (HBMSG=10322)' + +HIRMS:4:2:3+0020::Der Auftrag wurde ausgeführt. +0020::Die gebuchten Umsätze wurden +übermittelt.+0020::Vormerkungen sind nicht vorhanden.' + +HICAZ:5:1:3+DE06940594210000027227:TESTDETT421:::280:+urn?:iso?:std?:iso?:20022? +:tech?:xsd?:camt.052.001.02 + +\+ + +@2741@camt52 20131118153504 +ONLINEBA2013-11- + +18T15:35:04+01:001true + +camt052 ONLINEBA00000201 +3-11- + +18T15:35:04+01:00DE06940594210000027227EURTESTDETT421Test Insti- + +tut12345678901234UmsStId + +PRCD44049601.67CRDT
2013-11- +05
 + + +CLBD44049618.33CRDT
2013-11- +06
 + +[......]BOOK[......][......]BOOK[......] + + + +: + +@2031@camt52 20131118153504 +ONLINEBA2013-11- + +18T15:35:04+01:001true + +camt052 ONLINEBA00000201 +3-11- + +18T15:35:04+01:00DE06940594210000027227EURTESTDETT421Test Insti- +tut12345678901234UmsStId + +PRCD44049618.33CRDT
2013-11- +06
 + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 Rel 2015, FVKapitel: E
Dokument:Messages - Multibankfähige Geschäftsvorfälle
Kapitel:AnlagenStand:Seite:
Abschnitt:Beispiele für die eindeutige Belegung von camt.052-07.08.201543
+ + +CLBD44049622.35CRDT
2013-11- +07
 + +[......]BOOK[......] + + + +: + +@2955@camt52 20131118153504 + +ONLINEBA2013-11- + +18T15:35:04+01:001true + +camt052_ONLINEBA00000201 +3-11- + +18T15:35:04+01:00DE06940594210000027227EURTESTDETT421Test Insti- + +tut12345678901234UmsStId + +PRCD44049622.35CRDT
2013-11- +07
 + +CLBD44049624.34CRDT
2013-11- +13
 + +[......]BOOK[......][......]BOOK[......] + + + +: + +@2099@camt52 20131118153504 + +ONLINEBA2013-11- + +18T15:35:04+01:001true + +camt052_ONLINEBA00000201 +3-11- + +18T15:35:04+01:00DE06940594210000027227EURTESTDETT421Test Insti- + +tut12345678901234UmsStId + +PRCD44049624.34CRDT
2013-11- +13
 + + + + + + + + + + + + + + + +
Kapitel: EVersion: 3.0 Rel 2015, FVFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle
Seite:
44		Stand: 07.08.2015Kapitel: Anlagen
Abschnitt: Beispiele für die eindeutige Belegung von camt.052-messages
+ + +CLBD44049624.09CRDT
2013-11- +18
 +[......]BOOK[......] +' diff --git a/docs/fints-def/FinTS_3.0_Messages_Geschaeftsvorfaelle_2015-08-07_final_version.pdf b/docs/fints-def/FinTS_3.0_Messages_Geschaeftsvorfaelle_2015-08-07_final_version.pdf new file mode 100644 index 0000000..277f7e8 Binary files /dev/null and b/docs/fints-def/FinTS_3.0_Messages_Geschaeftsvorfaelle_2015-08-07_final_version.pdf differ diff --git a/docs/fints-def/FinTS_3.0_Security_Sicherheitsverfahren_HBCI_Rel_20130718_final_version.md b/docs/fints-def/FinTS_3.0_Security_Sicherheitsverfahren_HBCI_Rel_20130718_final_version.md new file mode 100644 index 0000000..f9899cd --- /dev/null +++ b/docs/fints-def/FinTS_3.0_Security_Sicherheitsverfahren_HBCI_Rel_20130718_final_version.md @@ -0,0 +1,22774 @@ +# ZENTRALER KREDITAUSSCHUSS Financial Transaction Services (FinTS) + +\- Security - +Sicherheitsverfahren HBCI + +Herausgeber: +Bundesverband deutscher Banken e.V., Berlin +Deutscher Sparkassen- und Giroverband e.V., Bonn/Berlin +Bundesverband der Deutschen Volksbanken und Raiffeisenbanken e.V., Berlin +Bundesverband Öffentlicher Banken Deutschlands e.V., Berlin + +Version: 3.0 + +Stand: 18.07.2013 +Final Version + + + +Die vorliegende Schnittstellenspezifikation für eine automatisiert nutzbare multibankfähige +Homebanking-Schnittstelle (im Folgenden: Schnittstellenspezifikation) wurde im Auftrag des +Zentralen Kreditausschusses entwickelt. Sie wird hiermit zur Implementation in Kunden- und +Kreditinstitutssysteme freigegeben. + +Die Schnittstellenspezifikation ist urheberrechtlich geschützt. Zur Implementation in Kunden- +und Kreditinstitutssysteme wird interessierten Herstellern unentgeltlich ein einfaches Nut- +zungsrecht eingeräumt. Im Rahmen des genannten Zwecks darf die Schnittstellenspezifika- +tion auch - in unveränderter Form - vervielfältigt und zu den nachstehenden Bedingungen +verbreitet werden. + +Umgestaltungen, Bearbeitungen, Übersetzungen und jegliche Änderung der Schnittstellen- +spezifikation sind untersagt. Kennzeichnungen, Copyright-Vermerke und Eigentumsangaben +dürfen in keinem Fall geändert werden. + +Im Hinblick auf die Unentgeltlichkeit des eingeräumten Nutzungsrechts wird keinerlei Ge- +währleistung oder Haftung für Fehler der Schnittstellenspezifikation oder die ordnungsge- +mäße Funktion der auf ihr beruhenden Produkte übernommen. Die Hersteller sind aufgefor- +dert, Fehler oder Auslegungsspielräume der Spezifikation, die die ordnungsgemäße Funkti- +on oder Multibankfähigkeit von Kundenprodukten behindern, dem Zentralen Kreditausschuss +zu melden. Es wird weiterhin ausdrücklich darauf hingewiesen, dass Änderungen der +Schnittstellenspezifikation durch den Zentralen Kreditausschuss jederzeit und ohne vorheri- +ge Ankündigung möglich sind. + +Eine Weitergabe der Schnittstellenspezifikation durch den Hersteller an Dritte darf nur unent- +geltlich, in unveränderter Form und zu den vorstehenden Bedingungen erfolgen. + +Dieses Dokument kann im Internet abgerufen werden unter http://www.fints.org. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 - Final VersionKapitel:
Dokument:Security - Sicherheitsverfahren HBCI
Kapitel:VersionsführungStand: 18.07.2013Seite: 1
+ + +## Versionsführung + +Das vorliegende Dokument wurde von folgenden Personen erstellt bzw. geändert: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
NameOrgani- sationDatumVersi- onDokumenteAnmerkungen
SteinSIZ15.11.20023.0FinTS 3.0 Security - Si- cherheitsverfahren HBCI.docFrühere Versionen wur- den im Rahmen der HBCI-Spezifikation ver- öffentlicht
Haubnerfür SIZ21.06.20053.0FinTS 3.0 Security - Si- cherheitsverfahren HBCI Rel. 2005-06-21.docEnthält alle bekannt ge- wordenen Fehler und Klarstellungen bis zum Releasedatum 21.06.2005.
Haubnerfür GAD07.05.20073.0FinTS 3.0 Security - Si- cherheitsverfahren HBCI Rel. 2007-05-07 final ver- sion.docEnthält die Anpassun- gen im Zusammenhang mit der Einführung von SECCOS 6 Bankensig- naturkarten
Haubnerfür GAD15.05.20083.0FinTS 3.0 Security - Si- cherheitsverfahren HBCI Rel. 2008-05-15 final ver- sion.docKorrekturen und Klar- stellungen zur SECCOS 6 Unterstüt- zung.
Haubnerfür SIZ14.10.20113.0FinTS 3.0 Security - Si- cherheitsverfahren HBCI Rel. 2011-09-23 final ver- sion.docErgänzen RAH- Verfahren
Haubnerfür SIZ25.09.20123.0FinTS 3.0 Security - Si- cherheitsverfahren HBCI Rel. 2012-09-25 final ver- sion.docEinführen DK-Padding bei RAH-Verfahren
HaubnerFür SIZ18.07.20133.0FinTS 3.0 Security - Si- cherheitsverfahren HBCI Rel. 2013-07-18 FV.docKlarstellungen und Feh- lerkorrekturen, Verweise auf DK Kryptokatalog
+ + + + + + + + + + + + + + + + +
Kapitel:Version: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite: 2Stand: 18.07.2013Kapitel: Änderungen gegenüber der Vorversion
+ + +## Änderungen gegenüber der Vorversion + +Hinzufügungen und Änderungen sind im Dokument in dieser Farbe und zusätzlich +durch Unterstreichung und einen Randbalken markiert. Löschungen sind aufgrund +der besseren Übersichtlichkeit nur durch einen Randbalken markiert. Hypertextlinks +sind in dieser Farbe markiert. Falls sich die Kapitelnummerierung geändert hat, be- +zieht sich die Kapitelangabe auf die neue Nummerierung. Aufgrund der umfangrei- +chen Textumstellungen wurden nicht alle Änderungen markiert. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
lfd.
Nr.		KapitelSeiten- nummerKen- nungArtBeschreibung
1DiverseDiverse0408EErgänzen des RAH-Verfahrens und der damit verbundenen Sicherheitsprofile RAH-7, RAH-9 und RAH-10
2B.2.2.S. 17ff0408, 0425ÄAnpassen der Abbildungen im Zuge der Einführung des RAH-Verfahrens. Ergän- zen des DK-Paddings. Ersetzen des Terminus ,,HBCI- Nachricht“ durch ,,FinTS-Nachricht“
3B.1.1, S. 3ÄAnpassen des Passus zu verpflichten- den Sicherheitsprofilen
4B.2.2.1ÄZKA-Padding, einfügen der AES- Blocklänge=16 Byte für den Wert „L“ Fehlerbehebungen und Klarstellungen in den Abbildungen 1, 2 und 3
5B.3.1.3.1ÄLöschen von Step 5, da nicht mehr rele- vant.
6DiverseÄErsetzen der konkret angegebenen Schlüssellängen durch Referenz auf die Empfehlungen des DK Kryptokatalogs [DK Krypto]
7C.1.3.2.4.1S. 99ÄWegfall der Prüfung, ob Ausgangswert = Verschlüsselungsergebnis ist.
+ + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 - Final VersionKapitel:
Dokument:Security - Sicherheitsverfahren HBCI
Kapitel:InhaltsverzeichnisStand: 18.07.2013Seite: 1
+ + +## Inhaltsverzeichnis + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Versionsführung1
Änderungen gegenüber der Vorversion.2
Inhaltsverzeichnis1
Abbildungsverzeichnis3
Abkürzungen5
Literaturhinweise7
A. Einleitung1
B. Verfahrensbeschreibung2
B.1 Allgemeines2
B.1.1 Sicherheitsprofile3
B.1.2 Sicherheitsklassen15
B.2 Mechanismen18
B.2.1 Elektronische Signatur18
B.2.2 Verschlüsselung21
B.2.3 Sicherheitsmedien beim Kundenprodukt30
B.3 Abläufe31
B.3.1 Schlüsselverwaltung31
B.3.2 Schlüsselsperrung45
B.4 Bankfachliche Anforderungen47
B.5 Formate für Signatur und Verschlüsselung48
B.5.1 Signaturkopf49
B.5.2 Signaturabschluss52
B.5.3 Verschlüsselungskopf53
B.5.4 Verschlüsselte Daten54
B.6 Key-Management55
B.6.1 Formate für Key-Management55
B.6.2 Key-Management-Nachrichten63
+ + + + + + + + + + + + + + + + +
Kapitel:Version: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:
2		Stand: 18.07.2013Kapitel: Inhaltsverzeichnis
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
B.7 RDH-x / RAH-y (aktuelles Verfahren)
B.8 RDH-y / RAH-y (neues Verfahren)		66
66
C. Chipapplikationen77
C.1 Chipapplikation für RAH / RDH77
C.1.1 Applikation Notepad77
C.1.2 EF_NOTEPAD77
C.1.3 Terminalabläufe91
C.2 Chipapplikation für DDV105
C.2.1 Daten der Applikation HBCI-Banking für Typ 1106
C.2.2 Daten der Applikation HBCI-Banking für SECCOS 6124
C.2.3 Platzbedarf der Applikation im Chip142
C.2.4 Terminalabläufe (Typ 1 und SECCOS 6)143
C.2.5 Makros154
C.2.6 Übersicht der Chip-Applikations-Parameter158
D. Data Dictionary159
E. Anlagen183
E.1 Übersicht der Segmente183
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 - Final VersionKapitel:
Dokument:Security - Sicherheitsverfahren HBCI
Kapitel:AbbildungsverzeichnisStand: 18.07.2013Seite: 3
+ + +## Abbildungsverzeichnis + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Abbildung 1: Nachrichtenverschlüsselung mit AES im CBC-Mode für RAH- Verfahren22
Abbildung 2: Verschlüsselung bei RAH-7 und RAH-923
Abbildung 3: Verschlüsselung bei RAH-1023
Abbildung 4: Nachrichtenverschlüsselung generell mit 2-Key-Triple-DES im CBC-Mode für RDH und DDV25
Abbildung 5: Verschlüsselung bei 2-Key-Triple-DES im DDV-Verfahren26
Abbildung 6: Entschlüsselung bei 2-Key-Triple-DES im DDV-Verfahren26
Abbildung 7: Verschlüsselung bei 2-Key-Triple-DES im RDH-Verfahren27
Abbildung 8: Entschlüsselung bei 2-Key-Triple-DES im RDH-Verfahren28
Abbildung 9: Verschlüsselung bei RDH-128
Abbildung 10: Verschlüsselung bei RDH-3 und RDH-529
Abbildung 11: Verschlüsselung bei RDH-6 bis RDH-929
Abbildung 12: Verschlüsselung bei RDH-1030
Abbildung 13: Ablauf der Erstinitialisierung bei RDH41
Abbildung 14: Beispiel für die Gestaltung des Ini-Briefs bei RDH-2 oder RDH-542
Abbildung 15: Beispiel für die Gestaltung des Ini-Briefs bei RAH-9, RAH-10, RDH-8, RDH-9 oder RDH-1043
Abbildung 16: Unterstützte Sicherheitsprofilwechsel RDH-1, RDH-2 und RDH-5 ...64
Abbildung 17: Unterstützte Sicherheitsprofilwechsel RDH-1, RDH-2 RDH-5, RDH-9 und RDH-1065
Abbildung 18: Unterstützte Sicherheitsprofilwechsel beim Übergang von RDH- auf RAH-Verfahren67
Abbildung 19: Datenelemente der Applikation "HBCI", Bankensignaturkarte mit Zertifikat106
Abbildung 20: Datenelemente der Applikation "HBCI", Bankensignaturkarte ohne Zertifikat107
Abbildung 21: Datenelemente der Applikation "HBCI", Bankensignaturkarte mit Zertifikat
124
+ + + + + + + + + + + + + + + + +
Kapitel:Version: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:
4		Stand: 18.07.2013Kapitel:
Abbildungsverzeichnis
+ + +Abbildung 22: Datenelemente der Applikation "HBCI", Bankensignaturkarte +ohne Zertifikat + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 - Final VersionKapitel:
Dokument:Security - Sicherheitsverfahren HBCI
Kapitel:AbkürzungenStand: 18.07.2013Seite: 5
+ + +## Abkürzungen + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
AbkürzungBedeutung
ACAccess Condition
AEFApplication Elementary File
AESAdvanced Encryption Standard
AIDApplication Identifier
BPDBankparameterdaten
CDatenstruktur ist konditional
CBCCipher Block Chaining
CIDCardholders Information Data (Kartenidentifikationsdaten der ZKA- Chipkarte)
CLAClass Byte
CRCarriage-Return (Wagenrücklauf)
DDVDES-DES-Verfahren
DEDatenelement
DEGDatenelementgruppe
DESData Encryption Standard
DFDedicated File
DFÜSynonym verwendet für "Datenkommunikation, die in Form von Fi- letransfer, E-Mail, Online-Nachrichtenaustausch etc. erfolgen kann
DKDie Deutsche Kreditwirtschaft
ECBElectronic Code Book
EDIFACTElectronic Data Interchange for Administration, Commerce and Transport
EFElementary File
EUElektronische Unterschrift; basiert auf dem asymmetrischen RSA- Verfahren
FCIFile Control Information
FCPFile Control Parameters
FCSFrame Check Sequence
FMDFile Management Data
GDGruppendatenelement
GDGGruppendatenelementgruppe
HBCIHomebanking Computer Interface
IInformation (z.B. Schlüsselart)
IDIdentifikationsmerkmal (Nummer oder alphanumerischer Code)
ISOInternational Organisation for Standardisation
IVInitialisierungsvektor
KGKKey Generating Key
+ + + + + + + + + + + + + + + + + + + + + +
Kapitel:Version: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:Stand:Kapitel: Abkürzungen
618.07.2013
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
AbkürzungBedeutung
LFLine-Feed (neue Zeile)
MDatenstruktur muss vorhanden sein und ist inhaltlich korrekt zu füllen
MACMessage Authentication Code; Symmetrisches Verfahren zur Erzeu- gung einer elektronischen Signatur (derzeit für die ZKA-Chipkarte ein- gesetzt)
MFMaster File
MFCMultifunktions-Chipkarte
MIMEMultipurpose Internet Mail Extensions
NNachricht
NNicht erlaubt (not allowed) (Datenstruktur darf nicht vorhanden sein)
ODatenstruktur ist optional
OIDObject IDentifier
PKDPublic-Key-Daten
RAHRSA-AES-Hybridverfahren
RDHRSA-DES-Hybridverfahren
RFCRequest for Comment
RSAAsymmetrischer Algorithmus für die elektronische Unterschrift (EU) (vgl. MAC), benannt nach den Erfindern Rivest, Shamir und Adleman.
SEGSegment
SEQSequenznummer
SFSegmentfolge
SFIShort File Identifier
SHASecure Hash Algorithm
SSLSecure Socket Layer
TTransaktion (z.B. Schlüsselart)
UN/EDIFACTs. EDIFACT
UPDUserparameterdaten
ZKAZentraler Kreditausschuss
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 - Final VersionKapitel:
Dokument:Security - Sicherheitsverfahren HBCI
Kapitel:LiteraturhinweiseStand: 18.07.2013Seite: 7
+ + +## Literaturhinweise + + +### . Allgemeines + +[DF_NOTEPAD] Genereller +Aufbau +der +SECCOS-Applikation +Notepad +(„DF_NOTEPAD“) für FinTS und das DFÜ-Abkommen , Version +3.0, 21.06.2005, Zentraler Kreditausschuss + +[Formals] +Financial Transaction Services (FinTS) - Formals (Allgemeine +Festlegungen für multibankfähige Online-Verfahren der deutschen +Kreditwirtschaft), Version 3.0, 14.06.2011, Zentraler Kreditaus- +schuss + +[HKAZS] +Financial Transaction Services (FinTS) - Security, Alternative Si- +cherheitsverfahren, Version 3.0, 22.01.2013, Die Deutsche Kredit- +wirtschaft + +[ISO 3166] +ISO 3166-1:1996: Code for the representation of names of coun- +tries and their subdivisions - Part 1: Country code +http://www.din.de/gremien/nas/nabd/iso3166ma/ oder +http://www.unece.org/trade/lcode/loc99.zip) + + +### ◆ Verfahrensbeschreibung + +[AES] +Federal Information Processing Standards 197 v. 26. November +2001, National Institute of Standards and Technology (NIST) + +[SigG] +Gesetz über Rahmenbedingungen für elektronische Signaturen +und zur Änderung weiterer Vorschriften v. 16. Mai 2001, Bundes- +gesetzblatt Jahrgang 2001, Teil I Nr. 22 + +[SigV] +Verordnung zur elektronischen Signatur v. 16. November 2001, +Bundesgesetzblatt Jahrgang 2001, Teil I Nr. 59 + +[EU-Richtlinie] +Richtlinie 1999/93/EG des Europäischen Parlaments und des Ra- +tes vom 13. Dezember 1999 über gemeinschaftliche Rahmenbe- +dingungen für elektronische Signaturen, Amtsblatt der Europäi- +schen Gemeinschaften v. 19.01.2000 + +[FormAnpG] +Gesetz zur Anpassung der Formvorschriften des Privatrechts und +anderer Vorschriften an den modernen Rechtsgeschäftsverkehr, +13. Juli 2001, Bundesgesetzblatt Jahrgang 2001, Teil I Nr. 35 + +[DFÜ-Abkommen] + +Kryptographische Verfahren des deutschen Kreditgewerbes für die +Elektronische Unterschrift und für die Verschlüsselung im Rahmen +der Kunde-Bank-Kommunikation + +in: Anlage 1 der Schnittstellenspezifikation für die Datenfernüber- +tragung zwischen Kunde und Kreditinstitut gemäß DFÜ- +Abkommen - Spezifikation für die EBICS-Anbindung, Version 2.5, +16.05.2011 + + + + + + + + + + + + + + + +
Kapitel:Version: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:
8		Stand: 18.07.2013Kapitel: Literaturhinweise
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
[DK Krypto]ZKA Kryptographie - Teil 1: Empfohlene kryptographische Algo- rithmen, Version 1.0
[ISO 9735-5]ISO 9735-5:1999 Electronic data interchange for administration, commerce and transport - (EDIFACT) - Application level syntax rules; (Syntax version number: 4) - Part 5: Security rules for batch EDI (Authenticity; Integrity and Non-repudiation of origin)
[ISO 9735-7]ISO 9735-7:1999 Electronic data interchange for administration, commerce and transport - (EDIFACT) - Application level syntax rules; (Syntax version number: 4) - Part 7: Security rules for batch EDI (Confidentiality)
[ISO 9735-9]ISO 9735-9:1999 Electronic data interchange for administration, commerce and transport - (EDIFACT) - Application level syntax rules; (Syntax version number: 4) - Part 9: Security key and certifi- cate management message (Message type - KEYMAN)
[ISO 9796]ISO 9796:1991: Information technology - Security techniques - Digital signature scheme giving message recovery
[ISO 9796-2]ISO 9796-2:1997: Information technology - Security techniques - Digital signature scheme giving message recovery - Part 2: Mech- anisms using a hash-function
[ISO 9796-3]ISO 9796-3:2000 Information technology - Security techniques - Digital signature scheme giving message recovery - Part 3: Dis- crete logarithm based mechanisms
[ISO 10116]ISO 10116:1997 Information technology Security techniques - Modes of operation for an n-bit block cipher algorithm
[ISO 10118-2]ISO 10118-2:1994 Information technology - Security techniques - Hash functions Part 2: Hash functions using an n-bit block cipher algorithm
[ISO 10118-3]ISO 10118-3:1998 Information technology - Security techniques - Hash functions Part 3: Dedicated hash-functions, 1998
[ISO 10126-1]ISO 10126-1:1991: Banking - Procedures for message encipher- ment (wholesale) - Part 1: General principles
[ISO 10126-2]ISO 10126-2:1991 Banking - Procedures for message encipher- ment (wholesale) - Part 2: DEA algorithm
[X3.92]ANSI X3.92-1981 (R1987): Data Encryption Algorithm
[X3.106]ANSI X3.106-1983 (R1996): Data Encryption Algorithm, Modes of operation for the
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 - Final VersionKapitel:
Dokument:Security - Sicherheitsverfahren HBCI
Kapitel:LiteraturhinweiseStand: 18.07.2013Seite: 9
+ + +[X9.19] + +ANSI X9.19-1996: Financial Institution Retail Message Authentica- +tion + +[X9.23] + +ANSI X9.23-1995 (R1995): Financial Institution Encryption of +Wholesale Financial Messages + +[X509] + +RFC 3039: Internet X.509 Public Key Infrastructure Qualified Cer- +tificates Profile + +[PKCS1] + +PKCS #1: RSA Cryptography Standard, Version 2.1, RSA Labora- +tories, June 2002 +(ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1.pdf) + +[SHA-1] + +FIPS 180-1, Secure Hash Standard, Federal Information Pro- +cessing Standards Publication 180-1, U. S. Department of Com- +merce / N.I.S.T., National Technical Information Service, 1995 +(http://www.itl.nist.gov/fipspubs/fip180-1.htm) + +[SHA-256] + +Federal Information Processing Standards Publication +180-2 2002 August 1, +(http://csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf) + +[ALGO] + +Geeignete Kryptoalgorithmen gemäß Anlage 1, I 2, SigV vom 22. +November 2001, +aktueller Stand siehe unter http://www.bsi.de/esig/kryptoalg.htm + +[ISIS/MTT] + +ISIS/MTT (Industrial Signature Interoperability and MailTrusT +Specification / MailTrusT) Version 1 - Part 1: Certificate and CRL +Profiles. + +[CIPHER] + +EDIFACT Message Implementation Guidelines: Ciphered Text +Message. CIPHER, SJWG; Working Draft Version, Paris Septem- +ber 16th 1994 + +[EDIFACT SIG] + +EDIFACT +Security +Implementation +Guidelines, +Trade/WP.4/R.1026/Add.2, 22 February + +[KEYMAN] + +MIG Handbook UN/EDIFACT Message KEYMAN (proposed draft), +June 30, 1995 + +[RSA] +R. Rivest, A. Shamir, L. Adleman: A method for obtaining digital +signatures and public key cryptosystems, Communications of the +ACM, vol. 21 no. 2, 1978. + +[RIPEMD] +H. Dobbertin, A. Bosselaers, B. Preneel: ,RIPEMD-160, a +strengthened version of RIPEMD", Fast Software Encryption - +Cambridge Workshop 1996, LNCS, Band 1039, D. Gollmann, Ed., +Springer-Verlag, 1996, S. 71-82 +(http://www.esat.kuleuven.ac.be/~bosselae/ripemd160.html) + + + + + + + + + + + + + + + + + + + + +
Kapitel:Version: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:Stand:Kapitel: Literaturhinweise
1018.07.2013
+ + +. Chipapplikationen + +[ISO PIN1] +ISO 9564-1, Banking - Personal Identification Number Manage- +ment and Security, Part 1: PIN protection principles and tech- +niques, DIS 1999 + +[DAT-MF] +Schnittstellenspezifikation für die ec-Karte mit Chip, Dateien des +MF, Version 4.2, 01.12.1999 + +[LT] +Schnittstellenspezifikation für die ec-Karte mit Chip, Ladeterminal, +Version 3.0, 02.04.1998 + +[DATKOM] +Schnittstellenspezifikation für die ZKA-Chipkarte, Datenstrukturen +und Kommandos, Version 4.1, 01.07.1999 + +[KT-KONZEPT] +Schnittstellenspezifikation für die ZKA-Chipkarte, Konzept für die +Unterstützung der Signatur-Anwendung der ZKA-Chipkarte durch +das Internet-Kundenterminal, Version 1.0, 15. Februar 2002 + +[KT-SIG] +Schnittstellenspezifikation für die ZKA-Chipkarte, Spezifikation des +Internet-Kundenterminals für die Unterstützung der Signatur- +Anwendung der ZKA-Chipkarte (ZKA-SIG-API), Version 2.0, 10. +März 2008 + +[SECCOS] + +Schnittstellenspezifikation für die ZKA-Chipkarte, Secure Chip +Card Operating System (SECCOS), Version 5.0, 5. Juni 2001 mit +Errata vom 13. Juni 2001 + +[SECCOS-6] +Interface Specifications for the SECCOS ICC Secure Chip Card +Operating System (SECCOS) Version 6.2.1, 11.11.2009 + +[ZKASIG] +Schnittstellenspezifikation für die ZKA-Chipkarte, Digital Signature +Application for SECCOS 6, Version 1.3.1, 10. März 2011 + +[DINSIG] +Chipcards with digital signature application/function according to +SigG and SigV, Part 4: Basic Security Services, DIN V66291-4 +vom 14. September 2001 + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionA
Kapitel:EinleitungStand:Seite:
Abschnitt:Allgemeines18.07.20131
+ + +## A. EINLEITUNG + +In diesem Dokument wird das Sicherheitsverfahren HBCI (,Homebanking Compu- +ter-Interface") beschrieben Dieses Verfahren beruht auf modernen kryptographi- +schen Methoden und Algorithmen, wie z.B. der Digitalen Signatur und Chipkarten- +technologie. + +Dieses Sicherheitsverfahren kann in multibankfähigen Onlinebanking-Verfahren der +deutschen Kreditwirtschaft eingesetzt werden. + +Informationen bzgl. Nachrichtenaufbau und Dialogablauf sind dem Dokument [For- +mals] zu entnehmen. + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:
2		Stand: 18.07.2013Kapitel: Verfahrensbeschreibung
Abschnitt: Allgemeines
+ + +## B. VERFAHRENSBESCHREIBUNG + + +### B.1 Allgemeines + +Im Rahmen von HBCI werden zeitgemäße Sicherheitsmechanismen und -methoden +eingesetzt, welche den Missbrauch der im Bereich des Homebankings eingesetzten +Systeme verhindern. + +Das folgende Kapitel ist in sechs Abschnitte gegliedert, welche sich mit den verwen- +deten Sicherheitsmechanismen, den Abläufen, den bankfachlichen Anforderungen +sowie den Segmentformaten für Signatur, Verschlüsselung und Key-Management +beschäftigen. + +Die Ausführungen lehnen sich an bestehende deutsche Kreditinstitutsstandards +(ZKA-Abkommen, z.B. DFÜ-Abkommen, ec-Chipkarte), sowie an internationale +Standards (z.B. ISO, UN/EDIFACT) an. + +Grundsätzlich kommen im Rahmen von HBCI drei verschiedene Sicherheitslösun- +gen zum Einsatz: + +· zwei auf dem asymmetrischen RSA-Verfahren basierende Lösungen + +• eine auf dem symmetrischen DES-Verfahren basierende Chipkartenlösung + +Die drei Varianten werden mit RAH (RSA-AES-Hybridverfahren), RDH (RSA-DES- +Hybridverfahren)_bzw. DDV (DES-DES-Verfahren) gekennzeichnet. RAH und RDH +signieren mit RSA-EU und chiffrieren den Nachrichtenschlüssel mittels RSA, wäh- +rend DDV den MAC als Signatur verwendet und den Nachrichtenschlüssel (nach- +richtenbezogener Chiffrierschlüssel) mittels 2-Key-Triple-DES verschlüsselt. + +Die in Version 3.0 neu aufgenommene einheitliche Chipkartenlösung für das RAH- +respektive RDH-Verfahren ist das angestrebte Zielverfahren. Da diese Sicherheits- +konzeption momentan aufgrund technischer Restriktionen noch nicht flächende- +ckend umzusetzen ist, kommt bis zur durchgehenden Verfügbarkeit der RSA- +Chipkartenlösung zusätzlich sowohl die DDV-Lösung auf Chipkartenbasis als auch +RAH-/RDH-Lösungen auf reiner Softwarebasis oder auf Basis proprietärer Chipkar- +tenlösungen zum Einsatz. + + +## . RAH-Verfahren + +Realisierung Bank: +verpflichtend + +Realisierung Kunde: verpflichtend. Ausgenommen hiervon sind Endgeräte, die eine +RSA-EU-Lösung oder RAH-Verschlüsselung noch nicht erlau- +ben (z.B. Smartphones mit MAC-Chipkarte erlauben ggf. kei- +ne RSA-EU, PC-basierte Produkte müssen hingegen stets die +RSA-EU unterstützen). + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 - Final VersionKapitel: B
Dokument:Security - Sicherheitsverfahren HBCI
Kapitel:VerfahrensbeschreibungStand:Seite:
Abschnitt:Allgemeines18.07.20133
+ + +## RDH-Verfahren + +Realisierung Bank: + +verpflichtend, falls übergangsweise das RAH-Verfahren noch +nicht angeboten werden kann + +Realisierung Kunde: + +verpflichtend,solange das RAH-Verfahren noch nicht flächen- +deckend eingeführt ist. + +Ausgenommen hiervon sind Endgeräte, die eine RSA-EU- +Lösung oder RDH-Verschlüsselung noch nicht erlauben (z.B. +Smartphones mit MAC-Chipkarte erlauben ggf. keine RSA- +EU, PC-basierte Produkte müssen hingegen stets die RSA- +EU unterstützen). + + +## . DDV-Verfahren + +Realisierung Bank: +optional (empfohlen) + +Realisierung Kunde: +optional + + +### B.1.1 Sicherheitsprofile + +Die Sicherheitsverfahren RAH, RDH und DDV können unterschiedlich parametrisiert +werden, wobei Sicherheitsprofile entstehen. Um Multibankfähigkeit zu gewährleis- +ten, ist bei Kommunikation auf Basis von FinTS 3.0 kundenproduktseitig die Unter- +stützung der Sicherheitsprofile RAH-7 und RDH-7, sowie RAH-9 und RDH-9 ver- +pflichtend. Aus Kompatibilitätsgründen sind die in den bisherigen FinTS-Versionen +genutzten Profile RDH-1, RDH-2, RDH-3, RDH-5, RDH-6, RDH-7, RDH-8, RDH-10, +und DDV-1 weiterhin gültig. Andere als die unten genannten Profile sind nicht zuläs- +sig. + +Das Kreditinstitut teilt dem Kunden die bankseitig unterstützten Profile in den Bank- +parameterdaten mit. Der Kunde wählt aus diesen Verfahren das für ihn geeignete +Verfahren aus und bildet auf diese Weise Signatur und Verschlüsselung. Das Kre- +ditinstitut antwortet stets mit dem vom Kunden gewählten Verfahren. + +Hier eine Übersicht der zugelassenen Sicherheitsprofile und deren Anwendungs- +spektrum: + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite: 4Stand: 18.07.2013Kapitel: Verfahrensbeschreibung
Abschnitt: Allgemeines
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Sicherheits- profilSchlüssel- längeMediumBemerkungen
RAH-7gemäß [DK Krypto]1Bankensignaturkarte SECCOS 6mit SHA-256, PKCS#1 PSS Padding, AES-Verschlüsselung
RAH-9gemäß [DK Krypto]Bankensignaturkarte SECCOS 6wie RAH-7 ohne Zertifikate
RAH-10gemäß [DK Krypto]RSA-SW-Lösungmit SHA-256, PKCS#1 PSS Padding, AES-Verschlüsselung
RDH-1708 bis 768 bitRSA-SW-Lösung RSA-ChipkarteRIPEMD-160_ISO 9796-1 Padding, Triple-DES-Verschlüsselung
RDH-21024 bis 2048 bitRSA-SW-LösungRIPEMD-160, ISO 9796-2 Padding, Triple-DES-Verschlüsselung
RDH-31024 bis 2048 bitBankensignaturkarte SECCOS 5RIPEMD-160, ISO 9796-2 Padding, Triple-DES-Verschlüsselung bzw. SHA-1_PKCS#1 V15 Padding, Triple-DES-Verschlüsselung
RDH-421024 bis 2048 bitBankensignaturkarte SECCOS 5SHA-1_PKCS#1 V15 Padding, Triple-DES-Verschlüsselung
RDH-51024 bis 2048 bitBankensignaturkarte SECCOS 5wie RDH-3 ohne Zertifikate
RDH-6gemäß [DK Krypto]Bankensignaturkarte SECCOS 5 / 6mit SHA-256_PKCS#1 V15 Padding, Triple-DES-Verschlüsselung
RDH-7gemäß [DK Krypto]Bankensignaturkarte SECCOS 6mit SHA-256_PKCS#1 PSS Padding, Triple-DES-Verschlüsselung
RDH-8gemäß [DK Krypto]Bankensignaturkarte SECCOS 5 / 6wie RDH-6 ohne Zertifikate
RDH-9gemäß [DK Krypto]Bankensignaturkarte SECCOS 6wie RDH-7 ohne Zertifikate
RDH-10gemäß [DK Krypto]RSA-SW-Lösungmit SHA-256_PKCS#1 PSS Padding, Triple-DES-Verschlüsselung
+ + +Die Angaben zum SECCOS-Betriebssystem bzw. der Betriebssystemversion sind +nur als beispielhaft anzusehen; es kann auch jede gleichwertige Signaturkarte ver- +wendet werden, welche die geforderten Verfahren unterstützt. + +Die Information über die Betriebssystemversion kann dem Byte 24 in EF_ID ent- +nommen werden. Dort sind derzeit folgende Werte vorgesehen: + +X'01': SECCOS 5 + +X'06': SECCOS 6 + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 - Final VersionKapitel: B
Dokument:Security - Sicherheitsverfahren HBCI
Kapitel:VerfahrensbeschreibungStand:Seite:
Abschnitt:Allgemeines18.07.20135
+ + +## RAH-7 + +Als Sicherheitsmedium für das Kundensystem ist nur die Bankensignaturkarte oder +eine gleichwertige Signaturkarte zugelassen. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ParameterWertBedeutung
Signaturalgorithmus, kodiert10RSA
Operationsmodus bei Signatur19Signier- und Signaturschlüs- sel - RSASSA- PSS [PKCS1]
Verwendung des Signaturalgorithmus6Owner Signing
Hashalgorithmus, kodiert6
3		Signierschlüssel - SHA-256 / SHA-256 [SHA-256] Signaturschlüssel - SHA- 256 [SHA-256]
Verschlüsselungsalgorithmus, kodiert14AES-256 [AES]
Operationsmodus bei Verschlüsselung18RSAES-PKCS1-v1 5 [PKCS1]
SchlüsselartS
V
D		Signierschlüssel Chiffrierschlüssel Schlüssel für Digitale Signa- turen
Schlüssellängegemäß [DK Krypto]
Zertifikatstyp3X.509
ZertifikatsinhaltEF X509.CH.DSfortgeschritten oder qualifi- ziert abh. von der Sicher- heitsklasse
+ + +Im Rahmen des Paddingverfahrens RSASSA-PSS wird als ,,Mask Generation Func- +tion" MGF1 verwendet. Beim Signierschlüssel wird ein doppeltes Hashing (Software +und Bankensignaturkarte) durchgeführt. Dies wird durch eine spezielle Ausprägung +des ,,Hashalgorithmus, kodiert“ gekennzeichnet. + +Als Salt-Länge (Länge des Initialwertes) ist die Länge des Hashwertes zu verwen- +den. Diese Festlegung ist z. B. auch Bestandteil der SECCOS 6 Spezifikation. + + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite: 6Stand: 18.07.2013Kapitel: Verfahrensbeschreibung
Abschnitt: Allgemeines
+ + +## RAH-9 + +Als Sicherheitsmedium für das Kundensystem ist nur die Bankensignaturkarte oder +eine gleichwertige Signaturkarte zugelassen. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ParameterWertBedeutung/Anmerkung
Signaturalgorithmus, kodiert10RSA
Operationsmodus bei Signatur19RSASSA-PSS [PKCS1]
Verwendung des Signaturalgorithmus6Owner Signing
Hashalgorithmus, kodiert6SHA-256 / SHA-256 [SHA-256]
Verschlüsselungsalgorithmus, kodiert14AES-256 [AES]
Operationsmodus bei Verschlüsselung18RSAES-PKCS1-v1 5 [PKCS1]
SchlüsselartVSignierschlüssel Chiffrierschlüssel
Schlüssellängegemäß [DK Krypto]
Zertifikatstypohne
Zertifikatsinhaltnicht spezifiziert
+ + +Im Rahmen des Paddingverfahrens RSASSA-PSS wird als ,,Mask Generation Func- +tion" MGF1 verwendet. Beim Signierschlüssel wird ein doppeltes Hashing (Software +und Bankensignaturkarte) durchgeführt. Dies wird durch eine spezielle Ausprägung +des ,,Hashalgorithmus, kodiert" gekennzeichnet. + +Als Salt-Länge (Länge des Initialwertes) ist die Länge des Hashwertes zu verwen- +den. Diese Festlegung ist z. B. auch Bestandteil der SECCOS 6 Spezifikation. + + +## RAH-10 + +Als Sicherheitsmedium für das Kundensystem ist eine RSA-Softwarelösung zuge- +lassen. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ParameterWertBedeutung/Anmerkung
Signaturalgorithmus, kodiert10RSA
Operationsmodus bei Signatur19RSASSA-PSS [PKCS1]
Verwendung des Signaturalgorithmus6Owner Signing
Hashalgorithmus, kodiert6SHA-256 / SHA-256 [SHA-256]
Verschlüsselungsalgorithmus, kodiert14AES-256 [AES]
Operationsmodus bei Verschlüsselung2CBC (0-Padding)
SchlüsselartS
V		Signierschlüssel Chiffrierschlüssel
Schlüssellängegemäß [DK Krypto]
Zertifikatstyp1 2
3		ZKA UN/EDIFACT X.509
Zertifikatsinhaltnicht spezifiziert
+ + +Im Rahmen des Paddingverfahrens RSASSA-PSS wird als ,,Mask Generation Func- +tion" MGF1 verwendet. Beim Signierschlüssel wird ein doppeltes Hashing durchge- +führt. Dies wird durch eine spezielle Ausprägung des ,,Hashalgorithmus, kodiert" ge- +kennzeichnet. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionB
Kapitel:VerfahrensbeschreibungStand:Seite:
Abschnitt:Allgemeines18.07.20137
+ + +Als Salt-Länge (Länge des Initialwertes) ist die Länge des Hashwertes zu verwen- +den. + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite: 8Stand: 18.07.2013Kapitel: Verfahrensbeschreibung
Abschnitt: Allgemeines
+ + +## . RDH-1 + +Als Sicherheitsmedien für das Kundensystem sind RSA-Softwarelösungen und +RSA-Chipkarten zugelassen. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ParameterWertBedeutung/Anmerkung
Signaturalgorithmus, kodiert10RSA
Operationsmodus bei Signatur16ISO 9796-1
Verwendung des Signaturalgorithmus6Owner Signing
Hashalgorithmus, kodiert999RIPEMD-160
Verschlüsselungsalgorithmus, kodiert132-Key-Triple-DES
Operationsmodus bei Verschlüsselung2CBC (0-Padding)
SchlüsselartS
V		Signierschlüssel Chiffrierschlüssel
Schlüssellänge708-768 Bit
Zertifikatstyp1
2
3		ZKA UN/EDIFACT X.509
Zertifikatsinhaltnicht spezifiziert
+ + +## . RDH-2 + +Als Sicherheitsmedium für das Kundensystem ist eine RSA-Softwarelösung zuge- +lassen. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ParameterWertBedeutung/Anmerkung
Signaturalgorithmus, kodiert10RSA
Operationsmodus bei Signatur17ISO 9796-2
Verwendung des Signaturalgorithmus6Owner Signing
Hashalgorithmus, kodiert999RIPEMD-160
Verschlüsselungsalgorithmus, kodiert132-Key-Triple-DES
Operationsmodus bei Verschlüsselung2CBC (0-Padding)
SchlüsselartS
V		Signierschlüssel Chiffrierschlüssel
Schlüssellänge1024-2048 Bit
Zertifikatstyp1
2
3		ZKA UN/EDIFACT X.509
Zertifikatsinhaltnicht spezifiziert
+ + +## . RDH-3 + +Als Sicherheitsmedium für das Kundensystem ist nur die Bankensignaturkarte oder +eine gleichwertige Signaturkarte zugelassen. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionB
Kapitel:VerfahrensbeschreibungStand:Seite:
Abschnitt:Allgemeines18.07.20139
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ParameterWertBedeutung/Anmerkung
Signaturalgorithmus, kodiert10RSA
Operationsmodus bei Signatur18 (bei S)
17 (bei D)		Signierschlüssel: RSASSA-PKCS1-v1_5 [PKCS1] Signaturschlüssel: ISO 9796-2
Verwendung des Signaturalgorithmus6Owner Signing
Hashalgorithmus, kodiert1 (bei S) 999 (bei D)Signierschlüssel: SHA-1 Signaturschlüssel: RIPEMD-160
Verschlüsselungsalgorithmus, kodiert132-Key-Triple-DES
Operationsmodus bei Verschlüsselung418RSAES-PKCS1-V1_5 [PKCS1]
SchlüsselartS V
D		Signierschlüssel Chiffrierschlüssel Schlüssel für Digitale Signa- turen
Schlüssellänge1024-2048 Bit
Zertifikatstyp3X.509
ZertifikatsinhaltEF_X509.CH.DSfortgeschritten oder qualifi- ziert abh. von der Sicher- heitsklasse
+ + +## . RDH-4 + +Das Verfahren RDH-4 ist obsolet, da es SHA-1 als Hashwertverfahren einsetzt und +daher für Neu-Anwendungen nicht mehr als sicher gelten kann. + + +## . RDH-5 + +Als Sicherheitsmedium für das Kundensystem ist eine Bankensignaturkarte oder ei- +ne gleichwertige Signaturkarte zugelassen. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ParameterWertBedeutung/Anmerkung
Signaturalgorithmus, kodiert10RSA
Operationsmodus bei Signatur18RSASSA-PKCS1-v1_5 [PKCS1]
Verwendung des Signaturalgorithmus6Owner Signing
Hashalgorithmus, kodiert1SHA1
Verschlüsselungsalgorithmus, kodiert132-Key-Triple-DES
Operationsmodus bei Verschlüsselung18RSAES-PKCS1-v1_5 [PKCS1]
SchlüsselartS VSignierschlüssel Chiffrierschlüssel
Schlüssellänge1024-2048 Bit
Zertifikatstypohne
Zertifikatsinhaltnicht spezifiziert
Kapitel: BVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite: 10Stand: 18.07.2013Kapitel: Verfahrensbeschreibung
Abschnitt: Allgemeines
+ + +## . RDH-6 + +Als Sicherheitsmedium für das Kundensystem ist nur die Bankensignaturkarte oder +eine gleichwertige Signaturkarte zugelassen. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ParameterWertBedeutung
Signaturalgorithmus, kodiert10RSA
Operationsmodus bei Signatur18Signier- und Signaturschlüs- sel - RSASSA -PKCS1- v1_5 [PKCS1]
Verwendung des Signaturalgorithmus6Owner Signing
Hashalgorithmus, kodiert3SHA-256 [SHA-256]
Verschlüsselungsalgorithmus, kodiert132-Key-Triple-DES
Operationsmodus bei Verschlüsselung18RSAES-PKCS1-v1_5 [PKCS1]
SchlüsselartS
V
D		Signierschlüssel Chiffrierschlüssel Schlüssel für Digitale Signa- turen
Schlüssellängegemäß [DK Krypto]
Zertifikatstyp3X.509
ZertifikatsinhaltEF_X509.CH.DSfortgeschritten oder qualifi- ziert abh. von der Sicher- heitsklasse
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: B
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final Version
Kapitel:VerfahrensbeschreibungStand:Seite:
Abschnitt:Allgemeines18.07.201311
+ + +## . RDH-7 + +Als Sicherheitsmedium für das Kundensystem ist nur die Bankensignaturkarte oder +eine gleichwertige Signaturkarte zugelassen. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ParameterWertBedeutung
Signaturalgorithmus, kodiert10RSA
Operationsmodus bei Signatur19Signier- und Signaturschlüs- sel - RSASSA- PSS [PKCS1]
Verwendung des Signaturalgorithmus6Owner Signing
Hashalgorithmus, kodiert6
3		Signierschlüssel - SHA-256 / SHA-256 [SHA-256] Signaturschlüssel - SHA- 256 [SHA-256]
Verschlüsselungsalgorithmus, kodiert132-Key-Triple-DES
Operationsmodus bei Verschlüsselung18RSAES-PKCS1-v1_5 [PKCS1]
SchlüsselartS V
D		Signierschlüssel Chiffrierschlüssel Schlüssel für Digitale Signa- turen
Schlüssellängegemäß [DK Krypto]
Zertifikatstyp3X.509
ZertifikatsinhaltEF_X509.CH.DSfortgeschritten oder qualifi- ziert abh. von der Sicher- heitsklasse
+ + +Im Rahmen des Paddingverfahrens RSASSA-PSS wird als ,,Mask Generation Func- +tion" MGF1 verwendet. Beim Signierschlüssel wird ein doppeltes Hashing (Software +und Bankensignaturkarte) durchgeführt. Dies wird durch eine spezielle Ausprägung +des ,,Hashalgorithmus, kodiert“ gekennzeichnet. + +Als Salt-Länge (Länge des Initialwertes) ist die Länge des Hashwertes zu verwen- +den. Diese Festlegung ist z. B. auch Bestandteil der SECCOS 6 Spezifikation. + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite: 12Stand: 18.07.2013Kapitel: Verfahrensbeschreibung
Abschnitt: Allgemeines
+ + +## . RDH-8 + +Als Sicherheitsmedium für das Kundensystem ist nur die Bankensignaturkarte oder +eine gleichwertige Signaturkarte zugelassen. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ParameterWertBedeutung/Anmerkung
Signaturalgorithmus, kodiert10RSA
Operationsmodus bei Signatur18RSASSA-PKCS1-v1_5 [PKCS1]
Verwendung des Signaturalgorithmus6Owner Signing
Hashalgorithmus, kodiert3SHA-256 [SHA-256]
Verschlüsselungsalgorithmus, kodiert132-Key-Triple-DES
Operationsmodus bei Verschlüsselung18RSAES-PKCS1-v1_5 [PKCS1]
SchlüsselartS VSignierschlüssel Chiffrierschlüssel
Schlüssellängegemäß [DK Krypto]
Zertifikatstypohne
Zertifikatsinhaltnicht spezifiziert
+ + +## . RDH-9 + +Als Sicherheitsmedium für das Kundensystem ist nur die Bankensignaturkarte mit +oder eine gleichwertige Signaturkarte zugelassen. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ParameterWertBedeutung/Anmerkung
Signaturalgorithmus, kodiert10RSA
Operationsmodus bei Signatur19RSASSA-PSS [PKCS1]
Verwendung des Signaturalgorithmus6Owner Signing
Hashalgorithmus, kodiert6SHA-256 / SHA-256 [SHA-256]
Verschlüsselungsalgorithmus, kodiert132-Key-Triple-DES
Operationsmodus bei Verschlüsselung18RSAES-PKCS1-v1_5 [PKCS1]
SchlüsselartS VSignierschlüssel Chiffrierschlüssel
Schlüssellängegemäß [DK Krypto]
Zertifikatstypohne
Zertifikatsinhaltnicht spezifiziert
+ + +Im Rahmen des Paddingverfahrens RSASSA-PSS wird als ,,Mask Generation Func- +tion" MGF1 verwendet. Beim Signierschlüssel wird ein doppeltes Hashing (Software +und Bankensignaturkarte) durchgeführt. Dies wird durch eine spezielle Ausprägung +des ,,Hashalgorithmus, kodiert" gekennzeichnet. + +Als Salt-Länge (Länge des Initialwertes) ist die Länge des Hashwertes zu verwen- +den. Diese Festlegung ist z. B. auch Bestandteil der SECCOS 6 Spezifikation. + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: B
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final Version
Kapitel:VerfahrensbeschreibungStand:Seite:
Abschnitt:Allgemeines18.07.201313
+ + +## . RDH-10 + +Als Sicherheitsmedium für das Kundensystem ist eine RSA-Softwarelösung zuge- +lassen. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ParameterWertBedeutung/Anmerkung
Signaturalgorithmus, kodiert10RSA
Operationsmodus bei Signatur19RSASSA-PSS [PKCS1]
Verwendung des Signaturalgorithmus6Owner Signing
Hashalgorithmus, kodiert6SHA-256 / SHA-256 [SHA-256]
Verschlüsselungsalgorithmus, kodiert132-Key-Triple-DES
Operationsmodus bei Verschlüsselung2CBC (0-Padding)
SchlüsselartS VSignierschlüssel Chiffrierschlüssel
Schlüssellängegemäß [DK Krypto]
Zertifikatstyp1
2
3		ZKA UN/EDIFACT X.509
Zertifikatsinhaltnicht spezifiziert
+ + +Im Rahmen des Paddingverfahrens RSASSA-PSS wird als ,,Mask Generation Func- +tion" MGF1 verwendet. Beim Signierschlüssel wird ein doppeltes Hashing durchge- +führt. Dies wird durch eine spezielle Ausprägung des ,,Hashalgorithmus, kodiert" ge- +kennzeichnet. + +Als Salt-Länge (Länge des Initialwertes) ist die Länge des Hashwertes zu verwen- +den. + + +## . DDV-1 + +Als Sicherheitsmedium für das Kundensystem ist nur die ec-Karte mit Chip zugelas- +sen. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ParameterWertBedeutung/Anmerkung
Signaturalgorithmus, kodiert1DES
Operationsmodus bei Signatur999Retail-MAC
Verwendung des Signaturalgorithmus6Owner Signing
Hashalgorithmus, kodiert999RIPEMD-160
Verschlüsselungsalgorithmus, kodiert132-Key-Triple-DES
Operationsmodus bei Verschlüsselung2CBC (0-Padding)
SchlüsselartS VSignierschlüssel Chiffrierschlüssel
Schlüssellänge128 Bit
Zertifikatstyp-nicht zulässig
Zertifikatsinhalt-nicht zulässig
Kapitel: BVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite: 14Stand: 18.07.2013Kapitel: Verfahrensbeschreibung
Abschnitt: Allgemeines
+ + +## B.1.1.1 Sicherheitsprofile im Secoder-Applikationsmodus + +Für den Einsatz der folgenden Sicherheitsprofle ist als Chipkartenleser ein Secoder +mindestens in Version 2.1 Voraussetzung. + + +## RAH-7 im Secoder-Applikationsmodus + +Als Sicherheitsmedium für das Kundensystem ist nur die Bankensignaturkarte oder +eine gleichwertige Signaturkarte zugelassen. Als Chipkartenleser ist ein Secoder ab +Version 2.1 zu verwenden. Im Applikationsmodus des Secoders haben Signaturen +z. B. bei Sicherheitsfunktion 811 folgenden Aufbau: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ParameterWertBedeutung
Signaturalgorithmus, kodiert10RSA
Operationsmodus bei Signatur19Signier- und Signaturschlüs- sel - RSASSA- PSS [PKCS1]
Verwendung des Signaturalgorithmus6Owner Signing
Hashalgorithmus, kodiert6
3		Signierschlüssel - SHA-256 / SHA-256 [SHA-256] Signaturschlüssel - SHA- 256 [SHA-256]
Verschlüsselungsalgorithmus, kodiert14AES-256 [AES]
Operationsmodus bei Verschlüsselung18RSAES-PKCS1-v1 5 [PKCS1]
SchlüsselartS
S|V|D|		Signierschlüssel Chiffrierschlüssel Schlüssel für Digitale Signa- turen
Schlüssellängegemäß [DK Krypto]
Zertifikatstyp3X.509
ZertifikatsinhaltEF X509.CH.DSfortgeschritten oder qualifi- ziert abh. von der Sicher- heitsklasse
+ + +Im Rahmen des Paddingverfahrens RSASSA-PSS wird als ,,Mask Generation Func- +tion" MGF1 verwendet. Beim Signierschlüssel wird ein doppeltes Hashing (Software +und Bankensignaturkarte) durchgeführt. Dies wird durch eine spezielle Ausprägung +des ,,Hashalgorithmus, kodiert" gekennzeichnet. + +Als Salt-Länge (Länge des Initialwertes) ist die Länge des Hashwertes zu verwen- +den. Diese Festlegung ist z. B. auch Bestandteil der SECCOS 6 Spezifikation. + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 - Final VersionKapitel: B
Dokument:Security - Sicherheitsverfahren HBCI
Kapitel:VerfahrensbeschreibungStand:Seite:
Abschnitt:Allgemeines18.07.201315
+ + +## RAH-9 im Secoder-Applikationsmodus + +Als Sicherheitsmedium für das Kundensystem ist nur die Bankensignaturkarte oder +eine gleichwertige Signaturkarte zugelassen. Als Chipkartenleser ist ein Secoder ab +Version 2.1 zu verwenden. Im Applikationsmodus des Secoders haben Signaturen +z. B. bei Sicherheitsfunktion 811 folgenden Aufbau: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ParameterWertBedeutung/Anmerkung
Signaturalgorithmus, kodiert10RSA
Operationsmodus bei Signatur19RSASSA-PSS [PKCS1]
Verwendung des Signaturalgorithmus6Owner Signing
Hashalgorithmus, kodiert6SHA-256 / SHA-256 [SHA-256]
Verschlüsselungsalgorithmus, kodiert14AES-256 [AES]
Operationsmodus bei Verschlüsselung18RSAES-PKCS1-v1 5 [PKCS1]
SchlüsselartV SSignierschlüssel Chiffrierschlüssel
Schlüssellängegemäß [DK Krypto]
Zertifikatstypohne
Zertifikatsinhaltnicht spezifiziert
+ + +Im Rahmen des Paddingverfahrens RSASSA-PSS wird als ,,Mask Generation Func- +tion" MGF1 verwendet. Beim Signierschlüssel wird ein doppeltes Hashing (Software +und Bankensignaturkarte) durchgeführt. Dies wird durch eine spezielle Ausprägung +des ,,Hashalgorithmus, kodiert“ gekennzeichnet. + +Als Salt-Länge (Länge des Initialwertes) ist die Länge des Hashwertes zu verwen- +den. Diese Festlegung ist z. B. auch Bestandteil der SECCOS 6 Spezifikation. + + +## B.1.2 Sicherheitsklassen + +Die Sicherheitsklasse gibt für jede Signatur den erforderlichen Sicherheitsdienst an. +Als Sicherheitsdienst gelten derzeit „Authentikation“ und ,Non-Repudiation“. + +Der Sicherheitsdienst ,,Authentikation“ erfordert die Signatur mit der Schlüsselart „S“ +(Schlüssel auf Kundenseite: SK.CH.AUT c/s). Der Sicherheitsdienst „Non-Repudi- +ation" erfordert die Signatur mit der Schlüsselart „D“ (Schlüssel auf Kundenseite: +SK.CH.DS). + +Derzeit sind folgende Sicherheitsklassen zulässig: + + + + + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:Stand: 18.07.2013Kapitel: Verfahrensbeschreibung
16Abschnitt: Allgemeines
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBedeutung
0kein Sicherheitsdienst erforderlich
1Sicherheitsdienst ,,Authentikation“
2Sicherheitsdienst ,,Authentikation" mit fortgeschrittener elektronischer Signatur ge- mäß §2, SigG und optionaler Zertifikatsprüfung unter Verwendung des S-Schlüssels (Schlüssel Sk.CH.AUT c/s)
3Sicherheitsdienst ,,Non-Repudiation" mit fortgeschrittener elektronischer Signatur gemäß §2, SigG und optionaler Zertifikatsprüfung unter Verwendung des DS- Schlüssels (SK.CH.DS)
4Sicherheitsdienst ,,Non-Repudiation" mit fortgeschrittener bzw. qualifizierter elektro- nischer Signatur gemäß §2, SigG und zwingender Zertifikatsprüfung unter Verwen- dung des DS-Schlüssels (SK.CH.DS)
+ + +Zu einem späteren Zeitpunkt kann die Notwendigkeit einer weiteren Sicherheits- +klasse überprüft werden, die qualifizierte Signaturen mit zwingender Zertifikatsprü- +fung erfordert. + +Folgende Zuordnungen von Sicherheitsklassen auf Sicherheitsprofile sind möglich: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
SicherheitsprofilSicherheitsklasse(n)
DDV1
RAH-71, 2, 3, 4
RAH-91,2
RAH-101
RDH-11
RDH-21
RDH-31, 2, 3, 4
RDH-51,2
RDH-61, 2, 3, 4
RDH-71, 2, 3, 4
RDH-81,2
RDH-91,2
RDH-101
+ + +Die Sicherheitsklasse gibt für jeden Geschäftsvorfall den erforderlichen Sicherheits- +dienst an. Signaturen gemäß der Sicherheitsklasse 2 und höher entsprechen den +Anforderungen des Signaturgesetzes und erlauben damit rechtsverbindliche Wil- +lenserklärungen unter der Voraussetzung, dass die außerhalb des HBCI-Protokolls +liegenden Anforderungen (z.B. Anforderungen an die Zertifizierungsinfrastruktur und +an die Endgeräte) ebenfalls erfüllt sind. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionB
Kapitel:VerfahrensbeschreibungStand:Seite:
Abschnitt:Allgemeines18.07.201317
+ + +Jede Signatur, die im Rahmen von HBCI generiert wird, muss der festgelegten Si- +cherheitsklasse entsprechen: + +. Technische Signaturen (Dialoginitialisierung, Dialogendenachricht) erfolgen ge- +nerell mit Sicherheitsklasse 1 (Authentikation) + +• Bei Geschäftsvorfällen kann das Kreditinstitut die Sicherheitsklasse individuell +festlegen (Die Sicherheitsklasse wird dem Kunden in den Bankparameterdaten +des betreffenden Geschäftsvorfalls mitgeteilt) + + +### Hinweis: + +Sicherheitsklassen werden nur in Verbindung mit dem Sicherheitsverfahren HBCI +benutzt. Unterstützt ein Kreditinstitut ausschlieBlich das PIN/TAN-Verfahren, so ist +in das DE ,Sicherheitsklasse' des jeweiligen Geschäftsvorfallparametersegmentes +als Füllwert ,0' einzustellen. Die Sicherheitsklasse hat bei PIN/TAN für die Verarbei- +tung keine Bedeutung und darf vom Kundenprodukt für PIN/TAN nicht ausgewertet +werden. Stattdessen sind bei PIN/TAN die Informationen aus HIPINS für die Festle- +gung benötigter Sicherheitsmerkmale zu verwenden. + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:
18		Stand: 18.07.2013Kapitel: Verfahrensbeschreibung
Abschnitt: Mechanismen
+ + +## B.2 Mechanismen + + +### B.2.1 Elektronische Signatur + +Die Bildung der elektronischen Signatur erfolgt durch die Vorgänge + +. Bildung des Hashwerts + +• Ergänzen des Hashwerts auf eine vorgegebene Länge und + +. Berechnung der elektronischen Signatur über den Hashwert. + +Je nach Sicherheitsverfahren sind die Verarbeitungsschritte jeweils verschieden. + + +### B.2.1.1 Hashing + +Als Hash-Funktion können im Rahmen von HBCI abhängig vom Sicherheitsprofil +entweder RIPEMD-160 [RIPEMD], SHA-1 [SHA-1] oder SHA-256 [SHA-256] einge- +setzt werden. + + +## . RIPEMD-160 + +Der Hash-Algorithmus RIPEMD-160 bildet Eingabe-Bitfolgen beliebiger Länge auf +einen als Bytefolge dargestellten Hash-Wert von 20 Byte (160 Bit) Länge ab. Teil +des Hash-Algorithmus ist das Padding von Eingabe-Bitfolgen auf ein Vielfaches von +64 Byte. Das Padding erfolgt auch dann, wenn die Eingabe-Bitfolge bereits eine +Länge hat, die ein Vielfaches von 64 Byte ist. RIPEMD-160 verarbeitet die Eingabe- +Bitfolgen in Blöcken von 64 Byte Länge. + +Als Initialisierungsvektor dient die binäre Zeichenfolge X'01 23 45 67 89 AB CD EF +FE DC BA 98 76 54 32 10 F0 E1 D2 C3'5. + +◆ SHA-1 + +Der Hash-Algorithmus SHA-1 bildet Eingabe-Bitfolgen beliebiger Länge auf Bytefol- +gen von 20 Byte Länge ab. Teil des Hash-Algorithmus ist das Padding von Eingabe- +Bitfolgen auf ein Vielfaches von 64 Byte. Das Padding erfolgt auch dann, wenn die +Eingabe-Bitfolge bereits eine Länge hat, die ein Vielfaches von 64 Byte ist. SHA-1 +verarbeitet die Eingabe-Bitfolgen in Blöcken von 64 Byte Länge. + + +## . SHA-256 + +Der Hash-Algorithmus SHA-256 bildet Eingabe-Bitfolgen beliebiger Länge auf Byte- +folgen von 32 Byte Länge ab. Teil des Hash-Algorithmus ist das Padding von Ein- +gabe-Bitfolgen auf ein Vielfaches von 64 Byte. Das Padding erfolgt auch dann, +wenn die Eingabe-Bitfolge bereits eine Länge hat, die ein Vielfaches von 64 Byte ist. +SHA-256 verarbeitet die Eingabe-Bitfolgen in Blöcken von 64 Byte Länge. + + +### B.2.1.2 Elektronische Signatur bei DDV (DES-basierend) + + +#### 1. Hashing der Nachricht + +Als Hash-Funktion kann, anhängig vom Sicherheitsprofil RIPEMD-160 oder +SHA-256 eingesetzt werden. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionB
Kapitel:VerfahrensbeschreibungStand:Seite:
Abschnitt:Mechanismen18.07.201319
+ + +## 2. Formatierung des Hashwerts + + +### Formatierung des Hashwerts bei RIPEMD-160 + +Das Padding ist je nach Typ der eingesetzten Chipkarte (Typ 0 oder Typ 1) +unterschiedlich: + +Bei Typ 0-Karten erfolgt das Padding entsprechend der folgenden Abbildung +mit X'00' auf das nächste Vielfache von 8 Byte: + +Byte-Position: + +Padding + + + + + + + + + + + + + +
242120
...
1
0000 00 00Hashwert
+ + +Bei Typ 1-Karten erfolgt das Padding entsprechend der folgenden Abbildung +auf das nächste Vielfache von 8 Byte: Sei der Hashwert = HashL | HashR, +wobei HashL die linken 8 Byte und HashR die rechten 12 Byte des Hashwerts +bezeichnet. + +Byte-Position: + +Padding + + + + + + + + + + + + + + + +
24 2322 ... 1110 98 ... 1
00 80HashR0C 81HashL
+ + +Ob eine Karte vom Typ 0 oder Typ 1 vorliegt, kann anhand der Länge der +Kartenidentifikationsdaten (CID) ermittelt werden. Für Typ 0-Karten hat die +CID eine Länge von 22 Byte, für Typ 1-Karten mindestens eine Länge von +24 Byte. + + +### Formatierung des Hashwerts bei SHA-256 + +Da der Hashwert bei SHA-256 mit 32 Byte bereits ein Vielfaches von 8 dar- +stellt, muss bei diesem Verfahren kein Padding stattfinden. + + +## 3. Berechnung der elektronischen Signatur + +Als Signatur wird ein Retail CBC-MAC gemäß ANSI X9.19 gebildet. Hierzu +wird der gepaddete Hashwert zunächst in 3 Blöcke der Länge 8 Byte aufge- +teilt. Als Zwischenresultat wird ein einfacher CBC-MAC über die ersten 2 +Blöcke berechnet. Als Initialisierungsvektor kommt X'00 00 00 00 00 00 00 +00' zum Einsatz. Dabei verwendet man als Schlüssel die linke Hälfte des +Signierschlüssels. Anschließend erfolgt eine 2-Key-Triple-DES-Verschlüsse- +lung mit dem Signierschlüssel des Kunden (muss beim Kreditinstitut herge- +leitet werden) über die XOR-Summe des Zwischenergebnisses mit dem letz- +ten Nachrichtenblock. Der so erhaltene 8 Byte(=64 bit)-Ausgabeblock ist der +Retail CBC-MAC. + + +### B.2.1.3 Elektronische Signatur bei RAH und RDH (RSA-basierend) + + +#### 1. Hashing der Nachricht + +Als Hash-Funktion kann abhängig vom Sicherheitsprofil entweder RIPEMD- +160, SHA-1 oder SHA-256 eingesetzt werden. + + +#### 2. Formatierung des Hashwerts + +Die Formatierung des Hashwerts erfolgt auf folgende Art und Weise: + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:
20		Stand: 18.07.2013Kapitel: Verfahrensbeschreibung
Abschnitt:
Mechanismen
+ + +ISO 9796-2 + +RDH-2, RDH-3 und RDH-5 + +PKCS#1 V1.5 + +RDH-3, RDH-6 und RDH-8 + +PKCS#1 PSS + +RAH-7, RAH-9 und RAH-10, +RDH-7, RDH-9 und RDH-10 + +ISO 9796:1991 +(Kap. 5.1 - 5.4) + +Übergangsweise für das Altverfahren RDH-1, wobei +der Hashwert wird für die nachfolgende Signaturbil- +dung als Langzahl6 interpretiert (s. auch die Beispiele +in der Anlage zu ISO 9796:1991). + + +#### 3. Berechnung der elektronischen Signatur + +Der Hashwert wird mittels RSA entweder gemäß DIN/ISO 9796-2 (bei RDH- +2, RDH-3 und RDH-5), gemäß PKCS#1 V1.5 (bei RDH-6 und RDH-8) oder +gemäß PKCS#1 PSS (bei RAH-7, RAH-9 und RAH-10 bzw. RDH-7, RDH-9 +und RDH-10) signiert. Übergangsweise ist für das Altverfahren RDH-1 auch +die Signatur gemäß ISO 9796-1 zulässig.7 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: B
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final Version
Kapitel:VerfahrensbeschreibungStand:Seite:
Abschnitt:Mechanismen18.07.201321
+ + +##### B.2.2 Verschlüsselung + +Bei der Verschlüsselung wird für jede Nachricht ein separater Nachrichtenschlüssel +verwendet. Die Verschlüsselung der HBCI-Nutzdaten erfolgt folgendermaßen: + +. Bei RAH-7, RAH-9 und RAH-10 + +Die Verschlüsselung erfolgt mittels AES-256 gemaß [AES]. Der Nachrichten- +schlüssel wird mittels RSA (RAH) chiffriert und mit der verschlüsselten Nachricht +mitgeliefert. + +. Sonst: + +Die Verschlüsselung erfolgt mittels 2-Key-Triple-DES gemäß ANSI X3.92. Der +Nachrichtenschlüssel wird entweder mittels 2-Key-Triple-DES (DDV) oder RSA +(RDH) chiffriert und mit der verschlüsselten Nachricht mitgeliefert. + + +![](figures/35.1) + + +Der Nachrichtenschlüssel muss für jede Nachricht eines Dialoges +individuell verschieden sein. Dies muss gewährleistet werden, in- +dem das sendende System den Nachrichtenschlüssel dynamisch +generiert. + + +![](figures/35.2) + + +Sollte bei der Verarbeitung des Nachrichtenschlüssels, insbesonde- +re beim Padding ein Fehler auftreten, so sind außer dem negativen +Prüfergebnis selbst keine weiteren Details an die aufrufende Funkti- +on zurückzugeben, um keine Rückschlüsse über die Art des Fehlers +und damit ggf. auf den Schlüssel selbst zu geben. + + +###### B.2.2.1 Verschlüsselung bei RAH-7, RAH-9 und RAH-10: + +Die Verschlüsselung und Entschlüsselung erfolgt bei den RAH-Verfahren in den fol- +genden drei Schritten: + +1\. Der Sender erzeugt eine Zufallszahl als Nachrichtenschlüssel. + +2\. Dieser Nachrichtenschlüssel wird verwendet, um die Daten mittels AES im CBC +Modus gemäß ISO 10116 (ANSI X3.106) zu verschlüsseln (vgl. Abbildung 1). +Das Padding der Nachricht erfolgt gemäß den Vorgaben des Kryptokatalogs der +Deutschen Kreditwirtschaft (vgl. [DK Krypto], Kapitel 4.3.1) (vgl.Abbildung 2 und +Abbildung 3). + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:
22		Stand: 18.07.2013Kapitel: Verfahrensbeschreibung
Abschnitt: Mechanismen
+ + +###### ZKA-Padding" (vgl. [DK Krypto], Kapitel 4.3.1 auf S. 20): + +Für die Verarbeitung von Daten durch einen kryptographischen Algorithmus kann deren Dar- +stellung als Folge von Byte-Blocken mit einer vorgegebenen Länge L erforderlich sein. Das +ZKA-Padding ist eine Methode zur Formatierung des letzten, möglicherweise unvollständi- +gen Datenblocks auf die Länge von L Byte. Die den Daten zugehörigen Bytes können ein- +deutig von den durch das Padding hinzugefügten Bytes unterschieden werden. + +An die Daten M wird zunächst das Byte '80' angehängt. Falls M || '80' nun eine Byte-Länge +besitzt, die kein Vielfaches von L ist, werden weitere Bytes '00' angehängt, bis das Ergebnis +der Operation eine Byte-Länge besitzt, die ein Vielfaches von L ist. + +ZKA-Padding (M) = M || '80' || '00' ||...|| '00' + +Verkettung bis zur +Gesamtlänge der Byte-Folge +als Vielfaches von L Byte +(hier: AES-Blocklänge = 16 Byte) + + +Abbildung 1: Nachrichtenverschlüsselung mit AES im CBC-Mode für RAH-Verfahren + +![Klartextblock 1 Klartextblock 2 Klartextblock n ZKA-Padding + + + Initialisierungsvektor=0 Schlüssel verschlüsseln AES Schlüssel verschlüsseln AES Schlüssel verschlüsseln AES 127 0 127 0 127 0 verschlüsselter Textblock 1 verschlüsselter Textblock 2 verschlüsselter Textblock n](figures/36.1) + + +3\. Der aktuelle Nachrichtenschlüssel wird mit dem öffentlichen Schlüssel des Emp- +fängers chiffriert. Da die Länge des Nachrichtenschlüssels bei AES nur 32 Byte, +d.h. 256 Bit beträgt, muss er auf die Moduluslänge des verwendeten öffentlichen +Chiffrierschlüssels ergänzt werden. Das Padding wird abhängig vom Sicherheits- +profil auf unterschiedliche Art und Weise vorgenommen, wie in den folgenden +Abbildungen gezeigt. + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: B
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final Version
Kapitel:VerfahrensbeschreibungStand:Seite:
Abschnitt:Mechanismen18.07.201323
+ + +Abbildung 2: Verschlüsselung bei RAH-7 und RAH-9 + +![255 0 Zufallszahl = Nachrichtenschlüssel FinTS-Nachricht (Klartext) ZKA-Padding Initialisierungsvektor=0 1535<=n<=\\[DK Krypto\\]-1 0 Padn(Nachrichtenschlüssel) Pad=PKCS#1 AES CBC Mode RSA 1535<=n<=\\[DK Krypto\\]-1 Chiffrierschlüssel* 0 * Öffentlicher Chiffrierschlüssel des Partners 1535<=n<=\\[DK Krypto\\]-1 0 Nachrichtenschlüssel (chiffriert) FinTS-Nachricht (chiffriert) \\[DK Krypto\\]: In \\[DK Krypto\\] empfohlene maximale Schlüssellänge](figures/37.1) + + +Abbildung 3: Verschlüsselung bei RAH-10 + +![255 0 Zufallszahl = Nachrichtenschlüssel FinTS-Nachricht (Klartext) ZKA-Padding Initialisierungsvektor=0 1535<=n<=\\[DK Krypto\\]-1 0 Padn(Nachrichtenschlüssel) Pad=Zero AES CBC Mode RSA 1535<=n<=\\[DK Krypto\\]-1 0 Chiffrierschlüssel* * Öffentlicher Chiffrierschlüssel des Partners 1535<=n<=\\[DK Krypto\\]-1 0 Nachrichtenschlüssel (chiffriert) FinTS-Nachricht (chiffriert) \\[DK Krypto\\]: In \\[DK Krypto\\] empfohlene maximale Schlüssellänge](figures/37.2) + + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite: 24Stand: 18.07.2013Kapitel: Verfahrensbeschreibung
Abschnitt: Mechanismen
+ + +####### B.2.2.2 Verschlüsselung bei RDH und DDV: + +Die ersten zwei Schritte sind für die beiden Verfahren RDH und DDV identisch: + +1\. Der Sender erzeugt eine Zufallszahl als Nachrichtenschlüssel und stellt ungerade +Parität sicher. Bei der Auswahl der Zufallszahl ist darauf zu achten, dass keiner +der folgenden schwachen oder halbschwachen Schlüssel9 gewählt wird (vgl. Ka- +pitel B.3.1.1). + +Die schwachen Schlüssel des DES-Algorithmus: + +X'01 01 01 01 01 01 01 01' +X' FE FE FE FE FE FE FE FE' +X' 1F 1F 1F 1F 0E 0E OE OE' +X'EO EO EO E0 F1 F1 F1 F1' + +Die halbschwachen Schlüssel des DES-Algorithmus: + +X' 01 FE 01 FE 01 FE 01 FE' +X' FE 01 FE 01 FE 01 FE 01' +X' 1F E0 1F E0 OE F1 0E F1' +X'E0 1F E0 1F F1 0E F1 0E' +X' 01 E0 01 E0 01 F1 01 F1' +X'E0 01 E0 01 F1 01 F1 01' +X' 1F FE 1F FE OE FE OE FE' +X'FE 1F FE 1F FE 0E FE OE' +X'01 1F 01 1F 01 0E 01 0E' +X' 1F 01 1F 01 0E 01 0E 01' +X'EO FE EO FE F1 FE F1 FE' +X'FE E0 FE E0 FE F1 FE F1' + +2\. Dieser Nachrichtenschlüssel wird verwendet, um die Daten mittels 2-Key-Triple- +DES im CBC Modus gemäß ISO 10116 (ANSI X3.106) zu verschlüsseln (vgl. +Abbildung 4). Das Padding der Nachricht erfolgt oktettorientiert gemäß ISO +10126 (ANSI X9.23), der Initialisierungsvektor ist X'00 00 00 00 00 00 00 00' (vgl. +Abbildung 5 und Abbildung 6). + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionB
Kapitel:VerfahrensbeschreibungStand:Seite:
Abschnitt:Mechanismen18.07.201325
+ + +Abbildung 4: Nachrichtenverschlüsselung generell mit 2-Key-Triple-DES im CBC- +Mode für RDH und DDV + +![Klartextblock 1 Klartextblock 2 Klartextblock n + + + Schlüssel 1 verschlüsseln DES Schlüssel 1 verschlüsseln DES Schlüssel 1 verschlüsseln DES Initialisierungsvektor Schlüssel 2 entschlüsseln DES Schlüssel 2 entschlüsseln DES Schlüssel 2 entschlüsseln DES Schlüssel 1 verschlüsseln DES Schlüssel 1 verschlüsseln DES Schlüssel 1 verschlüsseln DES 63 0 63 0 63 0 verschlüsselter Textblock 1 verschlüsselter Textblock 2 verschlüsselter Textblock n Schlüssel 1: linke Schlüsselhälfte Schlüssel 2: rechte Schlüsselhälfte](figures/39.1) + + +Die weitere Verarbeitung ist bei DDV und RDH unterschiedlich: + + +####### B.2.2.2.1 Verschlüsselung bei DDV (DES-basierend) + +3\. Der aktuelle Nachrichtenschlüssel für die Chiffrierung der Daten wird vom Kun- +denprodukt mit dem kundenindividuellen Chiffrierschlüssel der Chipkarte mittels +2-Key-Triple-DES im ECB-Mode (ISO 10116) verschlüsselt (vgl. Abbildung 5 und +Abbildung 6). + +Aufgrund vorgegebener Verfahren bei der ZKA-Chipkarte wird zum Chiffrieren +und Dechiffrieren des Nachrichtenschlüssels, unabhängig von der Übertragungs- +richtung, kundensystemseitig immer die Routine ,Encrypt“ benutzt, kreditinstituts- +seitig immer die Routine „Decrypt" (vgl. Kapitel C.2.5.2). + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:
26		Stand:
18.07.2013		Kapitel: Verfahrensbeschreibung
Abschnitt:
Mechanismen
+ + +Abbildung 5: Verschlüsselung bei 2-Key-Triple-DES im DDV-Verfahren + +![127 0 Zufallszahl = Nachrichtenschlüssel FinTS-Nachricht (Klartext) Padding nach ANSI X9.23 Initialisierungsvektor=0 3DES CBC Mode ECB Mode 3DES 127 0 Chiffrierschlüssel Kundensystem : Encrypt Kreditinstitut : Decrypt 127 0 Nachrichtenschlüssel (chiffriert) FinTS-Nachricht (chiffriert)](figures/40.1) + + +Abbildung 6: Entschlüsselung bei 2-Key-Triple-DES im DDV-Verfahren + +![127 0 Nachrichtenschlüssel (chiffriert) FinTS-Nachricht (chiffriert) Padding nach ANSI X9.23 Initialisierungsvektor=0 ECB Mode 3DES 127 0 Chiffrierschlüssel Kundensystem : Encrypt Kreditinstitut : Decrypt 127 0 Nachrichtenschlüssel 3DES CBC Mode FinTS-Nachricht (Klartext)](figures/40.2) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionB
Kapitel:VerfahrensbeschreibungStand:Seite:
Abschnitt:Mechanismen18.07.201327
+ + +####### B.2.2.2.2 Verschlüsselung bei RDH (RSA-basierend) + +3\. Der aktuelle Nachrichtenschlüssel wird mit dem öffentlichen Schlüssel des Emp- +fängers chiffriert. Da die Länge des Nachrichtenschlüssels nur 16 Byte, d.h. 128 +Bit bei 2-Key-Triple-DES beträgt, muss er auf die Moduluslänge des verwende- +ten öffentlichen Chiffrierschlüssels ergänzt werden. Das Padding wird abhängig +vom Sicherheitsprofil auf unterschiedliche Art und Weise vorgenommen, wie in +den folgenden Abbildungen gezeigt. + + +Abbildung 7: Verschlüsselung bei 2-Key-Triple-DES im RDH-Verfahren + +![127 0 Zufallszahl = Nachrichtenschlüssel FinTS-Nachricht (Klartext) Padding nach ANSI X9.23 Initialisierungsvektor=0 3DES CBC Mode RSA 127 0 Chiffrierschlüssel Kundensystem Kreditinstitut : Encrypt : Decrypt 127 0 Nachrichtenschlüssel (chiffriert) FinTS-Nachricht (chiffriert)](figures/41.1) + + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:
28		Stand: 18.07.2013Kapitel: Verfahrensbeschreibung
Abschnitt:
Mechanismen
+ + +Abbildung 8: Entschlüsselung bei 2-Key-Triple-DES im RDH-Verfahren + +![127 0 Nachrichtenschlüssel (chiffriert) FinTS-Nachricht (chiffriert) Padding nach ANSI X9.23 Initialisierungsvektor=0 RSA 127 0 Chiffrierschlüssel Kundensystem Kreditinstitut : Encrypt : Decrypt 127 0 Nachrichtenschlüssel 3DES CBC Mode FinTS-Nachricht (Klartext)](figures/42.1) + + +Abbildung 9: Verschlüsselung bei RDH-1 + +![127 0 Zufallszahl = Nachrichtenschlüssel FinTS-Nachricht (Klartext) Padding nach ANSI X9.23 Initialisierungsvektor=0 767 127 0 00..00 Nachrichtenschlüssel Padding >707 0 3DES CBC Mode Chiffrierschlüssel* RSA 767 >707 0 00..00 Chiffrierschlüssel* Padding * Öffentlicher Chiffrierschlüssel des Partners 767 0 Nachrichtenschlüssel (chiffriert) FinTS-Nachricht (chiffriert)](figures/42.2) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionB
Kapitel:VerfahrensbeschreibungStand:Seite:
Abschnitt:Mechanismen18.07.201329
+ + +Abbildung 10: Verschlüsselung bei RDH-3 und RDH-5 + +![127 0 Zufallszahl = Nachrichtenschlüssel FinTS-Nachricht (Klartext) Padding nach ANSI X9.23 Initialisierungsvektor=0 1023<=n<=2047 0 Padn(Nachrichtenschlüssel) Pad=PKCS#1 3DES CBC Mode RSA 1023<=n<=2047 0 Chiffrierschlüssel* * Öffentlicher Chiffrierschlüssel des Partners 1023<=n<=2047 0 Nachrichtenschlüssel (chiffriert) FinTS-Nachricht (chiffriert)](figures/43.1) + + +Abbildung 11: Verschlüsselung bei RDH-6 bis RDH-9 + +![127 0 Zufallszahl = Nachrichtenschlüssel FinTS-Nachricht (Klartext) Padding nach ANSI X9.23 Initialisierungsvektor=0 1535<=n<=\\[DK Krypto\\]-1 0 Padn(Nachrichtenschlüssel) Pad=PKCS#1 3DES CBC Mode RSA 1535<=n<=\\[DK Krypto\\]-1 0 Chiffrierschlüssel* * Öffentlicher Chiffrierschlüssel des Partners 1535<=n<=\\[DK Krypto\\]-1 0 Nachrichtenschlüssel (chiffriert) FinTS-Nachricht (chiffriert) \\[DK Krypto\\]: In \\[DK Krypto\\] empfohlene maximale Schlüssellänge](figures/43.2) + + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:
30		Stand: 18.07.2013Kapitel: Verfahrensbeschreibung
Abschnitt:
Mechanismen
+ + +Abbildung 12: Verschlüsselung bei RDH-10 + +![127 0 Zufallszahl = Nachrichtenschlüssel FinTS-Nachricht (Klartext) Padding nach ANSI X9.23 Initialisierungsvektor=0 1535<=n<=4095 0 Padn(Nachrichtenschlüssel) Pad=Zero 3DES CBC Mode RSA 1535<=n<=4095 0 Chiffrierschlüssel* * Öffentlicher Chiffrierschlüssel des Partners 1535<=n<=4095 0 Nachrichtenschlüssel (chiffriert) FinTS-Nachricht (chiffriert)](figures/44.1) + + +##### B.2.3 Sicherheitsmedien beim Kundenprodukt + +Bei Verwendung des symmetrischen Verfahrens (DDV) muss eine vom Kreditinstitut +ausgegebene ZKA-Chipkarte eingesetzt werden, welche die Berechnung der kryp- +tographischen Funktionen so durchführt, dass die kartenindividuellen Schlüssel +niemals die Chipkarte verlassen. + +Werden asymmetrische Verfahren (RAH oder RDH) eingesetzt, so kann als Sicher- +heitsmedium eine vom Kreditinstitut ausgegebene RSA-Chipkarte oder eine Schlüs- +seldatei dienen.10 Falls eine Chipkarte zum Einsatz kommen soll, wird die in Kap. +C.1 beschriebene Bankensignaturkarte empfohlen. Auf dem Sicherheitsmedium +wird unter anderem der private Schlüssel des Kunden gespeichert. Es ist aber auch +möglich, öffentliche Schlüssel des Kreditinstitutes darauf abzulegen oder aber im +Falle einer Chipkarte die kryptographischen Operationen damit durchzuführen. Bei +Einsatz einer RSA-Chipkarte müssen die geheimen Daten (z.B. private Schlüssel, +Passworte) gegen unberechtigtes Auslesen geschützt sein. + + +![](figures/44.2) + + +Es ist zwingend erforderlich, die Daten auf dem Sicherheitsmedium +(kryptographisch) zu schützen. Speziell ist im Rahmen der Speiche- +rung der Schlüsselpaare in der Schlüsseldatei sicherzustellen, dass +die Daten unter Einbeziehung eines Passwortes (Banking-PIN o.ä.) +verschlüsselt werden und der Zugriff auf die verschlüsselten Daten +nur über die manuelle Eingabe des entsprechenden Passwortes +möglich ist. + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 - Final VersionKapitel: B
Dokument:Security - Sicherheitsverfahren HBCI
Kapitel:VerfahrensbeschreibungStand:Seite:
Abschnitt:Abläufe18.07.201331
+ + +### B.3 Abläufe + + +#### B.3.1 Schlüsselverwaltung + +Bei der Schlüsselverwaltung muss zwischen der Verwendung von symmetrischen +Schlüsseln für DDV und asymmetrischen Schlüsseln für RAH und RDH unterschie- +den werden. + +Gemeinsam gültig sind hingegen für beide Verfahren die verwendeten Schlüsselar- +ten, Schlüsselnamen und die Generierung von Nachrichtenschlüsseln. + + +#### B.3.1.1 Gemeinsam verwendete Verfahren zur Schlüsselverwaltung + + +##### ◆ Schlüsselarten + +Bei den Sicherheitsverfahren DDV-1, RAH-9, RAH-10, RDH-1, RDH-2, RDH-5, +RDH-8, RDH-9 und RDH-10 können Kunde und Kreditinstitut über zwei Schlüssel +bzw. Schlüsselpaare verfügen: + +• einen Signierschlüssel bzw. -schlüsselpaar + +• einen Chiffrierschlüssel bzw. -schlüsselpaar + +Der Signierschlüssel wird zum Unterzeichnen von Transaktionen verwendet, wäh- +rend der Chiffrierschlüssel zum Verschlüsseln von Nachrichten dient. + +Bei den Verfahren RAH-7, RDH-3, RDH-6 und RDH-7 können Kunde und Kreditin- +stitut über bis zu drei Schlüssel bzw. Schlüsselpaare verfügen: + +• einen Schlüssel für digitale Signaturen + +• einen Signierschlüssel + +• einen Chiffrierschlüssel + +Abhängig von der Personalisierung der Chipkarte können Signier- und Chiffrier- +schlüssel identisch sein. + +Der Signierschlüssel und der DS-Schlüssel werden zum Unterzeichnen von Trans- +aktionen verwendet, während der Chiffrierschlüssel zum Verschlüsseln von Nach- +richten dient. Falls kreditinstitutsseitig nur Geschäftsvorfälle angeboten werden, für +die gemäß Bankparameterdaten die Unterzeichnung mit dem Signierschlüssel aus- +reichend ist, ist der DS-Schlüssel nicht erforderlich. + + +![](figures/45.1) + + +Bei Verwendung von Schlüsseldateien (Sicherheitsprofil RAH,10, +RDH-1, RDH-2 und RDH-10) wird dringend empfohlen, dass ge- +trennte Signier- und Chiffrierschlüssel zum Einsatz kommen. + + +##### ◆ Schlüsselnamen + +Der Schlüsselname bei den 2-Key-Triple-DES- und RSA-Schlüsseln setzt sich aus +den folgenden alphanumerischen Komponenten zusammen: + +• Ländercode +(max. 3 Byte, es wird gemäß ISO 3166 der numerische Ländercode verwendet) + +. Kreditinstitut + +(max. 30 Byte, normalerweise Bankleitzahl, vgl. [Formals], Kapitel II.5.3.2) + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:
32		Stand: 18.07.2013Kapitel: Verfahrensbeschreibung
Abschnitt: Abläufe
+ + +. Benutzerkennung + +(max. 30 Byte, kann vom Kreditinstitut festgelegt werden, vgl. [Formals], Kapitel +III.1.1) + +• Schlüsselart + +(1 Byte, D: DS-Schlüssel; S: Signierschlüssel; V: Chiffrierschlüssel) + +• Schlüsselnummer +(max. 3 Byte) + +. Versionsnummer +(max. 3 Byte) + +Falls kein öffentlicher Schlüssel des Kreditinstituts vorliegt, so ist als Versions- +nummer der Wert ,,999" einzustellen. Damit wird kreditinstitutsseitig auf den aktuell +gültigen Schlüssel referenziert (Ein Kreditinstitut kann während einer Übergangszeit +evtl. mehrere Schlüssel bis zu einem Verfallsdatum vorhalten. Aktuell gültig ist je- +weils der neueste Schlüssel). + + +##### ◆ Generierung von Nachrichtenschlüsseln + +Zur Chiffrierung von Nachrichten wird ein dynamisch erzeugter Nachrichtenschlüs- +sel verwendet, der folgendermaßen gebildet wird: + + +##### RAH-Verfahren: + +1\. Generieren einer 32 Byte langen Zufallszahl + + +##### RDH-Verfahren: + +1\. Generieren einer 16 Byte langen Zufallszahl + +2\. Erzeugung von ungerader Parität (optional) + +3\. Testen, ob erste und zweite Schlüsselhälfte unterschiedlich (optional) + +4\. Testen nach schwachen und semi-schwachen Schlüsseln (optional) (s. Kap. +B.2.2) + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 - Final VersionKapitel: B
Dokument:Security - Sicherheitsverfahren HBCI
Kapitel:VerfahrensbeschreibungStand:Seite:
Abschnitt:Abläufe18.07.201333
+ + +#### B.3.1.2 Symmetrische Schlüssel für DDV + +Für Verschlüsselung und MAC-Berechnung werden, wie unter VI.3.1.1 beschrieben, +unterschiedliche Schlüssel für Signatur und Chiffrierung verwendet. + + +#### B.3.1.2.1 Schlüsselgenerierung + +Beim symmetrischen Verfahren (DDV) sind zur Bildung eines kundenindividuellen +Schlüssels beim Kreditinstitut zwei Voraussetzungen zu erfüllen: + +· Generierung eines ZKA-weit eindeutigen 2-Key-Triple-DES-Masterkey pro +Schlüsselart und Ablegen in einer sicheren Umgebung (Hardwareeinrichtung) als +Key Generating Key (KGK). + +. Herleiten des jeweiligen kundenindividuellen Schlüssels mittels CID-Feld (Card- +holders Information Data = Feld ,,EF_ID") auf der ZKA-Chipkarte und entspre- +chendem 2-Key-Triple-DES-Masterkey. + + +##### . Generierung eines 2-Key-Triple-DES-Masterkey: + +Für die Generierung von ZKA-weit einheitlichen 2-Key-Triple-DES-Masterkeys (KGK += Key Generating Key), die als Basis für die Herleitung der kundenindividuellen Sig- +nier- und Chiffrierschlüsseln dienen, ist folgendes Verfahren, analog der ZKA- +Chipkarte, zu verwenden: + +1\. Generieren einer 16 Byte langen Zufallszahl + +2\. Erzeugung von ungerader Parität (optional) + +3\. Testen, ob erste und zweite Schlüsselhälfte unterschiedlich + +4\. Testen nach schwachen und semi-schwachen Schlüsseln (s. Kap. B.2.2) + + +##### ◆ Herleitung von Kartenschlüsseln: + +Zur eindeutigen Herleitung der symmetrischen Signier- und Chiffrierschlüssel wird +das Feld ,,EF_ID" im Master File (MF) der ZKA-Chipkarte (Cardholders Information +Data (CID) ohne Padding) zusätzlich übertragen (s. DEG „Sicherheitsidentifikation, +Details"). + +Ein kartenindividueller Schlüssel KK von 16 Byte Länge wird aus + +. KGK (Key Generating Key, 16 Byte) + +· CID (vollständiger Inhalt von EF_ID, mit X'00' auf das nächste Vielfache von 8 +Byte Länge aufgefüllt) und + +· dem öffentlich bekannten Initialwert I = X'52 52 52 52 52 52 52 52 25 25 25 25 25 +25 25 25' (16 Byte) + +zu + +KK = P(d * KGK(H(I, CID))) + +berechnet. + +Hierbei bezeichnen + +. 'P' die Funktion "Parity Adjustment" auf ungerade Parität, die wie folgt definiert +ist: + +Sei b1,..,b8 die Darstellung eines Byte als Folge von 8 bit. Dann setzt P das nied- +rigstwertige bit b8 jedes Byte auf ungerade Parität, d.h. b8 wird in jedem Byte so +gesetzt, dass es eine ungerade Anzahl von 1 enthält. + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:
34		Stand: 18.07.2013Kapitel: Verfahrensbeschreibung
Abschnitt: Abläufe
+ + +. 'd * KGK' die 2-Key-Triple-DES-Entschlüsselung im ECB-Mode (ISO 10116) mit +dem Schlüssel KGK. + +. 'H' die in ISO 10118-2 definierte Hash-Funktion. + + +#### B.3.1.2.2 Initiale Schlüsselverteilung + +Die initiale Schlüsselverteilung erfolgt implizit mit der Verteilung der Chipkarte. + + +#### B.3.1.2.3 Schlüsseländerungen + +Beim symmetrischen Verfahren (DDV) ist wegen der Verknüpfung mit der Chipkarte +auf elektronische Weise keine Änderung einzelner kartenindividueller Schlüssel +möglich. Im Falle einer vermuteten Kompromittierung muss daher ein Kartenaus- +tausch oder ein Ersatz aller Schlüssel und des Feldes „EF_ID“ erfolgen. + +Bei einer Schlüsseländerung wird die Signatur-ID (Sequenzzähler der Chipkarte) auf +1 zurückgesetzt. Die im Kreditinstitut geführte Liste der eingereichten bzw. noch +nicht eingereichten Signatur-IDs (s. Doppeleinreichungskontrolle) wird gelöscht. + + +#### B.3.1.2.4 Schlüsselverteilung nach Kompromittierung + +Die Schlüsselverteilung nach einer Kompromittierung erfolgt ebenfalls mittels +Vergabe einer neuen Chipkarte bzw. Ersatz aller Schlüssel und des EF-ID-Feldes. +Die alte Chipkarte bzw. deren Schlüssel werden gesperrt. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionB
Kapitel:VerfahrensbeschreibungStand:Seite:
Abschnitt:Abläufe18.07.201335
+ + +#### B.3.1.3 Asymmetrische Schlüssel für RAH und RDH + +Grundsätzlich können Kunde und Kreditinstitut beim asymmetrischen Verfahren +(RAH und RDH) über maximal drei Schlüsselpaare verfügen: + +• ein Signierschlüsselpaar + +• ein Chiffrierschlüsselpaar + +• ein Schlüsselpaar für die Erzeugung Digitaler Signaturen (DS) + +Der Signierschlüssel sowie der DS-Schlüssel werden zum Unterzeichnen von Nach- +richten verwendet, während der Chiffrierschlüssel zum Verschlüsseln von Nachrich- +ten dient (vgl. Kapitel B.1.1). + +Falls ein Kreditinstitut seine Nachrichten nicht signiert, kann es auf das Signier- +Schlüsselpaar verzichten. + + +#### B.3.1.3.1 Schlüsselgenerierung + +Die Schlüsselpaare des Kunden sind vom Kundenprodukt bzw. von der Chipkarte +zu erzeugen. Die Schlüsselpaare des Kreditinstituts sind vom Kreditinstitut zu er- +zeugen. Die privaten Schlüssel sind jeweils geheim zu halten. + +Die Schlüsselgenerierung hat gemäß dem folgenden Ablauf stattzufinden:11 + +1\. Es wird ein konstanter öffentlicher Exponent e und ein für jeden Kunden individu- +eller Modulus n für jedes eingesetzte RSA-Schlüsselsystem verwendet. + +2\. Der konstante öffentliche Exponent e wird auf die 4. Fermat'sche Primzahl fest- +gelegt: e = 216 + 1 + +3\. Der Modulus n eines jeden RSA-Schlüsselsystems hat eine Länge von N Bit. Es +sind keine führenden 0-Bits erlaubt, so dass auf jeden Fall gilt: 2N-1 ≤ n < 2N + +4\. Der Zielwert für N ist bei RDH-1 768, wobei eine aus der Suche nach starken +Primzahlen resultierende Unterschreitung dieses Wertes um maximal 60 Bit zu- +lässig ist. Bei RDH-2, RDH-3 und RDH-5 liegt der Zielwert für N zwischen 1024 +und 2048. Bei RAH-7, RAH-9 und RAH-10 sowie RDH-6, RDH-7, RDH-8, RDH-9 +und RDH-10 ergibt sich der Zielwert für N gemäß den Empfehlungen aus [DK +Krypto]. + + +![](figures/49.1) + + +Schlüsselgenerierung bei RAH10 und RDH-10: + +Das Kundensystem muss sicher stellen, dass die Schlüssellänge +eines neu generierten Schlüsselpaares des Kunden gleich der +Länge des öffentlichen Signierschlüssels des Instituts ist, falls +das Institut Institutssignaturen unterstützt. Anderenfalls ist die +Länge des Chiffirierschlüssels maßgebend. + +5\. n ist das Produkt zweier großer, zufällig ausgewählter Primzahlen p und q. Fol- +gende Anforderungen werden an die Faktoren p und q gestellt: + +· p hat eine vorher festgelegte minimale Länge + + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:
36		Stand: 18.07.2013Kapitel: Verfahrensbeschreibung
Abschnitt:
Abläufe
+ + +• p - 1 hat einen großen Primteiler12 r + +• p + 1 hat einen großen Primteiler s + +• r - 1 hat einen großen Primteiler + +Die entsprechenden Forderungen werden an q gestellt. + +Die Längen von p und q sollen sich um höchstens 12 Bits unterscheiden. + +Bei der Wahl von p und q ist sicherzustellen, dass e kein Primfaktor von p -1 o- +der q - 1 ist. + + +#### B.3.1.3.2 Behandlung von Zertifikaten + +In FinTS ist die Verwendung von Zertifikaten durch die vorgesehenen Elemente un- +terstützt, es existieren jedoch keine Prozesse für das Zertifikatsmanagement. Diese +sollen zu einem späteren Zeitpunkt auf Basis einer standardisierten Zertifizierungs- +infrastruktur übernommen werden. + +Folgende Festlegungen gelten für die Belegung der Zertifikatsfelder in den FinTS- +Segmenten: + + +##### 1. Allgemein + +Bei Verwendung des Signaturschlüssels (D-Schlüssel) wird grundsätzlich in al- +len Nachrichten ein Zertifikat im Signaturkopf mitgeschickt. + +Bei Verwendung des Authentifikationsschlüssels (S-Schlüssel) kann ein Zertifi- +kat in den Signaturkopf eingestellt werden. + +Im Verschlüsselungskopf kann ebenfalls ein Zertifikat eingestellt werden. +Ggf. dort eingestellte Zertifikate können vom Institut ignoriert werden. + + +##### 2. Erstmalige Übermittlung Kundenschlüssel bzw. Schlüsseländerung + +Bei der Erstmaligen Übermittlung der Kundenschlüssel bzw. bei der Schlüsse- +länderung wird grundsätzlich der Authentifikationsschlüssel (S-Schlüssel) und +wahlweise das zugehörige Zertifikat verwendet. Das Zertifikat wird nur in das +vorgesehene Element im Geschäftsvorfall (HKSAK bzw. HKISA) eingestellt +(nicht in den Signaturkopf). + + +## 3. Signaturkarten-Profil mit drei unterschiedlichen Schlüsseln + +Wenn ein Signaturkarten-Profil mit 3 unterschiedlichen Schlüsseln verwendet +wird, muss bei der Erstmaligen Übermittlung der Kundenschlüssel bzw. der +Schlüsseländerung auch die Möglichkeit bestehen, das Zertifikat für den eige- +nen Verschlüsselungsschlüssel im jeweiligen Geschäftsvorfall (HKSAK bzw. +HKISA) mitzuschicken. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: B
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final Version
Kapitel:VerfahrensbeschreibungStand:Seite:
Abschnitt:Abläufe18.07.201337
+ + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel
9351Zertifikat noch nicht gültig
9352Zertifikat zurückgezogen bzw. gesperrt
9353Zertifikatssignatur falsch
9354Zertifizierungsinstanz (Herausgeber) nicht akzeptiert
9355Fehler im Zertifikatsaufbau
9356Zertifikatstyp nicht akzeptiert
+ + +### B.3.1.3.3 Initiale Schlüsselverteilung + +Der Kunde benötigt für das Einrichten eines neuen Zugangs folgende Initialinfor- +mationen: + +. seine Benutzerkennung + +. Informationen zum Kommunikationszugang + +Die Übermittlung dieser Informationen ist auf folgenden Wegen denkbar: + +· Schriftstück des Kreditinstitutes (Benutzerkennung und Zugangsdaten müssen +manuell vom Kunden eingegeben werden) + +· Schlüsseldatei des Kreditinstitutes mit folgendem Inhalt: + +\- Segment HIUPA der UPD inkl. Benutzerkennung + +\- Aktuelle Version der Zugangsdatenbank des jeweiligen Verbandes bzw. Seg- +ment HIKOM mit den Kommunikationszugangsdaten des jeweiligen Instituts + +. Chipkarte des Kreditinstitutes, die die Kommunikationszugangsdaten in der Ap- +plikation EF_NOTEPAD enthält. + +Zu Beginn muss ein gegenseitiger Austausch der öffentlichen Schlüssel von Kunde +und Kreditinstitut erfolgen. Zukünftig soll dieser Austausch durch eine Anforderung +der Zertifikate bei den jeweiligen Zertifizierungsinstanzen erfolgen. Dieser Prozess +findet auBerhalb des HBCI-Protokolls statt und wird daher hier nicht näher beschrie- +ben. Übergangsweise kann der Schlüsselaustausch auch im Rahmen eines HBCI- +Dialoges erfolgen. + +Hierzu ist folgender Ablauf vorgesehen: + +1\. Das Kreditinstitut übermittelt seinen öffentlichen Chiffrierschlüssel an den Kun- +den. Falls es Nachrichten signiert, übermittelt es ebenfalls seinen öffentlichen +Signierschlüssel. Hierzu gibt es zwei Möglichkeiten: + +· Zusenden bzw. Aushändigung der Schlüssel und anderer relevanter Daten auf +einem Medium (z.B. Schlüsseldatei13, Chipkarte) bei Vertragseröffnung. + +Falls dem Kunden eine Schlüsseldatei zugesendet wird, hat diese folgende Da- +ten zu enthalten: + + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:
38		Stand: 18.07.2013Kapitel: Verfahrensbeschreibung
Abschnitt:
Abläufe
+ + +\- Datei mit bis zu drei Segmenten vom Typ HIISA, die jeweils einen öffent- +lichen Schlüssel des Kreditinstitutes enthalten + +\- BPD des Kreditinstitutes + +· Übertragung der Schlüssel beim Erstzugang + +(1) Der Kunde fordert die öffentlichen Schlüssel und die BPD mit Hilfe der +Key-Management-Nachricht ,,Erstmalige Anforderung der Schlüssel des +Kreditinstituts" (s. Kap. B.6.2.1) an. Diese Nachricht ist weder signiert +noch chiffriert. + +(2) Der weitere Ablauf ist abhängig davon, ob das Kreditinstitut seine Ant- +wortnachrichten signiert. + +Fall A: Das Kreditinstitut signiert + +Der Kunde erhält die öffentlichen Schlüssel des Kreditinstituts zu- +rückgemeldet. Während die Authentizität des Chiffrierschlüssels +dabei durch die Signatur gesichert ist, ist die Authentizität des +Signierschlüssels nicht gesichert, da das Kundensystem die +Echtheit der Signatur noch nicht prüfen kann. + +Fall B: Das Kreditinstitut signiert nicht + +Der Kunde erhält nur den öffentlichen Chiffrierschlüssel zurück- +gemeldet. Dessen Authentizität ist dabei nicht gesichert. + +(3) Die Sicherung der Authentizität dieser Schlüssel kann über folgende Me- +chanismen erfolgen: + +Fall A: Ini-Brief + +Diese Nachricht wird von einem Ini-Brief an den Kunden beglei- +tet. Die Gestaltung ist dem Kreditinstitut freigestellt, sollte sich +aber am Muster in Abbildung 14 bzw. Abbildung 15 orientieren. +Der Ini-Brief enthält für den Fall A Exponent und Modulus des +Signierschlüssels sowie dessen Hashwert und für den Fall B Ex- +ponent und Modulus des Chiffrierschlüssels sowie dessen Hash- +wert. + +Bei RDH-1 sind dabei Exponent und Modulus mit führenden Nul- +len (X'00') auf 768 Bit zu ergänzen (in den Abbildungen nicht +mehr berücksichtigt). + +Bei RAH-7, RAH-9 und RAH-10 sowie RDH-2, RDH-3, RDH-5, +RDH-6, RDH-7, RDH-8, RDH-9 und RDH-10 ist hierbei der Ex- +ponent mit führenden Nullen (X'00') auf die reale Länge des Mo- +dulus zu ergänzen. + +Für die Auswahl des zu verwendenden Hashwertverfahrens gel- +ten folgende Regeln: + +RIPEMD-160: + +Bei RDH-1, RDH-2, RDH-3 und RDH-5 generell; +bei RDH-6, RDH-7, RDH-8, RDH-9 oder RDH-10, wenn +EF_NOTEPAD, HBCI-Version C0=001 (vgl. Abschnitt C.1.2.2.2) + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionB
Kapitel:VerfahrensbeschreibungStand:Seite:
Abschnitt:Abläufe18.07.201339
+ + +SHA-256: + +bei RAH-7, RAH-9 und RAH-10 sowie RDH-6, RDH-7, RDH-8, +RDH-9 oder RDH-10, wenn EF_NOTEPAD, HBCI-Version +C0=002 (vgl. Abschnitt C.1.2.2.2) + +Ferner enthält der Ini-Brief den jeweiligen Schlüsselnamen. + +Bei der Hashwertbildung ist wie folgt vorzugehen: + +a) RDH-1: Padding der höchstwertigen Bits von Exponent und +Modulus des Schlüssels mit Nullen (X'00') auf 1024 Bit + +sonst: Padding der höchstwertigen Bits des Exponenten mit +Nullen (X'00') auf die reale Länge des Modulus + +b) Konkatenierung von Exponent und Modulus (Exponent || Mo- +dulus) + +c) Bildung des Hashwerts mittels RIPEMD-160 bzw. SHA-256 +gemäß Kap. B.2.1.1 über diesen Ausdruck + +Nach Erhalt des Ini-Briefs führt der Kunde einen Vergleich des im +Ini-Brief aufgeführten Hashwerts mit dem Hashwert des vom +Kreditinstitut übermittelten Schlüssels durch. + +Bei Übereinstimmung der Hashwerte gelten der bzw. die öffentli- +chen Schlüssel des Kreditinstituts als authentisiert. + + +![](figures/53.1) + + +Das Kundenprodukt sollte den Hashwertver- +gleich für den Kunden in geeigneter Weise un- +terstützen. + + +#### Fall B: Übermittlung des Hashwerts auf der Chipkarte + +Auf der Karte befindet sich in der Applikation EF_NOTEPAD (s. +Kap. C.1.1) für Fall A der Hashwert des öffentlichen Signier- +schlüssels des Kreditinstituts und für Fall B der Hashwert des öf- +fentlichen Chiffrierschlüssels des Kreditinstituts. Die Hashwertbil- +dung erfolgt wie in Fall A. + +Dieser Hashwert wird vom Kundenprodukt mit dem Hashwert des +in der Nachricht übermittelten Schlüssels verglichen. + + +![](figures/53.2) + + +Das Kundenprodukt sollte den Kunden über +das Ergebnis des Hashwertvergleichs informie- +ren. + +Bei Übereinstimmung der Hashwerte gelten der bzw. die öffentli- +chen Schlüssel des Kreditinstituts als authentisiert. + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:
40		Stand:
18.07.2013		Kapitel: Verfahrensbeschreibung
Abschnitt:
Abläufe
+ + +#### Fall C: Prüfung des übermittelten Zertifikates + +Falls das Kreditinstitut über zertifikatsbasierte Schlüssel verfügt, +übermittelt es das jeweilige Zertifikat in der Nachricht zusammen +mit dem öffentlichen Schlüssel. + +Somit ist der Kunde in der Lage, das Zertifikat bei der jeweiligen +Zertifizierungsinstanz zu verifizieren. Diese Verifikation findet au- +Berhalb des FinTS-Protokolls statt und wird daher hier nicht nä- +her beschrieben. + +Ein Hashwertvergleich wie in den beiden anderen Fällen ist nicht +erforderlich. + + +![](figures/54.1) + + +Das Kundenprodukt sollte den Kunden über +das Ergebnis der Zertifikatsprüfung informieren. + +2\. Der Kunde übermittelt alle seine öffentlichen Schlüssel, die mit dem privaten Si- +gnierschlüssel unterzeichnet wurden, im Rahmen der Key-Management-Nach- +richt „Erstmalige Übermittlung der Schlüssel des Kunden“ an das Kreditinstitut +(vgl. Kapitel B.8.1.3). Diese Nachricht muss sowohl signiert als auch chiffriert +sein. + +3\. Um die Authentizität der Schlüssel zu gewährleisten, sind folgende Mechanismen +möglich: + + +##### Fall A: Ini-Brief + +Der Kunde erfährt anhand des Rückmeldungscodes 3310 („Ini-Brief er- +forderlich“) in der Kreditinstitutsnachricht, dass diese Nachricht durch ei- +nen Ini-Brief gemäß dem in Abbildung 14 bzw. Abbildung 15 aufgeführ- +ten Muster begleitet werden muss. Im Ini-Brief bestätigt der Kunde aus- +schließlich den öffentlichen Signierschlüssel mit handschriftlicher Unter- +schrift. Eine Bestätigung des öffentlichen Chiffrierschlüssels ist nicht er- +forderlich, da dieser mit dem Signierschlüssel signiert wird und damit au- +thentifiziert ist. Neben dem Schlüssel und dem Schlüsselnamen wird im +Ini-Brief der Hashwert des Schlüssels aufgeführt. Dieser wird ebenso +gebildet wie der Hashwert im Ini-Brief des Kreditinstituts (s.o.). + +Im Kreditinstitut findet ein Vergleich zwischen dem im Ini-Brief aufgeführ- +ten Hashwert und dem Hashwert des vom Kunden übermittelten öffentli- +chen Signierschlüssels statt. + +Falls dieser Vergleich positiv verläuft, werden die öffentlichen Schlüssel +des Kunden freigeschaltet. + + +#### Fall B: Prüfung des übermittelten Zertifikates + +Der Kunde erfährt anhand des Rückmeldungscodes 3320 (,Ini-Brief +nicht erforderlich") in der Kreditinstitutsnachricht, dass das Kreditinstitut +die Prüfung der Authentizität der Schlüssel auf Basis eines Zertifikates +vornehmen kann. + +Falls der Kunde über zertifikatsbasierte Schlüssel verfügt, übermittelt er +daher das jeweilige Zertifikat in der Nachricht zusammen mit dem öffent- +lichen Schlüssel. Somit ist das Kreditinstitut in der Lage, das Zertifikat +bei der jeweiligen Zertifizierungsinstanz zu verifizieren. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionB
Kapitel:VerfahrensbeschreibungStand:Seite:
Abschnitt:Abläufe18.07.201341
+ + +Diese Verifikation findet auBerhalb des FinTS-Protokolls statt und wird +daher hier nicht näher beschrieben. + +Ein Hashwertvergleich wie in Fall A ist nicht erforderlich. + +4\. Im nächsten Schritt wird der Kunde freigeschaltet. + +5\. Es hat eine Synchronisierung der Kundensystem-ID zu erfolgen (s. [Formals], +Kap. III.8). + +6\. Hiermit ist die Erstinitialisierung abgeschlossen und der Kunde kann Auftrags- +nachrichten senden. + + +Abbildung 13: Ablauf der Erstinitialisierung bei RDH + +![Erstmalige Anforderung der Schlüssel des Kreditinstituts Kunde Kreditinstitut Erstmalige Übermittlung der Schlüssel des Kunden Synchronisierung der Kundensystem-ID Auftragsdialog](figures/55.1) + + +Um die Multibankfähigkeit verschiedener Kundenprodukte zu sichern, gelten für die +Ini-Schlüsseldatei folgende Namenskonventionen: + +. Segment HIUPA: +.UPA + +· Datei mit den öffentlichen Schlüsseln: +.PKD + +. BPD: + +.BPD + +· Segment mit Kommunikationszugang: +.KOM + +· Zugangsdatenbank des Verbandes: +BDB.KOM, BVR.KOM, DSGV.KOM bzw. +VOEB.KOM + +Falls die Benutzerkennung nicht im Dateisystem darstellbar ist, ist sie entsprechend +zu kürzen. Die Schlüsseldatei muss im Standardformat des jeweiligen Betriebssys- +tems formatiert sein. Die Dateien sind im Stammverzeichnis der Schlüsseldatei ab- +zulegen. + + + + + + + + + + + + + + + + + + + + +
Kapitel:
B		Version: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:Stand:Kapitel: Verfahrensbeschreibung
4218.07.2013Abschnitt:
Abläufe
+ + +Abbildung 14: Beispiel für die Gestaltung des Ini-Briefs bei RDH-2 oder RDH-5 + +![Ini-Brief HBCI Benutzername Kundensoftware-interner Name (Angabe freigestellt) Datum Datum der Erstellung des Initialisierungsauftrags (TT.MM.JJJJ) Uhrzeit Uhrzeit der Erstellung des Initialisierungsauftrags (hh:mm) Empfänger Kreditinstitutskennung (wird vom jeweiligen Kreditinstitut mitgeteilt) Benutzerkennung max. 30 Stellen alphanumerisch (wird vom jeweiligen Kreditinstitut mitgeteilt) Schlüsselnummer Nummer des Signierschlüssels (max. 3 Stellen) Schlüsselversion Version des Signierschlüssels (max. 3 Stellen) HBCI-Version derzeit 3.0 Sicherheitsprofil RDH-2, RDH-3 oder RDH-5 Öffentlicher Schlüssel für die elektronische Signatur: Exponent 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 01 Modulus .2048 97 A9 D8 FD 68 46 BA 5E DB E0 F5 35 41 3C B3 7C 95 6A 8C 11 29 63 1C 41 4A CC E3 A7 A6 7B A8 6D E8 1D 99 D2 BF 2A 5D B6 74 24 6E 6C C6 FD A9 9C 19 15 44 FB 88 19 66 2D 93 5B 80 FA 9B 42 FE 8C B2 A2 1C 96 FB 4F 5E 6A 5E 84 E6 9A 76 AB 52 5A 36 C1 6D F8 B1 EF E0 D1 65 0A BC 86 35 86 5B ฿5 84 A1 44 76 69 DE 34 D5 31 E7 8E A2 D0 25 02 78 B5 24 BE 57 AB C0 D9 30 13 B1 04 95 91 DF 23 0D 81 3B 58 E1 91 33 CD E5 3D E7 39 00 A2 EF 4B 60 85 71 3E 39 92 7C 14 F9 06 3A 97 3D 37 F1 9E A5 71 30 33 E2 60 3F 87 52 80 AF 4E E4 DD 38 66 E8 B2 29 6B BF 25 36 3E 0F A0 55 39 4A 31 7A 69 88 9B D6 3B 26 B6 B6 53 44 CA 33 C7 E0 40 4A 60 79 43 29 97 43 A6 50 C4 DC F2 EF 54 B6 E8 BD 05 95 17 56 93 13 EΕ B2 2A B9 87 52 FC 24 75 D4 F2 A7 E7 D1 CD 90 9A D3 D8 78 99 1D C3 21 4D 2F 5A A3 Hashwert (RIPEMD-160): 0B AD D5 D5 FD 57 0D 34 E7 84 7C ED AE 4B 3D EE 6B EB 98 AC Ich bestätige hiermit den obigen öffentlichen Schlüssel für meine elektronische Signatur. Ort / Datum Fima/Name Unterschrift](figures/56.1) + + +Die folgende Abbildung zeigt ein Beispiel für einen Ini-Brief bei Verwendung der Si- +cherheitsprofile RAH-9, RAH-10, RDH-8, RDH-9 oder RDH-10 unter Verwendung +von SHA-256 als Hashwertverfahren14. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionB
Kapitel:VerfahrensbeschreibungStand:Seite:
Abschnitt:Abläufe18.07.201343
+ + +Abbildung 15: Beispiel für die Gestaltung des Ini-Briefs bei RAH-9, RAH-10, RDH-8, +RDH-9 oder RDH-10 + +![Ini-Brief HBCI Benutzemame Kundensoftware-interner Name (Angabe freigestellt) Datum Datum der Erstellung des Initialisierungsauftrags (TT.MM.JJJJ) Uhrzeit Uhrzeit der Erstellung des Initialisierungsauftrags (hh:mm) Empfänger Kreditinstitutskennung (wird vom jeweiligen Kreditinstitut mitgeteilt) Benutzerkennung max. 30 Stellen alphanumerisch (wird vom jeweiligen Kreditinstitut mitgeteilt) Schlüsselnummer Nummer des Signierschlüssels (max. 3 Stellen) Schlüsselversion Version des Signierschlüssels (max. 3 Stellen) HBCI-Version derzeit 3.0 Sicherheitsprofil RAH-9, RAH-10, RDH-8, RDH-9 oder RDH-10 Öffentlicher Schlüssel für die elektronische Signatur: Exponent 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 01 Modulus .2048 97 A9 D8 FD 3C 68 46 BA 8C 5E DB E0 1C 35 41 41 4A B3 7C F5 E8 D2 95 74 6A 24 CC 11 29 E3 A7 63 A6 1D 99 6E 6C C6 FD A9 9C A2 7B A8 6D 19 15 44 BF 2A 5D B6 2D 93 5B FA FB 88 19 FE B2 1C 5E 96 FB 4F 5E 66 6A F8 80 84 81 9B 42 8C E6 9A 76 AB 52 5A EF 36 E0 C1 6D D1 65 0A BC 86 35 86 E7 8E 5B B5 84 A1 44 76 69 DE 34 D5 31 A2 D0 25 02 78 B5 24 BE 57 AB C0 D9 30 B1 0D E1 33 CD E5 A2 13 04 91 DF 3B 3D E7 EF 95 23 81 58 91 71 39 37 3E 00 92 7C F9 06 4B 60 97 3D 3F 85 3A 87 52 80 AF 4E 39 F1 9E 14 A5 71 30 33 29 6C E4 DD 38 66 E8 B2 6B BF F2 25 36 3E 0F A0 55 39 C7 4A 31 7A 69 88 9B D6 26 B6 B6 53 CA 40 4A 60 79 29 C4 97 DC 43 F2 3B 54 A6 B6 44 33 E0 E8 52 05 43 50 EF 87 17 13 EE D4 F2 BD B2 2A B9 95 FC 56 93 24 75 A7 E7 D1 CD 90 9A D3 D8 78 99 1D C3 21 4D 2F 5A A3 Hashwert (SHA-256): BF C2 A1 01 7C 65 31 9C BB 1B D8 26 09 85 E6 1F A9 99 1A 65 17 BF 67 86 17 D8 7C EE DC C3 61 11 Ich bestätige hiermit den obigen öffentlichen Schlüssel für meine elektronische Signatur. Ort / Datum Firma/Name Unterschrift](figures/57.1) + + +##### B.3.1.3.4 Schlüsseländerungen + + +###### ◆ Routinemäßige Schlüsseländerung des Kunden + +Bei Speicherung der Schlüssel auf einer Chipkarte ist i.d.R. auf elektronische Weise +keine Änderung einzelner kartenindividueller Schlüssel möglich. Im Falle einer routi- +nemäßigen Schlüsseländerung (z.B. bei Ablauf des Zertifikates) oder einer vermute- +ten Kompromittierung muss daher ein Kartenaustausch oder ein Ersatz aller +Schlüssel erfolgen. + +Falls die Karte die Generierung neuer Schlüssel zulässt oder im Falle anderer Spei- +chermedien (Schlüsseldatei) ändert der Kunde seine Schlüsselpaare unabhängig +voneinander. + +Der Kunde sendet je Kreditinstitut im Rahmen eines HBCI-Dialoges eine Nachricht, +in welcher dieses über einen neuen öffentlichen Schlüssel informiert wird (vgl. Kapi- +tel B.6.2.1). Die Nachricht ist mit dem alten (bei Wechsel des Signierschlüssels), +respektive dem aktuellen (bei Wechsel des DS-Schlüssels oder des Chiffrierschlüs- +sels) privaten Signierschlüssel des Kunden zu signieren und mit dem aktuellen +Chiffrierschlüssel des Kreditinstituts zu chiffrieren. + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:
44		Stand: 18.07.2013Kapitel: Verfahrensbeschreibung
Abschnitt: Abläufe
+ + +Das Kreditinstitut speichert diesen neuen öffentlichen Schlüssel des Kunden und +verwendet ihn ab sofort (d.h. bereits in der Antwortnachricht) für alle Verschlüsse- +lungen bzw. Verifikationen von Signaturen. Gleichzeitig kann der alte Schlüssel ge- +sperrt werden. Zusätzlich ist es jedoch bei kartengestützten Verfahren – unabhängig +von der Nutzung von Zertifikaten – erlaubt, einen Schlüssel für die Laufzeit der Kar- +te weiter aktiv zu halten und somit zwei Schlüssel parallel zu unterstützen. + +Falls die Übermittlung der neuen Schlüssel aus irgendeinem Grunde fehlschlägt, +kann der Kunde den Vorgang beliebig wiederholen. + +Bei einer Schlüsseländerung wird die Signatur-ID auf 1 zurückgesetzt. Die Liste der +eingereichten bzw. noch nicht eingereichten Signatur-IDs (s. Doppeleinreichungs- +kontrolle) wird gelöscht. + + +###### ◆ Routinemäßige Schlüsseländerung des Kreditinstituts + +Ein Kreditinstitut generiert bei Bedarf ein neues Schlüsselpaar. + +Der Kunde sendet jeweils bei der Dialoginitialisierung die Referenz auf die öffent- +lichen Schlüssel des Kreditinstitutes mit (vgl. [Formals], Kapitel III.3.1). Falls das +Kreditinstitut über aktuellere öffentliche Schlüssel verfügt, werden diese in der Kre- +ditinstitutsnachricht mitübertragen (vgl. [Formals], Kapitel III.3.2 respektive B.6.1.3). +Die neuen Schlüssel gelten ab sofort, d.h. bereits für die erste Auftragsnachricht +nach der Dialoginitialisierung. Da das Kreditinstitut i.d.R. aber auch noch die alten +Schlüssel aktiv hält, werden für einen begrenzten Zeitraum auch noch Nachrichten +akzeptiert, die mit den alten Kreditinstitutsschlüsseln chiffriert wurden. + +Zur Verifikation des kreditinstitutsseitigen öffentlichen Schlüssels auf dem Kunden- +system kann das entsprechende Kreditinstitut die Kreditinstitutsnachricht mit dem al- +ten Signierschlüssel signieren (wenn eine kreditinstitutsseitige Signatur vorgesehen +ist) oder den Hashwert des öffentlichen Schlüssels analog der initialen Schlüssel- +verteilung an den Kunden übermitteln. Die Verifikation ist grundsätzlich optional. + +Für den Fall, dass der alte Kreditinstitutsschlüssel nicht mehr zur Verfügung steht +oder gesperrt werden musste, wird dem Kunden - falls er den alten Kreditinstituts- +schlüssel zur Chiffrierung der Dialoginitialisierung verwendet – der Rückmeldungs- +code "9030" mit dem Hinweis "Fehler beim Entschlüsseln" gesendet. Ggf. kann die +Dialoginitialisierung vom Kreditinstitutssystem auch gar nicht verarbeitet werden, so +dass keine Antwort gesendet wird. Daraufhin sollte das Kundenprodukt über den +anonymen Dialog mit Hilfe der Nachricht ,Erstmalige Anforderung der Schlüssel des +Kreditinstituts" (s. Kap. B.6.2.1) die neuen Kreditinstitutsschlüssel anfordern. Zur Ve- +rifikation der neuen Schlüssel muss dem Kunden in diesem Fall zusätzlich ein Ini- +Brief mit dem Hashwert des neuen Kreditinstitutsschlüssels zugeschickt werden. + + +##### B.3.1.3.5 Schlüsselverteilung nach Kompromittierung + +Die Verteilung der Schlüssel nach einer Kompromittierung erfolgt analog der Schlüs- +selverteilung bei der Initialisierung. Es findet immer ein Austausch aller Schlüssel +statt, auch dann, wenn nur einer der Schlüssel kompromittiert wurde. + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: B
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final Version
Kapitel:VerfahrensbeschreibungStand:Seite:
Abschnitt:Abläufe18.07.201345
+ + +###### B.3.2 Schlüsselsperrung + +Bei der Schlüssel- bzw. Benutzersperrung muss zwischen folgenden Fällen unter- +schieden werden: + +· Kompromittierung des eigenen Schlüssels + +• Verlust des eigenen Schlüssels + +· Überschreiten der Anzahl der Falschsignaturen + +Zusätzlich müssen bei der Sperrung noch folgende Punkte berücksichtigt werden: + +. Information des Kunden + +. Entsperrung + +Die Sperrung anderer Benutzer wird als eigenständiger Auftrag behandelt und zu +einem späteren Zeitpunkt realisiert. + + +####### . Kompromittierung des eigenen Schlüssels + +Bei Verdacht auf Kompromittierung des eigenen Schlüssels kann die Sperrung mit- +tels einer speziellen Nachricht (vgl. Kapitel B.8.1.4) erfolgen, welche signiert sein +muss. + + +####### ◆ Verlust des eigenen Schlüssels + +Bei einem Verlust (inkl. Diebstahl) des eigenen Schlüssels (respektive des Spei- +chermediums) muss der Kunde Schlüssel bzw. Medium sperren und beim Kreditin- +stitut ein anderes Medium inkl. Schlüssel beantragen. + +Eine nicht-signierungspflichtige Sperrmöglichkeit ist optional, da hierdurch die Ge- +fahr des Mißbrauchs gegeben ist (absichtliche Sperrung fremder Anschlüsse). Der +Segmentaufbau erfolgt analog der oben beschriebenen Nachricht, jedoch ist keine +Signatur nötig (möglich). Die Steuerung hierfür erfolgt über das Feld „Anzahl benö- +tigter Signaturen" in der UPD. + +Eine Sperrung auf anderem Weg (z.B. telefonische Sperrung über Servicezentralen) +muss immer möglich sein (z.B. Verlust der eigenen Infrastruktur). + + +####### ◆ Überschreiten der Anzahl der Falschsignaturen + +Wird beim Einreichen von Aufträgen durch fehlerhafte Signaturen die festgelegte +Anzahl von n Falschsignaturen in Folge überschritten, werden kreditinstitutsseitig +die Schlüssel gesperrt. Als Falschsignaturen werden dabei fehlgeschlagene krypto- +graphische Operationen, jedoch z.B. keine fehlerhaften Berechtigungen verstanden. + +Bei einer Sperrung aufgrund zu vieler Fehlsignaturen werden alle Kundenschlüssel +gesperrt. Sofern die Nachricht lediglich von einem einzigen Benutzer signiert wurde +oder falls bei einer mehrfach signierten Nachricht der Dialogführer von der Fehlsig- +naturensperre betroffen ist, wird der Dialog beendet. Der Dialogabbruch erfolgt da- +bei kreditinstitutsseitig im Anschluss an die Antwortnachricht, d.h. ein Austausch von +Dialogbeendigungsnachrichten findet nicht statt. Die Antwort ist beim DDV- +Verfahren weder signiert noch verschlüsselt. Beim RAH- bzw. RDH-Verfahren ist die +Antwort signiert (sofern kreditinstitutsseitig signiert wird) aber nicht verschlüsselt. In +der Antwortnachricht teilt das Kreditinstitut lediglich den Grund des Dialogendes mit. +Antworten auf Aufträge dürfen nicht mitgesendet werden, da diese aufgrund der +Sperrung nicht abgesichert werden können. + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:
46		Stand: 18.07.2013Kapitel: Verfahrensbeschreibung
Abschnitt: Abläufe
+ + +## . Information des Kunden + +Im Falle einer Sperrung aufgrund von Schlüsselkompromittierung oder Schlüs- +selverlust erhält der Kunde auf die Sperrnachricht eine Antwortnachricht (vgl. Kapitel +B.8.1.4 b), welche ihm die Sperrung bestätigt. Bei einer Sperrung wegen Über- +schreitung des Maximalwertes möglicher Falschsignaturen erhält er lediglich einen +entsprechenden Rückmeldungscode. In jedem Fall erhält er jedoch entsprechende +Fehlermeldungen bei der Einreichung nachfolgender Nachrichten. + + +## . Entsperrung der Benutzerkennung + +Eine Entsperrung erfolgt nur gegen handschriftliche Unterschrift des Kunden. + +Ist der Schlüssel kompromittiert oder nicht mehr auffindbar, so wird für den Benutzer +eine neue Chipkarte, respektive neue Schlüssel und ein neues EF_ID (DDV), oder +ein neues Schlüsselpaar (RAH bzw. RDH) erzeugt und der alte Schlüssel bleibt ge- +sperrt. Es werden in jedem Falle alle Schlüsselpaare neu vergeben, auch wenn nur +ein Schlüsselpaar kompromittiert sein sollte. Damit ein Benutzer nach einer Sper- +rung wieder zum Zugang zum System autorisiert werden kann, darf er in diesem +Fall ausnahmsweise einer erneute Erstinitialisierung durchführen und seine Schlüs- +sel über einen Ini-Brief freischalten lassen. + +In den übrigen Fällen kann der Schlüssel einfach durch das Kreditinstitut entsperrt +werden. + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: B
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final Version
Kapitel:VerfahrensbeschreibungStand:Seite:
Abschnitt:Bankfachliche Anforderungen18.07.201347
+ + +## B.4 Bankfachliche Anforderungen + + +### ◆ Zu signierende Nachrichten + +Grundsätzlich sind alle Kundennachrichten zu signieren, bei Sicherheitsprofil +RAH-7, RDH-3, RDH-6 und RDH-7 gemäß den in den BPD vorgegebenen Sicher- +heitsklassen. Ausnahmen gelten beim anonymen Zugang, bei der Erstinitialisierung +und der Schlüsselsperrung. + +Die Signatur von Kreditinstitutsnachrichten ist optional. + + +### . Doppeleinreichungskontrolle + +Die Doppeleinreichungskontrolle wird mittels eines Zählers pro Signatur realisiert +(Signatur-ID), dessen Inhalt jeweils in die Signatur(en) der Nachricht einfließt. Falls +als Sicherheitsmedium keine Chipkarte verwendet wird, wird zur Doppeleinrei- +chungskontrolle zusätzlich zur Signatur-ID die Kundensystem-ID benötigt. + +Bei der Doppeleinreichungskontrolle (Verhinderung von Replay-Attacken) ist zu be- +rücksichtigen, dass die sequentiell erzeugten Referenznummern (=Signatur-IDs) +beim Kreditinstitut nicht in derselben Reihenfolge eintreffen müssen, da diese kun- +denseitig auch offline (d.h. zeitlich voneinander unabhängig) generiert werden kön- +nen. Das Kreditinstitut muss deshalb sicherstellen, dass innerhalb eines bestimmten +Zeitraums keine Sequenznummer mehrfach erscheint. + +Aus diesem Grund muss beim Kreditinstitut eine Liste mit den eingereichten (Posi- +tivliste) oder noch nicht eingereichten (Negativliste) Signatur-IDs geführt werden. +Nach einer festgelegten Aufbewahrungsfrist wird eine Referenznummer nicht mehr +akzeptiert. (Konkret wird ein Kreditinstitut eine Nachricht abweisen, welche länger +als die vereinbarte Frist nach einer Nachricht mit höherer Signatur-ID eintrifft). Diese +Liste muss je Signaturschlüsselpaar geführt werden, d.h., falls der Benutzer sowohl +mit dem Signierschlüssel- als auch mit dem DS-Schlüssel unterschreibt, sind zwei +Listen erforderlich. + + +### . Mehrfachsignaturen + +Bei Mehrfachsignaturen kann unterschieden werden, ob die Reihenfolge der Unter- +zeichnung bedeutungslos oder relevant ist. Diese Unterscheidung muss nicht nur im +Kundenprodukt gemacht werden können, sondern hat auch Einfluss auf die Verar- +beitung und Kontrolle im Kreditinstitut. In der vorliegenden FinTS-Version ist die +Reihenfolge der Signaturen bedeutungslos. + +Sind die Berechtigungsprofile mehrerer signierender Benutzer zueinander inkonsis- +tent, so liegt es im Ermessen des Kreditinstituts, ob es die Nachricht annimmt oder +ablehnt (Beispiel: Der Erfasser einer Nachricht, für deren Aufträge drei Signaturen +erforderlich sind, liefert nur eine zweite Signatur eines Benutzers mit, der über das +Recht verfügt, die Aufträge alleine zu signieren). + +Ob es zulässig ist, dass bei Mehrfachsignaturen verschiedene Signaturverfahren +eingesetzt werden, gibt das Kreditinstitut in den BPD im Segment ,Sicherheitsver- +fahren“ ([Formals], Kap. IV.4) an. + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:
48		Stand: 18.07.2013Kapitel: Verfahrensbeschreibung
Abschnitt: Formate für Signatur und Verschlüsselung
+ + +## B.5 Formate für Signatur und Verschlüsselung + +Für die Speicherung der Sicherheitsinformationen für die Signatur(en) werden un- +mittelbar nach dem Nachrichtenkopf das (die) Segment(e) „Signaturkopf“ (HNSHK) +und unmittelbar vor dem Nachrichtenabschluss das (die) Segment(e) „Signaturab- +schluss“ (HNSHA) in die bestehende Nachricht eingeschoben. + +Dies entspricht dem in UN/EDIFACT definierten Vorgehen und kann folgenderma- +Ben visualisiert werden: + + + + + + + + + + +
HNHBKHNSHKHBCI-NutzdatenHNSHAHNHBS
+ + +(Die grau hinterlegten Bereiche gehen in die Signatur mit ein.) + +Falls mehrere Signaturen für HBCI-Nachrichten erforderlich sind, so wiederholen +sich Signaturkopf und -abschluss entsprechend: + + + + + + + + + + + + +
HNHBKHNSHK2HNSHK1HBCI-NutzdatenHNSHA1HNSHA2HNHBS
+ + +(Die grau hinterlegten Bereiche bezeichnen die Daten für die Zweit-Signatur bei be- +liebiger Reihenfolge der Signaturen (vgl. Kapitel B.4)). + +Bei der Verschlüsselung wird nach dem Nachrichtenkopf ein Verschlüsselungskopf- +Segment (HNVSK) eingefügt. Dies bedeutet, dass alle Daten nach dem Segment- +endekennzeichen des Nachrichtenkopfes bis zum letzten Byte vor dem Nachrich- +tenabschluss inklusive aller Signaturen in die Verschlüsselung eingehen: + + + + + + + + + +
HNHBKHNVSKek(HNSHKn | HBCI-Nutzdaten | HNSHAn)HNHBS
+ + +Grundsätzlich erfolgt die Reihenfolge der Sicherheitsverarbeitung in folgender Rei- +henfolge: + +1\. elektronische Signatur + +2\. evtl. Zweit- und Drittsignatur + +3\. (Komprimierung) und Verschlüsselung + +Für die Übermittlung der sicherheitsrelevanten Informationen werden die folgenden +Segmente und Datenelementgruppen übertragen. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionB
Kapitel:VerfahrensbeschreibungStand:Seite:
Abschnitt:Formate für Signatur und Verschlüsselung18.07.201349
+ + +### B.5.1 Signaturkopf + + +#### . Beschreibung + +Der Signaturkopf enthält Informationen über den damit verbundenen Sicherheitsser- +vice, sowie über den Absender. + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Signaturkopf
Typ:Segment
Segmentart:Administration
Kennung:HNSHK
Bezugssegment:-
Version:4
Sender:Kunde/Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameTypFor- matLän- geSta- tusAn- zahlRestriktionen
1SegmentkopfDEGM1
2SicherheitsprofilDEGM1
3Sicherheitsfunktion, ko- diertDEcode..3M11,2
4Sicherheitskontrollrefe- renzDEan..14M1<>0
5Bereich der Sicherheits- applikation, kodiertDEcode..3M11
6Rolle des Sicherheits- lieferanten, kodiertDEcode..3M11, 3, 4
7Sicherheitsidentifikation, DetailsDEGM1
8Sicherheitsreferenznum- merDEnum.. 16M1
9Sicherheitsdatum und -uhrzeitDEGM1
10HashalgorithmusDEGM1
11SignaturalgorithmusDEGM1
12SchlüsselnameDEGM1
13ZertifikatDEGC1M: bei RAH-7, RDH-3, RDH-6 und RDH-7 in Ver- bindung mit mindestens ei- nem zu signierenden Ge- schäftsvorfall, der Sicher- heitsklasse 2, 3 oder 4 er- fordert.
O: bei RAH-9, RDH-1, RDH-5, RDH-8 und RDH-9 in Verbindung mit zu signie- renden Geschäftsvorfällen, die Sicherheitsklasse 1 bis 2 erfordern
N: bei DDV-1, RAH-10, RDH-2 und RDH-10
+ + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite: 50Stand: 18.07.2013Kapitel: Verfahrensbeschreibung
Abschnitt: Formate für Signatur und Verschlüsselung
+ + +## . Belegungsrichtlinien + + +### Sicherheitsfunktion, kodiert + +Abhängig von Sicherheitsprofil und Schlüsseltyp und HBCI-Version ist fol- +gender Wert einzustellen: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
SicherheitsprofilSchlüsseltypHBCI V2.xFinTS V3.0
DDV-1S22
RAH-7S-2
RAH-7D-1
RAH-9S-2
RAH-10S-2
RDH-1S11
RDH-2S-2
RDH-3
RDH-3		S-2
D-1
RDH-5S-2
RDH-6
RDH-6		S-2
D-1
RDH-7
RDH-7		S-2
D-1
RDH-8S-2
RDH-9S-2
RDH-10S-2
+ + +RDH-1 bleibt 1 aus Kompatibilitätsgründen zu HBC V2.x. + +Weitere Erläuterungen sind im Data Dictionary zu finden. + + +## Bereich der Sicherheitsapplikation, kodiert + +Der einzig zugelassene Wert ist "1", d.h. SHM (nur Signaturkopf und HBCI- +Nutzdaten). + + +## Rolle des Sicherheitslieferanten, kodiert + +Der Inhalt dieses Feldes sollte derzeit nicht ausgewertet werden. Optional +können aber die nachfolgenden Festlegungen angewendet werden, sofern +dies zwischen Kunde und Kreditinstitut zuvor vereinbart wurde: + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: B
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final Version
Kapitel:VerfahrensbeschreibungStand:Seite:
Abschnitt:Formate für Signatur und Verschlüsselung18.07.201351
+ + +## 1. Dialoginitialisierung und -ende: + +Die Rolle wird durch den Dialogführenden bestimmt. Es ist nur eine Sig- +natur erlaubt. Erlaubt ist nur der Wert ISS/wert115. + + +## 2. Auftragsnachricht: + +Grundsätzlich gilt: Sobald die Rolle ,,WIT" verwendet wird, muss dieser +Benutzer mit der Benutzerkennung aus der Dialoginitialisierung arbeiten. +Auch der Benutzer ,,WIT" muss bankseitig entsprechend der Auftragsart +am Konto des Benutzers ,,ISS" berechtigt sein. + +Die Reihenfolge der Signaturen ist beliebig. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Anzahl SignaturenErlaubte Kombinationen
1. Signatur2. Signatur3. Signatur
1ISS/wert1--
2ISS/wert1CON/beliebig-
WIT/wert1ISS/beliebig-
3WIT/wert1ISS/beliebigCON/beliebig
+ + +![](figures/65.1) + + +Auch bei Belegung dieses Feldes kann das Kunden- +produkt nicht davon ausgehen, dass das Feld kreditin- +stitutsseitig ausgewertet wird. + + +### Sicherheitsidentifikation, Details + +Wenn eine Synchronisierung der Kundensystem-ID durchgeführt wird, ist als +Identifizierung der Partei ,0' einzustellen. + + +### Sicherheitsdatum und -uhrzeit + +Als Bezeichner wird ,1" eingestellt, da es sich um einen Sicherheitszeitstem- +pel handelt. + + +### Zertifikat + +Im Falle der Bankensignaturkarte ist je nach Signaturanforderung der Ge- +schäftsvorfälle entweder das Zertifikat C_X509.CH.DS oder das Zertifikat +C_X509.CH.AUT c/s[&KE] anzugeben. + + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:
52		Stand: 18.07.2013Kapitel: Verfahrensbeschreibung
Abschnitt: Formate für Signatur und Verschlüsselung
+ + +#### B.5.2 Signaturabschluss + + +##### . Beschreibung + +Der Signaturabschluss stellt die Verbindung mit dem dazugehörigen Signaturkopf +her und enthält als "Validierungsresultat" die elektronische Signatur. + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Signaturabschluss
Typ:Segment
Segmentart:Administration
Kennung:HNSHA
Bezugssegment:-
Version:2
Sender:Kunde/Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameTypFor- matLän- geSta- tusAn- zahlRestriktionen
1SegmentkopfDEGM1
2Sicherheitskontrollrefe- renzDEan.. 14M1<>0
3ValidierungsresultatDEbin.512C1M: bei HBCI N: bei PINTAN
4Benutzerdefinierte Signa- turDEGC1N: bei HBCI M/N/O bei anderen Verfah- ren
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionB
Kapitel:VerfahrensbeschreibungStand:Seite:
Abschnitt:Formate für Signatur und Verschlüsselung18.07.201353
+ + +#### B.5.3 Verschlüsselungskopf + + +##### . Beschreibung + +Der Verschlüsselungskopf enthält Informationen über die Art des Sicherheitsservice, +die Verschlüsselungsfunktion und die zu verwendenden Chiffrierschlüssel. + +Zum Abgleich mit den in den BPD definierten Verschlüsselungsverfahren DDV bzw. +RAH und RDH wird das Feld ,,Bezeichner für Algorithmusparameter, Schlüssel“ in +I +der DEG „Verschlüsselungsalgorithmus“ herangezogen. + + +##### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Verschlüsselungskopf
Typ:Segment
Segmentart:Administration
Kennung:HNVSK
Bezugssegment:-
Version:3
Sender:Kunde/Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameTypFor- matLän- geSta- tusAn- zahlRestriktionen
1SegmentkopfDEGM1
2SicherheitsprofilDEGM1
3Sicherheitsfunktion, ko- diertDEcode..3M14
4Rolle des Sicherheits- lieferanten, kodiertDEcode..3M11, 4
5Sicherheitsidentifikation, DetailsDEGM1
6Sicherheitsdatum und -uhrzeitDEGM1
7Verschlüsselungs- algorithmusDEGM1
8SchlüsselnameDEGM1
9KomprimierungsfunktionDEcode..3M1
10ZertifikatDEGC1O: kreditinstitutsseitig bei RAH-7, RAH-9, sowie RDH-1, RDH-2, RDH-3, RDH-5 RDH-6, RDH-7, RDH-8 und RDH-9 (vgl. B.3.1.3.2)
N: sonst
+ + +##### . Belegungsrichtlinien + + +###### Sicherheitsdatum und -uhrzeit + +Als Bezeichner (DE Datum- und Zeitbezeichner, kodiert) wird ,1" (Sicher- +heitszeitstempel) eingestellt. + + +###### Zertifikat + +Im Falle der Bankensignaturkarte ist das Zertifikat EF_C_X509.CH.KE anzu- +geben. + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:
54		Stand: 18.07.2013Kapitel: Verfahrensbeschreibung
Abschnitt: Formate für Signatur und Verschlüsselung
+ + +#### B.5.4 Verschlüsselte Daten + + +##### . Beschreibung + +Dieses Segment enthält die verschlüsselten (und komprimierten) Daten. + +. Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Verschlüsselte Daten
Typ:Segment
Segmentart:Administration
Kennung:HNVSD
Bezugssegment:-
Version:1
Sender:Kunde/Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameTypFor- matLän- geSta- tusAn- zahlRestriktionen
1SegmentkopfDEGM1
2Daten, verschlüsseltDEbin..M1
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionB
Kapitel:VerfahrensbeschreibungStand:Seite:
Abschnitt:Key-Management18.07.201355
+ + +# B.6 Key-Management + + +## B.6.1 Formate für Key-Management + +Für die Schlüsseländerung, die Schlüsselverteilung sowie die Schlüsselsperrung +sind die nachfolgenden Segmente vorgesehen. Diese dürfen nur im Rahmen der +speziellen Key-Management-Nachrichten verwendet werden. + + +## B.6.1.1 Änderung eines öffentlichen Schlüssels + + +## . Beschreibung + +Dieses Segment enthält einen neuen öffentlichen Schlüssel des Kunden. + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Schlüsseländerung
Typ:Segment
Segmentart:Administration
Kennung:HKSAK
Bezugssegment:-
Version:3
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameTypFor- matLän- geSta- tusAn- zahlRestriktionen
1SegmentkopfDEGM1
2Nachrichtenbeziehung, kodiertDEcode1M12
3Bezeichner für Funktions- typDEcode..3M1112
4SicherheitsprofilDEGM1
5SchlüsselnameDEGM1
6Öffentlicher SchlüsselDEGM1
7ZertifikatDEGO1
+ + +## . Belegungsrichtlinien + + +### Nachrichtenbeziehung, kodiert + +Im Zusammenhang mit der Schlüsseländerung ist immer folgender Wert vor- +gesehen: "2" (Key-Management-Nachricht erwartet Antwort) + + +## Bezeichner für Funktionstyp + +Im Zusammenhang mit der Schlüsseländerung ist folgender Wert vorgese- +hen: "112" (Certificate Replacement) + + +## Sicherheitsprofil + +Es wird das den Schlüsseln entsprechende Sicherheitsprofil eingestellt. + + +## Schlüsselname + +Es ist der Name des neuen öffentlichen Schlüssels des Kunden einzustellen. + + +## Zertifikat + +Falls für den neuen öffentlichen Schlüssel ein Zertifikat verfügbar ist, kann es +dem Kreditinstitut auf diese Weise eingereicht werden. + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:
56		Stand: 18.07.2013Kapitel: Verfahrensbeschreibung
Abschnitt: Key-Management
+ + +## B.6.1.2 Anforderung eines öffentlichen Schlüssels + + +# . Beschreibung + +Dieses Segment enthält die Anfrage nach einem öffentlichen Schlüssel des Kredit- +instituts. Im Feld ,Sicherheitsprofil“ gibt der Kunde an, für welches Profil er die +Schlüssel anfordert. Das Segment wird entweder innerhalb der Dialoginitialisierung +(vgl. [Formals], Kapitel III.3.1) oder im Rahmen der erstmaligen Schlüsselanforde- +rung (vgl. Kapitel B.6.2.1) gesendet. + + +## . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Anforderung eines öffentlichen Schlüssels
Typ:Segment
Segmentart:Administration
Kennung:HKISA
Bezugssegment:-
Version:3
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameTypFor- matLän- geSta- tusAn- zahlRestriktionen
1SegmentkopfDEGM1
2Nachrichtenbeziehung, kodiertDEcode1M12
3Bezeichner für Funktions- typDEcode..3M1124
4SicherheitsprofilDEGM1
5SchlüsselnameDEGM1
6ZertifikatDEGO1
+ + +## . Belegungsrichtlinien + + +### Nachrichtenbeziehung, kodiert + +Im Zusammenhang mit der Anfrage nach einem öffentlichen Schlüssel ist +immer folgender Wert vorgesehen: "2" (Key-Management-Nachricht erwartet +Antwort) + + +### Bezeichner für Funktionstyp + +Im Zusammenhang mit der Anfrage für einen öffentlichen Schlüssel ist fol- +gender Wert vorgesehen: "124" (Certificate Status Request) + + +### Schlüsselname + +In den Schlüsselnamen ist die Schlüsselnummer und -version des Schlüs- +sels einzustellen, den das Kundenprodukt als aktuellen öffentlichen Schlüs- +sel des Kreditinstituts kennt. Falls dieser noch nicht vorliegt, ist in beide Fel- +der der Wert ,,999" einzustellen. + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: B
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final Version
Kapitel:VerfahrensbeschreibungStand:Seite:
Abschnitt:Key-Management18.07.201357
+ + +#### B.6.1.3 Übermittlung eines öffentlichen Schlüssels + + +##### . Beschreibung + +Dieses Segment wird zum einen innerhalb der Dialoginitialisierungsantwort (vgl. +[Formals], Kapitel III.3.2) an den Kunden übertragen, falls sich der öffentliche +Schlüssel des Kreditinstituts geändert hat. Es enthält dann jeweils einen öffentlichen +Schlüssel des Kreditinstituts. + +Zum anderen wird das Segment im Rahmen der erstmaligen Anforderung der öf- +fentlichen Schlüssel des Kreditinstituts (vgl. Kapitel B.6.2.1) benötigt. + + +##### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Übermittlung eines öffentlichen Schlüssels
Typ:Segment
Segmentart:Administration
Kennung:HIISA
Bezugssegment:HKISA
Version:3
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameTypFor- matLän- geSta- tusAn- zahlRestriktionen
1SegmentkopfDEGM1
2Nachrichtenbeziehung, kodiertDEcode1M11
3AustauschkontrollreferenzDEid#M1
4Nachrichtenreferenz- nummerDEnum..4M1>0
5Bezeichner für Funktions- typDEcode..3M1224
6SchlüsselnameDEGM1
7Öffentlicher SchlüsselDEGM1
8ZertifikatDEGO1
+ + +##### . Belegungsrichtlinien + + +###### Nachrichtenbeziehung, kodiert + +Es ist folgender Wert vorgesehen: "1" (Key-Management-Nachricht ist Ant- +wort) + + +###### Austauschkontrollreferenz + +Dialog-ID der Anfragenachricht des Kunden nach einem öffentlichen Schlüs- +sel (vgl. [Formals], Kapitel II.6.2). + +Wird das Segment HIISA in einer Schlüsseldatei auf einem Medium abge- +legt, so kann dieses Feld mit dem Wert "0" belegt werden. + + +###### Nachrichtenreferenznummer + +Nachrichtennummer der Anfragenachricht des Kunden nach einem öffentli- +chen Schlüssel (vgl. [Formals], Kapitel II.6.2). + +Wird das Segment HIISA in einer Schlüsseldatei auf einem Medium abge- +legt, so kann dieses Feld mit einem beliebigen gültigen Wert belegt werden. + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:
58		Stand: 18.07.2013Kapitel: Verfahrensbeschreibung
Abschnitt: Key-Management
+ + +# Bezeichner für Funktionstyp + +Es ist folgender Wert vorgesehen: "224" (Certificate Status Notice) + + +## Schlüsselname + +Der zurückgemeldete Schlüsselname enthält insbesondere die zugehörige +Schlüssel- und Versionsnummer, die das Kundenprodukt für die Referenzie- +rung des in der DEG „Öffentlicher Schlüssel“ übertragenen neuen öffentli- +chen Schlüssels verwendet. + + +## Öffentlicher Schlüssel + +Diese Datenelementgruppe enthält den neuen öffentlichen Schlüssel des +Kreditinstitutes. + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: B
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final Version
Kapitel:VerfahrensbeschreibungStand:Seite:
Abschnitt:Key-Management18.07.201359
+ + +### B.6.1.4 Schlüsselsperrung + + +#### . Beschreibung + +Dieses Segment enthält die Anforderung für das Sperren eines Schlüssels. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
. Format
Name:Schlüsselsperrung
Typ:Segment
Segmentart:Administration
Kennung:HKSSP
Bezugssegment:-
Version:3
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameTypFor- matLän- geSta- tusAn- zahlRestriktionen
1SegmentkopfDEGM1
2Nachrichtenbeziehung, kodiertDEcode1M12
3Bezeichner für Funktions- typDEcode..3M1130
4SicherheitsprofilDEGM1
5SchlüsselnameDEGM1
6SperrenkennzeichenDEcode..3M11,501,999
7Sicherheitsdatum und -uhrzeitDEGO1
8ZertifikatDEGO1
+ + +#### . Belegungsrichtlinien + + +##### Nachrichtenbeziehung, kodiert + +Im Zusammenhang mit der Schlüsselsperrung ist folgender Wert vorgese- +hen: "2" (Key-Management-Nachricht erwartet Antwort) + + +##### Bezeichner für Funktionstyp + +Im Zusammenhang mit der Schlüsselsperrung ist folgender Wert vorgese- +hen: "130" (Certificate Revocation) + + +##### Sicherheitsprofil + +Es wird das den Schlüsseln entsprechende Sicherheitsprofil eingestellt. + + +##### Schlüsselname + +Es sind die Identifikationsmerkmale des zu sperrenden Signierschlüssels +einzustellen, unabhängig davon, dass grundsätzlich immer sowohl Signier- +als auch Chiffrierschlüssel gesperrt werden (s. Kap. B.8.1.4). + + +##### Sicherheitsdatum und -uhrzeit + +Enthält optional Datum und Uhrzeit, ab welcher der Schlüssel nicht mehr gül- +tig ist. Als Bedeutung wird „6“ (für CRT, Certificate Revocation Time) einge- +stellt. + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite: 60Stand: 18.07.2013Kapitel: Verfahrensbeschreibung
Abschnitt: Key-Management
+ + +![](figures/74.1) + + +Es ist zu beachten, dass eine terminierte Sperre nicht von al- +len Kreditinstituten unterstützt wird. Das Kundenprodukt soll- +te den Kunden auf diesen Sachverhalt hinweisen. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionB
Kapitel:VerfahrensbeschreibungStand:Seite:
Abschnitt:Key-Management18.07.201361
+ + +### B.6.1.5 Bestätigung der Schlüsselsperrung + + +#### . Beschreibung + +Dieses Segment enthält die Bestätigung für eine Schlüsselsperrung. + + +#### . Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Bestätigung der Schlüsselsperrung
Typ:Segment
Segmentart:Administration
Kennung:HISSP
Bezugssegment:HKSSP
Version:3
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameTypFor- matLän- geSta- tusAn- zahlRestriktionen
1SegmentkopfDEGM1
2Nachrichtenbeziehung, kodiertDEcode1M11
3AustauschkontrollreferenzDEid#M1
4Nachrichtenreferenz- nummerDEnum..4M1>0
5Bezeichner für Funktions- typDEcode..3M1231
6SchlüsselnameDEGM1
7SperrenkennzeichenDEcode..3M11,501,999
8Sicherheitsdatum und -uhrzeitDEGM1
9ZertifikatDEGO1
+ + +#### . Belegungsrichtlinien + + +## Nachrichtenbeziehung, kodiert + +Im Zusammenhang mit der Bestätigung der Schlüsselsperrung ist folgender +Wert vorgesehen: "1" (Key-Management-Nachricht ist Antwort) + + +## Austauschkontrollreferenz + +Dialog-ID der Sperranforderung des Kunden (vgl. [Formals], Kapitel II.6.2). + + +## Nachrichtenreferenznummer + +Nachrichtennummer der Sperrenanforderung des Kunden (vgl. [Formals], +Kapitel II.6.2). + + +## Bezeichner für Funktionstyp + +Im Zusammenhang mit der Bestätigung der Schlüsselsperrung ist folgender +Wert vorgesehen: "231" (Revocation Confirmation) + + +## Schlüsselname + +Es sind die Identifikationsmerkmale des gesperrten Signierschlüssels einzu- +stellen, unabhängig davon, dass grundsätzlich immer sowohl Signier- als +auch Chiffrierschlüssel gesperrt werden (s. Kap. B.8.1.4). + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite: 62Stand: 18.07.2013Kapitel: Verfahrensbeschreibung
Abschnitt: Key-Management
+ + +### Sicherheitsdatum und -uhrzeit + +Enthält optional Datum und Uhrzeit, ab welcher der Schlüssel nicht mehr gül- +tig ist. Als Bedeutung wird „6“ (für CRT, Certificate Revocation Time) einge- +stellt. + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 - Final VersionKapitel: B
Dokument:Security - Sicherheitsverfahren HBCI
Kapitel:VerfahrensbeschreibungStand:Seite:
Abschnitt:Key-Management18.07.201363
+ + +### B.6.2 Key-Management-Nachrichten + +Aufträge des Key-Managements dürfen nur in den folgenden separaten Nachrichten +übertragen werden. + +Hiervon abweichend wird der Auftrag „Anforderung eines öffentlichen Schlüssels +des Kreditinstituts" nicht als eigene Nachricht, sondern innerhalb der Dialoginitiali- +sierung übertragen. + +Die Nachrichten für das Key-Management müssen zum Teil kryptographisch ge- +schützt werden. Alternativ können auch Offline-Sicherungsverfahren (z.B. Brief) zum +Einsatz kommen (vgl. Kapitel B.3.1.3). + +Es sind folgende Key-Management-Nachrichten vorgesehen: + +· Änderung eines öffentlichen Schlüssels des Kunden + +. Erstmalige Anforderung der Schlüssel des Kreditinstituts + +· Erstmalige Übermittlung der Schlüssel des Kunden + +· Schlüsselsperrung durch den Kunden + +Mit Ausnahme der Sperrnachricht sind alle Key-Management-Nachrichten nur bei +Einsatz des RAH- und RDH-Verfahrens möglich. + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite: 64Stand: 18.07.2013Kapitel: Verfahrensbeschreibung
Abschnitt: Key-Management
+ + +#### B.6.2.1 Änderung eines öffentlichen Schlüssels des Kunden + +Realisierung Bank: +verpflichtend + +Realisierung Kunde: verpflichtend + + +##### a) Kundennachricht + + +###### . Beschreibung + +Diese Nachricht ist nur bei Verwendung des RAH- bzw. RDH-Verfahrens möglich. +Der Nachricht muss eine Dialoginitialisierung vorausgehen. Der Auftrag muss mit +dem alten Signierschlüssel signiert werden. + +Es muss unterschieden werden, ob die Schlüsseländerung auch das Sicherheitspro- +fil wechselt oder nicht. + +Die folgenden Wechselmöglichkeiten bestehen, falls Sicherheitsprofilwechsel unter- +stützt sind: + + +Abbildung 16: Unterstützte Sicherheitsprofilwechsel RDH-1, RDH-2 und RDH-5 + +![RDH-1 RDH-2 Schlüssel- datei Schlüssel- datei RDH-1 Karte ohne Zertifikat RDH-5 Karte ohne Zertifikat](figures/78.1) + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: B
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final Version
Kapitel:VerfahrensbeschreibungStand:Seite:
Abschnitt:Key-Management18.07.201365
+ + +Abbildung 17: Unterstützte Sicherheitsprofilwechsel RDH-1, RDH-2 RDH-5, RDH-9 +und RDH-10 + +![RDH-1 Schlüssel- datei RDH-9 Karte ohne Zertifikat RDH-1 Karte ohne Zertifikat RDH-2 RDH-10 Schlüssel- datei Schlüssel- datei RDH-5 Karte ohne Zertifikat](figures/79.1) + + +Zusammengefasst ergeben sich folgende Wechselmöglichkeiten: + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:
66		Stand: 18.07.2013Kapitel: Verfahrensbeschreibung
Abschnitt: Key-Management
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Β.7
RDH-x / RAH-y (aktuelles Verfahren)		B.8 RDH-y / RAH-y (neues Verfahren)
RDH-9 Bankensignaturkarte ohne ZertifikatRAH-9 Bankensignaturkarte ohne Zertifikat
RDH-10 SchlüsseldateiRAH-10 Schlüsseldatei
RDH-10 SchlüsseldateiRAH-9 Bankensignaturkarte ohne Zertifikat
RAH-10 SchlüsseldateiRAH-9 Bankensignaturkarte ohne Zertifikat
RDH-1 SchlüsseldateiRDH-2 Schlüsseldatei
RDH-1 SchlüsseldateiRDH-5 Bankensignaturkarte ohne Zertifikat
RDH-1 SchlüsseldateiRDH-9 Bankensignaturkarte ohne Zertifikat
RDH-1 SchlüsseldateiRDH-10 Schlüsseldatei
RDH-1 Bankensignaturkarte ohne ZertifikatRDH-5 Bankensignaturkarte ohne Zertifikat
RDH-1 Bankensignaturkarte ohne ZertifikatRDH-9 Bankensignaturkarte_ohne Zertifikat
RDH-2 SchlüsseldateiRDH-5 Bankensignaturkarte ohne Zertifikat
RDH-2 SchlüsseldateiRDH-9 Bankensignaturkarte ohne Zertifikat
RDH-2 SchlüsseldateiRDH-10 Schlüsseldatei
RDH-5 Bankensignaturkarte ohne ZertifikatRDH-9 Bankensignaturkarte ohne Zertifikat
RDH-10 SchlüsseldateiRDH-9 Bankensignaturkarte ohne Zertifikat
+ + +##### 1. ohne Wechsel des Sicherheitsprofils: + +Nach der erfolgreichen Durchführung der Schlüsseländerung wird der vorher ak- +tuelle Schlüssel automatisch gesperrt. Es ist darauf zu achten, dass die Version +des neuen Schlüssels höher ist als die des alten Schlüssels. + + +##### 2. mit Wechsel des Sicherheitsprofils + +(vgl. Abbildung 16 und Abbildung 17): + +Bei einem Sicherheitsprofilwechsel muss der Kunde immer beide HKSAK- +Segmente einstellen. Nach der erfolgreichen Durchführung der Schlüsselände- +rung wird durch das Kreditinstitut mitgeteilt, ob der vorher aktuelle RAH-x bzw. +RDH-x-Schlüssel automatisch gesperrt wurde. Diese Nachricht wird mit den +RAH-x bzw. RDH-x-Schlüsseln abgesichert. Wurden die RAH-x bzw. RDH-x- +Schlüssel institutsseitig nicht gesperrt, wird der Dialog unter Absicherung der +RAH-x bzw. RDH-x-Schlüssel beendet. Es ist darauf zu achten, dass die Num- +mer der RDH-2-Schlüssel 2 ist, die Version kann mit 1 beginnen. Ab RDH-5 und +bei RAH-x sind Schlüsselnummer und -version vorgegeben. + + +![](figures/80.1) + + +Falls das Kreditinstitut nicht in der Lage ist, zwei Schlüsselpaare zu +einem Kunden gleichzeitig zu halten und somit die Endenachricht +mit den RAH-x bzw. RDH-x-Schlüsseln nicht mehr bedienen kann, ist +dies dem_Kundenprodukt durch den Rückmeldungscode 3250 mitzutei- +len. Das Kundenprodukt soll dann keine Endenachricht mehr senden und +den Bankdatensatz von der RAH-x bzw. RDH-x-Schlüsseldatei löschen. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionB
Kapitel:VerfahrensbeschreibungStand:Seite:
Abschnitt:Key-Management18.07.201367
+ + +Es empfiehlt sich, die RAH-x bzw. RDH-x-Schlüssel nach einem erfolgreichen Ab- +schluss des Dialoges durch einen Sperrdialog ungültig zu machen. + + +![](figures/81.1) + + +Falls der Kunde eine Schlüsseländerungsnachricht sendet, diese +aber aus kreditinstitutsinternen Verarbeitungsgründen nicht beant- +wortet wird, sollte das Kundenprodukt zunächst einen neuen Dialog +auf Basis eines der Schlüsselpaare aufbauen. Falls diese Nachricht +abgelehnt wird ist ein erneuter Versuch auf Basis eines anderen +Schlüsselpaares vorzunehmen. Aus der Reaktion des Kre- +ditinstituts ist für das Kundenprodukt ersichtlich, ob die Schlüssel- +änderung erfolgreich war oder wiederholt werden muss. + +Da es nicht möglich ist, einen DS-Schlüssel, der ja eine natürliche +Person identifiziert, über die HBCI-Schlüsseländerung zu ändern, +dürften nur "1..2" HKSAK-Segmente eingestellt werden. + + +### B.8.1.1.1 Wechsel des Sicherheitsprofils ohne Schlüsselwechsel + +Diese Situation tritt bei der Migration von RDH- nach gleichrangigen RAH-Verfahren +auf. Beim Übergang von gleichartigen Sicherheitsprofilen (z. B. RDH-9 auf RAH-9 +oder RDH-10 auf RAH-10) muss zwar eine erneute Übermittlung der bestehenden +öffentlichen Schlüssel durch entsprechende HKSAK-Segmente erfolgen, diese die- +nen jedoch nur dazu, die Änderung des Sicherheitsprofils bzgl. des Verschlüsse- +lungsalgorithmus (RDH: 2-Key-Triple-DES nach RAH: AES-256) mitzuteilen. Die +Schlüsselpaare selbst bleiben unverändert, d. h. weder im Kundenprodukt noch im +Kreditinstitut werden Änderungen an den bestehenden Schlüsseln vorgenommen. + +Beim Übergang von RDH- auf RAH-Verfahren ergeben sich folgende Möglichkeiten +des Schlüsselwechsels (RDH-10 auf RAH-9) bzw. des Wechsel des Verschlüsse- +lungsverfahrens von RDH auf RAH: + + +Abbildung 18: Unterstützte Sicherheitsprofilwechsel beim Übergang von RDH- auf +RAH-Verfahren + +![Karte ohne Zertifikat RAH-9 Karte ohne Zertifikat RDH-10 RAH-10 Schlüssel- datei Schlüssel- datei](figures/81.2) + + +RDH-9 + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:
68		Stand: 18.07.2013Kapitel: Verfahrensbeschreibung
Abschnitt: Key-Management
+ + +Zum Verfahren s. Kap. B.3.1.3.4. + + +#### . Format + + + + + + + + + + + + + + + +
Name:Änderung eines öffentlichen Schlüssels des Kunden
Typ:Nachricht
Version:4
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameTypKen- nungSta- tusAn- zahlAnmerkungen
1NachrichtenkopfSEGHNHBKM1s. [Formals], Kap. II.5.1
2SignaturkopfSEGHNSHKM1
3SchlüsseländerungSEGHKSAKM1..3
4SignaturabschlussSEGHNSHAM1
5NachrichtenabschlussSEGHNHBSM1s. [Formals], Kap. II.5.2
+ + +#### . Belegungsrichtlinien + +Der Kunde stellt entweder seinen neuen öffentlichen Signierschlüssel, seinen neuen +öffentlichen Chiffrierschlüssel oder beide Schlüssel ein. + + +#### a) Kreditinstitutsnachricht + + +##### . Format + + + + + + + + + + + + + + + +
Name:Kreditinstitutsnachricht allgemein
Typ:Nachricht
Format:s. [Formals], Kap. II.8.1
+ + +##### ◆ Erläuterungen + +Es werden keine Datensegmente zurückgemeldet. + + +##### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel
0020Öffentlicher Schlüssel wurde geändert
3250RDH-1-Schlüssel wurden gesperrt. Endenachricht nicht mehr möglich.
3260RDH-1-Schlüssel weiterhin gültig. Schlüsselsperre wird empfohlen.
9210Schlüsseländerung von RDH-1 auf RDH-2 zur Zeit nicht möglich
9010Schlüsseländerung zur Zeit nicht möglich
9010Sicherheitsverfahren unterstützt keine öffentlichen Schlüssel
9210Eingereichter Schlüssel ist mit dem aktuellen Schlüssel identisch
+ + +Sender: + +Kunde + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionB
Kapitel:VerfahrensbeschreibungStand:Seite:
Abschnitt:Key-Management18.07.201369
+ + +### B.8.1.2 Erstmalige Anforderung der Schlüssel des Kreditinstituts + +Mit Hilfe dieser Nachricht fordert der Kunde erstmalig den öffentlichen Signier- und +Chiffrierschlüssel des Kreditinstituts an. Gleichzeitig erhält er die aktuellen Bankpa- +rameterdaten, die er benötigt, um die unterstützten Verschlüsselungsverfahren des +Kreditinstituts in Erfahrung zu bringen. Mit Hilfe dieser Informationen wird der Kunde +in die Lage versetzt, beliebige Nachrichten zu verschlüsseln. + +Realisierung Bank: optional + +Realisierung Kunde: verpflichtend + + +### a) Kundennachricht + + +#### . Beschreibung + +Diese Nachricht wird an Stelle einer Dialoginitialisierung gesendet. Es dürfen keine +Auftragsnachrichten folgen. Der Dialog ist vom Kunden nach Erhalt der Antwort- +nachricht mit einer Dialogendenachricht zu beendigen. Die Nachricht wird weder +signiert noch verschlüsselt. + + +#### . Format + + + + + + + + + + + + + + + + + + + +
Name:Erstmalige Anforderung der Schlüssel des Kreditinstituts
Typ:Nachricht
Version:4
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameTypKen- nungSta- tusAn- zahlAnmerkungen
1NachrichtenkopfSEGHNHBKM1s. [Formals], Kap. II.5.1
2IdentifikationSEGHKIDNM1s. [Formals], Kap. III.3.1.2
3Verarbeitungsvorberei- tungSEGHKVVBM1s. [Formals], Kap. III.3.1.3
4Anforderung eines öffent- lichen SchlüsselsSEGHKISAM3
5NachrichtenabschlussSEGHNHBSM1s. [Formals],Kap. II.5.2
+ + +#### . Belegungsrichtlinien + + +#### Identifikation + +Die Datenelemente des Segments sind wie beim anonymen Zugang zu bele- +gen (s. [Formals], Kap. III.5). + + +#### Verarbeitungsvorbereitung + +Mit diesem Segment fordert der Kunde die Bankparameterdaten an. + + +#### Anforderung eines öffentlichen Schlüssels + +Mit diesen Segmenten fordert der Kunde jeweils den öffentlichen Signier- +schlüssel und den öffentlichen Chiffrierschlüssel des Kreditinstituts an. Es +sind stets alle Schlüssel eines Sicherheitsprofils anzufordern, auch wenn das +Kreditinstitut nicht signiert. + +In die DEG „Schlüsselname“ ist für die Benutzerkennung der Standardwert +'999' einzustellen. In der Rückmeldung wird dem Kunden die korrekte Benut- +zerkennung des Kreditinstituts mitgeteilt. + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:
70		Stand:
18.07.2013		Kapitel: Verfahrensbeschreibung
Abschnitt: Key-Management
+ + +![](figures/84.1) + + +Da bei der Erstinitialisierung noch keine BPD vorliegt, ist es +für das Kundenprodukt evtl. problematisch, zu ermitteln +welche Sicherheitsprofile das Kreditinstitut anbietet und - +wenn mehrere möglich sind - welches Profil für den Kunden +gilt. Falls dem Kunden diese Information nicht von seinem +Kreditinstitut mitgeteilt wurde, sollte das Kundenprodukt +versuchen, das Sicherheitsmedium zu lesen und daraus +das richtige Sicherheitsprofil zu erschließen. + +Da ein Kreditinstitut über keinen D-Schlüssel verfügt bzw. +verfügen kann (Voraussetzung ist eine "natürliche Per- +son"), dürfen nur zwei HKISA-Segmente eingestellt wer- +den. + + +##### b) Kreditinstitutsnachricht + +. Format + + + + + + + + + + + + + + + + + + + +
Name:Erstmalige Übermittlung der Schlüssel des Kreditinstituts
Typ:Nachricht
Version:4
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameTypKen- nungSta- tusAn- zahlAnmerkungen
1NachrichtenkopfSEGHNHBKM1s. [Formals], Kap. II.5.1
2SignaturkopfSEGHNSHKO1
3Rückmeldungen zur Ge- samtnachrichtSEGHIRMGM1s. [Formals], Kap. II.7.2
4Rückmeldungen zu Seg- mentenSEGHIRMSOns. [Formals], Kap. II.7.3
5BankparameterdatenSF#O1s. [Formals], Kap. III.3.2.2
6Übermittlung eines öffent- lichen SchlüsselsSEGHIISAM1..3
7KreditinstitutsmeldungSEGHIKIMOns. [Formals], Kap. III.3.2.5
8SignaturabschlussSEGHNSHAO1
9NachrichtenabschlussSEGHNHBSM1s. [Formals], Kap. II.5.2
+ + +### . Belegungsrichtlinien + + +#### Signaturkopf + +Falls das Kreditinstitut einen Signierschlüssel besitzt, d.h. seine Nachrichten +grundsätzlich signiert, hat es auch diese Nachricht zu signieren, um die Au- +thentizität des Chiffrierschlüssels zu sichern (s.u.). + + +#### Übermittlung eines öffentlichen Schlüssels + +In diesen Segmenten werden dem Kunden die öffentlichen Schlüssel des +Kreditinstituts mitgeteilt. + +Falls das Kreditinstitut seine Nachrichten nicht signiert, erhält der Kunde nur +den öffentlichen Chiffrierschlüssel zurückgemeldet. Auf die Anforderung des +Signierschlüssels erhält er einen entsprechenden Rückmeldungscode der +Kategorie ,,Warnungen und Hinweise", der ihm anzeigt, dass das Kreditinsti- +tut seine Nachrichten nicht signiert. + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: B
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final Version
Kapitel:VerfahrensbeschreibungStand:Seite:
Abschnitt:Key-Management18.07.201371
+ + +Da die Authentizität des Chiffrierschlüssels nicht gesichert ist, muss diese +Nachricht durch einen Ini-Brief an den Kunden mit dem Hashwert des Chiff- +rierschlüssels begleitet werden (s. Kap. B.3.1.3.2). + +Falls das Kreditinstitut seine Nachrichten signiert, erhält der Kunde sowohl +den öffentlichen Chiffrier- als auch Signierschlüssel zurückgemeldet. Die Au- +thentizität des Chiffrierschlüssels ist dabei durch die Signatur gesichert. Die +Authentizität des Signierschlüssels ist jedoch nicht gesichert, da das Kun- +densystem die Echtheit der Signatur nicht prüfen kann. Daher muss in die- +sem Fall die Nachricht durch einen Ini-Brief mit dem Hashwert des Signier- +schlüssels begleitet werden. + + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + +
CodeBeispiel
0020Auftrag ausgeführt
3310Kein Schlüssel verfügbar, da Kreditinstitutsnachrichten nicht signiert werden
+ + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:
72		Stand: 18.07.2013Kapitel: Verfahrensbeschreibung
Abschnitt: Key-Management
+ + +### B.8.1.3 Erstmalige Übermittlung der Schlüssel des Kunden + +Mit Hilfe dieser Nachricht übermittelt der Kunde erstmalig seinen öffentlichen Si- +gnier- und Chiffrierschlüssel an das Kreditinstitut („Erstinitialisierungsnachricht“). + +Da der Absender des öffentlichen Schlüssels den Beweis erbringen muss, dass er +auch im Besitz des zugehörigen privaten Schlüssels ist, muss die Nachricht des +Kunden signiert sein. + + +![](figures/86.1) + + +Das Kreditinstitut darf eine Nachricht nicht ablehnen, nur weil für +den Kunden noch kein öffentlicher Schlüssel in der Schlüsselverwal- +tung existiert. Falls die normale Signaturprüfung aus diesem Grund +negativ verläuft, muss zunächst geprüft werden, ob es sich um eine +Erstinitialisierung handelt. In diesem Fall ist der öffentliche Schlüs- +sel aus der Erstinitialisierungsnachricht zu extrahieren und die Sig- +naturprüfung auf der Basis dieses Schlüssels erneut vorzunehmen. + +Die Erstinitialisierungsnachricht des Kunden ist zu verschlüsseln, da die darin ent- +haltenen benutzerbezogenen Daten (Kunden-ID, Benutzerkennung) als vertraulich +einzustufen sind. Dies erfordert, dass sich der öffentliche Chiffrierschlüssel des Kre- +ditinstituts schon vor dem Senden der Erstinitialisierung im Besitz des Kunden be- +finden muss. Ferner muss dem Kunden das Verschlüsselungsverfahren bekannt +sein, das ihm in den Bankparameterdaten mitgeteilt wird. Um dem Kunden diese +Daten vorab zukommen zu lassen bieten sich folgende Lösungen an: + +. Das Kreditinstitut sendet dem Kunden eine Schlüsseldatei zu, die die Schlüssel +und die aktuelle BPD enthält, wie in VI.3.1.3.2 beschrieben. + +. Der Kunde sendet die Key-Management-Nachricht ,,Erstmalige Anforderung der +Schlüssel des Kreditinstituts“ (s. Kap. B.6.2.1). Diese Nachricht wird begleitet von +einem Ini-Brief. + + +![](figures/86.2) + + +Um die wiederholte Ausführung unberechtigter Initialisierungsversu- +che zu verhindern, sind kreditinstitutsseitig folgende Vorkehrungen +zu treffen: + +· Die Benutzerkennung sollte bei Verwendung des RAH- bzw. +RDH-Verfahrens nicht durch benutzerindividuelle Merkmale (z.B. +Kontonummer) hergeleitet werden können. + +· Eine erneute Erstinitialisierung ist nur zulässig, wenn zuvor eine +Sperrung der Schlüssel des Benutzers erfolgt ist. In allen ande- +ren Fällen ist eine erneute Erstinitialisierungsnachricht abzuleh- +nen. + + +![](figures/86.3) + + +Auf der Chipkarte können Kommunikationszugänge abgelegt wer- +den (s. Kap. C). Da pro Institut jedoch mehrere Kommunikationszu- +gänge gespeichert sein können (z.B. TCP/IP und HTTPS), muss ein +Kundenprodukt zunächst prüfen, ob für dieses Institut bereits die +Schlüssel eingereicht wurden, bevor eine erstmalige Übermittlung +der Schlüssel des Kunden durchgeführt wird. Für den Fall, dass das +Kundenprodukt die Schlüssel dennoch sendet, sollte das Institut die +Warnung 3330 „Schlüssel liegen bereits vor“ zurückmelden. + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0 - Final VersionKapitel: B
Dokument:Security - Sicherheitsverfahren HBCI
Kapitel:VerfahrensbeschreibungStand:Seite:
Abschnitt:Key-Management18.07.201373
+ + + + + + + + + + + +
Realisierung Bank:verpflichtend
Realisierung Kunde:verpflichtend
+ + +## a) Kundennachricht + + +### . Beschreibung + +Diese Nachricht wird an Stelle einer Dialoginitialisierung gesendet. Es dürfen keine +Auftragsnachrichten folgen. Die Nachricht muss signiert und verschlüsselt werden. +Der Dialog ist vom Kunden nach Erhalt der Antwortnachricht mit einer Dialogen- +denachricht zu beendigen. Die Dialogendenachricht ist nicht zu signieren, da der +übermittelte Kundenschlüssel zu diesem Zeitpunkt i.d.R. noch nicht freigeschaltet +ist. + + +### . Format + + + + + + + + + + + + + + + + + + + +
Name:Erstmalige Übermittlung der Schlüssel des Kunden
Typ:Nachricht
Version:4
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameTypKen- nungSta- tusAn- zahlAnmerkungen
1NachrichtenkopfSEGHNHBKM1s. [Formals], Kap. II.5.1
2SignaturkopfSEGHNSHKM1
3IdentifikationSEGHKIDNM1s. [Formals], Kap. III.3.1.2
4SchlüsseländerungSEGHKSAKM2-3
5SignaturabschlussSEGHNSHAM1
6NachrichtenabschlussSEGHNHBSM1s. [Formals], Kap. II.5.2
+ + +## . Belegungsrichtlinien + + +### Identifikation + +Der Benutzer hat die ihm zur Initialisierung mitgeteilten Daten einzustellen. +Wenn die Erstinitialisierung mit der alten Benutzerkennung durchgeführt +wird, ist - sofern noch vorhanden - die alte Kundensystem-ID anzugeben, +andernfalls ist als Kundensystem-ID der Wert ,0' anzugeben. Falls zu diesem +Zeitpunkt noch keine Synchronisierung durchgeführt wurde, ist als Kunden- +system-ID der Wert '0' einzustellen. + + +### Schlüsseländerung + +Der Kunde stellt seine öffentlichen Schlüssel ein. Dies können Signier-, Chiff- +rier- oder Authentikationsschlüssel sein. + +Die Authentizität des Chiffrierschlüssels ist dabei durch die Signatur gesi- +chert. Die Authentizität des Signierschlüssels ist jedoch nicht gesichert, da +das Kreditinstitut die Echtheit der Signatur nicht prüfen kann. Daher muss die +Nachricht durch einen Ini-Brief an das Kreditinstitut mit dem Hashwert des +Signierschlüssels begleitet werden (s. Kap. B.3.1.3.2). + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:
74		Stand: 18.07.2013Kapitel: Verfahrensbeschreibung
Abschnitt: Key-Management
+ + +## b) Kreditinstitutsnachricht + + +### . Beschreibung + + +![](figures/88.1) + + +Die Ablehnung der Erstinitialisierungsnachricht darf aus sicherheits- +technischen Aspekten im Rahmen der Rückmeldungscodes nicht +inhaltlich begründet werden. Fehlermeldungen, die sich auf den +syntaktischen Aufbau der Nachricht bzw. der Segmente beziehen, +sind hiervon unberührt. + + +### . Format + + + + + + + + + + + + + + + +
Name:Kreditinstitutsnachricht allgemein
Typ:Nachricht
Format:s. [Formals], Kap. II.8.1
+ + +### ◆ Erläuterungen + +Es werden keine Datensegmente zurückgemeldet. + + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel
0010Öffentlicher Schlüssel wurde entgegengenommen
0020Öffentlicher Schlüssel wurde freigeschaltet
0020Kunde wurde freigeschaltet
9010Auftrag abgelehnt
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionB
Kapitel:VerfahrensbeschreibungStand:Seite:
Abschnitt:Key-Management18.07.201375
+ + +#### B.8.1.4 Schlüsselsperrung durch den Kunden + +Diese Nachricht beschreibt die Anforderung zum Sperren der Schlüssel durch den +Kunden und die Bestätigung der Schlüsselsperrung durch das Kreditinstitut (vgl. +Kapitel B.3.2). + +Realisierung Bank: verpflichtend + +Realisierung Kunde: verpflichtend + + +## a) Kundennachricht + + +### . Beschreibung + +Es werden immer alle Schlüssel gesperrt. Eine selektive Schlüsselsperrung (z.B. +nur Chiffrierschlüssel) ist gegenwärtig nicht zulässig. + +Der Nachricht muss eine Dialoginitialisierung vorausgehen. Die Nachricht muss bei +Kompromittierung signiert sein. Es liegt in der Entscheidung des Kreditinstituts, ob +es auch nicht signierte (anonyme) Schlüsselsperrungen erlaubt (z.B. bei Verlust des +Sicherheitsmediums). Die Steuerung erfolgt in den Userparameterdaten über das +Feld „Anzahl benötigter Signaturen“. Die Nachricht darf maximal eine Signatur tra- +gen. + +Bei Verlust des Sicherheitsmediums liegen dem Benutzer u.U. die zur Durchführung +der Sperrung erforderlichen Daten (Schlüsselnummer und -version) nicht vor. In +diesem Fall ist zur Referenzierung auf den aktuellen Schlüssel jeweils der Wert +'999' einzustellen. Es ist daher darauf zu achten, dass dieser Wert reserviert ist und +nicht im Rahmen der Versionszählung belegt wird. + + +![](figures/89.1) + + +Falls das Kreditinstitut unsignierte Sperrungen zulässt, muss dem +Benutzer darüber hinaus explizit seine Benutzerkennung mitgeteilt +werden. Beim RAH- bzw. RDH-Verfahren erfolgt dies im Rahmen +des Ini-Briefs. Beim DDV-Verfahren kann diese dem Benutzer bei +der Aushändigung der Chipkarte mitgeteilt werden. + +Beim DDV-Verfahren wird der Dialog im Anschluss an die Sperrnachricht ungesi- +chert beendet, d.h. die Kreditinstitutsantwortnachricht sowie die Dialogbeendi- +gungsnachrichten werden weder signiert noch verschlüsselt. + +Beim RAH- sowie RDH-Verfahren wird im Anschluss an die Sperrnachricht + +. die Antwortnachricht sowie die Dialogendenachricht des Kreditinstituts nicht chif- +friert, aber signiert (sofern das Kreditinstitut grundsätzlich signiert) und + +· die Dialogendenachricht des Kunden chiffriert, aber nicht signiert + +Diese Verfahren gelten nur bei einer erfolgreichen Sperrung. Bei einer fehlgeschla- +genen Sperrung ist der Dialog gesichert zu Ende zu führen, da die Schlüssel des +Kunden weiterhin aktiv sind. + +Beim RAH- und RDH-Verfahren muss der Kunde nach einer Schlüsselsperrung zur +Entsperrung eine erneute Erstinitialisierung durchführen. + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite: 76Stand: 18.07.2013Kapitel: Verfahrensbeschreibung
Abschnitt: Key-Management
+ + +## . Format + + + + + + + + + + + + + + + +
Name:Sperrung eines Schlüssels durch den Kunden
Typ:Nachricht
Version:4
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameTypKen- nungSta- tusAn- zahlAnmerkungen
1NachrichtenkopfSEGHNHBKM1s. [Formals], Kap. II.5.1
2SignaturkopfSEGHNSHKO1
3SchlüsselsperrungSEGHKSSPM1
4SignaturabschlussSEGHNSHAO1
5NachrichtenabschlussSEGHNHBSM1s. [Formals], Kap. II.5.2
+ + +## . Belegungsrichtlinien + + +### Schlüsselsperrung + +Dieses Segment enthält die Anforderung für die Schlüsselsperrung. + +Eine selektive Schlüsselsperrung ist gegenwärtig nicht zulässig, d.h. es wer- +den immer alle Kundenschlüssel gleichzeitig gesperrt. In der DEG „Schlüs- +selname" sind die Merkmale des Signierschlüssels einzustellen (s. Kap. +Β.6.1.4). + + +## b) Kreditinstitutsnachricht + + +### . Format + + + + + + + + + + + + + + + + + + + +
Name:Bestätigung der Schlüsselsperrung durch das Kreditinstitut
Typ:Nachricht
Version:4
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameTypKen- nungSta- tusAn- zahlAnmerkungen
1NachrichtenkopfSEGHNHBKM1s. [Formals], Kap. II.5.1
2SignaturkopfSEGHNSHKO1
3Rückmeldungen zur Ge- samtnachrichtSEGHIRMGM1s. [Formals], Kap. II.7.2
4Rückmeldungen zu Seg- mentenSEGHIRMSOns. [Formals], Kap. II.7.3
5Bestätigung der Schlüs- selsperrungSEGHISSPM1
6SignaturabschlussSEGHNSHAO1
7NachrichtenabschlussSEGHNHBSM1s. [Formals], Kap. II.5.2
+ + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel
0020Schlüssel wurde erfolgreich gesperrt
9010Schlüssel ist bereits gesperrt
9010Terminierte Sperren werden nicht unterstützt
9210Unbekanntes Sperrenkennzeichen
9210Sperrdatum liegt zu weit in der Zukunft
+ + +Sender: + +Kunde + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionC
Kapitel:ChipapplikationenStand:Seite:
Abschnitt:Chipapplikation für RAH / RDH18.07.201377
+ + +# C. CHIPAPPLIKATIONEN + + +## C.1 Chipapplikation für RAH / RDH + +Kapitel C.1.1 dient als Überblick für die Datenstrukturen und Zugriffsregeln der Chi- +papplikation "DF_NOTEPAD" für SECCOS-Chipkarten [SECCOS] bzw. [SECCOS- +6]. Die Spezifikation des DF_NOTEPAD selbst und die Terminalabläufe sind im Do- +kument [DF_NOTEPAD] enthalten. + +Im Verlauf dieses Kapitels ist mit "Bankensignaturkarte" eine Chipkarte mit +SECCOS-Betriebssystem und Signaturanwendung gemeint, die u.U. auch die Note- +pad-Applikation aus Kap. C.1.1 enthält. Weitere Applikationen, wie z.B. die elektro- +nische Geldbörse, sind nicht notwendigerweise auf der Chipkarte enthalten. Ebenso +kann die Bankensignaturkarte mit oder ohne Zertifikat ausgeliefert werden. + + +## C.1.1 Applikation Notepad + +Die Anwendung ,,Notepad" dient als ,Notizbuch" zur Aufnahme von Daten anderer +Anwendungen. Durch das Notizbuch wird somit ein mobiler Datenspeicher geschaf- +fen, in dem bestimmte anwendungs- bzw. kundenspezifische Parameter abgelegt +werden können, z.B. für die Bankverbindungsdaten in HBCI. + +Wenn eine Anwendung auf die Karte zugreift, wird geprüft, ob auf der Chipkarte das +Notizbuch DF_NOTEPAD vorhanden ist. Falls ja werden die Daten ausgelesen, falls +nein, muss der Benutzer die Zugangsdaten selbst eingeben bzw. die Zugangsdaten +werden im Kundenprodukt selber verwaltet. + +Im Datenspeicher EF_NOTEPAD kann jeder Record durch eine Anwendung belegt +werden. Die Unterscheidung der Zugehörigkeit bestimmter Dateninhalte erfolgt an +Hand der Tags eines Records: + +. '00' bedeutet, dass der Record nicht belegt ist + +. 'F0' bedeutet, dass der Record HBCI-Bankverbindungsdaten (HBCI-Parameter- +block) enthält. + +. 'F1' bedeutet, dass der Record Bankverbindungsdaten analog dem DFÜ- +Abkommen enthält. + +Weitere Kennungen sind für den späteren Gebrauch durch andere Anwendungen +vorgesehen (Tag 'F2' bis 'FE'). + +Somit können mehrere HBCI-Bankverbindungsdaten (im Sinne der Multibankfähig- +keit) in unterschiedlichen Records, jeweils mit Kennung/Tag 'F0' abgelegt werden. +Jede HBCI-Bankverbindung belegt dabei einen Record analog der im Folgenden +beschriebenen Struktur EF_NOTEPAD. + + +## C.1.2 EF_NOTEPAD + +Bei dem EF_NOTEPAD handelt es sich um ein lineares EF mit einer variablen Re- +cordlänge, die aus technischen Gründen auf maximal 2391 Byte begrenzt ist. Es +dient der Ablage beliebiger Daten. + + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:
78		Stand: 18.07.2013Kapitel: Chipapplikationen
Abschnitt: Chipapplikation für RAH / RDH
+ + +Die HBCI Anwendung nutzt das EF_NOTEPAD zur Speicherung von Zugangsspezi- +fischen Daten, den HBCI-Parameterblöcken. So kann ein Online-Banking- +Kundenprodukt in einem HBCI-Parameterblock und damit in einem Record des +EF_NOTEPADs Informationen wie z.B. die HBCI-Benutzerkennung ablegen. Dar- +über hinaus können vom Kundenprodukt in einem separaten weiteren Record aber +auch (produktspezifische) Informationen zu Kundenpräferenzen und -einstellungen +(z.B. Sprache, Anzeigeparameter etc.) abgelegt werden. + + +![](figures/92.1) + + +Den Herstellern von Kundensystemen wird vorgeschlagen, beim +EF_NOTEPAD neben einer Länge von 239 Byte auch Karten mit +einer Maximallänge von nur 200 Byte zu unterstützen. Zur Ermitt- +lung der Maximallänge soll der Tag ,,82“ des Bereiches FCP ausge- +lesen werden. + +Der Inhalt des Notepad kann im Wesentlichen nur nach vorhergehender, erfolgrei- +cher CSA-Passwort-Verifizierung gelesen und verändert werden. Somit ist der Inhalt +insbesondere vor unberechtigtem Auslesen geschützt (z.B. wenn die Kontonummer +als Bestandteil der Benutzerkennung gespeichert ist). + +Das Auslesen der Records erfolgt über ein Read Record auf alle vorhandenen Re- +cords. Wird ein HBCI-Parameterblock gesucht so ist anschließend ein Vergleich +durchzuführen, ob der TAG des Records den Inhalt 'FO' enthält. + +Alternativ können mit dem Kommando SEARCH RECORD mit dem Suchmuster 'F0' +für das erste Byte des Recordinhalts genau die für HBCI relevanten Records aus- +gelesen werden. + + +## ◆ FCP + +Für das EF_NOTEPAD sind die folgenden FCP festzulegen: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TagLängeWertErläuterung
'62''1C'Tag und Länge für FCP
'82''05''14 41 00 EF XX'Datei-Deskriptor für lineares EF mit variabler Re- cordlänge bis zu 239 ('EF') Byte und XX Records
'83''02''A6 11'Datei-ID des EF_NOTEPAD
'85''02''YY YY'für Nutzdaten allokierter Speicherplatz in Byte (XX Records mal 239 Byte)2
'88''01''D0'SFI '1A' für das EF_NOTEPAD
'A1''08''8B 06 00 30 01 04 02 05'Zugriffsregel-Referenzen
+ + +Die maximale Anzahl der Records und deren maximale Länge wird bei der Produk- +tion der Karte festgelegt. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionC
Kapitel:ChipapplikationenStand:Seite:
Abschnitt:Chipapplikation für RAH / RDH18.07.201379
+ + +Im SE #1 durfen READ, SEARCH und UPDATE RECORD nur ausgeführt werden, wenn +zuvor eine Karteninhaberauthentikation mit dem globalen Passwort 3 (CSA- +Passwort) erfolgt ist. Der Returncode wird nicht MAC-gesichert (Zugriffsregeln im +Record 4 des EF_RULE). + +Im SE #2 dürfen die Kommandos READ, SEARCH und UPDATE RECORD nur ausge- +führt werden, wenn sie mit Secure Messaging durchgeführt werden. Entweder ist +zuvor eine Karteninhaberauthentikation mit dem globalen Passwort 3 (CSA- +Passwort) erfolgt und die MAC-Bildung im Secure Messaging erfolgt für Kommando- +und Antwortnachricht mit dem Sessionkey SK2; oder (ohne vorherige Karteninha- +berauthentikation) die MAC-Bildung erfolgt für Kommando- und Antwortnachricht mit +dem KNotepad_Admin (Zugriffsregel im Record 5 des EF_RULE). + +Im SE #2 darf das Kommando APPEND RECORD nur mit Secure Messaging durchge- +führt werden. Die MAC-Bildung erfolgt für Kommando- und Antwortnachricht mit +dem KNotepad_Admin. + +Im SE #2 darf das Kommando SELECT FILE (EF) ohne Einhaltung von Zugriffsbedin- +gungen oder mit Secure Messaging durchgeführt werden. Die MAC-Bildung im +Secure Messaging erfolgt für Kommando- und Antwortnachricht mit dem Session- +key SK2. + + +## . Aufbau eines Records + + + + + + + + + + + + + + + + + + + + + + + + + + + +
POSLängeWertErläuterung
11'XX'Tag
21 oder 2'XX' oder '81 XX'Länge (bei Längen über 127 Byte ist die Kodierung '81' 'xx' zu verwenden)
3L'XX..XX'Nutzdaten
+ + +Als Tags werden festgelegt: + + + + + + + + + + + + + + + + + + + +
Byte 1Bedeutung
'00'freier Record
'F0'Belegung mit HBCI-Parameterblock
'F1'-'FE'RFU
+ + +Durch den Tag 'F0' wird ein Recordeintrag als HBCI-Parameterblock für die HBCI- +Anwendung gekennzeichnet. Für Belegungen der EF_NOTEPAD-Records durch +andere Anwendungen stehen die Tags 'F1' bis 'FE' zur Verfügung. Die Kennungen +werden durch den ZKA vergeben. + +Initial werden alle Records mit '00..00' belegt und so als leere Records gekenn- +zeichnet. + + +## . Beispiel eines EF_NOTEPADs + +In der folgenden Tabelle ist die beispielhafte Belegung eines EF_NOTEPAD mit 7 +Records angegeben. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite: 80Stand: 18.07.2013Kapitel: Chipapplikationen
Abschnitt: Chipapplikation für RAH / RDH
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
RecordEintragErläuterung
1'F0 XX…XX'Erste HBCI-Bankverbindung
2'F0 XX..XX'Zweite HBCI-Bankverbindung
3'F0 XX..XX'Dritte HBCI-Bankverbindung
4'00..00'frei
5'F1 XX..XX'belegt durch Anwendung mit Kennung 'F1'
6'00..00'frei
7'F0 XX…XX'Vierte HBCI-Bankverbindung
+ + +## ◆ Umgang mit variablen Recordlängen + +Durch die Definition des EF_NOTEPAD als lineares EF mit variabler Recordlänge +werden beim Lesen eines Records nur die tatsächlich vorhandenen Daten von der +Karte zurückgegeben. + +Command APDU eines READ RECORD: + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ByteWertErläuterung
1-2'00 B2'CLA, INS
3'0X'P1, Recordnummer X
4'D4'P2, Reference Control Byte
5'00'Le
+ + +Wenn das READ RECORD erfolgreich ausgeführt wird, gibt die Chipkarte eine Ant- +wortnachricht mit der folgenden Struktur zurück: + + + + + + + + + + + + + + + + + + + + + +
ByteLängeWertErläuterung
1-LL'XX …XX'Recordeintrag
(L+1)-(L+2)2'SW1 SW2'Positiver Returncode SW1 SW2
+ + +Ein HBCI-Recordeintrag beginnt in diesem Fall mit dem Tag 'FO' und einem Län- +genbyte. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionC
Kapitel:ChipapplikationenStand:Seite:
Abschnitt:Chipapplikation für RAH / RDH18.07.201381
+ + +## C.1.2.1 Recordbelegung des EF_NOTEPAD mit einem HBCI-Parameterblock, Version 001 + +Bei Verwendung von SECCOS 6 muss mindestens die Version V002 des +EF_NOTEPAD eingesetzt werden. + + + + + + + + + + + + + + + + + + + + + + + + + + +
Ein HBCI-Recordeintrag hat bei V001 folgenden prinzipiellen Aufbau:
Kapitel:Version:Financial Transaction Services (FinTS)
C3.0 - Final VersionDokument: Security - Sicherheitsverfahren HBCI
Seite:Stand:Kapitel: Chipapplikationen
8218.07.2013Abschnitt: Chipapplikation für RAH / RDH
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TagLänge (Byte)WertFor- matSta tusErläuterung
'F0'Var. max 'EC'3HBCI-Parameterblock
'CO''03''30' '30' '31'3anOVersion 001 des HBCI- Parameterblocks
'E1'Var. max. '5B'MHBCI-Institutsparameterblock
'C1''01'-'14'Kreditinstituts- bezeichnung..20anO
'C2''03'Länderkenn- zeichen3anMISO 3166 numerisch in 3 ASCII-Zeichen codiert
'C3''01'-'1E'Kreditinstitutscode..30anMin jeweils national bekannter Notation
'C4'‘1B‘Hashwert Instituts- schlüssel27binO
'C5''01'Schlüsselstatus1binM8 Statusflags
‘E2‘Var. max. '37'MHBCI-Kommunikations- parameterblock
'C6''01'Kommunikations- dienst1nM2 = TCP/IP
'C7''01'-'32'Kommunikations- adresse..50anM
'E2'Var. max. '37'O2. HBCI-Kommunikations- parameterblock
'C6''01'Kommunikations- dienst1nM2 = TCP/IP
'C7''01'-'32'Kommunikations- adresse..50anM
‘E3‘Var. max. '54'OHBCI-Kundenparameterblock
‘C8‘'01'-'1E'Benutzerkennung..30anM
'C9''01'-'1E'Kunden-ID.30anO
'CA''0C' oder '12"Info Inhaber- schlüssel12an oder 18anMSchlüsselnummer und Schlüs- selversion jeweils für den Sig- nierschlüssel, den Chiffrier- schlüssels und optional für den Signaturschlüssel des Karten- inhabers
+ + +Die Längen der einzelnen Records werden wie folgt nach ASN.1 BER (Basic En- +coding Rules) kodiert: + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: C
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final Version
Kapitel:ChipapplikationenStand:Seite:
Abschnitt:Chipapplikation für RAH / RDH18.07.201383
+ + +Längen 'XX', wobei 'XX' die hexadezimale Darstellung eines Wertes zwischen 0 und +127 ist, werden als 'XX' in ein Byte kodiert werden. + +Längen 'XX', wobei 'XX' die hexadezimale Darstellung eines Wertes zwischen 128 +und 255 ist, müssen als '81 XX' in zwei Byte kodiert werden + +Ausnahme ist hier die Länge des TAG 'F0', dieser wird immer in der Form 'F0' '81 +XX' kodiert. + +Ist der Record länger als die tatsächliche ASN.1 Struktur so kann der überschüssige +Speicherplatz im Record mit '00' belegt (z.B. ASN.1 Struktur 170 Byte, Recordlänge +239 Byte → Filler 69 Byte mit '00'). Das Kundenprodukt soll nur die Nutzdaten über- +tragen, + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite: 84Stand: 18.07.2013Kapitel: Chipapplikationen
Abschnitt: Chipapplikation für RAH / RDH
+ + +## C.1.2.2Recordbelegung des EF_NOTEPAD mit einem HBCI-Parameterblock, Version 002 + +Bei Verwendung von SECCOS 6 muss mindestens die Version V002 des +EF_NOTEPAD eingesetzt werden. + +Ein HBCI-Recordeintrag hat bei V002 folgenden prinzipiellen Aufbau: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TagLängeWertFor- matSta tusErläuterung
(Byte)
'F0'Var. max 'EC'4HBCI-Parameterblock
'C0''03''30' '30' '32'3anMVersion 002 des HBCI- Parameterblocks
'E1'Var. max. '5B'MHBCI-Institutsparameterblock
'C1''01'-'14'Kreditinstituts- bezeichnung..20anO
'C2''03'Länderkenn- zeichen3anMISO 3166 numerisch in 3 ASCII-Zeichen codiert
'C3''01'-'1E'Kreditinstitutscode..30anMin jeweils national bekannter Notation
'C4''27'Hashwert Instituts- schlüssel39binO
'C5''01'Schlüsselstatus1binM8 Statusflags
‘E2‘Var. max. '37'MHBCI-Kommunikations- parameterblock
‘C6‘'01'Kommunikations- dienst1nM2 = TCP/IP
'C7''01'-'32'Kommunikations- adresse..50anM
'E2'Var. max. '37'O2. HBCI-Kommunikations- parameterblock
‘C6‘'01'Kommunikations- dienst1nM2 = TCP/IP
‘C7‘'01'-'32'Kommunikations- adresse..50anM
‘E3‘Var. max. '54'OHBCI-Kundenparameterblock
‘C8‘'01'-'1E'Benutzerkennung..30anM
'C9''01'-'1E'Kunden-ID..30anO
'CA''0C' oder '12"Info Inhaber- schlüssel12an oder 18anMSchlüsselnummer und Schlüs- selversion jeweils für den Sig- nierschlüssel, den Chiffrier- schlüssels und optional für den Signaturschlüssel des Karten- inhabers
+ +4 Nettodatenlänge ,EC'=236 Byte + 3 Byte Längenfeld ergibt die maximale Recordlänge von 239 Byte + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: C
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final Version
Kapitel:ChipapplikationenStand:Seite:
Abschnitt:Chipapplikation für RAH / RDH18.07.201385
+ + +### C.1.2.2.1 Tag 'F0': HBCI-Parameterblock + +Durch den Tag 'F0' wird ein Record mit HBCI-Parameterblock für die HBCI- +Anwendung gekennzeichnet. Für Belegungen der EF_NOTEPAD-Records durch +andere Anwendungen stehen die Tags 'F1' bis 'FE' zur Verfügung. + +Ein HBCI-Parameterblock enthält in der angegebenen Reihenfolge: + +· optional ein Versionskennzeichen + +· genau einen HBCI-Institutsparameterblock mit Tag 'E1' + +· genau einen HBCI-Kommunikationsparameterblöcke mit Tag 'E2' + +· optional einen weiteren HBCI-Kommunikationsparameterblöcke mit Tag 'E25 + +· optional einen HBCI-Kundenparameterblock mit Tag 'E3' + +Die maximale Länge des HBCI-Parameterblocks wird beschränkt durch die maxima- +le Recordlänge von 239 Byte6. + + +### C.1.2.2.2 Tag 'C0': HBCI-Version + +In jedem 'F0' Record kann zur Kennzeichnung der Version des EF-NOTEPAD ein +Sub-Record (z. B 'C0' '03' '30' '30' '30') aufgenommen werden. Die Zählung der +Version beginnt bei 1. Ist kein Sub-Record 'C0' vorhanden, so bedeutet dieses, dass +die Belegung des EF-NOTEPAD gemäß der Version 1 erfolgt. + +Anmerkung: In der vorhergehenden Version des Dokumentes wurde fälschlicher- +weise 'E0' als Tag verwendet. 'E0' kann für die erste HBCI-Version '000' weiter ver- +wendet werden. Seit der aktuellen HBCI-Version des EF_NOTEPAD wird durch- +gängig 'C0' verwendet. + + +### C.1.2.2.3 Tag 'E1': HBCI-Institutsparameterblock + +Durch den Tag 'E1' wird der Block der institutsspezifischen Parameter gekenn- +zeichnet. Ein HBCI-Institutsparameterblock enthält in der angegebenen Reihenfol- +ge: + +. optional eine Kreditinstitutsbezeichnung mit Tag 'C1', alphanumerisch mit bis zu +20 Zeichen + +· genau ein Länderkennzeichen des kontoführenden Instituts mit Tag 'C2'. Ver- +wendet wird der numerische ISO 3166-Code als 3-stellige alphanumerische Zei- +chenkette (z.B. Deutschland = "280") + +. genau eine Kreditinstitutskennung mit Tag 'C3', in einer jeweils national bekann- +ten Notation mit bis zu 30 Stellen. Für deutsche Kreditinstitute wird hier die 8- +stellige Bankleitzahl verwendet. + + + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:
86		Stand: 18.07.2013Kapitel: Chipapplikationen
Abschnitt: Chipapplikation für RAH / RDH
+ + +. V001: optional einen Hashwert des öffentlichen Signierschlüssels des Instituts +mit Tag 'C4', binär mit genau 27 Byte. Der Eintrag besteht aus + +[3 Byte Schlüsselnummer | 3 Byte Schlüsselversion | 1 Byte Kennzeichen +Hashverfahren | 20 Byte Hashwert]. + +Als Kennzeichen für das Hashverfahren werden festgelegt:7 + +\- '02' = RIPEMD-160 + +Die Parameter Schlüsselnummer und Schlüsselversion des Institutsschlüssels +werden in je 3 Byte rechtsbündig mit führenden Nullen codiert (z.B. Schlüssel- +nummer 1 → die Bytefolge '30' '30' '31'. + +. V002: optional einen Hashwert des öffentlichen Signierschlüssels des Instituts +mit Tag 'C4', binär mit genau 39 Byte für die Hashwertverfahren RIPEMD-160 +und SHA-256. Das Verfahren ist abhängig vom Sicherheitsprofil zu wählen. + +Der Eintrag besteht bei RIPEMD-160 aus + +[3 Byte Schlüsselnummer | 3 Byte Schlüsselversion | 1 Byte Kennzeichen +Hashverfahren | 32 Byte Hashwert]. + +Der Hashwert ist hierbei folgendermaßen aufgebaut: +[12 Byte '00' | 20 Byte RIPEMD-160 Hashwert] + +Der Eintrag besteht bei SHA-256 aus + +[3 Byte Schlüsselnummer | 3 Byte Schlüsselversion | 1 Byte Kennzeichen +Hashverfahren | 32 Byte Hashwert]. + +Als Kennzeichen für das Hashverfahren werden festgelegt: + +\- '02' = RIPEMD-160 für RDH-3 und RDH-5 + +\- '03' = SHA-256 für RAH-7, RAH-9 sowie RDH-6 bis RDH-9 + +Die Parameter Schlüsselnummer und Schlüsselversion des Institutsschlüssels +werden in je 3 Byte rechtsbündig mit führenden Nullen codiert (z.B. Schlüs- +selnummer 1 → die Bytefolge '30' '30' '31'. + +• genau ein Schlüsselstatus mit Tag 'C5', binär von genau 1 Byte Länge. Der +Schlüsselstatus enthält acht Flags mit folgender Bedeutung: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionC
Kapitel:ChipapplikationenStand:Seite:
Abschnitt:Chipapplikation für RAH / RDH18.07.201387
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Bit1Erstmalige Übermittlung der Kundenschlüssel notwendig'1'b - Ja '0'b - Nein
Bit2Institutsrechner erwartet Signaturen nach ISO9796 mit AnnexA'1'b - Ja '0'b - Nein
Bit3Institutsschlüssel validiert'1'b - Ja '0'b - Nein
Bit4Ausstehende Übermittlung des neuen öffentlichen Chiff- rierschlüssels des Kunden bei Schlüsseländerung8'1'b - Ja '0'b - Nein
Bit5Ausstehende Übermittlung des neuen öffentlichen Sig- nierschlüssels des Kunden bei Schlüsseländerung9'1'b - Ja '0'b - Nein
Bit6Schlüsselsperre mit Erfolg durchgeführt (Info, da termi- nierte Sperrung erst in der Zukunft wirksam werden kann)'1'b - Ja '0'b - Nein
Bit7Leitungsprobleme bei Übermittlung neuer Schlüssel'1'b - Ja '0'b - Nein
Bit8Reserviert'0'b
+ + +Bei der Personalisierung muss als Initialisierungswert '01' aufgebracht werden. + +Ein HBCI-Institutsparameterblock belegt inklusive der Tag- und Längenbytes somit +maximal 93 Byte. + + +### C.1.2.2.4 Tag 'E2': HBCI-Kommunikationsparameterblock + +Durch das Tag 'E2' wird der Block der generellen Kommunikations-Parameter ge- +kennzeichnet. Ein HBCI-Kommunikationsparameterblock enthält in der angegebe- +nen Reihenfolge: + +. genau einen Kommunikationsdienst mit Tag 'C6', 1 Stelle numerisch. Zurzeit de- +finiert ist der numerische Wert 2 (TCP/IP) + +· genau eine Kommunikationsadresse mit Tag 'C7', alphanumerisch mit bis zu 50 +Zeichen + +Ein HBCI-Kommunikationsparameterblock belegt inklusive der Tag- und Längen- +bytes somit maximal 57 Byte. + + +### C.1.2.2.5 Tag 'E3': HBCI-Kundenparameterblock + +Durch den Tag 'E3' wird der optional vorhandene Block der kundenspezifischen +Parameter gekennzeichnet. Ist der Block nicht vorhanden, so handelt es sich um ei- +ne im Rahmen der HBCI-Anwendung Bankensignaturkarte ohne Zertifikat. Ein +HBCI-Kundenparameterblock enthält in der angegebenen Reihenfolge: + +· genau eine Benutzerkennung mit Tag 'C8', alphanumerisch mit bis zu 30 Zei- +chen + +. optional eine Kunden-ID mit Tag 'C9', alphanumerisch mit bis zu 30 Zeichen + + + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite: 88Stand: 18.07.2013Kapitel: Chipapplikationen
Abschnitt: Chipapplikation für RAH / RDH
+ + +• genau ein Info Inhaberschlüssel mit Tag 'CA', von genau 12 oder 18 numerischen +Zeichen. + +Bei 12 Byte Länge des Blocks ist der Inhalt wie folgt definiert: + +Schlüsselnummer Signierschlüssel [3n] +Schlüsselversion Signierschlüssel [3n] +Schlüsselnummer Chiffrierschlüssel [3n] +Schlüsselversion Chiffrierschlüssel [3n] + +Bei 18 Byte Lange ist der Inhalt wie folgt definiert: + +Schlüsselnummer Signierschlüssel [3n] +Schlüsselversion Signierschlüssel [3n] +Schlüsselnummer Chiffrierschlüssel [3n] +Schlüsselversion Chiffrierschlüssel [3n] +Schlüsselnummer Signaturschlüssel [3n] +Schlüsselversion Signaturschlüssel [3n] + +Die Parameter Schlüsselnummer und Schlüsselversion werden in je 3 Byte nume- +risch rechtsbündig mit führenden Nullen angegeben. (z.B. Schlüsselnummer 1 → +"001" → die Bytefolge '30' '30' '31'. + +Fehlen die Angaben für den Signaturschlüssel (CA Record der Länge 12 Byte) so +werden als Schlüsselnummer und Schlüsselversion des Signaturschlüssels die +Schlüsselnummer und Schlüsselversion des Signierschlüssels übernommen. + +Fehlt der Teilrecord mit dem Tag 'CA' (nicht vorhandener Record E3 oder Record +CA oder fehlendes EF_NOTEPAD) und liegen somit weder für den Signierschlüssel +und den Chiffrierschlüssel noch für den Signaturschlüssel Schlüsselnummer und +Schlüsselversion vor so sind vom FinTS-Client die Schlüsselnummern und Schlüs- +selversionen aller Schlüssel nach folgenden Mechanismen vorzubesetzen. + +Die Schlüsselnummer wird gemäß dem genutzten RAH- bzw. RDH-Verfahren be- +setzt. Die Schlüsselversion wird gängigerweise im ersten Ausgabejahr mit "001" +vorbesetzt und anschließend im jährlichen Turnus um 1 erhöht. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
RDH VerfahrenSchlüsselnummerSchlüsselversion
RDH3"003" → '30' '30' 33'"001" → '30' '30' '31'
RDH5"005" → '30' '30' 35'"001" → '30' '30' '31'
RDH6"006" → '30' '30' 36'"001" → '30' '30' '31'
RAH7, RDH7"007" → '30' '30' 37'"001" → '30' '30' '31'
RDH8"008" → '30' '30' 38'"001" → '30' '30' '31'
RAH9, RDH9"009" → '30' '30' 39'"001" → '30' '30' '31'
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionC
Kapitel:ChipapplikationenStand:Seite:
Abschnitt:Chipapplikation für RAH / RDH18.07.201389
+ + + + + + + + + + + + + +
RDH VerfahrenSchlüsselnummerSchlüsselversion
RAH10, RDH10"010" → '30' '31' 30'"001" → '30' '30' '31'
+ + +![](figures/103.1) + + +Über die Schlüsselnummer im EF_NOTEPAD kann das zu verwen- +dende Sicherheitsprofil ermittelt werden. + +Wichtiger Hinweis: + +Bei allen Verfahren ab RDH-3 müssen für die Schlüsselnummer die +entsprechenden Werte aus der obigen Tabelle verwendet werden. +Die Nutzung von Schlüsselnummer ,,001" ist nicht erlaubt. + +Ein HBCI-Kundenparameterblock belegt inklusive der Tag- und Längenbytes somit +maximal 86 Byte. + + +## C.1.2.2.6 Beispiel + +Beispiel für eine Recordbelegung für V001 (Tags und Längenbytes sind fett mar- +kiert) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
InhaltErläuterung
F0 81 76HBCI-Parameterblock
E1 3DInstitutsparameterblock
C1 0C 54 45 53 54 49 4E 53 54 49 54 55 54Institutsbezeichnung "TESTINSTITUT"
C2 03 32 38 30Länderkennzeichen "280"
C3 08 31 32 33 34 35 36 37 38BLZ 12345678
C4 1B 30 30 31 30 30 31 02 01 02
03 04 05 06 07 08 09 0A 0B
0C 0D 0E 0F 10 11 12 13 14		Schlüsselnummer 1, Schlüssel- version 1, Hashverfahren RIPEMD-160, Hashwert
C5 01 01Schlüsselstatus '01'
E2 12Kommunikationsparameterblock
C5 01 02Kommunikationsdienst TCP/IP
C6 0D 31 39 32 2E 31 36 38 2E 31 31 2E 32 32Kommunikationsadresse 192.168.11.22
E3 21Kundenparameterblock
C8 0A 31 32 33 34 35 36 37 38 39 30Benutzerkennung "1234567890"
C9 05 31 32 33 34 35Kunden-ID "12345"
CA 0C 30 30 31 30 30 31 30 30 31 30 30 31Info Inhaberschlüssel Schlüsselnummer SIG 1, Schlüsselversion SIG 1 Schlüsselnummer CHIF 1, Schlüsselversion CHIF 1
+ + +### C.1.2.2.7 Erreichen der maximalen Recordlänge + +Bei Ausnutzung aller Maximallängen und Aufnahme aller optionalen Felder und Angabe +zweier Kommunikationsparameterblöcke und eines Kundenparameterblocks ergibt sich ein +maximaler Platzbedarf von 297 Byte. Dieser Platzbedarf ist aber in einem Record nicht ab- +bildbar. Normalerweise wird aber nur ein Kommunikationsparameterblock verwendet sowie + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite: 90Stand: 18.07.2013Kapitel: Chipapplikationen
Abschnitt: Chipapplikation für RAH / RDH
+ + +selten alle Maximallängen ausgereizt, so dass meistens die maximale Recordlänge von 239 +Byte genügt. Bei älteren bereits ausgegebenen Bankensignaturkarten ist nur eine maximale +Recordlänge von 200 Byte vorgesehen. + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: C
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final Version
Kapitel:ChipapplikationenStand:Seite:
Abschnitt:Chipapplikation für RAH / RDH18.07.201391
+ + +## C.1.3 Terminalabläufe + +Dieses Kapitel spezifiziert die Terminalabläufe im Umgang mit dem RAH- bzw. +RDH-Verfahren auf SECCOS-Chipkarten [SECCOS] bzw. [SECCOS-6]. Ein Online- +Banking-Kundenprodukt nutzt + +• zur Verschlüsselung und Signierung von HBCI-Nachrichten die auf der Chipkarte +zur Verfügung stehende Signatur-Anwendung (DF_SIG, [ZKASIG]) und die durch +das Betriebssystem bereitgestellten Signatur-Funktionen, + +· als Sequenzzähler (Signatur-ID) interne Bedienungszähler der Signatur- +Anwendung (siehe Kap. C.1.3.1), + +• als Datenspeicher für die Zugangsdaten ein auf der Chipkarte optional vorhan- +denes DF_NOTEPAD ([DF_NOTEPAD], siehe Kap. C.1.1). + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:
92		Stand: 18.07.2013Kapitel: Chipapplikationen
Abschnitt: Chipapplikation für RAH / RDH
+ + +### C.1.3.1 Verfahren zur Ermittlung der Sicherheitsreferenznummern + +Auf der Bankensignaturkarte wird kein eigenständiger Sequenzzähler (wie das Ele- +ment EF_SEQ im HBCI DDV-Verfahren) verwaltet, sondern es werden jeweils chip- +karteninterne ,,Usage Counter" der beiden zur Signatur verwendeten Schlüssel +SK.CH.DS und SK.CH.AUT c/s herangezogen. + +Für jedes Signaturschlüsselpaar wird ein separater Usage Counter verwaltet.Dieser +kann jeweils zwei, drei oder vier Byte lang sein. + +Da die Usage Counter auf der Chipkarte dekrementiert werden, als Sicherheitsrefe- +renznummer (,Signatur-ID“) aber ein streng monoton aufsteigender Zähler gefordert +ist, wird die konkrete Sicherheitsreferenznummer nach folgendem Algorithmus er- +mittelt: + +1\. Auslesen des 2 bis 4 Byte langen Usage Counter (UC) UCDs des Schlüssels +Sk.CH.DS bzw. UCAUT des Schlüssels Sk.CH.AUT c/s. + +2\. Sei neg(UC) die bitweise logische Negation von UC. Dann ist die Sicherheitsrefe- +renznummer (SRN) + +SRNDS = neg(UCDS) +SRNAUT = neg(UCAUT) + +Die einzelnen Usage Counter haben folgende Wertebereiche: + +von 0 bis 65.535 +bei Länge(UC) = 2 Byte + +von 0 bis 16.777.215 +bei Länge(UC) = 3 Byte + +von 0 bis 4.294.967.295 +bei Länge(UC) = 4 Byte + +Damit muss die Sicherheitsreferenznummer SRN über die entsprechenden Wer- +tebereiche verfügen und benötigt zur Darstellung ebenfalls mindestens 2, 3 oder 4 +Byte. + +Ein Wrap-Around bei Erreichen des jeweiligen Maximalwerts findet nicht statt, da +das Erreichen eines Usage Counter 0 den Schlüssel der Chipkarte für die weitere +Verwendung sperrt. + +Beispiel: + +UCDS = '00 0A' (dezimal 10) ⇒ SRNDS = neg(UCDS) = 'FF F5' (dezimal 65.525) + +UCAUT = 'FA 1D' (dezimal 64.029) ⇒ SRNAUT = neg(UCAUT) = '05 E2'(dezimal 1506) + +Dieser Algorithmus ist in der jeweiligen Anwendungssoftware zu realisieren. + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: C
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final Version
Kapitel:ChipapplikationenStand:Seite:
Abschnitt:Chipapplikation für RAH / RDH18.07.201393
+ + +### C.1.3.2 Beschreibung der Terminalabläufe + +Nachfolgend werden die Anwendungsabläufe aus Endgerätesicht an einem privaten +Signaturterminal [KT-KONZEPT] spezifiziert. Hierbei werden ausschließlich die +chipkartenbezogenen Aspekte berücksichtigt. Anwendungsbezogene Details sind +nicht Bestandteil dieser Spezifikation. + +Um die Abläufe möglichst einfach beschreiben zu können, werden in der nachfol- +genden Beschreibung Befehle der ZKA-SIG-API [KT-SIG] verwendet. Hiermit ist je- +doch die Verwendung der ZKA-SIG-API für technische Implementierungen nicht +zwingend vorgeschrieben. Wird die ZKA-SIG-API nicht verwendet, so sind die in +[KT-SIG] angegebenen Abläufe zum Aufruf der KT-Kommandos zu berücksichtigen. + +Die Anwendungsabläufe lassen sich auch auf öffentliche Signaturterminals (Ge- +schäftsterminals) erweitern. Zu beachten ist dabei insbesondere, dass in diesem +Fall zusätzlich eine + +. Komponenten-Authentikation zwischen Chipkarte und Geschäftsterminal mit +Aushandlung eines Sessionkey-Paares (SK1, SK2) stattfindet; + +· alle Befehle an die Chipkarte im Secure Messaging mit einem SK2-MAC durch- +geführt werden müssen. + +Falls bei der Ausführung der Kommandos ein Fehler auftritt, bricht das Terminal den +Vorgang ab, es sei denn, es ist ein abweichendes Verhalten spezifiziert. + + +![](figures/107.1) + + +In den hier beschriebenen Abläufen ist das Kundenterminal durch +ein zka_sig_open (zu Beginn des Ablaufs „Signatur einleiten“) und +ein zka_sig_close (Am Ende des Ablaufs ,,Signatur beenden“) für +die gesamte Zeitdauer exklusiv für die Kundenanwendung reser- +viert. + +Um zwischenzeitlich anderen Anwendungen die Möglichkeit zu ge- +ben, die Signaturdienste der Karte zu nutzen (z.B. für die Zeitdauer +der Nachrichtengenerierung), können die im Folgenden beschriebe- +nen Teilabläufe jeweils auch durch ein zka_sig_open und ein +zka_sig_close gekapselt werden. Dadurch wird die exklusive Re- +servierung des Kundenterminals aufgehoben, die internen Zwi- +schenwerte der ZKA-SIG-API (insbes. der Chipdaten) bleiben je- +doch erhalten. Erst durch Aufruf des +zka_sig_fini_signature_application im Ablauf ,,Signatur beenden“ +werden die internen Zwischenwerte der ZKA-SIG-API gelöscht. + + +![](figures/107.2) + + +Zur Administration der Signaturkarten (z.B. Freischalten eines Zerti- +fikates, Rücksetzen des Fehlbedienungszählers) werden von den +Kreditinstituten bzw. den Kartenemittenten Softwarekomponenten +zur Verfügung gestellt werden, die in der privaten Kundenumgebung +zum Einsatz kommen sollen. In Kundenprodukten, die nicht von den +Kartenemittenten herausgegeben werden, sollen diese Administra- +tionsfunktionen nicht realisiert werden. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:
94		Stand:
18.07.2013		Kapitel: Chipapplikationen
Abschnitt: Chipapplikation für RAH / RDH
+ + +![](figures/108.1) + + +Für die kreditinstitutsseitige Realisierung dieser Softwarekomponen- +ten hat der ZKA Anforderungen und Festlegungen formuliert, die bei +Bedarf über die jeweiligen Ansprechpartner der Standards erhältlich +sind. + + +#### C.1.3.2.1 Signatur einleiten + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ChipkarteEndgerät
M1Aufruf der ZKA-SIG-API-Funktion zka_sig_open
R2OK←
→
←
→
← →
← →		M2Aufruf der ZKA-SIG-API-Funktion zka_sig_init_signature_application
R3OKM3Aufruf der ZKA-SIG-API-Funktion zka_sig_verify_CSA_password
R4OK / ,File not found"C4SELECT FILE DF_NOTEPAD
R5BankverbindungC5
A5		ggf. READ RECORD EF_NOTEPAD
Daten prüfen und speichern
+ + +## ◆ Erläuterung + +1\. Die ZKA-SIG-API-Funktion zka_sig_open wird ausgeführt. Diese Funktion stellt +eine exklusive Verbindung zum Kundenterminal her. + +2\. Die ZKA-SIG-API-Funktion zka_sig_init_signature_application wird ausgeführt. +Diese sorgt insbesondere für ein Reset der Karte und das Auslesen der relevan- +ten Basisinformationen der Karte. + +3\. Die ZKA-SIG-API-Funktion zka_sig_verify_CSA_password wird ausgeführt. Die- +se Funktion liest das CSA-Passwort ein und führt eine Verifikation gegenüber der +Chipkarte durch. + +4\. Die Applikation ,,Notepad" wird geöffnet, indem das ADF der Applikation, +DF_NOTEPAD durch das Terminal mittels des Kommandos SELECT FILE ausge- +wählt wird. + + +## . Command APDU + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ByteWertErläuterung
1-2'00 A4'CLA, INS
3'04'P1, Selektion mit DF-Name
4'0C'P2, Keine Antwortdaten
5'09'Lc
6-14'D2 76 00 00 25 4E 50 01 00'AID der Notepad-Applikation
+ + +Wenn die Notepad-Applikation auf der Karte nicht vorhanden ist, wird der folgen- +de Schritt übersprungen. In diesem Fall müssen die Zugangsdaten von einer an- +deren Stelle gelesen oder vom Benutzer eingegeben werden. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionC
Kapitel:ChipapplikationenStand:Seite:
Abschnitt:Chipapplikation für RAH / RDH18.07.201395
+ + +4\. Das Terminal liest mittels READ RECORD sukzessive die Bankverbindungsdaten +in den Records des EF_NOTEPAD (SFI '1A'), bis der oder die "passenden" Ein- +träge gefunden wurden. Das Lesen von Einträgen ist erst nach erfolgreicher +CSA-Passwort-Verifikation (Schritt 2) möglich. + + +## . Command APDU + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ByteWertErläuterung
1-2'00 B2'CLA, INS
3'0X'P1, Recordnummer X
4'D4'P2, Reference Control Byte
5'00'Le
+ + +Wenn das READ RECORD erfolgreich ausgeführt wird, gibt die Chipkarte eine Ant- +wortnachricht mit der folgenden Struktur zurück: + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ByteLängeWertErläuterung
1-22'XX LL'Kennung und Länge
3-LLLL'XX..XX'Nutzdaten
(LL+1)- (LL+2)2'XX XX'Positiver Returncode SW1 SW2
+ + +Ist die Kennung ungleich '00', so sind Parameterdaten gemäß Kap. C.1.1 enthalten. +Es werden alle weiteren Records gelesen, bis die Chipkarte das Ende der Datei +(keine weiteren Records) signalisiert. + +Anstatt alle Records auszulesen und auf Übereinstimmung mit der Kennung zu +überprüfen, kann alternativ auch das Kommando SEARCH RECORD verwendet wer- +den, um mittels eines übergebenen Suchmusters vorab die "passenden" Record- +nummern in einem Schritt zu finden. Anschließend müssen dann nur diese Record- +nummern mittels READ RECORD ausgelesen werden. + + +## . Command APDU + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ByteWertErläuterung
1-2'00 A2'CLA, INS für SEARCH RECORD
3'01'P1, Start mit Recordnummer 1
4'D7'P2, spezifische Suche im SFI '1A'
5'04'Lc
6'04'CTRLB
7'00'Offset Indicator Byte
8'02'Konfigurationsbyte
9'FO'Suchmuster
10'00'Le
+ + +Wenn das SEARCH RECORD erfolgreich ausgeführt wird, gibt die Chipkarte eine Ant- +wortnachricht mit der folgenden Struktur zurück: + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ByteLängeWertErläuterung
1-nn'XX XX'Recordnummer(n)
n+11'XX'Statusbyte SW1
n+21'XX'Statusbyte SW2
+ + +Es können nun gezielt nur die in der Antwortnachricht angegebenen Records aus- +gelesen werden. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:
96		Stand: 18.07.2013Kapitel: Chipapplikationen
Abschnitt: Chipapplikation für RAH / RDH
+ + +### C.1.3.2.2 Nachrichten generieren + +Dieser Teil des Gesamtablaufs ist nur insofern chipkartenrelevant, als (optional) +Bankverbindungsdaten, die für die Auftragsgenerierung benötigt werden, aus der +Chipkarte entnommen werden. Dies ist bereits im Schritt ,Signatur einleiten“ (Kap. +C.1.3.2.1) geschehen. Für die folgende Ablaufbeschreibung wird angenommen, +dass die Anwendung bereits Auftrags-Nachrichten generiert hat. Diese Nachrichten +müssen jetzt ggf. noch kryptographisch gesichert werden, d.h. es werden Segmente +für die elektronische(n) Signatur(en) und für die Verschlüsselung entsprechend den +jeweiligen Spezifikationen eingefügt. + + +#### C.1.3.2.3 Nachrichten signieren + + +##### C.1.3.2.3.1 Nachrichten signieren bei HBCI + +Die folgenden Abläufe können im Falle von HBCI offline, d.h. außerhalb des Über- +tragungsdialogs vollzogen werden. Dies gilt für alle Nachrichten mit Ausnahme der +Dialoginitialisierung. Der Grund besteht darin, dass für die Absicherung aller Kredit- +institutsnachrichten der Schlüssel des Senders der Dialoginitialisierungsnachricht +erforderlich ist. Daher muss auch die Chipkarte des Senders während des gesam- +ten Dialogs im Endgerät stecken. + +Die Abläufe für die Signatur der Dialoginitialisierungsnachricht sind grundsätzlich +identisch mit den im Folgenden beschriebenen Abläufen für die Signatur von Auf- +tragsnachrichten. Da aber für die Dialoginitialisierung anwendungsseitig noch weite- +re Chipkartendaten (Benutzerkennung, Dialog-ID, Kommunikationszugang etc.) be- +nötigt werden, wird der komplette Ablauf einschließlich der Signatur der Dialoginitia- +lisierung im Kap. C.1.3.2.6 "Übertragungsdialog" noch einmal beschrieben. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ChipkarteEndgerät
R1BZ↑ ↓M1Sequenzzähler (Signatur-ID) ermitteln durch Aufruf der ZKA- SIG-API-Funktion zka_sig_read_key_usage_counter und an- schließende Invertierung des Rückgabewerts gemäß Abschnitt C.1.3.1)
A2Signaturkopf aufbauen und in HBCI-Nachricht einfügen
A3Daten (Signaturkopf, HBCI-Nutzdaten) für Signatur bereitstellen
↑ ↓M4Signaturerstellung (siehe Kap. C.1.3.3.1)
A5Signaturabschluss aufbauen und in HBCI-Nachricht einfügen
A6ggf. M1 bis A5 für weitere Nachrichten wiederholen
A7signierte HBCI-Nachrichten zur Weiterverarbeitung speichern
+ + +## ◆ Erläuterung + +1\. Der Sequenzzähler (Signatur-ID) wird durch Auslesen der Bedienungszähler der +Signaturanwendung und anschließende Berechnung ermittelt. Das Auslesen er- +folgt durch Aufruf der ZKA-SIG-API-Funktion zka_sig_read_key_usage_counter +mit der Parameterbelegung + +. counter_type = '00' bei Verwendung des Sk.CH.DS, bzw. + +. counter_type = '02' bei Verwendung des SK.CH.AUT c/S + +Das Ergebnis BZ wird gemäß Kap. C.1.3.1 zu SZ = neg(BZ) invertiert und als +Sequenzzähler gespeichert. + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: C
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final Version
Kapitel:ChipapplikationenStand:Seite:
Abschnitt:Chipapplikation für RAH / RDH18.07.201397
+ + +2\. Der Signaturkopf wird aufgebaut und in die HBCI-Nachricht eingefügt. + +3\. Die Daten (Signaturkopf, HBCI-Nutzdaten) für die Signaturerstellung werden be- +reitgestellt. + +4\. Die Signatur wird berechnet (siehe hierzu Kap. C.1.3.3). + +5\. Der Signaturabschluss wird aufgebaut und in die HBCI-Nachricht eingefügt. + +6\. Ggf. können die Schritte 1 bis 5 für weitere Nachrichten wiederholt werden. + +7\. Die signierten HBCI-Nachrichten können zur Weiterverarbeitung gespeichert +werden. + +Anmerkung: Für Mehrfachsignaturen wird jeweils die Abfolge „Signatur einleiten“ – +,Nachrichten signieren“ - ,Signatur beenden" wiederholt. Dies kann auch zu einem +späteren Zeitpunkt geschehen. Mehrfachsignaturen müssen jedoch abgeschlossen +sein, bevor die Verschlüsselung der Nachricht (Kap. C.1.3.2.4) durchgeführt wird. + + +### C.1.3.2.4 Nachrichten verschlüsseln + + +#### C.1.3.2.5 Nachrichten verschlüsseln bei RAH + +Die Chipkarte ist bei der eigentlichen Nachrichtenverschlüsselung nicht involviert. +Die Software berechnet einen Einmalschlüssel, verschlüsselt das Dokument und +verschlüsselt den Einmalschlüssel zur Übertragung mit dem öffentlichen Key- +Encryption-Schlüssel PK.RECVINST.KE des empfangenden Kreditinstituts, welches +dem entsprechenden Zertifikat des Empfängers entnommen wurde10. + +Allerdings wird die Chipkarte zur Berechnung von Zufallszahlen herangezogen, wel- +che den Einmalschlüssel bilden. + + + + + + + + + + + + + + + + + + + +
Kapitel:
C		Version: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:
98		Stand:
18.07.2013		Kapitel: Chipapplikationen
Abschnitt:
Chipapplikation für RAH / RDH
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ChipkarteEndgerät
↓↑ ↓↑ ↓↑ ↓↑
![](figures/112.1)		A1Daten (FinTS-Nutzdaten und ggf. Signatur) für die Verschlüsse- lung bereitstellen
R2RNDC2
A2		Aufruf der ZKA-SIG-API-Funktion zka sig_get_challenge
RND als Einmalschlüssel-Fragment KSL speichern
R3RNDC3
A3		Aufruf der ZKA-SIG-API-Funktion zka sig get challenge
RND als Einmalschlüssel-Fragment KSLR speichern
R4RNDC4
A4		Aufruf der ZKA-SIG-API-Funktion zka sig get challenge
RND als Einmalschlüssel-Fragment KSRL speichern
R5RNDC5
A5		Aufruf der ZKA-SIG-API-Funktion zka sig_get challenge
RND als Einmalschlüssel-Fragment KSRR speichern
A6KSL, KS R, KSRL und KSRR zu KS konkatenieren und speichern
A7Daten mit KS (symmetrisch) verschlüsseln
A8KS mit PK.RECVINST.KE (asymmetrisch) verschlüsseln
A9Verschlüsselungsdaten aufbauen und in FinTS-Nachricht einfü- gen
A10Verschlüsselte Daten als Binärdaten in Verschlüsselungsdaten einfügen
A11ggf. A1 bis A10 für weitere Nachrichten wiederholen
A12Verschlüsselte und signierte FinTS-Nachrichten zur weiteren Be- arbeitung speichern
+ + +# Erläuterung + +1\. Die Daten (FinTS-Nutzdaten und ggf. Signatur) für die Verschlüsselung werden be- +reitgestellt. + +2\. Mit dem Aufruf der ZKA-SIG-API-Funktion zka sig get challenge lasst sich das +Terminal eine Zufallszahl von der HBCI-Karte geben. + +Wenn das Kommando erfolgreich ausgeführt wurde, gibt die HBCI-Karte eine 8 Byte +lange Zufallszahl als Antwortdatum aus, die als Einmalschlüssel-Fragment KSLL ge- +speichert wird. + +3\. Mit dem Aufruf der ZKA-SIG-API-Funktion zka sig get challenge lasst sich das +Terminal eine zweite Zufallszahl von der HBCI-Karte geben, die als Einmalschlüssel- +Fragment KSLR gespeichert wird. + +4\. Mit dem Aufruf der ZKA-SIG-API-Funktion zka sig get challenge lasst sich das +Terminal eine dritte Zufallszahl von der HBCI-Karte geben, die als Einmalschlüssel- +Fragment KSRL gespeichert wird. + +5\. Mit dem Aufruf der ZKA-SIG-API-Funktion zka sig get challenge lasst sich das +Terminal eine vierte Zufallszahl von der HBCI-Karte geben, die als Einmalschlüssel- +Fragment KSLL gespeichert wird. + +6\. KSLL, KSLR, KSRL, und KSRR, werden zu KS konkateniert und gespeichert. + +7\. Die zu übertragenden Daten werden mit KS symmetrisch verschlüsselt (AES CBC- +Mode, IV=0, ZKA-Padding). + +8\. Der Einmalschlüssel KS wird linksbundig mit Nullbits auf die Schlussellänge aufge- +füllt und anschließend mit dem öffentlichen Key-Encryption-Schlüssel + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionC
Kapitel:ChipapplikationenStand:Seite:
Abschnitt:Chipapplikation für RAH / RDH18.07.201399
+ + +PK.RECVINST.KE des empfangenden Instituts, welches dem entsprechenden Zertifikat +des Empfängers entnommen wurde, verschlusselt. Das Ergebnis wird mit fuhrenden +Nullbits auf die Schlüssellänge erweitert. + +9\. Die Verschlüsselungsdaten werden aufgebaut und in die FinTS-Nachricht eingefügt. + +10\. Die verschlüsselten Daten als Binärdaten in die Verschlüsselungsdaten eingefügt. + +11\. Ggf. werden die Schritte 1 bis 10 für weitere Nachrichten wiederholt. + +12\. Die verschlüsselten und signierten FinTS-Nachrichten werden zur weiteren Bearbei- +tung gespeichert. + + +## C.1.3.2.5.1 Nachrichten verschlüsseln bei DDV und RDH + +Die Chipkarte ist bei der eigentlichen Nachrichtenverschlüsselung nicht involviert. +Die Software berechnet einen Nachrichtenschlüssel, verschlüsselt das Dokument +und verschlüsselt den Nachrichtenschlüssel zur Übertragung mit dem öffentlichen +Key-Encryption-Schlüssel PK.RECVINST.KE des empfangenden Instituts, welches der +übermittelten Kreditinstitutsnachricht entnommen wurde11. + +Allerdings wird die Chipkarte zur Berechnung von Zufallszahlen herangezogen, wel- +che den Nachrichtenschlüssel bilden. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ChipkarteEndgerät
A1Daten (FinTS-Nutzdaten und ggf. Signaturkopf/-abschluss) für die Verschlüsselung bereitstellen
R2RND↓↑ ↓↑C2
A2
C3		Aufruf der ZKA-SIG-API-Funktion zka_sig_get_challenge
RND als Nachrichtenschlüssel-Hälfte KSL speichern
Aufruf der ZKA-SIG-API-Funktion zka_sig_get_challenge
R3RNDA3RND als Nachrichtenschlüssel-Hälfte KSR speichern
A4KSL mit KSR zu KS konkatenieren und speichern
A5KS auf Eigenschaft ,(halb-)schwacher Schlüssel“ überprüfen und ggfs. Schritte 2-4 wiederholen.
A6Herstellung der Parität für KS (Parity Adjustment)
A7Daten mit KS (symmetrisch) verschlüsseln
A8KS mit PK.RECVINST.KE (asymmetrisch) verschlüsseln
A9Verschlüsselungskopf aufbauen und in FinTS-Nachricht einfügen
A10Verschlüsselte Daten als Binärdaten in FinTS-Nachricht einfügen
A11ggf. A1 bis A10 für weitere Nachrichten wiederholen
A12Verschlüsselte und signierte FinTS-Meldungen zur weiteren Be- arbeitung speichern
+ + +# ◆ Erläuterung + +1\. Die Daten (FinTS-Nutzdaten und ggf. Signaturkopf/-abschluss) für die Verschlüs- +selung werden bereitgestellt. + + + + + + + + + + + + + + + + +
Kapitel:
C		Version: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:
100		Stand:
18.07.2013		Kapitel: Chipapplikationen
Abschnitt: Chipapplikation für RAH / RDH
+ + +2\. Mit dem Aufruf der ZKA-SIG-API-Funktion zka_sig_get_challenge lässt sich das +Terminal eine Zufallszahl von der HBCI-Karte geben. + +Wenn das Kommando erfolgreich ausgeführt wurde, gibt die HBCI-Karte eine Zu- +fallszahl als Antwortdatum aus, die als Nachrichtenschlüssel-Hälfte KSL gespei- +chert wird. + +3\. Mit dem Aufruf der ZKA-SIG-API-Funktion zka_sig_get_challenge lässt sich das +Terminal eine weitere Zufallszahl von der HBCI-Karte geben, die als Nachrich- +tenschlüssel-Hälfte KSR gespeichert wird. + +4\. KSL wird mit KSR zu KS konkateniert und gespeichert. + +5\. KS wird auf die Eigenschaft „(halb-)schwacher Schlüssel“ überprüft. Liegt ein +(halb-)schwacher Schlüssel vor, so wird Schritt 2-4 wiederholt. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Schwache Schlüssel des DES:
0101010101010101
FEFEFEFEFEFEFEFE
1F1F1F1F0E0E0E0E
E0E0E0E0F1F1F1F1
+ + +Halbschwache Schlüssel des DES: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
01FE01FE01FE01FE
FE01FE01FE01FE01
1FE01FE00EF10EF1
E01FE01FF10EF10E
01E001E001F101F1
E001E001F101F101
1FFE1FFE0EFE0EFE
FE1FFE1FFE0EFE0E
011F011F010E010E
1F011F010E010E01
E0FEE0FEF1FEF1FE
FEE0FEE0FEF1FEF1
+ + +6\. Für KS wird_ein Parity Adjustment durchgeführt. Das Resultat ist der zu ver- +wendende Nachrichtenschlüssel. + +7\. Die zu übertragenden Daten werden mit KS symmetrisch verschlüsselt. + +8\. Der Nachrichtenschlüssel KS wird gemäß Paddingverfahren für das entspre- +chende Sicherheitsprofil auf die Länge des öffentlichen Key-Encryption- +Schlüssels PK.RECVINST.K des empfangenden Instituts, welches der übermittel- +ten Kreditinstitutsnachricht entnommen wurde, aufgefüllt und anschlieBend mit +dem PK.RECVINST.K verschlüsselt.. Stimmt das Verschlüsselungsergebnis mit +dem Ausgangswert überein, werden die Schritte 2 bis 8 wiederholt (Generie- +rung eines neuen Schlüssels); ansonsten wird Das Ergebnis wird mit führenden +Nullbits auf die Schlüssellänge erweitert. und es wird mit dem folgenden Schritt +9 fortgefahren. + +9\. Der Verschlüsselungskopf wird aufgebaut und in die FinTS-Nachricht eingefügt. + +10\. Die verschlüsselten Daten als Binärdaten in die FinTS-Nachricht eingefügt. + +11\. Ggf. werden die Schritte 1 bis 10 für weitere Nachrichten wiederholt. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionC
Kapitel:ChipapplikationenStand:Seite:
Abschnitt:Chipapplikation für RAH / RDH18.07.2013101
+ + +12\. Die verschlüsselten und signierten FinTS-Meldungen werden zur weiteren Be- +arbeitung gespeichert. + + +## C.1.3.2.6 Übertragungsdialog + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Chipkarte
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
↑↓
↑↓		EndgerätKreditinstitut
A1Benutzerkennung aus der bereits gelese- nen Bankverbindung extrahieren↑↓
M2Nachricht signieren (s. Kap. C.1.3.2.3)
A3Kommunikationszugang aus Bankverbin- dung herstellen
C4Nachricht (beginnend mit Dialoginitialisie- rungsnachricht) sendenR4Antwort- nachricht
A5falls Antwortnachricht verschlüsselt: Daten (Binärdaten nach dem Verschlüsse- lungskopf) und verschlüsselten Session- Key enc(KS) aus dem Signaturkopf für die Entschlüsselung bereitstellen
M6Ausführung der ZKA-SIG-API-Funktion zka_sig_decrypt zur Session-Key- Entschlüsselung, Resultat ist der Session- Key KS
A7Daten mit Session-Key KS entschlüsseln.
A8falls Kreditinstitutsnachricht signiert: Daten (Signaturkopf, Nutzdaten, Signatur) für Signatur-Prüfung bereitstellen
M9Signatur-Prüfung (siehe KapC.1.3.3.2)
A10C4 bis M9 für alle weiteren HBCI-Nach- richten wiederholen
+ + +### C.1.3.2.7 Signatur beenden + + + + + + + + + + + + + + + + + + + + + + +
ChipkarteEndgerät
M1Aufruf der ZKA-SIG-API-Funktion zka_sig_fini_signature_application
M2Aufruf der ZKA-SIG-API-Funktion zka_sig_close
+ + +#### ◆ Erläuterung + +1\. Die ZKA-SIG-API-Funktion zka_sig_fini_signature_application wird ausgeführt. +Diese Funktion setzt die ZKA-SIG-API in den Zustand ,,passiv“ und löscht die da- +rin gespeicherten Werte. + +2\. Die ZKA-SIG-API-Funktion zka_sig_close gibt die Verbindung zum Kundentermi- +nal wieder frei. + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:
102		Stand: 18.07.2013Kapitel: Chipapplikationen
Abschnitt: Chipapplikation für RAH / RDH
+ + +### C.1.3.3 Makros + + +#### C.1.3.3.1 Signatur-Berechnung + +Signaturen mit der Chipkarte werden im Rahmen der beiden Sicherheitsdienste „Au- +thentication" und ,,Non-Repudiation“ erzeugt. + +. Sicherheitsdienst Authentication: Signatur mit Schlüssel SK.CH.AUT c/s (Client- +Server-Authentikations-Schlüssel) + +. Sicherheitsdienst Non-Repudiation: Signatur mit Schlüssel SK.CH.DS (Digitaler +Signatur-Schlüssel) + +Die tatsächliche Durchführung der Signatur durch die Chipkarte ist insbesondere an +die Erfüllung von Zugriffsbedingungen geknüpft, hier ist dies insbesondere eine vor- +hergehende Benutzer-Authentikation in Form der Verifikation + +· des CSA-Passworts für die Erlaubnis zur Signatur mit dem Schlüssel +SK.CH.AUT C/S + +• der Signatur-PIN für die Erlaubnis zur Signatur mit dem Schlüssel Sk.CH.DS + +Durch einen in der Chipkarte personalisierten Parameter der Signatur-Anwendung +[ZKASIG] wird dabei festgelegt, nach wie vielen elektronischen Signaturen spätes- +tens die Benutzer-Authentikation zu wiederholen ist. Eine Benutzer-Authentikation +wird bei Bedarf innerhalb der ZKA-SIG-API-Funktionen zka_sig_digital_signature +bzw. zka_sig_cs_authentication durchgeführt. + + + + + + + + + + + + + + +
Chipkarte
R1evtl. Hash- wert
R2a
R2b		Signatur
Signatur
+ + +← +→ +← +→ + +← + +→ + + + + + + + + + + + + + + + + + + +
Endgerät
M1Hashwert HASH berechnen, optional unter Verwendung der ZKA-SIG-API-Funktion zka_sig_hash
M2aSicherheitsdienst Non-Repudiation: Aufruf der ZKA-SIG-API- Funktion zka_sig_digital_signature
oder:
M2bSicherheitsdienst Authentication: Aufruf der ZKA-SIG-API- Funktion zka_sig_cs_authentication
+ + +##### ◆ Erläuterung + +1\. Die Berechnung des Hashwertes erfolgt in der Regel außerhalb der Chipkarte +(Hashalgorithmus gemäß Vorgabe für den Sicherheitsdienst bzw. vom Institut +übermittelter BPD). Optional ist es auch möglich, den letzen Schritt oder alle +Schritte der Hashwert-Berechnung durch die Chipkarte durchführen zu lassen. +Diese Berechnung ist dann Bestandteil des Ablaufs der ZKA-SIG-API-Funktion +zka_sig_hash. Der zu verwendende Hash-Algorithmus wird dabei in Form der +zugehörigen OID übergeben: + +• OID = 1.3.14.3.2.26 für SHA-1 + +• OID = 1.3.36.3.2.1 für RIPEMD-160 + +• OID = 2.16.840.1.101.3.4.2.1 für SHA-256 + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionC
Kapitel:ChipapplikationenStand:Seite:
Abschnitt:Chipapplikation für RAH / RDH18.07.2013103
+ + +2a. Bei Verwendung des Schlüssels Sk.CH.DS (Sicherheitsdienst Non-Repudiation) +wird die Signatur durch Aufruf der ZKA-SIG-API-Funktion zka_sig_digital_sig- +nature erzeugt. Die Auswahl des Signaturalgorithmus und Paddingverfahrens +erfolgt gemäß Vorgabe für den Sicherheitsdienst bzw. vom Institut übermittelter +BPD. Die Signaturanwendung der Chipkarte bietet die Verfahren „sha-1- +WithRSAEncryption" (PKCS#1-Signaturverfahren, Standard-RSA, SHA-1) und +,sigS_ISO9796-2rndWithripemd160" (DIN-Signaturverfahren, Standard-RSA, +RIPEMD-160) an. Zusätzlich bieten Banken-Signaturkarten mit SECCOS 6 +auch das Signaturverfahren RSASSA-PSS an. + +Falls der Hashwert im vorangegangenen Schritt 1 durch die Chipkarte berech- +net wurde, ist er noch in der Chipkarte gespeichert und braucht nicht erneut als +Parameter des zka_sig_digital_signature übergeben zu werden. + +2b. Bei Verwendung des Schlüssels SK.CH.AUT c/s (Sicherheitsdienst Authenticati- +on) wird die Signatur durch Aufruf der ZKA-SIG-API-Funktion zka_sig_cs_au- +thentication erzeugt. Die Chipkarte verwendet dabei intern ein Paddingformat +gemäß PKCS#1 ([SECCOS, Kapitel 8.3.2.1]12), wobei die Digest-Info nicht von +der Chipkarte selbst erzeugt wird, sondern als aufbereiteter „Authentication- +Input“ (= zu signierendes Datenfeld) übergeben werden muss. + +Der Authentication-Input ist wie folgt aufgebaut ([SECCOS, Kapitel 8.1.8.3.1]): + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TagLängeWertErläuterung
'30''21' bzw. '31'Tag und Länge von SEQUENCE (SHA-1/RIPEMD-160 bzw. SHA-256)
'30''09' bzw. 'OD'Tag und Länge von SEQUENCE (SHA-1/RIPEMD-160 bzw. SHA-256)
'06''05' bzw. '09''2B 0E 03 02 1A' bzw. '2B 24 03 02 01' bzw. '60 86 48 01 65 03 04 02 01'OID des SHA-1 (1 3 14 3 2 26) bzw. OID des RIPEMD-160 (1 3 36 3 2 1) bzw. OID des SHA-256 (2 16 840 1 101 3 4 2 1)
'05''00'-TLV-Kodierung von NULL
'04''14''XX..XX'Hash-Wert
+ + +Anmerkung: Die direkte Weiterverwendung eines eventuell im Chip berechneten +und dort zwischengespeicherten Hashwerts ist bei der Signatur im Sicherheitsdienst +„Authentication“ nicht möglich. Der Hashwert (als Ergebnis von Schritt 1) muss da- +her explizit als Aufrufparameter in der oben beschriebenen Form in Schritt 2 über- +geben werden. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
BezeichnungByte-LängeWert
Blocktyp1'01'
Paddingfeld (PS)N-3-L'FF...FF'
Separator1'00'
DatenfeldLAuthentication Input (AI)
Kapitel: CVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:
104		Stand: 18.07.2013Kapitel: Chipapplikationen
Abschnitt: Chipapplikation für RAH / RDH
+ + +#### C.1.3.3.2 Signatur-Prüfung + +Die ZKA-Chipkarte selbst unterstützt zurzeit keine Signatur-Prüfung13. Die Prüfung +einer Signatur wird vom Kundenterminal-Makro "Überprüfen der Korrektheit der +elektronischen Unterschrift" durchgeführt. + +Die (mathematische) Korrektheit einer elektronischen Unterschrift wird überprüft, in +dem sie mit dem entsprechenden öffentlichen Schlüssel entschlüsselt wird und das +Ergebnis mit dem Hashwert über die signierten Daten verglichen wird. Der für die +Überprüfung der elektronischen Signatur eingesetzte öffentliche Schlüssel liegt in +dem Kundenterminal authentisch vor, falls die zu ihm gehörende Zertifikatshierar- +chie vorher ebenfalls in dem Kundenterminal überprüft wurde [KT-KONZEPT]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionC
Kapitel:ChipapplikationenStand:Seite:
Abschnitt:Chipapplikation für DDV18.07.2013105
+ + +##### C.2 Chipapplikation für DDV + +Im Folgenden wird für das in Kap. B beschriebene DDV-Verfahren eine entspre- +chende Chipanwendung namens ,,Banking" synonym ,HBCI-Banking" spezifiziert. +Voraussetzung ist neben den nachfolgend beschriebenen Datenelementen zusätz- +lich das Vorhandensein des Datenelements EF_ID sowie des Kryptoalgorithmus +Triple-DES, wie sie in der ,Schnittstellenspezifikation für die ec-Karte mit Chip" vom +ZKA festgelegt wurden. Die Spezifikation bezieht sich allein auf die für HBCI erfor- +derlichen Datenelemente. + +Die Anwendung ,Banking“ kann auf einer dedizierten Chipkarte (,HBCI-Karte“) oder +auf beliebigen multifunktionalen Chipkarten implementiert werden, sofern sie das +Betriebssystem der ec-Karte mit Chip einsetzen. Für die HBCI-Anwendung ist kein +ausführbarer Code über die Spezifikationen in ISO 7816-4 bzw. der ec-Karte mit +Chip hinaus erforderlich. + +In diesem Kapitel werden die Datenstrukturen und Zugriffsregeln der Chipapplikati- +on "DF_BANKING_20" für Chipkarten vom Typ 1 (,altes ZKA-Betriebssystem") und +Typ SECCOS 6 (,,neues ZKA-Betriebssystem") spezifiziert. Die Kommandoabläufe +im Terminal sind gemeinsam für Chipkarten vom Typ 114 und SECCOS 6 spezifi- +ziert. + +In Kap. C.2.1 wird explizit auf die Beschreibung für Typ 1 eingegangen. Im weiteren +Verlauf dieses Dokuments ist mit "HBCI-Chipkarte" eine Chipkarte mit neuem ZKA- +Betriebssystem gemäß [DATKOM] und [DAT-MF] gemeint, die die HBCI-Applikation +enthält. Weitere Applikationen, wie z.B. die elektronische Geldbörse, sind nicht not- +wendigerweise auf der Chipkarte enthalten. Ebenso kann die Bankensignaturkarte +mit oder ohne Zertifikat ausgeliefert werden. + +Das ADF der Applikation HBCI-Banking wird mit DF_BANKING_20 bezeichnet. In +der vorliegenden Spezifikation ist es direkt im MF enthalten. Die für die Applikation +relevanten DF-spezifischen Schlüssel sind im EF_KEY abgelegt, das direkt im +DF_BANKING_20 enthalten ist. + +In der vorliegenden Spezifikation werden im Kontext von Typ 1-Karten zwei Securi- +ty-Environments verwendet: + +1 Das Security-Environment mit der Nummer 1 (SE #1) als Standard-SE legt die +Zugriffsregeln für die Dateien der Applikation HBCI-Banking für den Anwen- +dungsfall, d.h. für den Zugriff im Feld an HBCI-fähigen Terminals fest. + +2 Das Security-Environment mit der Nummer 2 (SE #2) als Administrations-SE legt +die Zugriffsregeln für die Dateien und das Applikationsverzeichnis der Applikation +HBCI-Banking für den Fall von Administrationsvorgängen, z.B. Kontrolle, Ände- +rungen oder Erweiterungen, fest. + +Die Selektion von SEs erfolgt, wie in [DATKOM] beschrieben, mit dem Kommando +MANAGE SECURITY ENVIRONMENT. Für den Anwendungsfall, d.h. an HBCI- +fähigen Terminals, ist eine Selektion des SE nicht notwendig, da mit der Selektion +einer Applikation implizit das SE #1 aktiviert wird. + + + + + + + + + + + + + + + + + + + + + + + + + +
Kapitel:Version:Financial Transaction Services (FinTS)
C3.0 - Final VersionDokument: Security - Sicherheitsverfahren HBCI
Seite:
106		Stand:Kapitel: Chipapplikationen
18.07.2013Abschnitt: Chipapplikation für DDV
+ + +###### C.2.1 Daten der Applikation HBCI-Banking für Typ 1 + +Die folgende Grafik gibt eine Übersicht über die Dateien einer HBCI-Karte mit der +Applikation HBCI-Banking für Typ 1. + + +Abbildung 19: Datenelemente der Applikation "HBCI", Bankensignaturkarte mit Zerti- +fikat + +![MF EF_KEY EF_KEYD EF_PWD EF_PWDD EF_FBZ EF_ID EF_INFO EF_RULE EF_SIG EF_SIGD DF_BANKING_20 EF_KEY EF_KEYD EF_RULE EF_BNK EF_MAC EF_SEQ EF_PWD EF_PWDD EF_FBZ](figures/120.1) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionC
Kapitel:ChipapplikationenStand:Seite:
Abschnitt:Chipapplikation für DDV18.07.2013107
+ + +Abbildung 20: Datenelemente der Applikation "HBCI", Bankensignaturkarte ohne +Zertifikat + +![MF EF_KEY EF_KEYD EF_ID EF_RULE EF_SIG EF_SIGD DF_BANKING_20 EF_KEY EF_KEYD EF_RULE EF_BNK EF_MAC EF_SEQ EF_PWD EF_PWDD EF_FBZ](figures/121.1) + + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite: 108Stand: 18.07.2013Kapitel: Chipapplikationen
Abschnitt: Chipapplikation für DDV
+ + +####### C.2.1.1 ADF der Applikation HBCI-Banking + +Für das ADF der Applikation HBCI-Banking (DF_BANKING_20) sind beim Anlegen +die folgenden FCP festzulegen: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TagLängeWertErläuterung
'62''1A'Tag und Länge für FCP
'82''01''38'Datei-Deskriptor für DF
'83''02''A6 00'Datei-ID des DF_BANKING_20
'84''09''D2 76 00 00 25 48 42 02 00'DF-Name (AID) des DF_BANKING_20
'A1''06''8B 04 00 30 02 01'Zugriffsregel-Referenzen
+ + +Der DF-Name (die AID) des DF_BANKING_20 bestehend aus der nationalen RID +des ZKA ('D2 76 00 00 25'), der ASCII-kodierten Kennung "HB" ('48 42') sowie der +Version der Applikation 2.0 ('02 00'). + +Die Zugriffsregeln für das DF_BANKING_20 stehen in der zugeordneten Regeldatei +EF_RULE. Durch die Zugriffsregeln werden für die DF-spezifischen Kommandos die +folgenden Festlegungen getroffen: + +Wenn das DF_BANKING_20 selektiert ist, darf ein CREATE FILE (EF), DELETE +FILE (self), INCLUDE oder EXCLUDE nur ausgeführt werden, wenn die Komman- +donachricht mit Secure Messaging ausgeführt wird und mit einem korrekten MAC +versehen ist, der unter Verwendung des Schlüssels KHBCI Admin aus dem EF_KEY +des DF_BANKING_20 gebildet ist. Der Returncode wird für jedes dieser Komman- +dos durch die Karte mit einem MAC mit dem Schlüssel KHBCI_Admin versehen. Die +Kommandos CREATE FILE (DF) und DELETE FILE (child DF) dürfen nie ausge- +führt werden. Alle zulässigen Administrationskommandos dürfen nur im SE #2 aus- +geführt werden (Zugriffsregeln im Record 1 des EF_RULE). + +Der Applikation HBCI-Banking sind 10 Dateien als AEF zuzuordnen: + +SFI '01': +EF_RULE im DF_BANKING_20 + +SFI '02': +EF_KEY im DF_BANKING_20, + +SFI '03': +EF_PWD im DF_BANKING_20, + +SFI '04': +EF_PWDD im DF_BANKING_20, + +SFI '05': +EF_FBZ im DF_BANKING_20, + +SFI '19': +EF_ID im MF, + +SFI '1A': +EF_BNK im DF_BANKING_20, + +SFI '1B': +EF_MAC im DF_BANKING_20, + +SFI '1C': +EF_SEQ im DF_BANKING_20, + +SFI '1E': +EF_KEYD im DF_BANKING_20. + +Wenn das DF_BANKING_20 mittels SELECT FILE selektiert wird und die entspre- +chende Option im Parameterbyte P2 des Kommandos gesetzt ist, wird die folgende +FCI ausgegeben: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TagLängeWertErläuterung
'6F''0D'Tag und Länge für FCI
'84''09''D2 76 00 00 25 48 42 02 00'DF-Name (AID) des DF_BANKING_20
'A5''00'keine proprietären Informationen
Financial Transaction Services (FinTS)Version:Kapitel: C
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final Version
Kapitel:ChipapplikationenStand:Seite:
Abschnitt:Chipapplikation für DDV18.07.2013109
+ + +Wird das DF_BANKING_20 mittels SELECT FILE selektiert und die entsprechende +Option im Parameterbyte P2 des Kommandos gesetzt, werden die folgenden FMD +mit den Pfaden der AEFs ausgegeben (vorausgesetzt, das DF_BANKING_20 befin- +det sich direkt im MF): + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TagLängeWertErläuterung
'64''44'Tag und Länge für FMD
'85''03''C8 00 03'Pfad für AEF mit SFI '19' (EF_ID im MF)
'85''05''08 A6 00 00 30'Pfad für AEF mit SFI '01' (EF_RULE im DF_BANKING_20)
'85''05''10 A6 00 00 10'Pfad für AEF mit SFI '02' (EF_KEY im DF_BANKING_20)
'85''05''18 A6 00 00 12'Pfad für AEF mit SFI '03' (EF_PWD im DF_BANKING_20)
'85''05''20 A6 00 00 15'Pfad für AEF mit SFI '04' (EF_PWDD im DF_BANKING_20)
'85''05''28 A6 00 00 16'Pfad für AEF mit SFI '05' (EF_FBZ im DF_BANKING_20)
'85''05''D0 A6 00 03 01'Pfad für AEF mit SFI '1A' (EF_BNK im DF_BANKING_20)
'85''05''D8 A6 00 03 02'Pfad für AEF mit SFI '1B' (EF_MAC im DF_BANKING_20)
'85''05''E0 A6 00 03 03'Pfad für AEF mit SFI '1C' (EF_SEQ im DF_BANKING_20)
'85''05''F0 A6 00 00 13'Pfad für AEF mit SFI '1E' (EF_KEYD im DF_BANKING_20)
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite: 110Stand: 18.07.2013Kapitel: Chipapplikationen
Abschnitt: Chipapplikation für DDV
+ + +#### C.2.1.2 EF_RULE + + +##### . Beschreibung + +Die Datei EF_RULE enthält die Zugriffsregeln für die Applikation DF_BANKING_20. +In den FCP von Dateien und Verzeichnissen wird auf diese Zugriffsregeln referen- +ziert. + + +##### . Format + +Für das EF_RULE des DF_BANKING_20 sind die folgenden FCP festzulegen: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TagLängeWertErläuterung
'62''1C'Tag und Länge für FCP
'82''05''14 41 00 24 08'Datei-Deskriptor für lineares EF mit variab- ler Recordlänge (max. 36 Byte), 8 Records
'83''02''00 30'Datei-ID des EF_RULE
'85''02''00 7D'für Nutzdaten allokierter Speicherplatz in Byte
'88''01''08'SFI '01' für das EF_RULE
'A1''08''8B 06 00 30 01 02 02 03'Zugriffsregel-Referenzen
+ + +Im SE #1 dürfen nur die Kommandos READ / SEARCH RECORD mit ungesicherter +Kommando und Antwortnachricht ausgeführt werden (Zugriffsregel im Record 2 des +EF_RULE). + +Im SE #2 darf APPEND RECORD nur ausgeführt werden, wenn es mit Secure +Messaging ausgeführt wird. Die MAC-Bildung erfolgt für Kommando- und Antwort- +nachricht mit dem KHBCI_Admin. UPDATE RECORD darf nie ausgeführt werden (Zu- +griffsregel im Record 3 des EF_RULE). + + +##### . Daten + +Das EF_RULE im DF_BANKING_20 enthält 8 Records mit den Zugriffsregeln für +das Verzeichnis und die Datenfelder des Verzeichnisses. + +Die folgende Tabelle zeigt die Belegung dieser Records für eine HBCI-Chipkarte: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Rec.Nr.Record-InhaltByte
1'80 01 DA B4 05 83 03 80 01 FF'10
2'80 01 81 90 00'5
3'80 01 84 B4 05 83 03 80 01 FF'10
4'80 01 86 AF 11 B4 05 83 03 80 01 FF B8 08 95 01 10 83 03 80 01 FF'22
5'80 01 86 B4 05 83 03 80 01 FF'10
6'80 01 82 A4 07 95 01 08 83 02 80 01 80 01 81 90 00'17
7'80 01 82 A4 07 95 01 08 83 02 80 01 80 01 81 AF 13 B4 08 95 01 20 83 03 80 02 FF A4 07 95 01 08 83 02 80 01'36
8'80 01 83 90 00 80 01 84 B4 05 83 03 80 01 FF'15
+ + +Die Records 1 bis 5 enthalten jeweils eine, die Records 6 bis 8 jeweils zwei Zugriffs- +regeln. + +Im folgenden werden die einzelnen Records des EF_RULE näher erläutert. + +Record 1 wird referenziert als Zugriffsregel von DF_BANKING_20 in SE #2. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionC
Kapitel:ChipapplikationenStand:Seite:
Abschnitt:Chipapplikation für DDV18.07.2013111
+ + +CREATE FILE (EF), DELETE FILE (self), INCLUDE, EXCLUDE: MAC-SM-AC für +Kommando- und Antwortnachricht mit KHBCI_Admin: + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TagLängeWertErläuterung
'80''01''DA'Zugriffsart für CREATE FILE (EF), DELETE FILE (self), INCLUDE, EXCLUDE
'B4''05'CCT - Tag und Länge
'83''03''80 01 FF'Schlüsselreferenz für KHBCI_Admin
+ + +Record 2 wird referenziert als Zugriffsregel von EF_RULE, EF_KEYD, EF_PWDD +und EF_FBZ in SE #1. + +READ / SEARCH RECORD: ALW + + + + + + + + + + + + + + + + + + + + + +
TagLängeWertErläuterung
'80''01''81'Zugriffsart für READ / SEARCH RECORD
'90''00'Zugriffsbedingung ALW
+ + +Record 3 wird referenziert als Zugriffsregel von EF_RULE, EF_BNK und EF_MAC +in SE #2. + +APPEND RECORD: MAC-SM-AC für Kommando- und Antwortnachricht mit dem +Schlüssel KHBCI_Admin. + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TagLängeWertErläuterung
'80''01''84'Zugriffsart für APPEND RECORD
'B4''05'CCT - Tag und Länge
'83''03''80 01 FF'Schlüsselreferenz für KHBCI_Admin
+ + +Record 4 wird referenziert als Zugriffsregel von EF_KEY und EF_PWD in SE #2. + +APPEND RECORD, UPDATE RECORD: MAC-ENC-SM-AC für Kommandonach- +richt und MAC-SM-AC für Antwortnachricht mit KHBCI_Admin. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TagLängeWertErläuterung
'80''01''86'Zugriffsart für APPEND RECORD, UPDATE RECORD
'AF''11'AND- Template, Tag und Länge
'B4''05'CCT - Tag und Länge
'83''03''80 01 FF'Schlüsselreferenz für KHBCI_Admin
'B8''08'CT - Tag und Länge
'95''01''10'Usage Qualifier: Nur für Kommandonachricht
'83''03''80 01 FF'Schlüsselreferenz für KHBCI_Admin
+ + +Record 5 wird referenziert als Zugriffsregel von EF_KEYD, EF_SEQ, EF_PWDD +und EF_FBZ in SE #2. + +APPEND RECORD, UPDATE RECORD: MAC-SM-AC für Kommando- und Ant- +wortnachricht mit dem Schlüssel KHBCI_Admin- + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TagLängeWertErläuterung
'80''01''86'Zugriffsart für APPEND RECORD, UPDATE RECORD
'B4''05'CCT - Tag und Länge
'83''03''80 01 FF'Schlüsselreferenz für KHBCI_Admin
+ + + + + + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:Stand: 18.07.2013Kapitel: Chipapplikationen
112Abschnitt: Chipapplikation für DDV
+ + +Record 6 wird referenziert als Zugriffsregel von EF_BNK und EF_SEQ in SE #1. + +UPDATE RECORD: Karteninhaber-Authentikation (PWD) mit lokalem Passwort 1. +READ / SEARCH RECORD: ALW + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TagLängeWertErläuterung
'80''01''82'Zugriffsart für UPDATE RECORD
'A4''07'AT - Tag und Länge
'95''01''08'Usage Qualifier für Karteninhaber-Authentikation
'83''02''80 01'Passwort-Referenz, lokales Passwort mit der Nummer 1
'80''01''81'Zugriffsart für READ / SEARCH RECORD
'90''00'ALW
+ + +Record 7 wird referenziert als Zugriffsregel von EF_MAC in SE #1. + +UPDATE RECORD: Karteninhaber-Authentikation (PWD) mit lokalem Passwort 1. + +READ / SEARCH RECORD: Karteninhaber-Authentikation (PWD) mit lokalem +Passwort 1 und MAC-SM-AC für die Antwortnachricht mit dem Schlüssel KDAK. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TagLängeWertErläuterung
'80''01''82'Zugriffsart für UPDATE RECORD
'A4''07'AT - Tag und Länge
'95''01''08'Usage Qualifier für Karteninhaber-Authentikation
'83''02''80 01'Passwort-Referenz, lokales Passwort mit der Nummer 1
'80''01''81'Zugriffsart für READ / SEARCH RECORD
'AF''13'AND - Template, Tag und Länge
'B4''08'CCT - Tag und Länge
'95''01''20'Usage Qualifier: Nur Antwortnachricht
'83''03''80 02 FF'Schlüsselreferenz für KDAK
'A4''07'AT - Tag und Länge
'95''01''08'Usage Qualifier für Karteninhaber-Authentikation
'83''02''80 01'Passwort-Referenz, lokales Passwort mit der Nummer 1
+ + +Record 8 wird referenziert als Zugriffsregel im EF_PWDD. + +VERIFY, CHANGE REFERENCE DATA: ALW + +RESET RETRY COUNTER: MAC-SM-AC für Kommando- und Antwortnachricht mit +KHBCI_Admin + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TagLängeWertBeschreibung
'80''01''83'Zugriffsart für VERIFY, CHANGE REFERENCE DATA
'90''00'ALW
'80''01''84'Zugriffsart für Kommando: RESET RETRY COUNTER
'B4''05'CCT - Tag und Länge
'83''03''80 01 FF'Schlüsselreferenz für KHBCI_Admin
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionC
Kapitel:ChipapplikationenStand:Seite:
Abschnitt:Chipapplikation für DDV18.07.2013113
+ + +#### C.2.1.3 EF_KEY + + +##### . Beschreibung + +Die applikationsspezifischen Schlüssel der Applikation HBCI-Banking sind im +EF_KEY des Applikationsverzeichnisses DF_BANKING_20 gespeichert. Dies sind + +. ein 16 Byte langer kartenindividueller Schlüssel KHBCI_Admin mit der Schlüsselnum- +mer '01' zur Administration der Applikation DF_BANKING_20, + +. ein 16 Byte langer kartenindividueller Schlüssel KDAK mit der Schlüsselnummer +'02' als kundenindividueller Daten-Authentikationsschlüssel (DAK = Data Authen- +tication Key)15, sowie + +. ein 16 Byte langer kartenindividueller Schlüssel KENC mit der Schlüsselnummer +'03' als kundenindividueller Chiffrierschlüssel. + +Die Schlüssel KHBCI_Admin, KDAK und KENC sind nur der HBCI-Chipkarte und +dem für sie zuständigen Hintergrundsystem bekannt. Sie werden jeweils aus einem +KGK (Key Generating Key) unter Verwendung der Kartenidentifikationsdaten im +EF_ID des MF abgeleitet (vgl. Kapitel 8.4.1 von [DATKOM]). Das zuständige Hinter- +grundsystem kennt die jeweiligen KGK und leitet die kartenindividuellen Schlüssel +bei Bedarf ab. + +Es können pro logischer Schlüsselnummer verschiedene KGK verwendet werden. +Ein KGK wird wie alle daraus abgeleiteten Schlüssel anhand der Schlüsselversion +identifiziert. Die Schlüsselversion zur jeweiligen logischen Schlüsselnummer im zu- +gehörigen EF_KEYD zeigt an, aus welchem KGK der jeweilige kartenindividuelle +Schlüssel abgeleitet ist. + + +##### . Format + +Für das EF_KEY des DF_BANKING_20 sind die folgenden FCP festzulegen: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TagLängeWertErläuterung
'62''16'Tag und Länge für FCP
'82''05''12 41 00 12 03'Datei-Deskriptor für lineares EF mit fester Re- cordlänge (18 Byte), 3 Records
'83''02''00 10'Datei-ID des EF_KEY
'88''01''10'SFI '02' für das EF_KEY
'A1''06''8B 04 00 30 02 04'Zugriffsregel-Referenzen
+ + +Auf das EF_KEY darf nur im SE #2 zugegriffen werden. + +Die Kommandos APPEND RECORD und UPDATE RECORD dürfen nur ausgeführt +werden, wenn sie mit Secure Messaging durchgeführt werden, der Record-Inhalt +verschlüsselt (ENC) ist und die Kommandonachricht mit einem MAC abgesichert ist. +Verschlüsselung und MAC-Bildung erfolgen mit dem KHBCI_Admin. Der Returncode +eines APPEND RECORD oder UPDATE RECORD wird mit dem KHBCI_Admin MAC- +gesichert. Das Kommando READ RECORD darf nie ausgeführt werden. (Zugriffsre- +gel im Record 4 des EF_RULE) + + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite: 114Stand: 18.07.2013Kapitel: Chipapplikationen
Abschnitt: Chipapplikation für DDV
+ + +##### . Daten + +Das EF_KEY im DF_BANKING_20 enthält 3 Records mit den DF-spezifischen +Schlüsseln des DF_BANKING_20. + + + + + + + + + + + + + + + + + + + + + + + +
Logische Schlüs- selnummerSchlüssel-VersionSchlüssel
'01''XX'16 Byte langer KHBCI_Admin
'02''XX'16 Byte langer KDAK
'03''XX'16 Byte langer KENC
+ + +Es werden die Schlüsselversionen 1 bis 127 verwendet. + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: C
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final Version
Kapitel:ChipapplikationenStand:Seite:
Abschnitt:Chipapplikation für DDV18.07.2013115
+ + +#### C.2.1.4 EF_KEYD + + +##### . Beschreibung + +Das EF_KEYD im DF_BANKING_20 enthält die Zusatzinformationen zu den DF- +spezifischen Schlüsseln des DF_BANKING_20. + + +##### . Format + +Für das EF_KEYD sind die folgenden FCP festzulegen: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TagLängeWertErläuterung
'62''1C'Tag und Länge für FCP
'82''05''14 41 00 1C 03'Datei-Deskriptor für lineares EF mit variab- ler Recordlänge (max. 28 Byte) und 3 Re- cords
'83''02''00 13'Datei-ID des EF_KEYD
'85''02''00 48'für Nutzdaten allokierter Speicherplatz in Byte
'88''01''F0'SFI '1E' für das EF_KEYD
'A1''08''8B 06 00 30 01 02 02 05'Zugriffsregel-Referenzen
+ + +Im SE #1 dürfen nur die Kommandos READ / SEARCH RECORD mit ungesicherter +Kommando und Antwortnachricht ausgeführt werden (Zugriffsregel im Record 2 des +EF_RULE). + +Im SE #2 dürfen die Kommandos APPEND RECORD und UPDATE RECORD nur +ausgeführt werden, wenn sie mit Secure Messaging durchgeführt werden. Die MAC- +Bildung erfolgt für Kommando- und Antwortnachricht mit dem KHBCI_Admin (Zugriffs- +regel im Record 5 des EF_RULE). + + +##### ◆ Daten + +Das EF_KEYD enthält 3 Records, die die Zusatzinformation zu den DF-spezifischen +Schlüsseln des DF_BANKING_20 enthalten. + +Das Datenobjekt mit Tag '93' enthält im Wertfeld als zweites Byte die Version des +entsprechenden Schlüssels. + +Im folgenden wird der Aufbau der Schlüsselzusatzinformation dargestellt: + +Eintrag 1 (KHBCI_Admin): + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TagLängeWertErläuterung
'93''02''01 XX'Schlüsselnummer und Schlüssel-Version
'C0''02''81 10'Symmetrischer Schlüssel der Länge 16 Byte
'90''01''FF'Fehlbedienungszähler
'7B''0F'SE-Datenobjekt
'80''01''02'Festlegung für SE #2
'B4''04'CCT - Tag und Länge (Usage Qualifier '30' ist Default- wert)
'89''02''12 22'Algorithmus-ID: Schlüssel darf zur Bildung eines Retail-MAC im CFB-Mode verwendet werden
'B8''04'CT - Tag und Länge (Usage Qualifier '10' ist Default- wert)
'89''02''11 23'Algorithmus-ID: Schlüssel darf zur Verschlüsselung als Triple-DES Schlüssel im CBC-Mode mit ICV ≠ 0 und ICV-Variante verwendet werden
+ + + + + + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:Stand: 18.07.2013Kapitel: Chipapplikationen
116Abschnitt: Chipapplikation für DDV
+ + +#### Eintrag 2 (KDAK): + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Eintrag 3 (KENC):
TagLängeWertErläuterung
'93''02''02 XX'Schlüsselnummer und Schlüssel-Version
'C0''02''81 10'Symmetrischer Schlüssel der Länge 16 Byte
'7B''0C'SE-Datenobjekt
'80''01''01'Festlegung für SE #1
'B4''07'CCT - Tag und Länge
'95''01''20'Usage Qualifier: Nur SM-Antwortnachricht
'89''02''12 22'Algorithmus-ID: Schlüssel darf zur Bildung eines Retail-MAC im CFB-Mode verwendet werden
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TagLängeWertErläuterung
'93''02''03 XX'Schlüsselnummer und Schlüssel-Version
'C0''02''81 10'Symmetrischer Schlüssel der Länge 16 Byte
'7B''0C'SE-Datenobjekt
'80''01''01'Festlegung für SE #1
'A4''07'AT - Tag und Länge
'95''01''40'Usage Qualifier: Nur interne Authentikation
'89''02''21 12'Algorithmus-ID: Schlüssel darf zur Authentikation der Chipkarte mit Triple-DES verwendet werden
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionC
Kapitel:ChipapplikationenStand:Seite:
Abschnitt:Chipapplikation für DDV18.07.2013117
+ + +#### C.2.1.5 EF_PWD + + +##### . Beschreibung + +Das lokale EF_PWD im DF_BANKING_20 enthält in dem 9 Byte langen Record '01' +die Länge der HBCI-PIN und einen Referenzwert der HBCI-PIN der ZKA-Chipkarte. +Die HBCI-PIN hat eine Mindestlänge von 5 Ziffern und darf maximal 12 Ziffern lang +sein. + + +##### . Format + +Für das EF_PWD des DF_BANKING_20 sind die folgenden FCP festzulegen: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TagLängeWertErläuterung
'62''16'
'82''05''12 41 00 09 01'Datei-Deskriptor für lineares EF mit fester Recordlän- ge von 9 Byte
'83''02''00 12'Datei-ID des EF_PWD
'88''01''18'SFI '03' für das EF_PWD
'A1''06''8B 04 00 30 02 04'Zugriffsregel-Referenz
+ + +Auf das EF_PWD darf nur im SE #2 zugegriffen werden: Die Kommandos APPEND +RECORD und UPDATE RECORD dürfen nur ausgeführt werden, wenn sie mit +Secure Messaging durchgeführt werden, der Recordinhalt verschlüsselt (ENC) ist +und die Kommandonachricht mit einem MAC abgesichert ist. Verschlüsselung und +MAC-Bildung erfolgen dabei mit dem KHBCI_Admin. Der Returncode eines APPEND +RECORD oder UPDATE RECORD wird MAC-gesichert. Die MAC-Bildung erfolgt für +die Antwortnachricht mit dem KHBCI_Admin. Das Kommando READ RECORD darf +nie ausgeführt werden (Zugriffsregel im Record 4 des EF_RULE). + + +##### ◆ Daten + +Der Record '01' des EF_PWD enthält einen Referenzwert der HBCI-PIN. + + + + + + + + + + + + + + + + + + +
ByteInhaltBeschreibung
1'05'Länge der PIN
2-9'XX..XX'Referenzwert der PIN
+ + +Zur Erzeugung des Referenzwertes wird aus der HBCI-PIN zunächst der 8 Byte +lange 'Format 2 PIN Block' gemäß [ISO PIN1] wie folgt gebildet: + + + + + + + + + + + + + + + + + + + + + +
CLPPPPPP/FP/FP/FP/FP/FP/FP/FFF
+ + +#### Erläuterung: + +Jedes Feld repräsentiert ein Halbbyte. + +C: Kontroll-Feld, binär kodiert + +hat immer den Wert '2' + +L: PIN-Länge, binär kodiert + +mögliche Werte von '5' bis 'C' + +P: PIN-Ziffer, BCD-kodiert + +F: Filler, binär kodiert + +hat immer den Wert 'F' + +P/F: PIN-Ziffer/Filler + +Belegung abhängig von der PIN-Länge + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:
118		Stand: 18.07.2013Kapitel: Chipapplikationen
Abschnitt: Chipapplikation für DDV
+ + +Der erzeugte Format 2 PIN Block wird mit PB bezeichnet. Aus diesem PIN Block +wird der zu speichernde Referenzwert durch DES-Verschlüsselung mit sich selbst +erzeugt: + +PIN-Referenzwert: ePB(PB) + +Falls erforderlich, wird vor der Verwendung von PB als DES-Schlüssel ein Parity Ad- +justment vorgenommen. PB wird als Klartext unverändert verwendet. + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: C
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final Version
Kapitel:ChipapplikationenStand:Seite:
Abschnitt:Chipapplikation für DDV18.07.2013119
+ + +#### C.2.1.6 EF_PWDD + + +##### . Beschreibung + +Das EF_PWDD im DF_BANKING_20 enthält in Record '01' die Zusatzinformationen +zu der im EF_PWD des DF_BANKING_20 abgelegten HBCI-PIN. + + +##### . Format + +Für das EF_PWDD sind die folgenden FCP festzulegen: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TagLängeWertErläuterung
'62''1C'
'82''05''14 41 00 15 01'Datei-Deskriptor für lineares EF mit variabler Recordlänge (max. 21 Byte) und 1 Record
'83''02''00 15'Datei-ID des EF_PWDD
'85''02''00 15'Für Nutzdaten allokierter Speicherplatz in Byte
'88''01''20'SFI '04' für das EF_PWDD
'A1''08''8B 06 00 30 01 02 02 05'Zugriffsregel-Referenzen
+ + +Im SE #1 dürfen nur die Kommandos READ / SEARCH RECORD mit ungesicherter +Kommando und Antwortnachricht ausgeführt werden (Zugriffsregel im Record 2 des +EF_RULE). + +Im SE #2 durfen APPEND RECORD und UPDATE RECORD nur ausgeführt wer- +den, wenn sie mit Secure Messaging durchgeführt werden und die Kommandonach- +richt mit einem MAC abgesichert ist. Der Returncode wird MAC-gesichert. Die MAC- +Bildung erfolgt für Kommando- und Antwortnachricht mit dem KHBCI_Admin (Zugriffs- +regel im Record 5 des EF_RULE). + + +##### ◆ Daten + +Das lokale EF_PWDD enthält in Record '01' einen 21 Byte langen Record, der die +Zusatzinformationen zu der HBCI-PIN enthält. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TagLängeWertBeschreibung
'93''02''01 01'Passwortreferenz: Passwort '01' im Record '01' des EF_PWD
'89''02''11 50'Speicherformat des Passwortes (minimal 5 Ziffern)
'7B''0B'SE-DO, Tag und Länge
'80''01''00'SE Referenz-DO: Für alle SEs
'A1''03''8B 01 08'Zugriffsregel-Referenz
'89''01''12'Übertragungsformat der Authentikationsda- ten: PIN Format 2 Block
+ + + + + + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:Stand: 18.07.2013Kapitel: Chipapplikationen
120Abschnitt: Chipapplikation für DDV
+ + +#### C.2.1.7 EF_FBZ + + +##### . Beschreibung + +EF_FBZ bezeichnet das lineare EF, das in Record '01' den Fehlbedienungszähler +und den zugehörigen Initialwert für die im DF-spezifischen EF_PWD abgelegte +HBCI-PIN enthält. + + +##### . Format + +Für das EF_FBZ im DF_BANKING_20 sind die folgenden FCP festzulegen: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TagLängeWertErläuterung
'62''18'Tag und Länge für FCP
'82''05''12 41 00 02 01'Datei-Deskriptor für lineares EF fester Re- cordlänge
'83''02''00 16'Datei-ID des EF_FBZ
'88''01''28'SFI '05' für das EF_FBZ
'A1''08''8B 06 00 30 01 02 02 05'Zugriffsregel-Referenzen
+ + +Im SE # 1 dürfen nur die Kommandos READ / SEARCH RECORD mit ungesicherter +Kommando und Antwortnachricht ausgeführt werden (Zugriffsregel im Record 2 des +EF_RULE). + +Im SE #2 dürfen die Kommandos APPEND RECORD und UPDATE RECORD nur +ausgeführt werden, wenn sie mit Secure Messaging durchgeführt werden und die +Kommandonachricht mit einem MAC abgesichert ist. Der Returncode wird MAC- +gesichert. Die MAC-Bildung erfolgt für Kommando- und Antwortnachricht mit dem +KHBCI_Admin (Zugriffsregel im Record 5 des EF_RULE). + + +##### . Daten + +Das EF_FBZ enthält in Record '01' einen 2 Byte langen Record, der den Fehlbedie- +nungszähler und den zugehörigen Initialwert '03' für die HBCI-PIN enthält. + + + + + + + + + + + +
Initialwert des FBZFBZ
'03''03'
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionC
Kapitel:ChipapplikationenStand:Seite:
Abschnitt:Chipapplikation für DDV18.07.2013121
+ + +#### C.2.1.8 EF_BNK + + +##### . Beschreibung + +Bei dem EF_BNK handelt es sich um ein lineares EF mit 5 Records in dem Bank- +verbindungen abgelegt sind. + + +##### . Format + +Für das EF_BNK in einer HBCI-Chipkarte sind die folgenden FCP festzulegen: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TagLängeWertErläuterung
'62''18'Tag und Länge für FCP
'82''05''12 41 00 58 05'Datei-Deskriptor für lineares EF mit fester Recordlänge 88 Byte und 5 Records
'83''02''03 01'Datei-ID des EF_BNK
'88''01''D0'SFI '1A' für das EF_BNK
'A1''08''8B 06 00 30 01 06 02 03'Zugriffsregel-Referenzen
+ + +Im SE #1 dürfen READ / SEARCH RECORD immer ausgeführt werden, die Ant- +wortnachricht wird nicht abgesichert. UPDATE RECORD darf nur ausgeführt wer- +den, wenn zuvor eine Karteninhaber-Authentikation mit dem lokalen Passwort 1 +(HBCI-PIN) erfolgt ist. Der Returncode wird nicht MAC-gesichert (Zugriffsregeln im +Record 6 des EF_RULE). + +Im SE #2 darf das Kommando APPEND RECORD nur ausgeführt werden, wenn es +mit Secure Messaging durchgeführt wird. Die MAC-Bildung erfolgt für Kommando- +und Antwortnachricht mit dem KHBCI_Admin (Zugriffsregel im Record 3 des EF_RULE). + + +##### . Daten + +Die Records setzen sich aus einer Bankkurzbezeichnung, der Bankleitzahl, dem +Kommunikationsdienst, der Adresse und dem Adresszusatz für den Kommunikati- +onszugang, dem Länderkennzeichen und der Benutzerkennung zusammen. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ByteLängeWertErläuterung
1-2020'aa .. aa'Kurzbezeichner des Kreditinstituts
21-244'nn nn nn nn'Kreditinstitutscode des kontoführenden Instituts
25-251'n'Kommunikationsdienst
26-5328'aa .. aa'Kommunikationsadresse
54-552'aa aa'Kommunikationsadressenzusatz
56-583'aa aa aa'Länderkennzeichen des kontoführenden Instituts
59-8830'aa .. aa'Benutzerkennung
+ + +Alphanumerische Feldinhalte ('a') werden ASCII-kodiert, linksbündig eingestellt und +mit Leerzeichen (X'20') auf die vorgegebene Länge aufgefüllt. Numerische Feldin- +halte ('n') werden BCD-kodiert. + + + + + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:Stand: 18.07.2013Kapitel: Chipapplikationen
122Abschnitt: Chipapplikation für DDV
+ + +#### C.2.1.9 EF_MAC + + +##### . Beschreibung + +Das EF_MAC wird für die MAC-Bildung über den Hashwert einer Nachricht benötigt. +Es besteht aus einem 12 Byte langem Record deren Zugriffsregeln so gesetzt wer- +den müssen, dass beim Lesen des Records der MAC produziert wird. + + +##### . Format + +Für das EF_MAC sind die folgenden FCP festzulegen: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TagLängeWertErläuterung
'62''18'Tag und Länge für FCP
'82''05''12 41 00 0C 01'Datei-Deskriptor für lineares EF mit einem Record der Länge 12 Byte
'83''02''03 02'Datei-ID des EF_MAC
'88''01''D8'SFI '1B' für das EF_MAC
'A1''08''8B 06 00 30 01 07 02 03'Zugriffsregel-Referenzen
+ + +Im SE #1 dürfen READ / SEARCH RECORD nach Karteninhaber-Authentikation +ausgeführt werden, die Antwortnachricht wird mit einem KDAK-MAC versehen. +UPDATE RECORD darf nur ausgeführt werden, wenn zuvor eine Karteninhaber- +Authentikation mit dem lokalen Passwort 1 (HBCI-PIN) erfolgt ist. Der Returncode +eines UPDATE RECORD wird nicht MAC-gesichert (Zugriffsregeln im Record 7 des +EF_RULE). + +Im SE #2 darf das Kommando APPEND RECORD nur ausgeführt werden, wenn es +mit Secure Messaging durchgeführt wird. Die MAC-Bildung erfolgt für Kommando- +und Antwortnachricht mit dem KHBCI_Admin (Zugriffsregel im Record 3 des EF_RULE). + + +##### . Daten + +Das EF_MAC enthält einen Record, der den folgenden Aufbau hat: + + + + + + + + + + + + + +
ByteWertErläuterung
1-12'XX..XX'Hashwert
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionC
Kapitel:ChipapplikationenStand:Seite:
Abschnitt:Chipapplikation für DDV18.07.2013123
+ + +#### C.2.1.10 EF_SEQ + + +##### . Beschreibung + +Bei dem EF_SEQ handelt es sich um ein lineares EF, dessen Record ein 2 Byte +langes binär definiertes Element enthält. Dieser binäre aufsteigende Zähler fließt als +Sicherheitsreferenznummer (Signatur-ID) zur Absicherung der Daten gegen Doppe- +leinreichung ein. Der Startwert des Zählers ist 1. Ein Rücksetzen bei Überlauf findet +nicht statt. + + +##### . Format + +Für das EF_SEQ sind die folgenden FCP festzulegen: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TagLängeWertErläuterung
'62''18'Tag und Länge für FCP
'82''05''12 41 00 02 01'Datei-Deskriptor für lineares EF mit 1 Record der Länge 2 Byte
'83''02''03 03'Datei-ID des EF_SEQ
'88''01''E0'SFI '1C' für das EF_SEQ
'A1''08''8B 06 00 30 01 06 02 05'Zugriffsregel-Referenzen
+ + +Im SE #1 dürfen READ / SEARCH RECORD immer ausgeführt werden, die Ant- +wortnachricht wird nicht abgesichert. UPDATE RECORD darf nur ausgeführt wer- +den, wenn zuvor eine Karteninhaber-Authentikation mit dem lokalen Passwort 1 +(HBCI-PIN) erfolgt ist. Der Returncode wird nicht MAC-gesichert (Zugriffsregeln im +Record 6 des EF_RULE). + +Im SE #2 dürfen die Kommandos APPEND RECORD und UPDATE RECORD nur +ausgeführt werden, wenn sie mit Secure Messaging durchgeführt werden. Die MAC- +Bildung erfolgt für Kommando- und Antwortnachrichten jeweils mit dem KHBCI_Admin +(Zugriffsregel im Record 5 des EF_RULE). + + +##### . Daten + +Das EF_SEQ enthält 1 Record, der den folgenden Aufbau hat: + + + + + + + + + + + + + + + + + + + + + + + + + + +
ByteWertErläuterung
1-2'XX XX'Sequenznummer
Kapitel: CVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:
124		Stand: 18.07.2013Kapitel: Chipapplikationen
Abschnitt: Chipapplikation für DDV
+ + +#### C.2.2 Daten der Applikation HBCI-Banking für SECCOS 6 + +Die folgende Grafik gibt eine Übersicht über die Dateien einer HBCI-Karte mit der +Applikation HBCI-Banking für Seccos 6. + + +Abbildung 21: Datenelemente der Applikation "HBCI", Bankensignaturkarte mit Zerti- +fikat + +![MF EF_KEY EF_KEYD EF_PWD EF_PWDD EF_FBZ EF_ID EF_INFO EF_RULE EF_SIG EF_SIGD DF_BANKING_20 EF_KEY EF_KEYD EF_RULE EF_BNK EF_MAC EF_SEQ EF_PWD EF_PWDD EF_FBZ](figures/138.1) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionC
Kapitel:ChipapplikationenStand:Seite:
Abschnitt:Chipapplikation für DDV18.07.2013125
+ + +Abbildung 22: Datenelemente der Applikation "HBCI", Bankensignaturkarte ohne +Zertifikat + +![MF EF_KEY EF_KEYD EF_ID EF_RULE EF_SIG EF_SIGD DF_BANKING_20 EF_KEY EF_KEYD EF_RULE EF_BNK EF_MAC EF_SEQ EF_PWD EF_PWDD EF_FBZ](figures/139.1) + + + + + + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:Stand: 18.07.2013Kapitel: Chipapplikationen
126Abschnitt: Chipapplikation für DDV
+ + +#### C.2.2.1 ADF der Applikation HBCI-Banking + +Für das ADF der Applikation HBCI-Banking (DF_BANKING_20) sind beim Anlegen +die folgenden FCP festzulegen: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TagLängeWertErläuterung
'62''1A'Tag und Länge für FCP
'82''01''38'Datei-Deskriptor für DF
'83''02''A6 00'Datei-ID des DF_BANKING_20
'84''09''D2 76 00 00 25 48 42 02 00'DF-Name (AID) des DF_BANKING_20
'A1''06''8B 04 00 30 02 01'Zugriffsregel-Referenzen
'A2''09''88 01 C8 51 04 3F 00 00 03'SFI-Template: SFI '19' für das EF_ID im MF (Datei-ID: 00 03')
+ + +Der DF-Name (die AID) des DF_BANKING_20 bestehend aus der nationalen RID +des ZKA ('D2 76 00 00 25'), der ASCII-kodierten Kennung "HB" ('48 42') sowie der +Version der Applikation 2.0 ('02 00'). + +Die Zugriffsregeln für das DF_BANKING_20 stehen in der zugeordneten Regeldatei +EF_RULE. Durch die Zugriffsregeln werden für die DF-spezifischen Kommandos die +folgenden Festlegungen getroffen: + +Wenn das DF_BANKING_20 selektiert ist, darf ein CREATE FILE (EF) oder ein +DELETE FILE (self) nur ausgeführt werden, wenn die Kommandonachricht mit +Secure Messaging ausgeführt wird und mit einem korrekten MAC versehen ist, der +unter Verwendung des Schlüssels KHBCI_Admin aus dem EF_KEY des +DF_BANKING_20 gebildet ist. Der Returncode wird für jedes dieser Kommandos +durch die Karte mit einem MAC mit dem Schlüssel KHBCI_Admin versehen. Die +Kommandos CREATE FILE (DF), DELETE FILE (child DF), ACTIVATE, +DEACTIVATE und TERMINATE dürfen nie ausgeführt werden. Alle zulässigen Ad- +ministrationskommandos dürfen nur im SE #2 ausgeführt werden (Zugriffsregeln im +Record 1 des EF_RULE). + +Der Applikation HBCI-Banking sind 10 Dateien als AEF zuzuordnen: + +SFI '01': +EF_RULE im DF_BANKING_20 + +SFI '02': +EF_KEY im DF_BANKING_20, + +SFI '03': +EF_PWD im DF_BANKING_20, + +SFI '04': +EF_PWDD im DF_BANKING_20, + +SFI '05': +EF_FBZ im DF_BANKING_20, + +SFI '19': +EF_ID im MF, + +SFI '1A': +EF_BNK im DF_BANKING_20, + +SFI '1B': +EF_MAC im DF_BANKING_20, + +SFI '1C': +EF_SEQ im DF_BANKING_20, + +SFI '1E': +EF_KEYD im DF_BANKING_20. + +Wenn das DF_BANKING_20 mittels SELECT FILE selektiert wird und die entspre- +chende Option im Parameterbyte P2 des Kommandos gesetzt ist, wird die folgende +FCI ausgegeben: + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionC
Kapitel:ChipapplikationenStand:Seite:
Abschnitt:Chipapplikation für DDV18.07.2013127
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
TagLängeWertErläuterung
'6F''0D'Tag und Länge für FCI
'84''09''D2 76 00 00 25 48 42 02 00'DF-Name (AID) des DF_BANKING_20
'A5''00'keine proprietären Informationen
+ + +Wird das DF_BANKING_20 mittels SELECT FILE selektiert und die entsprechende +Option im Parameterbyte P2 des Kommandos gesetzt, werden die folgenden FMD +mit den Pfaden der AEFs ausgegeben (vorausgesetzt, das DF_BANKING_20 befin- +det sich direkt im MF): + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TagLängeWertErläuterung
'64''6E'Tag und Länge für FMD
'A2''6C'Tag und Länge SFI-Template
'88''01''08'SFI '01' (EF_RULE im DF_BANKING_20)
'51''06''3F 00 A6 00 00 30'Pfad für AEF mit SFI '01'
'88''01''10'SFI '02' (EF_KEY im DF_BANKING_20)
'51''06''3F 00 A6 00 00 10'Pfad für AEF mit SFI '02'
'85''01''18'SFI '03' (EF_PWD im DF_BANKING_20)
'51''06''3F 00 A6 00 00 12'Pfad für AEF mit SFI '03'
'85''01''20'SFI '04' (EF_PWDD im DF_BANKING_20)
'51''06''3F 00 A6 00 00 15'Pfad für AEF mit SFI '04'
'85''01''28'SFI '05' (EF_FBZ im DF_BANKING_20)
'51''06''3F 00 A6 00 00 16'Pfad für AEF mit SFI '05'
'88''01''C8'SFI '19' (EF_ID im MF)
'51''04''3F 00 00 03'Pfad für AEF mit SFI '19'
'85''01''D0'SFI '1A' (EF_BNK im DF_BANKING_20)
'51''06''3F 00 A6 00 03 01'Pfad für AEF mit SFI '1A'
'85''01''D8'SFI '1B' (EF_MAC im DF_BANKING_20)
'51',90,'3F 00 A6 00 03 02'Pfad für AEF mit SFI '1B'
'85''01''E0'SFI '1C' (EF_SEQ im DF_BANKING_20)
'51''06''3F 00 A6 00 03 03'Pfad für AEF mit SFI '1C'
'85''01''F0'SFI '1E' (EF_KEYD im DF_BANKING_20)
'51',90,'3F 00 A6 00 00 13'Pfad für AEF mit SFI '1E'
+ + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite: 128Stand: 18.07.2013Kapitel: Chipapplikationen
Abschnitt: Chipapplikation für DDV
+ + +#### C.2.2.2 EF_RULE + + +##### . Beschreibung + +Die Datei EF_RULE enthält die Zugriffsregeln für die Applikation DF_BANKING_20. +In den FCP von Dateien und Verzeichnissen wird auf diese Zugriffsregeln referen- +ziert. + + +##### . Format + +Für das EF_RULE des DF_BANKING_20 sind die folgenden FCP festzulegen: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TagLängeWertErläuterung
'62''1C'Tag und Länge für FCP
'82''05''14 41 00 24 08'Datei-Deskriptor für lineares EF mit variab- ler Recordlänge (max. 36 Byte), 8 Records
'83''02''00 30'Datei-ID des EF_RULE
'85''02''00 7D'für Nutzdaten allokierter Speicherplatz in Byte
'88''01''08'SFI '01' für das EF_RULE
'A1''08''8B 06 00 30 01 02 02 03'Zugriffsregel-Referenzen
+ + +Im SE #1 dürfen nur die Kommandos READ / SEARCH RECORD mit ungesicherter +Kommando und Antwortnachricht ausgeführt werden (Zugriffsregel im Record 2 des +EF_RULE). + +Im SE #2 darf APPEND RECORD nur ausgeführt werden, wenn es mit Secure +Messaging ausgeführt wird. Die MAC-Bildung erfolgt für Kommando- und Antwort- +nachricht mit dem KHBCI_Admin. UPDATE RECORD darf nie ausgeführt werden (Zu- +griffsregel im Record 3 des EF_RULE). + + +##### . Daten + +Das EF_RULE im DF_BANKING_20 enthält 8 Records mit den Zugriffsregeln für +das Verzeichnis und die Datenfelder des Verzeichnisses. + +Die folgende Tabelle zeigt die Belegung dieser Records für eine HBCI-Chipkarte: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Rec.Nr.Record-InhaltByte
1'80 01 42 B4 05 83 03 80 01 FF'10
2'80 01 01 90 00'5
3'80 01 04 B4 05 83 03 80 01 FF'10
4'80 01 06 AF 11 B4 05 83 03 80 01 FF B8 08 95 01 10 83 03 80 01 FF'22
5'80 01 06 B4 05 83 03 80 01 FF'10
6'80 01 02 A4 07 95 01 08 83 02 80 01 80 01 01 90 00'17
7'80 01 02 A4 07 95 01 08 83 02 80 01 80 01 01 AF 13 B4 08 95 01 20 83 03 80 02 FF A4 07 95 01 08 83 02 80 01'36
8'80 01 03 90 00 80 01 84 B4 05 83 03 80 01 FF'15
+ + +Die Records 1 bis 5 enthalten jeweils eine, die Records 6 bis 8 jeweils zwei Zugriffs- +regeln. + +Im folgenden werden die einzelnen Records des EF_RULE näher erläutert. + +Record 1 wird referenziert als Zugriffsregel von DF_BANKING_20 in SE #2. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionC
Kapitel:ChipapplikationenStand:Seite:
Abschnitt:Chipapplikation für DDV18.07.2013129
+ + +#### CREATE FILE (EF), DELETE FILE (self): MAC-SM-AC für Kommando- und Ant- wortnachricht mit KHBCI_Admin: + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TagLängeWertErläuterung
'80''01''42'Zugriffsart für CREATE FILE (EF), DELETE FILE (self)
'B4''05'CCT - Tag und Länge
'83''03''80 01 FF'Schlüsselreferenz für KHBCI_Admin
+ + +Record 2 wird referenziert als Zugriffsregel von EF_RULE, EF_KEYD, EF_PWDD +und EF_FBZ in SE #1. + +READ / SEARCH RECORD: ALW + + + + + + + + + + + + + + + + + + + + + +
TagLängeWertErläuterung
'80''01''01'Zugriffsart für READ / SEARCH RECORD
'90''00'Zugriffsbedingung ALW
+ + +Record 3 wird referenziert als Zugriffsregel von EF_RULE, EF_BNK und EF_MAC +in SE #2. + +APPEND RECORD: MAC-SM-AC für Kommando- und Antwortnachricht mit dem +Schlüssel KHBCI_Admin· + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TagLängeWertErläuterung
'80''01''04'Zugriffsart für APPEND RECORD
'B4''05'CCT - Tag und Länge
'83''03''80 01 FF'Schlüsselreferenz für KHBCI_Admin
+ + +Record 4 wird referenziert als Zugriffsregel von EF_KEY und EF_PWD in SE #2. + +APPEND RECORD, UPDATE RECORD: MAC-ENC-SM-AC für Kommandonach- +richt und MAC-SM-AC für Antwortnachricht mit KHBCI_Admin. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TagLängeWertErläuterung
'80''01''06'Zugriffsart für APPEND RECORD, UPDATE RECORD
'AF''11'AND- Template, Tag und Länge
'B4''05'CCT - Tag und Länge
'83''03''80 01 FF'Schlüsselreferenz für KHBCI_Admin
'B8''08'CT - Tag und Länge
'95''01''10'Usage Qualifier: Nur für Kommandonachricht
'83''03''80 01 FF'Schlüsselreferenz für KHBCI_Admin
+ + +Record 5 wird referenziert als Zugriffsregel von EF_KEYD, EF_SEQ, EF_PWDD +und EF_FBZ in SE #2. + +APPEND RECORD, UPDATE RECORD: MAC-SM-AC für Kommando- und Ant- +wortnachricht mit dem Schlüssel KHBCI_Admin. + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TagLängeWertErläuterung
'80''01''06'Zugriffsart für APPEND RECORD, UPDATE RECORD
'B4''05'CCT - Tag und Länge
'83''03''80 01 FF'Schlüsselreferenz für KHBCI_Admin
+ + + + + + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:Stand: 18.07.2013Kapitel: Chipapplikationen
130Abschnitt: Chipapplikation für DDV
+ + +Record 6 wird referenziert als Zugriffsregel von EF_BNK und EF_SEQ in SE #1. + +UPDATE RECORD: Karteninhaber-Authentikation (PWD) mit lokalem Passwort 1. +READ / SEARCH RECORD: ALW + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TagLängeWertErläuterung
'80''01''02'Zugriffsart für UPDATE RECORD
'A4''07'AT - Tag und Länge
'95''01''08'Usage Qualifier für Karteninhaber-Authentikation
'83''02''80 01'Passwort-Referenz, lokales Passwort mit der Nummer 1
'80''01''01'Zugriffsart für READ / SEARCH RECORD
'90''00'ALW
+ + +Record 7 wird referenziert als Zugriffsregel von EF_MAC in SE #1. + +UPDATE RECORD: Karteninhaber-Authentikation (PWD) mit lokalem Passwort 1. + +READ / SEARCH RECORD: Karteninhaber-Authentikation (PWD) mit lokalem +Passwort 1 und MAC-SM-AC für die Antwortnachricht mit dem Schlüssel KDAK. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TagLängeWertErläuterung
'80''01''02'Zugriffsart für UPDATE RECORD
'A4''07'AT - Tag und Länge
'95''01''08'Usage Qualifier für Karteninhaber-Authentikation
'83''02''80 01'Passwort-Referenz, lokales Passwort mit der Nummer 1
'80''01''01'Zugriffsart für READ / SEARCH RECORD
'AF''13'AND - Template, Tag und Länge
'B4''08'CCT - Tag und Länge
'95''01''20'Usage Qualifier: Nur Antwortnachricht
'83''03''80 02 FF'Schlüsselreferenz für KDAK
'A4''07'AT - Tag und Länge
'95''01''08'Usage Qualifier für Karteninhaber-Authentikation
'83''02''80 01'Passwort-Referenz, lokales Passwort mit der Nummer 1
+ + +Record 8 wird referenziert als Zugriffsregel im EF_PWDD. + +VERIFY, CHANGE REFERENCE DATA: ALW + +RESET RETRY COUNTER: MAC-SM-AC für Kommando- und Antwortnachricht mit +KHBCI_Admin + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TagLängeWertBeschreibung
'80''01''03'Zugriffsart für VERIFY, CHANGE REFERENCE DATA
'90''00'ALW
'80''01''04'Zugriffsart für Kommando: RESET RETRY COUNTER
'B4''05'CCT - Tag und Länge
'83''03''80 01 FF'Schlüsselreferenz für KHBCI_Admin
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionC
Kapitel:ChipapplikationenStand:Seite:
Abschnitt:Chipapplikation für DDV18.07.2013131
+ + +#### C.2.2.3 EF_KEY + + +##### . Beschreibung + +Die applikationsspezifischen Schlüssel der Applikation HBCI-Banking sind im +EF_KEY des Applikationsverzeichnisses DF_BANKING_20 gespeichert. Dies sind + +. ein 16 Byte langer kartenindividueller Schlüssel KHBCI_Admin mit der Schlüsselnum- +mer '01' zur Administration der Applikation DF_BANKING_20, + +. ein 16 Byte langer kartenindividueller Schlüssel KDAK mit der Schlüsselnummer +'02' als kundenindividueller Daten-Authentikationsschlüssel (DAK = Data Authen- +tication Key)16, sowie + +. ein 16 Byte langer kartenindividueller Schlüssel KENC mit der Schlüsselnummer +'03' als kundenindividueller Chiffrierschlüssel. + +Die Schlüssel KHBCI_Admin, KDAK und KENC sind nur der HBCI-Chipkarte und +dem für sie zuständigen Hintergrundsystem bekannt. Sie werden jeweils aus einem +KGK (Key Generating Key) unter Verwendung der Kartenidentifikationsdaten im +EF_ID des MF abgeleitet (vgl. Kapitel 8.4.1 von [DATKOM]). Das zuständige Hinter- +grundsystem kennt die jeweiligen KGK und leitet die kartenindividuellen Schlüssel +bei Bedarf ab. + +Es können pro logischer Schlüsselnummer verschiedene KGK verwendet werden. +Ein KGK wird wie alle daraus abgeleiteten Schlüssel anhand der Schlüsselversion +identifiziert. Die Schlüsselversion zur jeweiligen logischen Schlüsselnummer im zu- +gehörigen EF_KEYD zeigt an, aus welchem KGK der jeweilige kartenindividuelle +Schlüssel abgeleitet ist. + + +##### . Format + +Für das EF_KEY des DF_BANKING_20 sind die folgenden FCP festzulegen: + + + + + + + + + + + + + + + +
TagLängeWertErläuterung
'62''16'Tag und Länge für FCP
+ + +'82' + +'05' + +'32 41 00 12 03' + +Datei-Deskriptor für sicherheitsrelevantes line- +ares EF mit fester Recordlänge (18 Byte), 3 +Records + + + + + + + + + + + + + + + + + + + + + +
'83''02''00 10'Datei-ID des EF_KEY
'88''01''10'SFI '02' für das EF_KEY
'A1',90,'8B 04 00 30 02 04'Zugriffsregel-Referenzen
+ + +Auf das EF_KEY darf nur im SE #2 zugegriffen werden. + +Die Kommandos APPEND RECORD und UPDATE RECORD dürfen nur ausgeführt +werden, wenn sie mit Secure Messaging durchgeführt werden, der Record-Inhalt +verschlüsselt (ENC) ist und die Kommandonachricht mit einem MAC abgesichert ist. +Verschlüsselung und MAC-Bildung erfolgen mit dem KHBCI_Admin. Der Returncode +eines APPEND RECORD oder UPDATE RECORD wird mit dem KHBCI Admin MAC- +gesichert. Das Kommando READ RECORD darf nie ausgeführt werden. (Zugriffsre- +gel im Record 4 des EF_RULE) + + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite: 132Stand: 18.07.2013Kapitel: Chipapplikationen
Abschnitt: Chipapplikation für DDV
+ + +##### . Daten + +Das EF_KEY im DF_BANKING_20 enthält 3 Records mit den DF-spezifischen +Schlüsseln des DF_BANKING_20. + + + + + + + + + + + + + + + + + + + + + + + +
Logische Schlüs- selnummerSchlüssel-VersionSchlüssel
'01''XX'16 Byte langer KHBCI_Admin
'02''XX'16 Byte langer KDAK
'03''XX'16 Byte langer KENC
+ + +Es werden die Schlüsselversionen 1 bis 127 verwendet. + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: C
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final Version
Kapitel:ChipapplikationenStand:Seite:
Abschnitt:Chipapplikation für DDV18.07.2013133
+ + +#### C.2.2.4 EF_KEYD + + +##### . Beschreibung + +Das EF_KEYD im DF_BANKING_20 enthält die Zusatzinformationen zu den DF- +spezifischen Schlüsseln des DF_BANKING_20. + + +##### . Format + +Für das EF_KEYD sind die folgenden FCP festzulegen: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TagLängeWertErläuterung
'62''1C'Tag und Länge für FCP
'82''05''14 41 00 1C 03'Datei-Deskriptor für lineares EF mit variab- ler Recordlänge (max. 28 Byte) und 3 Re- cords
'83''02''00 13'Datei-ID des EF_KEYD
'85''02''00 48'für Nutzdaten allokierter Speicherplatz in Byte
'88''01''F0'SFI '1E' für das EF_KEYD
'A1''08''8B 06 00 30 01 02 02 05'Zugriffsregel-Referenzen
+ + +Im SE #1 dürfen nur die Kommandos READ / SEARCH RECORD mit ungesicherter +Kommando und Antwortnachricht ausgeführt werden (Zugriffsregel im Record 2 des +EF_RULE). + +Im SE #2 dürfen die Kommandos APPEND RECORD und UPDATE RECORD nur +ausgeführt werden, wenn sie mit Secure Messaging durchgeführt werden. Die MAC- +Bildung erfolgt für Kommando- und Antwortnachricht mit dem KHBCI_Admin (Zugriffs- +regel im Record 5 des EF_RULE). + + +##### ◆ Daten + +Das EF_KEYD enthält 3 Records, die die Zusatzinformation zu den DF-spezifischen +Schlüsseln des DF_BANKING_20 enthalten. + +Das Datenobjekt mit Tag '93' enthält im Wertfeld als zweites Byte die Version des +entsprechenden Schlüssels. + +Im folgenden wird der Aufbau der Schlüsselzusatzinformation dargestellt: + +Eintrag 1 (KHBCI_Admin): + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TagLängeWertErläuterung
'93''02''01 XX'Schlüsselnummer und Schlüssel-Version
'C0''02''81 10'Symmetrischer Schlüssel der Länge 16 Byte
'90''01''FF'Fehlbedienungszähler
'7B''0F'SE-Datenobjekt
'80''01''02'Festlegung für SE #2
'B4''04'CCT - Tag und Länge (Usage Qualifier '30' ist Default- wert)
'89''02''12 22'Algorithmus-ID: Schlüssel darf zur Bildung eines Retail-MAC im CFB-Mode verwendet werden
'B8''04'CT - Tag und Länge (Usage Qualifier '10' ist Default- wert)
'89''02''11 23'Algorithmus-ID: Schlüssel darf zur Verschlüsselung als Triple-DES Schlüssel im CBC-Mode mit ICV ≠ 0 und ICV-Variante verwendet werden
+ + + + + + + + + + + + + + + + + + + + + +
Eintrag 2 (KDAK):
Kapitel: CVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:Stand: 18.07.2013Kapitel: Chipapplikationen
134Abschnitt: Chipapplikation für DDV
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Eintrag 3 (KENC):
TagLängeWertErläuterung
'93''02''02 XX'Schlüsselnummer und Schlüssel-Version
'C0''02''81 10'Symmetrischer Schlüssel der Länge 16 Byte
'7B''0C'SE-Datenobjekt
'80''01''01'Festlegung für SE #1
'B4''07'CCT - Tag und Länge
'95''01''20'Usage Qualifier: Nur SM-Antwortnachricht
'89''02''12 22'Algorithmus-ID: Schlüssel darf zur Bildung eines Retail-MAC im CFB-Mode verwendet werden
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TagLängeWertErläuterung
'93''02''03 XX'Schlüsselnummer und Schlüssel-Version
'C0''02''81 10'Symmetrischer Schlüssel der Länge 16 Byte
'7B''0C'SE-Datenobjekt
'80''01''01'Festlegung für SE #1
'A4''07'AT - Tag und Länge
'95''01''40'Usage Qualifier: Nur interne Authentikation
'89''02''21 12'Algorithmus-ID: Schlüssel darf zur Authentikation der Chipkarte mit Triple-DES verwendet werden
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionC
Kapitel:ChipapplikationenStand:Seite:
Abschnitt:Chipapplikation für DDV18.07.2013135
+ + +#### C.2.2.5 EF_PWD + + +##### . Beschreibung + +Das lokale EF_PWD im DF_BANKING_20 enthält in dem 9 Byte langen Record '01' +die Länge der HBCI-PIN und einen Referenzwert der HBCI-PIN der ZKA-Chipkarte. +Die HBCI-PIN hat eine Mindestlänge von 5 Ziffern und darf maximal 12 Ziffern lang +sein. + + +##### . Format + +Für das EF_PWD des DF_BANKING_20 sind die folgenden FCP festzulegen: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TagLängeWertErläuterung
'62''16'
'82''05''32 41 00 09 01'Datei-Deskriptor für sicherheitsrelvantes lineares EF mit fester Recordlänge von 9 Byte
'83''02''00 12'Datei-ID des EF_PWD
'88''01''18'SFI '03' für das EF_PWD
'A1''06''8B 04 00 30 02 04'Zugriffsregel-Referenz
+ + +Auf das EF_PWD darf nur im SE #2 zugegriffen werden: Die Kommandos APPEND +RECORD und UPDATE RECORD dürfen nur ausgeführt werden, wenn sie mit +Secure Messaging durchgeführt werden, der Recordinhalt verschlüsselt (ENC) ist +und die Kommandonachricht mit einem MAC abgesichert ist. Verschlüsselung und +MAC-Bildung erfolgen dabei mit dem KHBCI_Admin. Der Returncode eines APPEND +RECORD oder UPDATE RECORD wird MAC-gesichert. Die MAC-Bildung erfolgt für +die Antwortnachricht mit dem KHBCI_Admin. Das Kommando READ RECORD darf +nie ausgeführt werden (Zugriffsregel im Record 4 des EF_RULE). + + +##### ◆ Daten + +Der Record '01' des EF_PWD enthält einen Referenzwert der HBCI-PIN. + + + + + + + + + + + + + + + + + + +
ByteInhaltBeschreibung
1'05'Länge der PIN
2 - 9'XX..XX'Referenzwert der PIN
+ + +Zur Erzeugung des Referenzwertes wird aus der HBCI-PIN zunächst der 8 Byte +lange 'Format 2 PIN Block' gemäß [ISO PIN1] wie folgt gebildet: + + + + + + + + + + + + + + + + + + + + + +
CLPPPPPP/FP/FP/FP/FP/FP/FP/FFF
+ + +#### Erläuterung: + +Jedes Feld repräsentiert ein Halbbyte. + +C: Kontroll-Feld, binär kodiert + +hat immer den Wert '2' + +L: PIN-Länge, binär kodiert + +mögliche Werte von '5' bis 'C' + +P: PIN-Ziffer, BCD-kodiert + +F: Filler, binär kodiert + +hat immer den Wert 'F' + +P/F: PIN-Ziffer/Filler + +Belegung abhängig von der PIN-Länge + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:
136		Stand: 18.07.2013Kapitel: Chipapplikationen
Abschnitt: Chipapplikation für DDV
+ + +Der erzeugte Format 2 PIN Block wird mit PB bezeichnet. Aus diesem PIN Block +wird der zu speichernde Referenzwert durch DES-Verschlüsselung mit sich selbst +erzeugt: + +PIN-Referenzwert: ePB(PB) + +Falls erforderlich, wird vor der Verwendung von PB als DES-Schlüssel ein Parity Ad- +justment vorgenommen. PB wird als Klartext unverändert verwendet. + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: C
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final Version
Kapitel:ChipapplikationenStand:Seite:
Abschnitt:Chipapplikation für DDV18.07.2013137
+ + +#### C.2.2.6 EF_PWDD + + +##### . Beschreibung + +Das EF_PWDD im DF_BANKING_20 enthält in Record '01' die Zusatzinformationen +zu der im EF_PWD des DF_BANKING_20 abgelegten HBCI-PIN. + + +##### . Format + +Für das EF_PWDD sind die folgenden FCP festzulegen: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TagLängeWertErläuterung
'62''1C'
'82''05''14 41 00 15 01'Datei-Deskriptor für lineares EF mit variabler Recordlänge (max. 21 Byte) und 1 Record
'83''02''00 15'Datei-ID des EF_PWDD
'85''02''00 15'Für Nutzdaten allokierter Speicherplatz in Byte
'88''01''20'SFI '04' für das EF_PWDD
'A1''08''8B 06 00 30 01 02 02 05'Zugriffsregel-Referenzen
+ + +Im SE #1 dürfen nur die Kommandos READ / SEARCH RECORD mit ungesicherter +Kommando und Antwortnachricht ausgeführt werden (Zugriffsregel im Record 2 des +EF_RULE). + +Im SE #2 durfen APPEND RECORD und UPDATE RECORD nur ausgeführt wer- +den, wenn sie mit Secure Messaging durchgeführt werden und die Kommandonach- +richt mit einem MAC abgesichert ist. Der Returncode wird MAC-gesichert. Die MAC- +Bildung erfolgt für Kommando- und Antwortnachricht mit dem KHBCI_Admin (Zugriffs- +regel im Record 5 des EF_RULE). + + +##### ◆ Daten + +Das lokale EF_PWDD enthält in Record '01' einen 21 Byte langen Record, der die +Zusatzinformationen zu der HBCI-PIN enthält. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TagLängeWertBeschreibung
'93''02''01 01'Passwortreferenz: Passwort '01' im Record '01' des EF_PWD
'89''02''11 50'Speicherformat des Passwortes (minimal 5 Ziffern)
'A1''03''8B 01 08'Zugriffsregel-Referenz
'7B',90,SE-DO, Tag und Länge
'80''01''00'SE Referenz-DO: Für alle SEs
'89''01''12'Übertragungsformat der Authentikationsda- ten: PIN Format 2 Block
+ + + + + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite: 138Stand: 18.07.2013Kapitel: Chipapplikationen
Abschnitt: Chipapplikation für DDV
+ + +#### C.2.2.7 EF_FBZ + + +##### . Beschreibung + +EF_FBZ bezeichnet das lineare EF, das in Record '01' den Fehlbedienungszähler +und den zugehörigen Initialwert für die im DF-spezifischen EF_PWD abgelegte +HBCI-PIN enthält. + + +##### . Format + +Für das EF_FBZ im DF_BANKING_20 sind die folgenden FCP festzulegen: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TagLängeWertErläuterung
'62''18'Tag und Länge für FCP
'82''05''12 41 00 02 01'Datei-Deskriptor für lineares EF fester Re- cordlänge
'83''02''00 16'Datei-ID des EF_FBZ
'88''01''28'SFI '05' für das EF_FBZ
'A1''08''8B 06 00 30 01 02 02 05'Zugriffsregel-Referenzen
+ + +Im SE # 1 dürfen nur die Kommandos READ / SEARCH RECORD mit ungesicherter +Kommando und Antwortnachricht ausgeführt werden (Zugriffsregel im Record 2 des +EF_RULE). + +Im SE #2 dürfen die Kommandos APPEND RECORD und UPDATE RECORD nur +ausgeführt werden, wenn sie mit Secure Messaging durchgeführt werden und die +Kommandonachricht mit einem MAC abgesichert ist. Der Returncode wird MAC- +gesichert. Die MAC-Bildung erfolgt für Kommando- und Antwortnachricht mit dem +KHBCI_Admin (Zugriffsregel im Record 5 des EF_RULE). + + +##### . Daten + +Das EF_FBZ enthält in Record '01' einen 2 Byte langen Record, der den Fehlbedie- +nungszähler und den zugehörigen Initialwert '03' für die HBCI-PIN enthält. + + + + + + + + + + + +
Initialwert des FBZFBZ
'03''03'
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionC
Kapitel:ChipapplikationenStand:Seite:
Abschnitt:Chipapplikation für DDV18.07.2013139
+ + +#### C.2.2.8 EF_BNK + + +##### . Beschreibung + +Bei dem EF_BNK handelt es sich um ein lineares EF mit 5 Records in dem Bank- +verbindungen abgelegt sind. + + +##### . Format + +Für das EF_BNK in einer HBCI-Chipkarte sind die folgenden FCP festzulegen: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TagLängeWertErläuterung
'62''18'Tag und Länge für FCP
'82''05''12 41 00 58 05'Datei-Deskriptor für lineares EF mit fester Recordlänge 88 Byte und 5 Records
'83''02''03 01'Datei-ID des EF_BNK
'88''01''D0'SFI '1A' für das EF_BNK
'A1''08''8B 06 00 30 01 06 02 03'Zugriffsregel-Referenzen
+ + +Im SE #1 dürfen READ / SEARCH RECORD immer ausgeführt werden, die Ant- +wortnachricht wird nicht abgesichert. UPDATE RECORD darf nur ausgeführt wer- +den, wenn zuvor eine Karteninhaber-Authentikation mit dem lokalen Passwort 1 +(HBCI-PIN) erfolgt ist. Der Returncode wird nicht MAC-gesichert (Zugriffsregeln im +Record 6 des EF_RULE). + +Im SE #2 darf das Kommando APPEND RECORD nur ausgeführt werden, wenn es +mit Secure Messaging durchgeführt wird. Die MAC-Bildung erfolgt für Kommando- +und Antwortnachricht mit dem KHBCI_Admin (Zugriffsregel im Record 3 des EF_RULE). + + +##### . Daten + +Die Records setzen sich aus einer Bankkurzbezeichnung, der Bankleitzahl, dem +Kommunikationsdienst, der Adresse und dem Adresszusatz für den Kommunikati- +onszugang, dem Länderkennzeichen und der Benutzerkennung zusammen. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ByteLängeWertErläuterung
1-2020'aa .. aa'Kurzbezeichner des Kreditinstituts
21-244'nn nn nn nn'Kreditinstitutscode des kontoführenden Instituts
25-251'n'Kommunikationsdienst
26-5328'aa .. aa'Kommunikationsadresse
54-552'aa aa'Kommunikationsadressenzusatz
56-583'aa aa aa'Länderkennzeichen des kontoführenden Instituts
59-8830'aa .. aa'Benutzerkennung
+ + +Alphanumerische Feldinhalte ('a') werden ASCII-kodiert, linksbündig eingestellt und +mit Leerzeichen (X'20') auf die vorgegebene Länge aufgefüllt. Numerische Feldin- +halte ('n') werden BCD-kodiert. + + + + + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:Stand: 18.07.2013Kapitel: Chipapplikationen
140Abschnitt: Chipapplikation für DDV
+ + +#### C.2.2.9 EF_MAC + + +##### . Beschreibung + +Das EF_MAC wird für die MAC-Bildung über den Hashwert einer Nachricht benötigt. +Es besteht aus einem 12 Byte langem Record deren Zugriffsregeln so gesetzt wer- +den müssen, dass beim Lesen des Records der MAC produziert wird. + + +##### . Format + +Für das EF_MAC sind die folgenden FCP festzulegen: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TagLängeWertErläuterung
'62''18'Tag und Länge für FCP
'82''05''12 41 00 0C 01'Datei-Deskriptor für lineares EF mit einem Record der Länge 12 Byte
'83''02''03 02'Datei-ID des EF_MAC
'88''01''D8'SFI '1B' für das EF_MAC
'A1''08''8B 06 00 30 01 07 02 03'Zugriffsregel-Referenzen
+ + +Im SE #1 dürfen READ / SEARCH RECORD nach Karteninhaber-Authentikation +ausgeführt werden, die Antwortnachricht wird mit einem KDAK-MAC versehen. +UPDATE RECORD darf nur ausgeführt werden, wenn zuvor eine Karteninhaber- +Authentikation mit dem lokalen Passwort 1 (HBCI-PIN) erfolgt ist. Der Returncode +eines UPDATE RECORD wird nicht MAC-gesichert (Zugriffsregeln im Record 7 des +EF_RULE). + +Im SE #2 darf das Kommando APPEND RECORD nur ausgeführt werden, wenn es +mit Secure Messaging durchgeführt wird. Die MAC-Bildung erfolgt für Kommando- +und Antwortnachricht mit dem KHBCI_Admin (Zugriffsregel im Record 3 des EF_RULE). + + +##### . Daten + +Das EF_MAC enthält einen Record, der den folgenden Aufbau hat: + + + + + + + + + + + + + +
ByteWertErläuterung
1-12'XX..XX'Hashwert
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionC
Kapitel:ChipapplikationenStand:Seite:
Abschnitt:Chipapplikation für DDV18.07.2013141
+ + +#### C.2.2.10 EF_SEQ + + +##### . Beschreibung + +Bei dem EF_SEQ handelt es sich um ein lineares EF, dessen Record ein 2 Byte +langes binär definiertes Element enthält. Dieser binäre aufsteigende Zähler fließt als +Sicherheitsreferenznummer (Signatur-ID) zur Absicherung der Daten gegen Doppe- +leinreichung ein. Der Startwert des Zählers ist 1. Ein Rücksetzen bei Überlauf findet +nicht statt. + + +##### . Format + +Für das EF_SEQ sind die folgenden FCP festzulegen: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TagLängeWertErläuterung
'62''18'Tag und Länge für FCP
'82''05''12 41 00 02 01'Datei-Deskriptor für lineares EF mit 1 Record der Länge 2 Byte
'83''02''03 03'Datei-ID des EF_SEQ
'88''01''E0'SFI '1C' für das EF_SEQ
'A1''08''8B 06 00 30 01 06 02 05'Zugriffsregel-Referenzen
+ + +Im SE #1 dürfen READ / SEARCH RECORD immer ausgeführt werden, die Ant- +wortnachricht wird nicht abgesichert. UPDATE RECORD darf nur ausgeführt wer- +den, wenn zuvor eine Karteninhaber-Authentikation mit dem lokalen Passwort 1 +(HBCI-PIN) erfolgt ist. Der Returncode wird nicht MAC-gesichert (Zugriffsregeln im +Record 6 des EF_RULE). + +Im SE #2 dürfen die Kommandos APPEND RECORD und UPDATE RECORD nur +ausgeführt werden, wenn sie mit Secure Messaging durchgeführt werden. Die MAC- +Bildung erfolgt für Kommando- und Antwortnachrichten jeweils mit dem KHBCI_Admin +(Zugriffsregel im Record 5 des EF_RULE). + + +##### . Daten + +Das EF_SEQ enthält 1 Record, der den folgenden Aufbau hat: + + + + + + + + + + + + + + + + + + + + + + + +
ByteWertErläuterung
1-2'XX XX'Sequenznummer
Kapitel: CVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite: 142Stand: 18.07.2013Kapitel: Chipapplikationen
Abschnitt: Chipapplikation für DDV
+ + +#### C.2.3 Platzbedarf der Applikation im Chip + +Die Platzbedarfsberechnung ist sehr stark von der Stärke der ROM-Maske abhän- +gig. Der notwendige Platz für die EF-Verwaltung z.B. Recordnummern- bzw. +Adressverwaltung steht im direkten Zusammenhang mit der Verwaltung des E2- +PROM. Diese Verwaltung ist Bestandteil der ROM-Maske. Der tatsächliche exakte +Platzbedarf kann nur von den ROM-Maskenentwicklern ermittelt werden. Er ist von +Chip zu Chip und ROM-Maske zu ROM-Maske unterschiedlich. + + +##### . Typ 0 + +Die nachfolgende Tabelle enthält daher nur die Nettodatengröße der "Banking"- +Applikation. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
DateinameHeadergröße17Datengröße
DF_Banking2826
EF_KEY2317
EF_KEYD235
EF_AUT2317
EF_AUTD234
EF_PWD1258
EF_PWDD1235
EF_BNK23440
EF_MAC2312
EF_SEQ232
237536
+ + +Demnach hat die Applikation "Banking" einen Mindestplatzbedarf von 773 Byte. + + +###### ◆ Typ 1 + +Die nachfolgende Tabelle enthält daher nur eine grobe Abschätzung der Netto- +datengrößen (in Byte) der Applikation. Dabei wurde als Overhead die Größe des je- +weiligen FCP zugrundegelegt. Zusätzlich wurde das FMD des DF_BANKING_20 +(enthält die vergebenen SFIs sowie deren Pfade) als "Nutzdaten" des DF interpre- +tiert. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
DateinameOverheadNutzdaten
DF_BANKING_202868
EF_KEY2454
EF_KEYD3072
EF_PWD249
EF_PWDD3021
EF_FBZ262
EF_RULE30125
EF_BNK26440
EF_MAC2612
EF_SEQ262
270805
+ + +Demnach hat die HBCI-Applikation einen Platzbedarf von ca. 1075 Byte. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionC
Kapitel:ChipapplikationenStand:Seite:
Abschnitt:Chipapplikation für DDV18.07.2013143
+ + +#### C.2.4 Terminalabläufe (Typ 1 und SECCOS 6) + +Nachfolgend werden die Anwendungsabläufe aus Endgerätesicht spezifiziert. Hier- +bei werden ausschließlich die chipkartenbezogenen Aspekte berücksichtigt. Anwen- +dungsbezogene Details sind nicht Bestandteil dieser Spezifikation. + +Falls bei der Ausführung der Kommandos ein Fehler auftritt, bricht das Terminal den +Vorgang ab, es sei denn, es ist ein abweichendes Verhalten spezifiziert. + + +### C.2.4.1 Startdialog + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
HBCI-Chipkarte
R1ATR der HBCI-Chipkarte
R2OK
R3Kartenidentifikationsdaten (CID)
R4OK
R4Sequenznummer (SEQ)
R5Bankverbindung
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
→ ← → ← →
← →
← →
← →		Endgerät/Gateway
A1
C1		Anzeige: 'Bitte Karte einstecken'
Reset HBCI-Chipkarte
C2SELECT FILE DF_BANKING(_20)
C3
A3		READ RECORD EF_ID
CID prüfen und speichern
A4
C4		HBCI-PIN-Eingabe und Formatie- rung
VERIFY HBCI-PIN
C5READ RECORD EF_SEQ
A5SEQ speichern
C6
A6		READ RECORD EF_BNK
Daten prüfen und speichern
+ + +#### ◆ Erläuterung + +1\. Nachdem die HBCI-Chipkarte eingesteckt ist, wird ein Reset der Karte durchgeführt +(Kommunikationsprotokoll T = 1). Der korrekte ATR und seine Behandlung sind z.B. +in [LT] spezifiziert. + +2\. Die Applikation HBCI-Banking wird geöffnet, indem das ADF der Applikation, +DF_BANKING_20 für HBCI-Karten von Typ 1 oder DF_BANKING für HBCI-Karten +von Typ 0, durch das Terminal mittels des Kommandos SELECT FILE ausgewählt +wird. Dabei wird zunächst versucht, die neue Applikation DF_BANKING_20 zu se- +lektieren. Bei einem Returncode '6A 82' ist die Applikation nicht vorhanden. Es wird +dann die "alte" Applikation DF_BANKING selektiert. + +Command APDU: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ByteWertErläuterung
1-2'00 A4'CLA, INS
3'04'P1, Selektion mit DF-Name
4'0C'P2, Keine Antwortdaten
5'09'Lc
6-14'D2 76 00 00 25 48 42 0X 00'AID der HBCI-Applikation (X=1,2)
Kapitel: CVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite: 144Stand: 18.07.2013Kapitel: Chipapplikationen
Abschnitt: Chipapplikation für DDV
+ + +Nachdem der Applikationskontext geöffnet ist, können die AEFs der Applikation mit- +tels SFI referenziert werden. Das Terminal hält die Information vor, um welchen Kar- +tentyp es sich handelt + +3\. Das Terminal liest mittels READ RECORD die Kartenidentifikationsdaten im Re- +cord '01' des EF_ID im MF der HBCI-Karte (SFI '19'). + +Command APDU: + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ByteWertErläuterung
1-2'00 B2'CLA, INS
3'01'P1, Recordnummer
4'CC'P2, Reference Control Byte
5'00'Le
+ + +Wenn das READ RECORD erfolgreich ausgeführt wird, gibt die HBCI-Karte eine +Antwortnachricht mit der folgenden Struktur zurück. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ByteWertErläuterung
1'67'Branchenhauptschlüssel
2-4'2n nn nn'Kurz-BLZ kartenausgebendes Institut
5-9'nn..nn'individuelle Kartennummer
10'nD'Prüfziffer für Byte 1 - 9
11-12'JJ MM'Verfalldatum der Karte
13-15'JJ MM TT'Aktivierungsdatum der Karte
16-17'0280'Ländercode
18-20'44 45 4D' oder '45 55 52'Währungskennzeichen "DEM" oder "EUR"
21'01'Wertigkeit der Währung
22'XX'Chiptyp
23'00'Filler
24'XX'Betriebssystem-Version
23-24 oder 25-26'XX XX'Positiver Returncode SW1 SW2
+ + +Die Antwortdaten sind mindestens 22 Byte lang und können für Karten von Typ 1 +länger als 24 Byte sein. + +Die Kodierung der empfangenen Daten wird geprüft: + +Wenn eine Karte von Typ 0 mehr als 22 Byte Antwortdaten ausgibt, oder wenn eine +Karte von Typ 1 weniger als 24 Byte Antwortdaten ausgibt, oder wenn Währungs- +kennzeichen in Byte 18-20 oder Wertigkeit der Währung in Byte 21 nicht korrekt ko- +diert sind, oder wenn eine Karte von Typ 0 das Währungskennzeichen "EUR" oder +eine Karte von Typ 1 das Währungskennzeichen "DEM" ausgibt, oder wenn Byte 24 +einer Karte von Typ 1 den Wert '00' hat sowie bei jedem anderen Fehlerfall wird mit +einer Fehlermeldung abgebrochen. + +4\. Das Terminal fordert den Karteninhaber auf, die PIN einzugeben und formatiert +dann die eingegebene PIN zum Format 2 PIN-Block FPIN2. Das Terminal baut eine +Kommandonachricht für das Kommando VERIFY auf. + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: C
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final Version
Kapitel:ChipapplikationenStand:Seite:
Abschnitt:Chipapplikation für DDV18.07.2013145
+ + +Command APDU: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ByteWertErläuterung
1'00 20'CLA, INS
3'00'P1, fester Wert
4'81'P2, PIN im EF_PWD1 des DF suchen (bzw. hat PWDID '01')
5'08'Lc
6-13'XX..XX'FPIN2
+ + +Die Chipkarte führt die PIN-Prüfung durch und setzt das Flag des entsprechenden +Sicherheitszustands, wenn die PIN-Prüfung erfolgreich war. Andernfalls wird der +PIN-Fehlbedienungszähler dekrementiert. + +Durch den Returncode des Kommandos VERIFY teilt die Chipkarte dem Terminal +mit, ob die Prüfung erfolgreich war, bzw. wie viele Versuche noch möglich sind. + +5\. Das Terminal liest mittels READ RECORD die Sequenznummer im Record '01' des +EF_SEQ (SFI '1C'). + +Command APDU: + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ByteWertErläuterung
1-2'00 B2'CLA, INS
3'01'P1, Recordnummer
4'E4'P2, Reference Control Byte
5'00'Le
+ + +Wenn das READ RECORD erfolgreich ausgeführt wird, gibt die HBCI-Karte eine +Antwortnachricht mit der folgenden Struktur zurück. + + + + + + + + + + + + + + + + + + +
ByteWertErläuterung
1-2'XX XX'Sequenzzähler
3-4'XX XX'Positiver Returncode SW1 SW2
+ + +Das Terminal speichert den Wert des Sequenzzählers. + +6\. Das Terminal liest mittels READ RECORD sukzessive die Bankverbindungsdaten in +den Records des EF_BNK (SFI '1A'), bis der "passende" Eintrag gefunden wird. + +Command APDU: + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ByteWertErläuterung
1-2'00 B2'CLA, INS
3'0Χ'P1, Recordnummer X
4'D4'P2, Reference Control Byte
5'00'Le
+ + +Wenn das READ RECORD erfolgreich ausgeführt wird, gibt die HBCI-Karte eine +Antwortnachricht mit der folgenden Struktur zurück: + + + + + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:Stand:
18.07.2013		Kapitel: Chipapplikationen
146Abschnitt:
Chipapplikation für DDV
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ByteLängeWertErläuterung
1-2020'aa .. aa'Kurzbezeichner des Kreditinstituts
21-244'nn nn nn nn'Bankleitzahl des kontoführenden Instituts
25-251'n'Kommunikationsdienst
26-5328'aa .. aa'Kommunikationsadresse
54-552'aa aa'Kommunikationsadressenzusatz
56-583'aa aa aa'Länderkennzeichen des kontoführenden Instituts
59-8830'aa .. aa'Benutzerkennung
89-902'XX XX'Positiver Returncode SW1 SW2
+ + +Alternativ kann für Chipkarten vom Typ 1 das Kommando SEARCH RECORD ver- +wendet werden, um mittels eines mit übergebenen Suchmusters den "passenden" +Eintrag in einem Schritt zu finden. + +Beispiel: Es soll der erste Eintrag zu einer vorgegebenen Bankleitzahl des kontofüh- +renden Instituts (an Byteposition 21-24) gefunden werden: + +Command APDU: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ByteWertErläuterung
1-2'00 A2'CLA, INS
3'01'P1, Recordnummer an der die Suche startet
4'D7'P2, Reference Control Byte (SFI + spezifische Su- che)
5'07'LC
6'04'Control Byte
7'14'Offset 20 = Byte 21
8'0E'Konfigurationsbyte: Suche an dieser Position bis zum ersten erfolgreichen Record mit Rückgabe des Inhalts
9-12'nn nn nn nn'Bankleitzahl-Suchmuster
13'00'Le
+ + +Das Kommando SEARCH RECORD gibt bei erfolgreicher Kommandoausführung +die folgende Antwortnachricht aus: + + + + + + + + + + + + + + + + + + + + + + + +
ByteWertErläuterung
1'XX'Recordnummer
2-89'XX..XX'Recordinhalt
90-91'XX XX'Statusbytes
+ + +Es sind auch weitere, umfangreichere Suchoptionen möglich (z.B. alle passenden +Einträge ermitteln oder Intervallsuche), siehe hierzu [LIT 1']. + + +### C.2.4.2Nachricht generieren + +Dieser Teil des Gesamtablaufs ist nur insofern chipkartenrelevant, als Bankverbin- +dungsdaten, die für die Auftragsgenerierung benötigt werden, aus der Chipkarte +entnommen werden. Für die folgende Ablaufbeschreibung wird angenommen, dass +die Anwendung bereits HBCI-Nachrichten generiert hat. Diese Nachrichten müssen +jetzt ggf. noch kryptographisch gesichert werden, d.h. es werden Segmente für die +elektronische(n) Signatur(en) und für die Verschlüsselung entsprechend den HBCI- +Spezifikationen eingefügt. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionC
Kapitel:ChipapplikationenStand:Seite:
Abschnitt:Chipapplikation für DDV18.07.2013147
+ + +### C.2.4.3 Nachricht signieren + +Die folgenden Abläufe können offline, d.h. außerhalb des Übertragungsdialogs voll- +zogen werden. Dies gilt für alle Nachrichten mit Ausnahme der Dialoginitialisierung. +Der Grund besteht darin, dass für die Absicherung aller Kreditinstitutsnachrichten +der Schlüssel des Senders der Dialoginitialisierungsnachricht erforderlich ist. Daher +muss auch die Chipkarte des Senders während des gesamten Dialogs im Endgerät +stecken. + +Die Abläufe für die Signatur der Dialoginitialisierungsnachricht sind grundsätzlich +identisch mit den im Folgenden beschriebenen Abläufen für die Signatur von Auf- +tragsnachrichten. Da aber für die Dialoginitialisierung anwendungsseitig noch wei- +tere Chipkartendaten (Benutzerkennung, Dialog-ID, Kommunikationszugang etc.) +benötigt werden, wird der komplette Ablauf einschlieBlich der Signatur der Dialogini- +tialisierung im Kapitel C.2.4.5 "Übertragungsdialog" noch einmal beschrieben. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
HBCI-Chipkarte
R1aKV
R1bOK
R1cDatensatz
R6OK
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Endgerät/Gateway
C1a
A1a		GET KEYINFO (nur Typ 1)
Schlüsselversion KV speichern
C1b
C1c		SELECT EF_KEYD (nur Typ 0)
READ RECORD EF_KEYD (nur Typ 0)
A1cSchlüsselversion KV speichern
A2Sequenzzähler (Signatur-ID) SEQ inkre- mentieren
A3Signaturkopf aufbauen und in HBCI- Nachricht einfügen
A4Daten (Signaturkopf, HBCI-Nutzdaten) für MAC-Berechnung bereitstellen
M5MAC über Daten berechnen (siehe Kap. C.2.5.1)
C6UPDATE RECORD EF_SEQ mit SEQ
A7Signaturabschluss aufbauen und in HBCI- Nachricht einfügen
A8ggf. A2 bis A7 für weitere Nachrichten wiederholen
A9signierte HBCI-Nachrichten zur Weiter- verarbeitung speichern
A10ggf. Startdialog und A1 bis A9 für Mehr- fachsignaturen wiederholen
+ + +#### ◆ Erläuterung + +1\. In diesem Schritt stellt das Terminal fest, welcher Daten-Authentikationsschlüssel +KGKDAK bzw. KDAK zur Signatur der Nachricht verwendet werden muss. Dabei wird +Schritt 1a nur für Karten vom Typ 1, Schritt 1b und 1c nur für Karten vom Typ 0 +durchgeführt. + +1a. Falls es sich um eine HBCI-Karte von Typ 1 handelt, wird hierzu das Kommando +GET KEYINFO verwendet. + +↓ ↑ ↓ ↑ +← + +← +→ + +← +→ +← +→ + + + + + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:Stand: 18.07.2013Kapitel: Chipapplikationen
148Abschnitt: Chipapplikation für DDV
+ + +# Command APDU: + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ByteWertErläuterung
1-2'BO EE'CLA,INS
3'80'P1 für "DF-spezifisch"
4'02'P2, Schlüsselnummer
5,00،Le
+ + +Bei der erfolgreichen Ausführung des GET KEYINFO gibt die HBCI-Karte eine Ant- +wortnachricht mit der folgenden Struktur zurück: + + + + + + + + + + + + + + + + + + +
ByteWertErläuterung
1'XX'1 vorhandene Schlüssel-Version KV
2-3'XX XX'Positiver Returncode SW1 SW2
+ + +Die Schlüsselversion wird gespeichert. + +1b. Falls es sich um eine HBCI-Karte von Typ 0 handelt, wird hierzu das EF_KEYD im +DF_BANKING mittels SELECT FILE EF_KEYD ausgewählt. + +Command APDU: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ByteWertErläuterung
1-2'00 A4'CLA, INS
3'02'P1, Selektion eines EF im aktuellen DF
4'0C'P2, Keine Antwortdaten
5'02'Lc
6-7'00 13'Datei-ID von EF_KEYD
+ + +1c. Mittels READ RECORD liest das Terminal aus Record '02' die Zusatzinformationen +für den Schlüssel KDAK· + +Command APDU: + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ByteWertErläuterung
1-2'00 B2'CLA, INS
3'02'P1, Recordnummer für logische Schlüsselnr. '02'
4'04'P2, Reference Control Byte
5'00'Le
+ + +Wenn das READ RECORD erfolgreich ausgeführt wurde, gibt die HBCI-Karte die +folgende Antwortnachricht zurück: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ByteWertErläuterung
1'02'Logische Schlüsselnummer
2'10'Schlüssellänge
3'07'Algorithmus-ID
4'XX'Fehlbedienungszähler
5'XX'Schlüssel-Version
6-7'XX XX'Positiver Returncode SW1 SW2
+ + +Die Schlüsselversion wird gespeichert. + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: C
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final Version
Kapitel:ChipapplikationenStand:Seite:
Abschnitt:Chipapplikation für DDV18.07.2013149
+ + +2\. Der zuvor gelesene und gespeicherte Sequenzzähler SEQ wird inkrementiert. + +3\. Der Signaturkopf wird aufgebaut und in die HBCI-Nachricht eingefügt. + +4\. Die Daten (Signaturkopf, HBCI-Nutzdaten) für die MAC-Berechnung werden bereit- +gestellt. + +5\. Der MAC über die Daten wird berechnet (siehe hierzu Kap. C.2.5.1). + +6\. Das Terminal überschreibt den Sequenzzähler in EF_SEQ mit dem inkrementierten +Wert. Dies geschieht durch ein UPDATE RECORD EF_SEQ ohne Secure Mes- +saging. Aufgrund der Zugriffsbedingungen für das EF_SEQ kann das Kommando +nur ausgeführt werden, wenn zuvor die HBCI-PIN erfolgreich verifiziert wurde. + +Command APDU: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ByteWertErläuterung
1-2'00 DC'CLA, INS
3'01'P1, Recordnummer
4'E4'P2, Reference Control Byte (SFI '1C')
5'02'Lc
6-7'XX XX'neuer Sequenzzähler SEQ
+ + +7\. Der Signaturabschluß wird aufgebaut und in die HBCI-Nachricht eingefügt. + +8\. Ggf. können die Schritte 2 bis 7 für weitere Nachrichten wiederholt werden. Schritt 1 +braucht nicht erneut durchgeführt zu werden, da die zu verwendende Schlüsselver- +sion bereits gespeichert ist.. + +9\. Die signierten HBCI-Nachrichten können zur Weiterverarbeitung gespeichert wer- +den. + +10\. Ggf. werden Startdialog und die Schritte 1 bis 9 für Mehrfachsignaturen wiederholt. + + + + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:
150		Stand:
18.07.2013		Kapitel: Chipapplikationen
Abschnitt:
Chipapplikation für DDV
+ + +# C.2.4.4Nachricht verschlüsseln + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
HBCI-Chipkarte
R1aKV
R1b
R1c		OK
Datensatz
R3RND
R4e* KENC(KSL)
R5RND
R6e* KENC(KSR)
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Endgerät/Gateway
← →
→
← →
← →
← →
←
→
← →		C1a
A1a		GET KEYINFO (nur Typ 1)
Schlüsselversion KV speichern
C1b
C1c
A1c		SELECT EF_AUTD (nur Typ 0)
READ RECORD EF_AUTD (nur Typ 0)
Schlüsselversion KV speichern
A2Daten (HBCI-Nutzdaten und ggf. Signa- turkopf/-abschluss) für die Verschlüsse- lung bereitstellen
C3
A3		GET CHALLENGE
RND als Nachrichtenschlüssel-Hälfte KSL speichern
C4
A4		INTERNAL AUTHENTICATE mit KSL
e* KENC(KSL) speichern
C5
A5		GET CHALLENGE
RND als Nachrichtenschlüssel-Hälfte KSR speichern
C6
A6		INTERNAL AUTHENTICATE mit KSR
e* KENC(KSR) speichern
A7e* KENC(KSL) mit e* KENC(KSR) zu e* KENC(KS) konkatenieren und speichern
A8KSL mit KSR zu KS konkatenieren und Da- ten mit KS verschlüsseln (Triple-DES CBC-Mode, IV=0, X9.23 Padding)
A9Verschlüsselungskopf aufbauen und in HBCI-Nachricht einfügen
A10Verschlüsselte Daten als Binärdaten in HBCI-Nachricht einfügen
A11ggf. A2 bis A10 für weitere Nachrichten wiederholen
A12Verschlüsselte und signierte HBCI-Mel- dungen zur weiteren Bearbeitung spei- chern
+ + +## ◆ Erläuterung + +1\. In diesem Schritt stellt das Terminal fest, welche Version des Chiffrierschlüssels +KGKENC bzw. KENC zur Verschlüsselung der Nachricht verwendet werden muß. +Dabei wird Schritt 1a nur für Karten vom Typ 1, Schritt 1b und 1c nur für Karten vom +Typ 0 durchgeführt. + +1a. Falls es sich um eine HBCI-Karte von Typ 1 handelt, wird hierzu das Kommando +GET KEYINFO verwendet. + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: C
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final Version
Kapitel:ChipapplikationenStand:Seite:
Abschnitt:Chipapplikation für DDV18.07.2013151
+ + +# Command APDU: + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ByteWertErläuterung
1-2'BO EE'CLA,INS
3'80'P1 für "DF-spezifisch"
4'03'P2, Schlüsselnummer
5,00،Le
+ + +Bei der erfolgreichen Ausführung des GET KEYINFO gibt die HBCI-Karte eine Ant- +wortnachricht mit der folgenden Struktur zurück: + + + + + + + + + + + + + + + + + + +
ByteWertErläuterung
1'XX'1 vorhandene Schlüssel-Version KV
2-3'XX XX'Positiver Returncode SW1 SW2
+ + +Die Schlüsselversion wird gespeichert. + +1b. Falls es sich um eine HBCI-Karte von Typ 0 handelt, wird hierzu das EF_AUTD im +DF_BANKING mittels SELECT FILE EF_AUTD ausgewählt. + +Command APDU: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ByteWertErläuterung
1-2'00 A4'CLA, INS
3'02'P1, Selektion eines EF im aktuellen DF
4'0C'P2, Keine Antwortdaten
5'02'Lc
6-7'00 14'Datei-ID von EF_AUTD
+ + +1c. Mittels READ RECORD liest das Terminal die Zusatzinformationen für den Schlüs- +sel KENC. Diese sind im Record '01' des selektierten EF_AUTD zu finden. + +Command APDU: + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ByteWertErläuterung
1-2'00 B2'CLA, INS
3'01'P1, Recordnummer für logische Schlüsselnr. '00'
4'04'P2, Reference Control Byte
5'00'Le
+ + +Wenn das READ RECORD erfolgreich ausgeführt wurde, gibt die HBCI-Karte die +folgende Antwortnachricht zurück: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ByteWertErläuterung
1'03'Logische Schlüsselnummer
2'10'Schlüssellänge
3'07'Algorithmus-ID
4'XX'Schlüssel-Version
5-6'XX XX'Positiver Returncode SW1 SW2
+ + +Die Schlüsselversion wird gespeichert. + +2\. Die Daten (HBCI-Nutzdaten und ggf. Signaturkopf/-abschluss) für die Verschlüsse- +lung werden bereitgestellt. + + + + + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:Stand: 18.07.2013Kapitel: Chipapplikationen
152Abschnitt: Chipapplikation für DDV
+ + +3\. Mit dem Kommando GET CHALLENGE lässt sich das Terminal eine Zufallszahl von +der HBCI-Karte geben. + +Command APDU: + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ByteWertErläuterung
1-2'00 84'CLA, INS
3'00'P1
4'00'P2
5'00'Le
+ + +Wenn das Kommando erfolgreich ausgeführt wurde, gibt die HBCI-Karte eine 8 Byte +lange Zufallszahl als Antwortdatum aus, die als Nachrichtenschlüssel-Hälfte KSL ge- +speichert wird. + +4\. Mit dem Kommando INTERNAL AUTHENTICATE wird der Wert KSL von der HBCI- +Karte mit dem Schlüssel KENC verschlüsselt und in der Antwortnachricht als e* +KENC(KSL) übergeben. + +Command APDU: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ByteWertErläuterung
1-2'00 88'CLA, INS
3'00'P1
4'80' oder '83'P2, Typ 0: '80' (log. Schlüsselnummer '00'), Typ 1: '83' (log. Schlüsselnummer '03')
5'08'Lc
6-13'XX .. XX'Zufallszahl KSL
14'00'Le
+ + +Das Kommando INTERNAL AUTHENTICATE gibt folgende Antwortnachricht zu- +rück: + + + + + + + + + + + + + + + + + + +
ByteWertErläuterung
1-8'XX .. XX'Verschlüsselter Wert e* KENC(KSL)
9-10'XX XX'Positiver Returncode SW1 SW2
+ + +5\. Mit dem Kommando GET CHALLENGE lässt sich das Terminal eine weitere Zu- +fallszahl von der HBCI-Karte geben, die als Nachrichtenschlüssel-Hälfte KSR ge- +speichert wird. + +6\. Analog zu Schritt 4 wird ein INTERNAL AUTHENTICATE mit KSR durchgeführt. + +7\. e* KENC(KSL) wird mit e* KENC(KSR) zu e* KENC(KS) konkateniert und gespeichert. + +8\. KSL wird mit KSR zu KS konkateniert und die Daten werden mit KS verschlüsselt +(Triple-DES CBC-Mode, IV=0, X9.23 Padding). + +9\. Der Verschlüsselungskopf wird aufgebaut und in die HBCI-Nachricht eingefügt. + +10\. Die verschlüsselten Daten als Binärdaten in die HBCI-Nachricht eingefügt. + +11\. Ggf. werden die Schritte 2 bis 10 für weitere Nachrichten wiederholt (eine Wiederho- +lung von Schritt 1 ist nicht nötig). + +12\. Die verschlüsselten und signierten HBCI-Meldungen werden zur weiteren Bearbei- +tung gespeichert. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionC
Kapitel:ChipapplikationenStand:Seite:
Abschnitt:Chipapplikation für DDV18.07.2013153
+ + +# C.2.4.5Übertragungsdialog + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Endgerät/GatewayKreditinstitut
A1Sequenzzähler (Signatur-ID) SEQ inkrementieren↑↓
A2Benutzerkennung aus der bereits gelesenen Bankverbindung (EF_BNK) ermitteln
A3Dialoginitialisierungsnachricht auf- bauen
A4Signaturkopf aufbauen und in HBCI- Nachricht einfügen
A5Daten (Signaturkopf, HBCI-Nutzda- ten) für MAC-Berechnung bereit- stellen
M6MAC über Daten berechnen (siehe Kap. C.2.5.1)
C7UPDATE RECORD EF_SEQ mit SEQ
A8Signaturabschluss aufbauen und in HBCI-Nachricht einfügen
A9Kommunikationszugang aus Bank- verbindung herstellen
C10Nachricht (beginnend mit Dialog- initialisierungsnachricht) sendenR10Antwortnach- richt senden
A11falls Antwortnachricht verschlüsselt: Daten (Binärdaten nach dem Signa- turkopf) und d*KENC(KS) aus dem Signaturkopf für die Entschlüsselung bereitstellen
M12Daten entschlüsseln (siehe Kap. C.2.5.2)
A13falls Kreditinstitutsnachricht signiert: Daten (Signaturkopf, Nutzdaten) und Referenz-MAC für MAC-Prüfung be- reitstellen
M14MAC über Daten und Referenz-MAC prüfen (siehe Kap. C.2.5.2)
A15C10 bis M14 für alle weiteren HBCI- Nachrichten wiederholen
+ + +HBCI-Chipkarte + +↓ ↑ ↓ ↑ + +R7 + +OK + +↓↑ + +↓↑ + + + + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite: 154Stand: 18.07.2013Kapitel: Chipapplikationen
Abschnitt: Chipapplikation für DDV
+ + +# C.2.5 Makros + + +## C.2.5.1 MAC-Berechnung / Prüfung + + + + + + + + + + + + + + + + + + + + + + + + + + +
HBCI-Chipkarte
R3OK
R4OK
R5Daten aus EF_MAC mit CFB-64 MAC über HASHR (iden- tisch mit CBC-MAC über HASH)
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
Endgerät/Gateway
A1Hashwert HASH über Daten berech- nen (RIPEMD160)
A2HASH zerlegen in HASHL (die linken 8 Byte von HASH) und HASHR (die rest- lichen 12 Byte)
C3UPDATE RECORD EF_MAC mit HASHR
C4PUT DATA mit HASHL (nur Typ 0)
C5
A5		READ RECORD EF_MAC mit Secure Messaging (für Typ 1 wird hier HASHL mit über- geben)
Bei MAC-Berechnung: MAC zwischen- speichern
Bei MAC-Prüfung: MAC aus Kreditin- stitutsnachricht mit MAC der Chipkarte vergleichen
+ + +### ◆ Erläuterung + +1\. Der Hashwert HASH wird über die Daten berechnet (RIPEMD160). + +2\. Der Hashwert HASH wird zerlegt in HASHL (die linken 8 Byte von HASH) und +HASHR (die restlichen 12 Byte). + +3\. HASHR wird in den ersten Record des EF_MAC eingetragen. Die Zugriffsbedingung +für das EF_MAC stellt sicher, daß das UPDATE-Kommando nur ausgeführt werden +kann, wenn zuvor die HBCI-PIN verifiziert wurde. + +Command APDU: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ByteWertErläuterung
1-2'00 DC'CLA, INS
3'01'P1, Recordnummer
4'DC'P2, Reference Control Byte (SFI '1B')
5'0C'Lc
6-17'XX .. XX'Recordinhalt HASHR
+ + +4\. Das Terminal übergibt HASHL mittels PUT DATA an die HBCI-Karte. Dieser Schritt +wird nur für Karten vom Typ 0 durchgeführt, da für Karten vom Typ 1 der Zufallswert +als Bestandteil des Kommandos im nächsten Schritt übergeben wird. + +↓ ↑ ↓ ↑ ↓ + +→ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: C
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final Version
Kapitel:ChipapplikationenStand:Seite:
Abschnitt:Chipapplikation für DDV18.07.2013155
+ + +Command APDU: + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ByteWertErläuterung
1-2'00 DA'CLA, INS
3-4'01 00'P1, P2
5'08'Lc
6-13'XX..XX'HASHL
+ + +5\. Das Terminal liest mittels READ RECORD den soeben in EF_MAC eingetragenen +Hash-Wert mit Secure Messaging. + +Command APDU für Chipkarten vom Typ 0: + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ByteWertErläuterung
1-2'04 B2'CLA, INS
3'01'P1, Recordnummer
4'DC'P2, Reference Control Byte
5'00'Le
+ + +Wenn das READ RECORD erfolgreich ausgeführt wird, gibt die HBCI-Karte eine +Antwortnachricht mit der folgenden Struktur zurück: + + + + + + + + + + + + + + + + + + + + + + + +
ByteWertErläuterung
1-12'XX … XX'Recordinhalt HASHR
13-20'XX … XX'CFB-MAC mit KENC über die 16 Byte 1-12|'00 00 00 00' mit ICV= HASHL
21-22'XX XX'Positiver Returncode SW1 SW2
+ + +## Command APDU für Chipkarten vom Typ 1:18 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ByteWertErläuterung
1-2'08 B2'CLA, INS mit Secure Messaging
3'01'P1, Recordnummer
4'DC'P2, Reference Control Byte
5'11'LC
6-7'BA 0C'Tag und Länge für Response Descriptor
8-9'B4 0A'Tag und Länge für CCT
10-11'87 08'Tag und Länge für Zufallszahl
12-19'XX..XX'Zufallszahl HASHL
20-22'96 01 00'Tag, Länge und Wert des Le-Datenobjekts
23'00'Le
+ + +Wenn das READ RECORD erfolgreich ausgeführt wird, gibt die HBCI-Karte eine +Antwortnachricht mit der folgenden Struktur zurück: + + + + + + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:Stand: 18.07.2013Kapitel: Chipapplikationen
156Abschnitt: Chipapplikation für DDV
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ByteWertErläuterung
1-2'81 0C'Tag und Länge des Klartext-Datenobjekts
3-14'XX … XX'Recordinhalt HASHR
15-16'8E 08'Tag und Länge des MAC-Datenobjekts
17-24'XX … XX'CFB-MAC mit KDAK über die 16 Byte 1-14|'80 00' mit ICV = HASHL
25-26'XX XX'Positiver Returncode SW1 SW2
+ + +Das Terminal speichert den Wert des MAC. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionC
Kapitel:ChipapplikationenStand:Seite:
Abschnitt:Chipapplikation für DDV18.07.2013157
+ + +## C.2.5.2 Entschlüsselung + + + + + + + + + + + + + + + + + + + + + + +
HBCI-Chipkarte
R2KSL
R3KSR
+ + +↓↑ ↓↑ + + + + + + + + + + + + + + + + + + + + + + +
Endgerät/Gateway
A1d* KENC(KS) in die zwei Hälften d* KENC(KSL) und d* KENC(KSR) zerlegen
C2
A2		INTERNAL AUTHENTICATE mit d* KENC(KSL)
KSL zwischenspeichern
C3
A3		INTERNAL AUTHENTICATE mit d* KENC(KSR)
KSR zwischenspeichern
A4KSL mit KSR zu KS konkatenieren und Daten mit KS entschlüsseln (Triple-DES CBC- Mode, IV=0, X9.23 Padding)
+ + +### ◆ Erläuterung + +1\. $\mathrm { d } ^ { * } \mathrm { K } _ { \mathrm { E N C } } \left( \mathrm { K S } \right)$ wird in die zwei Hälften $\mathrm { d } ^ { * } \mathrm { K } _ { \mathrm { E N C } } \left( \mathrm { K S } _ { \mathrm { L } } \right)$ und $\mathrm { d } ^ { * } \mathrm { K } _ { \mathrm { E N C } } \left( \mathrm { K S } _ { \mathrm { R } } \right)$ zerlegt. + +2\. Mit dem Kommando INTERNAL AUTHENTICATE wird der Wert $\mathrm { d } ^ { * } \mathrm { K } _ { \mathrm { E N C } } \left( \mathrm { K S } _ { \mathrm { L } } \right)$ von +der HBCI-Karte mit dem Schlüssel KENC entschlüsselt und in der Antwortnachricht +als KSL übergeben. + +Command APDU: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ByteWertErläuterung
1-2'00 88'CLA, INS
3'00'P1
4'80' oder '83'P2, Typ 0: '80' (log. Schlüsselnummer '00'), Typ 1: '83' (log. Schlüsselnummer '03')
5'08'Lc
6-13'XX .. XX'Parameterwert d* $\mathrm { K } _ { \mathrm { E N C } } \left( \mathrm { K S } _ { \mathrm { L } } \right)$
14'08'Le
+ + +Das Kommando INTERNAL AUTHENTICATE gibt folgende Antwortnachricht zu- +rück: + + + + + + + + + + + + + + + + + + +
ByteWertErläuterung
1-8'XX .. XX'Entschlüsselter Wert KSL
9-10'XX XX'Positiver Returncode SW1 SW2
+ + +KSL wird gespeichert. + +3\. Analog zu Schritt 2 wird ein INTERNAL AUTHENTICATE mit d* $\mathrm { K } _ { \mathrm { E N C } } \left( \mathrm { K S } _ { \mathrm { R } } \right)$ durchge- +führt. Das Ergebnis wird als KSR gespeichert. + +4\. KSL wird mit KSR zu KS konkateniert und die Daten werden mit KS entschlüsselt +(Triple-DES CBC-Mode, IV=0, X9.23 Padding). + + + + + + + + + + + + + + + + + + + +
Kapitel: CVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:Stand: 18.07.2013Kapitel: Chipapplikationen
158Abschnitt: Chipapplikation für DDV
+ + +## C.2.6 Übersicht der Chip-Applikations-Parameter + + +### . Dateistruktur + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
LageDatei- IDNameSFIZugriffsregel SE #1 (Standard)Zugriffsregel SE #2 (Admin)
MF'00 03'EF_ID'19'
'A6 00'DF_BANKING_201
DF_BANKING_20'00 30'EF_RULE'01'23
'00 10'EF_KEY'02'--4
'00 12'EF_PWD'03'--4
'00 13'EF_KEYD'1E'25
'00 15'EF_PWDD'04'25
'00 16'EF_FBZ'05'25
'03 01'EF_BNK'1A'63
'03 02'EF_MAC'1B'73
'03 03'EF_SEQ'1C'65
+ + +### . Zugriffsregeln + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
#READ / SEARCH RECORDAPPEND RECORDUPDATE RECORDIN-/EXCLUDE CREATE EF DELETE selfVERIFY CHANGE REF DATARESET RETRY COUNTER
1KHBCI_Admin-MAC
2ALW
3KHBCI_Admin“ MACNEV
4KHBCI_Admin-ENC-MAC (K) KHBCI_Admin-MAC (A)
5KHBCI_Admin-MAC
6ALWHBCI-PIN
7HBCI-PIN KDAK-MAC (A)HBCI-PIN
8ALWKHBCI_Admin“ MAC
+ + +Die angegebenen Access Conditions gelten sowohl für Kommando- (K) als auch +Antwortnachrichten (A), sonst in Klammern eingeschränkt. + + +### ◆ Schlüssel der Applikation + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Logische Schlüsselnr.Erlaubte SE #SchlüsselWer kennt den Masterschlüssel
'01'2KHBCI_Adminzuständiges Hintergrundsystem
'02'1KDAKzuständiges Hintergrundsystem
'03'1KENCzuständiges Hintergrundsystem
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionD
Kapitel:Data DictionaryStand:Seite:
Abschnitt:Buchstabe A18.07.2013159
+ + +# D. DATA DICTIONARY + +A + + +## Austauschkontrollreferenz + +Dialog-ID der korrespondierenden Nachricht des Kunden (vgl. [HBCI], Kapi- +tel II.6.2). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:id
Länge:#
Version:1
+ + +B + + +## Benutzerdefinierte Signatur + +Bei nicht-schlüsselbasierten Sicherheitsverfahren kann der Benutzer hier +Angaben zur Authentisierung machen. Ob das Feld verpflichtend ist, ist vom +jeweiligen Sicherheitsverfahren abhängig. + +Format: s. Spezifikation „Sicherheitsverfahren PIN/TAN“ + +Typ: +DEG + +Format: + +Länge: + +Version: +1 + + +## Benutzerkennung + +Eindeutig vergebene Kennung, anhand deren die Identifizierung des Benut- +zers erfolgt. Die Vergabe obliegt dem Kreditinstitut. Das Kreditinstitut hat zu +gewährleisten, dass die Benutzerkennung institutsweit eindeutig ist. Sie kann +beliebige Informationen enthalten, darf aber bei Verwendung des RAH- bzw. +RDH-Verfahrens aus Sicherheitsgründen nicht aus benutzer- oder kreditinsti- +tutsspezifischen Merkmalen hergeleitet werden. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:id
Länge:#
Version:1
+ + +## Bereich der Sicherheitsapplikation, kodiert + +Information darüber, welche Daten vom kryptographischen Prozess verarbei- +tet werden. Diese Information wird benötigt um z.B. zwischen relevanter und +belangloser Reihenfolge von Signaturen zu unterscheiden (vgl. [HBCI], Kapi- +tel VI.4). + +Wenn SHM gewählt wird, so bedeutet dies, dass nur über den eigenen Sig- +naturkopf sowie die HBCI-Nutzdaten ein Hashwert gebildet wird, der in die +Signatur eingeht. Dies entspricht bei Mehrfachsignaturen einer bedeutungs- +losen Reihenfolge. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:
160		Stand:
18.07.2013		Kapitel: Data Dictionary
Abschnitt:
Buchstabe B
+ + +Wenn SHT gewählt wird, dann werden auch alle schon vorhandenen Signa- +turköpfe und -abschlüsse mitsigniert. Das heißt, dass die Reihenfolge der +Signaturen relevant ist. + +Codierung: + +1: Signaturkopf und HBCI-Nutzdaten (SHM) + +2: Von Signaturkopf bis Signaturabschluss (SHT) + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:..3
Version:2
+ + +## Bezeichner für Algorithmusparameter, IV + +Eigenschaft betreffend den Initialisierungswert für die Verfahren DDV, RAH +und RDH (Die Steuerung erfolgt in den BPD, vgl. [HBCI], Kapitel IV.4). + +Codierung: + +1: Initialization value, clear text (IVC) + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:..3
Version:2
+ + +## Bezeichner für Algorithmusparameter, Schlüssel + +Eigenschaft des Schlüssels für die Verfahren DDV, RAH und RDH (Die +Steuerung erfolgt in den BPD, vgl. [HBCI], Kapitel IV.4). + + +### Codierung: + +5: Symmetrischer Schlüssel, ver- bzw. entschlüsselt mit einem symmetri- +schen Schlüssel bei DDV (KYE) (vgl. [HBCI], Kapitel VI.2.2.1). + +6: Symmetrischer Schlüssel, verschlüsselt mit einem öffentlichen Schlüssel +bei RAH und RDH (KYP). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:..3
Version:2
+ + +### Bezeichner für Exponent + +Enthält den Bezeichner für den Exponent des öffentlichen Schlüssels. + +Codierung: + +13: Exponent (EXP) + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:..3
Version:2
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionD
Kapitel:Data DictionaryStand:Seite:
Abschnitt:Buchstabe B18.07.2013161
+ + +## Bezeichner für Funktionstyp + +Enthält den Bezeichner für den Funktionstyp des Key-Management. + +Codierung: + +112: 'Certificate Replacement' (Ersatz des Zertifikats) im Zusammenhang +mit der Schlüsseländerung + +124: 'Certificate Status Request' im Zusammenhang mit der Anfrage für ei- +nen öffentlichen Schlüssel + +224: 'Certificate Status Notice' im Zusammenhang mit der Übermittlung ei- +nes öffentlichen Schlüssels + +130 : 'Certificate Revocation' (Zertifikatswiderruf) im Zusammenhang mit der +Schlüsselsperrung + +231: 'Revocation Confirmation' (Bestätigung des Zertifikatswiderrufs) im Zu- +sammenhang mit der Bestätigung der Schlüsselsperrung + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:..3
Version:2
+ + +## Bezeichner für Hashalgorithmusparameter + +Bezeichner für den Hashalgorithmusparameter. + +Codierung: + +1: IVC (Initialization value, clear text) + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:..3
Version:2
+ + +## Bezeichner für Modulus + +Bezeichner für den Modulus des öffentlichen Schlüssels. + +Codierung: + +12: Modulus (MOD) + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:..3
Version:2
+ + +## Bezeichner für Sicherheitspartei + +Identifikation der Funktion der beschriebenen Partei, in diesem Falle des +Kunden. + + +### Codierung: + +1: Message Sender (MS), wenn ein Kunde etwas an sein Kreditinstitut sen- +det. + +2: Message Receiver (MR), wenn das Kreditinstitut etwas an seinen Kunden +sendet. + + + + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:
162		Stand:
18.07.2013		Kapitel: Data Dictionary
Abschnitt:
Buchstabe C
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:..3
Version:2
+ + +#### Bezugssegment + +Sofern sich ein Kreditinstitutssegment auf ein bestimmtes Kundensegment +bezieht (z.B. Antwortrückmeldung auf einen Kundenauftrag) hat das Kredit- +institut die Segmentnummer des Segments der Kundennachricht einzustel- +len, auf das sich das aktuelle Segment bezieht (s. DE „Segmentnummer“). In +Zusammenhang mit den Angaben zur Bezugsnachricht aus dem Nachrich- +tenkopf ist hierdurch eine eindeutige Referenz auf das Segment einer Kun- +dennachricht möglich. + +Falls die Angabe eines Bezugssegments erforderlich ist, ist dieses bei der +Formatbeschreibung eines Kreditinstitutsegments angegeben. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..3
Version:1
+ + +C + + +##### CID + +(Cardholder Identification) Identifikation der verwendeten Chipkarte. Die CID +steht sowohl bei DDV-Chipkarten als auch bei Signaturkarten im EF_ID der +Karte. Im DDV-Verfahren dient die CID dem Kreditinstitut zur Herleitung des +kartenindividuellen Schlüssels. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:bin
Länge:.256
Version:1
+ + +D + + +###### Daten, verschlüsselt + +Enthält die verschlüsselten (und komprimierten) Daten. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:bin
Länge:..
Version:1
+ + +###### Datum + +Datumsangabe, zur Bestimmung eines Zeitpunktes. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dat
Länge:#
Version:1
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionD
Kapitel:Data DictionaryStand:Seite:
Abschnitt:Buchstabe F18.07.2013163
+ + +## Datum- und Zeitbezeichner, kodiert + +Enthält die Bedeutung des Zeitstempels. + +Codierung: + +1: Sicherheitszeitstempel (STS) + +6: Certificate Revocation Time (CRT) + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:..3
Version:2
+ + +F + + +## Filterfunktion + +Falls das Übertragungsverfahren eine Umwandlung der Nachricht in eine +7 Bit-Zeichendarstellung erfordert (z.B. Internet), so ist hier das anzuwen- +dende Filterverfahren anzugeben. Die Nachricht ist stets komplett zu filtern, +auch wenn eine Filterung nicht notwendig wäre, da bspw. keine binären Da- +ten enthalten sind. Ein Kreditinstitut darf jeweils nur eine Filterfunktion unter- +stützen. + +Codierung: + +MIM: MIME Base 64 + +UUE: Uuencode/Uudecode + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:3
Version:1
+ + +H + + +## Hashalgorithmus + +Angaben zu einem kryptographischen Algorithmus, seinen Operations- +modus, sowie dessen Einsatz. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Verwendung des Hashalgorithmus, kodiertDEcode.3M11
2Hashalgorithmus, kodiertDEcode..3M11, 3, 4, 5, 6, 999
3Bezeichner für Hash- algorithmusparame- terDEcode..3M11
4Wert des Hashalgo- rithmusparametersDEbin..512O1
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:
164		Stand:
18.07.2013		Kapitel: Data Dictionary
Abschnitt:
Buchstabe I
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:2
+ + +## Hashalgorithmus, kodiert + +Code des verwendeten Hash-Algorithmus. + +Codierung: + +1: SHA-1 + +2: belegt + +3: SHA-256 + +4: SHA-384 + +5: SHA-512 + +6: SHA-256 / SHA-256 + +999: Gegenseitig vereinbart (ZZZ); hier: RIPEMD-160 + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:..3
Version:2
+ + +![](figures/178.1) + + +Wird als ,,Hashalgorithmus, kodiert“ die Option „6: SHA-256 / +SHA256“ gewählt, so findet ein Hashing sowohl in Software +als auch in der Bankensignaturkarte statt. + +Die Anwendung muss dafür Sorge tragen, dass in der Karte +das gewünschte Hashverfahren - hier SHA-256 - selektiert +wird; ansonsten würde in dort das Default-Hashverfahren +angewendet, was nicht zulässig ist. + +I + + +# Identifizierung der Partei + +Code, welcher die (Kommunikations-)Partei identifiziert. Bei Verwendung des +RDH-Verfahrens ist die Kundensystem-ID einzustellen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:id
Länge:#
Version:1
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionD
Kapitel:Data DictionaryStand:Seite:
Abschnitt:Buchstabe K18.07.2013165
+ + +# K + + +## Kommunikationsadresse + +Beim Zugang über TCP/IP ist die IP-Adresse als alphanumerischer Wert +(z.B. '123.123.123.123') einzustellen. + +Beim Zugang über https ist die Adresse des Servlets als alphanumerischer +Wert (z.B. [,,https://www.xyz.de:7000/Servlet"](https://www.xyz.de:7000/Servlet)) einzustellen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:.512
Version:1
+ + +### Kommunikationsadressenzusatz + +Beim Zugang über TCP/IP und https wird das Feld nicht belegt. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..512
Version:1
+ + +### Kommunikationsdienst + +Unterstütztes Kommunikationsverfahren (Protokollstack). + +Zur Zeit unterstützte Kommunikationsverfahren: + +1: nicht belegt + +2: TCP/IP (Protokollstack SLIP/PPP) + +3: https + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:..2
Version:3
+ + +### Kommunikationsparameter + +Die Kommunikationsparameter enthalten Informationen für den Aufbau der +Transportverbindung. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameTypFor- matLän- geSta- tusAn- zahlRestriktionen
1KommunikationsdienstDEnum..2M11,2,3
2Kommunikationsadres- seDEan..512M1
3Kommunikationsadres- senzusatzDEan..512C1M: ,Kommunikations- dienst' = 1 N: sonst
4FilterfunktionDEan3C1MIM, UUE M: ,Kommunikations- dienst' = 2 N: sonst
5Version der Filterfunk- tionDEnum..3C1O: ,Filterfunktion' belegt N: sonst
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:
166		Stand:
18.07.2013		Kapitel: Data Dictionary
Abschnitt:
Buchstabe K
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:2
+ + +## Komprimierungsfunktion + +Code der unterstützten Komprimierungsfunktion. + +Codierung: + +0: Keine Kompression (NULL) + +1: Lempel, Ziv, Welch (LZW) + +2: Optimized LZW (COM) + +3: Lempel, Ziv (LZSS) + +4: LZ + Huffman Coding (LZHuf) + +5: PKZIP (ZIP) + +6: deflate (GZIP) [(http://www.gzip.org/zlib)](http://www.gzip.org/zlib) + +7: bzip2 [(http://sourceware.cygnus.com/bzip2/)](http://sourceware.cygnus.com/bzip2/) + +999: Gegenseitig vereinbart (ZZZ) + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:..3
Version:2
+ + +## Komprimierungsversion + +Version der unterstützten Komprimierungsfunktion. + +Momentan werden alle zulässigen Komprimierungsfunktionen mit Version 1 +verwendet. Falls keine Komprimierung verwendet wird (Komprimierungs- +funktion 0), wird Version 0 angegeben. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..3
Version:1
+ + +## Kreditinstitutscode + +Landesspezifische Kennung, die das Kreditinstitut eindeutig identifiziert. In +Deutschland wird die Bankleitzahl eingestellt. Bei Kreditinstituten, die in Län- +dern ohne Institutskennungssystem beheimatet sind, kann die Belegung ent- +fallen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..30
Version:1
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionD
Kapitel:Data DictionaryStand:Seite:
Abschnitt:Buchstabe L18.07.2013167
+ + +# Kreditinstitutskennung + +Kennung eines Kreditinstituts. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Formatkennungkik
Länge:#
Version:1
+ + +## Kunden-ID + +Institutsweit eindeutige Identifikation des Kunden. Die Vergabe obliegt dem +Kreditinstitut. Die Kunden-ID kann beliebige Informationen enthalten. Es +steht dem Kreditinstitut frei, ob es jedem Kunden genau eine Kunden-ID zu- +ordnet oder dem Kunden in Abhängigkeit vom Benutzer jeweils eine unter- +schiedliche Kunden-ID zuordnet. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:id
Länge:#
Version:1
+ + +L + + +## Länderkennzeichen + +Länderkennzeichen gemäß ISO 3166-1 (numerischer Code) (s. [Formals], +Kap. „Anlagen“). Für Deutschland wird der Code 280 verwendet da dieser im +Kreditgewerbe gebräuchlicher als der neue Code 276 ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:ctr
Länge:#
Version:1
+ + +N + + +## Nachrichtenbeziehung, kodiert + +Code der Nachrichtenbeziehung. Im Zusammenhang mit der Übermittlung +eines öffentlichen Schlüssels oder mit der Bestätigung der Schlüssel- +sperrung ist der Wert ,1" vorgesehen. Im Zusammenhang mit der Schlüssel- +änderung, mit der Anfrage nach einem öffentlichen Schlüssel oder mit der +Schlüsselsperrung ist der Wert „2“ vorgesehen. + + +### Codierung: + +1: Key-Management-Nachricht ist Antwort + +2: Key-Management-Nachricht erwartet Antwort + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:2
+ + + + + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:
168		Stand:
18.07.2013		Kapitel: Data Dictionary
Abschnitt:
Buchstabe O
+ + +## Nachrichtenreferenznummer + +Nachrichtennummer der korrespondierenden Nachricht des Kunden. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..4
Version:1
+ + +O + + +## Öffentlicher Schlüssel + +Information, die beim RAH-/RDH-Key-Management zum Transport des öf- +fentlichen Schlüssels zwischen Kunde und Kreditinstitut bzw. umgekehrt +dient. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Verwendungszweck für öffentlichen SchlüsselDEcode..3M15,6
2Operationsmodus, kodiertDEcode..3M12, 16, 17, 18, 19
3Verfahren BenutzerDEcode..3M110
4Wert für ModulusDEbin.512M1
5Bezeichner für Modu- lusDEcode..3M112
6Wert für ExponentDEbin.512M165537
7Bezeichner für Expo- nentDEcode..3M113
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:2
+ + +## Operationsmodus, kodiert + +Information über den Operationsmodus für den jeweils verwendeten Kryp- +toalgorithmus (zur Signaturbildung oder zur Verschlüsselung). + +Codierung: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeOperationsmodusVerwendung
2:Cipher Block Chaining (CBC)Nur für Verschlüsselung erlaubt (vgl. [HBCI], Kapitel VI.2.2)
16:ISO 9796-1 (bei RDH),Nur für Signatur erlaubt
17:ISO 9796-2 mit Zufallszahl (bei RDH)Nur für Signatur erlaubt
18:RSASSA-PKCS#1 V1.5 (bei RDH) bzw. RSAES-PKCS#1 V1.5 (bei RAH, RDH)Nur für Signatur erlaubt
Nur für Verschlüsselung erlaubt
19:RSASSA-PSS (bei RAH, RDH)Nur für Signatur erlaubt
999:Gegenseitig vereinbart (ZZZ); bei DDV bedeutet dies die Bildung eines Retail- MAC für die Berechnung der SignaturNur für Signatur erlaubt (vgl. [HBCI], Kap. VI.2.1)
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionD
Kapitel:Data DictionaryStand:Seite:
Abschnitt:Buchstabe R18.07.2013169
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:..3
Version:2
+ + +R + + +# Rolle des Sicherheitslieferanten, kodiert + +Kodierte Information über das Verhältnis desjenigen, der bezüglich der zu si- +chernden Nachricht die Sicherheit gewährleistet. + +Die Wahl ist von der bankfachlichen Auslegung der Signatur, respektive vom +vertraglichen Zustand zwischen Kunde und Kreditinstitut abhängig. + +Codierung: + +1: Der Unterzeichner ist Herausgeber der signierten Nachricht, z.B. Erfasser +oder Erstsignatur (ISS) + +3: Der Unterzeichner unterstützt den Inhalt der Nachricht, z.B. bei Zweitsig- +natur (CON) + +4: Der Unterzeichner ist Zeuge, aber für den Inhalt der Nachricht nicht ver- +antwortlich, z.B. Übermittler, welcher nicht Erfasser ist (WIT) + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:..3
Version:2
+ + +S + + +## Schlüsselart + +Information über die Art des Schlüssels. + +Bei den Sicherheitsverfahren RAH und RDH steht die Schlüsselart in engem +Zusammenhang mit dem Datenelement "Verwendungszweck für öffentlichen +Schlüssel". Die Inhalte beider Datenelemente sind konsistent zu halten. + +Codierung: + +D: Schlüssel zur Erzeugung digitaler Signaturen (DS-Schlüssel) + +S: Signierschlüssel + +V: Chiffrierschlüssel + +Der DS-Schlüssel steht nur im Zusammenhang mit einer Bankensignatur- +karte zur Verfügung. + +Im Falle der Bankensignaturkarte ergibt sich folgende Zuordnung zu den +Kartenschlüsseln: + +\- DS-Schlüssel: +SK.CH.DS + +\- Signierschlüssel: SK.CH.AUT + +\- Chiffrierschlüssel: SK.CH.KE + + + + + + + + + + + + + + + + + + + + + + + + + +
Kapitel:Version:Financial Transaction Services (FinTS)
D3.0 - Final VersionDokument: Security - Sicherheitsverfahren HBCI
Seite:Stand:Kapitel: Data Dictionary
17018.07.2013Abschnitt: Buchstabe S
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:2
+ + +# Schlüsselname + +Verwendeter Schlüsselnamen beim RAH- und RDH-Verfahren respektive die +Referenz auf den Chiffrierschlüssel beim DDV-Verfahren in strukturierter +Form. Mit dieser Information kann die Referenz auf einen Schlüssel herge- +stellt werden. + +Dabei enthält das DE „Benutzerkennung“ bei Schlüsseln des Kunden die +Benutzerkennung, mit der der Kunde eindeutig identifiziert wird. Bei Schlüs- +seln des Kreditinstituts ist dagegen eine beliebige Kennung einzustellen, die +dazu dient, den Kreditinstitutsschlüssel eindeutig zu identifizieren. Diese +Kennung darf weder einer anderen gültigen Benutzerkennung des Kreditin- +stituts noch der Benutzerkennung für den anonymen Zugang entsprechen. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Kreditinstitutsken- nungDEGkik#M1
2BenutzerkennungDEid#M1
3SchlüsselartDEcode1M1D, S, V
4SchlüsselnummerDEnum..3M1
5SchlüsselversionDEnum..3M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:3
+ + +## Schlüsselnummer + +Schlüsselnummer des entsprechenden Schlüssels. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..3
Version:1
+ + +## Schlüsselversion + +Versionsnummer des entsprechenden Schlüssels. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..3
Version:1
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionD
Kapitel:Data DictionaryStand:Seite:
Abschnitt:Buchstabe S18.07.2013171
+ + +# Segmentkennung + +Segmentspezifische Kennung, die jedem Segment bzw. Auftrag zugeordnet +ist (z.B. "HKUEB" für "Einzelüberweisung"). Die Angabe hat in Großschrei- +bung zu erfolgen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..6
Version:1
+ + +![](figures/185.1) + + +Falls der Kunde ein Segment mit einer veralteten Versions- +nummer einreicht, sollte ihm in einer entsprechenden War- +nung rückgemeldet werden, dass sein Kundenprodukt aktua- +lisiert werden sollte. + + +# Segmentkopf + +Informationen, die jedem Segment als Kopfteil vorangestellt sind. Im Unter- +schied zu Nachrichten enthalten Segmente jedoch keinen Abschlussteil, da +das Segmentende durch das Segmentende-Zeichen markiert ist. + +Im Segmentkopf stehen die Segmentkennung und Segmentversion unab- +hängig von der HBCI-Version (s. DE HBCI-Version) immer an derselben +Stelle, damit ein Segment auch in späteren HBCI-Versionen immer eindeutig +als solches identifiziert werden kann. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameTypFor- matLän- geSta- tusAn- zahlRestriktionen
1SegmentkennungDEan..6M1
2SegmentnummerDEnum..3M1>=1
3SegmentversionDEnum..3M1
4BezugssegmentDEnum..3C1>=1
O: Verwendung in Kre- ditinstitutsnachricht N: Verwendung in Kun- dennachricht
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +# Segmentnummer + +Information zur eindeutigen Identifizierung eines Segments innerhalb einer +Nachricht. Die Segmente einer Nachricht werden in Einerschritten streng +monoton aufsteigend nummeriert. Die Nummerierung beginnt mit 1 im ersten +Segment der Nachricht (Nachrichtenkopf). + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:
172		Stand:
18.07.2013		Kapitel: Data Dictionary
Abschnitt:
Buchstabe S
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..3
Version:1
+ + +# Segmentversion + +Versionsnummer zur Dokumentation von Änderungen eines Segmentfor- +mats. + +Die Segmentversion von administrativen Segmenten (die Segmentart 'Admi- +nistration' bzw. 'Geschäftsvorfall' ist bei jeder Segmentbeschreibung ange- +geben) wird bei jeder Änderung des Segmentformats inkrementiert. + +Bei Geschäftsvorfallssegmenten wird die Segmentversion auf logischer Ebe- +ne verwaltet, d.h. sie ist für das Auftrags-, das Antwort- und das Parame- +tersegment des Geschäftsvorfalls stets identisch und wird inkrementiert, +wenn sich das Format von mindestens einem der drei Segmente ändert. + +Dieses Verfahren gilt bei Standardsegmenten einheitlich für alle Kreditinsti- +tute. Bei verbandsindividuellen Segmenten obliegt die Versionssteuerung +dem jeweiligen Verband. Der Zeitpunkt der Unterstützung einer neuen Seg- +mentversion kann jedoch zwischen den Verbänden variieren. + +Die für die jeweilige HBCI-Version gültige Segmentversion ist bei der jeweili- +gen Segmentbeschreibung vermerkt. + +Falls der Kunde ein Segment mit einer veralteten Versionsnummer einreicht, +sollte ihm in einer entsprechenden Warnung rückgemeldet werden, dass +sein Kundenprodukt aktualisiert werden sollte. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..3
Version:1
+ + +# Sicherheitsdatum und -uhrzeit + +Zeitstempel, beispielsweise Datum und Uhrzeit des lokalen Rechners, an +dem die elektronische Unterschrift geleistet wurde, sowie die Bedeutung des +Zeitstempels. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Datum- und Zeitbe- zeichner, kodiertDEcode..3M11,6
2DatumDEdat#O1
3UhrzeitDEtim#C1O: ,Datum' belegt N: sonst
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:2
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionD
Kapitel:Data DictionaryStand:Seite:
Abschnitt:Buchstabe S18.07.2013173
+ + +## Sicherheitsfunktion, kodiert + +Bis HBCI 2.2 war die Sicherheitsfunktion die Unterscheidung zwischen DDV +und RDH, wobei die 1 nur das RDH-Verfahren kennzeichnete und 2 das +DDV-Verfahren. Ab FinTS 3.0 existieren beim RDH-Verfahren drei Schlüssel +(DS-Schlüssel für Non-Repudiation, Signierschlüssel für Authentication und +Chiffrierschlüssel für Verschlüsselung) und somit auch drei Sicherheitsfunk- +tionen (Sicherheitsfunktion 1 bei Verwendung des DS-Schlüssels, Sicher- +heitsfunktion 2 bei Verwendung des Signierschlüssel und Sicherheitsfunktion +4 bei Verwendung des Chiffrierschlüssels) beim RAH- und RDH-Verfahren. + +Die Sicherheitsfunktion hat ab FinTS 3.0 lediglich informatorischen Wert, da +die eigentliche Steuerung über die Sicherheitsprofile und -Klassen erfolgt. + +Kodierte Information über die Sicherheitsfunktion, die auf die Nachricht an- +gewendet wird. + +Codierung: + +1: Non-Repudiation of Origin, für RAH, RDH (NRO) + +2: Message Origin Authentication, für RAH, RDH und DDV (AUT) + +4: Encryption, Verschlüsselung und evtl. Komprimierung (ENC) + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:..3
Version:2
+ + +## Sicherheitsidentifikation, Details + +Identifikation der im Sicherheitsprozess involvierten Parteien. Dient zur +Übermittlung der CID bei kartenbasierten Sicherheitsverfahren bzw. der +Kundensystem-ID bei softwarebasierten Verfahren (z.B. Speicherung der +Schlüssel in einer Schlüsseldatei). + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Bezeichner für Si- cherheitsparteiDEcode..3M11, 2
2CIDDEbin.256C1M: Sicherheitsmedium = Chipkarte N: sonst
3Identifizierung der ParteiDEid#C1M: Sicherheitsmedium = Software N: sonst
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:2
+ + +### Sicherheitskontrollreferenz + +Referenzinformation, mit der die Verbindung zwischen Signaturkopf und da- +zu gehörigem Signaturabschluss hergestellt werden kann. Die Sicherheits- +kontrollreferenz im Signaturkopf muss mit der entsprechenden Information +im Signaturabschluss übereinstimmen. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:
174		Stand:
18.07.2013		Kapitel: Data Dictionary
Abschnitt:
Buchstabe S
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:. . 14
Version:1
+ + +#### Sicherheitsprofil + +Verfahren zur Absicherung der Transaktionen, das zwischen Kunde und +Kreditinstitut vereinbar wurde. Das Sicherheitsprofil wird anhand der Kombi- +nation der beiden Elemente ,,Sicherheitsverfahren“ und ,,Version" bestimmt +(z._B. RDH-3, DDV-1). Für das Sicherheitsverfahren PINTAN ist als Code der +Wert PIN und als Version der Wert 1 einzustellen. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Sicherheitsverfahren, CodeDEcode3M1DDV, RAH, RDH, PIN
2Version des Sicher- heitsverfahrensDEnum..3M11, 2, 3, 4, 5, 6, 7, 8, 9, 10
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +#### Sicherheitsreferenznummer + +Sicherheitsrelevante Nachrichtenidentifikation (Signatur-ID), welche zur Ver- +hinderung der Doppeleinreichung, respektive Garantie der Nachrichtense- +quenzintegrität eingesetzt werden kann. + +Bei chipkartenbasierten Verfahren ist der Sequenzzähler der Chipkarte ein- +zustellen. Dies ist bei Typ-1 Karten der Wert ,,EF_SEQ" in der Application +DF_BANKING und bei SECCOS Bankensignaturkarten der Wert „usage +counter“ der beiden Signierschlüssel SK.CH.DS und SK.CH.AUT. + +Bei softwarebasierten Verfahren wird die Sicherheitsreferenznummer auf +Basis des DE Kundensystem-ID und des DE Benutzerkennung der DEG +Schlüsselnamen verwaltet. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:.. 16
Version:1
+ + +##### Sicherheitsverfahren, Code + +Code des unterstützten Signatur- bzw. Verschlüsselungsalgorithmus. + +Weitere Informationen zu den Verfahren sind Kapitel B.1 zu entnehmen. + +Codierung: + +DDV: DES-DES-Verfahren + +RAH: RSA-AES-Hybridverfahren + +RDH: RSA-DES-Hybridverfahren + +PIN: PIN/TAN-Verfahren + +EMV: EMV-AC-Variante (S-Fkt=820, 821) bei AZS-Verfahren + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionD
Kapitel:Data DictionaryStand:Seite:
Abschnitt:Buchstabe U18.07.2013175
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:3
Version:3
+ + +###### Signaturalgorithmus + +Angaben zum kryptographischen Algorithmus, zu seinem Operationsmodus, +so wie zu dessen Einsatz, in diesem Fall für die Signaturbildung über DDV +bzw. RAH / RDH. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Verwendung des Signaturalgorithmus, kodiertDEcode..3M16
2Signaturalgorithmus, kodiertDEcode..3M11,10
3Operationsmodus, kodiertDEcode..3M116, 17, 18, 19, 999
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:2
+ + +####### Signaturalgorithmus, kodiert + +Kodierte Information über den Signaturalgorithmus. + +Codierung: + +1: DES-Algorithmus (bei DDV) + +10: RSA-Algorithmus (bei RAH und RDH) + +Typ: + +DE + +Format: + +code + +Länge: + +..3 + +Version: + +2 + + +####### Sperrenkennzeichen + +Information zur Begründung der Sperrung. + +Codierung: + +1: +Schlüssel des Zertifikatseigentümers kompromittiert + +501: Zertifikat ungültig wegen Verdacht auf Kompromittierung + +999: gesperrt aus sonstigen Gründen + + + + + + + + + + + + + + + + + + + + + + + + + +
Kapitel:Version:Financial Transaction Services (FinTS)
D3.0 - Final VersionDokument: Security - Sicherheitsverfahren HBCI
Seite:Stand:Kapitel: Data Dictionary
17618.07.2013Abschnitt:
Buchstabe U
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:..3
Version:2
+ + +U + + +######## Uhrzeit + +Uhrzeit eines Ereignisses (meist zusammen mit „Datum“ verwendet). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:tim
Länge:#
Version:1
+ + +V + + +######### Validierungsresultat + +Elektronische Signatur, die zur Validierung berechnet wurde. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:bin
Länge:..512
Version:1
+ + +######### Verfahren Benutzer + +Information über das Benutzer-Verfahren, die beim öffentlichen Schlüssel +angegeben wird. + +Es ist nur der folgende Wert zugelassen: + +10: RSA-Verfahren + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:..3
Version:2
+ + +######### Verschlüsselungsalgorithmus + +Angaben zum kryptographischen Algorithmus, zu seinem Operationsmodus, +so wie zu dessen Einsatz, in diesem Fall für die Nachrichtenverschlüsselung. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionD
Kapitel:Data DictionaryStand:Seite:
Abschnitt:Buchstabe V18.07.2013177
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Verwendung des Verschlüsselungs- algorithmus, kodiertDEcode..3M12
2Operationsmodus, kodiertDEcode..3M12, 16, 17, 18, 19
3Verschlüsselungs- algorithmus, kodiertDEcode..3M113
4Wert des Algorith- musparameters, SchlüsselDEbin..512M1
5Bezeichner für Algo- rithmusparameter, SchlüsselDEcode..3M15,6
6Bezeichner für Algo- rithmusparameter, IVDEcode..3M11
7Wert des Algorith- musparameters, IVDEbin..512O1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:2
+ + +######## Verschlüsselungsalgorithmus, kodiert + +Kodierte Information über den verwendeten Verschlüsselungsalgorithmus. + +Codierung: + +13: 2-Key-Triple-DES + +14: AES-256 [AES] + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:..3
Version:3
+ + +######### Version der Filterfunktion + +Version der Filterfunktion. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..3
Version:1
+ + +######### Version des Sicherheitsverfahrens + +Version des unterstützten Sicherheitsverfahrens (s. „Sicherheitsverfahren, +Code“). + +In Kombination mit dem Sicherheitsverfahren RAH sind die folgenden Versi- +onen gültig: + + + + + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:Stand:
18.07.2013		Kapitel: Data Dictionary
178Abschnitt:
Buchstabe V
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Ver- sionSignatur- verfahrenSchlüssellänge
(bit)		HashverfahrenSchlüsselart*
7PKCS#1 PSSgemäß [DK Krypto]SHA-256D, S, V
9PKCS#1 PSSgemäß [DK Krypto]SHA-256S, V
10PKCS#1 PSSgemäß [DK Krypto]SHA-256S, V
+ + +In Kombination mit dem Sicherheitsverfahren RDH sind die folgenden Versi- +onen gültig: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Ver- sionSignatur- verfahrenSchlüssellänge (bit)HashverfahrenSchlüsselart*
1ISO 9796-1708-768RIPEMD-160S, V
2DIN, ISO 9796-21024-2048RIPEMD-160S, V
3DIN, ISO 9796-2 PKCS#1 V1.51024-2048RIPEMD-160 SHA-1D, S, V
4PKCS#1 V1.51024-2048SHA-1D, S, V
5PKCS#1 V1.51024-2048SHA-1S,V
6PKCS#1 V1.5gemäß [DK Krypto]SHA-256D, S, V
7PKCS#1 PSSgemäß [DK Krypto]SHA-256D, S, V
8PKCS#1 V1.5gemäß [DK Krypto]SHA-256S, V
9PKCS#1 PSSgemäß [DK Krypto]SHA-256S, V
10PKCS#1 PSSgemäß [DK Krypto]SHA-256S, V
+ + +In Kombination mit dem Sicherheitsverfahren DDV sind die folgenden Versi- +onen gültig: + + + + + + + + + + + + + + + + + + + + + + + + +
Ver- sionSignatur- verfahrenSchlüssellänge (bit)HashverfahrenSchlüsselart*
1MAC128RIPEMD-160S, V
2MAC128SHA-256S, V
+ + +\* s. Element „Schlüsselart“ + +Andere als die genannten Profile sind nicht zulässig. + + +![](figures/192.1) + + +Um Multibankfähigkeit zu gewährleisten, ist die Unterstüt- +zung eines der Verfahren RAH-9 bzw. übergangsweise +RDH-9 kunden- und kreditinstitutsseitig verpflichtend. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..3
Version:2
+ + +###### Verwendung des Hashalgorithmus, kodiert + +Kodierte Information über die Verwendung des Hashalgorithmus. + +Im Zusammenhang mit Hash-Funktionen ist derzeit nur folgender Wert mög- +lich: + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionD
Kapitel:Data DictionaryStand:Seite:
Abschnitt:Buchstabe V18.07.2013179
+ + +###### Codierung: + +1: Owner Hashing (OHA) + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:..3
Version:2
+ + +####### Verwendung des Signaturalgorithmus, kodiert + +Kodierte Information über die Verwendung des Signaturalgorithmus. + +Im Zusammenhang mit Signaturbildung ist derzeit nur folgender Wert mög- +lich: + +Codierung: + +6: Owner Signing (OSG) + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:..3
Version:2
+ + +####### Verwendung des Verschlüsselungsalgorithmus, kodiert + +Kodierte Information über die Verwendung des Verschlüsselungs- +algorithmus. + +Im Zusammenhang mit der Verschlüsselung sind derzeit folgende Werte +möglich: + +Codierung: + +2: Owner Symmetric (OSY) + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:..3
Version:2
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:
180		Stand:
18.07.2013		Kapitel: Data Dictionary
Abschnitt: Buchstabe W
+ + +# Verwendungszweck für öffentlichen Schlüssel + +Kodierte Information über die Verwendung des öffentlichen Schlüssels. Die- +se Information muss konsistent zur Schlüsselart gehalten werden. + +Codierung: + +5: Owner Ciphering (Chiffrierschlüssel) + +6: Owner Signing (Signierschlüssel) + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:..3
Version:2
+ + +W + + +# Wert des Algorithmusparameters, IV + +Initialisierungswert für den kryptographischen Algorithmusparameter. Zur +Zeit ist die Angabe eines Wertes nicht zulässig; es wird dafür folgender Initia- +lisierungswert als Default verwendet: X'00 00 00 00 00 00 00 00' + +In einer zukünftigen Version kann ein abweichender Initialisierungswert defi- +niert werden. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:bin
Länge:..512
Version:1
+ + +# Wert des Algorithmusparameters, Schlüssel + +Verschlüsselter Nachrichtenschlüssel für den kryptographischen Algorith- +musparameter. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:bin
Länge:..512
Version:1
+ + +# Wert des Hashalgorithmusparameters + +Initialisierungswert für den Hashalgorithmusparameter. Zur Zeit ist die Anga- +be eines Wertes nicht zulässig; es wird für RIPEMD-160 folgender Initialisie- +rungswert als Default verwendet: + +X'01 23 45 67 89 AB CD EF FE DC BA 98 76 54 32 10 F0 E1 D2 C3' (Little- +Endian-Notation) + +In einer zukünftigen Version kann ein abweichender Initialisierungswert defi- +niert werden. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:bin
Länge:..512
Version:1
+ + +# Wert für Exponent + +Exponent des öffentlichen Schlüssels (z.Zt. 65537). Die Kürzung um führen- +de 0-Bytes ist empfehlenswert, aber nicht verbindlich. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionD
Kapitel:Data DictionaryStand:Seite:
Abschnitt:Buchstabe Z18.07.2013181
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:bin
Länge:..512
Version:1
+ + +## Wert für Modulus + +Modulus des öffentlichen Schlüssels. Die Kürzung um führende 0-Bytes ist +empfehlenswert, aber nicht verbindlich. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:bin
Länge:..512
Version:1
+ + +Z + + +## Zertifikat + +Zertifikat eines öffentlichen Schlüssels. + +Da Zertifikate Informationen beinhalten, die auch in den HBCI-Formaten ent- +halten sind (z.B. Zertifikatsreferenz respektive Schlüsselnamen), können Da- +ten redundant vorkommen. Diese müssen dann auf Konsistenz überprüft +werden. Bei Unstimmigkeiten hat das Zertifikat Vorrang. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameTypFor- matLän- geSta- tusAn- zahlRestriktionen
1ZertifikatstypDEcode1M11, 2, 3
2ZertifikatsinhaltDEbin٠٠
4096		M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:2
+ + +### Zertifikatsinhalt + +Transparenter Inhalt eines Zertifikats. + +Bei der Bankensignaturkarte handelt es sich hier um + +\- das Signaturzertifikat C_X509.CH.DS, + +\- das CSA-(KE-)Zertifikat C_X509.CH.AUTC/S[&KE] + +\- und das KE-Zertifikat C_X509.CH.KE + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:bin
Länge:..4096
Version:1
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0 - Final VersionFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren HBCI
Seite:
182		Stand: 18.07.2013Kapitel: Data Dictionary
Abschnitt:
Buchstabe Z
+ + +## Zertifikatstyp + +Information über Aufbau und Inhalt eines Zertifikats. + +Codierung: + +1: ZKA + +2: UN/EDIFACT + +3: X.509 v3 (gemäß [ISIS/MTT]) + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:2
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren HBCI3.0 - Final VersionE
Kapitel:AnlagenStand:Seite:
Abschnitt:Übersicht der Segmente18.07.2013183
+ + +### E. ANLAGEN + + +#### E.1 Übersicht der Segmente + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.SegmentnameKennungSen- der1Version
1Anforderung eines öffentlichen SchlüsselsHKISAK3
2Bestätigung der SchlüsselsperrungHISSPI3
3SchlüsseländerungHKSAKK3
4SchlüsselsperrungHKSSPK3
5SignaturkopfHNSHKK/I4
6Übermittlung eines öffentlichen SchlüsselsHIISAI3
7Verschlüsselte DatenHNVSDK/I1
8VerschlüsselungskopfHNVSKK/I3
+ + + diff --git a/docs/fints-def/FinTS_3.0_Security_Sicherheitsverfahren_HBCI_Rel_20130718_final_version.pdf b/docs/fints-def/FinTS_3.0_Security_Sicherheitsverfahren_HBCI_Rel_20130718_final_version.pdf new file mode 100644 index 0000000..f730ed1 Binary files /dev/null and b/docs/fints-def/FinTS_3.0_Security_Sicherheitsverfahren_HBCI_Rel_20130718_final_version.pdf differ diff --git a/docs/fints-def/FinTS_3.0_Security_Sicherheitsverfahren_PINTAN_2018-02-23_final_version.md b/docs/fints-def/FinTS_3.0_Security_Sicherheitsverfahren_PINTAN_2018-02-23_final_version.md new file mode 100644 index 0000000..d275c20 --- /dev/null +++ b/docs/fints-def/FinTS_3.0_Security_Sicherheitsverfahren_PINTAN_2018-02-23_final_version.md @@ -0,0 +1,29164 @@ + + + + +# FinTS Financial Transaction Services + +Schnittstellenspezifikation + +Sicherheitsverfahren PIN/TAN + +Herausgeber: + +Bundesverband deutscher Banken e.V., Berlin + +Deutscher Sparkassen- und Giroverband e.V., Bonn/Berlin + +Bundesverband der Deutschen Volksbanken und Raiffeisenbanken e.V., Berlin + +Bundesverband Öffentlicher Banken Deutschlands e.V., Berlin + + + + + + + + +Die vorliegende Schnittstellenspezifikation für eine automatisiert nutzbare multibankfähige +Banking-Schnittstelle (im Folgenden: Schnittstellenspezifikation) wurde im Auftrag der Deut- +schen Kreditwirtschaft entwickelt. Sie wird hiermit zur Implementation in Kunden- und Kredit- +institutssysteme freigegeben. + +Die Schnittstellenspezifikation ist urheberrechtlich geschützt. Zur Implementation in Kunden- +und Kreditinstitutssysteme wird interessierten Herstellern unentgeltlich ein einfaches Nut- +zungsrecht eingeräumt. Im Rahmen des genannten Zwecks darf die Schnittstellenspezifika- +tion auch - in unveränderter Form - vervielfältigt und zu den nachstehenden Bedingungen +verbreitet werden. + +Umgestaltungen, Bearbeitungen, Übersetzungen und jegliche Änderung der Schnittstellen- +spezifikation sind untersagt. Kennzeichnungen, Copyright-Vermerke und Eigentumsangaben +dürfen in keinem Fall geändert werden. + +Im Hinblick auf die Unentgeltlichkeit des eingeräumten Nutzungsrechts wird keinerlei Ge- +währleistung oder Haftung für Fehler der Schnittstellenspezifikation oder die ordnungsge- +mäße Funktion der auf ihr beruhenden Produkte übernommen. Die Hersteller sind aufgefor- +dert, Fehler oder Auslegungsspielräume der Spezifikation, die die ordnungsgemäße Funkti- +on oder Multibankfähigkeit von Kundenprodukten behindern, der Deutschen Kreditwirtschaft +zu melden. Es wird weiterhin ausdrücklich darauf hingewiesen, dass Änderungen der +Schnittstellenspezifikation durch Die Deutsche Kreditwirtschaft jederzeit und ohne vorherige +Ankündigung möglich sind. + +Eine Weitergabe der Schnittstellenspezifikation durch den Hersteller an Dritte darf nur un- +entgeltlich, in unveränderter Form und zu den vorstehenden Bedingungen erfolgen. + +Dieses Dokument kann im Internet abgerufen werden unter https://www.fints.org. + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: A
Dokument:Security - Sicherheitsverfahren PIN/TAN
Kapitel:EinleitungStand: 23.02.2018Seite: 5
+ + +## Versionsführung + +Das vorliegende Dokument wurde von folgenden Personen erstellt bzw. geändert: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
NameOrgani- sationDatumVersionDokumenteAnmerkungen
SIZ22.06.20043.0 Final VersionFinTS_3.0_PINTAN.doc
Haubnerfür SIZ27.10.20103.0 Final VersionFinTS_3.0_PINTAN_20 10-10-27_FV.docx
Haubnerfür SIZ06.10.20173.0 Final VersionFinTS_3.0_PINTAN_20 17-10- 06_final_version.docx
Haubnerfür SIZ23.02.20183.0 Final VersionFinTS_3.0_PINTAN_20 18-02- 23_final_version.docx
+ + +Grau dargestellte Spezifikationsteile sind aus Sicht der Spezifikation obsolet, kön- +nen aber aus Migrationsgründen noch verwendet werden. Die Entscheidung hier- +über ist institutsspezifisch. + + +## Änderungen gegenüber der Vorversion + +Änderungen zur Vorversion sind im Dokument durch einen Randbalken markiert. +Falls sich die Kapitelnummerierung geändert hat, bezieht sich die Kapitelangabe auf +die neue Nummerierung. + + +### Releasedatum 27.10.2010 + + + + + + + + + + + + + + + + + + + + + + + + + + + +
lfd. Nr.KapitelKapitel- nummerKen- nung 1Art2Beschreibung
1GV HKTANB.4ESegmentversionen #3 und #5
2Management chip- TAN und mobi- leTANC.3EErweiterungen im Management von chipTAN und mobileTAN
+ + +### Releasedatum 11.05.2017 + + + + + + + + + + + +
lfd. Nr.KapitelKapitel- nummerKen- nungArtBeschreibung
+ + + + + + + + + + + + + + + + + + +
Kapitel:Version: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite: 6Stand: 23.02.2018Kapitel: Einleitung
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
lfd. Nr.KapitelKapitel- nummerKen- nungArtBeschreibung
1Management TAN- MedienC.30475EErweiterungen bei den folgenden GVs für bilateral vereinbarte Sicherheitsver- fahren im Element ,,TAN-Medium- Klasse“:
- HKTAB #5
- HKTAU #3
- HKMTR #3
- HKMTF #3
- HKMTA #3
- HKTML #2
2Starke Authentifi- zierungB.3.30480EAbläufe zur starken Authentifizierung während der Dialoginitialisierung
3Geschäftsvorfall HKTAN#6B.4.10480ENeue HKTAN-Segmentversion #6 zur Unterstützung der starken Kun- denauthentifizierung während der Dialo- ginitialisierung und der Unterstützung der HHD_UC-Antwort bei bidirektionalen chipTAN-Lesern.
4BankensignaturDiverse0480ÄDie optionale Bankensignatur wird von keinem Kreditinstitut mehr verwendet und wurde daher komplett aus der Spe- zifikation entfernt. Dies bedeutet syntak- tisch, dass die Segmente ,,Signaturkopf“ und ,,Signaturabschluss" erhalten blei- ben, aber nicht mehr mit einer Banken- signatur belegt werden dürfen.
5TAN- ListenverfahrenDiverse0480ÄTAN-Listenverfahren (TAN-/iTAN-Liste) wurden aus der Spezifikation entfernt. Dies betrifft die aktuellen Segmentversi- onen. In den älteren Segmentversionen sind die Elemente zu TAN-Listen aus Kompatibilitätsgründen noch enthalten. Betroffen Elemente wurden farblich ge- kennzeichnet.
6Archiv in Abschnitt EDiverse0480ÄÄltere Segmentversionen wurden in den Abschnitt E „Archiv: Ältere Segmentver- sionen" verlagert.
+ + +### Releasedatum 06.10.2017 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
lfd. Nr.KapitelKapitel- nummerKen- nungArtBeschreibung
1Starke Kun- denauthentifizie- rungB.30496ENeues Einleitungskapitel zur SCA
2Rahmenbedingun- gen SCAB.4.3.10496ÄDiverse Konkretisierungen und Fehler- behebungen bei den Rahmenbedingun- gen zur starken Kundenauthentifizierung
3HITANB.5.1b0496Ergänzen FinTS-Füllwert bei Auftragsre- ferenz und Challenge für Dummy-HITAN
4PIN/TAN- ManagementC0496ÄKlarstellung zur Isolation von PIN/TAN- Management-Geschäftsvorfällen
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: A
Dokument:Security - Sicherheitsverfahren PIN/TAN
Kapitel:EinleitungStand: 23.02.2018Seite: 7
+ + + + + + + + + + + + + + + + + + + +
lfd. Nr.KapitelKapitel- nummerKen- nungArtBeschreibung
5PIN-ÄnderungC.1.10496ÄAnpassung an die starke Kundenauthen- tifizierung bzgl. des obligatorischen Ver- wendens einer TAN bei SCA.
+ + +### Releasedatum 23.02.2018 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
lfd. Nr.KapitelKapitel- nummerKen- nungArtBeschreibung
1Starke Authentifi- zierungB.4.30496ÄAllgemeine Anpassungen und Fehlerkor- rekturen in den Abläufen zu Prozessva- riante 1 und 2.
Speziell:
- Festlegung von fest definierten FinTS- Füllwerten
- Entfernen der festgelegten Bezugs- segmente in den Abläufen
2Starke Kun- denauthentifizie- rungB.30496EVerständlichere Darstellung der Auth- Klasse 2
3Rahmenbedingun- genB.4.3.10496EKlarstellung, dass die Verwendung von 2 BPDs bei anonymen Dialogen nicht ver- pflichtend ist.
4Data DicitionaryD - M0496EKlarstellung, dass der Parameter „Mehr als ein TAN-pflichtiger Auftrag pro Nach- richt erlaubt" = ,J" mit PSD2 nicht mehr zulässig ist.
+ + + + + + + + + + + + + + + + +
Kapitel:Version: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
8		Stand: 23.02.2018Kapitel: Einleitung
+ + +## Dokumentenstruktur + +Das vorliegende Dokument steht in folgendem Bezug zu den anderen Bänden der +FinTS V3.0 Spezifikation: + + +![Hauptdokument Formals Rückmeldungen SEPA Messages Geschäftsvorfälle Messages Finanzdatenformate Security HBCI Security PIN/TAN Security Secoder 1 5 2 3 4 6 0 8 9 7 DK- Signaturkarte C Secoder R chipTAN mobile TAN Secoder](figures/8.1) + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: A
Dokument:Security - Sicherheitsverfahren PIN/TAN
Kapitel:EinleitungStand: 23.02.2018Seite: 9
+ + +## Inhaltsverzeichnis + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Versionsführung5
Änderungen gegenüber der Vorversion5
Dokumentenstruktur8
Inhaltsverzeichnis9
Abbildungsverzeichnis13
A. Einleitung14
B. Verfahrensbeschreibung17
B.1 Allgemeines17
B.2 Zwei-Schritt-TAN-Verfahren18
B.3 Starke Kundenauthentifizierung20
B.4 Abläufe beim Zwei-Schritt-Verfahren22
B.4.1 Abläufe bei Prozessvariante 123
B.4.1.1 Einfach-TAN bei Prozessvariante 123
B.4.1.2 Synchrone Eingabe von Mehrfach-TANs bei Prozessvariante 125
B.4.2 Abläufe bei Prozessvariante 226
B.4.2.1 Einfach-TAN bei Prozessvariante 227
B.4.2.2 Synchrone Eingabe von Mehrfach-TANs in einem Dialog bei Prozessvariante 229
B.4.2.3 Zeitversetzte, dialogübergreifende Eingabe von Mehrfach-TANs bei Prozessvariante 231
B.4.3 Abläufe bei der Initialisierung mit starker Kundenauthentifizierung33
B.4.3.1 Rahmenbedingungen für den Einsatz der starken Kundenauthentifizierung34
B.4.3.2 Initialisierung bei Prozessvariante 138
B.4.3.3 Initialisierung bei Prozessvariante 240
B.4.4 Allgemeine Festlegungen zum Zeitverhalten beim Zwei- Schritt-Verfahren42
B.4.4.1 Verteilung von Aufträgen auf FinTS-Nachrichten42
B.4.4.2 Zeitüberwachung beim Zwei-Schritt-Verfahren bei Einfach-TANs43
B.5 Geschäftsvorfall HKTAN für Zwei-Schritt-TAN-Einreichung43
B.5.1 Geschäftsvorfall HKTAN in Segmentversion #644
B.6 Erweiterung der Rückmeldungscodes51
B.6.1 Beschreibung spezieller Rückmeldungen im Zwei-Schritt- Verfahren52
B.7 Bankfachliche Anforderungen54
+ + + + + + + + + + + + + + + + +
Kapitel:Version: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
10		Stand: 23.02.2018Kapitel: Einleitung
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
B.8 Erweiterung der Bank- und Userparameterdaten (BPD / UPD)54
B.8.1 PIN/TAN-spezifische Informationen (HIPINS)55
B.8.2 Spezielle Festlegungen für die Dialoginitialisierung beim Zwei-Schritt-Verfahren56
B.9 Besondere Belegungsrichtlinien57
B.9.1 DEG ,,Sicherheitsprofil"58
B.9.2 DEG ,,Schlüsselname“58
B.9.3 DEG ,,Sicherheitsidentifikation, Details"58
B.9.4 Segment ,,Signaturkopf"58
B.9.5 DEG ,,Hashalgorithmus"58
B.9.6 DEG ,,Signaturalgorithmus"58
B.9.7 Segment ,,Signaturabschluss“59
B.9.8 Segment „Verschlüsselungskopf“59
B.9.9 DEG „Verschlüsselungsalgorithmus“59
B.9.10 Segment „Verschlüsselte Daten“59
B.9.11 Parametersegmente zu Geschäftsvorfällen59
C. PIN/TAN-Management60
C.1 Verwalten der Online-Banking-PIN61
C.1.1 PIN-Änderung61
C.2 Sperren der Online-Banking-PIN63
C.2.1 Sperre bei mehrmaliger Falscheingabe63
C.2.2 PIN-Sperre64
C.2.3 PIN-Sperre aufheben65
C.3 Management chipTAN, mobileTAN und bilaterale Verfahren67
C.3.1 Anzeige der verfügbaren TAN-Medien67
C.3.1.1 Anzeigen der verfügbaren TAN-Medien, Segmentversion #567
C.3.1.2 Übermitteln / Anzeigen von TAN-Generator (HHD)- und Secoder-Informationen70
C.3.2 TAN-Medium an- bzw. ummelden in Segmentversion #373
C.3.3 TAN-Generator Synchronisierung76
C.3.4 Verwalten von Mobilfunkverbindungen79
C.3.4.1 Mobilfunkverbindung registrieren79
C.3.4.2 Mobilfunkverbindung freischalten81
C.3.4.3 Mobilfunkverbindung ändern82
C.3.4.4 Deaktivieren / Löschen von TAN-Medien84
C.4 Sonstige87
C.4.1 TAN-Verbrauchsinformationen anzeigen87
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel:
A
Dokument:Security - Sicherheitsverfahren PIN/TAN
Kapitel:EinleitungStand: 23.02.2018Seite: 11
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
C.4.1.1 TAN-Verbrauchsinformationen anzeigen, Segmentversion #287
C.4.2 TAN prüfen und „verbrennen“89
C.4.3 PIN prüfen89
D. Data-Dictionary91
E. Archiv: Ältere Segmentversionen150
E.1 HKTAN für Zwei-Schritt-TAN-Einreichung150
E.1.1 Geschäftsvorfall HKTAN in Segmentversion #1150
E.1.2 Geschäftsvorfall HKTAN in Segmentversion #2153
E.1.3 Geschäftsvorfall HKTAN in Segmentversion #3158
E.1.4 Geschäftsvorfall HKTAN in Segmentversion #4164
E.1.5 Geschäftsvorfall HKTAN in Segmentversion #5169
E.2 Management chipTAN, mobileTAN und bilaterale Verfahren176
E.2.1 Anzeige der verfügbaren TAN-Medien176
E.2.1.1 Anzeigen der verfügbaren TAN-Medien, Segmentversion #1176
E.2.1.2 Anzeigen der verfügbaren TAN-Medien, Segmentversion #2177
E.2.1.3 Anzeigen der verfügbaren TAN-Medien, Segmentversion #3179
E.2.1.4 Anzeigen der verfügbaren TAN-Medien, Segmentversion #4181
E.2.2 TAN-Generator / TAN-Liste an- bzw. ummelden184
E.2.2.1 TAN-Generator / TAN-Liste an- bzw. ummelden in Segmentversion #1184
E.2.2.2 TAN-Generator / TAN-Liste an- bzw. ummelden in Segmentversion #2186
E.2.3 Verwalten von Mobilfunkverbindungen188
E.2.3.1 Mobilfunkverbindung registrieren188
E.2.3.2 Mobilfunkverbindung freischalten193
E.2.3.3 Mobilfunkverbindung ändern195
E.2.3.4 Deaktivieren / Löschen von TAN-Medien199
E.2.4 TAN-Verbrauchsinformationen anzeigen
E.2.4.1 TAN-Verbrauchsinformationen anzeigen, Segmentversion #1		201
201
F. Anlagen204
F.1 Übersicht der Segmente204
F.2 Übersicht Nachrichtenaufbau206
F.2.1 Beispieldialog im Ein-Schritt-Verfahren207
F.2.2 Nachricht ,,Dialoginitialisierung"207
F.2.3 Nachricht „SEPA Einzelüberweisung“209
+ + + + + + + + + + + + + + + + +
Kapitel:Version: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite: 12Stand: 23.02.2018Kapitel: Einleitung
+ + + + + + + + + + + +
F.2.4
Nachricht ,,Saldenabfrage"		210
F.2.5
Nachricht ,,Dialogbeendigung"		210
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel:
A
Dokument:Security - Sicherheitsverfahren PIN/TAN
Kapitel:EinleitungStand: 23.02.2018Seite: 13
+ + +Abbildungsverzeichnis + + + + + + + + + + + + + + + +
Abbildung 1: Online-Banking mit PIN/TAN und HBCI14
Abbildung 2: Präsentationsbeispiel für ein konkretes Zwei-Schritt-Verfahren20
Abbildung 3: Wirkung der PSD2 Ausnahmen auf den Ablauf22
+ + + + + + + + + + + + + + + + +
Kapitel:Version: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
14		Stand: 23.02.2018Kapitel: Einleitung
+ + +### A. EINLEITUNG + +In dieser Spezifikation wird ein multibankfähiges FinTS-Protokoll für das Sicher- +heitsverfahren PIN/TAN beschrieben. Dieses Sicherheitsverfahren kann in mul- +tibankfähigen Online-Banking-Verfahren der deutschen Kreditwirtschaft eingesetzt +werden. Informationen bzgl. Nachrichtenaufbau und Dialogablauf sind dem Doku- +ment [Formals] zu entnehmen. + +Um ein möglichst hohes Maß an Synergie nutzen zu können, wird für die Kommuni- +kation zwischen Kundenprogramm und Kreditinstitut weitestgehend auf der FinTS- +Spezifikation V3.0 (Sicherheitsverfahren HBCI) [HBCI] aufgesetzt, insbesondere +bzgl. Syntax, Datenformaten und Abläufen. Sofern nicht anders vermerkt gelten für +den Nachrichtenaufbau, Dialogablauf etc. die dort getroffenen Regelungen. Dieses +Dokument beschreibt daher nur die für das PIN/TAN-Verfahren abweichenden Fest- +legungen. + +Die Einführung eines PIN/TAN-Protokolls auf Basis der FinTS-Syntax bietet die +Möglichkeit, sämtliche Online-Banking-Verfahren über eine einheitliche Plattform +abzuwickeln. + + +Abbildung 1: Online-Banking mit PIN/TAN und HBCI + +![Finanz- Software für FinTS -PIN/TAN- FinTS- Komponenten PIN/TAN PIN/TAN- Verwaltung PIN/TAN- Interface Internet- Protokolle FinTS- Server Finanz- Software für FinTS -HBCI- Bank- anwen- dungen FinTS- Componenten HBCI HBCI Schlüssel- verwaltung](figures/14.1) + + +FinTS mit dem Sicherheitsverfahren PIN/TAN verfolgt als primären Zweck das Onli- +ne-Banking mit Offline-Finanzsoftwareprodukten. Um eine möglichst einfache In- +tegration in bestehende FinTS-Systeme zu erlauben, sollen die in der FinTS- + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel:
A
Dokument:Security - Sicherheitsverfahren PIN/TAN
Kapitel:EinleitungStand: 23.02.2018Seite: 15
+ + +Spezifikation beschriebene Syntax und die Datenformate möglichst unverändert als +Grundlage verwendet werden. Somit gelten auch die für den Transport von Signa- +tur- und Verschlüsselungsinformationen erforderlichen Datenstrukturen weiterhin, +obwohl sie teilweise für das PIN/TAN-Verfahren nicht benötigt werden. Es wird le- +diglich eine neue DEG, die so genannte „Benutzerspezifische Signatur“ für die Auf- +nahme von PIN und TAN definiert, die anstatt der elektronischen HBCI-Signatur in +den Signaturabschluss eingestellt wird. Die nicht verwendeten Datenelemente der +Sicherheitssegmente werden, falls notwendig, mit Defaultwerten belegt. + +Ob ein Kreditinstitut das Sicherheitsverfahren PIN/TAN anbietet, erkennt das Kun- +denprodukt in den Bankparameterdaten am Vorhandensein des Geschäftsvorfallpa- +rametersegments HIPINS (,,PIN/TAN-spezifische Informationen", vgl. Kapitel B.8.1) +bzw. des Kommunikationsdienstes 3 (https) im HIKOM-Segment. + +Grundsätzlich können mit dem Sicherheitsverfahren PIN/TAN alle im Dokument +[Messages] aufgeführten Geschäftsvorfälle verwendet werden. Dies gilt auch für +verbandsindividuelle Erweiterungen. Welche Geschäftsvorfälle konkret zulässig +sind, teilt das Kreditinstitut im Segment HIPINS (s. Kap. B.8.1) mit. + +Da bei PIN/TAN aufgrund der nicht vorhandenen kryptographischen Verfahren auf +Protokollebene keine Verschlüsselung zum Einsatz kommen kann, muss https +(TLS) auf Transportebene verwendet werden. Das FinTS Sicherheitsverfahren +PIN/TAN verbindet damit die Sicherheit eines Einmalpassworts (TAN) mit der in TLS +bewährten Transportverschlüsselung. + +Das Sicherheitsverfahren PIN/TAN tritt in FinTS bezüglich der Einreichung von +TAN-pflichtigen Geschäftsvorfällen in zwei unterschiedlichen Ausprägungen auf, die +sich vom Prozessablauf her unterscheiden: + + +#### Ein-Schritt-TAN-Verfahren + +Beim Ein-Schritt-TAN-Verfahren wird der Geschäftsvorfall in einem Prozess-Schritt +zusammen mit der TAN eingereicht, d. h. in einem Dialogschritt bestehend aus Auf- +trag und Antwort wird ein TAN-pflichtiger Geschäftsvorfall komplett abgewickelt. +Diese Verfahrensweise entspricht dem Vorgehen bei signaturbasierten Verfahren +und war bis zur Einführung des Zwei-Schritt-Verfahrens die einzige Möglichkeit, +TAN-pflichtige Aufträge über das FinTS-Protokoll einzureichen. Mit dem Ein-Schritt- +Verfahren kann keine starke Authentifizierung (vgl. [PSD2]) durchgeführt werden. Es +wird jedoch benötigt, um PIN/TAN-Management-Geschäftsvorfälle wie z. B. eine ini- +tiale PIN-Änderung durchführen zu können. + + + + + + + + + + + + + + + +
Kapitel:Version: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
16		Stand: 23.02.2018Kapitel: Einleitung
+ + +## Zwei-Schritt-TAN-Verfahren + +Beim Zwei-Schritt-Verfahren werden die Auftragseinreichung und die TAN- +Übermittlung in zwei Teilschritte zerlegt. Dadurch hat das Kreditinstitut auch die +Möglichkeit, als Antwort auf die erste Nachricht eine so genannte ,,Challenge" zu +übermitteln, aus der der Kunde dann die zu verwendende TAN herleiten muss. +Dadurch wird auch eine logische Bindung (auch als ,Dynamic Linking" bezeichnet) +der TAN an den Auftrag erreicht. Ein Zwei-Schritt-Verfahren ist die Voraussetzung +für die Durchführung einer starken Authentifizierung (vgl. [PSD2]). + +Das Zwei-Schritt-Verfahren in FinTS beschreibt ausschlieBlich die Protokollabläufe +und dient als abstrakte Beschreibung, die in konkreten Ausprägungen wie z. B. +chipTAN verwendet werden kann. Die konkreten Ausprägungen selbst sind nicht +Bestandteil dieser Spezifikation. + +Die Vorteile des FinTS Sicherheitsverfahrens PIN/TAN: + +. Abwicklung aller Online-Banking-Verfahren (Kommunikationszugänge, Sicher- +heitsverfahren PIN/TAN und HBCI) über eine einheitliche Plattform + +· Verfügbarkeit aller FinTS-Geschäftsvorfälle auch für PIN/TAN-Kunden + +. Die Anpassung bestehender HBCI-Kundenprodukte ist mit Hilfe eines durch das +PIN/TAN-Verfahren erweiterten FinTS-Protokollbausteins möglich. + +· einheitliche Stammdatenhaltung für alle Online-Banking-Verfahren + +· einheitliche Anbindung der Banken-Fachanwendungen + +. Kundenauthentisierung und -autorisierung an einer zentralen Stelle + +· Standardisierung der Geschäftsvorfälle für das PIN/TAN-Management (z. B. PIN +ändern, TAN-Medien-Management u. ä.) + +Im Folgenden gilt die Definition: + + +## FinTS-Füllwert + +Als FinTS-Füllwert wird eine Belegung des entsprechenden Datenelementes be- +trachtet, welche den getroffenen Festlegungen (Formatvorgaben, Restriktionen, Be- +legungshinweise) nicht widerspricht. Ein FinTS-Füllwert ist somit ein gültiger Wert im +Sinne der Definition des Datenelementes. Trotzdem ist dieser FinTS-Füllwert des +betroffenen Datenelements für die Verarbeitung nicht relevant und wird daher von +den verarbeitenden Systemen auf Kreditinstitutsseite ignoriert. + +Handelt es sich um Datenelemente mit Status ,O", sollten diese leer gelassen wer- +den. Auch hier gilt, dass Vorhandensein und Inhalt kreditinstitutsseitig nicht geprüft +werden. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: B
Dokument:Security - Sicherheitsverfahren PIN/TAN
Kapitel:
Abschnitt:		Allgemeines
Verfahrensbeschreibung		Stand: 23.02.2018Seite: 17
+ + +# B. VERFAHRENSBESCHREIBUNG + + +## B.1 Allgemeines + +Es gelten die in [Formals] und [HBCI] aufgeführten Formate und Belegungsrichtli- +nien. + +Ergänzend bzw. abweichend hierzu gilt: + +· Datenelemente in den Sicherheitssegmenten werden teilweise abweichend be- +legt (s. Kap. B.8). Die korrekte Segmentabfolge ist in Kap. F.1 beschrieben. + +. PIN und TAN werden in die DEG ,,Benutzerdefinierte Signatur" des Segments +HNSHA ab der Version #2 eingestellt. + +· Für die Rückmeldungen wurden neue Codes definiert (s. Kap. B.5.1). + +. Beim HBCI DDV-Verfahren und TAN-Verfahren unter Verwendung von HKTAN > +Segmentversion #4 dürfen in der Dialoginitialisierung keine Schlüssel ausge- +tauscht werden (Segmente HKISA und HIISA). + +. Die Bankparameterdaten werden um das Segment HIPINS erweitert, das die +PIN/TAN-spezifischen Informationen des Kreditinstituts enthält. Zusätzlich +kommt bei Einsatz des Zwei-Schritt-TAN-Verfahrens der neue Geschäftsvorfall +HKTAN für die Abwicklung und das Parametersegment HITANS für die Festle- +gungen hinzu. + +• Der für den Kunden zugelassene Geschäftsvorfall HKTAN und die Geschäftsvor- +fälle für das PIN/TAN-Management sind im Segment HIUPD mitzuteilen. + +· Die Verschlüsselungssegmente werden auch beim PIN/TAN-Verfahren benötigt, +obwohl dort auf Protokollebene keine Verschlüsselung stattfindet. Dies ist erfor- +derlich, damit der Aufbau personalisierter Nachrichten bei den Sicherheitsverfah- +ren HBCI und PIN/TAN identisch ist. + +. Als Kommunikationsdienst ist https ab der Version #4 des Segmentes HIKOM zu +verwenden [Formals]. + +Für den Einsatz von Zwei-Schritt-Verfahren gelten zusätzlich die folgenden allge- +meinen Festlegungen: + +· 1 bis 98 unterschiedliche Zwei-Schritt-Verfahren pro Institut +1 bis 9 unterschiedliche Zwei-Schritt-Verfahren pro Benutzer +(+ ggf. Ein-Schritt-Verfahren) + +· Zur eindeutigen Bezeichnung des Ein- oder Zwei-Schritt-Verfahrens wird das +Element ,,Sicherheitsfunktion, kodiert" verwendet: + +999: Ein-Schritt-Verfahren; + +900 ... 997: Zwei-Schritt-Verfahren + +Die Verknüpfung von Code und Verfahren ist institutsspezifisch und wird in der +BPD festgelegt (vgl. hierzu Kapitel B.8.2 und D). + +• Alle unterstützten TAN-Verfahren (das Ein-Schritt-Verfahren und bis zu 98 in der +BPD definierte konkrete Zwei-Schritt-Verfahren) gelten als gleichberechtigte +PIN/TAN-Sicherheitsverfahren, die in HIPINS nicht dediziert angesprochen wer- +den können. + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
18		Stand: 23.02.2018Kapitel: Verfahrensbeschreibung
Abschnitt: Zwei-Schritt-TAN-Verfahren
+ + +Daher muss ein in HIPINS definierter TAN-pflichtiger Auftrag über irgendeines +aber kein spezielles der unterstützten TAN-Verfahren autorisiert werden. + +· Mit dem Rückmeldungscode 3920 und Rückmeldeparametern werden dem Kun- +den in der Dialoginitialisierungsantwort die für ihn zugelassenen PIN/TAN- +Sicherheitsverfahren (ein Einschritt-Verfahren und bis zu 9 unterschiedliche +Zwei-Schritt-Verfahren) mitgeteilt. Als Bezugssegment für das Rückmeldungs- +segment HIRMS wird HKVVB (Verarbeitungsvorbereitung) verwendet. + +• Der Kunde übermittelt im Signaturkopf der Dialoginitialisierungsnachricht, mit +welchem konkreten TAN-Verfahren er den Dialog führen will. Das konkrete TAN- +Verfahren darf während des Dialogs nicht gewechselt werden. + +• Die beiden Teilschritte des Zwei-Schritt-Verfahrens müssen nicht zwingend in ei- +nem einzigen Dialog abgewickelt werden, außer es handelt sich um eine Dialogi- +nitialisierung. Über den Auftrags-Hashwert bzw. die Auftragsreferenz ist eine ent- +sprechende Verkettung über mehrere Dialoge hinweg möglich. Über einen BPD- +Parameter wird gesteuert, ob zeitversetztes / dialogübergreifendes Arbeiten er- +laubt ist. + +. Beim Einsatz von Mehrfach-TANs gilt ein konkretes Zwei-Schritt-Verfahren für +den gesamten Dialog des jeweiligen Benutzers. Jeder Benutzer kann ein eigenes +konkretes Zwei-Schritt-Verfahren verwenden, die Prozessvariante (vgl. Kapitel +B.2) darf im Kontext einer Mehrfach-TAN-Einreichung jedoch nicht gewechselt +werden. Im Falle eines nicht zugelassenen Wechsels der Prozessvariante muss +das Kreditinstitut den Dialog mit Rückmeldungscode 9957 ,,Wechsel der TAN +Prozessvariante bei Mehrfach-TANs nicht erlaubt“ beenden. Für die Anmeldung +mit starker Authentifizierung (vgl. Kapitel B.4.3) sind Mehrfach-TANs nicht zuge- +lassen. Innerhalb eines Dialoges, der vom dialogführenden Benutzer mittels star- +ker Authentifizierung eröffnet wurde, können jedoch Aufträge mit Mehrfach-TANs +eingereicht werden. + +. Eine im Rahmen der Dialoginitialisierung für die starke Kundenauthentifizierung +verwendete TAN gilt nicht für weitere in diesem Dialog eingereichte TAN- +pflichtige Aufträge (dies ist keine Session-TAN). + + +![](figures/18.1) + + +Gemäß §7 der „Bedingungen für die konto-/depotbezogene Nutzung +des Online-Banking mit PIN und TAN" dürfen sowohl die PIN als +auch TANs nicht elektronisch im Kundenprodukt gespeichert wer- +den. + + +## B.2 Zwei-Schritt-TAN-Verfahren + +Das einschrittige PIN/TAN-Verfahren orientiert sich an der Arbeitsweise des HBCI- +Sicherheitsverfahrens und verwendet PIN und TAN im Sinne einer „Signatur“ einer +FinTS-Nachricht. Die Verwendung des Ein-Schritt-Verfahrens ist jedoch nur noch in +bestimmten Situationen, z. B. zur Ermittlung der zugelassenen Sicherheitsverfahren, +zugelassen. Die Arbeitsweise aller gängigen PIN/TAN-basierten Verfahren erfordert +jedoch bei TAN-pflichtigen Aufträgen eine Aufteilung zwischen Auftragseinreichung +und Authentisierung / Autorisierung in zwei Prozess-Schritte, um dem Kunden zum +Zweck der Transparenz über die relevanten Inhalte des Auftrags wie z. B. Betrag +und Empfänger eine Sicherheitsfrage, die so genannte ,,Challenge" mitzuteilen, die +er für die Ermittlung / Erzeugung der TAN benötigt. Damit wird die TAN über einen + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: B
Dokument:Security - Sicherheitsverfahren PIN/TAN
Kapitel:
Abschnitt:		Verfahrensbeschreibung
Zwei-Schritt-TAN-Verfahren		Stand: 23.02.2018Seite: 19
+ + +verfahrensabhängigen Algorithmus logisch an den Auftrag gebunden („Dynamic +Linking"). Dabei gibt es in FinTS grundsätzlich zwei unterschiedliche Prozessvarian- +ten, die mit insgesamt vier TAN-Prozessen abgebildet werden: + + +### Prozessvariante 1 + +. TAN-Prozess=1: + +Im ersten Schritt wird ein Auftrags-Hashwert zum Institut übermittelt, der zur Her- +leitung der Challenge dient, die vom Institut zum Kundenprodukt gesendet wird. +Im zweiten Schritt werden die Auftragsdaten inklusive TAN eingereicht und bestä- +tigt. + + +### Prozessvariante 2 + +Bei der Prozessvariante 2 werden die TAN-Prozesse=2 bis 4 verwendet. Die +TAN-Prozesse 3 und 4 sind nur Unterprozesse von TAN-Prozess=2 und können +nicht isoliert auftreten. + +. TAN-Prozess=2: + +Zuerst wird der Auftrag eingereicht (siehe TAN-Prozess=4), aus dem eine Chal- +lenge errechnet wird. Anschließend wird mit TAN-Prozess=2 die TAN zum Institut +übertragen. + +. TAN-Prozess=3: + +Bei Verwendung von Mehrfach-TANs kann mit diesem Prozess die Einreichung +einer TAN eines weiteren Benutzers eingeleitet werden. + +. TAN-Prozess=4: + +Dient der Einleitung des Zwei-Schritt-Verfahrens für die erste TAN und wird bei +der Auftragseinreichung (Schritt 1) verwendet. TAN-Prozess=4 wird weiterhin in +Verbindung mit dem Geschäftsvorfall „TAN Prüfen und Verbrennen“ benutzt. + +Beispiele für solche Zwei-Schritt-Verfahren sind Lösungen wie z. B. chipTAN- oder +mobile TAN-Verfahren. + +Mit dem FinTS Zwei-Schritt-TAN-Verfahren wird keines dieser genannten Verfahren +konkret spezifiziert - es erfolgt nur eine abstrakte Definition des Ablaufs, der über +Parameter gesteuert wird. Der Ablauf selbst ist für alle Zwei-Schritt-Verfahren iden- +tisch. Die Parametrisierung eines konkreten Zwei-Schritt-Verfahrens erfolgt über das +Parametersegment HITANS (Geschäftsvorfallparameter zu „Zwei-Schritt-TAN- +Einreichung“ HKTAN). + +Bei Verwendung von Mehrfach-TANs wird innerhalb eines Ablaufs die Prozessvari- +ante durch den Dialogführer des ersten (und ggf. einzigen) Dialogs für alle beteilig- +ten Benutzer festgelegt. + +Durch Verwendung des Parametersegmentes HITANS ist die abstrakte Beschrei- +bung von maximal 98 konkreten Zwei-Schritt-Verfahren in der BPD möglich, die +über das Datenelement „Sicherheitsfunktion, kodiert“ referenziert werden. + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
20		Stand: 23.02.2018Kapitel: Verfahrensbeschreibung
Abschnitt: Starke Kundenauthentifizierung
+ + +Einem Benutzer können maximal 9 konkrete Zwei-Schritt-Verfahren zugeordnet +werden. Bei der Verwendung von Mehrfach-TANs kann jeder beteiligte Benutzer ein +eigenes konkretes Zwei-Schritt-Verfahren verwenden - die Verfahren können also +innerhalb einer Nachricht unterschiedlich sein1. + + +Abbildung 2: Präsentationsbeispiel für ein konkretes Zwei-Schritt-Verfahren + +![1 X Überweisungsformular Empfangername Kontonummer Bankleitzahl Zwei-Schritt-Verfahren Nr. 1: Sicherheitsfkt, kodiert: 995 Techn. Identifikation: „chipTAN“ Name TAN-Verfahren: ,,chipTAN-Verfahren" Länge TAN-Eingabe: 6 Format TAN-Eingabe: 1 Text Rückgabewert: ,Start-Code" Länge Rückgabewert: 10 chipTAN-Verfahren Start-Code 2045201998 TAN:](figures/20.1) + + +Das Präsentationsbeispiel in Abbildung 2 soll zeigen, wie auf Basis der übermittel- +ten Parameter eine Gestaltung eines konkreten Zwei-Schritt-Verfahrens aussehen +kann. + + +## B.3 Starke Kundenauthentifizierung + +Durch [MaSI] und [PSD2] besteht die Forderung nach einer starken Kundenauthen- +tifizierung (Strong Customer Authentication – SCA) bei Zugriff auf Kontodaten (Dia- +loginitialisierung) und Geschäftsvorfällen, die aufgrund ihres Missbrauchsrisikos +entsprechend geschützt werden müssen (TAN-pflichtige Geschäftsvorfälle). + +Zusätzlich enthält [PSD2] aber auch Ausnahmen von dieser starken Kundenauthen- +tifizierung, d. h. unter bestimmten Rahmenbedingungen einen Verzicht auf die star- +ke Kundenauthentifizierung, was ebenfalls durch entsprechende FinTS-Prozesse +abzubilden ist. Da die Prüfung auf diese SCA-Ausnahmen zur Laufzeit erfolgen +muss, wird die Entscheidung, ob eine TAN erforderlich ist dynamisch gefällt. Wäh- +rend die Rahmenbedingungen zur Durchführung einer starken Kundenauthentifizie- +rung im Rahmen der Dialoginitialisierung in Abschnitt B.4.3 vollständig beschrieben +sind, folgen an dieser Stelle noch einige allgemeine Festlegungen zu den Ge- +schäftsvorfällen. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: B
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FV
Kapitel:VerfahrensbeschreibungStand:Seite:
Abschnitt:Starke Kundenauthentifizierung23.02.201821
+ + +Da sich die PSD2-Vorgaben nur auf den Zahlungsverkehr beziehen, gibt es in +FinTS weiterhin Geschäftsvorfälle, bei denen abhängig von der Deklaration in +HIPINS in keinem Fall oder immer eine TAN verwendet werden muss. + +Durch die Einführung der Ausnahmen zur TAN-Pflicht ergeben sich für die FinTS- +Verarbeitung daher vier unterschiedliche Authentifizierungsklassen, die auch Aus- +wirkungen auf die Belegung des Elements TAN erforderlich im Parameterseg- +ment PIN/TAN-Spezifische Informationen (HIPINS) haben: + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Auth- Klas- seBeschreibungTAN erforder- lich in HIPINS
1Nicht-Zahlungsverkehrs-Geschäftsvorfälle, für die grundsätz- lich keine TAN erforderlich ist. Dies betrifft z. B. den Bereich Wertpapier.N
2Zahlungsverkehrs-Geschäftsvorfälle im Sinne der PSD2 wie z. B. SEPA-Überweisungen, aber auch Salden- und Umsatzab- fragen, für die die starke Kundenauthentifizierung inkl. ihrer Ausnahmen gilt. Diese werden zwar abweichend von der ur- sprünglichen Bedeutung in HIPINS nun grundsätzlich als TAN- pflichtig definiert, es wird jedoch erst zum Ausführungszeit- punkt durch das Kreditinstitut festgelegt, ob wirklich eine SCA (=TAN-Eingabe) notwendig ist, oder es sich um eine SCA-
Ausnahme handelt. Dabei kann dann die Definition in HIPINS dergestalt übersteuert werden, dass für einen als TAN-pflichtig gekennzeichneten Geschäftsvorfall aufgrund einer SCA Aus- nahme doch keine TAN benötigt wird.		✓
3Nicht-Zahlungsverkehrs-Geschäftsvorfälle, für die grundsätz- lich eine TAN erforderlich ist. Dies betrifft z. B. den Bereich Wertpapier.✓
4PIN/TAN-Management-Geschäftsvorfälle, für die situationsbe- dingt eine starke Kundenauthentifizierung bis zum Abschluss des gesamten Prozesses ausgesetzt werden kann, z. B. im Rahmen einer initialen PIN-Änderung.✓
J
+ + +Die Authentifizierungsklassen 1 und 3 entsprechen den heutigen statischen TAN- +Festlegungen auf Basis der Definitionen in HIPINS. + +Bei der Durchführung von Geschäftsvorfällen der Authentifizierungsklasse 2 - hier- +zu gehört auch die Dialoginitialisierung – fällt die Entscheidung, ob eine TAN erfor- +derlich ist, erst nach dem Einreichen der Kundennachricht. Diese enthält bei Au- +thentifizierungsklasse 2 grundsätzlich eine TAN-Anforderung in Form eines HKTAN +ab Segmentversion #6. Institutsseitig wird nun gegen die in [PSD2] definierten Aus- +nahmen geprüft, wodurch zwei Möglichkeiten für die weitere Verarbeitung entste- +hen: + +1\. Fortführen des Zwei-Schritt-TAN-Verfahrens. Dies wird vom Kreditinstitut gene- +rell durch den neuen Rückmeldungscode 0030 Auftrag empfangen - Si- +cherheitsfreigabe erforderlich signalisiert. + +2\. Keine starke Kundenauthentifizierung erforderlich. Dies wird durch den Rück- +meldungscode 3076 Keine starke Authentifizierung erforderlich + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
22		Stand: 23.02.2018Kapitel: Verfahrensbeschreibung
Abschnitt: Abläufe beim Zwei-Schritt-Verfahren
+ + +angezeigt, zusätzlich zu fachlichen Rückmeldungen zum eingereichten Auftrag +wie z. B. 0010 Auftrag entgegengenommen. + + +Abbildung 3: Wirkung der PSD2 Ausnahmen auf den Ablauf + +![Benutzer Institut Schritt 1a: Auftrag einreichen und TAN anfordern Prüfung auf PSD2 Ausnahmen und Entscheidung, ob Schritte 1b & 2a nötig sind Schritt 1b: Challenge Schritt 2a: TAN Nur, wenn Schritt 1b/2a nötig Schritt 2b: Antwort](figures/22.1) + + +Ein Kundensystem, das HKTAN ab #6 anbietet, muss auf diese beiden Möglichkei- +ten der Auftragseinreichung entsprechend reagieren können. + +Details zu den genauen Abläufen sind in Kapitel B.4.3 für die Dialoginitialisierung +beschrieben. Das Verhalten beim Einreichen von Zahlungsverkehrsaufträgen ist +bzgl. der Ausnahmen analog dazu zu sehen. + + +![](figures/22.2) + + +Während der Migrationsphase: Da die Dialoginitialisierungsnach- +richt durch die Existenz des HKTAN ab Segmentversion #6 signali- +siert, ob das Kundenprodukt die starke Kundenauthentifizierung un- +terstützt, sollte das Kreditinstitut in der Antwort passende BPD +übermitteln, in denen das Segment HIPINS die für das Kundenpro- +dukt passenden Belegungen enthält. Somit sollten Geschäftsvorfälle +der Authentifizierungsklasse 2 nur bei SCA-fähigen Kundenproduk- +ten den Wert J besitzen, ansonsten den Wert N. Anderenfalls müss- +te ein Benutzer für Geschäftsvorfälle wie z. B. eine Saldenabfrage +bei nicht SCA-fähigen Kundenprodukten immer eine TAN eingeben. + + +## B.4 Abläufe beim Zwei-Schritt-Verfahren + +Die Abläufe zur Abwicklung des Zwei-Schritt-Verfahrens unterscheiden sich je nach +gewählter Variante und der Behandlung von Mehrfach-TANs. Konkret werden fol- +gende in der Praxis vorkommenden Abläufe beschrieben: + +Ablauf 1: +Prozessvariante 1 mit Einfach-TAN + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: B
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FV
Kapitel:VerfahrensbeschreibungStand:Seite:
Abschnitt:Abläufe beim Zwei-Schritt-Verfahren23.02.201823
+ + +Ablauf 2: +Prozessvariante 1 mit synchroner Eingabe von Mehrfach-TANs + +Ablauf 3: +Prozessvariante 2 mit Einfach-TAN + +Ablauf 4: +Prozessvariante 2 mit synchroner Eingabe von Mehrfach-TANs in ei- +nem Dialog + +Ablauf 5: +Prozessvariante 2 mit zeitversetzter Eingabe von Mehrfach-TANs, +dialogübergreifend + +Hinzu kommen folgende Abläufe für die Initialisierung mit starker Authentifizierung: + +Ablauf 6: +Initialisierung bei Prozessvariante 1 + +Ablauf 7: +Initialisierung bei Prozessvariante 2 + +Alle Abläufe sind bezogen auf die einzelnen Prozessschritte exakt in der beschrie- +benen Form umzusetzen; die Bildung von anderen Derivaten ist nicht zugelassen. +Die Dialogendenachricht und die darauf folgende allgemeine Kreditinstitutsnachricht +werden aus Gründen der Übersichtlichkeit in den Prozessen nicht dargestellt. + +Bei den Abläufen 1, 3 und 4 wird davon ausgegangen, dass alle enthaltenen Schrit- +te zwingend in einem einzigen Dialog abgewickelt werden. + +In einem Dialog ist es grundsätzlich möglich aber nicht verpflichtend, dass mehrere +in sich abgeschlossene Abläufe hintereinander durchgeführt werden. Es gelten hier- +bei als Rahmenbedingungen die für den gesamten Dialog getroffenen Festlegun- +gen, z. B., dass die Prozessvariante innerhalb eines Dialoges nicht gewechselt wer- +den darf. + +In den Prozessen mit Einfach-TAN sind die starke Kundenauthentifizierung und de- +ren Ausnahmen, wie in Kapitel B.3 beschrieben, berücksichtigt. + + +## B.4.1 Abläufe bei Prozessvariante 1 + +Um einen TAN-pflichtigen Auftrag im Zwei-Schritt-Verfahren über Prozessvariante 1 +einzureichen, müssen die im Folgenden beschriebenen Schritte durchgeführt wer- +den. Dabei gilt grundlegende Abfolge der Segmente am Beispiel einer SEPA- +Einzelüberweisung: + +1\. Schritt: HKTAN <> HITAN + +2\. Schritt: HKCCS <> HIRMS zu HKCCS + + +## B.4.1.1Einfach-TAN bei Prozessvariante 1 + +Der vollständige Ablauf sieht bei einem Auftrag mit nur einer benötigten TAN („Ein- +fach-TAN") folgendermaßen aus: + +Einfach-TAN bei Prozessvariante 1 + +Ausgangszustand: + +• Es wurde ein Auftrags-Hashwertverfahren ungleich „0“ gewählt. + +. Die Dialoginitialisierung ist erfolgt; der Kunde hat dort durch entsprechende +Belegung des DE ,,Sicherheitsfunktion, kodiert“ ein konkretes Zwei-Schritt- +Verfahren für den gesamten Dialog gewählt. Im Rahmen der Dialoginitialisie- +rung wurde ggf. bereits eine starke Kundenauthentifizierung durchgeführt (vgl. + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
24		Stand: 23.02.2018Kapitel: Verfahrensbeschreibung
Abschnitt: Abläufe beim Zwei-Schritt-Verfahren
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
Kapitel B.4.3).
Schritt 1a HKTAN→Auftrags-Hashwert einreichen
Durch Einreichung des Geschäftsvorfalls HKTAN mit der Bele- gung gemäß TAN-Prozess=1 wird der Auftrags-Hashwert zum Institut übertragen. Über die Belegung ,,Weitere TAN folgt" = ,N“ wird signalisiert, dass dies die letzte und einzige TAN zu dem eingereichten Auftrag ist.
Durch eine Prüfung der eingereichten Daten, im Speziellen der Benutzerkennung und der PIN, gegen die PSD2 Ausnahmen legt das Kreditinstitut fest, wie weiter vorgegangen werden soll:
. starke Kundenauthentifizierung erforderlich, angezeigt durch den Rückmeldungscode 0030 Auftrag emp- fangen - Sicherheitsfreigabe erforderlich (→weiter mit Schritt 1b(B))
. der Faktor Wissen ist ausreichend, angezeigt durch den Rückmeldungscode 3076 Keine starke Authen- tifizierung erforderlich (→weiter mit Schritt 1b, Fall (A)).
Schritt 1b HITAN←Challenge senden (A) Ohne starke Kundenauthentifizierung:
Durch RM-Code 3076 wird signalisiert, dass keine Challenge benötigt wird. Die Antwortnachricht enthält einen syntaktisch korrekten HITAN, d. h. für die Elemente Auftragsreferenz und Challenge sind vom Kreditinstitut die festen FinTS- Füllwerte ,,noref" und ,nochallenge" einzustellen. Diese sind vom Kundenprodukt zu ignorieren.
(B) Bei starker Kundenauthentifizierung:
Der Auftrag-Hashwert wird auf Institutsseite zwischengespei- chert und anschließend eine verfahrensspezifische Challenge ermittelt, die dem Kundenprodukt in HITAN mitgeteilt wird. Durch RM-Code 0030 zusammen mit den Elementen ,,Auf- trags-Hashwert" und ,Challenge" aus HITAN erhält das Kun- denprodukt in der Kreditinstitutsantwort die Information, dass der Kunde nun auf Basis der Challenge in vereinbarter Form ei- ne TAN ermitteln muss.
Schritt 2a z.B. HKCCS→1. TAN einreichen
(A) Ohne starke Kundenauthentifizierung:
Einreichen des eigentlichen Geschäftsvorfalls ohne TAN.
(B) Bei starker Kundenauthentifizierung:
Zusammen mit dem eigentlichen Geschäftsvorfall, z. B. HKCCS wird die ermittelte TAN zum Kreditinstitut übertragen. Nach er- folgreicher TAN-Verifikation kann der Auftrag verarbeitet wer- den.
Schritt 2b z. B.←Rückmeldungen senden
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: B
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FV
Kapitel:VerfahrensbeschreibungStand:Seite:
Abschnitt:Abläufe beim Zwei-Schritt-Verfahren23.02.201825
+ + + + + + + + +
HIRMS zu HKCCS(A) Ohne starke Kundenauthentifizierung:
Mit der Kreditinstitutsantwort werden ggf. erzeugte Antwortseg- mente sowie die Rückmeldungen zum Auftrag selbst zum Kun- denprodukt gesendet.
(B) Bei starker Kundenauthentifizierung:
Mit der Kreditinstitutsantwort werden ggf. erzeugte Antwortseg- mente sowie die Rückmeldungen zur TAN-Verifikation und zum Auftrag selbst zum Kundenprodukt gesendet.
+ + +## B.4.1.2Synchrone Eingabe von Mehrfach-TANs bei Prozessvariante 1 + +Bereits beim etablierten Ein-Schritt-TAN-Verfahren ist die Verwendung von Mehr- +fach-TANs möglich. Diese müssen dort in einem Schritt zusammen mit dem Auftrag +eingereicht werden. + +Beim Zwei-Schritt-TAN-Verfahren wird die Verwendung von Mehrfach-TANs optio- +nal in gleicher Weise unterstützt. Bei Prozessvariante 1 wird nur die synchrone Ein- +gabe von Mehrfach-TANs unterstützt. Der Parameter ,,TAN zeitversetzt / dialog- +übergreifend erlaubt“ in HITANS muss mit ,,N“ belegt werden. + +Bei Verwendung von Mehrfach-TANs gemäß Prozessvariante 1 wird grundsätzlich +eine starke Kundenauthentifizierung gefordert; SCA-Ausnahmen werden nicht un- +terstützt. + +Der erweiterte Ablauf für die synchrone Einreichung eines Auftrages mit Mehrfach- +TAN mit Prozessvariante 1 sieht folgendermaßen aus: + + +### Synchrone Eingabe von Mehrfach-TANs bei Prozessvariante 1 + +Ausgangszustand: + +. Der Parameter ,,Mehrfach-TAN erlaubt" in HITANS ist mit ,,J" belegt. + +. Der Parameter ,,TAN zeitversetzt / dialogübergreifend erlaubt" in HITANS ist +mit ,,N“ belegt. + +. Es wurde ein Auftrags-Hashwertverfahren ungleich „0“ gewählt. + +. Die Dialoginitialisierung ist erfolgt; der erste Benutzer hat dort durch Belegung +des DE ,,Sicherheitsfunktion, kodiert" ein konkretes Zwei-Schritt-Verfahren für +sich gewählt und dadurch die Prozessvariante 1 für den gesamten Ablauf fest- +gelegt. Im Rahmen der Dialoginitialisierung wurde ggf. bereits eine starke +Kundenauthentifizierung durchgeführt (vgl. Kapitel B.4.3). + + + + + + + + + + + + + + + + + + + + + + + +
Schritt 1a HKTAN→Auftrags-Hashwert einreichen
wie bei Einfach-TAN nach Prozessvariante 1. Über die Bele- gung ,,Weitere TAN folgt" = ,J" wird signalisiert, dass vor Einrei- chung des Auftrags mindestens eine weitere Challenge ange- fordert wird.
Schritt 1b HITAN←Challenge 1 senden (wie bei Einfach-TAN).
Kapitel: BVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
26		Stand: 23.02.2018Kapitel: Verfahrensbeschreibung Abschnitt: Abläufe beim Zwei-Schritt-Verfahren
+ + +Neuer Dialog mit zweitem Benutzer und ggf. anderem konkreten Zwei-Schritt- +Verfahren („Sicherheitsfunktion, kodiert“) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Schritt 2a HKTAN→Auftrags-Hashwert einreichen
wie bei Einfach-TAN nach Prozessvariante 1. Über die Bele- gung ,,Weitere TAN folgt" = ,J" wird signalisiert, dass vor Einrei- chung des Auftrags noch eine weitere Challenge angefordert wird.
Schritt 2b HITAN←Challenge 2 senden wie bei Einfach-TAN
Neuer Dialog mit drittem Benutzer und ggf. anderem konkreten Zwei-Schritt- Verfahren („Sicherheitsfunktion, kodiert“)
Schritt 3a HKTAN→Auftrags-Hashwert einreichen
wie bei Einfach-TAN nach Prozessvariante 1. Über die Bele- gung ,,Weitere TAN folgt" = ,N“ wird signalisiert, dass dies die letzte TAN zu dem eingereichten Auftrag ist.
Schritt 3b HITAN←Challenge 3 senden wie bei Einfach-TAN nach Prozessvariante 1
Schritt 4a z.B. HKCCS→Auftrag einreichen
Zusammen mit dem eigentlichen Geschäftsvorfall, z. B. HKCCS werden die ermittelten PINs und TANs in mehreren Signaturab- schlüssen zum Kreditinstitut übertragen. Nach erfolgreichen TAN-Verifikationen kann der Auftrag verarbeitet werden."
Schritt 4b z. B. HIRMS zu HKCCS←Rückmeldungen senden
Mit der Kreditinstitutsantwort zum Geschäftsvorfall werden die Rückmeldungen zum Auftrag selbst und zur TAN-Verifikation zum Kundenprodukt gesendet.
Über den Rückmeldecode 9910 - „Auftrag abgelehnt - Kompe- tenz nicht ausreichend" wird ggf. signalisiert, dass die für die Ausführung des Auftrags benötigten Berechtigungen nicht aus- reichend sind.
+ + +## B.4.2 Abläufe bei Prozessvariante 2 + +Um einen TAN-pflichtigen Auftrag im Zwei-Schritt-Verfahren über Prozessvariante 2 +einzureichen, müssen die im Folgenden beschriebenen Schritte durchgeführt wer- +den. Dabei gilt die grundlegende Abfolge der Segmente am Beispiel einer Einzel- +überweisung: + +Schritt 1: HKCCS und HKTAN <> HITAN + +Schritt 2: HKTAN <> HITAN und HIRMS zu HKCCS + +Durch die Verschachtelung der beiden Prozessschritte ergibt sich eine Sondersitua- +tion für die Verarbeitung der Rückmeldungen. Hierbei gelten folgende Regelungen: + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: B
Dokument:Security - Sicherheitsverfahren PIN/TAN
Kapitel: Abschnitt:Verfahrensbeschreibung Abläufe beim Zwei-Schritt-VerfahrenStand: 23.02.2018Seite: 27
+ + +• Alle Rückmeldungen in der letzten Antwort beziehen sich auf den Auftrag selbst, +auch die Rückmeldungen auf die ggf. erfolgte TAN-Einreichung mit HKTAN. In +der Antwort können auch explizite Kreditinstitutsantworten, z. B. ,SEPA Dauer- +auftragsbestand rückmelden (HICDB)" enthalten sein. + +· Bei dialogübergreifender Verarbeitung kann nicht auf Bezugssegmente referen- +ziert werden. Daher muss auf Basis der DE ,,Auftragsreferenz“ eine Referenz auf +den eigentlichen Auftrag hergestellt werden. + + +![](figures/27.1) + + +Tritt in Prozessvariante 2 bei der Prüfung im ersten Schritt des ein- +gereichten Auftrags eine ggf. behebbare Fehlersituation auf, so be- +stehen für das Kreditinstitut folgende Reaktionsmöglichkeiten: + +. Falls eine starke Kundenauthentifizierung erforderlich ist: Übermit- +teln einer Warnung (Rückmeldungscode 3xxx) zusammen mit ei- +nem Segment HITAN inklusive einer Challenge. Unterstützt das +Kreditinstitut das Stornieren von Aufträgen (BPD-Parameter „Auf- +tragsstorno erlaubt“=J) kann der Kunde im 2. Schritt den Auftrag +stornieren bzw. trotz der Warnung per TAN freigeben. + +Falls das Kreditinstitut ein Auftragsstorno nicht unterstützt (BPD- +Parameter ,,Auftragsstorno erlaubt“=N) und der Kunde die TAN für +den Auftrag aufgrund der Warnung nicht einreicht, wird vom Kre- +ditinstitut die TAN für diesen Auftrag entwertet. + +· Übermitteln eines Rückmeldungscode 9xxx ohne ein Segment +HITAN. Das Kundenprodukt muss dann den Auftrag verwerfen. +Andere Aufträge derselben Nachricht können jedoch ausgeführt +werden. + +· Beenden des Dialogs mit Rückmeldungscode 9800 ohne Übermitt- +lung eines Segmentes HITAN. Keiner der in der Nachricht enthal- +tenen Aufträge wird ausgeführt. + + +## B.4.2.1Einfach-TAN bei Prozessvariante 2 + +Der vollständige Ablauf sieht bei einem Auftrag mit nur einer benötigten TAN („Ein- +fach-TAN") folgendermaßen aus: + + +### Einfach-TAN bei Prozessvariante 2 + +Ausgangszustand: + +• Die Dialoginitialisierung ist erfolgt; der Benutzer hat dort durch Belegung des +DE ,,Sicherheitsfunktion, kodiert" ein konkretes Zwei-Schritt-Verfahren für sich +gewählt und dadurch die Prozessvariante 2 für den gesamten Ablauf festgelegt. +Im Rahmen der Dialoginitialisierung wurde ggf. bereits eine starke Kun- +denauthentifizierung durchgeführt (vgl. Kapitel B.4.3). + + + + + + + + + + + + + + + + + + +
Schritt 1a z.B. HKCCS,→Auftrag einreichen
Es wird ein TAN-pflichtiger Auftrag in einer FinTS-Nachricht eingereicht. Die Nachricht enthält zusätzlich das Segment HKTAN mit der Belegung gemäß TAN-Prozess=4. Der Sig-
Kapitel: BVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
28		Stand: 23.02.2018Kapitel: Verfahrensbeschreibung
Abschnitt: Abläufe beim Zwei-Schritt-Verfahren
+ + + + + + + + + + + + + + + + + + + + + + + +
HKTANnaturabschluss enthält die PIN des Benutzers aber keine TAN. Als ,,Rolle des Sicherheitslieferanten, kodiert" wird ,,1" für Herausgeber (ISS) verwendet.
Durch eine Prüfung der eingereichten Daten, im Speziellen der Benutzerkennung und der PIN, gegen die PSD2 Aus- nahmen legt das Kreditinstitut fest, wie weiter vorgegangen werden soll:
. starke Kundenauthentifizierung erforderlich, ange- zeigt durch den Rückmeldungscode 0030 Auf- trag empfangen - Sicherheitsfreigabe erforderlich (→weiter mit Schritt 1b)
. der Faktor Wissen ist ausreichend, angezeigt durch den Rückmeldungscode 3076 Keine starke Authentifizierung erforderlich (→weiter mit Schritt 2b, Fall (A)).
Schritt 1b HITAN←Challenge senden
Da die Eingabe einer TAN erforderlich ist, erfolgt eine Zwi- schenspeicherung des Auftrags. Anschließend wird auf In- stitutsseite eine verfahrensspezifische Challenge ermittelt und dem Kundenprodukt im Segment HITAN mitgeteilt. In HITAN erfolgt die Belegung ebenfalls gemäß TAN- Prozess=4. Durch RM-Code 0030 zusammen mit den In- formationen ,,Auftragsreferenz“ und ,,Challenge" aus HITAN erhält das Kundenprodukt in der Kreditinstitutsantwort die Information, dass der Kunde nun auf Basis der Challenge in vereinbarter Form eine TAN ermitteln muss.
Schritt 2a HKTAN→TAN einreichen
Mit dem Geschäftsvorfall HKTAN mit der Belegung gemäß TAN-Prozess=2 wird die ermittelte TAN zusammen mit der Auftragsreferenz zum Kreditinstitut übermittelt. Wie beim Ein-Schritt-Verfahren enthält der Signaturkopf die Benut- zerkennung und der Signaturabschluss PIN und TAN des aktiven Benutzers für diesen Auftrag. Als ,Rolle des Sicher- heitslieferanten, kodiert" wird „1“ für Herausgeber (ISS) verwendet. Über die Belegung ,,Weitere TAN folgt" = ,N" wird signalisiert, dass dies die letzte und einzige TAN zu dem eingereichten Auftrag ist. Nach erfolgreicher TAN- Verifikation kann der Auftrag verarbeitet werden.
Schritt 2b z. B. HIRMS zu HKCCS, HITAN←Rückmeldungen senden
Die Nachricht enthält auch ein Segment HITAN mit TAN- Prozess=2 als Beantwortung des HKTAN. Bei Anwendung einer SCA-Ausnahme ist das Segment HITAN mit FinTS- Füllwerten belegt.
(A) Ohne starke Kundenauthentifizierung:
Mit der Kreditinstitutsantwort werden ggf. erzeugte Antwort- segmente sowie die Rückmeldungen zum Auftrag selbst zum Kundenprodukt gesendet. Die Nachricht enthält auch ein Segment HITAN mit TAN-Prozess=4 als Beantwortung
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: B
Dokument:Security - Sicherheitsverfahren PIN/TAN
Kapitel:VerfahrensbeschreibungStand:Seite:
Abschnitt:Abläufe beim Zwei-Schritt-Verfahren23.02.201829
+ + + + + + + + +
des HKTAN aus Schritt 1a.
Für die Elemente Auftragsreferenz und Challenge sind vom Kreditinstitut die festen FinTS-Füllwerte „noref“ und ,,nochallenge") einzustellen. Diese sind vom Kunden- produkt zu ignorieren.
(B) Bei starker Kundenauthentifizierung:
Mit der Kreditinstitutsantwort werden ggf. erzeugte Antwort- segmente sowie die Rückmeldungen zur TAN-Verifikation und zum Auftrag selbst zum Kundenprodukt gesendet. Die Nachricht enthält auch ein Segment HITAN mit TAN- Prozess=2 als Beantwortung des HKTAN aus Schritt 2a.
+ + +## B.4.2.2Synchrone Eingabe von Mehrfach-TANs in einem Dialog bei Prozessvariante 2 + +Bei Prozessvariante 2 wird die synchrone und zeitversetzte / dialogübergreifende +Eingabe von Mehrfach-TANs unterstützt. Dies wird über den Parameter ,TAN zeit- +versetzt / dialogübergreifend erlaubt" in HITANS gesteuert. + +Bei der synchronen Eingabe von Mehrfach-TANs muss die Eingabe aller TANs zum +Auftrag innerhalb eines FinTS Dialoges erfolgen. + +Bei Verwendung von Mehrfach-TANs gemäß Prozessvariante 2 wird grundsätzlich +eine starke Kundenauthentifizierung gefordert; SCA-Ausnahmen werden nicht un- +terstützt. + +Der entsprechende Ablauf sieht folgendermaßen aus: + +Synchrone Eingabe von Mehrfach-TANs in einem Dialog bei Prozessvarian- +te 2 + +Ausgangszustand: + +. Der Parameter ,,Mehrfach-TAN erlaubt" in HITANS ist mit ,J“ belegt. + +. Der Parameter ,,TAN zeitversetzt / dialogübergreifend erlaubt" in HITANS ist +mit ,,N" belegt. + +• Der Kunde hat die Schritte 1a und 1b wie bei Einfach-TAN bei Prozessvariante +2 durchgeführt + + + + + + + + + + + + + + + + + + + + + + + +
Schritt 2a HKTAN→1. TAN einreichen wie bei Einfach-TAN mit Prozessvariante 2
Über die Belegung „Weitere TAN folgt" = ,J" wird signalisiert, dass dies nicht die letzte TAN zu dem eingereichten Auftrag war und noch mindestens eine weitere TAN nachgereicht wird. Als ,Rolle des Sicherheitslieferanten, kodiert“ wird ,1“ für Heraus- geber (ISS) verwendet.
Schritt 2b HITAN←Rückmeldungen zur 1. TAN senden
Zusammen mit dem Segment HITAN mit der Belegung gemäß TAN-Prozess=2 werden in der Kreditinstitutsantwort die Rück- meldungen zur TAN-Verifikation, nicht aber zum Auftrag selbst zum Kundenprodukt gesendet.
Kapitel: BVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
30		Stand: 23.02.2018Kapitel: Verfahrensbeschreibung
Abschnitt: Abläufe beim Zwei-Schritt-Verfahren
+ + + + + + + + + + + +
Weiterer Benutzer innerhalb des gleichen Dialogs mit ggf. anderem konkreten Zwei-Schritt-Verfahren („Sicherheitsfunktion, kodiert“)
Schritt 3a HKTAN→Challenge anfordern für TAN durch weiteren Benutzer
Mit dem Geschäftsvorfall HKTAN mit der Belegung gemäß TAN-Prozess=3 wird signalisiert, dass das Kundenprodukt eine weitere TAN zu einem bereits eingereichten Auftrag übermitteln möchte.
Dabei enthält ein 1. Signaturkopf die Benutzerkennung des dia- logführenden Benutzers. Als ,Rolle des Sicherheitslieferanten, kodiert“ wird „4“ für Zeuge (WIT) verwendet. Der korrespondie- rende Signaturabschluss enthält die zugehörige PIN des Dialog- führers.
Ein 2. Signaturkopf enthält die Benutzerkennung des weiteren Benutzers, für den die Challenge angefordert werden soll. Als ,Rolle des Sicherheitslieferanten, kodiert“ wird „1“ für Heraus- geber (ISS) verwendet. Der korrespondierende Signaturab- schluss enthält die zugehörige PIN des weiteren Benutzers.
Über die mitgeschickte Auftragsreferenz erfolgt die Zuordnung zu einem im Institut zuvor gespeicherten Auftrag.
+ + + + + + + + + + + + + +
Schritt 3b HITAN←Challenge senden für weitere TAN
Nach Überprüfung der PIN des weiteren Benutzers und Identifi- zieren des zwischengespeicherten Auftrags auf Institutsseite wird eine verfahrensspezifische Challenge ermittelt und dem Kundenprodukt mitgeteilt. Durch Verwenden des Rückmel- dungscode 0030 - „Auftrag empfangen - Sicherheitsfreigabe er- forderlich" zusammen mit den Informationen „Auftragsreferenz“ und ,,Challenge" aus HITAN erhält das Kundenprodukt in der Kreditinstitutsantwort die Information, dass der weitere Benutzer nun auf Basis der Challenge in vereinbarter Form eine TAN er- mitteln muss.
Schritt 4a HKTAN→TAN eines weiteren Benutzers einreichen
Mit dem Geschäftsvorfall HKTAN mit der Belegung gemäß TAN- Prozess=2 wird die ermittelte TAN eines weiteren Benutzers zum Kreditinstitut übertragen.
Dabei enthält ein 1. Signaturkopf wieder die Benutzerkennung des dialogführenden Benutzers. Als ,Rolle des Sicherheitsliefe- ranten, kodiert“ wird „4“ für Zeuge (WIT) verwendet. Der korres- pondierende Signaturabschluss enthält die zugehörige PIN des Dialogführers.
Ein 2. Signaturkopf enthält die Benutzerkennung des weiteren Benutzers, der die TAN einreichen möchte. Als „Rolle des Si- cherheitslieferanten, kodiert" wird ,1" für Herausgeber (ISS) ver- wendet. Der korrespondierende Signaturabschluss enthält die zugehörige PIN und TAN des weiteren Benutzers.
Über die Belegung „Weitere TAN folgt" = ,N" wird signalisiert, dass dies die letzte TAN zu dem eingereichten Auftrag war. An-
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: B
Dokument:Security - Sicherheitsverfahren PIN/TAN
Kapitel:VerfahrensbeschreibungStand:Seite:
Abschnitt:Abläufe beim Zwei-Schritt-Verfahren23.02.201831
+ + + + + + + + + + + + + +
derenfalls werden innerhalb des gleichen Dialogs von einem wei- teren Benutzer die Schritte 3 und 4 in gleicher Weise nochmals durchgeführt.
Schritt 4b z. B. HIRMS zu HKCCS, HITAN←Rückmeldungen senden
Falls keine weitere TAN mehr folgt, werden mit der Kreditinstitut- santwort zum eigentlichen Auftrag ggf. erzeugte Antwortsegmen- te, sowie die Rückmeldungen zum Auftrag selbst und zur TAN- Verifikation zum Kundenprodukt gesendet. Die Nachricht enthält auch ein Segment HITAN mit der Belegung gemäß TAN- Prozess=2 als Beantwortung des HKTAN.
+ + +## B.4.2.3Zeitversetzte, dialogübergreifende Eingabe von Mehrfach-TANs bei Prozessva- riante 2 + +Bereits beim etablierten Ein-Schritt-TAN-Verfahren ist die Verwendung von Mehr- +fach-TANs möglich. Diese müssen dort in einem Schritt zusammen mit dem Auftrag +eingereicht werden. + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
32		Stand: 23.02.2018Kapitel: Verfahrensbeschreibung
Abschnitt: Abläufe beim Zwei-Schritt-Verfahren
+ + +Beim Zwei-Schritt-TAN-Verfahren wird die Verwendung von Mehrfach-TANs optio- +nal in gleicher Weise unterstützt. Bei Prozessvariante 2 wird zusätzlich zur synchro- +nen Eingabe innerhalb eines Dialoges auch die asynchrone Eingabe von Mehrfach- +TANs unterstützt. Der Parameter ,TAN zeitversetzt / dialogübergreifend erlaubt" in +HITANS muss hierfür mit „J“ belegt werden. + +Dabei besteht aufgrund des komplexen Zeitverhaltens (vgl. Kapitel B.4.4.1 und +B.4.4.2.1) die Möglichkeit, die Auftrags-Einreichung mit der Eingabe der ersten TAN +von der Eingabe weiterer TANs zeitlich zu trennen. Mit dieser optionalen Möglichkeit +kann ein Einreicher einen Auftrag zusammen mit seiner PIN und TAN übermitteln – +weitere TANs anderer Berechtigter werden in separaten Prozessen in eigenen +FinTS-Dialogen nachgereicht. + +Bei Verwendung von Mehrfach-TANs gemäß Prozessvariante 2 wird grundsätzlich +eine starke Kundenauthentifizierung gefordert; SCA-Ausnahmen werden nicht un- +terstützt. + +Der entsprechend erweiterte Ablauf sieht folgendermaßen aus: + + +### Zeitversetzte, dialogübergreifende Eingabe von Mehrfach-TANs bei Pro- zessvariante 2 + +Ausgangszustand: + +. Der Parameter ,,Mehrfach-TAN erlaubt" in HITANS ist mit ,,J" belegt. + +. Der Parameter ,TAN zeitversetzt / dialogübergreifend erlaubt" in HITANS ist +mit ,,J“ belegt. + +· Der Kunde hat die Schritte 1a und 1b wie bei Einfach-TAN mit Prozessvariante +2 durchgeführt + + + + + + + + + + + + + +
Schritt 2a HKTAN→1. TAN einreichen wie bei Einfach-TAN mit Prozessvariante 2
Über die Belegung „Weitere TAN folgt" = ,J" wird signalisiert, dass dies nicht die letzte TAN zu dem eingereichten Auftrag war und noch mindestens eine weitere TAN nachgereicht wird.
Schritt 2b HITAN←Rückmeldungen zur 1. TAN senden
Zusammen mit dem Segment HITAN mit der Belegung gemäß TAN-Prozess=2 werden in der Kreditinstitutsantwort die Rück- meldungen zur TAN-Verifikation, nicht aber zum Auftrag selbst zum Kundenprodukt gesendet.
+ + +Neuer Dialog mit weiterem Benutzer, zeitversetzt und ggf. anderem konkreten +Zwei-Schritt-Verfahren (,Sicherheitsfunktion, kodiert") aber gleicher Prozessvari- +ante + + + + + + + + +
Schritt 3a HKTAN→Challenge anfordern für weitere TAN
Mit dem Geschäftsvorfall HKTAN mit Belegung gemäß TAN- Prozess=3 wird signalisiert, dass das Kundenprodukt eine wei- tere TAN zu einem bereits eingereichten Auftrag übermitteln möchte. Dabei enthält der Signaturkopf die Benutzerkennung und der Signaturabschluss die PIN des weiteren Benutzers. Über die mitgeschickte Auftragsreferenz erfolgt die Zuordnung zu einem im Institut zuvor gespeicherten Auftrag.
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: B
Dokument:Security - Sicherheitsverfahren PIN/TAN
Kapitel:VerfahrensbeschreibungStand:Seite:
Abschnitt:Abläufe beim Zwei-Schritt-Verfahren23.02.201833
+ + + + + + + + + + + + + + + + + + +
Schritt 3b HITAN←Challenge senden für weitere TAN
Nach Überprüfung der PIN des neuen Benutzers und Identifizie- ren des zwischengespeicherten Auftrags auf Institutsseite wird eine verfahrensspezifische Challenge ermittelt und dem Kun- denprodukt mitgeteilt. Durch Verwenden des Rückmeldungs- code 0030 - ,,Auftrag empfangen - Sicherheitsfreigabe erforder- lich" zusammen mit den Informationen „Auftragsreferenz“ und „Challenge“ aus HITAN erhält das Kundenprodukt in der Kredit- institutsantwort die Information, dass der Kunde nun auf Basis der Challenge in vereinbarter Form eine TAN ermitteln muss.
Schritt 4a HKTAN→weitere TAN einreichen
Mit dem Geschäftsvorfall HKTAN in der Belegung gemäß TAN- Prozess=2 wird die ermittelte weitere TAN zum Kreditinstitut übertragen.
Über die Belegung „Weitere TAN folgt" = ,N" wird signalisiert, dass dies die letzte TAN zu dem eingereichten Auftrag war. An- derenfalls werden zu einem späteren Zeitpunkt von einem wei- teren Benutzer die Schritte 3 und 4 in gleicher Weise nochmals durchgeführt.
Schritt 4b z. B. HIRMS zu HKCCS, HITAN←Rückmeldungen senden
Falls keine weitere TAN mehr folgt, werden mit der Kreditinsti- tutsantwort zum eigentlichen Auftrag ggf. erzeugte Antwortseg- mente, sowie die Rückmeldungen zum Auftrag selbst und zur TAN-Verifikation zum Kundenprodukt gesendet. Die Nachricht enthält auch ein Segment HITAN in der Belegung gemäß TAN- Prozess=2 als Beantwortung des HKTAN.
+ + +## B.4.3 Abläufe bei der Initialisierung mit starker Kundenauthentifizierung + +Durch [MaSI] und [PSD2] besteht die Forderung nach einer starken Kundenauthen- +tifizierung u. a. beim Zugriff auf Kontendaten, also auch zum Zeitpunkt der FinTS- +Dialoginitialisierung. Hierfür wurden Abläufe geschaffen, die eine Umsetzung der +starken Kundenauthentifizierung bei TAN-Verfahren ermöglichen. + +Hierzu wird in die Segmentfolge der Dialoginitialisierung durch das Kundenprodukt +unmittelbar nach dem Segment Verarbeitungsvorbereitung (HKVVB) ein +HKTAN-Segment mindestens der Segmentversion #6 eingestellt. + + +Damit ergibt sich für die Dialoginitialisierung bei starker Authentifizierung folgende +Segmentfolge: + +![HNHBK Nachrichtenkopf / -abschluss HNHBS HNSHK Signaturkopf / -abschluss HNSHA PIN HKIDN HKVVB HKTAN TP=4](figures/33.1) + + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
34		Stand: 23.02.2018Kapitel: Verfahrensbeschreibung
Abschnitt: Abläufe beim Zwei-Schritt-Verfahren
+ + +## B.4.3.1Rahmenbedingungen für den Einsatz der starken Kundenauthentifizierung + +· Voraussetzung für die Verwendung der starken Kundenauthentifizierung ist, +dass ein Kundenprodukt bereits vor der Dialoginitialisierung die Sicherheits- +verfahren und Parameter kennt. Daher muss ein Kreditinstitut das Abholen +der BPD über einen anonymen Dialog zulassen, wenn es starke Authentifi- +zierung verwenden möchte. + +· Sind dem Kundenprodukt die konkreten, für den Benutzer zugelassenen Si- +cherheitsverfahren nicht bekannt, so können diese über eine Dialoginitialisie- +rung mit Sicherheitsfunktion=999 angefordert werden. Die konkreten +Verfahren werden dann über den Rückmeldungscode=3920 zurückgemel- +det. Im Rahmen dieses Prozesses darf keine UPD zurückgeliefert werden +und die Durchführung anderer Geschäftsvorfälle ist in einem solchen Dialog +nicht erlaubt. + +· Bei Einsatz der Prozessvariante 1 wird auf die Verwendung des Elements +Auftrags-Hashwert verzichtet, da die relevanten Daten sich bereits in der +Dialoginitialisierungsnachricht befinden. Da der Auftrags-Hashwert bei Pro- +zessvariante 1 belegt werden muss, wird ein FinTS-Füllwert verwendet, der +von der Gegenseite nicht geprüft wird. Dies gilt auch bei Verwendung von +PIN/TAN-Management-Geschäftsvorfällen. + +· Basis für eine starke Authentifizierung ist die Verwendung des HKTAN ab der +Segmentversion #6. Ab dieser Segmentversion ist es möglich, ein HKTAN- +Segment in die Segmentfolge der Dialoginitialisierung zu integrieren. + +. Bei Verwendung von chipTAN ist bei HHD V1.3.2 die Challenge-Klasse 02 +(Anmelde-TAN) zu verwenden. Bei HHD V1.4 gilt die Schablone 01 bzw. 02 +(Legitimation Kunde mit einem Authentifizierungsmerkmal). Die Aus- +wahl der Schablone 01 bzw. 02 wird durch das Kreditinstitut getroffen und ist +Inhalt des Start-Code im Schritt 2a in den Abläufen. Das Authentifizie- +rungsmerkmal wird durch das Kreditinstitut festgelegt und mit dem Benut- +zer vereinbart. Bei Prozessvariante 1 ist das Element Challengeklasse +des HKTAN mit dem festen FinTS-Füllwert 99 zu belegen, der im Kreditinsti- +tut ignoriert wird. Das Element Challenge-Parameter bleibt leer. + +· Nach Bestätigung der eingereichten TAN mit HITAN ab #6 findet ein stan- +dardmäßiger FinTS-Dialog statt, in dem TAN-pflichtige und nicht-TAN- +pflichtige Aufträge ausgeführt werden können. Der Dialog muss durch das +Kundenprodukt mit einer Dialogendenachricht (HKEND) geschlossen werden. + +• Migration: Durch die Unterstützung des HKTAN ab Segmentversion #6 in den +BPD signalisiert das Kreditinstitut die Fähigkeit zur Durchführung einer star- +ken Kundenauthentifizierung. Enthält die Segmentfolge der Dialoginitialisie- +rung kein HKTAN-Segment, so handelt es sich um eine schwache Authenti- +fizierung. Diese kann - solange zulässig - parallel zur starken Kun- +denauthentifizierung unterstützt werden. Durch Verwendung des Rückmel- +dungscode 3075 ,,Starke Authentifizierung ab dem ... erfor- +derlich" kann ein Benutzer auf den Wegfall der schwachen Authentifizie- +rung hingewiesen werden. Nach Ablauf dieser Frist kann eine Dialoginitiali- +sierung ohne starke Kundenauthentifizierung durch den Rückmeldungscode +9075 „Starke Authentifizierung erforderlich" abgewiesen +werden. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: B
Dokument:Security - Sicherheitsverfahren PIN/TAN
Kapitel: Abschnitt:Verfahrensbeschreibung Abläufe beim Zwei-Schritt-VerfahrenStand: 23.02.2018Seite: 35
+ + +. Auch im Rahmen einer Eroffnung eines anonymen Dialogs muss ein Kun- +denprodukt, das die starke Kundenauthentifizierung unterstützt, in die Dia- +loginitialisierungsnachricht ein Segment HKTAN ab Segmentversion #6 ein- +stellen. Auf diese Weise ist eine Signalisierung der SCA-Fähigkeit möglich +und dem Kundensystem können in der Antwort bei Bedarf geeignete BPD +übermittelt werden, wenn das Kreditinstitut dies unterstützt. + + +![](figures/35.1) + + +![](figures/35.2) + + +Unterstützt ein Kreditinstitut die starke Kundenauthentifizierung +mithilfe von HKTAN ab #6, so sollte ein Kundenprodukt in die +Segmentfolge der Dialoginitialisierung grundlegend ein HKTAN- +Segment ab #6 einstellen, um ggf. einen Rückmeldungscode 3075 +bzw. 9075 zu vermeiden. + +Das Kreditinstitut muss anhand der in den PSD2 Regularien be- +schriebenen Ausnahmen festlegen, ob eine starke Kundenauthen- +tifizierung nötig ist (nur dann erfolgt der nächste Schritt des Zwei- +Schritt-Verfahrens) oder ob die Dialoginitialisierung in der Antwort- +nachricht unmittelbar beantwortet werden kann. + +Das Kundenprodukt steuert also nicht, ob es sich um eine starke +oder schwache Authentifizierung handelt. + +Im Rahmen der PIN/TAN-Management-Geschäftsvorfälle (vgl. Kapitel C.3) ist in be- +stimmten Situationen eine Einreichung ohne starke Kundenauthentifizierung erfor- +derlich (Authentifizierungsklasse 4, vgl. Kapitel B.3). Daher wird in einem solchen +Fall das Element Segmentkennung in HKTAN ab #6 mit der Segmentkennung des +jeweiligen Geschäftsvorfalls belegt, der dann isoliert in diesem Dialog eingereicht +wird. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
BezeichnungSegmentkennung
PIN-ÄnderungHKPAE
PIN-Sperre aufhebenHKPSA
PIN SperrenHKPSP
Anzeige der verfügbaren TAN-MedienHKTAB
TAN-Generator an- bzw. ummeldenHKTAU
TAN-Generator SynchronisierungHKTSY
Mobilfunkverbindung registrierenHKMTR / HKMTS
Mobilfunkverbindung freischaltenHKMTF
Mobilfunkverbindung ändernHKMTA
Deaktivieren / Löschen von TAN-MedienHKTML
+ + +In den nächsten Abschnitten sind die Rahmenbedingungen für repräsentative Pro- +zesse solcher PIN/TAN-Management Geschäftsvorfälle beschrieben. + + +## B.4.3.1.1 Rahmenbedingungen bei Erst-PIN-Änderung (HKPAE) + +Die folgenden Schritte gelten für die Einreichung einer Erst-PIN-Änderung, die +ohne starke Kundenauthentifizierung erfolgt. Ggf. wurde ein zuvor durchgeführ- +ter Anmeldeversuch durch einen Rückmeldungscode 3916 (z. B. ,PIN muss +wegen erstmaliger Anmeldung zwangsweise geändert werden“) beantwortet. + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
36		Stand: 23.02.2018Kapitel: Verfahrensbeschreibung
Abschnitt: Abläufe beim Zwei-Schritt-Verfahren
+ + +. Erster Dialog - Ermitteln TAN-Verfahren + +○ Zunächst wird ein Dialog mit der Signaturfunktion=999 (Ein- +Schritt-Verfahren) ohne integriertes HKTAN-Segment eröffnet. + +○ Die Dialoginitialisierungsantwort enthält über den Rückmeldungscode +3920 die für den Benutzer zugelassenen TAN-Verfahren. Die Ant- +wort darf keine UPD enthalten, da noch keine starke Kundenauthenti- +fizierung vorliegt. + +o Anschließend hat das Kundensystem den Dialog durch Senden einer +Dialogendenachricht (HKEND) zu beenden. + +• Zweiter Dialog – PIN-Einreichung und Authentifizierung durch eine TAN2 + +o Anschließend wird in Prozessvariante 1 bzw. 2 (vgl. hierzu die Abläu- +fe in Kapitel B.4.3.2 bzw. B.4.3.3) unter Verwendung eines zugelas- +senen TAN-Verfahrens (diese wurden im ersten Dialog mit Rückmel- +dungscode 3920 zurück gemeldet) ein zweiter Dialog mit integrier- +tem HKTAN-Segment eröffnet, um die PIN-Änderung durchzuführen. +Das Datenelement Segmentkennung in HKTAN wird mit dem Wert +HKPAE belegt, um zu signalisieren, dass es sich um eine PIN- +Änderung handelt. + +○ Hinweis: Ist die zur Durchführung des TAN-Prozesses benötigte Be- +zeichnung des TAN-Mediums noch nicht bekannt, so muss zuvor +der hierfür vorgesehene Ablauf (vgl. Abschnitt B.4.3.1.3) in einem +separaten Dialog durchgeführt werden. Erst dann kann der Dialog mit +der PIN-Änderung erfolgen. + +o Nach erfolgter Dialoginitialisierungsantwort wird in einem nächsten +Schritt durch das Kundensystem der Geschäftsvorfall PIN Ändern +(HKPAE) eingereicht. + +o Das Institut muss in der Antwort durch den Rückmeldungscode 0030 +eine TAN zur Authentifizierung anfordern. Nach Eingabe der TAN +durch den Benutzer wird diese durch das Kundensystem eingereicht. + +○ Unmittelbar nach Bestätigung der eingereichten TAN muss der Dia- +log durch das Kundensystem mit einer Dialogendenachricht (HKEND) +geschlossen werden. Um Auftragsnachrichten zu schicken, kann das +Kundenprodukt anschließend eine neue Dialoginitialisierung mit inte- +griertem HKTAN-Segment für diesen Benutzer senden. + + +### B.4.3.1.2 Rahmenbedingungen bei Zwangs-PIN-Änderung (HKPAE) + +Die folgenden Schritte gelten für die Einreichung einer Zwangs-PIN-Änderung. + +· Erster Dialog – Auslöser: Dialog mit fehlerhafter PIN + +○ Auslöser ist ein Dialog mit wiederholt eingegebener fehlerhafter PIN. +Das verwendete Sicherheitsverfahren ist dafür unerheblich. + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: B
Dokument:Security - Sicherheitsverfahren PIN/TAN
Kapitel:
Abschnitt:		Verfahrensbeschreibung Abläufe beim Zwei-Schritt-VerfahrenStand: 23.02.2018Seite: 37
+ + +o Das Institut antwortet in diesem Fall mit einem Rückmeldungscode +3916 (z. B. ,PIN muss wegen zu vieler Fehlversuche zwangsweise +geändert werden“). Es wird davon ausgegangen, dass dem Kunden- +system die für den Benutzer zugelassenen TAN-Verfahren bekannt +sind bzw. diese der Kreditinstitutsantwort (Rückmeldungscode 3920) +entnommen werden. Die Antwort darf keine UPD enthalten, da durch +Fehlen des Wissenselementes keine starke Kundenauthentifizierung +vorliegt. + +o Anschließend hat das Kundensystem den Dialog durch Senden einer +Dialogendenachricht (HKEND) zu beenden. + +· Zweiter Dialog – PIN-Änderung und Authentifizierung durch eine TAN3 + +o Anschließend wird in Prozessvariante 1 bzw. 2 (vgl. hierzu die Abläu- +fe in Kapitel B.4.3.2 bzw. B.4.3.3) unter Verwendung eines zugelas- +senen TAN-Verfahrens ein zweiter Dialog mit integriertem HKTAN- +Segment eröffnet, um die PIN-Änderung durchzuführen. Das Daten- +element Segmentkennung in HKTAN wird mit dem Wert HKPAE be- +legt, um zu signalisieren, dass es sich um eine PIN-Änderung han- +delt. + +○ Hinweis: Ist die zur Durchführung des TAN-Prozesses benötigte Be- +zeichnung des TAN-Mediums noch nicht bekannt, so muss zuvor +der hierfür vorgesehene Ablauf (vgl. Abschnitt B.4.3.1.3) in einem +separaten Dialog durchgeführt werden. Erst dann kann der Dialog mit +der PIN-Änderung durchgeführt werden. + +o Nach erfolgter Dialoginitialisierungsantwort wird in einem nächsten +Schritt durch das Kundensystem der Geschäftsvorfall PIN Ändern +(HKPAE) eingereicht. + +o Das Institut muss in der Antwort durch den Rückmeldungscode 0030 +eine TAN zur Authentifizierung anfordern. Nach Eingabe der TAN +durch den Benutzer wird diese durch das Kundensystem eingereicht. + +○ Unmittelbar nach Bestätigung der eingereichten TAN muss der Dia- +log durch das Kundensystem mit einer Dialogendenachricht (HKEND) +geschlossen werden. Um Auftragsnachrichten zu schicken, kann das +Kundenprodukt anschließend eine neue Dialoginitialisierung mit inte- +griertem HKTAN-Segment für diesen Benutzer senden. + + +## B.4.3.1.3 Rahmenbedingungen zur Ermittlung möglicher TAN-Medien-Kennungen (HKTAB) + +Beim Erstzugang mit einem neuen TAN-Verfahren liegt einem Kundenprodukt +ggf. noch keine TAN-Medien-Bezeichnung für dieses Verfahren vor. In diesem +Fall muss der Geschäftsvorfall Anzeige der verfügbaren TAN-Medien +(HKTAB) ohne starke Kundenauthentifizierung durchführbar sein. Dies ist bei +der Prüfung der Kriterien im Kreditinstitut zu berücksichtigen. + +. Erster Dialog - Ermitteln der TAN-Medien-Bezeichnung + + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
38		Stand: 23.02.2018Kapitel: Verfahrensbeschreibung
Abschnitt: Abläufe beim Zwei-Schritt-Verfahren
+ + +o Es wird eine Dialoginitialisierung in Prozessvariante 1 bzw. 2 durch- +geführt (vgl. hierzu die Abläufe in Kapitel B.4.3.2 bzw. B.4.3.3). In das +DE Segmentkennung in HKTAN wird der Wert HKTAB eingestellt. +Der vom Kundenprodukt hier als Füllwert gelieferte Inhalt des +Elementes Bezeichnung des TAN-Mediums in HKTAN ist vom +Kreditinstitut in dieser Situation zu ignorieren. + +o Das Kreditinstitut liefert nach erfolgreicher PIN-Prüfung in HITAB die +für den Benutzer eingereichten TAN-Medien und mit dem Rückmel- +dungscode 3920 die zugelassenen TAN-Verfahren für den Benutzer +zurück (falls diese dem Kundensystem noch nicht bekannt waren) + +o Anschließend hat das Kundensystem den Dialog durch Senden einer +Dialogendenachricht (HKEND) zu beenden. + +• Zweiter Dialog - Starke Kundenauthentifizierung + +o Nun wird unter Verwendung eines zugelassenen TAN-Verfahrens +und TAN-Mediums ein zweiter Dialog zum Durchführen einer starken +Kundenauthentifizierung eröffnet. Die SCA ist obligatorisch, da es +sich um die erste Nutzung dieses TAN-Verfahrens inkl. des gewähl- +ten TAN-Mediums handelt. + +o Im Rahmen dieses Dialoges können nach erfolgreicher Durchführung +der starken Kundenauthentifizierung beliebige Geschäftsvorfälle +durchgeführt werden. + + +## B.4.3.1.4 Rahmenbedingungen zur Synchronisation von TAN-Generatoren (HKTSY) + +Bei mehrfacher Eingabe einer falschen TAN wird bei chipTAN zunächst davon +ausgegangen, dass der TAN-Generator nicht synchronisiert ist, bevor eine TAN- +Sperre gesetzt wird. In diesem Fall muss für den Benutzer der nicht-TAN- +pflichtige Geschäftsvorfall TAN-Generator synchronisieren (HKTSY) +ohne starke Kundenauthentifizierung durchführbar sein, um eine TAN mit dem +zugehörigen aktuellen ATC einzureichen. Dies ist bei der Prüfung der Kriterien +im Kreditinstitut zu berücksichtigen. + +· Es wird eine Dialoginitialisierung in Prozessvariante 1 bzw. 2 durchgeführt +(vgl. hierzu die Abläufe in Kapitel B.4.3.2 bzw. B.4.3.3). Als Segmentken- +nung in HKTAN wird der Wert HKTSY eingestellt. + +. Das Kreditinstitut fordert nach erfolgreicher PIN-Prüfung den Benutzer mit +dem Rückmeldungscode 3931 auf, den Geschäftsvorfall HKTSY für eine ex- +plizite Synchronisation des TAN-Generators auszuführen. + +. Unmittelbar nach erfolgreicher Verifizierung von TAN und ATC muss der +Dialog durch das Kundenprodukt durch eine Dialogendenachricht (HKEND) +geschlossen werden. + + +## B.4.3.2Initialisierung bei Prozessvariante 1 + +Der vollständige Ablauf sieht bei einer Initialisierung nach Prozessvariante 1 fol- +gendermaßen aus: + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: B
Dokument:Security - Sicherheitsverfahren PIN/TAN
Kapitel:VerfahrensbeschreibungStand:Seite:
Abschnitt:Abläufe beim Zwei-Schritt-Verfahren23.02.201839
+ + +## Initialisierung bei Prozessvariante 1 + +Ausgangszustand: + +. Vor dem allerersten Dialog mit dem Kreditinstitut bzw. falls die Informationen +nicht vorliegen: Das Kundenprodukt hat über einen anonymen Dialog die aktu- +ellen BPD abgeholt und ist somit in Kenntnis aller vom Kreditinstitut unterstütz- +ten Sicherheitsverfahren und Parameter. + +. Vor dem allerersten Dialog mit dem Kreditinstitut bzw. falls die Informationen +nicht vorliegen: Mit der Durchführung eines personalisierten Dialogs mit der +Sicherheitsfunktion 999 erhält das Kundenprodukt mit dem Rückmeldungs- +code 3920 alle für den Benutzer zugelassenen Ein- und Zwei-Schritt- +Verfahren mitgeteilt. Eine UPD liegt zu diesem Zeitpunkt noch nicht vor. Dieser +Dialog wird durch das Kundensystem mit einer Dialogendenachricht (HKEND) +beendet. + +· Der Benutzer wählt durch entsprechende Belegung des DE Sicherheits- +funktion, kodiert ein konkretes Zwei-Schritt-Verfahren für den gesamten +zweiten Dialog. + +. Der Benutzer hat das Auftrags-Hashwertverfahren=1 (RIPEMD-160) +gewählt. Dies gilt für nachfolgende TAN-pflichtige Auftragsnachrichten, nicht +für die Dialoginitialisierung. + + + + + + + + + + + + + + + + + + + + + + + +
Schritt 1a HKIDN, HKVVB, HKTAN→Initialisierung starten
Es wird die Segmentfolge der Dialoginitialisierung eingereicht. Es wird der Geschäftsvorfall ab HKTAN#6 unmittelbar nach HKVVB mit der Belegung gemäß TAN-Prozess=1eingestellt. Das Element Auftrags-Hashwert ist mit dem FinTS-Füllwert binär '00000000' zu belegen. Das Datenelement Segmentken- nung des HKTAN enthält den Wert HKIDN zur Kennzeichnung, dass es sich um eine starke Authentifizierung handelt. Ggf. kann das DE Segmentkennung des HKTAN auch die Segment- kennung eines PIN/TAN-Management-Geschäftsvorfalls enthal- ten. Über die Belegung Weitere TAN folgt = N wird signa- lisiert, dass dies die einzige TAN ist.
Durch eine Prüfung der eingereichten Daten, im Speziellen der Benutzerkennung und der PIN, gegen die PSD2 Ausnahmen legt das Kreditinstitut fest, wie weiter vorgegangen werden soll:
· starke Kundenauthentifizierung erforderlich, angezeigt durch den Rückmeldungscode 0030 Auftrag emp- fangen - Sicherheitsfreigabe erforderlich (→weiter mit Schritt 1b)
. der Faktor Wissen ist ausreichend, angezeigt durch den Rückmeldungscode 3076 Keine starke Authen- tifizierung erforderlich (→weiter mit Schritt 2b, Fall (A)).
Schritt 1b HITAN←Challenge senden
Es wird eine verfahrensspezifische Challenge ermittelt und dem Kundenprodukt in HITAN mitgeteilt. Durch den RM-Code 0030 zusammen mit den Elementen Auftrags-Hashwert (fester
Kapitel: BVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite: 40Stand: 23.02.2018Kapitel: Verfahrensbeschreibung
Abschnitt: Abläufe beim Zwei-Schritt-Verfahren
+ + + + + + + + + + + + + + + + + + +
FinTS-Füllwert = binär '00000000') und Challenge aus HITAN erhält das Kundenprodukt in der Kreditinstitutsantwort die In- formation, dass der Kunde nun auf Basis der Challenge in ver- einbarter Form eine Anmelde-TAN ermitteln muss.
Schritt 2a HKTAN→Anmelde-TAN einreichen
Zusammen mit dem eigentlichen Geschäftsvorfall, in diesem Fall HKTAN mit Belegung gemäß TAN-Prozess=1, wird die er- mittelte TAN (im Signaturabschluss) zum Kreditinstitut übertra- gen. Nach erfolgreicher TAN-Verifikation kann die erfolgreiche Prüfung auf starke Kundenauthentifizierung bestätigt werden.
Schritt 2b HITAN, ggf. HIBPD, HIUPD, HIRMS←BPD, UPD und Rückmeldungen senden (A) Ohne starke Kundenauthentifizierung:
Mit der Kreditinstitutsantwort werden ggf. erzeugte BPD und UPD, sowie die Rückmeldungen zum Kundenprodukt gesendet. Die Nachricht enthält auch ein Segment HITAN mit TAN- Prozess=1 als Beantwortung des HKTAN.
(B) Bei starker Kundenauthentifizierung
Mit der Kreditinstitutsantwort werden ggf. erzeugte BPD und UPD, sowie die Rückmeldungen zur PIN-Prüfung und zur TAN- Verifikation zum Kundenprodukt gesendet. Die Nachricht enthält auch ein Segment HITAN mit TAN-Prozess=1 als Beantwortung des HKTAN.
+ + +## B.4.3.3Initialisierung bei Prozessvariante 2 + +Der vollständige Ablauf sieht bei einer Initialisierung nach Prozessvariante 2 folgen- +dermaßen aus: + + +### Initialisierung bei Prozessvariante 2 + +Ausgangszustand: + +. Vor dem allerersten Dialog mit dem Kreditinstitut bzw. falls die Informationen +nicht vorliegen: Das Kundenprodukt hat über einen anonymen Dialog die aktu- +ellen BPD abgeholt und ist somit in Kenntnis aller vom Kreditinstitut unterstütz- +ten Sicherheitsverfahren und Parameter. + +. Vor dem allerersten Dialog mit dem Kreditinstitut bzw. falls die Informationen +nicht vorliegen: Mit der Durchführung eines personalisierten Dialogs mit der +Sicherheitsfunktion 999 erhält das Kundenprodukt mit dem Rückmeldungs- +code 3920 alle für den Benutzer zugelassenen Ein- und Zwei-Schritt- +Verfahren mitgeteilt. Eine UPD liegt zu diesem Zeitpunkt noch nicht vor. Dieser +Dialog wird durch das Kundensystem mit einer Dialogendenachricht (HKEND) +beendet. + +· Der Benutzer wählt durch entsprechende Belegung des DE Sicherheits- +funktion, kodiert ein konkretes Zwei-Schritt-Verfahren für den gesamten +zweiten Dialog und legt die Prozessvariante 2 für den gesamten Ablauf fest. + + + + + + + + +
Schritt 1a HKIDN, HKVVB,→Initialisierung starten Es wird die Segmentfolge der Dialoginitialisierung eingereicht. Die Nachricht enthält unmittelbar nach HKVVB zusätzlich das
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: B
Dokument:Security - Sicherheitsverfahren PIN/TAN
Kapitel:VerfahrensbeschreibungStand:Seite:
Abschnitt:Abläufe beim Zwei-Schritt-Verfahren23.02.201841
+ + + + + + + + + + + + + + + + + + + + + + + +
HKTANSegment ab HKTAN#6 mit der Belegung gemäß TAN- Prozess=4. Das Datenelement Segmentkennung in HKTAN enthält den Wert HKIDN zur Kennzeichnung, dass es sich um eine starke Kundenauthentifizierung handelt. Ggf. kann das DE Segmentkennung des HKTAN auch die Segmentkennung eines PIN/TAN-Management-Geschäftsvorfalls enthalten. Der Signa- turabschluss enthält die PIN des Benutzers aber keine TAN.
Durch eine Prüfung der eingereichten Daten, im Speziellen der Benutzerkennung und der PIN, gegen die PSD2 Ausnahmen legt das Kreditinstitut fest, wie weiter vorgegangen werden soll:
. starke Kundenauthentifizierung erforderlich, angezeigt durch den Rückmeldungscode 0030 Auftrag emp- fangen - Sicherheitsfreigabe erforderlich (→weiter mit Schritt 1b)
. der Faktor Wissen ist ausreichend, angezeigt durch den Rückmeldungscode 3076 Keine starke Authen- tifizierung erforderlich (→weiter mit Schritt 2b, Fall (A)).
Schritt 1b HITAN←Challenge senden
Es wird eine verfahrensspezifische Challenge für eine Anmelde- TAN ermittelt und dem Kundenprodukt im Segment HITAN mit- geteilt. In HITAN erfolgt die Belegung ebenfalls gemäß TAN- Prozess=4. Durch den RM-Code 0030 _zusammen mit den In- formationen Auftragsreferenz und Challenge aus HITAN erhält das Kundenprodukt in der Kreditinstitutsantwort die In- formation, dass der Kunde nun auf Basis der Challenge in ver- einbarter Form einer Anmelde-TAN ermitteln muss.
Schritt 2a HKTAN→TAN einreichen
Mit dem Geschäftsvorfall HKTAN mit der Belegung gemäß TAN- Prozess=2 wird die ermittelte TAN zusammen mit der Auf- tragsreferenz zum Kreditinstitut übermittelt. Wie beim Ein- Schritt-Verfahren enthält der Signaturkopf die Benutzerkennung und der Signaturabschluss PIN und TAN des aktiven Benutzers für diese Anmeldung. Als Rolle des Sicherheitsliefe- ranten, kodiert wird „1“ für Herausgeber (ISS) verwendet. Über die Belegung Weitere TAN folgt = N wird signali- siert, dass dies die einzige TAN zu dem eingereichten Auftrag ist. Nach erfolgreicher TAN-Verifikation kann die erfolgreiche Prüfung auf starke Kundenauthentifizierung bestätigt werden.
Schritt 2b z. B. HIRMS, HIBPD, HIUPD HITAN←BPD, UPD und Rückmeldungen senden
(A) Ohne starke Kundenauthentifizierung:
Mit der Kreditinstitutsantwort werden ggf. erzeugte BPD und UPD, sowie die Rückmeldungen zur Dialoginitialisierung _zum Kundenprodukt gesendet. Die Nachricht enthält auch ein Seg- ment HITAN mit TAN-Prozess=4 als Beantwortung des HKTAN aus Schritt 1a.
Für die Elemente Auftragsreferenz und Challenge sind
+ + +| + + + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
42		Stand: 23.02.2018Kapitel: Verfahrensbeschreibung
Abschnitt: Abläufe beim Zwei-Schritt-Verfahren
+ + + + + + + + +
vom Kreditinstitut die festen FinTS-Füllwerte ,,noref“ und ,nochallenge“ einzustellen. Diese sind vom Kundenprodukt zu ignorieren.
(B) Bei starker Kundenauthentifizierung:
Mit der Kreditinstitutsantwort werden ggf. erzeugte BPD und UPD, sowie die Rückmeldungen zur TAN-Verifikation und zur Dialoginitialisierung selbst zum Kundenprodukt gesendet. Die Nachricht enthält auch ein Segment HITAN mit TAN-Prozess=2 als Beantwortung des HKTAN aus Schritt 2a.
+ + +## B.4.4 Allgemeine Festlegungen zum Zeitverhalten beim Zwei-Schritt-Verfahren + +Bei Verwendung des Zwei-Schritt-Verfahrens wird auf Institutsseite das Zeitfenster +zwischen den beiden Prozess-Schritten überwacht, um nicht freigegebene Aufträge +nach Ablauf der Gültigkeit entsprechend kennzeichnen und die zugehörige TAN +entwerten zu können. Das Zeitfenster selbst hängt von der Implementierung auf In- +stitutsseite ab. Auch bei der Verarbeitung von synchronen bzw. zeitversetzten Mehr- +fach-TANs ergibt sich unterschiedliches Zeitverhalten, wie in den folgenden Ab- +schnitten beschrieben. + + +![](figures/42.1) + + +Das Zeitfenster für die Eingabe einer TAN im Zwei-Schritt-Verfahren +wird institutsindividuell geregelt, muss dem Kunden aber genügend +Zeit für die Eingabe der TAN lassen und sollte daher einen Wert von +8 Minuten nicht unterschreiten. + +Ein oberes Limit wird nur durch die Aufbewahrungsdauer offener +Aufträge im Institut festgelegt. + +Um dem Kundenprodukt eine übersichtliche Benutzerführung zu +ermöglichen kann die DEG „Gültigkeitsdatum und –uhrzeit für Chal- +lenge" belegt werden (vgl. Kapitel B.5) + + +## B.4.4.1Verteilung von Aufträgen auf FinTS-Nachrichten + +Es können TAN-pflichtige und nicht-TAN-pflichtige Aufträge gemischt werden, wobei +über den BPD-Parameter ,,Mehr als ein TAN-pflichtiger Auftrag pro Nachricht er- +laubt“ die Anzahl der TAN-pflichtigen Aufträge geregelt wird. + + +![](figures/42.2) + + +Durch das Zeitverhalten bei TAN-pflichtigen Aufträgen im Zwei- +Schritt-Verfahren kann es zu Problemen in Kombination mit PIN- +pflichtigen Aufträgen kommen, die eine lange Verarbeitungszeit er- +fordern wie z. B. Umsatzabfragen. Dadurch kann es möglich sein, +dass die Antwortzeit der Umsatzabfrage das Zeitfenster für die Be- +reitstellung der TAN durch den Kunden so stark einschränkt, dass +ein Timeout auftritt. + +Diese Situation kann vermieden werden, wenn in solchen Fällen +die Aufträge in separaten Nachrichten vorab übertragen werden +und auf die Mischung mit den TAN-pflichtigen Aufträgen verzichtet +wird. + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: B
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FV
Kapitel:
Abschnitt:		Verfahrensbeschreibung
Geschäftsvorfall HKTAN für Zwei-Schritt-TAN-Einreichung		Stand: 23.02.2018Seite: 43
+ + +## B.4.4.2Zeitüberwachung beim Zwei-Schritt-Verfahren bei Einfach-TANs + +Die Eingabe einer TAN im Zwei-Schritt-Verfahren wird auf Institutsseite durch Timer +überwacht, d. h. nach Übermittlung der Challenge bleibt dem Kunden nur ein be- +stimmtes Zeitfenster, um die TAN einzureichen. Ein Ausbleiben der TAN wird als +fehlerhafter Versuch gewertet und die TAN wird als ungültig markiert. Dies wird bei +der Auftragsantwort im jeweiligen TAN-Prozess-Schritt über den Rückmeldecode +9951 – ,Zeitüberschreitung im Zwei-Schritt-Verfahren – TAN ungültig“ signalisiert. + +Diese Zeitüberwachung gilt bei jeder Einreichung einer TAN im Zwei-Schritt- +Verfahren, also auch, wenn - ggf. über HKTAN eingeleitet – nachträglich zusätzlich +benötigte TANs eingereicht werden. + + +## B.4.4.2.1 Zeitüberwachung beim Zwei-Schritt-Verfahren bei Mehrfach-TANs + +Bei der Verwendung von Mehrfach-TANs gelten für synchrone und zeitversetzte +Einreichung unterschiedliche Festlegungen für die Zeitüberwachung. + + +## B.4.4.2.2 Zeitüberwachung bei synchroner Eingabe von Mehrfach-TANs + +Die Überwachung bei synchroner Eingabe von Mehrfach-TANs entspricht der Be- +handlung von Einfach-TANs, wobei die Zeitüberwachung auf Institutsseite so ge- +staltet sein muss, dass den Benutzern ein genügend großes Zeitfenster für die Ein- +reichung der TANs bleibt. + + +## B.4.4.2.3 Zeitüberwachung bei zeitversetzter Eingabe von Mehrfach-TANs + +Die maximale Dauer, die ein eingereichter Auftrag für die Übermittlung weiterer +TANs aufbewahrt wird, unterliegt bei zeitversetzter Einreichung einer separaten +Zeitüberwachung für jeden Benutzer. Wird dieses Zeitfenster überschritten und der +Auftrag wurde inzwischen auf Institutsseite gelöscht, so wird dies in der Auftragsan- +twort HITAN über die Rückmeldecodes 9210 ,Auftrag abgelehnt - Kein eingereich- +ter Auftrag gefunden" bzw. 9210 - ,Auftragsreferenz ist unbekannt" signalisiert (vgl. +Kapitel B.6.1). + + +![](figures/43.1) + + +Die Aufbewahrungsdauer von Aufträgen mit Mehrfach-TANs bei +zeitversetzter Eingabe entspricht den Regelungen bei FinTS Sta- +tusprotokollen (vgl. [Formals] Kapitel C.7), kann institutsindividuell +jedoch auch bis zu einem Jahr betragen. + + +## B.5 Geschäftsvorfall HKTAN für Zwei-Schritt-TAN-Einreichung + +Dieser Geschäftsvorfall dient im Zwei-Schritt-Verfahren dazu, eine Challenge zur +TAN-Bildung anzufordern und eine TAN zu einem Auftrag zu übermitteln. Hierfür +existieren zwei Prozessvarianten, deren Funktion im Kapitel B.4 genau beschrieben +ist. + + +![](figures/43.2) + + +Der Geschäftsvorfall HKTAN nimmt in FinTS eine Sonderrolle ein: +HKTAN muss in BPD, UPD und HIPINS (Parameter ,,TAN erfor- +derlich“ = „n“) wie ein Geschäftsvorfall aufgeführt werden und be- +sitzt mit HITANS auch Geschäftsvorfallparameter. Als Sonderbe- +dingung wird HKTAN jedoch wie ein administratives Segment bei + + +![](figures/43.3) + + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
44		Stand: 23.02.2018Kapitel: Verfahrensbeschreibung
Abschnitt: Geschäftsvorfall HKTAN für Zwei-Schritt-TAN-Einreichung
+ + +der Zählung im DE „Maximale Anzahl Aufträge“ pro Nachricht (vgl. +[Formals], Kapitel D.6) nicht berücksichtigt. + +Durch Existenz dieses Geschäftsvorfalls HKTAN in der BPD und UPD wird grund- +sätzlich festgelegt, ob das Kreditinstitut Zwei-Schritt-Verfahren unterstützt bzw. ob +dies für den Kunden zugelassen ist. Mit Einführung der starken Kundenauthentifizie- +rung [PSD2] ist dies obligatorisch. Der Geschäftsvorfall HKTAN wird in mehreren +Segmentversionen angeboten. Ein Institut, das Zwei-Schritt-Verfahren anbieten will +muss mindestens eine dieser Segmentversionen unterstützen. Für die Unterstüt- +zung der starken Kundenauthentifizierung gemäß PSD2 wird mindestens die Seg- +mentversion #6 benötigt. + +Zusammen mit der Kreditinstitutsrückmeldung können abhängig vom verwendeten +fachlichen Geschäftsvorfall auch Antwortsegmente zu diesem Auftrag +übertragen werden. + + +### B.5.1 Geschäftsvorfall HKTAN in Segmentversion #6 + +Ab der Segmentversion #6 dieses Geschäftsvorfalls wird die starke Kundenauthenti- +fizierung bei der Dialoginitialisierung durch Eingabe einer TAN unterstützt. + +Mit dieser Version können aber auch andere PIN/TAN Zwei-Schritt-Verfahren - au- +Ber TAN-Listenverfahren - unterstützt werden; wahlweise können Kreditinstitute zu- +sätzlich auch die älteren Segmentversionen von HKTAN anbieten. + + +![](figures/44.1) + + +In der BPD können sich mehrere Segmentversionen von HITANS- +Segmenten befinden, wobei den einzelnen HITANS-Segmenten +über das Element „Sicherheitsfunktion, kodiert“ unterschiedliche +Verfahren zugeordnet sein können. Ein Kundenprodukt sollte - be- +ginnend mit der höchsten Segmentversion - alle in der BPD enthal- +tenen HITANS-Segmente analysieren, um so dem Kunden alle vom +Kreditinstitut unterstützten Sicherheitsverfahren anbieten zu kön- +nen. + +Beispiel: Die BPD enthält Definitionen für HITANS#6 und +HITANS#5. In HITANS#6 gilt für starke Kundenauthentifizierung +analog PSD2, mit HKTAN#5 ist übergangsweise auch noch eine +Dialoginitialisierung ohne starke Authentifizierung möglich. + +Realisierung Bank: verpflichtend in mindestens einer Segmentversion, falls +Geschäftsvorfälle mit PIN/TAN-Absicherung im Zwei-Schritt- +Verfahren angeboten werden. Zur Unterstützung der starken +Kundenauthentifizierung gemäß PSD2 wird mindestens Seg- +mentversion #6 benötigt. + +Realisierung Kunde: optional + + +# a) Kundenauftrag + + +# Format + + + + + + + + + + + + + + + +
Name:Zwei-Schritt-TAN-Einreichung
Typ:Segment
Segmentart:Geschäftsvorfall
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: B
Dokument:Security - Sicherheitsverfahren PIN/TAN
Kapitel:
Abschnitt:		Verfahrensbeschreibung
Geschäftsvorfall HKTAN für Zwei-Schritt-TAN-Einreichung		Stand: 23.02.2018Seite: 45
+ + + + + + + + + + + + + + + + + + + +
Kennung:HKTAN
Bezugssegment:-
Segmentversion:6
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2TAN-Prozess1DEcode1M11, 2, 3, 4
3Segmentkennung1DEan..6C1M: bei TAN-Prozess=1 M: bei TAN-Prozess=4 und starker Authentifizierung N: sonst
4Kontoverbindung international Auf- traggeber1DEGkti#C1M: bei TAN-Prozess=1 und „Auftraggeberkonto erfor- derlich"=2 und Kontover- bindung im Auftrag enthal- ten N: sonst
5Auftrags-Hashwert1DEbin.256C1M: bei Auftrags- Hashwertverfahren<>0 und TAN-Prozess=1 N: sonst
6Auftragsreferenz1DEan.35C1M: bei TAN-Prozess=2, 3 O: TAN-Prozess=1, 4
+ + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite: 46Stand: 23.02.2018Kapitel: Verfahrensbeschreibung
Abschnitt: Geschäftsvorfall HKTAN für Zwei-Schritt-TAN-Einreichung
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
7Weitere TAN folgt1DEjn1C1M: bei TAN-Prozess=1, 2 N: bei TAN-Prozess=3, 4
8Auftrag stornieren1DEjn1C1O: bei TAN-Prozess=2 und ,,Auftragsstorno erlaubt“=J N: sonst
9SMS- Abbuchungskonto1DEGkti#C1M: bei TAN-Prozess=1, 3, 4 und ,,SMS- Abbuchungskonto erforder- lich“=2
O: sonst
10Challenge-Klasse1DEnum..2C1M: bei TAN-Prozess=1 und ,Challenge-Klasse erforder- lich“=J N: sonst
11Parameter Challen- ge-Klasse1DEGC1O: bei TAN-Prozess=1 und ,Challenge-Klasse erforder- lich“=J N: sonst
12Bezeichnung des TAN-Mediums1DEan.32C1M: bei TAN-Prozess=1, 3, 4 und „Anzahl unterstützter aktiver TAN-Medien“ > 1 und ,,Bezeichnung des TAN-Mediums erforder- lich“=2
O: sonst
13Antwort HHD_UC1DEGC1M: bei TAN-Prozess=2 und "Antwort HHD_UC erfor- derlich“=“J“ O: sonst
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: B
Dokument:Security - Sicherheitsverfahren PIN/TAN
Kapitel:
Abschnitt:		Verfahrensbeschreibung
Geschäftsvorfall HKTAN für Zwei-Schritt-TAN-Einreichung		Stand: 23.02.2018Seite: 47
+ + +# ◆ Belegungsrichtlinien + + +## Segmentkennung + +Es ist die Kennung des Segmentes einzustellen, auf das sich die Challenge +bzw. dann die resultierende TAN bezieht. Dabei sind folgende Fälle zu un- +terscheiden: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
BezeichnungSegment- kennung
IdentifikationHKIDN
TAN-Management-Geschäftsvorfälle (siehe Abschnitt C.3):
Anzeige der verfügbaren TAN-MedienHKTAB
TAN-Generator an- bzw. ummeldenHKTAU
TAN-Generator SynchronisierungHKTSY
Mobilfunkverbindung registrierenHKMTR / HKMTS
Mobilfunkverbindung freischaltenHKMTF
Mobilfunkverbindung ändernHKMTA
Deaktivieren / Löschen von TAN-MedienHKTML
+ + +## Auftragsreferenz + +Als Auftragsreferenz ist derjenige Wert einzustellen, der bei der Auftragsein- +reichung im Rahmen der Kreditinstitutsrückmeldung mitgeteilt wurde. + + +## Parameter Challenge-Klasse + +Die Parameter zur Challenge-Klasse dienen zur Übermittlung von Daten, die +bei Prozessvariante 1 im ersten Verfahrensschritt für die weitere Steuerung +benötigt werden. Die konkrete Belegung der Parameter sind den Belegungs- +richtlinien des jeweiligen Verfahrens zu entnehmen. Für die DK-Verfahren +chipTAN und mobileTAN gelten die Festlegungen in [HHD Belegung]. + + +## Bezeichnung des TAN-Mediums + +Ist in der BPD als ,,Anzahl unterstützter aktiver TAN-Medien“ ein Wert > 1 +angegeben und ist der BPD-Wert für „Bezeichnung des TAN-Mediums erfor- +derlich" = 2, so muss der Kunde z. B. im Falle des mobileTAN-Verfahrens +hier die Bezeichnung seines für diesen Auftrag zu verwendenden TAN- +Mediums angeben. + + +## SMS-Abbuchungskonto + +Ist in der BPD das Element ,,SMS-Abbuchungskonto erforderlich" mit ,2" be- +legt, so muss der Kunde z. B. im Falle des mobileTAN-Verfahrens hier das +für diesen Auftrag zu belastende SMS-Abbuchungskonto einstellen. Dieses +kann unabhängig von der Kontoverbindung des Dialogführers gewählt wer- +den. + + +## Antwort HHD_UC + +Bei Verwendung von chipTAN-Verfahren mit bidirektionaler Kopplung wer- +den auf dem Rückkanal relevante Informationen aus dem TAN- + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
48		Stand: 23.02.2018Kapitel: Verfahrensbeschreibung
Abschnitt: Geschäftsvorfall HKTAN für Zwei-Schritt-TAN-Einreichung
+ + +Generierungsprozess an das Zugangsgerät übertragen. Diese können bei +Prozessvariante 2 – abhängig vom Zustand des BPD-Parameters „Antwort +HHD_UC erforderlich" - bei der TAN-Einreichung im zweiten Schritt mit +TAN-Prozess=2 zum Kreditinstitut übertragen werden. Bei Verwendung von +Prozessvariante 1 ist die Übertragung der HHD_UC-Parameter aus dem +Rückkanal nicht möglich, da dort im 2. Schritt kein HKTAN übermittelt wird. + + +# b) Kreditinstitutsrückmeldung + + +## Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Zwei-Schritt-TAN-Einreichung Rückmeldung
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HITAN
Bezugssegment:HKTAN
Segmentversion:6
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2TAN-Prozess1DEcode1M11, 2, 3, 4
3Auftrags-Hashwert1DEbin.256C1M: bei Auftrags- Hashwertverfahren<>0 und TAN-Prozess=1, N: sonst
4Auftragsreferenz1DEan..35C1M: bei TAN-Prozess=2, 3, 4 O: bei TAN-Prozess=1
5Challenge3DEan.204 8C1M: bei TAN-Prozess=1, 3, 4 O: bei TAN-Prozess=2
6Challenge HHD UC1DEbin..O1
7Gültigkeitsdatum und -uhrzeit für Challenge1DEGO1
8Bezeichnung des TAN-Mediums1DEan..32C1M: bei TAN-Prozess=1, 3, 4 und „Anzahl unterstützter aktiver TAN-Medien" nicht vorhanden O: sonst
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: B
Dokument:Security - Sicherheitsverfahren PIN/TAN
Kapitel:
Abschnitt:		Verfahrensbeschreibung
Geschäftsvorfall HKTAN für Zwei-Schritt-TAN-Einreichung		Stand: 23.02.2018Seite: 49
+ + +# ◆ Belegungsrichtlinien + + +## Auftrags-Hashwert + +Es ist der in der Kundennachricht in HKTAN übermittelte Auftrags-Hashwert +unverändert einzustellen. + + +## Auftragsreferenz + +Bei TAN-Prozess=2, 3 und 4 muss die Auftragsreferenz vom Institut immer +eingestellt werden. Bei TAN-Prozess=1 muss die Auftragsreferenz einge- +stellt werden, wenn sie zuvor im Segment HKTAN vom Kunden gesendet +wurde. Wird im Rahmen der starken Kundenauthentifizierung keine TAN be- +nötigt und ein „Dummy-HITANS“ geschickt, enthält die Auftragsreferenz den +fest definierten FinTS-Füllwert ,,noref“. + + +## Challenge + +Obwohl die Challenge bei Prozessvariante 2 im zweiten Schritt nicht zwin- +gend benötigt wird, sollte sie aus Integritätsgründen trotzdem übertragen +werden. Wird im Rahmen der starken Kundenauthentifizierung keine TAN +benötigt und ein „Dummy-HITANS“ geschickt, enthält die Challenge einen +FinTS-Füllwert, z. B. „nochallenge“. + + +![](figures/49.1) + + +Das Kundenprodukt muss den Inhalt der empfangenen Challenge +dem Kunden unverändert anzeigen. Ist der BPD-Parameter ,,Chal- +lenge strukturiert“ mit ,,J“ belegt, so können im DE Challenge For- +matsteuerzeichen enthalten sein, die dann entsprechend zu inter- +pretieren sind (Näheres hierzu im Data Dictionary unter dem DE +„Challenge“). + +Erläuterung: Die Challenge kann institutsindividuell aufgebaut wer- +den (z. B. 1 oder 2 Eingabefelder für den chipTAN-Leser). + + +## Challenge HHD_UC + +Das Datenelement enthält eine Datenstruktur, die entsprechend den Vorga- +ben aus [HHD-Erweiterung] aufgebaut sein muss. Die einzelnen Elemente +dieser Datenstruktur sind für FinTS transparent und werden nicht durch +Trennzeichen getrennt. + + +## Bezeichnung des TAN-Mediums + +Ist in der BPD der Parameter „Anzahl unterstützter aktiver TAN-Medien" +nicht vorhanden, so muss das Institut dem Kunden hier mitteilen, welches +TAN-Medium er z. B. beim mobileTAN-Verfahren verwenden soll. + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite: 50Stand: 23.02.2018Kapitel: Verfahrensbeschreibung
Abschnitt: Geschäftsvorfall HKTAN für Zwei-Schritt-TAN-Einreichung
+ + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
3075Starke Authentifizierung ab dem ... erforderlich
9075Dialog abgebrochen - starke Authentifizierung erforderlich
9210Auftrag abgelehnt - Auftragsdaten inkonsistent. Eingereichter Auftrag gelöscht
9210Auftrag abgelehnt - Zwei-Schritt-TAN inkonsistent. Eingereichter Auftrag gelöscht
9210Auftrag abgelehnt - Kein eingereichter Auftrag gefunden
9210Auftrag abgelehnt - Auftragsreferenz ist unbekannt
9330chipTAN-Leser gesperrt. Führen Sie ggf. eine chipTAN-Synchronisation durch
9380Gewähltes Zwei-Schritt-TAN-Verfahren nicht zulässig
9931Sperrung des Kontos nach x Fehlversuchen
9941TAN ungültig
9951Zeitüberschreitung im Zwei-Schritt-Verfahren – TAN ungültig
9953Nur ein TAN-pflichtiger Auftrag pro Nachricht erlaubt
9954Mehrfach-TANs nicht erlaubt
9955Ein-Schritt-TAN-Verfahren nicht zugelassen
9956Zeitversetzte Eingabe von Mehrfach-TANs nicht erlaubt
9991TAN bereits verbraucht
+ + +## c) Bankparameterdaten + + +## Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Zwei-Schritt-TAN-Einreichung, Parameter
Typ:Segment
Segmentart:Geschäftsvorfallparameter
Kennung:HITANS
Bezugssegment:HKVVB
Segmentversion:6
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Zwei- Schritt-TAN- Einreichung6DEGM1
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: B
Dokument:Security - Sicherheitsverfahren PIN/TAN
Kapitel:
Abschnitt:		Verfahrensbeschreibung Erweiterung der RückmeldungscodesStand: 23.02.2018Seite: 51
+ + +## ◆ Belegungsrichtlinien + +Auftrags-Hashwertverfahren (Parameter Zwei-Schritt-TAN-Einreichung) +Bei Verwendung von TAN-Prozess=1. + + +## B.6 Erweiterung der Rückmeldungscodes + +Bei Verwendung des PIN/TAN-Verfahrens können spezielle Rückmeldecodes vom +Kreditinstitut zurückgemeldet werden, die rein PIN/TAN-spezifisch sind und u. U. +nicht direkt mit dem zugehörigen Geschäftsvorfall in Verbindung stehen. Es handelt +sich hierbei um die folgenden Codes: + + +## Erfolgsmeldungen + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
0020PIN-Sperre erfolgreich
0020PIN-Sperre aufgehoben
0020PIN geändert
0030Auftrag empfangen - Sicherheitsfreigabe erforderlich
0030Auftrag empfangen - Sicherheitsfreigabe erforderlich und Auftragsstorno möglich
0031Auftragsstorno durchgeführt
0900TAN gültig
0901PIN gültig
+ + +## Warnungen und Hinweise + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
3075Starke Authentifizierung ab dem ... erforderlich
3076Keine starke Authentifizierung erforderlich
3910TAN wurde nicht verbraucht
3913TAN wurde verbraucht
3916PIN muss wegen erstmaliger Anmeldung zwangsweise geändert werden
3918Kompetenz nicht ausreichend - weitere TAN erforderlich
3920Zugelassene Ein- und Zwei-Schritt-Verfahren für den Benutzer (+ Rückmeldungsparameter)
3931PIN gesperrt. Entsperren mit GV ,,PIN-Sperre aufheben“ möglich
3931chipTAN-Leser gesperrt. Führen Sie ggf. eine chipTAN-Synchronisation durch
3932Bitte führen Sie zunächst eine PIN-Änderung durch
3933chipTAN-Leser gesperrt, Synchronisierung erforderlich Kartennummer
3934Bitte eine Karte für die Verwendung mit chipTAN zulassen
3935Bitte eine Karte für die Verwendung mit chipTAN zulassen
3939mobileTAN-Freischaltung erforderlich. SMS-Freischaltcode wurde versendet
3940Zur PIN-Änderung stehen folgende TAN-Medien zur Verfügung:
3941Zur PIN-Änderung stehen folgende Rufnummern zur Verfügung:
3950Die Selbstumstellung auf ein anderes Sicherheitsverfahren ist möglich
3951Die Selbstumstellung auf ein anderes Sicherheitsverfahren ist erforderlich
3952<Rückmeldung des erfolgten Prozessschrittes der Selbstumstellung>
3960Individuell
+ + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
52		Stand: 23.02.2018Kapitel: Verfahrensbeschreibung
Abschnitt: Erweiterung der Rückmeldungscodes
+ + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
-
3999
+ + +## Fehlermeldungen + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
9075Dialog abgebrochen - starke Authentifizierung erforderlich
9210Auftrag abgelehnt - Auftragsdaten inkonsistent. Eingereichter Auftrag gelöscht
9210Auftrag abgelehnt - Zwei-Schritt-TAN inkonsistent. Eingereichter Auftrag gelöscht
9210Auftrag abgelehnt - Kein eingereichter Auftrag gefunden
9210Auftrag abgelehnt - Auftragsreferenz ist unbekannt
9210Auftrag abgelehnt - Kompetenz nicht ausreichend
9330ChipTAN-Leser gesperrt. Führen Sie ggf. eine TAN-Gen.-Synchronisation durch
9931Teilnehmersperre durchgeführt
9939Freischalten der Mobilfunknummer für mobileTAN nicht möglich
9941TAN ungültig
9942PIN ungültig
9942neue PIN ungültig
9951Zeitüberschreitung im Zwei-Schritt-Verfahren – TAN ungültig
9953Nur ein TAN-pflichtiger Auftrag pro Nachricht erlaubt
9954Mehrfach-TANs nicht erlaubt
9955Ein-Schritt-TAN-Verfahren nicht zugelassen
9956Zeitversetzte Eingabe von Mehrfach-TANs nicht erlaubt
9957Wechsel des TAN-Prozesses bei Mehrfach-TANs nicht erlaubt
9991TAN bereits verbraucht
+ + +### B.6.1 Beschreibung spezieller Rückmeldungen im Zwei-Schritt-Verfahren + + +#### Rückmeldungscode 0030: Auftrag empfangen - Sicherheitsfreigabe erforderlich + +Mit dem Rückmeldungscode 0030 als Antwort auf HKTAN bei Prozessvariante 1 +bzw. die Einreichung einer Auftragsnachricht bei Prozessvariante 2 wird ein Zwei- +Schritt-Verfahren eingeleitet. Als Folge auf diesen Rückmeldecode darf je nach +TAN-Prozess ausschlieBlich ein Geschäftsvorfall mit der zugehörigen TAN übermit- +telt und kein neuer TAN-Prozess eingeleitet werden. Unabhängig davon können +PIN-pflichtige Geschäftsvorfälle, die keine TAN erfordern zwischen den beiden Pro- +zess-Schritten bearbeitet werden. + +Rückmeldungscode 3075 / 9075: + +\- Starke Authentifizierung ab dem ... erforderlich bzw. + +\- Dialog abgebrochen - starke Authentifizierung erforderlich + +Diese Rückmeldungen werden verwendet, wenn ein Institut durch Vorhandensein +von HKTAN#6 in den BPD eine starke Kundenauthentifizierung fordert, das Kunden- +produkt diese jedoch nicht durchführt. Diese Möglichkeit einer schwachen Authenti- +fizierung kann – solange zulässig – parallel zur starken Authentifizierung unterstützt +werden. Durch Verwendung des Rückmeldungscode 3075 „Starke Authenti- +fizierung ab dem ... erforderlich" kann der Benutzer auf den Wegfall der +schwachen Authentifizierung hingewiesen werden. Nach Ablauf dieser Frist kann +eine Dialoginitialisierung mit schwacher Authentifizierung durch den Rückmeldungs- +code 9075 ,,Dialog abgebrochen - starke Authentifizerung erfor- +derlich" abgewiesen werden. Der Rückmeldungscode 9075 muss in Kombination +mit Code 9800 auftreten. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: B
Dokument:Security - Sicherheitsverfahren PIN/TAN
Kapitel:
Abschnitt:		Verfahrensbeschreibung
Erweiterung der Rückmeldungscodes		Stand: 23.02.2018Seite: 53
+ + +##### Rückmeldungscode 3076: Keine starke Authentifizierung erforderlich + +Der Rückmeldungscode 3076 wird verwendet, wenn ein Institut durch Vorhanden- +sein von HKTAN#6 in den BPD eine starke Kundenauthentifizierung unterstützt. Im +Rahmen des Zwei-Schritt-Verfahrens bei Initialisierung und Auftragseinreichung +dient dieser RM-Code dazu, das Kundenprodukt nach der Einreichung in Schritt 1a +zu informieren, dass die Eingabe der PIN als Wissensfaktor ausreichend ist und +aufgrund einer in PSD2 definierten Ausnahme keine starke Kundenauthentifizierung +erforderlich ist. Die Verarbeitung wird mit Schritt 2b (Bestätigung der Auftragseinrei- +chung) fortgesetzt. Somit wird der RM-Code 3076 situationsbezogen alternativ zu +RM-Code 0030 verwendet. + + +#### Rückmeldungscode 3920: Zugelassene Ein- und Zwei-Schritt-Verfahren für den Benutzer (+ Rückmeldungsparameter) + +Der Rückmeldungscode 3920 dient dazu, dem Kundenprodukt im Rahmen der Dia- +loginitialisierungsantwort die für den Benutzer zugelassenen Ein- und Zwei-Schritt- +Verfahren mitzuteilen. Hierzu werden in den Rückmeldungsparametern P1 bis P10 +entsprechend den zugelassenen Verfahren (,,900" bis ,997") aus HITANS maximal +zehn mögliche Zwei-Schritt-Verfahren bzw. neun Zwei-Schritt-Verfahren + das Ein- +Schritt-Verfahren (,999") transportiert. + + +![](figures/53.1) + + +Das Kundenprodukt muss – unabhängig vom gewählten Verfahren +in ,,Sicherheitsfunktion, kodiert“ - bei jeder Dialoginitialisierung die +vom Institut mit dem Rückmeldungscode 3920 übermittelten Werte +P1, … , P10 prüfen, gegen gespeicherte Informationen vergleichen +und diese ggf. aktualisieren. + +Sollte das Kundenprodukt in der Dialoginitialisierungsnachricht ein +Verfahren wählen, das für den Benutzer nicht bzw. nicht mehr zu- +gelassen ist, so beendet das Kreditinstitut den Dialog mit Rück- +meldungscode 9800 in Kombination mit Code 3920 und meldet die +aktuell zugelassenen Verfahren in den Parametern P1 bis P10. + + +#### Rückmeldungscode 3934 bzw. 3935: Bitte eine Karte zur Verwendung mit chip- TAN zulassen (+ Rückmeldungsparameter) + +Die Rückmeldungscodes 3934 und 3935 veranlassen das Kundenprodukt, auf Basis +des Geschäftsvorfalls „TAN-Medium an bzw. ummelden (HKTAU)“ eine gültige Kar- +te für das chipTAN-Verfahren im laufenden Dialog anzumelden. Die Rückmeldungs- +parameter P1 und P2 enthalten pro Rückmeldung verpflichtend eine „Kartennum- +mer“ (Format „id“) und die zugehörige „Bezeichnung des TAN-Mediums“ (..32). + +Bei Verwendung des Rückmeldungscode 3934 ist das Anstoßen des Geschäftsvor- +falls HKTAU verpflichtend. + +Beim Rückmeldungscode 3935 ist das Initiieren der Kombination ,Anzeigen der ver- +fügbaren TAN-Medien (HKTAB)" und HKTAU optional. + + +#### Rückmeldungscode 9210: + +\- Auftragsreferenz ist unbekannt bzw. + +\- Auftrag abgelehnt - kein eingereichter Auftrag gefunden + +Diese Rückmeldung kann folgende Ursachen haben: + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
54		Stand: 23.02.2018Kapitel: Verfahrensbeschreibung
Abschnitt: Bankfachliche Anforderungen
+ + +• Die eingereichte Auftragsreferenz bzw. der Auftrags-Hashwert wird im Auftrags- +bestand nicht gefunden, da das Element auf dem Weg vom Kreditinstitut zum +Kunden und wieder zurück verfälscht wurde. + +• Ein zugehöriger Auftrag, der mehrere TANs erfordert, hat den maximalen Aufbe- +wahrungszeitraum überschritten und wurde vom Institut gelöscht. + +• Ein zugehöriger Auftrag, der mehrere TANs erfordert, wurde über einen anderen +Vertriebsweg (außerhalb FinTS) autorisiert und ist inzwischen verarbeitet. + + +![](figures/54.1) + + +Das Kreditinstitut sollte den wirklichen Grund für diese Rückmel- +dung in das Statusprotokoll einstellen, damit der Kunde sich später +dort informieren und den Auftrag kundenseitig entsprechend weiter +bearbeiten kann. + + +## B.7 Bankfachliche Anforderungen + +Es gelten die in [HBCI] aufgeführten Regelungen. Abweichend hierzu gilt: + + +### Zu signierende Nachrichten + +Wie auch beim Sicherheitsverfahren HBCI ist die Signatur von Kreditinstitutsnach- +richten optional. Da der Kunde in seiner Auftragsnachricht das anzuwendende Sig- +naturverfahren vorgibt, darf das Kreditinstitut jedoch nicht mit einem Sicherheitsver- +fahren aus HBCI (RAH, RDH bzw. DDV) antworten. Somit sendet das Kreditinstitut +entweder keinen Sicherheitskopf und -abschluss oder alternativ sendet es Signa- +turkopf und -abschluss, bei denen allerdings PIN und TAN nicht belegt werden. + + +### Doppeleinreichungskontrolle über Signatur-ID und Kundensystem-ID + +Im PIN/TAN-Verfahren werden keine Signatur-IDs benötigt, da hier die TAN deren +Aufgabe übernimmt und durch sie eine Doppeleinreichung verhindert wird. Eine +Kundensystem-ID ist jedoch auch hier notwendig, da der gleiche Benutzer zeitgleich +mehrere Dialoge von verschiedenen Kundensystemen aus führen kann. Soll eine +neue Kundensystem-ID durch das Segment HKSYN angefordert werden, so ist un- +ter ,,Sicherheitsfunktion, kodiert“ ein für den Kunden gültiges Ein- oder Zwei-Schritt- +Verfahren zurückzugeben. + + +## B.8 Erweiterung der Bank- und Userparameterdaten (BPD / UPD) + +Für die Verwendung des PIN/TAN-Verfahrens müssen dem Kundenprodukt weitere +Daten im Rahmen der BPD- bzw. UPD-Segmentfolge übermittelt werden. So ist bei- +spielsweise anzugeben, welche Geschäftsvorfälle über PIN/TAN abgesichert wer- +den dürfen und für welche davon eine TAN erforderlich ist. Weiterhin muss auch +kommuniziert werden können, ob ein oder mehrere Zwei-Schritt-Verfahren unter- +stützt sind. Hierfür existieren zusätzliche Geschäftsvorfälle, welche die folgende In- +formation transportieren: + + + + + + + + + + + +
HIPINSPIN/TAN-Verfahren ist unterstützt
nur Parametersegment; enthält die Segmentkennungen aller Ge- schäftsvorfälle, die über PIN/TAN abgewickelt werden können und die Information, welche Geschäftsvorfälle davon TAN-pflichtig sind.
HITANSMindestens ein Zwei-Schritt-Verfahren ist unterstützt (vgl. Kapitel B.5)
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: B
Dokument:Security - Sicherheitsverfahren PIN/TAN
Kapitel:
Abschnitt:		Verfahrensbeschreibung
Erweiterung der Bank- und Userparameterdaten (BPD /		Stand: 23.02.2018Seite: 55
+ + +### B.8.1 PIN/TAN-spezifische Informationen (HIPINS) + +Die für die Kennzeichnung des PIN/TAN-Verfahrens notwendige BPD-/UPD- +Ergänzung wird in Form eines speziellen Parametersegmentes realisiert, welches +sich auf keinen echten Geschäftsvorfall bezieht, sondern Daten zu allen unterstütz- +ten Geschäftsvorfällen aufnehmen kann. + +Das Spezialsegment HIPINS wird verwendet, um in die BPD-Segmentfolge +PIN/TAN-spezifische Daten einzufügen. Aufgrund seines Aufbaus analog zu einem +Segmentparametersegment wird es von Kundenprodukten, die das PIN/TAN- +Verfahren nicht unterstützen, ignoriert, da es sich auf einen ihnen unbekannten Ge- +schäftsvorfall zu beziehen scheint. + +Die in HIPINS aufgeführten Geschäftsvorfälle dürfen vom Kunden in über PIN/TAN +abgesicherte Nachrichten eingestellt werden, sofern sie in den BPD und UPD als +generell erlaubt hinterlegt sind. Alle übrigen Geschäftsvorfälle können mit dem +PIN/TAN-Verfahren nicht verwendet werden. + +Einzelheiten zur Verwendung von HIPINS in Kombination mit der starken Kun- +denauthentifizierung gemäß [PSD2] befinden sich in Kapitel B.3. + + +![](figures/55.1) + + +Um die Kompatibilität zwischen den Sicherheitsverfahren PIN/TAN +und HBCI sicherzustellen, konnte der mögliche Wertebereich in- +nerhalb von HISHV-Segmenten nicht um einen weiteren Wert für +PIN/TAN erweitert werden. Clients können diesem Segment somit +nicht entnehmen, ob das PIN/TAN-Verfahren unterstützt wird oder +nicht. Dies muss am Vorkommen des HIPINS-Segments festge- +macht werden. Ist ein solches Segment vorhanden, wird das +PIN/TAN- Verfahren unterstützt, andernfalls nicht. + +Realisierung Bank: +verpflichtend, +falls +Geschäftsvorfälle +mit PIN/TAN- +Absicherung angeboten werden + +Realisierung Kunde: +optional + + +#### ◆ Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:PIN/TAN-spezifische Informationen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIPINS
Bezugssegment:HKVVB
Segmentversion:1
Sender:Kreditinstitut
Format:Geschäftsvorfall mit Parametern
+ + +#### ◆ Erläuterungen + + + + + + + + + + + + + + + +
Name:Parameter PIN/TAN-spezifische Informationen
Typ:Datenelementgruppe
Status:M
+ + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
56		Stand: 23.02.2018Kapitel: Verfahrensbeschreibung
Abschnitt:
Erweiterung der Bank- und Userparameterdaten (BPD / UPD)
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameTypFor- matLän- geSta- tusAn- zahlRestriktionen
Minimale PIN-LängeDEnum..2O1
Maximale PIN-LängeDEnum..2O1
·Maximale TAN-LängeDEnum..2O1
.Text zur Belegung der BenutzerkennungDEan.30O1
.Text zur Belegung der Kunden-IDDEan..30O1
Geschäftsvorfallspezifi- sche PIN/TAN- InformationenDEGO999
+ + +### Beispiel + +HIPINS:4:1:5+1+1+0+5:6:6:Kunden-Nr aus dem TAN-B +rief : :HKCCS:J:HKKAN:N:HKSAL:J:HKPAE:J:HKTLA:J:HK +TLF : J' + + +### B.8.2 Spezielle Festlegungen für die Dialoginitialisierung beim Zwei-Schritt- Verfahren + +Im Rahmen der Dialoginitialisierung werden folgende Informationen ausgetauscht: + + +#### Zugelassene Ein- und Zwei-Schritt-Verfahren für den Benutzer + +In der Dialoginitialisierungsantwort wird dem Kunden im Rahmen der Rück- +meldungen zu Segmenten (HIRMS) über den Rückmeldungscode 3920 und +entsprechende Rückmeldungsparameter mitgeteilt, welche konkreten Zwei- +Schritt-Verfahren für ihn zugelassen sind. Dabei wird pro Rückmeldeparame- +ter (P1 bis P10) ein Verfahrenskennzeichen (maximal 10 bzw. 9 + ggf. Ein- +Schritt-Verfahren) übermittelt. Die Kodierung erfolgt analog der Belegung +des DE ,Sicherheitsfunktion, kodiert" im Parametersegment HITANS, also im +Wertebereich ,,900" bis ,,997" bzw. ,999“ für Ein-Schritt-Verfahren. + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: B
Dokument:Security - Sicherheitsverfahren PIN/TAN
Kapitel:VerfahrensbeschreibungStand:Seite:
Abschnitt:Besondere Belegungsrichtlinien23.02.201857
+ + +![](figures/57.1) + + +Das Kreditinstitut muss organisatorisch sicherstellen, dass der Kun- +de über eine geeignete Version eines Kundenproduktes verfügt, das +die Rückmeldeparameter entsprechend interpretieren kann. In je- +dem Falle sollte der Kunde durch einen verständlichen Rückmelde- +text darauf hingewiesen werden, dass er ggf. ein aktualisiertes Kun- +denprodukt benötigt. + +Sollte der Kunde vertraglich an die Nutzung des Zwei-Schritt- +Verfahrens gebunden sein und verwendet er ein Kundenprodukt, +welches das Zwei-Schritt-Verfahren nicht unterstützt, so ist der Dia- +log zu beenden. Über den Rückmeldungscode 9955 „Ein-Schritt- +TAN-Verfahren nicht zugelassen“ und einen geeigneten Rückmel- +dungstext muss der Kunde eindeutig über die Ursache dieser Dia- +logbeendigung informiert werden. Der Rückmeldungstext muss +auch berücksichtigen, dass die Anfrage des Kundenproduktes mit +DE ,,Sicherheitsfunktion, kodiert" = ,999" in diesem Fall nur erfolgt, +um die unterstützten konkreten Zwei-Schritt-Verfahren für den Be- +nutzer zu ermitteln. Diese müssen über den Rückmeldungscode +3920 ,,Zugelassene Ein- und Zwei-Schritt-Verfahren für den Benut- +zer“ (oder den entsprechenden Rückmeldungscode 3920 in Kombi- +nation mit Code 9800 im Fehlerfall) mitgeteilt werden. + + +![](figures/57.2) + + +Sollte das Kundenprodukt Zwei-Schritt-Verfahren unterstützen und +noch keine Verfahrensparameter mit Angabe der für den aktuellen +Benutzer unterstützten Verfahren verfügen, so muss es einen Dia- +log eröffnen, um über die Rückmeldeparameter in Kenntnis der er- +laubten Verfahren zu gelangen. Hierbei ist für das DE „Sicherheits- +funktion, kodiert" der Wert ,,999" für Ein-Schritt-Verfahren zu ver- +wenden. + + +#### Gewähltes Zwei-Schritt-Verfahren des Kunden + +Ein Kunde kann aus den für Ihn zugelassenen konkreten Zwei-Schritt- +Verfahren eines für den aktiven Dialog auswählen. Das entsprechende Ver- +fahrenskennzeichen wird in das DE ,,Sicherheitsfunktion, kodiert" im Signa- +turkopf der Dialoginitialisierungsnachricht eingestellt. Die Kodierung erfolgt +analog der Belegung des DE ,,Sicherheitsfunktion, kodiert" im Parame- +tersegment HITANS, also im Wertebereich ,,900" bis ,997". Das gewählte +konkrete Zwei-Schritt-Verfahren muss für den Benutzer erlaubt sein (BPD, +Rückmeldung 3920 bei Dialoginitialisierung). Auch wenn im Dialog keine +TAN-pflichtigen Geschäftsvorfälle eingereicht werden, muss ein Verfahren +ausgewählt werden. + + +## B.9 Besondere Belegungsrichtlinien + +Datenelemente mit Status „O“, sollten grundsätzlich leer gelassen werden. + +Für einige Datenelemente gelten bei PIN/TAN besondere Belegungsrichtlinien, die +von den allgemeinen in [HBCI] aufgeführten Richtlinien abweichen. Diese sind nach- +folgend aufgeführt. + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
58		Stand: 23.02.2018Kapitel: Verfahrensbeschreibung
Abschnitt: Besondere Belegungsrichtlinien
+ + +### B.9.1 DEG ,,Sicherheitsprofil" + +Sicherheitsverfahren, Code + +„PIN“ : bei allen Nachrichten + +Version des Sicherheitsverfahrens + +„1“ : bei allen Nachrichten, wenn Dialog im Einschritt-Verfahren + +„2“ : bei allen Nachrichten, wenn Dialog im Zwei-Schritt-Verfahren + + +### B.9.2 DEG „Schlüsselname“ + +Schlüsselnummer + +FinTS-Füllwert, z. B. „0“ + +Schlüsselversion + +FinTS-Füllwert, z. B. „0“ + + +### B.9.3 DEG ,,Sicherheitsidentifikation, Details" + +CID + +Dieses Feld darf nicht belegt werden. + +Identifizierung der Partei + +Dieses Feld muss eine gültige, zuvor vom Banksystem angeforderte Kun- +densystem-ID enthalten (analog zu RAH-/RDH-Verfahren). Dies gilt auch für +Zweit- und Drittsignaturen. + + +### B.9.4 Segment ,,Signaturkopf" + +Sicherheitsfunktion, kodiert + +Beim Ein-Schritt-Verfahren ist der Wert ,,999" einzustellen, beim Zwei-Schritt- +Verfahren der entsprechende in der BPD mitgeteilte Wert für das konkrete +Verfahren ,900" bis ,,997" (vgl. Kapitel B.8.2). + +Zertifikat + +Dieses Feld darf nicht belegt werden. + + +### B.9.5 DEG ,,Hashalgorithmus" + +Wert des Hashalgorithmusparameters + +Dieses Feld darf nicht belegt werden. + + +### B.9.6 DEG ,,Signaturalgorithmus" + +Signaturalgorithmus, kodiert +FinTS-Füllwert, z. B. „10“ + +Operationsmodus, kodiert +FinTS-Füllwert, z. B. „16“ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: B
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FV
Kapitel:VerfahrensbeschreibungStand:Seite:
Abschnitt:Besondere Belegungsrichtlinien23.02.201859
+ + +### B.9.7 Segment ,,Signaturabschluss" + +Es ist der Signaturabschluss gemäß [HBCI] ab Segmentversion 2 zu verwenden. + + +#### Validierungsresultat + +Dieses Feld darf nicht belegt werden. + +Benutzerdefinierte Signatur + +Hier werden bei Verwendung des PIN/TAN-Verfahrens PIN und TAN einge- +stellt. Bei Verwendung des Zwei-Schritt-Verfahrens mit Prozessvariante 2 +darf eine TAN ausschließlich über den Geschäftsvorfall HKTAN eingereicht +werden, wobei pro HKTAN nur die Verarbeitung einer einzelnen TAN zuläs- +sig ist. Ansonsten darf die DE ,,TAN" im Signaturabschluss nicht belegt wer- +den; ihr Inhalt wird in diesem Fall ignoriert und die TAN vom Institut entwer- +tet. Gleiches gilt bei der nicht zulässigen Übermittlung von mehreren TANs +mit HKTAN. Bei der Verwendung im Rahmen des Sicherheitsverfahrens +HBCI darf die DEG nicht belegt werden. Ihr Inhalt wird in diesem Fall igno- +riert. + + +### B.9.8 Segment „Verschlüsselungskopf“ + +Sicherheitsfunktion, kodiert + +Es wird der Wert ,,998" (Klartext) verwendet. + +Zertifikat + +Dieses Feld darf nicht belegt werden. + + +### B.9.9 DEG „Verschlüsselungsalgorithmus" + +Wert des Algorithmusparameters, Schlüssel +FinTS-Füllwert, z.B. X'00 00 00 00 00 00 00 00' + +Bezeichner für Algorithmusparameter, Schlüssel +FinTS-Füllwert, z.B. „5“ + +Wert des Algorithmusparameters, IV + +Belegung nicht zulässig. + + +### B.9.10 Segment „Verschlüsselte Daten“ + +Daten, verschlüsselt + +Enthält die unverschlüsselten Daten (die Verschlüsselung erfolgt via Trans- +portverschlüsselung des verwendeten Transportprotokolls HTTPS). + + +### B.9.11 Parametersegmente zu Geschäftsvorfällen + + +#### Sicherheitsklasse + +Sicherheitsklassen werden nur in Verbindung mit dem Sicherheitsverfahren +HBCI benutzt. Unterstützt ein Kreditinstitut ausschließlich das PIN/TAN- +Verfahren, so ist in das DE ,Sicherheitsklasse' des jeweiligen Geschäftsvor- +fallparametersegmentes als Füllwert ,0' einzustellen. Die Sicherheitsklasse +hat bei PIN/TAN für die Verarbeitung keine Bedeutung und darf vom Kun- +denprodukt für PIN/TAN nicht ausgewertet werden. + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
60		Stand: 23.02.2018Kapitel: PIN/TAN-Management
Abschnitt: Besondere Belegungsrichtlinien
+ + +Stattdessen sind die Informationen aus HIPINS für die Festlegung benötigter +Sicherheitsmerkmale zu verwenden. + + +# C. PIN/TAN-MANAGEMENT + +Alle Geschäftsvorfälle zum PIN/TAN-Management werden innerhalb eines persona- +lisierten Dialoges gesendet, also nach Eingabe der PIN. Falls zusätzlich eine TAN +erforderlich ist, ist dies in der Beschreibung des Geschäftsvorfalls vermerkt. PIN und +TAN werden in die entsprechenden Felder des Signaturabschlusses eingestellt (vgl. +Kapitel B.9.7) und sind in der Regel im Geschäftsvorfall selbst nicht vorhanden +(Ausnahmen sind z. B. die PIN-Änderung oder die TAN-Generator- +Synchronisierung). + + +![](figures/60.1) + + +![](figures/60.2) + + +Die Geschäftsvorfälle zum PIN/TAN-Management sollten vom +Kundenprodukt immer in einem geschlossenen Kontext, d. h. in +separaten Nachrichten in einem separaten Dialog geschickt wer- +den, da ansonsten eine gezielte Verarbeitung nicht gewährleistet +werden kann und somit ein exaktes Wissen, ab wann z.B. eine +PIN-Änderung gültig ist, nicht besteht. + +Desweiteren ist vom Kundenprodukt sicherzustellen, dass eine +Nachricht entweder nur einen einzelnen Geschäftsvorfall enthält, +für den eine TAN erforderlich ist, oder nur solche Geschäftsvorfäl- +le, für die keine TAN erforderlich ist. Andernfalls ist die eindeutige +Zuordnung der übergebenen TAN zu den Geschäftsvorfällen nicht +sichergestellt. + +Eine Mischung von Geschäftsvorfällen, die eine TAN erfordern, mit +solchen, die keine erfordern, ist generell nicht zulässig. + +Grundsätzlich werden alle vom Kunden übermittelten TANs, wenn möglich, aus Si- +cherheitsgründen entwertet („verbrannt“). + + +![](figures/60.3) + + +Damit der Kunde Informationen darüber erhält, dass eine von ihm +verwendete TAN aufgrund des Abbruchs der Verarbeitung eines +Geschäftsvorfalles nicht verbraucht wurde, ist vom Kreditinstitut ei- +ne entsprechende Rückmeldung zu diesem Geschäftsvorfall zu er- +zeugen. Ist diese Rückmeldung eingestellt worden, kann vom Kun- +den die gleiche TAN noch einmal verwendet werden. + + +![](figures/60.4) + + +Wird vom Kreditinstitut nicht gemeldet, dass die übermittelte TAN +weiterhin gültig ist, muss die Kundenseite davon ausgehen, dass +die TAN verbraucht wurde. Dies gilt auch dann, wenn der zugehöri- +ge Geschäftsvorfall aufgrund von Fehlern nicht ausgeführt wurde. + +Beim Einsatz des Zwei-Schritt-Verfahrens erfolgt die Verarbeitung wie in den Fest- +legungen in Kapitel B.2 beschrieben. + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: B
Dokument:Security - Sicherheitsverfahren PIN/TAN
Kapitel:PIN/TAN-ManagementStand:Seite:
Abschnitt:Verwalten der Online-Banking-PIN23.02.201861
+ + +Wird also für die Ausführung eines PIN/TAN-Management-Geschäftsvorfalls eine +TAN benötigt, so wird diese analog Prozessvariante 1 oder 2 ermittelt. + +PIN/TAN-Management-Geschäftsvorfälle zur Verwaltung von TAN-Listen wurden +aus der vorliegenden Spezifikation entfernt und können bei Bedarf in einem älteren +Release im Archiv unter [https://www.fints.org](http://www.fints.org/) gefunden werden. + + +## C.1 Verwalten der Online-Banking-PIN + + +### C.1.1 PIN-Änderung + +Dieser Geschäftsvorfall bewirkt die Änderung der PIN. Zur Änderung der PIN ist im +Signaturabschluss die alte PIN; der Geschäftsvorfall selbst enthält die neue PIN. + +Folgende Ereignisse können Auslöser zur Änderung der PIN sein: + +. Erstzugang zum Online Banking - hier ist die vom Institut vergebene PIN durch +eine persönliche PIN zu ersetzen. + +Dazu wird in der Dialoginitialisierung vom Kreditinstitut der Code 3916 (,PIN +muss wegen erstmaliger Anmeldung zwangsweise geändert werden“) zurück +gemeldet. Der Kunde muss in der folgenden Nachricht zwingend eine PIN- +Änderungsnachricht senden. + +. Auf Wunsch des Kunden + +· Zwangsänderung bei Verdacht auf Kompromittierung + +Die Abläufe zur Durchführung einer PIN-Änderung im Kontext der starken Kun- +denauthentifizierung befinden sich in den Abschnitten B.4.3.1.1(Erstzugang) und +B.4.3.1.2 (Zwangsänderung). + +Hinweis: mit Einführung der starken Kundenauthentifizierung muss eine PIN- +Änderung obligatorisch mit einer TAN authentifiziert werden. Hierzu muss der Ge- +schäftsvorfall „PIN-Änderung“ im Parametersegment HIPINS als TAN-pflichtig de- +klariert sein. + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
62		Stand: 23.02.2018Kapitel: PIN/TAN-Management
Abschnitt: Verwalten der Online-Banking-PIN
+ + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +#### a) Kundenauftrag + + +##### Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:PIN ändern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKPAE
Bezugssegment:-
Segmentversion:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2PIN1DEan.99O1
+ + +##### ◆ Belegungsrichtlinien + +PIN + +Es ist die neue PIN anzugeben. + + +##### b) Kreditinstitutsrückmeldung + + +##### ◆ Erläuterungen + +Es werden keine Datensegmente zurückgemeldet. + + +##### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020PIN geändert
9942neue PIN ungültig
+ + +##### c) Bankparameterdaten + + +##### Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + +##### ◆ Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:PIN ändern Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIPAES
Bezugssegment:HKVVB
Segmentversion:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: B
Dokument:Security - Sicherheitsverfahren PIN/TAN
Kapitel:PIN/TAN-ManagementStand:Seite:
Abschnitt:Sperren der Online-Banking-PIN23.02.201863
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum.3M1
3Anzahl Signaturen minde- stens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + +## C.2 Sperren der Online-Banking-PIN + +Es ist zu unterscheiden zwischen Sperren, die vom Kreditinstitut automatisch durch +eine mehrfach falsche Benutzereingabe veranlasst werden, und Sperren, die be- +wusst vom Benutzer initiiert werden. + + +### C.2.1 Sperre bei mehrmaliger Falscheingabe + +Bei jedem Erhalt einer falsch signierten Nachricht für einen noch nicht gesperrten +Benutzer (z. B. falsche PIN oder ungültige TAN) wird der jeweilige Fehlbedienungs- +zähler (PIN oder TAN) erhöht. Nach Überschreiten des vom Kreditinstitut vorgege- +benen Wertes wird eine Sperre vorgenommen. Eine erfolgte Sperre wird dem Be- +nutzer mittels eines Rückmeldungscodes (9931: Sperre durchgeführt) mitgeteilt. + +Sofern das Kreditinstitut dies zulässt, ist eine Entsperrung mit Hilfe des Geschäfts- +vorfalls ,,PIN-Sperre aufheben" (Kap. C.2.3) möglich. Andernfalls kann die Sperre +nur vom Kreditinstitut aufgehoben werden. + +Der Umfang der Sperre ist institutsabhängig und kann dem Kunden im Rahmen der +Rückmeldung detaillierter mitgeteilt werden. + + +#### Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
9931PIN gesperrt
9931Online-Zugang gesperrt
9931SB-Zugang gesperrt
9931Konto gesperrt
+ + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
64		Stand: 23.02.2018Kapitel: PIN/TAN-Management
Abschnitt: Sperren der Online-Banking-PIN
+ + +### C.2.2 PIN-Sperre + +Dieser Geschäftsvorfall bewirkt eine Sperre durch den Kunden. Der Umfang der +Sperre ist institutsabhängig und kann dem Kunden im Rahmen der Rückmeldung +detaillierter mitgeteilt werden. + +Das Sperren des Online-Banking-Zugangs durch den Benutzer erfordert analog zu +den HBCI-Signaturverfahren DDV und RAH die Eingabe einer gültigen PIN, selbst +wenn diese kompromittiert sein sollte. + +Realisierung Bank: +optional + +Realisierung Kunde: optional + + +## a) Kundenauftrag + + +## Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:PIN sperren
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKPSP
Bezugssegment:-
Segmentversion:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
+ + +## ◆ Belegungsrichtlinien + +Der Signaturabschluss muss eine gültige PIN enthalten. + + +## b) Kreditinstitutsrückmeldung + + +## ◆ Erläuterungen + +Es werden keine Datensegmente zurückgemeldet. + + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020PIN-Sperre erfolgreich
0020Konto-Sperre erfolgreich
0020Sperre erfolgreich. Zur Entsperrung wenden Sie sich bitte an Ihr Kreditinstitut
+ + +## c) Bankparameterdaten + + +## Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: B
Dokument:Security - Sicherheitsverfahren PIN/TAN
Kapitel:PIN/TAN-ManagementStand:Seite:
Abschnitt:Sperren der Online-Banking-PIN23.02.201865
+ + +## ◆ Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:PIN sperren Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIPSPS
Bezugssegment:HKVVB
Segmentversion:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen minde- stens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + +### C.2.3 PIN-Sperre aufheben + +Dieses Segment bewirkt das Aufheben einer PIN-Sperre. Wurde eine Online-Sperre +auf ein Konto gelegt (i.d.R. durch mehrmalige Eingabe einer falschen PIN), kann +das Konto durch die Eingabe der richtigen PIN und einer gültigen TAN wieder ent- +sperrt werden (PIN und TAN befinden sich im Signaturabschluss). + + +![](figures/65.1) + + +Da bei gesperrter PIN im Regelfall kein weiterer Dialog möglich ist, +da bereits die Dialoginitialisierung abgelehnt wird, kann dieser Ge- +schäftsvorfall nur angeboten werden, wenn das Kreditinstitut nach +einer PIN-Sperre einen weiteren Dialog mit der gesperrten PIN zu- +lässt, sofern in diesem nur der Geschäftsvorfall „PIN-Sperre aufhe- +ben“ gesendet wird. + + +![](figures/65.2) + + +In der Regel wird kreditinstitutsseitig nur ein einziger Versuch zur +Aufhebung der PIN-Sperre zugelassen. Schlägt dieser fehl, kann +nur das Kreditinstitut entsperren. + +Realisierung Bank: optional + +Realisierung Kunde: optional + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite: 66Stand: 23.02.2018Kapitel: PIN/TAN-Management
Abschnitt: Sperren der Online-Banking-PIN
+ + +## a) Kundenauftrag + + +### Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:PIN-Sperre aufheben
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKPSA
Bezugssegment:-
Segmentversion:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
+ + +### b) Kreditinstitutsrückmeldung + + +## ◆ Erläuterungen + +Es werden keine Datensegmente zurückgemeldet. + + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + +Code +Beispiel für Rückmeldungstext + +0020 +PIN-Sperre aufgehoben + + +## c) Bankparameterdaten + + +## Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + +## ◆ Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:PIN-Sperre aufheben Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIPSAS
Bezugssegment:HKVVB
Segmentversion:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen minde- stens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: B
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FV
Kapitel:PIN/TAN-ManagementStand:Seite:
Abschnitt:Management chipTAN, mobileTAN und bilaterale Verfahren23.02.201867
+ + +# C.3 Management chipTAN, mobileTAN und bilaterale Verfahren + + +## C.3.1 Anzeige der verfügbaren TAN-Medien + +Mit Hilfe dieses Geschäftsvorfalls wird dem Kunden eine Übersicht über seine ver- +fügbaren TAN-Medien (TAN-Generator) gegeben. + +Der Kunde muss auch im Hinblick auf das TAN-Zwei-Schritt-Verfahren wissen, wel- +ches Medium er verwenden darf. Hierzu werden ihm seine verfügbaren Medien +(Kartennummern) mit ihrem aktuellen Status angezeigt. Es wird dahingehend unter- +schieden, ob das Medium „Verfügbar" oder ,,Aktiv" ist. Folgekarten werden separat +mit eigenen Kennzeichen versehen, da mit der ,Aktivierung“ der Folgekarte die ak- +tuelle Karte für die TAN-Generierung gesperrt wird. + + + + + + + + + + + + + + + + + + + + + + + +
StatusErläuterungen
VerfügbarDas Medium kann genutzt werden, muss aber zuvor mit "TAN-Generator an- bzw. ummelden (HKTAU)" aktiv ge- meldet werden.
AktivDie Bank zeigt an, dass es eine TAN-Verifikation gegen dieses Medium vornimmt.
Verfügbare FolgekarteDas Medium kann mit dem Geschäftsvorfall „TAN-Medium an- bzw. ummelden (HKTAU)" aktiv gemeldet werden. Die aktuelle Karte kann dann nicht mehr genutzt werden.
Aktiv FolgekarteMit der ersten Nutzung der Folgekarte wird die zur Zeit ak- tive Karte gesperrt.
+ + +Anmerkung: Wenn eine Bank mehrere Medien in dem Status ,,Aktiv“ verwalten kann, +dann muss beim Zwei-Schritt-Verfahren dem Institut zuvor mit dem Geschäftsvorfall +,TAN-Medium an- bzw. ummelden“ (HKTAU) mitgeteilt werden, welches Medium für +die Signatur des Geschäftsvorfalles verwendet werden soll. + + +## C.3.1.1Anzeigen der verfügbaren TAN-Medien, Segmentversion #5 + +Bei Segmentversion #5 wird gegenüber der Vorgängerversion in der Kundennach- +richt durch das Datenelement ,,TAN-Medium-Klasse #4" die Unterstützung von bila- +teral vereinbarten Verfahren möglich. + +Realisierung Bank: optional + +Realisierung Kunde: optional + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
68		Stand: 23.02.2018Kapitel: PIN/TAN-Management
Abschnitt: Management chipTAN, mobileTAN und bilaterale Verfahren
+ + +# a) Kundenauftrag + + +## Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:TAN-Generator/Liste anzeigen Bestand
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKTAB
Bezugssegment:-
Segmentversion:5
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2TAN-Medium-Art2DEcode1M10, 1, 2
3TAN-Medium- Klasse4DEcode1M1A, L, G, M, S, B
+ + +## b) Kreditinstitutsrückmeldung + + +# Erläuterungen + +Es wird ein Datensegment zurückgemeldet. + + +## ◆ Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:TAN-Generator/Liste anzeigen Bestand Rückmeldung
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HITAB
Bezugssegment:HKTAB
Segmentversion:5
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2TAN-Einsatzoption1DEcode1M10, 1, 2
3TAN-Medium-Liste5DEGO99
+ + +# ◆ Belegungsrichtlinien + + +## TAN-Medium-Liste + +Darf nur belegt werden, wenn für den Kunden ein TAN-Medium verfügbar / +nutzbar ist. + +Beim mobileTAN-Verfahren (TAN-Medium-Klasse="M") muss entweder das +Datenelement ,,Mobiltelefonnummer“ oder ,,Mobiltelefonnummer verschleiert“ +angegeben werden. + +Bei bilateral vereinbarten Verfahren (TAN-Medium-Klasse="B") muss das Da- +tenelement ,,Sicherheitsfunktion, kodiert" angegeben werden. Die ,,Sicherheits- +funktion, kodiert" beinhaltet den Wert für das bilateral vereinbarte Verfahren in +der DEG ,,Verfahrensparameter Zwei-Schritt-Verfahren“. + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: B
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FV
Kapitel:PIN/TAN-ManagementStand:Seite:
Abschnitt:Management chipTAN, mobileTAN und bilaterale Verfahren23.02.201869
+ + +# ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag verarbeitet
+ + +# c) Bankparameterdaten + + +## Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + +# ◆ Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:TAN-Generator/Liste anzeigen Bestand Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HITABS
Bezugssegment:HKVVB
Segmentversion:5
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
70		Stand: 23.02.2018Kapitel: PIN/TAN-Management
Abschnitt: Management chipTAN, mobileTAN und bilaterale Verfahren
+ + +## C.3.1.2Übermitteln / Anzeigen von TAN-Generator (HHD)- und Secoder-Informationen + +Dieser Geschäftsvorfall dient dazu, Informationen über die Eigenschaften eines +TAN-Generators (HHD) oder Secoders vom Kundenprodukt an das Kreditinstitut zu +senden. Das Kreditinstitut kann mit diesen Daten zum Einen seine eigene Be- +standsverwaltung pflegen, aber auch entsprechende Informationen, die sich aus +den übertragenen Daten ergeben, zurück melden. + +So kann z. B. ein Kunde die eindeutige Reader-ID seines TAN-Generators ermitteln +(per HotKey oder durch die Challenge-Klasse 09 seines HHD - vgl. [HHD]) und die- +se an das Kreditinstitut übermitteln. Durch Interpretation der Reader-ID kann das +Institut z. B. Hersteller, Gerätetyp und Version der Firmware ermitteln und in der +Kreditinstitutsantwort an den Kunden übertragen. + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +# a) Kundenauftrag + + +# Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:HHD/Secoder-Informationen übermitteln
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKHSI
Bezugssegment:-
Segmentversion:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2TAN-Medium- Klasse2DEcode1M1G, S
3Reader-ID1DEid#C1M: bei DE ,,TAN-Medium- Klasse" = ,G" und DE ,,Reader-ID erforderlich" = „J“
O: bei DE ,,TAN-Medium- Klasse" = ,G" und DE ,Reader-ID erforderlich" = „N“ N: sonst
4Verfahrensbestäti- gung1DEjn#C1M: bei DE ,,Verfahrensbe- stätigung erforderlich“ = „J“ (BPD)
O: sonst
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: B
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FV
Kapitel:PIN/TAN-ManagementStand:Seite:
Abschnitt:Management chipTAN, mobileTAN und bilaterale Verfahren23.02.201871
+ + +# ◆ Belegungsrichtlinien + + +## TAN-Medium-Klasse + +Als TAN-Medium-Klasse kann entweder ,,G“ für TAN-Generator bzw. HHD +oder „S“ für Secoder angegeben werden. + + +## Reader-ID + +Bei der TAN-Medium-Klasse ,,G“ für HHD kann die Reader-ID belegt werden, +wenn diese institutsseitig nicht bekannt ist und abgeglichen bzw. erfasst wer- +den soll. Durch den BPD-Parameter ,,Reader-ID erforderlich" kann gesteuert +werden, ob die Angabe der Reader-ID zwingend für die Ausführung des Ge- +schäftsvorfalls erforderlich ist. + +Bei der TAN-Medium-Klasse ,,S“ für Secoder darf die Reader-ID nicht übertra- +gen werden, da diese als Teil des Sicherheitskonzeptes im Rahmen der ,,Vi- +sualisation Authentication" des Secoders als gemeinsames Geheimnis zwi- +schen Secoder und Institutsseite verwendet wird. + + +## b) Kreditinstitutsrückmeldung + + +## Erläuterungen + +Es wird ein Datensegment zurückgemeldet. + + +## ◆ Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:HHD/Secoder Informationen rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIHSI
Bezugssegment:HKHSI
Segmentversion:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Reader-ID1DEid#C1O: bei DE ,,TAN-Medium- Klasse“ = „G“ N: sonst
3Gerätehersteller1DEan..64O1
4Geräteklasse1DEan.64O1
5Gerätebezeichnung1DEan.64O1
6Geräteversion1DEan..64O1
+ + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag verarbeitet
+ + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
72		Stand: 23.02.2018Kapitel: PIN/TAN-Management
Abschnitt: Management chipTAN, mobileTAN und bilaterale Verfahren
+ + +## c) Bankparameterdaten + + +### Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:HHD/Secoder Informationen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIHSIS
Bezugssegment:HKVVB
Segmentversion:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter HHD/Secoder In- formationen1DEGM1
+ + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: B
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FV
Kapitel:
Abschnitt:		PIN/TAN-Management
Management chipTAN, mobileTAN und bilaterale Verfahren		Stand: 23.02.2018Seite: 73
+ + +#### C.3.2 TAN-Medium an- bzw. ummelden in Segmentversion #3 + +Mit Hilfe dieses Geschäftsvorfalls kann der Kunde seinem Institut mitteilen, welches +Medium (Chipkarte, TAN-Generator oder bilateral vereinbart) er für die Autorisierung +der Aufträge per TAN verwenden wird. + +Welches Medium gerade aktiv ist, kann mit Hilfe des Geschäftsvorfalls „TAN- +Medium anzeigen Bestand (HKTAB)“ bzw. für Detailinformationen zur Karte auch +„Kartenanzeige anfordern (HKAZK)" durch den Kunden erfragt werden. + +Der Kunde entscheidet selbst, welches seiner verfügbaren TAN-Medien er verwen- +den möchte. + +chipTAN-Verfahren: + +Steht beim chipTAN-Verfahren ein Kartenwechsel an, so kann der Kunde mit die- +sem Geschäftsvorfall seine Karte bzw. Folgekarte aktivieren. Kann der Kunde meh- +rere Karten verwenden, dann kann mit diesem GV die Ummeldung auf eine andere +Karte erfolgen. Das Kreditinstitut entscheidet selbst, ob dieser GV TAN-pflichtig ist +oder nicht. + +Realisierung Bank: +optional + +Realisierung Kunde: optional + + +## a) Kundenauftrag + + +## Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:TAN-Medium an- bzw. ummelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKTAU
Bezugssegment:-
Segmentversion:3
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2TAN-Medium- Klasse4DEcode1M1A, L, G, M, S, B
3Kartennummer1DEid#C1M: DE ,,TAN-Medium- Klasse“=“G“ N: sonst
4Kartenfolgenummer1DEid#C1M: DE ,,TAN-Medium- Klasse"="G" und DE ,,Ein- gabe Kartenfolgenummer J/N" (BPD)="J" N: sonst
5Kartenart1DEnum..2C1O: DE ,,TAN-Medium- Klasse"="G" und DE ,,Ein- gabe Kartenart zulässig“ (BPD) = „J“ N: sonst
6Kontoverbindung international Auf- traggeber1DEkti#C1M: DE ,,TAN-Medium- Klasse"="G" und DE ,,Kon- toverbindung erforderlich" (BPD)="J"
+ + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
74		Stand: 23.02.2018Kapitel: PIN/TAN-Management
Abschnitt: Management chipTAN, mobileTAN und bilaterale Verfahren
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
O: sonst
7gültig ab1DEdat#C1O: DE ,,TAN-Medium- Klasse“=“G“ N: sonst
8gültig bis1DEdat#C1O: DE ,,TAN-Medium- Klasse“=“G“ N: sonst
9ICCSN1DEnum.. 19C1O: DE ,,TAN-Medium- Klasse“=“G“ N: sonst
10TAN-Listennummer1DEan..20C1M: DE ,,TAN-Medium- Klasse"="L" und DE ,,Ein- gabe TAN-Listennummer J/N" (BPD)="J" O: DE „TAN-Medium- Klasse"="L" und DE ,,Ein- gabe TAN-Listennummer J/N" (BPD)="N" N: sonst
11ATC1DEnum..5C1M: DE ,,TAN-Medium- Klasse"="G" und DE ,,Ein- gabe von ATC und TAN er- forderlich" (BPD)="J" N: sonst
12TAN1DEan.99C1M: DE ,,TAN-Medium- Klasse"="G" und DE ,,Ein- gabe von ATC und TAN er- forderlich" (BPD)="J" N: sonst
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: B
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FV
Kapitel:PIN/TAN-ManagementStand:Seite:
Abschnitt:Management chipTAN, mobileTAN und bilaterale Verfahren23.02.201875
+ + +# ◆ Belegungsrichtlinien + +TAN-Listennummer + +Wird keine TAN-Listennummer angegeben, so wird die aktuelle / freigeschal- +tete Liste verwendet. + +Gültig ab, Gültig bis + +Die übliche Angabe im Format JJMM muss in diesem Fall auf ein existieren- +des Datumsformat umgesetzt werden (z. B. Gültig bis „9912“ wird umgesetzt +in „19991231“). + +Kartenart + +Die Eingabe der Kartenart wird über den BPD-Parameter ,,Eingabe Kartenart +zulässig“ gesteuert. Ist dieser Parameter auf „J“ gesetzt, enthält das BPD- +Segment HITAUS auch die zulässigen Kartenarten. + + +# b) Kreditinstitutsrückmeldung + + +# ◆ Format + +Allgemeine Kreditinstitutsnachricht ohne Datensegmente + +Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020An- bzw. Ummeldung erfolgreich
9935An- bzw. Ummeldung fehlgeschlagen
9935Kartennummer unbekannt
9935Karte als TAN-Generator nicht zugelassen - bitte wenden Sie sich an Ihr Institut
+ + +# c) Bankparameterdaten + + +# Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:TAN-Medium an- bzw. ummelden Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HITAUS
Bezugssegment:HKVVB
Segmentversion:2
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter TAN- Generator An- bzw. Ummelden3DEGM1
+ + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
76		Stand: 23.02.2018Kapitel: PIN/TAN-Management
Abschnitt: Management chipTAN, mobileTAN und bilaterale Verfahren
+ + +## C.3.3 TAN-Generator Synchronisierung + +Mit Hilfe dieses Geschäftsvorfalls ist eine explizite Synchronisierung eines TAN- +Generators nach dem chipTAN-Verfahren möglich. Als „TAN-Generator" wird die +entsprechende TAN-Applikation (Debit oder Credit) auf der SECCOS-Chipkarte be- +zeichnet. Im Regelfall erfolgt die Synchronisierung implizit, d. h. das Kreditinstituts- +system führt aufgrund eines Vergleichs des in der TAN übermittelten Zählers (ATC) +und des im Institut geführten Zählers eine automatische Synchronisierung durch. +Falls aufgrund eines zu starken Divergierens dieser beiden Zähler eine implizite +Synchronisierung nicht mehr möglich ist, muss der Kunde durch diesen Geschäfts- +vorfall eine explizite Synchronisierung veranlassen. + +Um die Synchronisierung durchführen zu können, muss der Kunde den aktuellen +ATC im chipTAN-Lesegerät zur Anzeige bringen und zusammen mit der zugehöri- +gen TAN an das Kreditinstitut übermitteln. Diese TAN wird zusammen mit der PIN +im Sicherheitskopf übertragen. + + +![](figures/76.1) + + +Da bei der vierten Falscheingabe der TAN-Generator kreditinsti- +tutsseitig gesperrt wird, sollte das Kundenprodukt den Kunden spä- +testens nach der dritten Ablehnung einer TAN zu einer expliziten +Synchronisierung auffordern, da in diesem Fall zu vermuten ist, +dass der Fehler nicht auf einer Falscheingabe des Kunden, sondern +auf einem Synchronisierungsproblem beruht. + +Realisierung Bank: verpflichtend, wenn das chipTAN-Verfahren unterstützt wird +Realisierung Kunde: optional + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: B
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FV
Kapitel:PIN/TAN-ManagementStand:Seite:
Abschnitt:Management chipTAN, mobileTAN und bilaterale Verfahren23.02.201877
+ + +# a) Kundenauftrag + + +## Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:TAN-Generator Synchronisierung
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKTSY
Bezugssegment:-
Segmentversion:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2ATC1DEnum..5M1
3TAN1DEan.99M1
4Kartennummer1DEid#C1M: DE ,,Eingabe der Kar- tennummer J/N" (BPD)="J" N: sonst
5Kartenfolgenummer1DEid#C1M: DE ,,Eingabe der Karten- folgenummer J/N" (BPD)="J" N: sonst
+ + +## b) Kreditinstitutsrückmeldung + + +# ◆ Format + +Allgemeine Kreditinstitutsnachricht ohne Datensegmente + + +# ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Synchronisierung erfolgreich
3931TAN-Generator gesperrt, Synchronisierung erforderlich
3933TAN-Generator gesperrt, Synchronisierung erforderlich Kartennummer ##########
9931TAN-Generator gesperrt
9931Online-Zugang gesperrt
+ + +# c) Bankparameterdaten + + +# Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:TAN-Generator Synchronisierung Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HITSYS
Bezugssegment:HKVVB
Segmentversion:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
78		Stand: 23.02.2018Kapitel: PIN/TAN-Management
Abschnitt: Management chipTAN, mobileTAN und bilaterale Verfahren
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter TAN- Generator Syn- chronisierung1DEGM1
+ + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: B
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FV
Kapitel:
Abschnitt:		PIN/TAN-Management
Management chipTAN, mobileTAN und bilaterale Verfahren		Stand: 23.02.2018Seite: 79
+ + +# C.3.4 Verwalten von Mobilfunkverbindungen + + +## C.3.4.1Mobilfunkverbindung registrieren + + +### C.3.4.1.1 Mobilfunkverbindung registrieren in Segmentversion #3 + +Mit Hilfe dieses Geschäftsvorfalls kann ein Kunde sein Mobilfunkverbindung regist- +rieren. + + +![](figures/79.1) + + +![](figures/79.2) + + +Dieser Geschäftsvorfall kann auch mit der Segmentkennung +HKMTS verwendet werden. Damit ist es möglich, den Geschäftsvor- +fall mit unterschiedlicher Belegung des Parameters ,,Abbuchungs- +konto erforderlich" in der BPD zur Verfügung zu stellen und damit +über die UPD eine kundenspezifische Abrechnung der SMS-Kosten +zu erreichen. + + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +#### a) Kundenauftrag + + +##### Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Mobilfunkverbindung registrieren
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKMTR
Bezugssegment:-
Segmentversion:3
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2TAN-Medium- Klasse4DEcode1M1M, B
3Mobiltelefonnum- mer1DEan..35M1M: DE ,,TAN-Medium- Klasse=“M“ O: sonst
4Bezeichnung des TAN-Mediums1DEan.32M1
5SMS- Abbuchungskonto1DEGkti#C1M: DE „SMS- Abbuchungskonto erforder- lich J/N" (BPD)="J" O: sonst
6Kontaktaufnahme durch Kreditinstitut erlaubt1DEjn#C1M: DE ,,Zustimmung zur Kontaktaufnahme unter- stützt“ (BPD)=“J“ O: sonst
+ + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
80		Stand: 23.02.2018Kapitel: PIN/TAN-Management
Abschnitt: Management chipTAN, mobileTAN und bilaterale Verfahren
+ + +#### ◆ Belegungsrichtlinien + + +##### Mobiltelefonnummer + +Es muss die Mobiltelefonnummer verwendet werden, die mit dem Institut für +die Nutzung von mobileTAN vereinbart ist. Es sind nur Ziffern inklusive füh- +render Nullen erlaubt und es gilt die nationale Schreibweise für Telefonnum- +mern, z. B. 0170/1234567 oder (0170) 1234567. + + +![](figures/80.1) + + +Das Kundensystem sollte den Kunden bei der Eingabe eines +korrekten Telefonnummern-Formates unterstützen. + + +![](figures/80.2) + + +Falls der Prozess vorsieht, dass die Registrierung der Mobilte- +lefonnummer zuvor auf alternativem Weg erfolgen muss, kön- +nen nur im Vorfeld vereinbarte Rufnummern verwendet wer- +den. Das Institut muss in diesem Fall die Existenz einer ent- +sprechenden Vereinbarung prüfen. + + +#### b) Kreditinstitutsrückmeldung + + +##### ◆ Erläuterungen + +Es werden keine Datensegmente zurückgemeldet. + + +##### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag verarbeitet
9939MobileTAN-Mobilrufnummer nicht zur Registrierung zugelassen
9939Format der mobileTAN-Mobilrufnummer nicht korrekt
9939MobileTAN-Mobilrufnummer bereits registriert
+ + +##### c) Bankparameterdaten + + +##### ◆ Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Mobilfunkverbindung registrieren Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIMTRS
Bezugssegment:HKVVB
Segmentversion:3
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: B
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FV
Kapitel:
Abschnitt:		PIN/TAN-Management
Management chipTAN, mobileTAN und bilaterale Verfahren		Stand: 23.02.2018Seite: 81
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DENum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Mobil- funkverbindung re- gistrieren2DEGM1
+ + +## C.3.4.2Mobilfunkverbindung freischalten + + +### C.3.4.2.1 Mobilfunkverbindung freischalten in Segmentversion #3 + +Mit Hilfe dieses Geschäftsvorfalls kann ein Kunde seine zuvor registrierte Mobil- +funkverbindung freischalten. + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +## a) Kundenauftrag + + +## Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Mobilfunkverbindung freischalten
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKMTF
Bezugssegment:-
Segmentversion:3
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2TAN-Medium- Klasse4DEcode1M1M, B
3Bezeichnung des TAN-Mediums1DEan.32M1
4Freischaltcode2DEan..64M1
+ + +## b) Kreditinstitutsrückmeldung + + +## Erläuterungen + +Es werden keine Datensegmente zurückgemeldet. + + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Mobiltelefon für mobileTAN freigeschaltet
9939mobileTAN-Mobilrufnummer kann nicht freigeschaltet werden
+ + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
82		Stand: 23.02.2018Kapitel: PIN/TAN-Management
Abschnitt: Management chipTAN, mobileTAN und bilaterale Verfahren
+ + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
3939mobileTAN-Freischaltung erforderlich. SMS-Freischaltcode wurde versendet
+ + +## c) Bankparameterdaten + + +### . Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + +## ◆ Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Mobilfunkverbindung freischalten Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIMTFS
Bezugssegment:HKVVB
Segmentversion:3
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + +# C.3.4.3Mobilfunkverbindung ändern + + +## C.3.4.3.1 Mobilfunkverbindung ändern in Segmentversion #3 + +Mit Hilfe dieses Geschäftsvorfalls kann ein Kunde seine Mobilfunkverbindung bzw. +die damit verbundenen Informationen ändern. + + +![](figures/82.1) + + +![](figures/82.2) + + +Dieser Geschäftsvorfall kann auch mit der Segmentkennung +HKMTB verwendet werden. Damit ist es möglich, den Geschäftsvor- +fall mit unterschiedlicher Belegung des Parameters ,,Abbuchungs- +konto erforderlich" in der BPD zur Verfügung zu stellen und damit +über die UPD eine kundenspezifische Abrechnung der SMS-Kosten +zu erreichen. + +Realisierung Bank: optional + +Realisierung Kunde: optional + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: B
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FV
Kapitel:
Abschnitt:		PIN/TAN-Management
Management chipTAN, mobileTAN und bilaterale Verfahren		Stand: 23.02.2018Seite: 83
+ + +# a) Kundenauftrag + + +## Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Mobilfunkverbindung ändern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKMTA
Bezugssegment:-
Segmentversion:3
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2TAN-Medium- Klasse4DEcode1M1M, B
3Mobiltelefonnum- mer1DEan..35M1M: DE „TAN-Medium- Klasse=“M“ O: sonst
4Bezeichnung des TAN-Mediums alt1DEan..32M1
5Bezeichnung des TAN-Mediums neu1DEan..32M1
6SMS- Abbuchungskonto1DEGkti#O1M: DE „SMS- Abbuchungskonto erforder- lich J/N" (BPD)="J" O: sonst
7Kontaktaufnahme durch Kreditinstitut erlaubt1DEjn#C1M: DE ,,Zustimmung zur Kontaktaufnahme unter- stützt“ (BPD)=“J“ O: sonst
+ + +## ◆ Belegungsrichtlinien + + +### Bezeichnung des TAN-Mediums alt + +Es muss die vereinbarte Bezeichnung einer bestehenden und frei geschalte- +ten Mobiltelefonnummer verwendet werden. + + +### b) Kreditinstitutsrückmeldung + + +## Erläuterungen + +Es werden keine Datensegmente zurückgemeldet. + + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag verarbeitet
9939MobileTAN-Mobilrufnummer nicht zur Registrierung zugelassen
9939Format der mobileTAN-Mobilrufnummer nicht korrekt
9939MobileTAN-Mobilrufnummer bereits registriert
9939alte mobileTAN-Mobilfunknummer existiert nicht oder ist nicht freigeschaltet
+ + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
84		Stand: 23.02.2018Kapitel: PIN/TAN-Management
Abschnitt: Management chipTAN, mobileTAN und bilaterale Verfahren
+ + +## c) Bankparameterdaten + + +### Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Mobilfunkverbindung registrieren Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIMTAS
Bezugssegment:HKVVB
Segmentversion:3
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Mobil- funkverbindung än- dern2DEGM1
+ + +#### C.3.4.4Deaktivieren / Löschen von TAN-Medien + + +##### C.3.4.4.1 Deaktivieren / Löschen von TAN-Medien, Segmentversion #2 + +Mit Hilfe dieses Geschäftsvorfalls kann ein Kunde ein aktives bzw. verfügbares +TAN-Medium deaktivieren oder löschen. + +Deaktivieren, bewirkt eine Statusänderung von „aktiv“ nach „verfügbar“ für das ge- +wählte TAN-Medium. + +Beim Löschvorgang wird das entsprechende TAN-Medium gänzlich von der Liste +der TAN-Medien genommen. Dieser Vorgang kann nicht mehr rückgängig gemacht +werden. + +Realisierung Bank: optional + +Realisierung Kunde: optional + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: B
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FV
Kapitel:PIN/TAN-ManagementStand:Seite:
Abschnitt:Management chipTAN, mobileTAN und bilaterale Verfahren23.02.201885
+ + +### a) Kundenauftrag + + +#### Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:TAN-Medium deaktivieren oder löschen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKTML
Bezugssegment:-
Segmentversion:2
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2TAN-Medium- Klasse4DEcode1M1A, L, G, M, S, B
3TAN-Listennummer1DEan..20C1M: DE ,,TAN-Medium- Klasse“=“L“ N: sonst
4Bezeichnung des TAN-Mediums1DEan.32C1M: DE ,,TAN-Medium- Klasse"="M" oder „TAN- Medium-Klasse"="B" N: sonst
5Deaktivie- ren/Löschen1DEcode1M1
+ + +#### ◆ Belegungsrichtlinien + + +##### TAN-Medium-Klasse + +Es muss die zu deaktivierende / zu löschende TAN-Medium-Klasse angege- +ben werden. Bei Angabe von TAN-Medium-Klasse"G" wird die als aktiv defi- +nierte Kombination aus TAN-Generator und Karte gelöscht bzw. deaktiviert. +Bei TAN-Medium-Klasse="L" oder ,,M" / ,B" muss die Angabe der TAN- +Listennummer bzw. der Bezeichnung des TAN-Mediums erfolgen. + + +![](figures/85.1) + + +Das Kundensystem sollte den Kunden darauf hinweisen, +wenn er versuchen will, das letzte im Bestand des Kunden- +systems bekannte TAN-Medium zu deaktivieren oder zu lö- +schen. + + +### b) Kreditinstitutsrückmeldung + + +## Erläuterungen + +Es werden keine Datensegmente zurückgemeldet. + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
86		Stand: 23.02.2018Kapitel: PIN/TAN-Management
Abschnitt: Management chipTAN, mobileTAN und bilaterale Verfahren
+ + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag verarbeitet
9958Deaktivieren / Löschen für TAN-Medium nicht möglich
9958TAN-Medium nicht bekannt
+ + +## c) Bankparameterdaten + + +## Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + +## ◆ Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:TAN-Medium deaktivieren oder löschen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HITMLS
Bezugssegment:HKVVB
Segmentversion:2
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FVB
Kapitel:
Abschnitt:		Sonstige
PIN/TAN-Management		Stand: 23.02.2018Seite: 87
+ + +# C.4 Sonstige + + +## C.4.1 TAN-Verbrauchsinformationen anzeigen + +Dieses Segment bewirkt die Anzeige der verbrauchten TANs des Kunden. + + +## C.4.1.1TAN-Verbrauchsinformationen anzeigen, Segmentversion #2 + +Dieses Segment bewirkt die Anzeige der verbrauchten TANs des Kunden. In Seg- +mentversion #2 wurden in der DEG ,,TAN-Information" die Datenelementgruppen +,Entgelte-Abbuchungskonto" und „Transaktionskonto“ ergänzt, um beim z. B. mobi- +leTAN-Verfahren eine PSD-konforme Information für den Kunden zu ermöglichen, +auf welche Kontoverbindung die ggf. entstandenen SMS-Entgelte belastet wurden +und für welches Konto die Transaktion durchgeführt wurde. Das Transaktionskonto +kann insbesondere für eine Aufteilung der entstandenen Entgelte dienen, wenn ge- +nerell nur ein Entgelte-Abbuchungskonto für alle Konten gemeinsam verwendet +wird. Weiterhin wird in Segmentversion #2 die Möglichkeit geboten, durch die Anga- +be der Elemente ,,Von Datum" und ,,Bis Datum" in der Kundennachricht TAN- +Verbrauchsinformationen ein dadurch definiertes Zeitfenster auszugeben. + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +# a) Kundenauftrag + + +## Beschreibung + +Das Auftragssegment enthält neben dem Segmentkopf die Angaben ,,Von Datum“ +und ,Bis Datum". Wenn diese beiden Felder in der Kundennachricht mitgeliefert +werden, enthält die Kreditinstitutsantwort TAN-Verbrauchsinformationen, die inner- +halb dieser Datumsgrenzen liegen. + + +## ◆ Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:TAN-Verbrauchsinformationen anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKTAZ
Bezugssegment:-
Segmentversion:2
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Von Datum1DEdat#O1
3Bis Datum1DEdat#O1
+ + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
88		Stand: 23.02.2018Kapitel: PIN/TAN-Management
Abschnitt: Sonstige
+ + +## b) Kreditinstitutsrückmeldung + + +## Beschreibung + +Je zurück zu meldender TAN-Liste ist ein Segment in die Antwortnachricht einzu- +stellen. + + +## ◆ Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:TAN-Verbrauchsinformationen rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HITAZ
Bezugssegment:HKTAZ
Segmentversion:2
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2TAN-Listenstatus1DEcode1O1A, N, S, V
3TAN-Listennummer1DEan.20O1
4Erstellungsdatum1DEdat#O1
5Anzahl TANs pro Liste1DEnum..4O1
6Anzahl verbrauch- ter TANs pro Liste1DEnum..4O1
7TAN-Information2DEGO999
+ + +## . Belegungsrichtlinien + +TAN-Listennummer + +Kennung der TAN-Liste, die zurückgemeldet wird. + + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
+ + +## c) Bankparameterdaten + + +## Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + +## ◆ Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:TAN-Verbrauchsinformationen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HITAZS
Bezugssegment:HKVVB
Segmentversion:2
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: B
Dokument:Security - Sicherheitsverfahren PIN/TAN
Kapitel:PIN/TAN-ManagementStand:Seite:
Abschnitt:Sonstige23.02.201889
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + +### C.4.2 TAN prüfen und ,,verbrennen" + +Um eine TAN prüfen und verbrennen zu lassen, wird dem Benutzer beim Ein- +Schritt-TAN-Verfahren kein spezieller Geschäftsvorfall bereitgestellt. Vielmehr hat er +dort die Möglichkeit, in der Initialisierungsnachricht neben der PIN zusätzlich auch +eine TAN mitzuschicken. + +Diese wird an die Bankanwendung übermittelt und kann dann von dieser geprüft +und entwertet werden. Die Ergebnisse der Prüfung und des Verbrennens werden +von der Bankanwendung als zusätzliche Returncodes innerhalb der Initialisierungs- +antwort zurückgemeldet. + + +#### Zwei-Schritt-Verfahren, Prozessvariante 1 + +Bei Einsatz eines Zwei-Schritt-Verfahrens bei Prozessvariante 1 wird das Prüfen +und ,,Verbrennen" von TANs nicht unterstützt. + + +#### Zwei-Schritt-Verfahren, Prozessvariante 2 + +Bei Einsatz eines Zwei-Schritt-Verfahrens darf die TAN bei Prozessvariante 2 nicht +in die Initialisierungsnachricht eingestellt werden. Die TAN-Eingabe muss über den +Geschäftsvorfall „Zwei-Schritt-TAN-Einreichung" (HKTAN, TAN-Prozess=4) einge- +leitet und über HKTAN, TAN-Prozess=2 abgewickelt werden. + + +![](figures/89.1) + + +Der Geschäftsvorfall „TAN prüfen und verbrennen“ unterscheidet +sich von einem Standardablauf dadurch, dass im ersten Schritt au- +ßer HKTAN kein Geschäftsvorfall übertragen wird. + + +## ◆ Beispiele für mögliche Rückmeldungscodes + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0900TAN gültig
9941TAN ungültig
3913TAN wurde verbraucht
+ + +### C.4.3 PIN prüfen + +Um eine PIN prüfen zu lassen, wird dem Benutzer kein spezieller Geschäftsvorfall +bereitgestellt. Vielmehr ist diese PIN-Prüfung innerhalb der Dialoginitialisierung im- +plizit von der Bankanwendung durchzuführen. Die PIN wird an die Bankanwendung +übermittelt und kann dort geprüft werden. Die Ergebnisse der Prüfung werden von +der Bankanwendung als zusätzliche Returncodes innerhalb der Initialisierungsant- +wort zurückgemeldet. + + + + + + + + + + + + + + + +
Kapitel: BVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite: 90Stand: 23.02.2018Kapitel: PIN/TAN-Management
Abschnitt: Sonstige
+ + +#### ◆ mögliche Rückmeldungscodes + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0901PIN gültig
9942PIN ungültig
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FVD
Kapitel:Data-DictionaryStand:Seite:
Abschnitt:Sonstige23.02.201891
+ + +# D. DATA-DICTIONARY + +A + + +## Antwort HHD_UC + +Enthält im Falle eines bidirektionalen chipTAN-Verfahrens unter Secoder 3 +die Antwortdaten des Secoder-Kommandos ,,SECODER TRANSMIT +HHDUC". + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1ATC1DEan..5M1
2Application Cryp- togram AC1DEbin.256M1
3EF ID Data1DEbin.256M1
4CVR1DEbin.256M1
5Versionsinfo der chipTAN- Applikation1DEbin.256M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +## Antwort HHD_UC erforderlich + +Nur bei bidirektionalen chipTAN-Verfahren: über diesen BPD-Parameter wird +festgelegt, ob die Inhalte der Datenelementgruppe „Antwort HHD_UC" zwin- +gend an das Kreditinstitut übertragen werden müssen oder ob dies optional +ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +## Anzahl Signaturen mindestens + +Mindestanzahl der Signaturen, die für einen Geschäftsvorfall als erforderlich +definiert ist. + +Vom Kreditinstitut wird immer die Minimalanforderung an einen Geschäfts- +vorfall mitgeteilt, d. h. '0', wenn der Geschäftsvorfall auch über den anony- +men Zugang angeboten wird, ansonsten mindestens '1', da Aufträge von +Kunden immer signiert werden müssen. + +Die für Kunden jeweils genaue Angabe der Signaturanzahl ergibt sich in den +UPD aus dem DE ,,Anzahl benötigter Signaturen“. Dabei muss die in den +UPD angegebene Signaturanzahl größer oder gleich der in den BPD ange- + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
92		Stand:
23.02.2018		Kapitel: Data-Dictionary
Abschnitt: Sonstige
+ + +gebenen Anzahl sein. Für Institute, die keine UPD unterstützen, bedeutet +dies, dass der Eintrag '0' in den BPD nur für Nichtkunden gilt und für Kunden +als 'mindestens 1' zu interpretieren ist. + +Der Wert gilt für alle Signaturverfahren. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:1
Version:1
+ + +## Anzahl freie TANs + +Anzahl der noch verfügbaren TANs einer TAN-Liste. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..3
Version:1
+ + +## Anzahl TANs pro Liste + +Anzahl der TANs pro TAN-Liste. Sofern dies das Kreditinstitut anbietet, kann +der Kunde die Anzahl TANs pro Liste bei der Anforderung einer neuen TAN- +Liste wählen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..4
Version:1
+ + +## Anzahl unterstützter aktiver TAN-Listen + +Dieser Parameter wird z. B. bei Verwendung eines indizierten TAN- +Verfahrens eingesetzt. Unterstützt das Institut mehrere aktive TAN-Listen, +kann über diesen Parameter angegeben werden, dass die Eingabe der TAN- +Listennummer erforderlich ist. + +Nicht gesetzt werden muss der Parameter, wenn das Institut mehrere Listen +unterstützt, jedoch der Kunde in der Rückantwort HITAN zusätzlich von der +Bank mitgeteilt bekommt, welche TAN auf welcher Liste zur Freischaltung +angegeben werden muss. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:1
Version:1
+ + +## Anzahl unterstützter aktiver TAN-Medien + +Dieser Parameter wird z. B. bei Verwendung des mobileTAN-Verfahrens o- +der des dynamischen ZKA TAN-Generators eingesetzt. Unterstützt das Insti- +tut mehrere aktive TAN-Medien, kann über diesen Parameter angegeben +werden, dass die Eingabe der Bezeichnung des entsprechenden TAN- +Mediums erforderlich ist. Nicht gesetzt werden muss der Parameter, wenn +das Institut mehrere TAN-Medien unterstützt, jedoch der Kunde in der Rück- +antwort HITAN zusätzlich vom Institut mitgeteilt bekommt, mit welchem TAN- +Medium er die jeweilige TAN erzeugen muss. + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: D
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FV
Kapitel:Data-DictionaryStand:Seite:
Abschnitt:Sonstige23.02.201893
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:1
Version:1
+ + +# Anzahl verbrauchter TANs pro Liste + +Anzahl der verbrauchten TANs pro TAN-Liste. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..4
Version:1
+ + +## Application Cryptogram AC + +Nur bei bidirektionalen chipTAN-Verfahren mit Secoder 3: Bestandteil der +Antwort auf das Secoder-Kommando ,,SECODER TRANSMIT HHDUC". + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:bin
Länge:.256
Version:1
+ + +### ATC + +Der ATC (Application Transaction Counter) ist ein zentraler Bestandteil des +DK-TAN-Generators auf Basis der SECCOS-Chipkarte. Der ATC wird auf +der Chipkarte bei jedem TAN-Generierungsvorgang erhöht. Kreditinsti- +tutsseitig wird der aktuelle ATC jeweils gespeichert und geht auch in die +zentrale TAN-Berechnung mit ein. Sind die ATCs auf Kunden- und Insti- +tutsseite nicht mehr deckungsgleich (bzw. überschreitet die Differenz einen +maximal zulässigen Wert) müssen Synchronisationsverfahren durchgeführt +werden, z. B. eine explizite Synchronisierung über den Geschäftsvorfall +,TAN-Generator synchronisieren" (HKTSY). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..5
Version:1
+ + +### Auftraggeberkonto erforderlich + +Parameter, der angibt, ob eine Zahlungsverkehrskontoverbindung explizit +angegeben werden muss, wenn diese im Geschäftsvorfall enthalten ist. + +Diese Funktion ermöglicht das Sicherstellen einer gültigen Kontoverbindung +z. B. für die Abrechnung von SMS-Kosten bereits vor Erzeugen und Versen- +den einer (ggf. kostenpflichtigen!) TAN. + +Codierung: + +0: Auftraggeberkonto darf nicht angegeben werden + +2: Auftraggeberkonto muss angegeben werden, +wenn im Geschäftsvorfall enthalten + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
94		Stand:
23.02.2018		Kapitel: Data-Dictionary
Abschnitt: Sonstige
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:1
+ + +#### Auftrags-Hashwert + +Er enthält im Falle des Zwei-Schritt-TAN-Verfahrens bei TAN-Prozess=1 den +Hashwert über die Daten eines Kundenauftrags (z. B. ,HKCCS"). Dieser wird +z. B. im Rahmen des Geschäftsvorfalls HKTAN vom Kunden übermittelt und +vom Kreditinstitut in der Antwortnachricht HITAN gespiegelt. + +Das vom Institut verwendete Auftrags-Hashwertverfahren wird in der BPD +übermittelt. In der vorliegenden Version wird RIPEMD-160 verwendet. + +In die Berechnung des Auftrags-Hashwerts geht der Bereich vom ersten bit +des Segmentkopfes bis zum letzten bit des Trennzeichens ein. + +RIPEMD-160 + +Der Hash-Algorithmus RIPEMD-160 bildet Eingabe-Bitfolgen beliebiger Län- +ge auf einen als Bytefolge dargestellten Hash-Wert von 20 Byte (160 Bit) +Länge ab. Teil des Hash-Algorithmus ist das Padding von Eingabe-Bitfolgen +auf ein Vielfaches von 64 Byte. Das Padding erfolgt auch dann, wenn die +Eingabe-Bitfolge bereits eine Länge hat, die ein Vielfaches von 64 Byte ist. +RIPEMD-160 verarbeitet die Eingabe-Bitfolgen in Blöcken von 64 Byte Län- +ge. + +Als Initialisierungsvektor dient die binäre Zeichenfolge X'01 23 45 67 89 AB +CD EF FE DC BA 98 76 54 32 10 F0 E1 D2 C3'. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:bin
Länge:.256
Version:1
+ + +#### Auftrags-Hashwertverfahren + +Information, welches Verfahren für die Hashwertbildung über den Kunden- +auftrag verwendet werden soll. Es sind nur die in [HBCI] beschriebenen Ver- +fahren und deren Parametrisierung (Initialisierungsvektor, etc.) zulässig. + +Codierung: + +0: Auftrags-Hashwert nicht unterstützt + +1: RIPEMD-160 + +2: SHA-1 + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:1
+ + +##### Auftragsreferenz + +Enthält im Falle des Zwei-Schritt-TAN-Verfahrens die Referenz auf einen +eingereichten Auftrag. Die Auftragsreferenz wird bei der späteren Einrei- + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FVD
Kapitel:Data-DictionaryStand:Seite:
Abschnitt:Sonstige23.02.201895
+ + +chung der zugehörigen TANs (mittels HKTAN bei TAN-Prozess=2 bzw. 3) +zur Referenzierung des Auftrags verwendet. + + +![](figures/95.1) + + +Da die Auftragsreferenz immer eindeutig ist, sollten Kun- +denprodukte diese als zentrale Referenzierung verwenden +und dem Kunden auch zusammen mit den Auftragsdaten +präsentieren bzw. für die Problemverfolgung leicht zugäng- +lich machen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:1
+ + +## Auftrag stornieren + +Falls ein Kreditinstitut die Auftragseinreichung mit einer oder mehreren War- +nungen beantwortet, aber trotzdem in HITAN eine Challenge übermittelt, +kann das Kundenprodukt unter Verwendung der zugehörigen TAN den Auf- +trag stornieren. Für die Auftragsstornierung gelten folgende Rahmenbedin- +gungen: + +1\. +Ein Auftragsstorno kann ausschließlich bei Prozessvariante 2 in +TAN-Prozess=2 erfolgen. + +2\. +Der BPD-Parameter ,,Auftragsstorno erlaubt“ ist mit ,,J“ belegt. + +3\. +Die Kreditinstitutsrückmeldung im ersten Schritt (Antwort auf Ein- +reichung von Auftrag und HITAN mit Belegung gemäß TAN- +Prozess=4) enthält: + +• eine oder mehrere Rückmeldungen mit Bezug zum Auf- +tragssegment mit mindestens einer Warnung zu diesem +Auftrag (Rückmeldungscode=3xxx). + +. ein Segment HITAN mit Belegung gemäß TAN-Prozess=4 +und einer Challenge zum Auftrag. + +4\. +Bei Mehrfach-TANs kann ein Storno nur in Verbindung mit der +Auftragseinreichung erfolgen, nicht bei der nachträglichen Über- +mittlung von zusätzlichen TANs. + + +![](figures/95.2) + + +Bietet ein Kreditinstitut die Möglichkeit eines Auftragsstorno +nicht an (BPD-Parameter ,,Auftragsstorno erlaubt"=N) und +übermittelt im Zusammenhang mit Warnungen als Antwort +auf die Auftragseinreichung trotzdem ein Segment HITAN in- +klusive einer Challenge, so bleibt dem Kunden nur die Mög- +lichkeit, die Challenge nicht zu beantworten und damit einen +TAN-Fehlversuch zu erzeugen, wenn er den Auftrag auf- +grund der Warnung stornieren möchte. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
96		Stand:
23.02.2018		Kapitel: Data-Dictionary
Abschnitt: Sonstige
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +### Auftragsstorno erlaubt + +Über diesen Parameter wird bestimmt, ob ein Kreditinstitut unter exakt defi- +nierten Rahmenbedingungen eine Stornierung von Aufträgen zulässt oder +nicht. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +B + + +#### BEN + +Optional in der Antwort auf die TAN gesendete Bestätigungsnummer, die der +Kunde in diesem Fall mit der auf seiner TAN-Liste abgedruckten BEN ver- +gleichen muss. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..99
Version:1
+ + +#### Benutzerdefinierte Signatur + +Enthält im Falle des PIN/TAN-Verfahrens die PIN und evtl. eine TAN. Die +PIN ist in jeder Nachricht zu senden. Ob eine TAN erforderlich ist, hängt von +den im HIPINS-Segment festgelegten Anforderungen der Geschäftsvorfälle +ab. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
6PIN1DEan.99M1
7TAN1DEan.99O1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +### Bezeichnung des TAN-Mediums + +Symbolischer Name für ein TAN-Medium wie z. B. TAN-Generator oder Mo- +biltelefon. Diese Bezeichnung kann in Verwaltungs-Geschäftsvorfällen be- +nutzt werden, wenn z. B. die Angabe der echten Handynummer aus Daten- +schutzgründen nicht möglich ist oder auch um die Benutzerfreundlichkeit zu +erhöhen. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FVD
Kapitel:Data-DictionaryStand:Seite:
Abschnitt:Sonstige23.02.201897
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..32
Version:1
+ + +## Bezeichnung des TAN-Mediums alt + +Symbolischer Name für ein TAN-Medium wie z. B. TAN-Generator oder Mobil- +telefon. Diese Bezeichnung kann in Verwaltungs-Geschäftsvorfällen benutzt +werden, wenn z. B. die Angabe der echten Handynummer aus Datenschutz- +gründen nicht möglich ist oder auch um die Benutzerfreundlichkeit zu erhö- +hen. In der Ausprägung mit Suffix „alt“ wird dieses Element zur Änderung der +Bezeichnung verwendet. Es muss die vereinbarte Bezeichnung einer beste- +henden und frei geschalteten Mobiltelefonnummer verwendet werden. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..32
Version:1
+ + +### Bezeichnung des TAN-Mediums neu + +Symbolischer Name für ein TAN-Medium wie z. B. TAN-Generator oder Mo- +biltelefon. Diese Bezeichnung kann in Verwaltungs-Geschäftsvorfällen be- +nutzt werden, wenn z. B. die Angabe der echten Handynummer aus Daten- +schutzgründen nicht möglich ist oder auch um die Benutzerfreundlichkeit zu +erhöhen. In der Ausprägung mit Suffix ,,neu" wird dieses Element zur Ände- +rung der Bezeichnung verwendet. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..32
Version:1
+ + +### Bezeichnung des TAN-Mediums erforderlich + +Abhängig vom Kreditinstitut und der Anzahl unterstützter TAN-Medien ist die +Angabe der Bezeichnung des TAN-Mediums erforderlich, damit der Kunde +dem Institut mitteilen kann, welches der TAN-Medien er verwenden möchte. + +Codierung: + +0: Bezeichnung des TAN-Mediums darf nicht angegeben werden + +1: Bezeichnung des TAN-Mediums kann angegeben werden + +2: Bezeichnung des TAN-Mediums muss angegeben werden + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:1
+ + +#### Bezugssegment + +Sofern sich ein Kreditinstitutssegment auf ein bestimmtes Kundensegment +bezieht (z. B. Antwortrückmeldung auf einen Kundenauftrag) hat das Kredit- +institut die Segmentnummer des Segments der Kundennachricht einzustel- +len, auf das sich das aktuelle Segment bezieht (s. DE ,Segmentnummer“). In +Zusammenhang mit den Angaben zur Bezugsnachricht aus dem Nachrich- + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
98		Stand: 23.02.2018Kapitel: Data-Dictionary
Abschnitt: Sonstige
+ + +tenkopf ist hierdurch eine eindeutige Referenz auf das Segment einer Kun- +dennachricht möglich. + +Falls die Angabe eines Bezugssegments erforderlich ist, ist dieses bei der +Formatbeschreibung eines Kreditinstitutssegments angegeben. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..3
Version:1
+ + +##### Bis Datum + +Endedatum eines Zeitraums (s. [Formals], Kap. B.6.3 „Abholauftrag“). + +Durch die Eingabe von Von- und Bis-Datum kann ein Zeitraum eingegrenzt +werden, für den Informationseinträge vom Kreditinstitut rückzumelden sind. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dat
Länge:#
Version:1
+ + +C + + +##### Challenge #1 + +Dieses Datenelement enthält im Falle des Zwei-Schritt-TAN-Verfahrens die +Challenge zu einem eingereichten Auftrag. Aus der Challenge wird vom +Kunden die eigentliche TAN ermittelt. Die Challenge wird unabhängig von +Prozessvariante 1 oder 2 in der Kreditinstitutsantwort im Segment HITAN +übermittelt. + + +![](figures/98.1) + + +Bei der Challenge kann es sich, abhängig vom konkreten +Zwei-Schritt-Verfahren, um eine „Auftragsquersumme“, ei- +nen Hashwert, einen Index auf eine bestimmte TAN in ei- +ner Liste o. ä. handeln. Bei chipTAN-Lesern ist es auch +möglich, dass die Challenge eine textuelle Anweisung ent- +hält, beispielsweise in der Form „Tippen Sie bitte die ersten +sechs Stellen der Empfänger-IBAN und die letzten beiden +Stellen des Betrags in den chipTAN-Leser ein". Das Kun- +denprodukt braucht i. d. R. die Bildungsregel für die Chal- +lenge bzw. die Ableitung der TAN aus der Challenge nicht +zu kennen – dies ist nur zwischen Kunde und Kreditinstitut +vereinbart und Inhalt der Verfahrensanweisung des jeweili- +gen Instituts. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:.256
Version:1
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel:
D
Dokument:Security - Sicherheitsverfahren PIN/TAN
Kapitel:Data-DictionaryStand:Seite:
Abschnitt:Sonstige23.02.201899
+ + +##### Challenge #2 + +Dieses Datenelement enthält im Falle des Zwei-Schritt-TAN-Verfahrens die +Challenge zu einem eingereichten Auftrag. Aus der Challenge wird vom +Kunden die eigentliche TAN ermittelt. Die Challenge wird unabhängig von +Prozessvariante 1 oder 2 in der Kreditinstitutsantwort im Segment HITAN +übermittelt. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:.999
Version:2
+ + +###### Challenge #3 + +Dieses Datenelement enthält im Falle des Zwei-Schritt-TAN-Verfahrens die +Challenge zu einem eingereichten Auftrag. Aus der Challenge wird vom +Kunden die eigentliche TAN ermittelt. Die Challenge wird unabhängig vom +Prozessvariante 1 oder 2 in der Kreditinstitutsantwort im Segment HITAN +übermittelt. + +Ist der BPD-Parameter ,,Challenge strukturiert“ mit „J“ belegt, so können im +Text folgende Formatsteuerzeichen enthalten sein, die kundenseitig entspre- +chend zu interpretieren sind. Eine Kaskadierung von Steuerzeichen ist nicht +erlaubt. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
<br>Zeilenumbruch
<p>Neuer Absatz
<b> ...</b> Fettdruck
<i> ...</i> Kursivdruck
<u> ...</u> Unterstreichen
<ul></ul> Beginn / Ende Aufzählung
<ol></ol> Beginn / Ende Nummerierte Liste
<li> ...</li>
Listenelement einer Aufzählung / Nummerierten Liste
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..2048
Version:3
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
100		Stand: 23.02.2018Kapitel: Data-Dictionary
Abschnitt: Sonstige
+ + +###### Challenge-Betrag erforderlich + +Über diesen BPD-Parameter erhält die Kundenseite die Information, ob im +Rahmen der ,,Parameter Challenge-Klasse“ auch der Betrag übermittelt wer- +den soll oder ob dies nicht zugelassen ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +###### Challenge-Betragswert + +Monetärer Wert eines Auftrags ohne das zugehörige Währungskennzeichen. +Das Format des Challenge-Betragswerts entspricht dem abgeleiteten Format +,wrt" (vgl. [Formals], Kapitel B.4.2). Die genaue Belegung wird durch das +konkrete Zwei-Schritt-Verfahren vorgegeben und ist der dortigen Spezifikati- +on zu entnehmen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..999
Version:1
+ + +###### Challenge-Betragswährung + +Information über die Auftragswährung, die in Verbindung mit dem Challenge- +Betragswert zu verwenden ist. Das Format der Challenge-Betragswährung +entspricht dem abgeleiteten Format ,cur" (vgl. [Formals], Kapitel B.4.2). Die +genaue Belegung wird durch das konkrete Zwei-Schritt-Verfahren vorgege- +ben und ist der dortigen Spezifikation zu entnehmen. + +Typ: DE + + + + + + + + + + + + + + + +
Format:an
Länge:..999
Version:1
+ + +###### Challenge HHD_UC + +Bei Verwendung von Zwei-Schritt-Verfahren mit unidirektionaler Kopplung +(vgl. hierzu [HHD_UC]) müssen zusätzlich zum Datenelement „Challenge" +die Daten für die Übertragung z. B. über eine optische Schnittstelle bereitge- +stellt werden. Die einzelnen Datenelemente der „Challenge HHD_UC" sind in +[HHD_UC] beschrieben und werden hier im FinTS Data Dictionary nicht nä- +her erläutert. Da HHD_UC einen anderen Basiszeichensatz verwendet (ISO +646) wird die HHD_UC-Struktur als binär definiert. Als maximale Länge kann +ein Wert von 128 angenommen werden. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:bin
Länge:..
Version:1
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FVD
Kapitel:Data-DictionaryStand:Seite:
Abschnitt:Sonstige23.02.2018101
+ + +###### Challenge-Klasse + +Mit der Challenge-Klasse wird dem Kreditinstitut die Art des Geschäftsvor- +falls mitgeteilt, was bei Prozessvariante 1 und der Verwendung von kontext- +abhängigen konkreten Zwei-Schritt-Verfahren essentiell für die weitere Ver- +arbeitung ist. Auf Basis der durch die Challenge-Klasse festgelegten Infor- +mation kann das Kreditinstitut dem Kunden eine dazu passende Challenge +übermitteln. Welche Geschäftsvorfälle welchen Challenge-Klassen zugeord- +net werden, ist der Beschreibung des jeweiligen konkreten Zwei-Schritt- +Verfahrens zu entnehmen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:.2
Version:1
+ + +###### Challenge-Klasse erforderlich + +Dieses DE kennzeichnet Zwei-Schritt-Verfahren (wie z. B. chipTAN-Leser), +bei denen für die Challenge-Ermittlung die Belegung des Elements „Challen- +ge-Klasse" in HKTAN erforderlich ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +###### Challenge-Klasse Parameter + +Zur jeweiligen Challenge-Klasse gehöriger Einzelparameter. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..999
Version:1
+ + +###### Challenge strukturiert + +Über diesen BPD-Parameter erhält die Kundenseite die Information, dass im +Datenelement ,,Challenge" Formatsteuerzeichen enthalten sein können. Nä- +heres hierzu siehe unter DE ,,Challenge“. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +###### CVR + +Nur bei bidirektionalen chipTAN-Verfahren mit Secoder 3: Das ,,Card Valida- +tion Result (CVR)" ist Bestandteil der Antwort auf das Secoder-Kommando +"SECODER TRANSMIT HHDUC". + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:bin
Länge:.256
Version:1
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
102		Stand: 23.02.2018Kapitel: Data-Dictionary
Abschnitt: Sonstige
+ + +D + + +####### Deaktivieren/Löschen + +Mit diesem Element wird kodiert ob ein Element deaktiviert oder gelöscht +werden soll. + +Codierung: + +D: Deaktivieren + +L: Löschen + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:1
Länge:1
Version:1
+ + +######## Dialog-ID + +Die Dialog-ID dient der eindeutigen Zuordnung einer Nachricht zu einem +HBCI-Dialog. Die erste Kundennachricht (Dialoginitialisierung) enthält als Di- +alog-ID den Wert 0. In der ersten Antwortnachricht wird vom Kreditinstitut ei- +ne Dialog-ID vorgegeben, die für alle nachfolgenden Nachrichten dieses Dia- +logs einzustellen ist. Es ist Aufgabe des Kreditinstituts, dafür zu sorgen, dass +diese Dialog-ID dialogübergreifend und systemweit eindeutig ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:id
Länge:#
Version:1
+ + +E + + +######## EF_ID Data + +Nur bei bidirektionalen chipTAN-Verfahren mit Secoder 3: Bestandteil der +Antwort auf das Secoder-Kommando ,,SECODER TRANSMIT HHDUC". + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:bin
Länge:.256
Version:1
+ + +######## Eingabe Kartenart zulässig + +Durch diesen Parameter wird festgelegt, ob bei Geschäftsvorfällen zum Ma- +nagement eines TAN-Generators (z. B. an-, ummelden) die Eingabe der Kar- +tenart erlaubt ist. Ist dies der Fall, so werden im zugehörigen BPD-Segment +(z. B. HITAUS) dem Kunden auch die zulässigen Kartenarten mitgeteilt. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FVD
Kapitel:Data-DictionaryStand:Seite:
Abschnitt:Sonstige23.02.2018103
+ + +####### Eingabe Kartennummer J/N + +Durch diesen Parameter wird festgelegt, ob bei Geschäftsvorfällen zum Ma- +nagement eines TAN-Generators (z. B. an-, ummelden, synchronisieren) die +Kartennummer mit angegeben werden muss. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +####### Eingabe Kartenfolgenummer J/N + +Durch diesen Parameter wird festgelegt, ob bei Geschäftsvorfällen zum Ma- +nagement eines TAN-Generators (z. B. an-, ummelden, synchronisieren) die +Kartenfolgenummer mit angegeben werden muss. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +####### Eingabe TAN-Listennummer J/N + +Durch diesen Parameter wird festgelegt, ob bei Anmeldung einer TAN-Liste +die TAN-Listennummer mit angegeben werden muss. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +####### Eingabe von ATC und TAN erforderlich + +Durch diesen Parameter wird festgelegt, ob bei Anmeldung eines TAN- +Generators zusätzlich zum ATC auch eine generierte TAN der neuen Karte +mit angegeben werden muss. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +####### Ein-Schritt-Verfahren erlaubt + +Angabe, ob Ein-Schritt-Verfahren erlaubt ist oder nicht. Darüber wird das +Kundenprodukt informiert, ob die Einreichung von Aufträgen im Ein-Schritt- +Verfahren zusätzlich zu den definierten Zwei-Schritt-Verfahren zugelassen +ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +![](figures/103.1) + + +Wird das Ein-Schritt-TAN-Verfahren von einem Institut nicht +mehr unterstützt und reicht ein Kunde trotzdem einen Auf- +trag in diesem Verfahren ein, so sollte das Institut dies mit + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
104		Stand: 23.02.2018Kapitel: Data-Dictionary
Abschnitt: Sonstige
+ + +einer verständlichen Rückmeldung ablehnen, damit der +Kunde entsprechend reagieren kann. Der passende Rück- +meldecode lautet 9955 - „Ein-Schritt-TAN-Verfahren nicht +zugelassen“ + + +##### Entgelte-Abbuchungskonto + +Zahlungsverkehrskontoverbindung, die für die Abbuchung von Transaktions- +entgelten wie z. B. SMS-Kosten oder transaktionsabhängige Schutzgebüh- +ren für chipTAN-Lesegeräte herangezogen werden soll bzw. herangezogen +wurde. Inhaltlich ist SMS-Abbuchungskonto als Teilmenge gleichbedeutend +mit dem Entgelte-Abbuchungskonto. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:kti
Länge:#
Version:1
+ + +###### Erlaubtes Format im Zwei-Schritt-Verfahren + +Angabe des erwarteten Formates der TAN im konkreten Zwei-Schritt- +Verfahren. + +Codierung: + +1: numerisch + +2: alfanumerisch + + +![](figures/104.1) + + +Kundenprodukte sollten die Eingabe der TAN auf dieses +Format beschränken. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:1
+ + +###### Erstellungsdatum + +Datum der Erstellung (z. B. einer TAN-Liste) + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dat
Länge:#
Version:1
+ + +F + + +##### Freigeschaltet am + +Datum, zu dem ein TAN-Medium freigeschaltet wurde. + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: D
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FV
Kapitel:Data-DictionaryStand:Seite:
Abschnitt:Sonstige23.02.2018105
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dat
Länge:#
Version:1
+ + +## Freischaltcode #1 + +Ordnungsbegriff der zur Freischaltung eines TAN-Mediums verwendet wird. +Dieser Ordnungsbegriff wird vom Institut vorgegeben und ggf. auf alternati- +vem Weg (z. B. als SMS) an den Kunden übermittelt. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..8
Version:1
+ + +### Freischaltcode #2 + +Ordnungsbegriff der zur Freischaltung eines TAN-Mediums verwendet wird. +Dieser Ordnungsbegriff wird vom Institut vorgegeben und ggf. auf alternati- +vem Weg (z. B. als SMS oder per Briefpost) an den Kunden übermittelt. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..64
Version:2
+ + +G + + +#### Geräteklasse + +Klasse, der ein HHD oder Secoder zugeordnet werden kann. Die Klasse ist +kein Bestandteil der Reader-ID und muss aus der Gerätebezeichnung abge- +leitet werden. Es handelt sich hierbei um Freitext, z. B. ,HHD manuell" bzw. +,HHD, optisch gekoppelt" oder ,Secoder I“. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..64
Version:1
+ + +##### Gerätehersteller + +Herstellerbezeichnung für ein HHD oder einen Secoder, wie sie sich z. B. +aus der Reader-ID oder institutsseitigen Beständen ergibt. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..64
Version:1
+ + +### Gerätebezeichnung + +Bezeichnung des HHD oder eines Secoders, wie sie sich z. B. aus der Rea- +der-ID oder institutsseitigen Beständen ergibt. Die Bezeichnung sollte ein- + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
106		Stand:
23.02.2018		Kapitel: Data-Dictionary
Abschnitt:
Sonstige
+ + +deutig sein und möglichst viele Aufschlüsse über die exakte Art des Gerätes +geben. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..64
Version:1
+ + +## Geräteversion + +Hierbei handelt es sich um die Firmware-Version des Gerätes und nicht um +die Version der HHD- oder Secoder-Spezifikation. Die Geräteversion ergibt +sich z. B. aus der Reader-ID oder institutsseitigen Beständen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..64
Version:1
+ + +## Geschäftsvorfallspezifische PIN/TAN-Informationen + +Eine DEG dieses Typs enthält für genau einen Geschäftsvorfall PIN/TAN- +relevante Informationen. Ist für einen Geschäftsvorfall eine zugehörige DEG +hinterlegt, kann das Kundenprodukt diesen Geschäftsvorfall über das +PIN/TAN-Verfahren absichern, andernfalls ist dies nicht erlaubt. + +Hierdurch wird nicht festgelegt, ob und wie oft ein Geschäftsvorfall zu signie- +ren ist. Dies wird weiterhin über die BPD und UPD angegeben. + +Werden mehr Signaturen eingestellt als in BPD und UPD gefordert, so sind +diese alle gemäß der Einstellungen im HIPINS-Segment zu bilden. + +Werden in BPD und UPD keine Signaturen gefordert, können diese selbst +dann weggelassen werden, wenn für den betreffenden Geschäftsvorfall eine +TAN erforderlich ist. + +Im Feld ,,Segmentkennung" ist die Kennung des Auftragssegments des Ge- +schäftsvorfalls anzugeben, auf den sich die PIN/TAN-Informationen bezie- +hen. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkennung1DEan..6M1
2TAN erforderlich1DEjn#M1
+ + +### Gültig ab + +Datum, ab dem eine Vereinbarung oder Vertrag gilt (z.B. Gültigkeitsbeginn +einer an den Kunden ausgegebenen Karte). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dat
Länge:#
Version:1
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FVD
Kapitel:Data-DictionaryStand:Seite:
Abschnitt:Sonstige23.02.2018107
+ + +#### Gültig bis + +Datum, bis zu dem eine Vereinbarung oder Vertrag gilt (z. B. Verfalldatum +einer an den Kunden ausgegebenen Karte). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dat
Länge:#
Version:1
+ + +##### Gültigkeitsdatum und -uhrzeit für Challenge + +Datum und Uhrzeit, bis zu welchem Zeitpunkt eine TAN auf Basis der ge- +sendeten Challenge gültig ist. Nach Ablauf der Gültigkeitsdauer wird die ent- +sprechende TAN entwertet. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameTypFor- matLän- geSta- tusAn- zahlRestriktionen
1DatumDEdat#M1
2UhrzeitDEtim#M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +I + + +#### ICCSN + += Integrated Circuit Card Serial Number. International eindeutige ID eines +Chip (z. B. eines Chip auf einer Banken-Chipkarte oder eines SIM). Die +ICCSN ist maximal 18 Stellen lang und verfügt optional an Stelle 19 über ei- +ne Prüfziffer. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:.. 19
Version:1
+ + +##### Initialisierungsmodus + +Bezeichnet das Verfahren, welches bei Verwendung von PIN/TAN während +der Dialoginitialisierung verwendet wird und bezieht sich dabei auf die in der +Spezifikation des HandHeldDevice [HHD] bzw. den Belegungsrichtlinien +[HHD-Belegung] definierten Schablonen 01 und 02. + +Die Schablonen werden in [HHD] zwar begrifflich auch als ,,Challengeklas- +sen" bezeichnet, sind jedoch Bestandteil des dort definierten ,,Start-Code", +der in Ausgaberichtung im FinTS Datenelement „Challenge“ übertragen wird +und daher nicht zu verwechseln mit der ,,Challengeklasse" im Sinne einer +Geschäftsvorfallsklasse bei HKTAN in der Prozessvariante 1. + +Codierung: + +00: Initialisierungsverfahren mit Klartext-PIN ohne TAN + +01: Verwendung analog der in [HHD] beschriebenen Schablone 01 - ver- +schlüsselte PIN und ohne TAN + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
108		Stand: 23.02.2018Kapitel: Data-Dictionary
Abschnitt: Sonstige
+ + +02: Verwendung analog der in [HHD] beschriebenen Schablone 02 - reser- +viert, bei FinTS derzeit nicht verwendet + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:2
Version:1
+ + +K + + +#### Kartenart + +Angabe zur Kartenart der Karte, auf die der Kundenauftrag oder die Kreditin- +stituts-Rückmeldung bezieht. + +Die je Kreditinstitut angebotenen Kartenarten sind in den BPD eingestellt. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..2
Version:1
+ + +##### Kartennummer + +Kartennummer der SECCOS-Karte, die beim DK-TAN-Generator verwendet +wird. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:id
Länge:#
Version:1
+ + +##### Kartenfolgenummer + +Kartenfolgenummer der SECCOS-Karte, die beim DK-TAN-Generator ver- +wendet wird. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:id
Länge:#
Version:1
+ + +##### Kontaktaufnahme durch Kreditinstitut erlaubt + +Über dieses Datenelement wird festgelegt, ob der Kunde einer Kontaktauf- +nahme des Kreditinstituts über das registrierte TAN-Medium zustimmt. oder +nicht. Wird das Datenelement weggelassen, gilt entsprechend den FinTS- +Konventionen die Belegung ,,N". + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FVD
Kapitel:Data-DictionaryStand:Seite:
Abschnitt:Sonstige23.02.2018109
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +##### Kontoverbindung Auftraggeber #3 + +Kontoverbindung des Auftraggebers, auf die sich der aktuelle Auftrag be- +zieht. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:ktv
Länge:#
Version:3
+ + +##### Kontoverbindung erforderlich + +Über dieses Datenelement wird festgelegt, ob die Angabe der Kontoverbin- +dung erfolgen muss oder optional ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +##### Kontoverbindung international Auftraggeber + +Kontoverbindung des Auftraggebers (Konto / BLZ bzw. IBAN), auf die sich +der aktuelle Auftrag bezieht. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:kti
Länge:#
Version:1
+ + +L + + +#### Letzte Benutzung + +Datum, an dem das TAN-Medium das letzte Mal benutzt wurde + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dat
Länge:#
Version:1
+ + +M + + +#### Maximale Anzahl Aufträge + +Höchstens zulässige Anzahl an Segmenten der jeweiligen Auftragsart je +Kundennachricht. Übersteigt die Anzahl der vom Kunden übermittelten Seg- +mente pro Auftragsart die zugelassene Maximalanzahl, so wird die gesamte +Nachricht abgelehnt. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
110		Stand: 23.02.2018Kapitel: Data-Dictionary
Abschnitt: Sonstige
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..3
Version:1
+ + +##### Maximale Länge des Rückgabewertes im Zwei-Schritt-Verfahren #1 + +Angabe der Länge der vom Institut übermittelten maximalen Länge des +Rückgabewertes (maximal 256 Stellen) im konkreten Zwei-Schritt-Verfahren. + + +![](figures/110.1) + + +Kundenprodukte sollten für die Anzeige des Rückgabewer- +tes ein geeignetes Anzeigefenster, ggf. mit Scrollbar vorse- +hen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..3
Version:1
+ + +###### Maximale Länge des Rückgabewertes im Zwei-Schritt-Verfahren #2 + +Angabe der Länge der vom Institut übermittelten maximalen Länge des +Rückgabewertes (maximal 999 Stellen) im konkreten Zwei-Schritt-Verfahren. + + +![](figures/110.2) + + +Kundenprodukte sollten für die Anzeige des Rückgabewer- +tes ein geeignetes Anzeigefenster, ggf. mit Scrollbar vorse- +hen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..3
Version:2
+ + +###### Maximale Länge des Rückgabewertes im Zwei-Schritt-Verfahren #3 + +Angabe der Länge der vom Institut übermittelten maximalen Länge des +Rückgabewertes (maximal 2048 Stellen) im konkreten Zwei-Schritt- +Verfahren. + + +![](figures/110.3) + + +Kundenprodukte sollten für die Anzeige des Rückgabewer- +tes ein geeignetes Anzeigefenster, ggf. mit Scrollbar vorse- +hen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:.4
Version:3
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FVD
Kapitel:Data-DictionaryStand:Seite:
Abschnitt:Sonstige23.02.2018111
+ + +##### Maximale Länge des TAN-Eingabewertes im Zwei-Schritt-Verfahren + +Angabe der erwarteten maximalen Länge der TAN im konkreten Zwei- +Schritt-Verfahren. + + +![](figures/111.1) + + +Kundenprodukte sollten die Eingabe der TAN auf diesen +Wert (maximal 99 Stellen) beschränken. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..2
Version:1
+ + +###### Maximale PIN-Länge + +Maximale Länge der PIN. Wenn das Kreditinstitut eine feste PIN-Länge er- +wartet, sind minimale und maximale PIN-Länge auf denselben Wert zu set- +zen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..2
Version:1
+ + +###### Maximale TAN-Länge + +Maximale Länge einer TAN. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..2
Version:1
+ + +###### Mehr als ein TAN-pflichtiger Auftrag pro Nachricht erlaubt + +Angabe, ob in einer FinTS-Nachricht mehr als ein TAN-pflichtiger Auftrag +gesendet werden darf. Bei Angabe von ,,N" darf in einer FinTS-Nachricht nur +ein TAN-pflichtiger Auftrag enthalten sein. Bei Angabe von ,J" wird die ma- +ximale Anzahl der TAN-pflichtigen Aufträge analog dem Geschäftsvorfallpa- +rameter „Maximale Anzahl Aufträge“ in der BPD bestimmt (vgl. [Formals], +Kapitel D.6). Die Option bezieht sich auf die Anzahl der in der Nachricht ent- +haltenen Aufträge, nicht auf die Anzahl der TANs, d. h. es ist pro Signaturab- +schluss nur eine TAN erlaubt, die bei Angabe von ,,J" aber ggf. für mehrere +Aufträge gilt. Dieser Parameter gilt sowohl für das Einschritt- als auch das +Zwei-Schritt-Verfahren. + + +![](figures/111.2) + + +Mit Einführung der Zahlungsdienstrichtlinie PSD2 (verglei- +che [PSD2]) ist die Angabe von ,,J“ nicht mehr erlaubt, da +das dort geforderte dynamic linking sowie die Transparenz +bzgl. Empfänger-IBAN und Betrag gegenüber dem Kunden +auftragsbezogen gilt. + +Um die Anzahl der FinTS-Nachrichten zu minimieren wird +empfohlen, die Option ,,Alle Konten“ = ,,J“ bei allen Ge- +schäftsvorfällen zu benutzen, die diese Option anbieten + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite: 112Stand: 23.02.2018Kapitel: Data-Dictionary
Abschnitt: Sonstige
+ + +###### und bei denen dies fachlich verarbeitbar ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FVD
Kapitel:Data-DictionaryStand:Seite:
Abschnitt:Sonstige23.02.2018113
+ + +####### Mehrfach-TAN erlaubt + +Angabe, ob beim Zwei-Schritt-Verfahren die Verwendung von Mehrfach- +TANs erlaubt ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +####### Minimale PIN-Länge + +Minimale Länge der PIN. Wenn das Kreditinstitut eine feste PIN-Länge er- +wartet, sind minimale und maximale PIN-Länge auf denselben Wert zu set- +zen. + +Typ: DE + + + + + + + + + + + + + + + +
Format:num
Länge:..2
Version:1
+ + +####### Mobiltelefonnummer + +Reale Nummer des Mobiltelefons. Es sind nur Ziffern inklusive führender +Nullen erlaubt und es gilt die nationale Schreibweise für Telefonnummern, +z. B. 0170/1234567 oder (0170) 1234567. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:1
+ + +####### Mobiltelefonnummer verschleiert + +Darstellung der Mobiltelefonnummer in der Form „*****nnnn“, wobei die letz- +ten vier Stellen denen der realen Mobiltelefonnummer entsprechen. Die An- +zahl des Platzhalters ,\*" kann entweder fix sein oder der Anzahl der Zeichen +der realen Mobiltelefonnummer (mit oder ohne Sonderzeichen) entsprechen. +Ein anderes Zeichen als ,,\*" als Platzhalter ist nicht zugelassen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:1
+ + +N + + +####### Name des Zwei-Schritt-Verfahrens + +Textliche Bezeichnung des konkreten Zwei-Schritt-Verfahrens, z. B. ,,chip- +TAN" oder ,,mobileTAN". Der Name soll vom Kundenprodukt zur Anzeige +verwendet werden. + + +![](figures/113.1) + + +Kundenprodukte sollten diesen Text als Beschreibung des +konkreten Zwei-Schritt-Verfahrens verwenden. Dies gilt für +die Anzeige bei der Eingabe zur TAN-Aufforderung. Bei +Verwaltungsfunktionen soll die ,,Technische Identifikation + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
114		Stand: 23.02.2018Kapitel: Data-Dictionary
Abschnitt: Sonstige
+ + +###### TAN-Verfahren“ verwendet werden. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..30
Version:1
+ + +####### Name Karteninhaber #2 + +Name des Inhabers einer vom Kreditinstitut ausgestellten Karte. Dabei muss +der Karteninhaber nicht notwendigerweise der Kontoinhaber sein. Auch die +Schreibweise des Namens muss nicht notwendigerweise mit dem auf der +Karte aufzudruckenden Namen übereinstimmen. + +Der Name des Karteninhabers und das Verfalldatum der Karte können bei +Kundenaufträgen als zusätzliche Identifizierungskriterien herangezogen wer- +den, wenn bspw. die Kartenfolgenummer nicht bekannt ist. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..35
Version:2
+ + +P + + +####### Parameter Challenge-Klasse + +Auftragsspezifische Daten, die entsprechend der Challenge-Klasse für die +Verarbeitung im Institut benötigt werden. + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Challenge-Klasse ParameterDEan.999O9
+ + +Typ: + +DEG + +Format: + +Länge: + +Version: + +1 + + +####### Parameter HHD-/Secoder-Informationen + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „HHD- +/Secoder-Informationen übermitteln“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Reader-ID erfor- derlichDEjn#M1
2Verfahrensbestä- tigung erforderlichDEjn#M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FVD
Kapitel:Data-DictionaryStand:Seite:
Abschnitt:Sonstige23.02.2018115
+ + +####### Parameter Mobilfunkverbindung ändern + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Mobil- +funkverbindung ändern“. + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1SMS- Abbuchungskonto erforderlich1DEjn#M1
+ + +Typ: + +DEG + +Format: + +Länge: + +Version: + +1 + + +####### Parameter Mobilfunkverbindung ändern #2 + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Mobil- +funkverbindung ändern“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1SMS- Abbuchungskonto erforderlich1DEjn#M1
2Zustimmung zur Kontaktaufnahme unterstützt1DEjn#M1
+ + +Typ: + +DEG + +Format: + +Länge: + +Version: + +2 + + +####### Parameter Mobilfunkverbindung registrieren + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall ,,Mobil- +funkverbindung registrieren“. + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1SMS- Abbuchungskonto erforderlich1DEjn#M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite: 116Stand: 23.02.2018Kapitel: Data-Dictionary
Abschnitt: Sonstige
+ + +####### Parameter Mobilfunkverbindung registrieren #2 + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall ,,Mobil- +funkverbindung registrieren". + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1SMS- Abbuchungskonto erforderlich1DEjn#M1
2Zustimmung zur Kontaktaufnahme unterstützt1DEjn#M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:2
+ + +####### Parameter TAN-Generator an- bzw. ummelden #1 + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „TAN- +Generator an- bzw. ummelden“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr .NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Eingabe TAN- Listennummer J/N1DEjn1M1
2Eingabe Kartenfol- genummer J/N1DEjn1M1
3Eingabe von ATC und TAN erforder- lich1DEjn1M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +####### Parameter TAN-Generator an- bzw. ummelden #2 + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall ,,TAN- +Generator an- bzw. ummelden“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FVD
Kapitel:Data-DictionaryStand:Seite:
Abschnitt:Sonstige23.02.2018117
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Eingabe TAN- Listennummer J/N1DEjn1M1
2Eingabe Karten- folgenummer J/N1DEjn1M1
3Eingabe von ATC und TAN erforder- lich1DEjn1M1
4Eingabe Kartenart zulässig1DEjn1M1
5Zulässige Karten- art1DEnum.2C0..99M: wenn ,,Eingabe Kartenart zulässig = J“ N: sonst
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:2
+ + +####### Parameter TAN-Generator an- bzw. ummelden #3 + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „TAN- +Generator an- bzw. ummelden“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Eingabe TAN- Listennummer J/N1DEjn1M1
2Eingabe Karten- folgenummer J/N1DEjn1M1
3Eingabe von ATC und TAN erforder- lich1DEjn1M1
4Eingabe Kartenart zulässig1DEjn1M1
5Kontoverbindung erforderlich1DEjn1M1
6Zulässige Karten- art1DEnum..2C0..99M: wenn ,,Eingabe Kartenart zulässig = J“ N: sonst
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:3
+ + +####### Parameter TAN-Generator Synchronisierung + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „TAN- +Generator Synchronisierung". + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite: 118Stand: 23.02.2018Kapitel: Data-Dictionary
Abschnitt: Sonstige
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Eingabe Karten- nummer J/N1DEjn1M1
2Eingabe Karten- folgenummer J/N1DEjn1M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +####### Parameter Zwei-Schritt-TAN-Einreichung, Elementversion #1 + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Zwei- +Schritt-TAN-Einreichung". + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Einschritt- Verfahren erlaubt1DEjn#M1
2Mehr als ein TAN- pflichtiger Auftrag pro Nachricht er- laubt1DEjn#M1
3Auftrags- Hashwertverfah- ren1DEcode1M1
4Sicherheitsprofil Banken-Signatur bei HITAN1DEcode1M1
5Verfahrenspara- meter Zwei- Schritt-Verfahren1DEGM1..98
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +####### Parameter Zwei-Schritt-TAN-Einreichung, Elementversion #2 + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall ,Zwei- +Schritt-TAN-Einreichung“. + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: D
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FV
Kapitel:Data-DictionaryStand:Seite:
Abschnitt:Sonstige23.02.2018119
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Einschritt- Verfahren erlaubt1DEjn#M1
2Mehr als ein TAN- pflichtiger Auftrag pro Nachricht er- laubt1DEjn#M1
3Auftrags- Hashwertverfah- ren1DEcode1M1
4Verfahrenspara- meter Zwei- Schritt-Verfahren2DEGM1..98
+ + +Typ: + +DEG + +Format: + +Länge: + +Version: + +2 + + +####### Parameter Zwei-Schritt-TAN-Einreichung, Elementversion #3 + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Zwei- +Schritt-TAN-Einreichung". + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Einschritt- Verfahren erlaubt1DEjn#M1
2Mehr als ein TAN- pflichtiger Auftrag pro Nachricht er- laubt1DEjn#M1
3Auftrags- Hashwertverfah- ren1DEcode1M1
4Verfahrenspara- meter Zwei- Schritt-Verfahren3DEGM1..98
+ + +Typ: + +DEG + +Format: + +Länge: + +Version: + +3 + + +####### Parameter Zwei-Schritt-TAN-Einreichung, Elementversion #4 + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Zwei- +Schritt-TAN-Einreichung". + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite: 120Stand: 23.02.2018Kapitel: Data-Dictionary
Abschnitt: Sonstige
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Einschritt- Verfahren erlaubt1DEjn#M1
2Mehr als ein TAN- pflichtiger Auftrag pro Nachricht er- laubt1DEjn#M1
3Auftrags- Hashwertverfah- ren1DEcode1M1
4Verfahrenspara- meter Zwei- Schritt-Verfahren4DEGM1..98
+ + +Typ: + +DEG + +Format: + +Länge: + +Version: + +4 + + +####### Parameter Zwei-Schritt-TAN-Einreichung, Elementversion #5 + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall „Zwei- +Schritt-TAN-Einreichung". + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Einschritt- Verfahren erlaubt1DEjn#M1
2Mehr als ein TAN- pflichtiger Auftrag pro Nachricht er- laubt1DEjn#M1
3Auftrags- Hashwertverfah- ren1DEcode1M1
4Verfahrenspara- meter Zwei- Schritt-Verfahren5DEGM1..98
+ + +Typ: + +DEG + +Format: + +Länge: + +Version: + +5 + + +####### Parameter Zwei-Schritt-TAN-Einreichung, Elementversion #6 + +Auftragsspezifische Bankparameterdaten für den Geschäftsvorfall ,Zwei- +Schritt-TAN-Einreichung“. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FVD
Kapitel:Data-DictionaryStand:Seite:
Abschnitt:Sonstige23.02.2018121
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Einschritt- Verfahren erlaubt1DEjn#M1
2Mehr als ein TAN- pflichtiger Auftrag pro Nachricht er- laubt1DEjn#M1
3Auftrags- Hashwertverfah- ren1DEcode1M1
4Verfahrenspara- meter Zwei- Schritt-Verfahren6DEGM1..98
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:6
+ + +PIN + +(Private Identifikationsnummer) Authentisierungsmerkmal des Kunden beim +PIN/TAN-Verfahren. Das Format einer PIN ist kreditinstitutsindividuell. Die +minimale und maximale Länge der PIN kann das Kreditinstitut im Segment +HIPINS angeben. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..99
Version:1
+ + +R + + +###### Reader-ID + +Eindeutige Identifikationsnummer eines chipTAN-Lesers bzw. eines Seco- +ders. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:id
Länge:#
Version:1
+ + +###### Reader-ID erforderlich + +Über diesen Parameter wird festgelegt, ob die Übertragung der Reader-ID +zwingend erforderlich ist oder optional erfolgen kann. So kann ein Kreditinsti- +tut die Übertragung der Reader-ID verlangen, wenn keine zentralen Bestän- +de zur Verfügung stehen oder die Reader-ID für eine zentrale Verwaltung er- +fasst werden soll. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
122		Stand: 23.02.2018Kapitel: Data-Dictionary
Abschnitt: Sonstige
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +S + + +###### Segmentkennung + +Segmentspezifische Kennung, die jedem Segment bzw. Auftrag zugeordnet +ist (z.B. "HKCCS" für "SEPA-Einzelüberweisung"). Die Angabe hat in Groß- +schreibung zu erfolgen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..6
Version:1
+ + +###### Segmentkopf + +Informationen, die jedem Segment als Kopfteil vorangestellt sind. Im Unter- +schied zu Nachrichten enthalten Segmente jedoch keinen Abschlussteil, da +das Segmentende durch das Segmentende-Zeichen markiert ist. + +Im Segmentkopf stehen die Segmentkennung und Segmentversion unab- +hängig von der HBCI-Version (s. DE HBCI-Version) immer an derselben +Stelle, damit ein Segment auch in späteren HBCI-Versionen immer eindeutig +als solches identifiziert werden kann. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameTypFor- matLän- geSta- tusAn- zahlRestriktionen
1SegmentkennungDEan..6M1
2SegmentnummerDEnum..3M1>=1
3SegmentversionDEnum..3M1
4BezugssegmentDEnum..3C1>=1
O: Verwendung in Kre- ditinstitutsnachricht
N: Verwendung in Kun- dennachricht
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +###### Segmentnummer + +Information zur eindeutigen Identifizierung eines Segments innerhalb einer +Nachricht. Die Segmente einer Nachricht werden in Einerschritten streng +monoton aufsteigend nummeriert. Die Nummerierung beginnt mit 1 im ersten +Segment der Nachricht (Nachrichtenkopf). + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: D
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FV
Kapitel:Data-DictionaryStand:Seite:
Abschnitt:Sonstige23.02.2018123
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..3
Version:1
+ + +###### Segmentversion + +Versionsnummer zur Dokumentation von Änderungen eines Segment- +formats. + +Die Segmentversion von administrativen Segmenten (die Segmentart 'Admi- +nistration' bzw. 'Geschäftsvorfall' ist bei jeder Segmentbeschreibung ange- +geben) wird bei jeder Änderung des Segmentformats inkrementiert. + +Bei Geschäftsvorfallssegmenten wird die Segmentversion auf logischer Ebe- +ne verwaltet, d. h. sie ist für das Auftrags-, das Antwort- und das Parame- +tersegment des Geschäftsvorfalls stets identisch und wird inkrementiert, +wenn sich das Format von mindestens einem der drei Segmente ändert. + +Dieses Verfahren gilt bei Standardsegmenten einheitlich für alle Kreditinsti- +tute. Bei verbandsindividuellen Segmenten obliegt die Versionssteuerung +dem jeweiligen Verband. Der Zeitpunkt der Unterstützung einer neuen Seg- +mentversion kann jedoch zwischen den Verbänden variieren. + +Die für die jeweilige FinTS-Version gültige Segmentversion ist bei der jewei- +ligen Segmentbeschreibung vermerkt. + +Falls der Kunde ein Segment mit einer veralteten Versionsnummer einreicht, +sollte ihm in einer entsprechenden Warnung rück gemeldet werden, dass +sein Kundenprodukt aktualisiert werden sollte. + +Typ: DE + + + + + + + + + + + + + + + +
Format:num
Länge:..3
Version:1
+ + +###### Sicherheitsfunktion, kodiert #2 + +Kodierte Information über die Sicherheitsfunktion, die auf die Nachricht angewendet +wird. Dieses Element wird gemeinsam in den Sicherheitsverfahren HBCI, PIN/TAN +und den AZS-Verfahren benutzt. + +FinTS V3.0 - Sicherheitsverfahren HBCI: + +Die Sicherheitsfunktion hat ab FinTS 3.0 lediglich informatorischen Wert, da die ei- +gentliche Steuerung über die Sicherheitsprofile und -klassen erfolgt. + +FinTS V3.0 - Sicherheitsverfahren PIN/TAN: + +Codierung der verwendeten Sicherheits- und Verschlüsselungsfunktionen + +FinTS V3.0 - Alternative ZKA Sicherheitsverfahren: + +Dient der Kennzeichnung des jeweiligen Verfahrens in Verbindung mit dem Ge- +schäftsvorfall HKAZS + + +####### Codierung: + + + + + + + + + + + + + + + + + + +
CodeSegmentBedeutung
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite: 124Stand: 23.02.2018Kapitel: Data-Dictionary
Abschnitt: Sonstige
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Sicherheitsverfahren HBCI: - SignaturkopfNon-Repudiation of Origin, für RAH (NRO)
2Sicherheitsverfahren HBCI: - SignaturkopfMessage Origin Authen- tication, für RAH und DDV (AUT)
4Sicherheitsverfahren HBCI: - VerschlüsselungskopfEncryption, Verschlüsse- lung und evtl. Komprimie- rung (ENC)
811Alternative ZKA Sicherheitsverfahren: - Signaturkopf bei HKAZS,
- HIAZSS Verfahrensparameter		Fortgeschrittene Elektro- nische Signatur (,,AUT- Signatur") mit Secoder ohne Institutssignatur
900Sicherheitsverfahren PIN/TAN:
- Signaturkopf bei HKTAN,
- HITANS Verfahrensparameter Zwei-Schritt-Verfahren		1. konkretes Zwei-Schritt- TAN-Verfahren
901Sicherheitsverfahren PIN/TAN:
- Signaturkopf bei HKTAN,
- HITANS Verfahrensparameter Zwei-Schritt-Verfahren		2. konkretes Zwei-Schritt- Verfahren
...
996Sicherheitsverfahren PIN/TAN:
- Signaturkopf bei HKTAN,
- HITANS Verfahrensparameter Zwei-Schritt-Verfahren		97. konkretes Zwei- Schritt-Verfahren
997Sicherheitsverfahren PIN/TAN:
- Signaturkopf bei HKTAN,
- HITANS Verfahrensparameter Zwei-Schritt-Verfahren		98. konkretes Zwei- Schritt-Verfahren
998Sicherheitsverfahren PIN/TAN:
- Verschlüsselungskopf		Daten im Klartext (nur in Verbindung mit TLS er- laubt)
999SignaturkopfKlassisches Ein-Schritt- Verfahren
+ + +Die Werte 900 bis 997 und 999 werden auch im Rahmen der Rückmeldung +mit Code 3920 ,,Zugelassene Ein- und Zwei-Schritt-Verfahren für Benutzer“ +als Rückmeldungsparameter P1 bis P10 verwendet. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:..3
Version:2
+ + +####### Sicherheitsprofil Banken-Signatur bei HITAN + +Information, ob das Kreditinstitut beim Zwei-Schritt-Verfahren die Absiche- +rung der Kreditinstitutsantwort HITAN mittels Banken-Signatur zulässt und + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FVD
Kapitel:Data-DictionaryStand:Seite:
Abschnitt:Sonstige23.02.2018125
+ + +wenn ja, welches Sicherheitsprofil zugelassen ist. Dieser Parameter wird aus +Kompatibilitätsgründen ausschließlich bei HITAN in Segmentversion=1 ver- +wendet und entfällt ab Segmentversion=2 ersatzlos, da die Unterstützung +der Banken-Signatur durch ein Institut außerhalb des FinTS-Protokolls gere- +gelt wird. + +Codierung: + +0: Banken-Signatur von HITAN nicht erlaubt + +1: RDH-1 (wird in FinTS V3.0 nicht verwendet) + +2: RDH-2 (in FinTS V3.0) + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:1
+ + +###### SMS-Abbuchungskonto + +Zahlungsverkehrskontoverbindung, die für die Abbuchung von SMS-Kosten +herangezogen werden soll. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:kti
Länge:#
Version:1
+ + +###### SMS-Abbuchungskonto erforderlich + +Parameter, der angibt, ob eine Zahlungsverkehrskontoverbindung für die +Abbuchung von SMS-Kosten angegeben werden muss. Die Belastung von +SMS-Kosten durch das Institut wird unabhängig von dem Vorhandensein ei- +ner Kontoverbindung z. B. kundenindividuell geregelt. + +Das Element wird in Basisfunktionen verwendet, die nur eine J/N Entschei- +dung benötigen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version1
+ + +###### SMS-Abbuchungskonto erforderlich + +Parameter, der angibt, ob eine Zahlungsverkehrskontoverbindung für die +Abbuchung von SMS-Kosten angegeben werden kann oder muss. Die Be- +lastung von SMS-Kosten durch das Institut wird unabhängig von dem Vor- +handensein einer Kontoverbindung z. B. kundenindividuell geregelt. + +Das Element in der Version #2 ermöglicht eine detailliertere Steuerung der +Belegung. Es wird z. B. in HKTAN ab Segmentversion #5 eingesetzt. + +Codierung: + +0: SMS-Abbuchungskonto darf nicht angegeben werden + +1: SMS-Abbuchungskonto kann angegeben werden + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
126		Stand:
23.02.2018		Kapitel: Data-Dictionary
Abschnitt:
Sonstige
+ + +###### 2: SMS-Abbuchungskonto muss angegeben werden + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:2
+ + +####### Status + +Gibt an, in welchem Status sich ein TAN-Medium befindet. + +Codierung: + +1: Aktiv + +2: Verfügbar + +3: Aktiv Folgekarte + +4: Verfügbar Folgekarte + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:1
+ + +T + + +####### TAN + +(Transaktionsnummer) One-Time-Passwort zur Freigabe von Transaktionen +beim PIN/TAN-Verfahren. Das Format einer TAN ist kreditinstitutsindividuell. +Die maximale Länge der TAN kann das Kreditinstitut im Segment HIPINS +angeben. Das DE TAN darf beim Zwei-Schritt-Verfahren bei TAN-Prozess=2 +ausschließlich in Verbindung mit dem Geschäftsvorfall HKTAN belegt wer- +den. Ansonsten wird der Inhalt ignoriert und die TAN vom Institut entwertet. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..99
Version:1
+ + +###### TAN erforderlich + +Es wird angegeben, ob beim Einreichen des Geschäftsvorfalles je vorhande- +ner Signatur eine TAN angegeben werden muss oder nicht. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +###### TAN-Einsatzoption + +Es werden die Möglichkeiten festgelegt, die ein Kunde hat, wenn er für +PIN/TAN parallel mehrere TAN-Medien zur Verfügung hat. + +Codierung: + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FVD
Kapitel:Data-DictionaryStand:Seite:
Abschnitt:Sonstige23.02.2018127
+ + +0: +Kunde kann alle ,,aktiven" Medien parallel nutzen + +1: +Kunde kann genau ein Medium (z. B. ein Mobiltelefon oder einen +TAN-Generator) zu einer Zeit nutzen + +2: +Kunde kann ein Mobiltelefon und einen TAN-Generator parallel nutzen + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:1
+ + +###### TAN-Information, Segmentversion #1 + +Informationen zu einer TAN der TAN-Liste. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1TAN-Verbrauchs- kennzeichen1DEcode..2M1
2TAN-Verbrauchs- erläuterung1DEan..99C1O: TAN- Verbrauchskenn- zeichen = 99 N: sonst
3TAN1DEan.99C1O: TAN wurde verbraucht N: sonst
4TAN- Verbrauchsdatum1DEdat#C1O: TAN wurde verbraucht N: sonst
5TAN- Verbrauchsuhrzeit1DEtim#C1O: TAN wurde verbraucht und Verbrauchsdatum angegeben N: sonst
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +###### TAN-Information, Segmentversion #2 Informationen zu einer TAN. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite: 128Stand: 23.02.2018Kapitel: Data-Dictionary
Abschnitt:
Sonstige
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1TAN-Verbrauchs- kennzeichen1DEcode..2M1
2TAN-Verbrauchs- erläuterung1DEan..99C1O: TAN- Verbrauchskenn- zeichen = 99 N: sonst
3TAN1DEan.99O1
4TAN- Verbrauchsdatum1DEdat#O1
5TAN- Verbrauchsuhrzeit1DEtim#C1O: Verbrauchs- datum angegeben N: sonst
6Entgelte- Abbuchungskonto1DEGkti#O1
7Transaktionskonto1DEGkti#O1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:2
+ + +###### TAN-Medium-Art, Elementversion #1 + +dient der Klassifizierung der gesamten dem Kunden zugeordneten TAN- +Medien. Bei Geschäftsvorfällen zum Management des TAN-Generators kann +aus diesen nach folgender Codierung selektiert werden. + +Codierung: + +0: Alle + +2: Aktiv + +3: Verfügbar + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:1
+ + +###### TAN-Medium-Art, Elementversion #2 + +dient der Klassifizierung der gesamten dem Kunden zugeordneten TAN- +Medien. Bei Geschäftsvorfällen zum Management des TAN-Generators kann +aus diesen nach folgender Codierung selektiert werden. + +Codierung: + +0: Alle + +1: Aktiv + +2: Verfügbar + +Typ: DE + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: D
Dokument:Security - Sicherheitsverfahren PIN/TAN
Kapitel:Data-DictionaryStand:Seite:
Abschnitt:Sonstige23.02.2018129
+ + + + + + + + + + + + + + + +
Format:code
Länge:1
Version:2
+ + +###### TAN-Medium-Klasse, Elementversion #1 + +dient der Klassifizierung der möglichen TAN-Medien. Bei Geschäftsvorfällen +zum Management der TAN-Medien kann aus diesen nach folgender Codie- +rung selektiert werden. + +Codierung: + +L: Liste + +G: TAN-Generator + +M: Mobiltelefon mit mobile TAN + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:1
+ + +###### TAN-Medium-Klasse, Elementversion #2 + +dient der Klassifizierung der möglichen TAN-Medien. Bei Geschäftsvorfällen +zum Management der TAN-Medien kann aus diesen nach folgender Codie- +rung selektiert werden. + +Codierung: + +L: Liste + +G: TAN-Generator + +M: Mobiltelefon mit mobile TAN + +S: Secoder + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:2
+ + +###### TAN-Medium-Klasse, Elementversion #3 + +dient der Klassifizierung der möglichen TAN-Medien. Bei Geschäftsvorfällen +zum Management der TAN-Medien kann aus diesen nach folgender Codie- +rung selektiert werden. + +Codierung: + +A: Alle Medien + +L: Liste + +G: TAN-Generator + +M: Mobiltelefon mit mobile TAN + +S: Secoder + +Typ: DE + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite: 130Stand: 23.02.2018Kapitel: Data-Dictionary
Abschnitt: Sonstige
+ + + + + + + + + + + + + + + +
Format:code
Länge:1
Version:3
+ + +###### TAN-Medium-Klasse, Elementversion #4 + +dient der Klassifizierung der möglichen TAN-Medien. Bei Geschäftsvorfällen +zum Management der TAN-Medien kann aus diesen nach folgender Codie- +rung selektiert werden. + +Codierung: + +A: Alle Medien + +L: Liste + +G: TAN-Generator + +M: Mobiltelefon mit mobile TAN + +S: Secoder + +B: Bilateral vereinbart + +Typ: DE + + + + + + + + + + + + + + + +
Format:code
Länge:1
Version:4
+ + +###### TAN-Medium-Liste, Elementversion #1 + +Informationen zu Art und Parametrisierung von TAN-Medien. Als TAN-Medien +werden sowohl TAN-Listen als auch ZKA-TAN-Generatoren / Karten be- +zeichnet. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1TAN-Generator / Liste1DEan1M1G, L
2Status1DEcode1M11, 2, 3, 4
3Kartennummer1DEId#C1M: DE „TAN- Generator / Lis- te“=“G“ N: sonst
4Kartenfolgenum- mer1DEId#C1M: DE „TAN- Generator / Lis- te“=“G“ N: sonst
5TAN- Listennummer1DEan..20C1M: DE „TAN- Generator / Liste"="L" N: sonst
6Anzahl freie TANs1DEnum.3O1
7Letzte Benutzung1DEdat8O1
8Freigeschaltet am1DEdat8O1
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FVD
Kapitel:Data-DictionaryStand:Seite:
Abschnitt:Sonstige23.02.2018131
+ + +Typ: +DEG + +Format: + +Länge: + +Version: +1 + + +###### TAN-Medium-Liste, Elementversion #2 + +Informationen zu Art und Parametrisierung von TAN-Medien. Als TAN-Medien +werden sowohl TAN-Listen als auch ZKA-TAN-Generatoren / Karten oder +Mobiltelefone bezeichnet. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1TAN-Medium- Klasse1DEcode1M1G, L, M
2Status1DEcode1M11, 2, 3, 4
3Kartennummer1DEid#C1M: DE ,,TAN-Medium- Klasse“=“G“ N: sonst
4Kartenfolgenum- mer1DEid#C1M: DE ,,TAN-Medium- Klasse“=“G“ N: sonst
5Kartenart1DEnum..2C1O: DE ,,TAN- Generator/-Liste"="G" und DE ,,Eingabe Kartenart zulässig“ (BPD) = „J“ N: sonst
6Kontoverbindung Auftraggeber3DEGktv#C1O: DE „TAN- Generator/-Liste"="G" N: sonst
7gültig ab1DEdat#C1O: DE ,,TAN- Generator/-Liste"="G" N: sonst
8gültig bis1DEdat#C1O: DE „TAN- Generator/-Liste"="G" N: sonst
9TAN- Listennummer1DEan..20C1M: DE ,,TAN-Medium- Klasse“=“L“ N: sonst
10Bezeichnung des TAN-Mediums1DEan..32C1M: DE ,,TAN-Medium- Klasse“=“M“ O: sonst
11SMS- Abbuchungskonto1DEGkti#C1O: DE ,,TAN-Medium- Klasse“=“M“ N: sonst
12Anzahl freie TANs1DEnum.3O1
13Letzte Benutzung1DEdat8O1
14Freigeschaltet am1DEdat8O1
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite: 132Stand: 23.02.2018Kapitel: Data-Dictionary
Abschnitt: Sonstige
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:2
+ + +###### TAN-Medium-Liste, Elementversion #3 + +Informationen zu Art und Parametrisierung von TAN-Medien. Als TAN-Medien +werden sowohl TAN-Listen als auch ZKA-TAN-Generatoren / Karten oder +Mobiltelefone bezeichnet. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1TAN-Medium- Klasse2DEcode1M1G, L, M, S
2Status1DEcode1M11, 2, 3, 4
3Kartennummer1DEId#C1M: DE ,,TAN-Medium- Klasse“=“G“ N: sonst
4Kartenfolgenum- mer1DEId#C1M: DE ,,TAN-Medium- Klasse"="G" N: sonst
5Kartenart1DEnum.2C1O: DE „TAN- Generator/-Liste"="G" und DE ,,Eingabe Kartenart zulässig“ (BPD) = „J“ N: sonst
6Kontoverbindung Auftraggeber3DEGktv#C1O: DE „TAN- Generator/-Liste"="G" N: sonst
7gültig ab1DEdat#C1O: DE „TAN- Generator/-Liste"="G" N: sonst
8gültig bis1DEdat#C1O: DE ,,TAN- Generator/-Liste"="G" N: sonst
9TAN- Listennummer1DEan..20C1M: DE ,,TAN-Medium- Klasse“=“L“ N: sonst
10Bezeichnung des TAN-Mediums1DEan..32C1M: DE ,,TAN-Medium- Klasse“=“M“ O: sonst
11Mobiltelefonnum- mer verschleiert1DEan..35C1M: DE ,,TAN-Medium- Klasse“=“M“ N: sonst
12SMS- Abbuchungskonto1DEGkti#C1O: DE ,,TAN-Medium- Klasse“=“M“ N: sonst
13Anzahl freie TANs1DEnum..3O1
14Letzte Benutzung1DEdat8O1
15Freigeschaltet am1DEdat8O1
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FVD
Kapitel:Data-DictionaryStand:Seite:
Abschnitt:Sonstige23.02.2018133
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:3
+ + +###### TAN-Medium-Liste, Elementversion #4 + +Informationen zu Art und Parametrisierung von TAN-Medien. Als TAN-Medien +werden sowohl TAN-Listen als auch ZKA-TAN-Generatoren / Karten oder +Mobiltelefone bezeichnet. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1TAN-Medium- Klasse3DEcode1M1A, G, L, M, S
2Status1DEcode1M11, 2, 3, 4
3Kartennummer1DEId#C1M: DE ,,TAN-Medium- Klasse“=“G“ N: sonst
4Kartenfolgenum- mer1DEId#C1M: DE ,,TAN-Medium- Klasse“=“G“ N: sonst
5Kartenart1DEnum..2C1O: DE „TAN- Generator/-Liste"="G" und DE ,,Eingabe Kartenart zulässig“ (BPD) = „J“ N: sonst
6Kontoverbindung Auftraggeber3DEGktv#C1O: DE „TAN- Generator/-Liste"="G" N: sonst
7gültig ab1DEdat#C1O: DE „TAN- Generator/-Liste"="G" N: sonst
8gültig bis1DEdat#C1O: DE „TAN- Generator/-Liste"="G" N: sonst
9TAN- Listennummer1DEan..20C1M: DE „TAN-Medium- Klasse“=“L“ N: sonst
10Bezeichnung des TAN-Mediums1DEan..32C1M: DE ,,TAN-Medium- Klasse“=“M“ O: sonst
11Mobiltelefonnum- mer verschleiert1DEan..35C1O: DE ,,TAN-Medium- Klasse"="M" N: sonst
12Mobiltelefonnum- mer1DEan..35C1O: DE ,,TAN-Medium- Klasse“=“M“ N: sonst
13SMS- Abbuchungskonto1DEGkti#C1O: DE ,,TAN-Medium- Klasse"="M"
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
134		Stand: 23.02.2018Kapitel: Data-Dictionary
Abschnitt: Sonstige
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
N: sonst
14Anzahl freie TANs1DEnum.3O1
15Letzte Benutzung1DEdat8O1
16Freigeschaltet am1DEdat8O1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:4
+ + +###### TAN-Medium-Liste, Elementversion #5 + +Informationen zu Art und Parametrisierung von TAN-Medien. Als TAN-Medien +werden sowohl TAN-Listen als auch DK-TAN-Generatoren / Karten oder Mo- +biltelefone sowie bilateral vereinbarte Medien bezeichnet. + +Wird das Datenelement ,,TAN-Medium-Klasse" mit ,B" (bilateral vereinbart) +belegt, so muss im Element ,,Sicherheitsfunktion, kodiert“ die entsprechende +Sicherheitsfunktion in der DEG ,,Verfahrensparameter Zwei-Schritt-Verfahren“ +referenziert werden. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1TAN-Medium- Klasse4DEcode1M1A, G, L, M, S, B
2Status1DEcode1M11, 2, 3, 4
3Sicherheitsfunkti- on, kodiert2DEnum3C1M: DE ,,TAN-Medium- Klasse“=“B“ N: sonst
4Kartennummer1DEId#C1M: DE ,,TAN-Medium- Klasse“=“G“ N: sonst
5Kartenfolgenum- mer1DEId#C1M: DE ,,TAN-Medium- Klasse“=“G“ N: sonst
6Kartenart1DEnum.2C1O: DE ,,TAN- Generator/-Liste"="G" und DE ,,Eingabe Kartenart zulässig“ (BPD) = „J“ N: sonst
7Kontoverbindung Auftraggeber3DEGktv#C1O: DE „TAN- Generator/-Liste"="G" N: sonst
8gültig ab1DEdat#C1O: DE „TAN- Generator/-Liste"="G" N: sonst
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: D
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FV
Kapitel:Data-DictionaryStand:Seite:
Abschnitt:Sonstige23.02.2018135
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
9gültig bis1DEdat#C1O: DE „TAN- Generator/-Liste"="G" N: sonst
10TAN- Listennummer1DEan..20C1M: DE „TAN-Medium- Klasse“=“L“ N: sonst
11Bezeichnung des TAN-Mediums1DEan..32C1M: DE ,,TAN-Medium- Klasse“=“M“ O: sonst
12Mobiltelefonnum- mer verschleiert1DEan..35C1O: DE ,,TAN-Medium- Klasse“=“M“ N: sonst
13Mobiltelefonnum- mer1DEan..35C1O: DE ,,TAN-Medium- Klasse“=“M“ N: sonst
14SMS- Abbuchungskonto1DEGkti#C1O: DE ,,TAN-Medium- Klasse“=“M“ N: sonst
15Anzahl freie TANs1DEnum..3O1
16Letzte Benutzung1DEdat8O1
17Freigeschaltet am1DEdat8O1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:5
+ + +###### TAN-Prozess + +Beim Zwei-Schritt-Verfahren werden die notwendigen Prozess-Schritte mit- +tels des Geschäftsvorfalls HKTAN durchgeführt. Dieser unterstützt flexibel +vier unterschiedliche Ausprägungen für die beiden Prozessvarianten für +Zwei-Schritt-Verfahren, wobei die TAN-Prozesse 3 und 4 nicht isoliert und +nur in Verbindung mit TAN-Prozess=2 auftreten können. Der TAN-Prozess +wird wie folgt kodiert: + +Codierung: + +Prozessvariante 1: + +TAN-Prozess=1: + +Im ersten Schritt wird der Auftrags-Hashwert über den Geschäftsvorfall +HKTAN mitgeteilt, im zweiten Schritt erfolgt nach Ermittlung der TAN +aus der zurückgemeldeten Challenge die Einreichung des eigentlichen +Auftrags inklusive der TAN über das normale Auftragssegment. + +Abfolge der Segmente am Beispiel HKCCS: + +1\. Schritt: HKTAN <> HITAN + +2\. Schritt: HKCCS <> HIRMS zu HKCCS + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
136		Stand: 23.02.2018Kapitel: Data-Dictionary
Abschnitt: Sonstige
+ + +###### Prozessvariante 2: + +Im ersten Schritt wird der Auftrag komplett über das normale Auftrags- +segment eingereicht, jedoch ohne Übermittlung der TAN. Im zweiten +Schritt erfolgt nach Ermittlung der TAN aus der zurückgemeldeten Chal- +lenge die Einreichung der TAN über den Geschäftsvorfall HKTAN. + +Abfolge der Segmente am Beispiel HKCCS: + +Schritt 1: HKCCS und HKTAN <> HITAN + +Schritt 2: HKTAN <> HITAN und HIRMS zu HICCS + + +####### TAN-Prozess=2: + +kann nur im zweiten Schritt auftreten. Er dient zur Übermittlung der TAN +mittels HKTAN, nachdem der Auftrag selbst zuvor bereits mit TAN- +Prozess=3 oder 4 eingereicht wurde. Dieser Geschäftsvorfall wird mit +HITAN, TAN-Prozess=2 beantwortet. + + +####### TAN-Prozess=3: + +kann nur im ersten Schritt bei Mehrfach-TANs für die zweite und ggf. +dritte TAN auftreten. Hierdurch wird die Einreichung eingeleitet, wenn +zeitversetzte Einreichung von Mehrfach-TANs erlaubt ist. + + +####### TAN-Prozess=4: + +kann nur im ersten Schritt auftreten. Hiermit wird das Zwei-Schritt- +Verfahren nach Prozessvariante 2 für die erste TAN eingeleitet. HKTAN +wird zusammen mit dem Auftragssegment übertragen und durch HITAN +mit TAN-Prozess=4 beantwortet. TAN-Prozess=4 wird auch beim Ge- +schäftsvorfall „Prüfen / Verbrennen von TANs" eingesetzt. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:1
+ + +###### TAN-Verbrauchsdatum + +Datum, an dem die TAN verbraucht wurde. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dat
Länge:#
Version:1
+ + +###### TAN-Verbrauchserläuterung + +Freitextliche Erläuterung zum Geschäftsvorfall, für den die TAN verbraucht +wurde. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..99
Version:1
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FVD
Kapitel:Data-DictionaryStand:Seite:
Abschnitt:Sonstige23.02.2018137
+ + +###### TAN-Verbrauchskennzeichen + +Kennzeichnet, für welchen Zweck eine TAN verbraucht wurde. + +Folgende Codes sind gültig: + +0 +noch nicht verbraucht + +1 +nicht belegt + +2 +PIN-Änderung + +3 +Kontosperre aufheben + +4 +Aktivieren neuer TAN-Liste + +5 +Entwertete TAN (maschinell, z. B. bei TAN-Verbrennen) + +6 +Mitteilung mit TAN + +7 +Überweisung + +8 +Wertpapiertransaktion (Neuanlage/Änderung/Löschung) + +9 +Dauerauftrag (Neuanlage/Änderung/Löschung) + +10 +Entwertete TAN durch Überschreitung des Zeitlimits +im Zwei-Schritt-Verfahren + +11 +Entwertete TAN durch Überschreitung des Zeitlimits bei +Mehrfachsignaturen im Zwei-Schritt-Verfahren + +12 +Entwertete TAN (z. B. bei falsch beantworteter Challenge) + +20 +Lastschriften + +21 +Europa-Überweisung + +22 +Auslandsüberweisung + +23 +Terminüberweisung + +24 +Umbuchung + +50 bis + +98 +institutsindividuell + +99 +Sonstige + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:..2
Version:1
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
138		Stand: 23.02.2018Kapitel: Data-Dictionary
Abschnitt:
Sonstige
+ + +###### TAN-Verbrauchsuhrzeit + +Transaktionsnummer in Klarschrift. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:tim
Länge:#
Version:1
+ + +###### TAN zeitversetzt / dialogübergreifend erlaubt + +Angabe, ob beim Zwei-Schritt-Verfahren die zeitversetzte Einreichung von +Mehrfach-TANs erlaubt ist. Dies bedeutet, dass ein Zweit-Signierer zu einem +späteren Zeitpunkt eine TAN zu einem zuvor eingereichten Auftrag einrei- +chen darf. Voraussetzung ist, dass grundsätzlich die Verwendung von Mehr- +fach-TANs beim Zwei-Schritt-Verfahren erlaubt ist (vgl. Parameter „Mehr- +fach-TAN erlaubt"). Der Parameter ist in der vorliegenden Version so zu in- +terpretieren, dass ein Institut je nach Parametrisierung entweder zeitversetz- +te Eingabe erlaubt, oder nicht - jedoch nicht beide Varianten. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +###### TAN Zeit- und Dialogbezug + +Beschreibung der protokolltechnischen Möglichkeiten, die dem Kunden im +Zusammenhang mit Mehrfach-TANs zur Verfügung stehen. Es wird festge- +legt, ob die Eingabe der einzelnen TANs zu einem Auftrag durch die unter- +schiedlichen Benutzer synchron in einem Dialog erfolgen muss oder zeitver- +setzt in mehreren Dialogen erfolgen kann. Es wird auch festgelegt, ob ein +Institut nur eines dieser Verfahren oder beide parallel anbietet. Vorausset- +zung ist, dass grundsätzlich die Verwendung von Mehrfach-TANs beim Zwei- +Schritt-Verfahren erlaubt ist (vgl. Parameter ,,Mehrfach-TAN erlaubt"). Bei +Prozessvariante 1 ist der Parameter immer mit „nicht zutreffend“ zu belegen, +da hier generell keine zeitversetzte Verarbeitung möglich ist. Dieser Parame- +ter erweitert den Parameter ,,TAN zeitversetzt / dialogübergreifend erlaubt". + +Folgende Codes sind gültig: + +1 +TAN nicht zeitversetzt / dialogübergreifend erlaubt + +2 +TAN zeitversetzt / dialogübergreifend erlaubt + +3 +beide Verfahren unterstützt + +4 +nicht zutreffend + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:code
Länge:1
Version:1
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FVD
Kapitel:Data-DictionaryStand:Seite:
Abschnitt:Sonstige23.02.2018139
+ + +###### TAN-Zusatzinformationen + +Bei Einsatz des Zwei-Schritt-Verfahrens und Prozessvariante 1 kann ein +Kunde bei Einreichung des Auftrags-Hashwerts mit HKTAN eine kundenspe- +zifische Kennung einstellen, um einen Auftrag bei Anforderung der Challen- +ge wieder erkennen zu können. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..99
Version:1
+ + +###### Technische Identifikation TAN-Verfahren + +Da das Kundenprodukt die konkreten Zwei-Schritt-Verfahren i. d. R. nicht +kennt, stellt die technische Identifikation einen vom Institut zur Verfügung +gestellten Schlüsselbegriff dar, der vom Kundenprodukt zur internen Refe- +renzierung des konkreten Zwei-Schritt-Verfahrens verwendet werden kann. +Diese Information dient somit nur der internen Verarbeitung des Kundenpro- +duktes und wird dem Kunden nicht angezeigt. + + +![](figures/139.1) + + +Institute sollten die technische Identifikation eines konkre- +ten Zwei-Schritt-Verfahrens nicht wechseln, um dem Kun- +denprodukt eine eindeutige Referenzierung zu ermögli- +chen. + +Die technische Identifikation sollte keine Leerzeichen oder +Umlaute enthalten. Als Trennzeichen ist nur ,," (Unter- +strich) zugelassen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:id
Länge:#
Version:1
+ + +###### Text zur Belegung der Benutzerkennung + +Da in heutigen PIN/TAN-Verfahren i. d. R. keine Benutzerkennungen ver- +wendet werden, kann dem Kunden mit Hilfe dieses Textes mitgeteilt werden, +welche Eingabe im Feld ,,Benutzerkennung“ des Kundenproduktes erwartet +wird (z. B. die Kundennummer). + + +![](figures/139.2) + + +Kundenprodukte sollten diesen Text z.B. als Vorbelegung +im Feld „Benutzerkennung“ anzeigen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..30
Version:1
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
140		Stand: 23.02.2018Kapitel: Data-Dictionary
Abschnitt: Sonstige
+ + +###### Text zur Belegung der Kunden-ID + +Da in heutigen PIN/TAN-Verfahren i.d.R. keine Kunden-IDs verwendet wer- +den, kann dem Kunden mit Hilfe dieses Textes mitgeteilt werden, welche +Eingabe im Feld ,,Kunden-ID" des Kundenproduktes erwartet wird (z. B. die +Kundennummer). + + +![](figures/140.1) + + +Kundenprodukte sollten diesen Text z.B. als Vorbelegung +im Feld ,,Kunden-ID“ anzeigen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..30
Version:1
+ + +###### Text zur Belegung des Rückgabewertes im Zwei-Schritt-Verfahren + +Es wird ein Textfeld übergeben, das die Art des geforderten Rückgabewertes +beschreibt, z. B. ,,Challenge“ oder ,Index“. + + +![](figures/140.2) + + +Kundenprodukte sollten diesen Text als Beschreibung vor +bzw. in dem Eingabefeld für den Rückgabewert anzeigen. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..30
Version:1
+ + +###### Transaktionskonto + +Zahlungsverkehrskontoverbindung, für die eine mit Entgelten belegte Trans- +aktion durchgeführt wurde. Dies ist z. B. bei einer Überweisung die Auftrag- +geberkontoverbindung. + + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:kti
Länge:#
Version:1
+ + +V + + +###### Verfahrensbestätigung + +Beim Wechsel zwischen unterschiedlichen Zwei-Schritt-Verfahren kann in +bestimmten Situationen eine explizite Bestätigung des Kunden erforderlich +sein, die als Willenserklärung auch an das Kreditinstitut übermittelt werden +muss, um dort mit in die Dokumentation einfließen zu können. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FVD
Kapitel:Data-DictionaryStand:Seite:
Abschnitt:Sonstige23.02.2018141
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +###### Verfahrensbestätigung erforderlich + +Über diesen Parameter wird festgelegt, ob im Fall eines Wechsels zwischen +Zwei-Schritt-Verfahren eine explizite Verfahrensbestätigung des Kunden er- +forderlich ist oder nicht. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +###### Verfahrensparameter Zwei-Schritt-Verfahren, Elementversion #1 + +Parametrisierung konkreter Zwei-Schritt-Verfahren. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Sicherheitsfunktion, kodiert1DEcode..3M1900, ., 997
2TAN-Prozess1DEcode1M11,2
3Technische Identifi- kation TAN- Verfahren1DEid#M1
4Name des Zwei- Schritt-Verfahrens1DEan..30M1
5Maximale Länge des TAN-Eingabewertes im Zwei-Schritt- Verfahren1DEnum..2M1
6Erlaubtes Format im Zwei-Schritt- Verfahren1DEcode1M1
7Text zur Belegung des Rückgabewertes im Zwei-Schritt- Verfahren1DEan..30M1
8Maximale Länge des Rückgabewertes im Zwei-Schritt- Verfahren1DEnum..3M11..256
9Anzahl unterstützter aktiver TAN-Listen1DEnum1O1
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite: 142Stand: 23.02.2018Kapitel: Data-Dictionary
Abschnitt: Sonstige
+ + + + + + + + + + + + + + + + + + + + + + + + + +
10Mehrfach-TAN er- laubt1DEjn#M1
11TAN zeitversetzt / di- alogübergreifend er- laubt1DEjn#M1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:1
+ + +###### Verfahrensparameter Zwei-Schritt-Verfahren, Elementversion #2 + +Parametrisierung konkreter Zwei-Schritt-Verfahren. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Sicherheitsfunktion, kodiert1DEcode..3M1900, ., 997
2TAN-Prozess1DEcode1M11,2
3Technische Identifi- kation TAN- Verfahren1DEid#M1
4Name des Zwei- Schritt-Verfahrens1DEan..30M1
5Maximale Länge des TAN-Eingabewertes im Zwei-Schritt- Verfahren1DEnum..2M1
6Erlaubtes Format im Zwei-Schritt- Verfahren1DEcode1M1
7Text zur Belegung des Rückgabewertes im Zwei-Schritt- Verfahren1DEan..30M1
8Maximale Länge des Rückgabewertes im Zwei-Schritt- Verfahren2DEnum..3M11..256
9Anzahl unterstützter aktiver TAN-Listen1DEnum1O1
10Mehrfach-TAN er- laubt1DEjn#M1
11TAN Zeit- und Dia- logbezug1DEcode1M1
12TAN-Listennummer erforderlich1DEcode1M10,2
13Auftragsstorno er- laubt1DEjn#M1
14Challenge-Klasse er- forderlich1DEjn#M1
15Challenge-Betrag er- forderlich1DEjn#M1
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FVD
Kapitel:Data-DictionaryStand:Seite:
Abschnitt:Sonstige23.02.2018143
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:2
+ + +###### Verfahrensparameter Zwei-Schritt-Verfahren, Elementversion #3 + +Parametrisierung konkreter Zwei-Schritt-Verfahren. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Sicherheitsfunktion, kodiert1DEcode..3M1900,., 997
2TAN-Prozess1DEcode1M11,2
3Technische Identifi- kation TAN- Verfahren1DEid#M1
4Name des Zwei- Schritt-Verfahrens1DEan..30M1
5Maximale Länge des TAN-Eingabewertes im Zwei-Schritt- Verfahren1DEnum..2M1
6Erlaubtes Format im Zwei-Schritt- Verfahren1DEcode1M1
7Text zur Belegung des Rückgabewertes im Zwei-Schritt- Verfahren1DEan..30M1
8Maximale Länge des Rückgabewertes im Zwei-Schritt- Verfahren2DEnum..3M11..256
9Anzahl unterstützter aktiver TAN-Listen1DEnum1O1
10Mehrfach-TAN er- laubt1DEjn#M1
11TAN Zeit- und Dia- logbezug1DEcode1M1
12TAN-Listennummer erforderlich1DEcode1M10,2
13Auftragsstorno er- laubt1DEjn#M1
14Challenge-Klasse er- forderlich1DEjn#M1
15Challenge-Betrag er- forderlich1DEjn#M1
16Initialisierungsmodus1DEcode#M100,01,02
17Bezeichnung des TAN-Mediums erfor- derlich1DEcode1M10, 2
18Anzahl unterstützter aktiver TAN-Medien1DEnum1O1
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite: 144Stand: 23.02.2018Kapitel: Data-Dictionary
Abschnitt: Sonstige
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:3
+ + +###### Verfahrensparameter Zwei-Schritt-Verfahren, Elementversion #4 + +Parametrisierung konkreter Zwei-Schritt-Verfahren. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Sicherheitsfunktion, kodiert1DEcode..3M1900, ., 997
2TAN-Prozess1DEcode1M11,2
3Technische Identifi- kation TAN- Verfahren1DEid#M1
4ZKA TAN-Verfahren1DEan..32O1
5Version ZKA TAN- Verfahren1DEan.. 10O1
6Name des Zwei- Schritt-Verfahrens1DEan..30M1
7Maximale Länge des TAN-Eingabewertes im Zwei-Schritt- Verfahren1DEnum..2M1
8Erlaubtes Format im Zwei-Schritt- Verfahren1DEcode1M1
9Text zur Belegung des Rückgabewertes im Zwei-Schritt- Verfahren1DEan..30M1
10Maximale Länge des Rückgabewertes im Zwei-Schritt- Verfahren2DEnum..3M11..256
11Anzahl unterstützter aktiver TAN-Listen1DEnum1O1
12Mehrfach-TAN er- laubt1DEjn#M1
13TAN Zeit- und Dia- logbezug1DEcode1M1
14TAN-Listennummer erforderlich1DEcode1M10,2
15Auftragsstorno er- laubt1DEjn#M1
16SMS- Abbuchungskonto erforderlich1DEjn#M1
17Challenge-Klasse er- forderlich1DEjn#M1
18Challenge-Betrag er- forderlich1DEjn#M1
19Challenge strukturiert1DEjn#M1
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FVD
Kapitel:Data-DictionaryStand:Seite:
Abschnitt:Sonstige23.02.2018145
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
20Initialisierungsmodus1DEcode#M100,01,02
21Bezeichnung des TAN-Mediums erfor- derlich1DEcode1M10, 1, 2
22Anzahl unterstützter aktiver TAN-Medien1DEnum1O1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:4
+ + +###### Verfahrensparameter Zwei-Schritt-Verfahren, Elementversion #5 + +Parametrisierung konkreter Zwei-Schritt-Verfahren. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Sicherheitsfunktion, kodiert1DEcode..3M1900, ., 997
2TAN-Prozess1DEcode1M11,2
3Technische Identifi- kation TAN- Verfahren1DEid#M1
4ZKA TAN-Verfahren1DEan.32O1
5Version ZKA TAN- Verfahren1DEan.10O1
6Name des Zwei- Schritt-Verfahrens1DEan..30M1
7Maximale Länge des TAN-Eingabewertes im Zwei-Schritt- Verfahren1DEnum..2M1
8Erlaubtes Format im Zwei-Schritt- Verfahren1DEcode1M1
9Text zur Belegung des Rückgabewertes im Zwei-Schritt- Verfahren1DEan..30M1
10Maximale Länge des Rückgabewertes im Zwei-Schritt- Verfahren3DEnum..4M11..2048
11Anzahl unterstützter aktiver TAN-Listen1DEnum1O1
12Mehrfach-TAN er- laubt1DEjn#M1
13TAN Zeit- und Dia- logbezug1DEcode1M1
14TAN-Listennummer erforderlich1DEcode1M10,2
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite: 146Stand: 23.02.2018Kapitel: Data-Dictionary
Abschnitt: Sonstige
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
15Auftragsstorno er- laubt1DEjn#M1
16SMS- Abbuchungskonto erforderlich2DEcode1M10, 1, 2
17Auftraggeberkonto erforderlich1DEcode1M10, 2
18Challenge-Klasse er- forderlich1DEjn#M1
19Challenge strukturiert1DEjn#M1
20Initialisierungsmodus1DEcode#M100,01,02
21Bezeichnung des TAN-Mediums erfor- derlich1DEcode1M10, 1, 2
22Anzahl unterstützter aktiver TAN-Medien1DEnum1O1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:5
+ + +###### Verfahrensparameter Zwei-Schritt-Verfahren, Elementversion #6 + +Parametrisierung konkreter Zwei-Schritt-Verfahren. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Sicherheitsfunktion, kodiert1DEcode..3M1900, ., 997
2TAN-Prozess1DEcode1M11,2
3Technische Identifi- kation TAN- Verfahren1DEid#M1
4ZKA TAN-Verfahren1DEan.32O1
5Version ZKA TAN- Verfahren1DEan..10O1
6Name des Zwei- Schritt-Verfahrens1DEan..30M1
7Maximale Länge des TAN-Eingabewertes im Zwei-Schritt- Verfahren1DEnum..2M1
8Erlaubtes Format im Zwei-Schritt- Verfahren1DEcode1M1
9Text zur Belegung des Rückgabewertes im Zwei-Schritt- Verfahren1DEan..30M1
10Maximale Länge des Rückgabewertes im Zwei-Schritt- Verfahren3DEnum..4M11..2048
11Mehrfach-TAN er-1DEjn#M1
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FVD
Kapitel:Data-DictionaryStand:Seite:
Abschnitt:Sonstige23.02.2018147
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
laubt
12TAN Zeit- und Dia- logbezug1DEcode1M1
13Auftragsstorno er- laubt1DEjn#M1
14SMS- Abbuchungskonto erforderlich2DEcode1M10, 1, 2
15Auftraggeberkonto erforderlich1DEcode1M10, 2
16Challenge-Klasse er- forderlich1DEjn#M1
17Challenge strukturiert1DEjn#M1
18Initialisierungsmodus1DEcode#M100,01,02
19Bezeichnung des TAN-Mediums erfor- derlich1DEcode1M10, 1, 2
20Antwort HHD UC er- forderlich1DEjn#M1
21Anzahl unterstützter aktiver TAN-Medien1DEnum1O1
+ + + + + + + + + + + + + + + + + + + +
Typ:DEG
Format:
Länge:
Version:6
+ + +###### Version ZKA-TAN-Verfahren + +Bei Einsatz eines ZKA TAN Zwei-Schritt-Verfahrens ist hier optional die An- +gabe einer Versionsbezeichnung möglich. + +Bei folgenden ZKA-Verfahren ist die Angabe der Version zwingend erforder- +lich; die verbindlichen Werte sind den jeweiligen Spezifikationen bzw. Bele- +gungsrichtlinien zu entnehmen: + +HHD: +z. B. 1.3.1 +(vgl. [HHD-Belegung]) + +HHDOPT1: z. B. 1.4 + +(vgl. [HHD-Belegung]) + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:.. 10
Version:1
+ + +###### Versionsinfo der chipTAN-Applikation + +Nur bei bidirektionalen chipTAN-Verfahren mit Secoder 3: Bestandteil der +Antwort auf das Secoder-Kommando ,,SECODER TRANSMIT HHDUC". + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
148		Stand: 23.02.2018Kapitel: Data-Dictionary
Abschnitt: Sonstige
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:bin
Länge:256
Version:1
+ + +###### Von Datum + +Anfangsdatum eines Zeitraums (s. [Formals], Kap. B.6.3 „Abholauftrag“). + +Durch die Eingabe von Von- und Bis-Datum kann ein Zeitraum eingegrenzt +werden, für den Informationseinträge vom Kreditinstitut rückzumelden sind. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:dat
Länge:#
Version:1
+ + +W + + +###### Weitere TAN folgt + +Das Kundenprodukt teilt mit, ob dies die letzte / einzige benötigte TAN für +den bereits eingereichten Auftrag ist, oder ob noch mindestens eine weitere +TAN eingereicht wird. + + +![](figures/148.1) + + +Kundenprodukte können entweder aus der UPD („Anzahl +benötigter Signaturen“) oder aufgrund eigener Administrati- +onsfunktionen entscheiden, ob für einen Auftrag noch wei- +tere TANs benötigt werden. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + +Z + + +###### ZKA TAN-Verfahren + +Es existieren FinTS Zwei-Schritt-Verfahren, die entweder im ZKA standardi- +siert sind oder deren Rahmenbedingungen für den Einsatz festgelegt sind. + +Folgende Verfahrensbezeichnungen sind gültig: + +HHD +[HHD], [HHD-Belegung] + +HHDUC +[HHD], [HHD-Belegung] + +HHDOPT1 [HHD], [HHD-Belegung], [HHD-Erweiterung] +mobileTAN [mobileTAN] + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FVD
Kapitel:Data-DictionaryStand:Seite:
Abschnitt:Sonstige23.02.2018149
+ + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:an
Länge:..32
Version:1
+ + +###### Zulässige Kartenart + +Informationen zu den zulässigen Kartenarten für das An- bzw. Ummelden +von TAN-Generatoren (HKTAU). + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:num
Länge:..2
Version:1
+ + +###### Zustimmung zur Kontaktaufnahme unterstützt + +Über diesen Parameter wird festgelegt, ob das Kreditinstitut die Steuerung +der Zustimmung des Kunden zur Kontaktaufnahme unterstützt oder nicht. + + + + + + + + + + + + + + + + + + + +
Typ:DE
Format:jn
Länge:#
Version:1
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite: 150Stand: 23.02.2018Kapitel: Archiv: Ältere Segmentversionen
Abschnitt: HKTAN für Zwei-Schritt-TAN-Einreichung
+ + +###### E. ARCHIV: ÄLTERE SEGMENTVERSIONEN + +In diesem Abschnitt befinden sich ältere Segmentversionen von HKTAN bzw. +PIN/TAN-Managementgeschäftsvorfällen, die je nach Institut noch angeboten wer- +den. + + +####### E.1 HKTAN für Zwei-Schritt-TAN-Einreichung + + +######## E.1.1 Geschäftsvorfall HKTAN in Segmentversion #1 + +Die Segmentversion #1 dieses Geschäftsvorfalls wird von Kreditinstituten verwen- +det, die das Zwei-Schritt-Verfahren ohne die Erweiterungen zur Unterstützung der +Challenge-Klasse anbieten. Kreditinstitute können zusätzlich auch die Segmentver- +sion #2 oder höher anbieten. + +Realisierung Bank: +verpflichtend in Segmentversion #1 oder höher, falls +Geschäftsvorfälle mit PIN/TAN-Absicherung im Zwei-Schritt- +Verfahren angeboten werden + +Realisierung Kunde: +optional + + +######### a) Kundenauftrag + + +######### Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Zwei-Schritt-TAN-Einreichung
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKTAN
Bezugssegment:-
Segmentversion:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2TAN-Prozess1DEcode1M11, 2, 3, 4
3Auftrags-Hashwert1DEbin.256C1M: bei Auftrags- Hashwertverfahren<>0 und TAN-Prozess=1 N: sonst
4Auftragsreferenz1DEan..35C1M: bei TAN-Prozess=2, 3 N: TAN-Prozess=1, 4
5TAN-Listennummer1DEan..20C1M: bei TAN-Prozess=1, 3, 4 und „Anzahl unterstützter aktiver TAN-Listen“ > 1 O: sonst
6Weitere TAN folgt1DEjn1C1M: bei TAN-Prozess=1, 2 N: bei TAN-Prozess=3, 4
7TAN- Zusatzinformatio- nen1DEan.99C1O: bei TAN-Prozess=1 N: bei TAN-Prozess=2, 3, 4
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: D
Dokument:Security - Sicherheitsverfahren PIN/TAN
Kapitel:
Abschnitt:		Archiv: Ältere Segmentversionen HKTAN für Zwei-Schritt-TAN-EinreichungStand: 23.02.2018Seite: 151
+ + +###### ◆ Belegungsrichtlinien + + +####### Auftragsreferenz + +Als Auftragsreferenz ist derjenige Wert einzustellen, der bei der Auftragsein- +reichung im Rahmen der Kreditinstitutsrückmeldung mitgeteilt wurde. + + +####### TAN-Listennummer + +Ist in der BPD als ,,Anzahl unterstützter aktiver TAN-Listen“ ein Wert > 1 an- +gegeben, so muss der Kunde z. B. im Falle eines indizierten TAN-Verfahrens +hier seine für diesen Auftrag zu verwendende TAN-Liste angeben. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
152		Stand: 23.02.2018Kapitel: Archiv: Ältere Segmentversionen
Abschnitt: HKTAN für Zwei-Schritt-TAN-Einreichung
+ + +b) +Kreditinstitutsrückmeldung + +Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Zwei-Schritt-TAN-Einreichung Rückmeldung
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HITAN
Bezugssegment:HKTAN
Segmentversion:1
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2TAN-Prozess1DEcode1M11, 2, 3, 4
3Auftrags-Hashwert1DEbin.256C1M: bei Auftrags- Hashwertverfahren<>0 und TAN-Prozess=1 N: sonst
4Auftragsreferenz1DEan..35C1M: bei TAN-Prozess=2, 3, 4 O: bei TAN-Prozess=1
5Challenge1DEan.256C1M: bei TAN-Prozess=1, 3, 4 O: bei TAN-Prozess=2
6Gültigkeitsdatum und -uhrzeit für Challenge1DEGO1
7TAN-Listennummer1DEan..20C1M: bei TAN-Prozess=1, 3, 4 und „Anzahl unterstützter aktiver TAN-Listen" nicht vorhanden O: sonst
8TAN- Zusatzinformatio- nen1DEan..99C1O: bei TAN-Prozess=1 N: bei TAN-Prozess=2, 3, 4
+ + +###### ◆ Belegungsrichtlinien + + +####### Auftrags-Hashwert + +Es ist der in der Kundennachricht in HKTAN übermittelte Auftrags-Hashwert +unverändert einzustellen. + + +####### Challenge + +Obwohl die Challenge bei Prozessvariante 2 im zweiten Schritt nicht zwin- +gend benötigt wird, sollte sie aus Integritätsgründen trotzdem übertragen +werden. + + +####### TAN-Listennummer + +Ist in der BPD der Parameter „Anzahl unterstützter aktiver TAN-Listen" nicht +vorhanden, so muss das Institut dem Kunden hier mitteilen, welche TAN- +Liste er z. B. bei Einsatz eines indizierten TAN-Verfahrens verwenden soll. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: D
Dokument:Security - Sicherheitsverfahren PIN/TAN
Kapitel:
Abschnitt:		Archiv: Ältere Segmentversionen HKTAN für Zwei-Schritt-TAN-EinreichungStand: 23.02.2018Seite: 153
+ + +###### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
9210Auftrag abgelehnt – Auftragsdaten inkonsistent. Eingereichter Auftrag gelöscht
9210Auftrag abgelehnt - Zwei-Schritt-TAN inkonsistent. Eingereichter Auftrag gelöscht
9210Auftrag abgelehnt – Kein eingereichter Auftrag gefunden
9210Auftrag abgelehnt – Auftragsreferenz ist unbekannt
9330TAN-Generator gesperrt. Führen Sie ggf. eine TAN-Gen.-Synchronisation durch
9360Sperrung der TAN-Liste nach weiteren x Fehlversuchen
9380Gewähltes Zwei-Schritt-TAN-Verfahren nicht zulässig
9931Sperrung des Kontos nach x Fehlversuchen
9941TAN ungültig
9951Zeitüberschreitung im Zwei-Schritt-Verfahren – TAN ungültig
9953Nur ein TAN-pflichtiger Auftrag pro Nachricht erlaubt
9954Mehrfach-TANs nicht erlaubt
9955Ein-Schritt-TAN-Verfahren nicht zugelassen
9956Zeitversetzte Eingabe von Mehrfach-TANs nicht erlaubt
9991TAN bereits verbraucht
+ + +###### c) Bankparameterdaten + + +###### Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Zwei-Schritt-TAN-Einreichung, Parameter
Typ:Segment
Segmentart:Geschäftsvorfallparameter
Kennung:HITANS
Bezugssegment:HKVVB
Segmentversion:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Zwei- Schritt-TAN- Einreichung1DEGM1
+ + +##### E.1.2 Geschäftsvorfall HKTAN in Segmentversion #2 + +Die Segmentversion #2 dieses Geschäftsvorfalls wird von Kreditinstituten verwen- +det, die das Zwei-Schritt-Verfahren inklusive der Erweiterungen zur Unterstützung +der Challenge-Klasse anbieten. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite: 154Stand: 23.02.2018Kapitel: Archiv: Ältere Segmentversionen
Abschnitt: HKTAN für Zwei-Schritt-TAN-Einreichung
+ + + + + + + + + + + +
Realisierung Bank:verpflichtend in mindestens einer Segmentversion, falls Geschäftsvorfälle mit PIN/TAN-Absicherung im Zwei-Schritt-Verfahren angeboten werden
Realisierung Kunde:optional
+ + +# a) Kundenauftrag + +Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Zwei-Schritt-TAN-Einreichung
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKTAN
Bezugssegment:-
Segmentversion:2
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2TAN-Prozess1DEcode1M11, 2, 3, 4
3Auftrags-Hashwert1DEbin.256C1M: bei Auftrags- Hashwertverfahren<>0 und TAN-Prozess=1 N: sonst
4Auftragsreferenz1DEan..35C1M: bei TAN-Prozess=2, 3 O: TAN-Prozess=1, 4
5TAN-Listennummer1DEan..20C1M: bei TAN-Prozess=1, 3, 4 und „Anzahl unterstützter aktiver TAN-Listen" > 1 und ,TAN-Listennummer erfor- derlich“=2 O: sonst
6Weitere TAN folgt1DEjn1C1M: bei TAN-Prozess=1, 2 N: bei TAN-Prozess=3, 4
7Auftrag stornieren1DEjn1C1O: bei TAN-Prozess=2 und „Auftragsstorno erlaubt“=J N: sonst
8Challenge-Klasse1DEnum..2C1M: bei TAN-Prozess=1 und ,Challenge-Klasse erforder- lich“=J N: sonst
9Parameter Challen- ge-Klasse1DEGC1O: bei TAN-Prozess=1 und ,,Challenge-Klasse erforder- lich“=J N: sonst
+ + +# ◆ Belegungsrichtlinien + + +# Auftragsreferenz + +Als Auftragsreferenz ist derjenige Wert einzustellen, der bei der Auftragsein- +reichung im Rahmen der Kreditinstitutsrückmeldung mitgeteilt wurde. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: D
Dokument:Security - Sicherheitsverfahren PIN/TAN
Kapitel:
Abschnitt:		HKTAN für Zwei-Schritt-TAN-Einreichung
Archiv: Ältere Segmentversionen		Stand: 23.02.2018Seite: 155
+ + +## Parameter Challenge-Klasse + +Die Parameter zur Challenge-Klasse dienen zur Übermittlung von Daten, die +bei Prozessvariante 1 im ersten Verfahrensschritt für die weitere Steuerung +benötigt werden. Ist das Datenelement ,,Challenge-Klasse“ belegt, so müs- +sen die Parameter die zur jeweiligen Challenge-Klasse passenden Informati- +onen, z. B. Empfänger-IBAN oder eine Wertpapierkennnummer enthalten. + +Ist das Datenelement ,,Challenge-Betrag erforderlich“ in den BPD mit „J“ be- +legt, muss bei Vorhandensein einer Betragsinformation im Auftrag dieser +Challenge-Betragswert direkt anschließend an die regulären Challenge- +Klasse-Parameter als zusätzliche(r) Challenge-Klasse Parameter übermittelt +werden. Je nach konkretem Zwei-Schritt-Verfahren muss ggf. auch eine zu- +gehörige Challenge-Betragswährung als weiterer Parameter eingestellt wer- +den. + +Hierbei gilt folgende Belegungsvorschrift: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Challenge- BetragswertDEan..999M1
2Challenge- BetragswährungDEan..999M1
+ + +Das alfanumerische DE "Challenge-Betragswert" muss analog der Belegung +des abgeleiteten Formats ,,wrt“ (vgl. [Formals], Kapitel B.4.2) befüllt werden. + +Das alfanumerische DE "Challenge-Betragswährung" muss analog der Bele- +gung des abgeleiteten Formats ,,cur" (vgl. [Formals], Kapitel B.4.2) befüllt +werden. Falls in den Auftragsdaten keine oder keine eindeutige Währung +existiert, ist es mit "000" zu befüllen. Weitere Belegungsrichtlinien für Chal- +lenge-Betragswert und Challenge-Betragswährung hängen vom verwende- +ten konkreten Zwei-Schritt-Verfahren ab und sind der dortigen Spezifikation +zu entnehmen. + + +## TAN-Listennummer + +Ist in der BPD als „Anzahl unterstützter aktiver TAN-Listen“ ein Wert > 1 an- +gegeben und ist der BPD-Wert für „TAN-Listennummer erforderlich“ = 2, so +muss der Kunde z. B. im Falle eines indizierten TAN-Verfahrens hier seine +für diesen Auftrag zu verwendende TAN-Liste angeben. + + +### b) Kreditinstitutsrückmeldung + +Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Zwei-Schritt-TAN-Einreichung Rückmeldung
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HITAN
Bezugssegment:HKTAN
Segmentversion:2
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite: 156Stand: 23.02.2018Kapitel: Archiv: Ältere Segmentversionen
Abschnitt: HKTAN für Zwei-Schritt-TAN-Einreichung
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2TAN-Prozess1DEcode1M11, 2, 3, 4
3Auftrags-Hashwert1DEbin.256C1M: bei Auftrags- Hashwertverfahren<>0 und TAN-Prozess=1, N: sonst
4Auftragsreferenz1DEan..35C1M: bei TAN-Prozess=2, 3, 4 O: bei TAN-Prozess=1
5Challenge2DEan.999C1M: bei TAN-Prozess=1, 3, 4 O: bei TAN-Prozess=2
6Gültigkeitsdatum und -uhrzeit für Challenge1DEGO1
7TAN-Listennummer1DEan..20C1M: bei TAN-Prozess=1, 3, 4 und „Anzahl unterstützter aktiver TAN-Listen" nicht vorhanden O: sonst
8BEN1DEan..99C1O: bei TAN-Prozess=2 N: sonst
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2TAN-Prozess1DEcode1M11, 2, 3, 4
3Auftrags-Hashwert1DEbin.256C1M: bei Auftrags- Hashwertverfahren<>0 und TAN-Prozess=1, N: sonst
4Auftragsreferenz1DEan..35C1M: bei TAN-Prozess=2, 3, 4 O: bei TAN-Prozess=1
5Challenge2DEan..999C1M: bei TAN-Prozess=1, 3, 4 O: bei TAN-Prozess=2
6Gültigkeitsdatum und -uhrzeit für Challenge1DEGO1
7TAN-Listennummer1DEan..20C1M: bei TAN-Prozess=1, 3, 4 und „Anzahl unterstützter aktiver TAN-Listen" nicht vorhanden
O: sonst
8BEN1DEan..99C1O: bei TAN-Prozess=2 N: sonst
+ + +#### ◆ Belegungsrichtlinien + + +##### Auftrags-Hashwert + +Es ist der in der Kundennachricht in HKTAN übermittelte Auftrags-Hashwert +unverändert einzustellen. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: D
Dokument:Security - Sicherheitsverfahren PIN/TAN
Kapitel:
Abschnitt:		Archiv: Ältere Segmentversionen HKTAN für Zwei-Schritt-TAN-EinreichungStand: 23.02.2018Seite: 157
+ + +# Auftragsreferenz + +Bei TAN-Prozess=2, 3 und 4 muss die Auftragsreferenz vom Institut immer +eingestellt werden. Bei TAN-Prozess=1 muss die Auftragsreferenz einge- +stellt werden, wenn sie zuvor im Segment HKTAN vom Kunden gesendet +wurde. + + +# Challenge + +Obwohl die Challenge bei Prozessvariante 2 im zweiten Schritt nicht zwin- +gend benötigt wird, sollte sie aus Integritätsgründen trotzdem übertragen +werden. + + +![](figures/157.1) + + +Das Kundenprodukt muss den Inhalt der empfangenen Challenge +dem Kunden unverändert anzeigen. + +Erläuterung: Die Challenge kann institutsindividuell aufgebaut wer- +den (z. B. 1 oder 2 Eingabefelder für den chipTAN-Leser). + + +## TAN-Listennummer + +Ist in der BPD der Parameter ,,Anzahl unterstützter aktiver TAN-Listen“ nicht +vorhanden, so muss das Institut dem Kunden hier mitteilen, welche TAN- +Liste er z. B. bei Einsatz eines indizierten TAN-Verfahrens verwenden soll. + + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
9210Auftrag abgelehnt – Auftragsdaten inkonsistent. Eingereichter Auftrag gelöscht
9210Auftrag abgelehnt – Zwei-Schritt-TAN inkonsistent. Eingereichter Auftrag gelöscht
9210Auftrag abgelehnt – Kein eingereichter Auftrag gefunden
9210Auftrag abgelehnt – Auftragsreferenz ist unbekannt
9330chipTAN-Leser gesperrt. Führen Sie ggf. eine chipTAN-Synchronisation durch
9360Sperrung der TAN-Liste nach weiteren x Fehlversuchen
9380Gewähltes Zwei-Schritt-TAN-Verfahren nicht zulässig
9931Sperrung des Kontos nach x Fehlversuchen
9941TAN ungültig
9951Zeitüberschreitung im Zwei-Schritt-Verfahren – TAN ungültig
9953Nur ein TAN-pflichtiger Auftrag pro Nachricht erlaubt
9954Mehrfach-TANs nicht erlaubt
9955Ein-Schritt-TAN-Verfahren nicht zugelassen
9956Zeitversetzte Eingabe von Mehrfach-TANs nicht erlaubt
9991TAN bereits verbraucht
+ + +## c) Bankparameterdaten + + +## Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Zwei-Schritt-TAN-Einreichung, Parameter
Typ:Segment
Segmentart:Geschäftsvorfallparameter
Kennung:HITANS
Bezugssegment:HKVVB
Segmentversion:2
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite: 158Stand: 23.02.2018Kapitel: Archiv: Ältere Segmentversionen
Abschnitt: HKTAN für Zwei-Schritt-TAN-Einreichung
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Zwei- Schritt-TAN- Einreichung2DEGM1
+ + +## ◆ Belegungsrichtlinien + +Auftrags-Hashwertverfahren (Parameter Zwei-Schritt-TAN-Einreichung) +Bei Verwendung von TAN-Prozess=1. + + +### E.1.3 Geschäftsvorfall HKTAN in Segmentversion #3 + +Die Segmentversion #3 dieses Geschäftsvorfalls wird von Kreditinstituten verwen- +det, die das Zwei-Schritt-Verfahren in Kombination mit HHD V1.3 und/oder mobi- +leTAN anbieten. Mit dieser Version können aber auch alle anderen PIN/TAN Zwei- +Schritt-Verfahren unterstützt werden; wahlweise können Kreditinstitute zusätzlich +auch andere Segmentversionen anbieten. + +Realisierung Bank: +verpflichtend in mindestens einer Segmentversion, falls +Geschäftsvorfälle mit PIN/TAN-Absicherung im Zwei- +Schritt-Verfahren angeboten werden + +Realisierung Kunde: +optional + + +#### a) Kundenauftrag + + +#### Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Zwei-Schritt-TAN-Einreichung
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKTAN
Bezugssegment:-
Segmentversion:3
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: D
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FV
Kapitel:Archiv: Ältere SegmentversionenStand:Seite:
Abschnitt:HKTAN für Zwei-Schritt-TAN-Einreichung23.02.2018159
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2TAN-Prozess1DEcode1M11, 2, 3, 4
3Auftrags-Hashwert1DEbin.256C1M: bei Auftrags- Hashwertverfahren<>0 und TAN-Prozess=1 N: sonst
4Auftragsreferenz1DEan..35C1M: bei TAN-Prozess=2, 3 O: TAN-Prozess=1, 4
5TAN-Listennummer1DEan..20C1M: bei TAN-Prozess=1, 3, 4 und „Anzahl unterstützter aktiver TAN-Listen“ > 1 und ,TAN-Listennummer erfor- derlich“=2
O: sonst
6Weitere TAN folgt1DEjn1C1M: bei TAN-Prozess=1, 2 N: bei TAN-Prozess=3, 4
7Auftrag stornieren1DEjn1C1O: bei TAN-Prozess=2 und „Auftragsstorno erlaubt“=J N: sonst
8Challenge-Klasse1DEnum..2C1M: bei TAN-Prozess=1 und „Challenge-Klasse erforder- lich“=J N: sonst
9Parameter Challen- ge-Klasse1DEGC1O: bei TAN-Prozess=1 und ,Challenge-Klasse erforder- lich“=J N: sonst
10Bezeichnung des TAN-Mediums1DEan..32C1M: bei TAN-Prozess=1, 3, 4 und „Anzahl unterstützter aktiver TAN-Medien" > 1 und ,,Bezeichnung des TAN-Mediums erforder- lich“=2 O: sonst
+ + +#### ◆ Belegungsrichtlinien + + +##### Auftragsreferenz + +Als Auftragsreferenz ist derjenige Wert einzustellen, der bei der Auftragsein- +reichung im Rahmen der Kreditinstitutsrückmeldung mitgeteilt wurde. + + +##### Parameter Challenge-Klasse + +Die Parameter zur Challenge-Klasse dienen zur Übermittlung von Daten, die +bei Prozessvariante 1 im ersten Verfahrensschritt für die weitere Steuerung +benötigt werden. Ist das Datenelement ,,Challenge-Klasse“ belegt, so muss +im ersten Parameter P1 die Segmentkennung des jeweiligen Geschäftsvor- +falls eingestellt werden. Die weiteren Parameter müssen die zur jeweiligen +Challenge-Klasse passenden Informationen, z. B. Empfänger-IBAN oder ei- +ne Wertpapierkennnummer enthalten. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
160		Stand: 23.02.2018Kapitel: Archiv: Ältere Segmentversionen
Abschnitt: HKTAN für Zwei-Schritt-TAN-Einreichung
+ + +Ist das Datenelement ,,Challenge-Betrag erforderlich" in den BPD mit „J“ be- +legt, muss bei Vorhandensein einer Betragsinformation im Auftrag dieser +Challenge-Betragswert direkt anschließend an die regulären Challenge- +Klasse-Parameter als zusätzliche(r) Challenge-Klasse Parameter übermittelt +werden. Je nach konkretem Zwei-Schritt-Verfahren muss ggf. auch eine zu- +gehörige Challenge-Betragswährung als weiterer Parameter eingestellt wer- +den. + +Hierbei gilt folgende Belegungsvorschrift: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Challenge- BetragswertDEan..999M1
2Challenge- BetragswährungDEan..999M1
+ + +Das alfanumerische DE "Challenge-Betragswert" muss analog der Belegung +des abgeleiteten Formats ,wrt“ (vgl. [Formals], Kapitel B.4.2) befüllt werden. + +Das alfanumerische DE "Challenge-Betragswährung" muss analog der Bele- +gung des abgeleiteten Formats ,,cur" (vgl. [Formals], Kapitel B.4.2) befüllt +werden. Falls in den Auftragsdaten keine oder keine eindeutige Währung +existiert, ist es mit "000" zu befüllen. + +Weitere Belegungsrichtlinien für Challenge-Betragswert und Challenge- +Betragswährung hängen vom verwendeten konkreten Zwei-Schritt-Verfahren +ab und sind der dortigen Spezifikation zu entnehmen. + + +### TAN-Listennummer + +Ist in der BPD als „Anzahl unterstützter aktiver TAN-Listen“ ein Wert > 1 an- +gegeben und ist der BPD-Wert für „TAN-Listennummer erforderlich“ = 2, so +muss der Kunde z. B. im Falle eines indizierten TAN-Verfahrens hier seine +für diesen Auftrag zu verwendende TAN-Liste angeben. + + +### Bezeichnung des TAN-Mediums + +Ist in der BPD als "Anzahl unterstützter aktiver TAN-Medien“ ein Wert > 1 +angegeben und ist der BPD-Wert für „Bezeichnung des TAN-Mediums erfor- +derlich" = 2, so muss der Kunde z. B. im Falle des mobileTAN-Verfahrens +hier die Bezeichnung seines für diesen Auftrag zu verwendenden TAN- +Mediums angeben. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: D
Dokument:Security - Sicherheitsverfahren PIN/TAN
Kapitel:
Abschnitt:		Archiv: Ältere Segmentversionen
HKTAN für Zwei-Schritt-TAN-Einreichung		Stand: 23.02.2018Seite: 161
+ + +#### b) Kreditinstitutsrückmeldung + +Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Zwei-Schritt-TAN-Einreichung Rückmeldung
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HITAN
Bezugssegment:HKTAN
Segmentversion:3
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.1NameVer- sionTypFor- matLän- geSta- tusAn- zahl1Restriktionen
1Segmentkopf1DEGM1
2TAN-Prozess1DEcode1M11, 2, 3, 4
3Auftrags-Hashwert1DEbin.256C1M: bei Auftrags- Hashwertverfahren<>0 und TAN-Prozess=1, N: sonst
4Auftragsreferenz1DEan..35C1M: bei TAN-Prozess=2, 3, 4 O: bei TAN-Prozess=1
5Challenge2DEan..999C1M: bei TAN-Prozess=1, 3, 4 O: bei TAN-Prozess=2
6Gültigkeitsdatum und -uhrzeit für Challenge1DEGO1
7TAN-Listennummer1DEan..20C1M: bei TAN-Prozess=1, 3, 4 und „Anzahl unterstützter aktiver TAN-Listen" nicht vorhanden O: sonst
8BEN1DEan..99C1O: bei TAN-Prozess=2 N: sonst
9Bezeichnung des TAN-Mediums1DEan..32C1M: bei TAN-Prozess=1, 3, 4 und „Anzahl unterstützter aktiver TAN-Medien" nicht vorhanden O: sonst
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite: 162Stand: 23.02.2018Kapitel: Archiv: Ältere Segmentversionen
Abschnitt: HKTAN für Zwei-Schritt-TAN-Einreichung
+ + +## ◆ Belegungsrichtlinien + +Auftrags-Hashwert + +Es ist der in der Kundennachricht in HKTAN übermittelte Auftrags-Hashwert +unverändert einzustellen. + + +### Auftragsreferenz + +Bei TAN-Prozess=2, 3 und 4 muss die Auftragsreferenz vom Institut immer +eingestellt werden. Bei TAN-Prozess=1 muss die Auftragsreferenz einge- +stellt werden, wenn sie zuvor im Segment HKTAN vom Kunden gesendet +wurde. + +Challenge + +Obwohl die Challenge bei Prozessvariante 2 im zweiten Schritt nicht zwin- +gend benötigt wird, sollte sie aus Integritätsgründen trotzdem übertragen +werden. + + +![](figures/162.1) + + +Das Kundenprodukt muss den Inhalt der empfangenen Challenge +dem Kunden unverändert anzeigen. + +Erläuterung: Die Challenge kann institutsindividuell aufgebaut wer- +den (z. B. 1 oder 2 Eingabefelder für den chipTAN-Leser). + + +#### TAN-Listennummer + +Ist in der BPD der Parameter ,,Anzahl unterstützter aktiver TAN-Listen“ nicht +vorhanden, so muss das Institut dem Kunden hier mitteilen, welche TAN- +Liste er z. B. bei Einsatz eines indizierten TAN-Verfahrens verwenden soll. + + +### Bezeichnung des TAN-Mediums + +Ist in der BPD der Parameter „Anzahl unterstützter aktiver TAN-Medien“ +nicht vorhanden, so muss das Institut dem Kunden hier mitteilen, welches +TAN-Medium er z. B. beim mobileTAN-Verfahren verwenden soll. + + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
9210Auftrag abgelehnt – Auftragsdaten inkonsistent. Eingereichter Auftrag gelöscht
9210Auftrag abgelehnt – Zwei-Schritt-TAN inkonsistent. Eingereichter Auftrag gelöscht
9210Auftrag abgelehnt – Kein eingereichter Auftrag gefunden
9210Auftrag abgelehnt – Auftragsreferenz ist unbekannt
9330chipTAN-Leser gesperrt. Führen Sie ggf. eine chipTAN-Synchronisation durch
9360Sperrung der TAN-Liste nach weiteren x Fehlversuchen
9380Gewähltes Zwei-Schritt-TAN-Verfahren nicht zulässig
9931Sperrung des Kontos nach x Fehlversuchen
9941TAN ungültig
9951Zeitüberschreitung im Zwei-Schritt-Verfahren – TAN ungültig
9953Nur ein TAN-pflichtiger Auftrag pro Nachricht erlaubt
9954Mehrfach-TANs nicht erlaubt
9955Ein-Schritt-TAN-Verfahren nicht zugelassen
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: D
Dokument:Security - Sicherheitsverfahren PIN/TAN
Kapitel:
Abschnitt:		HKTAN für Zwei-Schritt-TAN-Einreichung
Archiv: Ältere Segmentversionen		Stand: 23.02.2018Seite: 163
+ + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
9956Zeitversetzte Eingabe von Mehrfach-TANs nicht erlaubt
9991TAN bereits verbraucht
+ + +c) +Bankparameterdaten + + +### Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Zwei-Schritt-TAN-Einreichung, Parameter
Typ:Segment
Segmentart:Geschäftsvorfallparameter
Kennung:HITANS
Bezugssegment:HKVVB
Segmentversion:3
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Zwei- Schritt-TAN- Einreichung3DEGM1
+ + +## ◆ Belegungsrichtlinien + +Auftrags-Hashwertverfahren (Parameter Zwei-Schritt-TAN-Einreichung) +Bei Verwendung von TAN-Prozess=1. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
164		Stand: 23.02.2018Kapitel: Archiv: Ältere Segmentversionen
Abschnitt: HKTAN für Zwei-Schritt-TAN-Einreichung
+ + +### E.1.4 Geschäftsvorfall HKTAN in Segmentversion #4 + +Ab der Segmentversion #4 dieses Geschäftsvorfalls ist das chipTAN-Verfahren mit +unidirektionaler Kopplung unterstützt. Mit dieser Version können aber auch alle an- +deren PIN/TAN Zwei-Schritt-Verfahren unterstützt werden; wahlweise können Kre- +ditinstitute zusätzlich auch andere Segmentversionen von HKTAN anbieten. + +Realisierung Bank: verpflichtend in mindestens einer Segmentversion, falls +Geschäftsvorfälle mit PIN/TAN-Absicherung im Zwei-Schritt- +Verfahren angeboten werden. + +Realisierung Kunde: optional + + +#### a) Kundenauftrag + + +##### Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Zwei-Schritt-TAN-Einreichung
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKTAN
Bezugssegment:-
Segmentversion:4
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2TAN-Prozess1DEcode1M11, 2, 3, 4
3Auftrags-Hashwert1DEbin.256C1M: bei Auftrags- Hashwertverfahren<>0 und TAN-Prozess=1 N: sonst
4Auftragsreferenz1DEan..35C1M: bei TAN-Prozess=2, 3 O: TAN-Prozess=1, 4
5TAN-Listennummer1DEan..20C1M: bei TAN-Prozess=1, 3, 4 und „Anzahl unterstützter aktiver TAN-Listen" > 1 und „TAN-Listennummer erfor- derlich"=2 O: sonst
6Weitere TAN folgt1DEjn1C1M: bei TAN-Prozess=1, 2 N: bei TAN-Prozess=3, 4
7Auftrag stornieren1DEjn1C1O: bei TAN-Prozess=2 und ,,Auftragsstorno erlaubt“=J N: sonst
8SMS- Abbuchungskonto1DEGkti#C1M: bei TAN-Prozess=1, 3, 4 und „SMS-
Abbuchungskonto erforder- lich“=“J“ N: sonst
9Challenge-Klasse1DEnum..2C1M: bei TAN-Prozess=1 und ,Challenge-Klasse erforder- lich“=J N: sonst
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: D
Dokument:Security - Sicherheitsverfahren PIN/TAN
Kapitel:
Abschnitt:		Archiv: Ältere Segmentversionen HKTAN für Zwei-Schritt-TAN-EinreichungStand: 23.02.2018Seite: 165
+ + + + + + + + + + + + + + + + + + + + + + + + + +
10Parameter Challen- ge-Klasse1DEGC1O: bei TAN-Prozess=1 und ,,Challenge-Klasse erforder- lich“=J N: sonst
11Bezeichnung des TAN-Mediums1DEan..32C1M: bei TAN-Prozess=1, 3, 4 und „Anzahl unterstützter aktiver TAN-Medien“ > 1 und ,,Bezeichnung des TAN-Mediums erforder- lich“=2 O: sonst
+ + +#### ◆ Belegungsrichtlinien + + +##### Auftragsreferenz + +Als Auftragsreferenz ist derjenige Wert einzustellen, der bei der Auftragsein- +reichung im Rahmen der Kreditinstitutsrückmeldung mitgeteilt wurde. + + +##### Parameter Challenge-Klasse + +Die Parameter zur Challenge-Klasse dienen zur Übermittlung von Daten, die +bei Prozessvariante 1 im ersten Verfahrensschritt für die weitere Steuerung +benötigt werden. Ist das Datenelement ,,Challenge-Klasse“ belegt, so muss +im ersten Parameter P1 die Segmentkennung des jeweiligen Geschäftsvor- +falls eingestellt werden. Die weiteren Parameter müssen die zur jeweiligen +Challenge-Klasse passenden Informationen, z. B. Empfänger-IBAN oder ei- +ne Wertpapierkennnummer enthalten. + +Ist das Datenelement ,,Challenge-Betrag erforderlich“ in den BPD mit „J“ be- +legt, muss bei Vorhandensein einer Betragsinformation im Auftrag dieser +Challenge-Betragswert direkt anschließend an die regulären Challenge- +Klasse-Parameter als zusätzliche(r) Challenge-Klasse Parameter übermittelt +werden. Je nach konkretem Zwei-Schritt-Verfahren muss ggf. auch eine zu- +gehörige Challenge-Betragswährung als weiterer Parameter eingestellt wer- +den. + +Hierbei gilt folgende Belegungsvorschrift: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Challenge- BetragswertDEan.999M1
2Challenge- BetragswährungDEan..999M1
+ + +Das alfanumerische DE "Challenge-Betragswert" muss analog der Belegung +des abgeleiteten Formats ,,wrt“ (vgl. [Formals], Kapitel B.4.2) befüllt werden. + +Das alfanumerische DE "Challenge-Betragswährung" muss analog der Bele- +gung des abgeleiteten Formats ,,cur" (vgl. [Formals], Kapitel B.4.2) befüllt +werden. Falls in den Auftragsdaten keine oder keine eindeutige Währung +existiert, ist es mit "000" zu befüllen. + +Weitere Belegungsrichtlinien für Challenge-Betragswert und Challenge- +Betragswährung hängen vom verwendeten konkreten Zwei-Schritt-Verfahren +ab und sind der dortigen Spezifikation zu entnehmen. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
166		Stand: 23.02.2018Kapitel: Archiv: Ältere Segmentversionen
Abschnitt: HKTAN für Zwei-Schritt-TAN-Einreichung
+ + +##### TAN-Listennummer + +Ist in der BPD als ,,Anzahl unterstützter aktiver TAN-Listen“ ein Wert > 1 an- +gegeben und ist der BPD-Wert für „TAN-Listennummer erforderlich“ = 2, so +muss der Kunde z. B. im Falle eines indizierten TAN-Verfahrens hier seine +für diesen Auftrag zu verwendende TAN-Liste angeben. + + +##### Bezeichnung des TAN-Mediums + +Ist in der BPD als ,,Anzahl unterstützter aktiver TAN-Medien“ ein Wert > 1 +angegeben und ist der BPD-Wert für „Bezeichnung des TAN-Mediums erfor- +derlich" = 2, so muss der Kunde z. B. im Falle des mobileTAN-Verfahrens +hier die Bezeichnung seines für diesen Auftrag zu verwendenden TAN- +Mediums angeben. + + +##### SMS-Abbuchungskonto + +Ist in der BPD als ,,SMS-Abbuchungskonto erforderlich" mit ,,J" belegt, so +muss der Kunde z. B. im Falle des mobileTAN-Verfahrens hier das für die- +sen Auftrag zu belastende SMS-Abbuchungskonto einstellen. Dieses kann +unabhängig von der Kontoverbindung des Dialogführers gewählt werden. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: D
Dokument:Security - Sicherheitsverfahren PIN/TAN
Kapitel:
Abschnitt:		Archiv: Ältere Segmentversionen
HKTAN für Zwei-Schritt-TAN-Einreichung		Stand: 23.02.2018Seite: 167
+ + +###### b) Kreditinstitutsrückmeldung + +Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Zwei-Schritt-TAN-Einreichung Rückmeldung
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HITAN
Bezugssegment:HKTAN
Segmentversion:4
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2TAN-Prozess1DEcode1M11, 2, 3, 4
3Auftrags-Hashwert1DEbin.256C1M: bei Auftrags- Hashwertverfahren<>0 und TAN-Prozess=1, N: sonst
4Auftragsreferenz1DEan..35C1M: bei TAN-Prozess=2, 3, 4 O: bei TAN-Prozess=1
5Challenge3DEan.204 8C1M: bei TAN-Prozess=1, 3, 4 O: bei TAN-Prozess=2
6Challenge HHD UC1DEbin..O1
7Gültigkeitsdatum und -uhrzeit für Challenge1DEGO1
8TAN-Listennummer1DEan.20C1M: bei TAN-Prozess=1, 3, 4 und „Anzahl unterstützter aktiver TAN-Listen" nicht vorhanden O: sonst
9BEN1DEan..99C1O: bei TAN-Prozess=2 N: sonst
10Bezeichnung des TAN-Mediums1DEan..32C1M: bei TAN-Prozess=1, 3, 4 und „Anzahl unterstützter aktiver TAN-Medien" nicht vorhanden O: sonst
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
168		Stand: 23.02.2018Kapitel: Archiv: Ältere Segmentversionen
Abschnitt: HKTAN für Zwei-Schritt-TAN-Einreichung
+ + +#### ◆ Belegungsrichtlinien + + +##### Auftrags-Hashwert + +Es ist der in der Kundennachricht in HKTAN übermittelte Auftrags-Hashwert +unverändert einzustellen. + + +##### Auftragsreferenz + +Bei TAN-Prozess=2, 3 und 4 muss die Auftragsreferenz vom Institut immer +eingestellt werden. Bei TAN-Prozess=1 muss die Auftragsreferenz einge- +stellt werden, wenn sie zuvor im Segment HKTAN vom Kunden gesendet +wurde. + + +##### Challenge + +Obwohl die Challenge bei Prozessvariante 2 im zweiten Schritt nicht zwin- +gend benötigt wird, sollte sie aus Integritätsgründen trotzdem übertragen +werden. + + +![](figures/168.1) + + +Das Kundenprodukt muss den Inhalt der empfangenen Challenge +dem Kunden unverändert anzeigen. Ist der BPD-Parameter ,,Chal- +lenge strukturiert“ mit „J“ belegt, so können im DE Challenge For- +matsteuerzeichen enthalten sein, die dann entsprechend zu inter- +pretieren sind (Näheres hierzu im Data Dictionary unter dem DE +,Challenge“). + +Erläuterung: Die Challenge kann institutsindividuell aufgebaut wer- +den (z. B. 1 oder 2 Eingabefelder für den chipTAN-Leser). + + +##### Challenge HHD_UC + +Das Datenelement enthält eine Datenstruktur, die entsprechend den Vorga- +ben aus [HHD-Erweiterung] aufgebaut sein muss. Die einzelnen Elemente +dieser Datenstruktur sind für FinTS transparent und werden nicht durch +Trennzeichen getrennt. + + +##### TAN-Listennummer + +Ist in der BPD der Parameter ,,Anzahl unterstützter aktiver TAN-Listen“ nicht +vorhanden, so muss das Institut dem Kunden hier mitteilen, welche TAN- +Liste er z. B. bei Einsatz eines indizierten TAN-Verfahrens verwenden soll. + + +##### Bezeichnung des TAN-Mediums + +Ist in der BPD der Parameter „Anzahl unterstützter aktiver TAN-Medien“ +nicht vorhanden, so muss das Institut dem Kunden hier mitteilen, welches +TAN-Medium er z. B. beim mobileTAN-Verfahren verwenden soll. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: D
Dokument:Security - Sicherheitsverfahren PIN/TAN
Kapitel:
Abschnitt:		Archiv: Ältere Segmentversionen HKTAN für Zwei-Schritt-TAN-EinreichungStand: 23.02.2018Seite: 169
+ + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
9210Auftrag abgelehnt - Auftragsdaten inkonsistent. Eingereichter Auftrag gelöscht
9210Auftrag abgelehnt – Zwei-Schritt-TAN inkonsistent. Eingereichter Auftrag gelöscht
9210Auftrag abgelehnt – Kein eingereichter Auftrag gefunden
9210Auftrag abgelehnt – Auftragsreferenz ist unbekannt
9330chipTAN-Leser gesperrt. Führen Sie ggf. eine chipTAN-Synchronisation durch
9360Sperrung der TAN-Liste nach weiteren x Fehlversuchen
9380Gewähltes Zwei-Schritt-TAN-Verfahren nicht zulässig
9931Sperrung des Kontos nach x Fehlversuchen
9941TAN ungültig
9951Zeitüberschreitung im Zwei-Schritt-Verfahren – TAN ungültig
9953Nur ein TAN-pflichtiger Auftrag pro Nachricht erlaubt
9954Mehrfach-TANs nicht erlaubt
9955Ein-Schritt-TAN-Verfahren nicht zugelassen
9956Zeitversetzte Eingabe von Mehrfach-TANs nicht erlaubt
9991TAN bereits verbraucht
+ + +# c) Bankparameterdaten + + +## Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Zwei-Schritt-TAN-Einreichung, Parameter
Typ:Segment
Segmentart:Geschäftsvorfallparameter
Kennung:HITANS
Bezugssegment:HKVVB
Segmentversion:4
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Zwei- Schritt-TAN- Einreichung4DEGM1
+ + +## ◆ Belegungsrichtlinien + +Auftrags-Hashwertverfahren (Parameter Zwei-Schritt-TAN-Einreichung) +Bei Verwendung von TAN-Prozess=1. + + +## E.1.5 Geschäftsvorfall HKTAN in Segmentversion #5 + +Ab der Segmentversion #5 dieses Geschäftsvorfalls ist das chipTAN-Verfahren mit +unidirektionaler Kopplung bis zur Version 1.4 unterstützt. Mit dieser Version können + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
170		Stand: 23.02.2018Kapitel: Archiv: Ältere Segmentversionen
Abschnitt: HKTAN für Zwei-Schritt-TAN-Einreichung
+ + +aber auch alle anderen PIN/TAN Zwei-Schritt-Verfahren unterstützt werden; wahl- +weise können Kreditinstitute zusätzlich auch andere Segmentversionen von HKTAN +anbieten. + + +![](figures/170.1) + + +In der BPD können sich mehrere Segmentversionen von HITANS- +Segmenten befinden, wobei den einzelnen HITANS-Segmenten +über das Element „Sicherheitsfunktion, kodiert“ unterschiedliche +Verfahren zugeordnet sein können. Ein Kundenprodukt sollte – be- +ginnend mit der höchsten Segmentversion - alle in der BPD enthal- +tenen HITANS-Segmente analysieren, um so dem Kunden alle vom +Kreditinstitut unterstützten Sicherheitsverfahren anbieten zu kön- +nen. + +Beispiel: Die BPD enthält Definitionen für HITANS#5 und +HITANS#4. In HITANS#5 ist das Verfahren chipTAN nach HHD +V1.4 parametrisiert. HITANS#4 enthält die Beschreibung für mobi- +leTAN. + +Realisierung Bank: verpflichtend in mindestens einer Segmentversion, falls +Geschäftsvorfälle mit PIN/TAN-Absicherung im Zwei-Schritt- +Verfahren angeboten werden. + +Realisierung Kunde: optional + + +# a) Kundenauftrag + + +# Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Zwei-Schritt-TAN-Einreichung
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKTAN
Bezugssegment:-
Segmentversion:5
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2TAN-Prozess1DEcode1M11, 2, 3, 4
3Segmentkennung1DEan..6C1M: bei TAN-Prozess=1 N: sonst
4Kontoverbindung international Auf- traggeber1DEGkti#C1M: bei TAN-Prozess=1 und „Auftraggeberkonto erfor- derlich"=2 und Kontover- bindung im Auftrag enthal- ten N: sonst
5Auftrags-Hashwert1DEbin.256C1M: bei Auftrags- Hashwertverfahren<>0 und TAN-Prozess=1 N: sonst
6Auftragsreferenz1DEan..35C1M: bei TAN-Prozess=2, 3 O: TAN-Prozess=1, 4
+ + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: D
Dokument:Security - Sicherheitsverfahren PIN/TAN
Kapitel:
Abschnitt:		Archiv: Ältere Segmentversionen HKTAN für Zwei-Schritt-TAN-EinreichungStand: 23.02.2018Seite: 171
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
7TAN-Listennummer1DEan.20C1M: bei TAN-Prozess=1, 3, 4 und „Anzahl unterstützter aktiver TAN-Listen“ > 1 und ,TAN-Listennummer erfor- derlich"=2 O: sonst
8Weitere TAN folgt1DEjn1C1M: bei TAN-Prozess=1, 2 N: bei TAN-Prozess=3, 4
9Auftrag stornieren1DEjn1C1O: bei TAN-Prozess=2 und „Auftragsstorno erlaubt“=J N: sonst
10SMS- Abbuchungskonto1DEGkti#C1M: b
ei TAN-Prozess=1, 3, 4 und "SMS-Abbuchungskonto er- forderlich“=2
O: sonst
11Challenge-Klasse1DEnum..2C1M: bei TAN-Prozess=1 und ,,Challenge-Klasse erforder- lich“=J N: sonst
12Parameter Challen- ge-Klasse1DEGC1O: bei TAN-Prozess=1 und ,,Challenge-Klasse erforder- lich“=J N: sonst
13Bezeichnung des TAN-Mediums1DEan..32C1M: bei TAN-Prozess=1, 3, 4 und „Anzahl unterstützter aktiver TAN-Medien“ > 1 und ,,Bezeichnung des TAN-Mediums erforder- lich“=2 O: sonst
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
172		Stand: 23.02.2018Kapitel: Archiv: Ältere Segmentversionen
Abschnitt: HKTAN für Zwei-Schritt-TAN-Einreichung
+ + +# ◆ Belegungsrichtlinien + + +## Auftragsreferenz + +Als Auftragsreferenz ist derjenige Wert einzustellen, der bei der Auftragsein- +reichung im Rahmen der Kreditinstitutsrückmeldung mitgeteilt wurde. + + +## Parameter Challenge-Klasse + +Die Parameter zur Challenge-Klasse dienen zur Übermittlung von Daten, die +bei Prozessvariante 1 im ersten Verfahrensschritt für die weitere Steuerung +benötigt werden. Die konkrete Belegung der Parameter sind den Belegungs- +richtlinien des jeweiligen Verfahrens zu entnehmen. Für die DK-Verfahren +chipTAN und mobileTAN gelten die Festlegungen in [HHD Belegung]. + + +## TAN-Listennummer + +Ist in der BPD als „Anzahl unterstützter aktiver TAN-Listen“ ein Wert > 1 an- +gegeben und ist der BPD-Wert für „TAN-Listennummer erforderlich“ = 2, so +muss der Kunde z. B. im Falle eines indizierten TAN-Verfahrens hier seine +für diesen Auftrag zu verwendende TAN-Liste angeben. + + +## Bezeichnung des TAN-Mediums + +Ist in der BPD als ,,Anzahl unterstützter aktiver TAN-Medien“ ein Wert > 1 +angegeben und ist der BPD-Wert für „Bezeichnung des TAN-Mediums erfor- +derlich" = 2, so muss der Kunde z. B. im Falle des mobileTAN-Verfahrens +hier die Bezeichnung seines für diesen Auftrag zu verwendenden TAN- +Mediums angeben. + + +## SMS-Abbuchungskonto + +Ist in der BPD als ,,SMS-Abbuchungskonto erforderlich" mit ,,2" belegt, so +muss der Kunde z. B. im Falle des mobileTAN-Verfahrens hier das für die- +sen Auftrag zu belastende SMS-Abbuchungskonto einstellen. Dieses kann +unabhängig von der Kontoverbindung des Dialogführers gewählt werden. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: D
Dokument:Security - Sicherheitsverfahren PIN/TAN
Kapitel:
Abschnitt:		Archiv: Ältere Segmentversionen
HKTAN für Zwei-Schritt-TAN-Einreichung		Stand: 23.02.2018Seite: 173
+ + +### b) Kreditinstitutsrückmeldung + +Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Zwei-Schritt-TAN-Einreichung Rückmeldung
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HITAN
Bezugssegment:HKTAN
Segmentversion:5
Anzahl:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2TAN-Prozess1DEcode1M11, 2, 3, 4
3Auftrags-Hashwert1DEbin.256C1M: bei Auftrags- Hashwertverfahren<>0 und TAN-Prozess=1, N: sonst
4Auftragsreferenz1DEan..35C1M: bei TAN-Prozess=2, 3, 4 O: bei TAN-Prozess=1
5Challenge3DEan.204 8C1M: bei TAN-Prozess=1, 3, 4 O: bei TAN-Prozess=2
6Challenge HHD UC1DEbin..O1
7Gültigkeitsdatum und -uhrzeit für Challenge1DEGO1
8TAN-Listennummer1DEan.20C1M: bei TAN-Prozess=1, 3, 4 und „Anzahl unterstützter aktiver TAN-Listen" nicht vorhanden O: sonst
9BEN1DEan..99C1O: bei TAN-Prozess=2 N: sonst
10Bezeichnung des TAN-Mediums1DEan..32C1M: bei TAN-Prozess=1, 3, 4 und „Anzahl unterstützter aktiver TAN-Medien" nicht vorhanden O: sonst
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite: 174Stand: 23.02.2018Kapitel: Archiv: Ältere Segmentversionen
Abschnitt: HKTAN für Zwei-Schritt-TAN-Einreichung
+ + +# ◆ Belegungsrichtlinien + + +## Auftrags-Hashwert + +Es ist der in der Kundennachricht in HKTAN übermittelte Auftrags-Hashwert +unverändert einzustellen. + + +## Auftragsreferenz + +Bei TAN-Prozess=2, 3 und 4 muss die Auftragsreferenz vom Institut immer +eingestellt werden. Bei TAN-Prozess=1 muss die Auftragsreferenz einge- +stellt werden, wenn sie zuvor im Segment HKTAN vom Kunden gesendet +wurde. + + +## Challenge + +Obwohl die Challenge bei Prozessvariante 2 im zweiten Schritt nicht zwin- +gend benötigt wird, sollte sie aus Integritätsgründen trotzdem übertragen +werden. + + +![](figures/174.1) + + +Das Kundenprodukt muss den Inhalt der empfangenen Challenge +dem Kunden unverändert anzeigen. Ist der BPD-Parameter „Chal- +lenge strukturiert“ mit „J“ belegt, so können im DE Challenge For- +matsteuerzeichen enthalten sein, die dann entsprechend zu inter- +pretieren sind (Näheres hierzu im Data Dictionary unter dem DE +,Challenge“). + +Erläuterung: Die Challenge kann institutsindividuell aufgebaut wer- +den (z. B. 1 oder 2 Eingabefelder für den chipTAN-Leser). + + +## Challenge HHD_UC + +Das Datenelement enthält eine Datenstruktur, die entsprechend den Vorga- +ben aus [HHD-Erweiterung] aufgebaut sein muss. Die einzelnen Elemente +dieser Datenstruktur sind für FinTS transparent und werden nicht durch +Trennzeichen getrennt. + + +## TAN-Listennummer + +Ist in der BPD der Parameter ,,Anzahl unterstützter aktiver TAN-Listen“ nicht +vorhanden, so muss das Institut dem Kunden hier mitteilen, welche TAN- +Liste er z. B. bei Einsatz eines indizierten TAN-Verfahrens verwenden soll. + + +## Bezeichnung des TAN-Mediums + +Ist in der BPD der Parameter „Anzahl unterstützter aktiver TAN-Medien“ +nicht vorhanden, so muss das Institut dem Kunden hier mitteilen, welches +TAN-Medium er z. B. beim mobileTAN-Verfahren verwenden soll. + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version: 3.0-FVKapitel: D
Dokument:Security - Sicherheitsverfahren PIN/TAN
Kapitel:
Abschnitt:		Archiv: Ältere Segmentversionen HKTAN für Zwei-Schritt-TAN-EinreichungStand: 23.02.2018Seite: 175
+ + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0010Auftrag entgegengenommen
9210Auftrag abgelehnt – Auftragsdaten inkonsistent. Eingereichter Auftrag gelöscht
9210Auftrag abgelehnt - Zwei-Schritt-TAN inkonsistent. Eingereichter Auftrag gelöscht
9210Auftrag abgelehnt – Kein eingereichter Auftrag gefunden
9210Auftrag abgelehnt – Auftragsreferenz ist unbekannt
9330chipTAN-Leser gesperrt. Führen Sie ggf. eine chipTAN-Synchronisation durch
9360Sperrung der TAN-Liste nach weiteren x Fehlversuchen
9380Gewähltes Zwei-Schritt-TAN-Verfahren nicht zulässig
9931Sperrung des Kontos nach x Fehlversuchen
9941TAN ungültig
9951Zeitüberschreitung im Zwei-Schritt-Verfahren – TAN ungültig
9953Nur ein TAN-pflichtiger Auftrag pro Nachricht erlaubt
9954Mehrfach-TANs nicht erlaubt
9955Ein-Schritt-TAN-Verfahren nicht zugelassen
9956Zeitversetzte Eingabe von Mehrfach-TANs nicht erlaubt
9991TAN bereits verbraucht
+ + +### c) Bankparameterdaten + + +#### Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Zwei-Schritt-TAN-Einreichung, Parameter
Typ:Segment
Segmentart:Geschäftsvorfallparameter
Kennung:HITANS
Bezugssegment:HKVVB
Segmentversion:5
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Zwei- Schritt-TAN- Einreichung5DEGM1
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
176		Stand: 23.02.2018Kapitel: Archiv: Ältere Segmentversionen
Abschnitt: Management chipTAN, mobileTAN und bilaterale Verfahren
+ + +#### ◆ Belegungsrichtlinien + +Auftrags-Hashwertverfahren (Parameter Zwei-Schritt-TAN-Einreichung) +Bei Verwendung von TAN-Prozess=1. + + +## E.2 Management chipTAN, mobileTAN und bilaterale Verfahren + + +### E.2.1 Anzeige der verfügbaren TAN-Medien + + +### E.2.1.1Anzeigen der verfügbaren TAN-Medien, Segmentversion #1 + +Realisierung Bank: +optional + +Realisierung Kunde: optional + + +#### a) Kundenauftrag + + +#### Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:TAN-Generator/Liste anzeigen Bestand
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKTAB
Bezugssegment:-
Segmentversion:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2TAN-Medium-Art1DEcode1M10, 2, 3
+ + +b) +Kreditinstitutsrückmeldung + + +##### ◆ Erläuterungen + +Es wird ein Datensegment zurückgemeldet. + + +##### ◆ Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:TAN-Generator/Liste anzeigen Bestand Rückmeldung
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HITAB
Bezugssegment:HKTAB
Segmentversion:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FVD
Kapitel:Archiv: Ältere SegmentversionenStand:Seite:
Abschnitt:Management chipTAN, mobileTAN und bilaterale Verfahren23.02.2018177
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2TAN-Einsatzoption1DEcode1M10, 1, 2
3TAN-Medium-Liste1DEGO.99
+ + +#### ◆ Belegungsrichtlinien + + +##### TAN-Medium-Liste + +Darf nur belegt werden, wenn für den Kunden ein TAN-Medium verfügbar / +nutzbar ist. + + +#### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag verarbeitet
+ + +c) +Bankparameterdaten + + +##### Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + +###### ◆ Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:TAN-Generator/Liste anzeigen Bestand Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HITABS
Bezugssegment:HKVVB
Segmentversion:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + +### E.2.1.2Anzeigen der verfügbaren TAN-Medien, Segmentversion #2 + +Zusätzlich zur Segmentversion 1 des Geschäftsvorfalls wird nun auch das mobi- +leTAN-Verfahren unterstützt. + +Dem Kunden wird eine Übersicht über seine verfügbaren TAN-Medien (TAN- +Generator, Mobiltelefon und TAN-Liste) angezeigt. + +Der Kunde muss auch im Hinblick auf das TAN-Zwei-Schritt-Verfahren wissen, wel- +ches Medium er verwenden darf. Hierzu werden ihm seine verfügbaren Medien +(Karten, Telefonbezeichnungen bzw. TAN-Listennummern) mit ihrem aktuellen Sta- +tus angezeigt. Es wird dahingehend unterschieden, ob das Medium „Verfügbar“ o- +der ,Aktiv" ist. Folgekarten werden bei TAN-Generatoren separat mit eigenen Kenn- + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
178		Stand: 23.02.2018Kapitel: Archiv: Ältere Segmentversionen
Abschnitt: Management chipTAN, mobileTAN und bilaterale Verfahren
+ + +zeichen versehen, da mit der ,Aktivierung“ der Folgekarte die aktuelle Karte für die +TAN-Generierung gesperrt wird. + + + + + + + + + + + + + + + + + + + + + + + +
StatusErläuterungen
VerfügbarDas Medium kann genutzt werden, muss aber zuvor fol- gendermaßen aktiv gemeldet werden:
◆ TAN-Generator: mit ,TAN-Generator an- bzw. ummel- den (HKTAU)"
◆ Mobiltelefon mit „Mobilfunkverbindung freischalten“
AktivDas Institut zeigt an, dass es eine TAN-Verifikation gegen dieses Medium vornimmt.
Verfügbare FolgekarteDas Medium kann mit dem Geschäftsvorfall „TAN- Generator an- bzw. ummelden (HKTAU)“ aktiv gemeldet werden. Die aktuelle Karte kann dann nicht mehr genutzt werden.
Aktiv FolgekarteMit der ersten Nutzung der Folgekarte wird die zur Zeit ak- tive Karte gesperrt.
+ + +Anmerkung: Wenn ein Institut mehrere Medien in dem Status „Aktiv“ verwalten +kann, dann muss beim Zwei-Schritt-Verfahren dem Institut zuvor mit dem Ge- +schäftsvorfall „TAN-Generator an- bzw. ummelden“ (HKTAU) mitgeteilt werden, wel- +ches Medium für die Signatur des Geschäftsvorfalles verwendet werden soll. + +Realisierung Bank: +optional + +Realisierung Kunde: optional + + +## a) Kundenauftrag + + +# Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:TAN-Generator/Liste anzeigen Bestand
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKTAB
Bezugssegment:-
Segmentversion:2
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2TAN-Medium-Art1DEcode1M10, 2, 3
+ + +## b) Kreditinstitutsrückmeldung + + +## Erläuterungen + +Es wird ein Datensegment zurückgemeldet. + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: D
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FV
Kapitel:Archiv: Ältere SegmentversionenStand:Seite:
Abschnitt:Management chipTAN, mobileTAN und bilaterale Verfahren23.02.2018179
+ + +## ◆ Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:TAN-Generator/Liste anzeigen Bestand Rückmeldung
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HITAB
Bezugssegment:HKTAB
Segmentversion:2
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2TAN-Einsatzoption1DEcode1M10, 1, 2
3TAN-Medium-Liste2DEGO..99
+ + +## ◆ Belegungsrichtlinien + + +### TAN-Medium-Liste + +Darf nur belegt werden, wenn für den Kunden ein TAN-Medium verfügbar / +nutzbar ist. + + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag verarbeitet
+ + +### c) Bankparameterdaten + + +### Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + +#### ◆ Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:TAN-Generator/Liste anzeigen Bestand Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HITABS
Bezugssegment:HKVVB
Segmentversion:2
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + +## E.2.1.3Anzeigen der verfügbaren TAN-Medien, Segmentversion #3 + +Bei Segmentversion 3 wurden gegenüber der Vorgängerversion die Elemente „TAN- +Medium-Art“ und „TAN-Medium-Liste“ für das mobileTAN-Verfahren angepasst. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite: 180Stand: 23.02.2018Kapitel: Archiv: Ältere Segmentversionen
Abschnitt: Management chipTAN, mobileTAN und bilaterale Verfahren
+ + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +# a) Kundenauftrag + + +## Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:TAN-Generator/Liste anzeigen Bestand
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKTAB
Bezugssegment:-
Segmentversion:3
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2TAN-Medium-Art2DEcode1M10, 1, 2
+ + +## b) Kreditinstitutsrückmeldung + + +## Erläuterungen + +Es wird ein Datensegment zurückgemeldet. + + +### ◆ Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:TAN-Generator/Liste anzeigen Bestand Rückmeldung
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HITAB
Bezugssegment:HKTAB
Segmentversion:3
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2TAN-Einsatzoption1DEcode1M10, 1, 2
3TAN-Medium-Liste3DEGO.99
+ + +### ◆ Belegungsrichtlinien + +TAN-Medium-Liste + +Darf nur belegt werden, wenn für den Kunden ein TAN-Medium verfügbar / +nutzbar ist. + + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag verarbeitet
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: D
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FV
Kapitel:Archiv: Ältere SegmentversionenStand:Seite:
Abschnitt:Management chipTAN, mobileTAN und bilaterale Verfahren23.02.2018181
+ + +c) +Bankparameterdaten + + +## Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + +### ◆ Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:TAN-Generator/Liste anzeigen Bestand Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HITABS
Bezugssegment:HKVVB
Segmentversion:3
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + +#### E.2.1.4Anzeigen der verfügbaren TAN-Medien, Segmentversion #4 + +Bei Segmentversion #4 wird gegenüber der Vorgängerversion in der Kundennach- +richt durch das Datenelement ,,TAN-Medium-Klasse #3" die Selektion nach Sicher- +heitsverfahren wie z. B. chipTAN bzw. mobileTAN ermöglicht. + +Realisierung Bank: optional + +Realisierung Kunde: optional + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite: 182Stand: 23.02.2018Kapitel: Archiv: Ältere Segmentversionen
Abschnitt: Management chipTAN, mobileTAN und bilaterale Verfahren
+ + +# a) Kundenauftrag + + +## Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:TAN-Generator/Liste anzeigen Bestand
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKTAB
Bezugssegment:-
Segmentversion:4
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2TAN-Medium-Art2DEcode1M10, 1, 2
3TAN-Medium- Klasse3DEcode1M1A, L, G, M, S
+ + +## b) Kreditinstitutsrückmeldung + + +# Erläuterungen + +Es wird ein Datensegment zurückgemeldet. + + +## ◆ Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:TAN-Generator/Liste anzeigen Bestand Rückmeldung
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HITAB
Bezugssegment:HKTAB
Segmentversion:4
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2TAN-Einsatzoption1DEcode1M10, 1, 2
3TAN-Medium-Liste4DEGO.99
+ + +## ◆ Belegungsrichtlinien + + +## TAN-Medium-Liste + +Darf nur belegt werden, wenn für den Kunden ein TAN-Medium verfügbar / +nutzbar ist. + +Beim mobileTAN-Verfahren (TAN-Medium-Klasse="M") muss entweder das +Datenelement ,,Mobiltelefonnummer“ oder „Mobiltelefonnummer verschleiert“ +angegeben werden. + + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag verarbeitet
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: D
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FV
Kapitel:Archiv: Ältere SegmentversionenStand:Seite:
Abschnitt:Management chipTAN, mobileTAN und bilaterale Verfahren23.02.2018183
+ + +c) +Bankparameterdaten + + +# Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + +## ◆ Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:TAN-Generator/Liste anzeigen Bestand Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HITABS
Bezugssegment:HKVVB
Segmentversion:4
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
184		Stand: 23.02.2018Kapitel: Archiv: Ältere Segmentversionen
Abschnitt: Management chipTAN, mobileTAN und bilaterale Verfahren
+ + +### E.2.2 TAN-Generator / TAN-Liste an- bzw. ummelden + + +#### E.2.2.1 TAN-Generator / TAN-Liste an- bzw. ummelden in Segmentversion #1 + +Mit Hilfe dieses Geschäftsvorfalls kann der Kunde seinem Institut mitteilen, welches +Medium (Chipkarte, TAN-Generator bzw. TAN-Liste) er für die Autorisierung der +Aufträge per TAN verwenden wird. + +Welches Medium gerade aktiv ist, kann mit Hilfe des Geschäftsvorfalls „TAN- +Generator / -Liste anzeigen Bestand (HKTAB)" durch den Kunden erfragt werden. + +Der Kunde entscheidet selbst, ob er den TAN-Generator oder die aktuelle TAN-Liste +verwenden möchte. Steht ein Kartenwechsel an, so kann der Kunde mit diesem Ge- +schäftsvorfall seine Karte bzw. Folgekarte aktivieren. Kann der Kunde mehrere Kar- +ten verwenden, dann kann mit diesem GV die Ummeldung auf eine andere Karte er- +folgen. Das Kreditinstitut entscheidet selbst, ob dieser GV TAN-pflichtig ist oder +nicht. + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +##### a) Kundenauftrag + + +##### Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:TAN-Generator an- bzw. ummelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKTAU
Bezugssegment:-
Segmentversion:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2TAN-Generator/- Liste1DEan1M1G, L
3Kartennummer1DEid#C1M: DE ,,TAN-Generator/- Liste“=“G“ N: sonst
4Kartenfolgenummer1DEid#C1M: DE ,,TAN-Generator/- Liste"="G" und DE ,,Eingabe Kartenfolgenummer J/N" (BPD)="J" N: sonst
5TAN-Listennummer1DEan.20C1M: DE ,,TAN-Generator/- Liste"="L" und DE ,,Eingabe TAN-Listennummer J/N" (BPD)="J" O: DE ,,TAN-Generator/- Liste"="L" und DE ,,Eingabe TAN-Listennummer J/N" (BPD)=“N“ N: sonst
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: D
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FV
Kapitel:Archiv: Ältere SegmentversionenStand:Seite: 185
Abschnitt:Management chipTAN, mobileTAN und bilaterale Verfahren23.02.2018
+ + + + + + + + + + + + + + + + + + + + + + + + + +
6ATC1DEnum..5C1M: DE ,,TAN-Generator/- Liste"="G" und DE ,,Eingabe von ATC und TAN erforder- lich" (BPD)="J" N: sonst
7TAN1DEan.99C1M: DE ,,TAN-Generator/- Liste"="G" und DE ,,Eingabe von ATC und TAN erforder- lich" (BPD)="J" N: sonst
+ + +## ◆ Belegungsrichtlinien + + +### TAN-Listennummer + +Wird keine TAN-Listennummer angegeben, so wird die aktuelle / freigeschal- +tete Liste verwendet. + + +### b) Kreditinstitutsrückmeldung + +Format + +Allgemeine Kreditinstitutsnachricht ohne Datensegmente + + +### ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020An- bzw. Ummeldung erfolgreich
9935An- bzw. Ummeldung fehlgeschlagen
9935Kartennummer unbekannt
9935TAN-Listennummer unbekannt
9935Karte als TAN-Generator nicht zugelassen – bitte wenden Sie sich an Ihr Institut
9935Keine TAN-Liste freigeschaltet
+ + +c) +Bankparameterdaten + +Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:TAN-Generator an- bzw. ummelden Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HITAUS
Bezugssegment:HKVVB
Segmentversion:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
186		Stand: 23.02.2018Kapitel: Archiv: Ältere Segmentversionen
Abschnitt: Management chipTAN, mobileTAN und bilaterale Verfahren
+ + +#### E.2.2.2TAN-Generator / TAN-Liste an- bzw. ummelden in Segmentversion #2 + +Mit Hilfe dieses Geschäftsvorfalls kann der Kunde seinem Institut mitteilen, welches +Medium (Chipkarte, TAN-Generator bzw. TAN-Liste) er für die Autorisierung der +Aufträge per TAN verwenden wird. + +Welches Medium gerade aktiv ist, kann mit Hilfe des Geschäftsvorfalls „TAN- +Generator / -Liste anzeigen Bestand (HKTAB)“ bzw. für Detailinformationen zur Kar- +te auch ,,Kartenanzeige anfordern (HKAZK)“ durch den Kunden erfragt werden. + +Der Kunde entscheidet selbst, ob er den TAN-Generator oder die aktuelle TAN-Liste +verwenden möchte. Steht ein Kartenwechsel an, so kann der Kunde mit diesem Ge- +schäftsvorfall seine Karte bzw. Folgekarte aktivieren. Kann der Kunde mehrere Kar- +ten verwenden, dann kann mit diesem GV die Ummeldung auf eine andere Karte er- +folgen. Das Kreditinstitut entscheidet selbst, ob dieser GV TAN-pflichtig ist oder +nicht. + +Realisierung Bank: optional + +Realisierung Kunde: optional + + +##### a) Kundenauftrag + + +##### Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:TAN-Generator an- bzw. ummelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKTAU
Bezugssegment:-
Segmentversion:2
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2TAN-Generator/- Liste1DEan1M1G, L
3Kartennummer1DEid#C1M: DE ,,TAN-Generator/- Liste“=“G“ N: sonst
4Kartenfolgenummer1DEid#C1M: DE ,,TAN-Generator/- Liste"="G" und DE ,,Eingabe Kartenfolgenummer J/N" (BPD)="J" N: sonst
5Kartenart1DEnum..2C1O: DE ,,TAN-Generator/- Liste"="G" und DE ,,Eingabe Kartenart zulässig“ (BPD) = „J“
N: sonst
6Kontoverbindung Auftraggeber3DEktv#C1O: DE ,,TAN-Generator/- Liste“=“G“ N: sonst
7gültig ab1DEdat#C1O: DE ,,TAN-Generator/- Liste“=“G“ N: sonst
8gültig bis1DEdat#C1O: DE ,,TAN-Generator/-
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: D
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FV
Kapitel:Archiv: Ältere SegmentversionenStand:Seite:
Abschnitt:Management chipTAN, mobileTAN und bilaterale Verfahren23.02.2018187
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Liste"="G" N: sonst
9TAN-Listennummer1DEan..20C1M: DE ,,TAN-Generator/- Liste"="L" und DE ,,Eingabe TAN-Listennummer J/N" (BPD)="J" O: DE ,,TAN-Generator/- Liste"="L" und DE ,,Eingabe TAN-Listennummer J/N" (BPD)=“N“ N: sonst
10ATC1DEnum..5C1M: DE ,,TAN-Generator/- Liste"="G" und DE ,,Eingabe von ATC und TAN erforder- lich" (BPD)="J" N: sonst
11TAN1DEan.99C1M: DE ,,TAN-Generator/- Liste"="G" und DE ,,Eingabe von ATC und TAN erforder- lich" (BPD)="J" N: sonst
+ + +##### ◆ Belegungsrichtlinien + + +###### TAN-Listennummer + +Wird keine TAN-Listennummer angegeben, so wird die aktuelle / freigeschal- +tete Liste verwendet. + + +###### Gültig ab, Gültig bis + +Die übliche Angabe im Format JJMM muss in diesem Fall auf ein existieren- +des Datumsformat umgesetzt werden (z. B. Gültig bis „9912“ wird umgesetzt +in „19991231“). + +Kartenart + +Die Eingabe der Kartenart wird über den BPD-Parameter „Eingabe Kartenart +zulässig“ gesteuert. Ist dieser Parameter auf „J“ gesetzt, enthält das BPD- +Segment HITAUS auch die zulässigen Kartenarten. + + +##### b) Kreditinstitutsrückmeldung + + +# Format + +Allgemeine Kreditinstitutsnachricht ohne Datensegmente + +Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020An- bzw. Ummeldung erfolgreich
9935An- bzw. Ummeldung fehlgeschlagen
9935Kartennummer unbekannt
9935TAN-Listennummer unbekannt
9935Karte als TAN-Generator nicht zugelassen – bitte wenden Sie sich an Ihr Institut
9935Keine TAN-Liste freigeschaltet
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
188		Stand: 23.02.2018Kapitel: Archiv: Ältere Segmentversionen
Abschnitt: Management chipTAN, mobileTAN und bilaterale Verfahren
+ + +## c) Bankparameterdaten + +Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:TAN-Generator an- bzw. ummelden Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HITAUS
Bezugssegment:HKVVB
Segmentversion:2
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter TAN- Generator An- bzw. Ummelden2DEGM1
+ + +### E.2.3 Verwalten von Mobilfunkverbindungen + + +#### E.2.3.1 Mobilfunkverbindung registrieren + + +#### E.2.3.1.1 Mobilfunkverbindung registrieren in Segmentversion #1 + +Mit Hilfe dieses Geschäftsvorfalls kann ein Kunde sein Mobilfunkverbindung regist- +rieren. + + +![](figures/188.1) + + +![](figures/188.2) + + +Dieser Geschäftsvorfall kann auch mit der Segmentkennung +HKMTS verwendet werden. Damit ist es möglich, den Geschäftsvor- +fall mit unterschiedlicher Belegung des Parameters ,,Abbuchungs- +konto erforderlich“ in der BPD zur Verfügung zu stellen und damit +über die UPD eine kundenspezifische Abrechnung der SMS-Kosten +zu erreichen. + +Realisierung Bank: optional + +Realisierung Kunde: optional + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: D
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FV
Kapitel:Archiv: Ältere SegmentversionenStand:Seite:
Abschnitt:Management chipTAN, mobileTAN und bilaterale Verfahren23.02.2018189
+ + +## a) Kundenauftrag + + +### Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Mobilfunkverbindung registrieren
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKMTR
Bezugssegment:-
Segmentversion:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Mobiltelefonnum- mer1DEan..35M1
3Bezeichnung des TAN-Mediums1DEan..32M1
4SMS- Abbuchungskonto1DEGkti#C1M: DE „SMS- Abbuchungskonto erforder- lich J/N" (BPD)="J" O: sonst
+ + +# ◆ Belegungsrichtlinien + + +## Mobiltelefonnummer + +Es muss die Mobiltelefonnummer verwendet werden, die mit dem Institut für +die Nutzung von mobileTAN vereinbart ist. Es sind nur Ziffern inklusive füh- +render Nullen erlaubt und es gilt die nationale Schreibweise für Telefonnum- +mern, z. B. 0170/1234567 oder (0170) 1234567. + + +![](figures/189.1) + + +Das Kundensystem sollte den Kunden bei der Eingabe eines kor- +rekten Telefonnummern-Formates unterstützen. + + +![](figures/189.2) + + +Falls der Prozess vorsieht, dass die Registrierung der Mobiltelefon- +nummer zuvor auf alternativem Weg erfolgen muss, können nur im +Vorfeld vereinbarte Rufnummern verwendet werden. Das Institut +muss in diesem Fall die Existenz einer entsprechenden Vereinba- +rung prüfen. + + +## b) Kreditinstitutsrückmeldung + + +## ◆ Erläuterungen + +Es werden keine Datensegmente zurückgemeldet. + +◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag verarbeitet
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
190		Stand: 23.02.2018Kapitel: Archiv: Ältere Segmentversionen
Abschnitt: Management chipTAN, mobileTAN und bilaterale Verfahren
+ + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
9939MobileTAN-Mobilrufnummer nicht zur Registrierung zugelassen
9939Format der mobileTAN-Mobilrufnummer nicht korrekt
9939MobileTAN-Mobilrufnummer bereits registriert
+ + +# c) Bankparameterdaten + +Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Mobilfunkverbindung registrieren Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIMTRS
Bezugssegment:HKVVB
Segmentversion:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Mobil- funkverbindung re- gistrieren1DEGM1
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FVD
Kapitel:Archiv: Ältere SegmentversionenStand:Seite:
Abschnitt:Management chipTAN, mobileTAN und bilaterale Verfahren23.02.2018191
+ + +## E.2.3.1.2 Mobilfunkverbindung registrieren in Segmentversion #2 + +Mit Hilfe dieses Geschäftsvorfalls kann ein Kunde sein Mobilfunkverbindung regist- +rieren. + + +![](figures/191.1) + + +![](figures/191.2) + + +Dieser Geschäftsvorfall kann auch mit der Segmentkennung +HKMTS verwendet werden. Damit ist es möglich, den Geschäftsvor- +fall mit unterschiedlicher Belegung des Parameters „Abbuchungs- +konto erforderlich“ in der BPD zur Verfügung zu stellen und damit +über die UPD eine kundenspezifische Abrechnung der SMS-Kosten +zu erreichen. + + + + + + + + + + + +
Realisierung Bank:optional
Realisierung Kunde:optional
+ + +### a) Kundenauftrag + + +#### Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Mobilfunkverbindung registrieren
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKMTR
Bezugssegment:-
Segmentversion:2
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Mobiltelefonnum- mer1DEan..35M1
3Bezeichnung des TAN-Mediums1DEan..32M1
4SMS- Abbuchungskonto1DEGkti#C1M: DE „SMS- Abbuchungskonto erforder- lich J/N" (BPD)="J" O: sonst
5Kontaktaufnahme durch Kreditinstitut erlaubt1DEjn#C1M: DE „Zustimmung zur Kontaktaufnahme unter- stützt“ (BPD)=“J“ O: sonst
+ + +### ◆ Belegungsrichtlinien + +Mobiltelefonnummer + +Es muss die Mobiltelefonnummer verwendet werden, die mit dem Institut für +die Nutzung von mobileTAN vereinbart ist. Es sind nur Ziffern inklusive füh- +render Nullen erlaubt und es gilt die nationale Schreibweise für Telefonnum- +mern, z. B. 0170/1234567 oder (0170) 1234567. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite: 192Stand: 23.02.2018Kapitel: Archiv: Ältere Segmentversionen
Abschnitt: Management chipTAN, mobileTAN und bilaterale Verfahren
+ + +![](figures/192.1) + + +Das Kundensystem sollte den Kunden bei der Eingabe eines +korrekten Telefonnummern-Formates unterstützen. + + +![](figures/192.2) + + +Falls der Prozess vorsieht, dass die Registrierung der Mobilte- +lefonnummer zuvor auf alternativem Weg erfolgen muss, kön- +nen nur im Vorfeld vereinbarte Rufnummern verwendet wer- +den. Das Institut muss in diesem Fall die Existenz einer ent- +sprechenden Vereinbarung prüfen. + + +## b) Kreditinstitutsrückmeldung + + +# Erläuterungen + +Es werden keine Datensegmente zurückgemeldet. + +◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag verarbeitet
9939MobileTAN-Mobilrufnummer nicht zur Registrierung zugelassen
9939Format der mobileTAN-Mobilrufnummer nicht korrekt
9939MobileTAN-Mobilrufnummer bereits registriert
+ + +c) +Bankparameterdaten + +Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Mobilfunkverbindung registrieren Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIMTRS
Bezugssegment:HKVVB
Segmentversion:2
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DENum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Mobil- funkverbindung re- gistrieren2DEGM1
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: D
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FV
Kapitel:Archiv: Ältere SegmentversionenStand:Seite:
Abschnitt:Management chipTAN, mobileTAN und bilaterale Verfahren23.02.2018193
+ + +## E.2.3.2Mobilfunkverbindung freischalten + + +### E.2.3.2.1 Mobilfunkverbindung freischalten in Segmentversion #1 + +Mit Hilfe dieses Geschäftsvorfalls kann ein Kunde seine zuvor registrierte Mobil- +funkverbindung freischalten. + +Realisierung Bank: +optional + +Realisierung Kunde: +optional + + +# a) Kundenauftrag + + +# Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Mobilfunkverbindung freischalten
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKMTF
Bezugssegment:-
Segmentversion:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Bezeichnung des TAN-Mediums1DEan..32M1
3Freischaltcode1DEan..8M1
+ + +# b) Kreditinstitutsrückmeldung + + +# Erläuterungen + +Es werden keine Datensegmente zurückgemeldet. + + +# ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Mobiltelefon für mobileTAN freigeschaltet
9939mobileTAN-Mobilrufnummer kann nicht freigeschaltet werden
3939mobileTAN-Freischaltung erforderlich. SMS-Freischaltcode wurde versendet
+ + +c) +Bankparameterdaten + + +# Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + +## ◆ Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Mobilfunkverbindung freischalten Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIMTFS
Bezugssegment:HKVVB
Segmentversion:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite: 194Stand: 23.02.2018Kapitel: Archiv: Ältere Segmentversionen
Abschnitt: Management chipTAN, mobileTAN und bilaterale Verfahren
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + +### E.2.3.2.2 Mobilfunkverbindung freischalten in Segmentversion #2 + +Mit Hilfe dieses Geschäftsvorfalls kann ein Kunde seine zuvor registrierte Mobil- +funkverbindung freischalten. + +Realisierung Bank: +optional + +Realisierung Kunde: optional + + +# a) Kundenauftrag + +Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Mobilfunkverbindung freischalten
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKMTF
Bezugssegment:-
Segmentversion:2
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Bezeichnung des TAN-Mediums1DEan..32M1
3Freischaltcode2DEan..64M1
+ + +b) +Kreditinstitutsrückmeldung + + +# Erläuterungen + +Es werden keine Datensegmente zurückgemeldet. + +◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Mobiltelefon für mobileTAN freigeschaltet
9939mobileTAN-Mobilrufnummer kann nicht freigeschaltet werden
3939mobileTAN-Freischaltung erforderlich. SMS-Freischaltcode wurde versendet
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: D
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FV
Kapitel:Archiv: Ältere SegmentversionenStand:Seite:
Abschnitt:Management chipTAN, mobileTAN und bilaterale Verfahren23.02.2018195
+ + +## c) Bankparameterdaten + + +## Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + +### ◆ Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Mobilfunkverbindung freischalten Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIMTFS
Bezugssegment:HKVVB
Segmentversion:2
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + +#### E.2.3.3Mobilfunkverbindung ändern + + +##### E.2.3.3.1 Mobilfunkverbindung ändern in Segmentversion #1 + +Mit Hilfe dieses Geschäftsvorfalls kann ein Kunde seine Mobilfunkverbindung bzw. +die damit verbundenen Informationen ändern. + + +![](figures/195.1) + + +![](figures/195.2) + + +Dieser Geschäftsvorfall kann auch mit der Segmentkennung +HKMTB verwendet werden. Damit ist es möglich, den Geschäftsvor- +fall mit unterschiedlicher Belegung des Parameters „Abbuchungs- +konto erforderlich“ in der BPD zur Verfügung zu stellen und damit +über die UPD eine kundenspezifische Abrechnung der SMS-Kosten +zu erreichen. + +Realisierung Bank: optional + +Realisierung Kunde: optional + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite: 196Stand: 23.02.2018Kapitel: Archiv: Ältere Segmentversionen
Abschnitt: Management chipTAN, mobileTAN und bilaterale Verfahren
+ + +###### a) Kundenauftrag + + +####### Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Mobilfunkverbindung ändern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKMTA
Bezugssegment:-
Segmentversion:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Mobiltelefonnum- mer1DEan..35O1
3Bezeichnung des TAN-Mediums alt1DEan..32M1
4Bezeichnung des TAN-Mediums neu1DEan..32M1
5SMS- Abbuchungskonto1DEGkti#O1M: DE „SMS- Abbuchungskonto erforder- lich J/N" (BPD)="J" O: sonst
+ + +####### ◆ Belegungsrichtlinien + + +######## Bezeichnung des TAN-Mediums alt + +Es muss die vereinbarte Bezeichnung einer bestehenden und frei geschalte- +ten Mobiltelefonnummer verwendet werden. + + +######## b) Kreditinstitutsrückmeldung + + +######## Erläuterungen + +Es werden keine Datensegmente zurückgemeldet. + + +######## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag verarbeitet
9939MobileTAN-Mobilrufnummer nicht zur Registrierung zugelassen
9939Format der mobileTAN-Mobilrufnummer nicht korrekt
9939MobileTAN-Mobilrufnummer bereits registriert
9939alte mobileTAN-Mobilfunknummer existiert nicht oder ist nicht freigeschaltet
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: D
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FV
Kapitel:Archiv: Ältere SegmentversionenStand:Seite:
Abschnitt:Management chipTAN, mobileTAN und bilaterale Verfahren23.02.2018197
+ + +####### c) Bankparameterdaten + +Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Mobilfunkverbindung registrieren Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIMTAS
Bezugssegment:HKVVB
Segmentversion:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Mobil- funkverbindung än- dern1DEGM1
+ + +##### E.2.3.3.2 Mobilfunkverbindung ändern in Segmentversion #2 + +Mit Hilfe dieses Geschäftsvorfalls kann ein Kunde seine Mobilfunkverbindung bzw. +die damit verbundenen Informationen ändern. + + +![](figures/197.1) + + +![](figures/197.2) + + +Dieser Geschäftsvorfall kann auch mit der Segmentkennung +HKMTB verwendet werden. Damit ist es möglich, den Geschäftsvor- +fall mit unterschiedlicher Belegung des Parameters ,,Abbuchungs- +konto erforderlich“ in der BPD zur Verfügung zu stellen und damit +über die UPD eine kundenspezifische Abrechnung der SMS-Kosten +zu erreichen. + +Realisierung Bank: optional + +Realisierung Kunde: optional + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite: 198Stand: 23.02.2018Kapitel: Archiv: Ältere Segmentversionen
Abschnitt: Management chipTAN, mobileTAN und bilaterale Verfahren
+ + +###### a) Kundenauftrag + + +####### Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Mobilfunkverbindung ändern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKMTA
Bezugssegment:-
Segmentversion:2
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Mobiltelefonnum- mer1DEan..35O1
3Bezeichnung des TAN-Mediums alt1DEan..32M1
4Bezeichnung des TAN-Mediums neu1DEan..32M1
5SMS- Abbuchungskonto1DEGkti#O1M: DE „SMS- Abbuchungskonto erforder- lich J/N" (BPD)="J" O: sonst
6Kontaktaufnahme durch Kreditinstitut erlaubt1DEjn#C1M: DE „Zustimmung zur Kontaktaufnahme unter- stützt“ (BPD)=“J“ O: sonst
+ + +####### ◆ Belegungsrichtlinien + + +######## Bezeichnung des TAN-Mediums alt + +Es muss die vereinbarte Bezeichnung einer bestehenden und frei geschalte- +ten Mobiltelefonnummer verwendet werden. + + +######## b) Kreditinstitutsrückmeldung + + +######## Erläuterungen + +Es werden keine Datensegmente zurückgemeldet. + +◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag verarbeitet
9939MobileTAN-Mobilrufnummer nicht zur Registrierung zugelassen
9939Format der mobileTAN-Mobilrufnummer nicht korrekt
9939MobileTAN-Mobilrufnummer bereits registriert
9939alte mobileTAN-Mobilfunknummer existiert nicht oder ist nicht freigeschaltet
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: D
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FV
Kapitel:Archiv: Ältere SegmentversionenStand:Seite:
Abschnitt:Management chipTAN, mobileTAN und bilaterale Verfahren23.02.2018199
+ + +####### c) Bankparameterdaten + + +######## Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:Mobilfunkverbindung registrieren Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HIMTAS
Bezugssegment:HKVVB
Segmentversion:2
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
5Parameter Mobil- funkverbindung än- dern2DEGM1
+ + +######### E.2.3.4Deaktivieren / Löschen von TAN-Medien + + +########## E.2.3.4.1 Deaktivieren / Löschen von TAN-Medien, Segmentversion #1 + +Mit Hilfe dieses Geschäftsvorfalls kann ein Kunde ein aktives bzw. verfügbares +TAN-Medium deaktivieren oder löschen. + +Deaktivieren, bewirkt eine Statusänderung von „aktiv“ nach „verfügbar“ für das ge- +wählte TAN-Medium. + +Beim Löschvorgang wird das entsprechende TAN-Medium gänzlich von der Liste +der TAN-Medien genommen. Dieser Vorgang kann nicht mehr rückgängig gemacht +werden. + +Realisierung Bank: optional + +Realisierung Kunde: optional + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite: 200Stand: 23.02.2018Kapitel: Archiv: Ältere Segmentversionen
Abschnitt: Management chipTAN, mobileTAN und bilaterale Verfahren
+ + +####### a) Kundenauftrag + + +######## Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:TAN-Medium deaktivieren oder löschen
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKTML
Bezugssegment:-
Segmentversion:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2TAN-Medium- Klasse1DEcode1M1L, G, M
3TAN-Listennummer1DEan..20C1M: DE „TAN-Medium- Klasse“=“L“ N: sonst
4Bezeichnung des TAN-Mediums1DEan..32C1M: DE „TAN-Medium- Klasse“=“M“ N: sonst
5Deaktivie- ren/Löschen1DEcode1M1
+ + +### ◆ Belegungsrichtlinien + + +#### TAN-Medium-Klasse + +Es muss die zu deaktivierende / zu löschende TAN-Medium-Klasse angege- +ben werden. Bei Angabe von TAN-Medium-Klasse"G" wird die als aktiv defi- +nierte Kombination aus TAN-Generator und Karte gelöscht bzw. deaktiviert. +Bei TAN-Medium-Klasse="L" oder ,M" muss die Angabe der TAN- +Listennummer bzw. der Bezeichnung des TAN-Mediums erfolgen. + + +![](figures/200.1) + + +Das Kundensystem sollte den Kunden darauf hinweisen, +wenn er versuchen will, das letzte im Bestand des Kunden- +systems bekannte TAN-Medium zu deaktivieren oder zu lö- +schen. + + +#### b) Kreditinstitutsrückmeldung + + +## Erläuterungen + +Es werden keine Datensegmente zurückgemeldet. + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: D
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FV
Kapitel:Archiv: Ältere SegmentversionenStand:Seite:
Abschnitt:Management chipTAN, mobileTAN und bilaterale Verfahren23.02.2018201
+ + +## ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag verarbeitet
9958Deaktivieren / Löschen für TAN-Medium nicht möglich
9958TAN-Medium nicht bekannt
+ + +## c) Bankparameterdaten + + +## Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + +# ◆ Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:TAN-Medium deaktivieren oder löschen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HITMLS
Bezugssegment:HKVVB
Segmentversion:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen mindestens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + +## E.2.4 TAN-Verbrauchsinformationen anzeigen + +Dieses Segment bewirkt die Anzeige der verbrauchten TANs des Kunden. + + +### E.2.4.1 TAN-Verbrauchsinformationen anzeigen, Segmentversion #1 + +Realisierung Bank: +optional + +Realisierung Kunde: optional + + +### a) Kundenauftrag + + +### Beschreibung + +Das Auftragssegment enthält neben dem Segmentkopf keine weiteren Daten. + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
202		Stand: 23.02.2018Kapitel: Archiv: Ältere Segmentversionen
Abschnitt: Management chipTAN, mobileTAN und bilaterale Verfahren
+ + +# ◆ Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:TAN-Verbrauchsinformationen anfordern
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HKTAZ
Bezugssegment:-
Segmentversion:1
Sender:Kunde
+ + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
+ + +b) +Kreditinstitutsrückmeldung + + +# Beschreibung + +Je zurück zu meldender TAN-Liste ist ein Segment in die Antwortnachricht einzu- +stellen. + + +# ◆ Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:TAN-Verbrauchsinformationen rückmelden
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HITAZ
Bezugssegment:HKTAZ
Segmentversion:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FVD
Kapitel:Archiv: Ältere SegmentversionenStand:Seite:
Abschnitt:Management chipTAN, mobileTAN und bilaterale Verfahren23.02.2018203
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2TAN-Listenstatus1DEcode1M1A, N, S, V
3TAN-Listennummer1DEan..20M1
4Erstellungsdatum1DEdat#O1
5Anzahl TANs pro Liste1DEnum..4O1
6Anzahl verbrauchter TANs pro Liste1DEnum..4O1
7TAN-Information1DEGO999
+ + +# ◆ Belegungsrichtlinien + +TAN-Listennummer + +Kennung der TAN-Liste, die zurückgemeldet wird. + + +# ◆ Ausgewählte Beispiele für Rückmeldungscodes + + + + + + + + + + + +
CodeBeispiel für Rückmeldungstext
0020Auftrag ausgeführt
+ + +## c) Bankparameterdaten + + +## Beschreibung + +Geschäftsvorfallspezifische Parameter existieren nicht. + + +## ◆ Format + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name:TAN-Verbrauchsinformationen Parameter
Typ:Segment
Segmentart:Geschäftsvorfall
Kennung:HITAZS
Bezugssegment:HKVVB
Segmentversion:1
Sender:Kreditinstitut
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.NameVer- sionTypFor- matLän- geSta- tusAn- zahlRestriktionen
1Segmentkopf1DEGM1
2Maximale Anzahl Aufträge1DEnum..3M1
3Anzahl Signaturen minde- stens1DEnum1M10, 1, 2, 3
4Sicherheitsklasse1DEcode1M10, 1, 2, 3, 4
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite: 204Stand: 23.02.2018Kapitel: Anlagen
Abschnitt: Übersicht der Segmente
+ + +# F. ANLAGEN + + +## F.1 Übersicht der Segmente + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.SegmentnameKennungSen- der1Version
1Anzeige der Verfügbaren TAN-MedienHKTABK1
2Anzeige der Verfügbaren TAN-MedienHKTABK2
3Anzeige der Verfügbaren TAN-MedienHKTABK3
4Anzeige der Verfügbaren TAN-MedienHKTABK4
5Anzeige der Verfügbaren TAN-MedienHKTABK5
6Anzeige der Verfügbaren TAN-Medien ParameterHITABSI1
7Anzeige der Verfügbaren TAN-Medien ParameterHITABSI2
8Anzeige der Verfügbaren TAN-Medien ParameterHITABSI3
9Anzeige der Verfügbaren TAN-Medien ParameterHITABSI4
10Anzeige der Verfügbaren TAN-Medien ParameterHITABSI5
11Anzeige der Verfügbaren TAN-Medien rückmeldenHITABI1
12Anzeige der Verfügbaren TAN-Medien rückmeldenHITABI2
13Anzeige der Verfügbaren TAN-Medien rückmeldenHITABI3
14Anzeige der Verfügbaren TAN-Medien rückmeldenHITABI4
15Anzeige der Verfügbaren TAN-Medien rückmeldenHITABI5
16HHD- / Secoder-Informationen übermittelnHKHSIK1
17HHD- / Secoder-Informationen ParameterHIHSISI1
18HHD- / Secoder-Informationen rückmeldenHIHSII1
19Mobilfunkverbindung ändernHKMTAK1
20Mobilfunkverbindung ändernHKMTAK2
21Mobilfunkverbindung ändernHKMTAK3
22Mobilfunkverbindung ändern ParameterHIMTASI1
23Mobilfunkverbindung ändern ParameterHIMTASI2
24Mobilfunkverbindung ändern ParameterHIMTASI3
25Mobilfunkverbindung freischaltenHKMTFK1
26Mobilfunkverbindung freischaltenHKMTFK2
27Mobilfunkverbindung freischaltenHKMTFK3
28Mobilfunkverbindung freischalten ParameterHIMTFSI1
29Mobilfunkverbindung freischalten ParameterHIMTFSI2
30Mobilfunkverbindung freischalten ParameterHIMTFSI3
31Deaktivieren/Löschen von TAN-MedienHKTMLK1
32Deaktivieren/Löschen von TAN-MedienHKTMLK2
33Mobilfunkverbindung löschen ParameterHIMTLSI1
34Mobilfunkverbindung löschen ParameterHIMTLSI2
35Mobilfunkverbindung registrierenHKMTRK1
36Mobilfunkverbindung registrierenHKMTRK2
37Mobilfunkverbindung registrierenHKMTRK3
38Mobilfunkverbindung registrieren ParameterHIMTRSI1
39Mobilfunkverbindung registrieren ParameterHIMTRSI2
+ +1 +K: Kunde, I: Kreditinstitut + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel: D
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FV
Kapitel:AnlagenStand:Seite:
Abschnitt:Übersicht der Segmente23.02.2018205
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nr.SegmentnameKennungSen- der1Version
40Mobilfunkverbindung registrieren ParameterHIMTRSI3
41PIN ändernHKPAEK1
42PIN ändern ParameterHIPAESI1
43PIN sperrenHKPSPK1
44PIN sperren ParameterHIPSPSI1
45PIN-Sperre aufhebenHKPSAK1
46PIN-Sperre aufheben ParameterHIPSASI1
47PIN/TAN-spezifische InformationenHIPINSI1
48TAN-Generator an- bzw. ummeldenHKTAUK1
49TAN-Generator an- bzw. ummeldenHKTAUK2
50TAN-Medium an- bzw. ummeldenHKTAUK3
51TAN-Generator an- bzw. ummelden ParameterHITAUSI1
52TAN-Generator an- bzw. ummelden ParameterHITAUSI2
53TAN-Medium an- bzw. ummelden ParameterHITAUSI3
54TAN-Generator SynchronisierungHKTSYK1
55TAN-Generator Synchronisierung ParameterHITSYSI1
56TAN-Verbrauchsinformationen anfordernHKTAZK1
57TAN-Verbrauchsinformationen anfordernHKTAZK2
58TAN-Verbrauchsinformationen ParameterHITAZSI1
59TAN-Verbrauchsinformationen ParameterHITAZSI2
60TAN-Verbrauchsinformationen rückmeldenHITAZI1
61TAN-Verbrauchsinformationen rückmeldenHITAZI2
62Zwei-Schritt-TAN EinreichungHKTANK1
63Zwei-Schritt-TAN EinreichungHKTANK2
64Zwei-Schritt-TAN EinreichungHKTANK3
65Zwei-Schritt-TAN EinreichungHKTANK4
66Zwei-Schritt-TAN EinreichungHKTANK5
67Zwei-Schritt-TAN EinreichungHKTANK6
68Zwei-Schritt-TAN Einreichung ParameterHITANSI1
69Zwei-Schritt-TAN Einreichung ParameterHITANSI2
70Zwei-Schritt-TAN Einreichung ParameterHITANSI3
71Zwei-Schritt-TAN Einreichung ParameterHITANSI4
72Zwei-Schritt-TAN Einreichung ParameterHITANSI5
73Zwei-Schritt-TAN Einreichung ParameterHITANSI6
74Zwei-Schritt-TAN RückmeldungHITANI1
75Zwei-Schritt-TAN RückmeldungHITANI2
76Zwei-Schritt-TAN RückmeldungHITANI3
77Zwei-Schritt-TAN RückmeldungHITANI4
78Zwei-Schritt-TAN RückmeldungHITANI5
79Zwei-Schritt-TAN RückmeldungHITANI6
+ + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite: 206Stand: 23.02.2018Kapitel: Anlagen
Abschnitt: Übersicht Nachrichtenaufbau
+ + +## F.2 Übersicht Nachrichtenaufbau + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
SegmentNachricht
DialoginitialisierungAuftragsnachrichtDialogbeendigung
KundeKredit-KundeKredit-KundeKredit-
N6N2N15N14N8N14
Nachricht110-n0-n11
HNHBK111111
HNVSK111111
HNVSD111111
HNSHK10-11-30-110-1
HIRMG-1-1-1
HIRMS-0-m-0-m-0-m
HKIDN1-----
HKVVB1-----
HKISA------
HKSYN------
HIBPA-0-1----
HIKOM-0-1----
HISHV-0-1----
HIKPV-0-1----
2
...		-0-n----
HIPINS-1----
HITANS-0-1----
HIUPA-0-1----
HIUPD-0-n----
HIISA------
HISYN------
HIKIM-0-n----
HKSAL3
3		--1---
HISAL---0-n--
...------
HKTAN0-1-0-14---
HITAN-0-1-0-1--
HKPRO--0-1---
HIPRO---0-n--
HKEND----1-
HNSHA10-11-30-110-1
HNHBS111111
+ +2 +Hier sind für die weiteren unterstützten Geschäftsvorfälle die entsprechenden Parameter-Segmente +einzustellen. + +3 +Exemplarisch wird hier der Geschäftsvorfall „Saldenabfrage“ angenommen. + +4 +HKTAN kann mit anderen, nicht TAN-pflichtigen Aufträgen in einer Nachricht kombiniert werden. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FVD
Kapitel:AnlagenStand:Seite:
Abschnitt:Übersicht Nachrichtenaufbau23.02.2018207
+ + +### F.2.1 Beispieldialog im Ein-Schritt-Verfahren + +Das Beispiel entspricht dem Beispiel in [Formals] mit dem Unterschied, dass der +Kunde PIN/TAN im Ein-Schritt-Verfahren als Sicherheitsverfahren einsetzt. Abwei- +chungen sind fettgedruckt. + + +### F.2.2 Nachricht ,,Dialoginitialisierung" + + +#### a) Kundennachricht5 + +HNHBK:1:3+000000000323+300+0+1' + +HNVSK:998:3+PIN:1+998+1+1::2+1:20020610:102044+2 +:2:13:@8@:5:1+280:10 +020030:12345:V:0:0+0' + +HNVSD:999:1+@348@'6 + +HNSHK:2:4+PIN:1+999+654321+1+1+1::2+3234+1:20020 +701:111144+1:999:1+6:10:16+280:10020030:12345:S: +0 : 0' + +HKIDN:3:2+280:10020030+12345+2+1' + +HKVVB:4:2+2+3+1+Onlinebanking Plus+3.0' + +HNSHA:5:2+654321++83427' + +HNHBS:6:1+1' + + +## b) Kreditinstitutsnachricht + +Der Kunde erhält die aktuellen Bank- und Userparameterdaten, da die dem Kunden +vorliegenden Daten nicht mehr aktuell sind. Das Kreditinstitut unterstützt über +PIN/TAN die Geschäftsvorfälle „SEPA Einzelüberweisung“, „Neue Umsätze“ und +„Saldenabfrage“ sowie zusätzlich „PIN ändern“, „TAN-Liste anfordern" und ,,TAN- +Liste freischalten“. + +HNHBK:1:3+000000000932+300+4711+1+4711:1' + +HNVSK:998:3+PIN:1+998+1+1::2+1:20020610:102044+2 +:2:13:@8@:5:1+280:10 +020030:12345:V:0:0+0' + +HNVSD:999:1+@348@' + +HIRMG:2:2+0010::Nachricht entgegengenommen ' + + + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite: 208Stand: 23.02.2018Kapitel: Anlagen
Abschnitt: Übersicht Nachrichtenaufbau
+ + +HIBPA:3:2:4+3+280:10020030+Musterbank in Musters +tadt+1+1:2:3+1+100' + +HIKOM:4:4:4+280:10020030+1+2:123.123.123.123::UU +E:1+3:https?://www.xyz.de?: 7000/PinTanServlet: :U +UE : 1' 7 + +HISHV:5:2:4+N+RAH:3:2:1' + +HICCSS:6:1:4+1+2+7:51:53:54:67:69' + +HICCSS:7:2:4+1+2+14:51:53:54:67:69' + +HILASS:8:2:4+1+2+14:04:05' + +HISUBS:9:2:4+1+2+999:14:51:53:54' + +HISLAS:10:2:4+1+2+99:14:04:05' + +HIKAZS:11:2:4+1+2+60:J' + +HIKANS:12:2:4+1+2+60:J' + +HISALS:13:3:4+1+2' + +HIPINS:14:1:4+1+1+5:6:6:Kunden-Nr aus dem TAN-Br + +ief : :HKCCS : J:HKKAN:N:HKSAL:J:HKPAE:J:' + +HIPAES:15:1:4+1+1' + +HIUPA:18:2:4+12345+4+0' + +HIUPD:19:4:4+1234567:280:10020030+12345+EUR+Erns +t Müller++Giro Spezial+T:2000, : EUR+HKPRO : 1+HKSAK +:1+HKISA:1+HKSSP:1+HKCCS : 1+HKLAS :1+HKKAN:1+HKKAZ +:1+HKSAL:1+HKPAE:1' + +HIUPD:20:4:4+1234568:280:10020030+12345+EUR+Erns +t Müller++Sparkonto 2000++HKPRO: 1+HKSAK:0+HKISA: +1+HKSSP:0+HKCCS:2:Z:1000,: EUR:7+HKKAN:1+HKKAZ:1+ +HKSAL:2' + +HIKIM:21:2+Bausparförderung+Informieren Sie sich +über die neue Bausparförderung. ' + +HNHBS:22:1+1' + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FVD
Kapitel:AnlagenStand:Seite:
Abschnitt:Übersicht Nachrichtenaufbau23.02.2018209
+ + +## F.2.3 Nachricht „SEPA Einzelüberweisung" + + +### a) Kundennachricht + +Diese Nachricht wird sowohl von Benutzer '12345' als auch von Benutzer '76543' +signiert. + +HNHBK:1:3+000000000523+300+4711+2' + +HNVSK:998:3+PIN:1+998+1+1::2+1:20020610:102044+2 +:2:13:@8@:5:1+280:10 +020030:12345:V:0:0+0' + +HNVSD:999:1+@348@' + +HNSHK:2:4+PIN:1+999+765432+1+1+1::2+3234+1:20020 +701:111146+1:999:1+6:10:16+280:10020030:76543: S: +0 : 0 ' + +HNSHK:3:4+PIN:1+999+654321+1+1+1::2+3234+1:20020 +701:111147+1:999:1+6:10:16+280:10020030:12345:S: +0 : 0' + +HKCCS:4:2+1234567::280:10020030+7654321::280:200 +30040+MEIER FRANZ++1000,:EUR+51+000+RE-NR.1234:K +D-NR. 9876' + +HNSHA:5:2+654321++83427:954378' + +HNSHA:6:2+765432++22714:528019' + +HNHBS:7:1+2' + + +## b) Kreditinstitutsnachricht + +HNHBK:1:3+000000000140+300+4711+2+4711:2' + +HNVSK:998:3+PIN:1+998+1+1::2+1:20020610:102044+2 +:2:13:@8@:5:1+280:10 +020030:12345:V:0:0+0' + +HNVSD:999:1+@348@' + +HIRMG:2:2+0010::Nachricht entgegengenommen ' + +HIRMS:3:2:4+0010::Auftrag entgegengenommen ' +HNHBS:4:1+2' + + + + + + + + + + + + + + + +
Kapitel: DVersion: 3.0-FVFinancial Transaction Services (FinTS) Dokument: Security - Sicherheitsverfahren PIN/TAN
Seite:
210		Stand: 23.02.2018Kapitel: Anlagen
Abschnitt: Übersicht Nachrichtenaufbau
+ + +## F.2.4 Nachricht ,,Saldenabfrage" + + +### a) Kundennachricht + +Die Kundennachricht wird nur von Benutzer '12345' signiert. + +HNHBK:1:3+000000000257+300+4711+3' + +HNVSK:998:3+PIN:1+998+1+1::2+1:20020610:102044+2 +:2:13:@8@:5:1+280:10 +020030:12345:V:0:0+0' + +HNVSD:999:1+@348@' + +HNSHK:2:4+PIN:1+999+654321+1+1+1::2+3234+1:20020 +701:111149+1:999:1+6:10:16+280:10020030:12345: S: +0 : 0' + +HKSAL:3:3+1234567::280:10020030+N' + +HNSHA:4:2+654321++83427' + +HNHBS:5:1+3' + + +### b) Kreditinstitutsnachricht + +HNHBK:1:3+000000000213+300+4711+3+4711:3' + +HNVSK:998:3+PIN:1+998+1+1::2+1:20020610:102044+2 +:2:13:@8@:5:1+280:10 +020030:12345:V:0:0+0' + +HNVSD:999:1+@348@' + +HIRMG:2:2+0010::Nachricht entgegengenommen' + +HIRMS:3:2:3+0020::Auftrag ausgeführt' + +HISAL:4:3:3+1234567::280:10020030+Giro Spezial+E + +UR+C:1000, :EUR: 20020701+D:500,:EUR:20020701+5000 +, : EUR+7138,35: EUR+1476,98 : EUR' + +HNHBS:5:1+3' + + +## F.2.5 Nachricht ,,Dialogbeendigung“ + + +## a) Kundennachricht + +HNHBK:1:3+0000000000475+300+4711+4' + +HNVSK:998:3+PIN:1+998+1+1::2+1:20020610:102044+2 +:2:13:@8@:5:1+280:10 +020030:12345:V:0:0+0' + +HNVSD:999:1+@348@' + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Financial Transaction Services (FinTS)Version:Kapitel:
Dokument:Security - Sicherheitsverfahren PIN/TAN3.0-FVD
Kapitel:AnlagenStand:Seite:
Abschnitt:Übersicht Nachrichtenaufbau23.02.2018211
+ + +HNSHK:2:4+PIN:1+999+654321+1+1+1::2+3234+1:20020 +701:111151+1:999:1+6:10:16+280:10020030:12345: S: +0 : 0' + +HKEND:3:1+4711' + +HNSHA:4:2+654321++83427' + +HNHBS:5:1+4' + + +## b) Kreditinstitutsnachricht + +HNHBK:1:3+000000000385+300+4711+4+4711:4' + +HNVSK:998:3+PIN:1+998+1+1::2+1:20020610:102044+2 +:2:13:@8@:5:1+280:10 +020030:12345:V:0:0+0' + +HNVSD:999:1+@348@' + +HIRMG:2:2+0100::Dialog beendet' + +HIRMS:3:2:3+0020::Auftrag ausgeführt' +HNHBS:4:1+4' diff --git a/docs/fints-def/FinTS_3.0_Security_Sicherheitsverfahren_PINTAN_2018-02-23_final_version.pdf b/docs/fints-def/FinTS_3.0_Security_Sicherheitsverfahren_PINTAN_2018-02-23_final_version.pdf new file mode 100644 index 0000000..eb02530 Binary files /dev/null and b/docs/fints-def/FinTS_3.0_Security_Sicherheitsverfahren_PINTAN_2018-02-23_final_version.pdf differ diff --git a/docs/tested.rst b/docs/tested.rst index 6ca09ce..d34f27d 100644 --- a/docs/tested.rst +++ b/docs/tested.rst @@ -11,11 +11,13 @@ Postbank Yes BBBank eG Yes Yes Sparkasse Heidelberg Yes comdirect Yes Yes +Consorsbank Yes Yes ======================================== ============ ======== ======== ====== Tested security functions ------------------------- +* ``900`` "photoTAN" / "Secure Plus" (QR code) * ``902`` "photoTAN" * ``921`` "pushTAN" * ``930`` "mobile TAN" diff --git a/docs/transfers.rst b/docs/transfers.rst index c2e20c2..8f9fec2 100644 --- a/docs/transfers.rst +++ b/docs/transfers.rst @@ -67,13 +67,22 @@ Full example if isinstance(res, NeedTANResponse): print("A TAN is required", res.challenge) + # photoTAN / QR code: save and display the image + if getattr(res, 'challenge_matrix', None): + mime_type, image_data = res.challenge_matrix + with open('tan_challenge.png', 'wb') as f: + f.write(image_data) + print(f"QR code saved to tan_challenge.png ({len(image_data)} bytes)") + # Optionally open the image automatically: + # import subprocess; subprocess.Popen(['open', 'tan_challenge.png']) + if getattr(res, 'challenge_hhduc', None): try: terminal_flicker_unix(res.challenge_hhduc) except KeyboardInterrupt: pass - if result.decoupled: + if res.decoupled: tan = input('Please press enter after confirming the transaction in your app:') else: tan = input('Please enter TAN:') diff --git a/fints/client.py b/fints/client.py index 7e0898a..927222b 100644 --- a/fints/client.py +++ b/fints/client.py @@ -28,7 +28,7 @@ PinTanTwoStepAuthenticationMechanism, ) from .segments.accounts import HISPA1, HKSPA1 -from .segments.auth import HIPINS1, HKTAB4, HKTAB5, HKTAN2, HKTAN3, HKTAN5, HKTAN6, HKTAN7, HIVPPS1, HIVPP1, PSRD1, HKVPA1 +from .segments.auth import HIPINS1, HKTAB4, HKTAB5, HKTAN2, HKTAN3, HKTAN5, HKTAN6, HKTAN7, HIVPPS1, HIVPP1, HKVPP1, PSRD1, HKVPA1 from .segments.bank import HIBPA3, HIUPA4, HKKOM4 from .segments.debit import ( HKDBS1, HKDBS2, HKDMB1, HKDMC1, HKDME1, HKDME2, @@ -39,7 +39,7 @@ from .segments.journal import HKPRO3, HKPRO4 from .segments.saldo import HKSAL5, HKSAL6, HKSAL7 from .segments.statement import DKKKU2, HKKAZ5, HKKAZ6, HKKAZ7, HKCAZ1, HKKAU2, HKKAU1, HKEKA3, HKEKA4, HKEKA5 -from .segments.transfer import HKCCM1, HKCCS1, HKIPZ1, HKIPM1 +from .segments.transfer import HKCCM1, HKCCS1, HKCSE1, HICSE1, HKIPZ1, HKIPM1 from .types import SegmentSequence from .utils import ( MT535_Miniparser, Password, SubclassesMixin, @@ -75,6 +75,7 @@ class FinTSOperations(Enum): GET_SCHEDULED_DEBITS_MULTIPLE = ("HKDMB", ) GET_STATUS_PROTOCOL = ("HKPRO", ) SEPA_TRANSFER_SINGLE = ("HKCCS", ) + SEPA_TRANSFER_SINGLE_SCHEDULED = ("HKCSE", ) SEPA_TRANSFER_MULTIPLE = ("HKCCM", ) SEPA_DEBIT_SINGLE = ("HKDSE", ) SEPA_DEBIT_MULTIPLE = ("HKDME", ) @@ -880,6 +881,51 @@ def simple_sepa_transfer(self, account: SEPAAccount, iban: str, bic: str, xml = sepa.export().decode() return self.sepa_transfer(account, xml, pain_descriptor="urn:iso:std:iso:20022:tech:xsd:"+version, instant_payment=instant_payment) + def simple_scheduled_sepa_transfer(self, account: SEPAAccount, iban: str, bic: str, + recipient_name: str, amount: Decimal, account_name: str, reason: str, + execution_date: datetime.date, endtoend_id='NOTPROVIDED'): + """ + Simple scheduled SEPA transfer. + + :param account: SEPAAccount to start the transfer from. + :param iban: Recipient's IBAN + :param bic: Recipient's BIC (Can be None if domestic) + :param recipient_name: Recipient name + :param amount: Amount as a ``Decimal`` + :param account_name: Sender account name + :param reason: Transfer reason + :param execution_date: Future execution date requested from the bank + :param endtoend_id: End-to-end-Id (defaults to ``NOTPROVIDED``) + :return: Returns either a NeedRetryResponse or NeedVOPResponse or TransactionResponse + """ + config = { + "name": account_name, + "IBAN": account.iban, + "BIC": account.bic, + "batch": False, + "currency": "EUR", + } + + version = self._find_supported_sepa_version([ + 'pain.001.001.09', + 'pain.001.001.03' + ]) + + sepa = SepaTransfer(config, version) + payment = { + "name": recipient_name, + "IBAN": iban, + "amount": round(Decimal(amount) * 100), # in cents + "execution_date": execution_date, + "description": reason, + "endtoend_id": endtoend_id, + } + if bic: + payment["BIC"] = bic + sepa.add_payment(payment) + xml = sepa.export().decode() + return self.scheduled_sepa_transfer(account, xml, pain_descriptor="urn:iso:std:iso:20022:tech:xsd:"+version) + def sepa_transfer(self, account: SEPAAccount, pain_message: str, multiple=False, control_sum=None, currency='EUR', book_as_single=False, pain_descriptor='urn:iso:std:iso:20022:tech:xsd:pain.001.001.03', instant_payment=False): @@ -932,9 +978,38 @@ def sepa_transfer(self, account: SEPAAccount, pain_message: str, multiple=False, return self._send_pay_with_possible_retry(dialog, seg, self._continue_sepa_transfer) + def scheduled_sepa_transfer(self, account: SEPAAccount, pain_message: str, + pain_descriptor='urn:iso:std:iso:20022:tech:xsd:pain.001.001.03'): + """ + Custom scheduled SEPA transfer. + + :param account: SEPAAccount to send the transfer from. + :param pain_message: SEPA PAIN message containing the transfer details with a future execution date. + :param pain_descriptor: URN of the PAIN message schema used. + :return: Returns either a NeedRetryResponse or TransactionResponse (with data['order_id'] set if returned by bank) + """ + + with self._get_dialog() as dialog: + self._find_highest_supported_command( + HKCSE1, + return_parameter_segment=True + ) + + seg = HKCSE1( + account=HKCSE1._fields['account'].type.from_sepa_account(account), + sepa_descriptor=pain_descriptor, + sepa_pain_message=pain_message.encode(), + ) + + return self._send_pay_with_possible_retry(dialog, seg, self._continue_sepa_transfer) + def _continue_sepa_transfer(self, command_seg, response): retval = TransactionResponse(response) + for seg in response.find_segments(HICSE1): + if seg.order_id: + retval.data['order_id'] = seg.order_id + for seg in response.find_segments(HIRMS2): for resp in seg.responses: retval.set_status_if_higher(_RESPONSE_STATUS_MAPPING.get(resp.code[0], ResponseStatus.UNKNOWN)) @@ -1253,16 +1328,24 @@ def _parse_tan_challenge(self): class FinTS3PinTanClient(FinTS3Client): - def __init__(self, bank_identifier, user_id, pin, server, customer_id=None, tan_medium=None, *args, **kwargs): + def __init__(self, bank_identifier, user_id, pin, server, customer_id=None, tan_medium=None, + force_twostep_tan=None, *args, **kwargs): self.pin = Password(pin) if pin is not None else pin self._pending_tan = None self.connection = FinTSHTTPSConnection(server) self.allowed_security_functions = [] self.selected_security_function = None self.selected_tan_medium = tan_medium + self.force_twostep_tan = set(force_twostep_tan) if force_twostep_tan else self._default_force_twostep_tan(bank_identifier) self._bootstrap_mode = True super().__init__(bank_identifier=bank_identifier, user_id=user_id, customer_id=customer_id, *args, **kwargs) + @staticmethod + def _default_force_twostep_tan(bank_identifier): + if str(bank_identifier) == '76030080': + return {'HKCCS', 'HKKAZ', 'HKSAL'} + return set() + def _new_dialog(self, lazy_init=False): if self.pin is None: enc = None @@ -1394,14 +1477,16 @@ def _find_vop_format_for_segment(self, seg): def _need_twostep_tan_for_segment(self, seg): if not self.selected_security_function or self.selected_security_function == '999': return False - else: - hipins = self.bpd.find_segment_first(HIPINS1) - if not hipins: - return False - else: - for requirement in hipins.parameter.transaction_tans_required: - if seg.header.type == requirement.transaction: - return requirement.tan_required + + if seg.header.type in self.force_twostep_tan: + return True + + hipins = self.bpd.find_segment_first(HIPINS1) + if not hipins: + return False + for requirement in hipins.parameter.transaction_tans_required: + if seg.header.type == requirement.transaction: + return requirement.tan_required return False @@ -1414,12 +1499,13 @@ def _send_with_possible_retry(self, dialog, command_seg, resume_func): for resp in response.responses(tan_seg): if resp.code in ('0030', '3955'): + decoupled = any(r.code == '3955' for r in response.responses(tan_seg)) return NeedTANResponse( command_seg, response.find_segment_first('HITAN'), resume_func, self.is_challenge_structured(), - resp.code == '3955', + decoupled, ) if resp.code.startswith('9'): raise Exception("Error response: {!r}".format(response)) @@ -1443,11 +1529,16 @@ def _send_pay_with_possible_retry(self, dialog, command_seg, resume_func): - 'RVNM' - no match, no extra info seen - 'RVNA' - check not available, reason in single_vop_result.na_reason - 'PDNG' - pending, seems related to something not implemented right now. + + VoP polling flow (FinTS spec E.8.3.1): + Some banks return HIVPP with no vop_id but a polling_id and code 3040:aufsetzpunkt. + The client must poll by re-sending HKVPP with polling_id + aufsetzpunkt (without + HKCCS/HKTAN) until the bank returns HIVPP with a vop_id and the actual VoP result. + After that, the client sends HKVPA + HKCCS + HKTAN to authorize. """ vop_seg = [] vop_standard = self._find_vop_format_for_segment(command_seg) if vop_standard: - from .segments.auth import HKVPP1 vop_seg = [HKVPP1(supported_reports=PSRD1(psrd=[vop_standard]))] with dialog: @@ -1460,9 +1551,52 @@ def _send_pay_with_possible_retry(self, dialog, command_seg, resume_func): if vop_standard: hivpp = response.find_segment_first(HIVPP1, throw=True) + # Check if VOP polling is required: HIVPP has no vop_id but has polling_id + if not hivpp.vop_id and hivpp.polling_id: + # Extract aufsetzpunkt from HIRMS 3040 response + aufsetzpunkt = None + for hirms_seg in response.find_segments(HIRMS2): + for resp in hirms_seg.responses: + if resp.code == '3040' and resp.parameters: + aufsetzpunkt = resp.parameters[0] + + wait_seconds = int(hivpp.wait_for_seconds) if hivpp.wait_for_seconds else 2 + logger.info("VoP polling required (polling_id=%r, aufsetzpunkt=%r, wait=%ds)", + hivpp.polling_id, aufsetzpunkt, wait_seconds) + + import time + time.sleep(wait_seconds) + + # Poll: send HKVPP with polling_id + aufsetzpunkt (no HKCCS, no HKTAN) + poll_seg = HKVPP1( + supported_reports=PSRD1(psrd=[vop_standard]), + polling_id=hivpp.polling_id, + aufsetzpunkt=aufsetzpunkt, + ) + poll_response = dialog.send(poll_seg) + hivpp = poll_response.find_segment_first(HIVPP1, throw=True) + logger.info("VoP poll result: vop_id=%r", hivpp.vop_id) + vop_result = hivpp.vop_single_result - # Not Applicable, No Match, Close Match, or exact match but still requires confirmation - if vop_result.result in ('RVNA', 'RVNM', 'RVMC') or (vop_result.result == 'RCVC' and '3945' in [res.code for res in response.responses(tan_seg)]): + # Not Applicable, No Match, Close Match, or exact match but still requires confirmation + tan_codes = [res.code for res in response.responses(tan_seg)] + command_codes = [res.code for res in response.responses(command_seg)] + all_codes = [] + for seg in response.find_segments((HIRMG2, HIRMS2)): + all_codes.extend(r.code for r in seg.responses) + + # If we have a vop_id (from initial or polling), return NeedVOPResponse + # so the caller can inspect the result and then call approve_vop_response + if hivpp.vop_id: + return NeedVOPResponse( + vop_result=hivpp, + command_seg=command_seg, + resume_method=resume_func, + ) + + if vop_result and (vop_result.result in ('RVNA', 'RVNM', 'RVMC') or ( + vop_result.result == 'RCVC' and '3945' in all_codes + )): return NeedVOPResponse( vop_result=hivpp, command_seg=command_seg, @@ -1473,16 +1607,37 @@ def _send_pay_with_possible_retry(self, dialog, command_seg, resume_func): for resp in response.responses(tan_seg): if resp.code in ('0030', '3955'): + # Consorsbank returns 0030 together with 3955 + # ("Sicherheitsfreigabe erfolgt über anderen Kanal") + # for decoupled app approval. Treat the operation as + # decoupled whenever 3955 is present, regardless of the + # order in which the codes appear. + decoupled = any(r.code == '3955' for r in response.responses(tan_seg)) return NeedTANResponse( command_seg, response.find_segment_first('HITAN'), resume_func, self.is_challenge_structured(), - resp.code == '3955', + decoupled, hivpp, ) if resp.code.startswith('9'): raise Exception("Error response: {!r}".format(response)) + + # Some banks (e.g. Consorsbank) attach the 0030 TAN-required + # response to the command segment (HKCCS) rather than the + # HKTAN segment. Check command_seg responses as fallback. + for resp in response.responses(command_seg): + if resp.code in ('0030', '3955'): + decoupled = any(r.code == '3955' for r in response.responses(command_seg)) + return NeedTANResponse( + command_seg, + response.find_segment_first('HITAN'), + resume_func, + self.is_challenge_structured(), + decoupled, + hivpp, + ) else: response = dialog.send(command_seg) @@ -1518,6 +1673,30 @@ def approve_vop_response(self, challenge: NeedVOPResponse): challenge.vop_result, ) + for resp in response.responses(challenge.command_seg): + if resp.code in ('0030', '3955'): + return NeedTANResponse( + challenge.command_seg, + response.find_segment_first('HITAN'), + challenge.resume_method, + self.is_challenge_structured(), + resp.code == '3955', + challenge.vop_result, + ) + + for seg in response.find_segments((HIRMG2, HIRMS2)): + for resp in seg.responses: + if resp.code not in ('0030', '3955'): + continue + return NeedTANResponse( + challenge.command_seg, + response.find_segment_first('HITAN'), + challenge.resume_method, + self.is_challenge_structured(), + resp.code == '3955', + challenge.vop_result, + ) + resume_func = getattr(self, challenge.resume_method) return resume_func(challenge.command_seg, response) @@ -1554,7 +1733,7 @@ def send_tan(self, challenge: NeedTANResponse, tan: str): "No TAN status received." ) for resp in response.responses(tan_seg): - if resp.code == '3956': + if resp.code == '3956' or self._is_decoupled_signature_pending(resp): return NeedTANResponse( challenge.command_seg, challenge.tan_request, @@ -1566,6 +1745,14 @@ def send_tan(self, challenge: NeedTANResponse, tan: str): resume_func = getattr(self, challenge.resume_method) return resume_func(challenge.command_seg, response) + @staticmethod + def _is_decoupled_signature_pending(response): + return ( + response.code == '9010' + and 'Unterschriften' in str(getattr(response, 'text', '')) + and 'nicht ausreichend' in str(getattr(response, 'text', '')) + ) + def _process_response(self, dialog, segment, response): if response.code == '3920' and not self.bank_identifier == ING_BANK_IDENTIFIER: self.allowed_security_functions = list(response.parameters) @@ -1587,7 +1774,7 @@ def _process_response(self, dialog, segment, response): # Fall back to onestep self.set_tan_mechanism('999') - if response.code == '9010': + if response.code == '9010' and not dialog.open: raise FinTSClientError("Error during dialog initialization, could not fetch BPD. Please check that you " "passed the correct bank identifier to the HBCI URL of the correct bank.") diff --git a/fints/dialog.py b/fints/dialog.py index e1f66aa..7466b12 100644 --- a/fints/dialog.py +++ b/fints/dialog.py @@ -85,8 +85,14 @@ def init(self, *extra_segments): retval = self.send(*segments, internal_send=True) if tan_seg: - for resp in retval.responses(tan_seg): - if resp.code in ('0030', '3955'): + # Some banks (e.g. Consorsbank) attach the login-SCA + # 0030/3955 response to the HKIDN segment instead of the + # HKTAN segment, so check both references. + for ref in (tan_seg, segments[0]): + if self.client.init_tan_response is not None: + break + ref_responses = list(retval.responses(ref)) + if any(resp.code in ('0030', '3955') for resp in ref_responses): self.client.init_tan_response = NeedTANResponse( None, retval.find_segment_first('HITAN'), @@ -94,9 +100,12 @@ def init(self, *extra_segments): self.client.is_challenge_structured(), False, ) - if resp.code == '3955': + # 3955 ("Sicherheitsfreigabe erfolgt über anderen + # Kanal") flags decoupled app approval; it may appear + # alongside 0030, so check all responses, not just + # the first matching code. + if any(resp.code == '3955' for resp in ref_responses): self.client.init_tan_response.decoupled = True - break self.need_init = False return retval diff --git a/fints/formals.py b/fints/formals.py index 2d9d907..c07f24a 100644 --- a/fints/formals.py +++ b/fints/formals.py @@ -543,6 +543,12 @@ def from_sepa_account(cls, acc): return cls( iban=acc.iban, bic=acc.bic, + account_number=acc.accountnumber, + subaccount_number=acc.subaccount, + bank_identifier=BankIdentifier( + country_identifier=BankIdentifier.COUNTRY_ALPHA_TO_NUMERIC[acc.bic[4:6]], + bank_code=acc.blz + ) if acc.blz else None, ) @@ -868,6 +874,14 @@ class BatchTransferParameter1(DataElementGroup): single_booking_allowed = DataElementField(type='jn', _d="Einzelbuchung erlaubt") +class ScheduledTransferParameter1(DataElementGroup): + """Parameter terminierte SEPA-Überweisung, version 1 + + Source: FinTS Financial Transaction Services, Schnittstellenspezifikation, Messages -- Multibankfähige Geschäftsvorfälle """ + min_advance_days = DataElementField(type='num', max_length=4, _d="Mindestvorlaufzeit") + max_advance_days = DataElementField(type='num', max_length=4, _d="Maximaler Vorlauf") + + @doc_enum class ServiceType2(RepresentableEnum): T_ONLINE = 1 # doc: T-Online diff --git a/fints/security.py b/fints/security.py index e9f14e1..f65b5a8 100644 --- a/fints/security.py +++ b/fints/security.py @@ -104,8 +104,15 @@ def sign_prepare(self, message: FinTSMessage): _now = datetime.datetime.now() rand = random.SystemRandom() + # Per ZKA FinTS spec, two-step TAN methods (security_function != '999') + # require security_method_version=2 in the SecurityProfile. + if self.security_function and self.security_function != '999': + security_method_version = 2 + else: + security_method_version = 1 + self.pending_signature = HNSHK4( - security_profile=SecurityProfile(SecurityMethod.PIN, 1), + security_profile=SecurityProfile(SecurityMethod.PIN, security_method_version), security_function=self.security_function, security_reference=rand.randint(1000000, 9999999), security_application_area=SecurityApplicationArea.SHM, diff --git a/fints/segments/transfer.py b/fints/segments/transfer.py index 9773b3b..ec25cfb 100644 --- a/fints/segments/transfer.py +++ b/fints/segments/transfer.py @@ -1,5 +1,5 @@ from fints.fields import DataElementField, DataElementGroupField -from fints.formals import KTI1, Amount1, BatchTransferParameter1 +from fints.formals import KTI1, Amount1, BatchTransferParameter1, ScheduledTransferParameter1 from .base import FinTS3Segment, ParameterSegment @@ -12,6 +12,30 @@ class HKCCS1(FinTS3Segment): sepa_descriptor = DataElementField(type='an', max_length=256, _d="SEPA Descriptor") sepa_pain_message = DataElementField(type='bin', _d="SEPA pain message") + +class HKCSE1(FinTS3Segment): + """Terminierte SEPA-Überweisung einreichen, version 1 + + Source: FinTS Financial Transaction Services, Schnittstellenspezifikation, Messages -- Multibankfähige Geschäftsvorfälle """ + account = DataElementGroupField(type=KTI1, _d="Kontoverbindung international") + sepa_descriptor = DataElementField(type='an', max_length=256, _d="SEPA Descriptor") + sepa_pain_message = DataElementField(type='bin', _d="SEPA pain message") + + +class HICSE1(FinTS3Segment): + """Einreichung terminierter SEPA-Überweisung bestätigen, version 1 + + Source: FinTS Financial Transaction Services, Schnittstellenspezifikation, Messages -- Multibankfähige Geschäftsvorfälle """ + order_id = DataElementField(type='an', max_length=99, required=False, _d="Auftragsidentifikation") + + +class HICSES1(ParameterSegment): + """Terminierte SEPA-Überweisung einreichen Parameter, version 1 + + Source: FinTS Financial Transaction Services, Schnittstellenspezifikation, Messages -- Multibankfähige Geschäftsvorfälle """ + parameter = DataElementGroupField(type=ScheduledTransferParameter1, _d="Parameter terminierte SEPA-Überweisung einreichen") + + class HKIPZ1(FinTS3Segment): """SEPA-instant Einzelüberweisung, version 1 diff --git a/sample_consorsbank.py b/sample_consorsbank.py new file mode 100644 index 0000000..2d57ae9 --- /dev/null +++ b/sample_consorsbank.py @@ -0,0 +1,224 @@ +#!/usr/bin/env python3 +""" +Sample: Consorsbank (BLZ 76030080) with python-fints. + +Demonstrates fetching accounts/transactions and making a SEPA transfer with +either of Consorsbank's two current TAN methods. + +TAN methods +----------- +Consorsbank advertises two two-step TAN mechanisms: + +* **901 "Consorsbank/myPrivateBank App"** (``zka_id = "Decoupled"``) — the new + Consorsbank App. Login asks for a *typed* 9-digit TAN generated in the app; + a SEPA transfer is *approved in the app* (decoupled), no TAN is typed. +* **900 "SecurePlus TAN Generator"** (``zka_id = "photoTAN"``) — login needs no + TAN (the bank answers the dialog-init with ``3076``); a SEPA transfer returns + an order-bound **photoTAN QR image** (``response.challenge_matrix``) that is + scanned, after which the resulting TAN is typed. + +Both were exercised end-to-end against Consorsbank. A real SEPA transfer with +mechanism ``901`` was accepted and booked. + +.. note:: + The old **SecurePlus *App*** (the smartphone app, distinct from the + SecurePlus *TAN-generator device*) was shut down for Consorsbank online + banking on **2026-04-25**; since then it returns "TAN-Verfahren ungültig" + and any TAN it produces — including ones scanned from the ``900`` photoTAN + QR — is rejected with ``9941 TAN ungültig``. Use the new **Consorsbank App** + (``901``) or the **physical SecurePlus TAN-generator device** (``900``). + The ``900`` code path here is correct; only the decommissioned app's TAN is + refused by the bank. (Source: kritische-anleger.de SecurePlus-App shutdown + report, and the official Consorsbank HBCI FAQ.) + +Protocol quirks handled by python-fints (see PR #209 and the login-SCA fix) +-------------------------------------------------------------------------- +1. ``security_method_version=2`` for two-step TAN. +2. Full account details in ``KTI1.from_sepa_account``. +3. ``force_twostep_tan`` for segments the bank requires a TAN on despite + reporting otherwise in HIPINS (otherwise: ``9075``). +4. The TAN-required response ``0030`` is attached to the **command segment** + (``HKCCS``) instead of ``HKTAN``. +5. The **login** strong-customer-authentication response ``0030`` is attached + to the **HKIDN** segment of the dialog-init, not ``HKTAN``. Without + detecting it, the next command aborts the dialog with ``9800/9120``. +6. For decoupled app approval, Consorsbank returns ``0030`` **together with** + ``3955`` ("Sicherheitsfreigabe erfolgt über anderen Kanal"). python-fints + now flags the challenge as ``decoupled`` whenever ``3955`` is present. + +What the user sees with the Consorsbank App (mechanism 901) +----------------------------------------------------------- +* **Login**: the bank asks for a *typed* TAN. Open the Consorsbank App, + generate the (9-digit) TAN and type it in. ``response.decoupled`` is False. +* **SEPA transfer**: the bank pushes the order to the app for approval. + ``response.decoupled`` is True; the user approves in the app and the client + polls until the bank confirms — no TAN is typed. + +Usage: + pip install python-fints python-dotenv + python sample_consorsbank.py + +Environment variables (or .env file): + FINTS_BLZ=76030080 + FINTS_USER= + FINTS_PIN= + FINTS_SERVER=https://brokerage-hbci.consorsbank.de/hbci + FINTS_PRODUCT_ID= + FINTS_TAN_MECHANISM=901 # 901 = Consorsbank App, 900 = SecurePlus generator + MY_IBAN= + # To actually send money, set all of these: + TRANSFER_TO_IBAN= + TRANSFER_TO_NAME= + TRANSFER_AMOUNT=1.00 + TRANSFER_REASON=Test transfer +""" + +import os +import time +import logging +from datetime import date, timedelta +from decimal import Decimal + +from fints.client import FinTS3PinTanClient, NeedTANResponse, NeedVOPResponse + +logging.basicConfig(level=logging.WARNING) + +try: + from dotenv import load_dotenv + load_dotenv() +except ImportError: + pass + + +def handle_tan(response, client): + """Resolve TAN / VoP / decoupled challenges. + + * Decoupled (e.g. Consorsbank App): the user approves the order inside the + banking app; we poll with ``send_tan`` until the bank confirms. + * photoTAN / QR: an image is shown to scan, then the TAN is typed. + * Plain: the user types the TAN shown by the app/generator. + """ + while isinstance(response, (NeedTANResponse, NeedVOPResponse)): + if isinstance(response, NeedVOPResponse): + # Verification of Payee result; approve and continue. + response = client.approve_vop_response(response) + continue + + print(f"\nTAN required: {response.challenge}") + + # Decoupled app approval (Consorsbank App): no TAN is typed. + if response.decoupled: + input("Approve the request in your Consorsbank App, then press ENTER... ") + # Poll the bank until the decoupled approval is registered. + response = client.send_tan(response, "") + while isinstance(response, NeedTANResponse) and response.decoupled: + time.sleep(4) + response = client.send_tan(response, "") + continue + + # photoTAN / QR code image (e.g. SecurePlus generator). + if response.challenge_matrix: + mime_type, image_data = response.challenge_matrix + ext = ".png" if "png" in mime_type else ".jpg" + img_path = f"tan_challenge{ext}" + with open(img_path, "wb") as f: + f.write(image_data) + print(f" Challenge image saved to {img_path} ({len(image_data)} bytes)") + tan = input("Scan the image and enter the TAN: ") + else: + # Plain typed TAN (e.g. Consorsbank App login TAN, 9 digits). + tan = input("Enter the TAN from your app/generator: ") + + response = client.send_tan(response, tan) + + return response + + +def main(): + blz = os.environ.get("FINTS_BLZ", "76030080") + user = os.environ["FINTS_USER"] + pin = os.environ["FINTS_PIN"] + server = os.environ.get("FINTS_SERVER", "https://brokerage-hbci.consorsbank.de/hbci") + product_id = os.environ.get("FINTS_PRODUCT_ID") + mechanism = os.environ.get("FINTS_TAN_MECHANISM", "901") + my_iban = os.environ.get("MY_IBAN") + + client = FinTS3PinTanClient( + bank_identifier=blz, + user_id=user, + pin=pin, + server=server, + product_id=product_id, + # Consorsbank reports HKKAZ:N / HKSAL:N in HIPINS but actually requires + # a TAN for them; HKCCS always requires a TAN. + force_twostep_tan={"HKKAZ", "HKSAL"}, + ) + + # 901 = Consorsbank App (current), 900 = physical SecurePlus TAN generator. + if not client.get_current_tan_mechanism(): + client.fetch_tan_mechanisms() + client.set_tan_mechanism(mechanism) + + with client: + # Login strong-customer-authentication (typed TAN with the app). + if client.init_tan_response: + handle_tan(client.init_tan_response, client) + + # --- Fetch accounts --- + accounts = client.get_sepa_accounts() + if isinstance(accounts, NeedTANResponse): + accounts = handle_tan(accounts, client) + + print("Accounts:") + for a in accounts: + print(f" {a.iban} (BIC: {a.bic})") + + if my_iban: + account = next((a for a in accounts if a.iban == my_iban), None) + if not account: + print(f"Account {my_iban} not found") + return + else: + account = accounts[0] + print(f"\nUsing account: {account.iban}") + + # --- Fetch transactions --- + print("\nFetching transactions (last 30 days)...") + start_date = date.today() - timedelta(days=30) + res = client.get_transactions(account, start_date=start_date) + if isinstance(res, (NeedTANResponse, NeedVOPResponse)): + res = handle_tan(res, client) + if res: + print(f"Found {len(res)} transactions; showing last 5:") + for t in res[-5:]: + d = t.data + amt = d.get("amount") + amount_str = f"{amt.amount:>10.2f} {amt.currency}" if amt else "" + print(f" {d.get('date')} {amount_str} {d.get('applicant_name', '')}") + else: + print("No transactions found.") + + # --- SEPA transfer (approved in the Consorsbank App) --- + to_iban = os.environ.get("TRANSFER_TO_IBAN") + if to_iban: + print(f"\nSubmitting SEPA transfer to {to_iban} ...") + res = client.simple_sepa_transfer( + account=account, + iban=to_iban, + bic=os.environ.get("TRANSFER_TO_BIC", ""), + recipient_name=os.environ["TRANSFER_TO_NAME"], + amount=Decimal(os.environ.get("TRANSFER_AMOUNT", "1.00")), + account_name=os.environ.get("TRANSFER_FROM_NAME", user), + reason=os.environ.get("TRANSFER_REASON", "Test transfer"), + ) + # The bank pushes the order to the Consorsbank App for approval. + res = handle_tan(res, client) + print(f"Transfer result: {getattr(res, 'status', None)} {getattr(res, 'responses', None)}") + else: + print("\n(Set TRANSFER_TO_IBAN/TRANSFER_TO_NAME to perform a transfer.)") + + print("\nDone!") + + +if __name__ == "__main__": + main() diff --git a/tests/conftest.py b/tests/conftest.py index d584e8f..7f2016c 100644 --- a/tests/conftest.py +++ b/tests/conftest.py @@ -182,6 +182,20 @@ def make_answer(self, dialog_id, message): datadict['pending'].pop(ref, None) + hkcse = re.search(rb"'HKCSE:(\d+):1.*@\d+@(.*)/Document>'", message) + if hkcse: + segno = hkcse.group(1).decode('us-ascii') + pain = hkcse.group(2).decode('utf-8') + + memomatch = re.search(r"]*>\s*]*>\s*([^<]+)\s*]*>\s*]*>\s*]*>\s*([^<]+)\s*]*>]*>\s*([^<]+)\s*]*>(?:\s*]*>)?\s*([^<]+)\s*(?:)?