Kredit-App-Entwicklung: Compliance, Store-Regeln und was es wirklich kostet

Warum Kredit-Apps anders sind

Kredit-Apps tragen regulatorische Haftung, die normale Verbraucher-Apps nicht haben. Beim Bau einer Zahlungs- oder Messaging-App ist die primäre Compliance-Oberfläche der Datenschutz. Beim Bau einer Kredit-App sind Sie auf einem regulierten Finanzmarkt tätig, mit Regeln darüber, an wen Sie Kredite vergeben dürfen, wie Sie Kreditwürdigkeit bewerten müssen, was Sie offenlegen müssen, wie Sie eintreiben können und wie Sie an Auskunfteien berichten müssen. Jede Funktionsentscheidung — wie Sie einen Hinweis formulieren, welche Daten Sie für das Underwriting erheben, ob Sie eine Push-Benachrichtigung an einen säumigen Kreditnehmer senden — hat eine rechtliche Implikation.

Kredit-Apps berühren gleichzeitig drei separate Compliance-Oberflächen: Finanzregulierung (Bankrecht, Verbraucherkreditrecht, Geldwäscheprävention), App-Store-Richtlinien (sowohl Google Play als auch der Apple App Store haben spezifische Regeln für Kreditanwendungen, die weit über die Standardkriterien hinausgehen) und Datenschutz (DSGVO in Europa, staatliche Datenschutzgesetze in den USA sowie sektorzentrale Regeln wie FCRA). Ein Fehler auf einer dieser drei Oberflächen kann zur Ablehnung Ihrer App in App-Stores, zur Aussetzung Ihrer Kreditgeberlizenz oder zu Behördenstraßen führen.

Deshalb sollten die meisten generalistischen Mobile-Studios keinen Kreditaufbau ohne ein Spezialistenteam versuchen. Die Lücke zwischen einem funktionierenden Prototyp und einem konformen Produktionsprodukt ist keine Frage von Wochen der Politur — es ist eine Frage von tief eingebetteten Engineering-Entscheidungen, die bestimmen, ob Ihr Produkt einer Regulierungsprüfung standhalt. Unsere Fintech-Praxis bei YuSMP Group wurde speziell für diese Produktkategorie aufgebaut.

Der Kredit-Lebenszyklus: 9 Phasen

Ein Kreditprodukt ist kein einzelnes Feature — es ist eine Pipeline aus neun verschiedenen Phasen, jede mit eigenen Compliance-Anforderungen, Datenverarbeitungsregeln und Engineering-Infrastruktur. Jede davon als Nachgedanken zu behandeln, schafft Schulden, die später unter laufender Regulierungsprüfung teuer zu beheben sind.

1. Akquisition — Marketing, Lead-Generierung und Kanal-Attribution. Regulatorische Implikation: EU-Gleichbehandlungsrecht und nationale Vorschriften verlangen, dass Marketing-Targeting keine geschützten Merkmale diskriminiert, auch nicht beim Einsatz algorithmischer Zielgruppenauswahl.
2. Antragstellung — Das Kreditnehmerformular, die Identitätserhebung und die Einwilligungserfassung. Jeder erhobene Datenpunkt muss einen offengelegten Zweck haben; die Einwilligung muss freiwillig, spezifisch und dokumentiert sein.
3. Prüfung — KYC (Know Your Customer), Einkommensprüfung und Open-Banking-Datenabruf. Hier leben die meisten Drittanbieter-Integrationen: Identitätsdokumentenscan, Liveness-Check, Bankkonto-Aggregation.
4. Underwriting — Das Kreditmodell, die Scoring-Engine und der Auskunftei-Abruf. In der EU regelt Artikel 22 der DSGVO automatisierte Entscheidungsfindung.
5. Genehmigung — Die Entscheidungsengine, die Generierung bedingter Angebote und die Handhabung abgelehnter Anträge. Abgelehnte Antragsteller müssen in vielen Jurisdiktionen Ablehnungsbenachrichtigungen mit Begründungscodes erhalten.
6. Auszahlung — Geldüberweisung, Buchungseintrag und Bestätigung. Der Zeitpunkt der Geldüberweisung im Verhältnis zur Offenlegung muss den anwendbaren Widerrufsrecht-Regeln entsprechen.
7. Servicing — Zahlungseinzug, Zahlungspläne, Kontoauszüge und Kundenservice. Dies ist die größte laufende Engineering-Oberfläche des Produkts.
8. Delinquency — Erkennung ausgefallener Zahlungen, Verwaltung von Schonfristten und Eskalationsworkflows gemäß FCA-Regeln für vulnerable Kunden (UK) oder nationalen Vorschriften (EU).
9. Berichterstattung — Meldungen an Auskunfteien, Regulierungsberichte und Pflege der Prüfpfade. Vollständige und zeitgenaue Meldungen sind in allen Jurisdiktionen verpflichtend.

