Was ist eine virtuelle IBAN?

Eine virtuelle IBAN (vIBAN) ist eine echte, adressierbare International Bank Account Number, die aus einem eigenen Nummernkreis vergeben und auf ein einziges Hauptkonto geleitet wird. Sie nimmt Zahlungen an wie jede andere IBAN – der Zahler sendet von seiner Bank eine ganz normale SEPA-Überweisung dorthin –, führt aber kein eigenes Guthaben. Ihre Aufgabe ist die Identifikation: Da jede virtuelle IBAN genau einem Zahler oder Zweck zugewiesen ist, sagt eine eingehende Zahlung bereits, wer sie geschickt hat und wofür sie gedacht ist. Das Geld sammelt sich automatisch auf dem Hauptkonto; die virtuelle IBAN ist das Etikett an der Zahlung, kein zweiter Ort, an dem das Geld liegt.

Diese eine Eigenschaft – eine IBAN pro Zahler – ist die ganze Idee. Warum sie einen eigenen Artikel wert ist, zeigt sich am besten am Problem, das sie beseitigt.

Das eigentliche Problem: Geld den Zahlern zuordnen

Stellen Sie sich ein Unternehmen vor, das per Überweisung auf ein einziges Konto einnimmt: Mieten, Abos, Rechnungen. Jede Gutschrift landet auf derselben IBAN, und der einzige Hinweis darauf, wer gezahlt hat, ist das, was der Zahler ins Verwendungszweckfeld getippt hat. Verwendungszwecke werden vertippt, irgendwo in der Kette abgeschnitten oder bleiben ganz leer. Eine Überweisung über 49,00 € mit unleserlichem Verwendungszweck sind noch keine 49,00 € verbuchter Umsatz – sie ist ein Ticket. Jemand muss herausfinden, zu welchem Kunden und welcher Rechnung sie gehört, bevor die Bücher geschlossen werden.

Bei kleinen Mengen ist das lästig. Bei Plattformvolumen ist es eine ganze Abteilung. Matching-Engines bewerten Rechnungskandidaten nach Betrag, Datum und unscharfem Verwendungszweck; was sie nicht zuordnen können, landet in einer manuellen Warteschlange. Und das Problem ist strukturell: Zahlen zwei Abonnenten am selben Tag denselben Betrag ohne Verwendungszweck, kann keine Engine sie auseinanderhalten – die Information, die sie unterscheiden würde, war nie Teil der Zahlung.

Eine IBAN pro Zahler: Identität per Design

Ein vIBAN-Programm dreht das Design um. Statt jeden Zahler zu bitten, seine Zahlung korrekt zu beschriften, geben Sie jedem Zahler eine eigene Adresse. Jeder Mieter, Abonnent oder Marktplatzverkäufer zahlt auf eine IBAN, die nur ihm gehört. Der Verwendungszweck darf falsch, leer oder in einer anderen Schrift verfasst sein – die Gutschrift identifiziert sich trotzdem selbst, weil die Identität in der Kontonummer steckt.

Die Kontonummer ist ein weit besserer Träger als der Verwendungszweck. Eine IBAN enthält eigene Prüfziffern, sodass eine vertippte IBAN schon bei der Bank des Zahlers durchfällt, bevor die Überweisung überhaupt rausgeht. Ein vertippter Verwendungszweck rutscht dagegen durch und wird zu Ihrem Problem. Verlagert man die Identität vom Freitextfeld in die Adresse, wandert die Fehlerprüfung aus Ihrem Backoffice zur sendenden Bank.

Für den Zahler ändert sich nichts: Er überweist wie gewohnt per Banking-App an eine IBAN. Das Neue liegt ganz auf der Empfängerseite – die Zahlung kommt bereits beschriftet an, und der Verwendungszweck wird wieder das, was er immer hätte sein sollen: eine Notiz, kein Identifikationssystem.

Wenn jeder Zahler auf seine eigene IBAN zahlt, kann eine eingehende Zahlung nur eines bedeuten. Das Zuordnungsproblem wird nicht gelöst – es hört auf zu existieren.

Wo das Geld tatsächlich liegt

Darunter gibt es pro Währung genau ein Hauptkonto. Die virtuellen IBANs werden aus Nummernkreisen vergeben, die dem Programm vorbehalten sind, und jede Gutschrift auf eine davon wird auf dem Hauptkonto verbucht. Es gibt keine Salden pro Zahler zu verwalten und keine Sweep-Jobs am Tagesende, die Gelder von Tausenden kleiner Konten auf ein einziges schieben – die Bündelung geschieht per Routing, nicht durch zusätzliche Überweisungen, die Sie dann ihrerseits abstimmen müssten.

Genau das macht eine virtuelle IBAN zu etwas Echtem und nicht zu einem Trick. Sie ist von jeder Bank aus adressierbar, wird wie jede SEPA-Gutschrift abgewickelt und erscheint auf dem Kontoauszug des Zahlers als das Konto, auf das er gezahlt hat. Was ihr fehlt, ist genau das, was ein vollwertiges Konto mit sich schleppt: ein eigenes Guthaben und ein Lebenszyklus über Zuweisung und Stilllegung hinaus.

Was eine virtuelle IBAN nicht ist

