-
Notifications
You must be signed in to change notification settings - Fork 56
ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes (28th of January 2021)
CDR API Stream edited this page Jun 8, 2021
·
9 revisions
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: [email protected]
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
- Introductions
- Actions
- CDR Stream updates
- Presentation
- Q&A
- Any other business
- 5 min will be allowed for participants to join the call.
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 [email protected] should they have any further questions or wish to have any material redacted from the record.
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.
| Type | Topic | Update |
|---|---|---|
| Standards | Version 1.6.0 Published | Link to change log here |
| Standards | Version 1.7.0 Proposed | Link to Project Board with proposed changes here |
| Maintenance | 6th Maintenance Iteration planned for 2021 | Read about the Maintenance Iteration - If you would like to join these please reach out to [email protected] |
| DSB Newsletter | To subscribe to DSB Newsletter | Link here |
| ACCC Newsletter | To subscribe to ACCC Newsletter | Link here |
| ACCC Newsletter | 20th of January 2021 Edition | View in browser here |
| DSB Newsletter | 22nd of January 2021 Edition | View in browser here |
| Consultations | Decision Proposal 149 - Energy Draft Feedback Cycle 1 Feedback is now open on any issue related to draft. This thread will remain open until February 12th 2021. At that time proposed changes will be incorporated and a second consultation cycle will commence. |
Link to consultation |
| Consultations | Decision Proposal 145 - Strategy for Reporting & Metrics Feedback is now open for this proposal for an extended period to account for the end of year break. Feedback is planned to be closed on Friday 29th January 2021. |
Link to consultation |
| Consultations | Decision Proposal 144 - Amending Consent Authorisation Flow Feedback is now open for this proposal for an extended period to account for the end of year break. This consultation window will close on ( extended to ) Monday, 1st February at 5pm. |
Link to consultation |
Provides a weekly update on the activities of each of the CDR streams and their workplaces
| Organisation | Stream | Member |
|---|---|---|
| ACCC | Rules | Andrew Breeze |
| ACCC | CDR Register (Technical) | Elizabeth Arnold |
| DSB | CX Standards | Michael Palmyre |
| DSB | Technical Standards - Banking | Mark Verstege |
| DSB | Technical Standards - Energy & Engineering | James Bligh |
No presentation today.
However we will walk through Masking of Accounts and PAN from the Consumer Data Standards today.
- What are the data masking requirements for Biller CRNs?
- What are the data masking requirements for account numbers?
- We don't mask Biller CRN in our Internet Banking platform; do we need to do this for the Consumer Data Right?
- For Transaction data, if PANs are present should we mask this information?
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:
| Ticket # | Question | Answer |
|---|---|---|
| 232 | Till Nov 2021, Consumer data requests made by eligible CDR consumers are out of scope. The regulatory report excel sheet has an entry for this which will likely be 0. 3.2. Number of consumer data requests received from eligible CDR consumers Is there a plan to update the sheet removing this entry or do we as Data Holders send this value as 0 when we report this to ACCC? |
Thanks for your query. Two cells above the item you refer to, the reporting form includes the following guidance: - If a type of consumer data request is not relevant for the particular reporting period, for example, direct consumer data requests from eligible CDR consumers are not yet phased in under the rules, leave the relevant section blank. All data holders should use the approved reporting form until further notice, including following all of the drafting guidance it contains. Please let us know if this is useful. CDR Support Portal Article |
| 395 | we are interested in the thinking and history behind the definition of eligible cdr consumer in the rules. The requirement for a customer to be a holder of an open account means that a primary use case (ie credit checks/loan origination) will not be available for some customers with respect to given Data Holder/s. Further, what is the logic in requiring the DH to expire consents if/when a consumer becomes ineligible via the current rules - it appears to be both an impost on the DH to satisfy and a sub-optimal CX (I would presume they would, by and large, expect/prefer the sharing to continue). | The concept of an ‘eligible’ CDR consumer relates to the class of consumers who can share data under the CDR. For individuals, it captures customers of the data holder who are over 18 and have at least one open and online account. These customers will have online credentials with a data holder through internet or mobile banking. The purpose of this is to enable data holders to leverage those existing online credentials, for example when it comes to authentication in the CDR – making the experience of using the CDR a digital one. Due to the definition of ‘consumer’ under the Act, without the concept of ‘eligibility’ in the Rules data holders would be required to share CDR data for a broader range of their customer base, including those who have not activated online banking and those who are former customers. As noted at paragraph 3.1 of the Rules Framework, the ACCC recognises the utility of providing former (and wholly offline) customers with the right to access CDR data, however, these were not considered a priority class of consumers for the initial implementation of the CDR in light of issues such as consumer authentication. A consumer who seeks to open an account with a new provider will be able to share their CDR data from any data holder with whom they are eligible at the time. We note that consumers are also able to share data from closed accounts for a certain period of time (see here) – provided they are still eligible for that particular data holder (i.e. have at least one open account). The requirement for authorisation to expire when a consumer ceases to be eligible follows the rationale above, i.e. once a customer has closed all of their online accounts with a particular data holder, they no longer have an ongoing digital relationship with the data holder or any active credentials through which they could be authenticated. Therefore, any authorisation to continue disclosing expires at the same time. We note your view that an inability to share from certain data holders has the potential to impact use cases such as loan origination. We welcome feedback on this issue and, as noted in the Rules Framework, are keeping this issue under review with a view to the appropriate next steps. CDR Support Portal Article |
| 403 | An FAQ Answer for "User visibility of the profile scope" was recently posted on the CDR Support Portal, which we were a bit confused by. The answer implied that the "profile" scope should not be disclosed by the Data Holder unless the request also includes basic customer data cluster (common:customer.basic:read) or detail customer data cluster (common:customer.detail:read). Does this mean that if an ADR requests the profile scope by itself, the Data Holder should not grant it? The last part of the FAQ Answer also had this comment. Can you please clarify this? 'Note also that the ADR has a responsibility to request the essential claims they wish to receive via UserInfo, such as given_name, otherwise they must not be returned.' |
Thanks for the question, the article User visibility of the profile scope is accurate in it's description of the usage of profile scope. The current consequence is that the profile scope can only be accepted if it is in association with one of the CDR customer read scopes. This is so ADRs and DHs don't unintentionally introduce situations where consumers don't comprehend they are sharing personal information in the short term whilst this consultation is being conducted. The Data Standards Body will consult on this gap and look to remediate in Maintenance Iteration 6. CDR Support Portal Article |
| 449 | The CDR Rule 9.5(4) states that the copies of records to customers must be provided 'in a form (if any) approved by the Comission for the purpose of this rule'. Has the form been approved? If yes, where is it available? If not when should we expect to have it? I am aware of this answer https://cdr-support.zendesk.com/hc/en-us/articles/900002708306?input_string=customer+copies+of+records, however it is not clarifying the form in which the records must be provided? |
CDR Support Portal Article |
| 465 | We are seeking clarification on data masking requirements for Biller CRNs matching the format of a Credit Card PAN, returned as part of the GetPayeeDetail API endpoint. Should a data holder not currently mask Biller CRNs matching this criteria on their existing online banking channels, is there a requirement to apply this masking in the Open Banking API response? The answer to a similar query raised via GitHub indicates masking is not required in this scenario: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/259 |
If the CRN is a Credit Card PAN then it should be masked using the MaskedPANString format. CDR Support Portal Article |
| Ticket # | Question | Answer |
|---|---|---|
| 107 | Answer in progress | |
| 139 | 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 | |
| 283 | Answer in progress | |
| 290 | Answer in progress | |
| 291 | Answer in progress | |
| 292 | Answer in progress | |
| 293 | Answer in progress | |
| 299 | Answer in progress | |
| 301 | Answer in progress | |
| 303 | Answer in progress | |
| 308 | Answer in progress | |
| 310 | Answer in progress | |
| 311 | Answer in progress | |
| 312 | Answer in progress | |
| 318 | Answer in progress | |
| 319 | Answer in progress | |
| 321 | Answer in progress | |
| 323 | Answer in progress | |
| 324 | Answer in progress | |
| 329 | Answer in progress | |
| 331 | Answer in progress | |
| 333 | Answer in progress | |
| 334 | Answer in progress | |
| 335 | Answer in progress | |
| 336 | Answer in progress | |
| 337 | Answer in progress | |
| 338 | Answer in progress | |
| 339 | Answer in progress | |
| 340 | Answer in progress | |
| 341 | Answer in progress | |
| 346 | Answer in progress | |
| 347 | Answer in progress | |
| 350 | Answer in progress | |
| 351 | Answer in progress |
| # | Question | Answer/ Action |
|---|---|---|