Geschäftsmodelle

Bevor die erste Codezeile geschrieben wird, bestimmt das Geschäftsmodell das regulatorische Risiko, die benötigte Infrastruktur und den realistischen Go-to-Market-Zeitplan. Die fünf wichtigsten Modelle im Verbraucher- und KMU-Kreditgeschäft sind:

• Bilanzkreditgeber — Sie finanzieren Kredite mit eigenem Kapital oder Kreditlinien. Volle regulatorische Exposition: Sie benötigen eine Kreditgeberlizenz, müssen Kapitalanforderungen erfüllen und tragen das gesamte Kreditrisiko. Höchste Marge, höchste regulatorische Last.
• Marktplatz / Lead-Gen — Sie verbinden Kreditnehmer mit Kreditgebern. Geringere regulatorische Belastung (Sie benötigen typischerweise eine Kreditvermittlerlizenz statt einer vollständigen Kreditgeberlizenz), aber Erlöse sind Vermittlungsgebühren oder Umsatzbeteiligungen, keine Zinseinkünfte.
• Eingebettete Kreditvergabe — Kredit als Funktion innerhalb eines anderen Produkts, z. B. E-Commerce-Checkout-Finanzierung oder Betriebskapital innerhalb einer B2B-SaaS-Plattform. Der regulatorische Ansatz variiert: Wenn Sie mit einer Bank zusammenarbeiten, kann die Bank die Lizenz besitzen und Sie als deren Programmmanager agieren.
• BNPL (Buy Now Pay Later) — Kurzfristiger Ratenkauf am Point of Sale. Hohes Transaktionsvolumen, knappe Margen und spezifische Store-Regeln (Mindestlaufzeitanforderungen gelten). Die EU-Verbraucherkreditrichtlinie deckt BNPL nun ab; im Vereinigten Königreich werden formale Genehmigungsanforderungen erwartet.
• P2P (Peer-to-Peer) — Schwarm-finanzierte Kredite, bei denen Privatanleger Kreditnehmerdarlehen über Ihre Plattform finanzieren. Doppelseitige Marktplatzkomplexität: Sie müssen sowohl Anleger- als auch Kreditnehmer-Compliance verwalten. Nach den FCA-Verschärfungen 2019 meiden die meisten Neuzugänger dieses Modell für Verbraucherkredite.

Lizenzierungsanforderungen

Das Wichtigste über die Lizenzierung von Kredit-Apps ist die Reihenfolge: Sie benötigen eine Lizenz, bevor Sie live gehen, können aber mit dem Aufbau beginnen, während Sie den Antrag stellen. Lizenzanträge für Verbraucherkredite dauern je nach Jurisdiktion typischerweise 3 bis 12 Monate. Paralleles Bauen verhindert, dass sich Ihr Zeitplan verdoppelt.

In Deutschland ist die Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin) zuständig. Für Verbraucherkreditgeber ist eine Erlaubnis nach § 32 KWG erforderlich, wenn Sie als Kreditinstitut agieren, oder eine entsprechende Erlaubnis nach dem Zahlungsdiensteaufsichtsgesetz (ZAG) bei zahlungsdienstähnlichen Strukturen. Die Anforderungen umfassen Mindestkapital, geeignete Geschäftsführer und interne Kontrollsysteme.

