ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 2nd of September 2021 - ConsumerDataStandardsAustralia/standards GitHub Wiki

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: [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.11.0 Published Link to change log here
Standards Version 1.11.1 Drafted Standard-staging Version 1.11.1 Change log for Version 1.11.1
Maintenance 8th Maintenance Iteration Commenced Agenda from the 11th of August 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 18th of August 2021 View in browser here
DSB Newsletter 27th of August 2021 View in browser here
Consultation Decision Proposal 190 - Candidate Generic Tariff End Point Link to consultation
Consultation Decision Proposal 193 - Energy Non-functional Requirements Link to consultation
Consultation Decision Proposal 194 - Candidate NMI Standing Data End Points Link to consultation
Consultation Decision Proposal 195 - Candidate Usage End Points Link to consultation
Consultation Decision Proposal 196 - Candidate DER End Points Link to consultation
Consultation Decision Proposal 200 - Action Initiation Framework Link to consultation
Consultation Normative Standards Review (2021) Link to consultation
Consultation Decision Proposal 206 - Register Standards Link to consultation
Consultation Decision Proposal 208 - Binding NFRs Link to consultation

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 Jonathon Ingle
DSB CX Standards Michael Palmyre
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
920 Following the answers provided for https://cdr-support.zendesk.com/hc/en-us/articles/360003966116-Joint-account-holder-scenarios-follow-up-questions, we have some more follow up questions as an ADR. For an on-going consent authorisation, how we will be notified by the Data Holder when the 'other' joint account holder indicates their disclosure option only 5 days after the request was made (as an e.g.). From an ADR point of view, only the non-joint accounts of the primary account holder will be shared at the time of consent, and the joint account will only be shared once the 'other' account holder has indicated their disclosure option. Will the DH be sending a push notification when they get the green light from the other account holder? If yes, has it been published? Many thanks in advance. There are a few things this query may relate to based on my reading: The opt-in model specified in the v2 rules, where the 'other' joint account holder (let's call them 'AHB') has to agree to enable data sharing before it can be shared The optional 'co-approval' method in the v2 and proposed v3 rules, where 'AHB' has to agree to share data each time it is shared If you are referring to point (1) above, then the 'single consent' model proposed in the draft v3 rules makes this redundant as joint account sharing is 'on' by default and 'AHB' doesn't have to agree to enable data sharing before it can be shared. Whether or not the v3 rules will be put into effect is yet to be decided by the Minister. In any event, there is no technical mechanism or requirement where the DH notifies the ADR when 'AHB' approves sharing in point (1) or (2). The possibility of introducing something to this effect was consulted on in the Design Paper on the single consent model in relation to enhancing communication between DHs and ADRs. The submissions indicated support for this concept, however it is considered to be a lower priority to other items - particularly as 'co-approval' is optional for DHs. If the organisation you represent supports the introduction and prioritisation of this item then you are welcome to raise it as a standards maintenance issue here: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues
982 Part 2 We are still trying to understand this definition and how to apply to the different scenarios we have in the Bank. Our scheduled payments are always processed at the end/last day of the interval if there is no specific day for the payment. Please can you help clarify/confirm this based on the below examples? If 'interval' = P3M, no specific day to happen, then 'dayInInterval' = P90D? (based on processing the payment always on the last day of the interval) If 'interval' = P3M, specific day is 10 of the month, then 'dayInInterval' = ?? (Does it need to be calculated based on the first execution date?) Question: If 'interval' = P3M, no specific day to happen, then 'dayInInterval' = P90D? (based on processing the payment always on the last day of the interval) Answer: That is correct **Question: **If 'interval' = P3M, specific day is 10 of the month, then 'dayInInterval' = ?? (Does it need to be calculated based on the first execution date?) Answer: If the payment is made on the 10th day once every 3 months then the 'dayInInterval' is P10D. If the payment is instead made on the 10th day of every month, then the 'interval' needs to be P1M and the 'dayInInterval' is P10D. Further examples are available here: https://cdr-support.zendesk.com/hc/en-us/articles/900004748903-Scheduled-Payment-Recurrence-and-intervals
994 As per CDR documentation, following are the recommeded caching timings API Type Period GetDataRecipientsStatus Public 2-5 minutes GetSoftwareProductsStatus Public 2-5 minutes GetDataRecipients (statuses) Public 2-5 minutes GetDataRecipients (other data) Public 6 hours GetDataHolderBrands Private 6 hours SoftwareProduct and DataRecipient status can be retrieved through respective API endpoints (GetSoftwareProductsStatus and GetDataRecipientsStatus). If a data holder has scheduled status retrival through these two endpoints, do they need to schedule GetDataRecipients for every 2 minutes? Or GetDataRecipients can be scheduled for every 6 hours to retrieve all information of DataRecipient. Also our assumption is - the status of an Accredited Data Recipient Brand does not impact Data Holder responsibilities due to the cascade rules. So Data Holder does not require to retrieve brand status in every 2 minutes interval (as this will be covered through GetDataRecipientsStatus and (GetSoftwareProductsStatus). - Please confirm GetDataRecipients is optimised for presentation data recipient and associated information on the Data Holder dashboard. This API should be called on a periodic basis to keep the presented dashboard up to date. Slow moving data is expected to change infrequently and therefore a 6 hour poll frequency has been recommended. Statuses however need to be reacted to quickly. Your data holder responsibilities are tied to the status endpoints which need to be called frequently enough to allow your platform to react to change within 5 minutes. This is why a range from 2 - 5 minutes has been recommended. Your assumption about data holder brands is correct. The cascade rules means that you can infer your responsibilities from the Software Product Statuses.
1005 As a Data Holder, we are working through "Amending Consents". We would like some clarity or guidance around "CDR Receipts". Q: Is there a need to provide this to our customers or if it is just for the Data Recipient? (If so, does it have to be in a separate way eg. email or can it be information displayed on the dashboard) Further to this query, I would also like to confirm if the “send this sharing arrangement to your email” feature displayed in the wire example for Dashboards is a must? It appears to have the same purpose as a CDR receipt? Question: Is there a need to provide this to our customers or if it is just for the Data Recipient? (If so, does it have to be in a separate way eg. email or can it be information displayed on the dashboard) Response: Only ADRs are required to provide a CDR Receipt, however we recommend DHs also provide a CDR Receipt as good practice. DHs are doing this today via email, including major banks. Question: I would also like to confirm if the “send this sharing arrangement to your email” feature displayed in the wire example for Dashboards is a must? It appears to have the same purpose as a CDR receipt? Response: Noting that CDR Receipts are optional for DHs, the 'send this...' functionality is recommended as a way for a consumer to easily access an up to date record of their sharing arrangement. For ADRs, CDR Receipts may be included in the dashboard but must be given in writing other than through the dashboard. Importantly, the details contained in a CDR Receipt reflect the information displayed on the dashboard and the information presented to the consumer when obtaining the consent. In this sense, the CDR Receipt requirements provide a point in time record of the details of the sharing arrangement on the dashboard and the original consent request.
1006 as a Data Holder, I'm working through the Nov 21 obligations for "Amending Consent" and wanted some clarification regarding the below standards in the Future Dated Obligations. "Where account selection applies, Data Holders MUST pre-select accounts that were associated with the previous authorisation provided these accounts remain eligible and available to share. Data Holders MAY allow these accounts to be amended, and MAY provide information regarding the pre-selection of accounts." Is it correct to interpret the statement "Data Holders MAY allow these accounts to be amended" as having the ability to add and remove accounts? and for statement "MAY provide information regarding the pre-selection of accounts" is it just referring to data such as data clusters, sharing period etc? Question: Is it correct to interpret the statement "Data Holders MAY allow these accounts to be amended" as having the ability to add and remove accounts? Answer: Yes that is correct. Question: for statement "MAY provide information regarding the pre-selection of accounts" is it just referring to data such as data clusters, sharing period etc? Answer: This was included to allow DHs to explain why the accounts are pre-selected. E.g. 'These are accounts you were sharing as part of the existing authorisation. You can choose to add or remove accounts by selecting or deselecting the checkboxes.'
1010 In the DD we have 3 endpoints, do we need to consider optional fields while providing response? i.e lastDebitDateTime & lastDebitAmount because these data needs to capture from Transaction store. yes you do. If you have the data or can infer the data from the transactions then it needs to be provided. It is optional for the purposes that the two values may not be inferred for all direct debits.
1013 As a Data Holder, for the amending consent requirements, I would like to confirm whether or not we need to cater for scenarios where a CDR consumer wishes to "go back" a page when they have finished account selection? ie. in a situation where CDR consumer changes their mind or wrongly selects an account and they wish to return to account selection step. We are seeking guidance to determine if there is a CX standard to follow regarding this. Both the authorisation to disclose and amending authorisation flows use the prescribed CDR authentication model. In the context of a mobile app, we have relied on the fact that the navigation bar is persistent (see attached). No requirement exists for DHs in relation to this functionality, but the expectation would be for DHs to provide consumers with the ability to 'go back' where possible and regardless of the device or channel. This should reflect the functionality available to a consumer in their existing digital experiences with the DH. If you'd like to see the CX Standards updated to clarify this point we welcome you to raise a change request on the maintenance page: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues
1016 Hello, as a Data Holder, we are working through the Dashboard requirements and have a couple of questions. 1. The guidelines & rules state we need legal entity names and verification link to CDR website but on the wires, there is reference to the actual ADR accreditation number. Is this optional to provide on the dashboard? 2. For the "sharing period" copy such as "sharing for 24 hrs" and "sharing for 12 months" is it acceptable to just display a start and end date in the format of DD/MM/YY - DD/MM/YY? Question: The guidelines & rules state we need legal entity names and verification link to CDR website but on the wires, there is reference to the actual ADR accreditation number. Is this optional to provide on the dashboard? Response: The rules require DHs to refer to the ADR for various purposes, but neither the rules nor standards prescribe exactly how the ADR should be referenced (e.g. their brand name, legal entity etc.). It is optional to list an ADR's accreditation number, but we have recommended that it be surfaced to facilitate accreditation verification on https://www.cdr.gov.au/find-a-provider through a hyperlink that takes the consumer to the provider entry, noting that multiple brands and entities could operate under a single accreditation number and it is the legal entity, not the brand, who is 'accredited'. The ADR representation issue in NP207 will explore which, if any, additional ADR-related fields should be displayed on DH dashboards, such as the brand name, software product name, legal entity name, accreditation number, and/or any new fields. Any proposed standards and compliance dates will be subject to consultation. This issue is considered to be a lower priority than other items that will be consulted on in Q3/4 2021. Question: For the "sharing period" copy such as "sharing for 24 hrs" and "sharing for 12 months" is it acceptable to just display a start and end date in the format of DD/MM/YY - DD/MM/YY? Response: The rules and standards do not prescribe the format, so this is at the DH's discretion.
1022 It would be great if you could provide some guidance from the OAIC for us about what the expectations are in regards to Privacy Safeguard 13 - specifically in the event that we determine that the appropriate action is to provide a qualifying statement with the data and to attach an electronic link to the digital record of the data. The data standards do not allow for us to attach qualifying statements with any data that we provide, nor to attach electronic links to digital records. So to whom is this qualifying statement meant to be provided - is it to the consumer themselves? And if not, what is the mechanism for providing this? I note that this question has been raised in the following FAQ, but the answer to the question relates to Privacy Safeguard 11, not 13. https://cdr-support.zendesk.com/hc/en-us/articles/900005132003-Correcting-data-for-data-recipients The OAIC have provided additional guidance with an update to the article: https://cdr-support.zendesk.com/hc/en-us/articles/900005132003 The update is in green at the bottom; with the date just to assist those reading.
1025 The questions below relate to the fields: agentFirstName, agentLastName and agentRole. Across the 3 fields, the ‘agent’ is identified as the individual providing the authorisation and under the CDR rules, this would be a Nominated Representative appointed by the organisation. 1. Nominated representative(s) appointed by the organisation could change over time as individuals leave/join the organisation. We would like to clarify that the agentFirstName and LastName refer to the individual that provided the authorisation at the time of creation. If later the individual leaves the organisation or is no longer a nominated representative, it is not expected to be updated (for long-live consent). Is this correct? 2. For agentRole, we would like to clarify whether “Nominated Representative” is expected to be returned always, or is the expected behaviour to return the position held by the individual whom is acting in the capacity as the nominated representative at the time of granting the consent (eg “Secretary”)? There has been previous guidance that the transfer of a consent to another individual is at the discretion of the data holder and needs to be done with care. This acknowledges the fact that the authenticated user at the ADR may not be a business account and may be linked to the nominated representative's personal details. The language in the description for these fields does not assume that data holders will do this. It is specifically intended to clarify that the agent fields apply to an individual associated with the business and with the consent, not with a pre-defined role for the business such as an administrative account. It should not be understood to indicate the person originally establishing the consent even if the data holder allows for consent transfer. With that stated, as with the other resource APIs, the intent is to represent the data at the time of invocation and not the time of consent establishment. If the data holder elects to move the consent to a different nominated representative this should be reflected in invocations that occur after this change.
1026 Background Information on ZenDesk regarding concurrent consent requirements says that ‘the requirements were introduced into the Consumer Data Standards (CDS) from November 1st, 2020.’ (Link: https://cdr-support.zendesk.com/hc/en-us/articles/360003944055-Concurrent-consent) Question If a Data Holder solution requires an ADR to recognise separate CDR Arrangement IDs, but the ADR has not implemented this functionality, what is the recommended action by the Data Standards Body? Question Do the concurrent consent requirements introduced into the CDS last year constitute a mandatory requirement that ADRs must comply with? The ADR is not obliged to pass an existing arrangement ID when creating new consents as this is a scenario that is valid. If a new concurrent consent is to be created then a consent will be established without a pre-existing arrangement ID. An arrangement ID only needs to be passed by the ADR when an existing consent is being revoked and amended in an atomic step (such as extension or modification of consent). The ADR is obligated by the standards to implement the arrangement revocation end point defined in the information security profile so that a the data holder can notify the ADR if the consumer revokes an arrangement via the data holder's dashboard or assisted channel. In summary, the concurrent consent approach defined in the standards is made up of a variety of statements, some of which apply to the data holder and some that apply to the ADR.
1030 What are the requirements in regard to the return value for optional fields held by a data holder as an empty string? Can we return this as we hold it - i.e. an empty string or do the standard require that we return this as a null/blank? E.g. We hold merchant name/category against transactions. In some cases these values are empty strings (i.e. ""). Is it ok to return the empty string? This behaviour is defined in the payload conventions section of the standards: https://consumerdatastandardsaustralia.github.io/standards/#payload-conventions Specifically refer to the sub-headings Mandatory/Optional Fields and Empty/Null Fields for relevant statements. In summary, an empty string and a null value are not considered equivalent. An empty string indicates that the value is known and is empty (for instance, that is what a customer as actively entered). A null field indicates that the value is not held and no assumption can be made. If the data is empty simply because it is not held, and considering the merchant fields are optional. then the preference would likely be for the field to be null or absent.

Useful Links

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