Zusammenfassung

  • Murex teilte am 23. September mit, MX.3 sei für Google Cloud zertifiziert. Damit kommt zu einer Cloud-Geschichte mit Azure und AWS ein weiteres Ziel hinzu. Die Mitteilung nennt erkundende Kunden, aber keinen Produktionsstart, keine Migrationsdauer, Preise, Benchmarks oder Wiederanlaufergebnisse.
  • Die Zertifizierung senkt den Aufwand, eine weitere Infrastruktur zu prüfen. Sie übernimmt jedoch weder bestätigte Positionen und Sicherheiten noch Marktzeitpunkt, Rechte, Schnittstellenquittungen oder Tagesabschlussfolge. Eine Bank besitzt erst dann eine brauchbare Ausstiegsoption, wenn sie diesen Zustand innerhalb ihrer Toleranz wiederherstellen und abstimmen kann.

In einem Notfallplan lässt sich rasch eine weitere Wolke einzeichnen. Ein lebendes Kapitalmarktbuch folgt nicht so leicht. Vor der Wiedereröffnung muss feststehen, welche Geschäfte bestätigt, welche Sicherheiten wirksam übertragen, welche Marktdaten zur Bewertung verwendet und welche Zahlungen unwiderruflich versandt wurden. Zwei technisch verfügbare Systeme können unterschiedliche Geschäftswahrheiten enthalten.

So lässt sich die Murex-Mitteilung vom 23. September einordnen. MX.3 ist für Google Cloud zertifiziert. Genannt werden Handel, Treasury, Risiko und Nachhandel, darunter rechenintensive Markt- und Kontrahentenrisiken sowie Intraday-Analysen. Mehrere Kunden prüften die Möglichkeit einer Nutzung.

Das ist ein ernstzunehmendes neues Ziel, aber noch kein vollzogener Weg. Die Mitteilung nennt weder einen produktiven Kunden noch Zeit, Kosten, RPO, RTO, Regionsdesign oder Abstimmungsergebnis. Sie belegt, dass die Plattform unterstützt wird. Ob eine bestimmte Bank dort ihren Geschäftszustand intakt wieder aufbauen kann, bleibt offen.

Das dritte Ziel ist zunächst eine Option

MX.3 hat bereits eine Cloud-Vorgeschichte. Murex kündigte 2017 die Azure-Zertifizierung an. Die heutige Cloud-Seite beschreibt AWS und Microsoft Azure, mehrere Betriebsmodelle und eine schrittweise Einführung von Machbarkeitsnachweis über Entwicklung und Test bis Produktion. 2025 veröffentlichte Murex zudem eine mehrjährige AWS-Vereinbarung für den Ausbau verwalteter Dienste.

Google Cloud schafft damit Optionswert. Bei einer Neueinführung lassen sich mehr Angebote für Infrastruktur, Regionen, Sicherheit und Betrieb vergleichen. Bestehende Kunden können Entwicklung, Notfallwiederherstellung oder elastische Risikogitter neu zuordnen. Murex erhält einen Vertriebs- und Supportkanal; Google gewinnt Zugang zu einer betriebsnahen Finanzlast.

Der Wert kann vor einem Produktionsumzug entstehen. Wettbewerb verbessert Konditionen, Testumgebungen werden kurzlebiger, einzelne Berechnungen können anderswo skalieren. Diese Beweglichkeit hat jedoch verschiedene Reichweiten. Ein ausgelagertes Rechengitter macht das durchgängige Aufzeichnungssystem nicht austauschbar. Eine gestartete Ersatzumgebung enthält nicht automatisch das richtige Buch. Beschaffungswahl und ausführbarer Ausstieg sind unterschiedliche Vermögenswerte.

Auch Betriebsmodelle dürfen nicht vermischt werden. Die AWS-Mitteilung beschreibt MXSaaS als von Murex von Infrastruktur bis Upgrade verwalteten Dienst und nennt XVA as a Service gesondert. Die Google-Mitteilung spricht von einer MX.3-Bereitstellung auf Google Cloud; sie kündigt MXSaaS dort nicht an. Zertifizierte Software, kundengeführte IaaS und ein industrialisierter Managed Service teilen Arbeit und Haftung anders auf.

