Posts mit dem Label Teilnehmer werden angezeigt. Alle Posts anzeigen
Posts mit dem Label Teilnehmer werden angezeigt. Alle Posts anzeigen

Wie sich EBICS verbessern lässt, Teil 6 – eindeutige Identifikation der handelnden Person

Kann es vorkommen, dass ein Zahlungsverkehrsauftrag, der in EBICS eigentlich von zwei unterschiedlichen Personen autorisiert werden muss, doch nur von einer Person freigegeben wird? Ja, unter bestimmten Umständen ist das möglich. Bei manchen Vertragskonstellationen zwischen dem Kreditinstitut und dem Firmenkunden lässt sich die handelnde Person nicht eindeutig identifizieren. 


Die Falle steckt im EBICS-Datenmodell

Das Berechtigungsmodell des Firmenkunden für die EBICS-Kommunikation orientiert sich am Datenmodell von EBICS. Dieses unterscheidet zwischen dem Kunden und seinem Mitarbeiter als EBICS-Teilnehmer.

Firmenkunden kommunizieren per EBICS mit ihrer Bank über eine unternehmensweit gültige EBICS-Kunden-ID und die Teilnehmer-ID des handelnden Mitarbeiters. Die IDs vergibt die Bank bei der Einrichtung für den Kunden und seinen Mitarbeiter; der Kunde benötigt sie für die Verbindung zum Bankrechner in den Zugängen der EBICS-Clients. Nun ist eben diese Teilnehmer-ID nicht immer eindeutig. Wie kann das sein?

Firmenkunden nutzen verschiedene EBICS-Clients

Größere Firmenkunden setzen auch mal mehrere EBICS-Clients unterschiedlicher Hersteller ein. Dabei nutzt ein Mitarbeiter je nach Funktionsumfang auch verschiedene Clients parallel. Ein Beispiel ist der Mitarbeiter, der mit einem EBICS-PC-Produkt Zahlungen autorisiert und einreicht – und der gleichzeitig Zahlungen, die aus seiner ERP-Lösung für die in Deutschland übliche Verteilte Elektronische Unterschrift direkt zur Bank gesendet worden sind, per EBICS-Mobile-Lösung autorisiert.

Schlüssel und Zertifikate sind häufig nicht wiederverwendbar

Da die teilnehmerbezogenen Schlüssel bzw. Zertifikate je nach Kundensystem und EBICS-Land unterschiedlich abgelegt sind, kann ein Mitarbeiter sie in den meisten Fällen nicht für alle EBICS-Clients übergreifend nutzen. Sprich, das EBICS-PC-Produkt und die EBICS-Mobile-Lösung erfordern jeweils eigene Schlüssel für den Teilnehmer. Daher hat der Mitarbeiter für seinen EBICS-Zugang zur Bank in jedem Client eine andere Teilnehmer-ID, die dann die Verbindung zu seinen jeweiligen Schlüsseln bzw. Zertifikaten sicherstellt.

Da das Datenmodell von EBICS aber den EBICS-Teilnehmer als eindeutige handelnde Person definiert, kann theoretisch eine Person mit mehreren Teilnehmer-IDs Zahlungen freigeben, die eigentlich von mehreren Personen autorisiert werden müssen. Im EBICS-Datenmodell ist die Zuordnung einer Person zu mehreren Teilnehmer-IDs nicht vorgesehen.

Um einen derartigen Missbrauch zu verhindern verfügen EBICS-Bankrechner mittlerweile über zusätzliche individuelle Berechtigungsfunktionen, dennoch ist eine einheitliche Lösung im EBICS-Standard selbst wünschenswert.

Einheitliches Austauschformat für Schlüssel und Zertifikate

Eine Möglichkeit wäre es z. B., im EBICS-Standard das Austauschformat bzw. die Ablage der Schlüssel und Zertifikate einheitlich vorzuschreiben, z. B. einen Software-Token mit der Ablage im PKCS12-Format. In diesem Fall ist die Teilnehmer-ID eindeutig nutzbar, um die handelnde Person zu identifizieren. Schlüssel und Zertifikate können somit in Verbindung mit der Teilnehmer-ID auf mehreren Clients genutzt werden.

Michael Lembcke 

Blog-Serie: Wie sich EBICS verbessern lässt, Teil 5 – Kunden verwalten Konten und Teilnehmer selbst

EBICS bringt von Haus aus nützliche Auftragsarten für die Abfrage von Kunden- und Teilnehmerinformationen mit (welche notabene nicht alle Hersteller konsequent in ihren Produkten anbieten). Gemeint sind hier z. B. die Auftragsarten HKD (Kundendaten abrufen) und HTD (Teilnehmerdaten abrufen). Nach den Wünschen der Schweizer Grossbanken sollte es möglich sein, diese Stammdaten nicht nur abzufragen, sondern selbst zu verwalten und auch zu verändern.



Eine Besonderheit der Schweizer Implementierung ist aktuell die Beschränkung auf die Unterschriftsarten „T“ und „E“. Im ersten Fall erfolgt die notwendige zusätzliche Freigabe über einen separaten Kanal (z. B. Onlinebanking). Im zweiten Fall wird der Auftrag augenblicklich verarbeitet, da der Auftraggeber selbst für die notwendigen Sicherheitsvorkehrungen zu sorgen hat. In der Regel ist die Person, die signiert hat, im Fall „E“ nicht bekannt, sondern lediglich der Kunde respektive die auftraggebende Firma.

