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

Siehe https://www.willuhn.de/wiki/do…_angeboten

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.

wenn das Empfänger-Konto deins ist, dann wende dich an deine VR, ob die "Gasthaus X" zusätzlich hinterlegen können.
fakt ist, die Software liefert das an Informationen was von der Empfänger-Bank kommt.

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.

ganz sicher ist das Absicht und nicht Unfähigkeit.

"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.

@pahhur, Lektüreempfehlung.

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.

Und noch ein kleiner Gedanke:

Kommt denn bei Gemeinschaftskonten bei der Volksbank, z.B. von
dann auch regelmäßig eine rote Anzeige mit leerem Feld, wenn man nur an oder überweisen möchte?

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.

Bei einem Gemeinschaftskonto sind beide Kontoinhaber hinterlegt.
Die folgenden Kombinationen ergeben also einen "MATCH" (grün):
- Hertrude König
- Wilhelm König
- Hertrude und Wilhelm König
- Hertrude Wilhelm König

Ein "CLOSE MATCH" (gelb) würde die folgende Eingabe ergeben:
- König

Ein "NO MATCH" (rot) würde die folgende Eingabe ergeben:
- Maximilian König

Gleiches gilt übrigens für Kontoinhaber mit mehreren Vornamen. Man muss nicht alle Vornamen angeben, um ein "MATCH" oder "CLOSE MATCH" zu erzeugen. Gibt man allerdings einen absolut falschen Vorname an (ähnlich wie "Gasthaus" anstatt "Vorname") ergibt es ein "NO MATCH".

Getestet mit folgenden Empfängerbanken:
- DKB, ING, C24, Postbank, Norisbank, Deutsche Bank, Revolut, lokale Sparkasse, lokale VR-Bank, lokale Landesbank

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.

Wie du sicherlich gesehen hast, ist das Dokument eine Empfehlung und keine bindende Vorgabe. Deswegen habe ich angegeben, mit welchen Banken ich meine Aussagen getestet habe, was du bestimmt auch gesehen hast.


Es bleibt aber dabei: Der String "Gasthaus" hat mit dem String "Vorname" nichts gemein, deswegen gibt es ein "No Match", auch wenn der Nachname stimmt. Das ist so gewollt und wird auch im verlinkten Dokument als Empfehlung benannt.


Mögliche Vorgehensweise:
- "<Vorname> <Nachname>" probieren und schauen, ob dies ein "Match" oder "Close Match" ergibt
- "<Nachname>" probieren und schauen, ob dies ein "Close Match" ergibt
- Warten bis der Empfänger telefonisch erreichbar ist und dann Rückfrage
- Einfach trotzem überweisen. IBAN enthält ja eine Prüfziffer (Schreibfehler ist also unwahrscheinlich) und in der Vergangenheit fand ja auch keine Namensüberprüfung statt. Die Option bietet sich natürlich nur an, wenn man etwas risikoaffin ist.

Keine gute Vorgehensweise:
- Der Bank offensichtliche Unfähigkeit vorwerfen (siehe auch hier)
- Mitteilen, dass man lange Zeit in der IT einer Bank gearbeitet hat und Unwillen/Unvermögen erkennen kann, obwohl man nicht verstanden hat, warum "Gasthaus X" ein "No Match" liefert. (vgl. hierzu deine Aussage in diesem Posting und der falschen Erwarungshaltung).

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?

Sorry, ich bleibe bei meiner Einstellung und lasse sie mir auch von dir nicht verbieten, weder direkt noch indirekt.

"Gasthaus" ist genauso wie die in Punkt 0) benannten oder ähnliche Titel/Bezeichnungen/Berufstitel/etc kein gängiger Vor- oder Zuname und sollte deswegen auch mit anderen Namen nur dann gematched werden, wenn der Empfänger auch tatsächlich so heisst. Heisst der Empfänger aber weder mit Vor- noch mit Zunamen "Gasthaus", dann sollte dieser String nur mit eventuell vorhanden anderen Substrings gematched werden. Sind die nicht vorhanden, dann haben wir den gleichen Fall wie bei den Titeln. Man hatte dort ja die grundlegende Einsicht ! Denn man formt "Dr. X" ja auch zu "X" um bevor man matched (Vermutlich auch "Professor X" , "Professor Dr. X" und "Prof Dr. Dr. X" zu "X").

Nur weil du dir das nicht vorstellen kannst, heisst es noch lange nicht, dass die Erwartung auf meiner Seite zu hoch war oder gar die Einstellung falsch war.


Und was meinen CLOSE_MATCH angeht:

Dann müssten nach deiner Substring-Matching Erklärung



(sofern med. nicht herausgefiltert wird) auch alle einen CLOSE_MATCH erzeugen, der dann den vollen Text offenlegt ....

Und der Empfänger wurde ja von mir darauf hingewiesen, dieses mit seiner Voba zu regeln.

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.

Ich glaube es ist alles gesagt. Wenn jemand der Meinung ist, dass die Erde eine Scheibe ist, dann erkläre ich ihm einmal, warum er falsch liegt. Wenn er dann immernoch bei seiner Meinung bleibt, dann ist das für mich OK, dann soll er halt glauben, dass die Erde eine Scheibe ist.

siehe auch hier: