Finanzielle Souveränität erfordert souveräne Infrastruktur: Warum europäisches Fintech Kernbanken benötigt, die in Europa gebaut werden
Finanzielle Souveränität erfordert Unabhängigkeit auf Infrastrukturebene. Ein Ledger, das auf US-Cloud-Infrastruktur gehostet wird, Zahlungen über US-kontrollierte Netzwerke routet und von US-geführten Kapital kontrolliert wird, ist nicht souverän, unabhängig davon, wo die Bank eingetragen ist.
Die Abhängigkeit ist messbar. 63 % der europäischen Cloud-Infrastruktur läuft auf US-kontrollierten Providern. Mehr als 90 % der europäischen Kartentransaktionen routen über Visa und Mastercard. Jede EUR 1-Milliarden-plus-Finanzierungsrunde in europäischem Fintech im Jahr 2025 wurde von US-Investoren angeführt. EUR 9 Milliarden an jährlicher Finanzierung würden verschwinden, wenn US-Kapital sich aus europäischem Fintech zurückziehen würde. Die Infrastrukturabhängigkeit und die Kapitalabhängigkeit sind keine getrennten Probleme. Sie verstärken sich gegenseitig. Anbieter, die von US-Kapital finanziert werden, unterliegen US-regulatorischem Druck, US-Exportkontrollen und US-Gerichtsbarkeit, unabhängig davon, wo ihre Server stehen.
DORA verwandelt dies aus einer geopolitischen Präferenz in eine regulatorische Anforderung.
Die Drei Abhängigkeitsschichten
Europäische Finanzinstitutionen sehen sich mit Infrastrukturabhängigkeiten auf drei verschiedenen Ebenen konfrontiert. Jede Ebene hat unterschiedliche rechtliche Implikationen, unterschiedliche DORA-Exposures und unterschiedliche Sanierungszeiträume.
Schicht 1: Cloud-Infrastruktur. AWS, Azure und Google Cloud stellen den Großteil der Rechen-, Speicher- und Netzwerkinfrastruktur für europäische Finanzinstitutionen bereit. Diese Anbieter betreiben Rechenzentren in Europa, aber die Mutterunternehmen sind US-Konzerne, die US-Gerichtsbarkeit unterliegen. Der CLOUD Act (2018) erlaubt US-Strafverfolgungsbehörden, US-Cloud-Anbieter zur Offenlegung von Daten zu zwingen, die überall auf der Welt gespeichert sind, einschließlich europäischer Rechenzentren, ohne europäisches Rechtsverfahren zu erfordern. Daten-Residency in Frankfurt schafft keine Datensouveränität, wenn der US-Mutter des Anbieters gezwungen werden kann, sie herauszugeben.
DORA Artikel 28 verlangt von Finanzinstitutionen, ICT-Drittanbieter-Risiken zu bewerten und zu überwachen, einschließlich Konzentrationsrisiken. Artikel 30 verlangt schriftliche vertragliche Vereinbarungen mit ICT-Anbietern, die Audit-Rechte, Datenstandort-Anforderungen, Exit-Strategie-Bestimmungen und das Recht auf Durchführung von Penetrationstests enthalten. Für US-Cloud-Anbieter ist das Audit-Recht real, aber was eine europäische Institution bei einem Audit findet, kann ein System sein, das sie nicht modifizieren, nicht schnell wegmigrieren und nicht vollständig bewerten kann, weil die interne Architektur des Anbieters proprietär ist.
Schicht 2: Zahlungsnetzwerke. Visa und Mastercard verarbeiten mehr als 90 % der europäischen Kartentransaktionen. Beide sind US-Konzerne. SWIFT, das Interbank-Nachrichtenrouting betreibt, ist in Belgien eingetragen, aber von einem Board mit signifikanter US-Beteiligung geführt und historisch US-Regierungsdruck ausgesetzt. Im Jahr 2012 zwang das US-Finanzministerium SWIFT, den Iran aus seinem Netzwerk auszuschließen, was die Fähigkeit europäischer Banken beeinträchtigte, legitime Transaktionen mit iranischen Gegenparteien abzuwickeln.
SEPA bietet europäisch betriebene Infrastruktur für Überweisungen und Lastschriften. Die Europäische Zentralbank betreibt TARGET2 (und seinen Nachfolger T2) für hochwertige Euro-Zahlungen. Aber Kartenzahlungen, die den Großteil des Consumer-Transaktionsvolumens ausmachen, haben keine europäisch betriebene Alternative mit vergleichbarem Volumen. Die EPI (European Payments Initiative) baut Wero als Kartenzahlungsalternative auf, aber sie deckt nur einen Bruchteil des aktuellen Visa/Mastercard-Volumens Mitte 2026 ab.
Schicht 3: Kapital und Governance. Infrastrukturanbieter unterliegen den Governance-Prioritäten ihrer Kapitalgeber. Ein europäisches Fintech, das primär von US-Venture-Kapital finanziert wird, steht unter Druck, sich auf US-Märkte auszudehnen, US-Infrastruktur-Defaults zu übernehmen und US-Standard-Vertragsbedingungen zu akzeptieren, einschließlich Datenklauseln, die möglicherweise mit GDPR und DORA kollidieren.
Der Finch Capital State of European FinTech 2026 Report quantifiziert die Kapitalanfallstelle: EUR 37,5 Milliarden pro Jahr könnten freigesetzt werden, wenn europäische Pensionsfonds die Fintech-Allokationsraten ihrer US-Pendants erreichen würden. Diese Lücke ist nicht gefüllt. Das Ergebnis ist eine anhaltende US-geführte Kapitaldominanz in der Wachstumsphase, die sich in US-ausgerichteter Governance in den Unternehmen übersetzt, die die europäische Finanzinfrastruktur bauen.
Was souveräne Infrastruktur technisch bedeutet
Souveränität ist keine Zertifizierung oder eine Flagge auf einem Rechenzentrum. Auf der Infrastrukturebene erfordert sie vier spezifische Eigenschaften.
Daten-Residency mit Gerichtsbarkeitskontrolle. Daten müssen in der EU/EWR gespeichert werden unter einer Rechtsperson, die ausschließlich EU-Gerichtsbarkeit unterliegt. Das bedeutet, dass das Mutterunternehmen des Cloud-Anbieters, nicht nur die Betriebs-Tochter, an EU-Datenschutzanforderungen gebunden sein muss. Die German Sovereign Cloud (betrieben von T-Systems und SAP auf Azure-Infrastruktur) versucht dies durch ein Modell, bei dem Microsoft ohne deutsche Treuhänder-Zustimmung keinen Datenzugriff hat. EU-Sovereign-Cloud-Angebote von AWS und Google sind architektonisch ähnlich. Jedes Modell bietet partielle Souveränität: US-Technologie mit europäischer Governance-Überlagerung.
Audit-Zugang ohne Vendor-Gatekeeping. DORA Artikel 30(2)(d) verlangt, dass die Finanzinstitution ihren ICT-Anbieter auditieren kann, direkt oder durch einen Dritten. Bei Black-Box-Infrastruktur, bei der der Quellcode, die Dependency-Kette und das Laufzeitverhalten proprietär sind, ist dieses Audit-Recht nominal. Ein Auditor kann verifizieren, dass das System die erwarteten Ausgaben produziert; er kann nicht verifizieren, wie. Ein System mit veröffentlichtem Quellcode, dokumentierter Dependency-Kette und deterministischem Verhalten kann vollständig auditiert werden. Das Audit-Recht ist substantiell, nicht nominal.
Supply-Chain-Transparenz. DORA Artikel 9 verlangt die Bewertung von Supply-Chain-Risiken. Für ein Kernbankensystem umfasst die Supply Chain jede Bibliothek, von der das System abhängt, jede Drittanbieter-Service, den es aufruft, und jede Datenverarbeitung, durch die es Daten weiterleitet. Ein System mit 5.000 transitiven Dependencies kann seine Supply Chain nicht in irgendeinem sinnvollen Sinn auditieren lassen: der Dependency-Graph ist zu groß, um ihn zu bewerten. Ein System mit 30 transitiven Dependencies in seinem Finanzkern kann das.
Exit-Strategie mit begrenzten Migrationskosten. DORA Artikel 28(7) verlangt, dass Konzentrationsrisiken gemanagt werden, einschließlich der Fähigkeit, einen kritischen ICT-Anbieter zu verlassen, ohne unzumutbare operative Störungen. Für ein Kernbankensystem, das auf einem proprietären Vendor-Stack aufgebaut ist ( proprietäre APIs, proprietäre Datenformate, vendor-spezifisches Tooling), sind die Exit-Kosten in Jahren und zig Millionen Euro gemessen. Für ein System mit Standard-Schnittstellen (ISO 20022, offene APIs), offenen Datenformaten und portablen Deployment-Modellen sind die Exit-Kosten begrenzt.
DORAs Konzentrationsrisiko-Bestimmungen
DORA Artikel 28(5) behandelt Konzentrationsrisiken in ICT-Drittanbieter-Abhängigkeiten explizit. Die Europäischen Aufsichtsbehörden sind ermächtigt, kritische ICT-Drittanbieter (CTPPs) zu benennen und zusätzliche Überwachungsanforderungen aufzuerlegen, einschließlich Resilience-Tests, Exit-Planung und operativer Berichterstattung.
Für europäische Finanzinstitutionen hat die Konzentrationsrisiko-Analyse zwei Dimensionen. Erstens, ob ein einzelner ICT-Anbieter eine systemische Abhängigkeit darstellt: wenn dieser Anbieter ausfällt oder nicht verfügbar wird, fällt dann auch die Institution aus? Zweitens, ob der EU-Finanzsektor als Ganzes eine übermäßige Konzentration in einem einzelnen Anbieter oder Anbieterkategorie hat.
Die ESAs veröffentlichten ihre erste CTPP-Analyse 2025 und fanden signifikante Konzentration in Cloud- und Kernbanken-Technologie. Die regulatorische Antwort ist nicht Provider-Switching zu mandatieren, sondern zu verlangen, dass Institutionen nachweisen können, dass sie das Risiko bewertet haben und plausible Exit-Strategien haben. Eine Institution, die keine Migrationspfad zu einem anderen Kernbanken-Anbieter artikulieren kann, weil die Architektur des aktuellen Anbieters mit keiner Alternative kompatibel ist, hat ein Konzentrationsrisiko, das DORA verlangt, dass sie dokumentiert und adressiert.
Das Transparent-Architecture-Argument
Das Souveränitätsargument dreht sich nicht primär darum, wo die Infrastruktur physisch steht. Es dreht sich darum, ob die Infrastruktur vollständig auditiert, unabhängig betrieben und innerhalb eines definierten Zeitrahmens weggemigriert werden kann.
Ein in Europa gebautes Kernbankensystem, das auf europäischen Cloud-Providern läuft, mit proprietärem und undurchsichtigem Quellcode bietet schwächere Souveränitätsgarantien als ein überall gebautes System mit veröffentlichter Architektur, dokumentierten Schnittstellen, minimalen externen Dependencies und Standard-Datenformaten. Die Gründungsgerichtsbarkeit ist eine rechtliche Eigenschaft. Die Auditierbarkeit der Architektur ist eine operative. Regulatoren unter DORA kümmern sich um die operative Eigenschaft.
Die praktische Frage für einen CTO, der Kernbanken-Infrastruktur evaluiert: können Sie DORAs Audit-Zugangs-, Supply-Chain-Transparenz- und Exit-Strategie-Anforderungen mit Ihrem aktuellen Anbieter erfüllen? Wenn die Antwort Vertrauen in die Behauptungen des Anbieters statt eigener Audit-Verifikation erfordert, erfüllt die Architektur die Anforderung nicht. Die Anforderung ist Evidenz, nicht Behauptung.
Trade-offs
Infrastruktur-Souveränität hat Kosten, die real sind und nicht heruntergespielt werden sollten.
Schmalere Anbieterauswahl. Cloud-Provider unter europäischer Gerichtsbarkeit haben weniger Kapazität und weniger geografische Regionen als US-Hyperscaler. Eine rein europäische Cloud-Strategie kann bedeuten, höhere Baseline-Infrastrukturkosten, weniger Edge-Locations und weniger ausgereifte Managed Services zu akzeptieren.
Migrationskomplexität. Der Umzug von einem etablierten US-Cloud-Provider zu einer europäischen Alternative ist ein mehrquartaliges Projekt mit Service-für-Service-Bewertung, Vertragsverhandlung und operativer Validierung. Für Institutionen mit jahrelanger Investition in US-Cloud-Tooling sind die Wechselkosten hoch.
Zahlungsnetzwerk-Alternativen sind unvollständig. Wero und andere europäische Zahlungsinitiativen adressieren einen Teil der Visa/Mastercard-Abhängigkeit, aber die Abdeckung ist Mitte 2026 partiell. Eine Institution kann noch keine vollständig europäische Zahlungsinfrastruktur-Stack aufbauen, der die Akzeptanz und das Volumen der US-dominierten Netzwerke erreicht.
Regulatorische Unsicherheit. Der CTPP-Rahmen der ESAs wird noch operationalisiert. Was ausreichende Exit-Strategie-Dokumentation, akzeptables Konzentrationsrisiko und angemessener Audit-Zugang ausmacht, ist nicht einheitlich über Jurisdiktionen hinweg definiert. Infrastruktur zu bauen, die eine regulatorische Anforderung erfüllt, die noch geschrieben wird, erfordert Design für Flexibilität, nicht für eine feste Spezifikation.
Fernel Context
Fernels Finanzkern ist in Zig gebaut mit einer Dependency-Anzahl von etwa 30 transitiven Dependencies. Die Architektur ist veröffentlicht: drei streng isolierte Schichten mit dokumentierten Schnittstellen, ISO 20022-native Datenmodelle und Standard-API-Verträge, die nicht proprietär sind. Der Quellcode und das Dependency-Inventar sind für Audit verfügbar, ohne Vendor-Gatekeeping. Deployment ist portabel über Cloud-Provider hinweg. Es gibt keinen Vendor-Runtime, der erforderlich wäre: kein proprietärer Managed Service, keine Black-Box-Ausführungsumgebung, die die Institution nicht inspizieren oder ersetzen kann.
Weiterlesen: Sicherheit & Compliance | Die Architektur eines Financial Operating Systems | DORA für Finanzinfrastruktur-Anbieter
Quellen:
- Finch Capital, State of European FinTech 2026: Cloud-Konzentrationsdaten, Kapitalanfallstellen-Analyse, EUR 9B Finanzierungsabhängigkeit
- DORA, Verordnung (EU) 2022/2554, Art. 28 (ICT-Drittanbieter-Risikomanagement), Art. 28(5) (Konzentrationsrisiko), Art. 28(7) (Exit-Strategien), Art. 30 (Vertragliche Vereinbarungen), Art. 9 (Supply-Chain-Risiko)
- US CLOUD Act, Pub. L. 115-141 (2018), grenzüberschreitende Datenzugriffs-Bestimmungen
- SWIFT und Iran-Sanktionen: US Treasury OFAC-Aktion, 2012, Präzedenzfall für extraterritoriale Zahlungsnetzwerk-Kontrolle
- European Payments Initiative (EPI), Wero-Produktdokumentation (2025-2026)
- ESAs, Critical ICT Third-Party Provider (CTPP) Oversight Framework, erste Designationsanalyse 2025
- EZB TARGET2 und T2-Konsolidierung: Betriebsdokumentation