Sie ist kein Unterkonto: Ein Unterkonto führt ein Guthaben, muss gefüllt und geleert werden und vervielfacht die Hauptbücher, die Sie betreiben. Sie ist keine virtuelle Referenznummer: Die steckt weiterhin im Verwendungszweck und hängt davon ab, dass Zahler Zeichenketten korrekt abtippen. Und sie ist kein Wallet: Auf der vIBAN selbst wird nichts gespeichert. Sie ist eine Adresse mit Routing dahinter – das schmalste Konstrukt, das eine eingehende Zahlung selbstidentifizierend macht.

Rückläufer kommen mit Begründung zurück

Zahlungen kommen nicht nur an. Konten werden geschlossen, Banken lehnen Gutschriften ab, Zahler rufen Überweisungen zurück. In einer Welt mit einem einzigen Sammelkonto ist ein Rückläufer eine kleine Ermittlung: Welche Zahlung kam zurück, von wem war sie, und muss die Buchung, der sie zugeordnet war, rückgängig gemacht werden?

In einem vIBAN-Programm ist ein Rückläufer ein Datensatz. Er trägt seinen Reason-Code, trifft als Event payment.returned auf derselben virtuellen IBAN ein, die die ursprüngliche Gutschrift genutzt hat, und erhält auf dem Kontoauszug eine eigene Position. Sie wissen, wessen Zahlung zurückkam und warum, bevor jemand ein Ticket öffnet. Rückläufer werden zu Zeilen, die man abarbeitet, nicht zu Rätseln, denen man hinterherjagt.

Eine Ausnahmen-Queue statt eines Matching-Teams

Kein Design gleicht hundert Prozent von irgendetwas ab. Gutschriften treffen auf stillgelegten vIBANs ein. Dubletten passieren. Irgendjemand zahlt irgendwie direkt auf das Hauptkonto. Das Ziel ist nicht, Ausnahmen unmöglich zu machen, sondern sie selten und zählbar zu halten. In der Protocore-vIBAN-Demo werden 99,6 % der Gutschriften automatisch abgeglichen; der Rest landet mit der vollständigen Historie des Zahlers in der Prüfqueue, sodass die Bearbeitung einer Ausnahme beim Kontext beginnt und nicht bei einem Kontoauszug und einer Tabellenkalkulation.

Dieser Unterschied verändert das Team. Ein Matching-Betrieb skaliert mit dem Zahlungsvolumen: mehr Gutschriften, mehr nicht zugeordnete Gutschriften, mehr Personal. Ein Ausnahmeprozess skaliert mit der Zahl der Ausnahmen, die das Design bereits gegen null gedrückt hat. Die Leute, die bleiben, bearbeiten echte Anomalien statt neu getippter Verwendungszwecke. In unserem Stack lebt diese Queue in Protocore Center (/products/center), der Operations-Konsole, in der jede privilegierte Aktion eine Begründung erfordert und im Audit-Log landet.

Massenanlage, Zweck-Tags, Plattformen

Eine IBAN pro Zahler funktioniert nur, wenn das Anlegen nichts kostet. Ein Vermieter mit einem Dutzend Mietern könnte vIBANs von Hand erzeugen; ein Marktplatz, der Tausende Verkäufer onboardet, kann das nicht. Deshalb ist die Ausgabe ein Massenvorgang. In der vIBAN-Demo wird eine CSV mit 2.400 Zahlern validiert, zeigt in jeder Zeile eine Vorschau der IBAN und wird in einer einzigen Aktion ausgegeben – 2.400 Zahler, ein Vorgang, dazwischen ein Prüfschritt.

Zweck-Tags halten Zahlungsflüsse bereits auf Adressebene getrennt: Mieten hier, Abos dort, Marktplatz-Auszahlungen in einer eigenen Spur. Reporting nach Zweck wird zum Filter statt zum Projekt, und jede vIBAN erhält einen eigenen Kontoauszug – als CSV oder PDF –, während das Hauptkonto darunter die einzige Quelle der Wahrheit bleibt. Verlässt ein Zahler die Plattform, wird seine vIBAN stillgelegt: Die Historie bleibt, die Adresse nimmt keine neuen Gutschriften mehr an.

Wo das im Payment-Stack sitzt

Virtuelle IBANs sind Infrastruktur für den Zahlungseingang. Sie geben eingehenden Banküberweisungen das, was Kartenzahlungen schon immer hatten: eine Identität, die an der Zahlung selbst hängt und nicht daneben eingetippt wird. Im Protocore-Ökosystem tragen die Pay-by-Transfer-Bestellungen von Gateway vIBAN-Referenzen, und Center bearbeitet, was das Matching an Ausnahmen übrig lässt. Die Produktseite unter /products/viban führt den gesamten Kreislauf vor – ausgeben, teilen, abgleichen, Ausnahmen behandeln, berichten – mit denselben Demodaten wie hier.

Und eine ehrliche Grenze: Wenn Sie nur eine Handvoll Überweisungen im Monat erhalten, genügen eine Konvention für den Verwendungszweck und zehn Minuten Buchhaltung. Virtuelle IBANs lohnen sich dort, wo das Volumen die Zuordnung zum Prozess gemacht hat – Mietverwaltung, Abo-Inkasso, Marktplätze –, überall, wo die Frage, wer Ihnen gezahlt hat, tausendfach im Monat gestellt wird.