ACCC & DSB Data Holder Working Group Agenda & Meeting Notes (4th of June 2020)

ACCC & DSB Data Holder Working Group Agenda & Meeting Notes (4th of June 2020)

When: Weekly every Thursday at 3pm-4.30pm AEST
Location: WebEx, quick dial +61262464433,785383900%23%23
Meeting Details:

Desktop or Mobile Devices https://csiro.webex.com/csiro/j.php?MTID=m7c39ee9db5e5892ab35cd0bd7bbf94ce
Once connected to your meeting remember to start your audio and video
Please mute when you are not speaking.

Video Conferencing (VC) Rooms
Use the remote control or touch panel and dial the number indicated below:
External VC Room: 785383900@csiro.webex.com

Phones - AUDIO ONLY

• Primary Australia: +61 2 6246 4433
• Quick Dial: +61262464433,785383900%23%23
• Other Global Numbers: https://conferencing.csiro.au/Call-in.php
• Meeting Number/Access Code: 785 383 900

Agenda

1. Introductions
2. Outstanding actions
3. CDR Stream updates
4. Q&A
5. Any other business

Meeting notes

• Meeting Notes
• Next steps

Introductions

• 5 min will be allowed for participants to join the call.

Actions

Type	Topic	Update
Decision Proposal	Banking Maintenance Iteration 03	Decision Proposal 108
Decision Proposal	Decision Proposal 109 - NMI Standing Data Payloads	Decision Proposal 109
Decision Proposal	Decision Proposal 119 - Enhanced Error Handling Payload Conventions	Decision Proposal 119
Workshop	DSB - Enhanced Error Handling - Online Workshop 01 - Error Structure	Event registration
Workshop	DSB - Enhanced Error Handling - Online Workshop 02 - HTTP Response Codes	Event registration

CDR Stream Updates

Provides a weekly update on the activities of each of the CDR streams and their workplaces

• ACCC Rules
• ACCC CDR Register (Technical)
• DSB CX Standards
• DSB Technical Standards - Energy & Banking

Presentation

Topic: Enhanced Error Handling
Presenter: Mark Verstege
An overview of the proposed changes to error handling across ADRs, Data Holders and the CDR Register software.

Slides can be found here.

Q&A

Questions will be received by the community via WebEx chat before the questions are opened to the floor. Participants can pre-submit questions to the DSB mailing box.

Currently received pre-submitted questions:

