Stand: Juni 2026 · Lesezeit: ca. 11 Minuten · Engineering-Perspektive · Keine Rechts- oder Aufsichtsberatung
Eine Fintech-Plattform in Deutschland zu bauen heißt 2026 nicht nur, sauberen Code zu schreiben. Es heißt, regulatorische Erwartungen von Anfang an in die Architektur einzuplanen — DORA, die BaFin-Vorgaben (MaRisk, BAIT) und KYC/AML nach dem Geldwäschegesetz. Wer den Partner allein nach Tagessatz und Geschwindigkeit auswählt, zahlt oft doppelt: einmal für den schnellen Build und ein zweites Mal für den Umbau, sobald Aufsicht, Audit oder ein Bankpartner Fragen stellen, die das System nie beantworten sollte. Dieser Artikel ordnet ein, was ein Fintech-Engineering-Partner in Deutschland technisch leisten muss — und wann ein Spezialpartner nötig ist und wann ein guter Generalist mit Compliance-Beratung reicht.
Hinweis: Dies ist keine Rechts- oder Aufsichtsberatung. Zulassungs- und Compliance-Fragen gehören zu spezialisierten Rechts- und Compliance-Beratern. Hier geht es um die Engineering-Seite — was technisch entstehen muss, damit die regulatorischen Anforderungen erfüllbar sind. (Stand Juni 2026; Fristen und Details ändern sich — vor Entscheidungen prüfen.)
Kurze Antwort
Ein Fintech-Partner in Deutschland muss mehr können als Features liefern. Er muss Architektur so bauen, dass Incidents erkannt, klassifiziert und in den vorgesehenen Fristen technisch für eine Meldung vorbereitet sind (DORA), dass KYC/AML-Prüfungen (GwG) sauber in den Onboarding-Flow eingebettet sind, dass jede sicherheitsrelevante Aktion nachvollziehbar ist (Audit-Trail), und dass Daten und Hosting den EU- und Aufsichtsanforderungen genügen. Der falsche Partner baut ein Produkt, das funktioniert — bis es geprüft wird. Der richtige legt die technischen Voraussetzungen so an, dass spätere regulatorische Anforderungen in der Regel ohne grundlegenden Architekturumbau umgesetzt werden können.
Was ein Fintech-Engineering-Partner in Deutschland können muss
Die folgenden Anforderungen sind keine „Nice-to-haves". Sie bestimmen, ob sich Ihr Produkt in einer Prüfung sauber belegen lässt.
| Anforderung | Warum kritisch | Was im Build entstehen muss |
|---|---|---|
| ICT-Risikomanagement (DORA) | Pflicht für Finanzunternehmen seit 17.01.2025 | Logging, Monitoring, definierte Klassifizierung von Vorfällen, Wiederanlauf-Konzepte |
| Unterstützung regulatorischer Meldeprozesse | Fristen 4 h / 72 h / 1 Monat (DORA) | Erkennung + Klassifizierung + strukturierte Erfassung der relevanten Vorfalldaten im System |
| KYC/AML (GwG) | Das GwG sieht eine Identifizierung vor Aufnahme der Geschäftsbeziehung vor | Onboarding-Flow mit Identitätsprüfung, Risikoeinstufung, Re-KYC-Logik |
| Audit-Trail | Aufsicht und Prüfer erwarten regelmäßig „wer, was, wann, warum" | Unveränderliche Protokolle sensibler Aktionen |
| EU-Hosting / Datenresidenz | DSGVO + Aufsichtserwartung | EU-Infrastruktur, dokumentierte Sub-Prozessoren |
| ICT-Drittparteien-Transparenz | Register of Information (DORA) | Saubere Dokumentation von Dienstleistern und Abhängigkeiten |
Wie die Architektur angelegt ist, entscheidet, ob diese Punkte günstig (von Anfang an eingeplant) oder teuer (nachträglich nachgerüstet) sind.
DORA: was es für die Architektur konkret bedeutet
DORA (Digital Operational Resilience Act) gilt seit dem 17. Januar 2025 für Banken, Versicherer, Zahlungsdienstleister, Wertpapierfirmen und viele weitere Finanzunternehmen. Aus Engineering-Sicht sind vor allem zwei Dinge relevant:
1. Incident-Reporting in engen Fristen. Bei einem schwerwiegenden ICT-Vorfall sieht der technische Standard (RTS) vor: eine Erstmeldung innerhalb von 4 Stunden nach Einstufung als schwerwiegend (spätestens 24 Stunden nach Kenntnisnahme), einen Zwischenbericht innerhalb von 72 Stunden und einen Abschlussbericht innerhalb eines Monats. Zum Vergleich: Die DSGVO verlangt eine Meldung binnen 72 Stunden. Vier Stunden bekommt man nur hin, wenn das System Vorfälle automatisch erkennt, klassifiziert und die für eine etwaige Meldung relevanten Daten bereits strukturiert vorhält — das ist eine Architektur-Entscheidung, kein Formular.
2. ICT-Drittparteien-Risiko. Finanzunternehmen müssen ihre kritischen IT-Dienstleister erfassen und in einem „Register of Information" dokumentieren. Im November 2025 haben die europäischen Aufsichtsbehörden nach öffentlich verfügbaren Informationen erstmals eine Reihe kritischer ICT-Drittdienstleister benannt (darunter große Cloud-Hyperscaler); für diese gelten verschärfte Pflichten bis hin zu sehr kurzen Meldefristen, und bei schwerwiegenden Verstößen können Sanktionen von bis zu 1 % des durchschnittlichen weltweiten Tagesumsatzes verhängt werden. Praktische Folge fürs Engineering: Ihre Abhängigkeiten (Cloud, Zahlungs-Provider, KYC-Anbieter) müssen sauber dokumentiert und im Idealfall austauschbar gedacht sein.
Hinzu kommen die weiteren DORA-Säulen — ICT-Risikomanagement, Resilienz-Tests und Informationsaustausch über Cyberbedrohungen. Für ein Fintech-MVP heißt das nicht „alles am Tag 1", aber die Architektur sollte diese Anforderungen nicht ausschließen.
BaFin-Kontext: MaRisk, BAIT und das GwG
DORA steht nicht allein. Für regulierte Fintechs in Deutschland bildet die BaFin den Rahmen, und mehrere ihrer Vorgaben haben direkte Engineering-Konsequenzen:
- MaRisk — Risikomanagement und Governance: Prozesse müssen kontrolliert, nachvollziehbar und dokumentiert sein.
- BAIT — IT-Governance und -Sicherheit: Anforderungen an IT-Betrieb, Berechtigungen, Informationssicherheit.
- GwG (Geldwäschegesetz) — Das GwG sieht eine Identifizierung und Verifizierung von Kunden aus zuverlässigen, unabhängigen Quellen vor Aufnahme der Geschäftsbeziehung vor. Die Intervalle für eine erneute Überprüfung (Re-KYC) richten sich nach dem risikobasierten Ansatz und den internen Vorgaben — bei erhöhtem Risiko entsprechend häufiger.
Wichtig für 2026: Mit dem Sitz der EU-Geldwäschebehörde AMLA in Frankfurt gewinnt Deutschland künftig eine zentrale Rolle in der europäischen AML-Aufsicht. Nach öffentlich verfügbaren Informationen sind 2026 zudem weitere Vereinheitlichungen bei den Standards für Verdachtsmeldungen an die FIU vorgesehen. Die Erwartungshaltung steigt — und ein KYC/AML-Flow, der nur „irgendwie" funktioniert, wird zum Risiko.
Was man baut — und was man dokumentiert
Eine häufige Verwirrung: Nicht jede regulatorische Anforderung ist Code. Ein erfahrener Fintech-Partner unterscheidet sauber:
- Was man baut: Identitätsprüfung im Onboarding, Risikoeinstufung, Audit-Trail, Vorfall-Erkennung und -Klassifizierung, strukturierte Datenstrukturen für regulatorische Meldungen, Berechtigungs- und Rollenmodell, EU-Hosting.
- Was man dokumentiert: ICT-Drittparteien, Datenflüsse, Wiederanlauf-Konzepte, Verantwortlichkeiten — als Nachweis für Aufsicht und Prüfer.
Beides gehört zusammen. Ein Build ohne Dokumentation lässt sich in einer Prüfung schwer belegen; Dokumentation ohne die technischen Grundlagen ist nur ein Versprechen.
Wann Sie einen Fintech-Spezialpartner brauchen — und wann nicht
Nicht jedes Fintech-Projekt braucht einen hochspezialisierten Regulierungs-Engineering-Partner. Eine ehrliche Einordnung:
Spezialpartner sinnvoll, wenn: Sie eine erlaubnispflichtige Tätigkeit ausüben (Zahlungsdienst, E-Geld, Kontoinformationsdienst), unter DORA fallen, mit echten Kundengeldern oder sensiblen Finanzdaten arbeiten, oder einen Bank-/BaFin-Partner haben, der konkrete Nachweise verlangt.
Generalist + Compliance-Beratung reicht oft, wenn: Sie in einer frühen Validierungsphase sind, (noch) keine regulierte Tätigkeit ausüben, oder als technischer Dienstleister hinter einem lizenzierten Partner (BaaS / „Banking-as-a-Service") arbeiten. Hier ist entscheidend, dass die Architektur die spätere Regulierung nicht ausschließt — nicht, dass am Tag 1 alles fertig ist.
Ein häufiger und kostspieliger Fehler ist, beides zu verwechseln: ein reguliertes Produkt mit einer „schnell und billig"-Architektur zu starten — und es nach der ersten Prüfung neu bauen zu müssen.
Worauf es bei der Auswahl ankommt
Über die reine Fintech-Erfahrung hinaus sind es dieselben Engineering-Grundlagen, die ein Produkt prüfungsfest machen: Security-by-Design statt nachträglich angeklebter Sicherheit, ein belastbarer Audit-Trail, EU-Hosting mit dokumentierten Sub-Prozessoren, vertraglich geregelte Code-Ownership (das System gehört vertraglich Ihnen, nicht dem Dienstleister) und eine saubere Übergabe mit Dokumentation. Genau diese Punkte entscheiden später, ob eine Aufsichts- oder Due-Diligence-Frage in Stunden oder in Wochen beantwortet ist.
Zitierfähige Fakten
- DORA gilt seit dem 17.01.2025 für Finanzunternehmen in der EU.
- Meldefristen für schwerwiegende ICT-Vorfälle nach dem technischen Standard (RTS): Erstmeldung 4 h (nach Einstufung, spätestens 24 h nach Kenntnis), Zwischenbericht 72 h, Abschlussbericht 1 Monat. DSGVO im Vergleich: 72 h.
- Im November 2025 benannten die EU-Aufsichtsbehörden nach öffentlich verfügbaren Informationen erstmals kritische ICT-Drittdienstleister (u. a. große Cloud-Hyperscaler); bei schwerwiegenden Verstößen können Sanktionen von bis zu 1 % des durchschnittlichen weltweiten Tagesumsatzes verhängt werden.
- Der BaFin-Rahmen für Fintechs umfasst u. a. MaRisk, BAIT, GwG und DORA; die EU-Geldwäschebehörde AMLA hat ihren Sitz in Frankfurt; nach öffentlich verfügbaren Informationen sind 2026 weitere Vereinheitlichungen bei Verdachtsmeldungen an die FIU vorgesehen.
- Re-KYC-Intervalle richten sich nach dem risikobasierten Ansatz und den internen Vorgaben; bei erhöhtem Risiko in kürzeren Abständen.
(Stand Juni 2026. Keine Rechts- oder Aufsichtsberatung — regulatorische Details und Fristen ändern sich; vor Entscheidungen mit Rechts-/Compliance-Beratern prüfen.)
Sie bauen ein Fintech-Produkt und brauchen einen Engineering-Partner, der BaFin- und DORA-Kontext mitdenkt? H-Studio ist ein architecture-first Engineering-Studio in Berlin. Wir bauen die technischen Grundlagen — Audit-Trail, KYC/AML-fähiges Onboarding, technisch vorbereitetes Incident-Handling, EU-Hosting — so, dass regulatorische Anforderungen technisch unterstützt werden und Ihr Compliance-Team sowie Ihre Berater auf einer geeigneten technischen Grundlage arbeiten können, mit vertraglich geregelter Code-Ownership. Die regulatorische Beurteilung bleibt bei Ihren Rechts-/Compliance-Beratern; wir liefern das Engineering dazu. Erzählen Sie uns von Ihrem Fintech-Projekt.
Häufige Fragen
Braucht mein Fintech eine BaFin-Zulassung für ein MVP?
Das hängt davon ab, ob Sie eine erlaubnispflichtige Tätigkeit ausüben (z. B. Zahlungsdienst, E-Geld). Das ist eine Rechtsfrage für Ihre Compliance-/Rechtsberatung. Aus Engineering-Sicht zählt, dass die Architektur eine spätere Regulierung nicht ausschließt.
Was bedeutet DORA für die Architektur?
Vor allem zwei Dinge: Vorfälle müssen automatisch erkennbar, klassifizierbar und in engen Fristen (4 h / 72 h / 1 Monat) technisch für eine Meldung vorbereitet sein, und Ihre kritischen IT-Dienstleister müssen dokumentiert und idealerweise austauschbar gedacht sein.
Wer haftet für ICT-Risiken bei einem Dienstleister?
Die regulatorische Verantwortung bleibt grundsätzlich beim Finanzunternehmen — deshalb sind Dokumentation der Drittparteien (Register of Information) und ein belastbarer Audit-Trail so wichtig. Die Haftungsverteilung hängt vom jeweiligen Vertrag und den regulatorischen Vorgaben ab und ist eine Rechtsfrage.
Wie baut man einen KYC-Flow?
Als Teil des Onboardings: Identitätsprüfung aus zuverlässigen Quellen vor Aufnahme der Geschäftsbeziehung, Risikoeinstufung und eine Re-KYC-Logik, deren Intervalle sich nach dem individuellen Risiko richten. Die konkrete Ausgestaltung richtet sich nach GwG und den BaFin-Vorgaben.
Weiterführende Artikel
- NIS2 aus Engineering-Sicht: Was Software-Teams 2026 technisch vorbereiten sollten — die Engineering-Seite einer EU-Sicherheitsregulierung, eng verwandt mit dem DORA-Mindset
- Software bauen, die deutsche Compliance überlebt — warum „funktioniert heute" in Deutschland nicht reicht
- SaaS im B2B: Architektur, Skalierung und Compliance — wie Compliance-Anforderungen die Plattform-Architektur prägen
Wichtiger Hinweis
Dieser Artikel gibt eine technische, engineering-orientierte Einordnung von Themen rund um Fintech-Regulierung in Deutschland wieder, basierend auf öffentlich verfügbaren Quellen mit Stand Juni 2026. Er stellt keine Rechts- oder Aufsichtsberatung im Sinne des Rechtsdienstleistungsgesetzes dar, ersetzt nicht die individuelle rechtliche Bewertung Ihres konkreten Falls und begründet kein Mandatsverhältnis.
Für die Bewertung Ihrer Erlaubnispflicht, die Auslegung Ihrer Pflichten nach DORA, BaFin-Vorgaben und GwG sowie für die vertragliche Gestaltung mit Ihren Kunden, Bankpartnern und Aufsichtsbehörden wenden Sie sich bitte an auf Bank-/Aufsichtsrecht und Geldwäscheprävention spezialisierte Berater. Regulatorische Details und Fristen ändern sich; eine Haftung für Entscheidungen, die auf Grundlage dieses Artikels getroffen werden, ist ausgeschlossen.
Über H-Studio Berlin — Wir bauen Next.js-Websites und SaaS-Plattformen für B2B-Unternehmen, SaaS-Teams und Mittelstand in der DACH-Region. Architektur-first, mit Audit-Trail, EU-Hosting und vertraglich geregelter Code-Ownership. Mehr über uns.