Europäische Alternativen zu Plaid.

Plaid ist der Name, zu dem Entwickler greifen, wenn eine App mit einem Bankkonto sprechen soll, und in den USA hat es sich diese Position verdient. In Europa fällt die Rechnung gleich doppelt anders aus. Strukturell ist Plaid Inc. US-inkorporiert (San Francisco), was den konsolidierten Konzern unter US-CLOUD-Act-Zuständigkeit stellt, und Bankkontodaten (Salden, Transaktionshistorie, Kontoidentifikatoren) gehören zu den sensibelsten Kategorien, die ein Dritter verarbeiten kann. Praktisch hat Europa bereits eine regulierte Open-Banking-Schicht: PSD2 verpflichtet Banken, Konto- und Zahlungsschnittstellen bereitzustellen, und darauf aufbauend gibt es eine Reihe europäisch lizenzierter Anbieter.

Diese Seite ist kürzer als die meisten unserer Alternativen-Karten, weil die ehrliche europäische Antwort drei Anbieter sind, aufgeteilt nach Use Case statt gerankt. Wir haben jeden anhand der üblichen Fragen geprüft: Wem gehört das Unternehmen, wer reguliert es, was deckt es tatsächlich ab, und was bedeutet die Migration. Ein Befund vorab: Keiner der drei trägt eine vollständig saubere EU-Eigentumskette, und wir sagen das pro Anbieter, statt aufzurunden.

Die Namen sind GoCardless (UK, London; FCA-autorisiert, deckt Kontodaten über das frühere Nordigen plus Lastschrifteinzug ab; eine im Dezember 2025 angekündigte Mollie-Übernahme steht aus), Trustly (Schweden, Stockholm; das etablierte Account-to-Account-Zahlungsnetzwerk in über 33 Märkten, CLOUD-Act-Risiko: Erheblich) und Volt (UK, London; Echtzeit-A2A-Zahlungen über 2.500 angebundene Banken in 31 Territorien, CLOUD-Act-Risiko: Erheblich).

Was von Plaid mitkommt:

• PSD2-Kontodaten mit Nutzereinwilligung: Salden, Transaktionen, Kontodetails über GoCardless Bank Account Data.
• Banküberweisungs-Zahlungen im Checkout: Trustly und Volt lösen beide Account-to-Account-Zahlungen mit Echtzeit-Bestätigung aus, wo die empfangenden Schienen das unterstützen.
• Regulierte Abdeckung: Alle drei sind autorisierte europäische Zahlungs- bzw. E-Geld-Institute, Sie operieren also unter ihren Lizenzen, so wie heute unter denen von Plaid.
• Webhooks, Sandboxes, REST-APIs; gewöhnliche Integrationsoberflächen bei allen dreien.

Auf der Strecke bleibt:

• Die eine gebündelte API. Plaid verkauft Daten, Zahlungen, Identität und Risiko-Scoring hinter einem Vertrag; in Europa setzen Sie die Teile zusammen, typischerweise ein Datenanbieter plus ein Zahlungsanbieter.
• US-Bank-Abdeckung. Das ist Plaids Heimrevier, und das pragmatische Muster für transatlantische Produkte ist Plaid für US-Konten, ein europäischer Anbieter für EWR-/UK-Konten.
• Plaids Nebenprodukte (Identitätsverifikation, Kreditrisiko, Fraud-Tooling) landen bei separaten europäischen Anbietern, nicht bei einem der Anbieter auf dieser Seite.
• Etwas Long-Tail-Bank-Konnektivität: Die Abdeckungsqualität variiert bei jedem Anbieter, Plaid eingeschlossen, nach Land; testen Sie Ihre zwanzig wichtigsten Banken nach Nutzerzahl beim Zielanbieter, bevor Sie sich festlegen.

1. Teilen Sie Ihre Plaid-Nutzung in Daten und Zahlungen auf, bevor Sie irgendetwas wählen. Listen Sie, welche Plaid-Produkte Sie tatsächlich aufrufen (Transactions, Auth, Identity, Payment Initiation) und was jedes intern speist. Nur-Daten-Nutzer migrieren zu GoCardless Bank Account Data; Nur-Zahlungs-Nutzer vergleichen Trustly und Volt; gemischte Nutzer betreiben zwei Anbieter und sollten die Naht bewusst gestalten.
2. Testen Sie die Bank-Abdeckung gegen Ihre reale Nutzerbasis, nicht gegen die Prospektzahl. Ziehen Sie Ihre wichtigsten Banken nach verbundener Nutzerzahl aus Plaid und verifizieren Sie jede gegen die Live-Abdeckung des Zielanbieters in der Sandbox. Abdeckungslücken konzentrieren sich auf bestimmte Länder und kleine Banken; Sie wollen sie finden, bevor Ihre Nutzer es tun.
3. Planen Sie das Neu-Verknüpfen der Nutzer als Kampagne mit langem Tail. Bank-Einwilligungen übertragen sich nicht. Verdrahten Sie den Link-Flow des neuen Anbieters in Ihr Produkt, prompten Sie aktive Nutzer an natürlichen Momenten (Login, fehlgeschlagene Zahlung, Einwilligungsablauf) und akzeptieren Sie, dass ruhende Verbindungen erst migrieren, wenn der Nutzer das nächste Mal erscheint. Tracken Sie die Re-Link-Abschlussquote als Migrationsmetrik, nicht den API-Traffic.
4. Betreiben Sie beide Anbieter während des Re-Linking-Fensters. Lassen Sie Plaid bestehende Einwilligungen bedienen, während neue Verknüpfungen zum europäischen Anbieter gehen. Die Überlappung kostet für etwa ein Quartal Geld; die Alternative, Re-Links per Deadline zu erzwingen, verliert vor allem die Nutzer am Tail.
5. Bauen Sie die Daten-Normalisierung sorgfältig neu. Transaktionskategorisierung, Bereinigung von Händlernamen und Salden-Semantik unterscheiden sich zwischen Anbietern, und nachgelagerte Features (Budgetierung, Scoring, Abstimmung) erben die Unterschiede. Fahren Sie beide Feeds für eine Stichprobe einwilligender Nutzer nebeneinander und diffen Sie die Ausgaben, bevor Sie die Konsumenten umstellen.
6. Erneuern Sie bei der Gelegenheit Ihre Transferfolgenabschätzung. Bankdaten von einem US-inkorporierten Processor zu einem europäisch lizenzierten zu bewegen, verändert die Schrems-II-Analyse Ihres DSB wesentlich. Halten Sie die Verbesserung schriftlich fest; sie ist oft das interne Argument, das die Migration überhaupt finanziert.