ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 28th of March 2024
When: Weekly every Thursday at 3pm-4:30pm AEDT
Location: Microsoft Teams
Meeting Details: Join on your computer, mobile app or room device Click here to join the meeting
Meeting ID: 446 019 435 001
Passcode: BU6uFg
Download Teams | Join on the web
Join with a video conferencing device
teams@vc.treasury.gov.au
Video Conference ID: 133 133 341 4
Alternate VTC instructions
Or call in (audio only)
+61 2 9161 1229,,715805177# Australia, Sydney
Phone Conference ID: 715 805 177#
Find a local number | Reset PIN
Learn More | Meeting options
- 5 min will be al lowed for participants to join the call.
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.
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.
By participating in the Consumer Data Right Implementation Call you agree to the Community Guidelines. These guidelines intend to provide a safe and constructive space for members to discuss implementation topics with other participants and members of the ACCC and Data Standards Body.
⭐ indicates change from last week.
| Type | Topic | Update |
|---|---|---|
| Standards | Version 1.29.1 | Published: 28th of February 2024 Change log |
| Maintenance | Maintenance Iteration 18 commenced on the 7th February 2024 Working Group met on the 20th of March 2024 |
MI 18Agendas Please reach out to contact@consumerdatastandards.gov.au for an invitation |
| DSB Newsletter | To subscribe to DSB Newsletter | Link here |
| DSB Newsletter ⭐ | 22nd of March 2024 | View in browser here |
| Consultation | Decision Proposal 229 - CDR Participant Representation | Placeholder: no close date Link to consultation |
| Consultation | Noting Paper 279 - Accessibility Improvement Plan | No Close Date Link to consultation |
| Consultation | Noting Paper 323 - NFR Workshops | Link to consultation |
| Consultation | Noting Paper 330 - UNSW Reports | Link to consultation |
| Consultation | Decision Proposal 340 - Maintenance Iteration 18 | Link to consultation |
| Consultation | Noting Paper 342 - Information Security Working Group | Link to consultation |
| Consultation | Noting Paper 345 - Data Standards Body Capability, Consultation Processes and Operating Mode | Link to consultation |
| Engineering | JSON Schema Tools | The Github Repository has been updated to align with the artefact to the latest CDS version (1.29.1). |
| Engineering | Type Definition Library The Github Repository has been updated to align with the artefact to the latest CDS version (1.29.1). |
The relevant NPM package ( 7.2.0 ) has been published in the NPM Registry as well. |
| Video | Future Dated Obligations for Q3 of 2024 - narrated by Peter Nowotnik (28/03/2024) | Link to DSB YouTube Channel |
Provides a weekly update on the activities of each CDR stream and their work.
| Organisation | Stream | Member |
|---|---|---|
| ACCC | Register and Accreditation Application Platform, Conformance Test Suite & Participant Tooling | Christian |
| DSB | Consumer Experience | Michael |
| DSB | Energy | Hemang |
| DSB | Information Security | Mark |
None this week.
Questions will be received by the community via Microsoft Teams chat before the questions are opened to the floor. Participants can submit questions outside of the CDR Implementation Call to the CDR Support Portal.
In regards to topics for questions, we ask the participants on the call to consider the Community Guidelines when posing questions to the subject matter experts.
| Ticket # | Question | Answer |
|---|---|---|
| 2243 | Is there a requirement for ADI Data Holders to store a record of PAR request_uris, if so for how long? | The Data Standards don't explicitly require the logging on request_uris generated from PAR requests, however as part of operational monitoring, the logging of request_uri against authorisation requests may prove helpful for Data Holders when triaging issues, or analysing system performance and general trends. |
| 2285 | Is there a plan to introduce multiple account owners support in Customer API's in future? | The simple answer, is no there is not. One important aspect of the CDR is that only the consenting consumer's data is shared. Personal information related to other account owners is not intended to be shared via the Customer APIs. Instead, additional account owners can obtain their personal information by establishing a separate data sharing arrangement under their own consent. |
| 2305 | Questions: 1) Consider a situation where a bank has planned an outage, say for a couple of hours, to bring down partial or complete services offered on their primary digital channels. As a result of this plan, there is no impact identified to their Open Banking platform for sharing reliable and successful responses to properly constructed Common, Banking and Admin API requests. As per the NFR referenced above, is this bank still expected to post complete outage ("isPartial" flag as false and expected lead time) from Open Banking perspective which is commensurate in length as that of primary digital channels? 2) Consider a situation where a bank has planned an outage, say for a couple of hours, to bring down one or more of their core business systems (Core Banking / Business Process Management / Identify & Access Management / Master Data Management) partially or completely. As a result of this plan, there is some impact identified to their Open Banking platform for sharing reliable and successful responses to properly constructed Common, Banking and Admin API requests. As per the NFR referenced above, is this bank expected to post partial or complete outage ("isPartial" flag as false/true, expected lead time and appropriate "explanation" string value) from Open Banking perspective which is commensurate in length as that of the corresponding core business system(s) if: a) Primary digital channels would still be pretty much expected to be up and running for offering some of the basic services b) Primary digital channels would not be expected to be up and running |
It seems you may be referring to these lines: The availability requirement does not include planned outages. Planned outages should be: Commensurate in length and frequency to other primary digital channels offered by the data holder, The intent of 'commensurate' in these statements is to ensure that CDR services are not considered less important than the service levels of primary digital channels. For example, if primary digital channels only undergo planned outages of 4 hours every two months, then outages impacting CDR services should not occur for 4 hours every week. i.e., there should be a commensurate level of service provided to CDR. It is not expected that planned outages for primary digital services (unrelated to CDR) are reflected in the CDR Get Outages endpoint. |
| 2306 | AmountString presentation for Energy tariffs AmountString is defined as "A string representing an amount of currency." which seems to suggest the presentation of these values should be done in the context of Australian Dollars ("AUD"). When reviewing the output presented by AER however we are observing that all plans seems to be getting presented as a tarrif rate in CENTS (which isn't a currency, there is no such thing as Australian Cents (AUC)). Interpreting this string as dollars aligns with the banking expectation. On this basis is it reasonable to draw the conclusion that all AmountString values should be presented as DOLLARS not CENTS? |
The AmountString is in $$.cc format. So if a rate is 23 cents, it should be shared as 0.23. |
Attendees are invited to raise topics related to the Consumer Data Right that would benefit from the DSB and ACCCs' consideration.
View a number of informative and useful links in the Consumer Data Standards Guide on Information Links.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
|
 |
 |
 |