MX.3 ist eine Geschäftsfolge, kein einzelner Container

Die MX.3-Architekturseite beschreibt Präsentations-, Geschäfts-, Orchestrierungs- und technische Ebenen. Die technische Ebene umfasst Authentifizierung, Autorisierung und Diensteregistrierung. Verschiedene Technologien tragen Berechnungen; komplexe Preisbildung kann über CPU- oder GPU-Gitter laufen; Kubernetes und Container werden für Marktrisiko und Berichtswesen genutzt.

Container in einem Teil der Last machen das Gesamtgebilde nicht zum versiegelten Paket. Eine langjährig betriebene Installation enthält Produkt- und Buchkonfiguration, Referenz- und Marktdaten, Zertifikate, Schlüssel, Rechte, externe Anschlüsse, Batchfolgen, Alarmwerte, Ausnahmewarteschlangen und Wissen der Betreiber. Abhängigkeiten liegen nicht nur im Code, sondern auch in Lizenzen, Datenverträgen, Abwicklungsfenstern und internen Freigaben.

Portabilität hat wenigstens vier Ebenen. Infrastrukturportabilität rekonstruiert Rechenleistung, Speicher und Netz. Anwendungsportabilität führt unterstützte MX.3-Komponenten und Versionen korrekt aus. Datenportabilität überträgt vollständigen, geordneten und bedeutungsgleichen Zustand. Betriebsportabilität befähigt Teams, den Dienst unter der neuen Aufgabenverteilung zu sichern, abzustimmen und wiederaufzunehmen.

Die Zertifizierung liefert starke Hinweise für die ersten beiden Ebenen. Die letzten beiden sind kundenspezifisch. Sie hängen von nativen Diensten, Schnittstellendesign, Schlüssel- und Telemetriehaltung, Handbuchbesitz und der Frage ab, ob ein Geschäftswiederanlauf am Alternativziel tatsächlich stattgefunden hat.

Entscheidend ist der letzte anerkannte Zustand

Ein Neustart von Prozessen genügt nicht. Ein doppelt importiertes Geschäft erhöht die Risikoposition. Eine nur auf einer Seite gebuchte Sicherheitenbewegung erzeugt Streit. Der falsche Marktzeitpunkt verändert Bewertung und Limits. Eine bereits freigegebene Zahlung darf nicht als ungesendet erscheinen.

Zum Ausstiegspaket gehören deshalb mehr als Datenbankdateien: erklärter Wiederherstellungspunkt, geordnete Journale, Herkunft, schwebende Nachrichten, externe Quittungen, Jobabhängigkeiten und Abstimmungsregeln. Für jedes Objekt muss eine maßgebliche Quelle benannt sein und eine Person Konflikte entscheiden dürfen. Softwarestand, Konfiguration, Rechte und Freigaben sind ebenfalls Geschäftszustand.

Gleichwertige Server können also vorhanden sein, ohne einen betriebsfähigen Dienst zu ergeben. Anbieterspezifische Datenbanken, Identitäten, Warteschlangen, Beobachtung, Schlüsselhaltung oder Netzkontrollen verbessern oft den Alltag und vergrößern die Wiederaufbaufläche. Jede native Funktion zu meiden wäre nicht automatisch klug; Zuverlässigkeit und Produktivität könnten sinken. Die Abhängigkeit muss vielmehr erfasst, bepreist, zugeordnet und erprobt sein.

Eine erste belastbare Übung kann begrenzt bleiben. Die Bank wählt einen wichtigen Dienst und eine definierte Störung, stellt Anwendung und Abhängigkeiten am Alternativziel her, schließt einen kontrollierten Daten- und Schnittstellensatz an und vergleicht Positionen, Barbestand, Sicherheiten, Sensitivitäten, Bestätigungen und Buchhaltung mit einer genehmigten Referenz. Zeit, Handarbeit, Verlust, Ausnahmen und Annahmeverantwortlicher werden protokolliert.

