Financial Transaction Services (FinTS)

Z E N T R A L E R K R E D I T A U S S C H U S S 

Financial Transaction Services (FinTS) 

- Security - 

Alternative Sicherheitsverfahren 

Wichtiger Hinweis 

Die Sicherheitsverfahren 800, 810, 812, 820 und 821 wurden am 14.12.2011 abgekündigt. 

In Verbindung mit dem Secoder wird nur noch das Verfahren 

„811 - Fortgeschrittene Signatur ohne Institutssignaturen“ unterstützt. 

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: 15.12.2009 

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 Kundenund 

Kreditinstitutssysteme wird interessierten Herstellern unentgeltlich ein einfaches Nutzungsrecht 

eingeräumt. Im Rahmen des genannten Zwecks darf die Schnittstellenspezifikation 

auch - in unveränderter Form - vervielfältigt und zu den nachstehenden Bedingungen 

verbreitet werden. 

Umgestaltungen, Bearbeitungen, Übersetzungen und jegliche Änderung der Schnittstellenspezifikation 

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 Gewährleistung 

oder Haftung für Fehler der Schnittstellenspezifikation oder die ordnungsgemäße 

Funktion der auf ihr beruhenden Produkte übernommen. Die Hersteller sind aufgefordert, 

Fehler oder Auslegungsspielräume der Spezifikation, die die ordnungsgemäße Funktion 

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 vorherige 

Ankündigung möglich sind. 

Eine Weitergabe der Schnittstellenspezifikation durch den Hersteller an Dritte darf nur unentgeltlich, 

in unveränderter Form und zu den vorstehenden Bedingungen erfolgen. 

Dieses Dokument kann im Internet abgerufen werden unter http://www.fints.org.


Dokument: Security - Alternative Sicherheitsverfahren 

Version: 

Kapitel: Versionsführung Stand: 

3.0 

15.12.2009 

Kapitel: 

Seite: 

0 

1 

Versionsführung 

Das vorliegende Dokument wurde von folgenden Personen erstellt bzw. geändert: 

Name Organisatioon 

Datum Versi- 

Anmerkungen 

Haubner für SIZ 17.02.2009 0.1 Initialversion 

Haubner für SIZ 12.05.2009 0.8 Neustrukturierung der Abläufe und Ergänzen der 

Dialoginitialisierung, BPD, Steuerung, … (siehe 

Änderungsliste) 

Haubner für SIZ 20.08.2009 0.9 Einarbeitung der Änderungen aus der Sitzung 

der FinTS-Taskforce am 02.07.2009 

Haubner für SIZ 27.08.2009 0.91 Einarbeiten der Änderungen aus der QS 

Haubner für SIZ 13.10.2009 0.92 Fachlich vollständige Version mit genehmigten 

Änderungen aus der Sitzung des ZKA AK Online-Banking 

am 27.08.2009 

Haubner für SIZ 10.11.2009 0.93 Erstellung final draft mit inzwischen noch eingelieferten 

Befunden. 

Haubner für SIZ 15.12.2009 1.0 Erstellung Final Version

Kapitel: 

Seite: 

0 

2 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Ä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, bezieht 

sich die Kapitelangabe auf die neue Nummerierung. Aufgrund der umfangreichen 

Textumstellungen wurden nicht alle Änderungen markiert. 

lfd. 

Nr. 

1 

Kapitel 

Seitennummer 

Kennung 

Art 2 Beschreibung 

1 

2 

3 

4 

1 

2 

nur zur internen Zuordnung 

F = Fehler; Ä = Änderung; K = Klarstellung; E = Erweiterung



Version: 

Kapitel: Inhaltsverzeichnis Stand: 

3.0 

15.12.2009 

Kapitel: 

Seite: 

0 

3 

Inhaltsverzeichnis 

Versionsführung ........................................................................................... 1 

Änderungen gegenüber der Vorversion ..................................................... 2 

Inhaltsverzeichnis ......................................................................................... 3 

Abbildungsverzeichnis ................................................................................. 5 

Begriffe ......................................................................................................... 7 

Abkürzungen ............................................................................................... 10 

Literaturhinweise ........................................................................................ 12 

A. Einleitung .............................................................................................. 13 

A.1 Visualisierung und Secodervisualisierung ............................................... 14 

A.2 Secoder-Integration in FinTS .................................................................. 14 

A.2.1 Secoder-Applikationen und Verwendungsmöglichkeiten ........... 15 

A.2.2 Secoder-Verwaltung / Abfrage der Secoder-Eigenschaften ....... 15 

A.2.2.1 Einführen einer Metasprache .................................................15 

B. Verfahrensbeschreibung ..................................................................... 17 

B.1 Allgemeines ............................................................................................ 17 

B.2 AZS-Verfahren zur Secoder-Integration .................................................. 18 

B.2.1 AZS-Verfahren und Ein- / Zwei-Schritt-Verfahren ...................... 18 

B.2.2 Abläufe für AZS-Verfahren ........................................................ 22 

B.2.2.1 Sicherheitsverfahren ohne Secoder .......................................23 

B.2.2.2 Sicherheitsverfahren mit Secoder ..........................................28 

B.3 Geschäftsvorfall HKAZS für Ein- / Zwei-Schritt-AZS-Verfahren ............... 56 

B.3.1 Aufbau des Geschäftsvorfalls HKAZS ....................................... 56 

B.4 Erweiterung der Rückmeldungscodes ..................................................... 60 

B.4.1 

Beschreibung spezieller Rückmeldungen im Zwei-Schritt- 

Verfahren .................................................................................. 61 

B.5 Erweiterung der Bank- und Userparameterdaten (BPD / UPD) ............... 63 

B.5.1 Secoder-spezifische Visualisierungsinformationen (HIVISS) ..... 64 

B.5.1.1 Generelles Secoder-Visualisierungskonzept mit HIVISS .......64 

B.5.1.2 

Struktur des Parametersegmentes HIVISS............................73 

B.5.1.3 Tabelle der Secodervisualisierungstexte ...............................74 

B.5.1.4 

Geschäftsvorfallspezifische 

Visualisierungsinformationen für Secoder ..............................77 

B.5.1.5 Positionierung bei der Secodervisualisierung ........................79 

B.5.1.6 Parametersegment HIVISS ....................................................84

Kapitel: 

0 

Version: 

3.0 



Seite: 

4 

Stand: 

15.12.2009 

Kapitel: 

Inhaltsverzeichnis 

B.5.2 

Spezielle Festlegungen für die Dialoginitialisierung beim 

AZS-Verfahren .......................................................................... 85 

C. Dialogspezifikation für AZS-Verfahren ............................................... 87 

C.1 Allgemeines ............................................................................................ 87 

C.1.1 Verschlüsselung des Dialoges .................................................. 87 

C.1.2 Institutssignaturen bei AZS-Verfahren ....................................... 88 

C.1.3 Key-Management bei AZS-Verfahren ........................................ 88 

C.1.4 Behandlung der Dialogendenachricht (HKEND) ........................ 88 

C.2 Besondere Belegungsrichtlinien für AZS-Verfahren ................................ 88 

C.2.1 

Segment Sicherheitsverfahren, DEG Unterstützte 

Sicherheitsverfahren ................................................................. 89 

C.2.2 DEG „Sicherheitsprofil“ .............................................................. 89 

C.2.3 DEG „Schlüsselname“ ............................................................... 89 

C.2.4 DEG „Sicherheitsidentifikation, Details“ ..................................... 90 

C.2.5 Segment „Signaturkopf“ ............................................................ 90 

C.2.6 DEG „Hashalgorithmus“ ............................................................ 90 

C.2.7 DEG „Signaturalgorithmus“ ....................................................... 90 

C.2.8 Segment „Signaturabschluss“ ................................................... 90 

C.2.9 Segment „Verschlüsselungskopf“ .............................................. 90 

C.2.10 DEG „Verschlüsselungsalgorithmus“ ......................................... 91 

C.2.11 Segment „Verschlüsselte Daten“ ............................................... 91 

C.3 Nachrichtenaufbau für AZS-Verfahren .................................................... 92 

C.3.1 Kundennachricht bei der Dialoginitialisierung ............................ 92 

C.3.1.1 Nachrichtenformat ..................................................................93 

C.3.2 Kreditinstitutsnachricht bei der Dialoginitialisierung ................... 94 

C.3.2.1 Nachrichtenformat ..................................................................95 

C.3.3 Kundenauftragsnachricht .......................................................... 96 

C.3.4 Kreditinstitutsauftragsnachricht ................................................. 97 

C.3.5 Kundennachricht bei Mehrfachsignaturen ................................. 98 

D. Secoder-Management ........................................................................ 100 

D.1 Übermitteln / Anzeigen von Secoder-Informationen .............................. 100 

E. Data-Dictionary ................................................................................... 103 

F. Anlagen ............................................................................................... 122 

F.1 Übersicht der Segmente ....................................................................... 122 

F.2 Übersicht Nachrichtenaufbau ................................................................ 122



Version: 

Kapitel: Abbildungsverzeichnis Stand: 

Abbildungsverzeichnis 

3.0 

15.12.2009 

Kapitel: 

Seite: 

0 

5 

Abbildung 1: Mögliche logische Architekturen zur Integration des Secoders 

über eine Metadatenschnittstelle ............................................................... 16 

Abbildung 2: Legende für die Prozessdarstellungen ............................................... 23 

Abbildung 3: Dialoginitialisierung bei qualifizierter Signatur ohne Secoder, 

S-Fkt=800 ................................................................................................. 24 

Abbildung 4: Qualifizierte Signatur ohne Secoder – Phase Antrag und Angebot, 

S-Fkt=800 ................................................................................................. 26 

Abbildung 5: Qualifizierte Signatur ohne Secoder – Phase Angebot und Auftrag, 

S-Fkt=800 ................................................................................................. 27 

Abbildung 6: Dialoginitialisierung beim Zwei-Schritt-AZS-Verfahren mit Secoder, 

S-Fkt=810 (1 von 2) .................................................................................. 30 


S-Fkt=810 (2 von 2) .................................................................................. 30 

Abbildung 8: Qualifizierte Signatur mit Secoder, S-Fkt=810 (1 von 3) .................... 33 

Abbildung 9: Qualifizierte Signatur mit Secoder, S-Fkt=810 (2 von 3) .................... 33 

Abbildung 10: Qualifizierte Signatur mit Secoder, S-Fkt=810 (3 von 3) .................. 34 

Abbildung 11: Dialoginitialisierung beim AZS-Verfahren S-Fkt=811 (1 von 2) ......... 36 


Abbildung 13: Fortgeschrittene Signatur mit Secoder, S-Fkt=811 ........................... 39 



Abbildung 16: Auftragseinreichung beim AZS-Verfahren, S-Fkt=812 ...................... 45 

Abbildung 17: Szenario EMV-AC – Ablauf und Belegung der Segmente bei 

Verwendung der Online-Banking-PIN, S-Fkt=820 ..................................... 49 

Abbildung 18: Dialoginitialisierung EMV-AC-Verfahren mit Online-Banking-PIN, 

S-Fkt=820 ................................................................................................. 50 

Abbildung 19: Ablauf und Belegung der Segmente bei Verwendung der Offline- 

Benutzer-PIN, S-Fkt=821 .......................................................................... 52 

Abbildung 20: Dialoginitialisierung EMV-AC-Verfahren mit Offline-Benutzer-PIN, 

S- Fkt=821 ................................................................................................ 52 

Abbildung 21: EMV-AC-Kryptogramm mit Secoder, S-Fkt=820 und 821 ................. 54

Kapitel: 

Seite: 

0 

6 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abbildungsverzeichnis 

Abbildung 22: Struktur der geschäftsvorfallspezifischen 

Visualisierungsinformationen .................................................................... 65 

Abbildung 23: Zusammenhang zwischen Secoder MetaData und 

Secodervisualisierungstexten .................................................................... 67 

Abbildung 24: Aufbau des Parametersegmentes HIVISS........................................ 73 

Abbildung 25: Tabelle der Secodervisualisierungstexte und Secoder MetaData 

in HIVISS .................................................................................................. 74 

Abbildung 26: Analogien zwischen MetaData und Secoder Data Confirmation ....... 77 

Abbildung 27: Definition der Secoder MetaData pro Geschäftsvorfall ..................... 78 

Abbildung 28: Adressierung der Secodervisualisierungsdaten bei FinTS- 

Formaten .................................................................................................. 80 

Abbildung 29: Adressierung der Secodervisualisierungsdaten bei DTA- 

Formaten .................................................................................................. 81 

Abbildung 30: Adressierung der Secodervisualisierungsdaten bei DTAZV- 

Formaten .................................................................................................. 82 

Abbildung 31: Adressierung der Secodervisualisierungsdaten bei SEPA- 

Formaten .................................................................................................. 83 

Abbildung 32: Segmentaufbau der Dialoginitialisierungsnachricht (Kunde) bei 

AZS-Verfahren .......................................................................................... 92 

Abbildung 33: Segmentaufbau der Dialoginitialisierungsnachricht (Kreditinstitut) 

bei AZS-Verfahren .................................................................................... 94 

Abbildung 34: Segmentaufbau der Auftragsnachricht (Kunde) bei AZS- 

Verfahren .................................................................................................. 96 

Abbildung 35: Segmentaufbau der Auftragsnachricht (Kreditinstitut) bei AZS- 

Verfahren .................................................................................................. 97 

Abbildung 36: Kundennachricht bei Mehrfachsignaturen ........................................ 98 

Abbildung 37: Reihenfolge der Sicherheitssegmente bei Mehrfachsignaturen ........ 99



Version: 

Kapitel: Begriffe Stand: 

Begriffe 

3.0 

15.12.2009 

Kapitel: 

Seite: 

0 

7 

Abkürzung 

Anzeigedefinition 

AZS- 

Verfahren 

FinTS- 

Instanz 

FinTS- 

Füllwert 

MetaData 

Bedeutung 

=HIVISS Anzeigedefinition: Eine Beschreibung von Index, Secoder-Text 

und Secoder MetaData für eine Displayzeile im 

Rahmen eines Secodervisualisierungstextes. 

Unter AZS-Verfahren (Alternative ZKA-Sicherheitsverfahren) 

werden alle Sicherheitsverfahren verstanden, deren Visualisierungsinformationen 

und Signaturen mit Hilfe des Geschäftsvorfalls 

HKAZS transportiert werden. Beispiele hierfür sind qualifizierte 

elektronische Signaturen auf Basis von Signaturanwendungskomponenten 

und Secoder-Signaturen 

Komponente z. B. einer Finanzmanagementsoftware, die für die 

Abwicklung des FinTS-Protokolls zuständig ist. 

Als FinTS-Füllwert wird eine Belegung des entsprechenden Datenelementes 

betrachtet, welche den getroffenen Festlegungen 

(Formatvorgaben, Restriktionen, Belegungshinweisen) 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 werden. Auch hier gilt, dass Vorhandensein und 

Inhalt kreditinstitutsseitig nicht geprüft werden. 

(Secoder-) MetaData oder Metadaten werden als Eingangsschnittstelle 

zur Secoder-Anwendungsfunktion im Kundensystem 

benutzt. Sie entsprechen fachlich den Parameterstrukturen 

DSx, wie sie in den Data Confirmations des Secoders definiert 

sind. 

In FinTS werden die Metadaten im Rahmen des DE Secodervisualisierungstexte 

im BPD-Segment HIVISS abgebildet. 

Die Metadaten werden von der Secoder-Anwendungsfunktion 

verwendet und in ein logisches Secoder-Protokoll eingebettet, 

das physisch wiederum über PC/SC abgewickelt wird. 

Durch den Einsatz dieser Metadaten muss die Online-Banking- 

Applikation selbst kein Wissen bzgl. Protokoll und konkreter Datenschnittstelle 

zum Secoder besitzen.

Kapitel: 

Seite: 

0 

8 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Begriffe 

Online- 

Banking- 

Applikation 

SAK, 

SAKCmds 

SAK-Sig 

SAK-AuthSig 

SAK-InstSig 

Secoder 

Secoder- 

Anwendungsfunktion 

Bei der Online-Banking-Applikation kann es sich um eine FinTS 

Finanzmanagementsoftware oder eine browserbasierte Komponente 

(Java-Applet / -Servlet, PlugIn, …) handeln. Die Online-Banking-Applikation 

kommuniziert mit der Secoder- 

Anwendungsfunktion auf Basis von Metadaten. 

Eine SAK oder Signaturanwendungskomponente ist ein durch 

das BSI bestätigtes Programm zur Erstellung und Verifizierung 

qualifizierter elektronischer Signaturen. SAKCmds sind Befehle, 

welche an einer Schnittstelle zur Übergabe z. B. von zu signierenden 

Daten zur Verfügung stehen. 

Auftragssignatur (ggf. inkl. Zertifikat), die durch die Signaturanwendungskomponente 

(SAK) ohne Verwendung einer Secodervisualisierung 

mit Hilfe des Signaturschlüssels erzeugt wurde. 

Authentikationssignatur (ggf. inkl. Zertifikat), die durch die Signaturanwendungskomponente 

(SAK) ohne Verwendung einer 

Secodervisualisierung mit Hilfe des Signierschlüssels erzeugt 

wurde. 

Fortgeschrittene Institutssignatur (ggf. inkl. Zertifikat), die durch 

die Signaturanwendungskomponente (SAK) ohne Verwendung 

einer Secodervisualisierung geprüft werden kann. Bei Verfügbarkeit 

eines Institutszertifikats kann dieses vom Kunden mit 

Hilfe der SAK z. B. durch eine Online-Abfrage (OCSP) oder gegen 

Sperrlisten geprüft werden. 

Unter Secoder wird eine neue Generation von ZKA Chipkartenlesern 

verstanden, bei denen die Möglichkeit besteht, in einem 

so genannten Applikationsmodus Transaktionsdaten auf sichere 

Weise im Display anzuzeigen und mit Hilfe einer Bankensignaturkarte 

zu signieren. Zur Signaturbildung kann entweder die 

Signatur-Anwendung oder die EMV-AC-Applikation (EMV Application 

Cryptogram, Basis für TAN-Generierung) auf der Karte 

verwendet werden. Der Secoder wird in zwei Schritten am 

Markt eingeführt. Der Secoder I enthält die Applikationen EMV- 

AC und GeldKarte, Secoder enthält auch die Signatur- 

Applikation. Im Rahmen der vorliegenden Spezifikation wird 

Secoder als Basis vorausgesetzt und durchgängig als „Secoder“ 

bezeichnet. 

Anwendungsfunktion, welche auf Basis übergebener Metadaten 

einen über PC/SC angeschlossenen Secoder Protokoll-und datenmäßig 

bedienen kann. Die Secoder-Anwendungsfunktion 

kann eine Komponente einer Finanzmanagementsoftware bzw. 

im Browserkontext ein Java Applet oder PlugIn sein. Teile der 

Secoder-Anwendungsfunktion können sich auch auf einem 

Web-oder Application-Server befinden.



Version: 

Kapitel: Begriffe Stand: 

3.0 

15.12.2009 

Kapitel: 

Seite: 

0 

9 

Secoder- 

Kryptogramm 

Oberbegriff über EMV AC Kryptogramme und Secoder- 

Signaturen. In beiden Fällen fließen in die Secoder- 

Kryptogrammbildung die durch den Kunden bestätigten Daten 

(VisData) 

ein. 

Secoderspezifische 

Kommandos 

(SecCmds) 

VisAuthSig 

VisData 

VisDataSig 

Diese Secoder-spezifischen Kommandos werden an der 

Schnittstelle zwischen Secoder-Anwendungsfunktion und dem 

Secoder selbst über PC/SC ausgetauscht. Beispiele hierfür sind 

„Select Application“ oder „Data Confirmation“. 

Visualisierungsauthentikationssignatur (auch VisAuth-Signatur) 

des Secoders. Diese Signatur dient zum Nachweis gegenüber 

dem Kreditinstitut, dass – falls ein Secoder am Kundenendgerät 

angeschlossen war – dieser sich zum Zeitpunkt der VisData- 

Signatur im Applikationsmodus befunden hat. 

Analog der Secoder-Spezifikation wird hierunter der Aufbau der 

zu signierenden Daten im Secoder, d. h. zwischen Lesereinheit 

und Chipkarte verstanden. 

(auch VisData-Signatur)Signatur über den VisData-Bereich des 

Secoders.

Kapitel: 

Seite: 

0 

10 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abkürzungen 

Abkürzungen 

Abkürzung 

AZS 

ATC 

AUT-SIG 

BPD 

C 

CR 

DDV 

DE 

DEG 

DES 

DS 

EF 

EMV-AC 

EU 

GD 

GDG 

HBCI 

I 

ID 

ISO 

LF 

M 

MAC 

N 

N 

O 

OBanking-PIN 

PIN 

QES 

RDH 

RFC 

RSA 

SAK 

Bedeutung 

Alternative ZKA-Sicherheitsverfahren 

Application Transaction Counter 

Authentikations-Signatur 

Bankparameterdaten 

Datenstruktur ist konditional 

Carriage-Return (Wagenrücklauf) 

DES-DES-Verfahren 

Datenelement 

Datenelementgruppe 

Data Encryption Standard 

Digitale Signatur (z. B. Schlüsselart) 

Elementary File 

Europay-Mastercard-Visa Application Cryptogram 

Elektronische Unterschrift; basiert auf dem asymmetrischen RSA- 

Verfahren 

Gruppendatenelement 

Gruppendatenelementgruppe 

Homebanking Computer Interface 

Information (z.B. Schlüsselart) 

Identifikationsmerkmal (Nummer oder alphanumerischer Code) 

International Organisation for Standardisation 

Line-Feed (neue Zeile) 

Datenstruktur muss vorhanden sein und ist inhaltlich korrekt zu füllen 

Message Authentication Code; Symmetrisches Verfahren zur Erzeugung 

einer elektronischen Signatur (derzeit für die ZKA-Chipkarte eingesetzt) 

Nachricht 

Nicht erlaubt (not allowed) (Datenstruktur darf nicht vorhanden sein) 

Datenstruktur ist optional 

Online-Banking-PIN 

Private Identifikationsnummer 

Qualifizierte Elektronische Signatur(en) 

RSA-DES-Hybridverfahren 

Request for Comment 

Asymmetrischer Algorithmus für die elektronische Unterschrift (EU) 

(vgl. MAC), benannt nach den Erfindern Rivest, Shamir und Adleman. 

Signaturanwendungskomponente



Version: 

Kapitel: Abkürzungen Stand: 

3.0 

15.12.2009 

Kapitel: 

Seite: 

0 

11 

Abkürzung 

Bedeutung 

SAKCmds 

SAK-spezifische Kommandos 

SAK-Sig Signaturdaten – Auftragssignatur der SAK ohne Secoder- 

Visualisierung 

SecCmds 

SEG 

SEQ 

SF 

S-Fkt(. bzw. =) 

SSL 

TAN 

UPD 

VisAuthSig 

VisDataSig 

ZKA 

Secoder-spezifische Kommandos 

Segment 

Sequenznummer 

Segmentfolge 

Sicherheitsfunktion, kodiert (DE aus dem HBCI Signaturkopf) 

Secure Socket Layer 

Transaktionsnummer 

Userparameterdaten 

Visualisierungsbestätigungssignatur des Secoders 

Signaturdaten – Auftragssignatur des Secoders 

Zentraler Kreditausschuss

Kapitel: 

Seite: 

0 

12 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Literaturhinweise 

Literaturhinweise 

[Formals] 

[HBCI] 

[HHD] 

Financial Transaction Services (FinTS) – Formals (Allgemeine 

Festlegungen für multibankfähige Online-Verfahren der deutschen 

Kreditwirtschaft), Version 3.0, 15.11.2002, Zentraler Kreditausschuss 

Financial Transaction Services (FinTS) – Security (Sicherheitsverfahren 

HBCI), Version 3.0, 21.06.2005, Zentraler Kreditausschuss 

Schnittstellenspezifikation für die ZKA Chipkarte – HandHeld- 

Device (HHD) zur TAN-Erzeugung, Version 1.3.2, 02.02.2009, 

Zentraler Kreditausschuss 

[HHD-Erweiterung] HHD-Erweiterung für unidirektionale Kopplung, Version 1.0.1, 

Final Version, 02.02.2009, Zentraler Kreditausschuss 

[HHD-Belegung] ZKA TAN-Generator – Belegungsrichtlinien zur Dynamisierung der 

TAN, Version 1.3, Final Version, 15.01.2008, Zentraler Kreditausschuss 

[Messages] 

[PINTAN] 

[Secoder] 

[BP DigSig] 

[BP DataConf] 

Financial Transaction Services (FinTS) – Messages (Multibankfähige 

Geschäftsvorfälle), Version 3.0, 15.11.2002, Zentraler Kreditausschuss 

Financial Transaction Services (FinTS) – Security (Sicherheitsverfahren 

PIN/TAN), Version 3.0, 15.11.2002, Zentraler Kreditausschuss 

Secoder – Connected Mode Reader Applications, Version 2.0 Final 

Version, 08.06.2009, Zentraler Kreditausschuss 

Secoder – Best Practice Digital Signature, Version 0.2 Entwurf, 

13.02.2009, Zentraler Kreditausschuss 

Secoder – Best Practice Data Confirmation, Version 0.2 Entwurf, 

16.08.2007, Zentraler Kreditausschuss



Version: 

Kapitel: Einleitung Stand: 

3.0 

15.12.2009 

Kapitel: 

Seite: 

A 

13 

A. EINLEITUNG 

In dieser Spezifikation wird ein multibankfähiges FinTS-Protokoll für die Integration 

alternativer ZKA Sicherheitsverfahren (im Folgenden als „AZS-Verfahren“ bezeichnet) 

beschrieben. Darunter werden Verfahren verstanden, deren Sicherungsinformationen 

wie z. B. Signaturen nicht ausschließlich im FinTS-Signaturkopf bzw. – 

Abschluss übertragen werden, sondern über einen speziellen, neuen Geschäftsvorfall 

„HKAZS“ ergänzt werden. Grund dafür ist, dass bei diesen Verfahren zusätzliche 

Informationen wie z. B. Visualisierungsdaten übertragen werden müssen. Im Speziellen 

handelt es sich hierbei um die Einbindung des Secoders (Begriffsdefinition 

siehe Kapitel “Begriffe“) in den verschiedenen Ausprägungen und Einsatzszenarien. 

Unabhängig von der Verwendung eines Secoders dienen AZS-Verfahren aber auch 

dazu, qualifizierte elektronische Signaturen, die mit Hilfe einer Signaturanwendungskomponente 

gebildet wurden, sowie die zugehörigen Visualisierungsdaten zu 

übertragen. 

AZS-Verfahren verhalten sich vom Protokoll her wie normale FinTS-Transaktionen 

im Ein- oder Zwei-Schritt-Verfahren. Informationen bzgl. Nachrichtenaufbau und 

Dialogablauf sind dem Dokument [Formals] zu entnehmen. 

Um ein möglichst hohes Maß an Synergie nutzen zu können, wird für die Kommunikation 

zwischen Kundenprogramm und Kreditinstitut weitestgehend auf der FinTS- 

Spezifikation V3.0 (Sicherheitsverfahren HBCI bzw. PIN/TAN) [HBCI], [PIN/TAN] 

aufgesetzt, insbesondere bzgl. Syntax, Datenformaten und Abläufen. Sofern nicht 

anders vermerkt gelten für den Nachrichtenaufbau, Dialogablauf etc. die dort getroffenen 

Regelungen. Das vorliegende Dokument beschreibt daher nur die für AZS- 

Verfahren abweichenden Festlegungen. 

Bei AZS-Verfahren werden die bestehenden FinTS-Sicherheitsverfahren ersetzt; 

daher enthalten die FinTS-Signaturen nur geeignete FinTS-Füllwerte. 

Ob ein Kreditinstitut AZS-Verfahren anbietet, erkennt das Kundenprodukt in den 

Bankparameterdaten am Vorhandensein des Geschäftsvorfallparametersegments 

HIAZSS („Parameter Alternative ZKA Sicherheitsverfahren“, vgl. Kapitel B.5). 

Grundsätzlich können mit AZS-Verfahren alle im Dokument [Messages] aufgeführten 

Geschäftsvorfälle verwendet werden. Dies gilt auch für verbandsindividuelle Erweiterungen. 

Welche Geschäftsvorfälle konkret mit welchem AZS-Verfahren zulässig 

sind, teilt das Kreditinstitut im Segment HIAZSS (s. Kap. B.5) mit. 

Als Verschlüsselungsverfahren wird je nach Sicherheitsfunktion entweder HBCI- 

Verschlüsselung oder https (SSL) auf Transportebene verwendet. 

AZS-Verfahren treten in zwei unterschiedlichen Ausprägungen auf, die sich vom 

Prozessablauf her unterscheiden: 

Ein-Schritt-Verfahren 

Beim Ein-Schritt-Verfahren wird der Geschäftsvorfall in einem Prozess-Schritt zusammen 

mit allen benötigten Signaturinformationen eingereicht, d. h. in einem Dialogschritt 

bestehend aus Auftrag und Antwort wird ein Geschäftsvorfall komplett abgewickelt. 

Diese Verfahrensweise entspricht dem Vorgehen beim Sicherheitsverfahren HBCI 

und war bis zur Einführung des Zwei-Schritt-Verfahrens für PIN/TAN die einzige 

Möglichkeit, Aufträge über das FinTS-Protokoll einzureichen.

Kapitel: 

Seite: 

A 

14 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Einleitung 

Durch die neu eingeführten Secoder Metadaten (vgl. Abschnitt „Begriffe“), die über 

die Parameter-Segmente HIAZSS und HIVISS abgebildet werden, können die Secoder-Verfahren 

für fortgeschrittene Signaturen und EMV Applikationskryptogramme 

ebenfalls das Ein-Schritt-Verfahren einsetzen. 

Zwei-Schritt-Verfahren 

Beim Zwei-Schritt-Verfahren werden die Auftragseinreichung und die Signatur- 

Übermittlung in zwei Teilschritte zerlegt. Dadurch hat das Kreditinstitut die Möglichkeit, 

als Antwort auf die erste Nachricht Visualisierungsdaten festzulegen, welche 

auf Kundenseite die Basis für die Bildung z. B. einer Secoder-Signatur darstellen. 

Auf Basis einer Auftragsreferenz wird eine logische Bindung der Signatur an den 

Auftrag erreicht. Das Zwei-Schritt-Verfahren wird bei der Verwendung von qualifizierten 

elektronischen Signaturen mit oder ohne Secoder eingesetzt. 

A.1 Visualisierung und Secodervisualisierung 

Bereits durch die Integration von Zwei-Schritt-TAN-Verfahren wie dem chipTANoder 

mobileTAN-Verfahren wurden Teile des Auftrags als Challenge visualisiert und 

durch den Kunden bestätigt. Bei AZS-Verfahren wird dieser Ansatz weiter verfeinert, 

da hier ggf. größere Datenmengen zu visualisieren sind. Beim Secoder können bei 

maximaler Puffergröße z. B. bis zu 9 Elemente im Display durchgeblättert und bestätigt 

werden (Secodervisualisierung), bei der Verwendung von Signaturanwendungskomponenten 

wird der gesamte Auftrag in einem geeigneten Format wie 

ASCII, TIFF oder PDF angezeigt und mit einer qualifizierten elektronischen Signatur 

versehen. 

Bei Einzelaufträgen ist die Secodervisualisierung auf einfache Art zu bewerkstelligen. 

Angelehnt an die Belegungsrichtlinien von HHD V1.3 können Daten aus dem 

Auftrag in geeigneter Weise angezeigt und bestätigt werden. Der Secoder erlaubt 

mit seinen Techniken hierfür noch weitreichendere Möglichkeiten als das HHD. 

Bei Sammelaufträgen müssen Konstrukte geschaffen werden, deren Secodervisualisierung 

und Bestätigung dem Kunden einerseits noch zumutbar sind und ein vertretbares 

Sicherheitsniveau garantieren. Solche Lösungen können jedoch immer nur 

einen Kompromiss darstellen. 

Als Möglichkeiten der Auswahl der Secodervisualisierungsdaten bei solch großen 

Datenmengen kommen im Wesentlichen Summenwerte über verschiedene Daten 

wie Anzahl der Sätze oder Beträge in Frage. Auch die Signatur von Hashwerten und 

Vergleich mit einem zur Verfügung gestellten „Hashwert-Tool“ ist Praxis. Generell ist 

die Thematik nicht neu und im Firmenkundengeschäft generell zu betrachten. 

