Twint, eBill, Swift und Lightning-Netzwerk: Offene Standards im Zahlungsverkehr

Lightning baut aktuell auf uniken, zeitlich begrenzten Rechnungen auf. Mit BOLT 12, einer geplanten Erweiterung der Spezifikation, könnte ein Händler einen statischen QR-Code anzeigen oder ausdrucken, den die Applikation des Kunden nutzt, um einzelne Rechnungen zu empfangen und Zahlungen auszulösen. Hinter einem BOLT 12 Offer können sich komplexe wiederkehrende Rechnungen verbergen.

Zahler zu Client / Custodian

Im traditionellen Banking existieren verschiedene nationale Standards zur Kommunikation zwischen Kunde und Bank. Grössere Unternehmen nutzen oft File-basierte Anweisungen zur Ausführung von Zahlungen. Hierfür setzt sich das ISO 20022-Format pain.001 durch. Es hat jedoch je nach Region gewisse Spezifika. Privatkunden nutzen verschiedene proprietäre Kanäle: von E-Banking über Telefon-Order bis Filiale.

Für eine Zahlung über Lightning wird einzig eine Implementation wie LND oder CLN benötigt. Nach Verknüpfung mit einem aufgeladenen Account können Lighting-Zahlungen in einem Terminal programmiert werden. In diesem Fall sind Käufer und Client identisch und einen Custodian gibt es nicht.

Um Zahlungen zu vereinfachen werden Wallets – Apps für Smartphones oder Desktop – genutzt. Da die Rechnung als QR-Code dargestellt wird, greifen Wallets auf eingebaute Kameras zu. Die Interaktion zwischen Zahler und Client besteht demnach aus Abscannen und Bestätigung der Zahlung.

Sogenannte Custodial Wallets verwalten obendrein das Vermögen. Die Nutzererfahrung ist quasi identisch zu PayPal. Allerdings entsteht ein Prinzipal-Agent-Verhältnis analog zum traditionellen Banking bloss ohne Einlagensicherung.

Zwischen den Agenten des Käufers und des Verkäufers

ISO 20022 definiert die pacs-(payments clearing & settlement) Meldungen – pacs.008 wird für die Interbanken-Kommunikation genutzt. Analog zur User-Client-Interaktion existieren regional unterschiedliche Varianten und Versionen. Mit der SWIFT-Migration zu ISO 20022 wird eine global einheitliche Version Realität, die auch Use Cases wie Rückleitungen einfacher macht.

Insbesondere BOLT 4 spezifiziert die Kommunikation zwischen Knotenpunkten. Das sogenannte Onion Routing erhöht die Privatsphäre der Nutzer, da keine der zwischengeschalteten Nodes Zahler und Empfänger kennt, sondern nur die unmittelbar nächsten Parteien.

Jeder beteiligte Knoten subtrahiert gemäss der eigenen öffentlichen Konfiguration prozentuale oder fixe Beträge als Gebühren. Die Software des Zahlenden kennt diese vorab und sendet genau so viel, dass die geforderte Summe den Empfänger erreicht. Die Route ist optimiert auf geringe Gebühren und hohe Erfolgswahrscheinlichkeit.

Lightning ist wie das Internet ein Best Effort-Netzwerk, das heisst es gibt keine Garantie für eine erfolgreiche Übermittlung. Für das Internet wurden Protokolle entwickelt, um die Unzuverlässigkeit zu minimieren. Sie ist im alltäglichen Gebrauch nicht spürbar. Ähnliches existiert bei Lightning noch nicht. Zahlungen mit weniger gut vernetzten Knoten schlagen noch häufiger fehl.

Clearing & Settlement

Für Bankzahlungen werden verschiedene Clearing- und Settlement-Mechanismen genutzt. Bei nationalen Zahlungen werden meist von der Zentralbank betriebene (TIPS) oder beauftragte (SIC) Systeme genutzt. Diese Systeme werden künftig alle Realtime ablaufen (RTGS), um der globalen Bewegung hin zu Echtzeitzahlungen gerecht zu werden. Dies führt im gehebelten Bankensystem jedoch zu Liquiditätsrisiken in Extremszenarien (siehe FT). Internationale Transaktionen werden durch Banken gecleart, die an verschiedene nationale Clearing-Systemen angeschlossen sind (etwa eine Schweizer Bank mit SIC- und euroSIC-Zugang).

