Basic Search Fields

E-Payments Code


ASIC published the new ePayments Code on 20 September 2011. It regulates electronic payments, including online payments, internet and mobile banking, BPAY ATM, EFTPOS and credit card transactions. It replaces the Electronic Funds Transfer Code of Conduct (EFT Code). Subscribers to the new Code must start complying with it by 20 March 2013.

This article discusses the background to the new Code, the principal changes from the EFT Code, and FOS’s approach to disputes to which the new Code will apply.

The EFT Code

The EFT Code gave financial services providers (FSPs) detailed guidance on card and PIN transactions and all forms of electronic banking, including telephone banking and internet banking. It included information about:

  • acceptable standards for terms and conditions of use
  • how to handle disputes, and
  • how to allocate liability for unauthorised transactions.

The EFT Code upheld the long-standing principle of banking law that an FSP requires the mandate of its customer to validly debit an account, and that only in exceptional circumstances can a customer be held liable for unauthorised transactions on their account.

The ePayments Code

In accordance with its terms, the current EFT Code was the subject of a review by ASIC which commenced on 1 April 2004, and which has resulted in the release of the ePayments Code as the successor to the EFT Code.

One criticism of the EFT Code was that it used technical and precise terminology. To ensure that the ePayments Code could be easily comprehended by the layperson, ASIC decided to:

  • adopt a new structure and new defined terms for the Code, and
  • redraft the Code in plain English.

Importantly, from FOS’s perspective, ASIC explained 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”.

Features of the ePayments Code

Apart from the rewording in plain English, the main changes introduced by the ePayments Code are as follows:

  • There is a regime for dealing with mistaken internet payments.
  • The separate provisions for consumer stored value facilities and stored value transactions in the EFT Code have been dropped. Instead, the ePayments Code incorporates limited requirements for low value facilities that can hold a balance of no more than $500 at any one time.
  • Merchant agreements must prohibit a merchant from holding a user’s pass code (i.e. the PIN) as part of a ‘book up’ arrangement.
  • There are provisions for facilities that have an expiry date.
  • There is clarification that a cardholder is liable for losses arising from unauthorised transactions that occur because a user (either the cardholder or someone they have given permission to use their card) contributed to losses by leaving a card in an ATM.

How FOS will apply the two Codes

Subscribers to the ePayments Code must start complying with it by 20 March 2013. Some FSPs might decide to adopt the new Code before this deadline. Until 20 March 2013, we will consider electronic banking disputes in accordance with:

  • the EFT Code if the dispute involves an FSP that has not yet adopted the ePayments Code
  • the ePayments Code if the dispute involves an FSP that has already adopted the ePayments Code.


After 20 March 2013, we will consider all electronic banking disputes in accordance with the ePayments Code.

Mistaken internet payments

Identifying the issues

As part of its review of the EFT Code, in January 2007 ASIC released a consultation paper. The main new issue flagged in the consultation paper was whether (and, if so, how) the EFT Code should regulate mistaken payments arising out of internet banking ‘Pay Anyone’ transactions. ASIC recognised that mistaken internet payments were an emerging consumer issue. Comments made included that:


  • Payers are required to enter details of the intended recipient’s account number and, in most cases, the intended recipient’s name.
  • There is no process at either the paying or receiving ADI (authorised deposit-taking institution) for checking the number against the name.
  • As funds were transferred on the basis of the account number only, when a mistake in entering the number occurred there might be problems in recovering the funds from the unintended recipient. Ultimately, the funds might not be recovered at all.
  • The legal question of where to allocate liability for unrecovered loss after a mistaken internet payment was contentious.
  • It was ASIC’s understanding that general industry practice, while assisting customers to try to recover funds that had been transferred by mistake, was not to accept liability for mistaken payments.

In inviting comment on how the EFT Code should address the issue of mistaken payments, ASIC listed a number of suggestions for possible regulatory responses. These included prominent warnings for users, requiring receiving institutions to clarify any ambiguity in payment instructions (in relation to BSB and account number), and adopting a form of chargeback that allowed the paying institution to reverse the disputed transaction unless the recipient was able to show they were entitled to payment.

Development of proposals

