Die Ausführungen hier bauen auf der allgemeinen Einführung der Rubriken Transaktionsmodell und 4-Parteien-Modell auf. Im weiteren wird auf die Eigenheiten des kontobasierten Zahlungsverkehrs fokussiert.
IDENTIFIKATION BEI KONTOZAHLUNGEN
Die Identifikation bei Kontozahlungen erfolgt digital durch Anmeldung im Online Banking unter Nutzung einer Zugangskennung, die einem Konto zugeordnet ist. Auf einem Überweisungsträger erfolgt die Identifikation durch Angaben des Namens des Zahlungsempfänger und der IBAN.
Für das ziehen von Lastschriften benötigt man die IBAN des Zahlers. Diese kann über einen Lastschriftauftrag des Zahlers vorliegen. Ebenso steht im SEPA-Raum der SEPA-Proxy-Lookup zur verfügung.
IDENTIFIKATION BEI KONTOZAHLUNGEN ÜBER DEN SEPA PROXY LOOKUP (SPL)
Elektronischer Zahlungsverkehr funktioniert heute europaweit standardisiert unter Verwendung der IBAN. Die Eingabe der IBAN durch den Payer ist im (mobilen/ digitalen) Zahlungsverkehr ein Hemmschuh bei der komfortablen Durchführung von Zahlungsvorgängen und der gesicherten Identifizierung des Payee.
Das SPL-Scheme ermöglicht es mittels eines einheitlichen Proxys, europaweit zu bezahlen.
Neben einem Regelwerk, einem einheitlichen Standard und deren Datenformate stellt SPL einen (kostenpflichtigen) unabhängigen Service für registrierte Dienstleister bereit. SPL verbessert als Ergänzung zu bestehenden SEPA-Services deren Anwendbarkeit und Benutzerfreundlichkeit. Es bietet zudem die Basis für neue Use Cases auf europäischer Ebene.
HINTERGRUND ZUR IDENTIFIKATION MIT DEM SEPA PROXY LOOKUP (SPL)
Ein Proxy ist ein Vermittler oder im Anwendungsfall des SPL ein Mechanismus, der Anfragen unter einer Adresse (z. B. Mobilnummer) zur Vermittlung entgegennimmt und unter Verwendung von eigenen Daten (z. B. IBAN) eine Verbindung zur anderen Seite ermöglicht. Im SPL-Scheme dient dieser Mechanismus der eindeutigen Payer-Identifizierung. Der SPL-Proxy ist sowohl technisch als auch organisatorisch unabhängig von einem Zahlungsverfahren.
SPL ist damit ein wesentliches Element, um Person-to-Person- (P2P) oder andere Zahlverfahren (z. B. SCT oder Zahlkarten) App-basiert nutzerfreundlich umzusetzen. Im ersten Schritt ist als Proxy die Mobilnummer respektive die E-Mail-Adresse vorgesehen, wie man das bereits von Messenger Apps kennt. Aber auch andere Proxies sind denkbar und sollen im nächsten Schritt spezifiziert werden.
Damit kann die teils aufwändige und fehlerbehaftete Weitergabe sensibler Zahlungsdaten, wie z. B. die IBAN oder die Kreditkartennummer, bei der Zahlungsauslösung vereinfacht werden. SPL kann somit zu einer Interoperabilität für den Austausch notwendiger Daten im Zahlungsverkehr beitragen.
Auch für nicht-IBAN-basierte Verfahren wie beispielsweise einige P2P-Verfahren können auf diese Weise Kontodaten ausgetauscht werden.
Ziel ist es, einen einheitlichen Standard für verschiedene Zahlungsverfahren in Europa zu etablieren: mobil, digital und bequem.
SPL konzentriert sich auf die Suchfunktion des Payers (sog. Lookup-Funktion), um eine nachgelagerte Zahlung einzuleiten. Die tatsächliche Zahlung ist nicht Bestandteil des SPL-Schemes, sondern wird durch bestehende Zahlungsverfahren abgedeckt.
Das SPL-Scheme bzw. der entsprechende Service Provider des Verfahrens stellt als Vermittler die Verarbeitung der SPL-Anfragen und -Antworten sicher.
Mehr zum Thema Sepa Proxy Lookup (SPL).
IITIIERUNG VON KONTOZAHLUNGEN MIT REQUEST TO PAY (RTP)
Der RtP setzt unmittelbar nach einer Identifizierung auf um einen Zahlungsprozess zu initiieren.
Request-to-Pay (R2P) ist ein neuer „europäischer“ Standard für Zahlungsaufforderungen, der als vorgelagerter Kommunikationskanal bestehende Zahlungsinstrumente ergänzen und damit vereinfachen kann.1
R2P definiert dabei lediglich Regeln und technische Elemente, die es einem Zahlungsempfänger (Payee) ermöglichen, einen Geldbetrag in EURO von einem Zahler (Payer) für eine bestimmte Geschäftstransaktion zu verlangen. Das primäre Zahlungsinstrument für die Zahlung selbst stellt aktuell die SEPA Überweisung dar (SCT/SCT Inst).
Abb.: RtP Prozess-Komponenten im Zusammenhang
Es handelt sich explizit nicht um ein neues Zahlungsinstrument, sondern lediglich um eine vorgeschaltete Kommunikationsebene (= Request-Layer) zwischen den involvierten Parteien (primär Payee und Payer).
Abb.: Hauptbeteiligte RtP-Prozess
Der Zahlungsempfänger übermittelt an den Zahler:
- seine Kontodaten,
- seinen Verwendungszweck,
- den Betrag in EURO für die Zahlung und
- das Zahlungsinstrument, mit dem er bezahlt werden möchte (z. B. SEPA Instant Payments).
Die R2P Zustellung und Interaktion zwischen den Beteiligten erfolgt sofort z. B. über die Banking-App. Der Zahler kann dabei die R2P akzeptieren oder diese verweigern bzw. ablehnen. Akzeptiert der Zahler den R2P wird die Zahlung initiiert und ist nicht mehr rückgängig zu machen.
Eine Vielzahl an unterschiedlichen Anwendungsfällen sind für den R2P Abwicklungsprozess möglich:
- Digitalisierte Rechnungs-(kauf)-prozesse (E-Rechnung oder klassischer Rechnungsprozess)
- Online-Handel beim Check-Out (Wallet-/ Remote-Payment Ansätze)
- Physischer Handel am POS (POI)
- Geldüberweisungen zwischen zwei Personen
- Wiederkehrende LS-Aufträge (z. B. Energieversorger, Finanzbehörden)
Abhängig vom jeweiligen Anwendungsfall des R2P können unterschiedliche Verfahren zur Initiierung eines R2P (z. B. NFC im POS-Umfeld oder QR-Code basierte Verfahren im eCommerce) zum Einsatz kommen.
1 Derzeit unterstützen 27 Kreditinstitute in Europa die R2P Initiative über die EBA Infrastruktur.
Mehr zum Thema Request-to-Pay.
AUTHENTIFIZIERUNG BEI KONTOZAHLUNGEN
Die Authentifizierung bei Kontozahlungen entspricht den oben beschriebenen Vorgaben der PSD2. Anders als bei Kartenzahlungen gibt es keine Notwendigkeit zur Interoperabilität bei der Authentifizierung. Die Bank des Zahlers ist also innerhalb des regulatorischen Rahmens frei bei der Gestaltung der Authentifizierung. Dies führt zu einer größeren Vielfalt bei den Authentifizierungsmedien und -prozessen.
Die Anmeldung im Online Banking ist jedoch nicht ausreichend für eine starke Authentifizierung. Jede einzelne Zahlung ist zusätzlich zu Authentifizieren oder durch Nutzung einer der vorgegebenen Ausnahmen von der starken Authentifizierung zu entbinden.
DISPOSITION/AUTORISIERUNG VON KONTOZAHLUNGEN
Bei Kontozahlungen erfolgen Autorisierung und Disposition nicht zwingend zeitgleich. Dies kann zu einer Ausführung der Zahlung nachgelagerte Prozesse verursachen.
Lastschriften können bspw. retourniert werden. Gründe für Lastschriftrückgaben sind mangelnde Kontodeckung, falsche Daten und unerlaubte Abbuchungen. Retouren werden hierbei teils maschinell teils durch einen Kontobetreuer angestoßen.
Die Disposition beinhaltet ggf. auch die Frage, welche von mehreren Lastschriften zurückgegeben wird/werden.
CLEARING/SETTLEMENT BEI KONTOZAHLUNGEN
GEBÜHRENABRECHNUNG BEI KONTOZAHLUNGEN
REKLAMATION BEI KONTOZAHLUNGEN
Kommt es bei einer Kontozahlung zu einer Reklamation, ist zunächst die eingesetzte Zahlungsmethode von Bedeutung. Vom Zahler initiierte Überweisungen z. B. SEPA Credit Transfer (SCT) sind für den Zahler und sein Institut nach Ausführung bindend.
Vom Zahlungsempfänger initiierte Abbuchungen z. B. SEPA Direct Debit (SDD) können vom Zahler ohne Angabe von Gründen zurückgefordert werden. Bei der Rückgabe sind Fristen zu beachten. Eine Zahlungsrückgabe bedingt jedoch nicht, die Rückabwicklung des Geschäftes, das der Zahlung zu Grunde liegt.
Ebenso kann eine fehlerhafte Ausführung durch den Zahlungsdienstleister Grundlage einer Reklamation sein. Bspw. die doppelte Ausführung von Aufträgen oder die fehlerhafte, manuelle Bearbeitung eines Beleges. In diesem Fall ist die Reklamation zwischen dem Auftraggeber und seinem Institut zu regeln. Das Institut kann dann ggf. Rückgriff auf die zweite Partei im Zahlungsprozess nehmen.