Dat is dus precies het probleem waar ik al op doelde in:
https://www.security.nl/posting/885371/ING+hoeft+slachtoffer+van+bankhelpdeskfraude+geen+30_000+euro+te+vergoeden
Zo maak je het er dus niet veiliger op.
Maar wel gemakkeleuker...

Of zelfs de afwijking als 'juist" betitelen, want b.v. in het Duits mag je een umlaut altijd vervangen door de gewone letter met er een 'e' achter.

Het zou dan ook gebruiksvriendelijker zijn als je de juiste tenaamstelling zou zien als je een rekeningnummer hebt ingevuld.
En voor diegenen die niet willen dat hun naam bij een rekening wordt getoond, moet je maar een opt-in systeem maken, met als consequentie dat zij hun naam net zo zorgvuldig moeten opgeven als hun rekeningnummer om geld overmaken mogelijk te maken.

Dit is simpel op te lossen:
De opgegeven naam word naar de ontvangende bank gestuurd die dan zelf checkt of het overeenkomt. Doet het dat helemaal niet, dan word er een "FALSE" teruggegeven. Is de naam wel juist of bijna juist, dan word er een "TRUE" teruggegeven met de exacte naam. Daarbij kan de gebruiker het verschil zien en accepteren of weigeren. Op deze manier zal de gebruiker enkel de naam te weten te komen als hij die al weet. Hierdoor blijft de privacy behouden.

Jawel, nu krijg je een signaal " Let op er komt iets niet overeen", dat kan fraude zijn maar ook een typefout, als je dan toch doorzet is het je eigen verantwoording

Je zult maar degene zien die cash geld krijgt, privacy inbreuk dus verboden. Ergo gebruik van cash moet wegens privacy verboden worden. De onzin van het privacy idee in een notendop.

Maar dan kun je geen geld overmaken als je de juiste tenaamstelling niet weet omdat het bedrijf of instantie die niet (zoals de belastingdienst) of onduidelijk heeft opgegeven.

Dat soort fuzzy matching is voor software erg lastig.

Inderdaad heeft Duits de umlaut die naar letter+e transformeert, de ringel-S die dubbel s mag worden.

Het is (ook) een ramp in filesystems die op FS niveau "case insensitive" willen zijn , bedacht door mensen die alleen maar us-ascii kennen en dan denken "makkelijk toch" .
Ook alfabetisch sorteren wordt in veel talen al lastig om die reden.
Maar dat is nog deterministisch .


Ken je alle voorletters van je contact uberhaupt -

Stel, ik ken een "Kees van Beinum" . C J M G van Beijnum , matched dat ?

Diverse bedrijven hebben - logisch/terecht, en misschien ook verplicht - hun volledige firmanaam als tenaamstelling.
Dat kan ook best een mondvol zijn , waar ik alleen de korte versie (fietsenmaker <naam>) van ken, zonder "Fa Gebr <naam> rijwielherstellers VOF"


De mensen die hier zo makkelijk denken een "zero knowledge verificatie" te "designen" moeten gewoon eens opletten op (al) hun rekening contacten, zelf wat gaan zitten coden hoe ze (zouden) matchen en dan zich voorstellen hoe goed dat gaat werken.

Levenshtein distance. Problem solved.

Dat is ook gebruiksvriendelijker voor mensen die er misbruik van maken, bijvoorbeeld scammers die daarmee makkelijk namen bij rekeningnummers kunnen vinden en zich dan geloofwaardiger voor kunnen doen als ze iemand oplichten. Dat blokkeren maakt de toepassing wat minder gebruiksvriendelijk maar de dienst aanzienlijk klantvriendelijker.

De overboeking wordt niet geblokkeerd, het is een waarschuwing en die kan je negeren. Het idee is dat je wordt geholpen waar dat kan en in de overgebleven gevallen even extra goed oplet of wat je doet wel klopt.