Die gesamte Themenstellung ist jedoch nicht Inhalt dieser Spezifikation, sondern ist 

Betreiber-spezifisch zu lösen. Die Möglichkeiten hierfür sind durch die Verwendung 

der Metadaten in der BPD gegeben. 

A.2 Secoder-Integration in FinTS 

Über den Secoder werden neue Funktionalitäten in das FinTS-Protokoll integriert 

wie z. B. die Visualisierung eines Teils der Transaktionsdaten und das daraus resultierende 

Secoder-Kryptogramm. Die Secoder-Integration hat aber auch inhaltliche 

Auswirkungen, wie in den folgenden Abschnitten dargestellt ist.



Version: 

Kapitel: Einleitung Stand: 

3.0 

15.12.2009 

Kapitel: 

Seite: 

A 

15 

Inhalt der Spezifikation der AZS-Verfahren ist außer den Secoder-Varianten auch 

die Verwendung qualifizierter Signaturen mit Hilfe von Signaturanwendungskomponenten. 

A.2.1 Secoder-Applikationen und Verwendungsmöglichkeiten 

In FinTS werden die folgenden Secoder-Applikationen unterstützt: 

„sig“ Signaturapplikation unter Verwendung des DS-Schlüssels 

„aut“ Signaturapplikation unter Verwendung des AUT-Schlüssels 

„tan“ Verwendung des „EMV Application Cryptogram“ (EMV AC) 

Die Signaturbildung im Transparentmodus „def“ des Secoders ist nicht vorgesehen. 

Ferner wird in den Prozessabläufen davon ausgegangen, dass bei der Signaturbildung 

sowohl die Auftragsdaten (in Form eines übergebenen Hashwerts über die 

Auftragsdaten) kombiniert mit den Secoder-Visualisierungsdaten signiert werden als 

auch eine Visualisierungsauthentikationssignatur gebildet wird, durch das FinTS- 

Protokoll also zwei Signaturen zu übertragen sind. Dies wird durch zwei Secoder- 

Aufrufe der Applikationen sig/aut bzw. aut/aut erreicht. 

Bei der Verwendung der Applikation „tan“ wird nur das aus den Visualisierungsdaten 

resultierende EMV Application Cryptogram erzeugt und übertragen. Das Verhalten 

des Secoders entspricht näherungsweise dem eines „angeschlossenen TAN- 

Generators (HHD)“. 

A.2.2 Secoder-Verwaltung / Abfrage der Secoder-Eigenschaften 

Grundsätzlich muss ein Kreditinstitut die physischen Eigenschaften des vom Kunden 

genutzten Secoders nicht kennen. Durch die Einführung einer Metasprache 

(siehe nächster Abschnitt) erfolgt eine logische Entkopplung der fachlichen von den 

physischen Eigenschaften. Durch die Angabe im DE „Sicherheitsfunktion, kodiert“ 

gibt das Kreditinstitut zwar die unterstützten Varianten von AZS-Verfahren vor, es 

werden dort aber keine physischen Eigenschaften des Secoders vorgegeben. Die 

Secoder-Anwendungsfunktion ist dafür verantwortlich, aus den übergebenen Metadaten 

passende SecCmds für den Secoder-Aufruf zu erzeugen. 

Trotzdem kann es für ein Kreditinstitut aus organisatorischen Gründen wichtig sein, 

die physischen Eigenschaften des verwendeten Secoders zu kennen. Um einen 

Überblick über die wichtigsten Secoder-Eigenschaften (z. B. Displaygröße = 2x16 

oder 4x16) oder im Speziellen die eindeutige Reader-Id des Secoders zu erfahren 

wurde ein neuer Geschäftsvorfall (vgl. Abschnitt D.1 „Übermitteln / Anzeigen von 

Secoder-Informationen“) eingeführt, mit dem diese Daten zwischen Secoder- 

Anwendungsfunktion / FinTS-Instanz und Kreditinstitut ausgetauscht werden können. 

A.2.2.1 Einführen einer Metasprache 

Da es aus vielerlei Gründen nicht erwünscht ist, dass Online-Banking-Applikationen 

direkt Secoder-spezifische Kommandos aufbauen und übertragen, bietet sich die 

Schaffung einer Metasprache (vgl. Definiton „MetaData“ in Abschnitt “Begriffe“) an, 

die auf hohem Abstraktionsgrad all die Möglichkeiten abbildet, die ein Secoder darstellen 

kann. Hierzu gehört beispielsweise auch die Information, ob ein Element nur 

bestätigt oder vom Kunden eingetippt werden soll. Die MetaData entsprechen daher 

inhaltlich in etwa den Datensätzen DSx im Input von DATA CONFIRMATION.

Applikationssystem 

Kapitel: 

Seite: 

A 

16 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Einleitung 

Die Metasprache kapselt auch die beiden Secoder-Anwendungsaufrufe sig/aut bzw. 

aut/aut zur Signaturbildung. 

Die von der Online-Banking-Applikation erzeugten MetaData müssen von einer geeigneten 

Secoder-Anwendungsfunktion in die Secoder-spezifischen Kommandos 

umgesetzt werden. Dies kann zum einen ein Bestandteil eines FinTS- 

Kundenproduktes sein, im Bereich Internet-Banking z. B. aber auch eine Webserver-Applikation 

mit einem PlugIn oder Applet auf dem Kunden-PC (für die Ansteuerung 

des Secoders wird in jedem Fall eine aktive Komponente auf dem Kunden-PC 

benötigt). 

Secoderspezif. 

CMDs 

Secoder 

Meta 

Data 

Chip 

Card 

Support 

Secoder 

Meta 

Data 

Converter 

html 

Secoder 

Meta 

Data 

Webserver 

Chip 

Card 

Support 

FinTS 

Kundenprodukt 

Secoder 

Meta 

Data 

Converter 

html 

Secoderspezif. 

CMDs 


Secoder 

Meta 

Data 

Webserver 

Secoder 

Meta 

Data 

Converter 


Instanz 

Abbildung 1: Mögliche logische Architekturen zur Integration des Secoders 

über eine Metadatenschnittstelle



Kapitel: 

Abschnitt: 

Verfahrensbeschreibung 

Allgemeines 

Version: 

Stand: 

15.12.2009 

3.0 

Kapitel: 

Seite: 

17 

B 

B. VERFAHRENSBESCHREIBUNG 

B.1 Allgemeines 

Es gelten die in [Formals], [HBCI] und im übertragenen Sinn die in [Belegung] aufgeführten 

Formate und Belegungsrichtlinien. 

Ergänzend bzw. abweichend hierzu gilt: 

 

 

Beim Einsatz von AZS-Verfahren kommt der neue Geschäftsvorfall HKAZS für 

die Abwicklung und die Parametersegmente HIAZSS und HIVISS für die Festlegungen 

hinzu. In den neuen BPD-Segmenten sind die spezifischen Informationen 

des Kreditinstituts für den Einsatz der unterstützten AZS-Verfahren bis hin 

zu einer elementweisen Definition der zu visualisierenden Daten enthalten. 

Der für den Kunden zugelassene Geschäftsvorfall HKAZS ist im Segment 

HIUPD mitzuteilen. 

Für den Einsatz von AZS-Verfahren gelten zusätzlich die folgenden allgemeinen 

Festlegungen: 

1 bis 99 unterschiedliche AZS-Verfahren pro Institut 1 

1 bis 9 unterschiedliche AZS-Verfahren pro Benutzer 

 

 

Zur eindeutigen Bezeichnung von AZS-Verfahren wird das Element „Sicherheitsfunktion, 

kodiert“ um den zusätzlichen Nummernkreis 800 bis 899 erweitert. 

Auch die Verknüpfung von Code und Verfahren ist Teil dieser Spezifikation und 

wird in der BPD festgelegt. 

Mit dem Rückmeldungscode 3921 und Rückmeldeparametern werden dem 

Kunden in der Dialoginitialisierungsantwort die für ihn zugelassenen AZS- 

Verfahren mitgeteilt. Als Bezugssegment für das Rückmeldungssegment 

HIRMS wird HKVVB (Verarbeitungsvorbereitung) verwendet. 

 

 

Der Kunde übermittelt im Signaturkopf der Dialoginitialisierungsnachricht, mit 

welchem konkreten AZS-Verfahren er den Dialog führen will. Das konkrete AZS- 

Verfahren darf während des Dialogs nicht gewechselt werden (Näheres hierzu 

siehe Abschnitt C). 

Die beiden Teilschritte eines Zwei-Schritt-AZS-Verfahrens (bei den AZS- 

Verfahren zur Qualifizierten Signatur mit den Sicherheitsfunktionen 800 und 

810) müssen nicht zwingend in einem einzigen Dialog abgewickelt werden. Über 

die Auftragsreferenz ist eine entsprechende Verkettung über mehrere Dialoge 

hinweg möglich. Über einen BPD-Parameter wird gesteuert, ob zeitversetztes / 

dialogübergreifendes Arbeiten erlaubt ist. 

Beim Einsatz von Mehrfach-Signaturen gilt ein konkretes AZS-Verfahren für den 

gesamten Dialog des jeweiligen Benutzers. Jeder Benutzer kann ein eigenes 

konkretes AZS-Verfahren verwenden, dieses darf im Kontext einer Mehrfach- 

Signatur-Einreichung jedoch nicht gewechselt werden. 

1 Aktuell sind sechs AZS-Verfahren spezifiziert

Kapitel: 

Seite: 

B 

18 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abschnitt: 


AZS-Verfahren zur Secoder-Integration 

 

Im Falle eines nicht zugelassenen Wechsels des AZS-Verfahrens muss das Kreditinstitut 

den Dialog mit Rückmeldungscode 9957 „Wechsel des AZS-Verfahrens 

bei Mehrfach-Signaturen nicht erlaubt“ beenden. 

Die Signierung von Kreditinstitutsnachrichten wird in AZV-Verfahren anders als 

in HBCI verwendet, d. h. es wird über das AZS-Verfahren festgelegt, ob Institutssignaturen 

verwendet werden. So sind bei den Verfahren 800, 810 und 812 

die Aufträge signaturpflichtig (siehe dort). Bei diesen Verfahren ist das Kundenprodukt 

verpflichtet, diese Institutssignaturen auch zu prüfen. 

B.2 AZS-Verfahren zur Secoder-Integration 

Im Folgenden werden schwerpunktmäßig die AZS-Verfahren zur Secoder- 

Integration betrachtet. Secoder-Kryptogramme (Definition vgl. Abschnitt „Begriffe“) 

ersetzen die ansonsten in FinTS verwendeten HBCI-Signaturen, d. h. der Hashwert 

über die zu signierenden Auftragsdaten wird in der FinTS-Instanz gebildet, an den 

Secoder übertragen und dort signiert. In einem zweiten Aufruf des Secoders werden 

zur „Visualisation Authentication“ die Visualisierungsdaten zusammen mit einem definierten 

Visualisierungsbestätigungssignaturfüllwert – bestehend aus einer Konstante 

oder der Reader-ID des Secoders – signiert. Der Visualisierungsbestätigungssignaturfüllwert 

bewirkt, dass institutsseitig eindeutig festgestellt werden kann, 

dass der Secoder sich zum Zeitpunkt der Signaturbildung im Applikationsmodus befand, 

falls ein Secoder verwendet wurde (vgl. [Secoder]). Ein konkretes AZS- 

Verfahren bezeichnet in diesem Sinne also ein konkretes durch den Secoder durchzuführendes 

und dort definiertes, ein- oder zwei-schrittiges Signaturverfahren bzw. 

die Verwendung des Secoders als „angeschlossener TAN-Generator“ (mit „Sicherheitsfunktion, 

kodiert“=820 bzw. 821). 

Die Arbeitsweise des Secoders sieht zur Signaturbildung vor, dass zusammen mit 

dem Hashwert über die Auftragsdaten eine Auswahl von Transaktionsdaten in Form 

von Secoder-spezifischen Kommandos (SecCmds) z. B. über die USB-Schnittstelle 

an den Secoder gesendet werden. Befindet sich der Secoder im Applikationsmodus 

– d. h. ist z. B. eine der Signatur-Applikationen „sig“ oder „aut“ selektiert – so werden 

die relevanten Daten im Secoder-Display angezeigt. Bestätigt der Kunde diese 

Daten mit Hilfe der Secoder-Tastatur, so gehen diese zusammen mit anderen Informationen 

in die Bildung der Signatur – entsprechend dem gewählten Verfahren – 

mit ein. Die Signatur selbst wird als Antwort an die aufrufende Secoder- 

Anwendungsfunktion im PC zurückgegeben und kann dort in das FinTS-Protokoll 

(DE „Signaturdaten“ in HKAZS) integriert werden. 

B.2.1 AZS-Verfahren und Ein- / Zwei-Schritt-Verfahren 

Abhängig vom konkreten Secoder-Verfahren, das über einen der definierten Werte 

der Sicherheitsfunktion (im Datenelement „Sicherheitsfunktion, kodiert“) festgelegt 

ist, wird ein Ein- oder Zwei-Schritt-Verfahren zwischen Kunde und Kreditinstitut verwendet. 

Ein-Schritt-Verfahren bedeutet, dass Daten und sämtliche Sicherheitselemente in 

einem Dialogschritt an das Kreditinstitut gesendet und von dort beantwortet werden. 

Alle Informationen zur Absicherung des Auftrags wie z. B. die am Secoder zu signierenden 

Auftragselemente sind lokal in der FinTS-Instanz über die BPD bekannt; es 

wird also kein zwei-schrittiges Challenge-Response-Verfahren benötigt. Nach dem 

Ein-Schritt-Verfahren arbeiten die Verfahren 811 bzw. 812 (Signatur mittels „aut“ 

Anwendung des Secoders) und 820 bzw. 821 (EMV application cryptogram mittels 

„tan“ Anwendung).



Kapitel: 

Abschnitt: 



Version: 

Stand: 

15.12.2009 

3.0 

Kapitel: 

Seite: 

19 

B 

Zwei-Schritt-Verfahren, wie sie auch im Bereich des FinTS Sicherheitsverfahrens 

PIN/TAN eingesetzt werden, bilden die Basis für die Verfahren 800 und 810 unter 

Verwendung qualifizierter elektronischer Signaturen, die durch Signaturanwendungskomponenten 

gebildet werden (Secoder-Anwendung „sig“). In diesem Fall 

müssen die Antragsdaten in einem ersten Schritt zum Kreditinstitut gesendet werden, 

damit ein zu signierendes Angebot erstellt und mit einer Institutssignatur versehen 

zum Kunden übertragen werden kann. Erst dieses Angebot bildet die Basis 

für die qualifizierte Signatur, die dann erst in einem zweiten Schritt zum Kreditinstitut 

geschickt wird. An diesem grundsätzlichen Prozess ändert auch die Verwendung 

eines Secoders nichts. 

Mit Ein- oder Zwei-Schritt-AZS-Verfahren werden keine Verfahren konkret spezifiziert 

– es erfolgt nur eine abstrakte Definition des Ablaufs, der über Parameter gesteuert 

wird. Der Ablauf selbst ist für alle Ein- bzw. Zwei-Schritt-AZS-Verfahren identisch. 

Die Parametrisierung eines konkreten Ein- oder Zwei-Schritt-AZS-Verfahrens 

erfolgt über die neuen Parametersegmente HIAZSS (Geschäftsvorfallparameter zu 

„Alternative ZKA-Sicherheitsverfahren“ HKAZS) und bei Ein-Schritt-Verfahren auch 

HIVISS (reines Parametersegment zur elementweisen Definition der Secoder- 

Visualisierungsdaten). 

Bei Verwendung von Mehrfach-Signaturen wird innerhalb eines Ablaufs das AZS- 

Verfahren durch den Dialogführer des ersten (und ggf. einzigen) Dialogs für alle beteiligten 

Benutzer festgelegt. 

Durch Verwendung des Parametersegmentes HIAZSS ist die abstrakte Beschreibung 

aller verfügbaren konkreten Ein- und Zwei-Schritt-AZS-Verfahren in der BPD 

möglich, die über das Datenelement „Sicherheitsfunktion, kodiert“ referenziert werden 

(Details siehe Kapitel B.5“). Einem Benutzer können maximal 9 konkrete AZS- 

Verfahren zugeordnet werden. Bei der Verwendung von Mehrfach-Signaturen kann 

jeder beteiligte Benutzer ein eigenes konkretes AZS-Verfahren verwenden – die 

Verfahren können also innerhalb einer Nachricht unterschiedlich sein 2 . 

Mit dem Sicherheitsverfahren PIN/TAN wurden zwei Prozessvarianten eingeführt, 

welche bereits zu unterschiedlichen Belegungen der Elemente im Geschäftsvorfall 

HKTAN geführt haben. Entsprechend existieren dort auch zugehörige TAN- 

Prozesse, um die einzelnen Schritte zu kennzeichnen. 

Im Rahmen der AZV-Verfahren ist im übertragenen Sinne nur die Prozessvariante 2 

relevant. Die Belegung der Elemente im Geschäftsvorfall HKAZS ist abhängig von 

der Charakteristik des Ein- oder Zwei-Schritt-Verfahrens und dem konkret verwendeten 

AZS-Verfahren (gekennzeichnet durch die Sicherheitsfunktion) und den zugehörigen 

Signatur-Prozessen. 

Ein-Schritt-Verfahren (S-Fkt 811 und 812, 820 und 821)): 

Bei dieser Variante wird der Auftrag inklusive aller Sicherheitsinformationen in einem 

Dialogschritt an das Kreditinstitut übertragen. Es existieren folgende Signatur- 

Prozesse. 

2 Da es im aktuellen Dialog nur einen Dialogführer geben kann, müssen die zulässigen konkreten 

Zwei-Schritt-Verfahren der weiteren Benutzer bereits vorab über separate Dialoge (und entsprechende 

Rückmeldecodes 3921) festgelegt worden sein.

Kapitel: 

Seite: 

B 

20 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abschnitt: 



 

 

Signatur-Prozess=6: 

Dient der Einreichung von Auftrag und Secoder-Sicherheitsinformationen (VisDataSig 

und VisAuthSig) im Ein-Schritt-AZS-Verfahren und wird durch das Kreditinstitut 

beantwortet. Kennzeichen von Signatur-Prozess=6 ist also, dass die Signaturbildung 

inklusive Secoder-Visualisierung geschieht. Wird sowohl im Rahmen 

der Dialoginitialisierung als auch bei der Auftragsverarbeitung benutzt. 


Über diesen Signaturprozess wird signalisiert, dass es sich um keine Secodersignatur, 

sondern um eine RDH-Signatur (S-Fkt=811, 812) bzw. ein EMV AC (bei S- 

Fkt=820, 821) ohne Secoder-Visualisierung handelt. Institutssignaturen im Ein- 

Schritt-AZS-Verfahren nach Sicherheitsfunktion 812 werden immer durch Signatur-Prozess=7 

gekennzeichnet, da Instituts-seitig keine (Secoder-)Visualisierung 

verwendet wird. 

Zwei-Schritt-Verfahren (S-Fkt 800 und 810): 

Bei dieser Variante wird zunächst der Auftrag zum Kreditinstitut übertragen. Das 

Institut hat nun die Kontrolle über den Aufbau der SAK-Visualisierungsdaten. Für die 

Secodervisualisierung werden bei S-Fkt=810 Metadaten verwendet (vgl. Definition 

MetaData in Abschnitt „Begriffe“), damit institutsseitig kein Wissen über die Secoder-spezifischen 

Kommandos und die physikalischen Eigenschaften (z. B. die Displaygröße) 

des Secoders benötigt wird. Die Metadaten sind identisch zum Ein- 

Schritt-Verfahren in HIVISS abgelegt. Das Kundensystem muss dafür Sorge tragen, 

dass die vorgegebene Metadaten mit dem angeschlossenen Secoder über 

SecCmds dargestellt werden können. 

Es werden die Signatur-Prozesse 2 bis 5 verwendet. Die Signatur-Prozesse 3 und 4 

sind nur Unterprozesse von Signatur-Prozess 2 und können nicht isoliert auftreten. 

 

 

 

 


Zuerst wird der Auftrag eingereicht (siehe Signatur-Prozess=4), aus dem SAK- 

Visualisierungsdaten ermittelt werden. Anschließend werden mit Signatur- 

Prozess=2 die Secoder-Kryptogramme zum Institut übertragen. 


Bei Verwendung von Mehrfach-Signaturen kann mit diesem Prozess die Einreichung 

eines SAK- oder Secoder-Kryptogramms eines weiteren Benutzers eingeleitet 

werden. 


Dient der Einleitung des Zwei-Schritt-AZS-Verfahrens und wird bei der Auftragseinreichung 

(Schritt 1) verwendet. 


Über diesen Signaturprozess wird signalisiert, dass es sich um eine Dialoginitialisierung 

handelt.



Kapitel: 

Abschnitt: 



Version: 

Stand: 

15.12.2009 

3.0 

Kapitel: 

Seite: 

21 

B 

Die Dialoginitialisierung im Zwei-Schritt-AZS-Verfahren gehorcht den folgenden Mechanismen: 

in der BPD wird festgelegt, welche Sicherheitsverfahren vom Institut unterstützt 

sind. 

in den Rückmeldeparametern werden die für den Kunden zulässigen Sicherheitsverfahren 

zurückgeliefert. 

Zur Übermittlung wird der allgemein verwendbare Geschäftsvorfall „Alternative ZKA 

Sicherungsverfahren – HKAZS“ eingesetzt. 

Um einen Auftrag im Zwei-Schritt-AZS-Verfahren abzuwickeln, müssen die im Folgenden 

beschriebenen Schritte durchgeführt werden. Dabei gilt die grundlegende 

Abfolge der Segmente am Beispiel einer Einzelüberweisung: 

Schritt 1: HKUEB und HKAZS HIAZS 

Schritt 2: HKAZS HIAZS und HIRMS zu HKUEB 

Durch die Verschachtelung der beiden Prozessschritte ergibt sich eine Sondersituation 

für die Verarbeitung der Rückmeldungen. Hierbei gelten folgende Regelungen: 

 

 

Alle Rückmeldungen in der letzten Antwort beziehen sich auf den Auftrag selbst, 

auch die Rückmeldungen auf die Signatur-Einreichung mit HKAZS. In der Antwort 

können auch explizite Kreditinstitutsantworten, z. B. HIDAE enthalten sein. 

Bei dialogübergreifender Verarbeitung kann nicht auf Bezugssegmente referenziert 

werden. Daher muss auf Basis der DE „Auftragsreferenz“ eine Referenz auf 

den eigentlichen Auftrag hergestellt werden. 

Tritt bei der Prüfung im ersten Schritt des eingereichten Auftrags eine 

ggf. behebbare Fehlersituation auf, so bestehen für das Kreditinstitut 

folgende Reaktionsmöglichkeiten: 

Übermitteln einer Warnung (Rückmeldungscode 3xxx) zusammen 

mit einem Segment HIAZS inklusive einer Challenge. Unterstützt 

das Kreditinstitut das Stornieren von Aufträgen (BPD-Parameter 

„Auftragsstorno erlaubt“=J) kann der Kunde im 2. Schritt den Auftrag 

stornieren bzw. trotz der Warnung per Signatur freigeben. 

Übermitteln eines Rückmeldungscode 9xxx ohne ein Segment 

HIAZS. 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 Übermittlung 

eines Segmentes HIAZS. Keiner der in der Nachricht enthaltenen 

Aufträge wird ausgeführt. 

Bei der Verwendung von Qualifizierten Signaturen auf Kundenseite sind auch die 

Aufträge in den Kreditinstitutsnachrichten mit einer fortgeschrittenen Signatur zu 

versehen. Die Steuerung über die Signaturbildung erfolgt z. B. im Rahmen von 

ISIS-MTT, also außerhalb des FinTS-Protokolls. Die Signatur wird im Segment 

HIAZS übertragen und über das vollständige Datenelement „SAK- 

Visualisierungsdaten“ gebildet.

Kapitel: 

Seite: 

B 

22 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abschnitt: 



B.2.2 Abläufe für AZS-Verfahren 

Die Abläufe zur Abwicklung der unterschiedlichen AZS-Verfahren unterscheiden 

sich je nach gewählter Variante. Konkret werden folgende in der Praxis vorkommenden 

Abläufe beschrieben: 

S-Fkt. 

Sicherheitsverfahren ohne Secoder: 

Ablauf 1: 800 Qualifizierte Elektronische Signatur mit Zwei-Schritt-AZS- 

Verfahren 

Sicherheitsverfahren mit Secoder: 

Ablauf 2: 810 Qualifizierte Elektronische Signatur unter Nutzung der Secoder-Applikation 

„sig“ mit Zwei-Schritt-AZS-Verfahren 

Ablauf 3a: 811 Nutzung der Secoder-Applikation „aut“ mit Ein-Schritt-AZS- 

Verfahren ohne Institutssignatur 

Ablauf 3b: 812 Nutzung der Secoder-Applikation „aut“ mit Ein-Schritt-AZS- 

Verfahren mit verpflichtender Institutssignatur 

Ablauf 4a: 820 Nutzung der Secoder-Applikation „tan“ mit Ein-Schritt-AZS- 

Verfahren und Verwendung der Online-Banking-PIN 

Ablauf 4b: 821 Nutzung der Secoder-Applikation „tan“ mit Ein-Schritt-AZS- 

Verfahren und Verwendung der Benutzer-PIN der TAN- 

Generator-Anwendung 

Allen Abläufen ist gemeinsam, dass die FinTS-Sicherheitssegmente Signaturkopf 

und Signaturabschluss nicht für den Transport der Kryptogramme verwendet werden 

können, da es sich um andere syntaktische Konstrukte handelt. Daher werden 

die FinTS Sicherheitssegmente teilweise mit speziellen Defaultwerten belegt (vgl. 

Abschnitt C.2), die außer der Online-Banking-PIN keine sicherheitsrelevanten Daten 

enthalten. 

Da die normale FinTS Dialoginitialisierung ebenfalls nicht für den Transport der 

kryptografischen Informationen verwendet werden kann, werden auch dort die Sicherheitssegmente 

teilweise mit Defaultwerten belegt. Eine Ausnahme bilden bei 

den Sicherheitsfunktionen 811 und 812 die Schlüsseleinreichung oder –Änderung. 

hier werden die üblichen HBCI RDH-Sicherheitsverfahren verwendet (vgl. Abschnitt 

C.1.3 „Key-Management bei AZS-Verfahren“). 

Alle Abläufe sind bezogen auf die einzelnen Prozessschritte exakt in der beschriebenen 

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 

der Dialogendenachricht werden im Gegensatz zur normalen FinTS-Verarbeitung 

die AZS-Signaturen weggelassen, wie in Abschnitt Behandlung der Dialogendenachricht 

(HKEND)C.1.4 beschrieben. 

Bei allen Abläufen wird davon ausgegangen, dass sich nur ein signaturpflichtiger 

FinTS-Auftrag in der Nachricht befindet. Dabei kann es sich auch um einen Sammelauftrag 

handeln. 

In einem Dialog ist es grundsätzlich möglich aber nicht verpflichtend, dass mehrere 

in sich abgeschlossene Abläufe hintereinander durchgeführt werden.



Kapitel: 

Abschnitt: 



Version: 

Stand: 

15.12.2009 

3.0 

Kapitel: 

Seite: 

23 

B 

Es gelten hierbei als Rahmenbedingungen die für den gesamten Dialog getroffenen 

Festlegungen, z. B. dass die Sicherheitsfunktion innerhalb eines Dialoges nicht gewechselt 

werden darf. 

Bei der Verwendung von Mehrfach-Signaturen (nur für Ein-Schritt-Verfahren relevant) 

sind Aufträge, bei denen mindestens ein Secoder-Kryptogramm fehlerhaft ist, 

Kreditinstituts-seitig zu verwerfen. 

In den Beschreibungen der Abläufe werden die folgenden Symbole verwendet: 

Legende 

Secoder 

Signaturanwendungskomponente 

Signaturanwendungskomponente 

mit Secoder 

K 

Kundenzertifikat 

I 

Institutszertifikat 

Abbildung 2: Legende für die Prozessdarstellungen 

B.2.2.1 Sicherheitsverfahren ohne Secoder 

Derzeit ist als Sicherheitsverfahren ohne Secoder nur der Einsatz der Qualifizierten 

Elektronischen Signatur (QES) auf Kundenseite vorgesehen, da die dort eingesetzten 

Signaturanwendungskomponenten Signaturformate nach Standards wie z.B. 

ISIS-MTT verwenden, die nicht mit der HBCI-Syntax verträglich sind . Anwendungen, 

welche fortgeschrittene Signaturen einsetzen, verwenden die in HBCI definierten 

RDH-Verfahren (vgl. Sicherheitsfunktion 811 bzw. 812). Der folgende Wert der 

„Sicherheitsfunktion, kodiert“ ist für den Einsatz von qualifizierten Signaturen vorgesehen: 

S-Fkt Segment Bedeutung 

800 Alternative ZKA Sicherheitsverfahren: 

- HKAZS ergänzend zum Signaturabschluss, 

- HIAZSS Verfahrensparameter 

Qualifizierte Elektronische 

Signatur ohne Secoder 

B.2.2.1.1 

Qualifizierte Elektronische Signatur (S-Fkt=800) 

Die verwendeten fortgeschrittenen und Qualifizierten Elektronische Signaturen werden 

ausschließlich durch die Signaturanwendungskomponente gebildet. Als Chipkartenleser 

wird eine zugelassene und zertifizierte Signaturerstellungseinheit verwendet.

Kapitel: 

Seite: 

B 

24 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abschnitt: 



B.2.2.1.1.1 

Dialoginitialisierung 

Im Rahmen der FinTS-Dialoginitialisierungselemente werden nur die administrativen 

Informationen ausgetauscht. Zusammen mit der Dialoginitialisierung wird ein Geschäftsvorfall 

HKAZS übertragen, um zunächst die kundenseitige Authentikation 

durchzuführen. 

Auch im Rahmen der Dialoginitialisierung sind Kunden- und Kreditinstituts-seitig 

Signaturen zu verwenden. 

Kreditinstitut 

SAK-SigAuth 

+ ggf. Zert. prüfen, 

BPD und UPD 

ermitteln 

Hashwert Inst.Zert. 

ermitteln, 

SAK-SigInst 

erstellen 

BPD mit HIAZSS, 

Rückmeldung: 

AZS-Verfahren 

für den Kunden 

Auftrag wurde 

erfasst, Dial-INI 

wird von FinTS- 

Instanz gestartet 

Dial-INI 

mit SAK-SigAuth 

in HKAZS 

für SFkt=800, SP=5 

K 

HIAZSS: 

GVs für AZS, 

AZS-Verfahren 

mit Parameter 

übernehmen 

Kunde wird zur 

Eingabe der 

CSA-PIN 

aufgefordert 

K 

Abbildung 3: Dialoginitialisierung bei qualifizierter Signatur ohne Secoder, 

S-Fkt=800



Kapitel: 

Abschnitt: 



Version: 

Stand: 

15.12.2009 

3.0 

Kapitel: 

Seite: 

25 

B 

Der vollständige Ablauf sieht folgendermaßen aus: 


Ausgangszustand: 

 

 

 

Der Kunde ist vollständig initialisiert und hat ggf. alle benötigten Zertifikate auf 

seine Signaturkarte geladen. 

Die Dialoginitialisierungsnachricht wird mit Defaultwerten gesendet; der Kunde 

hat dort durch entsprechende Belegung des DE „Sicherheitsfunktion, kodiert“=800 

ein konkretes Zwei-Schritt-Verfahren für den gesamten Dialog gewählt. 

Der Kunde erhält in der Dialoginitialisierungsantwort ggf. aktualisierte 

BPD/UPD 

Schritt 1a 

HKIDN, 

HKAZS 

Schritt 1b 

HIAZS 

Kundenauthentikationsdaten senden 

Das Kundensystem baut aus den Anmeldeinformationen des 

HKIDN (Benutzerkennung, KundenID, usw.) eine Struktur auf 

und übergibt diese mittels SAKCmds an die Signaturanwendungskomponente. 

Die Signaturanwendungskomponente greift auf die Chipkarte 

zu, um die CID zu ermitteln. Bei diesem ersten Zugriff wird der 

Kunde aufgefordert, sein CSA-Passwort einzugeben. Der PIN 

Sicherheitszustand wird über den gesamten Ablauf hinweg gehalten, 

außer er wird durch eine Kundenaktion unterbrochen. 

