Skip to content

ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 12th of August 2021

Jump to bottom
CDR API Stream edited this page Aug 12, 2021 · 3 revisions

ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes

When: Weekly every Thursday at 3pm-4.30pm AEST
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.11.0 Published Link to change log here
Standards Version 1.11.0+ Planned for August 2021
Maintenance 8th Maintenance Iteration Commenced Agenda from the 28th of July 2021 meet
Maintenance Decision Proposal 202 - Banking Maintenance Iteration 8 Link to consultation
DSB Newsletter To subscribe to DSB Newsletter Link here
TSY Newsletter To subscribe to TSY Newsletter Link here
TSY Newsletter 29th of July 2021 View in browser here
DSB Newsletter 6th of August 2021 View in browser here
Consultation Decision Proposal 180 - Energy Draft Feedback Cycle 3 Link to consultation
Consultation Decision Proposal 183 - Purpose Based Consents Link to consultation
Consultation Decision Proposal 186 - Engineering Support Link to consultation
Consultation Decision Proposal 191 - Retailer to AEMO InfoSec Profile Link to consultation
Consultation Decision Proposal 200 - Action Initiation Framework Link to consultation
Consultation Normative Standards Review (2021) Link to consultation
Consultation Decision Proposal 207 - Draft v3 Rules Analysis - Anticipated Data Standards Link to consultation
Event Introduction to the Consumer Data Right Link to register
Observation A number of searches for 'x-cdr-arrangement' are being conducted on GitHub There are a number of articles on the CDR Support Portal which might assist those seeking an answer.
CDR Arrangement ID Mismatch Behaviour
Maintaining cdr_arrangement_id in amended consent
Pushed Authorisation Request end point and cdr_arrangement_id in Request validation
In lieu of the articles not covering the questions or interest, please reach out to the CDR Support Portal via: support@cdr-support.zendesk.com

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 (Away this week)
ACCC CTS Andrea Gibney
ACCC Onboarding Jonathon Ingle
DSB CX Standards Eunice Ching
DSB Technical Standards - Banking Mark Verstege
DSB Technical Standards - Energy & Engineering James Bligh

Presentation

