ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 9th of February 2023

CDR Implementation Call Banner

Agenda & Meeting Notes

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
[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.22.0 published 23rd of December 2022	Version 1.22.0 Change Log Release video 1.22.0
Maintenance	Iteration 14 has commenced!	Check out the agenda here
TSY Newsletter	To subscribe to TSY Newsletter	Link here
DSB Newsletter	To subscribe to DSB Newsletter	Link here
TSY Newsletter	5th of December 2022	View in browser here
DSB Newsletter	3rd of February 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
Design Paper	Design Paper: Consumer Data Right Rules and Standards for the Non-Bank Lending Sector	Feedback closed 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	Feedback closes: 10th of February 2023 (extended) Link to consultation
Consultation	Decision Proposal 287 - Energy C&I Consumers	Feedback closes: 17th of February 2023 Link to consultation
Workshop	7th of March 2023 Action Initiation Workshop 01	Registration for Workshop

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	CDR Register	Emma Harvey
ACCC	CTS	Andrea Gibney
DSB	CX Standards	Michael Palmyre
DSB	Technical Standards - Banking & Infosec	Mark Verstege
DSB	Technical Standards - Energy	Hemang Rathod
DSB	Technical Standards - Telecommunications	Brian Kirkpatrick
DSB	Technical Standards - Register	James Bligh
DSB	Engineering	Sumaya Hasan

Presentation

No presentation planned for 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
1023	We are still interested in seeking some clarity on this topic. However, we have taken the approach that consumers' access to the dashboard will cease as soon as their login credentials to the ADRs' service become invalid. Whether that be 1) the consumer taking specific actions to stop using a service, 2) continued failure to pay for the service or 3) consumer login is purged due to inactivity (i.e. they have failed to login for a specific period, per the ADR's T&C's, Privacy Policies. Data Governance etc.)	Rule 1.14 of the CDR Rules provides that an accredited person must provide each eligible CDR consumer on whose behalf the accredited person makes a consumer data request with a consumer dashboard. As you note, the rules are silent in respect of the length of time that an ADR must continue to provide a dashboard for a consumer. There may be some instances where it is appropriate to no longer maintain a dashboard, such as where the CDR consumer is no longer using the services of the ADR and the information contained on the consumer dashboard is more than six years old. This period would align with the record-keeping requirements in rule 9.3 of the CDR Rules and is also consistent with guidance for data holder dashboards in our compliance guidance for data holders in banking which provides that the data holder dashboard must contain the details of each authorisation to disclose CDR data within the past six years. It is the responsibility of CDR participants to determine how they will comply with the CDR Rules and we encourage you to seek independent advice if you require further information about your compliance obligations in relation to maintaining consumer dashboards.
1738	the ‘pricingModel’ field within the EnergyPlanContract f GET ENERGY ACCOUNT DETAIL API have enums value options as : “SINGLE_RATE, SINGLE_RATE_CONT_LOAD, TIME_OF_USE, TIME_OF_USE_CONT_LOAD, FLEXIBLE, FLEXIBLE_CONT_LOAD & QUOTA” Scenario Summary: However, there are scenarios where customers/premises can have multiple meters with primary tariff/rate types active at the same time period e.g. One meter has Single rate tariff, and the other meter has Time of Use tariff. Note : this setup is commonly observed with SA (RESI/ BUSI) customers. If there are multiple meters/tariffs/rate types applicable at an installation, they may have their respective pricing model but as the pricing model is not an array structure within this segment of api it can hold only one of the enum value provided. Therefore, this field response can hold & pass only one value (from the enums list provided) of the applicable pricing models e.g. passing pricing model as ‘TIME_OF_USE’ if both single & TOU meters exists. Please advise if this approach is correct given the scenario.	The plans object which EnergyPlanContract belongs to is an array. So you could represent the above scenario using multiple plans entries, each with a different contract structure and pricingModel. Request: Do you know of examples of such plans on energymadeeasy site? It would be good to see how they represent it.
1814	We have a question about the "alternative" language which is defined here: https://consumerdatastandardsaustralia.github.io/standards/#data-language-standards-common In particular, we are trying to understand the following statement: ------ If a scenario requires it, Data Holders and Data Recipients MUST merge and amend Basic and Detailed data cluster and permission language to show that Detailed scopes include Basic data. Data Holders and Data Recipients MUST use the alternative language denoted with an '‡' for the relevant scope(s). See the Banking Language section for banking data and the Energy Language section for energy data. Example: A Data Recipient presents the Detailed data cluster in a data request to a consumer, but does not present the Basic data cluster. The Detailed scope includes Basic data, but this is not apparent to the consumer based on the data cluster language and permissions used for the Detailed scope. ----- As an example, let's take the customer scopes: - common:customer.basic:read - common:customer.detail:read If an ADR requests "common:customer.basic:read", our understanding is that we should use the language as set out in the "Name and occupation" data cluster. If an ADR requests "common:customer.detail:read", our understanding is that we should use the language as set out in the "Contact Details" data cluster. If an ADR requests both "common:customer.basic:read" & "common:customer.detail:read", then we should use the language as set out in the "Name, occupation, contact details" data cluster. Can you please confirm if our understanding is correct? The reason for our confusion is the particular sentence below: ---- Example: A Data Recipient presents the Detailed data cluster in a data request to a consumer, but does not present the Basic data cluster. The Detailed scope includes Basic data, but this is not apparent to the consumer based on the data cluster language and permissions used for the Detailed scope. ---- This sentence above seems to imply that if an ADR requests the "detailed" scope, they are in effect also requesting the "basic" scope, which is not our understanding as an ADR will need to request both scopes.	As noted in Authorisation Scopes: CDR Data, detailed scopes includes the information in the corresponding basic scopes. For example common:customer.detail:read contains the data available with the Basic Customer Data scope plus contact details. That is why if an ADR only requests the "detailed" customer scope, they are in effect also requesting information that exist in the "basic" customer scope. Hence, if common:customer.detail:read is requested, the data language outlined in ‘Name, occupation, contact details’ should be surfaced to the consumer (aka the alternative language denoted with an '‡'). The Data Language Standards for ‘Detailed scope requests’ state that: ‘if a scenario requires it, Data Holders and Data Recipients MUST merge and amend Basic and Detailed data cluster and permission language to show that Detailed scopes include Basic data.’ For most cases detailed scopes will need to be requested alongside basic scopes. In this scenario the merged language (aka the alternative language denoted with an '‡') should still be surfaced to the consumer. However, the data language shows both merged (language denoted with ‡) and un-merged language for detailed scopes to provide flexibility to CDR Participants. For more detail related to merged/un-merged language, please refer to this comment.
1820	There is a Zendesk article 'Communicating Planned Outages' that states that "you should provide notice [for planned outage notifications] in a timely manner similar to your other channels." It differs from the schema which states "Planned outages should be...Published to Data Recipient Software Products with at least one week lead time for normal outages". I assume the schema takes precedence, and the Zendesk article is out of date? The schema goes on to say "Planned outages may occur without notification if the change is to resolve a critical service or security issue." Does this mean all of the below is correct: * If a DH puts in an urgent change and either doesn't lodge the notification with a weeks notice, or lodges no notification, that is still classified as a planned outage? * The Get Outages API has no impact on whether an outage is treated as Planned? * It is only ever an Unplanned outage if the DHs system is down for a reason other than a release/fix?	The Standards state that planned outages should be published through the Get Outages endpoint with at least one week lead time to not be considered an 'unavailable' period. If a planned outage is to resolve a critical service or security issue, it may occur without notification, to not be considered an 'unavailable' period. The Get Outages API does have an impact on whether an outage is treated as planned, because all planned outages, other than for critical fixes, are expected to be published. All other periods of outage should be considered as unavailability. Also note that planned outages should only be commensurate in length and frequency to your other primary digital channels.
1822	This article provides guidance that for Get Account Detail, “information specific to the account, not general product information” should be shared https://cdr-support.zendesk.com/hc/en-us/articles/900005433663-Grandfathered-products-and-PRDs. As a data holder, we have residential mortgages where we offer a “Cashback Offer”. For Get Product Detail, we will share the product feature of CASHBACK_OFFER. If a customer subsequently applies and qualifies for the cashback offer then the cashback is transferred to the customer to another account as part of the home loan settlement. We do not consider that the cashback feature is specific to the account but specific to the product and the application. It is not a feature of the account that is not active and can be activated, nor is it a feature of the account that is active as the event has completed. If a customer who has received a cashback offer as part of settlement subsequently consents to sharing the account details for their residential mortgage, then is it acceptable not to share Cashback Offer feature information as part of Get Account Detail?	For the CASHBACK_OFFER feature type, the Standards state - "Subject to terms, conditions and eligibility criteria, the product has a cashback offer for opening an account or by spending at a certain retailer." If the cashback feature related only to 'opening an account' (as a once-off) then it may make sense to only apply it in the public product endpoints (pre-instantiated). If it was a feature that was relevant to usage of the account ongoing, like 'spending' for example, then we would expect that to be included in the Account Detail endpoint for the instantiated account as well.
1825	For the Get Scheduled Payment schema, there is a field named 'nickname' under the 'BankingScheduledPaymentTo' object. The nickname is a conditional field and the description says "The short display name of the payee as provided by the customer unless toUType is set to payeeId. Where a customer has not provided a nickname, a display name derived by the bank for payee should be provided that is consistent with existing digital banking channels". The above description is contradicting as it talks about the payee's nickname but yet it says "unless toUType is set to payeeId". Do we need to supply this field if the toUType is payeeId or not ?	The nickname is not required in that schema if the toUType is set to payeeId, because when a payeeId is provided, the payee nickname (and other details) can be retrieved from the Get Payee Detail endpoint (which includes BankingPayeeV2), by using the payeeId provided in BankingScheduledPaymentTo. If the toUType is set to one of the other values, then a nickname for the payee should be provided directly in the Scheduled Payment schema. Note that the payeeId should only be included in the BankingScheduledPaymentTo schema if the payee scope has been consented, as the description of that field states.
1826	Large customers (e.g. C&I) , 'plan' set up is bit different to mass-market i.e. the plan/s have multi year contracts with stepped prices each year; please refer to the below example of a C&I plan and tariff set up for clarity: Date of CDR request = 16.12.2022 Plan A 1/7/21 – 30/6/22 - Year1 Price 1/7/22 – 30/6/23 - Year 2 Price 1/7/23 – 30/6/24 - Year 3 Price We note, DSB advice that "the intent is not to include historical plan information (within EnergyAccountDetailV2 API – PLANS array), therefore we believe the most appropriate data to provide in this instance, is providing plan and pricing detail that is "relevant for the year the request date is within and no past or future year prices" i.e. for the example above pass the response with "Year 2022" plan and pricing information. Seeking confirmation from the DSB, that the provision of plan and pricing details that is relevant for the year the request date is within and no past or future year prices is inline with the obligations for such customer data set ups.	The assumption I am making is that in the example above, the Year 3 price would be known as part of the plan during the request made on 16.12.2022. If the assumption is correct, it would make sense to share the known future price/rates. This would be beneficial in plan comparison use cases. Note that the rates objects in the energy schemas have start and end dates which can be used to specify when they are applicable from/to. For e.g. https://consumerdatastandardsaustralia.github.io/standards/#tocSenergyplantariffperiod
1832	Can you please advise what default value we should set for the following 3 new parameters for existing ADRs ? 1. authorization_signed_response_alg 2. authorization_encrypted_response_alg 3. authorization_encrypted_response_enc	Where you've said 'existing ADRs' I'm assuming you mean ADRs that are already registered. If so, there is no need to set defaults for them, as they would be expected to update their registration themselves once they have determined (through the data holder's OpenID Configuration) that the data holder supports authorisation code flow (in conjunction with JARM), which they should do before the retirement date of the OIDC hybrid flow. There is a transition period defined in the standards to support the change.
1836 Part 1	It was observed that one of the CDR solution provider had implemented a CDR solution where AUTHORISATION transactions has a status of POSTED, then disappears and is "replaced" with a new transaction - also POSTED - with a new transaction ID, different date and a more complete description. The standards and various ZenDesk articles discusses transactions with PENDING status and whether there is linkages to the final POSTED transactions is at the discretion of the data holder, but it is unclear as to whether the pattern described here is compliant to the standards. The data recipient is reporting that they are getting transactions returned with a status of POSTED which are behaving more like impermanent / pending transactions. The description of these posted transactions is AUTHORISATION. But that transaction then goes missing and is replaced with a new transaction - also posted - with a different date and a more complete description, with a new transaction ID. The Data Recipient is expecting the initial AUTHORISATION transaction to have a PENDING status. Could you please advise if this behaviour is acceptable? Context provided by the Data Recipient: To avoid querying a user’s full transaction history on every transaction refresh, the ADR treat posted transactions as finalised / permanent, and the ADR does not re-query the data holder for updates for posted transactions. For this optimisation to work, that particular ADR need to have confidence that posted transactions have been finalised.	There is nothing in the Rules or Standards that would prohibit changes to transaction data like that, and in most cases we have suggested that any data shared through CDR should match what is provided to the consumer through other channels. Whether a transaction is an AUTHORISATION or any other type, the type is independent of the status. Both values are determined by the data holder though, as described above. If the Data Holder system records AUTHORISATION transactions as POSTED (or if they become POSTED after also being PENDING), and that is how they are shared, that would appear to be acceptable. Note that the description of the status field states - "Status of the transaction whether pending or posted. Note that there is currently no provision in the standards to guarantee the ability to correlate a pending transaction with an associated posted transaction" Also note that the transactionId is not mandatory, so there may be cases where some corresponding transactions cannot be correlated at all. You may find the following articles relevant to the question as well - Pending and Posted Transaction duplication](https://cdr-support.zendesk.com/hc/en-us/articles/900003317306) Can Data Holders match Pending and Posting Transactions?
1836 Part 2	Thank you for your respond. I think the Data Recipient's concern was whether a POSTED transaction be removed from the data returned by the data holder brand in subsequent data retrieval request. In the example provided by the data recipient, they had assumed that POSTED data are permanent and as a result of that assumption, they are showing the customer to have "duplicate" transactions (the cached deleted transaction and the new transaction). It sounded like the standard's view is that POSTED transactions should not be considered as permanent and the ADR should replace the retrieved data completely after each data retrieval because POSTED transactions can be deleted. Is my understanding correct?	Your understanding is correct, there is no requirement in the Standards for POSTED transactions to be interpreted (by the Data Holder or Data Recipient) as meaning 'permanent'. If this causes a particular problem for the participant and they would like to request a change to the Standards for consultation by the community, they could raise a change request in the Standards Maintenance repository - https://github.com/ConsumerDataStandardsAustralia/standards-maintenance
1838	Standards version 1.22.0 changed the x-v and x-min-v headers from string to integer data type. The existing Banking APIs show these elements as string type. This appears to have introduced an inconsistency into the standards. Can it be assumed that this does not change in any way how the Register APIs are constructed and are these elements are to be handled in exactly the same way across both Register and Banking APIs despite this inconsistency? Will this inconsistency be addressed in the upcoming standards version. We also note that this issue was previously raised in two separate posts in the discussion within issue #546 but did not appear to be resolved at that time.	The changes in version 1.22.0 related to the x-v and x-min-v headers were intended to bring some consistency due to other differences in previous versions, and were limited to the Register specs only. They were not intended to signify a change in handling compared to the other definitions. The following issue has been raised to highlight the resulting inconsistency and to allow any further input from yourself and the community. Inconsistency of data types in various schema #575](https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/575)
1841	With the FAPI 1.0 Phase 3 Data Holder obligations due on the 14th April 2023 are these changes able to be implemented before this date or must they be implemented on or after the 14th April 2023 date? With the previous FAPI changes it was requested that Data Holder changes be implemented on the obligation date to minimise ADR impact. If this is the preferred or required approach then we would like to plan our implementation ahead of time.	Data Holders may implement the FAPI 1.0 Phase 3 changes at any time before April 14th 2023.
1846	In below link it is mentioned that timeouts can be excluded from calculation of average response time. https://cdr-support.zendesk.com/hc/en-us/articles/5080132948367--ARCHIVE-Timeouts-in-average-response-times-for-Get-Metrics Does that mean 504 errors(gateway timeout) occurring due to timeouts when calling external endpoints or internal gateway timeouts can be excluded from calculating average response times? To give more context for example if we have set a 20 second timeout for banking API calls the request times out if it crosses 20 seconds. Can we exclude these type of errors from the average response time calculation? Also please mention if there is any other error codes which need to be excluded for any other reason for calculating average response metric. If for example we are retrieving list of accounts and if there is a third party provider credit card along with the accounts the dataholder needs to call the third party service provider as well to retrieve the credit card account details. This is just one of the scenarios of what I meant by external endpoints.	Where the Standards are defined, and where additional guidance may be provided relating to response codes or response times, it would generally refer to the final response received by the ADR, associated with the success or error of a single 'roundtrip' request/response. If a sequence of 'behind-the-scenes' requests (that are internal to the data holder, including any relevant third-party requests, as per your example) are required to fulfil a single response to an ADR, and they ultimately result in a final 504 response back to the ADR, then those 504 responses (or the overall response times of them) are expected to be excluded from the ‘Average Response time’ and ‘Performance’ calculations. Note though, that all 5xx responses, including 504, must be counted as instances of errors ('Number of calls resulting in error due to server execution') in the Get Metrics API. I hope that explanation makes sense but let me know if I have misunderstood something about the context and situation you described. With regard to your second question - No other error types have been suggested for exclusion from the response time calculations, but if you feel that more could be worth considering we'd be interested in the reasoning.