Europa soll eigenständiger werden, auch im Zahlungsverkehr. An Ideen, Diskussionen, aber auch Taten mangelt es nicht: Wero, EUDI-Wallet, digitaler Euro … um nur einige zu nennen. Betrachten wir es als Rennen, so läge Wero momentan klar vorn und ist – im Gegensatz zum digitalen Euro – nicht mehr nur in aller Munde, sondern auch bereits in vielen digitalen Wallets und Banking-Apps in Europa zuhause. An dieser dynamischen Entwicklung sind auch wir maßgeblich beteiligt und möchten in diesem Artikel aus unserer praktischen Erfahrung als spezialisierte Beratung für Payment-Lösungen berichten.
Wero ist ein neuer europäischer Bezahldienst, der seit Juli 2024 schrittweise eingeführt und von der European Payments Initiative (EPI) betrieben wird. Er versteht sich als leistungsfähige europäische Alternative zu etablierten Diensten wie PayPal, Apple Pay oder Klarna und ermöglicht Echtzeit-Zahlungen direkt zwischen Bankkonten. Als moderne digitale Wallet erlaubt Wero das Senden und Empfangen von Geld in wenigen Sekunden – ohne IBAN, komfortabel über die Handynummer oder andere Alias-Dienste. Die Zahlungen erfolgen nahtlos über die Banking-App der teilnehmenden Banken oder über die eigenständige Wero-App.
Anfang 2023 erhielten wir den strategisch anspruchsvollen Auftrag, die Einführung von Wero für eine große deutsche Bankengruppe mit rund 350 angeschlossenen Banken bis Mitte des Folgejahres als Peer-to-Peer-Lösung (P2P) zu begleiten. Unsere konkrete Aufgabe bestand darin, die vollständige fachliche und technische Implementierung zu konzipieren, umzusetzen und organisatorisch tragfähig zu verankern.
Seit Herbst 2025 haben wir zwischenzeitlich auch die Bezahlung mit Wero im eCommerce technisch umgesetzt, so dass Wero nun auch im Online-Geschäft genutzt werden kann. Der nächste große Meilenstein soll gemäß aktueller Planung die Realisierung von Zahlungen an POS-Kassen noch im Jahr 2026 sein, um bald auch im stationären Handel über Wero kontaktlos zahlen zu können.
Die Stimmung rund um Wero war zu Beginn des Projekts – und insbesondere von außen betrachtet – eher verhalten. Skepsis, Kopfschütteln und die Frage „Braucht es das wirklich?“ waren allgegenwärtig. Schließlich gab es bereits etablierte Lösungen von Visa / Mastercard über Apple Pay / Google Pay bis hin zu PayPal und Co. Wer sollte da noch an Wero glauben?
Wir! Und mit uns einige große und kleinere Banken Europas.
Heute lässt sich sagen: Die Zahl der Unterstützer wächst kontinuierlich und Wero entwickelt sich Schritt für Schritt zu einer echten Erfolgsgeschichte. Dies allein mit Unabhängigkeitstendenzen auf geopolitischer Ebene zu erklären, wäre jedoch zu kurz gegriffen. Inzwischen haben zahlreiche namhafte Banken in Deutschland Wero erfolgreich eingeführt. Es spricht sich herum: Die Einführung von Wero – sofern gut aufgesetzt und gesteuert – ist mit überschaubarem Aufwand möglich und findet auch im Markt zunehmend Akzeptanz.
Doch was haben wir konkret auf unserem Projekt vorgefunden? Welche Herausforderungen ergaben sich daraus? Wie sind wir damit umgegangen und was war letztlich entscheidend dafür, dass das Projekt zu einem Erfolg wurde?
Von Beginn an war klar: Die Einführung von Wero würde kein klassisches IT-Integrationsprojekt werden. Wero wurde durch EPI auf der „grünen Wiese“ entwickelt – ohne gewachsene Altlasten, mit modernen Schnittstellen und einer konsequent agilen Produktentwicklung.
Die Einführung von Wero erfolgte somit nicht auf Basis eines stabilen Zielbilds, sondern unter dynamischen, sich fortlaufend verändernden Rahmenbedingungen durch EPI. Wero musste in die Systeme unseres Kunden integriert werden, während sich Produkt, technische Spezifikationen und organisatorische Verantwortlichkeiten parallel weiterentwickelten.
Banken hingegen betreiben Kernbanksysteme, die in der Regel über Jahrzehnte gewachsen sind. Diese Systeme sind hochintegriert, stabilitätskritisch und tief in regulatorische Anforderungen eingebettet. Änderungen erfordern daher eine sorgfältige, meist langfristige Planung, da selbst kleine Anpassungen spürbare Auswirkungen auf zahlreiche nachgelagerte Prozesse haben können.
Die wesentlichen Konsequenzen und Lösungsansätze lassen sich aus den folgenden zwei Herausforderungen ableiten:
Zwischen der Organisation und den Entwicklungsansätzen von EPI und unserem Kunden lagen strukturell und kulturell erhebliche Unterschiede. Die Organisation auf Kundenseite war – geprägt durch lange Historie, komplexe Aufgabenstrukturen und strenge regulatorische Anforderungen – klar hierarchisch ausgerichtet. Entwicklungsprojekte wurden konsequent im klassischen Wasserfall-Vorgehen und in stark formalisierten Prozessen umgesetzt.
EPI hingegen agierte als junges Unternehmen mit flachen Hierarchien und einer klar agilen Unternehmenskultur. Entsprechend wurde auch die Entwicklung von Wero vollständig agil organisiert und gesteuert.
Die zentrale Herausforderung bestand darin, diese zwei grundlegend unterschiedlichen Organisationslogiken und Projektmanagementmethoden so miteinander zu verzahnen, dass sie effizient und belastbar zusammenarbeiten konnten, ohne unnötige Reibungsverluste.
Die Entwicklungszyklen auf Kundenseite und bei EPI waren zeitlich faktisch nicht kompatibel. Während Wero von EPI in zweiwöchigen Sprints1 iterativ weiterentwickelt wurde und sich die Spezifikationen regelmäßig änderten, arbeitete unser Kunde mit langfristig geplanten, meist halbjährlichen Releases – ein in der Branche etabliertes Vorgehen.
Eine direkte Kopplung hätte release-technisch lediglich zu den beiden halbjährlichen Terminen des Kunden erfolgen können. Doch in diesem Zeitraum hätten sich durch die kontinuierlichen Sprint-Zyklen bei EPI die zugrunde liegenden fachlichen und technischen Annahmen bereits mehrfach geändert. Der Kunde hätte somit zwangsläufig auf veralteter Spezifikationsbasis entwickelt und ein halbes Jahr später einen nicht mehr aktuellen Stand ausgeliefert.
Die eigentliche Herausforderung bestand daher darin, diese strukturell unterschiedlichen Release-Logiken intelligent zu synchronisieren und praxistauglich kompatibel zu machen.
Auf der Kundenseite stand eine etablierte Bankstruktur mit klar definierten Verantwortlichkeiten, fest verankerten Entscheidungswegen und zwei planbaren Release-Zyklen pro Jahr. Dem gegenüber stand eine dynamisch wachsende Produktorganisation, die konsequent agil arbeitete und deren Spezifikationen sich während der laufenden Integration in der Regel im Zwei-Wochen-Rhythmus weiterentwickelten. Der Kunde benötigte belastbare Planungssicherheit, während sich das Zielsystem auf Seiten EPI parallel und kontinuierlich veränderte. Wie lässt sich unter solchen Voraussetzungen ein stabiles Integrationsprojekt realisieren?
Zunächst galt es, die methodische Inkompatibilität zwischen dem agilen Projektmanagement-Ansatz von EPI und dem klassischen Vorgehensmodell auf Kundenseite systematisch aufzulösen. Hierfür entwickelten wir ein maßgeschneidertes hybrides Projektmanagement-Vorgehen, das die grundsätzlichen Gegebenheiten auf beiden Seiten nicht veränderte, aber dennoch eine gemeinsame und effiziente Entwicklung ermöglichte:
Auch wenn eine vollständige Synchronisation im Zwei-Wochen-Rhythmus nicht realistisch war, überführten wir die seitens EPI geänderten fachlichen und technischen Spezifikationen in einem festen monatlichen Takt in die für den jeweiligen halbjährlichen Release-Zyklus relevanten Fachkonzepte des Kunden. Diese wurden strukturiert angepasst, erneut verabschiedet und dem Entwicklungsteam auf Bankenseite innerhalb des noch geöffneten Entwicklungsfensters bereitgestellt. Sobald die Entwicklungsphase eines Kernbank-Releases geschlossen war, flossen sämtliche weiteren Änderungen automatisch in das darauffolgende Halbjahres-Release ein. Auf diese Weise etablierten wir ein stabiles, durchgängiges Entwicklungsvorgehen, das Agilität und Planbarkeit belastbar miteinander verband.
Ein zentraler Erfolgsfaktor war die frühzeitige und konsequente Einbindung aller relevanten Beteiligten – beginnend bereits mit dem Kick-off des Projekts. Wir informierten, sensibilisierten und involvierten sämtliche Stakeholder durch gezielt aufgesetzte Kommunikations- und Entscheidungsformate, um Transparenz, Akzeptanz und Geschwindigkeit gleichermaßen sicherzustellen.
Auf Seite der Mitarbeitenden verlangte der hybride Ansatz – und die damit einhergehende deutlich höhere Volatilität in den fachlichen wie technischen Spezifikationen bis zur finalen Entwicklungsreife – ein hohes Maß an Anpassungsbereitschaft und Flexibilität. Zwar blieb der grundlegende Entwicklungsprozess unverändert, doch wurde unter Bedingungen gearbeitet, die von Unsicherheit geprägt waren. Die Spezifikationen durchliefen in jedem Release-Zyklus mehrere Iterationsschleifen oder basierten zunächst auf Annahmen, die erst im weiteren Projektverlauf schrittweise validiert und durch belastbare Fakten ersetzt werden konnten.
Hierfür etablierten wir ein aktives, strukturiertes Dependency-Management: Abhängigkeiten, die sich aus der Arbeit mit Annahmen ergaben, wurden konsequent dokumentiert, transparent gemacht und für alle Beteiligten nachvollziehbar aufbereitet. Diese wurden nicht nur verwaltet, sondern aktiv nachverfolgt, priorisiert und schrittweise reduziert – ein entscheidender Hebel zur Risikominimierung im laufenden Entwicklungsprozess.
Dieses Vorgehen erforderte von Beginn an die geschlossene Unterstützung aller Managementebenen. Dafür wurden sowohl ein hochkarätig besetzter Lenkungsausschuss als auch klare, handlungsfähige Entscheidungskompetenzen im mittleren Management etabliert. Alle Beteiligten mussten frühzeitig auf die Besonderheiten des Projekts vorbereitet und aktiv eingebunden werden. Um dies sicherzustellen, wurden regelmäßige Gremien- und Meetingformate geschaffen, die einen kontinuierlichen Informationsfluss ermöglichten. Die relevanten Entscheidungsträger waren dadurch jederzeit auf dem aktuellen Stand, konnten Rückfragen stellen und bei Bedarf unmittelbar steuernd eingreifen. Auf diese Weise gelang es, nicht nur zu Projektbeginn, sondern über den gesamten Verlauf hinweg die volle Rückendeckung des Managements zu sichern – und zugleich auf ein verlässliches Commitment der Mitarbeitenden zählen zu können.
Flankierend zu diesen Maßnahmen war es – gerade angesichts der besonderen Herausforderungen auf Entwickler‑ und Fachebene – von zentraler Bedeutung, die Kommunikation auch über Organisationsgrenzen hinweg neu auszurichten. Der direkte Austausch zwischen den Fachbereichen von EPI und den beteiligten Bankeinheiten sollte bewusst ohne unnötige Eskalations- oder Abstimmungsschleifen über das Management erfolgen. Dadurch ließen sich fachliche Informationen präzise, schnell und ohne Interpretationsverluste transportieren. Gleichzeitig sank der Koordinierungsaufwand im Projektmanagement spürbar. Besonders auf Entwicklerebene erwies sich dieser unmittelbare Dialog als ausgesprochen effizient und hilfreich.
Aufgrund der fundamental unterschiedlichen Entwicklungszyklen war es erforderlich, auch die technischen Entwicklungsebenen konsequent voneinander zu entkoppeln. Zusätzlich galt es, eine eventbasierte Architektur auf Seiten EPI mit einer serviceorientierten Kernbankschicht technisch sauber zu harmonisieren. Die strategische Lösung bestand in der Einführung einer technischen Abstraktionsebene zwischen Wero und dem Kernbanksystem.
Diese Integrationsschicht schuf eine hohe Flexibilität gegenüber dem EPI‑Zentralsystem und schirmte zugleich die stabilitätskritischen Bankfunktionen vor kurzfristigen Änderungen ab. Nachgelagerte Systeme wie Fraud‑Prüfung oder Zahlungsverkehrsprozesse wurden so weitgehend vor wiederkehrenden Anpassungen geschützt. Ziel war nicht, Veränderung zu vermeiden, sondern sie kontrolliert zu isolieren und gleichzeitig eine robuste Integrationsbasis zu etablieren. Entstanden ist damit weit mehr als eine Schnittstelle: Eine Entwicklungs‑ und zugleich Pufferarchitektur, die aktiv zur Risikoreduktion im Kernbanksystem beiträgt.
Die Abstraktionsebene erfüllte dabei mehrere zentrale Funktionen. Sie fungierte zunächst als Schutzschicht, die kernbanknahe Prozesse von Änderungen an Produktspezifikationen entkoppelt. Anpassungen an Schnittstellen, Datenformaten oder Prozesslogiken konnten innerhalb dieser Ebene umgesetzt werden – nicht nur zu den halbjährlichen Releases, sondern auch in den Zwischenphasen –, ohne tief in das Kernbanksystem eingreifen zu müssen. Dadurch blieb die Stabilität bestehender Zahlungsprozesse selbst während dynamischer Entwicklungsphasen gewahrt.
Gleichzeitig entwickelte sich die Abstraktionsebene zu einem zentralen Steuerungspunkt für die fachliche Orchestrierung der Zahlungsprozesse. Validierungen, Zustandslogiken und Transformationsregeln wurden hier gebündelt, sodass Änderungen konsistent verarbeitet und kontrolliert ausgerollt werden konnten. Die Ebene übernahm damit eine verbindende Rolle zwischen technischen, fachlichen und regulatorischen Anforderungen.
Die cognitivo AG verantwortete in Zusammenarbeit mit den Fachexperten auf Kundenseite das Design, die Steuerung und die Weiterentwicklung dieser Architektur. Entscheidungen zu Schnittstellen, Datenflüssen und Verantwortlichkeiten wurden nicht isoliert getroffen, sondern entlang einer übergreifenden Integrationsstrategie bewertet. Dadurch ließen sich Integrationsrisiken frühzeitig erkennen und Anpassungen kontrolliert umsetzen, noch bevor sie das Kernbanksystem erreichten.
Darüber hinaus bildete die Abstraktionsebene die Grundlage für die spätere Skalierbarkeit von Wero. Durch die konsequente Entkopplung von Produktlogik und Kernbanksystemen konnten neue Anforderungen, zusätzliche Teilnehmer oder erweiterte Zahlungsfunktionen integriert werden, ohne stabilitätskritische Systeme grundlegend verändern zu müssen.
Die Einführung von Wero war für unseren Kunden kein Integrationsprojekt von der Stange. Unterschiedlich gewachsene Organisationen, heterogene Systemlandschaften auf EPI‑ und Kundenseite sowie divergierende Methoden trafen aufeinander – und waren zunächst kaum miteinander vereinbar. Der Erfolg des Projekts beruhte maßgeblich auf fünf Faktoren, die sich als tragende Säulen erwiesen.
Der gewählte Projektansatz und das konsequente Vorgehen führten zu einer hohen Akzeptanz auf Management- und Mitarbeitendenebene. Die cognitivo AG leistete gemeinsam mit ihrem Technologie- und Implementierungspartner Critical Software einen wesentlichen Beitrag zur erfolgreichen Umsetzung eines der anspruchsvollsten Payment‑Programme der vergangenen Jahre. Gemeinsam mit unserem Kunden konnten wir daher unter anderem: