-
Notifications
You must be signed in to change notification settings - Fork 56
ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes (27th 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 |
Link to Summary Link to Board of changes |
| Maintenance | Retrospective to the 4th Maintenance Iteration will be held next week | Invitation to be sent out tonight |
| 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 |
| Newsletter | Latest Update from the ACCC | Link to the newsletter |
| Standards | Version 1.4.0 Approved! | Approved list of changes is located here |
| Event - Workshop | DSB - Amending Consent Workshop | 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
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 |
|---|---|---|
| - | 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? | - |
| 90 | Is there a cost to apply for accreditation as a data recipient? | - |
| 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. | - |
| 88 | In the BankingAccount schema on the following page (https://consumerdatastandardsaustralia.github.io/standards/#tocSbankingaccount), there is property called 'productName'. Based on the provided description, can you please clarify what is expected for the model number value? As an example, would the expected value be the product name such as 'Orange Everyday' or would the value be the unique product identifier '12345' ? | In regards to the 'productName' field in the product reference data payloads, this field is designed to hold any identifier that the data holder wishes to provide for the product in any format. It is not expected to be displayable. As the option exists for a single conceptual product to be represented multiple times in the product reference data APIs (for instance a single branded term deposit may be represented once for retail customers and again for business customers), the productName is not intended to be unique. Essentially, the contents of this field is at the discretion of the data holder. |
| 87 | For the Get Transaction APIs, how far back are we expected to support for the "oldest-time" parameter? Should we honor calls that will potentially result in 1000's of transactions being returned because the "oldest-time" was set to 1995 for example? | The extent of any historic calls is limited by the CDR Legislation. It is referred to as the holding day and is the 1st of January not more than 2 years earlier than the designation instrument. For banking this is the 1st January 2017. |
| 85 | Further to the RG165 question, how are bank to bank/third parties complaints are meant to be managed under RG165? | - |
| 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
|
- |
| 83 | Some bank products may have the concept of a ‘Nominated account’ – typically a transaction account – supplied by the customer during on-boarding for an online-only savings account for example. In some cases that account would be held at another bank. The customer may also be able to manage a set of such nominated accounts. Should these accounts details be included in the ‘Payees’ API, noting that it may be a convenient way for the customer to have these details shared with another bank.Some bank products may have the concept of a ‘Nominated account’ – typically a transaction account – supplied by the customer during on-boarding for an online-only savings account for example. In some cases that account would be held at another bank. The customer may also be able to manage a set of such nominated accounts. Should these accounts details be included in the ‘Payees’ API, noting that it may be a convenient way for the customer to have these details shared with another bank. |
In regard to your question regarding nominated accounts, it certainly appears that the nominated account settings you describe would meet the criteria for a registered payee so inclusion would be warranted. If you customers would get benefit from the inclusion then that should also be a consideration. |
| 82 | We have a feature in our online banking which permits customers to upload an excel file in a specified format with payment to details (accounts and amounts). This supports payment disbursements, typically for payroll. The mechanics of the payment are that there is a single payment made from the customer’s source account (let’s call it account A) to a suspense account (let’s call it Account S) and then the disbursement payments to the specific destination accounts (let’s call them Accounts X, Y, and Z) contained in the excel file are made from the suspense account. Within the BankingScheduledPayment schema there is one object called from and also the paymentSet array. Which of the following three representations would you expect:
We would expect 2, but note that there will never be transactions corresponding to a payment from Account A to any of Accounts X, Y, or Z arising from this process. |
The API is designed to expect option 2. If the inclusion of a suspension account would be a good addition then will consider a change request to include it. |
| 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 |
| 79 | Can I also please get the answer to ticket #70 from the Implementation Call - 20th of August 2020? | Ticket replied |
| 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. |
Taken on notice |
| 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? | Requests are made Daily @ 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 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? |
Regarding Get Product API version 2 - these is no defined date for obsolescence. Other |
| 73 |
Status- is there a clear definition of Pending and posted. |
Answered on the call |
| 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 |
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 |
| 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). |
Thank you for your question about the level of detail required in a CDR Policy in relation to internal dispute resolution processes under Privacy Safeguard 1. The CDR Policy must detail each of the matters set out under CDR Rule 7.2(6) regarding the internal dispute resolution process (including specific details on where, how and when a complaint can be made, the complaint process, expected timeframes and options for redress and review). The aim of setting out each of these matters within the CDR Policy is so that it functions as a stand-alone document for consumers on how their CDR data is managed and how they can make an inquiry or complaint. While there may be other generic complaints processes in place which you may wish to refer to, the CDR Policy must still provide specific and centralised information on how you will handle complaints about CDR data. This will assist consumers in the event they think you may not have met your CDR-related obligations. There is further guidance on what is required in a CDR Policy in the OAIC’s Guide to developing a CDR policy and Chapter 1 of the Privacy Safeguard Guidelines. |
| 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? | Under the current definition of ‘CDR complaint data’ in rule 1.7, data holders are to report on complaints received from other CDR participants about their PRD-related obligations for the purposes of rule 9.4. There is currently no obligation on data holders to report under rule 9.4 on PRD-related complaints from entities that are not data holders or accredited data recipients. Having said that, it is expected that data holders reasonably manage all complaints they receive, and note that the ACCC is able to consider complaints it receives from the public, including from comparison tool providers, about PRD data and related obligations. |
- TBA
| # | Question | Answer/ Action |
|---|---|---|
| # | In version 1.4.0 of the CDS standards, In client authentication section, DR’s calling DH’s there was a change to the aud definition to be the token endpoint. It used to be the URL of the endpoint being called. This is a potential breaking change. When is this change expected to be transitioned in? | |
| # | If PRD or Consumer Data previously provided was incorrect is there an obligation to go back to the person told and correct it? | |
| # | The description of field id_token_encryption_alg_values_support has changed. There is an added sentence “Must conform to FAPI-RW and OIDD”. Could the reasoning of this be explained in more detail? Which area of FAPI-RW should we look at to confirm the values are adhered to? Likewise for OIDD I haven’t seen a section which provides an allowed list of algorithms. | Taken on notice |
| # | ||
| # | ||
| # | ||
| # |
Other business
- TBA
- TBA
- TBA