O, als dit op mijn weg was gekomen had ik dit een leuke klus gevonden. Er zijn mensen die van intellectuele uitdagingen houden, die zich zelfs behoorlijk gaan vervelen als het niet zo nu en dan moeilijk is. En er zijn heel wat van dat soort types software gaan ontwikkelen.

Fuzzy matching is trouwens niet lastig voor software maar voor ontwikkelaars. Het aardige van software is dat die inspanning niet telkens opnieuw hoeft te worden verricht: als het resultaat er eenmaal is kan het bij elke controle opnieuw worden gebruikt. Daardoor worden de kosten van die inspanning uitgesmeerd over eindeloos veel naam-nummercontroles, zo veel dat de kosten per overboeking verwaarloosbaar klein zijn.

En zo verschrikkelijk moeilijk is het nou ook weer niet. Een ß kan als ss of sz zijn geschreven, accenttekens kunnen typisch domweg zijn weggelaten. Je kan een tabel van bijzondere tekens met hun vertalingen maken en een algoritme dat zich op die tabel baseert. Er zijn ook voor meerdere programmeertalen library's beschikbaar met namen als "unidecode" die de ascii-tegenhangers van unicode-strings kunnen produceren. Daarmee kan je niet alleen accenttekens verwijderen maar een ascii-representatie van Mandarijn of Sinhalees produceren als je wilt. En library's om gedeeltelijk overeenkomende reeksen te vergelijken zijn ook kant en klaar beschikbaar, elk versiebeheersysteem en elke diff-utility bevat dat soort logica, en die is ook los daarvan beschikbaar; dat wiel is al uitgebreid uitgevonden. Het is zeker even puzzelen om dat allemaal bij elkaar te zoeken, te beoordelen en in elkaar te passen, maar het is echt wel te doen. En wie weet is dat gepuzzel ook allang door een ander gedaan die het resultaat als library ter beschikking stelt.

Volgens mij hoeft dat helemaal niet. Op basis van de IBAN kan je naar het juiste land en meestal zelfs naar de juiste bank routeren, en die heeft de gegevens al dus die kan zonder "real-time uitwisselen" van persoonsgegevens de check uitvoeren en in geval van een mismatch een bounce terug sturen.

Ik vraag me af of dit werkelijk zo'n risico is.
Zelf lijkt het me veiliger als de juiste tenaamstelling wordt getoond, dan kun je ook zelf nog zien dat er mogelijk iets niet klopt.
Als ik bijvoorbeeld belastinggeld naar HHNK wil overmaken en er komt dan
Happy Home Nuts Knutselaars te staan,
dan weet ik dat dit niet goed kan zijn...

Dat is dus precies het probleem:
als je geen juiste tenaamstelling hebt,
kun je toch gewoon geld overmaken met alle risico's vandien (voor jezelf, niet de bank!)
Wil je dat risico niet lopen,
dan moet je dus zelf moeilijk contact zoeken met de begunstigde om de juiste tenaamstelling te achterhalen...

Ik heb het zojuist nog even uitgeprobeerd (bij de ASN en RABO). Als ik een rekeningnummer van de belastingdienst, of van een stichting of bedrijf intyp, met een foute naam, dan melden ze van wie de rekening wel is, precies wat je wil. Bij particulieren doen ze dat niet, dan moet je de naam al voldoende goed weten. Daar zal de AVG achter zitten, en die is er omdat gegevens zo makkelijk misbruikt worden.

Dat is dus alleen als de begunstigde een particuliere rekening heeft opgegeven. Als een bedrijf dat doet is dat raar en als een particulier de rekening van iemand anders opgeeft zonder dat er meteen bij te zeggen is dat ook raar. Je kan kiezen om het risico te nemen of om inderdaad uit te zoeken hoe het wel zit.