Lightning benötigt im Standardfall kein Clearing separat zum Zahlungsprozess. Alle Bilanzen aller Beteiligten (Zahler, Router, Empfänger) werden automatisch aktualisiert. Bei Disput oder Fehlern fungiert die Bitcoin-Blockchain als unparteiischer automatisierter Richter. Kanäle können via Blockchain-Transaktion final und unanfechtbar geschlossen werden.

Die relative Unabhängigkeit von der Blockchain ist kein Nachteil von Lightning, sondern das essentielle Feature einer Zahlungsverkehrsinfrastruktur. Für den Zahlungsverkehr werden skalierbare Lösungen benötigt, die unweigerlich hohe Datenmengen implizieren. Mit der Datenmenge wird eine Blockchain immer zentraler, da immer weniger Akteure die Ressourcen aufwenden können, die notwendig sind, um die Blockchain zu validieren. Dezentralität ist aber ein Grundbaustein einer verteilten Datenbank, ansonsten ist sie eben nicht verteilt. Viele Krypto-Projekte haben ihren Sales Pitch darauf ausgelegt, mehr Transaktionen prozessieren zu können als Bitcoin. Wenn jedoch Serverfarmen benötigt werden, um die Blockchain zu validieren, ist fraglich, warum Nutzer ihr mehr vertrauen sollten als traditionellen Clearing Systemen.

Lösungen wie Sharding, Rollups oder Batching lösen das Problem nur temporär, da die Blockchain prozentual zum Transaktionsvolumen beansprucht wird. Eine globale Infrastruktur für die Zukunft muss aber Grössenordnungen mehr Zahlungen prozessieren können als heutige Systeme, um Machine-to-Machine-Payments und Smart Contracts zu ermöglichen. Daher muss sie mehr oder minder unabhängig von der Blockgrösse der Blockchain sein.

Zahlungsbestätigungen und Advices

Privatkunden erhalten Zahlungsbestätigungen, Advices und Kontoauszüge proprietär von ihrer Bank. Manche aggregieren diese über mehrere Banken hinweg. Unternehmen nutzen regionale oder nationale Nachrichten-Protokolle wie pain.002 oder die camt-Formate für Zahlungsbestätigungen und Kontoinformationen. Multibanking ermöglicht Unternehmen ein effizientes Liquiditäts-Management und Treasury. Strukturierte Zahlungsinformationen ermöglichen die automatisierte Kategorisierung von Ein- und Ausgängen. End-to-End-IDs gewährleisten verlässliche Zuordnung von Positionen. Mit der globalen Verbreitung von ISO 20022 sind die Grundlagen gelegt, um Bankkunden mit diesen Vorzügen zu erfreuen.

Gegenwärtig bietet Lightning solche Dienstleistungen nicht standardmässig an. Sie liessen sich einfach implementieren, da Lightning Payloads variable Text-Felder enthalten. Es bedürfte eines Konsens über die Verwendung dieser Felder. Damit ist aufgrund des gegenwärtigen Fokus auf P2P und C2B erst einmal nicht zu rechnen.

Twint, eBill und Lightning

Welchen Einfluss hat nun die Standardisierung auf die verfügbaren Anwendungsfälle und die Bequemlichkeit der Nutzung? Um diese Frage zu beantworten, bietet sich ein Vergleich mit den modernen und standardisierten Schweizer Zahlungsverkehrslösungen an. So wird auch die Bewertung aus dem vorhergehenden Beitrag dieser Serie komplettiert. Während dort nur auf die zugrunde liegenden Protokolle fokussiert wurde, handelt es sich bei den Schweizer Lösungen um offene Systeme und gemeinsame Lösungen (im Kontrast zu den geschlossenen Systemen in Deutschland).

Twint

Twint kann einfach mit dem Bankkonto verknüpft werden. Eine Twint-Transaktion ist ein normaler Banktransfer, der gegenwärtig noch verzögert, künftig in Echtzeit gecleart wird. Betragsobergrenzen sind aufgrund der Geldwäscherei-Auflagen aber auch nach Eliminierung des Liquiditätsrisikos unausweichlich.

Twint startete mit P2P: via App können Zahlungen getätigt oder angefordert werden. Die Handy-Nummer aus dem Adressbuch fungiert als Alias. Aus ökonomischen Gründen ist es aber auf C2B angewiesen. Dies stellte das Unternehmen vor Probleme, da der POS in der Schweiz von Karten dominiert ist und Twint für Käufer dort keinen Mehrwert stiftet.

Das Unternehmen bedient daher Händler, die zu klein für Terminals und Verträge mit Worldline und Co. sind. Markthändler und Bauern legen statische QR-Codes aus, die mit der Twint-App abgescannt werden. Für variable Beträge offeriert Twint einen QR-Code, mit dem die Twint-App via Web-Interface eine spezifische Rechnung anfordern kann. Die Kosten für Händler orientieren sich an Kreditkarten-Preisen.

Der grosse Vorteil von Twint liegt im eCommerce. Statt der mühsamen Eingabe der Kartendaten genügt es, einen QR-Code mit der Twint-App abzuscannen. Twint ist ein Push-Payment-System und daher deutlich weniger aufwendig in der gesamten Abwicklung und Security. Die Kartenschemes müssen ihre Second-Best-Lösung Click-to-Pay erst noch ausrollen.

Twint benötigt eine Online-Verbindung sowohl des Zahlers und Empfängers. Das führt zu ärgerlichen Situationen, wie jeder merkt, der schon mal an einem Selecta-Automat in einem etwas schlechter vernetzten Ort zahlen wollte. Twint ist primär eine Schweizer Lösung. Das Bedürfnis nach europäischer Interoperabilität ist zwar erkannt, doch dazu müssen sich verschiedene nationale Player einigen (siehe EMPSA).

Wie lässt sich das mit Lightning vergleichen?

Das Onboarding auf Lightning ist im Vergleich aufwendig, weil neu, jedoch einfacher als ein neues Bankkonto. Custodial Wallets wie Wallet of Satoshi oder Händler-Lösungen wie Opennode reduzieren den Aufwand beträchtlich. Sie sind aber suboptimal, weil sie die Privatsphäre reduzieren und Gegenparteirisiken einführen. Betragsobergrenzen sind aktuell noch technologisch bedingt.

Wie Twint dringt Lightning aus P2P ins C2B vor. Dies vor allem im globalen Süden, wo keine effizienten Systeme existieren. In der Schweiz können Händler Lightning über den Acquirer Worldline akzeptieren. Dazu müssen sie aber eine dedizierte App herunterladen. Und für Käufer gibt es wenig Anreize, mit Lightning statt Schweizer Franken zu bezahlen.

Es eignet sich gut für Verkäufer, für die Acquiring-Lizenzen und Terminals zu hohe Initialkosten darstellen. Mit BTCpay-Server können individuelle Rechnungen über Web-Anfragen kreiert werden – analog zum Webservice von Twint, bloss ohne Acquiring-Gebühren und Intermediäre.

Lightning ist ein internet-natives Protokoll und kann daher einfach in jede App (siehe Twitter), jede Seite (siehe Shopify) und jeden Browser (siehe Alby) integriert werden. Im eCommerce ist Lightning ähnlich bequem wie Twint.

Als Protokoll für Peer-to-Peer-Netzwerke, kann es mehrere lokale Lightning-Netzwerke geben, die ohne Internet auskommen. Mesh-Netzwerke erhöhen die Resilienz gegen Internet-Probleme. Diese Alternativen sind in Krisenregionen wie aktuell der Ukraine hilfreich. Ansonsten ist jedoch eine Internet-Verbindung auf Seite des Käufers nötig. Für Non-Custodial Wallets stellt dies ein Problem dar, weil die privat betriebene Node regelmässig online sein muss, um mit dem Netzwerk synchronisiert zu werden.

Lösungen wie LNURLPoS ermöglichen Offline-Terminals. Dies ist umso interessanter, weil Lightning-Zahlungen irreversibel und final sind. Dies im Gegensatz zu Karten. Dort werden beim Einsatz stets eine Autorisierung der Bank (offline nicht möglich) oder Offline-Limiten (riskant) benötigt. In Krisensituationen, in denen ein Geschäft nur zu Randzeiten Strom hat, eignet sich Lightning sehr gut.

QR-Rechnung und eBill

Wird Twint vor allem im P2P und C2B eingesetzt, ist die QR-Rechnung ein allgemeiner Standard im hybriden (= digitalen und gleichzeitig analogen) Format. Zur Begleichung der Rechnung kann diese von jeder Banking App abgescannt werden. Die Daten können aber auch über ein GUI oder via pain.001-Zahlungsanweisung übermittelt werden. Der Überweisungsbetrag kann nach dem Abscannen noch mutiert werden. Rechnungen ohne Betrag (für Spenden) sind möglich.

Die QR-Rechnung kann postalisch, via e-Mail oder über das neue eBill-Portal direkt ins E-Banking des Zahlers gesendet werden. Die letzte Option stellt eine End-to-End digitale Rechnungsverarbeitung sicher. Dafür muss sich der Zahler im eBill-Portal registrieren. Die Rechnung wird dann direkt im E-Banking ausgelöst und archiviert. Für wiederkehrende Rechnungen kann eine Dauerfreigabe eingestellt werden.

Die Dauerfreigabe von wiederkehrenden eBill-Rechnungen soll perspektivisch die Lastschrift für Privatpersonen ablösen. Dies ist sehr sinnvoll, da es sich stets um (Push-)Bankzahlungen handelt: Will eine Kundin oder ein Kunde nicht mehr zahlen, kann die Freigabe einfach aufgehoben werden.

Dasselbe gilt für Lightning. Auch hier kann eine Dauerfreigabe mit Betragsgrenzen eingerichtet werden. Die Browser-Extension Alby bietet dieses Feature an, um eine automatisierte Bezahlung auf einer Webseite zu ermöglichen. Mit BOLT 12 könnten Rechnung analog QR-Rechnung postalisch versendet werden. Viel interessanter ist jedoch, dass über eine einzige Freigabe wiederkehrende Zahlungen ausgelöst, aber jederzeit gestoppt werden können.

Schlussfolgerungen und Prognosen

Lightning bietet eine völlig neue Architektur ohne historischen Ballast. In Bezug auf Standardisierung schlägt es das traditionelle Banking. Die global einheitliche, umfassende und einfache Spezifikation steht in Kontrast zu den historisch gewachsenen Standards im Bankensystem. Lightning ist Global by Default, der traditionelle Zahlungsverkehr ist Global by Extension. Zum Teil ist das durch nationale Regulierung begründet, die es in Lightning nicht gibt.

Obwohl viel jünger und mit viel weniger Kapital gefördert, bietet Lightning dieselbe effiziente und moderne Zahlungserfahrung wie der vorbildliche Schweizer Markt. Die besprochenen Anwendungsfälle von eBill, QR-Rechnung und Twint würden sich mit Lightning ähnlich anfühlen – zumindest nach etwas mehr Innovation wie durch BOLT 12. Und darüber hinaus können zahlreiche neue Anwendungsfälle realisiert werden. Und das alles in einer App, in einer Lösung. Zudem ist Lightning nicht an ein "Token" gebunden. So kann zum Beispiel eine Prepaid-Karte aufgeladen und für Offline-Payments genutzt werden (siehe diese kleine Demo).

Daraus leite ich folgende Prognosen ab:

• Die Bankenwelt erlebt, ausgelöst durch die Konkurrenz aus Big Tech und Krypto, einen erfreulichen Homogenisierungs- und Standardisierungsschub. Initiativen wie SWIFT MX, globale ISO 20022-Adoption, Instant Payments und modernere Clearing-Systeme sollen die Zukunft sichern. Doch die fehlende Standardisierung über die ganze Zahlungskette hinweg hat unweigerlich einen negativen Einfluss auf die Nutzererfahrung.
• Viele Anwendungsfälle über das reine Payment hinaus – etwa Rückleitung, Vorfinanzierung, Zug-um-Zug Geschäft – werden im heutigen Zahlungsverkehr nur über proprietäre Lösungen abgedeckt und benötigen manuelle Schritte. Sie liessen sich über eine Infrastruktur wie Lightning viel einfacher und mindestens teilautomatisiert abwickeln.
• Quasi alle klassischen Infrastrukturen sind primär national und expandieren erst sekundär ins Ausland (so auch Twint und eBill). Standards müssen abgestimmt, Regulatorik adressiert und der Market Fit bewertet werden. Im Gegensatz dazu ist Lightning global per Default. Erst in zweiter Instanz sind spezielle Protokoll-Erweiterungen für partikulare Anwendungen oder Regionen denkbar.
• QR-Rechnung, eBill und Twint sind relativ effiziente Lösungen: die Banken- und Interbanken-Infrastruktur der Schweiz ist modern und der Wertetransfer geschieht relativ direkt ohne allzu viele Mittelsmänner. Allerdings könnte auch das Schweizer System rasch disruptiert werden. Die grösste Gefahr geht von Apple Pay aus. Gegenwärtig baut Apple auf der ineffizienten Karten-Infrastruktur auf. Perspektivisch wird Apple sich dessen entledigen.
• Lightning Payloads können auf verschiedenen Kommunikations-Protokollen ausgetauscht werden: NFC, Bluetooth, Mesh-Netzwerke, Intranet und Internet mit niedriger Bandbreite. Dies wird die historisch als gegeben angenommene Trennungen im Payment infrage stellen.
• Lightning vereint Aspekte verschiedener heutiger Zahlungssysteme. Es eignet sich für diverse Anwendungsfälle. Daher sind Sonderlösungen für einzelne Nutzergruppen zu erwarten. Die Herausforderung besteht darin, partikulare Bedürfnisse zu adressieren, aber Einheitlichkeit und Interoperabilität zu bewahren. Die Bewahrung von Interoperabilität und Einfachheit sollte ein hohes Ziel sein.
• Wie die Verzögerung bei der Adoption von BOLT 12 zeigt, werden Protokoll-Änderungen immer schwieriger. Mit fortschreitender Adoption ossifiziert das Protokoll, Innovationen werden auf Applikationsebene oder auf aufbauenden Systemen wie dem Smart Contract-Protokoll RGB entwickelt.
• Lightning ist in jeder Hinsicht besser als Karten. Es ist Push, aber gleichzeitig sind wiederkehrende Zahlungen sehr einfach darstellbar. So werden die inhärenten Probleme des Pull-basierten Kartenzahlungsverkehrs vermieden, und gleichzeitig Händlern Planungssicherheit gewährt. Mittels zeitverzögerter Auszahlung, Multisignatur und Treuhand-Services lässt sich das bekannte Chargeback aus der Kartenwelt viel effizienter und fairer nachbauen.
• Lightning ist Open Banking. Die Open-Source-Implementationen stellen APIs kostenlos zur Verfügung. Wallet-Software kann direkt vertrieben werden, ohne im Backend auf Custodians angewiesen zu sein.
• Lightning ist Embedded Finance. Firmen können das komplette Management der Knoten an die Nutzer oder eine Lösung wie Greenlight auslagern und die Schnittstelle auf jedweder Oberfläche und in jedwedem Kontext integrieren.

Der vorerst letzte Teil der Serie wird einige dieser Punkte genauer beleuchten. Es wird klar werden, welche Chancen die Trennung zwischen Finanzdienstleistung und Verwahrung bietet.