In der EU insgesamt wird Verbraucherkredit durch die Verbraucherkreditrichtlinie (VKR, Richtlinie 2008/48/EG) geregelt, die durch die überarbeitete VKR2 (Richtlinie 2023/2225/EU) aktualisiert wurde und nun BNPL und digitale Kreditvergabe abdeckt. Die nationale Umsetzung variiert: Deutschlands BaFin, Frankreichs ACPR und die Regulatoren jedes Mitgliedstaates vergeben Lizenzen unabhängig. Ein Kreditinstituts-Pass aus einem EU-Mitgliedstaat ermöglicht den grenzüberschreitenden Betrieb, weshalb viele EU-Fintechs in Irland, Luxemburg oder Litauen sässig sind.

Im Vereinigten Königreich ist nach dem Brexit eine FCA-Genehmigung erforderlich. Zwei Wege existieren: direkte FCA-Genehmigung (volle Verbraucherkrediterlaubnis, typischerweise 12+ Monate, höhere Kapitalanforderungen) und das Appointed-Representative-Modell (AR), bei dem Sie unter dem Dach einer direkt genehmigten Firma operieren. Das AR-Modell bringt Sie schneller auf den Markt, gibt der Hauptfirma jedoch regulatorische Verantwortung für Ihre Tätigkeiten.

App-Store-Regeln

Sowohl Google Play als auch der Apple App Store haben spezifische Richtlinien für Kreditanwendungen, die weit über die Standardprüfkriterien hinausgehen. Die wichtigsten Regeln ab 2026:

• Mindestlaufzeiten — Google Play verlangt für Privatkreditanwendungen eine Mindestrückzahlungsfrist von 60 Tagen. Der Apple App Store verlangt für Verbraucherkreditanwendungen in den USA eine Mindestlaufzeit von 61 Tagen. Apps mit kürzeren Laufzeiten werden abgelehnt.
• Zinsobergrenzen — Beide Stores prüfen die offengelegten Kreditbedingungen und lehnen Apps ab, deren offengelegte Zinssätze die gesetzlichen Höchstgrenzen in Zielmärkten überschreiten. Ihre Offenlegungen müssen Ihre tatsächlichen Zinssätze vor der Einreichung korrekt widerspiegeln.
• Kreditgeberlizenz-Verifizierung — Beide Stores verlangen vor der Genehmigung einer Kreditanwendung den Nachweis einer Kreditgeberlizenz oder behördlichen Registrierung. Apps, die keine Lizenzdokumentation vorlegen können, werden nicht genehmigt.
• Verbot von Geräteberechtigungen — Dies ist die am häufigsten verletzte Regel durch Offshore-Entwicklungsteams und die mit den schwerwiegendsten Folgen. Sowohl Google Play als auch der Apple App Store verbieten Kreditanwendungen ausdrücklich den Zugriff auf: Gerätekontakte, Anruflisten, Fotos, Kamera, Dateispeicher, Standortdaten oder andere Gerätedaten für den Zweck der Kreditentscheidung oder der Inkasso-Durchsetzung. Apps, bei denen diese Berechtigungen für Kreditvergabezwecke festgestellt werden, erhalten eine automatische Ablehnung.

Das Verbot von Geräteberechtigungen verdient weitere Erläuterung, da einige Anbieter — insbesondere solche mit Erfahrung in Märkten, in denen diese Regeln weniger durchgesetzt werden — versuchen, den Zugriff auf Kontaktlisten oder Standortverfolgung als "Betrugsprävention" aufzunehmen. App-Store-Prüfer sind geschickt darin geworden, dieses Muster zu erkennen.

Unser Team für Mobile App-Entwicklung umfasst Engineers, die Kreditanwendungsprüfungen auf beiden Plattformen durchlaufen haben. Unsere iOS-Entwicklungs-Praxis berücksichtigt die App-Store-Prüfstrategie als Teil des Projekts, nicht als Nachgedanken.

Erklärbarkeit des Underwritings

Die regulatorischen Anforderungen an die Transparenz des Underwritings in der Kreditvergabe sind strenger als in fast jeder anderen Branche und schränken die Wahl der Modellarchitektur direkt ein. Dies ist kein Compliance-Zusatz — es muss von Anfang an in das System eingebaut sein.