The provisions in the ePayments Code resulted from extensive consultation with stakeholders in relation to the underlying issues, proposed solutions and incorporation of provisions into the EFT Code. The final form of the mistaken internet provisions was released in ASIC’s Report 218, issued in December 2010, which included all the changes to be made to the EFT Code. In relation to the mistaken payments issue, ASIC’s comments included that:


  • “The issue of how mistaken internet payments might be dealt with in the EFT Code has proven to be one of the most difficult to resolve in the current review”
  • “Stakeholder feedback revealed concerns that were difficult to reconcile, in particular that given that very little industry data is available on the extent and nature of mistaken payments ... but in the absence of data we were not able to accurately assess the true cost impact of allocating liability to either consumers or industry”, and
  • “The proposals in this report represent significant compromises by all Mistaken Internet Payments Working Group members to accommodate each other’s concerns and achieve a workable outcome for consumers and industry”.

Mistaken payments provisions in the ePayments Code

A ‘mistaken internet payment’ is defined as a payment by a user through a ‘Pay Anyone’ internet banking facility where funds are paid into the account of an unintended recipient because the user enters or selects a BSB and/or account number that does not belong to the named recipient, as a result of the user’s error or the user being advised of the wrong BSB and/or account number.

BPay payments are specifically excluded because ASIC considers BPay already has effective procedures in place to ensure that funds do not go astray. Another exclusion, arising out of the definition, is that the Code would not cover the situation where a user mistakenly selects the wrong payee from a pre-existing list of third party payees. In such a case, if the BSB and account number belonged to the named recipient, the user would have to attempt to recover the funds on their own.

Clauses 24 to 34 of the ePayments Code cover mistaken internet payments. In summary:


  1. Clause 24 requires that terms and conditions for accounts must detail the prescribed processes, including the circumstances in which a subscriber will recover funds and the circumstances in which a holder will be liable for losses.
  2. Clause 25 requires a clear on-screen warning about the importance of entering the correct BSB and account number and the risks of mistaken internet payments, including that it may not be possible to recover funds from an unintended recipient.
  3. Clause 26 requires subscribers to have an effective and convenient process for users to report mistaken internet payments.
  4. Clauses 27 to 32 deal with the remedies available when there is a mistaken internet payment.


Clause 27 requires the sending ADI to investigate whether a mistaken internet payment has occurred and, if satisfied, to send the receiving ADI a request for the return of the funds. The receiving ADI, within 5 business days, has to acknowledge the request and advise if there are sufficient funds in the account of the unintended recipient to cover the payment. The outcome varies according to the time taken to report the mistaken internet payment and whether or not funds are available in the account of the unintended recipient:


  1. Pursuant to clause 28, if


  1. the user reports the mistake within 10 business days of making the payment, and

  2. there are sufficient credit funds available in the account of the unintended recipient, and

  3. both the sending ADI and the receiving ADI are satisfied that a mistake occurred,


then the receiving ADI must return the funds to the sending ADI within 5 to 10 business days of receiving the request. The receiving ADI would not have to seek the consent of the unintended recipient, provided that the receiving ADI was satisfied it was a mistaken internet payment;


  1. Clause 29 details the process that must be followed if funds are available and the report is made between 10 business days and 7 months of the transaction. In summary, subject to both sending and receiving ADIs being satisfied of the mistake:


  1. The receiving ADI must complete its investigation within 10 business days of receiving the request.
  2. The receiving ADI must prevent the unintended recipient from withdrawing the funds for 10 further business days.
  3. The receiving ADI must notify the unintended recipient that it will withdraw the funds if the unintended recipient does not establish that that they are entitled to the funds within 10 business days.
  4. If the unintended recipient does not establish that they are entitled to the funds within 10 business days, the receiving ADI must return the funds within a further 2 business days.


  1. Clause 30 details the process that must be followed if funds are available and the report is made after 7 months. In summary, subject to both sending and receiving ADIs being satisfied of the mistake:


  1. The receiving ADI must seek the consent of the unintended recipient to return the funds.
  2. If the unintended recipient consents to the return of funds, the receiving ADI must return the funds to the sending ADI.


The choice of 7 months as a relevant period seems to be based on the fact that statements must be provided to the account holder at least once every 6 months. The user is thus given another month in which to check their statement and report any mistaken internet payments.

