-
Notifications
You must be signed in to change notification settings - Fork 56
ACCC & DSB Data Holder Working Group Agenda & Meeting Notes (14th of May 2020)
When: Weekly every Thursday at 3pm-4.30pm AEST
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
- Introductions
- Outstanding actions
- CDR Stream updates
- Q&A
- Any other business
Meeting notes
- 5 min will be allowed for participants to join the call.
Outstanding questions
| Type | Topic | Update |
|---|---|---|
| Action | Consumer Data Right 101 Session | To register, click here |
| Question | “Regarding Accessibility Standards. In CX Standards it has been stated that CDR participants must seek to comply with the said area. Does this mean that if the participants took a reasonable steps to comply with the understanding guideline would be sufficient or all the success criteria mentioned in the understanding guidelines have to be complied with.” |
The CX Standards require that CDR participants MUST seek to have all aspects of the Consent Model comply with specifically referenced WCAG items.</p. At a minimum, all CDR participants MUST seek to comply with those items throughout the Consent Model. These standards SHOULD be assessed, tested, and refined further by accessibility consultants directly involved in implementation. The intention is for CDR participants to, at a minimum, comply with the specific WCAG items referenced in the CX Standards. However, we acknowledge that WCAG compliance may not be applicable to all aspects of the Consent Model, such as non-web experiences, and, as per WCAG conformance requirement 5, non-compliant technologies can still be part of the overall experience. We would expect participants to be able to demonstrate that they have taken reasonable steps to achieve WCAG compliance, such as evidence that accessibility testing has occurred, and/or can note why compliance is not applicable for a particular experience. The particular wording in the standards was chosen to provide a reasonable level of flexibility; to acknowledge that making the CDR accessible will be an ongoing process; and to recognise that WCAG items may not apply to all aspects of the Consent Model. |
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 - Energy & Banking
Title: Rule 9.4 reporting forms
Presenter: Danielle Lettieri, ACCC
The ACCC has now published the first version of the approved reporting form for the purposes of reporting under rule 9.4. This presentation will provide an overview of the reporting forms and will focus on the ACCC’s expectations on how data holders should complete their first reports.
Link to the Reporting Forms is located here.
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.
Currently received pre-submitted questions:
| # | Question | Answer |
|---|---|---|
| #1 |
Section 3.2 of the CDR Rules (Joint account management services) provide details about revoking accounts owner by joint account holders. How should this process happen if an individual account owner wanted to revoke 1 of 2 accounts they are sharing with the ADR: a. Does consent need to be fully withdrawn and then re-consent OR b. Can individual owners also have the capability of revoking an account? |
- |
| #2 | Page 112 of the CX Guidelines (attached UI) – please provide guidance. What is meant to happen when a person selects “Edit accounts”? |
The answer provided below is in reference to the CX Guideline outlined on page 112 of the CX Guidelines: “Data holders SHOULD show the account(s) shared as part of the data sharing arrangement. It is at the discretion of data holders to provide functionality to add/remove additional accounts from the data sharing arrangement.” Accounts are separate to consents. A consumer can choose to share data from some or all of their accounts in the authorisation flow, and - for ongoing data sharing arrangements - could later choose to remove some or all of those accounts. Removing an account from a consent would stop data from that account being shared; it would not withdraw the consent. Similarly, a consumer could add accounts to an existing consent without altering the status of the consent itself. The 'Edit accounts' function on Page 112 of the CX Guidelines is an example of how a data holder might choose to initiate this process. When the consumer selects ‘Edit accounts’, the expectation is that the consumer could then choose to add or remove accounts for that consent. Importantly, however, providing this functionality is at the discretion of data holders. |
| #3 |
Can you please confirm that Voluntary and Required Product data referred to in the CDR Rules is NOT the same as the fields shown as Mandatory and Optional in the Data Standard? i.e. all data items in the Data Standard are Required Product Data and Voluntary Product data refers to additional fields or APIs that Data Holders can decide to add if they wish. |
- |
| #4 |
Are all possible fees for a product to be included? There are many different sorts of fees, some of which are highly unlikely for the majority of consumers and could actually confuse them E.g. > Chequebooks are an option on a number of products and there could be chequebook fees applicable but only if they decide to have a chequebook> Service fees in uncommon situations e.g. Trace on Electronic Debit/Credit, printed Transaction Listing, Overseas Visa card replacement, Telegraphic Transfer. |
- |
| #5 |
Will there be any verification completed of the Product data provided by Data holders? A Data holder could portray a more attractive product by not providing details of all possible fees. If all Data Holders are not interpreting this requirement in the same way then it could be detrimental to those adhering to these requirements. |
- |
| #6 | In a previous meeting, you mentioned a facility you had developed to utilise product data already available. Could you please provide more information regarding where to find this facility and how to utilise it? | - |
| #7 | Data Standards Versioning - Is it possible to provide a marked up version of the standards when there is a version change so it is easier for users to ensure that they are aware of and have addressed all the changes? This would simplify the process. This was the case for the APRA EFS project and made addressing updates simpler and safer. | - |
| #8 | Can you please clarify whether wholesale products form part of product data. It was noted in the last meeting that they do not but this is not reflected in the minutes. | - |
| #9 | Are all the questions raised via these meetings and their answers logged in GitHub or do some remain solely in the meeting minutes? As the number of questions rises, being able to locate and be across all information provided is becoming problematic. | - |
| #10 | Under situations compliant with the rules, Data Holders can refuse API requests from ADRs. The ADR will in majority of cases be unaware a refusal is in place, and will continue to repeatedly request this data from the Data Holder, with each request being logged by the Data Holder as a refuse to disclose. This may result in very large ‘refuse to disclose’ numbers reported, in most cases proportional to ADR behaviour toward data retrieval (out of the hands of Data Holders). Is this acknowledged by the regulator and understood as a potential variance between reports. | - |
| #11 | - | |
| # | - |
- TBA
| # | Question | Answer/ Action |
|---|---|---|
| #1 | Could you please address Register Issue 106 in the QnA session | - |
| #2 | Seeking clarification on reporting section (4. Refusals to disclose). As per CDR Rules 4.7(1)(c) and CDR Rules 4.7(1)(d) ‘refuse to disclose’ and ‘refuse to ask for an authorisation’ are 2 separate concepts. CBAs position is that record keeping (CDR Rules 9.3) and reporting (CDR Rules 9.4) relate to the concept of ‘refuse to disclose’. This is further re-enforced in the reporting form guidance in relation to requests to an API “…the data holder has not disclosed CDR data in response to a request”. Seeking clarification that it is only the ‘refuse to disclose’ concept that is in scope for record keeping and reporting. | - |
| #3 | Seeking clarification on CBA’s position: during outage periods, failure to respond to API requests does not constitute a refuse to disclose. This is in relation to both planned outages, and incidents (unplanned outages). By nature these periods will have limited system capabilities and will not provide reliable instrumentation. Additionally, planned outages and incidents are measured through other data standards APIs. | - |
| #4 | May I please confirm, the rules consultation that was mentioned, is this a separate consultation for rules post July 1? and is there a posibility to include complex business accounts into the same consultation as well? | - |
| #5 | Are these reports industry agnostic? | - |
| #6 | And reporting on product data complaints | - |
| #7 | about complaints it looks more like a manual report right? | - |
| #8 |
Question on item 2.7 - We assume the reference to ‘CDR participants’ refers to other Data Holders and ADRs in the CDR eco-system. However, internal complaints handling systems and processes are developed to accommodate complaints received from customers of the bank. Is the expectation that DHs would extend existing complaints handling processes to parties other than customers? If so, This could potentially have a large impact to existing process Will there be further clarity on how CDR participants are expected to deal with complains made by other CDR participants? |
- |
| #9 | For the number of refusal, does this include DoS attacks e.g. millions of requests come through and the system blocks it due to security attack. | - |
| #10 | Are we expected to just report on this? Or do we have to help resolve these complaints? Just concerned that if they are complaining about quality or content of data, it's not set by us..... | - |
| #11 | Since 4.3 is an optional field, would it be ok if accumulations of counts in 4.3 is not equivalent to count of 4.1 | - |
| #12 | Hello there, Please can help to confirm the non-functional requirements on API requests, are there any minimum number requests need to be served for individual APIs ? | - |
| #13 | Update on last weeks meeting notes stated complaints about PRD are not required to be reported - "there is no requirement under the current version of the CDR rules for a data holder to report on" | Question taken on notice - need clear examples of what |
| #14 | What is the expectation from a PRD consumer perspective. If we are a bank and consume PRD data of other participants and receive a customer complaint around another participant's product (info about which was obtained via PRD API), which was viewed on our channel? | - |
| #15 |
The API schema specification is not available for version 2 for Get Product and Get Product Detail (the schema within the responses section doesn't take you anywhere), however they are present in version 1 though. Links are below. Can we have them added in, to indicate the changes/the schema that was applicable for version 2. Links- |
- |
| #16 | Also, what is the best way to understand the changes (or a summary of the changes) to the API standards made within each version (of the specific API), without having to go into the change log and then looking at release notes of the various versions of the CDS to determine when the specific API changed and what was changed within it. | - |
| #17 | Future dated obligations - https://consumerdatastandardsaustralia.github.io/standards/#future-dated-obligations |
|
| Would the dates mentioned here vary based on the changing timelines? And are these dates the same across all DH (majors/non-majors)? | - | |
| #18 | Will the CX Guidelines be updated to provide examples of the Consent Flow for situations where we need to secure consent from two owners for a joint account before releasing data associated with that joint account? The current Consent flow seems to only deal with retrieving a single person's consent. My understanding is that we have the option of only releasing data from a joint account if both owners of the account jointly agree. | - |
| #19 | so based on brooke response means intermediaries and joint accts etc will not have consultation started or do you mean not completed until after 1 July or rules not till issued until after 1 July | - |
| #Template | - | - |
Other business
- TBA
- TBA
- TBA