Als wichtigster Grund, die VEU in der Schweiz nicht anzuwenden, wird der zu hohe Aufwand für die Administration der VEU-Rechte auf Teilnehmern und Konten angeführt. Da die Kundenstammdaten der Bank oft nicht direkt mit dem EBICS-Produkt verknüpft sind, fallen Doppelerfassungen an, welche bei einer gewissen Anzahl von Kunden und Veränderungen der Berechtigungen ins Gewicht fallen. Gesucht ist ein Mechanismus im Sinne eines Electronic Bank Account Management (eBAM).
Im Standard ISO 20022 sind für diese Zwecke bereits fünfzehn Meldungen modelliert (siehe Meldungskategorie acmt). Die ISO-Meldungen können als Basis dienen, das EBICS-Protokoll so zu erweitern, dass der Kunde die Konten und Teilnehmer zumindest teilweise selbst verwalten kann. Die mehrfache Bestätigung mittels Signaturen auf Kundenseite und ein Vier-Augen-Prinzip auf Bankseite könnten je nach Sicherheitsanforderung entsprechend kombiniert werden. Der Kunde müsste beispielsweise eine heikle Transaktion doppelt prüfen, und die Bank müsste die Transaktion als letzten Schritt manuell freigeben (jedoch nicht mehr selbst komplett erfassen).

Mit einer institutsspezifischen Auftragsart (XYZ) für die Übermittlung von XML-Konto- und Teilnehmerdaten wäre dies bereits heute möglich. Bankseitig würden die Berechtigungen entsprechend geprüft und mittels Schnittstelle zum EBICS-Produkt (z. B. Webservices) automatisiert angewendet. Aus Schweizer Sicht herrscht diesbezüglich aktuell eher etwas Zurückhaltung, hat man doch bereits zahlreiche Schweizer Auftragsarten auf diese Art und Weise eingeführt, die man in naher Zukunft durch ein generelles Konzept auf Basis der französischen Anwendung von FUL/FDL ablösen möchte. Wir würden es begrüssen, wenn diese Anforderung in eine zukünftige Auftragsbeschreibung in EBICS einfliessen könnte. Von mehr Automation würden sowohl der Kunde wie auch die Bank profitieren.

Carsten Miehling 

Blog-Serie: Wie sich EBICS verbessern lässt, Teil 4 – jeder Person die eigenen Kontoauszüge

Ein großer Teil der Daten, die ich als Firmenkunde mit EBICS von einem Bankrechner abhole, hat einen Kontobezug. Wie kann ich aber für diese Daten bereits bei der Abholung steuern, welcher meiner Mitarbeiter welche Kontoauszüge bekommen darf? Dabei kann eine bankrechnerseitige Steuerung helfen.


EBICS regelt die Einreichung und die Abholung von beliebigen Daten per Auftragsarten bzw. Formatparameter. Das mit der Auftragsart verbundene Datenformat entscheidet dabei letztendlich über die Verarbeitungsmöglichkeiten im EBICS-Bankrechner. Die Inhalte der Datenbereitstellung und Abholung selbst sind jedoch nicht durch EBICS geregelt; sie können daher von EBICS-Bankrechner zu EBICS-Bankrechner und von Kreditinstitut zu Kreditinstitut abweichen.

Welcher EBICS-Teilnehmer bekommt welche Kontoinformationen?

Die Daten, die Mitarbeiter als EBICS-Teilnehmer abholen, werden üblicherweise pro Kunde auf dem Bankrechner zum Download bereitgestellt. Jeder EBICS-Teilnehmer des Kunden, der über die passende Auftragsart verfügt, erhält alle Daten, die für den Kunden bereitstehen. Das gilt ebenso für kontobezogene Daten wie Kontoauszüge und Vormerkposten. Bei der EBICS-Abholung wird die Kontoberechtigung des EBICS-Teilnehmers nicht geprüft, bei der Einlieferung von Zahlungsverkehrsaufträgen in der Kunde-Bank-Beziehung dagegen sehr wohl. EBICS selbst sieht zudem keine Kontoangaben in der EBICS-Nachricht vor. Kontobezogene Prüfungen und Verarbeitungen hängen von der Implementierung des Bankrechners ab – und im Wesentlichen auch davon, ob die Kontoangaben der bereitzustellenden Daten vollständig sind und die Konten gefunden werden.

Kontoberechtigung für Abholungen

In bestimmten Fällen sollte ein EBICS-Teilnehmer lediglich Informationen zu bestimmten Konten bekommen. Eine naheliegende Lösung wäre es, die Daten statt pro Kunde pro Teilnehmer bereitzustellen. Da die Daten allerdings auf den Firmenkunden bezogen sind, führt dies bei mehreren Teilnehmern pro Kunde zu redundanten Daten und somit einem erhöhten Datenvolumen. Vorzuziehen ist daher, die Daten wie üblich je Kunde abzulegen und die Abholung über die Kontoberechtigung am Teilnehmer zu steuern (sofern es sich um kontenbezogene Daten handelt). So bekommt der Teilnehmer stets genau die Daten aller Konten, für die er berechtigt ist.
Sinnvoll wäre zusätzlich eine EBICS-Erweiterung, die es erlaubt, im EBICS-Request ein oder gar mehreren Konten anzugeben – ähnlich der Angabe eines Zeitraums beim historischen Abruf. Mit dieser EBICS-Funktion könnte ein EBICS-Teilnehmer optional auch Daten von bestimmten Konten abrufen. Für den Teilnehmer ist es nicht immer wichtig, dass die Kontoinformationen aller Konten aktuell sind. Eine entsprechende EBICS-Erweiterung ermöglicht eine gezieltere Abholung und bietet dem Kunden letztendlich mehr Flexibilität im Kontenabruf.

Michael Lembcke