Core-Banking-Testautomatisierung heisst: Die kritischen Abläufe Ihres Kernbankensystems werden bei jedem Release automatisch und reproduzierbar geprüft. Dazu gehören Buchungen, Zinsläufe, Zahlungen, Schnittstellen und Umsysteme. Das Ziel ist keine möglichst hohe Zahl automatisierter Tests. Sie wollen die Prozesse absichern, deren Ausfall Kunden, Bilanz oder Aufsicht direkt trifft, und dafür schneller und mit weniger Restrisiko releasen. In diesem Leitfaden gehen wir mit Ihnen durch, was Sie zuerst automatisieren, wie Sie API-Gateways, Testdaten und Testumgebungen in den Griff bekommen und welche Schweizer Anforderungen Sie dabei einhalten müssen.
Zuletzt aktualisiert: 28. Oktober 2026
Kurz gesagt
- Automatisieren Sie zuerst stabile, häufig genutzte und geschäftskritische Abläufe: Regressionstests für Buchungslogik, Zahlungen, Zinsen und Gebühren sowie API-Verträge.
- Schwer automatisierbare Systemintegrationstests über viele Applikationen hinweg sind oft unwirtschaftlich. Hier helfen Service-Virtualisierung und gezielte manuelle Tests.
- Testdaten sind der Engpass: Synthetische oder sauber anonymisierte Daten sind unter dem nDSG die sichere Wahl, Produktionskopien die riskante.
- Das API-Gateway verdient eine eigene Teststrategie: Verträge, Authentifizierung, Ratenbegrenzung und Fehlerbehandlung.
- Setzen Sie KI im Testen ein, müssen Nachvollziehbarkeit und Dokumentation für FINMA und, wo anwendbar, den EU AI Act von Anfang an mitgedacht sein.
Inhaltsverzeichnis
- Inhalt
- Was Testautomatisierung im Core Banking leisten soll
- Warum Kernbankensysteme besonders schwer zu testen sind
- Was Sie zuerst automatisieren sollten
- API-Gateway und Schnittstellen testen
- Testdaten, Testumgebungen und Umsysteme
- Vorgehen in sechs Schritten
- Testautomatisierung in Migration und Modernisierung
- Regulatorische Anforderungen in der Schweiz
- Typische Fehler und wie Sie sie vermeiden
- Unsere Sicht
- Häufige Fragen
- So unterstützt S-PRO Banken bei der Testautomatisierung
- Quellen
Inhalt
- Was Testautomatisierung im Core Banking leisten soll
- Warum Kernbankensysteme besonders schwer zu testen sind
- Was Sie zuerst automatisieren sollten
- API-Gateway und Schnittstellen testen
- Testdaten, Testumgebungen und Umsysteme
- Vorgehen in sechs Schritten
- Testautomatisierung in Migration und Modernisierung
- Regulatorische Anforderungen in der Schweiz
- Typische Fehler und wie Sie sie vermeiden
- Unsere Sicht
- Häufige Fragen
- So unterstützt S-PRO Banken
Was Testautomatisierung im Core Banking leisten soll
Im Kern geht es um vordefinierte Testfälle und Prüfungen, die bei jeder Ausführung identisch ablaufen. Die St.Galler Kantonalbank beschreibt ihre Testautomatisierung genau so: Sie umfasst Regressionstests für das Kernbankensystem Avaloq und End-to-End-Tests für Umsysteme, die Arbeitsabläufe aus Nutzersicht prüfen. Die Ziele sind gleichbleibende Ergebnisse, weniger menschliche Fehler, kürzere Prüfzeiten und eine breite Testabdeckung. Komplexe oder unklare Szenarien bleiben bewusst beim manuellen Test.
Diese Arbeitsteilung ist der realistische Massstab. Automatisierung übernimmt die wiederkehrende Pflicht, damit Ihre Fachtester Zeit für die Kür haben: explorative Tests, neue Produkte, Grenzfälle in der Regulierung.
Für Entscheidungsträger lassen sich die Ziele in drei Fragen übersetzen:
- Release-Sicherheit: Merken wir vor dem Go-live, wenn ein Update des Kernsystems oder eines Umsystems eine Buchungsregel bricht?
- Geschwindigkeit: Können wir Hersteller-Releases, regulatorische Änderungen und eigene Features einspielen, ohne dass ein wochenlanger manueller Regressionszyklus zum Flaschenhals wird?
- Nachweisbarkeit: Können wir Revision und Aufsicht zeigen, was getestet wurde, mit welchen Daten und mit welchem Ergebnis?
Warum Kernbankensysteme besonders schwer zu testen sind
Ein Kernbankensystem ist kein gewöhnliches Fachsystem. Mehrere Eigenschaften machen das Testen anspruchsvoll:
- Buchhalterische Exaktheit: Jede Transaktion muss auf den Rappen stimmen, über Haupt- und Nebenbuch hinweg. Ein Test, der nur prüft, ob eine Maske erscheint, sagt nichts über die Korrektheit der Buchung.
- Zeitabhängige Logik: Zinsabgrenzungen, Monats- und Jahresabschlüsse, Valuta und Fälligkeiten lassen sich nur testen, wenn Sie das Systemdatum kontrolliert verschieben können.
- Batch-Verarbeitung: Viele kritische Abläufe laufen nachts im Batch. Fehler zeigen sich oft erst im Folgeschritt.
- Parametrisierung statt Code: Produkte, Gebühren und Konditionen sind häufig konfiguriert und nicht programmiert. Eine geänderte Parametertabelle kann genauso viel brechen wie ein Code-Release.
- Dichte Umsystem-Landschaft: Zahlungsverkehr, Wertschriften, E-Banking, CRM, Meldewesen und Data Warehouse hängen am Kern. Jede Änderung wirkt über Schnittstellen weiter.
- Hersteller-Releases: Bei Standardsoftware bestimmt der Anbieter einen Teil des Release-Takts. Ihre Regressionssuite muss jedes Update absichern, auch wenn Sie selbst nichts geändert haben.
Daraus folgt: Eine reine UI-Automatisierung reicht im Core Banking nicht. Sie brauchen Tests auf mehreren Ebenen, von der Buchungslogik über die APIs bis zum Geschäftsprozess.
Was Sie zuerst automatisieren sollten
Bewährt hat sich eine Priorisierung nach drei Kriterien: Geschäftskritikalität, Nutzungshäufigkeit und technische Umsetzbarkeit. Ein Testfall, der täglich genutzte Zahlungseingänge prüft und stabil über eine API ansteuerbar ist, kommt vor einem seltenen Sonderprozess mit Medienbruch. Gute Kandidaten sind wiederkehrende Geschäftsprozesse wie Zahlungseingänge, Börsenaufträge, Kontoeröffnungen oder Zinsläufe.
| Testart | Was geprüft wird | Eignung für Automatisierung | Priorität |
|---|---|---|---|
| Regressionstests der Buchungslogik | Buchungen, Salden, Zinsen, Gebühren, Abschlüsse | Sehr hoch, stabil und wiederkehrend | Zuerst |
| API- und Vertragstests | Schnittstellen zwischen Kern, Gateway und Umsystemen | Sehr hoch, schnell und präzise | Zuerst |
| Batch- und Abschlusstests | Nachtverarbeitung, Monats- und Jahresende | Hoch, mit kontrollierter Systemzeit | Früh |
| End-to-End-Tests der Kernprozesse | Zahlung, Wertschriftenauftrag, Kontoeröffnung aus Nutzersicht | Mittel, wartungsintensiv | Gezielt für wenige Kernpfade |
| Systemintegrationstests über viele Applikationen | Prozesse mit Medien- oder Technologiebrüchen | Oft unwirtschaftlich | Selektiv, mit Service-Virtualisierung |
| Last- und Performancetests | Durchsatz zu Spitzenzeiten, Batch-Fenster | Hoch, aber umgebungsabhängig | Vor grossen Releases |
| Sicherheitstests | Authentifizierung, Autorisierung, Schwachstellen | Teilweise, ergänzt durch Penetrationstests | Laufend |
| Explorative Fachtests | Neue Produkte, unklare Anforderungen | Gering | Manuell |
Zwei Grundsätze helfen bei der Auswahl. Erstens: Testen Sie so tief im Stack wie möglich. Eine API-Prüfung der Buchungslogik ist schneller und robuster als derselbe Fall über die Oberfläche. Zweitens: Bauen Sie wiederverwendbare Testbausteine, etwa „Kunde anlegen“, „Konto eröffnen“, „Zahlung erfassen“. Aus wenigen gut gepflegten Bausteinen entstehen viele Testfälle, und eine Änderung am Prozess muss nur an einer Stelle nachgezogen werden.
API-Gateway und Schnittstellen testen
Mit Open Banking, Mobile-Apps und Partnerintegrationen wird das API-Gateway zur Eingangstür Ihrer Bank. Es verdient eine eigene Teststrategie, die vier Bereiche abdeckt.
Verträge und Funktionalität
Contract Tests prüfen, ob Anbieter und Konsument einer Schnittstelle dasselbe Verständnis von Feldern, Formaten und Statuscodes haben. Sie laufen bei jedem Build und fangen Brüche ab, bevor ein Umsystem sie in der Integrationsumgebung bemerkt. Ergänzend prüfen funktionale API-Tests die fachliche Antwort: Stimmt der Saldo nach einer Buchung, wird ein Auftrag mit fehlender Deckung korrekt abgelehnt?
Sicherheit
Die Schweizerische Bankiervereinigung gliedert ihre API-Sicherheitsempfehlungen für Open Finance in sichere Kommunikation sowie Backend-, kundenbezogene und drittanbieterbezogene Sicherheit. Diese Gliederung eignet sich gut als Raster für Ihre Testfälle:
- Kommunikation: Transportverschlüsselung, Zertifikatsprüfung, Ablehnung unsicherer Verbindungen.
- Backend: Autorisierung pro Ressource, damit ein gültiges Token nicht Zugriff auf fremde Konten öffnet.
- Kunde: Einwilligungen, starke Authentifizierung, Ablauf und Widerruf von Berechtigungen.
- Drittanbieter: Registrierung, Scopes und Sperrung eines Drittanbieters.
Automatisierte Negativtests sind hier wertvoller als Positivtests: abgelaufene Tokens, manipulierte Parameter, fehlende Scopes, zu viele Anfragen.
Fehlerbehandlung und Resilienz
Testen Sie bewusst, was passiert, wenn das Kernsystem langsam antwortet oder ausfällt. Liefert das Gateway saubere Fehlercodes? Greifen Timeouts, Wiederholungslogik und Circuit Breaker? Werden doppelte Anfragen idempotent behandelt, damit eine Zahlung nicht zweimal gebucht wird? Solche Szenarien lassen sich mit simulierten Backends gut automatisieren.
Last und Ratenbegrenzung
Prüfen Sie, ob Ratenbegrenzungen pro Kunde und pro Drittanbieter wirken und das Kernsystem auch bei Lastspitzen, etwa am Monatsende, geschützt bleibt.
Testdaten, Testumgebungen und Umsysteme
In den meisten Banken scheitert Testautomatisierung nicht an den Werkzeugen, sondern an Daten und Umgebungen.
Testdaten
Produktionskopien sind verlockend, weil sie realistisch sind. Sie enthalten aber Personendaten und unterliegen damit dem Datenschutzgesetz. Wie streng der EDÖB bei sensiblen Kundendaten ist, zeigt der Fall PostFinance: Der Beauftragte verpflichtete PostFinance, für Stimmabdrücke eine ausdrückliche Einwilligung einzuholen und Stimmabdrücke ohne diese Einwilligung zu löschen (Verfügung vom 16. Mai 2025, Mitteilung vom 7. August 2025). PostFinance hat Beschwerde erhoben, die Verfügung ist noch nicht rechtskräftig. Für Testumgebungen mit breiterem Zugriff ist das ein deutliches Signal. Klären Sie den Einsatz echter Kundendaten in Tests mit Ihrer Datenschutzberatung und der Compliance, bevor Sie Daten kopieren.
In der Praxis bewähren sich drei Ansätze:
- Synthetische Daten: Generierte Kunden, Konten und Transaktionen mit realistischen Verteilungen. Ideal für automatisierte Regressionstests, weil sie reproduzierbar sind.
- Maskierte Daten: Produktionsdaten, deren identifizierende Merkmale irreversibel ersetzt werden, unter Erhalt der referenziellen Integrität über alle Systeme.
- Testdaten als Code: Jeder Testfall erzeugt seine Ausgangslage selbst über APIs und räumt danach auf. Das macht Tests unabhängig voneinander.
Testumgebungen
Kernbankenumgebungen sind teuer und knapp. Typische Massnahmen sind eine klare Umgebungsplanung pro Release, automatisiertes Aufsetzen und Zurücksetzen von Datenständen sowie eine kontrollierbare Systemzeit für Abschluss- und Zinstests.
Umsysteme
Nicht jedes Umsystem muss in jeder Testumgebung verfügbar sein. Service-Virtualisierung bildet Schnittstellen wie Zahlungsverkehr, Kursdaten oder Meldewesen nach, damit Ihre Tests stabil laufen, auch wenn das echte System gerade gewartet wird. Echte End-to-End-Tests konzentrieren Sie auf wenige, kritische Pfade vor dem Release.
Vorgehen in sechs Schritten
- Bestandsaufnahme: Erfassen Sie Prozesse, Schnittstellen, vorhandene Testfälle und den aktuellen Aufwand pro Regressionszyklus.
- Risikobasierte Priorisierung: Bewerten Sie jeden Prozess nach Kritikalität, Häufigkeit und Umsetzbarkeit. Wählen Sie einen klar begrenzten Startumfang.
- Architektur der Testsuite: Legen Sie die Ebenen fest (Logik, API, Prozess), definieren Sie wiederverwendbare Bausteine und eine Testdatenstrategie.
- Pilot: Automatisieren Sie einen Kernprozess vollständig, inklusive Daten, Umgebung und Reporting. Messen Sie Laufzeit, Stabilität und gefundene Fehler.
- Integration in die Pipeline: Binden Sie die Tests in Ihre Build- und Release-Pipeline ein, sodass jede Änderung automatisch geprüft wird und Ergebnisse revisionssicher abgelegt werden.
- Skalierung und Pflege: Erweitern Sie schrittweise, entfernen Sie instabile oder überflüssige Tests und planen Sie Wartungskapazität fest ein.
Wie sich dieser Ablauf in einen KI-gestützten Entwicklungsprozess einfügt, beschreiben wir im Beitrag zum KI-nativen SDLC für Banken.
Testautomatisierung in Migration und Modernisierung
Bei einer Core-Banking-Migration ist Testautomatisierung keine Kür, sondern Ihr Sicherheitsnetz. Die wichtigsten Einsatzfelder:
- Datenabgleich: Automatisierte Abstimmungen von Salden, Positionen und Stammdaten zwischen Alt- und Neusystem, Konto für Konto.
- Parallelbetrieb: Dieselben Geschäftsfälle laufen in beiden Systemen, die Ergebnisse werden automatisch verglichen.
- Probeläufe des Cutovers: Jede Generalprobe wird mit derselben Testsuite geprüft, damit Abweichungen zwischen den Läufen sofort auffallen.
- Schnittstellen: Alle Umsysteme werden gegen die neuen APIs getestet, bevor sie umgestellt werden.
In einer modernisierten Architektur mit klaren APIs wird Testen ausserdem deutlich einfacher als in einem gewachsenen Monolithen. Wie Sie die Migration vom Datenprofil bis zum Cutover planen, zeigt unser Leitfaden zur Core-Banking-Migration. Die Schnittstellenseite vertiefen wir im Beitrag zur Kernbankensystem-Integration.
Regulatorische Anforderungen in der Schweiz
Tests sind Teil Ihres Risikomanagements und werden von Revision und Aufsicht entsprechend betrachtet.
- Operationelle Resilienz: Die FINMA stellte bei den beaufsichtigten Instituten einen heterogenen Reifegrad der operationellen Resilienz fest und erwartet belastbare Krisenszenarien für IKT und Cyberabwehr. Automatisierte Regressions-, Last- und Fehlertests liefern dafür belastbare Nachweise.
- Datenschutz: Unter dem nDSG gehören Personendaten in Testumgebungen auf den Prüfstand, siehe oben.
- EU-Geschäft: Institute mit Tätigkeit in der EU berücksichtigen zusätzlich DORA mit ihren Anforderungen an das Testen der digitalen operationalen Resilienz.
- KI im Testen: Generieren Sie Testfälle, Testdaten oder Auswertungen mit KI, gilt für diese KI-Systeme selbst der EU AI Act, soweit er auf Ihr Institut anwendbar ist. Unabhängig davon betont die Bankiervereinigung, dass bei KI-Anwendungen im Banking die Nachvollziehbarkeit der verwendeten Daten für Compliance und Audit entscheidend ist. Versionieren Sie Prompts, Modelle und generierte Artefakte und lassen Sie generierte Testfälle von Fachleuten freigeben. Mehr dazu in unserem Leitfaden zum Model Risk Management für KI.
Typische Fehler und wie Sie sie vermeiden
Das IT-Finanzmagazin warnt davor, Testautomatisierung blind einzuführen: Systemintegrationstests sind in heterogenen Bankenlandschaften wegen Medien- und Technologiebrüchen oft unwirtschaftlich zu automatisieren. Die Empfehlung lautet, die Automatisierung in die Gesamtstrategie einzubetten, früh und laufend zu testen und klein zu beginnen. Aus unserer Projekterfahrung kommen weitere Muster hinzu:
- Quote statt Risiko als Ziel: Eine hohe Automatisierungsquote sagt wenig, wenn die kritischen Prozesse fehlen.
- Nur über die Oberfläche testen: UI-Tests sind langsam und brechen bei jeder Layoutänderung. Verlagern Sie Prüfungen auf API- und Logikebene.
- Keine Testdatenstrategie: Tests, die von zufälligen Datenständen abhängen, werden instabil und verlieren das Vertrauen des Teams.
- Wartung nicht eingeplant: Jedes Hersteller-Release verändert Abläufe. Ohne feste Pflegekapazität veraltet die Suite.
- Ergebnisse ohne Nachweis: Ohne revisionssichere Ablage der Testläufe fehlt Ihnen gegenüber Revision und Aufsicht der Beleg.
Unsere Sicht
Wir sehen in Schweizer Banken oft dasselbe Bild: Der Wille zur Automatisierung ist da, aber die Tests sind an die Oberfläche gebunden, die Daten an Produktionskopien und die Umgebungen an knappe Zeitfenster. Unsere Erfahrung aus Fintech-Softwareentwicklung, Digital Banking und Core- und Legacy-Modernisierung zeigt: Der grösste Hebel liegt in der Architektur. Wenn das Kernsystem über saubere APIs erreichbar ist, werden Tests schneller, stabiler und günstiger in der Pflege.
KI verändert das Testen spürbar, etwa beim Ableiten von Testfällen aus Anforderungen oder beim Auswerten von Fehlschlägen. In einer regulierten Bank zählt dabei aber dasselbe wie bei jedem KI-Agenten in Produktion: Human-in-the-Loop, ein vollständiger Audit-Trail und eine Dokumentation, die Revision, FINMA und, wo anwendbar, dem EU AI Act standhält. Wir empfehlen deshalb, klein mit einem klar abgegrenzten Kernprozess zu beginnen, diesen sauber durchzuautomatisieren und erst dann zu skalieren.
Häufige Fragen
Wie hoch sollte die Automatisierungsquote im Core Banking sein?
Eine allgemeingültige Zielquote gibt es nicht. Entscheidend ist, dass die geschäftskritischen und häufig genutzten Prozesse abgedeckt sind. Viele Banken automatisieren bewusst nur einen Teil ihrer Testfälle und behalten explorative und komplexe Szenarien im manuellen Test.
Dürfen wir Produktionsdaten für automatisierte Tests verwenden?
Produktionsdaten enthalten Personendaten und unterliegen dem nDSG. Synthetische oder irreversibel maskierte Daten sind die sicherere Wahl. Klären Sie jede Ausnahme vorab mit Ihrer Datenschutzberatung und der Compliance.
Wie testen wir ein API-Gateway einer Bank sinnvoll?
Kombinieren Sie Contract Tests für die Schnittstellenverträge, funktionale API-Tests, Sicherheits- und Negativtests für Authentifizierung und Autorisierung sowie Resilienztests für Timeouts und Ausfälle. Ratenbegrenzung und Lastverhalten prüfen Sie vor grösseren Releases.
Lohnt sich Testautomatisierung auch vor einer geplanten Core-Migration?
Ja, denn eine Regressionssuite für die heutigen Prozesse ist die Grundlage für den Datenabgleich und den Parallelbetrieb während der Migration. Bauen Sie die Tests möglichst fachlich und über APIs auf, damit sie sich auf das neue System übertragen lassen.
Kann KI Testfälle für das Kernbankensystem erstellen?
KI kann Testfälle aus Anforderungen ableiten, Testdaten generieren und Fehlschläge auswerten. Generierte Artefakte sollten versioniert und von Fachleuten freigegeben werden. Für die KI-Systeme selbst gelten die Anforderungen an Nachvollziehbarkeit und, wo anwendbar, der EU AI Act.
So unterstützt S-PRO Banken bei der Testautomatisierung
S-PRO ist ein Softwareentwicklungsunternehmen mit Hauptsitz in Zürich (Löwenstrasse 45, 8001 Zürich) und R&D-Zentren in Zürich und Łódź. Seit der Gründung 2014 arbeiten wir für Banken, Privatbanken, Vermögensverwalter, Asset Manager und Fintechs, heute mit 250+ Engineers und 300+ Mitarbeitenden, zertifiziert nach ISO 27001 und ISO 27701.
Im Rahmen unserer Core-Banking- und Legacy-Modernisierung schaffen wir die API-Grundlage, auf der automatisierte Tests stabil laufen, und begleiten Migrationen mit Datenabgleich und Parallelbetrieb. Mit KI-Agenten für Banken und Finanzdienstleister sowie der Claude-Implementierung für Finanzinstitute bringen wir KI ins Testen und in die Entwicklung, vom KI-Pilot bis zur Produktion, mit Audit-Trail, Human-in-the-Loop und Dokumentation für EU AI Act, FINMA, DORA und nDSG. S-PRO ist ein Certified partner im Claude Partner Network, und unser Team umfasst Claude-zertifizierte Engineers und Architects. Zu unseren Referenzen im Banking gehören AMINA Bank (digitale Banking-Erfahrung) und New Horizon Bank (B2B-Digital-Banking-Plattform). Sprechen Sie mit uns über Ihren ersten Kernprozess.
Quellen
- St.Galler Kantonalbank: Roboter unterstützen bei Softwaretests
- Swiss Banking: Open Finance in Switzerland
- EDÖB: Untersuchung zur Stimmerkennung bei PostFinance
- FINMA Geschäftsbericht 2025: Resilienz
- Swiss Banking: Leading with Trust, Sovereign AI
- IT-Finanzmagazin: Testautomatisierung in der Banken-IT
Empfehlungen
Abonnieren
Vielen Dank!
Machen Sie sich bereit! Sie erhalten handverlesene Inhalte direkt in Ihren Posteingang.
