ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes (18th of February 2021)
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
- 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 contact@consumerdatastandards.gov.au 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 |
|---|---|---|
 |
1st Birthday of the CDR Implementation Call | Thanks to the Consumer Data Right Community, our panel of experts and special guests. Image: Birthday by Humantech from the Noun Project |
| 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 contact@consumerdatastandards.gov.au |
| Maintenance | 6th Maintenance Iteration Voting | On the 6th Maintenance Iteration vote on the scopehere |
| DSB Newsletter | To subscribe to DSB Newsletter | Link here |
| ACCC Newsletter | To subscribe to ACCC Newsletter | Link here |
| ACCC Newsletter | 11th of February 2021 Edition | View in browser here |
| DSB Newsletter | 12th of February 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 153 - Technical Standards Changes to Accommodate V2 Rules This decision proposal contains a review of the amendments to the CDR rules published on the 23rd of December 2020 to identify changes to the technical CDR standards. This includes the API standards, high level standards and the information security profile. This decision proposal does not cover consumer experience standards or guidelines which will be addressed separately. This thread will remain open until February 19th 2021. |
Link to consultation |
| Consultations | Decision Proposal 154 - Enhanced Error Handling: Error Code Payload Structure and Transition Arrangements This decision proposal is seeking to address the list of transition arrangements and payload changes to support standardised error codes across the CDR ecosystem. Feedback is planned to be closed on 19th February 2021. |
Link to consultation |
| Consultations | Decision Proposal 155 - Enhanced Error Handling: Error Code Catalogue This decision proposal is seeking to address the list of standardised error codes and HTTP status codes for error handling across the CDR ecosystem. Feedback is planned to be closed on 19th February 2021. |
Link to consultation |
| Consultations | Decision Proposal 156 - Enhanced Error Handling: Custom Error Code Discovery Service This decision proposal is seeking to address how participants — particularly ADRs — may discover custom error codes not covered by the standardised error code catalogue are used by servers where commercial / voluntary extensions to the core CDR APIs are offered. Feedback is planned to be closed on 19th February 2021. |
Link to consultation |
| Consultations | Noting Paper 157 - CX Standards Arising from v2 Rules. This noting paper outlines the anticipated Consumer Experience Data Standards changes arising from the v2 rules being made on 23rd December 2020. Feedback is now open on this noting paper. Feedback is planned to be closed on Friday 12th February, 2021. |
Link to consultation |
| Consultations | Decision Proposal 158 - Participant capability discovery This decision proposal pertains to the consultation for a functional discovery mechanism pertaining to the DSB's Future Plan roadmap item published here: ConsumerDataStandardsAustralia/future-plan#5. Feedback is now open for this proposal. Feedback is planned to be closed on 5th March 2021. |
Link to consultation |
| Consultations | Decision Proposal 159 - v1.7.0 Placeholder for the 1.7.0 Release |
Link to consultation |
| Consultations | Decision Proposal 160 - CX Standards This is a placeholder issue for consultation on CX Standards for non-individual consumers, business partnerships, and secondary users. This proposal is not yet ready for publication. This placeholder issue has been opened to gather initial community commentary on the scope and content of the proposal. While the intention is for this consultation to focus on the relevant items raised in Noting Paper 157*, the DSB encourages feedback on any additional CX Standards and CX Guidelines that the community views as required for the purposes of non-individual consumers, business partnerships, and secondary users. *Items 12-14. Item 16 on secondary user withdrawal standards will be dealt with separately. - Non-individual Consumers - Business Partnerships - Secondary users |
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) | Ivan Hosgood & Elizabeth Arnold |
| ACCC | Onboarding | Emma Joy & Chantelle Demian |
| DSB | CX Standards | Michael Palmyre |
| DSB | Technical Standards - Banking | Mark Verstege |
| DSB | Technical Standards - Energy & Engineering | James Bligh |
Presentation on the Enhanced Error Handling Decision Proposals:
- Decision Proposal 154 - Enhanced Error Handling: Error Code Payload Structure and Transition Arrangements
- Decision Proposal 155 - Enhanced Error Handling: Error Code Catalogue
- Decision Proposal 156 - Enhanced Error Handling: Custom Error Code Discovery Service
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 |
|---|---|---|
| 441 | In Scheduled Payments APIs, a DH should not be providing payeeID but full payee details when Bank Payee Scope is not consented to. Does the same principle apply for Basic Account Scope, i.e. if the ADR only has Scheduled Payments Scope consented to, should a DH provide accountID for scheduled payments between internal accounts, where accountID would apply? | CDR Support Portal Article |
| 484 - Part 2 | In relation to the following CDR support request that we raised recently, we would like to clarify the requirements for open accounts for grandfathered products. For example, an account was opened 10 years ago under a product that is no longer offered on the market. As such, the product data for that type of account is present in our Core Banking System, however, it is not published in the Product Reference Data APIs. In that scenario, is it still mandatory to disclose those optional/conditional fields, since the related product data is no longer available in the Product Reference Data tables? Please advise what is the Mandated Minimum information that is required to be compliant. Are the rules different for a product that is grandfathered (grandfathered products ) – 20 years, 10 years, 5 years old? |
We can recommend the following Knowledge Articles to cover your question: Minimum Product Grandfather Period 'Grandfathered' Product Sharing Grandfathered Product Reference Data (PRD) for Public vs Customer endpoints |
| 526 | It has been mentioned to use "SoftwareProductID" for "iss" field here [1]. Just want to clarify whether the "software_id" in the SSA is the same as "SoftwareProductID". [1] - https://cdr-register.github.io/register/#registration-request-using-jwt |
Yes this is correct. Please refer to the identifiers table in the CDR Register Design: https://cdr-register.github.io/register/#ecosystem-entities This table brings the ambiguity in naming conventions together and helps clarify these types of questions. CDR Support Portal Article |
| 544 | Acknowledging the question asked on Zen desk in regards to Get Outages and Get Status, and the answer that DSB expect a single unauthenticated baseURI, could you please clarify what is the expectation for a consumer to discover the base uri for PRD? Is it DH website? Is it acceptable for base uri for PRD endpoints to be different to unauthenticated base uri for Get Status and Get Outages. Is the following configuration example acceptable: PRD base uri https://ob-api.pnbank.com.au/cds-au/v1/banking/products CDR Public base uri https://cdr-api.pnbank.com.au/cds-au/v1/discovery Resource Base uri and others https://cdr-api.pnbank.com.au/cds-au/v1/banking/... With a single unauthenticated end point that combines Get Status and Get outage details for both unauthenticated and authenticated API's consideration should be given to the consumers of Product Reference Data. These consumers have no access to to the authenticated banking API's yet are given details about their status/outage. These details are irrelevant to consumers of Product Reference Data an therefore combining the data is unnecessary. Is there a basic issue being solved with the single publicbaseuri? |
CDR Support Portal Article |
| 546 | I wanted to check if there is any wriggle room in what the non-majors go-live with on 1st July 2021. Based on the - Phasing for CDR in Banking I know of the obligations for the non-majors e.g. Phase II products (e.g Joint Accounts) can be made available later till Nov 2021. Can the non-majors deliver some of the CDS APIs (full or partial) at a later date? Will the non-majors also be given similar flexibility or exemptions? Are these exemptions (such as the one listed above for CBA) are granted on a case by case basis or is that a blanket exemption for all majors? Appreciate some clarifications in this space. |
The latest version of the CDR Rules is on the Federal Register of Legislation, here: https://www.legislation.gov.au/Details/F2021C00076 The commencement table is at Schedule 3, clause 6.6. Information about the rollout of the CDR, including a phasing infographic is available here: https://www.cdr.gov.au/rollout The CDR Guidance for applicants seeking exemption under section 56GD is available here: https://www.cdr.gov.au/sites/default/files/2020-06/CDR%20-%20CE%20-%20Section%2056GD%20exemption%20guideline%20-%20final.pdf The ACCC/OAIC Compliance and Enforcement Policy for the CDR is available here: https://www.cdr.gov.au/sites/default/files/2020-06/CDR%20-%20CE%20-%20Joint%20ACCC%20and%20OAIC%20compliance%20and%20enforcement%20policy%20-%208%20May%202020.pdf ) |
| 552 | Looking for confirmation on when Product Fees need to be disclosed in full, as currently some fees are referred to website or PDS or is this still acceptable to disclose in this way? Thank you | CDR Support Portal Article |
| 554 | Re the current CX guidelines https://consumerdatastandards.gov.au/wp-content/uploads/2020/08/CX-Guidelines_v1.4.0.pdf#page=24 and Accessibility. Five WCAG guidelines with 35 associated criterions are considered at a minimum as a MUST for compliance throughout the Consent Model. 13 of those criterions possess a AAA conformance level. My question is are those AAA rated criterions still considered as a MUST requirement across the Consent Model, particulary in the context of the following WCAG note on conformance; "Note: It is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA Success Criteria for some content." - From https://www.w3.org/TR/WCAG21/#cc1 In short, are Data Recipients and Data Holders required to conform with all cited WCAG guidelines and criteria within the Consent Model, regardless of their conformance level? |
The accessibility standards state that participants must seek to comply with the specified WCAG items. The addition of 'seek to' was included to provide flexibility to ADRs and DHs in circumstances such as this one, where complying with an item is not appropriate or possible for certain aspects of the consent model. CDR Support Portal Article |
| 555 | When will the updated CX Standards and guidelines release with changes from v2 Rules? (Amending Consent) | For CX Standards arising from v2 rules, and expected timing, see Noting Paper 157. CX Guidelines will accompany these items. For other CX Guidelines, see the Kanban for how we’re scheduling the work: https://github.com/ConsumerDataStandardsAustralia/future-plan/projects/1. CX Guidelines for ADR-side amending consent flows are planned for Q1/Q2, as noted in the Kanban board. The Kanban does not provide an exhaustive list of all CX Guidelines being developed. Additional scenarios and variations will be catered to in CX artefacts releases. CDR Support Portal Article |
| 543 | Could you please clarify expectations for the following configuration of Debit/Credit cards. credit card configured as an overdraft account with card linked to it debit card configured as a savings account with card linked to it Shall we as part of consent flow and further API responses show cards as "CRED_AND_CHRG_CARDS" or "TRANS_AND_SAVINGS_ACCOUNTS" for Debit and "OVERDRAFTS" for Credit? |
For accounts that fall into grey areas between the categories defined we leave the selection of category entirely up to the discretion of the Data Holders. CDR Support Portal Article |
Updating the table below - if your question/ ticket has not received a response yet the team continues to work on a response. We do apologise for the delay on some tickets, the teams are doing their best to get to everyone's questions.
| Ticket # | Question | Answer |
|---|---|---|
| # | Question | Answer/ Action |
|---|---|---|
| Organisation | Description | Link |
|---|---|---|
| OAIC | Main landing page for the Office of the Australian Information Commissioner and the Consumer Data Right | Link |