The provision that the receiving ADI may return a mistaken internet payment within 10 business days of the transaction date without the consent of the unintended recipient apparently reflects a similar provision in the BECS (Bulk Electronic Clearing Systems) procedures.
Pursuant to clause 31, where the unintended recipient receives income support from Centrelink, the receiving ADI must recover funds in accordance with the Code of Operation for Centrelink Direct Credit Payments.

Clause 32 details the process that must be followed if funds are not available. In summary, if there are not sufficient funds to the full value of the mistaken internet payment, the receiving ADI is only required to use reasonable endeavours to retrieve the funds from the unintended recipient (for example, by facilitating repayment by instalments).

Clause 33 requires the sending ADI to inform the user of the outcome of a reported mistaken internet payment in writing and within 30 business days of the report.

Clause 34 provides that a user who reports a mistaken internet payment can complain to the sending ADI about how the report is dealt with and, if not satisfied with the outcome, can also complain to the sending ADI’s EDR scheme.

FOS’s approach

The supplement to Bulletin 39 that we published in September 2003 said:

“The receiving bank is not, in our view, entitled unilaterally to debit its customer’s account if the funds have been withdrawn, although it is in the best position to seek the recipient’s agreement to repay the funds. It should be remembered that its customer, the recipient, may also have a defence of change of position in good faith.”

If the FSP subscribes to the ePayments Code, we will apply the Code provisions rather than the view expressed in this quotation.

The provisions for automatic return of funds where a report is made within 10 business days of the transaction and the funds remain in the account of the unintended recipient give additional certainty for subscribers about their mutual obligations (over and above their rights and responsibilities as members of the Australian Payments Clearing Association). They also ensure that the payer will have their funds returned within a reasonably short period of time. While the unintended recipient may feel aggrieved about a unilateral reversal of a mistaken payment, they will not have suffered any compensable loss if they were not entitled to the funds in the first place.

The most important aspect of the provisions regarding cases in which a report is made between 10 business days and 7 months and there are sufficient funds in the account is that the receiving ADI is obliged to prevent the unintended recipient from withdrawing the funds during the 10 business days the unintended recipient has to establish an entitlement to the funds. This provision allows an unintended recipient to seek to establish an entitlement to the funds, but also prevents them from trying to frustrate the recovery process by unilaterally withdrawing the funds once notified of a disputed payment. The requirement to establish entitlement within 10 business days, failing which the funds will be returned, also ensures that the recovery process is relatively brief.

We may receive complaints about the actions of the receiving ADI from unintended recipients who are aggrieved by the return process. However, they would have to establish to our satisfaction that they had an entitlement to the funds, and that they had provided that information to the receiving ADI within 10 business days, before we could find that they had suffered a compensable loss.

When dealing with individual disputes, we will have regard to:


  • the prominent warnings routinely given on internet banking screens which alert the sender of a mistaken internet payment that the sending ADI places no reliance on the name entered and will transfer the funds by reference to the BSB/account number only, and
  • whether the process for retrieval provided by the Code has been followed.

As we may only consider a dispute that arises from or relates to the provision of a financial service by the FSP to the applicant, we cannot accept a dispute from a sender about the receiving ADI, unless the sender had attempted to send funds to their own account held with the receiving ADI.

Low value facilities

A ‘low value facility’ is a facility that is capable of having a balance of no more than $500 at any one time. The tailored requirements for low value facilities include the following:


  • A subscriber to the ePayments Code does not have to give terms and conditions unless it is practical to do so. Otherwise, the subscriber must give consumers a notice that highlights key terms.
  • A subscriber does not have to give consumers information about how to report the loss, theft or misuse of a device or breach of pass code security. Instead, subscribers must tell consumers whether they provide a process for doing so.
  • A subscriber does not have to give consumers advance notice of changes to terms and conditions unless they know the identity and contact details of the consumer. Otherwise, subscribers must simply publicise this information.
  • A subscriber does not have to give consumers receipts. Instead, subscribers must give consumers a process to check their balance and a simplified receipt or a mechanism for the consumer to check their transaction history.
  • A subscriber does not have to give consumers statements.
  • The rules for allocating liability for unauthorised transactions do not apply to low value facilities.

FOS’s approach

