ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 18th of November 2021 - ConsumerDataStandardsAustralia/standards GitHub Wiki
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: [email protected]
Phones - AUDIO ONLY
- Primary Australia: +61-2-9338-2221
- Quick Dial: +61-2-9338-2221,,1650705270##
- Other Global Numbers: https://treasuryau.webex.com/cmp3300/webcomponents/widget/globalcallin/globalcallin.do?MTID=m311f46c87a3ab9ae5335a6c0ea431da4&MTID=m311f46c87a3ab9ae5335a6c0ea431da4&MTID=m311f46c87a3ab9ae5335a6c0ea431da4&MTID=m311f46c87a3ab9ae5335a6c0ea431da4&serviceType=MC&serviceType=MC&serviceType=MC&siteurl=treasuryau&siteurl=treasuryau&siteurl=treasuryau&apiname=globalcallin.php&apiname=globalcallin.php&apiname=globalcallin.php&rnd=6124483603&rnd=6124483603&rnd=6124483603&tollFree=0&tollFree=0&tollFree=0&ED=1403111402&ED=1403111402&ED=1403111402&needFilter=false&needFilter=false&needFilter=false&actappname=cmp3300&actappname=cmp3300&actname=/webcomponents/widget/globalcallin/gcnredirector.do&actname=/webcomponents/widget/globalcallin/gcnredirector.do&renewticket=0
- Meeting Number/Access Code: 165 070 5270
Agenda
- Introductions
- Actions
- CDR Stream updates
- Presentation
- Q&A
- 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.14.0 Published | Link to change log here |
| Standards | v1.14.0+ is unplanned | Pending any minor tweaks, fixes or amendments to v1.14.0 |
| Maintenance | 9th Maintenance Iteration | Agenda from the 17th of November 2021 meet |
| Maintenance | Additional Call next week 24th of November 2021 | |
| Maintenance | 9th Maintenance Iteration | Extended until 1st of December 2021 Dates updated here on the comment in Decision Proposal 212 |
| Maintenance | Decision Proposal 212 - Banking Maintenance Iteration 9 | Link to consultation |
| 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 | 11th of November 2021 | View in browser here |
| DSB Newsletter | 12th of November 2021 | View in browser here |
| 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 216 - Profile scope support | Link to consultation |
| Consultation | Decision Proposal 222 - CX Standards & Insights and Trusted Adviser Disclosure Consents | Link to consultation |
| Consultation | Decision Proposal 225 - Data Recipient Security Standards | Link to consultation |
| Consultation | Decision Proposal 162 - CX Standards & Joint Accounts | Link to consultation |
| CDR Implementation Call | End of the year Survey: Results! |   |
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) | ACCC Team |
| ACCC | CTS | Andrea Gibney |
| ACCC | Onboarding | Christine Atkins |
| DSB | CX Standards | Michael Palmyre |
| DSB | Technical Standards - Banking | Mark Verstege |
| DSB | Technical Standards - Energy & 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 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 |
|---|---|---|
| 1161 Part 2 | Part 1 So to be clear, is 1 Jan 2017 always a fixed starting date ? Would a Data Holder always need to send (transaction) data dating back to 2017 if requested by an ADR? I understand that if an ADR requests ALL past transactions in the year 2022, a DH would go back till 2017. But if, for example, an ADR requests data in the year 2027, how far back would a DH need to go back ? Would that still be 2017 or would it be 2020 ? | It is up to Data Holders to make their own interpretation of the rules but that is how I have personally understood it (noting that I am not qualified to give legal advice in any form). The question about what happens in ten years time is a good one. I haven't seen anything in the rules or legislation that puts an cap on historic data although it's possible that non-CDR rules may come into play. |
| 1177 | On CDS API specs x-fapi-auth-date is Optional for Banking and Common APIs. However, the description says "Required for all resource calls (customer present and unattended). Not to be included for unauthenticated calls." Could you please confirm if it is Optional or Mandatory. | This is a documentation error. "x-fapi-auth-date" is mandatory for all authenticated resource endpoints but not the unauthenticated endpoints as described in the HTTP Headers section (https://consumerdatastandardsaustralia.github.io/standards/index.html#http-headers) In the resource endpoint descriptions, we have "Optional" in the required column (see https://consumerdatastandardsaustralia.github.io/standards/index.html#get-accounts). This is a documentation error and it should read "Mandatory". This issue will be fixed in the next version of the standards. |
| 1182 | x-fapi-auth-date is mentioned as mandatory when the ADR is calling an authenticated endpoint. Are data holders expected to verify the presence of this field and reject the call if not present? If yes, what is the reasoning behind this check? As far as I'm aware data holders are not obliged to store of use this field for further processing. | This is a documentation error. "x-fapi-auth-date" is mandatory for all authenticated resource endpoints but not the unauthenticated endpoints as described in the HTTP Headers section https://consumerdatastandardsaustralia.github.io/standards/index.html#http-headers) In the resource endpoint descriptions, we have "Optional" in the required column (see https://consumerdatastandardsaustralia.github.io/standards/index.html#get-accounts). This is a documentation error and it should read "Mandatory". This issue will be fixed in the next version of the standards. Question: Are data holders expected to verify the presence of this field and reject the call if not present? Answer: Yes Question: If yes, what is the reasoning behind this check? Answer: As stated in the HTTP Headers section this is mandatory. Therefore the verification is required by the DH to validate the interface contract with the ADR even if the DH is not actively using this value. |
| 1186 | Scheduled Payments are forward dated payments that are supposed to debit the account at some point in the future. How far back to we go to retrieve these for a given account? Do we just return forthcoming payments to the ADR? | it is at the discretion of the bank how to represent these items. Ultimately, the bank should align with how these types of payments are represented in other channels. I wouldn't expect historic scheduled payments to be returned, only active and ongoing payments the bank has scheduled. |
| 1189 | Error Handling. Will the ACCC be mandating the Error Handling CTS before February 2022, if not will the ACCC be verifying in the live ecosystem? | As per the Participant Conformance Approach the ACCC will allocate participants the most relevant test plan for their obligation date. In regards to February 2022 obligations the most relevant CTS test plan is v3.4 The ACCC does not intend to mandate v3.4 for active participants although v3.4 is available for participants should they wish to confirm usage of standardised error codes in preparation for February 2022. Please do not hesitate to reach out and discuss with your ACCC contact via [email protected] Note - as per the Participant Conformance Approach under certain circumstances, the Registrar may mandate active participants to retest their solution through the CTS. The Registrar will confirm the test plan to be completed. As with all mandatory standards and CDR obligations, the expectation is that all participants comply. Any non-compliance would be considered in-line with the ACCC/OAIC Compliance and Enforcement Policy for the Consumer Data Right. |
Useful Links
View a number of informative and useful links in the Consumer Data Standards Implementation Guide on Information Links.