Nun kann die CID gelesen und für die spätere Auftragsverarbeitung 

im Kundensystem gespeichert werden. 

Über die Anmeldeinformationen wird eine SAK-AuthSig mit dem 

Signierschlüssel gebildet. Die Signatur wird inklusive des Kunden-Zertifikats 

an das Kundensystem zurück geschickt und dort 

zusammen mit der CID in die HKAZS-Struktur integriert. 

Durch Einreichung des Geschäftsvorfalls HKAZS mit der Belegung 

gemäß Signatur-Prozess=5 wird die SAK-AuthSig zum 

Institut übertragen. Die Verschlüsselung erfolgt mit SSL. 

Authentikationsantwort senden 

Nach Überprüfung des Kundenzertifikats (über Sperrlisten oder 

eine OCSP-Abfrage) wird ein HIAZS Antwortsegment aufgebaut 

und an das Kundenprodukt mit der Belegung gemäß Signatur- 

Prozess=5 übertragen. Das HIAZS-Antwortsegment enthält ein 

Institutszertifikat mit einer SAK-AuthSig, das durch den Kunden 

mit Hilfe der Signaturanwendungskomponente und dem Signierschlüssel 

geprüft werden kann. 

Das Kundensystem wertet die Kreditinstitutsantwort aus und 

zeigt dem Kunden die Begrüßungsseite an. 

B.2.2.1.1.2 

Antragseinreichung und Angebotsübermittlung 

Das Zwei-Schritt-AZS-Verfahren geht davon aus, dass der Kunde zunächst einen 

Antrag über den gewünschten Geschäftsvorfall einreicht.

Kapitel: 

Seite: 

B 

26 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abschnitt: 



Nach Prüfung der Angaben wird daraus ein Angebot in Form von SAK- 

Visualisierungsdaten erstellt und zusammen mit dem Institutszertifikat an den Kunden 

übermittelt. Der Kunde prüft das Angebot und das Institutszertifikat und fügt eine 

qualifizierte Signatur an. Diese wird zusammen mit dem gespiegelten Angebot 

als Auftrag an das Institut gesendet. 

Kreditinstitutsseitig muss z. B. durch einen geeigneten Hashwert geprüft werden, 

dass Angebot und Auftrag identisch sind. 


Auftrag speichern, 

Aufbau HIAZS: 

SAK-VisDaten 

SAK-VisDaten 

signieren, 

HIAZS senden 

I 

Auftrag + 

(Dummy-) HKAZS 

aufbauen + 

senden 

Übergabe 

SAK-VisDaten + 

I-Zertifikat an SAK 

HKAZS mit 

QualSig. + 

SAK-VisDaten senden 

I-Zertifikat + 

SAK-VisDaten 

anzeigen 

I 

QualSig 

mit DS-PIN 

erzeugen 

K 

Abbildung 4: Qualifizierte Signatur ohne Secoder – Phase Antrag und Angebot, 

S-Fkt=800



Kapitel: 

Abschnitt: 



Version: 

Stand: 

15.12.2009 

3.0 

Kapitel: 

Seite: 

27 

B 


SAK-VisDaten 

vergleichen 

QualSig 

+ ggf. K-Zert. 

prüfen 

K 

Auftrag + 

Signatur 

archivieren 

Auftrag 

verarbeiten 

Abbildung 5: Qualifizierte Signatur ohne Secoder – Phase Angebot und Auftrag, 

S-Fkt=800 

Antragseinreichung und Angebotsübermittlung / Auftragseinreichung 


 

Die Dialoginitialisierung ist erfolgt; der Kunde hat dort durch entsprechende 

Belegung des DE „Sicherheitsfunktion, kodiert“=800 ein konkretes Zwei- 

Schritt-Verfahren für den gesamten Dialog gewählt. 

Schritt 1a 

HKUEB, 

(Dummy)- 

HKAZS 

Schritt 1b 

HIAZS 

Schritt 2a 

HKAZS 

Antrag einreichen 

Durch Einreichung des Geschäftsvorfalls zusammen mit einem 

HKAZS mit der Belegung gemäß Signatur-Prozess=4 wird der 

Antrag zum Institut übertragen. Über die Belegung „Weitere 

Signatur folgt“ = „N“ wird signalisiert, dass dies der letzte und 

einzige Signaturprozess zu dem eingereichten Auftrag ist. 

Angebot senden 

Der Antrag wird im Institut geprüft; bei positivem Ergebnis wird 

ein Angebot in dem über die BPD vereinbarten Visualisierungsformat 

aufgebaut und mit einer fortgeschrittenen Institutssignatur 

versehen. 

Durch Verwenden des Rückmeldungscode 0030 – „Auftrag 

empfangen - Sicherheitsfreigabe erforderlich“ zusammen mit 

den Elementen „SAK-Visualisierungsdaten“ und „Signaturdaten“ 

aus HIAZS erhält das Kundenprodukt in der Kreditinstitutsantwort 

das signierte Angebot inklusive dem Institutszertifikat. 

Unterschriebenen Auftrag einreichen 

Das Kundenprodukt übergibt die SAK-Visualisierungsdaten und 

das Institutszertifikat an die Signaturanwendungskomponente.

Kapitel: 

Seite: 

B 

28 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abschnitt: 



Schritt 2b 

z. B. 

HIRMS zu 

HKUEB 

Dort wird das Angebot visualisiert und der Kunde hat die Möglichkeit 

den Inhalt, sowie die Zertifikatsinformationen in einem 

zertifizierten Umfeld zu überprüfen. Bei positivem Ergebnis fügt 

der Kunde nach Eingabe seiner Signatur-PIN eine qualifizierte 

Signatur mit dem Signaturschlüssel an und schließt die Signaturanwendungskomponente 

– die Kontrolle geht zusammen mit 

den unterschriebenen Daten zurück an das Kundensystem. 

Das Kundensystem baut aus den Informationen einen HKAZS 

mit der Belegung gemäß Signatur-Prozess=2 auf und sendet 

den unterschriebenen Auftrag an das Institut. 

Nach erfolgreicher Signatur- und ggf. Zertifikatsprüfung kann 

der Auftrag verarbeitet werden. 

Rückmeldungen senden 

Mit der Kreditinstitutsantwort zum Geschäftsvorfall werden ggf. 

erzeugte Antwortsegmente sowie die Rückmeldungen zur Signatur-Prüfung 

und zum Auftrag selbst zum Kundenprodukt gesendet. 

B.2.2.2 Sicherheitsverfahren mit Secoder 

Beim FinTS-Sicherheitsverfahren HBCI unter Verwendung des Secoders werden 

die Prozesse des bestehenden Zwei-Schritt-TAN-Verfahrens sinngemäß übernommen 

und als AZS-Verfahren verfügbar gemacht. Bei Einsatz des Secoders existiert 

eine Ausprägung der „Sicherheitsfunktion, kodiert“, über welche die im Folgenden 

dargestellten Abläufe ausgelöst werden: 

S-Fkt Segment Bedeutung 

810 Alternative ZKA Sicherungsverfahren: 


- HIAZSS und HIVISS Verfahrensparameter 









- Online-Banking-PIN im Signaturabschluss 




- Def. Füllwert „noPIN“ im Signaturabschluss 



Signatur („DS-Signatur“) 

mit Secoder 

Fortgeschrittene Elektronische 

Signatur („AUT- 

Signatur“) mit Secoder 

ohne Institutssignatur 



Signatur“) mit Secoder mit 

verpflichtender Institutssignatur 

EMV-AC-Kryptogramm 

über Visualisierungsdaten 

mit Secoder und Online- 

Banking-PIN 

EMV-AC-Kryptogramm 

über Visualisierungsdaten 

mit Secoder und Offline- 

Benutzer-PIN



Kapitel: 

Abschnitt: 



Version: 

Stand: 

15.12.2009 

3.0 

Kapitel: 

Seite: 

29 

B 

B.2.2.2.1 

Qualifizierte Elektronische Signatur mit Secoder (S-Fkt=810) 

Die QES unter Einsatz eines Secoders kann derzeit nur grob skizziert werden, da 

die zukünftige Einbindung in eine Signaturanwendungskomponente mit der Bundesnetzagentur 

abgestimmt werden muss. 

Generell wird das Szenario ohne Verwendung des Secoders in mehrfacher Hinsicht 

erweitert: 

 

 

 

B.2.2.2.1.1 

Durch die Verwendung der Secoder-Applikation „sig“ kann eine sichere Leserumgebung 

genutzt werden, die es erlaubt, Daten am Secoder-Display anzuzeigen 

und die Aktionen des Kunden auf Basis des Secoder- 

Visualisierungskonzeptes signiert mitgeliefert zu bekommen. 

Außer der kompletten Angebotsvisualisierung in der Signaturanwendungskomponente 

können ausgewählte Daten durch die SAK auch am Secoder visualisiert 

werden. 

Durch die zusätzliche Visualisierungsbestätigungssignatur kann überprüft werden, 

ob der Secoder sich zum Zeitpunkt der Signaturbildung im Applikationsmodus 

befunden hat, falls der Kunde einen Secoder verwendet hat. 

In den Abläufen wird davon ausgegangen, dass die qualifizierte (Auftrags-)Signatur 

über die vom Institut bereitgestellten Angebotsdaten im Zwei-Schritt-Verfahren erzeugt 

wird, während die MetaData auf Basis der BPD-Informationen dezentral ermittelt 

und im Schritt 1b zugesteuert werden. 

Die Dialoginitialisierung besteht nur aus den Schritten 1a und 1b (Ein-Schritt- 

Verfahren). 



Informationen verwendet. Zusammen mit der Dialoginitialisierung wird ein Geschäftsvorfall 

HKAZS ausgetauscht, um zunächst die Kunden- und Instituts-seitige 

Authentikation durchzuführen. 

Die Dialoginitialisierung kann exakt dem Initialisierungsprozess ohne Verwendung 

des Secoders entsprechen, wenn zu diesem Zeitpunkt keine Daten im Secoder visualisiert 

werden, sondern nur eine fortgeschrittene Signatur über die Anmeldedaten 

(die mittels der Signaturanwendungskomponente visualisiert werden) mit der Secoder-Anwendung 

„aut“ erfolgt. Der hier beschriebene Prozess geht jedoch davon aus, 

dass die Anmeldedaten aus dem FinTS-Segment „Verarbeitungsvorbereitung“ zusätzlich 

im Secoder-Display visualisiert werden sollen und entsprechende Steuerungsinformationen 

hierzu im BPD-Segment HIVISS hinterlegt sind.

Kapitel: 

Seite: 

B 

30 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abschnitt: 




Auftrag erfasst, 

KDN-SW baut 

Dial-Ini inkl. 

HKAZS-Segment 

auf 

Ermitteln MetaData 

für HKVVB 

aus HIVISS 

(BPD) 

Eingabe 

Benutzerkennung 

am Kunden-PC 

Umsetzung 

MetaData nach 

Secoder-Cmds 

(inkl. 

Auftragshashwert) 

Abfrage und lokale 

Prüfung der 

CSA-PIN 

Anzeige z.B. 


und Bestätigen 

durch den Kunden 

Erzeugen 

VisDataSig und 

Rückgabe an 

KDN-SW 


S-Fkt=810 (1 von 2) 


VisDataSig, 

VisAuthSig 

+ggf. Zert. prüfen, 

BPD und UPDermitteln 

Hashwert Inst.Zert. 

ermitteln 

SAK-SigInst 

erstellen 

Übertragen Dial-Ini 

inkl. HKAZS- 

Segment für 

Sfk=810, SP=5 

Rückmeldungen, 

ggf. BPD, 

AZS-Verfahren 


Einstellen 

VisAuthSig 

und VisData in 

HKAZS-Segment 

Einstellen 

BenKennung 

in HKIDN und 

Defaults in 

HNSHK/HNSHA 

ggf. neue BPD- 

Parms aus HIAZSS 

und HIVISS 

übernehmen 

Aufruf SecCmd 

„VisAuthSig“ 

an Secoder 

Einstellen 

VisAuthSig 

in HKAZS 

Erzeugen 

VisAuthSig 

mit vorh.VisData 


S-Fkt=810 (2 von 2)



Kapitel: 

Abschnitt: 



Version: 

Stand: 

15.12.2009 

3.0 

Kapitel: 

Seite: 

31 

B 




 

 

 

Der Kunde ist vollständig initialisiert und hat ggf. alle benötigten Zertifikate auf 

seine Signaturkarte geladen. 



ein konkretes Zwei-Schritt-Verfahren für den gesamten Dialog gewählt. 

Im Kundensystem ist eine aktuelle BPD gespeichert, aus der die Steuerungsinformationen 

zum Aufbau der MetaData ermittelt werden können. Ggf. muss 

die FinTS-Instanz die aktuelle BPD über einen anonymen Dialog ermitteln. 

Schritt 1a 

HKIDN, 

HKAZS 



HKIDN (Benutzerkennung, KundenID, usw.) eine Struktur auf 

und übergibt diese mittels SAKCmds an die Signaturanwendungskomponente. 

Inhalt sind auch die Segmente Signaturkopf, 

Identifikation und Verarbeitungsvorbereitung, die in die Signaturbildung 

mit einfließen, jedoch nicht visualisiert werden. 

Zunächst erfolgt durch die Signaturanwendungskomponente ein 

Zugriff auf den Secoder im Default-Modus. Beim ersten Zugriff 

wird der Kunde aufgefordert, sein CSA-Passwort einzugeben. 

Der PIN Sicherheitszustand wird über den gesamten Ablauf 

hinweg gehalten, außer er wird durch eine Kundenaktion unterbrochen. 

Auch bei dem Wechsel zwischen Default- und Applikationsmodus 

im Secoder muss das CSA-Passwort nicht neu eingegeben 

werden. 

Anschließend wird die CID ermittelt und später an das Kundensystem 

zurückgegeben, das die CID in den Signaturkopf einstellt. 

Daraufhin baut die Signaturanwendungskomponente die benötigten 

SecCmds auf, um am Secoder im Applikationsmodus 

„aut“ eine VisData-Signatur mit Visualisierung durchzuführen. 

Der Kunde wird aufgefordert, die angezeigten Anmeldedaten zu 

ergänzen 3 bzw. zu bestätigen. 

Die zwischengespeicherten Segmente aus der Dialoginitialisierung 

werden analog den Vorgaben der Signaturanwendungskomponente 

gehasht und es wird eine VisData-Signatur gebildet 

und vom Secoder an die Signaturanwendungskomponente 

zurückgegeben. Von dort wird sie inklusive des Kunden- 

Zertifikats (im ISIS-MTT-Format) und der CID an das Kundensystem 

übergeben, welches mit den erhaltenen Werten eine 

HKAZS-Struktur füllt. Hierzu wird die gesamte ISIS-MTT- 

Struktur in das Element „Signaturdaten“ eingestellt. Die separat 

3 Das Eingeben / Ergänzen von Daten ist nur bei den Sicherheitsfunktionen 820 und 821 erlaubt.

Kapitel: 

Seite: 

B 

32 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abschnitt: 



übergebene CID wird in den Signaturkopf kopiert. 

Schritt 1b 

HIAZS 

Die Signaturanwendungskomponente ruft den Secoder nochmals 

im Applikationsmodus „aut“ zur Visualisierungsbestätigung 

auf (VisAuthSig) und übergibt hierzu den in der BPD festgelegten 

und vom Kundensystem zuvor übergebenen Visualisierungsbestätigungssignaturfüllwert. 

Der noch im VisData-Puffer 

vorhandene Hashwert über die Secoder-Visualisierungsdaten 

wird an den ersten Stellen mit dem Visualisierungsbestätigungssignaturfüllwert 

überschrieben und über dieses Resultat 

eine VisAuth-Signatur gebildet. Die erzeugte VisAuth-Signatur 

wird an die Signaturanwendungskomponente zurückgegeben. 

Diese leitet sie an das Kundensystem weiter, wo sie in das Datenelement 

Visualisierungsbestätigungssignaturdaten des 

HKAZS eingefügt wird. 

Die fachlichen Segmente (HKIDN, HKVVB …) werden zusammen 

mit HKAZS mit der Belegung gemäß Signatur-Prozess=5 

inklusive VisDataSig und VisAuthSig SSL-verschlüsselt zum 

Institut übertragen. 


Nach Überprüfung des Kundenzertifikats (über Sperrlisten oder 

eine OCSP-Abfrage), der VisData- und VisAuth-Signatur, wird 

ein HIAZS Antwortsegment aufgebaut und an das Kundenprodukt 

übertragen. Das HIAZS-Antwortsegment enthält das Institutszertifikat. 

Das Kundensystem wertet die Kreditinstitutsantwort aus überprüft 

die im Institutszertifikat enthaltene Signatur und zeigt dem 

Kunden die Begrüßungsseite an. 

B.2.2.2.1.2 

Antragseinreichung und Angebotsübermittlung 

Auch im Secoder-Betrieb geht das Zwei-Schritt-AZS-Verfahren davon aus, dass der 

Kunde zunächst einen Antrag über den gewünschten Geschäftsvorfall einreicht. 

Nach Prüfung der Angaben wird daraus ein Angebot in Form von SAK- 

Visualisierungsdaten erstellt und an den Kunden übermittelt. SAK- 

Visualisierungsdaten, Secoder-MetaData (aus HIAZSS und HIVISS) für die zusätzliche 

Visualisierung im Secoder und das Institutszertifikat werden an die Signaturanwendungskomponente 

übergeben. Der Kunde prüft das in der Signaturanwendungskomponente 

visualisierte Angebot und das Institutszertifikat und fügt – nach 

Kontrolle des Datenextraktes im Secoder-Display - eine Qualifizierte Signatur an. 

Diese wird zusammen mit dem gespiegelten Angebot als Auftrag an das Institut gesendet.



Kapitel: 

Abschnitt: 



Version: 

Stand: 

15.12.2009 

3.0 

Kapitel: 

Seite: 

33 

B 


Auftrag speichern, 

Aufbau HIAZS: 


MetaData 


MetaData 

signieren, 

HIAZS senden 

I 

Auftrag + 

(Dummy-) HKAZS 

aufbauen+senden 

mit SFK=810, SP=4 

Übergabe 


I-Zertifikat an SAK 

Einstellen Signaturen 

in HKAZS als 

DE „Signaturdaten“ 

I 

I-Zertifikat + 

SAK-VisDaten anzeigen 

Umw. MetaData 

nach SecCmds, 

senden an Secoder 

VisDataSig bilden 

QualSig 

mit DS-PIN 

mit SecAppl „sig“ 

erzeugen 

K 

Abbildung 8: Qualifizierte Signatur mit Secoder, S-Fkt=810 (1 von 3) 


Einstellen 

VisAuthSig 

in HKAZS 

FinTS-Nachricht 

HKAZS mit drei 

Signaturen und 

SAK-VisDaten senden 

mit SFK=810, SP=2 

Umw. MetaData 

nach SecCmds, 

senden an Secoder 

VisAutSig bilden 

Signatur mit 

SecAppl „aut“ 

als VisAuthSig 

Abbildung 9: Qualifizierte Signatur mit Secoder, S-Fkt=810 (2 von 3)

Kapitel: 

Seite: 

B 

34 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abschnitt: 




SAK-VisDaten 

vergleichen 

K 

VisDataSig / QualSig, 

VisAuthSig 

+ ggf. K-Zert. 

prüfen 

Auftrag + 

Signatur 

archivieren 

Auftrag 

verarbeiten 

Abbildung 10: Qualifizierte Signatur mit Secoder, S-Fkt=810 (3 von 3) 

Antragseinreichung und Angebotsübermittlung / Auftragseinreichung 


 


Belegung des DE „Sicherheitsfunktion, kodiert“=810 das konkrete Zwei-Schritt- 

AZS-Verfahren Qualifizierte Signatur mit Secoder für den gesamten Dialog 

gewählt. 

Schritt 1a 

HKUEB, 

(Dummy)- 

HKAZS 

Schritt 1b 

HIAZS 

Antrag einreichen 

Durch Einreichung des Geschäftsvorfalls zusammen mit einem 

HKAZS mit der Belegung gemäß Signatur-Prozess=4 wird der 

Antrag zum Institut übertragen. Über die Belegung „Weitere 

Signatur folgt“=„N“ wird signalisiert, dass dies der letzte und 

einzige Signaturprozess zu dem eingereichten Auftrag ist. 

Angebot senden 

Der Antrag wird im Institut geprüft; bei positivem Ergebnis wird 

ein Angebot in dem über die BPD vereinbarten SAK- 

Visualisierungsformat aufgebaut, mit einer fortgeschrittenen Institutssignatur 

versehen und zum Kundensystem übertagen. 

Durch Verwenden des Rückmeldungscode 0030 – „Auftrag 

empfangen - Sicherheitsfreigabe erforderlich“ zusammen mit 

den Elementen „SAK-Visualisierungsdaten“ und zugehörigen 

„Signaturdaten“ aus HIAZS erhält das Kundenprodukt in der 

Kreditinstitutsantwort das signierte Angebot inklusive dem Institutszertifikat. 

Anschließend werden anhand der BPD- 

Informationen (HIAZSS bzw. HIVISS) MetaData für die Anzeige 

im Secoder-Display erzeugt.



Kapitel: 

Abschnitt: 



Version: 

Stand: 

15.12.2009 

3.0 

Kapitel: 

Seite: 

35 

B 

Schritt 2a 

HKAZS 

Schritt 2b 

z. B. 

HIRMS zu 

HKUEB 

Unterschriebenen Auftrag einreichen 

Das Kundenprodukt übergibt die SAK-Visualisierungsdaten, das 

Institutszertifikat und die Secoder-MetaData an die Signaturanwendungskomponente. 

Dort wird das Angebot visualisiert und 

der Kunde hat die Möglichkeit den Inhalt, sowie die Zertifikatsinformationen 

in einem zertifizierten Umfeld zu überprüfen. Bei 

positivem Ergebnis drückt der Kunde den Button „Signieren“ 

und startet damit die Verarbeitung im Secoder. Die Signaturanwendungskomponente 

wandelt die MetaData in SecCmds um 

und sendet diese zusammen mit dem Hashwert über den Auftrag 

(die SAK-Visualisierungsdaten) an den Secoder. 

Dort wird zunächst die Secoder-Applikation „sig“ selektiert. Die 

Angebotsextrakte werden entsprechend der Anweisungen aus 

den SecCmds angezeigt und durch den Kunden bestätigt. in der 

SECCOS-Karte wird aus den Ergebnissen – mit dem zwischengespeicherten 

Hashwert über die SAK-Visualisierungsdaten 

startend – ein Hashwert über die gesamten Visualisierungsdaten 

gebildet. 

Abschließend fügt der Kunde nach Eingabe seiner Signatur-PIN 

eine Qualifizierte Signatur an. 

Die Kontrolle wird an die Signaturanwendungskomponente zurückgegeben; 

als Rückgabewerte werden die Qualifizierte Signatur 

und das Kundenzertifikat übertragen. 

Die Signaturanwendungskomponente ruft den Secoder nochmals 

im Applikationsmodus „aut“ zur Visualisierungsbestätigung 

auf (VisAuthSig) und übergibt hierzu den in der BPD festgelegten 

und vom Kundensystem zuvor übergebenen Visualisierungsbestätigungssignaturfüllwert. 






wird an die Signaturanwendungskomponente zurückgegeben. 

Diese leitet sie an das Kundensystem weiter, wo sie in das Datenelement 


HKAZS eingefügt wird. 

Der Kunde schließt die Signaturanwendungskomponente – die 

Kontrolle geht zusammen mit den unterschriebenen Daten zurück 

an das Kundensystem. 


inklusive VisDataSig und VisAuthSig mit der Belegung gemäß 

Signatur-Prozess=2 auf und sendet den unterschriebenen Auftrag 

SSL-verschlüsselt an das Institut. 




Auf Institutsseite wird anhand eines Hashwertvergleichs sichergestellt, 

dass Angebot und signierter Auftrag identisch sind.

Kapitel: 

Seite: 

B 

36 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abschnitt: 




erzeugte Antwortsegmente sowie die Rückmeldungen zur Signatur-Prüfung 

und zum Auftrag selbst zum Kundenprodukt gesendet. 

Dieses überprüft die im Institutszertifikat enthaltene 

Signatur und fährt im Dialog fort. 

B.2.2.2.2 

Fortgeschrittene Elektronische Signatur mit Secoder (S-Fkt=811) 

Bei diesem Szenario wird von einem ein-schrittigen Verfahren ausgegangen, d. h. 

die im Secoder zu visualisierenden Daten müssen dem Kundensystem über die 

BPD (HIAZSS und HIVISS) mitgeteilt werden. 

B.2.2.2.2.1 

Es wird davon ausgegangen, dass der Benutzer vor der ersten Verwendung dieses 

AZS-Verfahrens vollständig initialisiert ist, d. h. es muss über das Standard RDH- 

Verfahren (S-Fkt=1, Signaturübertragung im FinTS Signaturabschluss) ein Schlüsselaustausch 

erfolgt sein (vgl. hierzu auch Abschnitt C.1.3 „Key-Management bei 

AZS-Verfahren“). 

Die Kreditinstitutsantwort enthält bei S-Fkt=811 keine Institutssignatur. 




HKAZS eingereicht, um die Kunden-seitige Authentikation durchzuführen. 

Bei der Dialoginitialisierung werden wahlweise Daten im Secoder visualisiert und es 

erfolgt eine fortgeschrittene Signatur über die Anmeldedaten und ggf. Visualisierungsdaten 

mit der Secoder-Anwendung „aut“. 



KDN-SW baut 


HKAZS-Segment 

auf 


für HKVVB 

aus HIVISS 

(BPD) 

Eingabe 


am Kunden-PC 

Umsetzung 

MetaData nach 

Secoder-Cmds 

