ptimaAlle Teile des Tagebuchs
my AI Tagebuch · Im Grossen

Exkurs: Die Hochzeit von ISO und EBICS

Freitag, 30. Oktober 2026 · Michael Andrejews

Zwei Standards regeln, wer in einer Firma Geld bewegen darf. Sie leben meist nebeneinander, in getrennten Systemen. An einem Freitagabend haben wir sie zu einem Modell verbunden, in drei Stunden und drei Architekturentscheiden. Wir zeigen hier offen, wie.

Zwei Standards, die sich nicht kennen

ISO 20022 ist die Sprache des Zahlungsverkehrs. Aufträge kommen als pain.001, der Status geht als pain.002 zurück, Saldo, Kontoauszug und Buchungsanzeige heissen camt.052, camt.053 und camt.054. Weniger bekannt: ISO 20022 beschreibt auch Zeichnungsrechte. Das Kontomandat (acmt, OperationMandate) legt fest, wie viele Unterschriften es braucht, wer unterschreiben darf, bis zu welchem Betrag und ab wann. Ein Halter kann dabei eine Person sein oder eine Gruppe.

Was ISO 20022 nicht kennt: eine Meldung für «Zeig mir, was auf meine Unterschrift wartet» und eine für «Ich unterschreibe».

EBICS ist der Kanal, über den Firmen in der Schweiz und in Deutschland seit Jahren Zahlungen an ihre Bank liefern. EBICS kennt genau das, was ISO fehlt: die verteilte elektronische Unterschrift. Mit Unterschriftsklassen, einer Liste offener Aufträge, der Ansicht eines einzelnen Auftrags und dem Unterschreiben selbst. Dafür ist EBICS ein Übertragungsprotokoll und kein Datenmodell, das man in eine moderne Schnittstelle übernimmt.

In der Praxis führen viele Häuser die Zeichnungsrechte deshalb mehrfach: einmal für den EBICS-Kanal, einmal im E-Banking, einmal im Kernbankensystem. Drei Wahrheiten, die auseinanderlaufen.

Die Hochzeit

Unser Entscheid war einfach: Jeder Standard bringt das ein, was er am besten kann.

Baustein Woher Im System
Mandat pro Konto ISO 20022 acmt requiredSignatureNumber (ReqrdSgntrNb), validFrom/validUntil (StartDt/EndDt)
Halter: Person oder Gruppe ISO 20022 acmt userId (PtyOrGrp/Pty) oder groupId (PtyOrGrp/GrpId)
Limite pro Zahlung ISO 20022 acmt maxAmountByTransaction (Authstn/MaxAmtByTx)
Unterschriftsklasse EBICS signatureClass: E, A, B oder T
Offene Unterschriften EBICS (HVU, HVD) GET /api/v1/customer/signatures
Unterschreiben EBICS (HVE) POST /api/v1/orders/{id}/signatures
Aufträge, Status, Konto ISO 20022 pain, camt pain.001, pain.002, camt.052, camt.053, camt.054

Das Ergebnis: ein einziges Berechtigungsmodell. Das Kernbankensystem liefert es über eine Schnittstelle, alle Kanäle nutzen es, und das Modell spricht beide Standards.

Vier Buchstaben

Die Klassen aus EBICS sind kurz und in Firmen gut bekannt:

