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.

To align with the record keeping requirements in subdivision 9.3.1, the ACCC’s expectations are that six years of consent and authorisation history are displayed in consumer dashboards for expired consents and authorisations.

Where consents and authorisations are current and have remained active, the full history is expected to be displayed in the consumer dashboard.

We are interested in understanding how temporary blocks work, and if a temporary block impacts a consumer’s ability to access their online banking entirely, just at the account level, or both depending on the circumstance.

Also interested in how common blocking accounts is as a risk-mitigation strategy.

Revoking a joint account election means CDR data on the joint account must not be disclosed (see rule 4.3(1)(b)(i)). However, it does not revoke any existing consents or authorisations.

For example, Anna is sharing a joint account and an account in her name alone with an ADR. If the joint account election is revoked (whether by Anna or by the other joint account holder), the data holder should no longer share data on the joint account, but should continue to share data on the account in Anna’s name alone. Anna’s consent and authorisation are not disturbed by the revocation of the joint account election.

If a consumer closes an account but remains ‘eligible’, sharing may continue on the closed account (assuming it was already authorised for data sharing), noting there may be no new data to collect post closure.

If a consumer closes an account and no longer has an open account that is able to be accessed online with the data holder, the consumer ceases to be an ‘eligible’ consumer for the particular data holder and their authorisation is withdrawn (see rule 4.26(1)(b)). Therefore, the CDR data should not be disclosed.

Will ADRs be requesting to Authorise scopes that are not in scope for non-majors in Phase 1?

The following authorisation scopes are not “in-scope” for non-majors in Phase 1
• Common:customer:detail:read
• Bank:regular_payments:read
• Bank:payees:read

An eligible consumer can make data sharing requests.

Where a consumer is eligible to make sharing requests, they can share data in relation to accounts held in their name alone or accounts for which they are a joint account holder (subject to the JAMS rules).

An eligible customer that holds an account in their name alone is able to share data on that account even if the account is guaranteed by someone else. As the guarantor is not an account holder of the account, under the current rules, the guarantor could not share data from that account.

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?

This policy decision has previously been consulted on and decided by the ACCC. Existing ‘either to sign’ or ‘both to sign’ may not be used to meet the JAMS election requirements.

However, as the joint account management service is not required to be online, when opening new accounts, for example, joint account holders may make a joint account management election via a form. It must be made transparent to consumers that they are making an election about consumer data sharing under the consumer data right, which is distinct from the ability to make payments, set up payees etc. on the account.

An ISO 27001 certification does not meet the information security requirement for the unrestricted level of accreditation.

The required assurance report must be prepared in accordance with the Australian Standard on Assurance Engagements (ASAE) 3150 Assurance Engagement on Controls standard, or an accepted comparable standard, and must address all aspects of the information security obligation and control requirements specified at Schedule 2 of the Consumer Data Right Rules. ASAE 3150 is an Australian method of auditing and reporting.

The following are accepted comparable standards for assurance reports:

When applying for accreditation, an applicant may seek to use an existing assurance report prepared in accordance with ASAE 3150, or one of the accepted comparable standards. However, the existing report must be no more than 6 months old at the time of submission of the accreditation application, and if it contains only partial coverage over the required controls in Schedule 2 while require certain treatment for acceptance.

See our Supplementary Accreditation Guidelines on Information Security for further information on what is required.

Q. Page 108 of the CX Guidelines provides that DH should indicate the 'status of consent' as (Active, Withdrawn, Expired and Once off), we understand under the ‘Active’ category it will need to show ‘Paused’ or ‘Interrupted’ consents. Although we understand the scenario in which a consent (which is in Active state) can be paused by DH at its discretion e.g. in the event of suspicious activity. Please explain in detail the following:
1. How does Pause/Interrupted need to be displayed on the Dashboard to execute this and where?
2. Can the Consumer pause/unpause the consent or is it only for DH admin to manage pause/unpause?
3. If the consent is paused what are the error codes and explanation to be provided to ADR for not sharing the data in pause situation
4. Does Consumer/ADR need to be notified that consent was paused by DH.



These are not properly understood in the industry and need to be explained in details with examples of the screen added in the CX Guidelines on page 108 under the Data Holder – Manage Authorisation Dashboard