-
Notifications
You must be signed in to change notification settings - Fork 56
ACCC & DSB Data Holder Working Group Agenda & Meeting Notes (11th of June 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.
| Type | Topic | Update |
|---|---|---|
| Decision Proposal | Banking Maintenance Iteration 03 | Decision Proposal 108 |
| Decision Proposal | Decision Proposal 109 - NMI Standing Data Payloads | Decision Proposal 109 |
| Decision Proposal | Decision Proposal 119 - Enhanced Error Handling Payload Conventions | Decision Proposal 119 |
| Workshop | DSB - Enhanced Error Handling - Online Workshop 02 - HTTP Response Codes | Event registration |
| Action | Look at a means to track Questions from Data Holder Calls | In Progress - trailing two options internally |
| Question | Is there a way that facilitates obtaining testing SSAs from the registar? | The CDR Register design provides an example SSA with associated JWK to check the signature. |
| Question | Can you explain why polling and not push / asymmetric protocol? | To keep build effort down, we are using the polling mechanism to keep things simple. As part of release management we are planning on when the asymmetric approach should be adopted |
| Question | at what time of the day, register will call metrics APIs of DH daily? | Currently looking at around 5am. All Australian time zones are on the same day at this time and outside of business hours |
| Question | We are looking to check if there are any requirements or guidelines around the handling of requests that contain authorisation scopes that are not included in an ADR's SSA, but are subsequently requested as part of a consent flow In this scenario, should the Data Holder reject the request OR instead, prompt the user for consent using previously registered scopes that match the request, ignoring the scopes that the ADR has not been registered for (saved as part of the SSA during the client registration process)? | Thank you for outlining the issue in detail. This sounds to me to be an authorisation problem not necessarily a registration problem. RFC 6749 Section 3.3 talks to this behaviour and further work is required internally to define the appropriate behaviour |
| Question |
Can you please let me know if the CX Guidelines will be updated to provide an example Consent Flow which caters for joint accounts? My understanding is that we have the option of ensuring that both owners of a joint account consent for data to be shared before we release any data from that joint account. The current example of the Consent flow only deals with retrieving a single consent, will there be some examples of how we would potentially retrieve two consents (one from each owner of the joint account) as part of the Consent flow? I’ve also heard mention of “inbound” and “outbound” flows before, and was curious if these terms were related to how we might potentially handle securing joint consents in this context. |
The CX guidelines have prioritised the requirements in the rules where: - Joint accounts are only shown in the authorisation flow if pre-elected via a joint account management service- Once this election is made, a joint account will present in the account selection step in the same way that individual accounts are presented - If the DH provides the required ‘1 to authorise’ election preference, only one joint account holder needs to authorise disclosure as part of the authorisation flow No specific CX Guidelines exist for the optional ‘2 to authorise’ election preference. The expectation has been that the approval from the other joint account owner will occur outside the authorisation flow. A CX consultation occurred on aspects of the joint account election and authorisation experience. This proposal consulted on additional requirements relating to how joints are dealt with in the authorisation flow, including the ‘2 to authorise’ preference. The proposals outlined in this paper depend on rules amendments and as such any final decision proposals – including updated CX Standards and Guidelines – will be delayed until rules consultation can occur. |
| Question |
3.3. Number of consumer data requests received from accredited persons on behalf of eligible CDR consumers Does this relates to number of customer consent requests received via the online channel? Does this include successful and unsuccessful requests? (e.g. what if the customer doesn’t get through the authentication process – should this be counted) |
Item 3.3 requires data holders to report on the number of requests for consumer data it receives from the accredited person on behalf of eligible CDR consumers. This number should include all such requests, regardless of whether the request resulted in consumer data being shared or not. However, we do not expect data holders to include in their count for item 3.3 instances of a consumer not completing the authentication or authorisation process. |
| Question | 1. A consumer, on their consent, may share payee data with a 3rd party. This involves the bank account details of persons other than themself and these others will have no idea this data is being shared. What consideration has been given to the privacy of these persons (ie the payees)? | The ACCC considers there are sufficient protections in place to protect the privacy of these persons. Rule 4.12(3) prohibits an accredited person from identifying, or compiling insights in relation to, or building a profile in relation to any identifiable person who is not the CDR consumer, unless it is for the purposes of understanding that person’s interactions with the CDR consumer and in order to deliver the requested goods or services (see rule 4.12(4)). |
| Question | Seeking clarification on reporting section (4. Refusals to disclose). As per CDR Rules 4.7(1)(c) and CDR Rules 4.7(1)(d) ‘refuse to disclose’ and ‘refuse to ask for an authorisation’ are 2 separate concepts. CBAs position is that record keeping (CDR Rules 9.3) and reporting (CDR Rules 9.4) relate to the concept of ‘refuse to disclose’. This is further re-enforced in the reporting form guidance in relation to requests to an API “…the data holder has not disclosed CDR data in response to a request”. Seeking clarification that it is only the ‘refuse to disclose’ concept that is in scope for record keeping and reporting. | Only refusals to disclose CDR data are required to be reported on under rule 9.4; refusals to ask for authorisation are not required to be reported on under rule 9.4. Similarly, in terms of record keeping requirements, rule 9.3(1)(e) only requires data holders to record instances where CDR data has not been disclosed in reliance on an exemption from the obligation to disclose CDR. This does not include a requirement to record instances of refusing to ask for authorisation. |
| Question | May I please confirm, the rules consultation that was mentioned, is this a separate consultation for rules post July 1? and is there a posibility to include complex business accounts into the same consultation as well? | The ACCC consulted on draft amendments to the CDR Rules for two weeks in April/May which related to amendments to be made to the rules before 1 July 2020. The ACCC will consult on further draft amendments to the CDR Rules to be made some time after July 2020. |
| Question | Are these reports industry agnostic? | The reporting forms are intended to be industry agnostic. |
| Question | about complaints it looks more like a manual report right? | The reporting form currently requires manual completion, but we intend to explore the possibility of further automated reporting in the future. |
| Question |
Question on item 2.7 - We assume the reference to ‘CDR participants’ refers to other Data Holders and ADRs in the CDR eco-system. However, internal complaints handling systems and processes are developed to accommodate complaints received from customers of the bank. Is the expectation that DHs would extend existing complaints handling processes to parties other than customers? If so, This could potentially have a large impact to existing process Will there be further clarity on how CDR participants are expected to deal with complains made by other CDR participants? |
Currently, the CDR rules only stipulate internal dispute resolution process requirements for handling complaints from CDR consumers, and not for other industry participants. We will continue to monitor this space to see if there is a need to make further amendments to the rules in relation to internal dispute resolution requirements. |
| Question | Are we expected to just report on this? Or do we have to help resolve these complaints? Just concerned that if they are complaining about quality or content of data, it's not set by us..... | Under rule 9.4, data holders are only required to report on complaints from other CDR participants; there are no requirements set out in the rules as to the manner in which the data holder chooses to respond to such complaints. |
| Question | Since 4.3 is an optional field, would it be ok if accumulations of counts in 4.3 is not equivalent to count of 4.1 | This would be acceptable. |
| Question | Hello there, Please can help to confirm the non-functional requirements on API requests, are there any minimum number requests need to be served for individual APIs ? | Non-functional Requirements can be found here: https://consumerdatastandardsaustralia.github.io/standards/#non-functional-requirements |
| Question | Update on last weeks meeting notes stated complaints about PRD are not required to be reported - "there is no requirement under the current version of the CDR rules for a data holder to report on" | Only PRD complaints made by other CDR participants (i.e. other data holders or ADRs) to the data holder are required to be reported on under rule 9.4. However, general consumer complaints about PRD are not required to be reported on under rule 9.4, which is consistent with the definition of ‘CDR complaint data’ in rule 1.7 of the CDR rules. |
| Question | What is the expectation from a PRD consumer perspective. If we are a bank and consume PRD data of other participants and receive a customer complaint around another participant's product (info about which was obtained via PRD API), which was viewed on our channel? | Under the current definition of ‘CDR complaint data’ in rule 1.7, there is no requirement to report on any complaints from consumers about PRD. In relation to consumer complaints, data holders are only required to report on complaints made by CDR consumers relating to CDR consumer data under rule 9.4. |
| Question | Will the CX Guidelines be updated to provide examples of the Consent Flow for situations where we need to secure consent from two owners for a joint account before releasing data associated with that joint account? The current Consent flow seems to only deal with retrieving a single person's consent. My understanding is that we have the option of only releasing data from a joint account if both owners of the account jointly agree. |
v1.3.0 covers what the rules currently require for the November timeline, based on the following items and assumptions: • A joint account has been elected via the joint account management service (JAMS) prior to appearing in the authorisation flow• Once elected, the joint account will be dealt with in the same way as individual accounts • This election will be on a ‘1 to authorise’ basis • ‘2 to authorise’ is not covered as it is optional and not considered to be a November timeline priority • JAMS are out of scope for CX and have been left to the DH space for the November timeline A CX consultation occurred on aspects of the joint account election and authorisation experience [https://github.com/ConsumerDataStandardsAustralia/standards/issues/106]. This proposal consulted on additional requirements relating to how joints are dealt with in the authorisation flow, including the ‘2 to authorise’ preference. The proposals outlined in this paper depend on rules amendments and as such any final decision proposals – including updated CX Standards and Guidelines – will be delayed until rules amendments are considered by the ACCC. These proposals intend to build on, not replace, the mandatory requirements for joint accounts as outlined in the February rules. As such, they will look to consider '2 to authorise'. The timing and content of additional CX artefacts will depend on rules considerations and consultation. |
| Question | With version 1.3 looking to remove some fields from the PRD data structure - is removal of data considered a breaking change? Is there some guidance around versioning and breaking changes. | Versioning guidance from Standards website: https://consumerdatastandardsaustralia.github.io/standards/#versioning |
| Question | so based on brooke response means intermediaries and joint accts etc will not have consultation started or do you mean not completed until after 1 July or rules not till issued until after 1 July | The ACCC will consult on further draft amendments to the CDR Rules to be made some time after July 2020. |
| Question | Hi.. we wanted to know Whether historic swagger files will be maintained in consumer data standards site ?So data holders can always use it for any reference in case of any disputes with any ADRs , or for legal or compliance references. | Change log for the standards can be found here: https://consumerdatastandardsaustralia.github.io/standards/#change-log |
| Question | is it possible to get a template of streamline accreditation application prior to registering? | Yes, sample accrediation application forms are available on this page https://www.cdr.gov.au/data-recipients ; the streamlined application is available here https://www.cdr.gov.au/sites/default/files/resources/CDR_-_Accreditation_-_Application_Form_%28Streamlined%29_-_Sample_Version_for_Website_-_Approved_-_version_for_publication.docx |
| Question |
This question is regarding the REPORTING - Copy of Rule 9.4 draft reporting forms for Data Holders and ADRs spreadsheet. We understand that we will need to report on the number of product data requests received, once we go live with Get Products and Get Product Detail APIs in July 2020. Is there any additional reporting expected for Get Products and Get Product Detail APIs? Specifically:• Do we need to report on complaints from CDR consumers (Section 2, fields 2.1-2.9)? If yes, what would be a hypothetical scenario when a CDR consumer would complain about Get Products and Get Product Detail APIs, considering both these APIs don’t expose any CDR consumer data? • Do we need to report on refusals to disclose CDR data, CDR rules and data standards relied on to refuse disclosure, number of times relied on each of those (Section 4, fields 4.1-4.3)? If yes, what would be an example of such refusal? Is ‘Too many requests by unique identifier’ security policy that is setup through a gateway such as Apigee considered a refusal to disclose CDR data that needs to be reported on? |
We do not expect a data holder to complete items 2.1-2.6 of the reporting form prior to the commencement of the data holder’s obligations relating to consumer data sharing. We do, however, expect data holders to report on the total number of complaints received from other CDR participants in relation to compliance with Part IVD of the Competition and Consumer Act 2010 (Cth), the CDR rules and the binding data standards insofar as those complaints relate to product data requests during the relevant reporting period (item 2.7 of the reporting form). Having said that, we do expect data holders to reasonably manage all complaints they receive, and note that the ACCC is able to consider complaints it receives from the public about PRD data. We expect data holders to report on refusals to disclose CDR data and the CDR rules or data standards relied on to refuse to disclose that CDR data (items 4.1-4.2 of the reporting form). Item 4.3, which requests the data holder state the number of times it has relied upon the CDR rules or standards cited in response to item 4.2, is an optional reporting item. Under rule 2.5, a data holder may refuse to disclose required product data in response to a request in circumstances (if any) set out in the data standards. Examples of such circumstances in relation to product data are: • When the number of requests the data holder is receiving is above their service level thresholds defined in the non-functional requirements section of the data standards• There is a valid security reason that prevents sharing PRD data temporarily or for requests considered as suspicious. |
| Question | This question is regarding the REPORTING - Copy of Rule 9.4 draft reporting forms for Data Holders and ADRs spreadsheet. In the fields 2.7-2.9 for both DH and ADR report forms we are asked to provide the reporting on: 2.7. Number of complaints made to you by other CDR participants in relation to compliance with Part IVD of the CCA 2.8. Number of complaints made to you by other CDR participants in relation to compliance with the CDR Rules 2.9. Number of complaints made to you by other CDR participants in relation to compliance with the data standards. Can you please clarify what exactly is the meaning of ‘other CDR participants’? Is there guidance on how we should manage the complaints process for ‘other CDR participants’? |
‘CDR participant’ is defined in the Competition and Consumer Act 2010 (Cth) (relevantly a data holder or accredited data recipient) and the reporting form adopts the same meaning. Under the current version of the CDR rules, there are no mandatory requirements for managing the complaints process for complaints received from other data holders or accredited data recipients. We will continue to monitor this space to see if there is a need to make further amendments to the rules in relation to internal dispute resolution requirements. |
| Question | Posted on: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/231 |
The ACCC and OAIC have published their joint Compliance and Enforcement policy for the Consumer Data Right. The purpose of the policy is to help consumers and CDR participants understand the approach that the ACCC and the OAIC will adopt to encourage compliance with CDR rules, legislation (including Privacy Safeguards) and Consumer Data Standards. The policy also sets out how the ACCC and OAIC will respond to breaches of the CDR regulatory framework. The policy can be found on the ACCC website. We use a risk-based approach to monitoring and assessing compliance matters and taking enforcement action. We cannot pursue all matters that come to our attention. Our role is to focus on those circumstances that will, or have the potential to, cause significant harm to the CDR regime or result in widespread consumer detriment. Interested parties should make any complaints about data accuracy or how product reference data is being shared directly to the data holder. Interested parties can also report their concerns to the ACCC and we will consider in accordance with our Compliance and Enforcement policy. Reports can be submitted to us directly at accc-cdr@accc.gov.au. |
| Question | 1. Incorrect data has been observed in Product Reference Data APIs provided by the Major Banks, including incorrect lastUpdated dates, incorrect application of bundled discounts, misleading characterisation of fees, missing fees, and non-standard API response pagination. - What processes are in place to ensure sufficient data quality standards are adhered to? - What are the respective roles of ACCC and ASIC in the regulation of this area? - What process should interested parties follow when errors are found? |
In response to Questions 1 and 2, the ACCC and OAIC have published their joint Compliance and Enforcement policy for the Consumer Data Right. The purpose of the policy is to help consumers and CDR participants understand the approach that the ACCC and the OAIC will adopt to encourage compliance with CDR rules, legislation (including Privacy Safeguards) and Consumer Data Standards. The policy also sets out how the ACCC and OAIC will respond to breaches of the CDR regulatory framework. The policy can be found on the ACCC website. We use a risk-based approach to monitoring and assessing compliance matters and taking enforcement action. We cannot pursue all matters that come to our attention. Our role is to focus on those circumstances that will, or have the potential to, cause significant harm to the CDR regime or result in widespread consumer detriment. Interested parties should make any complaints about data accuracy or how product reference data is being shared directly to the data holder. Interested parties can also report their concerns to the ACCC and we will consider in accordance with our Compliance and Enforcement policy. Reports can be submitted to us directly at accc-cdr@accc.gov.au. |
| Question | 2. The 4 Major Banks differ significantly in the way they have applied the data standards for product reference information. This is most pronounced in Residential Mortgage products, where products include a range of different price variations (eg owners vs investors, P&I vs Interest Only repayments, packaged vs non-packaged, fixed vs variable and different fixed loan terms). In every one of those types of price variation, there are at least 2 different approaches among the 4 banks and in some cases there are 4 different approaches. This will lead to significant difficulties for data users wishing to make accurate and complete product comparisons, and in some cases it will lead to an inability to compare or to users unwittingly making incorrect or misleading comparisons. - How does the ACCC propose to resolve these issues and how can interested parties assist? |
In response to Questions 1 and 2, the ACCC and OAIC have published their joint Compliance and Enforcement policy for the Consumer Data Right. The purpose of the policy is to help consumers and CDR participants understand the approach that the ACCC and the OAIC will adopt to encourage compliance with CDR rules, legislation (including Privacy Safeguards) and Consumer Data Standards. The policy also sets out how the ACCC and OAIC will respond to breaches of the CDR regulatory framework. The policy can be found on the ACCC website. We use a risk-based approach to monitoring and assessing compliance matters and taking enforcement action. We cannot pursue all matters that come to our attention. Our role is to focus on those circumstances that will, or have the potential to, cause significant harm to the CDR regime or result in widespread consumer detriment. Interested parties should make any complaints about data accuracy or how product reference data is being shared directly to the data holder. Interested parties can also report their concerns to the ACCC and we will consider in accordance with our Compliance and Enforcement policy. Reports can be submitted to us directly at accc-cdr@accc.gov.au. |
| Question | 3. Non-ADI lenders are a significant segment in the home loan and personal loan markets. Currently the standards do not require product reference data to be published by non-ADI lenders. Given that one of the stated aims of CDR was an ability to provide consumers with better product comparison, this seems to be a major oversight. - What plans does the ACCC have to expand CDR obligations to non-ADI lenders? |
Only ADIs are designated as data holders under the CDR regime in banking. However, the CDR rules turn on data sharing obligations for non-ADI accredited persons where they publicly offer a banking-like product. Therefore, a non-bank lender that is accredited will have product reference data sharing obligations, in accordance with the commencement schedule in the rules. |
| Question | Danielle confirmed first reporting period for rule 9.4 is (6/2/2020 to 30/6/2020). Please confirm in writing. | The first report for initial data holders only requires information relating to activities occurring from 6 February 2020, the commencement date of the CDR rules, to be reported. This means the first reporting period for initial data holders is 6 February-30 June 2020. However, we encourage data holders to provide information from 1 January to 30 June 2020 where possible. |
| Question | • Danielle confirmed the report 9.4 does not need to be brand specific. This does not mean DH can’t report each brand separately, but it would be permitted to report all brands under 1 report. Please confirm in writing. | Under the current version of the rules, data holders are not required to submit separate reports for each of their individual brands for the purposes of rule 9.4 reporting. However, should a data holder wish to report by each brand separately, they are welcomed to do so and we are happy to provide some further guidance on how this can be done. |
| Question | What is an election of an account? This term is used above but really isn’t explained. | Answer can be found in the Appendices from the 21st of May 2020: here |
| Question | What does point (1) in the above text actually mean? | Answer can be found in the Appendices from the 21st of May 2020: here |
| Question | What is the difference between (1)(a)(i) and (1)(a)(ii)? | Answer can be found in the Appendices from the 21st of May 2020: here |
| Question | Do both people need to agree to share data or only one? | Answer can be found in the Appendices from the 21st of May 2020: here |
| Question | Do both people need to agree for an account to be available for data sharing? | Answer can be found in the Appendices from the 21st of May 2020: here |
| Question | In one of the Thursday meetings, it was said that a response for this would be updated as the original response was misleading. Where is that response? I can’t find it listed in the meeting minutes. | Answer can be found in the Appendices from the 21st of May 2020: here |
| Question | On a previous working group call, it was said it is permissible to implement only two-to-authorise without one-to-authorise, however the minutes did not include an answer. Can we confirm once more that yes, we are allowed to implement two-to-authorise without one-to-authorise? | Answer can be found in the Appendices from the 21st of May 2020: here |
| Question | Seeking clarification on reporting section (4. Refusals to disclose). As per CDR Rules 4.7(1)(c) and CDR Rules 4.7(1)(d) ‘refuse to disclose’ and ‘refuse to ask for an authorisation’ are 2 separate concepts. CBA's position is that record keeping (CDR Rules 9.3) and reporting (CDR Rules 9.4) relate to the concept of ‘refuse to disclose’. This is further re-enforced in the reporting form guidance in relation to requests to an API “…the data holder has not disclosed CDR data in response to a request”.We are of the view that only the ‘refuse to disclose’ concept that is in scope for record keeping and reporting. Please confirm in writing. | Only refusals to disclose CDR data are required to be reported on under rule 9.4; refusals to ask for authorisation are not required to be reported on under rule 9.4. Similarly, in terms of record keeping requirements, rule 9.3(1)(e) only requires data holders to record instances where CDR data has not been disclosed in reliance on an exemption from the obligation to disclose CDR. This does not include a requirement to record instances of refusing to ask for authorisation. |
| Question | Question outlined in appendices |
The ACCC is flexible as to the format used for responding to item 2.2, as long as the complaint type name is clearly specified and the number of complaints for each complaint type is also clear in the response provided. The suggested format of listing the complaint types in separate rows in one column and the corresponding complaint number in the following column is acceptable. Item 4.2, which requires only a list of the relevant CDR rules or data standards relied upon by a data holder in refusing to disclose CDR data, is a mandatory reporting requirement under rule 9.4. However, item 4.3, which asks for more detail in the form of a breakdown of the number of times each of the relevant CDR rules or data standards was relied upon in refusing to disclose CDR data, is only an optional reporting item. This is the reason why the form currently separates these two reporting items. However, if a data holder was inclined to respond to item 4.3 in the format suggested in the example provided in the question (i.e. list of the relevant reason in one column and the corresponding number of times it was relied upon in the next column), that would be welcomed. In such a case, it is acceptable for the data holder to make a note in item 4.2 that the relevant response is covered in the response to item 4.3. |
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:
| # | Question | Answer |
|---|---|---|
| #1 |
In the rules the definition is provided: recognised external dispute resolution scheme means a dispute resolution scheme that is recognised under section 56DA of the Act. Section 56DA of the Act states (1) The Commission may, by notifiable instrument, recognise an 26 external dispute resolution scheme for the resolution of disputes: 27 (a) relating to the operation of the consumer data rules, or this 28 Part, in relation to one or more designated sectors; Has an/the external dispute resolution scheme been determined/recognised and if so where is this stated/documented? |
- |
| #2 | Is there a specification/expectation around the recency of data available in the Get Metrics API for the ‘current’ periods? (currentDay, currentMonth.) Could it be up to the nearest 2 hours, 6 hours of aggregation? |
- |
| #3 |
2. The ‘number’ specification examples show only two decimal places; is a higher resolution expected or supported for the Get Metrics ‘availability’ and ‘performance’ percentage metrics? https://consumerdatastandardsaustralia.github.io/standards/#common-field-typeshttps://consumerdatastandardsaustralia.github.io/standards/#tocSavailabilitymetrics |
- |
| #4 | Does the obligation date for Concurrent Consent apply to non-major ADIs from July 2021? | - |
| #5 | We are seeking clarification from both CX and technical standards streams on the expected behavior for "Consent Expire", as per the Data Holder Responsibilities table, when a Software Product is removed. What is the expected behavior in such a case? Are Data Holders expected to cancel the consent? Is it expected to go to sharing history on the dashboard, per standard consent withdrawal process, or is it sufficient to cease disclosure of data and cease enabling authorization? Are issued tokens to be no longer accepted? | Answer provided in Issue 251 |
| #6 | Non-functional requirements include unauthenticated endpoints. Do these requirements apply to Product Reference Data (Get Products and Get Product Detail) and does 99.5% availability requirement apply to PRD as well? There is a note in Data Standards: “The standard relating to NFRs will commence on a date specified by the Data Standards Chair. It is intended that an analysis of actual usage in a production implementation for a period of time is conducted to validate that the specific thresholds stipulated in this section are appropriate prior to this standard commencing and becoming a binding data standard under the Consumer Data Rules”. If NFR apply to PRD, when does DSB going to make them effective, and what is the probability of changes for availability requirements and performance response time for unauthenticated endpoints. | - |
| #7 |
Regarding the announcement on the CDR dates for non-major ADI’s moving out to July ’21, will the ACCC be releasing a new Phasing table to confirm obligation dates for: PRD - Phased products (1,2,3)CDR - Phased products (1,2,3) CDR – consumer type (individual, joint) CDR – account status type (open, closed) DTC – direct to consumer obligations |
- |
| #8 |
If a non-major bank chooses to make their Product Reference Data API public on their website prior to the 1st of October (PRD phase 1 obligation date). Does the reporting period start from the date when the API is made public or does the reporting period only start from the 1st of October? i.e. we launch our PRD API on our website on the 1st of July does that mean the reporting period is from the 01/07/2020 – 31/12/2020 (6 month period) |
- |
| #9 | Will an uptime SLA be published for 1. Registry 2. CA? |
- |
| #10 | Will you be publishing an operational procedure that documents how quickly an ADR/software product status is made inactive in the event of a breach? | - |
| #11 | The announcement stated that the application process is initially open to the fintech community and prospective data recipients can apply for accreditation at the Consumer Data Website. What is the effective date for its opening and URL. | The CDR Participant Portal, available through the CDR website, launched on Monday 25 May. |
| #12 | Who can initially apply. It continues to be stated in the Accreditation Guidelines that Unrestricted is currently the only level of accreditation. So in effect ADIs ??. Additional levels of accreditation are still to be finalised and approved. Or may other Fintechs apply yet? . | Any business is able to apply for accreditation, provided that they meet the criteria for accreditation as stated in the CDR Rules. Currently the CDR Rules only provide for the accreditation at the unrestricted level. Further information about accreditation is available in our accreditation guidelines. ADIs have access to a the streamlined accreditation process. |
| #13 | May a Fintech Open Banking Solution provider or hosting service provider apply yet? Appreciating the details on Intermediaries and Third Parties are still being finalised. | Any business is able to apply for accreditation, provided that they meet the criteria for accreditation as stated in the CDR Rules, but would then become subject to ongoing obligations as an accredited person. The ACCC is considering appropriate amendments to the CDR Rules to introduce intermediaries into the CDR regime. |
| #14 | Would you please confirm an Open Banking Solution Provider contracted by a ADR ADIs or Fintechs be set as their endpoint connection to a DH. | During the Data Holder Working Group (DHWG) on 28 May 2020, Brooke Watson from the ACCC asked if further information could be provided through our email, in particular information on the types of services being offered by the Open Banking Solution Provider and to whom the services are being offered (e.g. an ADI, an ADR or a Fintech). |
- Stream updates
- ACCC Rules Stream
- ACCC CDR Register
- CX Stream
- Banking Stream
- Energy Stream
| # | Question | Answer/ Action |
|---|---|---|
| #1 | Hi, ANZ has the following question, the rules state that a closed account’s transaction data (limited range) must be shared if the account has been closed within the last 24 months. The rules have not specifically stated this 24 month requirement for account information (i.e. Account balance and details). Our assumption is that this same rule should apply for sharing a closed account’s account information. Could you please validate these assumptions? | Question taken on notice |
| #2 |
Regarding the pushed authorization request endpoint which needs to be exposed by DH. The RFC states that the endpoint needs to be protected with authentication The standards documentation doesn't mention how this endpoint will be protected. We need to understand if there will be an access token issued though client credentials grant with client assertion JWT and then use this access token for calling pushed auth. request endpoint. If so, what would be the scope that would be used to get access token using client credentials grant? |
Question taken on notice |
| #3 |
|
Question taken on notice |
| #4 | For participants going live next year, is the implementation of the Revocation Endpoint required given the introduction of the CDR Arrangement Management Endpoint for revocation of Consents? If still required, what would be the use cases for the Revocation Endpoint? | No, the revocation endpoint is not required |
| #5 | is there an SLA or expectation on the time that an ADR would make available to a consumer data received from and ADH. | Question taken on notice |
| #6 | What will be the registry access token lifetime (e.g. 10 mins)? | Question taken on notice |
Other business
- TBA
CDR - Reporting form for data holders (rule 9.4) - v.1
I wish to clarify the format in relation to this report format for fields 2.2, 4.2 and 4.3. These appear to be similar requirements but are shown differently in the reporting form. 2.2. Number of CDR consumer complaints received for each complaint type, in accordance with your complaints handling process. So in relation to the fields above are you expecting the below format?
| 2.2 Complaint type 1 | 99999 |
| 2.2 Complaint type 2 | 99999 |
| 2.2 Complaint type 3 | 99999 |
| 2.2 Complaint type 4 | 99999 |
| 2.2 Complaint type 5 | 99999 |
| 2.2 Complaint type 6 | 99999 |
4.2. Please set out each of the CDR Rules or data standards relied upon to refuse disclosure of that data. 4.3. For each CDR Rule or data standard identified in response to item 4.2, please state the number of times you relied on that particular CDR rule or data standard to refuse to disclose CDR data.
So in relation to the fields above are you expecting the below format? (CDR Rules or data standards = Reason)
| 4.2 Reason 1 | 99999 |
| 4.2 Reason 2 | 99999 |
| 4.2 Reason 3 | 99999 |
| 4.2 Reason 4 | 99999 |
| 4.2 Reason 5 | 99999 |
| 4.2 Reason 6 | 99999 |
As the reasons for refusal are dictated by the CDR Rules & the data standards, would it be better to list all the possible reasons and then we just complete the number for each? This will make it easier for us to complete and easier for you to utilise the data as your data would all be in the same format and consistent.
- TBA