Ein typischer Fall: Die Assistenz erfasst die Zahlungen (T), der Finanzchef (A) und die Buchhalterin (B, bis CHF 5'000) unterschreiben gemeinsam. So sieht das im Berechtigungsmodell aus:

PUT /api/entitlements/customers/C-200100
{
  "source": "core-banking",
  "users": [{ "id": "EB-200100-01" }, { "id": "EB-200100-02" }, { "id": "EB-200100-03" }],
  "mandates": [{
    "id": "M-1", "iban": "CH4909806000000100002", "requiredSignatureNumber": 2,
    "holders": [
      { "userId": "EB-200100-01", "signatureClass": "A" },
      { "userId": "EB-200100-02", "signatureClass": "B", "maxAmountByTransaction": 5000.00 },
      { "userId": "EB-200100-03", "signatureClass": "T" }
    ]
  }]
}

Die Regel dahinter: Ein Mandat ist erfüllt durch eine Unterschrift der Klasse E, oder durch die geforderte Zahl verschiedener Personen, darunter mindestens eine mit A. Bei jeder neuen Unterschrift werden alle bisherigen mit den aktuellen Rechten neu geprüft. Wer inzwischen gesperrt ist oder dessen Mandat abgelaufen ist, zählt nicht mehr.

Gruppen: was kaum ein System kann

Im Handelsregister steht oft etwas wie «kollektiv zu zweien, ein Mitglied der Geschäftsleitung mit einem Mitglied der Finanzabteilung». Die meisten Zahlungssysteme kennen nur Einzel- und Kollektivunterschrift. Gruppen werden von Hand nachgebildet oder gar nicht.

ISO 20022 sieht Gruppen vor. Also haben wir sie gebaut, 45 Minuten nach den Klassen. Ein Mandat kann Alternativen haben, etwa «eine Person aus der Geschäftsleitung und eine aus den Finanzen, oder zwei aus der Geschäftsleitung»:

"signatureRules": [ { "GL": 1, "FIN": 1 }, { "GL": 2 } ]

Das System verteilt die Unterschriften so auf die Plätze, dass jede Person nur einmal zählt, auch wenn sie in zwei Gruppen ist. Für uns ist das ein Kandidat für ein Alleinstellungsmerkmal.

Der Nachweis

Jede Zahlung trägt einen strukturierten Freigabenachweis: wer erfasst hat, wer in welcher Reihenfolge unterschrieben hat, mit welcher Klasse, für welche Gruppe und mit welcher Limite. Dieser Nachweis steht in den Zahlungsereignissen. Kernbankensystem, Geldwäscherei-Prüfung, Data Warehouse und Kanal lesen dieselben Daten, statt einen Freitext im Protokoll zu deuten.

Die Schnittstellen

Aus dem Entscheid folgt ein einfacher Grundsatz für den Kanal: Wo es eine ISO-Meldung gibt, wird sie verwendet. Wo es keine gibt, folgt die Schnittstelle dem Vorbild von EBICS. Ein Kanal integriert damit eine einzige Familie von Meldungen, und derselbe camt.053 dient später auch dem Abgleich bei Firmenkunden.

Die Kanal-Schnittstelle aus der OpenAPI-Beschreibung: Aufträge und Kontoinformationen in ISO 20022, offene Unterschriften und Unterschreiben nach dem Vorbild von EBICS.
Die Kanal-Schnittstelle aus der OpenAPI-Beschreibung: Aufträge und Kontoinformationen in ISO 20022, offene Unterschriften und Unterschreiben nach dem Vorbild von EBICS.
Die Berechtigungs-Schnittstelle für das Kernbankensystem: einzelne Kunden als Änderung oder alle auf einmal. Eine Gesamtlieferung, die mehr als zehn Prozent der Kunden entfernen würde, wird abgewiesen, ausser sie wird ausdrücklich bestätigt.
Die Berechtigungs-Schnittstelle für das Kernbankensystem: einzelne Kunden als Änderung oder alle auf einmal. Eine Gesamtlieferung, die mehr als zehn Prozent der Kunden entfernen würde, wird abgewiesen, ausser sie wird ausdrücklich bestätigt.

Was noch fehlt

Nicht alles aus dem ISO-Mandat ist umgesetzt: die verbindliche Reihenfolge der Unterschriften, Limiten pro Zeitraum und pro Sammelauftrag. Lieferungen mit diesen Angaben werden abgewiesen statt stillschweigend ignoriert. Eine Berechtigung, die nur halb gilt, ist gefährlicher als eine, die fehlt.

Unabhängig von der Technik

Nichts davon hängt an einer Technologie. Das Berechtigungsmodell und die Meldungen sind fachlich definiert. Ob ein Haus seine Ereignisse über Kafka, IBM MQ, Dateien oder REST verteilt, ob die Daten in PostgreSQL oder Oracle liegen: Das System hat für jede dieser Varianten eine austauschbare Anbindung, und der Wechsel ist Konfiguration, kein neues Release. S3 für Dateilieferungen und Archive ist als Nächstes geplant.

Früher war jede zusätzliche Anbindung ein Projekt. Heute ist sie ein Abend. Wenn Umsetzung fast nichts mehr kostet, wird das fachliche Modell zum Einzigen, was wirklich zählt. Ein gutes Modell lässt sich auf jede Technik bringen. Ein falsches wird auf jeder Technik teuer.

Wie es entstand

  1. ModulEigenes Berechtigungsmodul und delegierte Kanäle (ADR 0015)
  2. KlassenMandate nach ISO 20022, Klassen E, A, B, T nach EBICS, Freigabenachweis (ADR 0016)
  3. GruppenUnterschriftsgruppen und Alternativen (ADR 0017)
  4. EreignisseAuftragsereignisse mit jeder Änderung (ADR 0018)
Freitag, 30. Oktober 2026: vom Berechtigungsmodul zu den Unterschriftsgruppen in knapp drei Stunden.

Keiner dieser Schritte stand in einem Prompt. Ein Agent kennt ISO 20022 und EBICS, wenn man ihn fragt. Dass man die beiden verheiratet, wo die Naht verläuft und welche Felder man lieber abweist als ignoriert, entscheidet jemand, der Zeichnungsrechte von Firmenkunden schon umgesetzt hat. Die Agenten haben daraus Code, Tests, Datenbankmigrationen für zwei Datenbanken, Schnittstellen und Doku gemacht.

Warum wir das so offen zeigen

Der Wert liegt nicht im Code. Den schreiben Agenten heute in Stunden. Der Wert liegt darin, die richtigen Fragen zu stellen und die Standards richtig zu verbinden. Genau das geben wir an Teams weiter, damit sie es selbst können. Und wenn es schneller geht, bauen wir mit.