Skip to content

ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 21st of October 2021

Jump to bottom
CDR API Stream edited this page Oct 21, 2021 · 9 revisions

ACCC & DSB | CDR Implementation Call 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: 1650705270@webex.com

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 contact@consumerdatastandards.gov.au 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.12. Published Link to change log here
Standards v1.13.0 is now in Standards-Staging Release date: 22nd of October 2021
Maintenance 9th Maintenance Iteration Agenda from the 20th of October 2021 meet
Maintenance 9th Maintenance Iteration Extended until 1st of December 2021
Maintenance Decision Proposal 212 - Banking Maintenance Iteration 9 Link to consultation
Maintenance 9th Maintenance Iteration Meeting Details Now included on Decision Proposal here
Maintenance 10th Maintenance Iteration To commence on 16th of February 2022
DSB Newsletter To subscribe to DSB Newsletter Link here
TSY Newsletter To subscribe to TSY Newsletter Link here
DSB Newsletter 15th of October 2021 View in browser here
TSY Newsletter 20th of October 2021 View in browser here
Consultation Decision Proposal 197 - Candidate Account End Points Link to consultation
Consultation Decision Proposal 198 - Candidate Billing & Invoicing End Points Link to consultation
Consultation Normative Standards Review (2021) Link to consultation
Consultation Decision Proposal 209 - Transition to FAPI 1.0 Advanced Profile Link to consultation
Consultation Decision Proposal 213 - CX Standards & Energy Data Language Link to consultation
Knowledge Video of Energy Sector and Consumer Data Right 101 View Video

CDR Stream Updates

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

Organisation Stream Member
ACCC CDR Register (Technical) Ivan Hosgood
ACCC CTS Andrea Gibney
ACCC Onboarding Christine Atkins
ACCC Accreditation Natalie Plumridge
ACCC Technology David Renzella
DSB CX Standards Eunice Ching
DSB Technical Standards - Banking Mark Verstege
DSB Technical Standards - Energy & Engineering James Bligh

Presentation

Recording: this week we will trial recording and sharing the Presentation.

Title: Version 1.13.0 of the Consumer Data Standards
Presenter: James Bligh

Links:

Q&A

Questions will be received by the community via WebEx chat before the questions are opened to the floor. Participants can pre-submit questions to the DSB mailing box.

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

Answer provided

