Unabhängiger GLS-EBICS-Abruf: Betriebs- und Architekturleitfaden

Status und Ziel

Dieses Dokument beschreibt einen Vorschlag für einen eigenständigen, ausschließlich herunterladenden EBICS-Connector zur GLS Gemeinschaftsbank eG. Es ist keine implementierte Bankanbindung, keine Freigabe für den Produktivbetrieb und keine Aussage, dass eine bestimmte Softwarebibliothek von GLS unterstützt wird. Es wurden keine Bankeinstellungen, Schlüssel, Teilnehmer oder Berechtigungen geändert.

Ziel ist ein paralleler Kontoauszugsabruf, ohne den vorhandenen Frisbii-Transform-Zugang zu verändern. Der neue Connector soll Umsatzinformationen dauerhaft und nachweisbar übernehmen. Er soll keine Lastschriften, Überweisungen oder sonstigen Zahlungsaufträge einreichen.

Verifizierte Ausgangslage

Öffentliche GLS-Informationen

GLS nennt für EBICS den Host MULTIVIA und den HTTPS-Endpunkt https://ebics.multivia-suite.de/ebicsweb/ebicsweb. Die Bank führt C53 für Tagesumsätze als Standardart und C52 für Vormerkposten sowie C54 für Sammelbuchungsdateien beziehungsweise Soll-/Haben-Avis als besondere Auftragsarten. CDD reicht SEPA-Basislastschriften ein, CCT reicht SEPA-Überweisungen ein. Diese beiden Upload-Arten gehören nicht in einen Download-Connector.

Für neue Umsatzdatenbereitstellungen ist bei GLS seit September 2025 camt.05x Version 08 maßgeblich. Die Zuordnung lautet insbesondere:

GLS hält Umsatzinformationen zeitlich begrenzt bereit und kennzeichnet sie bei der ersten Abholung innerhalb einer Kunden-ID. Werden zwei voneinander unabhängige Datenbanken unter derselben Kunden-ID betrieben, können sich die Abrufe gegenseitig Daten wegnehmen. GLS empfiehlt dafür eine weitere Kunden-ID und nennt für den Antrag das Stichwort „zweite Kunden-ID wegen doppelter Bereitstellung“. Deshalb soll die bestehende Frisbii-Kunden-ID während Aufbau und Paralleltest nicht wiederverwendet werden. Ob GLS im Einzelfall eine andere sichere Bereitstellung anbietet, ist vor Bestellung schriftlich zu bestätigen.

In den GLS-DFÜ-Bedingungen ist die Partner-ID die Kunden-ID. Sie bezeichnet den Kundenzugang, in dessen Bereitstellung die Abholmarkierung wirkt. Jedem Teilnehmer ordnet die Bank zusätzlich eine eindeutige User-ID zu. Eine zweite User-ID unter derselben Kunden-ID trennt zwar Schlüssel und Teilnehmer, löst aber nicht das Problem gemeinsam als abgeholt markierter Daten. Für den parallelen Connector sind daher eine zweite Kunden-ID und eine eigene User-ID erforderlich.

Quellen: GLS: Alles zu EBICS, GLS: ISO 20022, GLS: Bedingungen für die Datenfernübertragung.

C53/camt.053 enthält gebuchte Auszugsposten. Der Abruf reicht weder CDD noch CCT ein und beweist für sich allein nicht Annahme oder Erfüllung eines bestimmten Zahlungsauftrags. EBICS-Quittungen, HAC und Payment-Status-Reports sind technische beziehungsweise auftragsbezogene Statusevidenz. Sie dürfen erst mit einer fachlich passenden Konto- oder Settlement-Evidenz als Zahlungserfolg bewertet werden.

Beobachtete Frisbii-Konfiguration

