ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 11th of May 2023

CDR Implementation Call Banner

Agenda & Meeting Notes

When: Weekly every Thursday at 3pm-4:30pm AEST
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
[email protected]
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

Agenda

Introductions
Actions
CDR Stream updates
Presentation
Q&A
Any other business

Introductions

5 min will be allowed for participants to join the call.

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.

House Keeping

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 [email protected] should they have any further questions or wish to have any material redacted from the record.

Community Guidelines

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.

Updates

Type	Topic	Update
Standards	Version 1.24.0 published 7th of May 2023	Version 1.24.0 Change Log
Maintenance	Iteration 15 next meet is 17th of May 2023	If you would like an invitation please reach out to [email protected]
Maintenance	Iteration Candidates nominated!	List of candidates on the MI5 Project Board
Maintenance	Agenda and Meeting Minutes for 3rd of May 2023	Agenda for 3rd of May 2023
TSY Newsletter	To subscribe to TSY Newsletter	Link here
DSB Newsletter	To subscribe to DSB Newsletter	Link here
TSY Newsletter	24th of April 2023	View in browser here
DSB Newsletter	5th of May 2023	View in browser here
Consultation	Decision Proposal 229 - CDR Participant Representation	Placeholder: no close date Link to consultation
Consultation	Decision Proposal 267- CX Standards Telco Data Language	Feedback extended with an end date to be determined pending the making of the telco rules. Link to consultation
Consultation	Decision Proposal 275 - Holistic Feedback on Telco Standards	No Close Date Link to consultation
Consultation	Noting Paper 276 - Proposed v5 Rules & Standards Impacts	No Close Date Link to consultation
Consultation	Noting Paper 279 - Accessibility Improvement Plan	No Close Date Link to consultation
Consultation	Noting Paper 280: The CX of Authentication Uplift	UPDATE: See NP296 for continuation of consultation
Consultation	Decision Proposal 288 - Non-Functional Requirements Revision	Feedback closes 12th of May 2023 Link to consultation
Consultation	Noting Paper 289 - Register Standards Revision	Feedback closes 12th of May 2023 Link to consultation Video 56 of NP289
Consultation	Decision Proposal 302 - Telco Draft Feedback Cycle 2	No Close Date Link to consultation

CDR Stream Updates

Provides a weekly update on the activities of each of the CDR streams and their stream of work

Organisation	Stream	Member
ACCC	Register	Eva
ACCC	CTS	Seamus
DSB	CX Standards	Amy
DSB	Technical Standards - Energy	Hemang
DSB	Technical Standards - Banking & Information Security	Mark
DSB	Technical Standards - Register	James
DSB	Technical Standards - Maintenance Iteration 15	Brian
DSB	Technical Standards - Engineering	Sumaya

Presentation

Data Standards Body
Hemang Rathod
Version 1.24.0 of the Consumer Data Standards

Q&A

Questions on Notice

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.

Answer provided

