Exkurs: Die Hochzeit von ISO und EBICS
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:
- E unterschreibt allein.
- A unterschreibt kollektiv, mit wem auch immer.
- B unterschreibt kollektiv, aber nur zusammen mit A oder E.
- T darf erfassen und übermitteln, aber nicht unterschreiben.
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.


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
- ModulEigenes Berechtigungsmodul und delegierte Kanäle (ADR 0015)
- KlassenMandate nach ISO 20022, Klassen E, A, B, T nach EBICS, Freigabenachweis (ADR 0016)
- GruppenUnterschriftsgruppen und Alternativen (ADR 0017)
- EreignisseAuftragsereignisse mit jeder Änderung (ADR 0018)
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.