In der EU gibt Artikel 22 der DSGVO Einzelpersonen das Recht, keiner auf ausschließlich automatischer Verarbeitung beruhenden Entscheidung unterworfen zu werden, die rechtliche oder ähnlich erhebliche Wirkung erzeugt, es sei denn, eine explizite Einwilligung wurde erteilt oder eine andere Rechtsgrundlage besteht. Wichtiger noch: Selbst wo automatisierte Entscheidungen zulässig sind, haben Personen das Recht, eine sinnvolle Erklärung zu erhalten und eine menschliche Überprüfung zu beantragen. Der praktische Standard, der durch Durchsetzungsentscheidungen etabliert wurde, ist, dass die Erklärung ausreichen muss, damit eine normale Person die Hauptfaktoren und ihre relative Bedeutung versteht.

Tests auf disparate Auswirkungen sind in der EU durch das Gleichbehandlungsrecht vorgeschrieben. Ihr Modell muss regelmäßig getestet werden, um sicherzustellen, dass es keine statistisch signifikant schlechteren Ergebnisse für Antragsteller in geschützten Gruppen produziert. Dies erfordert Audit-Infrastruktur, nicht nur einen einmaligen Test beim Launch.

Die praktische Implikation für die Modellauswahl ist erheblich. Baumbasierte Modelle — XGBoost, LightGBM, Random Forest — kombiniert mit SHAP-Werten (SHapley Additive exPlanations) sind der aktuelle Standard für konforme Underwriting-Systeme. SHAP liefert mathematisch fundierte Attribution des Beitrags jedes Features zu einer bestimmten Entscheidung, die in Begründungscodes für Ablehnungsbenachrichtigungen übersetzt werden kann. Tiefe neuronale Netze können für Hilfs-Scoring-Aufgaben verwendet werden, können aber typischerweise nicht als primäre Entscheidungsengine in einem regulierten Kreditkontext eingesetzt werden.

Die Speicherung von Entscheidungsaufzeichnungen ist in den meisten Jurisdiktionen Pflicht. EU-Aufzeichnungen erfordern typischerweise sechs bis sieben Jahre. Aufzeichnungen müssen nicht nur die Entscheidung, sondern auch die verwendeten Eingabedaten, die Modellversion und die generierten Begründungscodes enthalten.

Einkommens- und Identitätsprüfung

Die Einkommensprüfung ist der Teil des Antragsprozesses, der in den letzten fünf Jahren die größten Veränderungen erfahren hat, angetrieben durch Open-Banking-Regulierung in der EU (PSD2) und freiwilliges Infrastrukturwachstum. Der richtige Stack hängt von der Kreditnehmerpopulation ab, die Sie bedienen.

Open Banking (primärer Weg für die meisten Kreditgeber): Verbinden Sie das Bankkonto des Antragstellers über einen regulierten Open-Banking-Anbieter und rufen Sie 3 bis 12 Monate Transaktionsdaten ab. Der Transaktionsfeed wird dann auf Einkommensregeläßigkeit, Einkommenshöhe, wiederkehrende Verpflichtungen und Cashflow-Muster analysiert. In der EU und im Vereinigten Königreich sind Truelayer und Salt Edge die etablierten Optionen nach dem PSD2-Framework für Kontoinformationsdienstleister. Für PCI-DSS-konforme Entwicklung müssen Open-Banking-Integrationen sorgfältig konzipiert werden, um das Speichern roher Bankanmeldeinformationen zu vermeiden.

Gehaltsabrechnungsverbindungen: Argyle und Pinwheel verbinden direkt mit HR- und Gehaltsabrechnungssystemen (Workday, Paychex) und rufen verifizierte Beschäftigungs- und Gehaltsdaten ab. Dies ist für angestellte Kreditnehmer besser als die Open-Banking-Einkommensinferenz, da es autoritative Gehaltsdaten statt transaktionsbasierter Schätzungen liefert.

Dokumenten-Upload (Rückfall): Gehaltsabrechnungen, Kontoauszüge und Steuerbescheide sind der traditionelle Rückfall für Antragsteller, die kein Bankkonto verbinden wollen oder können, und für Selbstständige, deren Einkommen in Transaktionsdaten nicht klar hervorgeht. Die Dokumentenextraktion erfordert OCR mit Betrugserkennung, da Fälschung und Bildmanipulation häufige Angriffsvektoren sind.

