Solaris: „Open Banking war die Blaupause, Embedded Finance ist die Mutation“
Schwerpunkt: Tech Ökosysteme. . Millionen flossen in PSD2 Schnittstellen, verdient haben andere. Embedded Finance hat Open Banking technisch abgehängt: ein API Key statt wochenlanger Zertifizierung pro Bank. Die Bank liefert Lizenz und Bilanz und haftet für alles, auch unter DORA. Die Frage ist nicht, ob sie mitspielt, sondern zu welchem Preis. [speaker-prosody pitch=“high“]von Peter Hüftlein, Head of Product – Accounts, Solaris.[/speaker-prosody]. Technischer und strategischer Vergleich zwischen PSD2 Schnittstellen und proprietären Banking ähsa-Service APIs. Standardisierungsdefizite. Auslagerungsrisiken. Das Dilemma der Banken: Als im September 2019 die technischen Regulierungsstandards (RTS) zur starken Kundenauthentifizierung (SCA) unter der zweiten europäischen Zahlungsdiensterichtlinie (PSD2) vollständig anwendbar wurden, war die regulatorische Grundlage für Open Banking bereits seit Januar 2018 gelegt. Die Verpflichtung zur Bereitstellung von Access to Account Schnittstellen (XS2A) für Drittanbieter (TPPs) sollte den europäischen Bankensektor aufbrechen. In den Vorstandsetagen etablierter Institute dominierte die Sorge vor dem Verlust der Kundenschnittstelle. Es folgten millionenschwere Investitionen in regulatorisch erzwungene APIs.[speaker-prosody pitch=“medium“]XS2A: Rückblickend erwies sich diese Initiative für die meisten Banken als Ai Tieh Kostenfaktor ohne spürbaren Deckungsbeitrag. Viel Open. Wenig Banking.“[/speaker-prosody]Die Blaupause für den Daten-Austausch wurde geschaffen. Die tatsächliche kommerzielle Wertschöpfung fand jedoch andernorts statt. Embedded Finance ist die funktionale Mutation von Open Banking. Unkontrolliert. Adaptiv. Marktgetrieben. Während Open Banking primär auf einen passiven und stark reglementierten Datenlesezugriff und isolierte Zahlungsauslösungen beschränkt blieb, integriert Embedded Finance vollwertige Bilanz- und Transaktionsprodukte direkt in die Wertschöpfungsketten finanzfremder Bieh tu Bieh Plattformen. Von Konten und Firmenkreditkarten bis hin zu revolvierenden Kreditlinien. Der technologische Motor dieser Evolution sind nicht die starren PSD2 Schnittstellen der Hausbanken, sondern hochgradig modulare proprietäre Banking as a-Service APIs (Banking ähsa-Service APIs). [speaker-prosody pitch=“low“]Technischer Vergleich: Regulierte PSD2 vs. proprietäre Banking ähsa-Service Infrastruktur![/speaker-prosody]. . Die strukturellen Unterschiede zwischen den Ansätzen verdeutlichen, warum sich die Marktanteile zugunsten proprietärer Architekturen verschoben haben. Schnittstellen Architektur und Datenmodelle: PSD2 Schnittstellen basieren auf fragmentierten Implementierungen konkurrierender Spezifikationen. Die Berlin Group (NextGenPSD2) und STET in Frankreich und das UK Open Banking Framework haben jeweils eigene Standards etabliert. Mit unterschiedlichen Datenmodellen, Authentifizierungsflows und Consent Management Ansätzen. Allein in der EU existieren über 4.000 XS2A Schnittstellen, die trotz nominaler Standardisierung starke Implementierungsunterschiede aufweisen.[speaker-prosody pitch=“medium“]Aus Sicht vieler Integratoren blieb der reale Nutzen der Standardisierung hinter den Erwartungen zurück, was in vielen Unternehmen zu spürbarer Unzufriedenheit führte.“[/speaker-prosody]OAuth 2.0 mit eIDAS Zertifikaten bildet zwar das gemeinsame Authentifizierungsgerüst, doch die konkreten Redirect- und Decoupled Flows variieren je Institut erheblich. Proprietäre Banking ähsa-Service APIs setzen dagegen auf konsistente REST- oder GraphQL Architekturen mit einheitlichen Datenmodellen. Webhooks und ereignisgesteuerte Microservices ersetzen das Polling Paradigma der XS2A Welt. Die Integration in Enterprise Software (ERP Systeme und Procurement Plattformen und vertikale Software ähsa-Service) erfolgt über dokumentierte SDKs mit Sandbox Umgebungen, die produktionsnahe Testszenarien abbilden. Wo PSD2 Implementierungen oft wochenlange Zertifizierungsprozesse mit jedem einzelnen ASPSP erfordern, genügt bei Banking ähsa-Service Anbietern typischerweise ein einziger API Key. Im wahrsten Sinne ein Schlüsselerlebnis. Funktionsumfang und Prozesstiefe:Die PSD2 deckt im Kern lediglich bestehende Zahlungskonten und rudimentäre Umsatzdaten ab, wie AIS (Account Information Service) und PIS (Payment Initiation Service). Moderne Banking ähsa-Service- und Financial Platform APIs bilden hingegen vollständige Bankprozesse von Anfang bis Ende ab. Von automatisierten Käyh Why ßieh- und KYB Strecken (inklusive Video Ident, PEP/Sanktionsscreening und UBO Ermittlung), über die Realtime Kartenemission (Push Provisioning auf Apple/Google Wallets binnen Sekunden) bis hin zur dynamischen Bonitätsprüfung direkt am Point of Sale. Conversion und User Expiihriänces:PSD2 Prozesse leiten Nutzer fast immer zur externen Authentifizierung an ihre Hausbank weiter. Diese Redirect Flows erzeugen Kontextwechsel, die je nach Institut und Endgerät zu Abbruchraten von 30 bis 50 Prozent führen. Das digitale Äquivalent eines Bankschalterbesuchs, nur ohne kostenlosen Kaffee. Banking ähsa-Service ermöglicht dagegen eine unsichtbare und nätif Einbettung. Die Transaktion findet dort statt, wo der geschäftliche Kontext entsteht. Im ERP. Auf der Plattform. Im Checkout. [speaker-prosody pitch=“low“]Margendruck. Erlösmodelle. Auslagerungshaftung.![/speaker-prosody]. . Für Banken, die über Banking ähsa-Service APIs Finanzprodukte in Plattformen einbetten, ergibt sich ein differenziertes ökonomisches Bild, wenn sie zusätzlich API basierte Services anbieten. Verlust des Kundenzugangs und Margenerosion:Banken laufen Gefahr, zum reinen Risikoträger und Commodity Lieferanten degradiert zu werden. Während Plattformen und vertikale Software ähsa-Service Anbieter durch exzellente Schnittstellen die profitablen Kundenbeziehungen monetarisieren, verbleiben bei der Bank oft nur schmale Transaktionsmargen. Bei voller Bilanzbelastung. Die konkreten Revenue Modelle im Banking ähsa-Service Ökosystem unterscheiden sich dabei erheblich. Interchange Sharing bei Kartenprogrammen. Per Transaction Fees bei Zahlungsauslösungen. Wiederkehrende Software ähsa-Service Plattformgebühren für API Zugang und Infrastruktur. Oder Balance Sheet Rental, bei dem die Bilanz des lizenzgebenden Instituts gegen eine Risikoprämie genutzt wird. Bilanzvermietung, sozusagen Airbnb für Banklizenzen. Für die produzierende Bank stellt sich die zentrale Frage, welchen Anteil der Gesamtwertschöpfung sie in jedem dieser Modelle tatsächlich vereinnahmt und ob dieser Anteil das regulatorische Risiko rechtfertigt. Regulatorische Durchgriffshaftung und DORA:Im Software Engineering lässt sich die Infrastruktur leicht über SDKs einkaufen. Im Bankgeschäft lässt sich die regulatorische Verantwortung nicht outsourcen. Das lizenzgebende Institut ist voll haftbar für Geldwäsche Prävention (GwG) und Betrugserkennung und operationelle Resilienz. Wenn Banking ähsa-Service Partner oder technische Enabler Sorgfaltspflichten bei Käyh Why ßieh- oder Transaktionsprüfungen vernachlässigen, greift die Aufsicht unmittelbar bei der Bank durch. Diverse Sonderprüfungen und Maßnahmen der BaFin im europäischen Fintech Sektor haben das eindrücklich belegt. Verschärfend kommt seit Januar 2025 der Digital Operational Resilience Act (DORA) hinzu. Trotz der Einprägsamkeit des Namens setzt die Verordnung extrem hohe Maßstäbe an die operative Ai Tieh Resilienz und fordert Banken und andere Finanzdienstleister heraus. DORA etabliert verbindliche Anforderungen an das ICT Drittparteienrisikomanagement und die Überwachung kritischer IKT Dienstleister. Für Banking ähsa-Service Konstellationen ist das hochrelevant. Wenn der technische Enabler als kritischer Drittdienstleister eingestuft wird, unterliegt er einer direkten, aufsichtlichen Überwachung durch die ESAs. Die Bank muss detaillierte Register aller Vertragsbeziehungen führen und Exit Strategien vorhalten und regelmäßige Penetration Tests nachweisen. Das Banking ähsa-Service Modell wird dadurch nicht unmöglich. Aber die Governance Anforderungen steigen signifikant. Risiko im Banking ist eine Frage der Infrastruktur:Die Marktentwicklung der letzten Jahre hat gezeigt, dass das Banking ähsa-Service Modell fragil sein kann. Der Wirecard Kollaps und eine Serie von BaFin Sonderprüfungen bei Banking ähsa-Service Enablern sind allen noch im Gedächtnis. Das hat offengelegt, was passiert, wenn Compliance nicht im Kern der Architektur verankert ist, sondern als nachgelagerter Layer behandelt wird. Für die lizenzgebende Bank materialisiert sich das Risiko in jedem Fall. Reputationsschäden und aufsichtliche Maßnahmen und im Extremfall der Entzug der Lizenz treffen nicht den Distributor, sondern den Risikoträger. [speaker-prosody pitch=“low“]PSD3. PSR. FIDA. Die Zukunft der Plattform Banken.![/speaker-prosody]. . Die europäische Bankenaufsicht hat das Scheitern der PSD2 Standardisierung erkannt. Mit dem Entwurf zur PSD3 und der Zahlungsdiensteverordnung (PSR) und dem FIDA Framework (Financial Data Access) versucht die EU die Grundlagen für echtes Open Finance zu schaffen. Der regulierungstechnisch relevante Unterschied: Die Aufspaltung in PSD3 (Richtlinie mit nationaler Umsetzungspflicht) und PSR (Verordnung mit direkter Anwendbarkeit in allen Mitgliedstaaten) ist ein bewusster Schritt zur Vermeidung der Fragmentierung, die PSD2 so massiv geschwächt hat. Aufgrund von PSR müssen die EU Mitgliedstaaten einheitliche Regeln für Zahlungsdienste direkt und ohne Spielräume umsetzen. FIDA wiederum zielt auf standardisierte Datenzugänge jenseits des Zahlungsverkehrs wie Wertpapierdepots, Kreditverträge, Versicherungspolicen und Pensionsansprüche. Für die Architektur des europäischen Finanzmarktes ist die Lage jedoch eindeutig. Während der Gesetzgeber noch über technische Standards für FIDA berät, hat der Markt durch proprietäre Banking ähsa-Service Infrastrukturen längst Fakten geschaffen. Erfolgreiche Banken werden künftig eine von zwei Rollen einnehmen müssen. Entweder akzeptieren sie ihre Rolle als hochgradig automatisierte Produktfabrik, die Skaleneffekte über standardisierte API Kanäle erzielt und regulatorische Governance als Kernkompetenz begreift. Oder sie transformieren ihre eigenen Frontends zu Plattformen, die fremde Finanz- und Softwarebausteine modular integrieren. Das Standardisierungsdefizit von Embedded Finance wird letztlich nicht durch verspätete Regulierungsinitiativen gelöst werden, sondern durch den Markterfolg jener Akteure, die offene Plattformarchitekturen mit banktauglicher Compliance und lückenloser Auditierbarkeit verbinden. Denn die entscheidende Lektion aus der bisherigen Banking ähsa-Service Marktbereinigung lautet: technische Skalierbarkeit ohne regulatorische Substanz ist kein nachhaltiges Geschäftsmodell. Nicht für den Enabler. Nicht für die Bank. Ob diese Mutation am Ende gutartig oder bösartig ausfällt, entscheidet die Compliance DNA. [speaker-prosody pitch=“high“]Sie hörten einen Beitrag von “ Peter Hüftlein, Solaris/dk“[/speaker-prosody]
Sie finden diesen Artikel im Internet auf der Website: https://itfm.link/252163
Millionen flossen in PSD2-Schnittstellen, verdient haben andere. Embedded Finance hat Open Banking technisch abgehängt: ein API-Key statt wochenlanger Zertifizierung pro Bank. Die Bank liefert Lizenz und Bilanz und haftet für alles, auch unter DORA. Die Frage ist nicht, ob sie mitspielt, sondern zu welchem Preis.
von Peter Hüftlein, Head of Product – Accounts, Solaris
Technischer und strategischer Vergleich zwischen PSD2-Schnittstellen und proprietären BaaS-APIs. Standardisierungsdefizite. Auslagerungsrisiken. Das Dilemma der Banken: Als im September 2019 die technischen Regulierungsstandards (RTS) zur starken Kundenauthentifizierung (SCA) unter der zweiten europäischen Zahlungsdiensterichtlinie (PSD2) vollständig anwendbar wurden, war die regulatorische Grundlage für Open Banking bereits seit Januar 2018 gelegt.
Die Verpflichtung zur Bereitstellung von Access-to-Account-Schnittstellen (XS2A) für Drittanbieter (TPPs) sollte den europäischen Bankensektor aufbrechen. In den Vorstandsetagen etablierter Institute dominierte die Sorge vor dem Verlust der Kundenschnittstelle. Es folgten millionenschwere Investitionen in regulatorisch erzwungene APIs.
XS2A: Rückblickend erwies sich diese Initiative für die meisten Banken als IT-Kostenfaktor ohne spürbaren Deckungsbeitrag. Viel Open. Wenig Banking.“
Die Blaupause für den Datenaustausch wurde geschaffen. Die tatsächliche kommerzielle Wertschöpfung fand jedoch andernorts statt. Embedded Finance ist die funktionale Mutation von Open Banking. Unkontrolliert. Adaptiv. Marktgetrieben.
Während Open Banking primär auf einen passiven und stark reglementierten Datenlesezugriff und isolierte Zahlungsauslösungen beschränkt blieb, integriert Embedded Finance vollwertige Bilanz- und Transaktionsprodukte direkt in die Wertschöpfungsketten finanzfremder B2B-Plattformen. Von Konten und Firmenkreditkarten bis hin zu revolvierenden Kreditlinien. Der technologische Motor dieser Evolution sind nicht die starren PSD2-Schnittstellen der Hausbanken, sondern hochgradig modulare proprietäre Banking-as-a-Service-APIs (BaaS-APIs).
Technischer Vergleich: Regulierte PSD2 vs. proprietäre BaaS-Infrastruktur
Die strukturellen Unterschiede zwischen den Ansätzen verdeutlichen, warum sich die Marktanteile zugunsten proprietärer Architekturen verschoben haben.
Schnittstellen-Architektur und Datenmodelle: PSD2-Schnittstellen basieren auf fragmentierten Implementierungen konkurrierender Spezifikationen. Die Berlin Group (NextGenPSD2) und STET in Frankreich und das UK Open Banking Framework haben jeweils eigene Standards etabliert. Mit unterschiedlichen Datenmodellen, Authentifizierungsflows und Consent-Management-Ansätzen. Allein in der EU existieren über 4.000 XS2A-Schnittstellen, die trotz nominaler Standardisierung starke Implementierungsunterschiede aufweisen.
Aus Sicht vieler Integratoren blieb der reale Nutzen der Standardisierung hinter den Erwartungen zurück, was in vielen Unternehmen zu spürbarer Unzufriedenheit führte.“
OAuth 2.0 mit eIDAS-Zertifikaten bildet zwar das gemeinsame Authentifizierungsgerüst, doch die konkreten Redirect- und Decoupled-Flows variieren je Institut erheblich.
Autor Peter Hüftlein, Solaris
Peter Hüftlein startete seine Laufbahn im Finanzsektor bei der Fondsdepot Bank und wechselte anschließend zur Fidor Bank, später zu Fidor Solutions, wo er als Product Manager Payments & Accounts arbeitete. 2018 ging er als Product Lead Payments zu Mbanq. Seit 2020 verantwortet er bei Solaris (Webseite) die Produktentwicklung rund um Konten und Transaktionen, heute als Head of Product – Accounts.
Proprietäre BaaS-APIs setzen dagegen auf konsistente REST- oder GraphQL-Architekturen mit einheitlichen Datenmodellen. Webhooks und ereignisgesteuerte Microservices ersetzen das Polling-Paradigma der XS2A-Welt. Die Integration in Enterprise-Software (ERP-Systeme und Procurement-Plattformen und vertikale SaaS) erfolgt über dokumentierte SDKs mit Sandbox-Umgebungen, die produktionsnahe Testszenarien abbilden. Wo PSD2-Implementierungen oft wochenlange Zertifizierungsprozesse mit jedem einzelnen ASPSP erfordern, genügt bei BaaS-Anbietern typischerweise ein einziger API-Key. Im wahrsten Sinne ein Schlüsselerlebnis.
Funktionsumfang und Prozesstiefe: Die PSD2 deckt im Kern lediglich bestehende Zahlungskonten und rudimentäre Umsatzdaten ab, wie AIS (Account Information Service) und PIS (Payment Initiation Service). Moderne BaaS- und Financial-Platform-APIs bilden hingegen vollständige Bankprozesse von Anfang bis Ende ab. Von automatisierten KYC- und KYB-Strecken (inklusive Video-Ident, PEP/Sanktionsscreening und UBO-Ermittlung), über die Realtime-Kartenemission (Push Provisioning auf Apple/Google Wallets binnen Sekunden) bis hin zur dynamischen Bonitätsprüfung direkt am Point of Sale.
Conversion und User Experience: PSD2-Prozesse leiten Nutzer fast immer zur externen Authentifizierung an ihre Hausbank weiter. Diese Redirect-Flows erzeugen Kontextwechsel, die je nach Institut und Endgerät zu Abbruchraten von 30 bis 50 Prozent führen. Das digitale Äquivalent eines Bankschalterbesuchs, nur ohne kostenlosen Kaffee. BaaS ermöglicht dagegen eine unsichtbare und native Einbettung. Die Transaktion findet dort statt, wo der geschäftliche Kontext entsteht. Im ERP. Auf der Plattform. Im Checkout.
Margendruck. Erlösmodelle. Auslagerungshaftung.
Für Banken, die über BaaS-APIs Finanzprodukte in Plattformen einbetten, ergibt sich ein differenziertes ökonomisches Bild, wenn sie zusätzlich API-basierte Services anbieten.
Verlust des Kundenzugangs und Margenerosion: Banken laufen Gefahr, zum reinen Risikoträger und Commodity-Lieferanten degradiert zu werden. Während Plattformen und vertikale SaaS-Anbieter durch exzellente Schnittstellen die profitablen Kundenbeziehungen monetarisieren, verbleiben bei der Bank oft nur schmale Transaktionsmargen. Bei voller Bilanzbelastung. Die konkreten Revenue-Modelle im BaaS-Ökosystem unterscheiden sich dabei erheblich. Interchange-Sharing bei Kartenprogrammen. Per-Transaction-Fees bei Zahlungsauslösungen.
Wiederkehrende SaaS-Plattformgebühren für API-Zugang und Infrastruktur. Oder Balance-Sheet-Rental, bei dem die Bilanz des lizenzgebenden Instituts gegen eine Risikoprämie genutzt wird. Bilanzvermietung, sozusagen Airbnb für Banklizenzen. Für die produzierende Bank stellt sich die zentrale Frage, welchen Anteil der Gesamtwertschöpfung sie in jedem dieser Modelle tatsächlich vereinnahmt und ob dieser Anteil das regulatorische Risiko rechtfertigt.
Regulatorische Durchgriffshaftung und DORA: Im Software-Engineering lässt sich die Infrastruktur leicht über SDKs einkaufen. Im Bankgeschäft lässt sich die regulatorische Verantwortung nicht outsourcen. Das lizenzgebende Institut ist voll haftbar für Geldwäsche-Prävention (GwG) und Betrugserkennung und operationelle Resilienz. Wenn BaaS-Partner oder technische Enabler Sorgfaltspflichten bei KYC- oder Transaktionsprüfungen vernachlässigen, greift die Aufsicht unmittelbar bei der Bank durch. Diverse Sonderprüfungen und Maßnahmen der BaFin im europäischen Fintech-Sektor haben das eindrücklich belegt.
Verschärfend kommt seit Januar 2025 der Digital Operational Resilience Act (DORA) hinzu. Trotz der Einprägsamkeit des Namens setzt die Verordnung extrem hohe Maßstäbe an die operative IT-Resilienz und fordert Banken und andere Finanzdienstleister heraus. DORA etabliert verbindliche Anforderungen an das ICT-Drittparteienrisikomanagement und die Überwachung kritischer IKT-Dienstleister.
Für BaaS-Konstellationen ist das hochrelevant. Wenn der technische Enabler als kritischer Drittdienstleister eingestuft wird, unterliegt er einer direkten, aufsichtlichen Überwachung durch die ESAs. Die Bank muss detaillierte Register aller Vertragsbeziehungen führen und Exit-Strategien vorhalten und regelmäßige Penetration Tests nachweisen. Das BaaS-Modell wird dadurch nicht unmöglich. Aber die Governance-Anforderungen steigen signifikant.
Risiko im Banking ist eine Frage der Infrastruktur: Die Marktentwicklung der letzten Jahre hat gezeigt, dass das BaaS-Modell fragil sein kann. Der Wirecard-Kollaps und eine Serie von BaFin-Sonderprüfungen bei BaaS-Enablern sind allen noch im Gedächtnis. Das hat offengelegt, was passiert, wenn Compliance nicht im Kern der Architektur verankert ist, sondern als nachgelagerter Layer behandelt wird. Für die lizenzgebende Bank materialisiert sich das Risiko in jedem Fall. Reputationsschäden und aufsichtliche Maßnahmen und im Extremfall der Entzug der Lizenz treffen nicht den Distributor, sondern den Risikoträger.
PSD3. PSR. FIDA. Die Zukunft der Plattform-Banken.
Die europäische Bankenaufsicht hat das Scheitern der PSD2-Standardisierung erkannt. Mit dem Entwurf zur PSD3 und der Zahlungsdiensteverordnung (PSR) und dem FIDA-Framework (Financial Data Access) versucht die EU die Grundlagen für echtes Open Finance zu schaffen.
Der regulierungstechnisch relevante Unterschied: Die Aufspaltung in PSD3 (Richtlinie mit nationaler Umsetzungspflicht) und PSR (Verordnung mit direkter Anwendbarkeit in allen Mitgliedstaaten) ist ein bewusster Schritt zur Vermeidung der Fragmentierung, die PSD2 so massiv geschwächt hat. Aufgrund von PSR müssen die EU-Mitgliedstaaten einheitliche Regeln für Zahlungsdienste direkt und ohne Spielräume umsetzen. FIDA wiederum zielt auf standardisierte Datenzugänge jenseits des Zahlungsverkehrs wie Wertpapierdepots, Kreditverträge, Versicherungspolicen und Pensionsansprüche.
Für die Architektur des europäischen Finanzmarktes ist die Lage jedoch eindeutig. Während der Gesetzgeber noch über technische Standards für FIDA berät, hat der Markt durch proprietäre BaaS-Infrastrukturen längst Fakten geschaffen.
Erfolgreiche Banken werden künftig eine von zwei Rollen einnehmen müssen. Entweder akzeptieren sie ihre Rolle als hochgradig automatisierte Produktfabrik, die Skaleneffekte über standardisierte API-Kanäle erzielt und regulatorische Governance als Kernkompetenz begreift. Oder sie transformieren ihre eigenen Frontends zu Plattformen, die fremde Finanz- und Softwarebausteine modular integrieren.
Das Standardisierungsdefizit von Embedded Finance wird letztlich nicht durch verspätete Regulierungsinitiativen gelöst werden, sondern durch den Markterfolg jener Akteure, die offene Plattformarchitekturen mit banktauglicher Compliance und lückenloser Auditierbarkeit verbinden. Denn die entscheidende Lektion aus der bisherigen BaaS-Marktbereinigung lautet: technische Skalierbarkeit ohne regulatorische Substanz ist kein nachhaltiges Geschäftsmodell. Nicht für den Enabler. Nicht für die Bank. Ob diese Mutation am Ende gutartig oder bösartig ausfällt, entscheidet die Compliance-DNA. Peter Hüftlein, Solaris/dk
Sie finden diesen Artikel im Internet auf der Website: https://itfm.link/252163
Schreiben Sie einen Kommentar