We’ve received a lot of questions regarding the legality of submitting one’s personal bank login details to Raiz in order to use our Round-Ups feature, so we thought we would try to explain the ePayments Code, which the Australian Securities & Investment Commission (ASIC) administers on behalf of its subscribers, the banks and institutions. To see if your financial institution is a subscriber, you can view a list on ASIC’s website.

We recommend you keep reading, but if you can’t be bothered with the legal mumbo jumbo, here’s the take home message:

Having researched ASIC’s ePayments code, we can tell you that using your internet banking login details with Raiz should not void any terms and conditions with your bank.

To quote ASIC’s site directly:

Almost all banks, credit unions and building societies in Australia are subscribers to the ePayments Code. Other providers of consumer electronic payment facilities such as PayPal have also subscribed to the code.

Among other things, the ePayments Code:

·         requires subscribers to give consumers clear and unambiguous terms and conditions,

·         stipulates how terms and conditions changes (such as fee increases), receipts and statement need to be made

·         sets out the rules for determining who pays for unauthorised transactions, and;

·         establishes a regime for recovering mistaken internet payments.

Most of the questions we have received come from customers who believe that entering one’s login details into the Raiz app will make them liable for any losses in their account. This is false.

Entering banking login details into the Raiz app to create round-up opportunities will not see you become liable for unauthorised transactions because:

(a)        the user expressly appoints Raiz and Yodlee to collect information on the user’s behalf only (i.e. Raiz and Yodlee have “read only” access to the user’s bank account. They cannot effect transactions); and

(b)        Raiz and Yodlee protect the data using encryption and bank standard security measures to keep it safe.

Raiz uses industry-standard security like 256-bit SSL encryption of sensitive information, redundant backups, and disaster recovery planning. Even in the incredibly unlikely event that all these measures fail, customers of Raiz are insured against fraud & cyber-crime. This insurance does not invalidate the liability of your financial institution, so you are protected against liability and loss.

In conclusion, Raiz and its use of a transaction aggregator to retrieve round-ups on your behalf, we believe, is in compliance with ePayments Code as outlined by ASIC. You will not be forfeiting any protection by using your online login with Raiz. Stay safe out there, and continue to be smart about with whom you share your sensitive information.

We appreciate your trust and loyalty. We promise never to abuse it.

Source: ePayments Code – http://asic.gov.au/for-consumers/codes-of-practice/epayments-code/

Relevant excerpts below:

unauthorised transaction means a transaction that is not authorised by a user

…

9 Scope Transactions not authorised by a user

9.1 This Chapter applies to unauthorised transactions. It does not apply to any transaction that is performed by a user or by anyone who performs a transaction with the knowledge and consent of a user.

…

10 When holder is not liable for loss

10.1 A holder is not liable for loss arising from an unauthorised transaction if the cause of the loss is any of the following:

(a) fraud or negligence by a subscriber‘s employee or agent, a third party involved in networking arrangements, or a merchant or their employee or agent,

(b) a device, identifier or pass code which is forged, faulty, expired or cancelled,

© a transaction requiring the use of a device and/or pass code that occurred before the user received the device and/or pass code (including a reissued device and/or pass code),

(d) a transaction being incorrectly debited more than once to the same facility, and

(e) an unauthorised transaction performed after the subscriber has been informed that a device has been misused, lost or stolen, or the security of a pass code has been breached.

10.2 A holder is not liable for loss arising from an unauthorised transaction that can be made using an identifier without a pass code or device. Where a transaction can be made using a device, or a device and an identifier, but does not require a pass code, the holder is liable only if the user unreasonably delays reporting the loss or theft of the device.

10.3 A holder is not liable for loss arising from an unauthorised transaction where it is clear that a user has not contributed to the loss.

…

12 Pass code security requirements

Pass code security

12.1 Clause 12 applies where one or more pass codes are needed to perform a transaction.

12.2 A user must not:

(a) voluntarily disclose one or more pass codes to anyone, including a family member or friend,

(b) where a device is also needed to perform a transaction, write or record pass code(s) on a device, or keep a record of the pass code(s) on anything:

(i) carried with a device, or

(ii) liable to loss or theft simultaneously with a device, unless the user makes a reasonable attempt to protect the security of the pass code, or

© where a device is not needed to perform a transaction, keep a written record of all pass codes required to perform transactions on one or more articles liable to be lost or stolen simultaneously, without making a reasonable attempt to protect the security of the pass code(s).

12.3 For the purpose of clauses 12.2(b)–12.2©, a reasonable attempt to protect the security of a pass code record includes making any reasonable attempt to disguise the pass code within the record, or prevent unauthorised access to the pass code record, including by:

(a) hiding or disguising the pass code record among other records,

(b) hiding or disguising the pass code record in a place where a pass code record would not be expected to be found,

© keeping a record of the pass code record in a securely locked container, or

(d) preventing unauthorised access to an electronically stored record of the pass code record. This list is not exhaustive.

12.4 A user must not act with extreme carelessness in failing to protect the security of all pass codes where extreme carelessness means a degree of carelessness that greatly exceeds what would normally be considered careless behaviour.

Note 1: An example of extreme carelessness is storing a user name and pass code for internet banking in a diary, BlackBerry or computer that is not password protected under the heading ‘Internet banking codes’.

…

12.9 Where a subscriber expressly or implicitly promotes, endorses or authorises the use of a service for accessing a facility (for example, by hosting an access service on the subscriber’s electronic address), a user who discloses, records or stores a pass code that is required or recommended for the purpose of using the service does not breach the pass code security requirements in clause 12.

Note 1: For example, if a subscriber permits users to give their pass code(s) to an account aggregator service offered by the subscriber or an associated company, a user who discloses their pass code(s) to the service does not breach the pass code security requirements in clause 12.

13 Pass code security guidelines

13.1 A subscriber may give users guidelines on ensuring the security of devices and pass codes in their terms and conditions or other communications.

13.2 Guidelines under this clause must:

(a) be consistent with clause 12,

(b) clearly distinguish the circumstances when holders are liable for unauthorised transactions under this Code, and

© include a statement that liability for losses resulting from unauthorised transactions will be determined by this Code, rather than the guidelines.

…

15 Network arrangements

15.1 In clause 15:

merchant acquirer means a subscriber that provides a service to merchants that enables them to accept/receive electronic payments

party to a shared electronic payments network includes retailers, merchants, communications services providers and other organisations offering facilities, merchant acquirers and subscribers

15.2 A subscriber must not avoid any obligation owed to users under this Code on the basis that:

(a) it is a party to a shared electronic payments network, and

(b) another party to the network caused the failure to meet the obligation.

15.3 A subscriber must not require a user who is their customer to:

(a) raise a complaint or dispute about the processing of a transaction with any other party to a shared electronic payments network, or

(b) have a complaint or dispute investigated by any other party to a shared electronic payments network.