#	Question	Answer
#1	Follow-up on: "To be eligible to share data, each joint account holder needs to be over 18, and be the account holder for an account that is set up in such a way that it can be accessed online. If one joint account holder sets up their online access to the joint account, it could be argued that both joint account holders will be “account holders for an account that is set up in such a way that it can be accessed online” (i.e., it is accessible online, but only to the account holder who set up access). Is it the intention of the rules to capture joint account holders accounts where the second joint account holder is unable to access the account online?"	-
#2	Question regarding the term “publicly offered” (clause 1.4 of Schedule 3 to the CDR Rules) What is the ACCC’s view of the term “publicly offered?” Clarification is sought as to how this term is intended to be interpreted.
#3	Can the ACCC outline the plan for what the industry testing/conformance will look like in practice for the non-major banks, including timelines?
#4	What is the limit on historical account/transaction data which a DH needs to share, i.e. what is the “oldest time” that an ADR can request for?	Answered provided from in chat: For question #4 (on historical acount/transaction data): Please refer to page 80, and 97 on the CX Guidelines here- https://consumerdatastandards.gov.au/wp-content/uploads/2020/05/CX-Guidelines-v1.3.0.pdf
#5	Is there an obligation for a DH to provide a developer portal to publish their API documentation? If so, for a DH with multiple brands registered under them in the CDR register, does the DH need to provide a separate branded developer portal for each brand?
#6	Is there a specific requirement around displaying account details (BSB/account number) in full in the consent/authorization flow or can a DH show these details masked?
#7	Seeking clarification on reporting section (4. Refusals to disclose). As per CDR Rules 4.7(1)(c) and CDR Rules 4.7(1)(d) ‘refuse to disclose’ and ‘refuse to ask for an authorisation’ are 2 separate concepts. CBA's position is that record keeping (CDR Rules 9.3) and reporting (CDR Rules 9.4) relate to the concept of ‘refuse to disclose’. This is further re-enforced in the reporting form guidance in relation to requests to an API “…the data holder has not disclosed CDR data in response to a request”. We are of the view that only the ‘refuse to disclose’ concept that is in scope for record keeping and reporting. Please confirm in writing.
#8	Seeking clarification on CBA’s position: during outage periods, failure to respond to API requests does not constitute a refuse to disclose. This is in relation to both planned outages, and incidents (unplanned outages). By nature these periods will have limited system capabilities and will not provide reliable instrumentation. Additionally, planned outages and incidents are measured through other data standards APIs. James clarified during the DH WG 14/5/2020 that Refuse to disclose applies when there is an intentional active condition that is refusing, which is why incidents and planned outages does not fit the definition of refuse to disclose. We agree with the view that planned and unplanned outages are not refusals to disclose and will not be in scope for record keeping and reporting. Please confirm in writing.
#9	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. Please confirm in writing.
#10	Danielle confirmed first reporting period for rule 9.4 is (6/2/2020 to 30/6/2020). Please confirm in writing.
#11	Danielle confirmed the report 9.4 does not need to be brand specific. This does not mean DH can’t report each brand separately, but it would be permitted to report all brands under 1 report. Please confirm in writing.
#12	During the DH working group (14/5/2020) Danielle communicated the intent of 9.4 reporting form Section 3 was to represent the total number of requests (both successful and failed), and Section 4 represent the proportion of those that failed due to refusal to disclose. This indicates refusal to disclose is a measurement at the API transaction grain – which aligns with CBA’s existing interpretation. 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. Please confirm in writing.
#13	Incorrect data has been observed in Product Reference Data APIs provided by the Major Banks, including incorrect lastUpdated dates, incorrect application of bundled discounts, misleading characterisation of fees, missing fees, and non-standard API response pagination. - What processes are in place to ensure sufficient data quality standards are adhered to? - What are the respective roles of ACCC and ASIC in the regulation of this area? - What process should interested parties follow when errors are found?
#14	The 4 Major Banks differ significantly in the way they have applied the data standards for product reference information. This is most pronounced in Residential Mortgage products, where products include a range of different price variations (eg owners vs investors, P&I vs Interest Only repayments, packaged vs non-packaged, fixed vs variable and different fixed loan terms). In every one of those types of price variation, there are at least 2 different approaches among the 4 banks and in some cases there are 4 different approaches. This will lead to significant difficulties for data users wishing to make accurate and complete product comparisons, and in some cases it will lead to an inability to compare or to users unwittingly making incorrect or misleading comparisons. - How does the ACCC propose to resolve these issues and how can interested parties assist?
#15	Non-ADI lenders are a significant segment in the home loan and personal loan markets. Currently the standards do not require product reference data to be published by non-ADI lenders. Given that one of the stated aims of CDR was an ability to provide consumers with better product comparison, this seems to be a major oversight. - What plans does the ACCC have to expand CDR obligations to non-ADI lenders?
#16	The response provided by the ACCC is from a Non-ADI perspective. Could we please request that the ACCC provide a response from an ADI perspective (i.e. where the ADR is an ADI). Will it be required that the ADR who has as a result of accumulating the multiple ADHs data respond to requests or be obligated to provide this accumulated or consolidated data to all of the respective any or all the original ADHs? In effect if you took a traditional PFM use case would where a consumer can “see all their accounts in one place”, that a consolidated view of transaction data forms the minimum data set that is eligible for reciprocity????	For information concerning ADI reciprocity This question has two elements to address: 1. If an ADI receives designated CDR data, through any means other than the CDR, the ADI is a data holder of that data (‘first case’ reciprocity 56AJ(1)). 2. If an ADI is accredited, and receives CDR data via the CDR regime, the ADI will become a data holder only if the conditions in 56AJ(4) and Clause 7.2 of Schedule 3 are met (‘third case’ reciprocity 56AJ(4)). Once the ADI is a data holder in respect of the data, the ADI is required to share that data in response to a valid request (whether under the direct to consumer mechanism or with an ADR). The timeline for direct to consumer functionality is still under consideration, and there is currently no requirement for DHs to provide functionality that facilitates consumer data requests made by CDR consumers. During the course of the meeting, a follow up question was asked about correction obligations where 3rd case reciprocity has occurred. For example, if DH1 has become a data holder under third case reciprocity with respect to data originally received from DH2, what are their obligations for corrections (e.g., how can they correct data they weren’t responsible for creating)? It is necessary to consider if Privacy Safeguard 13 (correction at the request of a consumer) applies. If Privacy Safeguard 13 applies, it is necessary to consider rule 7.15 of the CDR Rules, which outlines the steps to be taken when responding to correction requests. If Privacy Safeguard 13 does apply because DH1 has previously disclosed that data previously received from DH2, then in response to a request to correct from a consumer, DH1 must either: 3. correct the data if DH1 has the necessary information to correct or include a statement with the data, even though they were not the originating source of the data. For example, if data received from DH2 had an incorrect address for a consumer, and the consumer asks DH1 to correct that data, DH1 may be able to correct if the consumer presents them with a proof of address. 4. give notice to the consumer why a correction or amending statement is not necessary or appropriate in the circumstances. For example, this may include if DH1 is unable to interrogate the data because they are not privy to why the record was made in the first place. In these circumstances, it is recommended that DH1 advise the consumer to contact DH2 to make that correction.
#Template

