Was ist Regulatory Change Management?

Regulatory Change Management (RCM), zu Deutsch regulatorisches Änderungsmanagement, bezeichnet den strukturierten Prozess, mit dem ein beaufsichtigtes Finanzinstitut eine bereits erkannte regulatorische Änderung intern zur Umsetzung bringt und diese Umsetzung nachweisbar abschließt. Es ist die „act on it and prove it“-Phase: RCM übernimmt genau dort, wo Detektion endet — nachdem eine Anforderung erfasst und als relevant klassifiziert wurde — und führt sie über Impact-Bewertung, Zuweisung von Verantwortung, Umsetzung der nötigen Kontroll-, Richtlinien-, Prozess- und Systemänderungen bis zur Abnahme und zum prüffesten Nachweis.

Der Scope von RCM ist bewusst eng auf Ausführung geschnitten. Es beobachtet nicht das Regeluniversum (das ist Regulatory Monitoring) und spürt keine emergierenden Signale auf (das ist Horizon Scanning); es nimmt ein diskretes, hinreichend verbindliches Änderungs-Item entgegen und wandelt es in nachverfolgbare, terminierte, mit Ownern versehene Arbeit um. Typische Auslöser sind eine im Amtsblatt veröffentlichte Verordnung, ein finalisierter technischer Standard (RTS/ITS), eine neue Leitlinie oder ein Aufsichtsschreiben mit konkretem Umsetzungsbedarf. Der Endpunkt ist nicht „umgesetzt“, sondern „umgesetzt und belegt“ — der Zustand, in dem das Institut in einer Inspektion zeigen kann, was es wann getan hat.

Die drei Disziplinen sind aufeinanderfolgende Stufen einer einzigen Pipeline, keine konkurrierenden Ansätze. Regulatory Monitoring ist der Oberbegriff für die fortlaufende Überwachung des gesamten relevanten Regeluniversums — geltender wie neuer Vorgaben. Horizon Scanning ist die vorausschauende Teilmenge davon: das gezielte Aufspüren emergierender, noch nicht bindender Signale, bevor sie operative Realität werden. Beide sind Detektion — sie beantworten „Was hat sich geändert?“ und „Was kommt auf uns zu?“. Regulatory Change Management beantwortet die dritte Frage: „Was müssen wir konkret tun, bis wann, und wie belegen wir es?“

Der Übergabepunkt ist präzise: detect → RCM. Sobald das Monitoring ein Item erfasst, bewertet und an die zuständige Funktion geroutet hat und die Anforderung hinreichend verbindlich ist, um Umsetzungsaufwand zu rechtfertigen, verlässt sie die Sensorik und tritt in den Umsetzungs-Workflow ein. RCM ist damit ausdrücklich nicht Detektion — es ist die Ausführung am Ende der Kette. Und es ist auch nicht mit RegTech zu verwechseln: RegTech (Regulatory Technology) ist die Software-Kategorie, mit der sich sowohl Detektion als auch Umsetzung automatisieren lassen — der Werkzeugkasten, nicht die Tätigkeit selbst ^[3].

Ein belastbarer RCM-Prozess durchläuft fünf Stufen. Erstens die Impact-Bewertung: Welche Geschäftsbereiche, Produkte, Prozesse und Systeme berührt die Änderung, und wie schwer wiegt sie? Zweitens die Gap-Analyse: Wo genau weicht der Ist-Zustand von der neuen Anforderung ab — welche Kontrolle, Richtlinie oder Systemfunktion fehlt oder muss angepasst werden? Drittens die Umsetzung: die identifizierten Lücken werden in konkrete Maßnahmen mit Verantwortlichen und Fristen übersetzt und durchgeführt. Genau diese Erwartung — „a process to regularly assess changes in the law and regulations applicable to its activities“ — formulieren die EBA-Leitlinien zur internen Governance ausdrücklich ^[2].

Viertens die Validierung: Es wird geprüft und abgenommen, dass die umgesetzten Änderungen die Anforderung tatsächlich erfüllen — nicht bloß, dass eine Aufgabe als „erledigt“ markiert wurde. Fünftens der prüffeste Nachweis: Über den gesamten Lauf hinweg entsteht ein unveränderbarer, zeitgestempelter Audit-Trail — wann die Änderung erkannt, wie bewertet, an wen zugewiesen, mit welchen Maßnahmen umgesetzt und mit welchem Ergebnis validiert wurde. Wie schon beim Monitoring gilt: In der Inspektion zählt nicht, dass umgesetzt wurde, sondern dass es belegbar ist. Ein „auf Anfrage“ rekonstruierter Nachweis besteht diesen Test typischerweise nicht.

