Skip to content

ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes (19th of November 2020)

Jump to bottom
CDR API Stream edited this page Nov 19, 2020 · 3 revisions

ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes (19th of November 2020)

When: Weekly every Thursday at 3pm-4.30pm AEDT
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

Agenda

  1. Introductions
  2. 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.

Recording

The Consumer Data Right Implementation Calls are recorded for note taking purposes. All recordings are kept securely, as are the transcripts which may be made from them. No identifying material shall be provided without the participant's consent. Participants may contact@consumerdatastandards.gov.au should they have any further questions or wish to have any material redacted from the record.

Acknowledgement of Country

We acknowledge the Traditional Custodians of the various lands on which we work today and the Aboriginal and Torres Strait Islander people participating in this call.
We pay our respects to Elders past, present and emerging, and recognise and celebrate the diversity of Aboriginal peoples and their ongoing cultures and connections to the lands and waters of Australia.

Actions

Type Topic Update
Standards Version 1.5.1 Published Link to change log here
Standards Version 1.6.0 Drafted Link to Project Board with proposed changeshere
Standards Version 1.7.0 Proposed Link to Project Board with proposed changeshere
Decision Proposal - Energy Decision Proposal 117 - Distributed Energy Resources Payload View the Decision Proposal 117 here
Decision Proposal - Energy Decision Proposal 115 - Tailored Tariff Data Payloads View the Decision Proposal 115 here
Maintenance 5th Maintenance Iteration underway List of scope and agenda(s) can be found here
DSB Newsletter To subscribe to DSB Newsletter Link here
ACCC Newsletter To subscribe to ACCC Newsletter Link here
ACCC Newsletter Newsletter published on the 18th of November 2020 View the newsletter here
End of Year Winners of the survey: 10th of December 2020 (52.3%), through to the 14th of January 2021 (76.5%) We will keep everyone updated on the plan for over the Seasonal Break
Events Workshop to be announced in the next fortnight on Data Conventions
The Data Standards Body have published a draft of PROPOSED Data Conventions
We would like feedback and insight from the community		 The Conventions main article can be found here: CDR Support Portal - Conventions
Events Energy Workshop on the draft Standards, Authentication and Authorisation Register here on Eventbrite
Events DSB Data Quality Workshop 02 : Data Conventions Register here on Eventbrite

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 - Banking
  • DSB Technical Standards - Energy & Engineering

Presentation

Topic: Future Dated Obligations
Presented by: James Bligh
Link to material: Consumer Data Standards

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.

Current received pre-submitted questions:

Answer provided