Notes

• TBA

Question and answers

#	Question	Answer/ Action
#1	During the CX stream update 'amending consent' was mentioned. Does this apply to the consent grant process, consent management or both?	By consent grant process do you mean the consent flow? For R4 research we looked into extending duration (toward expiry of the data sharing arrangement), and amending consent where disclosure/collection expires, but use continues. For R5- we are looking at adding/removing data sets through the trigger of extending duration (toward expiry of data sharing arrangement). I think in response to your question, we're looking at it more from a consent grant process, and less than from a consent management (ie- amending consent via the dashboard).
#2	can you please post the link to the banking comparator?	for those who want to view the Banking Product Comparator tool: https://consumerdatastandardsaustralia.github.io/banking-products-comparator/
#3	appologies if this has been asked before, but can you please confirm one more time that the current version for a non-major ADI deploying PRD in July '20 is: 1) common API's = V1 and 2) PRD Banking API's = V2	-
#4	We have a question in regards to the following CX Guidelines (Account Selection Page): Data holders are not permitted to show unavailable joint accounts as joint accounts need to be elected via a joint account management service before they are permitted to appear in the authorisation flow (See CDR Rules: Schedule 3, 4.1(1); 4.2; 4.3(3); and CDR Rule 4.24) Has consideration been given to customers whom only have joint accounts, under the above guidance such customers would not see any of their accounts listed under the ‘accounts unavailable for sharing’ section? Would it not be better to show such these accounts in the ‘accounts unavailable for sharing’ section, along with information about the joint account management service explaining the customers how to enable them? Note: page 80 of 1.3 Guidelines.	We acknowledge that we have received this question previously from you-so it's not lost! We will be getting back to you soon on this.
#5	just a comment here - i noticed that some of the questions documented in the minutes have "answered on the call by DSB" as answers - can you please publish what the actual response was so that we can refer to this documentation?	-
#6	Would it be possible to give every question a unique identifer(e.g. date/number) to enable these to be tracked and followed up on? Especially important for questions that are taken on notice.	-
#7	There was a very large and comprehensive testing assurance document published for the majors, would the same be made available for the non-majors in due course?	-
#8	Q related to #13, how and who will be responsible for data quality? Entities outside DH cannot validate the data, except customer himself. Do we expect the customer to report these variations?	-
#9	Hello Jarred #10 - does this mean we do not have to provide reporting for product data until those dates? e.g. CDR Participant complaints?	-
#10	Page 97 of https://consumerdatastandards.gov.au/wp-content/uploads/2020/05/CX-Guidelines-v1.3.0.pdf mentions Jan 1 2017 with "We have collected transaction data that may date back to 1st january 2017". It doesn't sound prescriptive to state that Data holders ought to be able to return 7 years worth transaction history. Sounds more like it is left to the how much the data holder can/cannot provide although the data receipient may have requested all the way back to Jan 1 2017.	Taken on notice
#Template		-

Other business

• TBA

Appendices

** Background for Pre-submitted Question #2**

Background

Clause 1.4(1) of Schedule 3 of the Competition and Consumer (CDR) Rules 2020 (CDR Rules) states that the term “phase 1 product” means a product that is publicly offered and generally known as being of any of the following types:

1. a savings account;
2. a call account;
3. a term deposit;
4. a current account;
5. a cheque account;
6. a debit card account;
7. a transaction account;
8. a personal basic account;
9. a GST or tax account;
10. a personal credit or charge card account;
11. a business credit or charge card account.

Pursuant to clause 1.2 of Schedule 3 of the CDR Rules, the term “product” has the meaning given by the banking sector designation instrument.
The Consumer Data Right (Authorised Deposit Taking Institutions) Designation 2019 (Designation Instrument) defines the term “product” in subsection 4(2) as:

1. a good or service that is or has been offered or supplied to a person in connection with one or more of the following activities:
   1.1. taking money on deposit (otherwise than as part-payment for identified goods or services); 1.2. making advances of money; 1.3. another financial activity prescribed for the purposes of subparagraph (b)(ii) of the definition of banking business in subsection 5(1) of the Banking Act 1959; or
2. a purchased payment facility that is or has been offered or supplied to a person.

The term “publicly offered” is not defined in the CDR Rules or the Designation Instrument, nor banking legislation generally.

Both the Explanatory Statement to the CDR Rules and the Explanatory Statement to the Designation Instrument are silent on the matter of what is considered to be “publicly offered.”

In assessing call account and term deposit products, according to the above they are products captured by the term “phase 1 products” for inclusion in product reference data obligations. Our product department is quite sure that call account and term deposit products that are available only to wholesale clients are not intended to be within scope. Guidance is sought from the ACCC as to whether the term “publicly offered” is intended to be construed as excluding products available to wholesale customers only.

Next Steps

• Notes to be added and written up
• Next week's meeting scheduled