Regulierung verlangt einen geprobten Ausstieg

Für erfasste EU-Finanzunternehmen macht DORA Artikel 28 die Unterscheidung ausdrücklich. Unterstützen IKT-Dienste kritische oder wichtige Funktionen, muss der Ausstieg ohne Geschäftsunterbrechung, regulatorische Einschränkung oder Schaden für die Kundenkontinuität möglich sein. Pläne müssen umfassend, dokumentiert, hinreichend getestet und regelmäßig überprüft sein. Alternativen sowie ein sicherer und vollständiger Transfer von Diensten und Daten oder die Rückführung ins Haus sind vorzusehen.

DORA zertifiziert keine MX.3-Architektur und genehmigt keine Google-Cloud-Konfiguration. Es verlangt auch keinen ständigen Mehrfachbetrieb jeder Last. Die Verantwortung bleibt beim Finanzunternehmen. Ein vom Softwareanbieter unterstütztes Alternativziel ist hilfreich, ersetzt aber nicht den Ausstiegsnachweis des Kunden.

Die Bank of England weist aus systemischer Sicht darauf hin, dass Auslagerung und Abhängigkeit von wenigen Dritten operative Verbindungen schaffen. Ein weiterer zertifizierter Anbieter reduziert Konzentration auf dem Beschaffungsplan. Praktisch sinkt sie, wenn wichtige Dienste in tolerierbarer Zeit bewegt oder wiederhergestellt werden können.

Mit jedem Betriebsmodell verschiebt sich Verantwortung

Murex kontrolliert Softwarezertifizierung, unterstützte Muster, Releases und Teile der technischen Methode. Google Cloud kontrolliert Regionen, Kapazität, Netz und verwaltete Produkte. Ein Integrator kann Landezone, Automatisierung und Teile des Betriebs übernehmen. In einem Managed Service übernimmt der Anbieter weitere tägliche Aufgaben.

Die Bank bleibt Eigentümerin der Geschäftsentscheidung. Sie klassifiziert Kritikalität, setzt Ziele, genehmigt Daten- und Identitätsdesign, hält Marktanschlüsse, akzeptiert Abstimmungen und verantwortet sich gegenüber Leitung und Aufsicht. Aufgaben auszulagern heißt nicht, die Bedeutung einer wiederhergestellten Position auszulagern.

Eine Verantwortungsmatrix muss Normalbetrieb und Ausstieg umfassen. Wer pflegt Infrastrukturcode? Wer exportiert Konfiguration, Protokolle und Nachweise? Wer stellt Lizenzen im Übergang? Wer öffnet Netze, dreht Schlüssel und validiert Marktdaten? Wer genehmigt die Handelsaufnahme? Welche Hilfe gilt nach Kündigung? Eine Partnerschaftsmeldung beantwortet diese Kundenthemen nicht.

Mehr Wahl kann Bindung zunächst vertiefen

Das neue Ziel erzeugt ein Paradox. Native Dienste beschleunigen Lieferung und begründen die Einführung; anschließend werden Daten, Sicherheit und Beobachtung enger mit dem Anbieter verbunden. Der Normalbetrieb kann besser, seine Reproduktion anderswo teurer werden. Das kann rational sein, zeigt aber, warum die Zahl der Zertifizierungen den Ausstiegsaufwand schlecht misst.

Der Gegenfall entsteht, wenn Murex portable Bereitstellungsartefakte, Datenbankoptionen, klare Komponentengrenzen und gemeinsame Betriebsnachweise pflegt. Dann kann jede Zertifizierung den Weg standardisieren. Wiederholte Migrationen schaffen Fachkräfte und wiederverwendbare Werkzeuge. Der Markt sollte solche Belege statt Logos zählen.

Der Umfang erster Fälle wird entscheidend sein: Entwicklung und Test, Risikogitter, Wiederherstellung, Produktion oder die gesamte Kette? Ein Wiederanlauf braucht Dienst, Punkt, Zeit und Abstimmungsergebnis. Ein Ausstieg braucht zusätzlich Formate, Vertragshilfe, Personal, Schnittstellen und Gesamtkosten.