Direct Debits

Classification of direct debits

Direct debits normally cover situations where a direct debit is made from an account into an account held by a different account holder. An example is a regular payment for a gym membership. These are normally done via BECS (Bulk Electronic Clearing System), or directly if both parties are customers of the same institution. A regular repayment scheduled by a bank for home loan or credit card payments is normally represented either in account details or in the scheduled payments end points. It is at the discretion of the Data Holder (DH) to classify these items and to align these with payment representations in other channels.

The last direct debit is meant to indicate the most recently identified direct debit transaction. If the same merchant is debiting two distinct accounts, they should be treated as two different direct debits. However, within an account, the merchant is the determining factor. If a merchant debits the same account multiple times but from different Financial Institutions (FIs), then it is treated as a single direct debit.

Periodic credit card payments are not considered direct debits. If the schedule is managed by the DH then they may be considered scheduled payments.

PayTo

The PayTo project is not currently accommodated by the CDS. It is not intended for PayTo to be included in the Direct Debits APIs.

Direct debit response schema clarifications

The lastDebitDateTime and lastDebitAmount fields in the BankingDirectDebit schema are optional. However, these fields are optional only in the sense that, if the values are not available for a particular direct debit, they can be omitted. However, if you have the data, or can infer the data from the transactions, then it needs to be provided.
In the lastDebitAmount field, the debit amount should be a positive AmountString. 

In the BankingDirectDebit schema, the authorisedEntity is the originating source of the debit from the customer's account. This is the merchant the customer has given authorisation to debit an account directly. An example would be AGL for a quarterly direct debit for an electricity bill, or Telstra for a monthly phone or internet bill.

Data presented, in response to calls to the Direct Debits APIs, should be accurate at the time of invocation. Regarding direct debit authorisations, the DH should make the best effort to deduce the data from the transaction history of an account. The duration for which the authorisation is required is defined as 13 months in the CDR Rules. If a merchant has changed financial institution and migrated their direct debits, then this should be communicated via the Direct Debits APIs as soon as the DH can reasonably know, probably after the next debit actually occurs.

Direct debit endpoint 

The Direct Debit endpoint is intended to show Direct Debit Authorisations and not Direct Debit transactions. Where the direct debit was rejected due to insufficient funds or payment being stopped, the expectation is that this would be presented as a Direct Debit Authorisation in the Direct Debit endpoint.

The intention of the direct debit endpoint is to provide data on direct debit authorisations (ie. customer authorisations to a merchant to debit an account directly). This is the designated data cluster that this API was intended to provide. For example, if one of the payment types mentioned falls into this category ie. payments on a home loan with Bank A are paid via Direct Debit from an account at Bank B and the customer has authorised this, then it should be included. The purpose of the direct debit is not a defining characteristic. It is only the existence of an authorisation that defines inclusion.

Only technical direct debit authorisations should be included in the Direct Debits APIs. Where a DH can deduce a recurring payment that would apply to credit or debit card accounts they should be represented via the Scheduled payments API. Where a data holder can deduce a direct debit authorisation against an account (even if it is recurring or on a regular schedule) this would be shown via the Direct Debits API.

In response to a direct debit call,  financialInstitution is required, unless the payment is made via a credit card scheme. The merchant financialInstitution is contained in the direct debit, that the customer institution receives via BECS, and is retained in the transaction history. The records used in the ResponseBankingDirectDebitAuthorisationList response are expected to be derived from the transaction history.

The definition of a financial institution in the scopes for Banking Authorised Party, is the financial institution of the merchant requesting the funds from the customer's data holder via the direct debit authorisation.