-
Notifications
You must be signed in to change notification settings - Fork 56
ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes (17th 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
- 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 | 5th Maintenance Iteration has commenced on the 16th of September 2020 | Kick-off and Backlog can be found here |
| Decision Proposals | Decision Proposal 112 - Usage Data Payloads | Link to Decision Proposal 112 |
| Decision Proposals | Decision Proposal 114 - Account Payloads | Link to Decision Proposal 114 |
| Standards | Version 1.5.0 is now live | Link to release notes here |
| FAQs | On-boarding FAQs are now published and able to be viewed | Link to CDR Support Portal |
| Newsletter | ACCC Newsletter 16th of September 2020 | Link to Newsletter here |
| Community | New Community Module now enabled on CDR Support Portal | Link to 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 - Banking
- DSB Technical Standards - Energy & Engineering
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.
Current received pre-submitted questions:
| Ticket # | Question | Answer |
|---|---|---|
| 68 | 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? |
Please note this includes Issues 296 and 297 - Taken on notice |
| 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 |
The ACCC has released more information on On-boarding please refer to the latest ACCC CDR newsletter |
| 80 | We are unable to add/ remove users from the portal. Is this a bug or is the functionality unavailable at the moment? | User has been contacted for more information, CDR Team is waiting for response. |
| 81 | Is there a timeline associated with “outsourced service providers“ (OSP)? | The CDR Rules currently allow an Accredited Data Recipient to disclose CDR data to an OSP under a CDR outsourcing arrangement. However, the CDR Rules do not currently allow an ADR to use an OSP to collect CDR data from a data holder. The ACCC recognises the importance of rules accommodating the use of third parties to collect CDR data from data holders on behalf of ADRs and has been developing rules that authorise third parties who are accredited at the ‘unrestricted’ level to collect CDR data on behalf of another ADR. |
| 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). |
Consumer Experience Team response: If the data hasn't been disclosed then the notification doesn't need to be shown. When the data is disclosed that section can be added, and it doesn't have to be done in the way the CX Guidelines suggest - the DH can notify the consumer via the dashboard in another way. |
| 107 | If the Core Banking vendor/provider delivers Account Aggregation solution, providing technology for consent management and data capturing, does vendor have to become ADR? Where does responsibility to be compliant with CDR Rules sit: ADI or Vendor? The assumption is that ADI in this case should become ADR anyway. If third-party provides to ADR solution on the non-exclusive SaaS licence basis, which includes CDR data collection, and solution is cloud-based, should the systems and data storage sit in the ADR cloud account (AWS or Azure) or this is acceptable when solution deployed in the third-party cloud account? The service will be provided from the ADR name, and third-party delivers technology only. |
Taken on notice |
| 138 | 1) If DH do not hold country code (optional), area code (conditional), number (mandatory) in separate fields and only hold a phone number (which may or may not contain all the required splits), what is the expectation of the DH to provide in these fields? For context, some scenarios of the types of data that exist in our backend system within the same field - 0396001234, 96001234, 9600 1234, +61396001234, +61401000123, 0401000123 2) CommonPhoneNumber schema - number field (mandatory) - How does this field vary from fullNumber field. Can DH provide a phone number AS-IS in DH back-end systems without additional formatting. For context, some scenarios of the types of data that exist in our backend system within the same field - 0396001234, 96001234, 9600 1234, +61396001234, +61401000123, 0401000123 3) CommonPhoneNumber schema - fullNumber field (mandatory) - Are DH expected to provide a phone number in this field ONLY if we have the fully formatted phone number which incorporates country code, area code, number and extension? OR can DH provide a phone number such as some of the examples outlined above in this field? For context, we have numerous customer records with numbers stored without all the parts required to make it a 'fully formatted' number. |
CDR Support Article CDR Support Article CDR Support Article |
| 139 | I have a question about what is required with respect to what must be presented to the consumer in the DH dashboard relating to disclosure on a consent. The rules (1.15 (3) (f)) state: information relating to CDR data that was disclosed pursuant to the authorisation (see rule 7.9); This does not provide any detail on what “information” is required. In the CX guidelines (pg 109) there is a picture of the consumer dashboard with the “guideline” 2 stating: Data holder consumer dashboards SHOULD show details of any historical CDR data that was disclosed. The example does not actually provide much information on the data that has been disclosed under the consent, how many times, when etc: it states only when data was first disclosed. Other information relates to the consent duration and the first holder date, but not to data actually disclosed. Our question is whether it is sufficient to do as the example in the CX Guidelines has done (ie whether this example is compliant)? |
- |
| 140 | CommonSimpleAddress schema - state field (mandatory) – If DH have data quality issues for some records for this field, can DH send free text (even if country is Australia) with the value as-is or should we send empty string "" for this mandatory field in this scenario | CDR Support Portal |
| 141 | When will the decision 135 be reflected in the standards? We understand it will be in the next release. Do we have an ETA for when that update will be released? We feel it is difficult to fully understand the net impact (items added, removed or changed) of the decision until the standards reflect the decision holistically. | Version 1.5.0 |
| 142 | What is the process for communicating when a planned outage will occur and what is the 'advanced notice' timing. Where can I find this documented? | CDR Support Portal |
| 144 | We would like clarification on a field within this schema, paymentDueAmount.
|
CDR Support Portal |
| 145 | we are after some clarity around the timeline required for Get Outages of a PRD API. We note the following links for Get Status endpoints has been answered https://cdr-support.zendesk.com/hc/en-us/articles/900001656623-GetStatus-Obligation-Dates https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/239 Therefore it is our reading that Get Outages is also not required until the commencement of sharing of consumer data. |
Your interpretation of the article you referenced (provided by the ACCC) would appear to be correct. |
| 146 | We are interested in an update on availability of the conformance test suite. We would be happy with an aspirational timeline if nothing concrete is available even with the caveat that it is subject to change. In particular, we would seek to understand if when the suite is released for use if it will be complete (ie addressing all components and phases) or if the intention is to deliver it incrementally. If, for example, we had the aspiration of participating in advance of our compliance date of July 1 (for the purposes of discussion, say on May 1) and we wanted to go in with all product phases and all elements of the solution (eg Joint Accounts), is the expectation that this will be supported by the suite? We would also appreciate some kind of guidance on the elapsed time or effort to complete testing using the suite and any information on what functionality it will provide 9ie what test coverage). | - |
| 148 | When Data61 standards says ‘NA’ under the additional value does that mean it has to be blank or we can set something if we like ? | CDR Support Portal |
| 149 |
Just to confirm, DH's do not need to provide other consent channels for consumers to provide consent other than via the online consent flow described in the Consumer Experience standards and guidelines? i.e. DH's do not need to provide a channel where Frontline (branch staff for example) log in to a consent flow with their staff login and then provide consent on behalf of the consumer. Only the consumer can consent to data sharing themselves via the online consent flow. Is this assumption correct? |
The information security profile provides no mechanism for a consent that has been established in another channel to be initiated by an ADR or to be sent to the ADR if authorised. Under the current rules, the DSB understands that a separate consent process is not required. Under the current standards a separate channel would not be implementable. The answer is not the same, however, for revocation or for the Joint Account Management Service. I believe that assisted channel support for revocation is required by the rules. It would be logical (and maybe expected by customers) to provide assisted channel support for JAMS, although this is in the competitive space. |
| 150 | Hello, We plan to release an update to our current Get Product API endpoints which may result in an outage. Since the NFRs are not yet mandatory and the implementation of the Get Status and Get Outages APIs are not yet required, what is the approach to be taken with outages? Are we able to perform our release, cause an outage to our Get Products/Get Product Details APIs without notifying anyone about it? | CDR Support Portal |
| 151 |
I'm struggling to understand how the different parts of the eco-system interoperate, and cannot seem to find any documentation that gives a good overview of how things SHOULD work. The documentation appears to be very fragmented and working through this is very time consuming! The technical specifications go into good detail, and I have become very familiar with: https://consumerdatastandardsaustralia.github.io/standards and https://cdr-register.github.io/register BUT I cannot find if/where these isolated specs. are 'brought together'. Ie, as 1 of many examples that are currently confusing me; I have assumed that getDataHolder brands is expected to be called by the ADR to get a list of registered brands during the consent flow.(Although I can see what this API does, nowhere can I see any documentation confirming my assumption) I have yet to find which of the service endpoints the ADR is supposed to call to kick-start the DH authorisation flow. Is it in publicBaseUri or resourceBaseUri ? If so what piece of documentation states this. I assume that the ADR is then expected to register with each and every DH they need to get data from, but nowhere does it state when this is expected to be done. (before/after/in parralllel with user authentication) Is there any overview documentation, either simlar to the CX guidelines or as a process flow, but that shows where the interraction between the different participants is, and which API calls are to be made at each point. I feel like the documentation covers a series of separate blocks, but im having to guess how each block fits together! |
|
| 153 |
Westpac will soon need to expand our data sharing services across multiple brands and we have a number of questions in relation to the representation of these brands within the register:
We would also appreciate it if it could be confirmed whether or not the entity model published in cdr-register issue 26 (https://github.com/cdr-register/register/issues/26) is still an accurate representation. |
- |
| 154 | The ACCC has previously approved (https://www.accc.gov.au/focus-areas/consumer-data-right-cdr-0/reporting-forms-rule-94) the forms for the data holder and accredited data recipient reporting for the purposes of rule 9.4 in the consumer data right rules. Would it be possible to confirm that published reporting forms will remain unchanged for the reporting period ending in December 2020? | - |
| 155 |
For example - In the scenario where DH's CDR platform was unavailable for 10 hours on a certain day BUT were not subjected to any data requests during this time, and as a result there were no error responses provided to the ADR, would this period of time need to be considered by the DH when calculating their Availability as part of the 'Availability requirement’ |
Q: Could you please clarify what the definition of 'Large payload' tier in the Performance Requirements section? We notice that the 'Get Transaction for Account' end point is mentioned in the Low priority tier as well as the large Payload tier. Is this correct? Further clarification would be much appreciated. A: This was just clarified in v1.5.0 of the standards. If you still have an issue with v1.5.0 please let us know. Q: Could you please clarify the Performance requirements associated with the endpoints mentioned in the CDR register page (registration endpoint, Get/Put/Delete register). The current NFR - Performance Requirements standards outlined in the CDS do not cover these end points. Also, please clarify if performance need to be reported on for these end points through the Get Metrics API. Thanks. A: The CDR standards do not include NFRs for the end points specified in the Register standards with the exception of Dynamic Client Registration which is covered in both standards. Q: As part of the Availability requirements calculation, could you please clarify if Data holders need to consider the period of unavailability when they were not receiving any data requests. A: Yes |
| 156 | Can you please confirm that we should support ANZSCO v1.2 for Occupation codes? The link (http://www.abs.gov.au/ANZSCO) in the standards takes me to v1.3 of the ANZSCO codes (which is the latest version). | Version 1.5.0 of the Consumer Data Standards |
| 157 | Clarification on article: https://cdr-support.zendesk.com/hc/en-us/articles/900002708226-Valid-Consent-over-multiple-accounts | Data Standards Body are reviewing the article |
| 158 |
In reference to Availability Requirements for 'unauthenticated end points', the standards say that planned outages should be published to data recipients with at least one week lead time for normal outages.
A similar question was asked 11th June (Q&A #6) but i cant find a response to it. My apologies if I've missed it. I think this has been mentioned in discussion several times, however we need to provide confirmation of our interpretation. |
In response to your questions: We are looking for confirmation that: 1. this does not apply to the Get Products API for ADI's if they are not data holders of consumer data yet (ie non-registered ADI's) A: It does apply. As the get outages API is not required to be published, however, there is no mechanism to provide the notice. 2. that 'data recipients' in the context of non-functional requirements means an accredited data recipient A: No. For unauthenticated APIs there is no accreditation required but NFRs are still applicable. In this case data recipient just means someone validly receiving data 3. If it is applicable to non-registered ADI's, can you please provide an example of how we should publish this outage notification to data recipients. A: There is no mechanism specified for this scenario. |
| 160 | Our overdraft account works similarly to our credit card account, and I would like some clarity about the way we should return payment information. Approved overdrafts are added to a transaction account, and each month the customer is sent a statement showing a min payment amount. The payment is calculated as a % or min payment, whichever is higher. This is calculated the same way as a credit card. However, there is no interest free period, and the as the overdraft may be attached to their main account, regular credits would automatically satisfy the minimum repayment. There are be some stand alone accounts with an overdraft, receiving no regular payments. These customers would be required to make a separate payment. Can you please advise where we can show the overdraft minimum repayment so the information we are providing via API is consistent with the statement/billing information? |
For the situation you describe it would be recommended to include the "loan" object in account details with the required fields only. If this doesn't meet your need then we would recommend raising a change request on the standards maintenance site to introduce the structure you would need to represent an overdraft account |
| 161 | Can you please provide a link to the latest phasing table which shows the current release deadlines for Open Banking? Their is a FAQ on Zendesk which links to the following page: https://www.accc.gov.au/system/files/Proposed%20CDR%20rules%20-%20Phasing%20table.pdf But I am not sure that this is the latest version and think there may have been an update to the timeline. | Please find the latest Phasing Table here |
| 162 | When an institution has an internet banking solution and an app solution for online banking, is there a requirement for the consumer dashboard to be accesible on both? Normally the app is a streamlined or cut down version of internet banking for improved UX. The app will link to internet banking for more complex tasks or transactions. | - |
| 163 | I have a query with reference to https://consumerdatastandardsaustralia.github.io/standards/#traffic-thresholds For Unattended traffic during high traffic periods only best effort support is required. I am trying to understand if there is a specific meaning for best-effort support? What are the expectations here? Data Holders will naturally provide their best support always. Appreciate some clarifications here. |
A: 'best efforts' means that there are no specific NFRs specified. |
| - | Would appreciate some guidance on whether InfoSec endpoints are in scope to be reported on as part of: 1. Metrics data in Get Metrics API. If so, should all InfoSec endpoints be considered as part of the High Priority tier? (Related GitHub issue https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/299) 2. Status information in Get Status API |
- |
- TBA
| # | Question | Answer/ Action |
|---|---|---|
| # | ||
| # | ||
| # | ||
| # | ||
| # | ||
| # | ||
| # |
Other business
- TBA
- TBA
- TBA