Die interne, am 6. September 2026 nur lesend beobachtete House-Bank-Ansicht zeigte GLS, MULTIVIA, den genannten GLS-Endpunkt, EBICS 3.0 und C53/camt.053. Der automatische tägliche Kontoauszugsabruf war aus, der tägliche SEPA-XML-Upload an. Sichtbar waren unter anderem HTD, HPB, C53, HAC, CDD und CCT als erlaubte Berechtigungen. Ein historischer CDD-Logeintrag belegte Dateiannahme und Signaturprüfung; er belegt keine Zahlung oder Kontobelastung.

Diese Beobachtung beschreibt nur den bestehenden Frisbii-Zugang. Sie ist kein Muster für den neuen Connector. Frisbii dokumentiert selbst, dass seine direkte EBICS-Anbindung sowohl CAMT-Abruf als auch SEPA-Upload unterstützt und mit dem EBICS-Benutzer des Händlers arbeitet. Der unabhängige Connector erhält deshalb eigene Identitäten, Schlüssel und eine engere Bankberechtigung.

Die ebenfalls nur lesend beobachtete Frisbii-Seite #/logs/ebics-logs verlangt einen Datumsbereich und bietet Aktionsfilter wie Datei-Download, Datei-Upload, Akzeptiert, Abgelehnt und Signaturprüfung. Das sind Filter über historische Logs, keine Schaltflächen für Bankaufträge und kein Beleg für den Ausgang einer Zahlung.

Quelle: work-log-2026-09-06.md, Frisbii Transform: EBICS.

Bei GLS zu beantragender Zugang

Der Antrag sollte folgende Punkte ausdrücklich enthalten:

1. eine zweite EBICS-Kunden-ID zur doppelten Bereitstellung, getrennt von Frisbii;

2. einen eigenen Teilnehmer beziehungsweise Benutzer für den neuen Connector;

3. Zugriff nur auf die ausdrücklich benannten Konten;

4. Download-Berechtigung für C53 sowie, falls fachlich benötigt, C52 und C54;

5. schriftliche Auskunft, welche administrativen Auftragsarten GLS verlangt: HPB zum Abruf der Bankschlüssel, HTD falls für Teilnehmer-/Berechtigungsdaten unterstützt, HAA für aktuell bereitliegende Transaktionsformate und HAC falls für Kundenprotokolle erforderlich;

6. keine Berechtigung für CDD, CCT, VEU-Einreichungen oder andere fachliche Datei-/Zahlungsuploads; nur die systembedingten INI-/HIA-Nachrichten der Teilnehmerinitialisierung bleiben zulässig;

7. Bestätigung von EBICS-Version, BTF-Zuordnung und camt.05x-Version 08;

8. schriftliche Bestätigung der Einrichtungs- und laufenden Gebühren für genau diesen zweiten Kundenzugang.

Eine N-Vollmacht allein ist keine hinreichende Read-only-Garantie. GLS beschreibt N als Auskunfts-/Transportvollmacht: Sie kann Kontostände und Umsätze abrufen, aber auch Zahlungsverkehr vorbereiten und in die verteilte elektronische Unterschrift (VEU) übertragen. Maßgeblich ist daher die Kombination aus Kontobindung und bankseitig verweigerten Upload-Auftragsarten.

Eine geeignete Formulierung für die Anfrage ist:

Wir benötigen für eine zweite, technisch unabhängige Datenbank eine weitere EBICS-Kunden-ID wegen doppelter Bereitstellung. Bitte richten Sie einen eigenen Teilnehmer ausschließlich für den Abruf der benannten Konten ein. Benötigt werden C53 und optional C52/C54. Bitte bestätigen Sie die für Initialisierung und Betrieb erforderlichen administrativen Auftragsarten. Außer den systembedingten INI-/HIA-Nachrichten sollen CDD, CCT, VEU-Einreichungen und sämtliche fachlichen Datei- oder Zahlungsuploads nicht freigeschaltet werden. Bitte bestätigen Sie EBICS-Version, BTF-/camt-Versionen und die Kosten vor Einrichtung.

Schlüsselinitialisierung und Aktivierung

Der Connector erzeugt und verwaltet eigene EBICS-Schlüssel. Schlüsselmaterial wird weder aus Frisbii exportiert noch zwischen den beiden Zugängen geteilt.

