Ein Core-Banking-System ist nicht einfach eine weitere Anwendung im IT-Portfolio. Es ist das zentrale Hauptbuch der Bank, an dem Kontostände, Abrechnungen, Zinsabgrenzungen und das aufsichtsrechtliche Meldewesen hängen. Wird dieses System langsam oder steht es still, ist das keine Unannehmlichkeit, sondern finanzielles, Reputations- und regulatorisches Risiko. Für einen Head of IT oder Head of Operations in einer Bank lautet die Frage deshalb nicht, ob Core Banking gewartet wird, sondern wie es gewartet wird, damit es sich vorhersehbar verhält und sich auf Service-Ebene steuern lässt.
Nach unserer Erfahrung entsteht Vorhersehbarkeit nicht durch einige Helden, die Brände löschen. Sie entsteht durch einen wiederholbaren Prozess und klar definierte SLAs. Deshalb kommen wir meist über ein Managed-Services-Modell in eine Bank: Wir übernehmen Wartung, Monitoring und Integrationen, und die Bank misst uns an Reaktionszeiten und Verfügbarkeit statt an geleisteten Stunden.
Warum sind Wartung und Support von Core Banking so kritisch?
Eine Bank arbeitet durchgehend, und ihre Systeme sind dicht miteinander verflochten. Jede Minute Ausfall im Core Banking wird zu blockierten Überweisungen, fehlgeschlagenen Kartenzahlungen und einer wachsenden Warteschlange in der Service-Hotline. Dazu kommt regulatorischer Druck: Die Aufsicht erwartet dokumentierte Geschäftskontinuität, Kontrolle über Änderungen und volle Rechenschaft über Vorfälle.
In der Praxis zählen drei Dinge gleichzeitig. Erstens die Verfügbarkeit während der Bankzeiten und der nächtlichen Batch-Verarbeitung. Zweitens die Datenintegrität, denn ein Fehler in den Abrechnungen kostet mehr als ein kurzer Ausfall. Drittens die Reaktionsgeschwindigkeit, wenn doch etwas schiefgeht. Eine Wartung, die nur eines davon adressiert, lässt die Bank mit unkontrolliertem Risiko zurück.
Was sind Managed Services und SLA in der Wartung einer Bank?
Managed Services bedeutet, dass wir die Verantwortung für einen definierten Systembereich übernehmen, statt nur Hände zu leihen. Wir vereinbaren ein Ergebnis, beschrieben in einem SLA (Service Level Agreement): wie schnell wir reagieren, wie schnell wir Vorfälle lösen und welche Verfügbarkeit wir zusichern.
Für Core Banking umfasst ein solches SLA üblicherweise:
- Prioritätsstufen (P1-P4) mit jeweils eigener Reaktions- und Lösungszeit,
- die Zielverfügbarkeit des Service (z. B. über Arbeits- und Batch-Fenster hinweg),
- Wartungsfenster für Änderungen, Updates und geplante Arbeiten,
- einen Eskalationsweg sowie die Berichterstattung über die tatsächlich erreichten Kennzahlen.
Der entscheidende Unterschied zu einfachem Support: Ein SLA verschiebt das Gespräch von „wie viele Menschen arbeiten” zu „welches Ergebnis wir liefern”. Genau dieses Ergebnis zeigt die Bank später ihrem Prüfer und ihrer Aufsicht.
Wie sehen Monitoring, Support und Administration im Alltag aus?
Wir bauen die tägliche Arbeit auf drei Säulen auf, die zusammenlaufen müssen. Wir überwachen das System und sein Umfeld, wir bearbeiten Tickets über die Support-Linien hinweg, und wir administrieren die Umgebungen so, dass ein Vorfall gar nicht erst entsteht.
Auf dieser Ebene tun wir üblicherweise Folgendes:
- wir beobachten Performance, Verfügbarkeit und Batch-Verarbeitung, bevor ein Nutzer ein Problem meldet,
- wir verantworten Tickets auf der 1., 2. und 3. Linie, mit klarer Aufteilung der Zuständigkeit,
- wir administrieren Umgebungen, Zugriffsrechte, Konfiguration und wiederkehrende Jobs,
- wir analysieren Daten und Logs, um eine einmalige Störung von einem aufkommenden Trend zu unterscheiden.
Der Punkt ist: Support endet nicht mit dem Schließen eines Tickets, sondern mit dem Schließen der Ursache.
Wie integrieren wir Core Banking mit den übrigen Systemen der Bank?
Core Banking arbeitet selten im luftleeren Raum. Darum herum leben Zahlungssysteme, Online- und Mobile-Banking, das Data Warehouse, CRM, Module für das Meldewesen und Dienste Dritter. Wartung heißt deshalb auch, die Integrationen zu betreuen und die Schicht des Datenaustauschs, denn genau dort tauchen stille Fehler am häufigsten auf.
Wir halten die Schnittstellen und APIs zwischen den Systemen stabil und machen Datenflüsse prüfbar und nachvollziehbar. Wir achten auf die Konsistenz der Daten zwischen Core Banking, Warehouse und Meldewesen, und wann immer sich ein System ändert, prüfen wir, was mit dem Rest geschieht. In einer Bank ist Integration kein einmaliges Projekt, sondern ein fortlaufender Wartungsbereich, der wie jeder andere Teil des Service versioniert, getestet und überwacht werden muss.
Wie sichern wir Geschäftskontinuität und Sicherheit?
Wir behandeln Kontinuität und Sicherheit als Teil der Wartung und nicht als eigenes Thema für später. In der Praxis heißt das Arbeiten nach Prozeduren: Wir planen Änderungen innerhalb der Wartungsfenster, wir halten Backups und Wiederherstellungsszenarien vor, und wir steuern Zugriffe nach dem Grundsatz der geringsten Rechte.
Für Sicherheit und Kontinuität tun wir üblicherweise Folgendes:
- wir steuern Änderungen, damit keine Modifikation ohne Kontrolle in die Produktion gelangt,
- wir testen Wiederherstellungs- und Failover-Prozeduren, statt anzunehmen, dass sie funktionieren,
- wir wachen über Zugriffsrechte und Audit-Trails, denn in einer Bank muss jede Operation nachvollziehbar sein,
- wir dokumentieren Vorfälle und Änderungen so, dass es einer aufsichtsrechtlichen Prüfung standhält.
Wie messen wir das SLA in der Wartung von Core Banking?
Ein SLA wirkt nur, wenn es messbar und für beide Seiten sichtbar ist. Wir weisen Reaktionszeit und Lösungszeit nach Priorität aus, die Verfügbarkeit des Service sowie die Wirksamkeit (wie viele Vorfälle wir innerhalb der vereinbarten Schwellen gelöst haben). Diese Zahlen berichten wir in festem Takt, zusammen mit Ursachenanalyse und Empfehlungen, damit die Wartung Monat für Monat besser wird und nicht nur „erledigt” ist. Für einen Head of IT ist das der Datenbestand, der Wartung planbar, budgetierbar und in einer Prüfung vertretbar macht.
Welche Kompetenzen stellen wir für die Wartung einer Bank bereit?
Wir stellen das Team rund um die konkrete Bankumgebung zusammen, nicht nach einer generischen Vorlage. In Wartungsteams für Banken besetzen wir Rollen wie System- und Datenbankadministratoren, Application-Support-Engineers, Integrationsspezialisten und Datenanalysten, die tatsächlich lesen können, was das System tut. Wo die Bank Flexibilität braucht, verbinden wir Managed Services mit Team-Verstärkung, sodass wir die Besetzung mit Arbeitslast und Roadmap hoch- und herunterskalieren können.
Wie machen wir das bei RITS?
Wir tun es auf Basis echter Bankerfahrung. Für eine Gruppe, die im Genossenschaftsbankwesen begann und zu einem internationalen Akteur wuchs, liefern wir seit 2017 IT-Administration, technischen Support und Datenanalyse. Mit der Zeit wuchs das Engagement auf nahezu 80 Spezialisten im Body-Leasing-Modell, was dem Kunden erlaubte, seine Umgebung zu warten und weiterzuentwickeln, ohne eine ganze Abteilung von Grund auf aufzubauen.
Was bedeutet das für eine andere Bank? Dass Wartung auf einem stabilen, dedizierten Team ruhen kann, das die Umgebung kennt und mit der Organisation wächst, statt erst zu reagieren, wenn etwas bricht. Als Nearshore-Partner aus Polen arbeiten wir in einer nahen Zeitzone, fügen uns also ohne langen Anlauf in Arbeitsrhythmus, Reviews und Wartungsfenster der Bank ein und rechnen unsere Arbeit über SLAs ab statt über erfasste Stunden.
Wo beginnen Sie mit der Wartung von Core Banking nach SLA?
Beginnen Sie mit einer Karte Ihrer Systeme und Integrationen und mit der Frage, welche Services für die Bank und für die Aufsicht wirklich kritisch sind. Das legt Ihre Prioritäten, SLA-Stufen und die Kompetenzen fest, die Sie im Wartungsteam brauchen. Wenn Sie Managed Services gegen ein dediziertes Team oder die Verstärkung der eigenen Leute abwägen, haben wir die Unterschiede in unserem Artikel zu IT-Kooperationsmodellen beschrieben.
Sie wollen Core Banking nach festen SLAs warten und integrieren? Sprechen wir darüber - wir finden ein Team und ein Service-Modell passend zu Ihrer Bank.