The orchestration layer: unregulated, unavoidable, and on the critical path
Die Orchestrierungsschicht: unreguliert, unumgänglich und auf dem kritischen Pfad
Between a merchant and its payment providers there is now, increasingly, another company. It holds no funds, needs no payment licence in most constructions, and appears on no consumer’s statement. It also decides which provider each transaction is sent to, which means that when it stops working, the merchant stops taking money. European regulators have just begun naming vendors of this general kind as systemically important — and the criteria they used are the ones every merchant should be applying to its own.
What orchestration does
The commercial logic is sound and the problems it solves are real.
A merchant of any scale ends up with more than one payment provider: a primary acquirer, a secondary for redundancy, local providers in markets where domestic acceptance rates are materially better, alternative payment methods with their own integrations, plus fraud tools, tokenisation and reconciliation. Integrating each one separately produces a codebase in which the payment logic is spread across a dozen vendor SDKs and nobody can answer a question about the whole.
An orchestration layer collapses that into one integration. It routes each transaction to a provider according to configurable rules, retries a declined authorisation through a second provider, fails over when one goes down, normalises the reporting, and holds the tokens so that a change of provider does not mean asking every customer to re-enter a card. Merchants that adopt it generally report exactly what they were promised: fewer integrations, better resilience, and measurable improvement in authorisation rates.
The position it occupies
Now describe the same thing in terms of risk rather than benefit.
The orchestrator sits synchronously on the authorisation path. Every card transaction the merchant takes passes through it, in real time, with a customer waiting. Its availability is therefore a hard ceiling on the merchant’s ability to take payment — not a degradation, a stop.
In most constructions it is not a regulated payment institution, because it does not hold or transmit funds. It is a technology supplier. That is legally accurate and operationally beside the point: the regulatory perimeter was drawn around the movement of money, and this company does not move money. It merely determines whether money moves.
The result is a party with systemic importance to the merchant’s revenue, no prudential supervision, no capital requirement, no recovery and resolution planning, and — in the ordinary case — a contract whose liability cap is a multiple of monthly fees. That asymmetry between operational significance and contractual exposure is the defining feature of the layer, and it is not unique to orchestration: it describes a whole generation of infrastructure vendors.
What the regulators have started to do about it
The European Union’s digital operational resilience framework is the first serious attempt to close this gap, and its mechanism is worth understanding because it is unusual.
Rather than regulating each financial firm’s outsourcing separately, the framework allows supervisors to designate individual technology providers as critical, and to supervise them directly. In November 2025 the European Supervisory Authorities published the first such list: nineteen critical ICT third-party providers, comprising the large cloud platforms, data-centre operators, telecommunications providers and specialist financial technology firms. The list is to be updated annually.
The designation criteria are the genuinely useful part, because they are a general-purpose test for concentration risk. The supervisors assessed the potential systemic impact of a large-scale failure; the systemic importance of the financial entities relying on the provider; the concentration of reliance across sectors; and — the one that does the most work — the substitutability of the provider’s services.
That fourth criterion is the question a merchant should be asking about its own orchestrator, and it is not the same as “could we replace them”. Substitutability is about how quickly, at what cost, and whether the replacement can be executed under the conditions in which it would actually be needed — that is, during an outage, not during a planning cycle.
Three questions with uncomfortable answers
Who owns the tokens? The orchestrator holds the stored card credentials that make repeat purchases and subscriptions work. If those tokens are the orchestrator’s rather than the merchant’s, and are not portable to another provider, the merchant’s ability to leave is constrained by the thing it adopted the layer to avoid. The single most valuable clause in an orchestration contract is the one governing token portability on exit, and it is routinely not negotiated.
What is the routing actually optimising? Routing rules are presented as optimising authorisation rates. Authorisation rate is not the only variable an orchestrator can see, and not the only one it has an interest in. Some orchestrators have commercial arrangements with the providers they route to. A merchant should be able to see, per provider, the volume routed, the authorisation rate achieved and the total cost — and should verify that the routing it believes is happening is the routing that occurs. Where an orchestrator declines to expose that, the reason is worth pursuing.
What is the failure mode? An orchestrator’s own outage is the obvious case and usually the best-handled. The harder one is partial failure — elevated latency, or a routing decision that sends volume to a provider that is itself degraded. A merchant whose fallback is “route directly to the primary acquirer” should have tested that path recently enough to know it still works, because the integration that bypasses the orchestrator is the one nobody has exercised in two years.
The general shape
Orchestration is worth having. The criticism here is not of the product but of a mismatch that the product makes unusually visible.
The payment system’s regulatory architecture was built around institutions that hold customer money. That was the right place to draw the line when the risk in payments was overwhelmingly credit and custody risk. It is no longer where the operational risk concentrates. The parties whose failure would most reliably stop payments today are frequently parties that never touch funds — orchestrators, gateways, fraud engines, cloud regions, identity providers.
The designation of critical technology providers is the first structural acknowledgement that supervision has to follow dependency rather than custody. It is a narrow instrument, it covers a small number of very large firms, and most orchestrators are well outside it. But the criteria it introduced are portable, and a merchant can apply them without waiting for anyone: what happens if this vendor fails, how concentrated is our reliance, and how substitutable is it in the conditions where substitution would matter.
Most merchants have never asked the third question. It is the one that determines the answer to the first.
Zwischen einem Händler und seinen Zahlungsanbietern steht inzwischen immer häufiger noch ein Unternehmen. Es hält keine Gelder, braucht in den meisten Konstruktionen keine Zahlungslizenz und erscheint auf keinem Kontoauszug. Es entscheidet aber, an welchen Anbieter jede Transaktion geht — was bedeutet: Wenn es ausfällt, nimmt der Händler kein Geld mehr ein. Europäische Aufseher haben gerade begonnen, Anbieter dieser Art als systemisch bedeutsam zu benennen — und die Kriterien, die sie dafür verwendet haben, sollte jeder Händler auf seinen eigenen anwenden.
Was Orchestrierung leistet
Die wirtschaftliche Logik ist stimmig, und die Probleme, die sie löst, sind real.
Ein Händler jeder relevanten Größe endet mit mehr als einem Zahlungsanbieter: einem Haupt-Acquirer, einem zweiten für Redundanz, lokalen Anbietern in Märkten mit deutlich besseren Annahmequoten, alternativen Zahlarten mit eigenen Anbindungen, dazu Betrugswerkzeuge, Tokenisierung und Abstimmung. Jede davon einzeln anzubinden erzeugt eine Codebasis, in der die Zahlungslogik über ein Dutzend Anbieterbibliotheken verstreut liegt und niemand eine Frage über das Ganze beantworten kann.
Eine Orchestrierungsschicht faltet das auf eine Anbindung zusammen. Sie leitet jede Transaktion nach konfigurierbaren Regeln an einen Anbieter, wiederholt eine abgelehnte Autorisierung über einen zweiten, schaltet bei Ausfall um, vereinheitlicht das Berichtswesen und hält die Token, damit ein Anbieterwechsel nicht bedeutet, jeden Kunden um die erneute Eingabe seiner Karte zu bitten. Wer sie einführt, berichtet in der Regel genau das Versprochene: weniger Anbindungen, bessere Ausfallsicherheit, messbar bessere Autorisierungsquoten.
Die Position, die sie einnimmt
Nun dieselbe Sache in der Sprache des Risikos statt des Nutzens.
Der Orchestrator sitzt synchron auf dem Autorisierungspfad. Jede Kartentransaktion des Händlers läuft in Echtzeit durch ihn hindurch, mit einem wartenden Kunden. Seine Verfügbarkeit ist damit eine harte Obergrenze für die Fähigkeit des Händlers, Zahlungen anzunehmen — keine Verschlechterung, ein Stillstand.
In den meisten Konstruktionen ist er kein reguliertes Zahlungsinstitut, weil er keine Gelder hält oder weiterleitet. Er ist ein Technologielieferant. Das ist juristisch zutreffend und betrieblich nebensächlich: Der Aufsichtsrahmen wurde um die Bewegung von Geld gezogen, und dieses Unternehmen bewegt kein Geld. Es bestimmt lediglich, ob Geld sich bewegt.
Das Ergebnis ist eine Partei mit systemischer Bedeutung für den Umsatz des Händlers, ohne aufsichtsrechtliche Beaufsichtigung, ohne Eigenkapitalanforderung, ohne Sanierungs- und Abwicklungsplanung — und im Normalfall mit einem Vertrag, dessen Haftungsgrenze ein Vielfaches der Monatsentgelte beträgt. Diese Asymmetrie zwischen betrieblicher Bedeutung und vertraglicher Verantwortung ist das prägende Merkmal dieser Schicht, und sie ist nicht auf Orchestrierung beschränkt: Sie beschreibt eine ganze Generation von Infrastrukturanbietern.
Was die Aufsicht dagegen zu tun begonnen hat
Der Rahmen der Europäischen Union zur digitalen operationalen Resilienz ist der erste ernsthafte Versuch, diese Lücke zu schließen, und sein Mechanismus verdient Verständnis, weil er ungewöhnlich ist.
Statt das Auslagerungsverhalten jedes Finanzunternehmens einzeln zu regulieren, erlaubt der Rahmen den Aufsehern, einzelne Technologieanbieter als kritisch zu benennen und sie unmittelbar zu beaufsichtigen. Im November 2025 haben die Europäischen Aufsichtsbehörden die erste solche Liste veröffentlicht: neunzehn kritische IKT-Drittanbieter, darunter die großen Cloud-Plattformen, Rechenzentrumsbetreiber, Telekommunikationsanbieter und spezialisierte Finanztechnologieunternehmen. Die Liste soll jährlich fortgeschrieben werden.
Der wirklich nützliche Teil sind die Benennungskriterien, denn sie sind ein allgemein verwendbarer Test für Konzentrationsrisiko. Die Aufseher prüften die mögliche systemische Wirkung eines großflächigen Ausfalls; die systemische Bedeutung der abhängigen Finanzunternehmen; die Konzentration der Abhängigkeit über Sektoren hinweg; und — das Kriterium mit der meisten Arbeit — die Ersetzbarkeit der Dienste des Anbieters.
Dieses vierte Kriterium ist die Frage, die ein Händler seinem eigenen Orchestrator stellen sollte, und sie ist nicht dasselbe wie „könnten wir ihn austauschen”. Ersetzbarkeit fragt, wie schnell, zu welchen Kosten — und ob der Austausch unter den Bedingungen möglich wäre, unter denen er tatsächlich nötig würde: während eines Ausfalls, nicht während einer Planungsrunde.
Drei Fragen mit unbequemen Antworten
Wem gehören die Token? Der Orchestrator hält die gespeicherten Kartenreferenzen, die Wiederholungskäufe und Abonnements funktionieren lassen. Gehören diese Token dem Orchestrator statt dem Händler und sind sie nicht zu einem anderen Anbieter portierbar, ist die Fähigkeit des Händlers zu gehen genau durch das eingeschränkt, wogegen er die Schicht eingeführt hat. Die wertvollste Klausel eines Orchestrierungsvertrags ist die zur Token-Portabilität bei Beendigung — und sie wird regelmäßig nicht verhandelt.
Worauf optimiert die Leitung tatsächlich? Leitungsregeln werden als Optimierung der Autorisierungsquote dargestellt. Die Autorisierungsquote ist nicht die einzige Größe, die ein Orchestrator sieht, und nicht die einzige, an der er ein Interesse hat. Manche Orchestratoren haben geschäftliche Vereinbarungen mit den Anbietern, an die sie leiten. Ein Händler sollte je Anbieter das geleitete Volumen, die erzielte Autorisierungsquote und die Gesamtkosten sehen können — und sollte prüfen, ob die Leitung, die er annimmt, auch die Leitung ist, die stattfindet. Weigert sich ein Orchestrator, das offenzulegen, lohnt die Frage nach dem Grund.
Wie sieht der Ausfall aus? Der eigene Ausfall des Orchestrators ist der offensichtliche Fall und meist der bestbehandelte. Schwieriger ist der Teilausfall — erhöhte Latenz oder eine Leitungsentscheidung, die Volumen an einen Anbieter schickt, der selbst beeinträchtigt ist. Wer als Rückfallebene „direkt an den Haupt-Acquirer leiten” vorsieht, sollte diesen Pfad kürzlich genug getestet haben, um zu wissen, dass er noch funktioniert — denn die Anbindung, die den Orchestrator umgeht, ist die, die seit zwei Jahren niemand benutzt hat.
Die allgemeine Form
Orchestrierung lohnt sich. Die Kritik hier gilt nicht dem Produkt, sondern einem Missverhältnis, das das Produkt ungewöhnlich sichtbar macht.
Die Aufsichtsarchitektur des Zahlungssystems wurde um Institute herum gebaut, die Kundengelder halten. Das war die richtige Grenzziehung, solange das Risiko im Zahlungsverkehr ganz überwiegend Kredit- und Verwahrrisiko war. Dort konzentriert sich das operationelle Risiko heute nicht mehr. Die Parteien, deren Ausfall den Zahlungsverkehr heute am zuverlässigsten stoppen würde, sind häufig Parteien, die nie Gelder berühren — Orchestratoren, Gateways, Betrugsmaschinen, Cloud-Regionen, Identitätsanbieter.
Die Benennung kritischer Technologieanbieter ist das erste strukturelle Eingeständnis, dass Aufsicht der Abhängigkeit folgen muss statt der Verwahrung. Sie ist ein schmales Instrument, sie erfasst eine kleine Zahl sehr großer Unternehmen, und die meisten Orchestratoren liegen weit außerhalb. Aber die Kriterien, die sie eingeführt hat, sind übertragbar — und ein Händler kann sie anwenden, ohne auf irgendjemanden zu warten: Was passiert, wenn dieser Anbieter ausfällt, wie konzentriert ist unsere Abhängigkeit, und wie ersetzbar ist er unter den Bedingungen, unter denen Ersetzbarkeit zählen würde.
Die dritte Frage haben die meisten Händler nie gestellt. Sie ist diejenige, die die Antwort auf die erste bestimmt.
