-
Notifications
You must be signed in to change notification settings - Fork 56
ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes (3rd of September 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: 785383900@csiro.webex.com
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.
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.
| Type | Topic | Update |
|---|---|---|
| Maintenance | Banking Maintenance Iteration 04 |
Link to Summary Link to Board of changes |
| Maintenance | Retrospective held 2nd of September | Link to board here |
| Maintenance | 5th Maintenance Iteration is planned to commence on the 16th of September 2020 | Updates and invitations will be notified to the broader CDR Groups later |
| Standards | Version 1.4.0 Approved! | Approved list of changes is located here |
| Event - Workshop | DSB - Amending Consent Workshop 8th of September 2020 2:00PM AEST Start Time |
Link to register is here |
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: On-boarding information timeline
Description: Planned release of on-boarding information to CDR participants
Presented by David Franzmann (ACCC Register Team)
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:
| Ticket # | Question | Answer |
|---|---|---|
| - | confirm there is no requirement to share grandfathered products as part of product reference data. | Answer can be found here CDR Support Portal |
| - | Can you please confirm if there will be any penalties for incorrect product reference data at launch? Just conscious from the Data Quality workshop there were numerous interpretations of the data requirements and that we may have to make corrections to ensure data is consistent between DHs, aligned to intention of the standards and does not present a DHs products in an noncompetitive light. I am also wanting to confirm if there are reporting requirements if data needs to be corrected? And if so, what are the requirements around this? |
The ACCC notes that CDR rule 1.12 states that a data holder must provide a product data request service, and that this is a civil penalty provision. The dates that data sharing obligations commence for phase 1, 2 and 3 product data are indicated in the commencement table at Schedule 3, clause 6.6 of the CDR Rules. The ACCC’s approach to compliance and enforcement is underpinned by the objective of ensuring that consumers can trust the security and integrity of the CDR regime. We use a risk-based approach to monitoring and assessing compliance matters and taking enforcement action. In considering whether to take action, we will have regard to a range of factors set out in our joint [CDR Compliance and Enforcement Policy](https://www.accc.gov.au/system/files/CDR - CE - Joint ACCC and OAIC compliance and enforcement policy - 8 May 2020.pdf), including whether the conduct was deliberate or repeated, and the likelihood that the conduct will result in significant detriment to consumers and the integrity of the CDR regime. The CDR is a significant, economy wide reform and the ACCC recognises that there may be a period of transition for CDR participants to ensure their systems and processes fully meet their obligations under the CDR regulatory framework. The ACCC will monitor the situation closely and take action as appropriate. Any changes to product reference data can be reported to us for monitoring purposes at cdr.gov.au/contact-us. |
| 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).. | - |
| 97 |
In the CX Guidelines for the Dataholder consent management dashboard, there is a requirement to indicate the date when data was first exposed by (relevant section below). This information is presented at a data cluster level. For the situation where information in a data cluster has not yet been shared, what is the recommended approach for the dashboard. Should this section be removed or should it be altered to indicate that data in this cluster has not yet been shared? CDR Rule 1. For subsection 56EM(1) of the Act, a data holder that discloses CDR data to an accredited person as a result of a consumer data request must, as soon as practicable, update each consumer dashboard that relates to the request to indicate: (a) what CDR data was disclosed; and (b) when the CDR data was disclosed*; and (c) the accredited data recipient. *For ongoing data sharing: Data holders should include the date range between which CDR data will be disclosed (dates of initial and final disclosure). For single or ‘once-off’ disclosure: Data holders should include the date on which the CDR data was disclosed (date of initial disclosure). |
- |
| 95 |
In the BankingLoanAccount schema (https://consumerdatastandardsaustralia.github.io/standards/#tocSbankingloanaccount) can you please clarify what is expected in the following property: originalLoanAmount - As there are multiple types of loan products, what is considered to be the original loan value? The approved amount, draw down amount, or something else? |
Answer can be found here CDR Support Portal |
| 94 |
|
Answer can be found here CDR Support Portal |
| 93 |
We are looking at the Direct Debit API. My current understanding is that to identify a Direct Debit authorisation, we will need to review past transactions on an account and identify those which relate to a Direct Debit transfer. My question is how far back in the history of transactions do you expect us to scan for Direct Debit transactions? Or do you imagine there will be another way of identifying Direct Debit authorisations? |
Answer can be found here CDR Support Portal |
| 92 |
Get transactions for account: For any other relevant ADI and initial data holders for non-primary brands, the compliance date for phase 1 products is 1st July 2021. Please confirm that pending transactions such as card authorisations are also due by this date. If the answer is yes, then please confirm pending cards authorisations should be marked with a status of Pending whilst settled card authorisations should be marked with a status of Posted. |
Answer can be found here CDR Support Portal |
| 91 | Is there a timeline for (banking) data holder's direct request service standards? | - |
| 90 | Is there a cost to apply for accreditation as a data recipient? | Answer can be found here CDR Support Portal |
| 89 | The Wednesday email from the ACCC states (under PRD clarification – guidance for data holders) that “The first reporting period for those data holders that choose to share PRD prior to 1 October 2020 will be from the date the data holder starts sharing PRD to 31 December 2020”. We found this oddly worded in that it solely referred to data holders that choose to share prior to 1 October – is it not also true that those DHs or DH brands that choose to share PRD on or after 1 October 2020, but prior to the end of the calendar year will be required to report for that period? Please confirm. | Answer can be found here: CDR Support Portal |
| 85 | Further to the RG165 question, how are bank to bank/third parties complaints are meant to be managed under RG165? | Answer can be found here CDR Support Portal |
| 84 | We have a query regarding versioning related to ‘Get Products’ and ‘Get Products Detail’ API. We have already developed the Version1 (v1) and we notice the current version is v3. https://consumerdatastandardsaustralia.github.io/standards/#get-products
|
- |
| 81 | Is there a timeline associated with “outsourced service providers“ (OSP)? | - |
| 80 | We are unable to add/ remove users from the portal. Is this a bug or is the functionality unavailable at the moment? | Under investigation by the CDR.gov.au Team |
| 78 |
In the Joint Account guidance document, scenario 5, Mary is able to ‘revoke’ an account on a consent that she did not create. We are concerned by this advice - we do not see this as a valid use case. We only conceive that the party that creates the consent can manage the consent. It is highly problematic from a security and implementation perspective for us to permit Mary to manage a consent that she did not create. We also see it as unnecessary when the appropriate mechanism will already exist via the JAMs election – ie if Mary does not want data shared on the account then she is able to control this by electing that it not be available for sharing (thereby ensuring data is not shared on the account from that point onwards). We only anticipate that the dashboard for Mary is equivalent to the extent that it shows the consent with accounts of which she is the owner and the history of data collection on those accounts (ie read only). We request a review of this use case and attendant guidance. We are seeking confirmation that this is not actually a requirement and that it is reasonable to only permit the user who created the consent to manage the consent itself. |
JAH2 (Mary) is not able to make amendments to JAH1’s (John’s) consent with an ADR, however JAH2 may revoke authorisations that relate to a joint account (see clause 4.2(1)(a)(iii) of Schedule 3). Revoking an authorisation on a joint account results in data on the joint account no longer being shared, but otherwise does not disrupt consents or authorisations in place. The joint account policy position has previously been subject to a number of consultation processes, see for example, the Rules Framework. The ACCC considers the ability to remove an election and an authorisation serve distinct purposes, and provide account holders with appropriate control over their CDR data. Where a joint account holder removes a joint account election, sharing of that joint account with all ADRs must cease. However, removing an authorisation allows JAH2 (Mary) to have more granular control, and cease sharing with only a particular ADR, should they wish to do so. |
| 71 |
When you have a moment, would you be able to please share the process for registering as a data holder? We are seeking clarity on the process to add our organisation as a Data Holder to this page: https://www.cdr.gov.au/find-a-provider |
Taken on notice |
| 70 |
As an ADR, we have sought consent from our customer to collect data from a Data Holder for a purpose, for example, "to provide accounting and taxation services.". The consumer has given consent for all data scopes for 12 months, and the Data Holder is honouring that consent, i.e. they had no reason to reject consent. The consumer is utilising our ADR solution without issue or compliant to undertake their bookkeeping requirements. Our solution is cloud-based, and the consumer wishes to get assistance from qualified experts like an accountant, tax agent and auditor to meet quarterly GST reporting requirement, annual income tax return and audited financial statements. These experts are external parties directly contracted by the consumer to perform functions, and these experts have the proper professional qualifications (with associated insurance, indemnities, etc.). These experts are given a login to our cloud-based solution by the consumer, this login allows them access to all data within our solution. As the ADR we allow our users to provide logins to any party they deem necessary. Question 1: As an ADR does the ACCC/DSB, believe we are in breach of any CDR rules by allowing our customers the ability to give access to adequately qualified professionals? Question 2: Further to the above question does the ACCC/DSB believe we, the ADR is in breach of any CDR rules if these experts use derived CDR data from our solution in order to undertake tasks which are included in the purpose of consent for example lodge a BAS, prepare an Income Tax Return, prepare a set of Financial Accounts, provide those financial accounts to the Bank? (because that may be a lending requirement of the Bank) We ask these questions because as an ADR, we are not allowed to share CDR data with a non-accredited party. However, we have not shared the data; rather, the consumer has allowed other parties access to the data and its derivations utilising our solution. Questions 3 & 4: Does the answer to question 1 & 2 change if these experts utilise their own software tools? For example, an accountant uses a separate solution (not an ADR) to prepare a properly formatted set of financial statements in accordance with the Australian Accounting Standards. The accountant sourced their primary data from our (ADR) solution (this may have been done by manual data input, downloading summarised data or an electronic connection). |
Taken on notice |
| 69 |
We are interested in the scenario where there is a valid consent with three associated accounts. If there is a reason not to disclose data relating to one of those accounts (as per 4.7) and data is requested for all three accounts we will still return data on an ADR request for data relating to the three accounts (for the other two accounts). The API response code will be a 200 (ie success). Is this request to be considered as a refusal as per reporting form section 4.1? In the same scenario as above, but with a reasons not to disclose on two of the three accounts and each a different reason, please confirm that this constitutes a count of two times we have refused to disclose data as per 4.1 (one for each reason) even though the overall request is met with a success response? |
Taken on notice |
| 68 | #296 CX Stream: Use of ADR name and logo in CX: Where the CX designs refer to an ADR name and logo should this be ADR name/logo or where provided - Brand or Software product? The CX should be consistent from consent through to authorisation establishment and management #297 Rules Account Owners added after authorisation. For accounts (typically businesses) an account owner can be added after an account has been opened. If a data sharing consent has been established when only one owner was on the account and subsequently an additional owner was added does the data holder need to stop sharing the data on that account (Phase 1 only single account holder) or pause sharing until the second holder has provided authorisation (Phase 2) If a third owner is added should disclosure of that account then be stopped and the account become ineligible to share. Additionally – Im sure this has been raised before but I could find the status?? The privacy safeguards require Dataholders to provide customers the ability to have their data resent / qualified following a data correction. Is there a mechanism being developed in the standards to support this requirement? |
3rd Question Taken on notice |
| 65 | Are there any Data Sovereignty requirements for a CDR solution developed by a FinTech on behalf of a Data Holder to be hosted in Australian Data Centres (either Cloud Provider or Hosted Solution)? There doesn't appear to be any mention of this in the available CDR specifications. |
Thank you for your question. There are currently no requirements in the CDR system for CDR data to be stored in Australian data centres. Where the entity is an accredited data recipient, they must not disclose CDR data to a recipient located overseas unless one of the exceptions in Privacy Safeguard 8 applies. We provide further guidance on these exceptions in Chapter 8 of the OAIC’s CDR Privacy Safeguard Guidelines. In addition, where an accredited data recipient proposes to store CDR data outside of Australia or an external territory, it must specify the countries where it proposes to store the data in its CDR policy (due to the requirements in Privacy Safeguard 1 and CDR Rule 7.2(7)). We provide further information on these requirements in the OAIC’s Guide to developing a CDR policy. |
- TBA
| # | Question | Answer/ Action |
|---|---|---|
| # | ||
| # | ||
| # | ||
| # | ||
| # | ||
| # | ||
| # |
Other business
- TBA
- TBA
- TBA