KYC und Identitätsprüfung: Der Standardablauf ist ein Identitätsdokumentenscan (Reisepass, Führerschein, Personalausweis) kombiniert mit einem biometrischen Liveness-Check. Onfido, Veriff und Persona sind die führenden Anbieter. Alle drei unterstützen EU-eIDAS-konforme Verifizierung, wo erforderlich. AML-Datenbankscreening (PEP-Listen, Sanktionslisten) läuft parallel.

Servicing und Inkasso

Servicing ist die größte laufende Engineering-Oberfläche eines Kreditprodukts und der Teil, der bei der anfänglichen Scope-Schätzung am häufigsten unterschätzt wird. Die Auszahlung des ersten Kredits ist der Beginn der Engineering-Arbeit, nicht das Ende.

Zahlungsplanverwaltung: Feste und variable Zahlungspläne, Feiertagsbehandlung (Bankfeiertage, Wochenenden), Logik für fehlgeschlagene Zahlungswiederholungen, Zahlungsmethodenverwaltung (Karte, Lastschrift, SEPA) und Abstimmung mit Ihrer Bankpartnerschaft.

Kontoauszüge: Monatliche Auszüge im von Ihrer Jurisdiktion geforderten Format, Auszüge auf Anfrage für Kundenanfragen, Jahresabschluss-Zinszusammenfassungen. Formatanforderungen variieren je nach Jurisdiktion und Kreditgebertyp.

Delinquency-Management: Erkennung ausgefallener Zahlungen innerhalb des Zahlungsverarbeitungsfensters, Verwaltung von Schonfristten, Eskalationsworkflows, die Konten durch Stadien bewegen (1 – 30 Tage überfällig, 31 – 60 Tage, 61 – 90 Tage, 90+ Tage), und Übergabeprozesse an Inkassopartner, wo eingesetzt.

Inkassokommunikation: FCA-Regeln im Vereinigten Königreich über Rückstände und Ausfall-Management verlangen, dass Unternehmen vulnerable Kunden identifizieren und Stundungen anbieten, bevor sie eskalieren. Nationale Vorschriften in EU-Mitgliedstaaten variieren erheblich. Die Engineering-Implikation ist, dass Ihr Kommunikationssystem für jurisdiktionsspezifische Regeln konfigurierbar sein und alle Kontaktversuche für die Regulierungsprüfung protokollieren muss.

Meldung an Auskunfteien: Monatliche Datensätze an Schufa (Deutschland), Experian und andere Auskunfteien je nach Markt. Streitbehandlung (Verbraucherbeschwerden zu gemeldeten Informationen müssen innerhalb definierter Fristen untersucht und gelöst werden) erfordert einen separaten Workflow.

EU- und UK-Besonderheiten gegenüber den USA

Die Kreditregulierung in der EU und im Vereinigten Königreich ist in vielerlei Hinsicht vorschreibender als in den USA, was bestimmte Engineering-Anforderungen schafft, die Teams mit US-Hintergrund manchmal übersehen. Die obligatorische Kreditwürdigkeitsprüfung nach der EU-Verbraucherkreditrichtlinie ist anspruchsvoller als der US-Standard. EU-Kreditgeber müssen eine echte Beurteilung vornehmen, ob der Antragsteller den Kredit zurückzahlen kann, und müssen Anträge ablehnen, wenn sie Grund zur Annahme haben, dass der Kreditnehmer nicht zurückzahlen kann. Die Beurteilungsmethodik muss dokumentiert und vertretbar sein.

Im Vereinigten Königreich haben die beiden FCA-Wege zur Verbraucherkreditgenehmigung sehr unterschiedliche Anforderungen. Das Appointed-Representative-Modell (AR) ermöglicht einen schnelleren Markteintritt unter dem Dach einer Hauptfirma, erlegt jedoch erhebliche Einschränkungen auf: Die Hauptfirma muss Ihr Marketing, Ihre Produktbedingungen und Ihre Beschwerdebehandlung genehmigen und trägt regulatorische Verantwortung für Ihr Verhalten. Direkte FCA-Genehmigung gibt volle Unabhängigkeit, erfordert aber die Erfüllung der FCA-Zulassungsvoraussetzungen für Kapital, Kompetenz und Governance.

