-
Notifications
You must be signed in to change notification settings - Fork 56
ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes (20th of August 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.
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 |
Key Phase Dates Phase 1: Retrospective and Backlog Grooming - 9th July 2020 commencement. 2 weeks duration Phase 2: Consultation - 22nd July 2020 commencement. 4 weeks duration Phase 3: Approvals and Documentation - 19th August 2020 commencement. 2 week duration Please contact [email protected] for an invite to the series |
| Maintenance | Banking Maintenance Iteration 04 |
Link to Summary Link to Board of changes |
| Standards | Version 1.4.0 Approved! | Approved list of changes is located here |
| Decision Proposal - Energy | Decision Proposal 111 - Generic Tariff Data Payload | Decision Proposal 111 |
| Event - Workshop | DSB & ACCC - Data Quality Workshop 01 | Link to register is here |
| Guidance | Joint Account Guidance | Find on the CDR-Support Portal 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
No presentation this week
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 |
|---|---|---|
| 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. |
- |
| 77 | In order to for us to design a suitable solution for the get metrics endpoint we are after an indication of the frequency that the ACCC will poll it for data. Are you able to advise? | 5AM AEST |
| 76 |
I can see accreditation number defined under RegisterDataRecipient schema https://cdr-register.github.io/register/#tocSregisterdatarecipient. Noting that this is scheduled for Nov 2020. However, it's still not available via the registry endpoint https://api.int.cdr.gov.au/cdr-register/v1/banking/data-recipients. Is this an oversight? When will it be available via the registry endpoint? In the CDS standards, under End Points, Authorization End Point, the non-normative example id_tokens, values, says "values": ["urn:cds.au:cdr:3"]. Should this say cdr:2 instead? The "CommonPhoneNumber" schema has fullNumber listed as mandatory, however it relies on a combination of countryCode, areaCode, number, and extension. The type refers to section 5.1.4. of RFC3966, however countryCode (optional), areaCode (conditional), and extension (optional) may not always be present. As such, fullNumber as according to the underlying standards cannot always be provided. Should fullNumber be Conditional instead of Mandatory? Is there an indication when Get Product API version 2 is to be made obsolete? |
|
| 73 |
Status- is there a clear definition of Pending and posted. |
- |
| 72 |
We have payment instructions in core banking that are completely unrelated to payments and payees managed in our ebanking. These instructions and the ‘payees’ associated with these instructions are not visible to the customer in eBanking. There is no clear definition of payees in the rules – the only real text relating to payees is in the definition of account data on page 103. It states “details of payees stored with the account, such as those entered by the customer in a payee address book.” The payment instructions are not entered by the customer or available to the customer as part of an ‘address book.’
|
- |
| 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 |
|
| 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). |
- |
| 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? |
- |
| 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 |
| 66 | Question relates to Part 7 – Rules relating to privacy safeguards, section 7.2.1. According to this rule, we need to include details of the complaints process on the CDR policy. We are already required by RG165 to provide details of our complaints process online. Just wanted to find out whether the following details need to be spelled out on the CDR policy OR whether we can refer customers to our generic complaints process that include the details below?
Note: This subrule is a civil penalty provision (see rule 9.8). |
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. | Taken on notice |
| 61 | In respect of reporting requirements to the ACCC, the guidance for PRD-only reporting (https://www.cdr.gov.au/sites/default/files/2020-06/CDR%20-%20Reporting%20forms%20on%20product%20data-related%20obligations%20-%20Guidance%20for%20data%20holders.pdf) currently notes that the "Total number of complaints made to you by other CDR participants" uses the definition of a CDR Participant from the Act which specifically calls out Data Holders and Accredited Data Recipients. In view of the fact that the likely majority of users of the PRD APIs will be neither Data Holders nor ADRs, can you please confirm that reporting of complaints from these entities (e.g comparison web sites) is NOT required? This seems odd and I question whether this is the intent of the reporting requirement and whether a drafting amendment is needed? | - |
- TBA
| # | Question | Answer/ Action |
|---|---|---|
| # | ||
| # | ||
| # | ||
| # | ||
| # | ||
| # | ||
| # |
Other business
- TBA
- TBA
- TBA