Seit dem 17. Januar 2025 gilt der Digital Operational Resilience Act (DORA) unmittelbar für über 22.000 regulierte Finanzunternehmen in der EU und verpflichtet sie, IKT-Drittdienstleister vor Vertragsabschluss einer dokumentierten Sorgfaltsprüfung zu unterziehen. Die BaFin beobachtet die Konzentrationsrisiken bei IKT-Auslagerungen im deutschen Finanzsektor aktiv und hat seit 2022 eine Auslagerungsdatenbank aufgebaut, um betroffene Unternehmen bei schwerwiegenden Vorfällen bei Dienstleistern frühzeitig zu warnen. Für ein deutsches Fintech, das eSIM-Konnektivität als App-Feature einbetten will, bedeutet das: Die Wahl des eSIM-API-Anbieters ist nicht nur eine technische Integrationsentscheidung, sondern auch eine regulatorische.

Ein eSIM-API-Anbieter, der in ein reguliertes Fintech-Produkt integriert wird, kann je nach Ausgestaltung als IKT-Drittdienstleister im Sinne von DORA gelten, insbesondere wenn Konnektivität eine kritische oder wichtige Funktion des Produkts unterstützt. Das ändert nichts an der technischen Integration selbst, aber es verändert, welche Fragen ein Fintech vor Vertragsabschluss stellen sollte.

Dieser Leitfaden erklärt die technische Architektur einer eSIM-API-Integration, was speziell für deutsche und EU-regulierte Fintechs bei der Anbieterauswahl relevant ist, und wie eine Sandbox-zu-Live-Integration realistisch abläuft.

Das eSIM Reseller Portal von Monty Mobile bietet eine vollständige REST-API neben dem gehosteten Portal, inklusive Sandbox-Zugang für die technische Evaluierung.

Technischer Kontext: Was eine eSIM-API für Fintechs bereitstellt

Eine eSIM-API stellt programmatischen Zugriff auf die Provisionierungsinfrastruktur bereit: Profilbestellung, Aktivierung, Gerätekompatibilitätsprüfung und Lebenszyklusverwaltung, als REST-Endpunkte statt als Bildschirmoberfläche. Die technische Grundlage bildet GSMA SGP.22, die Spezifikation für Remote SIM Provisioning bei Endkundengeräten. Für ein Fintech, das eSIM als eingebettetes Produktmerkmal anbietet, etwa Reisekonnektivität als Kartenvorteil oder App-Funktion, ist entscheidend, dass die gesamte Aktivierung innerhalb der eigenen App bleibt, ohne Weiterleitung zu einer fremden Oberfläche.

Ein Beispiel für eine Profilbestellung über die API:

Warum DORA die Anbieterauswahl beeinflusst, nicht nur die Integration

DORA verlangt von regulierten Finanzunternehmen ein dokumentiertes Register aller IKT-Auslagerungen, unabhängig davon, wie klein die einzelne Dienstleistung erscheint. Diese Pflicht betrifft nicht nur klassische Kern-IT wie Kernbankensysteme, sondern grundsätzlich jeden Drittanbieter, dessen Ausfall den Geschäftsbetrieb beeinträchtigen könnte. Ein eSIM-API-Anbieter, der als eingebettetes App-Feature läuft, fällt in vielen Fällen in diese Kategorie, insbesondere wenn Konnektivität Teil eines beworbenen Produktversprechens ist.

Das bedeutet praktisch: Ein Fintech sollte vom eSIM-API-Anbieter vor Vertragsabschluss dokumentierte Informationen zu Sub-Auslagerungen, Standort der Datenverarbeitung, Notfall- und Wiederherstellungsplänen und Kündigungsmodalitäten einfordern, nicht erst, wenn die interne Compliance-Abteilung danach fragt. Ein Anbieter, der diese Fragen nicht routinemäßig beantworten kann, hat die regulatorische Realität seiner Fintech-Kunden noch nicht in seinen Vertriebsprozess integriert.

Anwendungsfall: Reisekonnektivität als eingebettetes Kartenmerkmal

Digitale Banken und Neobroker mit reiseaffiner Zielgruppe bieten zunehmend eSIM-Datenpakete als Kartenvorteil oder Premium-Feature an, direkt in der Banking-App aktivierbar.

Native Aktivierung ohne Markenbruch

Die Aktivierung muss vollständig innerhalb der App laufen. Jede Weiterleitung zu einer externen Seite unterbricht die Nutzererfahrung und wirft aus Nutzersicht die Frage auf, warum eine Bank-App plötzlich zu einem fremden Anbieter wechselt.

Kopplung an bestehende Kontostruktur

Die eSIM-Aktivierung sollte an das bestehende Nutzerkonto gekoppelt sein, mit Abrechnung über die vorhandene Zahlungsinfrastruktur, statt eine separate Zahlungsmethode zu verlangen.

