Direct debit requests and DDR service agreements, what your business must do

If your business runs a gym, a software subscription, a childcare centre or any other arrangement where you take money from customers' bank accounts automatically, you cannot simply start debiting. Before the first debit, you need the customer's authority, and the way you obtain and document that authority is governed by the industry rules for direct debits in Australia.

Those rules are the Bulk Electronic Clearing System (BECS) procedures, administered by the Australian Payments Network (AusPayNet), the body formerly known as the Australian Payments Clearing Association (APCA). Compliance centres on two documents: the direct debit request (DDR) form, which records the customer's authorisation, and the DDR service agreement, which sets out the terms under which you will debit the account. On top of the BECS rules sit consumer protection obligations under the ePayments Code, privacy obligations under the Privacy Act 1988 (Cth), and an industry-wide transition away from BECS that you should factor into any new payment setup.

This article sets out who these obligations apply to, what the two documents must contain, the consumer protection layers you cannot ignore, what happens if you get it wrong, and a practical compliance checklist.

Who must comply

The direct debit rules apply to any business that initiates debits from customers' bank accounts through the BECS direct entry system. In the language of the rules, your business becomes a direct entry user: an entity that issues debit payment instructions under the BECS procedures. To become one, you obtain a user ID through your financial institution or payment processor, and every debit you send is identified by that user ID.

The obligations bite from the moment you set up the arrangement, not from the first dispute:

You must obtain each customer's authority to debit their account before any money is taken.
You must give the customer the documents that record that authority and its terms.
You must honour the customer's ongoing rights to cancel, amend or dispute debits.
You must handle the customer's bank account details in line with the Privacy Act.

These requirements apply whether your customers are individuals or businesses. The extra consumer protections under the ePayments Code apply only where the customer is an individual acting for personal purposes, so the distinction matters when you draft your documents and design your dispute process.

Obtain the customer's authority with a direct debit request

The DDR form is the document that records the customer's authorisation to debit their account. It is the proof that a debit is not an unauthorised transaction, and it is the first thing a customer's bank will ask to see if a debit is disputed.

At a minimum, the form must capture the details needed to identify the account being debited and the person authorising it:

Account details: the account name, BSB and account number of the customer's nominated account.
Your identity: your business's name and its direct entry user ID, so the customer and their bank can see exactly who is authorised to debit the account.
The debit terms: the amount to be debited, how often, and on what date. If these details are set out in the DDR service agreement instead, the form must say so and direct the customer to the agreement.
Consent: the customer's authorisation, signed and dated where consent is given in writing. Electronic consent is acceptable, but you need a record of it either way.

Keep the completed form. In practice, it is the evidence that decides who bears the loss when a customer says a debit was never authorised. A customer who signs a DDR covering a set amount and frequency has authorised those debits; a debit outside that scope is not authorised.

Provide a DDR service agreement

The DDR service agreement sits alongside the form and sets out the terms and conditions of the arrangement. AusPayNet's rules require it to deal with specific matters, and the document should be written so an ordinary customer can follow it:

Cancellation, amendment and dispute rights: the customer can cancel the direct debit authority at any time, ask for changes, or dispute a particular debit. State how they do this, including through their own bank.
Sufficient funds: the customer must keep enough money in the nominated account for each debit to be paid, and should understand that a failed debit can be dishonoured with fees.
Non-business days: if the scheduled debit date falls on a weekend or public holiday, the debit is generally processed on the next business day. Say so.
Privacy: explain how you collect, use, store and disclose the customer's personal information, including their bank account details, and point to your privacy policy.

If the DDR form carries the amount, frequency and timing details, the service agreement can cross-refer to it instead of repeating them. What matters is that the customer can find the terms of what they have agreed to.

Meet the consumer protection layers

Where your customer is an individual, the ePayments Code adds a layer of protection on top of the BECS rules. The Code is a voluntary code administered by ASIC that most banks, credit unions and building societies subscribe to, and it applies to consumer electronic payment transactions including direct debits.

Under the Code, your customer's bank must give clear terms and conditions, and the rules determine who bears the loss for unauthorised transactions. Broadly, a customer is not liable for loss from an unauthorised transaction where the cause is, for example, fraud or negligence by the business or its staff, or where the account was incorrectly debited more than once. A customer is also not liable where it is clear they have not contributed to the loss. What this means for your business is simple: a debit taken without a valid authority can be reversed through the customer's bank, and the bank will look to you for the DDR that proves the authority existed.

When a customer disputes a debit, the complaint usually runs through their bank, which can ask you to substantiate the debit. If it cannot be resolved, the customer can escalate to the Australian Financial Complaints Authority (AFCA). The practical cost of a compliance failure is not a fine on day one; it is reversed debits, chargebacks and a damaged relationship with the payment system.

Handle account details under the Privacy Act

The BSB and account number you collect on a DDR form are personal information under the Privacy Act 1988 (Cth), because they identify the customer's account and therefore the customer. The Australian Privacy Principles (APPs) in Schedule 1 of the Act then govern what you do with that information:

Collection (APP 3): collect only what is reasonably necessary for the direct debit arrangement.
Notification (APP 5): tell customers what you collect, why, and who you disclose it to, at or before the time of collection.
Use and disclosure (APP 6): use the details only for the purpose collected, such as processing debits, unless the customer consents or another exception applies.
Security (APP 11): protect the information from misuse, interference, loss and unauthorised access, and destroy or de-identify it once the arrangement ends and you no longer need it.

The Office of the Australian Information Commissioner (OAIC) can investigate privacy complaints and seek civil penalties, and the maximum penalty for serious or repeated interference with privacy can reach $50 million. For most small businesses, the realistic exposure is an OAIC investigation and a direction to change your practices, but the reputational cost of a breach involving customers' bank details is its own risk.

What happens if you get it wrong

Direct debits run on authority. When the authority is missing or defective, the consequences flow through the payment system rather than a court:

Reversals and chargebacks: A debit the customer's bank treats as unauthorised can be reversed, and the customer can recover the amount from their bank, which then recovers it from you.
Loss of access: Your financial institution can suspend or cancel your direct entry user ID if you breach the BECS procedures, which ends your ability to debit customers at all.
Complaints and escalation: Disputes can reach AFCA through the customer's bank, and privacy complaints can reach the OAIC.
Regulator attention: ASIC administers the ePayments Code and monitors subscribers' compliance; persistent failures can draw its scrutiny.

For a subscription business, the cash-flow effect of mass reversals, or the loss of the direct debit channel entirely, is usually a far bigger problem than any fine.

Plan for the end of BECS

BECS is more than 30 years old and is Australia's largest retail payment system, handling salary, pension and other account-to-account payments. The industry has announced a target of decommissioning BECS by June 2030, and the Reserve Bank's Payments System Board has classified BECS as a prominent payment system while it oversees the transition.

The successor for recurring account-to-account payments is PayTo, a service on the New Payments Platform (NPP). Under PayTo, a customer authorises a payment agreement in their own online banking, which means they see and manage the arrangement themselves, and your business initiates real-time payments from their account. If you are setting up recurring payments now, it is worth asking your bank or payment processor whether PayTo is available to you, and structuring your consent and terms so they can move across when BECS winds down. Any DDR you collect under BECS will not automatically become a PayTo agreement.

Compliance checklist

Before you take a single debit, work through this list:

[ ] Register as a direct entry user and obtain your user ID from your financial institution or processor.
[ ] Use a DDR form that captures the customer's account name, BSB and account number, your user ID, and the amount, frequency and timing of debits.
[ ] Have the customer sign and date the form, or keep a reliable record of electronic consent.
[ ] Provide a DDR service agreement covering cancellation, amendment and dispute rights, sufficient funds, non-business days and privacy.
[ ] Keep every DDR on file and retrievable, because it is your proof of authority in a dispute.
[ ] Notify customers about how their details are handled, and secure the account information you hold.
[ ] Ask your bank or processor about PayTo before committing to a new BECS arrangement.

When to get legal help

The documents themselves are where most businesses come unstuck, because the BECS procedures set out what the DDR and service agreement must say and a template from a competitor or a website will not necessarily match your pricing model, your dispute process or the way you collect consent online. A lawyer can review your DDR form and service agreement against the current BECS rules, check your privacy collection notice, and advise on the PayTo transition and how to move existing customers across.

Every part of this compliance framework comes back to one record: the direct debit request. When a customer disputes a debit, the customer's bank, and ultimately AFCA, will ask whether the debit was authorised, and the DDR is the answer. A form that fails to capture the account details, your user ID and the agreed debit terms is not just a paperwork gap; it is a debit that can be reversed as unauthorised. Get the form right, keep it on file, and make sure your service agreement says what you actually do, because the document that matches your real process is the one that survives scrutiny.