(inkl. 



Prüfung der 

CSA-PIN 

Anzeige z.B. 




Erzeugen 


Rückgabe an 

KDN-SW 

Abbildung 11: Dialoginitialisierung beim AZS-Verfahren S-Fkt=811 (1 von 2)



Kapitel: 

Abschnitt: 



Version: 

Stand: 

15.12.2009 

3.0 

Kapitel: 

Seite: 

37 

B 


Signaturen prüfen, 



ggf. BPD, 

AZS-Verfahren 

für den Kunden, 

keine Instsig 


inkl. 

HKAZS-Segment 

für 

Sfk=811, SP=6 

Übertragen 

Dial-Ini-Antwort 

ohne HIAZS 

Einstellen 

VisDataSig in 

HKAZS-Segment 

Einstellen 

VisAuthSig 

in HKAZS 



und HIVISS 

übernehmen 

Aufruf SecCmd 


an Secoder 

Erzeugen 

VisAuthSig 

mit vorh.VisData 

Abbildung 12: Dialoginitialisierung beim AZS-Verfahren S-Fkt=811 (2 von 2) 


Dialoginitialisierung bei Sicherheitsfunktion 811 


 

 

 

Der Kunde ist vollständig initialisiert und seine Karte ist frei geschaltet (über 

Zertifikate oder Ini-Brief-Austausch). Dieser Vorgang wird über das Standard 

RDH-Verfahren mit Sicherheitsfunktion=1 durchgeführt. 



ein konkretes Ein-Schritt-Verfahren für den gesamten Dialog gewählt. 




Schritt 1a 

HKIDN, 

HKAZS 



HKIDN (Benutzerkennung, KundenID, usw.) eine Struktur auf. 

Als Signaturalgorithmus wird ein geeignetes (BPD) Sicherheitsprofil 

selektiert. Über die Segmente Signaturkopf, Identifikation, 

Verarbeitungsvorbereitung und ggf. Anforderung öffentlicher 

Schlüssel wird entsprechend den Angaben im Sicherheitsprofil, 

das in den Verschlüsselungskopf eingestellt wird, der Auftragshashwert 

erzeugt. Falls die Länge des Hashwerts nicht der 

Blocklänge entspricht, wird dieser wird mit Nullen aufgefüllt. 

Es erfolgt ein Zugriff auf den Secoder im Default-Modus. Beim 

ersten Zugriff wird der Kunde aufgefordert, sein CSA-Passwort

Kapitel: 

Seite: 

B 

38 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abschnitt: 



Schritt 1b 

HIAZS 

einzugeben. 





werden. 

Anschließend wird der aktuelle Signaturzähler des Signier- 

Schlüssels ermittelt, inkrementiert und in das Datenelement Sicherheitsreferenznummer 

im Signaturkopf eingestellt. Auch die 

restlichen benötigten Werte wie z. B. CID, Schlüsselnummer, 

Schlüsselversion und ggf. Kunden-Zertifikat des Signierschlüssels 

werden auf diese Weise von der Karte gelesen und für die 

spätere Auftragsverarbeitung im Kundensystem gespeichert. 

Auf Basis der Informationen aus HIAZSS und HIVISS erzeugt 

das Kundensystem die benötigten SecCmds, um Visualisierungsinformationen 

und den Auftragshashwert zu übergeben 

und am Secoder im Applikationsmodus „aut“ eine VisData- 

Signatur mit Visualisierung der relevanten Daten aus HIVISS 

durchzuführen. Hierbei wird der VisData-Puffer sukzessive mit 

den Ergebnissen des Visualisierungsprozesses aufgefüllt. Nach 

der letzten Bestätigung des Kunden wird – beginnend mit dem 

Auftragshashwert, der als Initialwert zwischengespeichert wurde 

– in der Karte ein Hashwert über den VisData-Puffer gebildet. 

Das Ergebnis dieser Hashoperation wird an den Secoder zurückgegeben 

und ersetzt den Inhalt des VisData-Puffers. 

Über den erzeugten Hashwert wird dann eine VisData-Signatur 

mit dem Signierschlüssel gebildet und vom Secoder an die aufrufende 

Applikation zurückgegeben. Die Signatur wird dort in 

die bereits vorbereitete HKAZS-Struktur in das Datenelement 

Signaturdaten eingestellt. 

Das Kundenprodukt ruft den Secoder nochmals im Applikationsmodus 

„aut“ zur Visualisierungsbestätigung auf (VisAuthSig) 

und übergibt hierzu den in der BPD festgelegten Visualisierungsbestätigungssignaturfüllwert. 






wird an das Kundenprodukt zurückgegeben und dort in das Datenelement 


HKAZS eingefügt. 



inklusive VisDataSig und VisAuthSig HBCI-verschlüsselt zum 



Nach Überprüfung von VisDataSig und VisAuthSig wird eine 

Dialoginitialisierungsantwort aufgebaut.



Kapitel: 

Abschnitt: 



Version: 

Stand: 

15.12.2009 

3.0 

Kapitel: 

Seite: 

39 

B 

Da bei S-FKT=811 keine Institutssignatur verwendet wird, wird 

die Nachricht unsigniert aber HBCI-verschlüsselt an das Kundenprodukt 

übertragen. 

Das Kundensystem wertet nach der Entschlüsselung die Kreditinstitutsantwort 

aus und zeigt dem Kunden die Begrüßungsseite 

an. 

B.2.2.2.2.2 

Auftragseinreichung beim Ein-Schritt-AZS-Verfahren 

Bei diesem Szenario werden die SecCmds von der aktiven Kundenkomponente auf 

Basis des zugrunde liegenden Auftrags offline erzeugt und an den Secoder übertragen. 

Der Kunde fügt – nach Kontrolle und Bestätigung des Datenextraktes im Secoder-Display 

- eine fortgeschrittene Signatur an. Diese wird zusammen mit dem Auftrag 

an das Institut gesendet. 



VisAuthSig 

prüfen 

analog BPD 


und senden 

Übertragen Auftrag 

und 

HKAZS-Segment 

für Sfk=811, SP=6 

Auftrag 

verarbeiten 

Ermitteln 

MetaData für GV 

aus HIAZSS 

und HIVISS (BPD) 

Einstellen 

VisDataSig in 

HKAZS-Segment 

Einstellen 

VisAuthSig 

in HKAZS 

Rückmeldungen 

anzeigen 

Umsetzung 

MetaData nach 

Secoder-Cmds 

(inkl. 


Aufruf SecCmd 


an Secoder 

Anzeige 

VisAuftrag und 

Bestätigen/ 

Ergänzen 


Erzeugen 


Rückgabe an 

KDN-SW 

Erzeugen 

VisAuthSig 

Abbildung 13: Fortgeschrittene Signatur mit Secoder, S-Fkt=811 

Auftragseinreichung bei Sicherheitsfunktion=811 


 




Schritt 1a 

HKUEB, 

HKAZS 

Auftrag einreichen 

Im Kundenprodukt wird eine HKAZS-Struktur aufgebaut. Hierbei 

wird in das Datenelement Signaturreferenznummer im Signaturkopf 

der zwischengespeicherte und um 2 (VisDataSig und 

VisAuthSig) inkrementierte Signaturzähler eingestellt.

Kapitel: 

Seite: 

B 

40 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abschnitt: 



Das Kundenprodukt erzeugt auf Basis des Auftrags und der 

BPD die benötigten SecCmds und sendet diese zusammen mit 

dem Auftragshashwert über Signaturkopf und fachliches Segment 

(z. B. HKUEB) an den Secoder im Applikationsmodus 

„aut“. Falls die Länge des Hashwerts nicht der Blocklänge entspricht, 

wird dieser wird mit Nullen aufgefüllt. 

Wie bei der Dialoginitialisierung beschrieben wird auch hier der 

VisData-Puffer sukzessive mit Informationen aus dem Secoder- 

Visualisierungsprozess gefüllt. Aus den Ergebnissen wird – mit 

dem zwischengespeicherten Hashwert über die Auftragsdaten 

startend – ein Hashwert über die Visualisierungsdaten gebildet, 

der den Inhalt des VisData-Puffers ersetzt. Über diesen Hashwert 

wird mit Hilfe des Signierschlüssels eine VisData-Signatur 

erzeugt. 

Die Kontrolle wird an das aufrufende Programm zurückgegeben 

und die VisData-Signatur in das DE Signaturdaten in HKAZS 

eingestellt. 












Der fachliche Geschäftsvorfall (z. B. HKUEB) wird zusammen 

mit HKAZS mit der Belegung gemäß Signatur-Prozess=6 inklusive 

VisDataSig und VisAuthSig HBCI-verschlüsselt zum Institut 

übertragen. 

Schritt 1b 

z. B. 

HIRMS zu 

HKUEB 


Nach erfolgreicher Signaturprüfung kann der Auftrag verarbeitet 

werden. 

Es wird eine Auftragsantwort aufgebaut, die ggf. erzeugte Antwortsegmente 

sowie die Rückmeldungen zur Signatur-Prüfung 

und zum Auftrag selbst enthält Da bei S-FKT=811 keine Institutssignatur 

verwendet wird, wird die Nachricht unsigniert aber 

HBCI-verschlüsselt an das Kundenprodukt übertragen. 

Das Kundensystem wertet nach der Entschlüsselung die Kreditinstitutsantwort 

aus.



Kapitel: 

Abschnitt: 



Version: 

Stand: 

15.12.2009 

3.0 

Kapitel: 

Seite: 

41 

B 

B.2.2.2.3 

Fortgeschrittene Elektronische Signatur mit Secoder (S-Fkt=812) 



BPD (HIAZSS und HIVISS) mitgeteilt werden. 

Bei der Verwendung des AZS-Verfahrens nach Sicherheitsfunktion=812 werden die 

Aufträge auch in den Kreditinstitutsnachrichten mit einer Signatur versehen. Die 

Steuerung über die Signaturbildung erfolgt im FinTS-Signaturkopf. Die Signatur wird 

im Segment HIAZS übertragen und über die FinTS Segmente (HNSHK, HIRMG, 

n x HIRMS und Antwortsegmente, z. B. HIKAZ) gebildet. Die Signatur selbst ist eine 

RDH-Signatur mit Sicherheitsfunktion=1. 

Es wird davon ausgegangen, dass der Benutzer vor der ersten Verwendung dieses 

AZS-Verfahrens vollständig initialisiert ist, d. h. es muss über das Standard RDH- 

Verfahren (S-Fkt=1, Signaturübertragung im FinTS Signaturabschluss) ein Schlüsselaustausch 

erfolgt sein (vgl. hierzu auch Abschnitt C.1.3 „Key-Management bei 

AZS-Verfahren“). 

Die in der Kreditinstitutsantwort enthaltene Institutssignatur muss vom Kundensystem 

zwingend geprüft werden.

Kapitel: 

Seite: 

B 

42 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abschnitt: 



B.2.2.2.3.1 Dialoginitialisierung bei Sicherheitsfunktion 812 



HKAZS ausgetauscht, um zunächst die Kunden- und bei S-Fkt=812 

auch Kreditinstituts-seitige Authentikation durchzuführen. 

Bei der Dialoginitialisierung werden wahlweise Daten im Secoder visualisiert und es 

erfolgt eine fortgeschrittene Signatur über die Anmeldedaten und ggf. Visualisierungsdaten 

mit der Secoder-Anwendung „aut“. 



KDN-SW baut 


HKAZS-Segment 

auf 


für HKVVB 

aus HIVISS 

(BPD) 

Eingabe 


am Kunden-PC 

Umsetzung 

MetaData nach 

Secoder-Cmds 

(inkl. 



Prüfung der 

CSA-PIN 

Anzeige z.B. 




Erzeugen 


Rückgabe an 

KDN-SW 

Abbildung 14: Dialoginitialisierung beim AZS-Verfahren S-Fkt=812 (1 von 2)



Kapitel: 

Abschnitt: 



Version: 

Stand: 

15.12.2009 

3.0 

Kapitel: 

Seite: 

43 

B 


Signatur prüfen, 



ggf. BPD, 

AZS-Verfahren 

für den Kunden, 

Antwort signieren 


inkl. 

HKAZS-Segment 

für 

Sfk=812, SP=6 

Übertragen Dial-Ini- 

Antwort inkl. 

HIAZS-Segment 

für 

Sfk=812, SP=7 

Einstellen 

VisDataSig 


HKAZS-Segment 

Einstellen 

BenKennung 

in HKIDN und 

Defaults in 

HNSHK/HNSHA 




und HIVISS 

übernehmen 

Aufruf SecCmd 


an Secoder 

Einstellen 

VisAuthSig 

in HKAZS 

Erzeugen 

VisAuthSig 

mit vorh. VisData 

Abbildung 15: Dialoginitialisierung beim AZS-Verfahren S-Fkt=812 (2 von 2) 


Dialoginitialisierung bei Sicherheitsfunktion 812 


 

 

 

Der Kunde ist vollständig initialisiert und seine Karte ist frei geschaltet (über 

Zertifikate oder Ini-Brief-Austausch). Dieser Vorgang wird über das Standard 

RDH-Verfahren mit Sicherheitsfunktion=1 durchgeführt. 



ein konkretes Ein-Schritt-Verfahren für den gesamten Dialog gewählt. 




Schritt 1a 

HKIDN, 

HKAZS 



HKIDN (Benutzerkennung, KundenID, usw.) eine Struktur auf. 

Als Signaturalgorithmus wird ein geeignetes (BPD) Sicherheitsprofil 

selektiert. Über die Segmente Signaturkopf, Identifikation, 

Verarbeitungsvorbereitung und ggf. Anforderung öffentlicher 

Schlüssel wird entsprechend den Angaben im Sicherheitsprofil, 

das in den Verschlüsselungskopf eingestellt wird, ein Auftragshashwert 

erzeugt. Falls die Länge des Hashwerts nicht der 

Blocklänge entspricht, wird dieser wird mit Nullen aufgefüllt. 

Es erfolgt ein Zugriff auf den Secoder im Default-Modus. Beim

Kapitel: 

Seite: 

B 

44 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abschnitt: 



Schritt 1b 

HIAZS 

ersten Zugriff wird der Kunde aufgefordert, sein CSA-Passwort 

einzugeben. 





werden. 

Anschließend wird der aktuelle Signaturzähler des Signier- 

Schlüssels ermittelt, inkrementiert und in das Datenelement Sicherheitsreferenznummer 

im Signaturkopf eingestellt. Auch die 

restlichen benötigten Werte wie z. B. CID, Schlüsselnummer, 

Schlüsselversion und ggf. Kunden-Zertifikat des Signierschlüssels 

werden auf diese Weise ermittelt und für die spätere Auftragsverarbeitung 

im Kundensystem gespeichert. 

Auf Basis der Informationen aus HIAZSS und HIVISS erzeugt 

das Kundensystem die benötigten SecCmds, um Visualisierungsinformationen 

und den Auftragshashwert zu übergeben 

und am Secoder im Applikationsmodus „aut“ eine VisData- 

Signatur mit Visualisierung der relevanten Daten aus HIVISS 

durchzuführen. Hierbei wird der VisData-Puffer sukzessive mit 

den Ergebnissen des Visualisierungsprozesses aufgefüllt. Nach 

der letzten Bestätigung des Kunden wird – beginnend mit dem 

Auftragshashwert als Initialwert – in der Karte ein Hashwert 

über den VisData-Puffer gebildet. Das Ergebnis dieser 

Hashoperation wird an den Secoder zurückgegeben und ersetzt 

den Inhalt des VisData-Puffers. 

Über den erzeugten Hashwert wird dann eine VisData-Signatur 

mit dem Signierschlüssel gebildet und vom Secoder ggf. inklusive 

des Kunden-Zertifikats an die aufrufende Applikation zurückgegeben. 

Die Signatur wird dort in die bereits vorbereitete 

HKAZS-Struktur in das Datenelement Signaturdaten eingestellt. 














inklusive VisDataSig und VisAuthSig HBCI-verschlüsselt zum 



Nach Überprüfung von VisDataSig und VisAuthSig wird eine 

Dialoginitialisierungsantwort aufgebaut.



Kapitel: 

Abschnitt: 



Version: 

Stand: 

15.12.2009 

3.0 

Kapitel: 

Seite: 

45 

B 

In das HIAZS Antwortsegment wird bei S-FKT=812 in das DE 

Signaturdaten eine Institutssignatur nach RDH eingestellt und 

mit Signatur-Prozess=7 HBCI-verschlüsselt an das Kundenprodukt 

übertragen. 

Das Kundensystem wertet nach der Entschlüsselung und Signaturprüfung 

die Kreditinstitutsantwort aus und zeigt dem Kunden 

die Begrüßungsseite an. 

B.2.2.2.3.2 Auftragseinreichung bei Sicherheitsfunktion 812 


Basis des zugrunde liegenden Auftrags offline erzeugt und an den Secoder übertragen. 

Der Kunde fügt – nach Kontrolle und Bestätigung des Datenextraktes im Secoder-Display 

- eine fortgeschrittene Signatur an. Diese wird zusammen mit dem Auftrag 

an das Institut gesendet. 



VisAuthSig 

prüfen 

analog BPD 


Antwort signieren 

und senden 


Übertragen Auftrag 

und 

HKAZS-Segment 


Auftrag 

verarbeiten 

Ermitteln 

MetaData für GV 

aus HIAZSS 

und HIVISS (BPD) 

Einstellen 

VisDataSig 


HKAZS-Segment 

Einstellen 

VisAuthSig 

in HKAZS 


Rückmeldungen 

anzeigen 

Umsetzung 

MetaData nach 

Secoder-Cmds 

(inkl. 


Übergabe 

VisAuthData 

an Secoder 

Anzeige 

VisAuftrag und 

Bestätigen/ 

Ergänzen 


Erzeugen 


Rückgabe an 

KDN-SW 

Erzeugen 

VisAuthSig 

Abbildung 16: Auftragseinreichung beim AZS-Verfahren, S-Fkt=812

Kapitel: 

Seite: 

B 

46 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abschnitt: 



Auftragseinreichung bei Sicherheitsfunktion=812 


 




Schritt 1a 

HKUEB, 

HKAZS 


Im Kundenprodukt wird eine HKAZS-Struktur aufgebaut. Hierbei 

wird in das Datenelement Signaturreferenznummer im Signaturkopf 

der zwischengespeicherte und um 2 (VisDataSig und 

VisAuthSig) inkrementierte Signaturzähler eingestellt. 


BPD die benötigten SecCmds und sendet diese zusammen mit 

dem Auftragshashwert über Signaturkopf und fachliches Segment 

(z. B. HKUEB) an den Secoder im Applikationsmodus 

„aut“. Falls die Länge des Hashwerts nicht der Blocklänge entspricht, 

wird dieser wird mit Nullen aufgefüllt. 

Wie bei der Dialoginitialisierung beschrieben wird auch hier der 

VisData-Puffer sukzessive mit Informationen aus dem Secoder- 

Visualisierungsprozess gefüllt. Aus den Ergebnissen wird – mit 

dem Hashwert über die Auftragsdaten startend – ein Hashwert 

über die Visualisierungsdaten gebildet, der den Inhalt des Vis- 

Data-Puffers ersetzt. Über diesen Hashwert wird mit Hilfe des 

Signierschlüssels eine VisData-Signatur erzeugt. 

Die Kontrolle wird an das aufrufende Programm zurückgegeben 

und die VisData-Signatur in das DE Signaturdaten in HKAZS 

eingestellt. 












Der fachliche Geschäftsvorfall (z. B. HKUEB) wird zusammen 

mit HKAZS mit der Belegung gemäß Signatur-Prozess=6 inklusive 

VisDataSig und VisAuthSig HBCI-verschlüsselt zum Institut 

übertragen. 

Schritt 1b 

z. B. 

HIRMS zu 

HKUEB 




Es wird eine Auftragsantwort aufgebaut, die ggf. erzeugte Antwortsegmente 

sowie die Rückmeldungen zur Signatur-Prüfung



Kapitel: 

Abschnitt: 



Version: 

Stand: 

15.12.2009 

3.0 

Kapitel: 

Seite: 

47 

B 

und zum Auftrag selbst enthält. 

In das HIAZS Antwortsegment wird bei S-FKT=812 in das DE 

Signaturdaten eine Institutssignatur nach RDH eingestellt und 

mit Signatur-Prozess=7 HBCI-verschlüsselt an das Kundenprodukt 

übertragen. 

Das Kundensystem wertet nach der Entschlüsselung und Signaturprüfung 

die Kreditinstitutsantwort aus. 

B.2.2.2.4 

Ein-Schritt-AZS-Verfahren mit EMV Application Cryptogram (EMV-AC) 

Im Rahmen der AZS-Verfahren ist es auch möglich, die TAN-Generator-Anwendung 

der Bankensignaturkarte zu verwenden, um ein EMV Application Cryptogram (EMV- 

AC) zur Absicherung der Daten zu verwenden. Obwohl die Secoder-Application 

„tan“ zum Einsatz kommt, ist das Resultat der Kryptogrammbildung ein volles EMV 

Application Cryptogram und keine TAN, da der Secoder über keine Komprimierungs- 

und Dezimalisierungsfunktion verfügt. Die Verwendung des kompletten EMV- 

AC hat aber auch den Vorteil, dass das gesamte Kryptogramm inklusive aller administrativen 

Daten wie z. B. dem kompletten ATC zum Kreditinstitut übertragen werden 

kann und somit keine Synchronisation wie bei einem nicht angeschlossenen 

TAN-Generator (HHD) notwendig ist. 

Da bei der EMV-AC-Verarbeitung keine Signaturfunktion „aut“ zur Verfügung steht, 

kann auch keine Visualisation Authentication durchgeführt werden, d. h. es kann 

nicht auf technischem Wege überprüft werden, ob sich ein angeschlossener Secoder 

im Applikationsmodus befunden hat. Aus dem gleichen Grund ist es auch nicht 

möglich, eine Instituts-seitige Signatur zu verwenden, da die Applikation „tan“ nur 

zur Erzeugung von Kryptogrammen verwendet werden kann. 



BPD mitgeteilt werden. 

Die Absicherung der TAN-Applikation auf der Karte kann wahlweise durch die Eingabe 

einer Offline-Benutzer-PIN abgesichert werden, wenn diese durch den Kunden 

aktiviert wurde. Die Offline-Benutzer-PIN kann derzeit nur zusätzlich zur Online- 

Banking-PIN verwendet werden, da im ZKA noch keine Regelungen zur Ablösung 

der Online-Banking-PIN definiert wurden. In den im Folgenden dargestellten Abläufen 

ist jedoch bereits ein solches Szenario mit reiner Offline-PIN-Prüfung dargestellt. 

Der Einsatz eines solchen Szenarios mit reiner Offline-PIN-Prüfung kann jedoch erst 

nach entsprechenden grundsätzlichen ZKA-Festlegungen zum Ersatz der Online- 

Banking-PIN erfolgen. 

Die nächsten beiden Abschnitte befassen sich mit der Dialoginitialisierung bei der 

EMV-AC-Variante. Dabei wird zwischen zwei Verfahren unterschieden: 

 

Verwendung der Online-Banking-PIN 

Dieses Szenario entspricht den gängigen PIN/TAN-Verfahren. Es kommt eine 

statische PIN zum Einsatz, die in Verbindung mit der Benutzerkennung zur Authentikation 

des Kunden verwendet wird. Dabei wird die Dialoginitialisierung wie 

ein normaler Auftrag behandelt, d. h. die Dialoginitialisierung wird über ein EMV- 

AC abgesichert, in das bestimmte Daten des FinTS-Segmentes „Verarbeitungsvorbereitung“ 

wie z. B. die Benutzerkennung über die BPD gesteuert einfließen. 

Zur Authentikation ist somit das Wissen der PIN und der Besitz der zugehörigen

Kapitel: 

Seite: 

B 

48 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abschnitt: 



 

Bankensignaturkarte Voraussetzung. Nach erfolgter Dialoginitialisierung können 

alle nicht-TAN-pflichtigen Geschäftsvorfälle durchgeführt werden. 

Verwendung der Offline-Benutzer-PIN der EMV-AC-Application 

Bei diesem Szenario wird die Online-Banking-PIN durch die Benutzer-PIN der 

EMV-AC-Applikation der Bankensignaturkarte ergänzt bzw. sie ersetzt diese. 

Der Prozess der Absicherung der Dialoginitialisierung ist identisch, d. h. es wird 

ebenfalls ein EMV-AC mit Daten aus dem Segment „Verarbeitungsvorbereitung“ 

gebildet, jedoch muss am Kundensystem nur die Benutzerkennung eingegeben 

werden, die Eingabe der Online-Banking-PIN erfolgt zusätzlich oder entfällt. 

Voraussetzung für diese Betriebsart ist, dass die Verwendung der Benutzer-PIN 

für die EMV-AC-Anwendung organisatorisch zwingend vorgegeben ist, damit 

keine Initialisierung ohne PIN erfolgen kann. Ist die Benutzer-PIN gesetzt, muss 

sie entweder vor jeder EMV-AC-Operation neu eingegeben werden, oder sie 

kann über einen Zeitparameter gesteuert die TAN-Applikation für einen längeren 

Zeitraum freischalten. Nach erfolgter Dialoginitialisierung können alle nicht-TANpflichtigen 

Geschäftsvorfälle durchgeführt werden. 

B.2.2.2.4.1 

Dialoginitialisierung mit Online-Banking-PIN 

Zusammen mit der Dialoginitialisierung wird ein Geschäftsvorfall HKAZS ausgetauscht, 

um zunächst die kundenseitige Authentikation durchzuführen. Die Online- 

Banking-PIN wird wie beim FinTS-Sicherheitsverfahren PIN/TAN in das Datenelement 

„PIN“ im Signaturabschluss eingestellt. 

Zur zusätzlichen Absicherung der Dialoginitialisierung wird über die Secoder- 

Anwendung „tan“ ein EMV-AC aus den administrativen Daten der Bankensignaturkarte 

und zusätzlich visualisierten Daten aus dem Segment „Verarbeitungsvorbereitung“ 

wie z. B. Benutzerkennung oder Kunden-ID gebildet. 

Das EMV-AC und die Visualisierungsdaten werden über HKAZS transportiert.



Kapitel: 

Abschnitt: 



Version: 

Stand: 

15.12.2009 

3.0 

Kapitel: 

Seite: 

49 

B 

S-Fkt= 820; „EMV-AC mit Online-Banking-PIN“ 

ATC 

Benutzerkennung, 

Kunden-ID 

Anmeldename: 

EMV-AC 

Online-Banking 

PIN: 

HKAZS Vis. Daten EMV-AC HNSHA PIN 

Secoder 

Abbildung 17: Szenario EMV-AC – Ablauf und Belegung der Segmente bei Verwendung 

der Online-Banking-PIN, S-Fkt=820

Kapitel: 

Seite: 

B 

50 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abschnitt: 



Der resultierende Prozess sieht folgendermaßen aus. 

Sie erzeugt die benötigten SecCmds, um am Secoder ein EMV- 


OBankingPIN 

prüfen, EMV-AC 

prüfen, 

BPD und UPD- 

Version prüfen 


ggf. BPD 

AZS-Verfahren 



inkl. 

HKAZS-Segment 

für 

Sfk=820, SP=6 


KDN-SW baut 


HKAZS-Segment 

auf 


für HKVVB 

aus HIVISS 

(BPD) 

Eingabe 


und OBanking-PIN 

am Kunden-PC 

Einstellen 

Ben-Kennung 

in HKIDN 

und OBanking-PIN 

in HNSHA 



und HIVISS 

übernehmen 

Umsetzung 

MetaData nach 

Secoder-Cmds 

(inkl. 


Einstellen 

EMV-AC in 

HKAZS-Segment 

der Dial-Ini 

Anzeige z.B. 




Erzeugen 

EMV-AC und 

Rückgabe an 

KDN-SW 

Abbildung 18: Dialoginitialisierung EMV-AC-Verfahren mit Online-Banking-PIN, 

S-Fkt=820 




 

 

 

 

Der Kunde ist vollständig initialisiert, seine Karte ist frei geschaltet und eine 

Bankensignaturkarte für EMV-AC zugeordnet. 

Die Dialoginitialisierungsnachricht wird mit Defaultwerten aufgebaut, wie in der 

FinTS PIN/TAN Spezifikation beschrieben; der Kunde hat dort durch entsprechende 

Belegung des DE „Sicherheitsfunktion, kodiert“=820 das „EMV-AC- 

Verfahren mit Online-Banking-PIN“ für den gesamten Dialog gewählt. Die Online-Banking-PIN 

wird in das Datenelement „PIN“ im Signaturabschluss eingestellt. 


zum Aufbau der SecCmds ermittelt werden können. Ggf. muss 


Der Kunde hat in der Online-Banking-Applikation seine Benutzerkennung, ggf. 

die Kunden-ID und sein Online-Banking-Passwort als Anmeldeinformation eingegeben. 

Schritt 1a 

HKIDN, 

HKAZS 



HKIDN (Benutzerkennung, KundenID, usw.) gemäß den Vorgaben 

aus der BPD (HIVISS) eine Struktur auf.



Kapitel: 

Abschnitt: 



Version: 

Stand: 

15.12.2009 

3.0 

Kapitel: 

Seite: 

51 

B 

Schritt 1b 

HIAZS 

AC mit entsprechender Visualisierung durchzuführen. Der Kunde 

wird aufgefordert, seine Anmeldedaten an der Leser- 

Tastatur zu vervollständigen bzw. zu bestätigen. 

Über die Anmeldeinformationen wird ein EMV-AC gebildet und 

vom Secoder an die aufrufende Applikation zurückgegeben. 

Dort werden die erhaltenen Werte in eine HKAZS-Struktur eingefügt. 


gemäß Signatur-Prozess=6 wird das EMV-AC SSLverschlüsselt 

zum Institut übertragen. 


Nach Überprüfung des EMV-AC wird eine allgemeine Kreditinstitutsnachricht 

aufgebaut und SSL-verschlüsselt an das Kundenprodukt 

übertragen. Es wird kein HIAZS-Antwortsegment 

übermittelt. 



B.2.2.2.4.2 

Dialoginitialisierung mit Offline-Benutzer-PIN 

Zusammen mit der Dialoginitialisierung wird ein Geschäftsvorfall HKAZS ausgetauscht, 

um zunächst die kundenseitige Authentikation durchzuführen. Wenn die 

Prüfung der Benutzer-PIN offline erfolgt, wird in das Datenelement „PIN“ im Signaturabschluss 

der definierte Füllwert „noPIN“ eingestellt, ansonsten wird wie bei S- 

FKT=820 verfahren. 

Zur zusätzlichen Absicherung der Dialoginitialisierung wird über die Secoder- 

Anwendung „tan“ ein EMV-AC aus den administrativen Daten der Bankensignaturkarte 

und zusätzlich visualisierten Daten aus dem Segment „Verarbeitungsvorbereitung“ 

wie z. B. Benutzerkennung oder Kunden-ID gebildet. Das EMV-AC und die Visualisierungsdaten 

werden über HKAZS transportiert.

Kapitel: 

Seite: 

B 

52 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abschnitt: 



S-Fkt= 821; „EMV-AC mit Benutzer-PIN (TAN-Generator“) 

Ben. PIN 

OK 

 

ATC 

BPIN 

Benutzerkennung, 

Kunden-ID 

EMV-AC BPIN 

Anmeldename: 

Online-Banking 

PIN: 

HKAZS Vis. Daten EMV-AC BPIN 

HNSHA „no PIN“ 

Secoder 

Abbildung 19: Ablauf und Belegung der Segmente bei Verwendung der Offline- 

Benutzer-PIN, S-Fkt=821 

Der resultierende Prozess sieht folgendermaßen aus: 


EMV-AC BPIN 

prüfen, 

BPD und UPD- 

Version prüfen 


ggf. BPD, 

AZS-Verfahren 



inkl. 

HKAZS-Segment 

für 

Sfk=821, SP=6 


KDN-SW baut 


HKAZS-Segment 

auf 


für HKVVB 

aus HIVISS 

(BPD) 

Eingabe 


am Kunden-PC 

Einstellen 

Ben-Kennung 

in HKIDN und 

„NoPIN“ in HNSHA 



und HIVISS 

übernehmen 

Umsetzung MetaData 

nach Secoder-Cmds 

(inkl. Auftragshashwert) 

Einstellen 

EMV-AC BPIN 

in HKAZS-Segment 

der Dial-Ini 


Prüfung der 

Benutzer-PIN 

Anzeige z.B. 




Erzeugen 

EMV-AC BPIN und 

Rückgabe an 

KDN-SW 

Abbildung 20: Dialoginitialisierung EMV-AC-Verfahren mit Offline-Benutzer-PIN, 

S- Fkt=821



Kapitel: 

Abschnitt: 



Version: 

Stand: 

15.12.2009 

3.0 

Kapitel: 

Seite: 

53 

B 




 

 

 

 

Der Kunde ist vollständig initialisiert, seine Karte ist frei geschaltet und eine 

Bankensignaturkarte für EMV-AC zugeordnet. Die Benutzer-PIN der EMV-AC- 

Applikation ist aktiviert. 

Die Dialoginitialisierungsnachricht wird mit Defaultwerten aufgebaut, wie in der 

FinTS PIN/TAN Spezifikation beschrieben; der Kunde hat dort durch entsprechende 

Belegung des DE „Sicherheitsfunktion, kodiert“=821 das „EMV-AC- 

Verfahren mit Offline-Benutzer-PIN“ für den gesamten Dialog gewählt. Wird 

die Online-Banking-PIN nicht verwendet, so wird in das Datenelement „PIN“ im 

Signaturabschluss der definierte Füllwert „noPIN“ eingestellt. Ansonsten erfolgt 

die Belegung wir bei S-Fkt=820. 


zum Aufbau der SecCmds ermittelt werden können. Ggf. muss 


Der Kunde hat in der Online-Banking-Applikation seine Benutzerkennung und 

ggf. die Kunden-ID als Anmeldeinformation eingegeben. 

Schritt 1a 

HKIDN, 

HKAZS 

Schritt 1b 

HIAZS 



HKIDN (Benutzerkennung, KundenID, usw.) gemäß den Vorgaben 

aus der BPD (HIVISS) eine Struktur auf. Sie erzeugt die 

benötigten SecCmds, um am Secoder ein EMV-AC mit entsprechender 

Visualisierung durchzuführen. Der Kunde wird nach 

Eingabe und Offline-Prüfung der Benutzer-PIN aufgefordert, 

seine Anmeldedaten an der Leser-Tastatur zu vervollständigen 

bzw. zu bestätigen. 

Über die Anmeldeinformationen wird ein EMV-AC gebildet und 

vom Secoder an die aufrufende Applikation zurückgegeben. 

Dort werden die erhaltenen Werte in eine HKAZS-Struktur eingefügt. 


gemäß Signatur-Prozess=6 wird das EMV-AC SSLverschlüsselt 

zum Institut übertragen. 


Nach Überprüfung des EMV-AC wird eine allgemeine Kreditinstitutsnachricht 

aufgebaut und SSL-verschlüsselt an das Kundenprodukt 

übertragen. Es wird kein HIAZS-Antwortsegment 

übermittelt. 



B.2.2.2.4.3 

Auftragseinreichung beim Ein-Schritt-AZS-Verfahren mit EMV-AC 


Basis des zugrunde liegenden Auftrags und der in der BPD hinterlegten MetaData 

offline erzeugt und an den Secoder übertragen.

Kapitel: 

Seite: 

B 

54 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abschnitt: 



Der Kunde fügt – nach Kontrolle und Bestätigung des Datenextraktes im Secoder- 

Display – ein EMV-AC an. Dieses wird zusammen mit dem Auftrag an das Institut 

gesendet. 


VisAuftrag mit 

BPD-Vorgabe 

vergleichen 

EMV-AC prüfen 

Auftrag 

verarbeiten 

Übertragen 

Auftrag und 

HKAZS für 

Sfk=820/821, SP=6 

Ermitteln 

MetaData 

für GV aus 

HIVISS (BPD) 

Einstellen 

EMV-AC und 

VisAuftrag in 

HKAZS 

Umsetzung 

MetaData nach 

Secoder-Cmds 

(inkl. Auftragshashwert) 

Anzeige VisAuftrag 


bzw. Ergänzen 


Erzeugen 

EMV-AC und 

Rückgabe an 

KDN-SW 

Abbildung 21: EMV-AC-Kryptogramm mit Secoder, S-Fkt=820 und 821 

Auftragseinreichung bei EMV-AC-Kryptogramm 


 


Belegung des DE „Sicherheitsfunktion, kodiert“=820 bzw. 821 ein EMV-AC- 

Verfahren für den gesamten Dialog gewählt. 

Schritt 1a 

HKUEB, 

HKAZS 



BPD (HIAZSS, HIVISS) die benötigten Secoder-SecCmds und 

sendet diese zusammen mit dem Hashwert über den Auftrag an 

den Secoder. 

Dort wird zunächst die Secoder-Applikation „tan“ selektiert. Die 

über HIVISS definierten Auftragselemente werden entsprechend 

der Anweisungen aus den SecCmds angezeigt und 

durch den Kunden ergänzt bzw. bestätigt. Aus den Ergebnissen 

wird – mit dem Hashwert über die Auftragsdaten startend – ein 

Hashwert über die Visualisierungsdaten gebildet. 

Bei S-Fkt=821 wird – falls die TAN-Applikation nicht über einen 

Parameter für einen längeren Zeitraum freigeschaltet ist – vor 

jeder Erzeugung eines EMV-AC die Benutzer-PIN vom Kunden 

abgefragt und offline geprüft.



Kapitel: 

Abschnitt: 



Version: 

Stand: 

15.12.2009 

3.0 

Kapitel: 

Seite: 

55 

B 

Schritt 2b 

z. B. 

HIRMS zu 

HKUEB 

Bei S-Fkt=820 erfolgt keine PIN-Prüfung; hier muss über eine 

geeignete Benutzerführung am Secoder (z. B. „Auftrag signieren 

“) die Kryptogrammbildung gestartet werden. Gleiches 

gilt auch bei S-Fkt=821 und Verwendung eines Zeitparameters 

für die Benutzer-PIN. 

Die Kontrolle wird an das aufrufende Programm zurückgegeben; 

als Rückgabewerte wird das EMV-AC übergeben. 


mit der Belegung gemäß Signatur-Prozess=6 auf und sendet 

den unterschriebenen Auftrag SSL-verschlüsselt an das Institut. 

Nach erfolgreicher Prüfung des EMV-AC kann der Auftrag verarbeitet 

werden. 



erzeugte Antwortsegmente sowie die Rückmeldungen zur EMV- 

AC-Prüfung und zum Auftrag selbst SSL-verschlüsselt zum 

Kundenprodukt gesendet. Es wird kein HIAZS-Antwortsegment 

gesendet.

Kapitel: 

Seite: 

B 

56 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abschnitt: 


Geschäftsvorfall HKAZS für Ein- / Zwei-Schritt-AZS-Verfahren 

B.3 Geschäftsvorfall HKAZS für Ein- / Zwei-Schritt-AZS-Verfahren 

Dieser Geschäftsvorfall dient im Zwei-Schritt-Verfahren dazu, eine Qualifizierte Signatur 

zu einem Auftrag zu übermitteln oder im Ein-Schritt-Verfahren als Ergänzung 

des FinTS-Segmentes Signaturabschluss eine fortgeschrittene Signatur oder ein 

EMV-AC zu transportieren. 

 

 

Der Geschäftsvorfall HKAZS nimmt in FinTS eine Sonderrolle ein: 

HKAZS muss in BPD, UPD wie ein Geschäftsvorfall aufgeführt 

werden und besitzt mit HIAZSS auch Geschäftsvorfallparameter. 

Als Sonderbedingung wird HKAZS jedoch wie ein administratives 

Segment bei der Zählung im DE „Maximale Anzahl Aufträge“ pro 

Nachricht (vgl. [Formals], Kapitel D.6) nicht berücksichtigt. 

Durch Existenz dieses Geschäftsvorfalls HKAZS in der BPD und UPD wird grundsätzlich 

festgelegt, ob das Kreditinstitut AZS-Verfahren unterstützt bzw. ob dies für 

den Kunden zugelassen ist. 

Zusammen mit der Kreditinstitutsrückmeldung können abhängig vom verwendeten 

fachlichen Geschäftsvorfall auch Antwortsegmente zu diesem Auftrag 

übertragen werden. 

B.3.1 Aufbau des Geschäftsvorfalls HKAZS 

Der Geschäftsvorfall HKAZS wird verwendet, um beliebige digitale Signaturen von 

ZKA-Verfahren, die nicht das HBCI-Format verwenden, inklusive der zugehörigen 

Visualisierungsdaten transportieren zu können. Ausprägungen solcher Signaturverfahren 

können sein: 

- Qualifizierte Elektronische Signaturen ohne / mit Secoder (S-Fkt=800, 810) 

Signaturbelegungen in den Signaturdaten / Zertifikaten enthalten 

(aufgebaut nach ISIS-MTT) 

- Fortgeschrittene Elektronische Signaturen mit Secoder (S-Fkt=811, 812) 

Signaturbelegung nach HBCI 

- EMV-AC mit Online-Banking-PIN / Benutzer-PIN (S-Fkt=820, 821) 

Signaturbelegung nach HBCI 

Sonderbelegungen der HBCI-Sicherheitssegmente für alle AZS-Verfahren sind in 

den Abschnitten B.5.2 und C enthalten.



Kapitel: 

Abschnitt: 

Verfahren 


Geschäftsvorfall HKAZS für Ein- / Zwei-Schritt-AZS- 

Realisierung Bank: 

Realisierung Kunde: 

a) Kundenauftrag 

Version: 

Stand: 

15.12.2009 

3.0 

Kapitel: 

Seite: 

57 

verpflichtend, wenn Geschäftsvorfälle mit Absicherung 

über alternative Signaturverfahren angeboten werden 

verpflichtend, wenn Geschäftsvorfälle mit Absicherung 

über alternative Signaturverfahren unterstützt werden 

sollen 

B 

 

Format 

Name: 

Alternative ZKA Sicherheitsverfahren 

Typ: 

Segment 

Segmentart: Geschäftsvorfall 

Kennung: HKAZS 

Bezugssegment: - 

Segmentversion: 1 

Sender: Kunde 

Nr. Name 

Typ Formatuzahl 

Länge Sta- 

An- 

Restriktionen 

1 Segmentkopf DEG M 1 

2 Signatur-Prozess DE code 1 M 1 2, 3, 4, 5, 6, 7 

3 Sicherheitsprofil DEG C 1 M: bei S-Fkt=811, 812, 820, 

821 

N: sonst 

4 Sicherheitskontrollreferenz 

DE an ..14 M 1 

5 SAK- 

Visualisierungsdaten 

6 Visualisierungsbestätigungssignaturdaten 

DE bin ..2MB C 1 M: bei S-Fkt=800, 810 und 

Signatur-Prozess=2, 5 

N: sonst 

DE bin ..4KB C 1 M: bei S-Fkt=810, 811, 812 

und Signatur-Prozess=2, 5, 

6 

N: sonst 

7 Signaturdaten DE bin ..4KB C 1 M: bei Signatur-Prozess=2, 

5, 6 und für S-Fkt=811, 812 

bei Signaturprozess=7 

N: sonst 

8 Auftragsreferenz DE an ..35 C 1 M: bei S-Fkt=800, 810 und 


N: sonst 

9 Weitere Signatur folgt DE jn 1 C 1 M: bei Signatur-Prozess=2 

N: sonst 

10 Auftrag stornieren DE jn 1 C 1 O: bei S-Fkt=800, 810 und 

Signatur-Prozess=2 und 

„Auftragsstorno erlaubt“=J 

N: sonst 

11 SAK-Referenz DE num ..2 C 1 M: bei S-Fkt=800, 810 

N: sonst 

12 Aufsetzpunkt DE an ..35 O 1

Kapitel: 

Seite: 

B 

58 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abschnitt: 


Geschäftsvorfall HKAZS für Ein- / Zwei-Schritt-AZS-Verfahren 

 

Belegungsrichtlinien 

Signaturdaten 

Im Datenelement Signaturdaten existieren für Kundennachrichten drei Möglichkeiten 

der Belegung: 

Bei der Sicherheitsfunktion 800 wird das Kundenzertifikat nach ISIS-MTT 

(SAK-Signatur) eingestellt. 

Bei allen anderen Sicherheitsfunktionen befindet sich im Element „Signaturdaten“ 

die VisData-Signatur. 

Ausnahme: Bei den Sicherheitsfunktionen 811 und 812 wird für Key- 

Management-Nachrichten eine RDH-Signatur verwendet (vgl. Abschnitt 

C.1.3). 

b) Kreditinstitutsrückmeldung 

 

Format 

Name: 

Alternative ZKA Sicherheitsverfahren Rückmeldung 

Typ: 

Segment 


Kennung: 

HIAZS 

Bezugssegment: HKAZS 


Anzahl: 1 

Sender: 


Nr. Name 

Typ Formatuzahl 

Länge Sta- 

An- 

Restriktionen 


2 Signatur-Prozess DE code 1 M 1 2, 3, 4, 5, 7 

3 SAK- 

Visualisierungsdaten 

DE bin ..2MB C 1 O: bei S-Fkt=800, 810 und 

Signatur-Prozess=3, 4, 5 

N: sonst 

4 Signaturdaten DE bin ..4KB C 1 M: bei S-Fkt=800, 810, 812 

und Signatur-Prozess=3, 4, 

5, 7 

N: sonst 

5 Auftragsreferenz DE an ..35 C 1 M: bei S-Fkt=800, 810 und 


N: sonst 

6 Datum, Angebot gültig 

bis 

7 Uhrzeit, Angebot gültig 

bis 

DE dat C 1 O: bei S-Fkt=800, 810 und 


N: sonst 

DE tim C 1 O: bei S-Fkt=800, 810 und 


N: sonst



Kapitel: 

Abschnitt: 

Verfahren 

 


Geschäftsvorfall HKAZS für Ein- / Zwei-Schritt-AZS- 


Auftragsreferenz 

Version: 

Stand: 

15.12.2009 

3.0 

Kapitel: 

Seite: 

59 

Als Auftragsreferenz ist derjenige Wert einzustellen, der bei der Auftragseinreichung 

im Rahmen der Kreditinstitutsrückmeldung mitgeteilt wurde. 

Signaturdaten 

Im Datenelement Signaturdaten existieren für Kreditinstitutsnachrichten zwei 

Möglichkeiten der Belegung: 

Bei der Sicherheitsfunktion 800 und 810 wird das Institutszertifikat nach ISIS- 

MTT eingestellt. 

Bei der Sicherheitsfunktion 812 wird eine RDH-Institutssignatur verwendet. 

In allen anderen Fällen wird das DE „Signaturdaten“ nicht belegt. 

B 

 

Ausgewählte Beispiele für Rückmeldungscodes 

Code 

Beispiel für Rückmeldungstext 

0010 Auftrag entgegengenommen 

3921 Zugelassene AZS-Verfahren für den Benutzer 

(+ Rückmeldungsparameter) 

9210 Auftrag abgelehnt – Auftragsdaten inkonsistent. Eingereichter Auftrag gelöscht 

9210 Auftrag abgelehnt – Kein eingereichter Auftrag gefunden 

9210 Auftrag abgelehnt – Auftragsreferenz ist unbekannt 

9380 Gewähltes ZKA-Signatur-Verfahren nicht zulässig 

9931 Sperrung des Kontos nach x Fehlversuchen 

9941 Signatur ungültig 

9350 Zertifikat abgelaufen 

9351 Zertifikat gesperrt 

9352 Zertifikatseigner unbekannt 

9359 OCSP-Anfrage nicht beendet 

9330 Schlüsseleigner gesperrt 

9330 Schlüssel gesperrt 

9340 Signatur fehlerhaft 

9340 Sicherheitsprofil unbekannt 

9360 Signatur fehlerhaft - BPD nicht mehr aktuell

Kapitel: 

Seite: 

B 

60 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abschnitt: 


Erweiterung der Rückmeldungscodes 

c) Bankparameterdaten 

 

Format 

Name: 

Alternative ZKA Sicherheitsverfahren, Parameter 

Typ: 

Segment 

Segmentart: Geschäftsvorfallparameter 

Kennung: 

HIAZSS 

Bezugssegment: HKVVB 


Sender: 


Nr. Name 

Typ Formagtuzahl 

Län- 

Sta- 

An- 

Restriktionen 


2 Maximale Anzahl Aufträge DE num ..3 M 1 

3 Anzahl Signaturen mindestens 

DE num 1 M 1 0, 1, 2, 3 

4 Sicherheitsklasse DE code 1 M 1 0, 1, 2, 3, 4 

5 Parameter Alternative 

ZKA Sicherheitsverfahren 

DEG M 1 

B.4 Erweiterung der Rückmeldungscodes 

Bei Verwendung des AZS-Verfahrens können spezielle Rückmeldecodes vom Kreditinstitut 

zurückgemeldet werden, die rein AZS-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 

Code Beispiel für Rückmeldungstext 

0010 Auftrag entgegengenommen 

0030 Auftrag empfangen – Sicherheitsfreigabe erforderlich 

0030 Auftrag empfangen – Sicherheitsfreigabe erforderlich und Auftragsstorno möglich 

0031 Auftragsstorno durchgeführt 

Warnungen und Hinweise 


3918 Kompetenz nicht ausreichend – weitere Signatur erforderlich 

3921 Zugelassene AZS-Verfahren für den Benutzer 

(+ Rückmeldungsparameter) 

3950 Individuell 

-999 

Fehlermeldungen 


9210 Auftrag abgelehnt – Auftragsdaten inkonsistent. Eingereichter Auftrag gelöscht 

9210 Auftrag abgelehnt – Zwei-Schritt-Signatur inkonsistent. Eingereichter Auftrag gelöscht 

9210 Auftrag abgelehnt – Kein eingereichter Auftrag gefunden 

9210 Auftrag abgelehnt – Auftragsreferenz ist unbekannt



Kapitel: 

Abschnitt: 



Version: 

Stand: 

15.12.2009 

3.0 

Kapitel: 

Seite: 

61 

B 


9210 Auftrag abgelehnt – Kompetenz nicht ausreichend 

9330 Schlüsseleigner gesperrt 

9330 Schlüssel gesperrt 

9340 Signatur fehlerhaft 

9340 Sicherheitsprofil unbekannt 

9380 Gewähltes ZKA-Signatur-Verfahren nicht zulässig 

9931 Sperrung des Kontos nach x Fehlversuchen 

9931 Teilnehmersperre durchgeführt 

9941 Signatur ungültig 

9350 Zertifikat abgelaufen 

9951 Zeitüberschreitung im Zwei-Schritt-Verfahren – Signatur ungültig 

9351 Zertifikat gesperrt 

9352 Zertifikatseigner unbekannt 

9953 Nur ein Signatur-pflichtiger Auftrag pro Nachricht erlaubt 

9954 Mehrfach-Signaturen nicht erlaubt 

9956 Zeitversetzte Eingabe von Mehrfach-Signaturen nicht erlaubt 

9957 Wechsel des Signatur-Prozesses bei Mehrfach-Signaturen nicht erlaubt 

9359 OCSP-Anfrage nicht beendet 

9360 Signatur fehlerhaft – BPD nicht mehr aktuell 

B.4.1 Beschreibung spezieller Rückmeldungen im Zwei-Schritt-Verfahren 

Rückmeldungscode 0030: Auftrag empfangen – Sicherheitsfreigabe erforderlich 

Mit dem Rückmeldungscode 0030 als Antwort auf HKAZS wird bei Sicherheitsfunktion 

800 und 810 ein Zwei-Schritt-Verfahren eingeleitet. Als Folge auf diesen Rückmeldecode 

darf je nach Signatur-Prozess ausschließlich ein Geschäftsvorfall mit der 

zugehörigen Signatur übermittelt und kein neuer Signatur-Prozess eingeleitet werden. 

Unabhängig davon können PIN-pflichtige Geschäftsvorfälle, die keine Signatur 

erfordern zwischen den beiden Prozess-Schritten bearbeitet werden. 

Rückmeldungscode 3921: Zugelassene AZS-Verfahren für den Benutzer (+ 

Rückmeldungsparameter) 

Der Rückmeldungscode 3921 dient dazu, dem Kundenprodukt im Rahmen der Dialoginitialisierungsantwort 

die für den Benutzer zugelassenen AZS -Verfahren mitzuteilen. 

Hierzu werden in den Rückmeldungsparametern P1 bis P10 entsprechend 

den zugelassenen Verfahren („800“ bis „899“) aus HIAZSS maximal zehn mögliche 

Ein- und Zwei-Schritt-Verfahren transportiert. 

 

Das 

Kundenprodukt muss – unabhängig vom gewählten Verfahren 

in „Sicherheitsfunktion, kodiert“ – bei jeder Dialoginitialisierung die 

vom Institut mit dem Rückmeldungscode 3921 ü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 zugelassen 

ist, so beendet das Kreditinstitut den Dialog mit Rückmeldungscode 

9800 in Kombination mit Code 3921 und meldet die 

aktuell zugelassenen Verfahren in den Parametern P1 bis P10.

Kapitel: 

Seite: 

B 

62 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abschnitt: 



Rückmeldungscode 9210: 

- Auftragsreferenz ist unbekannt bzw. 

- Auftrag abgelehnt – kein eingereichter Auftrag gefunden 

Diese Rückmeldung kann folgende Ursachen haben: 

 

 

 

Die eingereichte Auftragsreferenz bzw. der Auftrags-Hashwert wird im Auftragsbestand 

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 Signaturen erfordert, hat den maximalen 

Aufbewahrungszeitraum überschritten und wurde vom Institut gelöscht. 

Ein zugehöriger Auftrag, der mehrere Signaturen erfordert, wurde über einen 

anderen Vertriebsweg (außerhalb FinTS) autorisiert und ist inzwischen verarbeitet. 

Das Kreditinstitut sollte den wirklichen Grund für diese Rückmeldung 

in das Statusprotokoll einstellen, damit der Kunde sich später 

dort informieren und den Auftrag kundenseitig entsprechend weiter 

bearbeiten kann. 

Rückmeldungscode 9360: Signatur fehlerhaft – BPD nicht mehr aktuell 

Diese Rückmeldung bezieht sich speziell auf die Parametrisierung der Visualisierungsinformationen 

mit HIAZSS und HIVISS im Rahmen der Dialoginitialisierung. Es 

wird Instituts-seitig festgestellt, dass die Signaturprüfung fehlschlug, da das Kundensystem 

über keine aktuelle BPD verfügt. Die Kreditinstitutsnachricht wird analog 

den Informationen im Verschlüsselungskopf verschlüsselt und nicht signiert.



Kapitel: Verfahrensbeschreibung 

Abschnitt: Erweiterung der Bank- und Userparameterdaten (BPD / 

UPD) 

Version: 

Stand: 

15.12.2009 

3.0 

Kapitel: 

Seite: 

63 

B.5 Erweiterung der Bank- und Userparameterdaten (BPD / UPD) 

Für die Verwendung von AZS-Verfahren müssen dem Kundenprodukt weitere Daten 

im Rahmen der BPD- bzw. UPD-Segmentfolge übermittelt werden. So ist beispielsweise 

anzugeben, welche Geschäftsvorfälle über welches AZS-Verfahren abgesichert 

werden dürfen und wie die Visualisierung zu erfolgen hat. Hierfür existieren 

zwei zusätzliche Parametersegmente, welche die folgende Information transportieren: 

HIAZSS 

Parametersegment zu HKAZS 

In diesem Parametersegment werden grundsätzliche Mechanismen 

zu den AZS-Verfahren festgelegt: 

Welche AZS-Verfahren werden unterstützt? 

Welche Geschäftsvorfälle werden pro AZS-Verfahren unterstützt? 

Welche Signaturanwendungskomponenten werden in welchen 

Versionen unterstützt? 

B 

HIVISS 

Die vollständige Beschreibung von HIAZSS befindet sich in Abschnitt 

B.3.1. 

Secoder-spezifische Visualisierungsinformationen 

nur Parametersegment; enthält pro Geschäftsvorfall / Segmentversion 

und Sicherheitsfunktion die Informationen, welche Daten am Secoder 

in welcher Weise zu visualisieren sind 

Die Parametersegmente HIAZSS und HIVISS müssen nicht immer paarig auftreten; 

es sind folgende Konstellationen erlaubt: 

GV enthalten in … 

HIAZSS: nein 

HIVISS: nein 

HIAZSS: ja 

HIVISS: nein 

Ist ein Geschäftsvorfall in keinem der beiden Parametersegmente 

enthalten. so findet weder eine Secoder- 

Visualisierung, noch eine kundenseitige Signatur statt. 

Diese Variante ist für die AZS-Verfahren mit Sicherheitsfunktion 

800, 810, 820 und 821 erlaubt und kennzeichnet z. B. 

Abholaufträge, die nur im Rahmen der Dialogabsicherung mit 

Benutzerkennung und Online-Banking- bzw. Benutzer-PIN 

abgesichert werden und keine Interaktionen des Kunden am 

Secoder erfordern sollen. 

Ist ein Geschäftsvorfall nur im Parametersegment HIAZSS 

enthalten. so findet keine Secoder-Visualisierung statt, es 

wird jedoch eine kundenseitige Signatur gebildet. 


800, 811 und 812 erlaubt. 

Bei Sicherheitsfunktion 800 (Qualifizierte Signatur ohne Secoder) 

stellt diese Belegung den Standardfall für alle zu signierenden 

Geschäftsvorfälle dar.

Kapitel: 

Seite: 

B 

64 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abschnitt: 


Erweiterung der Bank- und Userparameterdaten (BPD / UPD) 

HIAZSS: nein 

HIVISS: ja 

HIAZSS: ja 

HIVISS: ja 

Bei Sicherheitsfunktion 811 und 812 wird im Default-Modus 

des Secoders eine RDH-Signatur (ohne Secodervisualisierung) 

gebildet und als Kundensignatur in das DE „Signaturdaten“ 

in HKAZS eingestellt. Das Sicherheitsniveau entspricht 

also dem des HBCI RDH-Verfahrens. Es sind keine 

Interaktionen des Kunden am Secoder erforderlich. 

nicht zulässig 

Ist ein Geschäftsvorfall in beiden Parametersegmenten vorhanden, 

so wird auf Basis dieser Informationen eine Secodersignatur 

mit Visualisierung gebildet. 


810, 811, 812, 820 und 821 erlaubt und stellt dort den 

Normalfall eines am Secoder zu visualisierenden und zu signierenden 

Geschäftsvorfalls dar. 

B.5.1 Secoder-spezifische Visualisierungsinformationen (HIVISS) 

Die für die Definition von AZS-Verfahren notwendige BPD-/UPD-Erweiterung zur Visualisierung 

von Auftragsdaten am Secoder wird in Form eines speziellen Parametersegmentes 

realisiert, welches sich auf keinen echten Geschäftsvorfall bezieht, 

sondern Daten zu allen unterstützten Geschäftsvorfällen aufnehmen kann. 

Das Spezialsegment HIVISS wird verwendet, um in die BPD-Segmentfolge Secoder-spezifische 

Visualisierungsdaten einzufügen. Aufgrund seines Aufbaus analog 

zu einem Segmentparametersegment wird es von Kundenprodukten, die keine AZS- 

Verfahren unterstützen, ignoriert, da es sich auf einen ihnen unbekannten Geschäftsvorfall 

zu beziehen scheint. 

Die in HIAZSS aufgeführten Geschäftsvorfälle dürfen vom Kunden in über AZS- 

Verfahren abgesicherte Nachrichten eingestellt werden, sofern sie in den BPD und 

UPD als generell erlaubt hinterlegt sind. Alle übrigen Geschäftsvorfälle können mit 

AZS-Verfahren nicht verwendet werden. 

Während HIAZSS die Segmentkennungen aller über AZS-Verfahren abgesicherten 

Geschäftsvorfälle enthält, treten in HIVISS nur die Geschäftsvorfälle auf, welche eine 

Visualisierung am Secoder benötigen. Reine Abholaufträge sind i. A. nicht in 

HIVISS enthalten. 

B.5.1.1 Generelles Secoder-Visualisierungskonzept mit HIVISS 

Das Visualisierungskonzept ist durch das Design des Secoders strikt vorgegeben. 

Im Speziellen gelten die Festlegungen der Secoder-Spezifikation [Secoder] und der 

„Best Practices – Data Confirmation“ [BP DataConf] inkl. der dort skizzierten Beispiele. 

Aus diesen Beispielen lassen sich für die Parametrisierung in der BPD drei 

grundsätzliche Anzeigedefinitionen ableiten (die Ausrichtung der Texte in der folgenden 

Abbildung sind exemplarisch).





UPD) 

Version: 

Stand: 

15.12.2009 

3.0 

Kapitel: 

Seite: 

65 

Aufgrund der Komplexität der dezentralen Visualisierungsaufbereitung 

mittels HIAZSS und HIVISS wird dringend empfohlen, dass die 

Secoder-Anwendungsfunktion, welche für die Umsetzung in die Secoder-Kommandos 

zuständig ist, über eine Trace-Funktion verfügt, 

um die Fehlersuche bei abweichenden Signaturergebnissen zu erleichtern. 

B 

Nr. 3 

Geschäftsvorfallspezifische Visualisierungsinformationen für Secoder 

Nr. 1 – Segmentkennung 

Nr. 2 – Segmentversion [oder „0“] 

Nr. 3 – Sicherheitsfunktion, kodiert [oder „0“] 

n 

Drei Typen von Anzeigedefinitionen 

B e z e i c h n u n g 1 

( B e z e i c h n u n g 2 ) 

B e z e i c h n u n g 1 

W e r t 1 

B e z . 1 : W e r t 1 

B e z . 2 : W e r t 2 

Abbildung 22: Struktur der geschäftsvorfallspezifischen Visualisierungsinformationen 

Im Folgenden wird generell von einer heute marktüblichen Displaygröße von 2 x 16 

Zeichen ausgegangen, wobei die Physik in der HIVISS-Definition keine Rolle spielt, 

sondern diese durch die Secoder-Anwendungsfunktion an die physischen Eigenschaften 

des verwendeten Secoders angepasst wird. Eine HIVISS-Anzeigedefinition 

umfasst eine Zeile, d. h. 1 x 16 Zeichen. Diese Einheit wird in der Secoder- 

Spezifikation als „Dataset (DS)“ bezeichnet. Somit beschreibt eine HIVISS- 

Anzeigedefinition genau ein Secoder Dataset. 

Pro Geschäftsvorfall können – abhängig vom zur Verfügung stehenden VisData- 

Pufferbereich im Secoder von derzeit maximal 512 Byte theoretisch bis zu 255 solcher 

Datasets verwendet werden. 

Die drei oben gezeigten typischen Anzeigedefinitionen haben folgende Bedeutung: 

1. Die erste Anzeigedefinition dient der Darstellung von einer oder zwei textuellen 

Bezeichnungen, die linksbündig dargestellt werden, z. B. die Texte „Einzelüberweis.“ 

und „Inland“. Als Sonderfall dieser Anzeigedefinition kann die 

zweite Displayzeile auch leer bleiben.

Kapitel: 

Seite: 

B 

66 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abschnitt: 



2. Die zweite Anzeigedefinition kombiniert eine Bezeichnung (z. B. den Text 

„Ziel-Konto“) in Zeile 1 und einen zugehörigen Wert (z. B. die Kontonummer 

des Begünstigten aus einem DTA-Satz) in Zeile 2. 

3. Mit der 3. Anzeigedefinition ist es möglich, je Zeile eine Bezeichnung und 

einen Wert darzustellen. 

Auf Basis dieser 3 Anzeigedefinitionen ist es möglich, sieben grundsätzliche Szenarien 

abzubilden, die i. W. den Beispielen aus den Best Practices in [BP DataConf] 

entsprechen. Die Anzeigedefinitionen verfügen über folgenden Befehlsvorrat 4 : 

Secodervisualisierung 

Index 

Display-Position 

Länge (Secoder- 

Text) 

Secoder-Text 

Länge Secoder- 

Eingabedaten 

Ausrichtung und 

Format Secoder- 

Eingabedaten 

Secoder-Padding 

Index des jeweiligen Secodervisualisierungstextes, der in 

den „geschäftsvorfallspezifischen Visualisierungsinformationen“ 

referenziert wird. 

Default: Keiner 

Ausrichtung des Dataset im Secoder-Display (Links, 

Rechts 5 ). Diese Angabe ist nötig, da die Secoder-Texte in 

der BPD nicht gepadded werden. 

Default: Links 

Länge des Secoder-Textes 

Default: 0 

Secoder-Text, entweder statisch durch die Anzeigedefinition 

selbst oder dynamisch aus den Auftragsdaten oder leer. 

Default: leer 

Soll ein Wert nicht nur bestätigt, sondern komplett eingegeben 

oder ergänzt werden, wird hierdurch die Länge der geforderten 

Eingabedaten am Secoder vorgegeben. 

Default: 0 

Dieser Parameter beschreibt die Ausrichtung bei der Eingabe 

der Daten (Textmodus oder Taschenrechnermodus) und die 

Verwendung des Kommas. 

Default: 

Textmodus, falls Länge (Secoder-Text) > 0 

Taschenrechnermodus, sonst 

Dieser Parameter beschreibt das Padding der Daten im Vis- 

Data-Puffer des Secoders. 

Default: 

E0 bei numerischen Daten 

EF bei alfanumerischen Daten 

4 Aus Gründen der besseren Lesbarkeit – vor allem in den Abbildungen – werden Begriffe wie „Secodervisualisierung 

Index“ auf „Index“ gekürzt. Die exakten Namen befinden sich im Data Dictiononary 

unter „Secodervisualisierungstexte“. 

5 Die im Secoderkonzept theoretisch mögliche Ausprägung „Mitte“ wird in FinTS nicht benutzt.





UPD) 

