ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 10th of February 2022 - ConsumerDataStandardsAustralia/standards GitHub Wiki

CDR Implementation Call Banner

Agenda & Meeting Notes

When: Weekly every Thursday at 3pm-4.30pm AEDT Location: WebEx, quick dial +61-2-9338-2221,,1650705270##

Meeting Details:

Desktop or Mobile Devices https://treasuryau.webex.com/treasuryau/j.php?MTID=m9614a7c6166155d3d950a8999e437f9f 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: [email protected]

Phones - AUDIO ONLY

Agenda

  1. Introductions
  2. Actions
  3. CDR Stream updates
  4. Presentation
  5. Q&A
  6. Any other business

Introductions

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

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.

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.

Updates

Type Topic Update
Standards Version 1.16.0 Published Link to change log here
Maintenance 10th Maintenance Iteration To commence on 16th of February 2022
TSY Newsletter To subscribe to TSY Newsletter Link here
DSB Newsletter To subscribe to DSB Newsletter Link here
TSY Newsletter 25th of January 2022 View in browser here
DSB Newsletter 4th of February 2022 View in browser here
Consultation Normative Standards Review (2021) No Close Date Link to consultation
Consultation Decision Proposal 225 - Data Recipient Security Standards Feedback closes 18th of February 2022 Link to consultation
Consultation Decision Proposal 229 - CDR Participant Representation Placeholder: no close date Link to consultation
Event DSB: CDR Introduction - Telecommunications Sector 2022 Free - Register here
Guidance Published by the ACCC: CDR Representatives Guidance CDR Support Portal Article
Support New Video on DSB Obligation Dates ( Published 08/02/2022) Data Standards Body YouTube Link

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 Hopeson Chiao
ACCC CTS Andrea Gibney
DSB CX Standards Michael Palmyre
DSB Technical Standards - Register Ivan Hosgood
DSB Technical Standards - Energy Hemang Rathod
DSB Technical Standards - Banking Mark Verstege
DSB Technical Standards - Engineering James Bligh

Presentation

None.

Q&A

Questions will be received by the community via WebEx chat before the questions are opened to the floor. Participants can submit questions outside of the CDR Implementation Call to the CDR Support Portal.

We are using Sli.do for Question and Answer. Join our Q&A live here: https://www.sli.do/ Code: #169517

Answer provided

The following table will be updated after the meeting.

