Skip to content

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

Jump to bottom
CDR API Stream edited this page Nov 12, 2020 · 5 revisions

ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes (12th 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 11th of November 2020 View the newsletter here
CDR Support Portal Known issue - those who are subscribed to follow a user profile may not be receiving email notifications of new posts being published Issue Resolved - email notification recommenced yesterday 11th of November 2020. Cause of issue remains unidentified
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
Community Request from NTT Ltd for Community help with their usability testing Post on the CDR Community Forum for more details and how to sign up
Community A community made CDR Trivia game is live on the Community Forum - a great initiative by Manglu Balasubramanian, Randima N and Xin Chen Link to the CDR Trivia Game
Community Guides available on managing your CDR Support Tickets
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

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

No presentation 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.

Current received pre-submitted questions:

Answer provided

Ticket # Question Answer
220 In the case of a fraud or data security event, how do ADRs communicate with other OB participants, including the ACCC? Is there any obligation on the ADR in these circumstances? Thanks for your query.
    While there aren’t any specific prescriptions within the CDR Rules which explicitly require ADRs to communicate the details of a data security event or fraudulent activity to participants or the ACCC, we hope the following points will be of use:
    • In the event of a data security breach, the correct notification pathway would be via the Office of the Australian Information Commissioner (OAIC), as per s56ES of the Competition and Consumer Act 2010. The ACCC and the OAIC will share information in accordance with the ACCC-OAIC CDR Memorandum of Understanding and take action as appropriate, in line with the ACCC-OAIC Compliance and Enforcement Policy for the CDR
    • The CDR Rules do not currently include provisions for notification of fraud. There are a number of options available to the ACCC and its co-regulators to address fraud in the future, including:
      • an amendment to the CDR Rules
      • a standing request by the Accreditation Registrar requiring participants to provide notification of any instance(s) of fraud they are aware of, with wider communication of the activity being at the discretion of the Registrar
      • amendments to RAAP procedures
      • consultation with industry on their preferred method for providing notification of fraud within the CDR system.
    • The ACCC are continuing to analyse security monitoring and reporting structures, noting that we are currently working through architectural issues
      • we are looking at appropriate mechanisms for ADRs and other CDR participants to report issues, both in CDR and in relation to wider (economy-wide and industry specific) frameworks
      • we are in the initial stages of documenting a process for responsible disclosure and a reporting issues. This will be done in accordance with best practise guidelines as seen in the Government’s Information Security Manual. We do expect to update and consult with stakeholders.
    • Under rule 5.14 of the CDR Rules, there is no specific obligation to provide notification to the Data Recipient Accreditor of fraud or a security data event, though the notification requirement under rule 5.14 may be triggered if there was a material change in circumstances that might affect the ability of the ADR to comply with its accreditation obligations, or alter its status as a fit and proper person
      • the CDR Rules require notifiable data breaches to be reported to the OAIC. Rule 1.7(3)(c) also requires ADRs to notify the ACSC of any data security incidents, no later than 30 days after the incident. The ACSC use this for information gathering and monitoring of security incidents, but don’t currently have any processes in place to share that information with CDR participants
      • if an ADR’s accreditation was revoked or suspended as a result of fraud or a security data event, notification to relevant data holders of the revocation or suspension could occur via the Register.
222 A question to the ACCC re rule 4.25 (). What is the intent behind offering the customer an alternative channel to withdrawing their consent via the dashboard?
Outages of eBanking are understandably rare, short, and, where planned, at times less likely to impact. If, for whatever reason, eBanking (and the dashboard) were temporarily unavailable, it would still be significantly quicker to wait for it to be returned to service and withdrawal performed via the dashboard than to write to us and request the bank to action. They also have the ability to revoke consent via the ADR. Our intention was not to offer an alternative as we understood the rules to offer this as a valid approach and we do not believe it is in the spirit of the regime (ie the consumer is empowered to manage their own sharing arrangements). We did/do not want staff managing customer consent and do not believe this is appropriate. We intend/ed for our staff to support the customer if they required help but the customer always to manage the sharing. We welcome comment from both the ACCC and other ADIs.		 CDR Support Portal - Knowledge Article
267 Context: The Get Customer Details API doesnt have the customer ID in the path param. Understand that since this API will be accessed from the customer context, there need not be a customer ID explicitly mentioned in the input parameters. However, technically the customer ID is required to be passed to this API to fetch the customer details. Further Query is - Will the access token will be passed as bearer token in Authorization header? That is correct it is presented as a bearer token.
269 We would like to seek clarification on an edge case scenario regarding extension of an existing arrangement.
We assume that the extension of an existing arrangement is only allowed if the arrangement is still valid. i.e., ADR cannot seek an extension after an arrangement is either expired or revoked by customer.
If a request to extend an existing arrangement is made with cdr_arrangement_id in the PAR request and if the cdr_arrangement_id is not valid i.e., no active consent but we still recognize the cdr_arrangement_id, we can reject the request?		 CDR Support Portal - Knowledge Article
271 Is the data set an ADR/OSP derives from consumer data received from an ADH viewed as CDR DATA? Yes, that's correct.
Section 56AI of the Competition and Consumer Act 2010 gives the definition of CDR data.
The Explanatory Memorandum to the legislation that introduced s.56AI confirms that data derived from CDR data is still CDR data. It states, at para 1.114:
'The definition of CDR data includes data that is ‘derived’ from data listed in the designation instrument. It means that the Privacy Safeguards continue to apply to CDR data that relates to a consumer even if it has been subsequently transformed in the hands of the accredited data recipient.'
272 Does the CDR overwrite the RFC? When active = true or false the Introspective Response returns at least the following fields (active, exp, scope, cdr_arrangement_id)
Or
Does the RFC overwrite the CDR? When active = false do we only return 1 field (active)? When active = true we return the following fields (active, exp, scope, cdr_arrangement_id)		 In response to your question on the introspection end point.
The statements around required fields are not meant to override the normative standards that define the behaviour of the introspection end point. Specifically, it should not be seen as overriding or conflicting with the statements in the latter half of section 2.2 that describes how to respond to requests with invalid or expired tokens.
The field section is intended to modify the earlier part of section 2.2 which makes a variety of fields option and is not seen to be in conflict with the RFC. It is clarification aligned with the parts of section 2.2 that specifically allow for authorisation servers to extend or modify the introspection payload.
Essentially the fields section in the CDR standards ensures that data holders always provide the exp and scope fields (when it is valid to do so) so that ADRs can validate token capabilities. The cdr_arrangement_id is a CDR specific extension to support more complex consent scenarios.
278 Dynamically registering a client involves a series of steps interacting with systems such as an API Management Platform and Identity Provider.
This may make it hard to comply with the current performance requirements, which classify DCR operations as High Priority, and should thus provide a response in under 1,000ms.
Given that these are operations that are not expected to be high volume and no end user would be involved, it may be useful to reclassify them as Unattended, similar to Admin endpoints.		 In response to your feedback on the NFRs for the dynamic client registration end point, this feedback is helpful. We will incorporate it when we open consultation for making the NFRs binding and we would encourage you to reiterate that feedback when that consultation is posted.
279 Can you please confirm the list of Testing phases which are mandatory for non-major bank? Or for a bank that is planning to go-live as Data Holder in Mid-2021. It was announced in one of the meetings held in Oct 2021 regarding Conformance Test Suite that Industrial testing is now out of scope/non-mandatory testing phase for Data Holders. Can you please confirm what else is no marked as non-mandatory. Thanks for your query. Appendix B of the ACCC's draft On-Boarding Guide should speak to each of your questions, but if you have any outstanding queries, please do let us know.
280 Regarding CDR Rules Schedule 3 - Part 2.1, the consumer must have an open account that "is set up in such a way that it can be accessed online". We have seen at least 1 bank interpret that to mean that the customer must be registered for internet banking (IB). Is this in line with expectations? If a CDR consumer meets all the eligibility criteria in the Rules, including having an account with the data holder that is set up in such a way that it can be accessed online, then the data holder is obliged to respond to any valid request made by that consumer under the Rules.
In the Explanatory Statement to the Rules we published in February 2020, we noted that an account would be able to be accessed online if it could be accessed: 'for example, by using an internet browser or mobile phone application' (see para 73).
In practice, we expect this is likely to occur through internet banking in many cases. But our expectation is that any data holder with a customer who has at least one account that is set up in such a way that it can be accessed online, however that access is achieved, should consider carefully whether the customer meets the eligibility criteria in the Rules.
If the eligibility criteria are met, the customer is an eligible CDR consumer and will be able to make requests under the Rules in relation to any in-scope account they hold with the data holder.

Response pending

Ticket # Question Answer
173 Appreciate if we could get some answers to these github issues.
Expectations when a consumer closes their account/relationship with an ADR
Issue 313 		Taken on notice
189 I have been unable to find guidance on when a CDR Policy must be made available by Data Holders. A literal reading of the regulation would suggest that it should be made available as soon as any data sharing occurred (i.e 1 October for most data holders). However, the vast majority of a typical CDR Policy is only relevant for customer data sharing. Can you confirm that a Data Holder does not need to provide a CDR Policy until they begin customer data sharing? Taken on notice
190 I am seeking guidance on how "wholesale" products are handled in the CDR. In this context I'm talking about products that are sold via alternative channels, but branded by the Data Holder. Examples would be term deposits sold through marketplaces such as Australian Money Market or Cashworkz, or loans sold through brokers. In these cases, the terms and conditions may differ from directly sold retail products. As the channels are generally not ADIs and therefore not Data Holders, I would assume any obligations would fall back on the product originating ADI. It's unclear if these products are "publicly available" under the CDR definitions as they are not sold directly by the ADIs concerned. Additionally, the terms and conditions can vary across the re-sellers and so if required, how should they be exposed in the PRD APIs? A separate entry for each re-seller, or a generic entry with, for example, no rates given? Any additional guidance around "wholesale" products sold through alternate channels would be appreciated. Thanks. Taken on notice
192 We, are looking for clarity on requirements that are compulsory for account & transaction data on Phase 1 & 2 products, specifically for joint accounts. We understand that ACCC provided the Joint Account Guidance where scenarios are outlined. The question we have is on the status of Joint Account Guidance document – are the requirements derived from this document compulsory to implement, or only suggested but not compulsory? Specifically the next two requirements – are they compulsory to implement for account & transaction data on Phase 1 & 2 products release:
1. ‘Pause’ via JAMS (Scenario 4a & b)
If one of Joint Account Holders removes an election via JAMS for an account that is already in an active sharing arrangement with 3rd party, authorisation should not be withdrawn, but the data sharing for that account should be stopped. Removal of election via JAMS for joint account does not cause removal of this account from authorisation. It only caused the data sharing to stop for this account.
2. Resume via JAMS (Scenario 4c & 7)
After the requirement above, if both Joint Account Holders elect though JAMS for this same joint account that is ‘paused’ in an active sharing arrangement to be shared back (meaning this account is marked back as ‘available for data sharing’), the data sharing should continue as this account was never removed from authorisation in the first place.		 Taken on notice
195 Could you please provide clarity about what “a product that is publicly offered” (under the ACCC CDR Rules) and “products that are currently openly offered to the market” (under the CDR Standards for Banking APIs) means when it comes to sharing required PRD. Specifically, if a phase 1 product is currently only offered by direct invitation to existing customers (i.e. not through online application channels), is PRD required to be shared? Taken on notice
196 https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/329
https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/330 		Taken on notice
204 Clarification on Data holder providing link to CDR policy: This question relates to Part 7 – Rules relating to privacy safeguards, section 7.2.1.
According to this rule, a Data Holder (DH) will need to include details of the complaints process on the Consumer Data Right (CDR) policy..
The question is at which stage (wireframe) is the CDR policy expected to be shown on Data holder side.
As per the CX guidelines, the CDR policy is only visible on the Data recipient Consumer dashboard as attached.		 Taken on notice
208 Seeking further clarification with regards to the CDS rule - Part 5, Division 5.2 (Rule 5.10) which states that
5.10 Other conditions on accreditation
(1) The Data Recipient Accreditor may, in writing:
(a) impose any other condition on an accreditation:
(i) at the time of accreditation under subsection 56CA(1) of the Act; or
(ii) at any time after accreditation; and
(b) vary or remove any conditions imposed under this rule.
and that ...
(5) The Accreditor:
(a) may, but need not, give public notice of a condition or variation imposed or removed under this rule; and
(b) may do so in any way that the Accreditor thinks fit.
Example: The Accreditor could give public notice of a description of the effect of the conditions, rather than of the conditions themselves.
Background: Given that these conditions could be varied and nebulous there is the potential of impact on data holders when engaging or providing CDR Data to an Accredited Data Recipient (ADR)
As example - What if the condition is:
1. the ADR is only allowed access to a subset of CDR Data; or
2. only able to receive a particular period of CDR data; or
3. only able to hold authorisation for a particular period.
Question:
Due to the above are Data holders required to identify and comply with these conditions; and
if there is a breach of a condition due to CDR data passed from a Data Holder to an ADR, where does liability sit?
Adding some more clarification on the context related to the question,
1. Will these conditions placed on the ADR , be within the metadata update endpoint i.e. DH be informed of these new imposed conditions via metadata update?
2. Regardless of whether it’s in the metadata end point or not, who will be liable to ensure the correct information has been shared between the DR and the DH?
a. Will it be on the DR – that they are only requesting the information they have been accredited for?
b. If a DH has packaged information, and there is a data set in that package – is it up to the DR to only consume the information they are conditioned to or is it up the DH to remove the set of information DR is not allowed to access ?		 -
209 Where there is a joint account with a Power Of Attorney, what are the rules around sharing data, when both parties are required to authorise the sharing of data?
The Power of Attorney question also relates to individual accounts. Where a request has been made, however it has been made from the Power of Attorney, what rules apply to sharing the data? If we have deemed the transaction not be be causing financial or physical harm, is there an issue with sharing the data?		 -
210 We have noticed the answer provided on ZenDesk in relation to the minimum product grandfather period (https://cdr-support.zendesk.com/hc/en-us/articles/900002707406-Minimum-Product-Grandfather-Period), which asked if there were criteria required for products which have been grandfathered. Based on the response that said “No. If the product is open or was closed for less than 12 months it should be included."
We note that products can either be on-sale or not-for-sale (grandfathered). We therefore seek clarification on whether the intention of the previous response with respect to required consumer data is as in the attached table.		 -
214 Wanting to confirm the following in the phasing table:
1. Part 4 for 1 Feb 2021: is this a MUST timeframe or can FI's fall back to the 1 July 2021 as the MUST date?
2. Part 3 for 1 July 2021: has it been finalised that CDR Consumers (customers/members of the bank) can request their information directly from the FI?		 -

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