Version: 

Stand: 

15.12.2009 

3.0 

Kapitel: 

Seite: 

67 

Nähere Festlegungen zum konkreten Mapping zwischen HIVISS und Secoder- 

Kommandos befinden sich in Abschnitt B.5.1.2. 

Die Secodervisualisierungstexte beschreiben die Anzeigedefinitionen für n Datasets, 

die sequentiell am Secoder angezeigt und ergänzt bzw. bestätigt werden, bevor ein 

Secoder-Kryptogramm gebildet wird. 

Die Secodervisualisierung MetaData („Geschäftsvorfallspezifische Visualisierungsinformationen“) 

enthalten die Definitionen pro Geschäftsvorfall. 

Pro Geschäftsvorfall wird über Indizes auf die entsprechenden Secodervisualisierungstexte 

referenziert, wobei berücksichtigt werden muss, ob eine Abfrage oder 

Bestätigung ein- oder zweizeilig dargestellt wird. 

Da in den Secodervisualisierungstexten im Element Secoder-Text auch Variable – 

dargestellt durch den Platzhalter „#“ – enthalten sind, enthalten die Geschäftsvorfallspezifischen 

Visualisierungsinformationen die jeweiligen Werte hierfür (z. B. konkrete 

Kontonummer aus FinTS, DTA, SEPA …). 

B 

Index=1 

Index=1 

Index=2 

Index=3 

Index=3 

Anzeigedefinition 1 (AD1.1) 





Secodervisualisierungstexte 

HKUEB#0 

HKSUB#0 

HKCCS#0 

S-Fkt=0 

S-Fkt=0 

S-Fkt=0 

Index=1, Parms zu AD1.1 und AD1.2 

Index=2, Parms zu AD2.1 

Index=3, Parms zu AD3.1und AD3.2 

Geschäftsvorfallspezifische Visualisierungsinformationen 

Abbildung 23: Zusammenhang zwischen Secoder MetaData und Secodervisualisierungstexten 

B.5.1.1.1 

Element „Ausrichtung und Format von Secoder-Eingabedaten“ 

Die Ausrichtung der Secoder-Eingabedaten kann auf zwei Arten erfolgen: 

a) Textmodus 

Im Textmodus beginnt die Eingabe direkt hinter dem letzten Zeichen des Secoder- 

Textes, d. h. der Cursor blinkt an der ersten Stelle rechts vom Secoder-Text. Ist der 

Secoder-Text leer, blinkt der Cursor an Stelle 16 ganz rechts.

Kapitel: 

Seite: 

B 

68 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abschnitt: 



Jedes eingegebene Zeichen schiebt den Cursor um eine Position nach rechts, bis 

die vorgegebene Anzahl von Eingabezeichen erreicht ist. Der Secoder-Text und die 

bereits eingegebenen Zeichen werden nicht bewegt. 

Der Textmodus stellt die Default-Belegung dar, wenn ein Secoder-Text vorhanden 

ist. 

b) Taschenrechnermodus 

Im Taschenrechnermodus blinkt der Cursor grundsätzlich an Position 16 der Zeile 

ganz rechts, auch wenn ein Secoder-Text vorhanden ist. Jedes eingegebene Zeichen 

schiebt die bereits vorhandenen Zeichen (ggf. Secoder-Text und Eingabezeichen) 

um eine Position nach links. 

B.5.1.1.2 

Der Taschenrechnermodus stellt die Default-Belegung dar, wenn kein Secoder-Text 

vorhanden ist. 

Repräsentative Beispiele zum Secoder-Visualisierungskonzept 

Die folgenden Kapitel beschreiben die Parametrisierung anhand von sieben repräsentativen 

Konstellationen, wie sie auch in den Secoder Best Practices 

[BP_DataConf] verwendet werden. Das Mapping der FinTS-Definitionen in die 

SecCmds ist mit der dort beschriebenen Syntax der Secoder Data Confirmation vorzunehmen. 

Hinweis: Das Ergänzen von Daten kann ausschließlich bei den Sicherheitsfunktionen 

820 und 821 verwendet werden; bei allen anderen Sicherheitsfunktionen kann 

nur eine Bestätigung von Daten erfolgen.





UPD) 

Version: 

Stand: 

15.12.2009 

3.0 

Kapitel: 

Seite: 

69 

a) Szenario 1: Bestätigung statischer Werte, 2-zeilig 

Szenario 1 dient zur Darstellung statischer Werte im Display des Secoders. Die Anzeigedefinition 

lässt die Belegung beider Displayzeilen mit je einem maximal 16- 

stelligen Textstring zu. Die Bezeichnungen werden ohne Leerzeichen eingestellt. 

Über die Parametrisierung im Element „Display-Position“ wird eine entsprechende 

Ausrichtung erreicht. In den Beispielen werden wo immer möglich die Defaultwerte 

verwendet, um eine möglichst kompakte BPD-Modellierung zu erzielen. 

B 

Ü b e r w e i s u n g 

O K ? 

Aufbau der beiden zugehörigen Visualisierungstexte: 

Idx 

Dis- 

play- 

Pos 

Länge 

(Secoder- 

Text) 

Secoder- 

Text 

Länge Sec- 

Eingabe- 

Daten 


Fmt. Sec- 

Eingabedaten 

Secoder- 

Padding 

1 Def Def „Überweisung“ Def Def Def 

Idx 

Dis- 

play- 

Pos 

Länge 

(Secoder- 

Text) 

Secoder- 

Text 

Länge Sec- 

Eingabe- 

Daten 


Fmt. Sec- 

Eingabedaten 

Secoder- 

Padding 

1 R Def „OK?“ Def Def Def 

Die Bezeichnungen werden ohne Leerzeichen eingestellt. Über die Parametrisierung 

