Key Phase Dates

Phase 1: Retrospective and Backlog Grooming - 9th July 2020 commencement. 2 weeks duration

Phase 2: Consultation - 22nd July 2020 commencement. 4 weeks duration

Phase 3: Approvals and Documentation - 19th August 2020 commencement. 2 week duration

Please contact [email protected] for an invite to the series

We have previously submitted the following questions for Data Holder Work Group 04/06/2020, as well as Data Holder Work Group 18/06/2020:
1. Further to the item above, we are of the view that traffic throttled due to exceeding non-functional requirements does not constitute a refusal to disclose and would not be in scope for record keeping an reporting as a refusal to disclose. Throttled traffic is a reported measurement in the Get Metrics API. Could you please publish the answer in the minutes?
2. We are of the view that each refused API call constitutes a separate refusal to disclose event for the purposes of record keeping and reporting. Could you please publish the answer in the minutes?

When can we expect a response in writing, as no response has been provided to either of these items in the meeting minutes?

We’re grateful to our stakeholder for raising this issue.

In one of the paragraphs of our guidance, we used ‘white labeller/brand owner’ terminology to illustrate that (a) the data holder that has the contractual relationship with the consumer may agree that the other data holder will respond to product data requests; but (b) in that case, the data holder with the contractual relationship would remain accountable for performance of the obligation by the other data holder.

However, due to an error, the paragraph as published described what we understand is a relatively unusual situation, namely where the brand owner has the contractual relationship with the customer. We had intended to provide an example based on what we understand is the more common situation, namely where the white labeller has the contractual relationship with the customer.

Our corrected guidance is:

‘Where there are two data holders involved in providing a white label product, (for example, where a brand owner bank distributes a credit card on behalf of a white labeller bank) the ACCC expects the data holder that has the contractual relationship with the consumer to respond to product data requests. We understand that the data holder that has the contractual relationship with the consumer is generally the white labeller. The other party (generally the brand owner) may also respond to product data requests, however we do not propose to treat this as mandatory. > The data holder that has the contractual relationship with the customer (e.g. the white labeller) may agree with the other data holder (e.g. the brand owner) that the brand owner will perform that obligation on behalf of the white labeller. In that case the white labeller, as the data holder that has the contractual relationship with the consumer, remains accountable for performance of the obligation by the brand owner.’

We apologise for any confusion this may have caused. In addition to today’s clarification, we plan to publish a clarification in our next newsletter. This should ensure all stakeholders who receive the newsletter are notified of the correction.

As a data holder with 4 brands, answers to these questions will provide clarity on whether we are trying to achieve:

• 300TPS – for both API’s covering all brands.
• 600TPS – 300 for get-products + 300 for get-product-details (i.e. 600 covering all brands).
• 1200TPS – 300 for both API’s, repeated for each brand.
• 2400TPS – 300 for get-products + 300 for get-product-details, (i.e. 600 repeated for each brand).

Note: We plan to publish specific API endpoints for each brand in-line with the standard, however they will all hit the same APIs on the backend
• Brand 1 - http://www.bank.com.au/brand1/cds-au/v1/banking/products
• Brand 2 - http://www.bank.com.au/brand2/cds-au/v1/banking/products
• Brand 3 - http://www.bank.com.au/brand3/cds-au/v1/banking/products
• Brand 4 - http://www.bank.com.au/brand4/cds-au/v1/banking/products

Background for the question:

When opening a new Joint account, the bank enables customers to elect ‘either to sign’ or ‘both to sign’, and customers have the option to update this election at any time.
• If a customer elects ‘Either to sign’; either of the joint account holders have the ability to individually manage the account to the full extend. This includes online access, view of all account details and transactions, making payments, setting up payees, change of product parameters, subscriptions, etc...
• If a customer elects ‘Both to sign’; neither of the joint account holders have the ability to individually manage the account. Both joint account holders must provide instructions in order to operate and manage the joint account.

Question

Using a non-digital form of capturing the JAMS election, and adopting the “One to authorise” election process Under Rule 4.2(1)(a). Is it acceptable to treat all existing to bank joint account holders, whom have previously elected the ‘Either to sign’ option, as being automatically opted into using Open Banking services, without the need for an additional JAMS election? This in turn will enable Joint account holders to utilise Open banking services as soon as the service becomes available, without the need to create additional friction by introducing another election process in the authorisation flow. Please confirm if this is an acceptable outcome?

In the latest update from the ACCC on white-label products, the ACCC states:

Where there are two data holders involved in providing a white label product (for example, where a brand owner bank distributes a credit card on behalf of a white labeller bank) the ACCC expects the data holder that has the contractual relationship with the consumer to respond to product data requests. The other data holder may also respond to product data requests. However, in the interests of avoiding unnecessary duplication, we do not propose to treat this as mandatory.

The data holder that has the contractual relationship with the customer (i.e. the brand owner) may agree with the white labeller that the white labeller will perform that obligation on behalf of the brand owner, in which case the brand owner remains accountable for performance of that obligation by the white labeller.

Question - We seek clarification on the highlighted part above, as based on our understanding a customer that holds a white-label product (Bank A branded card issue by a Bank B) has a contractual relationship with the Bank B (the white labeler), which issues the credit and not the Bank A(brand owner). Is the ACCC trying to indicated that the expectation is that the brand owner ADIs are expected to respond to product data requests for products branded in their brand including white-label products which they do not issue?