As ASIC explained in its final report (issued in December 2010) on the review of the EFT Code, it has deliberately designed a ‘light touch’ regime for low value electronic payment products. ASIC recognised that new and innovative payments products were being introduced but that some of the products were not subject to any industry code or regulation. It wanted to encourage the providers of such products to consider subscribing to the Code without making it too expensive for industry participants to comply with the Code. It settled on a monetary limit of $500 as a level that balanced consumer and industry interests and that limited the risk to consumers of holding such a product. In doing so, ASIC acknowledged that there may be circumstances where it is not operationally or economically viable for providers to give their customers the ability to notify the loss, theft or unauthorised use of their product, and receive either a refund or a replacement product with the remaining value. In other words, ASIC accepts that the holder of a low value facility runs the risk of losing the value held on the facility, but the loss can be no more than $500. 

Clause 4.4 of the ePayments Code imposes an obligation on providers to give holders of a low value facility at least a notice that highlights any key terms (for example, the fact that the user will forfeit the balance on the facility if they lose a device). Effectively, this requirement means that the holder of a low value facility is being warned that they should treat the product like cash.

Because of the tailored requirements for low value facilities that are written into the ePayments Code, FOS will not be able to require the provider of such a facility to issue a refund to the holder if the facility is lost or stolen.

Book up

A ‘book up arrangement’ is defined as being:

“Credit offered by merchants for the purchase 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”.

In order to deal with real or perceived abuses of the book up system, ASIC has inserted the following clause [20.1] into the ePayments Code:

“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”.

Clause 20.1 allows that a merchant may retain a user’s card. However, by prohibiting the retention of the pass code as well, it is designed to prevent unauthorised access to a user’s account without their knowledge and consent.

FOS’s approach

We acknowledge that ASIC, as a matter of policy, wants to discourage the practice of merchants holding both cards and PINs as part of a book up arrangement. In our view, the fact that a cardholder hands over their card to a merchant does not in itself mean that the cardholder has breached a requirement of the ePayments Code. If we were to receive a complaint about an unauthorised transaction on a card held by a merchant, we would be guided by the fact that the ePayments Code affords some protection to cardholders in the event that a merchant abuses their possession of the card, and knowledge of the PIN, to perform an unauthorised transaction. This is because the ePayments Code carries over from the EFT Code the provision that a cardholder is not liable for loss caused by fraud or negligence by a merchant or their employee or agent (clause 10.1(a)). This provision takes precedence over the fact that the cardholder might otherwise be regarded as having contributed to the loss, and be liable for unauthorised transactions, either by voluntarily disclosing their PIN to the merchant (clause 12.2(a)) or by unreasonably delaying reporting the misuse of their card after becoming aware that the merchant was making unauthorised transactions (clause 11.5)).

In considering any dispute that involves a book up arrangement, we will take into account whether or not the subscriber has complied with clause 20.1 as well as applying the liability clauses in light of the facts of the dispute.

Facilities with expiry dates

The provisions about expiry dates cover both cards that are not reloadable (such as store gift cards) and cards that are reloadable (such as bank-issued travel cards for holding foreign currencies). Reloadable cards are cards that can have further funds deposited on them.

Whether or not a facility with an expiry date is covered by the ePayments Code will depend on whether the issuer subscribes to the Code. At the moment, store cards with expiry dates may not be covered because no issuer is currently a subscriber to the EFT Code. However, bank-issued travel cards with expiry dates are covered.

The minimum expiry dates specified by the ePayments Code are:


  • for non-reloadable facilities, the expiry date must be at least 12 months from the date the user activates the facility, and
  • for reloadable facilities, the expiry date must be at least 12 months from the date the user last reloads the facility.

Other provisions with regard to expiry dates are that:


  • the issuer must not unilaterally bring forward the expiry date
  • the issuer must give users a way to check the expiry date
  • if a card is used to access the facility, the expiry date must be disclosed on the card, or
  • if the issuer cannot ascertain the expiry date because it depends on the date of activation or last reload, the period during which transactions can be made must be disclosed on the card.

FOS’s approach

We note that there is no mention in the ePayments Code of what should happen to the balance remaining on a facility at the expiry date. Therefore, the fate of the balance depends on the terms and conditions for the facility. In many cases this would mean that the balance on expiry is forfeited to the issuer.