im Element „Display-Position“ wird eine entsprechende Ausrichtung erreicht. In 

den Beispielen werden wo immer möglich die Defaultwerte verwendet, um eine 

möglichst kompakte BPD-Modellierung zu erzielen.

Kapitel: 

Seite: 

B 

70 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abschnitt: 



b) Szenario 2: Bestätigung statischer Werte, 1-zeilig 

Szenario zwei beschreibt die Darstellung eines 1-zeiligen Textes im Secoder- 

Display. Der Kunde geht in diesem Fall ohne weitere Benutzerführung davon aus, 

dass er diesen Text bestätigen muss, bevor die Verarbeitung im Secoder fortgesetzt 

werden kann. 

Ü b e r w e i s u n g 

Aufbau des zugehörigen Visualisierungstextes: 

Idx 

Dis- 

play- 

Pos 

Länge 

(Secoder- 

Text) 

Secoder- 

Text 

Länge Sec- 

Eingabe- 

Daten 


Fmt. Sec- 

Eingabedaten 

Secoder- 

Padding 

2 Def Def „Überweisung“ Def Def Def 

Zu beachten ist, dass in FinTS nur die Secoderoption durch Wegfall des Dataset für 

die zweite Zeile unterstützt wird, nicht die Möglichkeit ein Dataset mit Länge 0 zu 

verwenden (dies würde zu einem unterschiedlichen Kryptogramm führen). 

c) Szenario 3: Auffüllen mit Ziffern, 2-zeilig 

In Szenario 3 wird in Zeile 1 ein statischer Text angezeigt. Zeile 2 enthält einen Teil 

der Kontonummer (des Begünstigten), die letzten 3 Stellen muss der Kunde ergänzen, 

bevor er den gesamten Ausdruck betätigen kann. 

K o n t o n u m m e r 

3 4 5 6 7 8 ▌ ̲ ̲ 


Idx 

Dis- 

play- 

Pos 

Länge 

(Secoder- 

Text) 

Secoder- 

Text 

Länge Sec- 

Eingabe- 

Daten 


Fmt. Sec- 

Eingabedaten 

Secoder- 

Padding 

3 Def Def „Kontonummer“ Def Def Def 

Idx 

Dis- 

play- 

Pos 

Länge 

(Secoder- 

Text) 

Secoder- 

Text 

Länge Sec- 

Eingabe- 

Daten 


Fmt. Sec- 

Eingabedaten 

Secoder- 

Padding 

3 R 6 # 3 Def Def 

In Zeile 1 wird der statische Text aus dem Element „Secoder-Text“ angezeigt. Zeile 

2 besteht aus einem dynamischen Text, was durch den Platzhalter „#“ im Element 

„Secoder-Text“ dargestellt ist. Der konkrete Wert für den Platzhalter wird durch die 

„Geschäftsvorfallspezifische Visualisierungsinformation“ festgelegt.





UPD) 

Version: 

Stand: 

15.12.2009 

3.0 

Kapitel: 

Seite: 

71 

d) Szenario 4: Eingabe von Ziffern, 2-zeilig 

Szenario 4 ist dadurch gekennzeichnet, dass der Wert in Zeile 2 komplett vom Kunden 

eingetippt werden muss. 

B 

A n z a h l 

1 3 ▌ 


Idx 

In Zeile 2 wird zusätzlich zur geforderten Datenlänge 5 (inklusive Komma) das Formatkennzeichen 

„05“ für die Darstellung von 2 Kommastellen am Secoder verwendet. 

Dis- 

play- 

Pos 

Länge 

(Secoder- 

Text) 

Secoder- 

Text 

Länge Sec- 

Eingabe- 

Daten 

In Zeile 2 wird die geforderte Länge der Eingabedaten angegeben. Alle anderen 

Werte entsprechen der Default-Belegung. 

e) Szenario 5: Eingabe von Komma-Zahlen, 2-zeilig 

Szenario 5 verwendet als Eingabe eine Kommadarstellung. 


Fmt. Sec- 

Eingabedaten 

Secoder- 

Padding 

4 Def Def „Anzahl“ Def Def Def 

Idx 

Dis- 

play- 

Pos 

Länge 

(Secoder- 

Text) 

Secoder- 

Text 

Länge Sec- 

Eingabe- 

Daten 


Fmt. Sec- 

Eingabedaten 

Secoder- 

Padding 

4 R Def Def 3 Def Def 

B e t r a g ̺ i n ̺ € 

4 7 , 0 ▌ 


Idx 

Dis- 

play- 

Pos 

Länge 

(Secoder- 

Text) 

Secoder- 

Text 

Länge Sec- 

Eingabe- 

Daten 


Fmt. Sec- 

Eingabedaten 

Secoder- 

Padding 

5 Def Def „Betrag in €“ Def Def Def 

Idx 

Dis- 

play- 

Pos 

Länge 

(Secoder- 

Text) 

Secoder- 

Text 

Länge Sec- 

Eingabe- 

Daten 


Fmt. Sec- 

Eingabedaten 

Secoder- 

Padding 

5 R Def Def 5 05 Def

Kapitel: 

Seite: 

B 

72 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abschnitt: 



f) Szenario 6: Verdeckte Eingabe, 2-zeilig 

In Szenario 6 wird im Fall der Sicherheitsfunktionen 820 und 821 die Verwendung 

der verdeckten Eingabe angewendet. 

B a n k i n g - P I N 

▌ * * * 


Idx 

Dis- 

play- 

Pos 

Länge 

(Secoder- 

Text) 

Secoder- 

Text 

Länge Sec- 

Eingabe- 

Daten 


Fmt. Sec- 

Eingabedaten 

Secoder- 

Padding 

6 Def Def „Banking-PIN“ Def Def Def 

Idx 

Dis- 

play- 

Pos 

Länge 

(Secoder- 

Text) 

Secoder- 

Text 

Länge Sec- 

Eingabe- 

Daten 


Fmt. Sec- 

Eingabedaten 

Secoder- 

Padding 

6 R Def Def 4 04 Def 

Die verdeckte Eingabe wird durch das Kennzeichen „04“ für die Darstellung am Secoder 

erreicht. 

g) Szenario 7: Auffüllen mit Ziffern in einer Zeile 

Szenario 7 stellt eine kompakte Darstellung der Eingabe von zwei Werten inklusive 

Beschreibung in je einem Dataset dar. 

P I N : ▌ * * * 

B e t r a g : 4 7 , 0 ▌ 


Idx 

Dis- 

play- 

Pos 

Länge 

(Secoder- 

Text) 

Secoder- 

Text 

Länge Sec- 

Eingabe- 

Daten 


Fmt. Sec- 

Eingabedaten 

Secoder- 

Padding 

7 Def 12 „PIN:“ 4 04 Def 

Idx 

Dis- 

play- 

Pos 

Länge 

(Secoder- 

Text) 

Secoder- 

Text 

Länge Sec- 

Eingabe- 

Daten 


Fmt. Sec- 

Eingabedaten 

Secoder- 

Padding 

7 Def 8 „Betrag:“ 5 05 Def 

Die Verwendung von Secoder-Text und Eingabe in einer Zeile wird durch die Kombination 

eines statischen Secoder-Textes „Betrag:“, der durch die Längenangabe „8“ 

mit Leerzeichen ergänzt wird, mit einer 5-stelligen Eingabe erreicht.





UPD) 

Version: 

Stand: 

15.12.2009 

3.0 

Kapitel: 

Seite: 

73 

Restriktion: 

Als Einschränkung bei diesem Szenario gilt, dass keine Kombination eines statischen 

Secoder-Textes (IM Beispiel „Betrag:“) mit einem dynamischen Textfragment 

(z. B. aus der DTA-Defintion), das dann noch manuell zu ergänzen wäre, möglich 

ist. Hierfür muss eine zweizeilige Darstellung pro Parameter gewählt werden. 

B 

B.5.1.2 Struktur des Parametersegmentes HIVISS 

Das Parametersegment HIVISS hat einen zweiteiligen Aufbau, der im Folgenden 

detailliert beschrieben ist: 

 

 

Abschnitt Nr. 1: Secoder Visualisierungstexte und Secoder MetaData 

Abschnitt Nr. 2: Geschäftsvorfallspezifische Visualisierungsinformationen 

Die generelle Struktur von HIVISS wird aus folgendem Diagramm ersichtlich: 

Nr. 1 


Secodervisualisierung Index 


Länge Secoder-Text 

Secoder-Text 

Länge Secoder-Eingabedaten 

Ausrichtung und Format Secoder-Eingabedaten 


Nr. 2 


Segmentkennung ,Segmentversion und Sicherheitsfunktion 

Secodervisualisierungstext Index 

Secodervisualisierung Finanzdatenformat 

Secodervisualisierung Position 

Abbildung 24: Aufbau des Parametersegmentes HIVISS

Kapitel: 

Seite: 

B 

74 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abschnitt: 



B.5.1.3 Tabelle der Secodervisualisierungstexte 

Im Display des Secoders können zunächst beliebige Texte angezeigt werden. Um 

jedoch Redundanzen zu vermeiden und die HIVISS möglichst kompakt zu halten, 

werden die verwendeten Texte und die Secoder MetaData in einer Tabelle jeweils 

bestehend aus Index, zugehörigem Text und MetaData zusammengefasst: 

L(Eingabedaten) 

Ausr.+Fmt 

Eing.Daten 

Secoder- 

Padding 

1; 

; 

; ; 

; 

; 

; 

1; 

R; 

; OK?; 

; 

; 

; 

2; 

; 

; Überweisung; 

; 

; 

; 

3; 

; 

; Kontonummer; 

; 

; 

; 

3; 

R; 

6; #; 

3; 

; 

; 

4; 

; 

; Anzahl; 

; 

; 

; 

4; 

R; 

0; ; 

3; 

; 

; 

L(Secoder- 

Text) 

Secoder- 

Text 

Index 

Display- 

Position 

Abbildung 25: Tabelle der Secodervisualisierungstexte und Secoder MetaData in 

HIVISS 

Die einzelnen Secodervisualisierungstexte können so über die Angabe des Index in 

den geschäftsvorfallspezifischen Visualisierungsdaten referenziert werden. Es können 

nur Texte dargestellt werden, die auch in der Tabelle der Secodervisualisierungstexte 

enthalten sind. 

Die Secoder MetaData sind vom Funktionsumfang so gestaltet, dass sie 1:1 in 

SecCmds umgesetzt werden können, wie sie in den Secoder Best Practices Data 

Confirmation [BP DataConf] beschrieben sind. 

Im Einzelnen sind folgende Werte möglich: 

Secodervisualisierung 

Index 

Index des jeweiligen Secodervisualisierungstextes, der in 

den „geschäftsvorfallspezifischen Visualisierungsinformationen“ 

referenziert wird. Da ein Dataset 1 x 16 Zeichen umfasst, 

werden 2 Anzeigedefinitionen benötigt, um z. B. 2 x 16 

Zeichen für die Darstellung von Bezeichnung und Wert eines 

Auftragsbestandteils am Secoder darzustellen. Hierbei weisen 

beide Anzeigedefinitionen denselben Index auf. Die Reihenfolge 

der Anzeigedefinitionen in der Tabelle der Secodervisualisierungstexte 

entspricht der Reihenfolge der Anzeige 

dieser Texte am Secoder.





UPD) 


Länge (Secoder- 

Text) 

Secoder-Text 

Länge Secoder- 

Eingabedaten 

Default: Keiner 

Version: 

Stand: 

15.12.2009 

3.0 

Kapitel: 

Seite: 

75 

Ausrichtung des Dataset im Display. Diese Angabe ist nötig, 

da die Secoder-Texte in der BPD nicht gepadded werden. 

Mögliche Werte sind: 

L: Links 

R: Rechts 

Die Secoder-Anwendungsfunktion kann über die Einstellung 

von DS X .L-VIS und der realen Displaygröße die gewünschte 

Ausrichtung einstellen. 

Default: Links 

Folgende Möglichkeiten existieren: 

1. Statischer Text , z. B. „Ziel-Konto:“ 

Hier ergibt sich die Länge implizit aus der Länge des 

Secoder-Textes und muss nicht angegeben werden 

(Default). 

2. Dynamischer Wert, z. B. „12345678“ 

Die Daten werden dynamisch aus dem Auftrag (z. B. 

DTA) übernommen und werden in der angegebenen 

Länge verwendet. In diesem Fall muss ein konkreter 

Wert für die Länge angegeben werden. 

Default: 0 

Für diesen Parameter existieren drei Ausprägungen: 

1. Statischer Text 

die Bezeichnung („Label“) des zu bestätigenden bzw. 

zu ergänzenden Wertes, z. B. „Ziel-Konto:“. 

2. Fester Anteil des dynamischen Werts 

Der zu bestätigende Wert selbst in Form des Platzhalters 

# bzw. dessen fester Anteil, z. B. „12345678“ 

bzw. „12345___“. 

3. Leer 

Es ist weder ein statischer Text noch ein fester Anteil 

eines dynamischen Wertes angegeben, d. h. der 

Kunde muss den Wert komplett eingeben. 

Statische Secoder-Texte stehen fest und ohne Padding in 

der BPD. Dynamische Werte (komplett oder anteilig) werden 

durch den Platzhalter „#“ repräsentiert. Pro Anzeigedefinition, 

die aus bis zu zwei Datasets mit identischem Index bestehen 

kann, kann maximal ein Platzhalter „#“ definiert werden. 

Default: leer 

Soll ein Wert nicht nur bestätigt, sondern komplett eingegeben 

oder ergänzt werden, wird hierdurch die Länge der geforderten 

Eingabedaten am Secoder vorgegeben. 

Hinweis: Das Ergänzen von Daten kann ausschließlich bei 

den Sicherheitsfunktionen 820 und 821 verwendet werden; 

bei allen anderen Sicherheitsfunktionen kann nur eine Bestä- 

B

Kapitel: 

Seite: 

B 

76 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abschnitt: 




Format Secoder- 

Eingabedaten 

tigung von Daten erfolgen. 

Default: 0 

Dieser Parameter beschreibt die Ausrichtung bei der Eingabe 

der Daten und die Verwendung des Kommas. Er entspricht 

dem Secoder-Parameter DS x .DCF (Details hierzu siehe unter 

[BP_DataConf]) und hat folgende Ausprägungen: 

00 Eingabeposition ist ab der ersten Stelle hinter dem 

Secoder-Text bzw. rechts, falls kein Secoder-Text 

vorhanden. 

01 Die Eingabe startet rechts (Taschenrechnermodus). 

04 Wie 00, jedoch werden die Eingaben verdeckt dargestellt. 

Dieses Format ist nur bei den Sicherheitsfunktionen 

820 und 821 zugelassen. 

03 

05 

07 

Wie 01, jedoch mit 1, 2 oder 3 Kommastellen. 


Default: 

00, falls Länge (Secoder-Text) > 0 

01, sonst 

Dieser Parameter beschreibt das Padding der Daten im Vis- 

Data-Puffer des Secoders und entspricht dem Secoder- 

Parameter DS x .VCI (Details hierzu siehe unter 

[BP_DataConf]) und hat folgende Ausprägungen: 

D0 

E0 

DF 

EF 

Numerische Daten (BCD) mit 0-Padding 

Numerische Daten (BCD) mit F-Padding 

Alfanumerische Daten (ISO 646) mit 0-Padding 

Alfanumerische Daten (ISO 646) mit F-Padding 

Default: 

E0 bei numerischen Daten 

EF bei alfanumerischen Daten 

Es bestehen die folgenden Zusammenhänge zwischen den MetaData-Defintionen 

und dem Aufbau des Secoder Data Confirmation Kommandos.





UPD) 

Version: 

Stand: 

15.12.2009 

3.0 

Kapitel: 

Seite: 

77 

B 

BPD-Parameter 

Index 

Secoder-Kommando 

keine Entsprechung 


keine Entsprechung, wird anhand 

DSx.LVIS und physischer Displaygröße 

umgesetzt 

Länge (Secoder-Text) 

DS x .L DB 

Secoder-Text Dataset x .Datablock x (DS x .DB x ) 

Länge Secoder-Eingabedaten DS x .L DB + L (Secoder-Eingabedaten) = 

Ausrichtung und Format Secoder- 

Eingabedaten 

DS x .L VIS 

DS x .DCF 

Ziffern/Buchstaben DCF = ´00´ / ´01´ 

Kommastellen K1 bis K3 DCF = ´03´/ ´05´/ ´07´ 

Asterisk DCF = ´04´ 


DS x .VCI 

Abbildung 26: Analogien zwischen MetaData und Secoder Data Confirmation 

B.5.1.4 Geschäftsvorfallspezifische Visualisierungsinformationen für Secoder 

Die Mechanismen zur Steuerung des Visualisierungsvorgangs im Rahmen des Parametersegmentes 

HIVISS werden durch die folgende Abbildung verdeutlicht. Dabei 

sind die Werte für Segmentversion und Sicherheitsfunktion mit „0“ als Default definiert, 

um die Anzahl der Einträge zu minimieren. Werden hierbei explizite Werte benutzt, 

um unterschiedliche Visualisierungen zu erreichen (z. B. Segmentversion #1 

und #2 und/oder S-Fkt= 811, 820 und 821), so muss pro Ausprägung eine eigene 

Definition vorhanden sein. 

Hinweise: 

1. Alle nicht explizit modellierten Segmentversionen bzw. Sicherheitsfunktionen 

werden analog dem Default-Eintrag behandelt. 

2. Für jede in HIAZSS angegebene Sicherheitsfunktion muss eine Definition 

(Default oder Explizit) in HIVISS vorhanden sein.

Kapitel: 

Seite: 

B 

78 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abschnitt: 



HIAZSS 

HIVISS 

HKUEB 

(S-Fkt=810, 811, 820) 

1;Secodervisualisierungstext 1 ; 

...; 

nnn;Secodervisualisierungstext nnn 


HKUEB#0 

S-Fkt=0 

1;;; 3;1;3,1; 5;1;6,1; 

HKUEB#0 S-Fkt=810 1;;; 3;1;3,1; 

HKSUB#0 

HKCCS#0 

S-Fkt=0 

S-Fkt=0 

1;;; 3;2;E.4; 5;2;E.8; 

1;;; 3;4;CdtrAcct.1; 5;4;Amt.1; 

Geschäftsvorfallspezifische Visualisierungsinformationen 

Abbildung 27: Definition der Secoder MetaData pro Geschäftsvorfall 

Das Parametersegment enthält im Abschnitt der Geschäftsvorfallspezifischen Visualisierungsinformationen 

pro Anzeigendefinition einen Eintrag mit folgendem Aufbau: 

Index 

Index auf den / die darzustellenden Visualisierungstext(e) in 

der Tabelle der Secodervisualisierungstexte. Die dort enthaltenen 

Texte (1 oder 2 Datasets) mit identischem Index werden 

in der dort definierten Reihenfolge abgearbeitet. 

Finanzdatenformat Kennzeichnung der Art des Finanzdatenformates wie z. B. 

FinTS, DTA oder SEPA; dies ist Voraussetzung für die Positionierung 

innerhalb eines Finanzdatenformates, um die zu 

visualisierenden Daten zu lokalisieren. Außer FinTS sind dort 

alle vorkommenden Finanzdatenformate definiert. 

Position 

Je nach Finanzdatenformat wird die Position des zu visualisierenden 

Elementes angegeben, z. B. 

FinTS: 3,1 3. DEG, 1. Datenelement 

DTA: E.4 4. Element im E-Satz 

SEPA: CdtrAcct.1 1. Vorkommen des Tag „CdtrAcct“ 

Je Anzeigedefinition kann maximal ein Positionsparameter 

festgelegt werden. Dieser ersetzt dann den Platzhalter „#“ an 

der entsprechenden Stelle des jeweiligen Secodervisualisierungstextes.





UPD) 

Version: 

Stand: 

15.12.2009 

3.0 

Kapitel: 

Seite: 

79 

Die einzelnen Einträge sind durch Semikolon getrennt, da sie syntaktisch in FinTS 

V3.0 nicht mehr darstellbar sind. Ein DE „Secodervisualisierung MetaData“ kann 

theoretisch bis zu 255 solcher Secoder-Visualisierungselemente aufnehmen; die 

Begrenzung erfolgt nur durch den Speicherplatz im Secoder (derzeit 512B). 

Da alle drei Informationen zwingend belegt werden müssen, können die einzelnen 

Secoder-Visualisierungselemente leicht identifiziert werden. 

B.5.1.5 Positionierung bei der Secodervisualisierung 

Abhängig vom jeweiligen Finanzdatenformat existieren unterschiedliche Adressierungsmöglichkeiten 

für die einzelnen Elemente im Format. Es handelt sich dabei im 

Regelfall um die Auswertung der Kundennachrichten, welche ein oder mehrere Finanzdatenformate 

enthalten können, d. h. ein Kundenprodukt kann – ‚offline‘ – vor 

der Einreichung des Auftrags auf Basis der BPD die Secodervisualisierungsdaten 

ermitteln. Gleiches gilt für Werte aus dem Segment HKIDN, welche im Rahmen der 

Dialoginitialisierung visualisiert werden können. 

Enthält die Kundennachricht mehrere Aufträge – in Form mehrerer FinTS-Elemente 

oder Sammelaufträge – so muss beim Aufbau der BPD darauf geachtet werden, 

dass ein Visualisierungselement ausgewählt wird, das sich auf alle Aufträge bezieht 

wie z. B. Summenwerte oder ein bestimmtes Auftreten eines Wertes im Auftrag. Iterationen 

von Visualisierungselementen über enthaltene Einzelaufträge – also die 

Anzeige mehrerer Instanzen eines Wertes im Secoder – sind nicht vorgesehen. 

Da durch die Definition im DE „Secodervisualisierung Finanzdatenformat“ eine Festlegung 

nur für ein Secoder-Visualisierungselement gemacht wird, können die Visualisierungsdaten 

für einen Auftrag auch aus unterschiedlichen Finanzdatenformaten 

bestehen, z. B. aus ggf. vorangestellten FinTS-Datenelementen und einem DTA- 

Format. 

B

Kapitel: 

Seite: 

B 

80 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abschnitt: 



B.5.1.5.1 

Positionierung bei FinTS-Formaten 

Bei FinTS-Formaten findet die Positionierung folgendermaßen statt: 

3,1 

Abbildung 28: Adressierung der Secodervisualisierungsdaten bei FinTS-Formaten 

Entsprechend der definierten Protokollhierarchie wird ein Datenelement durch seine 

Position im Segment beschrieben. Ausschlaggebend ist dabei die Nummerierung, 

die in der Geschäftsvorfallbeschreibung angegeben ist. 

Ein Datenelement auf Segmentebene wird durch die einstufige Adressierung 

 

beschrieben (z. B. ‚4‘ für ‚Name Empfänger‘ beim Segment Einzelüberweisung). 

Ein Gruppendatenelement in einer Datenelementgruppe wird durch die zweistufige 

Adressierung 

, 

beschrieben (z. B. ‚3,1‘ für ‚Konto-/Depotnummer Empfänger‘ in der DEG ‚Kontoverbindung 

Empfänger‘ beim Segment ‚Einzelüberweisung‘).





UPD) 

B.5.1.5.2 

Positionierung bei DTA 

Version: 

Stand: 

15.12.2009 

3.0 

Kapitel: 

Seite: 

81 

B 

E.4 

E.8 

Abbildung 29: Adressierung der Secodervisualisierungsdaten bei DTA-Formaten 

Beim Format „DTA“ wird durch die erste Stelle der Datensatz innerhalb des DTA- 

Formates festgelegt; die zweite Stelle bezeichnet das Feld innerhalb des DTA- 

Datensatzes. Es erfolgt also grundsätzlich eine zweistufige Adressierung.

Kapitel: 

Seite: 

B 

82 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abschnitt: 



B.5.1.5.3 

Positionierung bei DTAZV 

Z.3 

Z.4 

Abbildung 30: Adressierung der Secodervisualisierungsdaten bei DTAZV-Formaten 

Beim Format „DTAZV“ wird durch die erste Stelle der Datensatz innerhalb des 

DTAZV-Formates festgelegt; die zweite Stelle bezeichnet das Feld innerhalb des 

DTAZV-Datensatzes. Es erfolgt also grundsätzlich eine zweistufige Adressierung.





UPD) 

B.5.1.5.4 

Positionierung bei SEPA XML Formaten 

Version: 

Stand: 

15.12.2009 

3.0 

Kapitel: 

Seite: 

83 

Bei den SEPA-Formaten wird zur Bezeichnung der im Secoder-Display zu visualisierenden 

Daten das entsprechende Tag verwendet, gefolgt von einem Index i, der 

das i-te Vorkommen dieses Tags im SEPA-Format bezeichnet, wie die folgende Abbildung 

zeigt: 

B 

CtrlSum.1 

Abbildung 31: Adressierung der Secodervisualisierungsdaten bei SEPA-Formaten 

In diesem Fall würde das erste vorkommende Tag CtrlSum als Position angegeben. 

Die Angabe erfolgt case sensitive. 

Hinweis: für die Visualisierung der SEPA-Formate können auch die Informationen 

aus dem Datenelementen des FinTS-Geschäftsvorfalls (außerhalb des transparenten 

SEPA-Formats) wie z. B. das Datenelement Wert aus der DEG Summenfeld 

über die Kennzeichnung 3,1 visualisiert werden.

Kapitel: 

Seite: 

B 

84 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abschnitt: 



B.5.1.6 Parametersegment HIVISS 

Format 

Realisierung Bank: 

Realisierung Kunde: optional 

Name: 

Typ: 

Segmentart: 

Kennung: 

Bezugssegment: 


Sender: 

Format: 

Erläuterungen 

Name: 

Typ: 

Status: 

verpflichtend, falls Geschäftsvorfälle mit AZS-Absicherung angeboten 

werden 

Secoder-spezifische Visualisierungsinformationen 

Segment 

Geschäftsvorfall 

HIVISS 

HKVVB 


Geschäftsvorfall mit Parametern 

Parameter Secoder-spezifische Visualisierungsinformationen 

Datenelementgruppe 

M 

Nr. Name 


Län- 

Sta- 

An- 

Restriktionen 




DE num 1 M 1 0, 1, 2, 3 


5 Parameter Secoderspezifische 

Visualisierungsinformationen 

DEG M 1 


In „Parameter Secoder-spezifische Visualisierungsinformationen“, 

dort „Geschäftsvorfallspezifische Visualisierungsinformationen für Secoder“ 

Segmentversion 

Als „Segmentversion“ kann in HIVISS eine der definierten Segmentversionen des 

jeweiligen Segmentes oder der Wert „0“ auftreten. „0“ bedeutet, dass die Struktur 

„Geschäftsvorfallspezifische Visualisierungsinformationen für Secoder“ als Default 

für alle Segmentversionen des Segmentes gilt, für die keine explizite Parameter- 

Struktur vorhanden ist.





UPD) 

Sicherheitsfunktion, kodiert 

Version: 

Stand: 

15.12.2009 

3.0 

Kapitel: 

Seite: 

85 

Als „Sicherheitsfunktion, kodiert“ kann in HIVISS einer der für AZS-Verfahren definierten 

Werte (800, 810, 811, 812, 820, 821) oder der Wert „0“ auftreten. „0“ bedeutet, 

dass die Struktur „Geschäftsvorfallspezifische Visualisierungsinformationen für 

Secoder“ als Default für all die AZS-Verfahren gilt, für die keine explizite Definition 

vorhanden ist. Es können somit innerhalb der Struktur „Geschäftsvorfallspezifische 

Visualisierungsinformationen für Secoder“ maximal sechs Ausprägungen auftreten 

(wobei dann alle AZS-Verfahren konkret oder eine davon als Default ausgeprägt 

sein können). 

B.5.2 Spezielle Festlegungen für die Dialoginitialisierung beim AZS-Verfahren 

Im Rahmen der Dialoginitialisierung werden folgende Informationen ausgetauscht: 

Zugelassene AZS-Verfahren für den Benutzer 

In der Dialoginitialisierungsantwort wird dem Kunden im Rahmen der Rückmeldungen 

zu Segmenten (HIRMS) über den Rückmeldungscode 3921 und 

entsprechende Rückmeldungsparameter mitgeteilt, welche konkreten AZS- 

Verfahren für ihn zugelassen sind. Dabei wird pro Rückmeldeparameter (P1 

bis P10) ein Verfahrenskennzeichen übermittelt. Die Kodierung erfolgt analog 

der Belegung des DE „Sicherheitsfunktion, kodiert“ im Parametersegment 

HIVISS, also im Wertebereich „800“, „810“, „811“, „812“, „820“ und 

„821“. 

B

Kapitel: 

Seite: 

B 

86 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abschnitt: 



Das Kreditinstitut muss organisatorisch sicherstellen, dass der Kunde 

über eine geeignete Version eines Kundenproduktes verfügt, das 

die Rückmeldeparameter entsprechend interpretieren kann. In jedem 

Falle sollte der Kunde durch einen verständlichen Rückmeldetext 

darauf hingewiesen werden, dass er ggf. ein aktualisiertes Kundenprodukt 

benötigt. 

Sollte der Kunde vertraglich an die Nutzung eines der AZS- 

Verfahren gebunden sein und verwendet er ein Kundenprodukt, 

welches dieses AZS-Verfahren nicht unterstützt, so ist der Dialog zu 

beenden. Über den Rückmeldungscode 9955 „AZS-Verfahren nicht 

zugelassen“ und einen geeigneten Rückmeldungstext muss der 

Kunde eindeutig über die Ursache dieser Dialogbeendigung informiert 

werden. Der Rückmeldungstext muss auch berücksichtigen, 

dass die Anfrage des Kundenproduktes z. B. mit DE „Sicherheitsfunktion, 

kodiert“ = „999“ in diesem Fall nur erfolgt, um die unterstützten 

Sicherheits-Verfahren für den Benutzer zu ermitteln. Diese 

müssen über den Rückmeldungscode 3921 „Zugelassene AZS- 

Verfahren für den Benutzer“ (oder den entsprechenden Rückmeldungscode 

3921 in Kombination mit Code 9800 im Fehlerfall) mitgeteilt 

werden. Bei den Sicherheitsfunktionen 811 und 812 gilt dies ab 

dem ersten Dialog nach der Schlüsseleinreichung (mit S-Fkt=1). 

Sollte das Kundenprodukt AZS-Verfahren unterstützen und noch 

keine Verfahrensparameter mit Angabe der für den aktuellen Benutzer 

unterstützten Verfahren verfügen, so muss es einen Dialog eröffnen, 

um über die Rückmeldeparameter in Kenntnis der erlaubten 

Verfahren zu gelangen. Hierbei ist für das DE „Sicherheitsfunktion, 

kodiert“ der Wert „999“ für Ein-Schritt-TAN-Verfahren zu verwenden. 

Gewähltes AZS-Verfahren des Kunden 

Ein Kunde kann aus den für Ihn zugelassenen AZS-Verfahren eines für den aktiven 

Dialog auswählen. Das entsprechende Verfahrenskennzeichen wird in das DE „Sicherheitsfunktion, 

kodiert“ im Signaturkopf der Dialoginitialisierungsnachricht eingestellt. 

Die Kodierung erfolgt analog der Belegung des DE „Sicherheitsfunktion, kodiert“ 

im Parametersegment HIVISS, also im Wertebereich „800“, „810“, „811“, 

„812“, „820“ und „821“. Das gewählte AZS-Verfahren muss für den Benutzer erlaubt 

sein (BPD, Rückmeldung 3921 bei Dialoginitialisierung).



Kapitel: 

Abschnitt: 

Dialogspezifikation für AZS-Verfahren 

Allgemeines 

Version: 

Stand: 

15.12.2009 

3.0 

Kapitel: 

Seite: 

87 

E 

C. DIALOGSPEZIFIKATION FÜR AZS-VERFAHREN 

C.1 Allgemeines 

Der Einsatz von AZS-Verfahren erfordert den Transport von sicherheitsrelevanten 

Daten mit Hilfe des Geschäftsvorfalls „Alternative ZKA-Sicherheitsverfahren 

(HKAZS)“. Hiermit lassen sich alle auftragsbezogenen Sicherheitsinformationen 

komplett transportieren und die HBCI-Signatursegmente werden nur soweit nötig mit 

konkreten Werten gefüllt und ansonsten mit FinTS-Füllwerten bestückt übertragen. 

Insbesondere wird bei AZS-Verfahren das DE „Validierungsresultat“ im Signaturabschluss 

