It's never wrong to review that famous and ever-relevant essay, Falsehoods Programmers Believe About Names, and for which there has been oodles of prior discussion on this forum:
Turo was using out-of-date info to validate my driver's license; I had to guess that it wanted the expiration date from before I renewed my license.
An identity check system used for VA loans uses your credit history to come up with secret questions. It's multiple choice and they auto-generate convincing other answers and/or some questions are completely auto-generated "ringers" which you must answer none of the above.
(The questions are things like "Which of the following banks have you had a car loan through?" "Which of the following addresses have you had?")
Problem is, I have very little credit history, so the likelihood of getting a question I can answer is near zero. On the other hand, whatever source they're using also has some assumed-real but actually incorrect associations for me (again, because I have little real credit history, the credit check system seems to be "grasping at straws" to generate a report on me).
So I couldn't just answer "none of the above" for all of the questions, because at least 1 out of each batch of 4 was not an auto-generated made up question but a real question asking me to guess what mistaken answer to it they have on file. After several tries / refreshed batches of questions that were all unanswerable, it locked me out of the system.
On the other side of this, if you have a long credit history you just don't remember the answer for many of these things. What was my apartment number 15 years ago? Which county did I stay in for one month while I was in temporary housing waiting for a new job?
Now I had to look them up and have a lot of these written down for whenever I need to do a bank wire.
Suggestion: get and save a copy of your credit report from each of the major credit reporting agencies. They are required by to give you a free copy of your report if you request it, and you can ask for a copy annually [1].
Then when you get a question and you aren't sure if it is one of the "ringers" or one of the ones that comes from errors on your credit report, you can check the reports to help decide.
I've got a similar problem, due to the post office trying to be helpful. Briefly, a neighbor with the same last name as me got married, changed her last name, and her husband moved into her house. Years later they moved and submitted a change of address form. The PO noticed the name on the form did not match the name in their records for that address, but did match the name on my address, assumed I was the one moving, and so it was my address that got changed, not my neighbors. We got it straightened out, but now my credit reports show me being at that other address for a few weeks.
Same in the US. In the US it helps that there are 3 major credit bureaus. When you ask for your free annual report, you have to answer the questions for each.
Unless there is a lot of wrong information in your report, there is a good chance at least one of them won't use the wrong information in their set of questions.
Once you've got one downloaded and saved, you can try again with the others, checking any questions you are unsure about against the first download.
I have the same problems. I am an American who has lived overseas for many years. These questions about my credit history are full of things that I guess are connected with other people. Very frustrating.
The Thai version of this doesn’t require you to enter the recipient name, you just enter a number and a bank ... and it tells you the recipient name for you to check. Pretty fool proof except that it leaks names for bank account details
My understand is that in the US system anyone can initiate transfer out of your account with your routing and account numbers (both are on the check itself so they're not really "secret"), but if they are doing it without your consent they'll get into legal trouble and you can get your money back (but it _might_ take some time to get your money back). As a result most people just shrug it off.
They may get into legal trouble. My mom had her checkbook stolen that was in her luggage and the person used the checking account to pay for an electricity bill. She reported it to the police, but they had more important things to spend time on. When you can use someones else's checking account number to pay for a utility at a fixed location, you probably aren't worried about legal trouble when you are doing it.
That’s correct. I had someone take $40 out of my account this way a while back. My credit union was great about it, refunding my money and generally straightening out the situation for me.
But, in order to fix it, they had to close my account.
This alone was more than $40 in inconvenience for me, but there was literally nothing else that could be done. I had no idea how my account information got compromised (or, even if it was compromised), and I’m not sure what I would have done had my account information been leaked again via the same channel.
Donald Knuth used to write checks in hexadecimal amounts to people who reported errors in his books (I have $7.68) but had to stop because people post photos of the checks online and the numbers printed on them can be used for fraud.
Back then you probably couldn't electronically withdraw money from someone's account with just the account number---it has become more sensitive later.
Here in the US we have Zelle which is okay-ish. Participating banks let link the email and mobile phones you have associated with them, senders just enter those in and it will display the name of the recipient.
It’s not ideal, but at least since banks have KYC to deal with you know the name is correct. I pay our landlady every month via Zelle and it’s a lot better than mailing checks, if nothing else.
The UK has that system too, for the 'pay a contact system' which lets you make small bank transfers by knowing the recipient account holder's phone number. I assume my bank rates limits attempts.
This is one thing the Japanese banking system actually handles pretty well. When you send money, you enter the bank name, branch and account number and it will give you the reading of the name on the account (Japanese names/words can be read in many ways). If you keep trying this on different accounts your bank will disable this functionality and require you to enter the reading on the account to send money to it, until you go into a branch to reset it.
There is definitely similar Japanese-specific issues with specifying readings (especially for foreign names), but this works far better than requiring someone to specify the name exactly on the account to see if it is a match or not. I'm not sure if that would work well in the UK given how much more larger the Faster Payments infrastructure is.
Singapore has this figured out, it's not THAT hard, especially when you have a solid national identity / SSO design.
You can use phone number or national ID number to register and that's all that is needed but you can set a display name freely if you don't want your name to leak via reverse lookup.
Generating QR also is available right in app and accepted pretty much universal via the same app you can check in for contact tracing or logging into government services or banks. Opening an account now is as simple as confirming a personal data sharing request sent to your app - no more paper forms
This is a different issue. It's not about verifying your own identity, it's about verifying the account number when making a payment to somebody else. The name on their account must exactly match the one that you entered or you get a warning.
At least this is explainable by designers not anticipating hard cases.
I remember the shittiest app from HSBC (who, by the way, seem to be sleepwalking their way through retail banking, with no direction from anyone who cares), which asked:
"What is the answer to your chosen secret question?"
It's dumbfounding how awful bank websites are at security. They started with the stupidest conceivable way to implement two-factor--a second clear-text password that is an answer to a very small number of secret questions. Then they limited the secret questions to things people could find out about you on Facebook, then on top of that added secret questions about esoteric crap like your father's mother's childhood neighbor's dog's name, secret questions that have answers that vary over time like your favorite song, secret questions that have ridiculous length or punctuation requirements, authentication by SMS, authentication by robocall, and on and on and on. The only thing they absolutely refuse to try is an actual friggin' two-factor app!
There's security theater, and then there's Punch and Judy security puppet shows.
Our banks in Australia try two-factor apps. Every bank has their own unique one, so phone only and the expected app pollution. And then they push you to using a different app on the same phone for your banking (say by having unique features such as push notifications of credit card purposes), which completely defeats the purpose of the TFA app since you can drain the accounts with nothing but the phone and (if you are lucky) a PIN number.
That's equivalent to asking you to enter a second password. It's OK and more secure than hinting about that password (example: the name of a city, the name of a woman, etc)
I remember that in a similar case I generated a random string with my password manager but I don't remember
for which account. I hope it was one for I'll never have to spell that on a phone.
Then why not just say, "use a 2nd password"? You now have to remember your question, remember the format (with spacing, capitalization, etc) that you used?
Ah, about 12 years ago, in India they used to have people choose two passwords. You would fill out the primary password in full, and then fill in specific characters (1st, 4th, 7th for eg) of the second password as a "second factor." I used to have to type out the full password on an editor and then fill in the right values.
They also sent out a free RSA token for logins when they deprecated this system. It was first sent to "privilege banking" customers like me. And then they forgot that they sent them out, and tried to get me to pay for a new one. They were insistent that the token wasn't sent out at all. Ended up cancelling that credit card.
We have a very similar system in Canada called Interac, which works well enough. All you need is the registered email or phone number of the recipient and it will grab all the rest of the info, no matter who they bank with.
This is clearly a usability vs security decision. The advantage here seems to be that you can receive payments without registering your email, which seems like a nice feature to have. I wouldn't have to keep track of yet another money transfer service (there's already paypal, vemo, zelle), and it's one less account that could get hacked in the future. Also, considering that the recipient's email was probably hacked (how else were they able to get ahold of the email?), even having a mandatory email registration system wouldn't necessarily prevent the fraud from happening. The attacker could re-register your email address to his account, and since he controls your email, he could also approve any verification emails.
Australian banks have a system called osko/pay id. You register with your bank a phone number or email I think. And when someone transfers money using your phone number you get a confirmation of their name.
As a sanity check it’s not a bad system. If you’re expecting you send money to a John Doe it makes sense to be able to tell the bank this so they can compare and come back with “uhh this account is owned by a Mary Sue, are you sure?” As far as catching mistakes I’m sure it’s fantastically good. The odds that a mistyped account number happened to land on someone with the same name is probably vanishingly low.
And that really seems to be all this is except that it uses the naivest process to do the check.
If we're willing to deal with the 'wardialing account numbers' factor, I think the right flow is "enter account number, SHOW associated name, and make customer confirm it (i. e. by transcribing it off the screen if it's a huge transfer, or just click "Yes, I meant to send to Scamco Ltd.") That avoids the usability nightmare of "the name on file is wrong but not in a guessable way."
I have pretty close to the simplest case for Western-style names-- no middle name, no hyphenation, no suffix or odd prefix, short, common first name, dictionary word last name. The number of times it gets recorded wrong is unbelievable.
The bank numbers we use in Europe (IBAN) have checksums so you will probably not end up sending your money to a wrong account (at lrast if you type one wrong digit or invert two digits).
This. It's a pain in the ass and I've been bitten by it several times. Most recently, trying to transfer funds to my own son. It's a great example of a "good in theory, devil in detail" system.
Barclays does it well: they check and warn but still allow a transaction if names don't match. Santander does it badly: they check and fail, with no way to get around the system if names don't match.
Barclays generally does great UX and Santander sucks, so the above comes as no surprise whatsoever...
Hmm, although it sounds like this was intended to prevent fraud, to me it almost sounds like it was intended to prevent accidental missends, like this:
Now I understand, this is done to protect the banks from the legal fees they might have to cover. (In the linked story bank paid thousands in legal fees). The warning during the transfer also makes sense now. I.e. we provided you with means to check the identity and warned you when we couldn’t confirm it, so the erroneous transfer is now on you.
So the main user of that feature is the bank, not the bank customers.
Japan's banks have a similar system, based on half-width katakana. Fortunately most banks can fetch the name from each other, but sometimes transfers fail due to issues similar to those found in this article.
They're fun, too, in that the ultimate authority for setting the recipient name is on the sender but the ultimate authority for accepting a transfer is the bank of the recipient, which can result in that failure-to-sync causing someone to input a name which cannot be reconciled with the account's owner. (This is particularly common in consumer-to-business payments because even with great attention to detail if you're not doing this frequently the error rate will be a few percent.)
The pull system works in a different but similar fashion, and will (notably) fail if the information submitted with an incremental pull fails to match the name which was handwritten onto the document which sets up the pull (which is circulated at both financial institutions). A gym once received, and I was (in the literal sense) CCed, an icily polite letter from my local bank saying that the bank had no knowledge of a Mr. (close misspelling of McKenzie) and that if the gym had business with customer of the bank it should due him the common courtesy of getting his name right.
It's almost a rite of passage for expats in Japan to be denied some service over name issues.
The length of names is a common cause. In Japan, a normal full name is usually 4 or 5 characters long, with some exceptional cases being slightly longer. Systems often have a character limit which can exclude many non-Japanese names, especially if you have a middle name.
For comparison, the new system setup in Australia allow you to send payments using lots of unique identifiers using a registry. So most banks let me link my bank account to my mobile phone number with various confirmation steps, and that number is all that is required for someone to send me funds. Email address is similarly possible for people (although I haven't seen a bank that has implemented that yet), and business numbers for businesses.
Yes, I find the way ABN Amro implements this to be quite useful. If there's a mismatch between the name I entered and the account name, IIRC I'm required to confirm it before continuing. But it'll never stop me outright as mentioned in the article, which seems like generally wrong-headed approach.
This feels similar to the other irritating assumption banks in the UK and EU make - that you have your phone on you and able to receive messages every time you make an online transaction. Every time I want to buy something online I have to walk down the street to get enough signal to receive a text message. There is no alternative or opt-out. Infuriating.
I'm experiencing a similar problem at Citibank here in the US. When I add a new bill payee, it tries to verify that I am really me. The website does this by asking me specific questions about my past (gleamed from various records) that, presumably, only I would know the right answers to. Among those questions are things like "In what city does your mother live?"
It sounds like a good idea, until I found out that the correct answers are considered to be incorrect by their system. I'm sorry, but I know where my mother lives, and she has lived there for decades. You got your data wrong, that's not my fault. When I answer the question correctly, it therefore locks me out of my account entirely, and I have to call Citibank to get my account unlocked. Helpfully, when you get locked out of your own Citibank account, anytime you try to log in the website delivers a plain-text "HTTP 403 Error" without any explanation. I had to deduce myself that it was because I "incorrectly" answered the question about me correctly.
I asked Citibank's customer service how to resolve this. I was eventually routed all the way to the top of their organization. Their best answer was that I should file a request with LexisNexis, the huge corporation that aggregates these data records on people using automated tools, to have the "official" answers changed.
That made me laugh. They want to place that burden on me?
So now I just do the whole dance every time I need to add a bill payee. Answer their questions correctly, get locked out because they think it's incorrect, then call customer service to get my account unlocked and to add the payee manually.
https://news.ycombinator.com/item?id=1438472
https://news.ycombinator.com/item?id=12450825
https://news.ycombinator.com/item?id=21492464
Original at https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-...