ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 20th of July 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
Updates
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.25.0	The latest version 1.25.0 was Published on 8 July 2023, it incorporates Decision Proposal 303 Maintenance Iteration 15 and Decision Proposal 288 Non Functional Requirements Revision. Note that a correction to the standards was published on 17 July however the version was not incremented. A field name was mislabeled.
Maintenance	Maintenance Iteration 16	Kicked off on 12 July 2023, participants are invited to comment on the candidates to be consulted on. The minutes will be published shortly if they haven't been published already Email [email protected] to request an invitation
TSY Newsletter	To subscribe to TSY Newsletter	Link here
DSB Newsletter	To subscribe to DSB Newsletter	Link here
TSY Newsletter	27th of June 2023	View in browser here
DSB Newsletter	14th of July 2023	View in browser here
Consultation	Decision Proposal 229 - CDR Participant Representation	Placeholder: 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	No Close Date Link to consultation
Consultation	Decision Proposal 306 - Updates to Banking Product and Account Detail	Feedback closes: 28th of July 2023 Link to consultation
Consultation	Noting Paper 307 - LCCD Consultation Approach	No Close Date Link to consultation Video
Consultation	Noting Paper 308 - Categories of Standards	No Close Date Link to consultation
Consultation	Decision Proposal 314 - Last Consumer Change Date (Phase 1)	8 August 2023 Link to consultation
Consultation	Non-Bank Lending Place holders	Heads up, more details to come!
Consultation	Joint CX and Information Security Decision Proposal for authentication uplift	This Decision Proposal is being drafted. There is no ETA but the work follows on from last week's presentation on Noting Paper 280 and the team continues to work toward publication in the coming weeks.
Guidance	The ACCC has revised its guidance on the requirement for a data holder to notify an account holder if a secondary user amends or withdraws an authorisation, or an authorisation given by the secondary user expires.	The Rule 4.28 Notification requirements guidance has been updated to clarify when a data holder is required to send these notifications.
Guidance	The ACCC has made minor amendments to its Compliance Guide for Data Holders in the Banking sector and Clarification of specific Data Quality obligations.	The changes clarify that a data holder must share relevant data where it is held ‘in a digital form’, even if the data is not available to the consumer digitally. ‘Digital form’ has its ordinary meaning.
Obligation Date: Authorisation Code Flow (ACF)	10th of July 2023 obligation date has passed FAPI 1.0 adoption is introduced across four phases. Phase 4: Retire Hybrid Flow: Data Holders MAY retire Hybrid Flow	The ACCC is reaching out to participants to gather information regarding the transition from Hybrid to ACF. If any data recipients have feedback they wish to provide regarding their overall experience of ACF, please get in contact with the ACCC at [email protected]. We also encourage recipients to continue raising individual issues with the relevant data holders for resolution.

CDR Stream Updates

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

No updates from the ACCC on RAAP or CTS or the DSB on Information Security & Banking or Engineering.

Organisation	Stream	Member
DSB	Consumer Experience	Bikram
DSB	Technical Standards - Energy	Hemang
DSB	Technical Standards - Maintenance Iteration 16	Nils & Hemang
DSB	Technical Standards - Register	James

Presentation

