I've been thinking about the electronic transfer system in Australia and have decided it's unnecessarily prone to mistakes. A payee can give the payer wrong BSB and/or account identifier details and the payer can likewise make entry errors.
ASICs' current recommendation for banks warning of mistaken internet payments in its ePayments Code (http://download.asic.gov.au/media/3798542/epayments-code-pub…) is written thus:
25 On-screen warning
25.1 A subscriber must clearly warn users about the importance of
entering the correct identifier and the risks of mistaken internet
payments, including that:
(a) the funds may be credited to the account of an unintended
recipient if the BSB number and/or identifier do not belong to
the named recipient, and
(b) it may not be possible to recover funds from an unintended
recipient.
My understanding is that the account name field is not taken into consideration by banks during internet transfers since updating current systems to implement this is considered expensive (perhaps this will change with the real-time payment system being introduced and expected to be implemented late next year, but I've read nothing to suggest that - http://www.apca.com.au/about-payments/future-of-payments/rea…).
I'm considering proposing to ASIC that an extremely simple, optional validation system be implemented that could prevent simple user error mistakes from occurring.
For example, take this sample account:
BSB: 923111
Account: 012345678 (0 added to front to force 9 digits)
Concatenate the BSB to the account number: 923111012345678
Perform a crc32b hash of 923111012345678: ada77604 (used http://www.md5calc.com/)
Convert hexadecimal (base-16) hash ada77604 to decimal (base-10): 2913433092 (used http://www.binaryhexconverter.com/hex-to-decimal-converter)
Take last 4 digits of decimal hash 2913433092 as a validation code: 3092
When a payee provides account details they can also specify this validation code to be optionally entered into their banking software for peace of mind, with a much lower statistical probability of user error. This is not at all intended to provide an extra layer of security but to save people from needless time-wasting exercises (an improperly entered account may currently take days to resolve - even when BSBs are incorrectly entered and mismatch the account identifiers).
This can easily be implemented instantly in all mobile banking apps and web portals using basic client-side or server-side code and the validation can be performed instantly. The generated validation code is extremely easily to generate. The risk is that a payee could use a third-party app to calculate the validation code of an improperly entered account number/BSB combination, but this is against their own interests.
Using a secondary code is nothing new and could provide an extra level of certainty where human error is especially likely but account details cannot be publicly verified in real-time (like with paypal.me). Something as simple as registering an Opal card uses a (probably) non-predictable validation code to provide an extra level of security. This proposed system isn't intended for security (who doesn't want to receive accidental money…) but for user confidence.
What are the obvious flaws?
This is a nifty idea, especially as it can be implemented as an option without getting multi-party agreement.
I had a long conversation at a party with a bloke that was heading up the project for the new payment system you linked to for one of the big four banks.
He advised there wasn't any practical way to make changes to the existing system, as getting all the banks to agree was like herding cats, and they all had a preference for spending any resources on the new system.
Also that they wanted to harmonise systems so end users find them easier. He quoted some figure I thought was shockingly high about people who have never made a transfer, and another about people who make them only in-person at the bank as opposed to online. We didn't talk about mutli factor auth, but I am sure he would have articulated a preference for fewer steps/checks so as not to make it too hard for nervous users.
He advised the new system was going to have some pretty neat features. My conclusion was it would become similar to paypal in terms of ease of use, but with the benefits of bank transfer (low fees, limited repudiation).
He said he thought it would make it in time for next year (this was in Feb 16), but with software projects, who can really say this far out.