Artikel 22 der DSGVO in der EU geht weiter als das US-Äquivalent bei der Regulierung automatisierter Entscheidungen. Wo das US-Recht sich auf die nachträgliche Offenlegung von Begründungscodes konzentriert, verlangt die DSGVO, dass bevor eine automatisierte Entscheidung getroffen wird, die betroffene Person entweder eine explizite Einwilligung erteilt haben muss oder die Entscheidung für einen Vertrag notwendig sein muss. Zusätzlich hat die betroffene Person das Recht auf menschliche Überprüfung jeder automatisierten Entscheidung, die sie erheblich betrifft. Diesen menschlichen Überprüfungspfad in Ihren Entscheidungsworkflow einzubauen, ist eine harte Anforderung.

Der European Accessibility Act 2025 (EAA) verlangt, dass digitale Finanzdienstleistungen die WCAG-2.1-AA-Barrierefreiheitsstandards erfüllen. Diese Frist ist abgelaufen und die Durchsetzung ist aktiv. Wenn Sie eine Kredit-App für den EU-Markt entwickeln, sind Barrierefreiheitstests und -behebungen nicht optional. Dies umfasst Bildschirmleser-Kompatibilität, Tastaturnavigation, ausreichenden Farbkontrast und Textalternativen für alle Nicht-Text-Inhalte.

Entwicklungskostentabelle

Build-Phase	Typisches Budget	Zeitplan	Inhalte
MVP  —  Kern-Kreditprozess	90.000 – 160.000 USD	4 – 6 Monate	Antragstellung, KYC, grundlegendes Underwriting, Auszahlung, Zahlungseinzug
Produktion  —  volle Compliance	200.000 – 350.000 USD	7 – 10 Monate	Vollständiges Servicing-Modul, Delinquency-Management, Auskunftei-Meldung, Prüfpfade, erklärbares Underwriting
Multi-Produkt-Plattform	400.000 USD+	10+ Monate	Mehrere Kreditprodukte, White-Label-Kapazität, erweiterte Analytics, regulierungsbereites Berichtssystem

EU-Nearshore-Preise. US-Onshore kostet etwa das 2 – 2,5-Fache. Budget enthält individuelle Softwareentwicklung, Drittanbieter-Integrationen und QA.

Fragen an Ihren Anbieter

Beim Evaluieren eines Entwicklungspartners für ein Kreditprodukt trennen die folgenden Fragen Anbieter mit echter regulierter Fintech-Erfahrung von solchen, die angrenzende Produkte gebaut haben und ihre Kompetenz übertreiben:

• Haben Sie eine Kredit-App gebaut, die die App-Store-Prüfung mit Kreditkonditionen bestanden hat, und wie lang war Ihr Genehmigungszeitraum? Können Sie uns die Einreichungshistorie zeigen?
• Können Sie zeigen, wie Ihr Underwriting-Modul Begründungscodes für Ablehnungsbenachrichtigungen aus der Modellausgabe generiert?
• Wie behandeln Sie Artikel 22 der DSGVO in Ihrer Entscheidungsengine — insbesondere den menschlichen Überprüfungspfad?
• Welche Servicing-Infrastruktur stellen Sie nach dem Launch bereit, und wie ist das Delinquency-Management implementiert?
• Welche Open-Banking-Anbieter haben Sie integriert, und in welchen Märkten?
• Wie testen Sie auf disparate Auswirkungen in Kreditmodellen, und in welcher Häufigkeit?
• Was ist Ihr Ansatz zum Verbot von Geräteberechtigungen im App Store und Google Play, und können Sie uns Ihren KYC-Ablauf erklären?

Wenn ein Anbieter diese Fragen nicht spezifisch und detailliert beantworten kann, behandeln Sie das als Signal, dass er diese Antworten auf Ihre Kosten während des Projekts lernen wird.

Häufige Fragen

Was kostet die Entwicklung einer Kredit-App im Jahr 2026?

Ein Kredit-App-MVP für den Kernkreditprozess kostet 90.000 bis 160.000 US-Dollar und benötigt 4 bis 6 Monate. Ein produktionsreifer Build mit vollständiger Regulierungskonformität, Servicing-Modul, Delinquency-Management und Prüfpfaden kostet 200.000 bis 350.000 US-Dollar über 7 bis 10 Monate. Eine Multi-Produkt-Kreditplattform — Privatkredite, BNPL, Kreditlinie — startet bei 400.000 US-Dollar und dauert 10 oder mehr Monate. Dies sind EU-Nearshore-Preise; US-Onshore-Teams liegen etwa das 2 bis 2,5-Fache höher.