Anwendungsfall: IoT- und Machine-to-Machine-Konnektivität für Fintech-Hardware

Fintechs mit eigener Hardware, etwa Kartenterminals oder IoT-gestützte Zahlungsgeräte, benötigen eine andere Integrationsebene: Bulk-Provisionierung vieler Geräte gleichzeitig statt Einzelaktivierung pro Endnutzer.

Hier ist die Frage nach Sub-Auslagerung und Lieferkette besonders relevant, da eine Unterbrechung der Konnektivität bei Zahlungsterminals einen unmittelbaren operativen Ausfall bedeutet, nicht nur eine schlechtere Nutzererfahrung.

Praxisbeispiel: Sandbox-zu-Live-Integration bei einem europäischen Fintech

Ein europäisches Fintech mit 380.000 aktiven Nutzern wollte eSIM-Konnektivität als Reisefeature in seine bestehende App integrieren, ohne ein separates Produktteam aufzubauen.

Die Sandbox-Integration begann mit Authentifizierung und einem Test der Profilbestellung gegen die sechs wichtigsten Zielmärkte des Nutzerstamms, gefolgt von Webhook-Konfiguration für die Aktivierungsbestätigung. Das zweiköpfige Produktteam schloss die Backend-Integration innerhalb von drei Wochen ab.

In den ersten 45 Tagen nach Live-Schaltung aktivierten 2.800 Nutzer eine eSIM über die App, bei einer Provisionierungserfolgsquote von 95,8 Prozent.

Hinweis: Dies ist ein anonymisiertes Bereitstellungsszenario auf Basis typischer Implementierungsergebnisse. Konkrete Ergebnisse variieren je nach Umsetzung, Zielgruppe und Marktbedingungen.

Compliance-Anforderungen für eSIM-API-Integrationen bei deutschen Fintechs

Erste Schritte: eSIM-API-Integration für Fintechs

1. Regulatorische Vorbewertung. Vor der technischen Integration intern klären, ob das Feature eine DORA-relevante oder BaFin-anzeigepflichtige Auslagerung darstellt.

2. Sandbox-Zugang und Kern-Endpunkte. Gegen Profilbestellung, Aktivierung und Webhook-Bestätigung testen, inklusive gezielt ausgelöster Fehlerfälle.

3. Kopplung an bestehende Kontostruktur. Aktivierung und Abrechnung an das vorhandene Nutzerkonto koppeln, statt eine separate Zahlungsmethode einzuführen.

4. Live-Schaltung und Dokumentation. Vor Live-Gang die Auslagerungsdokumentation abschließen, nicht erst im Nachgang, wenn Compliance oder Revision nachfragt.

Kontaktieren Sie das Partnerteam von Monty Mobile für Sandbox-Zugang und eine technische Erstberatung.

Über den Autor

Daniel Dib ist Senior Brand Manager bei Monty Mobile, einem globalen Telekommunikationsanbieter mit über 25 Jahren MNO-Beziehungen in mehr als 120 Ländern. Er verantwortet die Go-to-Market-Strategie und Content-Produktion für die Produktlinien CPaaS, A2P Wholesale SMS und Travel eSIM.

Häufig gestellte Fragen

Gilt ein eSIM-API-Anbieter automatisch als IKT-Drittdienstleister unter DORA?

Das hängt von der konkreten Ausgestaltung ab. Wenn die eSIM-Konnektivität eine kritische oder wichtige Funktion des Fintech-Produkts unterstützt, etwa ein beworbenes Kernfeature, fällt sie eher in den Anwendungsbereich als eine untergeordnete Zusatzfunktion. Fintechs sollten diese Einordnung intern mit Compliance klären, nicht allein technisch entscheiden.

Muss die Integration bei der BaFin angezeigt werden?

Nur wesentliche Auslagerungen sind anzeigepflichtig. Ob eine eSIM-Integration als wesentlich gilt, hängt von Umfang, Kritikalität und Datenverarbeitung ab und sollte im Einzelfall geprüft werden, nicht pauschal angenommen oder ausgeschlossen werden.

Wie lange dauert eine typische eSIM-API-Integration für ein Fintech?

Die reine Backend-Integration, Profilbestellung, Aktivierung und Webhook-Handling, dauert bei einem Team mit API-Erfahrung typischerweise zwei bis vier Wochen, gefolgt von einer QA-Phase. Die regulatorische Vorbewertung sollte parallel und nicht erst danach beginnen.

Welche Daten verarbeitet eine eSIM-API-Integration, und was bedeutet das für die DSGVO?

Typischerweise Gerätekennung (EID), Aktivierungszeitstempel und Zielort- oder Tarifauswahl, die bei Verknüpfung mit einem identifizierbaren Nutzer unter die DSGVO fallen. Vor Live-Schaltung sollte eine Auftragsverarbeitungsvereinbarung mit dem Anbieter vorliegen.