No presentations this week.

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
1997	If we have a secondary user who has no accounts of their own: SU-Acc1: A regular account they can share as a secondary user. It has no internet banking access. SU-Acc2: A joint account they can share as a secondary user. It does have internet banking access. The secondary user is eligible due to SU-Acc2. If we add an underage owner to SU-Acc2, our understanding is that they can no longer share that account, but are still 'eligible'(i.e. they can transact). They would not normally be able to have a secondary user instruction for an invalid account, but it's allowed if they were made a secondary user before the account became invalid for sharing. i.e. they can still share SU-Acc1, due to their 'internet banking' access criteria coming from an account they cannot share. Second issue. If they do not have SU-Acc1.. then we have a user who is eligible to share no accounts. This is.. technically valid as they can still share contact details, but incredibly weird to us and feels like we may have missed something?	We have provided general comments below that we hope will assist. Note the ACCC cannot provide compliance advice tailored to individual scenarios and we encourage you to seek independent advice if you require specific information about your compliance obligations. Issue 1 We have assumed the data holder is the same for both accounts and the “secondary user” you have referred to is an individual who is at least 18 years old. If an underage account holder is added to the joint account (SU-Acc2), joint account data can no longer be shared from that account because the definition of “joint account” in rule 1.7(1) requires each individual joint account holder to be “eligible”. This in turn requires each individual to be at least 18 years old (see rule 1.10B(1)(a)). The user would also no longer be a “secondary user” as defined under rule 1.7(1) for that joint account as all account holders must be 18 years or older (see subparagraph (c)(i) of the definition of secondary user). The former secondary user would also no longer be “eligible” in relation the data holder as they would not have at least one account that meets all the eligibility criteria in rule 1.10B. Issue 2 As above, the user would no longer be “eligible” in relation to the data holder.
2011	We would like some guidance around the provision of optional dat[a]. The BankingProductFee object for Get Account Detail is an optional object. When it comes to credit card and personal loan fees, these information are stored a system config level. They are not stored a customer level. Customers will only see a fee on their transaction history, if an event is triggered. For example, the fee config table may have an overseas transaction fee for Product A. The customer will not see this fee on their transaction history unless they actually did an overseas transaction. Also credit card are managed by a 3rd party vendor. Since we don't have this information today, are our vendors expected to build something for us to obtain these information for the purpose of Open Banking only?	In response to your question about optional data for account detail. A fee on an account should be presented in Account Detail if you intend to charge this fee. If you intend to charge the fee (whether via an outsource partner or directly) then it is obviously held information, otherwise the charge could not be applied. It is also clearly a material component of the designated data and useful to the consumer.
2020	1. For the upcoming Get Metrics v4, Decision 288 states that “v4 will contain additions that are considered less impactful for implementors and will be targeted for obligation date for Tranche 3 Energy Data Holders - 1/11/2023” 1. Is this only for the Energy sector? 2. For Get Metrics v4, the requirements for the change to ErrorMetrics, AvailabilityMetrics, AverageTPSMetrics and PeakTPSMetrics doesn’t mention anything about aggregating the numbers however the sample payload has it. Do we follow the sample or the requirements? 3. For Get Metrics v5, the requirements for the change to PerformanceMetrics doesn’t mention anything about aggregating the numbers however the sample payload has it. Do we follow the sample or the requirements? 4. For Get Metrics v5, the requirements for the change to add new abandonmentByStage object to Authorisation doesn’t mention anything about splitting the figures by currenDay and previousDays. Do we follow the sample or the requirements?	Q1: No. It applies to all data holders Q2: The standards are now published and must be adhered to. The requirement for this was articulated in the final decision document approved by the Chair as a result of relatively late feedback from the ACCC that need this data to allow for continuity of the CDR dashboard over time. Q3: Follow the standards in v1.25.0 Q4: All of the metrics cover current and historic data so this breakdown was implied (hence inclusion in the samples). This has been made clear in v1.25.0
2022	We understand that we are required to make up to 7 years of transactions data available per the CDR legislation. However, we have concerns about our ability to retrieve that data quickly enough to meet the non-functional requirements around Performance, which is 1500ms for a transactions API request. Are there any standards around limiting the size of a transactions response, so that it can meet performance requirements?	Like some other endpoints that can return a large number of records, the Get Transactions For Account endpoint supports pagination which provides defined query parameters with some constraints: For this endpoint, these include: As stated under Additional Pagination Rules in the Pagination section, endpoints with pagination support a maximum page-size (per request) of 1000 records. the page-size parameter. If no page-size is specified, a default of 25 is assumed as specified by the endpoint parameter. Any remaining transactions to fullfil a request are provided through pagination links. the oldest-time parameter. This can constrain the time period for the request. As the endpoint description states, "If absent defaults to newest-time minus 90 days.". If a longer period is requested, pagination links are used to provide access to more records. The combination of these parameters is expected to reduce the response time for each request/response that may be required to incrementally return a larger dataset.
2028	There seems to be conflicting information about the definition of 'Availability. Link # 1 --> https://cdr-support.zendesk.com/hc/en-us/articles/900003123023-Definition-of-status-and-how-health-check-status-can-be-determined- Link # 1 above states "if you cannot successfully fulfil authorisation requests, consent withdrawal or respond to one or more of the API endpoints, then the status should represent the current availability.". Can I assume an example of the above statement is we return 5xx or 4xx error code to the ADR when they try to call our Get Accounts API? Link # 2 --> https://cdr-support.zendesk.com/hc/en-us/articles/6461435303823-CDR-metrics-and-reporting-by-Data-Holders#Availability Link # 2 states "For clarity, a period of unavailability should be reported even where a data holder did not record any requests in that period. This means that an absence of requests cannot be used to determine that a period of unavailability did not occur." Can you please clarify which one is correct? Can you also please clarify how we can measure outage?	I understand the statements in both articles to be correct. The Availability Requirements section of the Standards provides a definition of Availability as - The definition of a period of unavailability is any period of time when any of the API end points defined in the standard is unable to reliably provide a successful response to an appropriately constructed request. As link 1 states, if components of the service are not functioning reliably, this is expected to be reflected in the Get Status endpoint as a period of either PARTIAL_FAILURE (meaning 'one or more end points are unexpectedly unavailable'), UNAVAILABLE ('the full implementation is unexpectedly unavailable'), or, if during a period of planned outage, as SCHEDULED_OUTAGE ('an advertised outage is in effect'). The status of components may be determined by more than the occurrence of error codes, because, as link 2 states, you may be aware due to other factors that your services are not responding reliably, but you may not be receiving requests at that particular time in order for particular error codes to be generated. This means that a period of time where your services are experiencing a PARTIAL_FAILURE or UNAVAILABLE status but not receiving requests, would still regarded as 'a period of unavailability'. Note that SCHEDULED_OUTAGE time, where notice of the outage has been provided in advance through the Get Outages API, is not included in the Availability calculation. The two articles you referenced, plus the related links below provide more detail and comments about implementation guidance - Measuring availability metrics Clarifications on Metrics Requirements Monitoring availability metrics This Q&A prosvide some related information on how Data Holders may measure their availablity- https://cdr-support.zendesk.com/hc/en-us/articles/900004207563-Measuring-availability-metrics