ACCC & DSB Data Holder Working Group Agenda & Meeting Notes 2020_04_23 - ConsumerDataStandardsAustralia/standards GitHub Wiki

ACCC & DSB Data Holder Working Group Agenda & Meeting Notes (23rd April 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: [email protected]

Phones - AUDIO ONLY

Agenda

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

Meeting notes

Introductions

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

Actions

Outstanding questions

Type Topic Update
Question Issue 187 Issue 187 Updated with commentary
Question “Hi, could you please advise what is a tolerable delay to show the transaction in the API response from the moment transaction is made.” At the moment, there is no standard or non-functional requirement with regard to data latency (ie. how up to date data should be). Instead, the requirement for data latency is that data presented via API end points should be commensurate to data presented via other primary digital channels. For example, for a Bank that provides a mobile application as their primary digital experience, a balance presented via one of the balance end points should be the same as the balance presented through the mobile application. The ACCC will monitor complaints concerning data latency issues. If the ACCC notices any trends in the complaints data, the ACCC may consider if any rule changes are necessary.
Feedback Scenarios - error response codes Actions taken: Issue 119, Issue 20, Issue 21 and Issue 22 have been raised to capture the next set of steps
Question A couple of weeks ago Liz stated that DH registration would not be required for PRD.  Can we please have this clarified? As a Data Holder, you are not required to register on the CDR Register until you are required to share CDR consumer data with accredited data recipients in accordance with the timetable set out in under Schedule 3 of the CDR Rules. You are not required to register to share product reference data nor report on product reference data via the Admin APIs.
Question 2. CDR data that becomes redundant must be de-identified or destroyed (Sec 56EO(2) Privacy Safeguard 12). Data becomes redundant when it is no longer needed by the Data Recipient (Sec 56EO(2)). a.Is the redundancy of CDR data automatically tied to the finish of a consumer's CDR consent period, i.e. are the two events linked together, or are they separate and unrelated? b.If these two events are indeed linked, what are the legislative or CDR Rule references for this linkage (other than through section headings)? Yes, redundancy is automatically tied to the end of a consent period or withdrawal of consent. Under section 56EO(2) the CDR entity must take the steps specified in the consumer data rules to delete or de-identify data which is no longer needed by the CDR entity for: A purpose permitted under the consumer data, rules; A purpose permitted in accordance with Division 5 (Privacy Safeguards); A requirement under an Australian law or court/tribunal order, or for current or anticipated legal or dispute resolution proceedings. When a consent expires, the ADR no longer has a permitted use or disclosure under Privacy Safeguard 6 (in particular rule 7.5(1)(a)(ii)). Therefore, unless there is a requirement under an Australian law or court/tribunal order or anticipated proceedings, the CDR data must be deleted or de-identified when consent expires.
Question 3. What public education about CDR/Open Banking is planned to be rolled out, and if so, when and what channels are planned to be used? 1) The ACCC is taking a phased approach to communications and engagement to coincide with the key implementation milestones. Our approach will use a combination of tailored communications through owned (websites and social media channels) and earned media (media coverage), and a range of targeted stakeholder engagement activities, in particular focussing on trusted intermediaries who can have an impact on what our target audiences know, feel and do in relation to the implementation of the CDR regime. 2) ACCC communications will take the form of a below the line campaign, which will be run primarily though the CDR.gov.au website, once it is launched in or around June, and ACCC social media channels. We are currently completing a RFQ process to procure a video developer to create educational videos for the CDR.gov.au website. We are also working very closely with Treasury, OAIC and DSB to ensure we disseminate consistent messaging to all stakeholders, and that we leverage off the communications and engagement work each agency is responsible for. This strategy will develop as we get greater clarity from Treasury and the Department of Finance regarding budget and responsibilities later in the year.
Question Are there any compliance/reporting requirements relating to Product Data (phase 1)? ACCC Response: Under rule 9.4(1)(c) – data holders are required to report every six months on the number of product data requests received during the reporting period, as well as the number of times the data holder refused to disclose data in response to a request and the rule or standard relied on for the refusal. We then followed up asking: Regarding your response to question 13, Rule 9.4(1)(c) states that the report required every six months will be “in the form approved by the Commission for the purposes of this rule”. Has the form been defined, and if so where can we find that please? The ACCC then provided us a form (attached) that was in draft awaiting feedback. This form is focused on Accredited Data Recipients reporting requirements, and does not clearly address what a Data Holder will need to provide during phase 1 (when only product data is being shared). We are seeking clarity on how to report to the ACCC, as a data holder, requirements relating to our product reference data, in accordance with rule 9.4(1)(c). We are expecting to release the approved reporting forms by the end of the month. We expect to release further guidance on our reporting expectations for phase 1 PRD obligations alongside the reporting forms
Question Are Data Holders required to submit any reports during Phase 1 – Product Reference Data? If yes, is there any specific reporting template that can be used to submit phase 1 reports? Yes, Data Holders are required to submit reports during Phase 1 – Product Reference Data. We are expecting to release the approved reporting forms by the end of the month. These will be made available on the ACCC’s website.
Question Brooke around the questions related to compliance/reporting requirements relating to product data (phase 1) be shared with the whole group, or noted on github or meeting minutes? We will endeavour to share information about compliance and reporting requirements relating to product data on github or meeting minutes. We are expecting to release the approved reporting forms by the end of the month. We expect to release further guidance on our reporting expectations for phase 1 PRD obligations alongside the reporting forms.
Question Could you share how to access the excel template for semi annual reporting of Product data and refusals mentioned before? We are expecting to release the approved reporting forms by the end of the month. These will be made available on the ACCC’s website.
Question Under the CDR Rules, a data holder must have an internal dispute resolution process which complies with RG165. Do complaints or disputes include expressions of dissatisfaction in regards to Product Reference Data? The Rules require data holders to have internal dispute resolution processes that comply with provisions of Regulatory Guide 165 that deal with certain matters, as if references in Regulatory Guide 165 to complaints or disputes were references to CDR consumer complaints. CDR consumer complaints means any expression of dissatisfaction made by a CDR consumer to or about a CDR participant that relates to, inter alia, the CDR participant’s obligations under or compliance with Part IVD of the Competition and Consumer Act 2010, the Competition and Consumer (Consumer Data Right) Rules 2020 or the binding data standards. Given this, expressions of dissatisfaction made by CDR consumers in regard to Product Reference Data is captured within the meaning of complaints or disputes.

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