Warum werden Kredit-Apps im App Store abgelehnt?

Die häufigsten Ablehnungsgründe sind: Darlehenslaufzeiten kürzer als 61 Tage (Apple) oder 60 Tage (Google), fehlender Nachweis einer Kreditgeberlizenz, Zinssätze, die gegen lokale Wuchergesetze verstoßen, sowie die Anforderung von Geräteberechtigungen — Kontakte, Fotos, Anruflisten, Standort — die App-Stores für Kreditentscheidungen verbieten. Beide Plattformen haben ihre Richtlinien seit 2019 erheblich verschärft. Ablehnung ist nicht nur eine Verzögerung — wiederholte Verstöße können zur Sperrung des Entwicklerkontos führen.

Darf meine Kredit-App Kontakte oder Telefonspeicher-Berechtigungen anfordern?

Nein. Sowohl Google Play als auch der Apple App Store verbieten Kreditanwendungen ausdrücklich, auf Gerätekontakte, Fotos, Anruflisten, Kamera oder Standortdaten für Zwecke der Kreditwürdigkeitsprüfung oder des Inkassos zuzugreifen. Apps, die diese Berechtigungen für Kreditentscheidungen anfordern, werden abgelehnt. Einkommens- und Identitätsnachweis müssen über zugestimmte Open-Banking-Daten, Gehaltsabrechnungsverbindungen oder den Dokumenten-Upload erbracht werden — nicht über Gerätedaten.

Benötige ich eine Lizenz, bevor ich mit der Entwicklung der Kredit-App beginne?

Sie benötigen eine Kreditlizenz, bevor Sie live gehen, können aber mit dem Aufbau beginnen, während Sie den Antrag stellen. In Deutschland ist die BaFin zuständig. In der EU gilt die Verbraucherkreditrichtlinie; im Vereinigten Königreich ist eine FCA-Genehmigung erforderlich (Verbraucherkrediterlaubnis). Den App-Build vor der Lizenzbewilligung zu beginnen, ist üblich; ohne Lizenz zu launchen ist es nicht.

Kann ich KI für Kreditentscheidungen verwenden?

Ja, aber mit erheblichen Einschränkungen. In der EU verlangt Artikel 22 der DSGVO, dass automatisierte Entscheidungen mit rechtlicher oder ähnlich erheblicher Wirkung erklärbar und anfechtbar sind. Undurchsichtige Modelle, die keine menschenlesbaren Begründungscodes liefern können, werden die Regulierungsprüfung nicht bestehen. Erklärbarkeit ist keine optionale Funktion — es ist eine harte Anforderung.

Welche Einkommensprüfungsmethode sollte ich verwenden?

Open Banking ist die schnellste und genaueste Methode: Verbinden Sie das Bankkonto des Antragstellers über Truelayer oder Salt Edge (EU/UK) und rufen Sie 3 bis 12 Monate Transaktionsdaten ab. Gehaltsabrechnungsverbindungen — Argyle, Pinwheel — liefern Gehaltsdaten direkt aus HR-Systemen und sind für angestellte Kreditnehmer besser geeignet. Der Dokumenten-Upload (Gehaltsabrechnungen, Steuerbescheide) ist der Rückfallweg für Selbstständige. Verwenden Sie Open Banking als primären Weg und den Dokumenten-Upload als Rückfall.

Was passiert nach der Auszahlung — gibt es Post-Launch-Servicing-Arbeit?

Ja — Servicing ist die größte laufende Engineering-Oberfläche eines Kreditprodukts. Post-Auszahlungsarbeit umfasst: Zahlungsplanverwaltung, Kontoauszugserstellung, Delinquency-Erkennung und Eskalationsworkflows, Inkassokommunikation gemäß FCA-Regeln (UK) und nationalen Vorschriften (EU), Meldung an Auskunfteien und Regulierungsberichte. Die meisten Teams unterschätzen dies zu Beginn erheblich; planen Sie 1 bis 2 dedizierte Engineers für die Servicing-Infrastruktur nach Ihrer ersten Produktionskohorte ein.