Ticket # Question Answer
1099 When a consent expires are there any obligations on the data holder to:
- notify the ADR, and/or
- notify the consumer
- 'clean-up' the consent record and any Consent database to show the consent has expired with the applicable date/time
A Portal article "Expiry of Access Token for expired consent" already directs that "standards do not specifically require an access token to become invalid when a consent expires"
https://cdr-support.zendesk.com/hc/en-us/articles/900005248766-Expiry-of-Access-Token-for-expired-consent 		The response to this ticket overlaps with the response to #1100 as they relate to similar issues.
When an authorisation expires, is the DH required to notify the ADR?
As noted in #1100, if the DH withdraws consent because the consumer is ineligible, the DH must notify the ADR via the ADR's CDR Arrangement Revocation endpoint. DHs must thereafter reject any data disclosure requests. However, the rules define 'expiry' broadly - consents and authorisations 'expire' when they are withdrawn, for example. The rules only specify that DHs notify ADRs when a withdrawal occurs, but other aspects of the rules require CDR participants to notify other CDR participants when expiry occurs (e.g. AP disclosures). Our preliminary view is that there are no obligations for a DH to notify an ADR when the sharing duration of an authorisation naturally expires, but let us get back to you to confirm this one.
When an authorisation expires, is the DH required to notify the consumer?
There are scenarios that require DHs to notify consumers of an authorisation's expiry, such as:
When an authorisation sharing data from a joint account expires (rule 4A.14 in the v3 rules)
When an authorisation given by a secondary user expires, the account holder must be notified (rule 4.28(2))
As per privacy safeguard 10, via the dashboard, to update when the CDR data was last disclosed
Via the dashboard in general, to ensure the dashboard is up to date (this relates to the 'clean-up' consent record query)
The CX Guidelines for DH dashboards recommend that DHs provide a 'CDR Receipt' to the consumer in writing, other than through the dashboard, when authorisations are:
established
withdrawn
expired
amended (noting that technically the authorisation is revoked and a new one established, but to the consumer it appears as if they are amending it via the full consent flow)
When an authorisation expires, is the DH required to clean up the consent record and any database to show the consent has expired with the applicable date/time?
Yes. DHs must update the consumer dashboard to show when the authorisation has expired. This should also be recorded by the DH as per Division 9.3 of the rules.
1100 When a consumer becomes an ineligible CDR customer due to closing all their online accounts held with a data holder what are the data holder obligations with regards any active consents?
Is the data holder expected to:
- notify the ADR that the customer has closed all their accounts and any future resource request will be rejected
- notify the customer that no further CDR data will be disclosed to their ADRs
- revoke any access tokens and refresh tokens
- revoke the active consent(s) and set the revocation date to the date/time the last account was closed
If any of the above is expected to be performed by the data holder is there a time window this action must be completed within?
The existing Portal article "Consent on closed accounts" does not provide any direction on this.
https://cdr-support.zendesk.com/hc/en-us/articles/900003831546?input_string=data+holders+obligations+when+all+cdr+accounts+closed 		The response to this ticket overlaps with the response to #1099 as they relate to similar issues.
When a consumer becomes ineligible due to closing all their online accounts held with a data holder what are the data holder obligations with regards any active consents?
Data Holders must not disclose data for ineligible consumers. All consents must expire if the consumer is no longer eligible from a CDR perspective.
Is the data holder expected to notify the ADR that the customer has closed all their accounts and any future resource request will be rejected?
If the DH withdraws consent because the consumer is ineligible, the DH must notify the ADR via the ADR's CDR Arrangement Revocation endpoint. DHs must thereafter reject any data disclosure requests.
Is the data holder expected to notify the customer that no further CDR data will be disclosed to their ADRs?
As noted in #1099, there are scenarios that require DHs to notify consumers of an authorisation's expiry, such as:
When an authorisation sharing data from a joint account expires (rule 4A.14 in the v3 rules)
When an authorisation given by a secondary user expires, the account holder must be notified (rule 4.28(2))
As per privacy safeguard 10, via the dashboard, to update when the CDR data was last disclosed
Via the dashboard in general, to ensure the dashboard is up to date (this relates to the 'clean-up' consent record query)
The CX Guidelines for DH dashboards recommend that DHs provide a 'CDR Receipt' to the consumer in writing, other than through the dashboard, when authorisations are:
established
withdrawn
expired
amended (noting that technically the authorisation is revoked and a new one established, but to the consumer it appears as if they are amending it via the full consent flow)
Is the data holder expected to revoke any access tokens and refresh tokens?
There are no standards permitting the revocation of access and refresh tokens by Data Holders. The correct course of action on consent withdrawal is to withdraw the consent and expire the consent whilst notifying the ADR of the withdrawal. As part of this process, the oAuth security tokens can be revoked.
Is the data holder expected to revoke the active consent(s) and set the revocation date to the date/time the last account was closed?
DHs must withdraw any active consents where the consumer ceases to be ineligible. The rules generally provide notification and dashboard update time-frames that range from 'as soon as practicable' to 'within 2 business days'. With this in mind, the expectation would be for the date/time of revocation to be when the authorisation was actually withdrawn, not when the accounts were closed (which may in practice be the same date/time).
1117 I would like to find out what is the expected action required of a data holder in the context of managing a Joint account that contains a under 18 individual?
1. My assumption is that since the U18 personnel is ineligible to be CDR consumer, and I've read on the FAQ that since Joint Account eligibility is deemed collectively, I'm assuming here on the authorisation flow that this Joint Account with such individual will be listed as an un-selectable and unavailable account.
2. For the disclosure option though, can I assume we (as data holder) are still setting the default for such ineligible accounts with the Pre-approval option as a default? (Don't think there is any exceptions rules listed to indicate to DH what to do for these accounts on disclosure options that contains AH who are ineligible.)
To round up, based on what I can find currently, is this flow correct?
1. DH set default disclosure option for all joint accounts (regardless of AH eligibility)
2. AH will only finds out they are ineligible (collectively impacted as one of them is U18) only if they try to access the accounts to share CDR (i.e. un-selectable and unavailable account)		 That is correct - eligibility is determined collectively, meaning all joint account holders must be eligible for the joint account itself to be eligible for sharing. Put another way, if one joint account holder is not eligible then none of the joint account holders can share that joint account's data.
The technical workflow is for DHs to determine, but the default pre-approval disclosure option should only take effect when the joint account becomes eligible.
1127 We are seeking confirmation on the interpretation for an individual consumer to be a Secondary User of another account holder.
CDR Rules state a Secondary User is required to have account privileges in relation to an account and is an eligible CDR Consumer with an account to be set up in such a way that it can be accessed on line by the CDR Consumer.
Is it sufficient for a Secondary User to have online access to their own account(s) only or do they require online access to an account of the other account holder for which they have account privileges?
It is possible for a person to have account privileges for an account (eg. ATO) but not have online access to that account.		 We (DSB) can't provide a legal/compliance view on this, but our interpretation to date aligns with yours.
That is, the secondary user is eligible if they can access accounts online, even if the account they are a secondary user of is not one of those accounts. Based on this interpretation, the account they are a secondary user of would be available for them to share in this scenario too.
1128 Reference - 4A.7 Changing to a more restrictive disclosure option
Under point (2) - it states that:
"If the pre-approval option applies to a joint account, a joint account holder may at any time choose that the co-approval option will apply to the joint account, using the disclosure option management service."
Question:
1. As all accounts will default to "pre-approval" , does this mean that "co-approval" status is no longer optional? as stated in 4A.5 (1) (b) (b) "the co-approval option, under which joint account data may be disclosed in response to a valid consumer data request only after:
(i) the requester has authorised the disclosure; and
(ii) each of the relevant joint account holders has approved the disclosure; "		 The co-approval option is still optional.
See rule 4A.5(2), which states that DHs must provide for the pre-approval and non-disclosure options, compared to 4A.5(3), which states that DHs may provide for the co-approval option.
4A.4's simplified outline similarly states that 'Data holders must offer the pre-approval and non-disclosure option on joint accounts, and may offer the co-approval option.'
1129 Could you please confirm that for the sessionCount to be reported in Get Metrics DHs should include the sessions that result in responding to the DR with an error? sessionCount is the successful provisioning of an access token. It is not the number of Authenticated API calls made.
1131 Are features mandatory for grandfathered products in get account details api?
Some products have been discontinued and the legacy data is no longer available. Under these circumstance, can we expose the data with FeatureType = 'OTHER' and additionalInfo= 'Retired product'? If not, could you please advise on an alternate solution?		 product data applicable to the account the customer holds such as features, fees and rates, need to be provided. These would be the features that are negotiated and specific to the account held by the customer, not the grandfathered product.
1134 If a Data Recipient, when calling the Get Balances For Specific Accounts endpoint of a Data Holder, sends an empty array as accountIds should the Data Holder respond with an empty array back or 400 Bad Request error? I assume that if the accountIds is totally empty a Bad Request error should be returned since the field is mandatory, but what if the array is present, however no account is provided. The data standards aren't explicit and I would say both are acceptable responses.
If you think an explicit response (e.g. 400 Bad Request) is desirable, please feel free to raise a change request so this can be accommodated.

Useful Links

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

Getting Started

Meetings

Maintenance Iterations

CDR Implementation Call

Clone this wiki locally