No presentation is scheduled for this week.

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 What should happen to Data Recipient calls on V3 between Sept 2020 and Feb 2021 if the data holder does not update their version to V3 until Feb 2021? This has been clarified in Issue 192
#2 Will we need to support, as a minimum, V2 PRD API’s from July 2020 to 29 Aug 2020 (ie 2 months) to be compliant and then we may decommission it and support V3 PRD API’s? V2 must be supported at least until Feb 2021. No decommission date has been explicitly set for v2 and when one is set it will be after the mandatory date for v3. If you support v3 from Feb 2021 you can choose to tell data recipients that this is the minimum version you support and you do not support v2.
#3 Can we implement and support V3 PRD API’s from July 2020 only No – the future dated obligation is February 2021. You can choose to adopt v3 earlier than Feb 2021, but it is at your discretion
#4 Reaching out to see if there been any news around the implementation timelines for the non-majors due the covid19 challenges? Does the standards body have a view on this? Answered on call and part of the publication by the ACCC here
#5 Would you mind advising if it is possible to access an environment that we could connect and authenticate with so that we understand the flow that is required for onboarding? We understand there are a number of select organisations for the formal process of certification etc. but hoping there is some type of sandbox for others to play with who intend to form part of the second wave. Sandboxes for the Register, Information Security and Banking APIs are not currently available. Swagger definitions on the CDR Register and Consumer Data Standards provide sample responses to calls made to the Register, Data Holders and Data Recipients. These can be used to inform development work. The ACCC is developing a Conformance Test Suite (CTS) which will include tests to call the CDR Register, Data Holders and Data Recipients. However it will only be made available to participants who are in the process of onboarding to the ecosystem. It won't be publically available as a sandbox.

Notes

Stream updates: Rules

  1. Paul Franklin was a guest for the ACCC Rules team
  2. Clarity on timeline and expectations was for a release to be made in the next few days, link is here: https://www.accc.gov.au/media-release/temporary-exemptions-under-consumer-data-right
  3. Stage 04 was not be included in the announcement – still under discussion
  4. Accreditation for intermediaries and application window; no timeframe for these
  5. No quick fix for screen-scraping, best method is to proceed to data sharing endpoints
  6. Rules draft to be published late this week or early next week
  7. Short consultation period; only two weeks
  8. Proposed to come in effect from the 1st of July 2020

Register

  1. Release 1.1.1 has been released on Monday morning past
  2. GitHub Issue #94 has been raised to capture what Data Holders would like to see and be most beneficial for their dashboards

CX

  1. Michael Palmyre was an apology for this week
  2. v1.3.0 CX Standards and Guidelines released. This release resolved a few issues, minor defects, and provided clarity on a few standards items including the display of unavailable accounts. A report on further joint account and right to delete research is being finalised for publication. This goes into a bit more depth on joint account election and authorisation, including the JAH2 experience. The JA and CDR Logo issues on GitHub have been commented on noting that a decision has been delayed so that rules changes can be consulted on.

Technical - Banking

  1. Released 1.3.0 of the Data Standards end of last week
  2. Included CR and scope of Iteration 02
  3. New standard for concurrent consent included
  4. Kicked off Banking Maintenance Iteration 03 link here
  5. Standards Issue #108 – welcome to any and all feedback
  6. Enhance Error Handling; fantastic feedback received – drive is to delve into each more deeply, thus the different standards decision proposals

Technical - Energy

  1. James Bligh was an apology for this week

Question and answers

# Question Answer/ Action
#1 Does onboarding cover both Recipients and Holders? Yes, both Data Holders and Data Recipients will be required to onboard.
#2 I was wondering if another security review will be conducted, given the standards have been significantly expanded and modified? Internally reviewing this, will advise if another Security review is required.
#3 Does a data holder have to create V1 for the period 1 July 2020 to 29 August 2020 or are they able to create only V2 from 1 July 2020 onwards? Answer here
#4 I could not see any difference between the Get Products v2 and v3 api specifications, was that intentional or am I missing something? Action taken to verify version increment
#5 ANZ is looking for some clarity around closed accounts. It is clear based on the rules the transaction data range we are required to supply (i.e 24 months) but it is not specifically stated if Account information (account details and balances) is required to follow the same rules. We are also assuming the following are out of scope as they are not valid on closed accounts: Direct debits , Scheduled payment. Could someone from the rules team please comment on the points above? Question taken on notice
#6 Does a data holder have to create V1 for the period 1 July 2020 to 29 August 2020 or are they able to create only V2 from 1 July 2020 onwards? Answer here
#7 Up until Aug 29th 2020, can we tell clients that the minmum supported version is V2 and not support V1? Answer here

Other business

  • Energy Workshop on the 29th of April 2020 @ 2pm

Next Steps

  • Questions are to be fielded internally and answers provided when they are ready