Sometimes all it takes is a missed keystroke to see people wrongfully parting ways with their money. One suggestion is that erroneous transfers could be curbed by requiring consumers to enter the details of a transfer twice, but CHOICE believes a more onerous double-entry system won’t fix the problem. Instead, more needs to be done to help customers recoup the money that is lost.
What are your thoughts?
If a consumer makes the error why would the bank be responsible for correcting it? One might use a card charge back facility as a model, but the cards charge the merchants and their customers so that is not free. Further, the recipient could have already taken the money and run. If an error is claimed, was it fat fingers or scamming the bank and the recipient and what is the process to tell? I don’t think I need to elaborate as retrieving money introduces many complex questions, many with no practical answers.
But to the point of making it better, I have always been amazed how easy it is to fat finger, and how there is no leave given to even enter and display accounts as we customers see them on our statements. Regardless whether the number is shown on an account as 1234 123456 12345 (eg Amex) or 1234 1234 1234 1234 (other cards) or 123 12345 123 123 1234 (an ATO PAYG) it almost always gets entered and displayed as 12345678901234567… making it Very hard to notice a fat fingered entry.
It is not a difficult task to let a customer enter a number with embedded spaces and display it back that way for verification, and pack out spaces behind the screens for final processing to meet the network requirements.
A small job for the web programmers, a modest but useful help for the customer?
I agree with @PhilT, why would banks be interested in correcting the error. To me it is like dropping a $100 note immediately after withdrawing money from an ATM and then expecting the bank to reimburse the lost money.
Also $11 million is very small amounts of money compared to the total amount of money subject to transfers/payments.
I think the double entry would be okay as a fallback position to reduce chance of entering the number incorrectly twice.
I think a far better option would be to split any number into groups of 4 or 5 integers and then having the webpage having 4 or 5 integer entry cells. This occurs already for say software keys and some credit card payment websites.
For example, rather than:
395345934789669035690
the number could be presented on documentation as:
3953 4593 4789 6690 3569 0 or 3953-4593-4789-6690-3569-0
OR
39534 59347 89669 03569 0 or 39534-59347-89669-03569-0
If the payment/banking website is standardised and therefore had entry in same format, then I believe it would substantially reduce likelihood of an error.
Also nominating a minimum font point size would be also useful so that the numbers are not presented small.
I find when I have a long number block, I manually break the number up into 4 integers using a pencil and then typing them in. I then also check each four number sets entered to confirm there are no errors.
A timely article about a timely new feature!
http://thenewdaily.com.au/money/your-budget/2017/05/16/payid/
@PhilT agreed - for once it’s not really the banks responsibility, but yes they could make it easier.
Given many of them can’t even handle a postcode with a leading zero, I doubt theres much hope. The banks I’ve used online don’t seem to be able to even handle space or dash padded numbers, even in the bsb in one case. I don’t have much faith in coders or code testers generally but web coders seem to be special …
One of the credit unions I’ve dealt with has an amazingly stupid way of protecting against the likelihood of transfers working at all - by rejecting any transfer that doesn’t have a fairly close approximation of the recipients account name in the transfer description field, regardless of the fact that bsb and account number are correct. After three tries (yes I should have suspected something sooner) and three bounce fees I checked with the recipient who checked with their credit union and sure enough, yes they were rejecting a perfectly valid transaction because the description wasn’t the account name … and no they wouldn’t refund the fee, and neither would my bank. Utter muppets. So maybe be a little careful asking the banks to make it more resilient, its possible they’ll just make it more painful.
The fee seems wrong, but a devils advocate question, how would the destination bank know whether the account was correct or the name was correct and how would you have reacted if they got it wrong and you had to argue to get your money back, or perhaps could not get it back?
The fat fingers could easily enter 12345 instead of 12344 for the account, but if 12345 was Big Company P/L and 12344 was My Partner, and what got entered was 12345 to My Partner, was this a family transfer or a bill payment, and to whom and how does the system figure out your intentions? Now substitute 12344 for account Birthday Cake, seems the same problem.
My view is the BSB/Account combination should be enough. In my case I knew the BSB and account number were correct, my mistake was to try a few times knowing this and not figuring out that there was muppetry in the receiving system.
I always try to pay companies/bills by credit card or BPay - where I have to do a transfer I always cut and paste if possible and double check everything regardless. With personal transfers I always do a tester first, save the account as a shortcut/address book then do a small amount as part payment - my risk is limited to a few dollars - then pay the rest from the shortcut. I’ve never actually lost money - had a few bounce here and there from being given wrong numbers, but theres always a first time and I figure for a few dollars it is a good test.
It would be interesting to see some real stats on these kinds of transactions, including losses, to get a relative idea of how big the problem is (including stats on transfers that bounce rather than land in the wrong place).
Whatever the case, $11m is insignificant compared to how much money is stolen, identity theft or lost to scams and miniscule compared to money just lying around unclaimed waiting to be collected - over a billion dollars in Australia in shares, bank accounts and life insurance. Then theres superannuation …
Maybe some subsidised typing lessons and better eyesight testing and I reckon we’d have spent enough on this problem 
I’m flabbergasted that the consensus say its OK for companies who design systems created with accountants, lawyers and the dodgy brothers to make systems that take your money. They often make things unclear and ambiguous. Intentionally - I think so! This is OK? NO its not. I was an ISP until Telstra decided that they wanted to be Australia’s ISP. I created web pages with the bank credit card transactions that were unambiguous and clear and sold $50 to $100 thousand dollars a month - never had a complaint.
Not now - often the pages aren’t tested and frequently fail. It seems that its OK to use the public to test financial systems to find the bugs (and all the other problems).
Its the way of the world - but it shouldn’t be. Consumer Affairs used to control things but now they’re a waste of time…
Best thing to do is study law and treat every business who turns over more than $5,000,000 as a crook.
That’s what we’ve now got. Even the Prime Minister has used Tax havens.
How is that a consensus? Despite poorly designed and implemented systems some of us see a problem to put the onus on a bank to recover money their customer has inadvertently, accidentally, or from lack of care misdirected, for practical as well as legal reasons. OTOH there seems consensus that the systems are poorly designed rubbish, are difficult for consumers, and fail usability.
I was never an ISP or web developer, but did about 40 years in IT from the 1970’s from design and development (scientific applications, operating systems, SCADA, and hardware) through senior management, where my responsibility included a major web delivered service.
A few decades ago “we” could reasonably test software regardless of what it did. A small handful of people could understand every bit of it and had all the code. Today there is so much “magic” in the code (library functions calling library functions, all hidden from view) as well as multiple browsers each with their own eccentricities, plug and play, and so on, in a practical sense no number of coders could know how it all works under the covers; it is complex. A rigorous test we could do in a few weeks could now take a year, and in the interim the platforms will have moved on introducing new variables, fixes, and bugs, so what was the ultimate value? All while management is hot to get the product or update out to customers. That is not to diminish that testing is required, but it is not what it once was. To achieve that would require a complete industry reset including the re-education of generations of coders, and management culture that did not worry much about the competition (what are the chances?).
I remember a now dated (major corporate) study on their software reliability (sorry I cannot find the reference) done after years of increasing customer dissatisfaction re bugs, where the conclusion was their software was never going to have fewer than about 1200 bugs because when they got under about 1200 they tended to inadvertently create new ones. The outcome was that they accepted this and started documenting the bugs including workarounds. Their customer satisfaction went up as a result of 1200 known bugs rather than bugs they had worked around being fixed and sometimes breaking the workarounds, and new bugs being routinely introduced.
We are getting a little off topic but they don’t call modern software ‘bloatware’ for nothing. Its estimated that Windows could reduce in size by 30 -50% in size. Linux does OK, its nice and small and doesn’t break… Testing should still be a prerequisite. Yes coders should take time with their libraries and function calls. I worked in Defense on managing software development networks and have seen how bloatware happens. The reliance on accountants to dictate the human race needs to be reigned in a bit. Its not OK to make stuff that’s ‘wrong’ - broken, unreliable or not fit for purpose; Choice then wouldn’t be for complaining…
Yes the bug testing is not as stringent as it once was. Partly why Open Source does so well in this regard is because of the community who are able to and do tear the code apart and see the faults and report them back.
Proprietary software suffers from a limited checks regime because they don’t like or want reverse engineering of their secret coding but some do try to at least broaden the fault testing by having Alpha and Beta releases so that users can pick up issues before official production releases. Microsoft did and still does this with the Insiders program of Windows 10 but it isn’t quite as rigorous as Open Source, hence the many patches to address issues that may have been addressed early if open.
Agree it should be easy to get a wrong payment back, but double entry wouls surely help . . . . especially if both the account number and the amount were entered twice on different pages and copy/cut and paste locked out. I have only made one mistake with ATO, paying the wrong amount to one of our accounts. At least the money was in the same place and they very graciously swapped the amounts over.
Credit card number are not the issue. (And don’t matter! If you get a digit wrong there, the checksum and/or CCV and/or expiry date will fail. The user immediately knows the number is wrong. If you have enough sense to paste your number in from a file, you have zero chance of getting it wrong unless the site breaks the number into separate fields, forcing you to enter it manually and introducing the chance of error.)
The topic is bank account numbers. Again, the best thing to do is always copy/paste them. Anything that’s hand written or typed from memory has a chance of being wrong.
Those were just used as examples of how account numbers are presented mate, as was the ATO number. Cutting and pasting sometimes works, and sometimes does not because of bad web form programming. And yes, anything manually entered has a chance of being wrong.
Here’s another real-time payment transfer service that will use mobile phone numbers.
I suppose the other option is top subscribe to Bpay View for bills…those companies which offer them. I don’t use it but may also be an option for those who have problems reading and repeating long numbers.