Ticket # Question Answer
1285 Part 1 For annotation 14 on https://www.notion.so/Joint-account-disclosure-option-management-service-365dcb00593b4cd89864da6d59732ff4 under "Changing to a Non Disclosure option" it says the below: As part of the process of removing a joint account approval or changing to a more restrictive disclosure option, the data holder MUST advise the consumer: 1. that doing this may impact existing services, including arrangements initiated by the other account holder(s) 2. when removing an approval: a. that even though sharing for this service has now stopped, the other account holder(s) can still create new data sharing arrangements for the joint account b. how to change their disclosure option Note: The exact phrasing of the withdrawal message is at the discretion of the data holder. This standard does not affect data holders’ other notification obligations, including under rule 4A.7(3). For point no.2a - is this saying that after customer selects "stop all sharing from this account" other account holders can still create a new data sharing arrangement? My understanding is that we can no longer share this account unless the account holder changes the disclosure option back to single or joint consent options? You are correct, when a customer selects 'stop all sharing from this account', data will no longer be shared from this account until it is changed to a less restrictive disclosure option. Please also refer to annotation 22 on the Change to non-disclosure option for more information. However, annotation 14 references the Withdrawal Standard for joint accounts (see Withdrawal: Joint accounts) with point 2a part of this standard referring specifically to removing an approval rather than changing to a non-disclosure option. When a customer removes an approval for a specific sharing arrangement, they and other joint account holders can still share data from that joint account for other sharing arrangements. To further clarify, points 2a and 2b of this standard do not need to be applied to changing to non-disclosure option scenarios, but need to be applied to 'removing approval' scenarios.
1285 Part 2 The below points make sense but I think the “stop all sharing from this account” selection displayed in the wires is throwing me off. Is that wire example for non-disclosure option only or is it meant to represent the ability to just ‘remove an approval’ also? The reason I ask, is cause annotation 14 mentions both but the wires seem to only represent one of the options? Those wires only refer to where a non-disclosure option is being selected, not where an approval is being removed. Annotation #14 refers to a CX standard for both approval removals and where changing to a non-disclosure option. Bullet point (1) of that standard applies to both approval removals and where changing to a non-disclosure option, while bullet point (2) of that standard only applies to approval removals as specified in the statement. The approval removal flows are demonstrated in the DH dashboard withdrawals guidelines, where approval removals would occur (i.e. not specifically in the DOMS). You'll see the same standard referred to in the DH dashboard withdrawal guidelines,which shares the same annotation number (i.e. #14).
1288 Can you please clarify the following queries related to EnergyAPI – EnergyInvoice 1. Assuming – DH to provide the invoices issued in last 24 months based on Invoice Issue Date (not based on Invoice Period End Date). Please confirm. 2. In EnergyInvoiceElectricityUsageCharges section, a. field “totalUsageCharges”, does it include Demand Charges also? Or just the Peak, Off Peak, Shoulder and Controlled load charges? If not including Demand charge then should Demand be passed as Other Charges? (Notes: In BillingTransasction APIs, Usage and Demand related charges are separate section) b. field “totalOnceOffCharges”, does it include only the service orders fees/charges or late payment fees or bill delivery fee or Payment fees)? c. field “totalOnceOffDiscounts”, Does this also include Concession Amount and any other discount applied on bill? In consultation 198, you have mentioned concession and rebates are not included. If not included, then InvoiceAmount will not match with this sub-section of data (because of Invoice amount includes Concession amount deducted). Is this ok? d. field “otherCharges”, assuming this will include Daily Supply charge, metering charge or anything else that was not included in above fields? Answer 1: Correct Answer 2: The standards are not prescriptive in this regards, it is at the discretion of the Data Holder to determine what charges fall into which category, similar to the approach taken in banking. As general guidance, I’d suggest the following: a. Any charges resulting from usage of energy would be within totalUsageCharges b. Any charges that are incurred once-off (i.e. not recurring) would be within totalOnceOffCharges c. Are you referring to the below comment? The comment is clarifying that separate specific fields will not be created for concessions; they should be included in the total fields as per suggestion. “Concessions and rebates should be included in the total fields as suggested. Separate fields have not been created due to the sensitivity of this data set. By aggregating this data a customer is able to share their invoice data without the need to disclose a hardship related concession. Concessions have been separated into a specific data scope for this reason.” d. Any charges part of the invoice that don’t fall within usage or once off charges would be within other charges
1302 We’re unable to support the ‘OR’ operator between the two account fields to be searched in the ‘text’ query parameter in Get Transactions For Account but cannot implement the requirement stated in the last sentence of the fields’ description: “If it is not implemented then a response should be provided as normal without text filtering applied and an additional boolean field named isQueryParamUnsupported should be included in the meta object and set to true (whether the text parameter is supplied or not)”. Adding this field fails schema validation as it is not a valid field in the MetaPaginated schema. There is no other reference to isQueryParamUnsupported in the standards. Can you please advise how this should be managed? just to confirm I have created a documentation change request that can be addressed in the next maintenance iteration / release. https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/469
1304 For the following requests, if an extra / is sent in the request instead of the accountId/transactionId/productId/payeeId (ex: /banking/accounts//), what is the expected response? Should the call be mapped to a bulk retrieval or should an error be returned as "urn:au-cds:error:cds-all: Field/Missing"? Resources: /banking/accounts/{accountId} /banking/accounts/{accountId}/transactions/{transactionId} /banking/payees/{payeeId} /banking/products/{productId} Question: For the following requests, if an extra / is sent in the request instead of the accountId/transactionId/productId/payeeId (ex: /banking/accounts//), what is the expected response? Should the call be mapped to a bulk retrieval or should an error be returned as "urn:au-cds:error:cds-all: Field/Missing"? Answer: This is an implementation decision on how to treat trailing slashes. It may differ between API gateways, code libraries and code implementations for the APIs. If the DH saw two trailing slashes and their implementation parsed this as a null resource identifier then it would be reasonable to throw an error. Other implementations may see the two trailing slashes and ignore them and return the parent resource. Basically: If the DH truncates trailing slashes then they would treat the call as the bulk call If the DH treats it as a missing parameter then an error is appropriate I would consider either behaviour as valid since we don't specify this behaviour in the data standards. That said, ADRs should certainly not do this and check their request to APIs are well-formed.
1314 When a consent has been withdrawn / cancelled and when a consumer invokes any authenticated API's which error code should be returned? 401 Unauthorised or 403 Forbidden. As per the new Standard Error Code, Consent revoked is categorised under 403 Forbidden, however technically if the consent is revoked, it will make all the refresh and access tokens invalid and after that when a consumer invokes an authenticated API, it will return 401 Unauthorised as the authorisation token is not invalid in the request header. In the above scenario, which error code should be returned?

Useful Links

View a number of informative and useful links in the Consumer Data Standards Implementation Guide on Information Links.