Ticket # Question Answer
248 The DCR API states that the DELETE API is optional.
This implies that the data holders may optionally implement or not implement this API.
In the data holder responsibilities section - https://cdr-register.github.io/register/#data-holder-responsibilities the Data Holder has obligations to clean up registration.
The Data Holder will have to implement the cleanup registration even though they don't implement the DCR DELETE API.
In other words, if the DHs are already implementing the cleanup registration why do we keep the DCR DELETE API as optional?
The hard work is already performed by the Data Holders. It is now just a question of exposing the DELETE API for the caller to invoke
Q1: Why can't this be made mandatory (keeps things simple with little associated additional effort)
Q2: Is there a standard definition of cleanup registration? The Rules document and the CDR Register page haven't defined this term/activity. I simply assume that whatever we did during registration (we would do the necessary reversals of those activities). Is this up to the data holders to decide on what they perform as cleanup registration activity?		 There is currently no defined use case where an ADR would be required to clean up their own registration. Registration deletion has the consequence of invalidating all current consents so we would need to tread carefully here.
If you believe this is a technical design issue please raise it on the CDR Register GitHub https://github.com/cdr-register/register/issues.
270 Is there a different phasing timeline for white labeled products?
If an ADI has a white labeled credit card, are they expected to share Customer data regarding that product by 1/7/21 or is there a different date?
Do ADI CDR obligations still hold when the white labeler is not an ADI and the brand owner is an ADI?
If the ADI does not hold the data (key benefit of a white label) and the provider that does hold the data is not required to share data (not an ADI) therefore not set up for sharing, what is the expectation of the CDR?		 You asked whether ADI CDR obligations would apply where the white labeller is not an ADI/data holder and the brand owner is an ADI/data holder.
In our previous guidance on PRD for white labelled products, we stated that where there is a single data holder involved in providing a white label product (whether that is the white labeller or the brand owner), the ACCC expects the data holder to respond to product data requests in relation to the product. We have recently consulted on incorporating that position formally into the rules, and are now considering stakeholder feedback.
The guidance and proposed rules related to product data requests only, however, and do not affect consumer data request obligations in respect of white label products. Our policy overall is that white label products that are in-scope for CDR should be included in for the benefit of consumers. But as noted in our guidance, we are aware there is a wide variety of white label arrangements in the banking sector and beyond. We have therefore been engaging with key stakeholder groups regarding our approach to consumer data requests. We will also take the scenario you have raised into account as we finalise this position.
Finally, there is currently no separate timeline for white label products in the phasing table. As it stands, this means that obligations in relation to white label credit cards fall due at the same time as other credit cards. We are mindful of the coming compliance deadlines, however, and intend to update stakeholders about our approach to this issue in due course. We expect to communicate this via channels such as the CDR newsletter and here on the portal.
285 As per CDR Register API reference document( https://cdr-register.github.io/register/ ) if ADR status is "Suspended" and software product status is "Inactive", then consents need to be withdrawn. But if ADR status is "Suspended" and software product status is "Removed", then consents need to be invalidated. Can you please clarify what is the basic difference between withdrawal consent and invalidate consent ? How to invalidate consents? Is it same as "Consent Expiry"? I believe you’re referring to the table in this section of the register https://cdr-register.github.io/register/#data-holder-responsibilities.
Where the ADR status is “Suspended” and software product status is “Inactive” this is referring to an obligation on Data Holders and Accredited Data Recipients in the Rules that require data sharing to cease BUT all consents for the ADR to remain valid during the period of suspension. However participants must continue to facilitate withdrawal of consent at the consumers request during the period of suspension, refer Rule 5.23(3)(b)(ii)(A). If the suspension is lifted data sharing can resume using consents for consumers that have not expired during the period of suspension.
Conversely, where an ADR is revoked or surrendered all consents must expire, or be “Invalidated” refer Rule 4.14 (2). “Notes” following the table in the link above indicate this is suitable to be performed as an overnight process. This process of invaliding consents also applies where the ADR status is “Suspended” and the software product status is “Removed”.
In the context of the rules “Consent expiry” would ordinarily occur on the date nominated by the consumer when the consent was established. Invalidation occurs when all consents for an ADR are ‘expired’ at the same time due to an ADR's status changing from ACTIVE to either Revoked or Surrendered.
See excerpts of the aforementioned rules below. You may also be interested in the Guide on Finding the latest version of the Consumer Data Right Rules.
5.23(3)(b)(ii) in the case of a suspension—of the following:
(A) that any consents to collect and to use CDR data may be withdrawn at any time;
4.14 (2) If an accredited person’s accreditation is revoked or surrendered in accordance with rule 5.17, all consents for the accredited person to collect and use CDR data expire when the revocation or surrender takes effect.
I hope this clears things up for you, please don’t hesitate to let me know if you have a follow up question.
286 Do we need to include the Access-Control-Expose-Headers to expose the Access-Control-Allow-Origin header to be visible to java script clients for CORs support?
Most of the banks API implementations are failing in the Product Comparator Tool at the moment, and those whose APIs are not failing have this header present.
A definitive list of all require headers would be appreciated.		 All of the calls to CDR APIs include customs headers (for instance 'x-v' is always included as a minimum). The CORS specification indicates that calls with custom headers must be handled as pre-flighted calls rather than as simple CORS requests.
The pre-flight mode results in a initial HTTP call using the OPTIONS method that must be responded to successfully. Most modern browsers implement CORS this way. The following mozilla article has a good overview of the simple and pre-flight modes of CORS: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS.
In essence, if you do support the OPTIONS call then CORS will fail for PRD end points. This could be the issue you are facing.
287 Hi, just wondering if there is a current / latest version of the Data sets map, which mapped the designation instrument, Rules, Standards, APIs, Payloads? I've seen a couple of different versions from 2019, but the latest I could find was a draft from May 2019. If I could get pointed in the right direction please, that would be great. Thank you, In regards to your question regarding the data set mapping, I don't believe there has been an update to this document since July 2019. This document was a point in time support document and I don't believe it has been formally included in the rules or standards so it hasn't been actively maintained. Much of the content is now embedded in the CX standards and API sections of the standards, however. Also, there has been no designation change for banking so it is likely to still be accurate.
296 From Data Holder perspective what is the expectation for a customer that only has one account which is in a sharing arrangement with an ADR (or multiple ADRs). When customer closes this account (which could potentially mean they lose their online banking access), does that terminate the existing sharing arrangement(s) as customer is technically no longer eligible (they don't have active accounts with the DH, nor are their accounts set up in a way that they can be accessed online) or does the DH still need to respond to data requests even after the account and the relationship is closed, until the consent/authorisation is withdrawn explicitly? Regarding your question on customer eligibility:
Q: From Data Holder perspective what is the expectation for a customer that only has one account which is in a sharing arrangement with an ADR (or multiple ADRs). When customer closes this account (which could potentially mean they lose their online banking access), does that terminate the existing sharing arrangement(s) as customer is technically no longer eligible (they don't have active accounts with the DH, nor are their accounts set up in a way that they can be accessed online) or does the DH still need to respond to data requests even after the account and the relationship is closed, until the consent/authorisation is withdrawn explicitly?
A: As the definition of an eligible customer in the rules for the Banking Sector is for customers with at least one online account then the scenario you articulated would appear to make them ineligible. It is the expectation of the DSB that any arrangements in place for a customer that becomes ineligible should be treated as being revoked and should be actioned accordingly so that the ADR can clean up the CDR data previously shared according the customer's election.
300 In the last maintenance iteration the DSB included a set of impact analysis:
https://github.com/ConsumerDataStandardsAustralia/standards/wiki/DSB-Maintenance-Iteration-5:-Final-Checkpoint:-Agenda-&-Meeting-Notes-(12th-November-2020)
Notably the DSB specified:
- Initial Data Holder
- Non-Major Data Holder with specific reference to November 2021 obligation dates
Could the DSB provide guidance on where it sees "Early Non-Major Data Holders" in this analysis?		 Thanks for calling this out. We will take this on board and be more explicit in those considerations in future as we want to promote motivated DHs to go early where possible. Although it wasn't called out explicitly it was considered with the options to deal with CRN and CRN Type to reduce breaking changes and enable implementers to support CRN type only if it is known and derivable for the given DH.
304 Hi. Just want to check whether we need to expose Product reference data for a product that we consider as openly available but is not available to the customer through our online banking channel?
We have Commercial Loan products that are advertised on our main visitor site but these products are customised and the account is not visible through our online banking channel. Should these products be returned as part of Product reference data request? We believe that these products should be returned as part of PRD but will not be eligible for consumer data sharing (since the account is not available through online banking). Is this correct?		 Thanks for your question. PRD in relation to a publicly offered, offline product is likely to be subject to the PRD obligations in Part 2 of the Rules.
Schedule 3, Clause 3.1 of the Rules defines 'required product data'. While the data must be 'held in a digital form' to qualify, the product itself doesn't need to be available online.
Separately, it's important to note that products that aren't available through online banking may also be subject to the consumer data request obligations.
Provided the consumer is ‘eligible’ to make data sharing requests (see Schedule 3, clause 2.1), a consumer can make requests to share data from offline accounts. To be eligible, the consumer must have at least one account that they can access through online banking.
Where an eligible consumer makes a consumer data request, a data holder must disclose any ‘required consumer data’ that is the subject of that request. This can include ‘account data’, whether or not the account can be accessed online (see Schedule 3, Clause 3.2, and in particular Note 3 to that clause).
305 Hi All - In performing a risk assessment of our DH solution our risk folks asked if it is clear who is liable for our customers' data once it has been disclosed to an ADR. I have looked through the rules and this does not appear explicit. In "General Consumer Data Right FAQs" (10 June 2020) there is the statement " The Consumer Data Right regulatory framework, which covers the Competition and Consumer Act 2010 (Cth) (the Act) and the Consumer Data Right Rules, establishes clear principles of liability. " Where are these stated? If they are not documented can the ACCC confirm that liability of data security for data correctly disclosed to ADRs based on the customer's explicit consent is with the ADR? Thank you for your enquiry. Below is an extract from the Explanatory Memorandum to the Consumer Data Right Bill which introduced the changes to the Competition and Consumer Act:
Protection from liability
1.465 The CDR applies to data that is captured within designated sectors and data sets. As such, it is primarily about the provision of information by persons within the CDR system and consistently with the consumer data rules, the privacy framework and the Privacy Act 1988.
1.466 If a person provides information to another person or allows that person to access information, in good faith and complying with a CDR system requirement, the person providing the information is protected from liability. That is, a person so protected from liability will not be able to have an action taken against them, whether civil or criminal, for or in relation to the provision of the relevant CDR information. [Schedule 1, item 1, section 56GC]
1.467 A person who wants to rely on a protection from liability bears an evidential burden of proof. This is appropriate given that the person will know whether or not they received evidence of a valid consent or request and otherwise met the obligations in the CDR regime. [Schedule 1, item 1, subsections 56GC(2) and 56GC(3)]
As this explains, a data holder or an accredited data recipient will need to ensure that it has met its obligations under the Act and the Rules, and be able to provide evidence that it has done so.
For ADRs, this includes compliance with data security requirements such as those in the data standards, Schedule 2 of the consumer data rules, and in the privacy safeguards (particularly Privacy Safeguard 12). We would not expect liability to accrue to a data holder in relation to data once disclosed to an ADR but the data holder does have an obligation to notify a consumer of any disclosure (Privacy Safeguard 10) and continuing obligations under the CDR regime such as to ensure that the data that it has disclosed is correct and accurate (Privacy Safeguard 13). Please see the OAIC’s Privacy Safeguard Guidelines.
Please note that the above is to provide you with general advice about the obligations under the CDR regime. We are not able to give legal advice about BABL’s operations, circumstances or potential liability.
316 I just wanted to clarify, I've had some questions about the reporting requirements based on the response from ticket #53 -
"Q: Do requests blocked for these reasons (bad scraping behaviour/bot) need to be included in ACCC reporting?
A: Yes"
Should the 'rejections' metric in the Get Metrics API and 'Refusals' in the ACCC (Rule 9.4) form include the number of requests blocked by our edge services (Akamai for example) due to reasons like reputation-based scoring or maliciously formatted requests (like script injection), or is it only intended to capture 'Number of calls rejected due to traffic thresholds over time' as explicitly stated in the standards? -
https://consumerdatastandardsaustralia.github.io/standards/#tocSrejectionmetricsv2 		Thanks for your follow up on issue #53. Specifically your question is below:
Q: Should the 'rejections' metric in the Get Metrics API and 'Refusals' in the ACCC (Rule 9.4) form include the number of requests blocked by our edge services (Akamai for example) due to reasons like reputation-based scoring or maliciously formatted requests (like script injection), or is it only intended to capture 'Number of calls rejected due to traffic thresholds over time' as explicitly stated in the standards? - https://consumerdatastandardsaustralia.github.io/standards/#tocSrejectionmetricsv2
A: As stated in the standards the 'rejections' metric in the Get Metrics API should only contain calls that were rejected due to traffic thresholds but would otherwise have been valid. To be clear, it is not expected that malicious or invalid calls that would be screened out by your WAF or CDN should be included in this definition.
Refusals are otherwise valid requests rejected due to the exemption criteria (e.g. to protect the customer). There is currently no metric for refusals to be included in the Get Metrics API but they are required for ACCC reporting.
For clarification, my comment that the number of calls being screened out by your WAF would need to be available for ACCC reporting should not be understood to mean that this data is represented in the Get Metrics API. The ACCC have broad powers with regard to reporting and they are both able, and possibly likely, to request information regarding the number of malicious calls that are being made to CDR end points at some stage to aid them in regulating the ecosystem.

Response pending

Ticket # Question Answer
314 Would it be possible to provide an extract of the Act, Rules and also the CX Guidelines ‘should’ and ‘must’ criteria in a plain text list format? This would help Implementation teams more easily confirm they have met their obligations, and Compliance teams verify that fact as part of their formal assessment process. So you understand the request more easily… we have had to convert the Rules and Act into a monster 1300-line XLS with each clause separated so we can demonstrate evidence and cross-reference to screen-shots of our UI, policy docs, processes etc. It’s a massive body of work and we’ll have to re-do it as soon as the new Rules come out. We did a similar thing for the CX Guidelines which was an even bigger job as they’re really wireframes with notes so very hard to copy/paste into something that can be used as a checklist. Answer in progress
98 Answer in progress
107 Answer in progress
139 Answer in progress
172 Answer in progress
174 Answer in progress
189 Answer in progress
196 Answer in progress
203 Answer in progress
209 Answer in progress
214 Answer in progress
221 Answer in progress
225 Answer in progress
232 Answer in progress
244 Answer in progress
250 Answer in progress
256 Answer in progress
257 Answer in progress
259 Answer in progress
261 Answer in progress
263 Answer in progress
265 Answer in progress
268 Answer in progress
274 Answer in progress
281 Answer in progress
283 Answer in progress
289 Answer in progress
290 Answer in progress
291 Answer in progress
292 Answer in progress
293 Answer in progress
295 Answer in progress
299 Answer in progress
301 Answer in progress
303 Answer in progress
308 Answer in progress
309 Answer in progress
310 Answer in progress
311 Answer in progress
312 Answer in progress
315 Answer in progress

Notes

  • TBA

Question and answers

# Question Answer/ Action

Other business

  • TBA

Appendices

  • TBA

Next Steps

  • TBA

Getting Started

Meetings

Maintenance Iterations

CDR Implementation Call

Clone this wiki locally