RCM ist kein isolierter Projektplan, sondern in das Governance-Modell des Instituts eingebettet. Im verbreiteten Three-Lines-of-Defence-Modell trägt die erste Verteidigungslinie — die Geschäftsbereiche — die operative Verantwortung für die Umsetzung der Änderung in ihren Prozessen und Kontrollen. Die zweite Linie — Compliance und Risikomanagement — bewertet die Auswirkung, gibt die Umsetzung frei und überwacht sie; die EBA-Leitlinien verlangen, dass die Compliance-Funktion „should assess the possible impact of any changes in the legal or regulatory environment on the institution’s activities and compliance framework“ ^[2]. Die dritte Linie — die interne Revision — prüft unabhängig, ob der Prozess selbst funktioniert.

Klare Ownership und die Line-of-Sight des Leitungsorgans sind dabei nicht optional. Die EBA-Leitlinien weisen dem Leitungsorgan in seiner Aufsichtsfunktion ausdrücklich die Überwachung einer „well-documented compliance policy“ zu und verlangen, dass die Compliance-Funktion dem Leitungsorgan über das Compliance-Risiko und dessen Steuerung berichtet ^[2]. Für RCM heißt das: Ein Änderungs-Item braucht einen benannten Verantwortlichen, einen definierten Eskalationsweg und eine dokumentierte Berichtslinie zum Board — sonst ist die aufsichtsrechtlich geforderte Nachvollziehbarkeit nicht gegeben.

Ein dokumentierter Änderungsprozess ist keine freiwillige Best Practice, sondern eine implizite aufsichtsrechtliche Erwartung. Ihre kanonische Grundlage ist der Basel-Standard „Compliance and the compliance function in banks“ (2005): Die Compliance-Funktion soll die Geschäftsleitung zu geltenden Gesetzen, Regeln und Standards beraten, „including keeping them informed on developments in the area“ ^[1]. Beraten über eine Entwicklung ist ohne einen nachgelagerten Prozess, der diese Entwicklung in konkrete Maßnahmen übersetzt und deren Umsetzung belegt, jedoch folgenlos — RCM ist genau dieser Prozess.

Die EU-Aufsicht konkretisiert diese Erwartung. Die EBA-Leitlinien zur internen Governance nach CRD verlangen ausdrücklich einen Prozess, um Änderungen der anwendbaren Gesetze und Verordnungen regelmäßig zu bewerten, und eine dokumentierte Compliance-Policy unter Aufsicht des Leitungsorgans ^[2]. Ein dokumentierter Änderungsprozess ist außerdem der praktische Kern von Instrumenten wie dem SREP, dem ICAAP und — im Versicherungssektor — der ORSA: Alle drei setzen voraus, dass ein Institut nachweisen kann, wie es auf regulatorische und Risiko-Veränderungen reagiert. Der Druck steigt zudem durch das Volumen bindender Rahmenwerke: DORA (Verordnung (EU) 2022/2554) ist seit dem 17. Januar 2025 vollständig anwendbar ^[4] und MiCA (Verordnung (EU) 2023/1114) schafft einen harmonisierten Rahmen für Krypto-Dienstleister ^[5] — beide erzeugen einen fortlaufenden Strom umzusetzender technischer Standards.

RCM lässt sich in Tabellen und E-Mail-Postfächern führen — bis Volumen, Fristendruck und die Nachweisanforderung diesen Ansatz überfordern. Die EBA sieht in RegTech ausdrücklich ein Mittel, um Compliance- und Meldeprozesse im EU-Finanzsektor effizienter und wirksamer zu gestalten ^[3]; die Kernfrage lautet daher nicht ob, sondern welche Werkzeugtiefe. Der build-vs-buy-Abwägung liegt ein einfacher Maßstab zugrunde: Verbindet ein Werkzeug die Detektion (Monitoring/Horizon Scanning) und die Umsetzung (RCM) in einem durchgängigen, unveränderbaren Audit-Trail — vom ersten Signal bis zur validierten Maßnahme — so adressiert es das eigentliche Problem; deckt es nur eine Stufe ab, verlagert es die Bruchstelle lediglich an eine andere Stelle.