Decision Proposal 029 - Direct Debit Authorisation Payloads

[JamesMBligh]

This decision proposal outlines a recommendation for the payloads for direct debit authorisations as per the end points defined in decision proposal 015.

Feedback is now open for this proposal. Feedback is planned to be closed on the 26th October.
Decision Proposal 029 - Direct Debit Authorisation Payloads.pdf

Please note the specific concerns. If there is significant early feedback I will reissue with amendments prior to the closure date.

[anzbankau]

Direct Debits (DD)

• Direct debit mandates are generally not stored in a bank in Australia. They are held at a merchant (i.e. with a banks’ corporate customer that is authorised for direct debits)
• A customer provides the debit details to a merchant (e.g. health fund, telecom, local gym).
• A merchant does not send the details of the direct debit mandate to bank.
• The merchant just sends the debit request to a bank.

So, a bank will not have details like:

• When the direct debit starts/ends (if setup at a merchant)
• The frequency of the direct debit (e.g. monthly/quarterly/yearly/Fortnightly on a Thursday.)
• The debit amount threshold – if it was setup as fixed at the merchant. Amounts could be different for each debit.
• Direct debit expiry date (if setup at merchant)

A bank will process a debit to a customers’ account, when it receives the request from a merchant for an amount.

Because of current process in Australia, complete direct debit information is not visible to a customer today via a banks’ online channels.

A way to realise the AU direct-debit endpoint:
A bank can process the last 13 months (ABA banking code of practice) transactions on one/more accounts, identify the payments that were DD (sent via Direct Entry) and report on that, the details will be limited to:

1. Amount debited
2. Date
3. Limited Merchant information.

The rest of the details about the direct debit will not be returned. Also, information about any existing direct debits that are yet to send a debit request to a bank cannot be returned. So, the list of DDs can be incomplete and so is the information about each DD.
From a portability perspective, this information may not be sufficient for a customer.

Some merchants allows customer to setup recurring debits from their credit cards, in this case a bank may also be able to return the details about a debit but not about the “direct debit” from a credit card (similar to DD done via DE).

In addition, banks may have automated loan/credit-card/other repayment details in their internal systems, these details could also be shared.
The details stored here will vary from system to system across/within banks.

In the UK as direct debits are stored centrally, sufficient details maybe readily be available in a bank accessible system.
The UK spec for standing orders (direct debits), returns useful information (https://openbanking.atlassian.net/wiki/spaces/DZ/pages/641959800/Standing+Orders+v3.0) like frequency, finalPaymentData etc. This information if available will assist portability. In addition the GET /accounts/{AccountId}/standing-orders endpoint is Conditional – To be provided if available to a PSU in the ASPSPs existing online channel, or the ASPSP has been mandate by a regulatory requirement. GET /standing-orders is marked Optional (not necessarily required for regulatory compliance but may be implemented to enable desired customer outcomes). This classification allows banks in the UK required flexibility in implementation.

From the above, the data returned in this AU Open Banking endpoint could be incomplete in the number of items returned (DDs which have not submitted a debit will be missing) and will be incomplete with respect to each direct debit item returned (e.g. expiry date, threshold etc is missing)

Direct Debits = BECS payments from Corporate Customer to bank,

Recurring Payments = Credit Card debits at Corporate customer via card scheme

-S

[NationalAustraliaBank]

NAB supports ANZ Bank's position on Direct Debit Authorisations, our ability to implement the current decision proposal is outside of our direct control.

Additionally, any solution that involves mining the already completed direct debit data will:

• not be a trivial exercise,
• likely lead to inconsistencies across provider implementations, and
• will not deliver the intended user experience.

[da-banking]

+1 on ANZs response.

We do not have the data required to meet the proposed structure. If this is retained in scope in its current form, we would implement the directDebitAuthorisations as an empty array.

We have 13 months direct debit transaction history data that includes very little beyond what is already included in the scope of #28 Transaction Payloads. For example, we could add to transaction history the fact that the transaction was a direct debit, and that's it really. The merchant information is already in the transaction description.

[WestpacOpenBanking]

Westpac supports the position put forward by @anzbankau and @NationalAustraliaBank.

[bazzat]

Just chiming in - the ABA Open Banking Technical Working Group as a whole supports the comments above from ANZ and NAB.

[commbankoss]

CommBank supports @anzbankau position on Direct Debit Authorisations, an alternate solution for the concept of a direct debit would be an inclusion of a schedule payments or standing orders payload. We would recommend not including direct debits in scope for Open Banking due to the data not being available at the institution level.

[TKCOBA]

Feedback from our Open Banking Working Group is that this proposal would be difficult to comply with due to field/data scope limitations. For example, while some systems may record information relating to a DDA request, other information relating to the merchant is not captured.

[JamesMBligh]

Thanks for the feedback. The discussion of how to obtain the data for these end points and whether this data should be out of scope needs to be directed to the ACCC. From a standards perspective the data is currently in scope. I'll try to incorporate the remainder of the feedback as much as possible.

-JB-

[JamesMBligh]

The finalised decision for this topic has been endorsed. Please refer to the attached document.
Decision 029 - Direct Debit Authorisation Payloads.pdf

-JB-