None this week.

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
924 oping you can clarify the below as some of it is open to interpretation.
With regards to the information displayed to a customer during the authorisation process, can you please clarify whether it is required for a customer to view all transactions (dating back to 2017) prior to consenting to share transactions with a data recipient ?
Or is it alright for a customer not to see the transactions they are intending to share with a data recipient ?
As currently, in the design provided by our solution provider, a customer is able to see name, occupation, contact details, accounts & balances and they cannot see any transactions in the authorisation flow even though they have chosen to share transactions with a data recipient. Please confirm if this in accordance to the standards or is there a requirement for a customer to view or download the transactions they are going to share prior to consenting ?		 Data holders do not need to show consumers their actual transactions during the authorisation process.
The authorisation process allows the consumer to review and authorise the disclosure of classes of data to a accredited data recipient; the consumer does not need to review the actual data in question to do this.
The data language standards contain requirements for how data must be presented to consumers during consent, authorisation, and management-related process. These similarly do not require the actual data to be displayed to the consumer.
Examples of the authorisation flow can be found in the CX Guidelines for Authorisation to Disclose.
The ACCC have also noted that the following references contain relevant information:
Rule 1.15, 4.23 and 7.9
pages 24 and 25 of our DH guidance
the following knowledge articles: Date for collection of consumer historical data
Data holder dashboards – disclosure on consent
957 In the scenario that a consumer has concurrent consents in place between an ADR and a Data Holder, does the Data Holder consumer dashboard need to support the withdrawal of each individual consent, or would it be acceptable for the withdrawal action apply to all active concurrent consents (with that ADR)? Data holders need to support the withdrawal of each individual authorisation, even where concurrent consents exist with a single ADR.
The rules and standards are constructed in a way that an authorisation to disclose has a 1:1 relationship, and this is how the authorisation works in a technical sense too.
Consumers can only establish one authorisation at a time, so not supporting the withdrawal of one authorisation at a time would be counter intuitive; would raise issues with regard to consumer control, service impacts, and informed withdrawal processes; and would also go against the rule that requires withdrawals to be 'no more complicated to use than the process for giving the authorisation to disclose' (Rule 1.15(1)(c)(iii)).
If you haven't seen them already, we have CX Guidelines for authorisation withdrawal that may be a useful reference point.
964 Could you please confim that it's acceptable to only show closed accounts as available in the authorisation flow if they have been closed for 12 months or less. And show closed accounts as unavailable if they were closed for more then 12 months. Therefore a customer can only include in a consent only accounts that were closed for 12 months or less. The CX Guidelines state the following on unavailable accounts:
Unavailable accounts may include eligible accounts that cannot be shared, such as where a data holder deems it necessary to prevent financial harm or abuse.
Unavailable accounts may also include ineligible accounts which data holders may show to mitigate confusion, such as where a consumer expects to see their accounts but cannot select them because they are ineligible for CDR.
The rules state the following on required consumer data in relation to closed accounts:
_(5) Despite subclause (1), for an account that is closed at a particular time, the following CDR data is not required consumer data at that time: _
_(a) account data that relates to an authorisation on an account for direct debit deductions; _
_(b) where the account was closed no more than 24 months before that time―transaction data in relation to a transaction that occurred more than 12 months before the account was closed; _
_(c) where the account was closed more than 24 months before that time: (i) account data that relates to the account; and (ii) transaction data that relates to any transaction on the account; and (iii) product specific data in relation to a product relating to any such account. _
Note: As a result, such CDR data would be voluntary consumer data.
The rules contain date ranges of 12-24 months depending on the data in question. The rules also note that while data outside this period isn't required consumer data, it could be considered voluntary consumer data.
So long as it is in accordance with the rules on required consumer data and eligibility, a closed account could be shown as unavailable if the data being requested is not required consumer data.
966 Wondering if you could provide guidance on how the 'last' direct debit authorisation should be selected from a set of transactions where there may appear to be multiple for a particular merchant with different amounts at different times of the month and directed at different account numbers and BSBs with their associated financial institution.
Should the list of direct debits be deduplicated by Merchant name only, or by a combination of merchant and financial institution, or also include the account and BSB which are held by us, but are not shared in the Direct Debit API responses?		 If the same merchant is debiting two accounts they should be treated as two different direct debits
Within an account, merchant is the determining factor. If a merchant debits the same account multiple times but from different FIs it shouldn't be two direct debits
The 'last' direct debit is meant to indicate the most recently identified direct debit transaction
970 I have a few questions around the accessibility requirements: Are these accessibility requirements applicable to the CDR July/Nov 2021 release? If yes, could you please point out the minimum level of compliance required around them?
2.2.1 Timing Adjustable: https://www.w3.org/WAI/WCAG22/Understanding/timing-adjustable
3.3.5 Context Sensitive Help available: https://www.w3.org/WAI/WCAG22/Understanding/help
3.3.7: Accessible Authentication: https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication 		Thanks for this query. I'm not sure if you're referring to standards compliance or WCAG compliance levels, so I'll cover a few areas.
If you are referring to CX standards compliance:
The CX standards are all immediately mandatory unless otherwise stated in the future dated obligations or because the items in question are not in scope yet (e.g. as per rules phasing). The accessibility standards apply as soon as an ADR or DH participates in CDR.
There is, however, some contextual flexibility. The accessibility standards obligations are phrased as ‘Must seek to…’ with the emphasis on ‘seek to’. The wording acknowledges that there are situations where a CDR participant cannot comply or it may not make sense to (e.g. non-digital processes). This provides some flexibility with the intent being that CDR Participants should seek to comply and if they are unable to, or it is not appropriate, they should demonstrate how or why they did not comply.
For example, if a CDR participant was being investigated for issues related to its CX flow (including accessibility issues) they could be asked to provide information or documents that demonstrate that they have taken steps to “seek to comply” with the relevant accessibility guidelines. If they are unable to prove they have sought to comply with the relevant guidelines, they may be in breach of the CX Standards and regulators may consider whether any further enforcement action is appropriate.
If you are referring to compliance with the specified WCAG items:
2.2.1 (Timing Adjustable) is level A, but this is not covered in the CX accessibility standards
3.3.5 (Context Sensitive Help available) is level AAA, and this is covered in the standards under Accessibility: Input assistance
3.3.7 (Accessible Authentication) should be covered in Accessibility: Input assistance. This would fall under WCAG Guideline 3.3 but at the moment it's part of a WCAG2.2 working draft, so it may be changed or removed before WCAG2.2 is finalised.
There are a few elements there, but I hope that helps and answers your questions.
978 In the CDS spec date field classified as RFC-3339 standards. What date format need to apply for 'x-fapi-auth-date' The usage of this field is derived from the normative standards (in this instance the FAPI read profile). Specifically in section 6.2.2:
3. may send the last time the customer logged into the client in the x-fapi-auth-date header where the value is supplied as a HTTP-date as in section 7.1.1.1 of [RFC7231], e.g., x-fapi-auth-date: Tue, 11 Sep 2012 19:43:31 GMT;
956 Can a secondary user create a consent which can include their individual accounts along with nominated accounts?
Scenario : Secondary user has created a consent which includes their individual accounts along with nominated accounts and data scope includes “Get customer” and “Get customer details”. In this scenario, the customer details required to be shared would be of the secondary user (consent initiator) and not of the owner of the nominated accounts?		 Can a secondary user create a consent which can include their individual accounts along with nominated accounts?
Yes, a secondary user can established a single authorisation that is associated with their individual accounts and accounts they are a secondary user of, provided the account owner has given a secondary user instruction.
Scenario : Secondary user has created a consent which includes their individual accounts along with nominated accounts and data scope includes “Get customer” and “Get customer details”. In this scenario, the customer details required to be shared would be of the secondary user (consent initiator) and not of the owner of the nominated accounts?
Yes, the customer details shared would be those of the secondary user, not the account owner.

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