Some FSPs issue reloadable travel cards that have an expiry date. Each FSP provides that the card is unusable after the expiry date, but that the holder may apply for a refund of the balance up to 12 months after the expiry date. However, any balance remaining at the expiration of 12 months after the expiry date is forfeited to the FSP.

In considering disputes about facilities with expiry dates, particularly with regard to any balance that is forfeited to the issuer, we will be concerned to ensure that the issuer has complied with the particular provisions in clause 18 about minimum expiry dates, as well as with the general disclosure requirements in clause 4 to prepare clear and unambiguous terms and conditions for facilities. There is clearly an obligation on subscribers to ensure that their customers are fully informed about both the advantages and the disadvantages (including forfeiture of an unclaimed balance) of a facility with an expiry date.

Cards left in an ATM

Pursuant to clause 11.4, a cardholder will be liable if a user leaves a card in an active ATM. The clause states:

“The holder is liable for losses arising from unauthorised transactions that occur because a 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”.

An accompanying note explains that:

“Reasonable safety standards that mitigate the risk of a card being left in an ATM include ATMs that capture cards that are not removed after a reasonable time and ATMs that require a user to swipe then remove a card in order to commence a transaction”.

FOS’s approach

When a card user withdraws cash from an ATM in Australia, they are usually required to take their card before the cash is dispensed. Therefore, in order to perform a second transaction after withdrawing cash, the user must reinsert the card and re-enter the PIN. This routine is designed to minimise the possibility of cards being left in ATMs.

However, a different routine applies when a user performs a non-cash transaction such as a balance enquiry, transfer of funds between accounts or deposit. After such transactions, ATMs in Australia are usually programmed to remain active to permit another transaction. After the non-cash transaction, the ATM remains active and the user is asked whether or not they want to make another transaction. The user is required to respond ‘Yes’ or ‘No’ to the question. If they choose ‘Yes’, the next transaction can be made without re-entering the PIN. If they choose ‘No’, the card is ejected.

This is a reasonable procedure given that the most common non-cash transaction is a balance enquiry, after which the user might often decide to withdraw cash. However, if a user becomes distracted, they might take their balance enquiry receipt, walk away and leave the card in the ATM while the on-screen message is asking whether or not they want to make another transaction. When this happens, the next person to approach the ATM may be in a position to answer ‘Yes’ and make another transaction, including a withdrawal. To minimise the risk of this happening, an ATM may be programmed to either shut down or retain the card after a certain period of time has elapsed. However, if the next person arrives at the ATM within a short period, they would be able to make an unauthorised withdrawal.

We have received disputes about such unauthorised withdrawals, which fall between the gaps of the EFT Code. While the withdrawal transaction was unauthorised, the ATM was active was as a result of an authorised transaction.

On the other hand, it has not been clear that the user contributed to the losses in EFT Code terms because it would be hard to argue that there was voluntary disclosure of the PIN, and the concept of ‘acting with extreme carelessness’ does not apply to the card itself but only to the security of the PIN.

Nevertheless, it has been our practice for many years that the account holder should bear the liability for such unauthorised transactions.
We recognise that the purpose of the EFT Code is to limit an account holder’s liability for unauthorised transactions to certain specified situations where the user has contributed to losses. We also recognise that the EFT Code imposes very few obligations on a user with regard to card and PIN security. The rationale for our usual practice of allocating liability to the account holder for a card left in an active ATM is that:


  • The user is completely in control of the card while using an ATM.
  • It is fair and reasonable that the account holder should be liable for the consequences of the user’s carelessness with the card.
  • It would be unfair and unreasonable for the FSP to suffer a loss because of the user’s carelessness with the card.

We have considered each dispute on its merits, of course, and in some cases have asked an FSP to refund money to an account holder if we were satisfied that the user was unfamiliar with the usual ATM routine, or that the ATM remained active for an overlong period of time, or, in the case of an overseas ATM, if the routine followed by the ATM was markedly different from the routine of an Australian ATM.

However, for transactions to which the ePayments Code applies, we will apply clause 11.4 and will only consider whether the ATM incorporated reasonable safety measures to mitigate the risk of a card being left in an ATM.


Training opportunities

We can run workshops for FSPs to explain how we interpret and implement the EFT Code in our decisions and how we will approach disputes under the ePayments Code. If you would like more details or would like to arrange a training session, please call our member line 1300 56 55 56 or email