Ticket #	Question	Answer
1883	In addition to the above questions, we have one additional item for clarification in regard to what status should be assigned to a Consent/Sharing Arrangement on the Data Holder Dashboard when the status of the authorising consumer becomes ineligible (either the ineligible authorising consumer is the Account owner or a Secondary User as this is not specifically related to Secondary Users but applicable to an arrangement when any authorising consumer becomes ineligible). We have seen references to the status being expired and then other instances referring to revoked. Is there a specific status that should be assigned to these arrangements?	This knowledge article on Authorisation States for Joint Account and Secondary User Sharing may help answer your question on ineligible Secondary Users. In regards to the terminology of authorisation status being expired or revoked, this is at the discretion of the data holder. In relation to the second query, a secondary user instruction previously given by an account holder would not be affected if the account holder is no longer eligible under rule 1.10B. The secondary user instruction would remain current unless withdrawn by the account holder (see rules 1.13(1)(e) and 1.15(5)).
1924	As asked during the MI14 call, for existing clients, from 14 April, if they don't update their DCR to specify if they request SIGNED or SIGNED+ENCRYPTED reponse, what would be the default setting? Also, is it correct to interpret that from 14 April, existing clients are enforced to use Authentication code flow? If existing clients continue to use hybrid flow, they will get error.	I am assuming this relates to ID token signing & encryption but please correct me if I am wrong. To some extent this depends on the authentication flow. If Hybrid Flow is registered, then ADRs must provide the claims to sign and encrypt ID tokens. This is a FAPI 1.0 requirement and the holder would be expected to reject the registration request. If the DCR request only includes Authorization Code Flow, then encryption of ID tokens is not required. As per FAPI 1.0 ID tokens must still be signed. As for default values, in some instances this may be possible however not always. If the DH advertises only one signing algorithm option the DH may apply that single value as a default but it is equally acceptable to reject the request. If the DH advertises only one encryption algorithm option and Hybrid Flow is registered then the DH may apply that single value as a default but it is equally acceptable to reject the request. If the ADR sends a request that omits the encryption algorithm claims, they are requesting that ID tokens not be encrypted. This is allowable for Authorization Code Flow (which must be used in combination with JARM) but not for Hybrid Flow.
1961	GET /energy/accounts/{accountId}/invoices - invoiceAmount Can you please advise whether invoiceAmount includes GST?	You are correct. The intent of the invoiceAmount is to represent the actual amount presented to the customer on the invoice which includes GST. The gstAmount field was added to capture how much of the invoice amount is GST.
1966	Energy Invoices - Is accountCharges a summation of all charges or separate account-level charges? Just looking to understand if the 'accountCharges' object is intended to hold charges/discounts/gst for ancilliary items that don't fit into energy usage, or if instead it is a roll-up of all charges/discounts/gst for the invoice	The intent for accountCharges is to capture any charges applied an account level (for e.g. account setup charges). It's not a roll-up of all other charges for the invoice.
1758	Follow on Question, on a Joint Account when it comes to DOMS side, is this functionality that's controlled by DOMS as in non disclosure?	The knowledge article on Authorisation States for Joint Accounts: https://cdr-support.zendesk.com/hc/en-us/articles/6589715324047 may assist you.
1808	Treatment of CDR Consumers when digital channel access is temporarily unavailable We would like to clarify expected treatment for the following scenario. Say an eligible account holder (18 years+, open account accessible online and/or mobile) has – or wishes to authorise - data sharing arrangements (herein ‘arrangements’) with one or more ADRs. Say their online or mobile banking (digital channel) access requires an active, unlocked (hard or soft) token. The Account Holder's Consumer Dashboard, DOMS, and Secondary User instruction services are located in the digital channel. Say the consumer’s token becomes 'temporarily locked’, preventing them from logging in. This can happen for various reasons, a typical one being multiple failed login attempts leading to automated token locking (requiring - say - the Call Centre to unlock it). Under a 'temporarily locked' (digital channel login blocked) scenario what is the expected treatment for the following: 1. Account Holder (AH) wishes to create or amend a data sharing arrangement - noting that only an OTP is required currently? 2. ADR requests data via banking APIs against an active authorised arrangement - should data holder reject or ignore until online access is restored? 3. The AH has appointed a Secondary User (SU) - whose token is active - but the AH's token becomes temporarily locked, preventing the AH from withdrawing a Secondary User Instruction and from withdrawing approval on accounts in the SU’s arrangement, or – in future perhaps – from blocking the ADR? 4. A Relevant Joint AH's token becomes temporarily locked, preventing them from withdrawing approval on a joint account in the Requester’s active data sharing arrangement? There are almost certainly other variations. Strictly speaking, the AH or SU is 'not able to access the account online' while their token is temporarily locked. But - being temporary - we do not consider this situation to be a strict eligibility failure requiring immediate expiry of the user's active arrangements. This view is supported by common sense, the aim of avoiding friction, and this guidance article: https://cdr-support.zendesk.com/hc/en-us/articles/360004504675-Blocked-or-suspended-accounts-consumer-eligibility-and-refusals-to-disclose-data. These appear to be the related Rules: · Rule 2.1 Additional criteria for eligibility—banking sector - (1) For subrule 1.10B(1), the additional criterion for CDR consumer to be eligible, in relation to a particular data holder in the banking sector at a particular time, is that the person is able to access the account online. · Rule 3.5 Refusal to disclose required consumer data in response to consumer data request - (1) …the data holder may refuse to disclose required consumer data in response to the request: - … (aa) in relation to an account that is blocked or suspended; · Rule 4.7 Refusal to disclose required consumer data in response to consumer data request - (1) … a data holder may refuse to ask for an authorisation in relation to the relevant CDR data, to invite a CDR consumer to amend the authorisation, or to disclose required consumer data in response to the request: - … (c) in relation to an account that is blocked or suspended. Pulling this all together, please advise, when a token (login to a digital channel) is in a temporary locked state: 1. Should the AH / SU be able to create and amend data sharing arrangements? 2. Should ADR data requests be ignored (paused), refused, or allowed? We note that token locks are typically very short lived (client will quickly call in most case to get it unlocked), and so we believe that we should err on the side of allowing Open Banking data sharing to continue. But we would like this view formally confirmed.	Our sincere apologies for the delay in getting back to you – your query involved some complexities that we needed to consult with various ACCC teams on in order to give you a clear answer. The ability for a data holder to refuse to disclose required consumer data in response to a consumer data request is dealt with under clause 4.7 of the CDR Rules. The circumstances under which the Rules allow for a refusal to disclose are: if the data holder considers this to be necessary to prevent physical, psychological or financial harm or abuse; or in relation to an account that is blocked or suspended; or in circumstances (if any) set out in the data standards. An account being ‘temporarily locked’ (for example, due to a number of failed login attempts or a forgotten password) does not fall under the meaning of a ‘blocked or suspended account’ because the account itself is still active and is not blocked or suspended– it is only the access token that has been affected. Therefore, a ‘temporarily locked’ token does not fall under any of the circumstances listed in clause 4.7, and a data holder would not be able to refuse to disclose required consumer data in the event of a consumer being unable to log into their account. In addition, a CDR consumer who is temporarily unable to log into their account online remains to be an eligible CDR consumer because their account is still technically able to be accessed online. Therefore, data requests received by an ADR while a CDR consumer’s online account is temporarily locked should not be ignored or refused. Data should continue to be shared in relation to a valid consent even if the consumer is temporarily unable to log into their account online. We hope this information assists you. If you require any further information, please do not hesitate to contact us again.