Moeilijk? Het is even gedoe ja, en dat is lastig, maar als het voor de zeldzame gevallen dat het gebeurt (ik maak het althans domweg nooit mee) teveel moeite is om zorgvuldig om te gaan met je eigen geld, misschien moet je dan het risico gewoon voor lief nemen en niet zeuren als het misgaat.

Bij de ING werkt dat dus niet goed.
Als ik een rekeningnummer van de belastingdienst invul, komt er geen naam tevoorschijn.
Als ik een foute naam invul komt er bijvoorbeeld tevoorschijn
"Belastingdienst uit Den Haag" (terwijl het Eindhoven is volgens de brief die ik gekregen heb...)
maar als ik invul "Belastingdienst uit Den Haag" wordt dat veranderd in "Belastingdienst"...
Als ik dat vervolgens wil opslaan in mijn adressenboek wordt een ander adres van "Belastingdienst" overgeschreven...

Eerst moet je dan contact zien te vinden en dan krijgen met iemand die jou een antwoord kan geven anders dan "dat kunt u op onze website vinden"...
Als dan uiteindelijk doordringt dat het daar niet te vinden is, wordt er intern iemand geraadpleegd al dan niet door je door te verbinden. En uiteindelijk krijg je dan te horen dat ze het ook niet (precies) weten en of ze je later terug kunnen bellen of mailen...
Dan krijg je iemand aan de lijn die toch het verkeerde antwoord geeft.
Dat is mij te lastig inderdaad omdat het gemakkelijk anders zou kunnen.
EN het kost me geld en tijd ook nog bovendien.

wat er eigenlijk staat dat de banken controle gaan doen welke naam gebruikt wordt overeenstemt. en zo dus potentiele oplichters gaan opsporen zo lijkt mij dat . als er een prive persoon een overschrijving ontvangt met overheid dit of dat of wat dan ook deze aan het licht komen. of meer zichtbaar gaan komen en dan gaat de overheid vermoedelijk de grootst oplichters eerst aanpakken zou ik zo denken en zo die ongewenste praktijken stoppen en die mensen hopelijk eens aan het werk plaatsen.

Nee want in de teruggegeven naam zit een extra 'j'. Het is dus niet de Kees die jij kent.
En nu zie je maar hoe effectief dit systeem is tegen typefouten.

Zo goed werkt dat niet omdat het niet bepaald logisch is.
Zo geven mensen vaak zelf hun tenaamstelling op als:
K. Anoniem terwijl het K Anoniem moet zijn...

Alleen maar de unicode transformaties, en accenten platslaan is verhoudingsgewijs simpel.

Het probleem komt bij de voorstellen waarin de bank alleen maar "goed/niet goed" teruggeeft bij een mismatch.

Een onterechte match goedkeuren legt dan de verantwoordelijk behoorlijk bij de bank, en een onterechte mismatch geeft enorm snel frustratie bij de overboeker "grrrr. ik schrijf het verdomme toch goed genoeg, dit is 100% zeker de rekening" .

En onvermijdelijk schuift het percentage fouten van de ene naar de andere kant, afhankelijk van hoe strict (of niet strict) je de matching maakt.

Er zal best een mooi test-corpus te maken zien (of gemaakt zijn) door banken die kunnen vergelijken wat ingetikt wordt en wat de werkelijke tenaamstelling is.

Als je gewoon de gelijkende benaming laat zien en zegt "weet je zeker dat je naar ..." wilt overboeken zit je niet vast op de laatste procenten perfectie .

Een begin stap is m.i. het Soundex algorithme van Knuth .

Nee, nu zoek ik me de tering waarom het niet wil overboeken.
Alleen maar omdat ik even niet meer wist (of niet kon horen aan de telefoon) dat die kerel z'n achternaam ook een j bevat.
Ik noem 'm altijd gewoon Kees.

(en ik had dit voorbeeld natuurlijk bewust zo verzonnen).

Smit Smid .
Stadt.
(de) Visscher . Visser

