Commentary on the Laurence O Keefe EFT Disputes Manager Karen Guerinoni Senior Case Manager Prepared for FOS National Conference 16-17 October 2012 Page 1 of 25
Contents 1 Why the need for the? 4 2 What is the? 4 3 What s covered by the? 5 4 What s excluded from the? 6 5 New provisions in the 6 6 Mistaken internet payments 7 6.1 Definition 7 6.2 Compliance requirements 7 6.3 Summary of return process 8 6.4 Relationship with Centrelink Code 8 6.5 Process where funds are available and report is made within 10 business days [clause 28] 8 6.6 Process where funds are available and report is made between 10 business days and 7 months [clause 29] 9 6.7 Process where funds are available and report is made after 7 months [clause 30] 10 6.8 Process where funds are not available [clause 32] 11 6.9 Sending ADI to inform user of outcome 11 6.10 Complaints about MIPs 11 7 Tailored requirements for low value facilities 11 8 Minimum expiry dates 12 9 Book up arrangements 13 10 Leaving a card in an active ATM 14 11 Important definitions in 14 12 Liability provisions of 15 12.1 Liability provisions / Circumstances where holder has no liability 16 12.2 Liability provisions / Circumstances where holder has full liability 17 12.3 Liability provisions / Limitations on full liability 18 12.4 Liability provisions / Limited liability 19 12.5 Effect of charges 19 12.6 Proof that a user contributed to losses 19 12.7 Liability provisions/ Discretion to reduce holder s liability 20 Page 2 of 25
12.8 Unauthorised scheme credit and debit card transactions 20 12.9 Liability provisions / Breaching pass code security requirements 20 12.10 Liability provisions / Protecting the security of a code record 21 13 Relationship between liability provisions and security guidelines 22 14 Complaint procedures 23 14.1 Complaint procedures / Timeframes 24 14.2 Explaining the outcome of a complaint 24 14.3 Complaint procedures / Compensation for non-compliance 25 14.4 Complaints covered by card scheme rules 25 Page 3 of 25
1 Why the need for the? Before consumers gained access to electronic facilities, all account transactions had to be authorised by signature. A manual signature could be subjected to forensic analysis. Therefore, there existed a mechanism to determine objectively whether or not a transaction had been signed by and, therefore, authorised by the account holder. Where a transaction was made with a fraudulent signature, banking law and common law provided that a financial institution usually did not have a mandate to debit a customer s account for such unauthorised transactions, except in exceptional circumstances. With the introduction of pass codes [e.g. PINs and passwords] as authorisation for electronic transactions, the ability to objectively determine whether or not a customer had authorised a transaction was substantially weakened. But the legal principle remained that, if a transaction was unauthorised, the financial institution had no mandate to debit the customer s account except in exceptional circumstances where the customer had contributed to losses. The reflects the legal principle of mandate by setting out a procedure for allocating liability for unauthorised electronic transactions. In the first place, it provides for no liability where it is clear that the user did not contribute to the losses, and full liability where the subscriber (that is, the financial institution) can prove on the balance of probabilities that the user did contribute to the losses in certain limited and specific ways. However, the also provides for limited liability of $150 in cases where the subscriber cannot prove that the user contributed to losses. The Code effectively modifies the mandate rule by allowing that there will be circumstances where a holder has some liability for transactions that they may not have authorised or contributed to, but there is insufficient information to make that clear. There will be other circumstances in which a user may have contributed to losses but the subscriber still has to limit liability because there is insufficient information for the subscriber to prove its case. Many electronic banking disputes fall into this unclear category. 2 What is the? The (the Code) has been designed as a technology neutral code of practice covering all forms of consumer electronic funds transfers. The responsible authority is the Australian Securities and Investments Commission (ASIC). Following an extensive review of the former Electronic Funds Transfer Code of Conduct (EFT Code), ASIC published the on 20 September 2011. Subscribers must comply with the Code by 20 March 2013. Page 4 of 25
Compared to the EFT Code, features of the include: It is restructured, and redrafted in plain English; and Includes some new provisions, including for mistaken internet payments, low value facilities and facilities with an expiry date. ASIC confirmed in its Consultation Paper 158 dated May 2011 that Redrafting the Code in plain English is not intended to diminish the consumer protections afforded by the Code in any way. The is a voluntary code of practice. It is only binding on providers of electronic payment facilities to consumers who advise ASIC that they have subscribed to the Code. 3 What s covered by the? The Code applies to payment, funds transfer and cash withdrawal transactions that are initiated using electronic equipment, and not intended to be authenticated by comparing a manual signature with a specimen signature (Clause 2.4). Clause 2.5 gives examples of transactions covered by the Code. In banking terms, they include Electronic card transactions, including credit card PIN@POS; Contactless card transactions, not requiring a PIN; Telephone banking transactions; Internet banking transactions; Online bill payments, including BPAY; Card transactions effected by quoting card number and expiry date over telephone or internet; Direct debits; Mail order transactions not intended to be authenticated by comparing a manual signature with a specimen signature; and Transactions using mobile devices. Page 5 of 25
4 What s excluded from the? The following transactions are not covered by the Code: Business transactions, i.e. transactions performed using a facility that is designed primarily for use by a business, and established primarily for business purposes [clause 2.1(a)]; For example, transactions on a business cheque account opened in the name of a business would not be covered by the Code. But if a business owner used their personal credit card account to charge transactions on behalf of the business, such transactions would be covered (provided they were not intended to be authenticated by signature). Similarly, if a sole trader operated a small business through a consumer cheque account, electronic transactions would be covered. Transactions performed using a facility where the holder and the subscriber do not have a contractual relationship [clause 2.1(b)]; For example, a mistaken internet payment is covered by the Code in relationship to the sender and the sending ADI, but not in relationship to the sender and the receiving ADI. Signature-authenticated transactions, i.e. transactions that are intended to be authenticated by comparing a manual signature with a specimen signature [clause 2.4(b)]. For example, a cardholder-present credit card transaction, for which the cardholder signs and the merchant has the opportunity to sight the specimen signature on the card, is not covered by the Code. However, a signed mail order transaction, where the merchant does not have the ability to sight a specimen signature, is covered by the Code; likewise, transactions authorised by direct debit even where the direct debit authority is signed are covered by the Code because the merchant or utility would not be comparing the signature on the direct debit authority with a specimen signature. In any event, clause 2.5(g) of the Code specifically provides that direct debits are covered. 5 New provisions in the In addition to what was already in the EFT Code, the includes provisions about: Mistaken internet payments (MIP) Low value facilities Minimum expiry dates Book-up arrangements Leaving a card in an active ATM Page 6 of 25
6 Mistaken internet payments Clauses 24 to 34 of the epayments code contain specific provisions about how subscribers are to deal with an MIP. 6.1 Definition A mistaken internet payment is defined in both clause 2.6 and clause 23.2 to mean:...a payment by a user through a Pay Anyone internet banking facility and processed by an ADI through direct entry where funds are paid into the account of an unintended recipient because the user enters or selects a Bank/State/Branch (BSB) number and/or identifier that does not belong to the named and/or intended recipient as a result of: the user s error, or the user being advised of the wrong BSB number and/or identifier. This does not include payments made using BPAY. A transaction where the user inadvertently selected an unintended payee from an existing list of payees in their internet banking profile would not come within the definition of an MIP, because in such a case the name and BSB/account number would match. The funds might have gone to an unintended recipient, but the transaction would have been authorised by the user. The only remedy available to the holder would be to seek the return of funds from the recipient themself. 6.2 Compliance requirements Preliminary provisions about disclosure requirements, warnings, reporting and investigation include that: T&Cs have to set out the processes prescribed by the Code, including information about the circumstances in which a subscriber will recover funds from an unintended recipient without their consent; and the circumstances in which a holder will be liable for losses arising from an MIP [clause 24.1]. A subscriber must clearly warn users about the importance of entering the correct identifier and the risks of MIPs, including that funds may be credited to the account of an unintended recipient if the BSB and and/or identifier do not belong to the named recipient; and that it may not be possible to recover funds from an unintended recipient [clause 25.1]. Where practicable, the warning must be delivered on-screen, when the user is performing a Pay Anyone transaction, and before the transaction is finally confirmed at a time when the user can cancel the transaction or correct the error [clause 25.2]. Page 7 of 25
A subscriber has to have an effective and convenient process for users to report MIPs; the process has to be free, or for the cost of a local call; and the subscriber must acknowledge the report in a way that enables the user to verify that the report was made and when [clauses 26.1 to 26.3] Where a user reports an MIP, the sending ADI must investigate whether an MIP occurred and, if so satisfied, send a request for the return of the funds to the receiving ADI, which in turn must within 5 business days acknowledge the request and advise whether there are sufficient funds in the account of the unintended recipient to cover the MIP [clauses 27.1 to 27.2]. The sending ADI is not required to take any further action if it is not satisfied that an MIP occurred [clause 27.3]. For example, a sending ADI would not have to take action if the cause of the complaint was that the user had selected a payee from a list of payees in their internet banking profile that was not the payee to whom they intended to send funds. Such a transfer would not meet the definition of an MIP because the BSB/account number would match the named recipient, even if the user had not intended to send funds to that particular recipient. 6.3 Summary of return process Whether or not funds will be returned to the holder after the user has made an MIP depends on a number of factors including: Whether or not sufficient funds remain in the account of the unintended recipient; The period of time that has elapsed between making the MIP and reporting the MIP; and In some circumstances, whether or not the unintended recipient agrees to return the funds. The return process is detailed in the following pages. 6.4 Relationship with Centrelink Code Clause 31.1 provides that where the unintended recipient is receiving income support from Centrelink, the receiving ADI must recover the funds from the unintended recipient in accordance with the Code of Operation for Centrelink Direct Credit Payments. 6.5 Process where funds are available and report is made within 10 business days [clause 28] Clause 28.1 clarifies that the Clause 28 process applies where: Page 8 of 25
the user has reported the MIP within 10 business days of making the payment; and the sending ADI is satisfied that an MIP has occurred and there are sufficient funds in the account of the unintended recipient [based on advice from the receiving ADI] to the value of the MIP. The subsequent process is that: 1. Subject to the above conditions being met, and subject to it being satisfied that an MIP has occurred, the receiving ADI must return the funds to the sending ADI within 5 business days of the request, if practicable, and no later than 10 business days [clause 28.2]. Note that the receiving ADI is not required to obtain the consent of the unintended recipient to return the funds, provided that it is satisfied that an MIP occurred. 2. If it is not satisfied that an MIP occurred, the receiving ADI may seek the consent of the unintended recipient to return the funds [clause 28.3]. 3. The sending ADI must return the funds to the holder as soon as practicable [clause 28.4]. 6.6 Process where funds are available and report is made between 10 business days and 7 months [clause 29] Clause 29.1 clarifies that the Clause 29 process applies where: the user has reported the MIP between 10 business days and 7 months after making the payment; the sending ADI is satisfied that an MIP has occurred; and there are sufficient funds in the account of the unintended recipient to the value of the MIP. The subsequent process is that: 1. The receiving ADI must complete its investigation into the reported MIP within 10 business days of receiving the request [clause 29.2]. 2. If it is satisfied that an MIP has occurred, the receiving ADI must: (a) prevent the unintended recipient from withdrawing the funds for 10 further business days; and (b) notify the unintended recipient that it will withdraw the funds if the unintended recipient does not establish that they are entitled to the funds within 10 business days (from the day the unintended recipient was prevented from withdrawing the funds) [clause 29.3]. Page 9 of 25
3. If the unintended recipient does not establish their entitlement to the funds, the receiving ADI must return the funds to the sending ADI within 2 business days after the expiry of the 10 business day period during which the funds were frozen [clause 29.4]. 4. If it is not satisfied that an MIP occurred, the receiving ADI may seek the consent of the unintended recipient to return the funds [clause 29.5]. 5. The sending ADI must return the funds to the holder as soon as practicable [clause 29.6]. The choice of 7 months as the upper limit for the application of this clause seems to be based on the fact that a subscriber must give a holder a statement of account at least every six months [clause 7.1]. After allowing that statements may be issued only every six months, ASIC seems to have allowed an extra month in which a holder can examine the statement and identify that a mistaken internet payment occurred. Provided that the dispute is notified within 7 months of the date of the transaction, the clause 29 provisions will apply. 6.7 Process where funds are available and report is made after 7 months [clause 30] Clause 30.1 clarifies that the Clause 30 process applies where: the user reports the MIP more than 7 months after making the payment; the sending ADI is satisfied that an MIP has occurred; and there are sufficient funds in the account of the unintended recipient to the value of the MIP. The subsequent process is that: 1. If the receiving ADI is satisfied that an MIP occurred, it must seek the consent of the unintended recipient to return the funds [clause 30.2]. 2. If it is not satisfied that an MIP occurred, the receiving ADI may seek the consent of the unintended recipient to return the funds [clause 30.3] 3. If the unintended recipient consent to return the funds, the receiving ADI must return the funds to the sending ADI; and the sending ADI must return the funds to the holder as soon as practicable [clause 30.4]. Note that no time limits are specified where a report is made after 7 months. This is probably because the process depends very much on the co-operation of the unintended recipient. It seems that ASIC regards a delay in reporting of more than 7 months as not being reasonable and that there should be lesser safeguards for the sender in such circumstances. Page 10 of 25
6.8 Process where funds are not available [clause 32] Where both sending and receiving ADIs are satisfied that an MIP occurred but there are not sufficient funds in the account of the unintended recipient to the full value of the MIP, the receiving ADI must use reasonable endeavours to retrieve the funds from the unintended recipient (for example, by facilitating repayments of the funds by instalments) [clause 32.1]. Note that reasonable endeavours are not otherwise explained; so if the unintended recipient does not respond to a request for the return of funds or is otherwise noncooperative, there is not much that the receiving ADI could or should do to retrieve funds, apart from making the request. Consequently, in many cases where funds - to the full value of the MIP - no longer remain in the account of the unintended recipient, it would be unlikely that the sender would retrieve their funds. 6.9 Sending ADI to inform user of outcome The sending ADI must inform the user of the outcome of a reported MIP in writing and within 30 business days of the report being made [clause 33.1]. 6.10 Complaints about MIPs A user can complain to the sending ADI about how a report was dealt with, including that the sending ADI and/or receiving ADI was not satisfied that an MIP occurred, or did not comply with the processes and timeframes. The sending ADI must deal with the complaint and must not require the user to complain to the receiving ADI. If not satisfied with the outcome of a complaint, the user can lodge a complaint with the sending ADI s EDR scheme. [clauses 34.1 to 34.3]. Both the sending ADI and the receiving ADI must cooperate with the sending ADI s EDR scheme, including complying with any decision of that scheme (for example, about whether an MIP did in fact occur) [clause 34.4]. A note to clause 34.4 comments that if a subscriber is unable to comply with its obligations to return funds because the unintended recipient does not cooperate, the user can complain to the EDR scheme of the sending ADI. While the user may have a right to complain, it is difficult to see how FOS could resolve a dispute to the satisfaction of the applicant where failure to return funds is a consequence of the actions of the unintended recipient rather than the actions of either the sending ADI or the receiving ADI. 7 Tailored requirements for low value facilities A low value facility in defined in clause 2.6 as...a facility that is capable of having a balance of no more than $500 at any one time. Page 11 of 25
At the moment, FOS is not aware of any specific banking-related product that would fit this definition. In introducing the concept of the low value facility, it seems that ASIC may be anticipating the needs of other types of organisations who have not subscribed to the EFT Code but who might, potentially, subscribe to the. Such facilities could include a gift card, a telephone card, or a public transport card. Tailored requirements for low value facilities include that: 1. The information to be provided before, or at the time, a user first performs a transaction is [clause 4.4]: (a) if practical, a copy of the terms and conditions; or (b) a notice that highlights any key terms (such as expiry date, or period during which facility can be used, or that the balance will be forfeited if the facility is lost) and explains how to obtain the full terms and conditions; 2. Instead of having a compulsory process for reporting a lost device or a breach of pass code security, a subscriber that issues a low value facility only has to tell holders whether or not it has a process for reporting the loss, theft or misuse of a device or breach of pass code security. [clause 4.9]; 3. Notification of changes to terms and conditions only has to be made directly to the holder if the subscriber knows the identity and contact details of the holder [clause 4.15]. Otherwise, the information can be made available in a way that is reasonably likely to come to the attention of the holder [clause 4.17]; 4. Instead of having to offer a receipt for all transactions at the time of the transaction, it is sufficient to give users [clause 5.8]: (a) a process for checking the balance on the facility; and (b) either a receipt or reference for each transaction, or a process for users to check their transaction history; 5. The provisions about allocating liability for unauthorised transactions do not apply to a low value facility [clause 9.2] In other words, if you lose a low value facility you may lose up to $500. 8 Minimum expiry dates Clause 18 has a number of requirements for a facility that has an expiry date: If a facility is not reloadable and cannot be used after a certain date, the expiry date must be at least 12 months from the date the user activates the facility, unless the user is entitled to a refund at the expiry date [clause 18.1]. Page 12 of 25
If a facility is reloadable and cannot be used after a certain date, the expiry date must be at least 12 months from the date the user last reloaded the facility, unless the user is entitled to a refund at the expiry date [clause 18.2]. A note provides as an example that a Christmas Club account does not have to comply with clause 18.1 if the subscriber refunds the balance of the account to the holder when the account is closed. A subscriber that offers a facility with an expiry date must not unilaterally bring forward the expiry date and must give users a way to check the expiry date [clause 18.3] If a device is needed to perform transactions, the expiry date must either be disclosed on the device, or if the expiry date cannot be ascertained e.g. because it depends on date of activation or date of reload there must be disclosure on the device of the period during which the facility can be used [clause 18.4]. 9 Book up arrangements Book up arrangement is defined in clause 2.6 to mean:...credit offered by merchants for the purpose of goods or services commonly used by Aboriginal people in remote and regional areas of Australia. It is common for merchants to hold a consumer s debit card and/or pass code as part of a book up arrangement. A few years ago, book up arrangements were the subject of a federal government review. ASIC has also published Dealing with book up a guide to assist Aboriginal communities in dealing with this type of credit arrangement. While acknowledging that there is a place for book up in Aboriginal communities, ASIC seems to be concerned that book up arrangements have been or could be abused by merchants, e.g. by merchants withdrawing money from an account without the consent of the holder. Clause 20.1 provides that if a subscriber and a merchant have a merchant agreement, the agreement must prohibit the merchant from holding a user s pass code as part of a book up arrangement FOS has sighted at least one FSP s standard merchant agreement that already includes a statement that a merchant must not request or hold any PINs for their customers. If other merchant providers have similar provisions, the inclusion of clause 20.1 in the epayments Code may not actually provide greater protection for Aboriginal people than is already provided by existing merchant agreements. In any event, FOS considers that holders and users are already protected by the in the event that a merchant conducted an unauthorised transaction by abusing their knowledge of a user s PIN or pass code. This is because of the operation of clause 10.1(a) that provides, among other things, that a holder is not liable for loss caused Page 13 of 25
by fraud or negligence by a merchant or their employee or agent. Clause 10.1(a) takes precedence over the fact that the user might otherwise be considered to be liable under clause 11.2 because they voluntarily disclosed their PIN. 10 Leaving a card in an active ATM Clause 11.4 is a new provision in the that provides that a holder is liable for losses arising from unauthorised transactions that occur because the user left a card in an ATM, provided that the ATM incorporates reasonable safety standards that mitigate the risk of a card being left in the ATM. FOS asked for such a clause to be incorporated in the because the situation was not adequately covered by the EFT Code. However, in most cases, it has been FOS s practice to allocate liability in such circumstances to the account holder on the basis that the user was in control of their card when using the ATM and that it was not reasonable that the FSP should be held liable for the consequences of the user s carelessness. 11 Important definitions in Clause 2.6 contains definitions of a number of terms used in the Code and this Commentary. Important definitions include: Account means an account maintained by a subscriber that belongs to an identifiable holder who is a customer of the subscriber. Subscriber means an entity that has subscribed to the Code. Holder Facility means an individual in whose name a facility has been established, or to whom a facility has been issued. means an arrangement through which a person can perform transactions. Facility can be understood as being comparable to the definition of access method in the EFT Code, though it also seems to overlap with the definition of an account. Device means a device given by a subscriber to a user that is used to perform a transaction, such as a card, a contactless device and a token that generates a pass code. Pass Code means a password or code that the user must keep secret, that may be required to authenticate a transaction or user. It does not include a number printed on a device. The comparable definition in the EFT Code included the content of which is known to the user and is intended to be known only to the user or only to the Page 14 of 25
user and the account institution. Although these words are no longer included, a practical application of the definition should acknowledge that, in some circumstances, a secret pass code will also be known to the provider of the account and the facility. Identifier means information that a user knows but is not required to keep secret and must provide to perform a transaction. Examples of identifiers include an account number, a card number, a security number printed on a card and a customer access number. A holder cannot be held liable for an unauthorised transaction because a user has disclosed or kept a record of an identifier. User means a holder or an individual who is authorised by a subscriber and holder to perform transactions using a facility held by the holder. 12 Liability provisions of The liability provisions only apply to unauthorised transactions. They do not apply to any transaction performed by the user or by anyone who performs a transaction with the knowledge and consent of a user [clause 9.1]. In some cases, the outcome of an investigation will be that the weight of information supports a conclusion that disputed transactions were actually carried out by the user or with the user s knowledge and consent, and that compensation is not appropriate. An example might be a dispute where there are disputed transactions from a joint account, the dispute is driven by one of the joint account holders, the access method belonged to the other joint account holder, and there may be difficulty in obtaining information directly from the actual user. Another example might be where a user/holder has always had their device in their possession, but who disputes transactions possibly some years after they were made because they consider the balance of their facility is less than it should be. While in some cases FOS reaches a conclusion, on the weight of information, that disputed transactions were more likely than not to have been carried out by the user and that the liability provisions do not apply, such a decision is an exception rather than the rule and it must always be supported by sufficient information. With unauthorised transactions, the provides for: No liability in specified circumstances, set out in clauses 10.1 to 10.5; Full liability in specified circumstances, set out in clauses 11.2 to 11.6; and Limited liability of $150 in all other circumstances, set out in clause 11.7, provided that a pass code is required to perform a transaction. The no liability clauses take precedence over the clauses applying either full or limited liability. Limited liability applies where a pass code was required to perform an unauthorised transaction, and where none of the full liability clauses apply. Page 15 of 25
There is an exceptional situation in relation to transactions that can be made with a device, or a device and an identifier, but where no pass code is required. Examples of such transactions are contactless card payments where an RFID-enabled card is tapped against a reader but no PIN entry is required, or other merchant facilities where a card is read but no PIN entry required, such as some low value transactions. Clause 10.2 includes a statement that the holder will be liable for unauthorised transactions made in such a way if the user unreasonably delays reporting the loss or theft of the device. So a holder could be fully liable, on the basis of unreasonable delay in reporting the loss of the card, but the limited liability clause would not apply because a pass code is not required. 12.1 Liability provisions / Circumstances where holder has no liability A holder has no liability for loss arising from an unauthorised transaction if the cause of the loss is any of the following: 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 [clause 10.1(a)]; This clause applies to people such as supermarket checkout operators and taxi drivers with an in-cab electronic terminal, who are associated with a merchant. A device, identifier or pass code which is forged, faulty, expired or cancelled [clause 10.1(b)]; A current example of a forged device is a card that is duplicated by copying magnetic stripe information through use of a skimming device. 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) [clause 10.1(c)]. Note that clause 10.4 provides that where there is a dispute about whether a user received a device or pass code, there is a presumption that the user did not received it, unless the subscriber can prove that the user did receive it (such as by obtaining an acknowledgement of receipt from the user); and proof of delivery to a user s correct mailing or electronic address is not proof that the user received the device or pass code. Clause 10.5 then provides that T&Cs must not deem that a device or pass code sent to the correct address has been received by the user. A transaction being incorrectly debited more than once to the same facility [clause 10.1(d)]; 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 [clause 10.1(e)]; In addition, a holder has no liability for the following transactions: Page 16 of 25
An unauthorised transaction that can be made using an identifier without a pass code or device [clause 10.2]; For example, an internet-based credit card purchase where only the card number, expiry date (and possibly CVV) have to be entered. Loss arising from an unauthorised transaction where it is clear that a user has not contributed to the losses [clause 10.3]. 12.2 Liability provisions / Circumstances where holder has full liability Where none of the no liability provisions of clause 10 apply and where a subscriber can prove on the balance of probability that a user contributed to losses arising from an unauthorised transaction, the holder is liable in full for the actual losses that occur before the loss, misuse or theft of a device or breach of pass code security is reported to the subscriber, subject to limitations described on the next page. Full liability for an unauthorised transaction applies as follows: 1. Clause 11.2 provides that the holder is liable for losses where the user contributed to losses through: fraud; or breaching the pass code security requirements in clause 12. 2. However, clause 11.3 then provides that where more than one pass code is required to perform a transaction, and the subscriber proves that the user breached the pass code requirements for one or more but not all the pass codes, the holder is liable only if the subscriber also proves that the breach of the pass code security requirements was more than 50% responsible for the losses, when assessed together with all the contributing causes. 3. Clause 11.4 provides that the holder is liable for losses that occur because the user contributed to losses by leaving a card in an ATM, as long as the ATM incorporates reasonable safety standards that mitigate the risk of a card being left in the ATM. A note clarifies that reasonable safety standards includes ATMs that capture cards that are not removed after a reasonable time, or swipe ATMs. 4. Clause 11.5 provides that the holder is liable for losses where the user contributed by unreasonably delaying reporting the misuse, loss or theft of a device, or that the security of all pass codes has been breached. In many cases the holder and the user will be the same person. However a note clarifies that the holder may also be liable if a different user contributed to the loss. For example, a primary credit card holder may be liable for losses caused by a Page 17 of 25
secondary card holder delaying reporting the loss of their card. Clause 10.2 also clarifies that 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. Note this does not include misuse of a device. Consequently, a holder would be liable for unauthorised transactions made with an RFID-enabled card that can be used to make contactless card payments only if there was unreasonable delay in reporting a lost or stolen card. 12.3 Liability provisions / Limitations on full liability Even where the holder is otherwise liable for losses arising from unauthorised transactions under clauses 11.2 and 11.5, the same clauses also provide that a holder is not liable for the portion of losses that fall within the following categories: a loss incurred on any one day that exceeds any applicable daily transaction limit; a loss incurred in any period that exceeds any applicable periodic transaction limit; The electronic network is generally effective in ensuring that daily or periodical transaction limits are not exceeded. However, occasional excesses may occur in such circumstances as: an ATM being off-host, with the subscriber being unable to confirm whether or not the daily limit will be exceeded but the ATM being programmed to dispense a certain amount of cash if the PIN is verified; or ATM or EFTPOS transactions made overseas being approved on the basis of a different 24-hour cycle to the definition of day in the subscriber s terms and conditions; or being approved by Visa or MasterCard without reference back to the subscriber s daily limits. A subscriber must refund any over-transaction-limit amounts, no matter the cause. a loss that exceeds the balance on the facility, including any pre-arranged credit; or Unauthorised transactions that exceed the balance of a facility or that exceed a prearranged credit limit are fairly common. One reason for this is that some subscribers have authorisation programs that, according to parameters set by the subscriber, permit overdrawing of a deposit account or extension of the limit on a credit account. If such transactions were not authorised by the user, they must be refunded by the subscriber because the overdrawing represents a unilateral decision on the part of the subscriber without the specific consent or agreement of the holder. a loss incurred on any facility that the subscriber and the holder had not agreed could be accessed using the device or identifier and/or pass code used to perform the transaction. FOS has considered a dispute under the comparable provision of the EFT Code where an account holder had requested access to internet banking but specified that Page 18 of 25
one of his accounts should be excluded from internet access. The bank ignored the instruction and granted internet access to all accounts. FOS determined that the bank was liable to refund unauthorised withdrawals from the account that the account holder requested to be excluded from internet banking access, even though there may have been disclosure of the pass code. 12.4 Liability provisions / Limited liability Where a pass code is required to perform an unauthorised transaction, and the other full liability clauses do not apply, clause 11.7 provides that the holder is liable for no more than $150. 12.5 Effect of charges Clause 11.6 provides that in deciding whether a user has unreasonably delayed reporting the misuse, loss or theft of a device, or a breach of code security, the effect of any charges imposed by the subscriber for making the report or replacing a device or pass code must be taken into account. If a holder/user would be adversely affected by (say) a fee for replacing a card (e.g. a Centrelink), the clause requires a subscriber to take into account what would be a reasonable time for such a user to confirm that a card was lost or stolen which could be longer than for unaffected users before the subscriber could conclude that the user had unreasonably delayed in reporting. 12.6 Proof that a user contributed to losses Clause 11.8 states three factors that must be taken into account when assessing whether a subscriber has proved on the balance of probability that a user has contributed to losses. These are: 1. All reasonable evidence must be considered, including all reasonable explanations for the transaction occurring; 2. The fact that a facility has been accessed with the correct device and/or pass code, while significant, does not of itself constitute proof on the balance of probability that a user contributed to losses through fraud or a breach of the pass code security requirements in clause 12; and 3. The use or security of any information required to perform a transaction that is not required to be kept secret by users (for example, the number and expiry date of a device) is not relevant to a user s liability. A subscriber who declines to refund unauthorised transactions simply on the basis that an account was accessed with the holder s own card and the correct PIN, without any analysis of the way in which, on the balance of probability, the user might have breached the pass code security requirements of clause 12, may be in breach of the complaints procedures set out in clause 38. In particular, there is a requirement in clause 38.7(b) to give a user who makes a complaint the reasons for the outcome, including references to the relevant Page 19 of 25
clauses of the Code. 12.7 Liability provisions/ Discretion to reduce holder s liability Clause 11.9 provides a discretion for an external dispute resolution body to reduce a holder s liability for an unauthorised transaction where the subscriber has not applied a reasonable daily or periodic transaction limit. Reasonableness is to be determined having regard to prevailing industry practice. The main test for exercising the discretion is whether the security of the means used to verify that the transaction was authorised adequately protected the holder in the absence of reasonable transaction limits. A second test, where the unauthorised transaction draws on a credit facility, is whether the subscriber took reasonable steps to warn the holder about the risk of the device and/or pass code being used to make unauthorised transactions on the credit facility. A credit facility includes redrawing on loan repayments made to a loan facility (such as a home loan). The reference to access with a device and/or pass code is presumably meant to include all of card and PIN access, internet banking access and telephone banking access, because all these means of access were included in the EFT Code. A credit facility would also include a credit card account. Many banks do not impose a daily limit on PIN@POS transactions, that is credit card transactions authorised by PIN. This would allow a credit card account to be drawn to its limit in a single PIN-authorised transaction, just as could happen with a signature-authorised transaction. If a PIN@POS transaction that exceeds the usual daily transaction limit is permitted on entry of PIN only, without any other measures being taken to ensure that the transaction is authorised by the true cardholder (such as by production of photo ID) this could be sufficient for FOS to exercise a discretion to reduce the holder s liability even if the user otherwise contributed to the losses. Similarly, FOS might exercise this discretion if a subscriber allows an ATM withdrawal to the daily limit to be followed by a PIN-authorised in-branch withdrawal of a much higher amount on entry of PIN only and without any other identification requirement. In a recent decision, where such ATM and in-branch withdrawals were unauthorised, totalling up to $11,000 on a single day, FOS determined that the holder s liability should be reduced to the amount of the usual daily transaction limit ($1,000) because the FSP did not have any additional measures in place (such as identification requirements) to ensure that the inbranch withdrawals were made by the actual cardholder. 12.8 Unauthorised scheme credit and debit card transactions Clause 11.10 provides that a subscriber must not hold the holder liable for more than the liability the holder would have if the account institution exercised any rights it had under card scheme rules at the time the report was made, such as charge back rights. The same rule applies even if the subscriber did not exercise the rights it had. 12.9 Liability provisions / Breaching pass code security requirements The security requirements apply where one or more pass codes are needed to perform a transaction (clause 12.1). A user must not: Page 20 of 25
voluntarily disclose one or more pass codes to anyone, including a family member or friend [clause 12.2(a)]; where a device is 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 carried with a device, or liable to loss or theft simultaneously with a device, unless the user makes a reasonable attempt to protect the security of the pass code [clause 12.2(b)]; 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) [clause 12.2(c)]. 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 [clause 12.4]. A note clarifies that 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. A further note refers to clause 12.5 for the obligations applying to the selection of a pass code by a user. on or after 1 April 2002, select a numeric pass code that represents their birth date, or an alphabetical pass code that is a recognisable part of their name, provided that the subscriber has specifically instructed the user not to do so and warned the user of the consequences of doing so [clause 12.5]. Clause 12.6 provides that the subscriber must give the specific instruction and warning at the time of selecting the pass code, in a way designed to focus the user s attention on the instruction and the consequences of breaching it, and taking into account the user s capacity to understand the instruction and warning. Clause 12.7 provides that the onus is on the subscriber to prove, on the balance of probability, that it complied with clause 12.5. The result is to make it difficult for FOS to allocate liability under clause 12.5 if a user claims they were not given the instruction and warning. 12.10 Liability provisions / Protecting the security of a code record Clause 12.3 provides that 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. The clause then provides a list, stated to be not exhaustive, of examples of reasonable attempts, including: hiding or disguising the pass code record among other records; Page 21 of 25
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 preventing unauthorised access to an electronically stored record of the pass code record. As well as being guided by the specific examples in the, policies followed by FOS include that: The fact that a pass code disguise failed does not, of itself, make the attempt to disguise unreasonable; A reasonable attempt to disguise a pass code includes: - concealing the format of the pass code by altering the content, e.g. by rearranging or substituting numbers or alpha characters; - concealing the relevant pass code within a larger record, without altering numbers or alpha characters or their order; The context in which a pass code record is stored is relevant. For example: Was a phone or computer password protected? Was a pass code disguised as a phone number written down by itself or hidden in an address book among a large number of entries? FOS takes the view that some disguises are easily penetrated, and suggests that users do not use such disguises as: phone numbers or postcodes, without additional disguising; numbers marked or highlighted to indicate the pass code; numbers that stand out from contextual information, e.g. a 6-digit pass code among 8-digit phone numbers. 13 Relationship between liability provisions and security guidelines There is often a tension between the restricted circumstances in which a holder can be held liable for unauthorised transactions and the broader security guidelines which account institutions insert into their Terms and Conditions. While the security guidelines have the very useful function of focusing a holder s attention on practical ways of ensuring the security of accounts that can be accessed electronically, they cannot be used as a substitute set of reasons for allocating liability. In other words, Page 22 of 25
a holder s non-compliance with a security guideline (such as a suggestion to destroy the original PIN mailer) cannot be used as a reason for allocating liability. Clause 13 of the deals with this specifically, by stating that a subscriber may give users guidelines on ensuring the security of devices and pass codes in their terms and conditions or other communications. Clause 13.2 then provides that any such guidelines must: 1. Be consistent with the pass code security guidelines in clause 12; 2. Clearly distinguish the circumstances when holders are liable for unauthorised transactions; and 3. Include a statement that liability for losses resulting from unauthorised transactions will be determined by the Code rather than the guidelines. When a subscriber to the is considering a complaint about an unauthorised transaction, it may not allocate liability on the basis that its security guidelines have been breached (e.g. because a holder accessed telephone banking from a hotel phone, where T&Cs advise not to do this). Were liability to be allocated for such a reason, this would represent a failure to observe Code complaint procedures. 14 Complaint procedures Clauses 36 to 39 deal with the procedures for dealing with complaints about matters that come under the, for a subscriber that is:...an Australian financial services licensee, unlicensed product issuer, unlicensed secondary seller, Australian credit licensee or credit representative [clause 36.1]. All current subscribers to the EFT Code, all of which are members of FOS, come within the above group of subscribers. There is a separate group of complaint procedures set out in Appendix A for subscribers who do not come within the above group. At the moment there are no subscribers to the EFT Code, and potentially of the, who would come into the Appendix A group. ASIC seems to have included the Appendix in the hope that other providers of electronic payment facilities will subscribe to the Code. The main difference in the rules in Appendix A is that there is acknowledgement that such subscribers are not bound to follow ASIC s Regulatory Guide165 Licensing: Internal and external dispute resolution. The main features of the complaints procedures are that: Subscribers must have IDR procedures that comply with ASIC RG165 Licensing: Internal and external dispute resolution and AS ISO 10002-2006 Customer satisfaction Guidelines for complaints handling in organizations [clause 37.1]. Subscribers must accept complaints received within 6 years of the day the user became aware, or should reasonably have become aware, of the circumstances giving rise to the complaint [cl 38.1]. Page 23 of 25