The vendor layer: whose software the banking system actually runs on
Die Anbieterschicht: Auf wessen Software das Bankensystem wirklich laeuft
Ask who runs the payments system and the answer names banks and card networks. Ask whose software they run it on, and the list is a great deal shorter than most people expect.
The layer nobody names
Between the bank and the card network sits a layer of specialist software: switching, authorisation, fraud scoring, settlement, reconciliation, dispute handling. Very few institutions build this themselves. They license it from a small group of vendors — ACI Worldwide, FIS, Fiserv, Finastra and a handful of others — whose products have been embedded in bank infrastructure for decades.
This is not a scandal. Payment switching is unglamorous, extremely demanding software with punishing uptime requirements, and it makes sense to buy rather than build. But it has a consequence worth naming: the operational behaviour of a large part of the retail payments system is determined by the configuration of a handful of commercial products.
Why concentration here matters more than elsewhere
Three reasons.
Correlated failure. When many institutions run the same platform, a defect or an outage does not stay local. Payments infrastructure has a low tolerance for downtime precisely because the alternative — cash, or nothing — is not available at scale any more.
Regulatory reach stops at the bank. Supervisors examine regulated institutions. The vendor is a supplier, addressed indirectly through outsourcing and operational-resilience rules — in the EU now substantially through DORA, which does extend oversight toward critical third-party ICT providers. That extension exists because the gap was real.
Change becomes vendor-paced. When a network introduces a new rule or a regulator a new requirement, the practical timetable is not set by the bank. It is set by when the vendor ships support and when the bank can schedule the upgrade. This is one of the quieter reasons that rules on paper take years to become rules in practice.
The upgrade problem
Core payment platforms are old, and that is a feature as much as a fault: code that has processed transactions correctly for twenty years has been tested more thoroughly than anything written last year. But it also means institutions run versions several releases behind current, because upgrading a payment switch is a project measured in quarters and carries the risk of breaking something that currently works.
The result is a system whose real capabilities lag its documented ones. When we report that a network rule is not being applied in practice, the explanation is sometimes indifference — and sometimes that the field required to apply it does not exist in the version the institution is running.
What this means for our reporting
It changes where to look. If a control is not working, the interesting question is often not “did the bank choose not to apply it” but “can the bank apply it at all with what it has deployed”. Those have different remedies, and conflating them produces reporting that blames the wrong party.
It also means the vendor layer deserves the same scrutiny as the institutions. A defect in a widely deployed fraud-scoring module affects more cardholders than a policy failure at a single mid-sized bank, and it receives a fraction of the attention because the vendor has no retail customers to complain publicly.
A note on fairness
None of the vendors named above is doing anything improper by existing, and the concentration described here is the ordinary outcome of a market where reliability compounds and switching costs are enormous. The point is not that anyone is at fault. It is that a critical dependency sitting outside the supervised perimeter should be visible, and at present it mostly is not.
We intend to report on it. Where we do, the vendors concerned will get the same right of reply as anyone else.
Sources: public company filings and product documentation of the named vendors; EU Digital Operational Resilience Act (DORA) provisions on critical ICT third-party service providers. This article describes market structure; it makes no allegation about any specific product or institution.
Fragt man, wer das Zahlungssystem betreibt, fallen Namen von Banken und Kartennetzwerken. Fragt man, auf wessen Software sie es betreiben, wird die Liste deutlich kürzer als erwartet.
Die Schicht, die niemand nennt
Zwischen Bank und Kartennetzwerk liegt eine Schicht spezialisierter Software: Vermittlung, Autorisierung, Betrugsbewertung, Abrechnung, Abstimmung, Streitfallbearbeitung. Kaum ein Institut baut das selbst. Man lizenziert es bei einer kleinen Gruppe von Anbietern — ACI Worldwide, FIS, Fiserv, Finastra und einer Handvoll weiterer —, deren Produkte seit Jahrzehnten in der Bankinfrastruktur stecken.
Das ist kein Skandal. Zahlungsvermittlung ist unspektakuläre, extrem anspruchsvolle Software mit gnadenlosen Verfügbarkeitsanforderungen, und Kaufen statt Bauen ist vernünftig. Eine Folge gehört aber benannt: Das Betriebsverhalten eines großen Teils des Massenzahlungsverkehrs hängt an der Konfiguration einiger weniger kommerzieller Produkte.
Warum Konzentration hier stärker wiegt
Drei Gründe.
Gleichlaufendes Versagen. Laufen viele Institute auf derselben Plattform, bleibt ein Fehler oder ein Ausfall nicht lokal. Zahlungsinfrastruktur verträgt Ausfallzeit besonders schlecht, weil die Alternative — Bargeld oder gar nichts — in der Breite nicht mehr verfügbar ist.
Die Aufsicht endet bei der Bank. Aufseher prüfen regulierte Institute. Der Anbieter ist Zulieferer und wird nur mittelbar erfasst, über Auslagerungs- und Resilienzregeln — in der EU inzwischen wesentlich über DORA, das die Aufsicht tatsächlich auf kritische IKT-Drittdienstleister ausdehnt. Diese Ausdehnung gibt es, weil die Lücke real war.
Das Tempo bestimmt der Anbieter. Führt ein Netzwerk eine neue Regel ein oder eine Behörde eine neue Pflicht, setzt nicht die Bank den praktischen Zeitplan. Ihn setzt, wann der Anbieter die Unterstützung ausliefert und wann die Bank das Upgrade einplanen kann. Das ist einer der stilleren Gründe, warum Regeln auf dem Papier Jahre brauchen, bis sie Regeln in der Praxis sind.
Das Upgrade-Problem
Kern-Zahlungsplattformen sind alt, und das ist ebenso Vorzug wie Mangel: Code, der zwanzig Jahre lang korrekt Transaktionen verarbeitet hat, ist gründlicher geprüft als alles, was letztes Jahr geschrieben wurde. Es heißt aber auch, dass Institute mehrere Versionen hinter dem aktuellen Stand betreiben, weil das Upgrade einer Zahlungsvermittlung ein Projekt über Quartale ist und riskiert, etwas zu zerbrechen, das gerade funktioniert.
Das Ergebnis ist ein System, dessen tatsächliche Fähigkeiten hinter seinen dokumentierten zurückbleiben. Wenn wir berichten, dass eine Netzwerkregel in der Praxis nicht angewandt wird, ist die Erklärung manchmal Gleichgültigkeit — und manchmal, dass das dafür nötige Feld in der eingesetzten Version gar nicht existiert.
Was das für unsere Arbeit bedeutet
Es verschiebt den Blick. Funktioniert eine Kontrolle nicht, lautet die interessante Frage oft nicht „hat die Bank sich dagegen entschieden”, sondern „kann die Bank sie mit dem Eingesetzten überhaupt anwenden”. Das verlangt unterschiedliche Abhilfen, und wer beides vermengt, beschuldigt den Falschen.
Es heißt auch, dass die Anbieterschicht dieselbe Prüfung verdient wie die Institute. Ein Fehler in einem weit verbreiteten Betrugsbewertungsmodul betrifft mehr Karteninhaber als ein Regelverstoß bei einer einzelnen mittelgroßen Bank — und bekommt einen Bruchteil der Aufmerksamkeit, weil der Anbieter keine Privatkunden hat, die sich öffentlich beschweren.
Eine Anmerkung zur Fairness
Keiner der genannten Anbieter tut durch seine bloße Existenz etwas Unrechtes, und die beschriebene Konzentration ist das gewöhnliche Ergebnis eines Marktes, in dem Zuverlässigkeit sich aufsummiert und Wechselkosten enorm sind. Es geht nicht darum, jemandem Schuld zuzuweisen. Es geht darum, dass eine kritische Abhängigkeit außerhalb des beaufsichtigten Bereichs sichtbar sein sollte — und das ist sie derzeit überwiegend nicht.
Wir haben vor, darüber zu berichten. Wo wir das tun, erhalten die betroffenen Anbieter dasselbe Recht auf Stellungnahme wie alle anderen.
Quellen: Geschäftsberichte und Produktunterlagen der genannten Anbieter; die Vorgaben des EU Digital Operational Resilience Act (DORA) zu kritischen IKT-Drittdienstleistern. Dieser Beitrag beschreibt Marktstruktur und erhebt keinen Vorwurf gegen ein bestimmtes Produkt oder Institut.