Warum dieses Beispiel?
Indien ist ein wichtiger Handelspartner vieler mittelständischer Unternehmen in Deutschland. Technisch ist das Land über das SWIFT‑Netz angebunden – eigentlich ein Standard‑Setup. In der Praxis berichten Unternehmen jedoch häufig von Verzögerungen, uneinheitlichen Gebühren und begrenzter Transparenz bei Zahlungen nach Indien.
Der zentrale Punkt dabei: Diese Effekte sind selten „Fehler“ einzelner Banken, sondern folgen aus der Architektur grenzüberschreitender Zahlungen – Korrespondenzbanken (Nostro/Vostro), Zeitzonen, lokale regulatorische Prüfungen und Währungsumrechnungen. Dieses Beispiel macht sichtbar, was zwischen „Zahlungsauftrag erteilt“ und „Geldeingang beim Lieferanten“ konkret passiert – und warum Fintech‑Netzwerke und blockchain‑basierte Ansätze hier ansetzen können.
Wie läuft eine klassische Auslandsüberweisung ab?
Ausgangspunkt ist eine Überweisung über 50.000 € von einem deutschen Unternehmen an einen indischen Lieferanten. In der Regel wird die Zahlung als klassische Banküberweisung über SWIFT abgewickelt. Der Zahler erteilt seiner Bank einen Auslandszahlungsauftrag mit Empfänger, Betrag, Währung, Gebührenteilung (z. B. OUR/SHA/BEN) und Verwendungszweck.
Zwischen den beteiligten Banken werden SWIFT‑Nachrichten ausgetauscht – historisch im MT‑Format, zunehmend im ISO‑20022‑Standard. Haben Absender‑ und Empfängerbank keine direkte Beziehung, wird mindestens eine Korrespondenzbank dazwischengeschaltet, die Konten für beide Parteien führt (Nostro/Vostro). In jeder Stufe finden Sanktions‑, Geldwäsche‑ und KYC‑Prüfungen statt – teils vollautomatisch, teils mit manuellen Reviews. Rückfragen und Dokumentationsanfragen sind oft eher Folge dieser Prüfmechanik als „Willkür“.
Soll der Betrag in INR gutgeschrieben werden, erfolgt eine FX‑Konvertierung (EUR→INR oder ggf. EUR→USD→INR). Der genutzte Kurs enthält einen Spread zur Mittelkurs‑Referenz. Auf indischer Seite greifen lokale Gutschrift‑ und Wertstellungsregeln, häufig über NEFT / RTGS / IMPS (Indien). Banken können interne Cut‑off‑Zeiten und Post‑Processing‑Schritte haben, wodurch Zahlungen leicht um einen Tag „rutschen“.
Laufzeiten & All‑in‑Kosten
Die End‑to‑End‑Dauer liegt in der Praxis häufig zwischen T+2 und T+5 Kalendertagen. Ursachen sind Cut‑off‑Zeiten, Zeitzonen, Zwischenstufen und manuelle Prüfungen. Die All‑in‑Kosten ergeben sich aus Bankgebühren (Absender/Korrespondenz/Empfänger) plus FX‑Spread – ex ante oft nur grob abschätzbar. Tracking wurde mit SWIFT‑GPI verbessert, bleibt aber im Bankkanal.
AWV‑Meldepflicht
In Deutschland gilt für grenzüberschreitende Zahlungen grundsätzlich eine Meldepflicht ab 12.500 € (Ausnahmen möglich). Bei 50.000 € ist daher in der Regel eine AWV‑Meldung abzugeben. Banken können zusätzlich Zweckangaben und Belege anfordern, um ihre Compliance‑Pflichten zu erfüllen.
Was machen Fintech‑Netzwerke anders?
Anbieter wie Wise nutzen häufig lokale Ein‑ und Auszahlungsnetze. Praktisch bedeutet das: Das Unternehmen zahlt in Europa EUR auf ein lokales Konto ein, während der Anbieter in Indien aus einem lokalen Pool INR über NEFT / RTGS / IMPS (Indien) an den Empfänger auszahlt. Der Geldfluss wird auf beiden Seiten lokal gespiegelt, statt eine lange Korrespondenzbank‑Kette zu durchlaufen.
Das Ergebnis ist häufig schneller (von Minuten bis same‑day), planbarer durch klare Status‑Updates und kostentransparenter, weil Gebühr und FX‑Spread explizit ausgewiesen werden. Grenzen dieser Modelle liegen bei Betragslimits, Country‑Coverage und sehr großen Ticketgrößen, bei denen individuelle Konditionen und erweiterte KYC/AML‑Prüfungen greifen.
Was leisten Blockchain‑basierte Zahlungen (Stablecoins)?
Die Grundidee ist, Geld als digitalen Token zu übertragen, statt Kontosaldi über Korrespondenzbanken zu verschieben. Das eröffnet Zahlungen mit 24/7‑Verfügbarkeit und – je nach Design – der Option auf T+0‑Finalität. Im Kontext „Deutschland → Indien“ lassen sich zwei Grundmuster unterscheiden.
(1) End‑to‑End on‑chain mit INR‑Off‑Ramp: Der Zahler wandelt EUR→Euro‑Stablecoin (oder USD‑Stablecoin) und transferiert diesen on‑chain an den Empfänger. Dieser nutzt einen On‑/Off‑Ramp‑Dienstleister, um den Token in INR zu tauschen und auf ein lokales Konto auszahlen zu lassen. Vorteile sind Geschwindigkeit und Transparenz; Risiken liegen in Verfügbarkeit und Qualität der On‑/Off‑Ramps, der Aufsichtssituation und der Auswahl seriöser Partner.
(2) On‑Chain‑Settlement mit klassischer Auszahlung: Vertragspartner nutzen Stablecoins, um Forderungen on‑chain zu begleichen, die physische Auszahlung in Fiat erfolgt weiterhin über bestehende Bankkanäle. So lassen sich Wertstellungs‑ und Liquiditätsrisiken reduzieren, während etablierte Workflows für FX, Reporting und lokale Auszahlungen erhalten bleiben.
Transparenz, Nachvollziehbarkeit & Kostenstruktur
Technisch sind Stablecoin‑Transfers innerhalb von Minuten möglich. Die Kosten ergeben sich aus Netzwerkgebühren und Dienstleister‑Entgelten und sind häufig wettbewerbsfähig im Vergleich zu SWIFT‑Ketten. Durch öffentliche Transaktions‑IDs auf der Blockchain ist der Verlauf prüfbar. KYC/AML‑Prüfungen liegen organisatorisch bei Banken und On‑/Off‑Ramp‑Anbietern, nicht bei der Blockchain selbst – das muss in Governance und Dokumentation berücksichtigt werden.
Operative Implikationen für ERP & Finance
Für CFOs und Finance‑Teams ist entscheidend, wie sich Stablecoin‑Zahlungen konkret in bestehende Prozesse einbetten lassen. Ein sinnvoller Startpunkt ist kein „Big‑Bang‑Wechsel“, sondern ein gezielt gewählter Pilot: ein klar definierter Lieferant oder Lieferanten‑Cluster, ein überschaubares Volumen und ein Zeitraum von 30–90 Tagen, in dem klassische Zahlungen mit FinTech‑ und Stablecoin‑Ansätzen verglichen werden.
Operativ lassen sich die Schritte grob in vier Bereiche unterteilen: (1) Auswahl des Korridors und der Partner, (2) Definition von Rollen, Freigaben und Limits, (3) Abbildung in Buchhaltung und Reporting sowie (4) Governance und Ausstiegsszenario. Die folgende Übersicht beschreibt einen möglichen Weg.
Schritt-für-Schritt-Pilot: Stablecoins für Zahlungen nach Indien
- Korridor & Umfang definieren: Einen oder wenige indische Lieferanten auswählen, Zahlungsarten festlegen (z. B. wiederkehrende Service‑Fees) und ein Zielvolumen für den Pilot bestimmen (Anzahl Zahlungen, Zeitraum).
- Regulatorische Rahmenbedingungen prüfen: Zusammen mit Tax/Legal und ggf. Bank klären, ob Stablecoin‑Zahlungen als Auslandsüberweisung gelten, welche AWV‑Meldungen erforderlich sind und wie KYC/AML sichergestellt werden.
- On‑/Off‑Ramp‑Provider auswählen: Einen regulierten Anbieter mit EU‑Lizenz, SEPA‑Ein‑/Auszahlungen (idealerweise SEPA Instant) und solider API‑Dokumentation wählen. Klären, ob der Provider direkte Auszahlungen nach Indien unterstützt oder mit lokalen Partnern zusammenarbeitet.
- Rollen, Freigaben und Limits definieren: Im ERP und beim Provider festlegen, wer Zahlungen anstoßen darf, wer freigibt und welche Limits pro Zahlung/Tag gelten. Idealerweise gilt das Vier‑Augen‑Prinzip und es gibt eine Adress‑Whitelist für bekannte Empfänger.
- Buchungs‑ und Kontierungslogik festlegen: Im Kontenplan entscheiden, wie Stablecoins und EUR‑Bestände auf dem Provider‑Konto abgebildet werden (z. B. separates Wallet‑Konto in der Buchhaltung). Für jede Zahlung klären, wie FX‑Effekte und Gebühren verbucht werden.
- Pilot technisch anbinden: Je nach Reifegrad zunächst mit einem manuellen Prozess starten (Upload von Zahlungsdateien, manuelles Verknüpfen mit Belegen im ERP) und erst in einem zweiten Schritt API‑basierte Integration (Webhooks, Referenzfelder, Status‑Updates) aufbauen.
- 30–90‑Tage‑Benchmark durchführen: Klassische Banküberweisungen, FinTech‑Zahlungen und Stablecoin‑Zahlungen parallel messen: Durchlaufzeit (T+?), All‑in‑Kosten, Anzahl Rückfragen und internen Abstimmungsaufwand. Ergebnisse strukturiert dokumentieren.
- Entscheidung & Skalierung: Auf Basis der Daten entscheiden, ob der Einsatz von Stablecoins auf weitere Lieferanten oder Korridore ausgeweitet wird. Governance‑Regeln (z. B. jährliche Provider‑Review, Limit‑Anpassungen) definieren.
Häufige Fragen
Muss ich bei 50.000 € etwas melden?
Ja, in Deutschland ist grundsätzlich eine AWV‑Meldung ab 12.500 € erforderlich (Ausnahmen möglich). Die Bank kann zudem Zweckangaben und Belege abfragen.
Kann ich in EUR zahlen, der Lieferant erhält INR?
Ja. Bei Bank oder FinTech erfolgt die FX‑Konvertierung im Prozess; on‑chain ist sie Teil des Off‑Ramps. Für das Unternehmen bleibt der Auftrag in EUR, der Lieferant erhält die vereinbarte Währung.
Fazit
Die Entwicklung verläuft von intransparenten Banken‑Korrespondenzketten über transparente Fintech‑Netzwerke hin zu Blockchain‑basierten Settlements mit 24/7‑Verfügbarkeit und T+0‑Option. Für den Mittelstand bedeutet das: klassische Kanäle verbessern, Fintech aktiv nutzen und Stablecoin‑Know‑how mit kleinen, gut geführten Piloten aufbauen. Dort entstehen die Zeit‑ und Kostenvorteile, die im Tagesgeschäft zählen.
Quellen & Stand
Quellen (Auswahl):
- •SWIFT gpi – Überblick über Funktionen und Tracking‑Möglichkeiten für grenzüberschreitende Zahlungen.
- •Deutsche Bundesbank – AWV‑Meldepflicht (Merkblätter, FAQ und Meldeportal).
- •Reserve Bank of India (RBI) – Informationen und Regelwerke zu NEFT / RTGS / IMPS (Indien).
- •FEMA – Foreign Exchange Management Act (Indien) – Devisen‑ und Zweckcode‑Regelungen.
- •Wise Business – Funktionsweise lokaler Auszahlungen und Preismodelle.
- •BIS / CPMI – Cross‑border payments Programme – Berichte zu Geschwindigkeit, Kosten und Transparenz.
Stand: 26. Oktober 2025.