Der vorgeschlagene Aktivierungsablauf lautet:

1. Mandant, GLS-Host, neue Kunden-ID und neuen Teilnehmer in einem deaktivierten Konfigurationsdatensatz anlegen.

2. Signatur-, Authentifikations- und Verschlüsselungsschlüssel in einem geschützten Key Store erzeugen. In der Anwendungsdatenbank stehen nur Schlüsselreferenzen und öffentliche Metadaten.

3. Teilnehmerinitialisierung mit INI und HIA durchführen und den von GLS verlangten Initialisierungsbrief beziehungsweise Freigabeprozess abschließen.

4. Nach Bankaktivierung HPB abrufen. Die erhaltenen öffentlichen Bankschlüssel beziehungsweise Zertifikatsfingerprints über einen zweiten, vertrauenswürdigen Kanal mit den von GLS veröffentlichten oder individuell bestätigten Werten vergleichen.

5. Erst nach dokumentierter HPB-Prüfung den Teilnehmer für C53-Testabrufe freigeben. C52/C54 folgen einzeln nach fachlichem Bedarf und Bankbestätigung.

6. Falls GLS HTD unterstützt, dessen Teilnehmer-/Berechtigungsdaten mit der schriftlichen GLS-Bestätigung zu Konten und Rechten abgleichen. HAA zeigt operativ, für welche Formate aktuell Daten zur Abholung bereitliegen; es ist kein vollständiges Berechtigungsverzeichnis. Jede fachliche Upload- oder VEU-Einreichungsberechtigung blockiert die Aktivierung, bis GLS die Abweichung geklärt hat.

Die EBICS-Spezifikation 3.0.2 und die zugehörigen H005-XML-Schemata sind die technische Referenz. Der Client muss HTTPS/TLS und die EBICS-eigenen Signatur-, Authentifikations- und Verschlüsselungsverfahren korrekt umsetzen. EBICS ist kein JSON-REST-Protokoll: Requests, Responses und administrative Belege sind XML; Auftragsdaten können in Segmenten übertragen werden, und der Client muss Transaktions-ID, Segmentfolge und abschließende Empfangsbestätigung nach Spezifikation behandeln. Ein HTTP-200 allein bedeutet weder vollständige Nutzdaten noch einen abgeschlossenen Abruf.

Quellen: EBICS SC: Spezifikation 3.0.2, EBICS SC: H005-XML-Schemata, GLS: veröffentlichte Bankschlüssel und Serverdaten.

Vorgeschlagene Softwarearchitektur

flowchart LR
  S[Mandantenbezogener Scheduler] --> C[Download-only EBICS Client]
  K[Key Store] --> C
  C -->|HTTPS + EBICS 3 XML| G[GLS MULTIVIA]
  G -->|C53 / optional C52 C54| C
  C --> R[Unveränderlicher Rohdatenspeicher]
  R --> P[Versionierter CAMT Parser]
  P --> N[Normalisierte Bankumsätze]
  C --> A[Sanitiertes Audit und Metriken]
  P --> A

Sicherheitsgrenze

Jede Verbindung ist genau einem Merchant, einer Bankverbindung, einer GLS-Kunden-ID und einem Teilnehmer zugeordnet. Geheimnisse und private Schlüssel liegen in einem Key Store unter mandantenspezifischen Referenzen. Ein Worker erhält nur die Referenz des auszuführenden Abrufs; er darf keinen freien Host, keine freie Kunden-ID und keine Auftragsart aus Jobdaten übernehmen.

Die betriebliche Konfiguration besitzt eine feste Allowlist C53, optional C52 und C54. Fachliche Upload-Codepfade, CDD, CCT und VEU-Einreichungen sind in diesem Dienst nicht vorhanden. INI/HIA existieren ausschließlich in einem getrennten, operatorgesteuerten Initialisierungszustand. HTD wird, falls von GLS unterstützt, zusammen mit der schriftlichen GLS-Bestätigung für den Rechteabgleich genutzt. HAA dient nur der operativen Anzeige bereitliegender Formate.