nicht belegt, da die Signatur selbst im DE „Signaturdaten“ in HKAZS bzw. 

HIAZS übertragen wird. Somit lassen sich AZS-Verfahren auch mit den Versionen 

HBCI-V2.2 und FinTS V3.0 einsetzen und zwar in folgenden Ausprägungen: 

HBCI V2.2 : möglich für Sicherheitsfunktionen 800, 810, 820, 821 

FinTS V3.0 : möglich für Sicherheitsfunktionen 800, 810, 811, 812, 820, 821 

Für neuere FinTS-Versionen wird eine separate Modellierung angeboten werden. 

Zusätzlich besteht jedoch die Anforderung, dass bereits im Zuge der Dialoginitialisierung 

visualisierte Daten übertragen werden müssen, was dazu führt, dass bereits 

zu diesem Zeitpunkt HKAZS-Segmente zu integrieren sind. Da eine Modifikation 

des FinTS-Protokolls auf ein Minimum beschränkt werden soll, werden die im Folgenden 

beschriebenen Anpassungen gezielt nur für die AZS-Verfahren eingesetzt. 

Diese sind am Nummernkreis 800 bis 899 für die „Sicherheitsfunktion, kodiert“ eindeutig 

zu erkennen. Für alle anderen Sicherheitsfunktionen bleibt die bestehende 

HBCI V2.2 bzw. FinTS V3.0 Protokollstruktur erhalten. 

Bei den AZS-Verfahren mit den Sicherheitsfunktionen 811, 812, 820 und 821 kann 

das Segment HIAZS in der Kreditinstitutsnachricht wegfallen, wenn es ausschließlich 

FinTS-Füllwerte enthält. 

C.1.1 

Verschlüsselung des Dialoges 

Grundsätzlich sind bei AZS-Verfahren sowohl alle Kunden- als auch alle Kreditinstitutsnachrichten 

eines Dialoges mit HBCI bzw. SSL zu verschlüsseln. Von dieser 

Regel ausgenommen sind die folgenden Dialogarten: 

Anonymer Zugang 

Schlüsselsperrung durch den Kunden 

Kommunikationszugang anfordern 

Im Unterschied zu der standardmäßigen Belegung in FinTS wird bei AZS-Verfahren 

im Datenelement „Sicherheitsfunktion, kodiert“ der Wert für das AZS-Verfahren, also 

800, 810, 811, 812, 820 oder 821 eingestellt. Hierdurch wird indirekt auch das eigentliche 

Verschlüsselungsverfahren „HBCI“ oder „SSL“ festgelegt. 

Die sonstigen Protokolleigenschaften zum Verschlüsseln von Daten sind den entsprechenden 

Vorgaben der Sicherheitsverfahren HBCI (HBCI-Verschlüsselung) und 

PIN/TAN (SSL-Verschlüsselung) zu entnehmen.

Kapitel: 

Seite: 

E 

88 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abschnitt: 


Besondere Belegungsrichtlinien für AZS-Verfahren 

C.1.2 

C.1.3 

Institutssignaturen bei AZS-Verfahren 

Bei der Verwendung der AZS-Verfahren nach den Sicherheitsfunktionen 800, 810 

und 812 werden auch die Kreditinstitutsnachrichten mit einem Institutszertifikat bzw. 

einer Institutssignatur versehen. Die Signatur wird im Segment HIAZS übertragen. 

Bei den Sicherheitsfunktionen 800 und 810 wird sie Signatur über die SAK- 

Visualisierungsdaten (=Angebot) gebildet. Das Ergebnis wird in das Institutszertifikat 

eingestellt und via ISIS-MTT beschrieben. 

Bei der Sicherheitsfunkton 812 wird die Signatur über das vollständige FinTS Antwortsegment 

(z. B. HIKAZ) zum Auftrag gebildet (vgl. hierzu Abschnitt C.3 

„Nachrichtenaufbau für AZS-Verfahren“). Die Steuerung über die Signaturbildung erfolgt 

im FinTS-Signaturkopf. Die Signatur selbst ist eine RDH-Signatur mit Sicherheitsfunktion=1. 

Die in der Kreditinstitutsantwort enthaltene Institutssignatur muss 

vom Kundensystem zwingend geprüft werden. 

Bei den Verfahren 811, 820 und 821 werden keine Institutssignaturen eingesetzt. 

Key-Management bei AZS-Verfahren 

Der Geschäftsvorfall HKAZS wird nur zur Auftragsverarbeitung verwendet, d. h. 

dass bei den betroffenen Sicherheitsfunktionen 800, 810, 811 und 812 davon ausgegangen 

wird, dass das Key- bzw. Zertifikatsmanagement mit anderen syntaktischen 

Mitteln erfolgt. 

Bei den Sicherheitsfunktionen 800 und 810 müssen sich die benötigten Zertifikate 

bereits auf der Karte befinden. Weitere Informationen zum Zertifikatsmanagement 

werden innerhalb von ISIS-MTT geregelt. 

Bei den Sicherheitsfunktionen 811 und 812 muss die erstmalige Schlüsseleinreichung 

nach dem Standard RDH-Verfahren erfolgen. Zum Einreichen der Schlüssel 

muss also zunächst ein separater Dialog mit Sicherheitsfunktion=1 durchgeführt 

werden. Gleiches gilt für die Schlüsselsperre. Änderungen der Kundenschlüssel 

könnten bei den kartenbasierten AZS-Verfahren nicht auftreten. 

Eine Ausnahme stellt das Anfordern der öffentlichen Schlüssel des Instituts dar. Der 

Austausch erfolgt via HKISA / HIISA im Rahmen des AZS-Verfahrens. 

Bei den Sicherheitsfunktionen 820 und 821 wird kein Key-Management benötigt. 

C.1.4 

Behandlung der Dialogendenachricht (HKEND) 

Die Dialogendenachricht (HKEND) wird grundsätzlich nicht signiert. Dies gilt für die 

Kunden- und die Institutsseite. Dadurch kann das entsprechende HxAZS, sowie die 

Segmente Signaturkopf (HNSHK) und Signaturabschluss (HNSHA) entfallen. Die 

Verschlüsselung ist von dieser Sonderregelung nicht betroffen. 

C.2 Besondere Belegungsrichtlinien für AZS-Verfahren 

In den im Folgenden dargestellten Strukturen sollten Datenelemente mit Status „O“, 

grundsätzlich leer gelassen werden. 

Für einige Datenelemente gelten bei AZS-Verfahren besondere Belegungsrichtlinien, 

die von den allgemeinen in [HBCI] aufgeführten Richtlinien abweichen. Diese 

sind nachfolgend aufgeführt.



Kapitel: 

Abschnitt: 



Version: 

Stand: 

15.12.2009 

3.0 

Kapitel: 

Seite: 

89 

E 

C.2.1 Segment Sicherheitsverfahren, DEG Unterstützte Sicherheitsverfahren 

Das Segment „Sicherheitsverfahren (HISHV)“ ist Teil der Segmentfolge „Bankparameterdaten“. 

 

Um 

die Kompatibilität mit den bestehenden Sicherheitsverfahren 

HBCI und PIN/TAN sicherzustellen, konnte der mögliche Wertebereich 

innerhalb von HISHV-Segmenten nicht um einen weiteren 

Wert für AZS-Verfahren erweitert werden. Clients können diesem 

Segment somit nicht entnehmen, ob AZS-Verfahren unterstützt 

werden oder nicht. Dies muss am Vorkommen des HIVISS- 

Segments festgemacht werden. Ist ein solches Segment vorhanden, 

werden AZS-Verfahren unterstützt, andernfalls nicht. 

C.2.2 DEG „Sicherheitsprofil“ 

Die DEG „Sicherheitsprofil“ wird sowohl im Signaturkopf als auch in HKAZS verwendet. 

Die Verwendung in HKAZS ist erforderlich, um AZS-Verfahren auch mit 

HBCI V2.2 einsetzen zu können. Bei HBCI V2.2 existiert im Signaturkopf keine DEG 

„Sicherheitsprofil“. 

Bei FinTS V3.0 wird die DEG in beiden Segmenten, Signaturkopf und HKAZS identisch 

belegt. 

Unabhängig von der FinTS-Version wird bei S-Fkt=800 und 810 die DEG „Sicherheitsprofil“ 

nicht belegt). 

Sicherheitsverfahren, Code 

„RDH“: bei allen Nachrichten mit S-Fkt=800, 810, 811, 812 

„EMV“: bei allen Nachrichten mit S-Fkt=820, 821 

Version des Sicherheitsverfahrens 

„e“ : bei allen Nachrichten mit Sicherheitsfunktion = 820, 821 

wobei „e“ dem der Version des Sicherheitsprofils entspricht, 

dessen Algorithmen bei der Hashwert-Bildung verwendet werden. 

Gültige Sicherheitsprofile: EMV-1, EMV-2 

„r“ : bei allen Nachrichten mit Sicherheitsfunktion = 800, 810, 811, 812 

wobei „r“ dem der Version des Sicherheitsprofils entspricht, 

dessen Algorithmen bei HBCI-Verschlüsselung, Hashwert-Bildung 

usw. verwendet werden. 

Gültige Sicherheitsprofile: RDH-3, RDH-5 – RDH-9 

C.2.3 

DEG „Schlüsselname“ 

Bei Sicherheitsfunktion = 811 und 812 gelten die HBCI-Konventionen, ansonsten 

sind FinTS-Füllwerte einzustellen. 

Schlüsselnummer 

FinTS-Füllwert, z. B. „0“ 

Schlüsselversion 

FinTS-Füllwert, z. B. „0“

Kapitel: 

Seite: 

E 

90 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abschnitt: 



C.2.4 

DEG „Sicherheitsidentifikation, Details“ 

CID 

Dieses Feld ist bei allen AZS-Verfahren mit der CID zu belegen, da es sich 

bei AZS-Verfahren ausschließlich um Chipkarten-Verfahren handelt. 

Identifizierung der Partei 

Dieses Feld muss eine gültige, zuvor vom Banksystem angeforderte Kundensystem-ID 

enthalten (analog zum RSA-Verfahren). Dies gilt auch für 

Zweit- und Drittsignaturen. 

C.2.5 

Segment „Signaturkopf“ 

Zertifikat 

Dieses Feld darf außer bei Sicherheitsfunktion 811 und 812 nicht belegt 

werden. 

C.2.6 

DEG „Hashalgorithmus“ 



Wert des Hashalgorithmusparameters 

Dieses Feld darf nicht belegt werden. 

C.2.7 

DEG „Signaturalgorithmus“ 



Signaturalgorithmus, kodiert 


Operationsmodus, kodiert 


C.2.8 

Segment „Signaturabschluss“ 

Es ist der Signaturabschluss gemäß [HBCI] in Segmentversion 2 zu verwenden. 

Validierungsresultat 

Dieses Feld darf nicht belegt werden, da die Signatur selbst im DE „Signaturdaten“ 

in HKAZS bzw. HIAZS übertragen wird. 

C.2.9 

Segment „Verschlüsselungskopf“ 


Im Unterschied zu der standardmäßigen Belegung in FinTS wird bei AZS- 

Verfahren im Datenelement „Sicherheitsfunktion, kodiert“ der Wert für das 

AZS-Verfahren, also 800, 810, 811, 812, 820 oder 821 eingestellt. 

Zertifikat 

Dieses Feld darf nicht belegt werden.



Kapitel: 

Abschnitt: 



Version: 

Stand: 

15.12.2009 

3.0 

Kapitel: 

Seite: 

91 

E 

C.2.10 DEG „Verschlüsselungsalgorithmus“ 

Bei Sicherheitsfunktion=811 und 812 gelten die HBCI-Konventionen, ansonsten sind 

FinTS-Füllwerte einzustellen. 

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 


Wert des Algorithmusparameters, IV 

Belegung nicht zulässig. 

C.2.11 Segment „Verschlüsselte Daten“ 

Daten, verschlüsselt 

Enthält bei Sicherheitsfunktion 811 und 812 die verschlüsselten Daten, in allen 

anderen Fällen die unverschlüsselten Daten (die Verschlüsselung erfolgt 

via Transportverschlüsselung des verwendeten Transportprotokolls HTTPS).

Kapitel: 

Seite: 

E 

92 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abschnitt: 


Nachrichtenaufbau für AZS-Verfahren 

C.3 Nachrichtenaufbau für AZS-Verfahren 

In Ergänzung zum bisherigen Segmentaufbau wird in der FinTS-Kundennachricht 

vor dem Signaturabschlusssegment ein Segment HKAZS eingefügt, das die alternativen 

Sicherungselemente transportiert. Somit kann das HKAZS-Segment auch als 

Erweiterung des Signaturabschlusssegmentes gesehen werden. 

 

Die 

folgende Darstellung enthält im Rahmen der Dialoginitialisierung 

das neue Segment HKAZS. Es soll an dieser Stelle darauf 

hingewiesen werden, dass diese neue Protokolleigenschaft – speziell 

in Verbindung mit den AZS-Verfahren 820 bzw. 821 – zukünftig 

ggf. auch beim chipTAN-Verfahren eingesetzt werden könnte, 

was aber derzeit noch nicht in Planung ist. 

C.3.1 

Kundennachricht bei der Dialoginitialisierung 

Die folgende Abbildung zeigt den Aufbau der Kundennachricht bei der Dialoginitialisierung. 

Sie enthält zusätzlich ein HKAZS-Segment zur Übermittlung der Signaturund 

Visualisierungsinformationen. In die Signaturbildung fließen die Segmente Signaturkopf 

(HNSHK), Identifikation (HKIDN), Verarbeitungsvorbereitung (HKVVB) 

und ggf. die Anforderung öffentlicher Schlüssel (HKISA) ein. 

Nachrichten- 

Kopf 

Signaturkopf 

Identifikation 

Nachrichtenabschluss 

Verarbeitungsvorbereitung 

Anforderung 

öffentlicher 

Schlüssel 

zu signierende Daten 

Alternative ZKA 

Sicherheitsverfahren 

Verschlüsselungskopf 

Signaturabschluss 

HKAZS und HNSHA 

treten immer paarig auf 

Abbildung 32: Segmentaufbau der Dialoginitialisierungsnachricht (Kunde) bei AZS- 

Verfahren



Kapitel: 

Abschnitt: 



Version: 

Stand: 

15.12.2009 

3.0 

Kapitel: 

Seite: 

93 

E 

Die folgende Tabelle zeigt die Belegungsmöglichkeiten für die einzelnen AZS- 

Verfahren. 

Seg- 

S-Fkt=800 S-Fkt=810 S-Fkt=811 S-Fkt=812 S-Fkt=820 S-Fkt=821 

ment- 

name 

HNHBK X X X X X X 

HNVSK 800 810 811 812 820 821 

HNSHK FinTS-FW FinTS-FW X X FinTS-FW FinTS-FW 

HKIDN X X X X X X 

HKVVB X X X X X X 

HKISA nicht erlaubt nicht erlaubt X X nicht erlaubt nicht erlaubt 

HKAZS X X X X X X 

HNSHA FinTS-FW FinTS-FW X X X FinTS-FW 

HNHBS X X X X X X 

X: Segment wird gemäß FinTS-Protokoll ohne Sonderbelegung verwendet. 

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 „Standardsprache“ 

des Kommunikationszugangs zu entnehmen. Die Antwort des Kreditinstituts erfolgt 

dann in der vom Kunden gewünschten Sprache (Zeichensatz). 

Format 

Name: 

Typ: 

Version: 5 

Sender: 


Nachricht 

Kunde

Kapitel: 

Seite: 

E 

94 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abschnitt: 



Nr. Name Typ Kennuntuzahl 

Sta- 

An- 

Anmerkungen 

1 Nachrichtenkopf SEG HNHBK M 1 

2 Signaturkopf SEG HNSHK M 1 s. [HBCI], Kap. B.5.1 

3 Identifikation SEG HKIDN M 1 

4 Verarbeitungsvorbereitung SEG HKVVB M 1 

5 Anforderung eines öffentlichen 

Schlüssels 

6 Alternative ZKA Sicherungsverfahren 

SEG HKISA C 3 O: bei RDH, S-Fkt=811, 812 

N: sonst 

SEG HKAZS C 1 M: S-Fkt=800 .. 899 

N: sonst 

7 Signaturabschluss SEG HNSHA M 1 s. [HBCI], Kap. B.5.2 

8 Nachrichtenabschluss SEG HNHBS M 1 

C.3.2 

Kreditinstitutsnachricht bei der Dialoginitialisierung 

Die folgende Abbildung zeigt den Aufbau der Kreditinstitutsnachricht bei der Dialoginitialisierung. 

Bei den Sicherheitsfunktionen 800, 810 und 812 enthält sie zusätzlich 

ein HIAZS-Segment zur Übermittlung der Zertifikats- bzw. Signaturdaten. In die 

Signaturbildung fließen die Segmente Signaturkopf (HNSHK), Rückmeldungen 

(HIRMG und HIRMS), und ggf. BPD und UPD, die Übermittlung öffentlicher Schlüssel 

(HIISA) und Kreditinstitutsmeldungen (HIKIM) ein. 

Bei allen anderen AZS-Verfahren entfällt das Segment HIAZS. 

Nachrichten- 

Kopf 


Signaturkopf 

Rückmeldung 

Segment 

Übermittlung 

öffentlicher 

Schlüssel 

Rückmeldung 

Gesamtnachricht 

Kreditinstitutsmeldung 

BPD / UPD 






Abbildung 33: Segmentaufbau der Dialoginitialisierungsnachricht (Kreditinstitut) bei 

AZS-Verfahren



Kapitel: 

Abschnitt: 



Version: 

Stand: 

15.12.2009 

3.0 

Kapitel: 

Seite: 

95 

E 

Die folgende Tabelle zeigt die Belegungsmöglichkeiten für die einzelnen AZS- 

Verfahren. 

Segmentname 

S-Fkt=800 S-Fkt=810 S-Fkt=811 S-Fkt=812 S-Fkt=820 S-Fkt=821 

HNHBK X X X X X X 

HNSHK FinTS-FW FinTS-FW X X FinTS-FW FinTS-FW 

HIRMG X X X X X X 

HIRMS X X X X X X 

„BPD“ X X X X X X 

„UPD“ X X X X X X 

HIISA nicht erlaubt nicht erlaubt X X nicht erlaubt nicht erlaubt 

HIKIM X X X X X X 

HIAZS X X nicht erlaubt X nicht erlaubt nicht erlaubt 

HNSHA FinTS-FW FinTS-FW FinTS-FW FinTS-FW FinTS-FW FinTS-FW 

HNHBS X X X X X X 

X: Segment wird gemäß FinTS-Protokoll ohne Sonderbelegung verwendet. 

C.3.2.1 Nachrichtenformat 

Realisierung Bank: verpflichtend 

Realisierung Kunde: verpflichtend 

Format 

Name: 

Typ: 

Version: 5 

Sender: 

Antwort auf Dialoginitialisierung 

Nachricht 


Nr. Name Typ Kennuntuzahl 

Sta- 

An- 

Anmerkungen 

1 Nachrichtenkopf SEG HNHBK M 1 

2 Signaturkopf SEG HNSHK O 1 s. [HBCI], Kap. B.5.1 

3 Rückmeldungen zur Gesamtnachricht 

SEG HIRMG M 1 

4 Rückmeldungen zu Segmenten 

SEG HIRMS O n 

5 Bankparameterdaten SF # O 1 

6 Userparameterdaten SF # O 1 

7 Übermittlung eines öffentlichen 

Schlüssels 

8 Kreditinstitutsmeldung SEG HIKIM O n 

9 Alternative ZKA Sicherungsverfahren 

SEG HIISA C 3 O: bei RDH, S-Fkt=811, 812 

N: sonst 

SEG HIAZS C 1 M: S-Fkt=800 .. 899 

N: sonst 

10 Signaturabschluss SEG HNSHA O 1 s. [HBCI], Kap. B.5.2 

11 Nachrichtenabschluss SEG HNHBS M 1

Kapitel: 

Seite: 

E 

96 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abschnitt: 



C.3.3 

Kundenauftragsnachricht 

Die folgende Abbildung zeigt den Aufbau der Kundennachricht bei der Auftragsverarbeitung. 

Sie enthält zusätzlich ein HKAZS-Segment zur Übermittlung der Signaturund 

Visualisierungsinformationen. In die Signaturbildung fließt der Signaturkopf 

(HNSHK) und ein Auftragssegment ein. 

Nachrichten- 

Kopf 

Signaturkopf 

1 Auftrag 







HKAZS und HNSHA 

treten immer paarig auf 

Abbildung 34: Segmentaufbau der Auftragsnachricht (Kunde) bei AZS-Verfahren



Kapitel: 

Abschnitt: 



Version: 

Stand: 

15.12.2009 

3.0 

Kapitel: 

Seite: 

97 

E 

C.3.4 

Kreditinstitutsauftragsnachricht 

Die folgende Abbildung zeigt den Aufbau der Kreditinstitutsnachricht bei der Auftragsverarbeitung. 

Bei den Sicherheitsfunktionen 800, 810 und 812 enthält sie zusätzlich 

ein HIAZS-Segment zur Übermittlung der Zertifikats- bzw. Signaturdaten. In 

die Signaturbildung fließen die Segmente Signaturkopf (HNSHK), ggf. Auftragsantwortsegmente 

und die Rückmeldungssegmente (HIRMG und HIRMS) ein. 

Bei allen anderen AZS-Verfahren entfällt das Segment HIAZS. 

Nachrichten- 

Kopf 

Signaturkopf 



Auftragsantwort 

Rückmeldung 

Segment 

Rückmeldung 

Gesamtnachricht 





Abbildung 35: Segmentaufbau der Auftragsnachricht (Kreditinstitut) bei AZS- 

Verfahren

Kapitel: 

Seite: 

E 

98 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abschnitt: 



C.3.5 Kundennachricht bei Mehrfachsignaturen 

Bei den AZS-Ein-Schritt-Verfahren (S-Fkt=811, 812, 820, 821) ist es möglich, mehrere 

Signaturen im Rahmen der Auftragseinreichung mitzuschicken, wie dies beim 

FinTS-Ein-Schritt-Verfahren grundsätzlich möglich ist. In Kombination mit den zugehörigen 

HKAZS-Segmenten ergibt sich folgender Segmentaufbau: 

Nachrichten- 

Kopf 

Signaturkopf 

Signaturkopf 

Signaturkopf 

1 Auftrag 





ZKA 

Alternative 


ZKA 

Alternative 





Abbildung 36: Kundennachricht bei Mehrfachsignaturen 

Mehrfachsignaturen werden bei AZS-Ein-Schritt-Verfahren (S-Fkt=811, 812, 820, 

821) wie beim Sicherheitsverfahren HBCI von außen nach innen verarbeitet.



Kapitel: 

Abschnitt: 



Version: 

Stand: 

15.12.2009 

3.0 

Kapitel: 

Seite: 

99 

E 

Signaturkopf 3 



1 Auftrag 


Sicherungsverfahren 

1 



2 



3 


1 


2 


3 

Abbildung 37: Reihenfolge der Sicherheitssegmente bei Mehrfachsignaturen 

Die Referenzierung zwischen den Segmenten geschieht in den drei Segmenten 

Signaturkopf, Signaturabschluss und HKAZS mit Hilfe der Sicherheitskontrollreferenz. 

Bei Mehrfachsignaturen wird das Datenelement „Bereich der Sicherheitsapplikation, 

kodiert“ mit dem Wert 1 (= SHM) belegt, d. h. die Sicherheitselemente der anderen 

Signierenden werden nicht mit signiert und die Reihenfolge der Signaturen ist daher 

nicht von Belang. 

Alle anderen Belegungen wie z. B. die „Rolle des Sicherheitslieferanten, kodiert“ 

sind identisch zu den Aussagen bzgl. Mehrfachsignaturen bei Sicherheitsverfahren 

HBCI. 

Bei den AZS-Zwei-Schritt-Verfahren (S-Fkt=800, 810) zur Bildung von qualifizierten 

Signaturen sind in FinTS nur Einfachsignaturen erlaubt. Möglichkeiten der mehrfachen 

Signaturbildung auf Basis einer Signaturanwendungskomponente, die sich im 

ISIS-MTT-Protokoll wiederspiegeln, werden hier nicht betrachtet. 

Unabhängig von der Art des AZS-Verfahrens lassen sich auch bei den AZS-Zwei- 

Schritt-Verfahren 800 und 810 Mehrfachsignaturen zeitlich versetzt über den Signatur-Prozess=3 

einreichen. Dies führt jedoch vom Segmentaufbau her zur Einreichung 

von Einfach-Signaturen, welche im Kreditinstitut über die Auftragsreferenz logisch 

verknüpft werden können.

Kapitel: 

Seite: 

E 

100 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abschnitt: 

Secoder-Management 

Übermitteln / Anzeigen von Secoder-Informationen 

D. SECODER-MANAGEMENT 

Der im Folgenden beschriebene Geschäftsvorfall HKHSI ist identisch im FinTS- 

Band [PIN/TAN] erläutert. Dort befindet sich auch die Spezifikation aller vorkommenden 

Elementversionen bestimmter Datenelemente; hier sind nur die Secoderspezifischen 

Elemente dokumentiert. 

D.1 Übermitteln / Anzeigen von 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 Bestandsverwaltung 

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 diese 

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



Kapitel: 

Abschnitt: 



Version: 

Stand: 

15.12.2009 

3.0 

Kapitel: 

Seite: 

101 

E 

a) Kundenauftrag 

Format 

Name: 

HHD/Secoder-Informationen übermitteln 

Typ: 

Segment 


Kennung: 

HKHSI 

Bezugssegment: - 


Sender: 

Kunde 

Nr. Name 


Län- 

Sta- 

An- 

Restriktionen 


2 TAN-Medium-Klasse DE code 1 M 1 G, S 

3 Reader-ID DE id # C 1 M: 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 

4 Verfahrensbestätigung DE jn # C 1 M: bei DE „Verfahrensbestätigung 

erforderlich“ = „J“ 

(BPD) 

O: sonst 


TAN-Medium-Klasse 1 

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 werden 

soll. Durch den BPD-Parameter „Reader-ID erforderlich“ kann gesteuert 

werden, ob die Angabe der Reader-ID zwingend für die Ausführung des Geschäftsvorfalls 

erforderlich ist. 

Bei der TAN-Medium-Klasse „S“ für Secoder darf die Reader-ID nicht übertragen 

werden, da diese als Teil des Sicherheitskonzeptes im Rahmen der „Visualisation 

Authentication“ des Secoders als gemeinsames Geheimnis zwischen 

Secoder und Institutsseite verwendet wird. 

1 Es ist die Elementversion 2 der TAN-Medium-Klasse zu verwenden.

Kapitel: 

Seite: 

E 

102 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abschnitt: 



b) Kreditinstitutsrückmeldung 

Erläuterungen 

Es wird ein Datensegment zurückgemeldet. 

Format 

Name: 

HHD/Secoder Informationen rückmelden 

Typ: 

Segment 


Kennung: 

HIHSI 

Bezugssegment: HKHSI 


Sender: 


Nr. Name 


Län- 

Sta- 

An- 

Restriktionen 

1 Segmentkopf 1 

DEG M 1 

2 Reader-ID DE id # C 1 O: bei DE „TAN-Medium- 

Klasse“ = „G“ 

N: sonst 

3 Gerätehersteller 2 

DE an ..64 O 1 

4 Geräteklasse DE an ..64 O 1 

5 Gerätebezeichnung 3 

DE an ..64 O 1 

6 Geräteversion DE an ..64 O 1 

Ausgewählte Beispiele für Rückmeldungscodes 


0020 Auftrag verarbeitet 

c) Bankparameterdaten 

Format 

Name: 

HHD/Secoder Informationen Parameter 

Typ: 

Segment 


Kennung: 

HIHSIS 

Bezugssegment: HKVVB 


Sender: 


Nr. Name 


Län- 

Sta- 

An- 

Restriktionen 




DE num 1 M 1 0, 1, 2, 3 


5 Parameter HHD/Secoder 

Informationen 

DEG M 1



Kapitel: 

Abschnitt: 

Data-Dictionary 

Version: 

Stand: 

15.12.2009 

3.0 

Kapitel: 

Seite: 

103 

E 

E. DATA-DICTIONARY 

A 

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äftsvorfall 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 angegebenen 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: 

Format: 

DE 

num 

Länge: ..1 

Version: 1 

Auftrag stornieren 

Falls ein Kreditinstitut die Auftragseinreichung mit einer oder mehreren Warnungen 

beantwortet, aber trotzdem in HIAZS ein Angebot übermittelt, kann das Kundenprodukt 

unter Verwendung einer Signatur den Auftrag stornieren. Für die Auftragsstornierung 

gelten folgende Rahmenbedingungen: 

1 Ein Auftragsstorno kann ausschließlich bei Signatur-Prozess=2 erfolgen. 

2 Der BPD-Parameter „Auftragsstorno erlaubt“ ist mit „J“ belegt. 

3 Die Kreditinstitutsrückmeldung im ersten Schritt (Antwort auf Einreichung 

von Auftrag und HIAZS mit Belegung gemäß Signatur-Prozess=4) 

enthält: 

 

 

eine oder mehrere Rückmeldungen mit Bezug zum Auftragssegment 

mit mindestens einer Warnung zu diesem Auftrag 

(Rückmeldungscode=3xxx). 

ein Segment HIAZS mit Belegung gemäß Signatur-Prozess=4 

und einem gültigen Angebot 

4 Bei Mehrfach-Signaturen (AB-Kompetenzen) kann ein Storno nur in 

Verbindung mit der Auftragseinreichung erfolgen, nicht bei der nachträglichen 

Übermittlung von zusätzlichen Signaturen. 

Typ: 

Format: 

DE 

jn

Kapitel: 

Seite: 

E 

104 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abschnitt: 


Länge: # 

Version: 1 

Auftragsstorno erlaubt 

Über diesen Parameter wird bestimmt, ob ein Kreditinstitut unter exakt definierten 

Rahmenbedingungen eine Stornierung von Aufträgen zulässt oder nicht. 

Typ: 

Format: 

DE 

jn 

Länge: # 

Version: 1 

B 

Bezugssegment 

Sofern sich ein Kreditinstitutssegment auf ein bestimmtes Kundensegment bezieht 

(z. B. Antwortrückmeldung auf einen Kundenauftrag) hat das Kreditinstitut die Segmentnummer 

des Segments der Kundennachricht einzustellen, auf das sich das aktuelle 

Segment bezieht (s. DE „Segmentnummer“). In Zusammenhang mit den Angaben 

zur Bezugsnachricht aus dem Nachrichtenkopf ist hierdurch eine eindeutige 

Referenz auf das Segment einer Kundennachricht möglich. 

Falls die Angabe eines Bezugssegments erforderlich ist, ist dieses bei der Formatbeschreibung 

eines Kreditinstitutssegments angegeben. 

Typ: 

Format: 

DE 

num 

Länge: ..3 

Version: 1 

D 

Dialog-ID 

Die Dialog-ID dient der eindeutigen Zuordnung einer Nachricht zu einem HBCI- 

Dialog. Die erste Kundennachricht (Dialoginitialisierung) enthält als Dialog-ID den 

Wert 0. In der ersten Antwortnachricht wird vom Kreditinstitut eine Dialog-ID vorgegeben, 

die für alle nachfolgenden Nachrichten dieses Dialogs einzustellen ist. Es ist 

Aufgabe des Kreditinstituts, dafür zu sorgen, dass diese Dialog-ID dialogübergreifend 

und systemweit eindeutig ist. 

Typ: 

Format: 

DE 

id 

Länge: # 

Version: 1



Kapitel: 

Abschnitt: 


Version: 

Stand: 

15.12.2009 

3.0 

Kapitel: 

Seite: 

105 

E 

G 

Geschäftsvorfallspezifische Informationen zum alternativen Sicherheitsverfahren 

Ein DE dieses Typs enthält für genau einen Geschäftsvorfall relevante Informationen 

zum gewählten alternativen Sicherheitsverfahren. Ist für einen Geschäftsvorfall ein 

zugehöriges DE hinterlegt, kann das Kundenprodukt diesen Geschäftsvorfall über 

das alternative Sicherheitsverfahren absichern, andernfalls ist dies nicht erlaubt. 

Hierdurch wird nicht festgelegt, ob und wie oft ein Geschäftsvorfall zu signieren ist. 

Dies wird weiterhin über die BPD und UPD angegeben. Werden in BPD und UPD 

keine Signaturen gefordert, können diese selbst dann weggelassen werden, wenn 

