Abend 1: Vom leeren Repository zum Zahlungskern
Am ersten Abend entstand das Fundament eines Instant-Payment-Systems: Nachrichtenmodell, Fachregeln, Zahlungskern, Gateway, Simulator, Bankenstamm, Sicherheit, Rückforderung und ein erstes Backoffice. 45 Commits. Möglich wurde das, weil die Architektur vor dem ersten Code feststand.
Die Ausgangslage
Seit August 2024 laufen Instant Payments in der Schweiz. Bis Ende 2026 müssen alle Banken im Kundenzahlungsverkehr sie empfangen können. Für viele kleinere Institute ist das eine Pflicht, die Geld und Zeit kostet.
Instant ist dabei kein schnellerer Batch, sondern ein anderer Betrieb. Eine Zahlung muss in wenigen Sekunden geprüft, reserviert, gesendet und gutgeschrieben sein. Sie ist danach endgültig. Fehler lassen sich nur noch über Rückforderungen mit Fristen lösen. Und das alles rund um die Uhr.
Wir kennen diese Welt aus 15 Jahren Zahlungsverkehr. Die Frage für diesen Abend war: Wie weit kommen wir, wenn wir nicht selbst programmieren, sondern KI-Agenten führen?
Erst denken, dann bauen
Bevor ein Agent eine Zeile schrieb, standen drei Entscheide fest:
- Hexagonale Architektur: Der Zahlungskern kennt weder Datenbank noch Netzwerk. Alles Äussere hängt an Schnittstellen.
- Das Nachrichtenmodell wird generiert, nicht geschrieben: aus den offiziellen Schweizer XML-Schemas. Kein Agent soll ISO 20022 nachtippen.
- Regeln als Code mit Quelle: Jede Fachregel verweist auf die Stelle in den Implementation Guidelines, aus der sie stammt.
Diese drei Sätze sind unscheinbar. Sie haben aber verhindert, dass die Agenten in den folgenden Stunden ein Durcheinander bauen.
Was an diesem Abend entstand
Die Commits lesen sich wie der Projektplan eines halben Jahres:
| Etappe | Inhalt |
|---|---|
| Nachrichtenmodell | Typisierte Klassen aus den CH-Schemas, Schweizer Kennungen wie IBAN und QR-Referenz, Fachregeln über das Schema hinaus |
| Zahlungskern | Zustandsautomat für jede Zahlung, Idempotenz, Prüfung der Grundcodes gegen die SIX-Regeln |
| Gateway und Simulator | Anbindung an die zentrale Plattform und ein Simulator, der sie samt Ende-zu-Ende-Szenarien ersetzt |
| Bankenstamm | Import des SIX-Bankenstamms, Empfängerbank aus der IBAN |
| Sicherheit | Berechtigungskonzept, Rollen, Vier-Augen-Freigaben, Login über Keycloak |
| Rückforderung | camt.056, camt.029 und pacs.004 mit Fristen und Freigabe |
| Backoffice | Erste Weboberfläche mit Login |
Jede Etappe lief über einen eigenen Feature-Branch mit Pull Request. Am Ende des Abends gab es sieben gemergte Pull Requests und eine Roadmap für die nächsten Schritte.
Was unsere Rolle war
Wir haben kaum Code gelesen, aber viel entschieden. Welche Nachricht kommt wann? Was passiert, wenn die Plattform nach acht Sekunden nicht antwortet? Wer darf eine Rückforderung freigeben, und darf es dieselbe Person sein, die sie erfasst hat?
Solche Fragen beantwortet kein Agent von selbst richtig. Er beantwortet sie plausibel. Der Unterschied zwischen plausibel und richtig ist im Zahlungsverkehr genau das, was später teuer wird.
Die Erkenntnis des Abends
Die Geschwindigkeit hat uns überrascht, aber nicht das Wichtigste. Wichtiger war: Die Qualität hing fast vollständig an den ersten zehn Minuten. Architektur, Quellen und Regeln vorgeben, dann laufen lassen. Wo wir das versäumt hätten, hätten wir am nächsten Abend aufgeräumt statt gebaut.