ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes (26th of November 2020) - ConsumerDataStandardsAustralia/standards GitHub Wiki
ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes (26th of November 2020)
When: Weekly every Thursday at 3pm-4.30pm AEDT
Location: WebEx, quick dial +61262464433,785383900%23%23
Meeting Details:
Desktop or Mobile Devices
https://csiro.webex.com/csiro/j.php?MTID=m7c39ee9db5e5892ab35cd0bd7bbf94ce
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 6246 4433
- Quick Dial: +61262464433,785383900%23%23
- Other Global Numbers: https://conferencing.csiro.au/Call-in.php
- Meeting Number/Access Code: 785 383 900
Agenda
- Introductions
- Actions
- CDR Stream updates
- Q&A
- Any other business
Meeting notes
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.
Actions
| Type | Topic | Update |
|---|---|---|
| Standards | Version 1.5.1 Published | Link to change log here |
| Standards | Version 1.6.0 Drafted | Link to Project Board with proposed changeshere |
| Standards | Version 1.7.0 Proposed | Link to Project Board with proposed changeshere |
| Decision Proposal - Energy | Decision Proposal 117 - Distributed Energy Resources Payload | View the Decision Proposal 117 here |
| Decision Proposal - Energy | Decision Proposal 115 - Tailored Tariff Data Payloads | View the Decision Proposal 115 here |
| Maintenance | 5th Maintenance Iteration underway | List of scope and agenda(s) can be found here |
| DSB Newsletter | To subscribe to DSB Newsletter | Link here |
| ACCC Newsletter | To subscribe to ACCC Newsletter | Link here |
| End of Year | Winners of the survey: 10th of December 2020 (52.3%), through to the 14th of January 2021 (76.5%) | We will keep everyone updated on the plan for over the Seasonal Break |
| Events | Workshop to be announced in the next fortnight on Data ConventionsThe Data Standards Body have published a draft of PROPOSED Data Conventions We would like feedback and insight from the community | The Conventions main article can be found here: CDR Support Portal - Conventions |
| Events | DSB Data Quality Workshop 02 : Data Conventions | Register here on Eventbrite |
| Feature | Articles changed/ published in the last seven days | CDR Support Portal |
CDR Stream Updates
Provides a weekly update on the activities of each of the CDR streams and their workplaces
- ACCC Rules
- ACCC CDR Register (Technical)
- DSB CX Standards
- DSB Technical Standards - Banking
- DSB Technical Standards - Energy & Engineering
Presentation
No presentation 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.
Current received pre-submitted questions:
Answer provided
| Ticket # | Question | Answer |
|---|---|---|
| 98 | We are interested in implementing the capability to blacklist an ADR. This would be in order to protect customers and the regime in cases where an ADR is known to be behaving contrary to the ACCC rules, in advance of an ACCC response (via registry status change). Curious to know if the ACCC thinks this is in line with 4.7 (1) (b) (ii) or has any other comment/advice on the topic (ie has had discussions with other participants on this matter).. | Thanks for your query, and apologies for the delayed response. We have not incorporated ‘blacklisting’ into our rules. The following points may be useful, however. Rule 4.7(1) allows a data holder to refuse to ask for authorisation in relation to relevant CDR data, or to refuse to disclose that data. There are three cases in which a data holder can do this, namely where:it (1) considers it necessary to prevent physical or financial harm or abuse; or it has reasonable grounds to believe that disclosure of some or all of the data would adversely impact the security, integrity or stability of either (2) the Register or (3) the data holder's information and communication technology systems.We consider that if a data holder was satisfied that one or more of the three cases outlined above was persistent in relation to a request for disclosure to a particular ADR, taking account of all the circumstances, it may have grounds to refuse to ask for authorisation or to disclose for a period of time.However, it is important to note that data holders should not go beyond the provisions outlined in the rules. We therefore would not expect a data holder to consider factors beyond those set out under the rules, and we would not generally expect a data holder to pre-empt a decision from the Data Recipient Accreditor as to the status of an ADR. Additionally, a data holder’s reporting obligations may still apply in respect of the ADR’s requests, even if the data holder considers the request may be refused in accordance with the rules, and we would expect these obligations to be met. Finally, if you are concerned that a CDR participant is behaving contrary to the rules, you may wish to use the 'make a report' link at the following link: https://www.cdr.gov.au/contact-us or alternatively, email your concerns to [email protected] |
| 172 | The CDR Rule 4.5: Data holder must ask eligible CDR consumer to authorise disclosure (1) This rule applies if:(a) a data holder receives a consumer data request under this Part; and (b) there is no current authorisation for the data holder to disclose the requested data to the person who made the request; and This sounds like it prohibits concurrent consent. Am I interpreting this incorrectly or is this in the pipeline to be updated.. | CDR Support Portal Knowledge Article |
| 274 | In the Joint Account guidance document the ACCC has effectively stated that it is requred that DHs permit Joint account holders who did not create the consent to 'remove' joint accoint/s of which they are joint owners (presumably the only accounts visible to the user) from the consent. We are not planning to offer the consenting consumer and ability to modify accounts included in the consent. This in not in alignment with the only documented rule/standard relating to this function (ie 4.4) which currently states "the data holder must also provide an equivalent consumer dashboard to the other joint account holder". Further, on what basis should we see this advice as a requirement - is it not only the rules and standards which represent 'requirements'? | Thanks for your query, and apologies for the delay in getting back to you. If data is shared on a joint account, joint account holder B must be provided with an equivalent consumer dashboard (see clause 4.4 of schedule 3). As part of this dashboard, joint account holder B must be able to remove authorisations on the joint account (see rule 1.15(1)(c)(i) and clause 4.2(1)(a)(iii)). The intended outcome of joint account holder B withdrawing the authorisation on the joint account is that the joint account is removed from the sharing arrangement. This is preferred over the alternative options that are possible under the current data standards as: disrupting joint account holder A’s good or service by breaking the entire authorisation may have significant and unintended consequences not actioning joint account holder B’s intention to cease sharing data on the joint account may similarly have significant and unintended consequences.Therefore it is the ACCC’s position that data holders must support removing joint accounts from sharing arrangements when joint account holder B revokes an authorisation (i.e. this is not optional implementation, as suggested in the query). The proposed amendments to the rules seek to make this position and implementation expectations clearer. |
| 281 | Within the CX Standards Data Language Standard #2 states: "If a scenario requires it, Data Holders and Data Recipients MUST merge and amend Basic and Detailed data cluster and permission language to show that Detailed scopes include Basic data." However in the Standards within "Authorization Scopes" states: "Granting this authorisation only makes sense if the Bank Account Data scope is also authorised.". In addition the wording on endpoints only includes the Basic versions rather than stating, for example, "To perform this operation, you must be authenticated and authorised with the following scopes: bank:accounts.basic:read" rather than "To perform this operation, you must be authenticated and authorised with the following scopes: bank:accounts.basic:read or bank:accounts.detail:read". This leads to the question of whether, if a Data Recipient includes only the detailed scope what should a Holder do? Is it expected the Holder will imply, on the Data Recipients behalf, that the authorization request is for both basic and detail, effectively amending the authorization request? Alternatively, if the Data Recipient doesn't include the basic scope should it be rejected or should proceed without the Basic component? In both the implied and explicitly included cases, it is assumed that the presence of both scopes would result in the alternate CX rendering. Is this correct? | CDR Support Portal Knowledge Article |
| 289 | Can we please clarify the definition of lodgementDate on the schema in the standards document for BankTermDepositAccount. Definition is Lodgement Date of the Original Deposit.At AMP:-When a TD is first created, we have a start date (date of when the TD starts accumulating interest).When a TD is renewed and it's the same term as the original TD (the original TD continues and the original start date remains unchanged)When a TD is renewed and the terms are different, we terminate the original TD and create a new one. In this scenario, there is no relationship kept between the original TD and the new one. We will need to use the new start dateWe wanted to confirm the definition of lodgement date:-Is it the original start date ORDate of renewalIf option 1 is correct, then are you ok for us to use the original start for renewals on the same term, and the new start date for new term deposits and renewals with different terms. | CDR Support Portal Knowledge Article |
| 295 | If a consumer withdraws their authorisation directly with a DH (in writing or perhaps via phone), it isn’t specifically stated, but should the DH also reflect that withdrawal in the consumer dashboard by marking the associated consent as inactive/withdrawn. Furthermore, should the dashboard entry reflect the fact that the withdrawal occurred as a result of a manual request from the consumer? | Yes, in line with Rule 1.15, we'd expect any withdrawal/expiry of authorisation to be reflected on the consumer dashboard, whether the consumer withdraws via the dashboard or directly with the data holder. There's nothing in the rules to require the method of withdrawal to be shown on the consumer dashboard. Data Holders may wish to do this, if it's helpful for consumers, both on the dashboard and/or in any CDR Receipt they choose to provide in accordance with the CX Guidelines. Finally, the data holder must keep and maintain records of withdrawals of authorisations in accordance with Rule 9.3(1)(b). We expect this to include how the withdrawal was requested by the customer (e.g. via the dashboard, over the phone, in writing, etc). |
| 305 | Hi All - In performing a risk assessment of our DH solution our risk folks asked if it is clear who is liable for our customers' data once it has been disclosed to an ADR. I have looked through the rules and this does not appear explicit. In "General Consumer Data Right FAQs" (10 June 2020) there is the statement " The Consumer Data Right regulatory framework, which covers the Competition and Consumer Act 2010 (Cth) (the Act) and the Consumer Data Right Rules, establishes clear principles of liability. " Where are these stated? If they are not documented can the ACCC confirm that liability of data security for data correctly disclosed to ADRs based on the customer's explicit consent is with the ADR? | CDR Support Portal Knowledge Article |
| 314 | Would it be possible to provide an extract of the Act, Rules and also the CX Guidelines ‘should’ and ‘must’ criteria in a plain text list format? This would help Implementation teams more easily confirm they have met their obligations, and Compliance teams verify that fact as part of their formal assessment process. So you understand the request more easily… we have had to convert the Rules and Act into a monster 1300-line XLS with each clause separated so we can demonstrate evidence and cross-reference to screen-shots of our UI, policy docs, processes etc. It’s a massive body of work and we’ll have to re-do it as soon as the new Rules come out. We did a similar thing for the CX Guidelines which was an even bigger job as they’re really wireframes with notes so very hard to copy/paste into something that can be used as a checklist. | Michael Palmyre to walk through |
| 315 | Can you please confirm if our understanding around what information will be available at ADR end is correct: ADRs / Third party apps will not have visibility of the actual Identifier value and will only have have information about the reference identifier(s). ADRs will store the reference identifiers and this information will be used in the API calls to get CDR data from the Data Holder. Our understanding is that these reference identifiers will not be displayed to the consumers as they are meaningless. | We can confirm that these statements are correct. The caveat is that occassionally the ADRs will have the real identifiers but only if the appropriate scopes dictate this (for instance, accountId is not the real identifier for an account but the account detail payload does include real account number and BSB as payload fields). |
| 316 | Questions - see "Q" in answer column | Q: Regarding "3.1. Number of product data requests received" the guidance states - "A reference to 'requests you received' includes all requests you received, regardless of whether the request was successful or not" Should this item include requests rejected due to thresholds? A: Yes. It would appear so Q: Could we assume that requests refused due to other technical reasons (e.g. blocked by Akamai) should be excluded from items 3.1, 3.2 and 3.3 as we may not be able to classify malicious requests into one of those groups of requests? (I expect these make more sense in section 4 of that report as noted in my previous post.)A: I think that is pretty reasonableQ: I'm assuming that the Akamai 429 responses described above should be included in the Rule 9.4 form, marked as 'Refusals' for technical reasons (protecting infrastructure and customer data in general, not necessarily a specific customer.)Is that correct?A: I can't really comment on the ACCC reporting. If the ACCC haven't clarified, and considering the 9.4. report is more of a form than a payload, you may want to include both with a note and see what they say to that. Alternatively we could route this ticket to the ACCC for review if you like?Q: Related to this, should the number of 'Rejections' be added to the number of other 'Refusals' (for technical reasons) in the Rule 9.4 report?A: This would also need to be clarified by the ACCC. |
| 320 | Please advise if Consent ID is subject to ID Permanence rules | A: By Consent ID it is assumed you mean Arrangement ID. ID permanence rules apply to the creation of IDs for pre-existing entities across multiple arrangements. As Arrangement IDs explicitly identify a specific arrangement, which does not pre-exist, the ID permanence rules do make sense. The mechanism for creating an Arrangement ID is left to the Data Holder. |
| 322 | Can you please confirm localityName could also be called "suburb" or "town"? If yes, what is the purpose of this information being mandatory as opposed to the street number and street which is not? | That is correct, locality is a general term used by Australia Post to represent suburbs and town and location groups. Not all addresses have a street name (e.g. PO BOX or GPO) so the address should be comprised of the correct addressable information but would at a minimum be within a locality. For further information on the PAF see https://auspost.com.au/content/dam/auspost_corp/media/documents/australia-post-data-guide.pdf |
| 325 | Can you please confirm the purpose for Pending & Posted transaction status? Is Pending for any transaction which does not appear on the transaction history immediately (but shows as a transaction on hold?) eg. Visa transaction or a cheque deposit/withdrawal and the transaction has affected the "available balance" of the account, but not the "current balance".Does it also need to show the minute change of say an OSKO payment into the account from pending to posted?Is a Posted transaction one which is now showing on the transaction history?If so, why does this need to be defined that way, because now it would be available in transaction history? | pending is meant to represent a transaction that has been authorised where the payment has not yet been fully processed by the merchant. Both pending and posted transactions would show in the list of transactions via Get Transactions. As to the marking of specific account types as pending, this is at the discretion and interpretation of the data holder. (see https://cdr-support.zendesk.com/hc/en-us/articles/900002415783-Pending-Transactions-on-Accounts). |
| 326 | Can we please get a view of the final list of changes which are part of Iteration 5. It is a bit unclear as Iteration 5 consultation is complete now and the project has a lot of issues in Iteration Candidates and In progress sections. https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/projects/4 | These will be cleaned up in the next week. We have a few remaining issues to address that are open for consultation and then we will move all unaddressed issues into the backlog for the next iteration. I'll be posting a final list on Standards Decision issue 138 and the decision record on Standards with the final list of changes in the coming couple of weeks. |
| 327 | As a DH, we are looking at scenarios in which we need to call the arrangement endpoint of a Data Recipient to revoke an existing arrangement. Would you be able to provide us with some examples as to what the request will look like? The one provided is on the standards website caters to the request made by the DR to the DH endpoint and we wanted to work out if there were any differences when a DH calls the DR (one change would be the bearer token for authentication instead of the client assertion provided in the example) | If a customer goes to the DH dashboard and actively revokes an arrangement the DH would be expected to call the ADR Arrangement end point to communicate the revocation to the ADR so that they can invoke deletion/de-identification according to the customer's election. |
| 328 | A quick clarification on this statement: "Data Recipients MAY send authorisation requests using [PAR] if supported by the Data Holder. Request objects which contain the cdr_arrangement_id claim MUST only be sent using [PAR]. If a Data Holder does not support [PAR], a Data Recipient SHOULD NOT provide the cdr_arrangement_id claim in the request object" Question: "Request objects which contain the cdr_arrangement_id claim MUST only be sent using [PAR]."Should the DH reject the request if there is a request to the /authorize endpoint that contains the cdr_arrangement id claim? Could the ADR use the par endpoint to establish a new arrangement (no arrangement id provided) and to amend an existing consent (arrangement id provided) ? or is the expectation that the ADR will use the authorize endpoint for new arrangements and par endpoint for existing? | Q: The standards say "Request objects which contain the cdr_arrangement_id claim MUST only be sent using [PAR]." Should the DH reject the request if there is a request to the /authorize endpoint that contains the cdr_arrangement id claim? A: Yes, but that is a SHOULD not a MUSTQ: Could the ADR use the par endpoint to establish a new arrangement (no arrangement id provided) and to amend an existing consent (arrangement id provided) ? or is the expectation that the ADR will use the authorize endpoint for new arrangements and par endpoint for existing? A: The ADR will always use the authorize end point for creating or amending consent. The PAR end point is only used to supply the request object in a secure manner. It doesn't remove the need to call the authorize end point. A new arrangement can be created with or without the use of PAR. The amendment of an existing arrangement can only be done with the request object being supplied via |
| 330 | Dopes a ADR or DH arrangement revocation must be processed prior to returning 204 response to the caller? Or Does a ADR or DH arrangement revocation can be processed after returning 204 response? | The standards do not specify the order of action although it is implied that revocation will occur synchronously. If would be highly problematic if the actual revocation occurred at a later time using a batch or any other asynchronous mechanism. |
| 332 | Questions - see "Q:" in the Answer column | Q: intervalSchedule: what would this contain? Will this be right to interpret that Interval Schedule to contain schedule of payments intervals i.e reoccurrence of payment frequency e.g. weekly, fortnightly, monthly, quarterly and yearly? Please clarify? A: Yes Q: lastWeekDay: what would this contain? Will it be the last day of the final payment is due e.g. if the loan is 5 years term and taken on Monday, 10 Jan 2020 and payments are monthly then last occurrence of the specific Week Day will be Monday, 9 Jan 2025? Please clarify?A: As stated in the description of the lasWeekDay object: "Indicates that the schedule of payments is defined according to the last occurrence of a specific weekday in an interval." The lastWeekDay structure includes both the interval and the last week day to applyQ: Challenge: If the answer to the above 1 and 2 is yes as explained, the current challenge becomes that the intervalSchedule and lastWeekDay can’t coexist, its either one or the other.A: Only one of "onceOff", "intervalSchedule", "lastWeekDay" or "eventBased" should be present. See the definition of the recurrenceUType field.Q: intervals: why intervals is an Array? The System currently can’t define the different interval on the same payment schedule, in other words each payment set can’t have multiple interval set. Please clarify?A: Under consultation, some banks wanted the flexibility to have multiple intervals occurring simultaneously. For instance, a payment may occur on the first of each month and the last Thursday of each month. If any specific Data Holder doesn't need this complexity they need not use this facility.Q: interval: is the interval of payment i.e duration between payments starting with next Payment Date e.g. if the payment is weekly and first payment date is 25 Nov 2020 then interval will be 7 days and next Payment Date will be 2 Dec 2020. Please clarify. A: The nextPaymentDate field in the recurrence object is used as the baseline. Q: dayInInterval: the below definition is very confusing. Please explain with an example clearly of weekly, fortnightly, monthly, quarterly, half yearly and yearly.Quoting the definition: Uses an interval to define the ordinal day within the interval defined by the interval field on which the payment occurs. If the resulting duration is 0 days in length or larger than the number of days in the interval then the payment will occur on the last day of the interval. A duration of 1 day indicates the first day of the interval. If absent the assumed value is P1D. Formatted according to ISO 8601 Durations (excludes recurrence syntax) with components less than a day in length ignored. The first day of a week is considered to be Monday. A: This field is used to specify a specific day in an interval for the payment. For instance, a payment that always occurs on the 10th of the month would have a interval of P1M and a dayInInterval of 10 |
Response pending
| Ticket # | Question | Answer |
|---|---|---|
| 107 | Answer in progress | |
| 139 | Answer in progress | |
| 174 | Answer in progress | |
| 189 | Answer in progress | |
| 196 | Answer in progress | |
| 203 | Answer in progress | |
| 209 | Answer in progress | |
| 214 | Answer in progress | |
| 221 | Answer in progress | |
| 225 | Answer in progress | |
| 232 | Answer in progress | |
| 244 | Answer in progress | |
| 250 | Answer in progress | |
| 256 | Answer in progress | |
| 257 | Answer in progress | |
| 259 | Answer in progress | |
| 261 | Answer in progress | |
| 263 | Answer in progress | |
| 265 | Answer in progress | |
| 268 | Answer in progress | |
| 283 | Answer in progress | |
| 290 | Answer in progress | |
| 291 | Answer in progress | |
| 292 | Answer in progress | |
| 293 | Answer in progress | |
| 299 | Answer in progress | |
| 301 | Answer in progress | |
| 303 | Answer in progress | |
| 308 | Answer in progress | |
| 309 | Answer in progress | |
| 310 | Answer in progress | |
| 311 | Answer in progress | |
| 312 | Answer in progress | |
| 318 | Answer in progress | |
| 319 | Answer in progress | |
| 321 | Answer in progress | |
| 323 | Answer in progress | |
| 324 | Answer in progress | |
| 329 | Answer in progress | |
| 331 | Answer in progress | |
| 333 | Answer in progress | |
| 334 | Answer in progress |
Notes
- TBA
Question and answers
| # | Question | Answer/ Action |
|---|---|---|
Other business
- TBA
Appendices
- TBA
Next Steps
- TBA