-
Notifications
You must be signed in to change notification settings - Fork 56
ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes (24th of September 2020)
CDR API Stream edited this page Sep 25, 2020
·
11 revisions
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
- 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 |
| Music | Request for intro music | Trial of YouTube Audio Library |
| FAQs | New FAQ Structure now live on CDR Support Portal | Check out the sections here |
| Community | New Community Module now enabled on CDR Support Portal | Link to CDR Support Portal here |
| Daylight Savings | First weekend of October | CDR Implementation Call move/remain at 3:00PM AEDT |
| Standards 1.5.0 | Update on crnType in Version 1.5.0 | James Bligh to provide update |
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 |
|---|---|---|
| 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 |
| 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)? |
Taken on Notice |
| 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! |
Taken on notice |
| 171 | We (As Data Holder) would consume the ACCC metadata management APIs to update our cache for ADR Status, ADR List, ADR SoftwareProductStatus. I have query that, what would be the response data from ACCC for this APIs? Example - If there is a change in a particular ADR status then, will i get the data related to that particular ADR where change occurred ? Or will i get a list of ADRs which contains the recent change as well as the old data's( which is already shared from ACCC). |
- |
| 172 | The CDR Rule 4.5: Data holder must ask eligible CDR consumer to authorise disclosure (1) This rule applies if: (a) a data holder receives a consumer data request under this Part; and (b) there is no current authorisation for the data holder to disclose the requested data to the person who made the request; and This sounds like it prohibits concurrent consent. Am I interpreting this incorrectly or is this in the pipeline to be updated.. |
- |
| 173 | Appreciate if we could get some answers to these github issues. Expectations when a consumer closes their account/relationship with an ADR Issue 313 |
- |
| 174 | If we have accounts that are singly owned but have another person as a signatory relationship to be able to transact (not a owner) on the account. Are we able to offer the ability to share this accounts data if the owner of the accounts requests? | - |
| 175 | Quick question around handling of x-v and x-min-v headers in couple of scenarios. Where x-v = a supported version, and x-min-v is sent in the request, however a blank value is sent like shown below - x-v = 2 x-min-v = What should the expected response be - 200 OK or a failure response?. If the response should be a failure response, should it be a 406 or 400 response code? We have noticed 3 out of the big 4 (and few other non majors) responding differently to this scenario, and we were hoping to clarify the correct way to handle this. Another rare scenario (however still possible I guess), where x-v or x-min = 0 or a negative integer, should the error response be 406 or 400 in this instance. If the mandatory header x-v is not present in the request at all, should the response be a 406 or a 400 in this scenario? We are under the impression that this is a 400 bad request, however would like to clarify. |
- |
| 177 | Hi – Just looking for an update on the required approach for use of ADR/brand/software product names and logos as requested through these issues. As the non-majors progress their builds it is becoming increasingly important to have direction on this to ensure consistency across the ecosystem. https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/222 https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/296 |
- |
| 178 | Do we have any metrics and other info that shows what's working well and what is not? There is no information available in the public domain. Is there a plan to publish something similar to API performance that is published by the folks in the UK? https://www.openbanking.org.uk/providers/account-providers/api-performance/ |
- |
| Ticket # | Question | Answer |
|---|---|---|
| - | This question was emailed to Consumer Data Rights Data 61 on the 12/8. I can't see it minuted on the meeting 13/8. Can I please confirm whether Data Holders will be required to put the CDR logo on the Authorise > Select Account screens? Just that the Consumer Data Standards say that this has been removed pending ACCC making the functionality available AND the CX guideline has not provided a reason why it was removed. |
Information about use of the Consumer Data Right logo was included in the ACCC’s newsletter issued on 1 September 2020. Only those who have entered into a licencing agreement with the ACCC are entitled to use the CDR Logo. The CDR logo is a registered trade mark owned by the ACCC, and the ACCC keeps a record of CDR participants who are licenced to use the logo. The CDR logo is intended to be a symbol of trust in the Consumer Data Right. It is only intended for use by accredited persons and data holders (CDR participants) and only according to the terms and conditions set by the ACCC. The ACCC encourages all CDR participants to use the CDR logo in the consent and authorisation processes offered to consumers. CDR participants are not permitted to use the logo for other purposes. The ACCC expects that in the future the Consumer Data Right Rules and Consumer Experience Standards/Guidelines may provide for additional requirements or recommendations in relation to the use of the CDR logo. The ACCC will be consulting on a draft rule for the CDR logo later this month. |
| 50 | We have a question in regards to the re-authorisation process. In the latest version of CDS and CX guidelines we couldn’t really find anything related to it (https://consumerdatastandards.gov.au/standards/latestversion/) However we found a Data61 prototype (both re-authorise via data recipient and data holder) below that was created a while ago: http://559gwh.axshare.com/#g=1&p=reauthorise_via_holder Our question: - ACCC, when re-authorisation process on the data holder side is to be delivered? - Data61, in case of a re-authorisation initiated on the data holder side, I assume that the data recipient needs to be informed about it. Do we currently have a CDR endpoint similar to the withdrawal process as part of the data holder Dashboard? Do I understand correctly when I say that this is considered as a consent update? |
The Standards and Guidelines do not currently support re-authorisation. This has been noted in the CX Standards and Guidelines since v1.0.0 last year as per the following: The CX Standards and Guidelines do not cover re-authorisation. This position reflects current CDR Rules. Further CX work on re-authorisation is encouraged to identify ways in which re-authorisation flows can be simplified without compromising the quality of consumer consent That is, re-authorisation is not currently permitted or supported in the rules, standards, or guidelines. The prototype referenced was part of early stage CX research on re-authorisation conducted last year. This explored initiation points for re-authorisation, including from the Data Holder side. The path of re-authorising solely on the Data Holder side is not being pursued for various reasons, but work is underway to consider how to support re-authorisation in general. These now outdated CX artefacts have been kept public for transparency and documentation purposes but are not to be interpreted as reflective of current rules or standards. The CX Workstream is currently testing how existing consents can be amended (see Phase 3 reports on rounds 4 and 5), including how to extend the duration of an existing consent (i.e. re-authorisation). The ACCC is concurrently considering rules to support various amending consent scenarios. |
| 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 Response: Under the Privacy Safeguards, data holders are required to provide corrected data to ADRs and qualifying statements. We are aware that further guidance and potentially data standards changes are required to better support data holders in this respect. The ACCC, OAIC and DSB are currently considering this issue. We will provide updated guidance on this issue when available. In the meantime, we would recommend that data holders ask the relevant accredited data recipient of the incorrect data to request that the consumer make a new valid request (with consent to seek to collect the corrected CDR data from the data holder). Data holders could also ask consumers to contact their ADR to facilitate this process. |
| 85 | I don’t think there has been an answer to question 8 from the page below, could you confirm if there are any more details on this?Further to the RG165 question, how are bank to bank/third parties complaints are meant to be managed under RG165? | CDR Support Portal |
| 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). | The ACCC recently released information on On-boarding, please refer to the latest CDR newsletter. Over time On-boarding updates will include more information on the CTS. When the information is available an update will be included in the CDR Newsletter. |
| 153 |
We 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. |
Answered on 17th of September - response being written up |
| 155 | 1.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. 2.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. 3.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. 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 |
| 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 |
| 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. | The rules require consumer dashboards to be provided online but do not specify the channel. There are requirements relating to ease of use and access, however, including that the dashboard be made simple and straightforward to use, and that it be no more complicated to use than the process of giving the authorisation to disclose CDR data (see rule 1.15(1)(c)). The expectation is would be for DHs to align with existing channels and experiences. For completeness, we also note an entity’s CDR policy must be readily available through each online service it ordinarily deals with CDR consumers (see rule 7.2(8)). |
| 164 | Question 1 Is there any concern or reason not to launch CDR for all 3 product phases at the one time (as a Data Holder) by July 2021 (and including joint accounts, closed accounts etc), rather than staggering as per the phasing table? I.e. any gaps or guidelines that won't yet be defined or are to be changed specifically for phase 2, 3 products, or can we rely on the standards and guidelines being relevant for all product types?" Question 2 Will there be any further CX guidelines or OAIC guidance (etc) released on the required Joint Account Management Service for Data Holders? There doesn’t seem to be much guidance available compared to consent flows and consumer dashboard? |
Q: Is there any concern or reason not to launch CDR for all 3 product phases at the one time (as a Data Holder) by July 2021 (and including joint accounts, closed accounts etc), rather than staggering as per the phasing table? I.e. any gaps or guidelines that won't yet be defined or are to be changed specifically for phase 2, 3 products, or can we rely on the standards and guidelines being relevant for all product types?" A: The standards are complete and the four major banks are already building to the full scope for November 2020 and January 2021. Personally, I would encourage deployment ahead of the ACCC schedule but that is a decision that each DH will have to answer for themselves. Q: Will there be any further CX guidelines or OAIC guidance (etc) released on the required Joint Account Management Service for Data Holders? There doesn’t seem to be much guidance available compared to consent flows and consumer dashboard? A: We are not aware of any plan for additional OAIC guidance. The DSB CX team, however, are constantly doing research and providing additional guidance and are anticipating uplift to the standards and guidelines before the end of the year. It is expected that this would include additional support for joint accounts. No firm plans have been published, however, as this work needs to be responsive to the outcome of the rules changes that the ACCC are currently considering and consulting on. |
| 165 | Could you kindly provide some answers to my examples below as to what the response would be for Interval and dayInInterval: 1. Scheduled payment is monthly, next payment date is 30/09/2020 2. Scheduled payment is daily, next payment date is 19/09/2020 3. Scheduled payment is once every 2 months, next payment date is 28/09/2020 For example one, the response I would think is correct is the following: Interval: P1M dayInInterval: P1D However in the standards it refers to the first day of the week being Monday which makes me think, the dayInInterval might be P3D?? Could you kindly provide the correct responses to the above examples and explain the reference to Monday being the first day if the week. |
Q: Could you kindly provide some answers to my examples below as to what the response would be for Interval and dayInInterval: 1. Scheduled payment is monthly, next payment date is 30/09/2020 A: This could be: Interval: P1M dayInInterval: P31D Note that for some months this would be beyond the end of the interval, however, the structure does not yet cover scenarios where the day in the interval is measured from the end of the base period. If this is problematic then we would encourage a change request to be raised. 2. Scheduled payment is daily, next payment date is 19/09/2020 A: This could be: interval: P1D dayInInterval: absent 3. Scheduled payment is once every 2 months, next payment date is 28/09/2020 A: This could be: interval: P2M dayInInterval: P28D (assuming the interval began at the start of September) Q: In the standards it refers to the first day of the week being Monday which makes me think, the dayInInterval might be P3D?? A: The reason for this scenario is when the interval is PxW representing payments on a weekly basis. In this scenario dayInInterval of P1D means weekly on a Monday. |
| 166 | In regards to BankingProductFee - do we need to provide every possible fee that could potentially be charged to an account, i.e. common fees such as account servicing fees as well as fees that only apply if an event takes place such as a portability fee which is only charged if the consumer changes the security on their home loan. Do we have to provide event based fees that may never even be charged to an account, but potentially could be? Also, how far back historically do we need to provide fees for? I.e. if a home loan settled 15 years ago and therefore the settlement fees were charged 15 years ago, do we need to provide those as well? Please advise how far back historical data for fees needs to date back to. |
Q: In regards to BankingProductFee - do we need to provide every possible fee that could potentially be charged to an account, i.e. common fees such as account servicing fees as well as fees that only apply if an event takes place such as a portability fee which is only charged if the consumer changes the security on their home loan. A: Yes Q: Do we have to provide event based fees that may never even be charged to an account, but potentially could be? A: Yes Q: Also, how far back historically do we need to provide fees for? I.e. if a home loan settled 15 years ago and therefore the settlement fees were charged 15 years ago, do we need to provide those as well? A: No. If the fee will never be charged again (for instance, an establishment fee) then it does not need to included. |
| 168 | The Get Status API specification states that "Obtain a health check status for the implementation" (Link: https://consumerdatastandardsaustralia.github.io/standards/#consumer-data-standards-common-apis). Can you please clarify what is the definition of Status and how health check status will be determined? We have an implementation span across multiple integration and component to achieve the CDR requirement. To determine status, do we need to check only the availability of the API endpoints or health check of other integrating components are also needs to be Considered. For example, if all API endpoints are up and running but consent management component is not functional, then what should be the status of the implementation? |
The "status" is the state of the CDR implementation including all APIs and Information Security components. In other words, if you cannot successfully fulfil authorisation requests, consent withdrawal or respond to one or more of the API endpoints, then the status should represent the current availability. In this case, if one API endpoint is down, it should be a PARTIAL_FAILURE. If all of the CDR implementation is down it would be UNAVAILABLE. Similarly, if there is a planned outage (as reported through Get Outages) then this would be considered SCHEDULED_OUTAGE. > Can you please clarify what is the definition of Status and how health check status will be determined? How you determine the status for your implementation will depend on your architecture choices and infrastructure. The DSB doesn't comment on the internal implementation decisions of data holders. > For example, if all API endpoints are up and running but consent management component is not functional, then what should be the status of the implementation? This would be a PARTIAL_FAILURE. |
| 169 | understanding the requirement for common API as part CDR data 61 implementation. Common API comes with 4 API. Query is regarding the Status api. The description of the status API says that "obtain a health check status for the implementation" . We have an implementation span across multiple integration and component to achieve the CDR requirement. Could you please help us to understand the status definitions. Does the status mean its system status (system up and running)? Does this includes all the integrating systems health or just the CDR Banking API hosting system? Or API status by checking the individual Banking API for its availability with some dummy data. Is there any requirement to get the status using the actual API (like /banking/accounts) or can there be an alternalte endpoint to check the status? |
The "status" is the state of the CDR implementation including all APIs and Information Security components. In other words, if you cannot successfully fulfil authorisation requests, consent withdrawal or respond to one or more of the API endpoints, then the status should represent the current availability. > The description of the status API says that "obtain a health check status for the implementation" . We have an implementation span across multiple integration and component to achieve the CDR requirement. Could you please help us to understand the status definitions. In this case, if one API endpoint is down, it should be a PARTIAL_FAILURE. If all of the CDR implementation is down it would be UNAVAILABLE. Similarly, if there is a planned outage (as reported through Get Outages) then this would be considered SCHEDULED_OUTAGE. > Does the status mean its system status (system up and running)? That is correct. > Does this includes all the integrating systems health or just the CDR Banking API hosting system? It includes any aspect of the CDR solution such that it cannot successfully respond to requests. > Is there any requirement to get the status using the actual API (like /banking/accounts) or can there be an alternalte endpoint to check the status? I don't understand the question. Get Status is an independent API endpoint. |
| 176 | With respect to rule 7.9, I think the question is, are we required to list every instance of the data disclosure or is a generic statement like the CX guidleines that states we are sharing this data, we will continue sharing it until and we last disclosed it on . We are happy to do what is required to comply here but just do not know. If we are not provided with clear guidance to the contrary we will align with the CX guidelines. | The generic statement in the CX Guidelines was developed with ACCC and OAIC to demonstrate a compliant example for rule 7.9. The intention of the example is to show, in a relatively static way, how to compliantly state (1) the first time a specific data cluster was disclosed (2) who the specific data cluster was disclosed to (3) when the DH expects (or knows) the final date of disclosure to be. The example is provided as a way to meet the rule 7.9 disclosure requirements in relation to the authorisation details (the dates of which may differ). The OAIC guidelines on PS10 should be referred to as it will be context dependent. |
- TBA
| # | Question | Answer/ Action |
|---|---|---|
| # | When will 1.5.1 be released? Will there be a documented process that includes alignment with Decision Proposals? Is this going to accelerate the resolution of the various issues raised regarding how breaking changes are evaluated? Why is incrementing the endpoint version not the default position? | |
| # | Can I ask if there is any known issue with the Comparator tool currently (or rather with some ADIs not returning a payload through the tool), more specifically to do with the big 4 bank's data specifically, as it doesn’t seem to load even with the appropriate headers chosen. Some of the non major bank product data does load though. | |
| # | In the change notes for 1.5.0 there is a change called "Updates to November consent changes - Updates the sections covering Concurrent Consent, PAR client authentication, CDR Arrangement Revocation and CDR Arrangement ID documenation based on DP135" and it is linked to the Scopes and Claims section. I am looking for some clarification on what this change is | the change in 1.5.0 for concurrent consent is described in the decsision document for Decision Proposal 135 which can be found here: https://github.com/ConsumerDataStandardsAustralia/standards/issues/135 The decision document is linked in the first line of the issue description |
| # | May I request if below query regarding joint accounts can be addressed as a part of this session. https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/323 Is the joint account authorisation, in regards to whether the joint account holders need to provide joint authorisation or they can provide individual authorisation, driven off how the account is set up on the data holder side? For example, if the account has been set up as a 2 to sign, does CDR authorisation need to honour that arrangement or can the members set up a separate arrangement for the purposes of CDR? |
|
| # | Is there any plans for the Public ACCC CDR Consumer website to show who and in what capacity financial institutions are participating in CDR for easy reference? | |
| # | Question - when a consumers consent expires - do we have any option to provide a grace period ie of 7 days | |
| # | When deleting or deidentifying the data: can we wait until the backups get deleted as per the backup policy, or do we have to dig into the backups to delete or deidentify a specific set of data? | |
| # | When consulting on Rules2.0 can the ACCC please issue the changes in mark up? | |
| # | when organisations apply for accrediation.... will there be a lead time? | |
| # | Will lthe cdr.gov.au website become the source of all information for CDR or do we still need to refer to the ACCC site? |
Other business
- TBA
- TBA
- TBA