Dit had al een feature vanaf day 1 moeten zijn. En persoonlijk vind ik dat wanneer de gegevens niet matchen je er ook niks aan kan overmaken. Wie kan daar nou op tegen zijn?

Het werkt maar een kant op hoor.

Hij zoekt geen rekeningnummer op bij een ingevoerde naam, hij controleert of de door jou ingevoerde naam bij het door jou ingevoerde rekeningnummer hoort.

Dus spellen, dialecten of wat dan ook is allemaal niet van toepassing op een rekeningnummer. En dat zal je toch echt zelf moeten invullen.

Maak je eigenlijk ooit wel eens geld over? We hebben het systeem al jaren in Nederland. Het onderscheid dat gemaakt wordt is tussen niet twee maar drie mogelijkheden: goed, bijna goed en niet goed. En goed slaat daarbij op hoe goed de match is, de overboeking wordt NIET geblokkeerd als als de match slecht is.

Dit gaat over het uitbreiden van wat in Nederland al gedaan wordt naar (nu) België en (uiteindelijk) Europa. Gaat het in Nederland zo slecht of neem je aan dat ze vooral niet zullen overnemen wat hier goed gaat?

Juist als je geen rekening hoeft te houden met allerlei accenten en andere omzettingen is het vrij simpel: hoeveel tekens komen overeen met de bekende naam en staan ook in de juiste volgorde, en hoeveel tekens wijken af? Je kan uit die getallen een score berekenen die je weer kan afbeelden op goed, bijna goed en niet goed. Mogelijk worden initialen apart behandeld, dat kan het wat ingewikkelder maken. Het simpelweg weglaten van accenten is inderdaad niet moeilijk, maar een ß kan zijn vervangen door s, ss of sz, de Griekse phi kan als f of ph worden weergegeven in ons schrift, en Griekenland is ook een EU-land. Meerdere mogelijkheden en verschillende aantallen tekens die goed kunnen zijn, dat zal het lastigste deel van de vergelijking zijn. Maar als je weet welke typen situaties voor kunnen komen dan kan je een algoritme maken dat per type alle gevallen van dat type aankan, met verder alleen nog maar een tabel die de werkelijk voorkomende combinaties bevat. Dat is even een uitdaging, als het er niet al gewoon is, maar ik zou daar zelf uitkomen (zeker toen ik jonger was, ik ben nu niet meer zo scherp als een half leven terug) en ik ben echt niet de enige. En als het eenmaal is gemaakt dan is het er voortaan.

Nogmaals, de overboeking wordt NIET geblokkeerd. En heb je wat je beschrijft zelf ooit meegemaakt? Hoor je er anderen ooit over? Lees je in de kranten over hoe slecht en frustrerend het werkt? Laat dat dan even weten, zelf ben ik dat soort dingen niet tegengekomen.

Als dat onvermijdelijk is moet je dat ook in werkelijkheid zien gebeuren. We hebben dat systeem al jaren. Zie je dat ook echt?

Je maakt de indruk dat je zelf domweg nog nooit geld naar iemand anders hebt overgeboekt, of dat je nog niet op het idee bent gekomen om de bezwaren die je bedenkt te vergelijken met hoe je zelf kan zien dat het werkt. Dit is niet iets uit een alternatieve werkelijkheid, we HEBBEN dit systeem al jaren in Nederland. Je KRIJGT een waarschuwing en de overboeking wordt NIET geblokkeerd. Dat "als" van je is hoe het allang werkt. Negeer dat niet, neem het mee in je oordeel.

De in het artikel genoemde percentages zijn trouwens geen kleinigheid: 81% minder fraudegevallen en 67% minder vergissingen. Had je dat meegewogen in je oordeel erover?

