Regulatorisches Horizon Scanning aufsetzen — eine operative Schritt-für-Schritt-Anleitung

Dieser Beitrag setzt das „Was“ und „Warum“ von Horizon Scanning voraus und geht direkt zum „Wie“ über: die konkreten, operativen Schritte, mit denen ein EU-Finanzinstitut eine auditierbare Horizon-Scanning-Funktion aufsetzt — vom Abstecken des regulatorischen Kosmos bis zur Build-vs.-Buy-Entscheidung. Die Methodik ist keine Erfindung des Finanzsektors: Sie ist im UK Government Office for Science Futures Toolkit kodifiziert ^[1], das ein strukturiertes PESTLE-Raster mit einer Impact-/Likelihood-Matrix kombiniert, und wird vom Institute of Risk Management für den kommerziellen Kontext im Leitfaden „Horizon Scanning: A Practitioner's Guide“ adaptiert ^[2].

Behandeln Sie die sieben Schritte unten als eine geordnete Sequenz. Jeder Schritt erzeugt ein Artefakt — eine Scope-Matrix, eine Quellenliste, eine Taxonomie, einen Workflow, ein KPI-Set —, das der nächste Schritt voraussetzt. Ein Programm, das mit Schritt vier (dem Workflow-Tooling) beginnt, bevor Schritt eins (der Scope) definiert ist, produziert vorhersehbar Rauschen: viel Aktivität, wenig belastbares Signal.

Beginnen Sie nicht mit Quellen, sondern mit Ihrer Lizenz. Der regulatorische Kosmos eines Instituts ergibt sich aus drei Achsen: den Rahmenwerken, die auf seine Tätigkeit anwendbar sind (für ein Kreditinstitut typischerweise CRR/CRD, DORA ^[6] und das AML-Paket; für einen Versicherer Solvency II, IDD und DORA; für einen CASP MiCA, die Travel-Rule-Regelung und DORA); den Aufsichtsbehörden, die es beaufsichtigen; und dem EU-Primärrecht selbst über das Amtsblatt und EUR-Lex. Erst wenn diese drei Achsen niedergeschrieben sind, wird sichtbar, was tatsächlich beobachtet werden muss — und ebenso wichtig, was nicht.

Auf der Behörden-Achse ist der beobachtbare Raum breiter, als die meisten Teams zunächst annehmen. Neben den drei Europäischen Aufsichtsbehörden (EBA, EIOPA, ESMA) und der EZB betreibt jeder EU-/EWR-Mitgliedstaat mindestens eine nationale zuständige Behörde — in Summe rund 45 Aufsichtsstellen, deren Verlautbarungen relevant werden, sobald ein Institut grenzüberschreitend tätig ist oder ausländische Kunden bedient. Das praktische Ergebnis dieses Schritts ist eine Matrix Rahmenwerk × Jurisdiktion, in der jede Zelle als „in scope“ oder „out of scope“ markiert ist — mit einer kurzen Begründung. Diese Matrix ist das erste auditierbare Artefakt Ihres Programms.

Der Futures Toolkit verlangt explizite Quellendiversität und empfiehlt eine kleine Kerngruppe von zwei bis drei Personen, die den Scan organisiert, ergänzt durch eine beliebige Zahl weiterer Scanner ^[1]. Übertragen auf die Regulierung heißt das: Ordnen Sie jeder In-Scope-Zelle Ihrer Matrix eine benannte Primärquelle zu — die Publikationsseite der Aufsichtsbehörde, ihren RSS-Feed oder ihr Register, das EUR-Lex-Dossier des Rahmenwerks, das Amtsblatt der EU. Primärquellen sind autoritativ, tragen einen präzisen Zeitstempel und geben den verbindlichen Wortlaut wieder.

Sekundärquellen — Anwaltskanzlei-Newsletter, Fachpresse, Berater-Alerts — haben einen echten Platz als Interpretationsschicht, aber nicht als Erfassungsschicht. Drei Gründe sprechen dagegen, sie als Ihr Detektionssignal zu verwenden. Erstens Latenz: Ein Newsletter erscheint Tage bis Wochen nach der Primärveröffentlichung, und diese Verzögerung geht direkt in Ihre Time-to-Action ein. Zweitens Selektivität: Sekundärquellen kuratieren, und ihre Kuratierung bildet nicht Ihren Lizenz-Scope ab. Drittens Nachweisbarkeit: In einer Inspektion ist der belastbare Nachweis, wann Sie Kenntnis erlangten, der Primärquellen-Zeitstempel — nicht das Datum, an dem ein Dritter Sie informierte. Nutzen Sie Primärquellen zur Detektion und Sekundärquellen zur Anreicherung, niemals umgekehrt.

Rohe Detektionen sind noch kein Signal. Der Futures Toolkit trägt emergierende Treiber auf einer zweidimensionalen Matrix aus Impact und Likelihood auf und leitet daraus die Priorität ab — „hoher Impact / hohe Wahrscheinlichkeit“ ist planungskritisch, „hoher Impact / niedrige Wahrscheinlichkeit“ rechtfertigt eine laufende Beobachtung ^[1]. Für die Regulierung erweitern Teams dies typischerweise zu einer dreidimensionalen Bewertung: regulatorischer Impact, Umsetzungswahrscheinlichkeit oder Ressourcenintensität sowie Fristkritikalität — jede Dimension auf einer disziplinierten Skala, etwa 1 bis 4. Legen Sie die PESTLE-artigen Kategorien darüber (für Finanzinstitute meist als Prudential, Conduct, Financial Crime, ICT/operationelle Resilienz und Nachhaltigkeit reformuliert), damit jede Detektion sowohl eine Domäne als auch einen Score trägt.

Die entscheidende Design-Entscheidung ist die Materialitätsschwelle: der Punkt, an dem ein Finding aus der Routine-Behandlung in eine formale Vier-Augen-Prüfung übergeht. Setzen Sie eine explizite Regel — beispielsweise löst jedes Item, dessen Impact- oder Fristkritikalitäts-Score den Höchstwert erreicht, eine Zweitbegutachtung durch eine unabhängige Person aus, bevor es geroutet wird. Das Vier-Augen-Prinzip ist kein Zierrat, sondern eine etablierte Governance-Kontrolle: Die EBA-Leitlinien zur internen Governance behandeln die Aufgabentrennung und das Management von Interessenkonflikten als zentrale Governance-Kontrollen ^[3]. Eine dokumentierte Schwelle verwandelt subjektives Urteil in eine wiederholbare, prüfbare Regel.

Fassen Sie die Schritte eins bis drei zu einer laufenden Pipeline mit vier Stationen zusammen. Detect: Die zugeordneten Primärquellen werden auf einer festen Kadenz abgefragt, und jede neue Verlautbarung wird mit einem Erfassungs-Zeitstempel aufgenommen. Classify: Jedes Item erhält seine Domäne und seine Impact-/Wahrscheinlichkeits-/Frist-Scores; Items über der Materialitätsschwelle durchlaufen die Vier-Augen-Prüfung. Route: Das klassifizierte Finding geht an das inhaltlich verantwortliche Team — DORA-Themen an die ICT-/operationelle-Resilienz-Funktion, AML-Themen an Financial Crime, Prudential-Themen an Treasury oder Meldewesen. Evidence: Jeder Übergang — Detektion, Klassifikation, Review, Routing, Bestätigung — wird in ein unveränderbares, zeitgestempeltes Audit-Log geschrieben.

Zwei Regeln machen den Unterschied zwischen einem Workflow, der eine Inspektion übersteht, und einem, der es nicht tut. Erstens: Routen Sie nach Inhalt, nicht nach Organigramm. Landet ein DORA-Finding standardmäßig beim Rechts-Team, weil „Regulierung zu Legal gehört“, statt bei der ICT-Sicherheit, wächst die Time-to-Action messbar. Zweitens: Schreiben Sie das Audit-Log fortlaufend, nicht auf Anfrage. Ein Nachweis, der erst rekonstruiert wird, wenn die Aufsicht fragt, ist im aufsichtsrechtlichen Test — wann erlangte das Institut Kenntnis? — genau der Nachweis, der fehlt. Die RegTech-Analyse der EBA nennt als von Finanzinstituten berichtete Hauptvorteile „verbessertes Risikomanagement, bessere Überwachungs- und Stichprobenfähigkeiten sowie reduzierte menschliche Fehler“ ^[4] — Effekte, die genau aus der Automatisierung von Klassifikation und Audit-Trail stammen.

Eine Scanning-Funktion, die sich nicht messen lässt, lässt sich weder verbessern noch gegenüber dem Vorstand verteidigen. Drei KPIs decken den Großteil ab. Coverage: der Anteil Ihrer In-Scope-Zellen (aus Schritt 1) mit einer aktiven, verifiziert erreichbaren Quelle — das Ziel ist vollständige Abdeckung, und jede Lücke wird bewusst und dokumentiert akzeptiert. Time-to-Route: die verstrichene Zeit von der Primärveröffentlichung bis zur Bestätigung durch das verantwortliche Team. False-Positive-Rate: der Anteil gerouteter Items, den das empfangende Team als nicht relevant zurückweist — ein hoher Wert deutet auf eine zu grobe Taxonomie oder zu breite Quellen hin.

Audit-Bereitschaft ist kein separates Projekt, sondern ein Nebenprodukt der Schritte eins bis vier, sofern diese sauber ausgeführt wurden. Der praktische Test in einer Inspektion ist wiederkehrend: Kann das Institut nachweisen, wann es Kenntnis von einer bestimmten Anforderung erlangte, wer das Finding bewertete und an wen es ging? Wenn die Scope-Matrix, die Quellenzuordnung, die Klassifikationslogik und das fortlaufende Audit-Log alle als Artefakte vorliegen, ist die Antwort ein Datensatz-Export, kein Feuerwehreinsatz. Genau dies unterscheidet ein operatives Programm von einem bloß aspiratorischen.

Vier Fehlermuster treten wiederholt auf, wenn Programme unterperformen; sie sind aus der Anbieter- und Beratungspraxis beobachtet und qualitativ, nicht peer-reviewed. Erstens Boilerplate-Szenarien: generische Impact-Beschreibungen, die für jedes Finding gleich klingen und dem empfangenden Team keine Handlung nahelegen. Zweitens Newsletter-Lag: der Aufbau der Detektion auf Sekundärquellen, wodurch die Time-to-Route strukturell um die Latenz Dritter erhöht wird — siehe Schritt 2. Ein anschauliches Beispiel für den Wert des Scannings liefert der EU AI Act: Ursprünglich galt für Hochrisiko-KI-Systeme nach Anhang III der 2. August 2026; das im Juni 2026 verabschiedete Digital-Omnibus-Paket verschob diese Frist jedoch auf den 2. Dezember 2027 (für in regulierte Produkte eingebettete Systeme nach Anhang I auf den 2. August 2028) ^[5] — genau die Art beweglicher Frist, die ein manuelles, newslettergetriebenes Setup zu spät erfasst.

Drittens keine Vorstands-Sichtlinie: Wenn die Scanning-Funktion Findings routet, aber keine aggregierte, priorisierte Sicht an die Leitungsebene meldet, bleibt die aufsichtsrechtlich erwartete „line of sight“ aus, und die Funktion wird bei der ersten Inspektion als unwirksam bewertet. Viertens breit-aber-flach: das Beobachten von 200 Quellen bei niedriger Auflösung liefert typischerweise weniger handlungsrelevanten Output als 40 Quellen bei hoher Auflösung. Der IRM Practitioner's Guide betont denselben Punkt aus der Risiko-Perspektive — Horizon Scanning ist eine Technik, um Komplexität zu strukturieren und Annahmen zu hinterfragen, nicht eine Übung im Sammeln von Volumen ^[2].

Sobald die Schritte eins bis sechs spezifiziert sind, wird die Build-vs.-Buy-Frage konkret, weil Sie nun eine präzise Anforderungsliste haben: die Zahl der In-Scope-Quellen, die geforderte Detektionskadenz, das Taxonomie-Schema, die Routing-Logik und die Audit-Trail-Aufbewahrung. Build ist attraktiv, wenn Ihr Scope eng und stabil ist und Sie bereits Ingenieurskapazität für Betrieb und Pflege der Quellen-Adapter haben — jede Aufsichtsbehörde ändert ihr Seitenlayout, ihren Feed oder ihr Register irgendwann, und ein defekter Adapter erzeugt still eine Abdeckungslücke. Der Erhaltungsaufwand, nicht der initiale Aufbau, dominiert die Gesamtkosten eines Eigenbaus.

Buy ist attraktiv, wenn Ihr Scope viele Jurisdiktionen umspannt, die Aufsichtslandschaft sich schnell bewegt und Sie den Audit-Trail vom ersten Tag an standardisiert haben wollen, statt ihn selbst zu spezifizieren. Prüfen Sie einen Anbieter an genau den Artefakten dieser Anleitung: Deckt er Ihre Scope-Matrix vollständig ab? Detektiert er aus Primärquellen? Ist seine Klassifikation transparent und Ihrer Taxonomie zuordenbar? Schreibt er einen unveränderbaren Audit-Trail? Als eine Referenz-Implementierung: Horizon Scanner beobachtet rund 45 EU-/EWR-Aufsichtsbehörden aus Primärquellen, wendet auf jedes Finding eine dreidimensionale 1–4-Klassifikation an, routet an das verantwortliche Team und schreibt standardmäßig einen unveränderbaren Audit-Trail — die sieben Schritte oben, als Produkt gebaut.