Die Abgrenzung
Wo Regulatorik aufhört und Entwicklung anfängt.
In Finanzunternehmen bindet die Regulatorik einen großen Teil der Entwicklungskapazität. PSD2, MaRisk, DORA, KYC und Meldewesen erzeugen erheblichen Aufwand – aber sie geben den Lösungsweg vor. Eine Vorgabe umzusetzen belegt keine technische Unsicherheit, sondern das Gegenteil.
Förderfähig wird es dort, wo eine Zielgröße erst im Experiment geklärt werden konnte. Ein Scoring-Modell, dessen Trennschärfe mit verfügbaren Verfahren nicht erreichbar war. Eine Betrugserkennung, deren Falsch-Positiv-Rate bei geforderter Erkennungsquote offen war. Eine Verarbeitungsarchitektur, deren Durchsatz unter Lastspitzen nicht absehbar war.
Eine Zahl ist hier fast immer der Prüfstein. Wer Trennschärfe, Erkennungsrate, Falsch-Positiv-Quote, Latenz oder Durchsatz benennen kann und zeigt, dass der Zielwert mit etablierten Verfahren nicht erreichbar war, hat die Grundlage für einen belastbaren Antrag. Wer nur beschreibt, was das System leistet, hat sie nicht.
Auch hier gilt: bewusst abgrenzen. Anbindung von Kernbank- und Zahlungssystemen, Reporting, Datenmigration, Auditvorbereitung und Betrieb gehören zum Vorhaben, sind aber selten der förderfähige Kern. Ein Antrag, der den experimentellen Teil klar herausarbeitet, ist prüffähiger als einer, der die gesamte Plattformentwicklung einreicht.
Die drei Kriterien in Finanzprojekten
Neuheit
Kein verfügbares Produkt, kein etabliertes Verfahren erfüllt die Anforderung. Der Stand der Technik ist mit Kennwert oder Benchmark benannt.
Technische Unsicherheit
Ob Trennschärfe, Erkennungsrate oder Durchsatz erreichbar sind, steht vor dem Experiment nicht fest. Regulatorische Fristen zählen nicht.
Systematik
Hypothese, Experiment, Messung, Iteration – nachvollziehbar in Modellvalidierungen, Backtests und Lastmessungen.
Achtzehn Tätigkeiten
Was in Fintech-Projekten wie eingeordnet wird.
Die folgende Einordnung beschreibt typische Fälle. Maßgeblich ist immer das konkrete Vorhaben.
Tätigkeit
Befund
Worauf es ankommt
Nachweis
Entwicklung eines eigenen Scoring- oder Risikomodells, dessen Trennschärfe mit verfügbaren Verfahren nicht erreichbar war
Förderfähig
Etablierte Verfahren müssen nachweislich an der Zielgröße gescheitert sein
Modellvalidierung, Backtests, verworfene Ansätze
Entwicklung eines Betrugserkennungsverfahrens mit vorab unsicherer Erkennungs- und Falsch-Positiv-Quote
Förderfähig
Beide Zielgrößen müssen benannt und offen gewesen sein
Testdatensätze, Metrikverläufe, Schwellwertanalysen
Entwicklung einer Verarbeitungsarchitektur für Transaktionen unter fester Latenz- oder Durchsatzvorgabe
Förderfähig
Die Grenze muss benannt und technisch unsicher gewesen sein
Lastmessungen, Zielwert gegen Ist, Iterationsstände
Entwicklung eines Verfahrens zur Konsistenz und Ausfallsicherheit im Zahlungsverkehr
Förderfähig
Standardmuster müssen an einer konkreten Eigenschaft gescheitert sein
Fehlerinjektionstests, Konsistenzprotokolle
Entwicklung eines eigenen Verfahrens zur Identitäts- oder Dokumentenprüfung
Förderfähig
Erkennungsgüte unter realen Bedingungen muss offen gewesen sein
Testkorpora, Fehlerraten, Vergleichsmessungen
Modell- oder Architekturreihe, die nach Auswertung verworfen wurde
Förderfähig
Scheitern schadet nicht – entscheidend sind Systematik und Dokumentation
Versuchsplan, Metriken, Abbruchentscheidung
Entwicklung eines Prognose- oder Handelsalgorithmus
Einzelfall
Nur wenn eine messbare Zielgröße vorab nicht erreichbar war und systematisch erprobt wurde
Backtests, Out-of-Sample-Ergebnisse
Entwicklung eines Verfahrens für Erklärbarkeit oder Fairness von Kreditentscheidungen
Einzelfall
Kritisch bei Anwendung bekannter Bibliotheken, relevant bei neuartigen Anforderungen
Testdesign, Ergebnisse, Vergleichswerte
Entwicklung eigener Verfahren für Datenschutz und Anonymisierung
Einzelfall
Nur wenn etablierte Verfahren die Anforderung nachweislich nicht erfüllen
Verfahrensbeschreibung, Angriffs- und Qualitätstests
Entwicklung einer Blockchain- oder Distributed-Ledger-Anwendung
Einzelfall
Nur wenn Protokoll- oder Skalierungsfragen technisch ungelöst waren, nicht bei Nutzung bestehender Netze
Architekturvergleich, Durchsatzmessungen
Sicherheits- und Kryptoarchitektur für neue Anforderungen
Einzelfall
Kritisch bei Einsatz etablierter Bibliotheken, relevant bei ungelöster Bedrohungslage
Bedrohungsmodell, Prüfberichte, Entwurfsalternativen
Umsetzung regulatorischer Vorgaben wie PSD2, DORA, MaRisk oder Meldewesen
Nicht förderfähig
Vorgegebener Lösungsweg, keine technische Unsicherheit
—
Anbindung von Kernbanksystemen, Zahlungsdienstleistern und Marktdaten-Schnittstellen
Nicht förderfähig
Integration nach dokumentierter Spezifikation
—
Aufbau von Onboarding, Konto-, Depot- und Vertragsverwaltung
Nicht förderfähig
Etablierte Muster, technischer Erfolg von Beginn an absehbar
—
Erstellung von Reporting, Dashboards und aufsichtsrechtlichen Auswertungen
Nicht förderfähig
Auswertung vorhandener Daten ohne Erkenntnisgewinn
—
Parametrierung und Nachtraining bestehender Modelle ohne Verfahrensänderung
Nicht förderfähig
Wiederholung eines bekannten Ablaufs
—
Datenmigration, Systemablösung und Cloud-Umzug
Nicht förderfähig
Umsetzung im Rahmen bekannter Lösungswege
—
Betrieb, Monitoring, Support und Auditvorbereitung
Nicht förderfähig
Laufender Betrieb im Rahmen bekannter Lösungswege
—
Dieselbe Tätigkeit kann in einem Vorhaben förderfähig und in einem anderen Routine sein. Entscheidend ist nicht, was gemacht wurde, sondern ob zu Beginn offen war, ob es funktioniert.
Häufige Ablehnungsgründe
Woran Fintech-Anträge typischerweise scheitern.
Regulatorik als FuE eingereicht
Umsetzungsprojekte zu PSD2, DORA oder MaRisk binden große Kapazitäten, folgen aber einer Vorgabe. Die BSFZ liest daraus Pflichterfüllung, keine Forschung.
Keine messbare Zielgröße
Ohne Trennschärfe, Erkennungsrate oder Durchsatz mit Ausgangswert lässt sich technische Unsicherheit nicht belegen. Qualitative Aussagen über bessere Ergebnisse reichen nicht.
Stand der Technik nicht abgegrenzt
Es fehlt der Nachweis, dass verfügbare Verfahren oder Anbieterlösungen die Anforderung nicht erfüllen. Gerade bei Scoring und Betrugserkennung fällt das auf.
Plattformprojekt statt Entwicklungsvorhaben
Onboarding, Anbindungen, Reporting und Betrieb machen den größten Teil des Aufwands aus. Der experimentelle Teil muss getrennt ausgewiesen sein.
Dokumentation
Die Validierung ist der Nachweis.
Finanzunternehmen dokumentieren gründlich – nur meist für Aufsicht und Revision, nicht für die Forschungszulage. Modellvalidierungen, Backtests, Testdatensätze, Lastmessungen und Versionsverläufe enthalten trotzdem fast alles, was BSFZ und Finanzamt brauchen.
Was fehlt, ist die Verbindung zur Fragestellung. Aus den Unterlagen muss hervorgehen, welche Zielgröße unsicher war, was der Ausgangswert war, was das Experiment ergeben hat und warum ein Modell verworfen wurde. Verworfene Modelle sind dabei oft aussagekräftiger als das produktive.
Für rückwirkende Jahre gilt: Rekonstruktion ist möglich, aber sie braucht Anker in vorhandenen Artefakten und eine dokumentierte Methodik. Wo Regulatorik- und Entwicklungsstunden nie getrennt erfasst wurden, wird die Argumentation schnell dünn.
Was wir typischerweise auswerten
Modellvalidierungen und Backtests
Testdatensätze und Metrikverläufe
Lastmessungen und Architekturentscheidungen
Rollen, Stundensätze und Personalstammdaten
Rechenbeispiel
Was ein Fintech-Entwicklungsteam typischerweise erreicht.
Beispielrechnung zur Veranschaulichung. Der FuE-Anteil ergibt sich aus der konkreten Abgrenzung und der Zeiterfassung, nicht aus einer Pauschale. 42 % ist kein gesetzlicher Satz, sondern der rechnerische Effektivwert aus 35 % Fördersatz und dem Gemeinkostenzuschlag.
Branchenlogik allein reicht nicht.
GrantonomyOS
Die Einordnung ist der Anfang. Belastbar wird ein Antrag erst, wenn Projektstruktur, Stunden, Kosten und Dokumentation über Jahre zusammenpassen — und einer Prüfung standhalten.
Vorprüfung
Vorprüfung der Vorhaben gegen die drei Kriterien, bevor Aufwand entsteht.
Antrags-Copilot
Projektbeschreibungen für die BSFZ, aus euren technischen Artefakten hergeleitet.
Zeiterfassung
Stunden und Rollen nach GoBD-Grundsätzen, monatlich festgeschrieben.
Audit-Ready AI
Simulierte Prüfung vor der Einreichung: wo die Argumentation noch nicht trägt.
FAQ
Fragen zur Forschungszulage
bei Fintech und Finance.
Ist die Entwicklung einer Finanzplattform förderfähig?
Das Produkt als Ganzes nicht. Einzelne technische Vorhaben darin können es sein, etwa Modell-, Architektur- oder Verarbeitungsthemen, bei denen der Erfolg zu Beginn nicht absehbar war.