Dauerhafte Rohdaten vor fachlicher Verarbeitung

Ein erfolgreicher Abruf wird erst bestätigt, nachdem folgende Artefakte atomar und dauerhaft gespeichert wurden:

• die unveränderten empfangenen Auftragsdaten beziehungsweise Containerbytes;

• Auftragsart/BTF, EBICS-Transaktions-ID und Segmentmetadaten;

• Host, Kunden- und Teilnehmerreferenz in internen, nicht protokollierten IDs;

• Abrufzeitraum, Empfangszeit, Bytezahl und SHA-256-Digest;

• der Zustand, dass die protokollgemäße Empfangsbestätigung noch aussteht;

• Parserstatus und Parser-/Schema-Version getrennt von den Rohbytes.

Rohbytes werden nicht in Anwendungslogs geschrieben. Zugriff und Aufbewahrung folgen den Regeln für Bank- und personenbezogene Daten. Eine Parserkorrektur erzeugt eine neue abgeleitete Version und überschreibt weder das Original noch eine frühere Normalisierung.

Idempotenz und Wiederanlauf

GLS kennzeichnet Daten innerhalb der Kunden-ID als abgeholt. Deshalb gilt: erst dauerhaft speichern, dann den protokollgemäßen Empfang bestätigen. Anfrage und Ergebnis dieser Bestätigung werden anschließend in demselben dauerhaften Protokolljournal ergänzt; ein fehlendes Ergebnis bleibt als explizit wiederaufzunehmender Zustand sichtbar. Bei Prozessabbruch wird dieselbe EBICS-Transaktion entsprechend der Spezifikation fortgesetzt oder kontrolliert neu begonnen; es wird nicht anhand eines HTTP-Status geraten.

Die technische Deduplizierung bindet mindestens Merchant, Verbindung, Auftragsart/BTF, EBICS-Transaktions-ID, Nutzdaten-Digest und Abrufzeitraum. Die fachliche CAMT-Deduplizierung verwendet zusätzlich die stabilen Kontoauszugs-, Kontoumsatz- und Referenzkennungen aus der jeweiligen Nachricht. Gleiche Rohbytes werden idempotent wiedererkannt. Abweichende Bytes unter derselben technischen Identität führen zu einem Konflikt und manueller Prüfung; sie werden nicht überschrieben.

Audit und Betrieb

Audit-Einträge enthalten nur Merchant, interne Verbindungs-ID, Auftragsart, Ergebniscode, Transaktions-/Digest-Kurzreferenz, Segmentanzahl, Bytezahl, Dauer und Zeitstempel. Sie enthalten keine Kontonummern, Kunden-/Teilnehmerkennungen, privaten Schlüssel, Passphrasen, vollständigen Digest, CAMT-Inhalt oder EBICS-XML. Fehlertexte der Bank werden als feste interne Fehlercodes klassifiziert; ungefilterte Bankantworten bleiben im geschützten Rohdatenspeicher.

Der Betrieb braucht Alarme für ausbleibende C53-Lieferungen, wiederholte Protokollfehler, Fingerprintabweichungen, unvollständige Segmentfolgen, Deduplizierungskonflikte und Parserfehler. Ein manueller Wiederanlauf arbeitet auf einer internen Abruf-ID und kann keine Auftragsart oder Bankidentität verändern.

Einführungs- und Abnahmeschritte

1. GLS-Angebot, zweite Kunden-ID, Teilnehmer, Konten, Berechtigungen, Versionen und Kosten schriftlich bestätigen lassen.

2. Die dauerhaft produktionszugeordneten Schlüssel einmalig in der geschützten Connector-Umgebung erzeugen, sicher aufbewahren und mit INI/HIA initialisieren; HPB-Fingerprints im Vier-Augen-Prinzip dokumentieren. Die anschließende begrenzte C53-Validierung verwendet diese Schlüssel und keine später zu ersetzenden Wegwerf-Testschlüssel.