Blijkbaar lees jij de commentaren niet goed, want dat is nu juist het probleem.
Want dan ligt de verantwoordelijkheid bij degene die het geld wil overboeken.
En zoals ik al eerder als voorbeeld heb aangegeven (lees dat eerst maar eens)
krijg je dan met bijvoorbeeld het overmaken naar de Belastingdienst problemen.
En gezien het feit dat er bij de Belastingdienst sprake is van omgekeerde bewijslast,
dat wil zeggen dat jij moet bewijzen dat dat jij geen fout hebt gemaakt
met alle gevolgen vandien (zie de Toeslagenaffaire...)
wil je toch zeker weten dat jij het geld goed overmaakt.

Toch zal een leverancier van gebruikte slipjes het prettiger vinden niet met naam en toenaam zichtbaar te zijn.
Sexwerkers idemdito. Je mag van haar best haar gezicht zien, ook wel meer, maar het is onnodig haar godganse doopceel te kunnen achterhalen. En andersom, onnodig om enkel om deze reden i.p.v. eenmanszaak (m/v/x) een flex-BV te moeten oprichten.

Maar ook anderen zullen het prettig vinden onnodige informatie te moeten verstrekken om een betaling mogelijk te maken. Of gewoon als ZZP'er om niet in het weekend lastig gevallen te worden over de afwijkende kleur van keukenkastdeurtjes.

Ik vind "een gezicht zien" nog steeds iets anders dan een voornamen en achternamen moeten verstrekken.
Helemaal als je een namen draagt waar er volgens wikipedia slechts twee van bestaan in Nederland.

Dus je vergelijking gaat nogal mank, omdat je ineens niet de nadere -onnodige- identicatie in de weegschaal gooit.

Dus waar gaan we de grens trekken?
Voorletters of volledige voornamen? En waarom ook geen geboortedatum en BSN?
Bedenk dat het niet ook zomaar was dat BTW nummers eindelijk vervangen zijn door BTW ID's.

Ook op Marktplaats zien we dit. Mensen die geen IBAN wensen te verstrekken, en daar een partij tussen zetten die de privacy waarborgt. Een dienst aan de verkoper, waar men overigens klakkeloos steevast de koper voor laat opdraaien, à € 0,40
Essentie daarvan is dat dus zelfs mensen niet hun IBAN willen prijsgeven voor het ontvangen van een betaling.

Marktplaats is niet zoals een bank verplicht: jje kunt dus zelf kiezen of je daar aan meedoet.
Hier gaat het erom dat je bij het invullen van het IBAN nummer de juiste tenaamstelling zou moeten zien.
Wat daar het probleem van is, zie ik niet zo.

Correct, ik gaf het slechts aan ter illustratie hoezeer de wens om privacy zichtbaar is.
Maar inderdaad, hetgeen jij zegt is een feit, en met dat detail je hebt mijn complete verhaal ontkracht ...aldus jouw conclusie.
Ik blijf dat een vreemde manier van discussie voeren vinden, daar jij zelf ook wel weet dat zo'n trucje doorzien wordt.
Ikzelf (11:01) mis dus nog wel enige argumenten, om tot jouw conclusie te kunnen komen.

Omdat, zoals beschreven, anderen mensen dan jij een volstrekt legitieme reden kunnen hebben om niet met naam en toenaam bekend te zijn bij een betalende partij.
Maargoed, ook dat is al een non-discussie, nu er inmiddels in de EU enkele banken bestaan die dat wel begrijpen èn durven toe te geven, èn hun nek wensen uit te steken. Daar kun je middels een pseudoniem bankieren, zonder dat een client als natuurlijk persoon daarvoor een juridisch vehicle nodig heeft.
Iedereen blij, en computer says yes.

Laat ik het dan anders formuleren:

Als jij mij jouw bankrekening opgeeft om een betaling aan jou te doen,
wat is dan het probleem dat ik de juiste naamstelling daarbij te zien krijg,
in dit geval dus bijvoorbeeld
A Noniem, A. Noniem. A N Oniem, Anders Noniem of wat dan ook,
in plaats dat ik daar zelf maar naar moet raden wat het precies is.