Sichere Webportale für Banken und den Finanzsektor: Architektur, Regulatorik, Umsetzung
Ein sicheres Webportal einer Bank verbindet öffentliche Website, Produktinformationen und den Einstieg ins Online-Banking auf einer Architektur, die Angriffsflächen klein hält und regulatorische Vorgaben prüfbar erfüllt. In der DACH-Region zählen dazu vor allem DORA, das Barrierefreiheitsstärkungsgesetz (BFSG), die DSGVO und die Zahlungsdiensteregeln. Eine Headless-Architektur mit zentralem Content-Hub erleichtert beides: Sicherheit und schnelle Änderungen.
Das Wichtigste in Kürze
- DORA gilt seit 17.01.2025 direkt für Banken, Versicherer und Zahlungsdienstleister. Die BaFin hat VAIT, KAIT und ZAIT aufgehoben, die BAIT entfallen vollständig mit Ablauf des 31.12.2026.
- Seit 28.06.2025 müssen Websites und Apps für Verbraucher-Bankdienstleistungen nach BFSG barrierefrei sein (Standard EN 301 549, Erklärtexte maximal Sprachniveau B2).
- Das deutsche NIS2-Umsetzungsgesetz ist seit 06.12.2025 in Kraft. Für Finanzunternehmen hat DORA beim IKT-Risikomanagement Vorrang, Registrierungspflichten beim BSI können trotzdem greifen.
- PSD3 und PSR sind politisch geeinigt, aber noch nicht anwendbar. Sie bringen unter anderem Namensabgleich mit der IBAN und barrierefreiere starke Kundenauthentifizierung.
- Headless-Architektur trennt Redaktionssystem und Auslieferung. Das reduziert die Angriffsfläche und macht Freigaben, Versionen und Änderungen revisionssicher nachvollziehbar.
Warum ist das Webportal einer Bank strategische Infrastruktur?
Weil es heute Vertrieb, Service und Pflichtkommunikation zugleich trägt. Die Website informiert nicht mehr nur, sie ist der Einstieg in Kontoeröffnung, Kreditantrag und Online-Banking und damit Teil der regulierten Wertschöpfung.
Begriffsklärung: Mit „Webportal“ meinen wir in diesem Artikel die öffentliche Website einer Bank samt Produkt- und Rechtsinhalten sowie die kundenseitigen Frontends (Login-Bereich, Antragsstrecken). Das Kernbankensystem und die Transaktionsverarbeitung im Backend sind nicht gemeint, wohl aber deren Schnittstellen zum Portal.
Die Architektur bestimmt, wie schnell eine Bank Konditionen oder Pflichtangaben ändern kann, wie belastbar das Portal bei Lastspitzen und Angriffen ist und wie gut es Prüfungen durch Aufsicht und Revision besteht. Planen Sie es daher gemeinsam mit Core-Systemen, CRM, Datenplattform und Compliance-Prozessen. Kundenzentrierung heißt dabei: Gestaltung entlang realer Aufgaben wie „Konto eröffnen“, mit klarer Sprache und barrierefreier Bedienung, was seit dem BFSG für viele Inhalte Rechtspflicht ist.
Welche Regulatorik gilt für Bank-Webportale in der DACH-Region?
In Deutschland und Österreich sind vor allem DORA, die nationale Umsetzung des European Accessibility Act, die DSGVO und das Zahlungsdiensterecht maßgeblich, in der Schweiz die Vorgaben der FINMA. Stand: September 2026.
| Regelwerk | Stand | Was es für das Webportal bedeutet |
| DORA (EU-Verordnung 2022/2554) | anwendbar seit 17.01.2025 | IKT-Risikomanagement, Meldung schwerwiegender IKT-Vorfälle, Resilienztests, Informationsregister für alle IKT-Drittdienstleister (z. B. CMS-SaaS, CDN, Cloud) |
| BaFin-Rundschreiben BAIT/VAIT | VAIT, KAIT, ZAIT aufgehoben mit Ablauf 16.01.2025; BAIT vollständig aufgehoben mit Ablauf 31.12.2026 | Für DORA-Institute ersetzt DORA die BAIT; übrige Institute folgen ab 01.01.2027 über das FinmaDiG |
| NIS2UmsuCG (DE) | in Kraft seit 06.12.2025 | DORA geht beim IKT-Risikomanagement und bei Meldungen vor; Registrierung beim BSI kann dennoch nötig sein |
| NISG 2026 (AT) | in Kraft ab 01.10.2026 | nationale NIS2-Umsetzung; Registrierung über das Unternehmensserviceportal bis 01.01.2027 |
| BFSG (DE) / European Accessibility Act | seit 28.06.2025 | barrierefreie Websites und Apps für Kredite, Zahlungen, Konten, Wertpapierdienste; EN 301 549; Sprachniveau B2 für Erklärungen |
| DSGVO | seit 25.05.2018 | Einwilligungsmanagement, Datensparsamkeit bei Tracking und Personalisierung, Auftragsverarbeitung mit CMS- und Analytics-Anbietern |
| PSD3/PSR | politische Einigung 27.11.2025, formale Annahme ausstehend | Namensabgleich mit IBAN, Haftung bei Betrug durch Identitätsvortäuschung, barrierefreiere starke Kundenauthentifizierung, Zugang zu menschlichem Support |
| EU AI Act | Transparenzpflichten ab 02.08.2026 | Chatbots und digitale Assistenten im Portal müssen als KI erkennbar sein; Kreditwürdigkeitsprüfung von Privatpersonen ist Hochrisiko-KI (Frist nach dem seit 27.07.2026 geltenden KI-Omnibus: 02.12.2027) |
| FINMA-RS 2023/1 (CH) | in Kraft seit 01.01.2024 | IKT-, Cyber- und Resilienzanforderungen für Schweizer Banken, inhaltlich vergleichbar mit DORA |
Häufig unterschätzt: Auch der SaaS-Anbieter des CMS oder das CDN ist ein IKT-Drittdienstleister im Sinne von DORA. Und das BFSG erfasst laut Bundesfachstelle Barrierefreiheit die gesamte Banking-App einschließlich der Dokumente im Postfach.
Wie gelingt die Transformation statt punktueller Modernisierung?
Mit einer Bestandsaufnahme, bevor Technologie ausgewählt wird. In vielen Instituten ist die Web-Umgebung über Jahre gewachsen: Jede Änderung löste ein akutes Problem, erhöhte aber Komplexität, technische Schulden und die Abhängigkeit von einzelnen Anbietern.
Ein belastbarer Einstieg umfasst:
- Audit von Design System, Customer Journeys und Conversion-Pfaden
- As-is/To-be-Analyse der Systemarchitektur und ihrer Integrationsabhängigkeiten
- Prüfung von Content-Modell, Redaktions- und Freigabeprozessen
- Abgleich mit DORA-Anforderungen (Drittdienstleister, Exit-Strategien, Tests) und BFSG-Konformität der bestehenden Seiten und Apps
Was bringt eine Headless-CMS-Architektur für Banken?
Sie trennt das Redaktionssystem von der Auslieferung der Inhalte. Das Frontend lässt sich unabhängig weiterentwickeln, neue Kanäle kommen per API hinzu, und das Redaktionsbackend muss nicht öffentlich erreichbar sein.
Definition: Ein Headless CMS ist ein Content-Management-System ohne fest gekoppelte Präsentationsschicht. Inhalte werden strukturiert gespeichert und über APIs an Website, App oder Beraterarbeitsplatz ausgeliefert. Headless ist ein Baustein des Composable- bzw. MACH-Ansatzes (Microservices, API-first, Cloud-native, Headless), aber nicht damit gleichzusetzen.
| Anforderung | Klassisches, gekoppeltes CMS | Headless-Architektur |
| Angriffsfläche | Redaktionsbackend oft über dieselbe Domain erreichbar | Backend isoliert, öffentlich nur Auslieferung und APIs |
| Änderungsgeschwindigkeit | Frontend-Änderungen an CMS-Releases gebunden | Frontend und Backend mit eigenem Release-Zyklus |
| Anbieterabhängigkeit | hoch, Frontend und CMS gekoppelt | geringer, Komponenten einzeln austauschbar |
| DORA-Sicht | ein großer Drittdienstleister | mehrere Dienstleister, die einzeln zu bewerten und zu registrieren sind |
Die letzte Zeile zeigt den Preis: mehr Verträge, Schnittstellen und Einträge im Informationsregister. Cloud-Betrieb erhöht Verfügbarkeit und Lastreserven. Seit dem 18.11.2025 stehen 19 benannte kritische IKT-Drittdienstleister, darunter AWS, Google Cloud und Microsoft, unter direkter Aufsicht der europäischen Aufsichtsbehörden. Risiko- und Exit-Verantwortung bleiben bei der Bank.
Welche Sicherheitsmaßnahmen braucht ein Bank-Webportal?
Mehrschichtige Kontrollen auf Auslieferung, API und Redaktion. Diese Maßnahmen gehören in jedes Architektur-Review:
- Web Application Firewall, DDoS-Schutz und CDN vor allen öffentlichen Endpunkten
- TLS 1.2 oder höher, HSTS und eine restriktive Content Security Policy gegen eingeschleuste Skripte
- API-Absicherung mit OAuth 2.0, kurzlebigen Tokens und Rate Limiting
- Single Sign-on mit Mehr-Faktor-Authentifizierung für Redakteure und Administratoren
- Rollen- und Rechtekonzept mit Funktionstrennung zwischen Erstellung, Fachfreigabe und Veröffentlichung
- manipulationssichere Protokolle und regelmäßige Penetrationstests, bei bedeutenden Instituten eingebettet in DORA-Resilienztests
Warum ist ein Headless-Content-Hub zentral für Kommunikation und Compliance?
Weil im Finanzsektor jede veröffentlichte Information eine rechtliche, vertriebliche und reputative Wirkung hat. Ein Content-Hub bündelt alle Inhalte in einer kontrollierten Quelle und steuert, wer was wann freigibt.
Definition: Ein Content-Hub ist eine zentrale, API-first organisierte Content-Management-Ebene, die Inhalte für alle Kanäle, Marken und Märkte einer Gruppe bereitstellt. Anders als ein Website-CMS ist er nicht an einen einzelnen Auftritt gebunden.
Für Banken bedeutet das:
- eine Quelle für Konditionen, Pflichtangaben und Produkttexte, ohne Duplikate, auch über Länder- und Sprachversionen hinweg
- mehrstufige Freigabe-Workflows mit Rechtsabteilung und Compliance
- lückenlose Versionshistorie, Archivierung und Wiederherstellung früherer Stände
- geringere Betriebskosten, wenn mehrere Marken einer Gruppe dieselbe Plattform nutzen
„Ein richtig konzipierter, auf Headless-Architektur basierender Content-Hub definiert das Content-Management-Modell neu: vom Publikationsmodell hin zu einem operativen Modell. Gleichzeitig sorgt er für ein höheres Sicherheitsniveau, Compliance-Kontrolle und die Fähigkeit, Änderungen in Kommunikation und Angebot schnell umzusetzen.“ Paweł Łancewicz, Business Architect, Univio
Wie wird Omnichannel Teil der operativen Architektur?
Indem alle Kanäle auf dieselben Daten, Prozessstatus und Inhalte zugreifen. Ein online begonnener Antrag muss in der App und im Beratersystem sichtbar sein. Fehlt die Integration, bricht die Customer Journey ab, und Betriebskosten steigen. Das Portal braucht daher Schnittstellen zu Antragssystemen, CRM, Datenplattform sowie Filial- und Contact-Center-Systemen und ein kanalübergreifendes KPI-Modell für Vertriebseffizienz und Akquisitionskosten.
Wie nutzen Banken Daten und KI im Webportal?
Über die Anbindung an die Analyseplattform und eine Architektur, die KI-Funktionen kontrolliert aufnimmt. Typische Einsatzfelder sind digitale Assistenten, Personalisierung, Automatisierung redaktioneller Routinen und Anomalieerkennung. Die Leitplanken: Chatbots müssen nach dem EU AI Act als KI erkennbar sein, Personalisierung braucht eine DSGVO-konforme Rechtsgrundlage, und KI-Vorschläge im Redaktionsprozess sollten dieselbe Freigabekette durchlaufen wie manuell erstellte Inhalte.
Wie unterstützt Univio Banken und Finanzdienstleister in der DACH-Region?
Univio verbindet Architekturberatung, Integration und Content-Management mit Erfahrung in regulierten Umgebungen, etwa aus Headless-Projekten in der Versicherungsbranche. Unser Vorgehen richtet sich an Institute unter Aufsicht von BaFin, FMA (Österreich) oder FINMA (Schweiz).
Univio unterstützt bei:
- Konzeption von MACH- und Headless-Architekturen sowie Content-Hubs mit Freigabe- und Audit-Prozessen
- Cloud-Migration und Integration mit Core-Systemen und CRM
- barrierefreien Kundenerlebnissen nach BFSG
- datengetriebenen und KI-gestützten Funktionen in DORA-konform dokumentierten Umgebungen
Der nächste Schritt: Architektur-Review Ihres Portals
Sie möchten prüfen, ob Ihr Portal den Anforderungen aus DORA, BFSG und PSD3/PSR gewachsen ist? Unser Architektur-Review liefert eine Gap-Analyse zu Sicherheit, Barrierefreiheit und Content-Governance sowie eine priorisierte Roadmap. Kontaktieren Sie uns für ein erstes Gespräch.
FAQ
Gilt DORA auch für die öffentliche Website einer Bank?
Ja, soweit die Website zu den IKT-Systemen des Instituts gehört. DORA erfasst das gesamte IKT-Risikomanagement, also auch Webserver, CMS, CDN und die zugehörigen Dienstleister. Diese müssen bewertet, vertraglich abgesichert und im Informationsregister geführt werden. Ausfälle oder Angriffe auf das Portal können zudem meldepflichtige schwerwiegende IKT-Vorfälle sein.
Gelten die BAIT noch?
Für Institute, die DORA unterliegen, nicht mehr. Die BaFin hat VAIT, KAIT und ZAIT mit Ablauf des 16.01.2025 aufgehoben. Die BAIT gelten nur noch für Institute außerhalb des DORA-Anwendungsbereichs und werden mit Ablauf des 31.12.2026 vollständig aufgehoben. Ab 01.01.2027 erweitert das FinmaDiG den DORA-Anwendungsbereich auf diese Institute.
Welche Teile des Online-Bankings fallen unter das BFSG?
Websites und Apps, über die Verbraucher Kredite, Zahlungen, Zahlungskonten, E-Geld oder Wertpapierdienstleistungen nutzen, einschließlich der Dokumente im Postfach. Maßgeblicher technischer Standard ist EN 301 549. Informationen zur Funktionsweise der Dienste dürfen höchstens Sprachniveau B2 haben. Ausgenommen sind Kleinstunternehmen mit weniger als zehn Beschäftigten und höchstens zwei Millionen Euro Jahresumsatz.
Ist ein Headless CMS automatisch sicherer?
Nein, aber es erleichtert Sicherheit. Weil das Redaktionsbackend nicht öffentlich erreichbar sein muss, sinkt die Angriffsfläche. Dafür entstehen mehr APIs und Dienstleister, die abgesichert und nach DORA bewertet werden müssen. Maßgeblich für das Sicherheitsniveau sind Rollenkonzept, MFA, API-Schutz, Protokollierung und Tests, nicht die Architektur allein.
Wann kommen PSD3 und PSR?
Rat und Parlament haben sich am 27.11.2025 politisch geeinigt, die formale Annahme und Veröffentlichung im Amtsblatt stehen noch aus. Die PSR gilt voraussichtlich rund 21 Monate nach Inkrafttreten, nach aktuellen Schätzungen also 2028. Portale sollten sich auf Namensabgleich mit der IBAN, transparente Entgeltanzeige und barrierefreie starke Kundenauthentifizierung vorbereiten.