3. Nur C53 freigeben und einen begrenzten Zeitraum abrufen. Rohbytes, Segmentabschluss und Digest prüfen, bevor ein Parser aktiviert wird.

4. CAMT.053.001.08 gegen bekannte GLS-Auszüge abstimmen. Buchungsdatum, Valuta, Betrag/Währung, Sammelbuchungen, Rückgaben und Bankreferenzen fachlich abgleichen.

5. Parallelbetrieb mit Frisbii durchführen. Vollständigkeit und Dubletten pro Kalendertag und Konto vergleichen, ohne die bestehende Frisbii-Konfiguration zu ändern.

6. C52 oder C54 nur nach eigener fachlicher Abnahme aktivieren.

7. Berechtigungen regelmäßig über HTD, soweit unterstützt, und die schriftliche GLS-Vereinbarung kontrollieren; HAA nur für die operative Formatverfügbarkeit verwenden. Jede neue fachliche Upload- oder VEU-Einreichungsberechtigung deaktiviert den Connector bis zur Klärung.

Gebühren und offene Bestätigungen

Die öffentliche GLS-Gebührenübersicht, Version 04 mit Stand August 2025, nennt netto:

• 100,00 EUR einmalig je Kundenzugang für die Ersteinrichtung;

• 10,00 EUR monatlich je Kundenzugang;

• 12,00 EUR je Erweiterungs-/Änderungsauftrag, beispielsweise für neue Teilnehmer.

Die Beträge verstehen sich zuzüglich der im Leistungszeitraum gültigen Umsatzsteuer. Die Übersicht sagt zugleich, dass die Preise unabhängig von der Zahl der eingetragenen Konten oder Teilnehmer berechnet werden. Trotzdem muss GLS vor Bestellung bestätigen, wie eine zweite Kunden-ID, der neue Teilnehmer, besondere C52/C54-Berechtigungen und spätere Änderungen im konkreten Vertrag berechnet werden. Preise und Bedingungen können sich nach August 2025 geändert haben.

Quelle: GLS EBICS-Gebührenübersicht, Stand 08/2025.

Nicht Bestandteil dieses Vorschlags

• keine Auswahl oder Installation einer EBICS-Bibliothek;

• kein Abruf mit echten GLS-Identitäten oder Schlüsseln;

• kein CDD-, CCT-, SEPA-, VEU- oder sonstiger fachlicher Upload; INI/HIA bleiben auf die einmalige, operatorgesteuerte Schlüsselinitialisierung begrenzt;

• keine automatische Bankabstimmung oder Verbuchung;

• kein Ersatz oder Umbau der Frisbii-Verbindung;

• keine Behauptung, dass beobachtete Frisbii-Schalter den tatsächlichen Bankvertrag vollständig wiedergeben.

Die vorhandene lokale Kontenabgleichsseite ist kein CAMT-Import: Sie erfasst manuell übergebene Betrags-, Währungs- und Buchungsdaten gegen einen Vertrag. Abruf, CAMT-Parsing, Importprüfung und Zuordnung bilden daher ein späteres, getrennt zu planendes Teilsystem.

Für eine spätere technische Bewertung existieren unter anderem die offenen Projekte railslove/epics, ebics-api/ebics-client-php und ebics-java/ebics-java-client. Ihre jeweiligen Lizenz- und Versionsangaben sind Herstellerangaben. Das aktuelle epics-README nennt EBICS 2.4, 2.5 und 3.0, standardmäßig 2.5, sowie INI/HIA/HPB und C52/C53/C54. Vor einer Auswahl müssen daher insbesondere die veröffentlichte Gem-Version, die explizite 3.0-Konfiguration und das Verhalten am GLS-H005-Endpunkt geprüft werden. Keines der Projekte wurde für GLS geprüft, ausgewählt, installiert oder mit dem kostenpflichtigen API-Angebot eines Anbieters gleichgesetzt.