für den betreffenden Geschäftsvorfall laut diesem DE eine Signatur erforderlich ist. 

Da die einzelnen Bestandteile dieses Datenelements aus syntaktischen Gründen 

nicht mehr modelliert werden können, werden diese mittels „Semikolon“ („;“ – 0x3B 

nach FinTS-Zeichensatz) getrennt. 

Im Feld „Segmentkennung“ ist die Kennung des Auftragssegments des Geschäftsvorfalls 

anzugeben, auf den sich die Informationen zum alternativen Sicherheitsverfahren 

beziehen. 

Beim Einsatz der AZS-Verfahren müssen für die in HIVISS enthaltenen Segmentkennungen 

und Segmentversionen auch entsprechende Einträge in HIAZSS enthalten 

sein. 

Bei den Sicherheitsfunktionen 811, 812, 820 und 821 werden für Segmentkennungen 

und Segmentversionen die in HIAZSS aber nicht in HIVISS enthalten sind und 

für die somit keine Secoder-Visualisierung erfolgen soll, Signaturen nach Signatur- 

Prozess=7 erzeugt. 

Nr. Name Typ Formazahl 

Länge Status An- 

Restriktionen 

1 Segmentkennung DE an ..6 M 1 

2 Segmentversion DE num ..3 M 1 

3 SAK- 

DE code 1 M 1 0, 1, 2, 3 

Visualisierungsformat 

4 Zeit- und Dialogbezug DE code 1 M 1 1, 2, 3 

beim alternativen Signaturverfahren 

5 Sicherheitsfunktion, 

kodiert 

DE code 3 O ..99 

Typ: 

Format: 

DE 

an 

Länge: ..512 

Version: 1

Kapitel: 

Seite: 

E 

106 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abschnitt: 



In diesem Datenelement wird eine Sequenz von Secoder-MetaData-Elementen 

beschrieben, d. h. bezogen auf einen Geschäftsvorfall ein Anzeigetext und die zugehörigen 

Daten aus dem Auftrag. Je Geschäftsvorfall können so viele Secodervisualisierungstexte 

definiert werden, wie der Secoder erlaubt. 

Da die einzelnen Bestandteile eines Secoder-Visualisierungselementes aus syntaktischen 

Gründen nicht mehr modelliert werden können, werden diese mittels „Semikolon“ 

(„;“ – 0x3B nach FinTS-Zeichensatz) getrennt. Die Struktur beginnt somit mit 

der Segmentkennung und der Segmentversion des Geschäftsvorfalls und der Sicherheitsfunktion, 

gefolgt von n Secoder-Visualisierungselementen, die rekursiv 

dargestellt werden. 

Die Informationen Secodervisualisierung Finanzdatenformat und –Position müssen 

immer paarweise auftreten und deren Anzahl muss den Platzhaltern „#“ in den Secodervisualisierungstexten 

entsprechen. 

N 

r. 

Name Typ Format 

Länge 

Status 

Anzahl 

Restriktionen 

1 Segmentkennung 

DE an ..6 M 1 

2 Segmentversion DE num ..3 M 1 0, Seg- 

Vers. 

3 Sicherheitsfunktion, 

kodiert 

3 Secodervisualisierungstext 

Index 

4 Secodervisualisierung 

Finanzdatenformat 


Position 

DE code ..3 M 1 0, 800, 

810, 811, 

812, 820, 

821 

DE num ..3 M 1 

DE code 1 K 1 

DE an ..256 K 1 

Typ: DE 

Format: an 

Länge: ..4KB 

Version: 1



Kapitel: 

Abschnitt: 


Version: 

Stand: 

15.12.2009 

3.0 

Kapitel: 

Seite: 

107 

E 

M 

Maximale Anzahl Aufträge 

Höchstens zulässige Anzahl an Segmenten der jeweiligen Auftragsart je Kundennachricht. 

Übersteigt die Anzahl der vom Kunden übermittelten Segmente pro Auftragsart 

die zugelassene Maximalanzahl, so wird die gesamte Nachricht abgelehnt. 

Typ: 

Format: 

DE 

num 

Länge: ..3 

Version: 1 

P 

Parameter Alternative ZKA Sicherheitsverfahren 

Für die Kennzeichnung der alternativen ZKA Sicherheitsverfahren auf Basis von 

HKAZS stehen definierte Werte als „Sicherheitsfunktion, kodiert“ im Wertebereich 

von 800 bis 899 zur Verfügung. 

Nr. Name Typ Format 

Länge 

Status 

Anzahl 

1 Visualisierungsbestätigungssignaturfüllwert 

DE code 1 M 1 

2 Auftragsstorno erlaubt DE jn # M 1 

3 Zulässige Signaturanwendungskomponenten 

4 Unterstützte EMV AC Versionen 

5 Geschäftsvorfallspezifische 

Informationen zum alternativen 


Restriktionen 

DE an ..1KB C 1 M: S-Fkt=800, 

810 

O: sonst 

DE num 1 O ..9 

DE an ..512 M n 

Typ: DEG 

Format: 

Länge: 

Version: 1 

Parameter Secoder-spezifische Visualisierungsinformationen 

Mit dieser DEG können Visualisierungstexte und eine geschäftsvorfallabhängige 

Darstellung festgelegt werden. 

Nr. Name 

1 Secodervisualisierungstexte 

1 

2 Geschäftsvorfallspezifische 

Visualisierungsin- 

1 

formationen für Secoder 

Typ Format 

Länge 

Status 

Anzahl 

Restriktionen 

DE an ..4KB M 1 

DE an ..4KB M n

Kapitel: 

Seite: 

E 

108 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abschnitt: 


Typ: DEG 

Format: 

Länge: 

Version: 1 

PIN 

(Private Identifikationsnummer) = Online-Banking-PIN (OBanking-PIN). 

Authentisierungsmerkmal des Kunden beim PIN/TAN- oder auch EMV-AC- 

Verfahren (AZS-Verfahren mit S-Fkt=820). Das Format einer PIN ist Kreditinstitutsindividuell. 

Die minimale und maximale Länge der PIN kann das Kreditinstitut im 

Segment HIPINS angeben. 

Typ: 

Format: 

DE 

an 

Länge: ..99 

Version: 1 

R 

Reader-ID 

Eindeutige Identifikationsnummer eines HHD bzw. eines Secoders. 

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 Kreditinstitut die 

Übertragung der Reader-ID verlangen, wenn keine zentralen Bestände zur Verfügung 

stehen oder die Reader-ID für eine zentrale Verwaltung erfasst werden soll. 

Typ: DE 

Format: jn 

Länge: # 

Version: 1



Kapitel: 

Abschnitt: 


Version: 

Stand: 

15.12.2009 

3.0 

Kapitel: 

Seite: 

109 

E 

S 

SAK-Produkt 

Produktbezeichnung einer Signaturanwendungskomponente. 

Typ: DE 

Format: an 

Länge: ..64 

Version: 1 

SAK-Referenz 

Eindeutige Kennzeichnung einer Kombination aus SAK-Produkt und SAK-Version. 

Die SAK-Referenz ist numerisch und streng monoton aufsteigend zu wählen. 

Typ: 

Format: 

DE 

num 

Länge: ..2 

Version: 1 

SAK-Version 

Versionsbezeichnung einer Signaturanwendungskomponente. 

Typ: DE 

Format: an 

Länge: ..64 

Version: 1 

SAK-Visualisierungsdaten 

Diese Datenelementgruppe enthält Visualisierungsdaten für die Signaturanwendungskomponente 

(SAK) in Form von Angeboten oder signierten Aufträgen. Hiermit 

sind nicht die Secodervisualisierungsdaten gemeint; diese werden aufgrund der 

BPD-Steuerung durch HIVISS gebildet. 

Typ: 

Format: 

Länge: 

DE 

bin 

Version: 1 

..2MB

Kapitel: 

Seite: 

E 

110 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abschnitt: 


SAK-Visualisierungsformat 

Kodierung des verwendeten, zu verwendenden Visualisierungsformates für die Visualisierungsdaten 

in der Signaturanwendungskomponente (SAK) bei der Bildung 

von Qualifizierten Signaturen. Hiermit sind nicht die Secodervisualisierungsdaten 

gemeint; diese werden aufgrund der BPD-Steuerung durch HIVISS gebildet. 

Folgende Codes sind gültig: 

0 Keine Visualisierung 

1 Textdaten im ASCII-Format nach FinTS Zeichensatz 

2 Dokumentendaten im PDF-Format 

3 Grafische Daten im TIFF-Format, 

Typ: 

Format: 

Länge: 1 

Version: 1 

DE 

code 


Das DE Secodervisualisierungstexte beinhaltet eine Tabelle aller möglichen Anzeigendefintionen 

für das Secoderdisplay. Die Länge der einzelnen Anzeigedefintionen 

muss sich an der Zeilengröße der zugelassenen Secoderprodukte am Markt 

orientieren. Momentan sind dies 16 Zeichen. Ein einzelner Eintrag der Tabelle besteht 

aus einem maximal dreistellig numerischen Index und zugehörigen Secoder 

MetaData (vgl. Abschnitt „Begriffe“) zur Ansteuerung des Secoders durch eine geeignete 

aktive Komponente. 

Index und Text sowie die einzelnen Index-Text-Kombinationen werden durch „Semikolon“ 

(„;“ – 0x3B nach FinTS-Zeichensatz) getrennt. Die Texte selbst dürfen das 

Zeichen ‚Semikolon‘ nicht enthalten. Die Kodierung erfolgt auf Basis der MetaData 

im FinTS-Zeichensatz. Die Konvertierung in den ISO 646 DE Zeichensatz des Secoders 

wird durch die Secoder-Anwendungsfunktion durchgeführt. Der Zeichenvorrat 

wird allerdings durch die Festlegungen in der Secoder-Spezifikation [Secoder] 

bestimmt, nicht durch den FinTS-Zeichenvorrat. 

N 

r. 

Name Typ Format 

Länge 

Status 

Anzahl 

Restriktionen 


DE num ..3 M 1 

Index 

2 Displayposition DE code 1 O 1 L, R 

3 Länge Secoder- DE num ..2 O 1 

Text 

4 Secoder-Text DE an ..32 O 1 

5 Länge Secoder DE num ..2 O 1 

Eingabedaten 

6 Ausrichtung und 

Format Secoder 

Eingabedaten 

DE dig 2 O 1 00, 01, 

03, 04, 

05, 07 

7 Secoder Padding DE an 2 O 1 D0, DF, 

E0, EF



Kapitel: 

Abschnitt: 


Version: 

Stand: 

15.12.2009 

3.0 

Kapitel: 

Seite: 

111 

E 

Nur bei S-Fkt=820 und 821 darf das Element „Länge Secoder Eingabedaten“ >0 

sein, da nur hier ein Eingeben / Ergänzen von Daten erlaubt ist. 

Die detailliierte Beschreibung der Secoder MetaData befindet sich in Abschnitt 

B.5.1.1. Eine weitere Untergliederung der Elemente im Data Dictionary erfolgt 

nicht. 

Typ: DE 

Format: an 

Länge: ..4096 

Version: 1 

Secodervisualisierungstext Index 

Index auf die Tabelle der Secodervisualisierungstexte. Ein Index muss auf einen 

gültigen Tabelleneintrag verweisen. 

Typ: 

Format: 

DE 

num 

Länge: ..3 

Version: 1 

Secodervisualisierung Finanzdatenformat 

Die Adressierung der Secodervisualisierungsdaten innerhalb eines Geschäftsvorfalls 

oder Finanzdatenformats ist abhängig von dessen Typ. Folgende Datenformate 

sind für die Secodervisualisierung vorgesehen: 

Codierung: 

1: FinTS 

2: DTA 

3: DTAZV 

4: SEPA 

Typ: 

Format: 

Länge: 1 

DE 

Version: 1 

code

Kapitel: 

Seite: 

E 

112 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abschnitt: 


Secodervisualisierung Position 

Je nach Datenformat gibt es unterschiedliche Möglichkeiten der Adressierung der 

Secodervisualisierungsdaten im Auftrag: 

bei FinTS: 

bei DTA 

bei DTAZV: 

bei SEPA: 

oder 

< DEG#>,< DE# in der DEG> 

. 

. 

. 

Bzgl. der Nummern sind die entsprechenden Definitionen der Geschäftsvorfälle 

bzw. Finanzdatenformate heranzuziehen. 

Typ: 

Format: 

DE 

an 

Länge: ..256 

Version: 1 


Kodierte Information über die Sicherheitsfunktion, die auf die Nachricht angewendet 

wird. 

Bis HBCI 2.2: 

dient der Unterscheidung zwischen DDV und RDH, wobei die 1 das RDH-Verfahren 

kennzeichnet und 2 das DDV-Verfahren. 

FinTS V3.0 – Sicherheitsverfahren HBCI: 

Die Sicherheitsfunktion hat ab FinTS 3.0 lediglich informatorischen Wert, da die eigentliche 

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 Geschäftsvorfall 

HKAZS 

Codierung: 

Code Segment Bedeutung 

1 Sicherheitsverfahren HBCI: 

- Signaturkopf 


- Signaturkopf 

Non-Repudiation of 

Origin, für RDH (NRO) 

Message Origin Authentication, 

für RDH und 

DDV (AUT)



Kapitel: 

Abschnitt: 


Version: 

Stand: 

15.12.2009 

3.0 

Kapitel: 

Seite: 

113 

E 


- Verschlüsselungskopf 


- Signaturkopf bei HKAZS, 

















900 Sicherheitsverfahren PIN/TAN: 

- Signaturkopf bei HKTAN, 

- HITANS Verfahrensparameter 






. . . 









Encryption, Verschlüsselung 

und evtl. Komprimierung 

(ENC) 

Fortgeschrittene bzw. 


Signatur ohne Secoder 


Signatur („DS- 





ohne Institutssignatur 




mit verpflichtender Institutssignatur 

Absicherung von Visualisierungsdaten 

durch ein 

EMV Application Cryptogram 

(EMV-AC) mit Secoder 

mit Online- 

Banking-PIN 

Absicherung von Visualisierungsdaten 

durch ein 

EMV Application Cryptogram 

(EMV-AC) mit Secoder 

mit Benutzer-PIN 

1. konkretes Zwei-Schritt- 

TAN-Verfahren 

2. konkretes Zwei-Schritt- 

Verfahren 

97. konkretes Zwei- 

Schritt-Verfahren 

98. konkretes Zwei- 

Schritt-Verfahren

Kapitel: 

Seite: 

E 

114 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abschnitt: 



- Verschlüsselungskopf 

Daten im Klartext (nur in 

Verbindung mit SSL erlaubt) 

999 Signaturkopf Klassisches Ein-Schritt- 

Verfahren 

Typ: DE 

Format: Code 

Länge: ..3 

Version: 2 

Sicherheitskontrollreferenz 

Referenzinformation, mit der die Verbindung zwischen Signaturkopf, dazu gehörigem 

Signaturabschluss und HKAZS hergestellt werden kann. Die Sicherheitskontrollreferenz 

im Signaturkopf muss mit der entsprechenden Information im Signaturabschluss 

und in HKAZS übereinstimmen. 

Typ: DE 

Format: an 

Länge: ..14 

Version: 1 

Sicherheitsprofil 

Verfahren zur Absicherung der Transaktionen, das zwischen Kunde und Kreditinstitut 

vereinbart wurde. Das Sicherheitsprofil wird anhand der Kombination der beiden 

Elemente „Sicherheitsverfahren“ und „Version“ bestimmt (z. B. RDH-3, DDV-1, PIN- 

1, EMV-2). Für das Sicherheitsverfahren PINTAN ist als Code der Wert PIN und als 

Version der Wert 1 einzustellen. 

Nr. Name 

1 Sicherheitsverfahren, 

Code 

2 Version des Sicherheitsverfahrens 

Typ: 

Format: 

Länge: 

Version: 1 

DEG 


Län- 

Sta- 

An- 

Restriktionen 

DE code 3 M 1 DDV, RDH, PIN, EMV 

DE num ..3 M 1 1, 2, 3, 4, 5, 6, 7, 8, 9, 10



Kapitel: 

Abschnitt: 


Version: 

Stand: 

15.12.2009 

3.0 

Kapitel: 

Seite: 

115 

E 

Sicherheitsverfahren, Code 

Code des unterstützten Signatur- bzw. Verschlüsselungsalgorithmus. Weitere Informationen 

zu den Verfahren sind Kapitel B.1 [HBCI] zu entnehmen. 

Codierung:. 

DDV: DES-DES-Verfahren 

RDH: RSA-DES-Hybridverfahren, AZS-Verfahren mit S-Fkt=810, 811, 812 

PIN: 

PIN/TAN-Verfahren 

EMV: EMV-AC-Variante (S-Fkt=820, 821) bei AZS-Verfahren 

Typ: DE 

Format: code 

Länge: 3 

Version: 3 

Signaturdaten 

Ergebnis der Signaturbildung bei AZS-Verfahren, unabhängig von der Art der erzeugten 

Signatur. 

Folgende Inhalte sind für das DE Signaturdaten möglich: 

S-Fkt. Inhalt des DE „Signaturdaten“ 

800 Qualifizierte Signatur, wie sie von der SAK erzeugt wurde (SAK-Sig) 

810 Qualifizierte Signatur, wie sie von der SAK mit Hilfe der Secoder- 

Applikation „dig“ erzeugt wurde (SAK-Sig) 

811 Fortgeschrittene Signatur, wie sie mit Hilfe der Secoder-Applikation „aut“ 

erzeugt wurde (VisDataSig) bzw. HBCI-RDH-Signatur bei Signatur- 

Prozess=7 

812 Fortgeschrittene Signatur, wie sie mit Hilfe der Secoder-Applikation „aut“ 

erzeugt wurde (VisDataSig) bzw. HBCI-RDH-Signatur bei Signatur- 

Prozess=7 

820 EMV application cryptogram, wie es mit Hilfe der Secoder-Applikation „tan“ 

erzeugt wurde (VisDataSig) 

821 EMV application cryptogram, wie es mit Hilfe der Secoder-Applikation „tan“ 

erzeugt wurde (VisDataSig) 

Typ: DE 

Format: bin 

Länge: ..4096 

Version: 1

Kapitel: 

Seite: 

E 

116 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abschnitt: 


Signatur-Prozess 

Bei der Verwendung der Elektronischen Signatur werden die notwendigen Prozess- 

Schritte mittels des Geschäftsvorfalls HKAZS durchgeführt. Der Signatur-Prozess 

wird wie folgt kodiert: 

Signatur-Prozess 2 bis 5 (Zwei-Schritt-AZS-Verfahren) 

Im ersten Schritt wird der Auftrag komplett über das normale Auftragssegment 

eingereicht, jedoch ohne Hinzufügen von Signaturdaten. Im zweiten 

Schritt erfolgt auf Basis der übermittelten Visualisierungsdaten die Signaturbildung 

analog dem gewählten alternativen Sicherheitsverfahren durch den 

Benutzer. Die signierten Daten werden dann inklusive der Signaturdaten als 

Auftrag über den Geschäftsvorfall HKAZS eingereicht. 

Abfolge der Segmente am Beispiel HKUEB: 

Schritt 1: HKUEB und HKAZS HIAZS 

Schritt 2: HKAZS HIAZS und HIRMS zu HIUEB 


kann nur im zweiten Schritt auftreten. Er dient zur Einreichung eines Auftrags 

inklusive der Signaturdaten des Benutzers und ggf. auch des Instituts. 

Dieser Geschäftsvorfall wird mit einer allgemeinen Kreditinstitutsnachricht 

und Rückmeldungscodes beantwortet. 


kann nur im ersten Schritt bei dialogübergreifender / zeitversetzter Verarbeitung 

für die Nachreichung einer ersten und das Hinzufügen einer zweiten 

Signatur auftreten. Hierdurch wird die Einreichung eines unterzeichneten 

Auftrags eingeleitet, wenn dialogübergreifende / zeitversetzte Einreichung 

signierter Aufträge erlaubt ist. 


kann nur im ersten Schritt auftreten. Hiermit wird ein Antrag eingereicht und 

ein Angebot angefordert. HKAZS wird zusammen mit dem Auftragssegment 

übertragen und durch HIAZS mit Belegung analog Signatur-Prozess=4 beantwortet. 

In der Kreditinstitutsantwort HIAZS befindet sich das Angebot ggf. 

inklusive der Institutssignatur. 


kann nur bei der Dialoginitialisierung auftreten. Hiermit wird eine fortgeschrittene 

Authentifizierungssignatur mit den Anmeldedaten eines Benutzers eingereicht. 

In der Kreditinstitutsantwort HIAZS mit Belegung analog Signatur- 

Prozess=5 befindet sich im DE „Visualisierungsdaten“ der Hashwert über 

das Institutszertifikat und die zugehörige Institutssignatur. 

Signatur-Prozess 6 bis 7 (Ein-Schritt-AZS-Verfahren) 


Kennzeichnet die Auftragseinreichung inkl. aller Sicherheitsinformationen 

mit den AZS-Verfahren der Sicherheitsfunktionen 811 und 812 sowie 820 

und 821 , soweit es sich um Secoder-Signaturen inklusive Secoder- 

Visualisierung handelt. 


Kennzeichnet Signaturen mit den AZS-Verfahren der Sicherheitsfunktionen 

811 und 812, sowie 820 und 821, bei denen keine Secoder-Visualisierung 

erfolgt.



Kapitel: 

Abschnitt: 


Version: 

Stand: 

15.12.2009 

3.0 

Kapitel: 

Seite: 

117 

E 

Typ: 

DE 

Format: 

Code 

Länge: 1 

Version: 1 

T 

TAN-Medium-Klasse 

dient der Klassifizierung der möglichen TAN-Medien. Bei Geschäftsvorfällen zum 

Management der TAN-Medien kann aus diesen nach folgender Codierung selektiert 

werden. 

Codierung: 

L: Liste 

G: TAN-Generator 

M: Mobiltelefon mit mobileTAN 

S: Secoder 

Typ: DE 

Format: code 

Länge: 1 

Version: 2 

U 

Unterstützte EMV AC Versionen 

Information über die kreditinstitutsseitig unterstützten Versionen des EMV AC Sicherheitsverfahrens 

(vgl. Element „Version des Sicherheitsverfahrens“ ). Wird dieses 

Datenelement weggelassen, so sind keine EMV AC Verfahren (derzeit sind 

dies die Sicherheitsfunktionen 820 und 821) unterstützt. 

Typ: DE 

Format: num 

Länge: 1 

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.

Kapitel: 

Seite: 

E 

118 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abschnitt: 


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 erforderlich ist 

oder nicht. 

Typ: 

Format: 

DE 

jn 

Länge: # 

Version: 1 

Version des Sicherheitsverfahrens 

Version des unterstützten Sicherheitsverfahrens (s. „Sicherheitsverfahren, Code“). In Kombination 

mit dem HBCI-Sicherheitsverfahren RDH sind die folgenden Versionen gültig: 

Version Signaturverfahren Schlüssellänge Hashverfahren Schlüsselart* 

(bit) 

1 ISO 9796-1 708-768 RIPEMD-160 S, V 

2 DIN, ISO 9796-2 1024-2048 RIPEMD-160 S, V 

3 DIN, ISO 9796-2 

PKCS#1 V1.5 

1024-2048 RIPEMD-160 

SHA-1 

D, 

S, V 

4 PKCS#1 V1.5 1024-2048 SHA-1 D, S, V 

5 PKCS#1 V1.5 1024-2048 SHA-1 S,V 

6 PKCS#1 V1.5 1536-4096 SHA-256 D, S, V 

7 PKCS#1 PSS 1536-4096 SHA-256 D, S, V 

8 PKCS#1 V1.5 1536-4096 SHA-256 S, V 

9 PKCS#1 PSS 1536-4096 SHA-256 S, V 

10 PKCS#1 PSS 1536-4096 SHA-256 S, V 

In Kombination mit dem Sicherheitsverfahren DDV sind die folgenden Versionen gültig 

(nicht bei AZS-Verfahren zugelassen!): 


(bit) 

1 MAC 128 RIPEMD-160 S, V 

2 MAC 128 SHA-256 S, V 

Bei Verwendung des Sicherheitsverfahrens PIN/TAN sind die folgenden Versionen gültig 

(nicht bei AZS-Verfahren zugelassen!): 

Version Signaturverfahren 

1 PINTAN 

Schlüssellänge 

(bit) 

Hashverfahren 

Schlüsselart*



Kapitel: 

Abschnitt: 


Version: 

Stand: 

15.12.2009 

3.0 

Kapitel: 

Seite: 

119 

E 

2 PINTAN 

Bei Verwendung der chipkartenbasierten AZS-Verfahren können bei der S-Fkt=810, 811 

und 812 folgenden Versionen auftreten: 

Version Signaturverfahren 

3 DIN, ISO 9796-2 

PKCS#1 V1.5 

Schlüssellänge Hashverfahren 

(bit) 

1024-2048 RIPEMD-160 

SHA-1 

Schlüsselart* 

D, 

S, V 

5 PKCS#1 V1.5 1024-2048 SHA-1 S,V 

6 PKCS#1 V1.5 1536-4096 SHA-256 D, S, V 

7 PKCS#1 PSS 1536-4096 SHA-256 D, S, V 

8 PKCS#1 V1.5 1536-4096 SHA-256 S, V 

9 PKCS#1 PSS 1536-4096 SHA-256 S, V 

In Kombination mit dem AZS-Verfahren EMV-AC (S-Fkt=820, 821) sind die folgenden Versionen 

gültig: 


(bit) 

1 EMV 128 RIPEMD-160 S 

2 EMV 128 SHA-256 S 

* s. Element „Schlüsselart“ 

Andere als die genannten Profile sind nicht zulässig. 

Typ: DE 

Format: num 

Länge: ..3 

Version: 3 

Visualisierungsbestätigungssignaturfüllwert 

Die Secoder-Spezifikation lässt zwei unterschiedliche Arten von Fülldaten bei der 

Bildung einer Visualisierungssignatur zu. Die folgenden Codierungen sind erlaubt: 

Codierung: 

1: String "SECODERSECODERSECODE" 

2: Eindeutige Reader ID, mit “SECODERSECODERSECODE“ 

aufgefüllt auf 20 bytes 

Typ: DE 

Format: code 

Länge: 1 

Version: 1 

Visualisierungsbestätigungssignaturdaten

Kapitel: 

Seite: 

E 

120 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abschnitt: 


Ergebnis der Signaturbildung über die zwischengespeicherten visualisierten Daten 

beim Secoder in einem extra Schritt. Dadurch wird sichergestellt, dass ein Secoder 

sich zum Zeitpunkt der Signaturbildung im Applikationsmodus befand. Die Visualisierungsbestätigungssignatur 

wird mit der Applikation „aut“ gebildet. 

Typ: 

Format: 

DE 

bin 

Länge: ..4096 

Version: 1 

W 

Weitere Signatur folgt 

Das Kundenprodukt teilt mit, ob dies die letzte / einzige benötigte Elektronische 

Signatur für den bereits eingereichten Auftrag ist, oder ob noch mindestens eine 

weitere Signatur eingereicht wird. 

 

Kundenprodukte können entweder aus der UPD („Anzahl 

benötigter Signaturen“) oder aufgrund eigener Administrationsfunktionen 

entscheiden, ob für einen Auftrag noch weitere 

Signaturen benötigt werden. 

Typ: DE 

Format: jn 

Länge: # 

Version: 1 

Z 

Zeit- und Dialogbezug für alternative ZKA Sicherheitsverfahren 

Beschreibung der protokolltechnischen Möglichkeiten, die dem Kunden vom Verarbeitungsprozess 

her zur Verfügung stehen. Es wird festgelegt, ob ein unterschriebener 

Auftrag synchron in einem Dialog abgearbeitet werden muss oder dies zeitversetzt 

in mehreren Dialogen erfolgen kann. Es wird auch festgelegt, ob ein Institut 

nur eines dieser Verfahren oder beide parallel anbietet. 

Folgende Codes sind gültig: 

1 Signatur nicht zeitversetzt / dialogübergreifend erlaubt 

2 Signatur zeitversetzt / dialogübergreifend erlaubt 

3 beide Verfahren unterstützt 

Typ: 

Format: 

Länge: 1 

DE 

Version: 1 

code



Kapitel: 

Abschnitt: 


Version: 

Stand: 

15.12.2009 

3.0 

Kapitel: 

Seite: 

121 

E 

Zulässige Signaturanwendungskomponenten 

Definition der kreditinstitutsseitig erlaubten Signaturanwendungskomponenten. Jede 

Kombination von SAK-Produkt und SAK-Version erhält zur Referenzierung eine 

eindeutige SAK-Referenz. 

Da die n zulässigen Signaturanwendungskomponenten aus syntaktischen Gründen 

nicht mehr modelliert werden können, werden diese mittels „Semikolon“ („;“ – 0x3B 

nach FinTS-Zeichensatz) getrennt. Je zulässiger Signaturanwendungskomponente 

wird die folgende Struktur verwendet: 

Nr. Name Typ Format 

Länge 

Status 

Anzahl 

1 SAK-Referenz DE num ..2 M 1 

2 SAK-Produkt DE an ..64 M 1 

Restriktionen 

3 SAK-Version DE an ..64 M 1 

Typ: DE 

Format: an 

Länge: ..1KB 

Version: 1

Kapitel: 

Seite: 

E 

122 

Version: 

3.0 

Stand: 

15.12.2009 



Kapitel: 

Abschnitt: 

Anlagen 

Übersicht der Segmente 

F. ANLAGEN 

F.1 Übersicht der Segmente 

Nr. Segmentname Kennung Sender 

Version 

2 

1 Alternative ZKA-Sicherungsverfahren HKAZS K 1 

2 Alternative ZKA-Sicherungsverfahren Parameter HIAZSS I 1 

3 Alternative ZKA-Sicherungsverfahren Rückmeldung HIAZS I 1 

4 Secoderspezifische Visualisierungsinformationen HIVISS I 1 

F.2 Übersicht Nachrichtenaufbau 

Nachricht 

Segment Dialoginitialisierung Auftragsnachricht Dialogbeendigung 

Kunde Kreditinstitut 

Kunde Kredit- 

Kunde Kredit- 

N6 N2 N15 institut N14 N8 institut 

N14 

Nachricht 1 1 0-n 0-n 1 1 

HNHBK 1 1 1 1 1 1 

HNVSK 1 1 1 1 1 1 

HNVSD 1 1 1 1 1 1 

HNSHK 1 0-1 1-3 0-1 1 - 

HIRMG - 1 - 1 - 1 

HIRMS - 0-m - 0-m - 0-m 

HKIDN 1 - - - - - 

HKVVB 1 - - - - - 

HKISA 0-2 - - - - - 

HKSYN - - - - - - 

HIBPA - 0-1 - - - - 

HIKOM - 0-1 - - - - 

HISHV - 0-1 - - - - 

HIKPV - 0-1 - - - - 

HIUEBS - 0-n - - - - 

... 3 - 0-n - - - - 

HIAZSS - 0-1 - - - - 

HIVISS - 0-1 - - - - 

HIUPA - 0-1 - - - - 

HIUPD - 0-n - - - - 

HIISA - 0-2 - - - - 

HISYN - - - - - - 

HIKIM - 0-n - - - - 

2 

3 

K: Kunde, I: Kreditinstitut 

Hier sind für die weiteren unterstützten Geschäftsvorfälle die entsprechenden Parameter-Segmente 

einzustellen.



Kapitel: 

Abschnitt: 

Anlagen 

Übersicht Nachrichtenaufbau 

Version: 

Stand: 

15.12.2009 

3.0 

Kapitel: 

Seite: 

123 

E 

Nachricht 

Segment Dialoginitialisierung Auftragsnachricht Dialogbeendigung 

Kunde Kreditinstitut 

Kunde Kredit- 

Kunde Kredit- 

N6 N2 N15 institut N14 N8 institut 

N14 

HKSAL 4 - - 1 - - - 

HISAL - - - 0-n - - 

... - - - - - - 

HKAZS 1 - 0-3 - - - 

HIAZS - 0-1 - 0-1 - - 

HKPRO - - 0-1 - - - 

HIPRO - - - 0-n - - 

HKEND - - - - 1 - 

HNSHA 1 0-1 1-3 0-1 1 - 

HNHBS 1 1 1 1 1 1 

4 

Exemplarisch wird hier der Geschäftsvorfall „Saldenabfrage“ angenommen.

Financial Transaction Services (FinTS)

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?