Empfängerüberprüfung liefert leeres Gegenfeld bei fehlgeschlagenem Match

Moin allerseits,

kann es sein, dass die Volksbanken (ganz konkret die Volksbank in Ostwestfalen) noch Probleme mit der Anlieferung der Daten bei der Empfängerprüfung haben.

Bei mir wird eine SEPA Überweisung als fehlgeschlagen angezeigt und zur Bestätigung vorgelegt:

Roter Kreis mit Ausrufezeichen


Oder ist das Ganze ein Problem von Hibiscus?

Das Konto selbst existiert in dieser Form seit Fusion der an der Volksbank in Ostwestfalen beteiligten Volksbanken
(vorher unter anderer BLZ/SEPA), das Gasthaus selbst unter diesem Namen ca. 70 Jahre.

Gruss
pahhur

Ok, das ist dann aber sehr bescheiden, wenn "Gasthaus X" eingegeben wird
und das Konto auf "Vorname X" läuft.

Da sollte doch wohl ein genügend großes Match allein mit dem X gegeben sein.

Nein, das ist natuerlich nicht mein Konto, sondern das eines Empfängers (und der ist ja auch bereits darüber informiert worden).

Ja, Hibiscus mag das liefern, was von der Spk/Bank kommt, wo die Überweisung eingereicht wird. Das ist aber ja auch nicht das Problem. Das Problem ist, laut Olaf, dass hier nicht die bei der Empfängerbank gespeicherten Informationen (d.h. "Vorname X") übermittelt werden, sondern ein leerer String, weil man dort ganz offensichtlich zu unfähig war, einen Matching Algorithmus zu verwenden, der in der Lage ist herauszufinden, dass "Vorname X" und "Gasthaus X" so ähnlich sind, dass man sie als "Gelb" mit Überprüfung darstellen könnte.

"Vorname X" und "Gasthaus X" sind nunmal nicht ähnlich und deswegen ergibt es ein "NO MATCH".
Ein "CLOSE MATCH" wäre es, wenn z.B. ein oder zwei Buchstaben vertauscht sind, also z.B: "Vornmae" anstatt "Vorname". Und dann würde von der Empfängerbank der richtige Name zurückgeliefert werden.
Aber "Vorname" und "Gasthaus" haben absolut keine Ähnlichkeit. Deswegen ist das Ergebnis "NO MATCH" korrekt und die Bank macht alles richtig.

Nun, generell, ist das selbst mit dem Dokument Auslegungssache und nur Teil einer Vorgabe, wie man auch bei den Sparkassen sehen kann:


Wenn ich also bei der Sparkasse für meine Eingabe


oder

eine gelbe Anzeige mit der Korrektur



bekomme, dann sind da auch nicht nur ein paar Typos drin (wie in dem Dokument beschrieben) und der Unterschied wesentlich größer als bei der Volksbank in meinem Beispiel.

D.h. der Sparkassenalgorithmus ist hier zumindest was den Teil angeht wesentlich ausgefeilter.


Ich habe im Übrigen sehr sehr lange für Banken in der IT gearbeitet. ich kann das durchaus einschätzen, was dort Unwillen und was Unvermögen ist.

Nein, der Unterscheid ist nicht größer.

Bei deinem Beispiel "Dr. X" matchen die Substrings "Dr." und "X" zu 100%. Also "Dr." kommt vor und "X" kommt vor. Deswegen ist es ein "Close Match".
In der Praxis reicht es also in aller Regel aus einfach nur den Nachname einzugeben, um einen "Close Match" zu erzeugen.
Wenn man aber "Gasthaus" anstatt "Vorname" eingibt, was zwei völlig unterschiedliche Strings sind, dann ergibt dies ein "No Match", auch wenn der Nachname dabei korrekt ist.

Was soll eigentlich diese ganze Diskussion und die künstliche Eschauffierung?
- Das Problem liegt nicht bei der Bank.
- Sowohl Absender, als auch der Empfänger sind hier das Problem.

Warum der Empfänger?
- Weil der Empfänger offensichtlich bisher nicht in der Lage war, seiner Bank mitzuteilen, dass diese auch "Gasthaus X" als Name aufnehmen soll. Es ist ja nicht so, dass VoP nicht schon seit vielen Monaten angekündigt war.
- Weil der Empfänger wohl auch nicht in der Lage ist, auf seinen Rechnungen einfach den Vermerk "Kontoinhaber: <Vorname> <Nachname>" aufzudrucken, um das Problem elegant zu umgehen.

Warum der Absender?
- Weil der Absender wohl nicht verstanden hat, wann es zu einem "Close Match" bzw. einem "No Match" kommt, und den Banken hier Unfähigkeit vorwirft.
- Weil der Absender ein Fass aufmacht, anstatt die Überweisung (nach genauer Kontrolle der IBAN) einfach trotz "No Match" durchzuwinken.

Nun, gemäß dem obigen Dokument findet das Matching ggf. auch nicht ganz so statt, wie du das jetzt beschrieben hast. Aber sei es, wie es sei.

Ich finde mich unter dem Punkt:



wieder, sprich die Option, dieses auch anders zu tun, ist gegeben.


Und natürlich wird keiner überweisen, wenn da ein leeres Feld bei einer neuen Kontonummer kommt. Genau dafür ist die Überprüfung doch wohl da.

Die IBAN war handschriftlich und auf der Rechnung stand an anderer Stelle "Gasthaus X" über "Vorname X" und der Empfänger zu dem Zeitpunkt nicht erreichbar. Da geht keine schnelle Kontrolle und man möchte ja die etwas größere Summe auch nicht unwiderruflich an jemand anderen überweisen.

Falsch, so könnte man ja ganz easy den Vornamen des Kontoinhabers rauskriegen, dementsprechend ergibt sich ein No Match.
Bei Einzelkonten reicht für einen Close Match ja die Initiale des Vornamens plus Nachame des Inhabers. Das geht bei meinem DKB-Gemeinschaftskonto nicht. Und bei einem Close Match eines Kontoinhabers wird auch nur der korrekte Name desselben angezeigt und nicht zusätzlich noch der des zweiten. Dies entspricht alles den oben verlinkten Empfehlungen.

Edit: Das oben Gesagte gilt für Hibiscus. B4A liefert nur mit dem Nachnamen den Vornamen dazu. Wie kann es zu solch unterschiedlichem Verhalten kommen?

Getestet mit den von mir o.g. Banken liefert die Eingabe des Nachnamens (vollständig korrekt geschrieben) den Vorname zurück (Close Match). Bei einem Konto, welches bei einer Sparkasse liegt, sogar beide Vornamen. Bei einem Gemeinschaftskonto, welches bei der Norisbank liegt die Vornamen beider Kontoinhaber. Getestet mit der jeweiligen Banking-/Freigabeapp und mit Banking4. Nicht getestet mit Hobby-Projekten, die VoP erst seit wenigen Tagen können.
Evtl. gibt es Banken, die das anders handhaben, die Regeln sind ja nicht verpflichtend.


Kann ich nicht bestätigen. Ich habe zwar o.g. nicht mit Hibiscus getestet, aber gerade einen Versuch Deutsche Bank -> DKB mit Hibiscus vorgenommen, und auch hier lieferte mir der Nachname ein "Close Match".

Aber das Thema war ja vorallem "Gasthaus X" und ich glaube da sind wir uns einig.