ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes (1st of April 2021)
CDR API Stream edited this page Aug 17, 2021
·
6 revisions
When: Weekly every Thursday at 3pm-4.30pm AEDT
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
- Presentation
- Q&A
- Any other business
- 5 min will be allowed for participants to join the call.
The Consumer Data Right Implementation Calls are recorded for note taking purposes. All recordings are kept securely, as are the transcripts which may be made from them. No identifying material shall be provided without the participant's consent. Participants may contact@consumerdatastandards.gov.au should they have any further questions or wish to have any material redacted from the record.
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 |
|---|---|---|
| Standards | Version 1.7.0 Published | Link to change log here |
| Maintenance | 6th Maintenance Iteration underway for 2021 | Read about the Maintenance Iteration - If you would like to join these please reach out to contact@consumerdatastandards.gov.au |
| Maintenance | Decision Proposal 161 - Banking Maintenance Iteration 6 | Link to consultation |
| DSB Newsletter | To subscribe to DSB Newsletter | Link here |
| ACCC Newsletter | To subscribe to ACCC Newsletter | Link here |
| ACCC Newsletter | 26th of March 2021 Edition | View in browser here |
| DSB Newsletter | 26th of March 2021 Edition | View in browser here |
| Consultations | Decision Proposal 160 - CX Standards This is a placeholder issue for consultation on CX Standards for non-individual consumers, business partnerships, and secondary users. This proposal is not yet ready for publication. This placeholder issue has been opened to gather initial community commentary on the scope and content of the proposal. While the intention is for this consultation to focus on the relevant items raised in Noting Paper 157*, the DSB encourages feedback on any additional CX Standards and CX Guidelines that the community views as required for the purposes of non-individual consumers, business partnerships, and secondary users. *Items 12-14. Item 16 on secondary user withdrawal standards will be dealt with separately. - Non-individual Consumers - Business Partnerships - Secondary users |
Link to consultation |
| Consultation | Decision Proposal 162 - CX Standards, Joint Accounts, Authorisation Flow | Link to consultation |
| Consultation | Decision Proposal 164 - Endpoint Metrics | Link to consultation |
| Consultation | Decision Proposal 165 - Brand aware metrics | Link to consultation |
| Consultation | Decision Proposal 166 - CX metrics for Data Holders | Link to consultation |
| Consultation | Decision Proposal 167 - Direct to consumer | Link to consultation |
| Consultation | Decision Proposal 168 - Separate Consents, Authorisation Withdrawal | Link to consultation |
| Consultation | Noting Paper - White Label Conventions | Link to consultation |
| Consultation | Decision Proposal 173 - Energy Draft Feedback Cycle 2 | Link to consultation |
| CDR Implementation Call | Administration - invitations will change by 1st of July 2021 | Awareness you will see the invitation change - we will use the existing invitation list |
| Community | New Post from one of our regular contributors Manglu CDR Related articles - Looking for feedback and collaborators |
Link to their community post here |
Provides a weekly update on the activities of each of the CDR streams and their workplaces
| Organisation | Stream | Member |
|---|---|---|
| ACCC | CDR Register (Technical) | Ivan Hosgood |
| ACCC | Onboarding | Chantelle Demian |
| DSB | CX Standards | Eunice Ching |
| DSB | Technical Standards - Banking | Mark Verstege |
| DSB | Technical Standards - Energy & Engineering | James Bligh |
Presentation this week is on Direct Debits:
- As a Data Holder I dont have Direct Debits - where can I get these from?
- External vs Internal Direct Debits (ie. one set-up for your gym membership vs a regular payment for your home loan from the same institutions account)
- Scheduled payments vs Direct Debits
- How far back do we need to scan for Direct Debits
- Which Financial Institution should be represented on a Direct Debit - the authorised entity or the institution where it is executed
- History of why Direct Debits are included
- Tips in representing Direct debits in the Open Banking
Link to the Standards: GET Direct Debits for Account
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.
We are trialling Sli.do for Question and Answer. Join our Q&A live here: https://www.sli.do/ Code: #11096
| Ticket # | Question | Answer |
|---|---|---|
| 490 | Can you please detail the Data Holder obligations around send notifications to customers when consent is created, withdrawn or expired? I can't find any requirements listed anywhere as the only CDR Receipts in the legislation seem to relate to ADRs. |
In terms of informing the CDR consumer about their authorisations, a data holder is required to keep the consumer dashboard updated (Rule 4.27). Information that must be contained on the consumer dashboard includes details of the CDR consumer's authorisations (Rule 1.15)(b). In addition to the rules, you may also want to consider what the CX Guidelines say about management of authorisations. See e.g. page 108. But it is important to note that the CX Guidelines contain recommendations that SHOULD be followed, as well as mandatory requirements. CDR Support Portal Article |
| 495 | This question relates to ADR obligations on "keeping records" and "Requests from CDR consumers for copies of records" - rule 9.3 and 9.5 We would like to understand the granularity of information a data holder is required to provide the consumer when they ask for copies of their records. 1. Do we need to provide "scope" information for the initial consent (i.e. account details, transaction details etc)? 2. If the consumer requests for a renewal with ammended scope, then will the Data Holder be required to provide previous scope Vs current scope details? |
As you are aware, rule 9.3(2)(a) requires ADRs to ‘keep and maintain records that record and explain … all consents, including, if applicable, the uses of the CDR data that the CDR consumer has consented to under any use consents’. For the purposes of a collection or use consent, it is expected that these records will include information such as: the type of data the consumer has consented to sharing (for example, account balance and details, transaction details, customer details, etc.), when the consent was given (date and time), the duration of the initial consent, whether the consumer made an election to delete redundant data, and, where applicable, a description of the ADR’s uses of that CDR data. In relation to records that record and explain amended consents, rule 9.3(2)(b) requires an ADR to ‘keep and maintain records that record and explain … amendments to or withdrawals of consents by CDR consumers’. In meeting this requirement, it is expected that an ADR’s records will indicate any changes to the original scope of the data the consumer has consented to sharing. For example, if Consumer X decides to amend a consent to include an additional data set, that change in scope should be reflected in the relevant records. The same applies for data holders keeping records regarding amendments to authorisations, which are required to be kept under rule 9.3(1)(b). CDR Support Portal Article |
| 500 | There have been multiple phasing documents, issued before the V2 rules. Some that say if Joint accounts for two account holders only has been implemented that it would be compliant, however, I can see no reference to this in the rules, and therefore interpret this to mean that for non-majors – we should deliver multiple joint account holders for Nov 21 compliance date Part 4. Can you please confirm if my interpretation is correct. |
Yes, that's correct. Non-majors need to deliver to the new joint account rules (including multiple joint account holders) by the November 2021 compliance deadline. CDR Support Portal Article |
| 523 | 4.16 Notification requirements for consumer data requests on joint accounts (1) If the requester gives, amends or withdraws an authorisation, or if an authorisation expires, the data holder must: (a) as soon as practicable, notify each relevant account holder through its ordinary means of contacting them; and Does the clause when referring to an authorisation mean the Data sharing arrangement/consent contract OR Does is it meaning the Joint account election ie: the indication of disclosure option? |
'Authorisation' has the meaning given in the definitions section of the rules (Rule 1.7). So broadly, it's the first of the two options you noted in your question. Since you asked this question, we have also finalised our joint accounts guidance, which may be of further assistance in considering this part of the rules. CDR Support Portal Article |
| 563 | Can we please confirm our assumption of how an active consent would be treated following the death of a customer: 1. Where a customer dies, their CDR consent expires and no further data sharing should take place. 2. Where a customer dies and they have a joint account, the account ownership reverts to the other living account holders. (a) If the deceased customer was the requestor / initiator of the CDR consent, the consent expires and no further data sharing should take place. (b) if the requestor / initiator of the CDR consent is one of the remaining living account holders, the CDR consent continues unaffected. |
The rules don't directly specify what happens when a CDR consumer dies. To some extent, the effect of a customer dying will depend on the data holder's practices in relation to the customer's accounts. We are not able to review and comment on all data holders' practices. However, our assumption is that generally the consumer would no longer qualify as an eligible CDR consumer, which would cause their authorisations to automatically expire (Rule 4.26).. We would expect the result of this automatic expiry to be consistent with your assumptions, as set out in your question. CDR Support Portal Article |
| 572 | In relation to our ticket titled "Using existing consent to enhance customer experience", for the data that we ingest but are not displaying in the banking app, our intent is to delete the data when a customer’s consent to collect and use has expired. Can you please confirm that this approach for data deletion is in line with the ACCC’s expectation? | There are a number of factors in both the rules and the Act that an ADR will need to consider in relation to when it should de-identify or delete of redundant data. These stem from Privacy Safeguard 12. We'd therefore suggest considering the guidance produced by the OAIC. The OAIC is our co-regulator, and has a particular focus on privacy matters. https://www.oaic.gov.au/consumer-data-right/cdr-privacy-safeguard-guidelines/chapter-12-privacy-safeguard-12-security-of-cdr-data-and-destruction-or-de-identification-of-redundant-cdr-data/ CDR Support Portal Article |
| 574 | • CDR consumers that are not individuals are to nominate a user or users. An organisation is not able to make this nomination - only an individual who is an agent acting on behalf of the organisation. Are the ACCC going to provide direction on who is entitled to make the nomination on behalf of the CDR Consumer (organisation) or will that be left to each DH to apply as they see fit? • We would assume for 1.13 (1) (d) that a partner would be able to nominate such a representative. There appear to be no obligations or further requirements relating to partnerships (ie as there are with joint accounts). Therefore, a partner could share data or could nominate a representative, without the other partner/s having knowledge of these activities or having 'pre-approved'. Please confirm this is correct. • In the case of a joint account, can one owner create a secondary user? Is any 'pre-approval' required? • If instructions are revoked for any of these non-owners (ie nominated reps or secondary users) what happens to consents they created - are they impacted? Additionally, should data be shared in this instance? For all of the 'additional users' - can we have confirmation that they must be 18 in order to share data (or is that up to the discretion of the account holder)? • Is removal of secondary user instructions only by owner who appointed (joint accounts) or is it open to any owner? • When reading the rules, is a secondary user and/or a nominated representative a CDR Consumer or not? If so, where is this indicated? |
• CDR consumers that are not individuals are to nominate a user or users. An organisation is not able to make this nomination - only an individual who is an agent acting on behalf of the organisation. Are the ACCC going to provide direction on who is entitled to make the nomination on behalf of the CDR Consumer (organisation) or will that be left to each DH to apply as they see fit? The CDR rules relating to nominating representatives are designed to be sufficiently flexible to allow data holders to leverage their existing systems and processes for dealing with non-individuals and business partnership customers. The ACCC is not proposing to provide further prescription on who is entitled to make the nomination on behalf of a non-individual or partnership. It will instead be left to the data holder’s discretion. • We would assume for 1.13 (1) (d) that a partner would be able to nominate such a representative. There appear to be no obligations or further requirements relating to partnerships (ie as there are with joint accounts). Therefore, a partner could share data or could nominate a representative, without the other partner/s having knowledge of these activities or having 'pre-approved'. Please confirm this is correct. The CDR rules do not require all partners in a partnership to approve the nomination of a representative to authorise data sharing on behalf of the partnership. However, the rules are intended to provide flexibility in how this is managed between the data holder and their business consumers, so it is open to a data holder and their business partnership customer to agree to a bespoke nomination process. For example, a data holder and a business partnership customer may agree that all or some select partners in a partnership must approve a nomination of an individual before they are recognised as a ‘nominated representative’. A consumer dashboard can be provided to the partners in the partnership but only a nominated representative can manage authorisations. • In the case of a joint account, can one owner create a secondary user? Is any 'pre-approval' required? This is dealt with in paragraph 11.2 of our Joint Account guidance. It is generally a matter for data holders to determine how to offer the functionality for making, and revoking, a secondary user instruction. • If instructions are revoked for any of these non-owners (ie nominated reps or secondary users) what happens to consents they created - are they impacted? Additionally, should data be shared in this instance? Where a secondary user instruction is revoked in relation to a particular person for a particular account, the person’s authorisations and consents for that account remain current. However, the sharing of CDR data by that person on that account ceases (Rule 4.6A). In relation to nominated representatives, the CDR consumer is the non-individual or the partners in the partnership that nominated the nominated representative. How authorisations continue after an individual ceases to be a nominated representative will depend on the data holder’s approach to managing nominated representatives. • For all of the 'additional users' - can we have confirmation that they must be 18 in order to share data (or is that up to the discretion of the account holder)? A person who is an individual must be 18 or older in order to be an eligible CDR consumer and share their own CDR data (clause 2.1 of Schedule 3 of the Rules). This covers both account holders and secondary users. In relation to nominated representatives, we expect that nominations are made appropriately by non-individuals / partnerships and that data holders exercise appropriate discretion in relation to the same. • Is removal of secondary user instructions only by owner who appointed (joint accounts) or is it open to any owner? This is dealt with in paragraph 11.2 of our Joint Account guidance. It is generally a matter for data holders to determine how to offer the functionality for making, and revoking, a secondary user instruction. A joint account holder may also unilaterally remove a disclosure option in order to stop sharing on the joint account (though this will cease sharing for all joint account holders / secondary users). • When reading the rules, is a secondary user and/or a nominated representative a CDR Consumer or not? If so, where is this indicated? The meaning of “CDR consumer” is provided at s 56AI(3) of the Competition and Consumer Act (2010). Whether a secondary user is an eligible CDR consumer is governed by Schedule 3, Clause 2.1 of the Rules. Being nominated as a nominated representative does not make a person an eligible CDR consumer. CDR Support Portal Article |
| 575 | More queries on v 2 rules: • Subclause 2..1(2) of Schedule 3 describes an eligible consumer (where the consumer is not a person but an organisation) as (ii) a person who is not an individual; and (b) is an account holder or a secondary user for an account with the data holder that: (i) is open; and (ii) is set up in such a way that it can be accessed online by the CDR consumer. At the bank, for organisation customers, the organisation itself (ie CDR consumer) cannot access the account online. It can be accessed online by individuals who have a defined relationship and act on behalf of the CDR consumer: that is, they access eBanking as themselves but have access to either accounts they own and/or accounts they have rights to operate on (be they of any type of ownership). The bank does not support the concept of logging into eBanking as an organisation or on behalf of an organisation. Additionally, in (ii) the secondary user is not an individual. Looking at 1.13 the definition of a secondary user would always have them as an individual. Further the context of this clause would appear to imply that rather than just secondary users (which 1.13 seems to apply to only individually owned accounts) nominated users were also intended to be addressed (ie individuals who can share on non-individually owned accounts). Have we misread these rules or do they need to be tightened? • The rules have introduced partnerships as being separate to joint accounts. And, in the absence of a full set of analogous rules to the joint accounts they will not be treated the same. What is the rationale in addressing them separately to joint accounts? Is the intention that they be afforded a different treatment? There is no rule that we identified that explicitly states that the partners in a partnership are able to share data as account owner or if to do so they must first become a nominated user on the account. Please clarify. |
• Subclause 2..1(2) of Schedule 3 describes an eligible consumer (where the consumer is not a person but an organisation) as (ii) a person who is not an individual; and (b) is an account holder or a secondary user for an account with the data holder that: (i) is open; and (ii) is set up in such a way that it can be accessed online by the CDR consumer. At the bank, for organisation customers, the organisation itself (ie CDR consumer) cannot access the account online. It can be accessed online by individuals who have a defined relationship and act on behalf of the CDR consumer: that is, they access eBanking as themselves but have access to either accounts they own and/or accounts they have rights to operate on (be they of any type of ownership). The bank does not support the concept of logging into eBanking as an organisation or on behalf of an organisation. Additionally, in (ii) the secondary user is not an individual. Looking at 1.13 the definition of a secondary user would always have them as an individual. Further the context of this clause would appear to imply that rather than just secondary users (which 1.13 seems to apply to only individually owned accounts) nominated users were also intended to be addressed (ie individuals who can share on non-individually owned accounts). Have we misread these rules or do they need to be tightened? The CDR rules allow for nominated representatives who can share data on behalf of a business consumer. Based on your description, this would be analogous to your description of ‘individuals who have a defined relationship and act on behalf of the CDR consumer.’ After being nominated, the representative would be able to be authenticated with a data holder using their individual profile or log-in credentials that is linked to the business consumer. In relation to your second query, ‘secondary user’ is defined in rule 1.7 to be a ‘person’. This means a secondary user can be either a natural or legal person, although we expect in most cases a secondary user will be an individual. • The rules have introduced partnerships as being separate to joint accounts. And, in the absence of a full set of analogous rules to the joint accounts they will not be treated the same. What is the rationale in addressing them separately to joint accounts? Is the intention that they be afforded a different treatment? The rationale for the partnership rules is set out in Section 6.2 of the consultation paper the ACCC published in September 2020 (link). There is no rule that we identified that explicitly states that the partners in a partnership are able to share data as account owner or if to do so they must first become a nominated user on the account. Please clarify. Note 3 of rule 1.13 requires a partnership to have a nominated representative before it is able to give authorisations in relation to its partnership account. This means that partnerships would need to nominate a partner, in accordance with the process set by the data holder, before that individual was able to authorise the sharing of data from the relevant partnership account. CDR Support Portal Article |
| 576 | • 4.8 (1) (c) There is no such thing as product data associated with the account - refer to the standards (any product type attributes are considered account data). What does this clause intend? • 6.5. We do not understand this clause and request guidance on what this clause is stating. • 6.4 (3) (i) gives relief for joint accounts until phase 2 products come in. What about accounts owned by non-individuals and accounts owned by partnerships - are these required for phase 1 products from July 1st? If not, where is the exclusion in the rules? |
• 4.8 (1) (c) There is no such thing as product data associated with the account - refer to the standards (any product type attributes are considered account data). What does this clause intend? Clause 4.8(1)(c) of Schedule 3 refers to 'product specific data'. This is defined in the table at Clause 1.3 of Schedule 3. • 6.5. We do not understand this clause and request guidance on what this clause is stating. Clause 6.5 clarifies that a data holder may disclose CDR data in response to a data request made under Part 2, 3 or 4, even if one of the provisions of Part 6 of Schedule 3 (which deals with staged application of the rules) means the data holder wouldn't otherwise be required or authorised to do so. • 6.4 (3) (i) gives relief for joint accounts until phase 2 products come in. What about accounts owned by non-individuals and accounts owned by partnerships - are these required for phase 1 products from July 1st? If not, where is the exclusion in the rules? The timing for non-individuals and business partnerships is set out at Schedule 3, Clause 6.7. These are not required for phase 1 products from July 1 2020. CDR Support Portal Article |
| 592 | Folowing on from this question and answer raised - https://cdr-support.zendesk.com/hc/en-us/articles/900005404703?input_string=one+open+account If the customers accounts are all closed besides one account, do they have to be the owner of that one open account to be able to share data on their closed accounts? Or can they have a different relationship to the open account and so long as they can view that account on internet banking then that suffices the rule to be able to consent to share data on their closed accounts (where they are the account owner of that closed account)? |
Clause 2.1 of Schedule 3 to the rules governs whether a consumer is eligible in relation to a data holder. 2.1(2)(b) states that a CDR consumer may be eligible if they are either an account holder or a secondary user for at least one open account, which is set up in a way that it can be accessed online. You may wish to consider whether your consumer's relationship to the open account fits into this definition. CDR Support Portal Article |
| 648 | Could you please clarify the depositRates tiers should display the generic products rates list as being presented publicly by the Product Reference API or the data needs to have the tailored/negotiated rates specific to that account?? | The purpose of the statement in the standards is meant to imply that the way fees are presented for the account use the same BankingProductFee structure and you should be consistent in the naming and terminology (e.g. if you a saving account has an "EARLY_TERMINATION_FEE" then you should be consistent when presenting that fee for the account rather than calling it something else such as "Termination fees on early exit"). It is also meant that how you represent tiers, discounts etc. should be consistent between the PRD data and the fees, rates etc. applicable in the account data response. The fees for an account should only be those that apply to the given account (now that the product has been taken up by the customer and any fees have been negotiated or tailored). CDR Support Portal Article |
| 649 | Seeking clarification on the expectations from CDR Rules, in the scenario where a loan account is written off i.e. when customer is not making payments and the bank is unable to recover the debt and the account is written off. Is this reasonable to be treated as a blocked/suspended or closed account ? AND how should the Data Holder notify the customer and ADR at this stage regarding the refusal to share CDR data. OR As per this article, https://cdr-support.zendesk.com/hc/en-us/articles/900004225543-Expected-CX-Behaviour-for-Closed-Accounts- Closed accounts should be in the 'available' list if they are eligible. Should this scenario be treated as eligible for data sharing and be displayed under the "Accounts allowed for sharing" on the Accounts Selection screen in Consent Flow? |
If the loan is written off or in arrears, but the account is still available, it would be eligible for data sharing. However, this is determined by how the bank handles these account scenarios in existing digital banking channels. If the bank deals with this as a closed account (no longer representing a debt that is recoverable) or a suspended account or blocked account, and it is otherwise unavailable, it is at the discretion of the bank whether they share this data or treat the account as closed. If the request is rejected due to a business rule, it would be a 404 or 422 error response depending on the API being responded from. CDR Support Portal Article |
| 661 | Just wondering if you can provide more clarification on a previous question we had which you have previously responded to: https://cdr-support.zendesk.com/hc/en-us/requests/384 On the support request have previously mentioned this: "The collection arrangement is not executed by the Provider having their own software product. As described above, the Provider is managing the software product on behalf of the Principal. Any software products that the Provider has in the ecosystem are not utilised as part of the collection arrangement." So we wanted to confirm whether the following scenario is supported by CDR where: Whether as a Provider with a registered Software Product with CDR can collect data on behalf of a Principal for a consent was not established by our Software Product (e.g. by the Principal's own Software) but is provided with the CDR arrangement ID and access token in order to perform the data retrieval? |
The model you have proposed does not align with the collection arrangement model. The collection arrangement has the Provider managing the Provider's software product. The Provider uses their own platform and services, but the registration, keys, certificates, consent arrangements and collected data must be tied to that software product CDR Support Portal Article |
| 669 - Part 1 | As we look at preparing for testing with the CTS, we have the following questions: We anticipate that a number of Tier 2 Data Holders will be looking to test with the CTS during the May / June period, perhaps a large number during a very short timeframe. Are there any restrictions / capacity constraints in terms of ACCC support for CTS during this period? How is ACCC looking at handling multiple parties connecting during a peak period prior to the compliance date? Once we have successfully completed all the tests on the CTS tool in a non-Production environment, are there any conditions that would invalidate these results? We have seen the note about the solution being in a near Production or Production ready state, but wanted to understand any other changes that might trigger a re-test using CTS once a successful run has been achieved. |
1. There are no restrictions or capacity constraints. CTS has been stress and volume tested and is expected to cater for Tier 2 Data Holders on-boarding between now and 30 June 2021. The CTS enrolment process and support offered by the ACCC is described in the detailed guidance materials. 2. Once the result from a successful run in CTS is available it will be used as input into the Registrar’s final decision to activate a participant on the Register. The section on “Conformance testing approach for existing participants” in the CDR Participant Test Strategy outlines some circumstances where the ACCC may require a participant re-run the CTS. Participants are encouraged to voluntarily re-run CTS at their own discretion. |
| 669 - Part 2 | On the second point, the CDR participant test strategy has some general information on what might trigger a CTS retest, possibly even after a participant has entered the ecosystem. I was trying to determine if say we run the CTS in our non-Production environment and successfully complete all of the tests, following which we find ourselves in a situation where we have to implement a fix, are we expected to re-execute CTS? Are there any specific types of similar changes that would necessitate a re-run of the CTS after we have passed all scenarios? Thanks. Under certain circumstances, the ACCC may mandate or request existing participants retest their solution through the CTS, to reduce broader ecosystem risk. This may include a sub-set or all of the CTS tests in a test suite. The following factors will form part of the consideration for such a request: § at the ACCC’s Compliance & Enforcement Team’s request through routine or targeted enforcement activities § release of a new CTS version § introduction of a new sector § changes to the Rules [R1] and/or Consumer Data Standards [R3] § the stability of the ecosystem (e.g. info security concerns) § volume and severity of incidents in ecosystem § proportion of participants voluntarily conducting conformance testing In such circumstances, the ACCC will outline why they are mandating or requesting CTS retesting. |
You may not have seen Section 10 of the Data Holder CTS Enrolment Form at this time; it's available here https://www.accc.gov.au/focus-areas/consumer-data-right-cdr-0/cdr-conformance-test-suite. It requires the Legal Entity, responsible for on-boarding a Data Holder Brand, to undertake a number of acknowledgements related to testing, Point 1 is particularly relevant. We would encourage any Data Holder to exercise judgement on whether CTS should be re-run if changes to their solution are associated to areas tested by CTS and therefore affect a previous, successful result. |
| 673 | When performing bulk operations, data may be gathered from many internal endpoints, and compiled into a single bulk response. If a single source does not respond or is unavailable how should respond to the recipient? An example would be deposit account in one system, and lending in another. If one of these systems is unavailable, should the whole request fail, should the missing accounts be left out of the response, or, should meta include and error listing the missing accounts. In particular, when it is a white-label provider that fails to respond, if the entire request was to fail, even if the brand owner had the majority of the data available to respond with. Preference in this case would be to return what we can, and, let the recipient work out what they were expecting vs what they got. However not sure how this would work from a "admin api" reporting perspective. How do you report a partial failure. |
Previously we have said if one account fails, then all fail and we have recommended against partial responses. It would be a 500 in this situation. If you see benefit in dealing with partial responses I'd encourage you to raise a change request so we can consult on this with the community. |
| 694 | With the v2 rule it states that data holder has to support amending consent use case. Referring to the output of the previous workshop for amending consent (https://consumerdatastandards.gov.au/2020/10/amending-consent-workshop/), specifically in the "ADR and DH communication" section, there is a statement that says: "... technically the process will be to call the revocation endpoints of the relevant data holder(s), and create a new consent with the “cdr_arrangement_id”...." How can this be achieved with the current data standards? It is not clear if the current authorise endpoint can accept "cdr_arrangement_id". |
For ADRs seeking to "amend consent" they must use the PAR endpoint that is correct. Please note that the standards do not actually support amending of a technical consent. Technically it supports the replacement of an existing consent with a new consent under the same arrangement. This means the following: - The new consent can be completely different. All aspects are able to be changed because it is technically a new OAuth consent. - For the new consent to be associated with the existing arrangement PAR needs to be used and the arrangement ID needs to be passed - The same consent flow, including the same screens, are required. There is currently no facility for simplified amendment - The ADR can initiate the consent flow from wherever they like in their experience including the dashboard |
Updating the table below - if your question/ ticket has not received a response yet the team continues to work on a response. We do apologise for the delay on some tickets, the teams are doing their best to get to everyone's questions.
To our valued CDR participants, We have undertaken a review of the CDR Support Portal as a channel for providing guidance on CDR Rules. Based on the volume and nature of questions we have received recently, we have decided to move to a model based on publishing guidance to the community, rather than providing individual responses to stakeholder questions. Our goal is to prioritise the provision of guidance that is accessible, transparent and has industry-wide application. We intend to develop this to meet clear community needs, which we will identify and prioritise based on questions and issues raised by stakeholders. We kindly ask for your patience as we work our way through the tickets, feedback and guidance
A work in progress - open for feedback from the community on what you would like to see.
| Organisation | Description | Link |
|---|---|---|
| OAIC | Main landing page for the Office of the Australian Information Commissioner and the Consumer Data Right | Link |
| DSB | CX Artefacts - The CX Guidelines provide optional examples of key requirements and recommendations to help organisations build best practice consent models. CDR Participants should also refer to the CDR Rules, data standards, and privacy guidelines for a complete view of obligations to facilitate compliance. | Link |
| DSB | Consumer Data Standards Main Page - About the DSB team, engaging with our consultations and Events | Link |
| DSB | The Consumer Data Standards - The technical and consumer experience standards for the Consumer Data Right | Link |
| DSB | The Banking Product Comparator - a demonstration of Product Reference Data from Data Holders as part of the Consumer Data Right | Link |
| DSB | GitHub Consultations - all public consultations from the Data Standards Body | Link |
| DSB | Java Artefacts - An Open Source Project comprised of reference implementations of both Data Holders and Data Recipients | Link |
| ACCC & DSB | The Consumer Data Right Support Portal Knowledge base for the Consumer Data Right covering Rules through to Technical articles and questions |
Link |
| ACCC | ACCC Main focus area/ landing page for the Consumer Data Right | Link |
| ACCC | GitHub Consultations - all public consultations from the ACCC Register Team | Link |
| ACCC | CDR Register Design Reference | Link |
| ACCC | Public page for the Consumer Data Right | Link |
| ACCC | Participant Portal page including sign-up and log-in | Link |
| TSY | Consumer Data Right background and historic records from the Treasury | Link |
- Overview
- 2nd of May 2024
- 25th of April 2024 - Cancelled (ANZAC Day)
- 18th of April 2024
- 11th of April 2024
- 4th of April 2024
- March 2024 Agendas
- February 2024 Agendas
- January 2024 Agendas
- 2023 Agendas