-
Notifications
You must be signed in to change notification settings - Fork 56
ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes (11th of February 2021)
CDR API Stream edited this page Jun 8, 2021
·
5 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: [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
- 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 [email protected] 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.6.0 Published | Link to change log here |
| Standards | Version 1.7.0 Proposed | Link to Project Board with proposed changes here |
| Maintenance | 6th Maintenance Iteration planned for 2021 | Read about the Maintenance Iteration - If you would like to join these please reach out to [email protected] |
| DSB Newsletter | To subscribe to DSB Newsletter | Link here |
| ACCC Newsletter | To subscribe to ACCC Newsletter | Link here |
| ACCC Newsletter | 5th of February 2021 Edition | View in browser here |
| DSB Newsletter | 5th of February 2021 Edition | View in browser here |
| Consultations | Decision Proposal 149 - Energy Draft Feedback Cycle 1 Feedback is now open on any issue related to draft. This thread will remain open until February 12th 2021. At that time proposed changes will be incorporated and a second consultation cycle will commence. |
Link to consultation |
| Consultations | Decision Proposal 153 - Technical Standards Changes to Accommodate V2 Rules This decision proposal contains a review of the amendments to the CDR rules published on the 23rd of December 2020 to identify changes to the technical CDR standards. This includes the API standards, high level standards and the information security profile. This decision proposal does not cover consumer experience standards or guidelines which will be addressed separately. This thread will remain open until February 19th 2021. |
Link to consultation |
| Consultations | Decision Proposal 154 - Enhanced Error Handling: Error Code Payload Structure and Transition Arrangements This decision proposal is seeking to address the list of transition arrangements and payload changes to support standardised error codes across the CDR ecosystem. Feedback is planned to be closed on 19th February 2021. |
Link to consultation |
| Consultations | Decision Proposal 155 - Enhanced Error Handling: Error Code Catalogue This decision proposal is seeking to address the list of standardised error codes and HTTP status codes for error handling across the CDR ecosystem. Feedback is planned to be closed on 19th February 2021. |
Link to consultation |
| Consultations | Decision Proposal 156 - Enhanced Error Handling: Custom Error Code Discovery Service This decision proposal is seeking to address how participants — particularly ADRs — may discover custom error codes not covered by the standardised error code catalogue are used by servers where commercial / voluntary extensions to the core CDR APIs are offered. Feedback is planned to be closed on 19th February 2021. |
Link to consultation |
| Consultations | Noting Paper 157 - CX Standards Arising from v2 Rules. This noting paper outlines the anticipated Consumer Experience Data Standards changes arising from the v2 rules being made on 23rd December 2020. Feedback is now open on this noting paper. Feedback is planned to be closed on Friday 12th February, 2021. |
Link to consultation |
| Consultations | Decision Proposal 158 - Participant capability discovery This decision proposal pertains to the consultation for a functional discovery mechanism pertaining to the DSB's Future Plan roadmap item published here: ConsumerDataStandardsAustralia/future-plan#5. Feedback is now open for this proposal. Feedback is planned to be closed on 5th March 2021. |
Link to consultation |
| Consultations | Decision Proposal 159 - v1.7.0 Placeholder for the 1.7.0 Release |
Link to consultation |
| 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 |
Provides a weekly update on the activities of each of the CDR streams and their workplaces
| Organisation | Stream | Member |
|---|---|---|
| ACCC | Rules | Andrew Breeze |
| ACCC | CDR Register (Technical) | Ivan Hosgood |
| DSB | CX Standards | Michael Palmyre |
| DSB | Technical Standards - Banking | Mark Verstege |
| DSB | Technical Standards - Energy & Engineering | James Bligh |
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 - Part 1 | 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. | The current CDR Rules do not allow an ADR to use a non-accredited third party to collect CDR data from a Data Holder on its behalf. Therefore, if the ADI (as an ADR) plans to use a vendor to collect data the vendor must become accredited. Further note, if an ADI is an Accredited Data Recipient (ADR), the ADI (as an ADR) can use a non-accredited third party (an outsourced service provider) under a CDR outsourcing arrangement. Such an arrangement allows an ADR to disclose to the outsourced service provider CDR data for the purposes of providing to the ADR goods or services using the CDR data. Rule 1.10 of the CDR Rules sets out what a CDR outsourcing arrangement is, and the obligations that an outsourced service provider must comply with. Compliance with the CDR Rules remains with the ADR as the accredited person. CDR Support Portal Article |
| 107 - Part 2 | 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. | The ACCC published advice in a newsletter on the use of SaaS, https://mailchi.mp/accc.gov.au/minor-rules-amendments-exemptions-granted-white-label, see heading "ACCC position on utilising software to collect Consumer Data Right data", our position remains unchanged since this advice. If you need further clarification we recommend seeking legal advice on the application of the rules in relation to SaaS. CDR Support Portal Article |
| 139 | I have a question about what is required with respect to what must be presented to the consumer in the DH dashboard relating to disclosure on a consent. The rules (1.15 (3) (f)) state: information relating to CDR data that was disclosed pursuant to the authorisation (see rule 7.9); This does not provide any detail on what “information” is required. In the CX guidelines (pg 109) there is a picture of the consumer dashboard with the “guideline” 2 stating: Data holder consumer dashboards SHOULD show details of any historical CDR data that was disclosed. The example does not actually provide much information on the data that has been disclosed under the consent, how many times, when etc: it states only when data was first disclosed. Other information relates to the consent duration and the first holder date, but not to data actually disclosed. Our question is whether it is sufficient to do as the example in the CX Guidelines has done (ie whether this example is compliant)? |
Your query refers to a few distinct requirements and recommendations, which I'll respond to separately below. Rule 1.15(3)(f) and 7.9 Rule 1.15(3)(f) requires data holders to provide information relating to CDR data that was disclosed pursuant to the authorisation, which refers to rule 7.9. The information that is required is specified in rule 7.9 - which relates to privacy safeguard 10 (PS10) - and requires data holders to state what CDR data was disclosed, when it was disclosed, and who it was disclosed to. In answer to your question: yes, the CX Guideline on p.110 of the v1.4.0 release covers this requirement and provides a compliant example for how to meet rule 1.15(3)(f), rule 7.9, and PS10 that the DSB developed with the OAIC and ACCC. This is considered to be a minimal way to comply with these requirements. This example meets these requirements in the following ways: 'What CDR data was disclosed' is met by displaying the disclosure notification in the context of the data cluster (p.110 presents the PS10 notification in relation to the Transaction Details data cluster only, not as a general authorisation notice). 'When the CDR data was disclosed' is met by displaying the first time that specific data cluster was disclosed to the ADR, and the expected date of the final disclosure (the authorisation's expiry date). A once-off disclosure can refer to the single disclosure date. 'Who it was disclosed to' is met by referring to the ADR in the statement about the first disclosure date. Importantly, the second statement need not refer to the ADR again if it is presented in relation to the other statements that do refer to the ADR's name. This can be done to avoid making repeated reference to the ADR in relation to each statement/requirement. If these statements are presented separately the DH would need to refer to the ADR in relation to each separate statement. DHs may wish to provide more detail than the CX Guideline suggests, such as a statement/notification on when a specific data cluster was last disclosed (e.g. 20 January 2021 at 9pm). The CX Guideline only provides one simple example; DHs should note that meeting PS10 will be context dependent. For example, there are exceptions to rule 7.9 for joint accounts that will need to be considered. DHs may also choose to meet this requirement in another way, such as through a dashboard notification feed instead of on the authorisation record itself. DHs should refer to the OAIC's online guidance for more detail. Importantly, rule 1.15(3)(g) refers to a different set of requirements under subsection 56EN(4) of the Act concerning data quality (PS11) and correction requests (PS13). The CX Guideline on p.110 does not provide examples for how to comply with Privacy Safeguards 11 and 13 (rules 7.10 and 7.15, respectively). CX Guideline p.109 - Historical data This guideline is a separate recommendation to the privacy safeguard requirements discussed above. For context, rule 4.23(b) requires DHs to give CDR consumers information about the 'period of time to which the CDR data that was the subject of the request relates'. This rule refers to the historical range of the data, e.g. 'data that may date back to 1st January 2017'. An example of this requirement is displayed on p.83 of the v1.4.0 CX Guidelines for the authorisation flow in relation to the Transaction Details data cluster. An equivalent requirement does not exist for the DH dashboard, so the CX Guideline on p.109 recommends this same level of detail be provided on the DH dashboard for consistency. It is not required nor does it relate to rule 1.15(3)(f), rule 7.9 or any of the privacy safeguards. CDR Support Portal Article |
| 250 | We have a question on providing the corrected CDR data as per the CDR rule below. Assuming that - as a Data Holder we have 1. identified incorrect CDR data has been disclosed for a consumer 2. identified dates of disclosures, disclosed CDR data elements 3. already corrected the data and corrected data set is identified 4. informed the consumer as per the rule below via a written notification If consumer request us to resend the data as per rule 7.10 d (i) , how do you expect us to re send the corrected CDR data to ADR as per 7.10 d(ii)? As per the rules and the CDR scheme, ADR should initiate the data request covering the affected CDR data. To do that, ADR should aware of such case. Who should inform the ADR to re collect the data? Consumer or Data Holder? We prefer consumer to do so. Otherwise, DH's required to obtain contact details of ADRs and have communications outside what is defined in the rules, which we would like to avoid. Authorization for the past data disclosure might not be valid any more to re request data (ie: expired or authorization for a single occasion disclose). Consumer may need to provide a new authorization. Can you please shed some light as to how you expect this process to work? |
In relation to your question on Privacy Safeguard 11 late 2020 we posted an article on the CDR Support Portal in regards to this topic. Further, we have recently addressed a similar question in a knowledge article - both are included below. Please find the link to these articles: Note on privacy safeguard 11 Disclosing corrected data |
| 336 | What is the intended usage of server v/s client certificate, from a data recipients perspective? For a data recipient, during communication(server to server API) with data holder or registry should we use client or server certificate? Also data recipient needs to host the jwks and revoke end points. In this case do these end points need to support two-way SSL(MATLS)? What is the type of certificate to be used here? |
Question: What is the intended usage of server v/s client certificate, from a data recipients perspective? Answer: Client certificates are used when calling MTLS protected endpoints hosted by either Data Holders or the CDR Register. Please refer to: 1. The Endpoints section of the Consumer Data Standards: https://consumerdatastandardsaustralia.github.io/standards/#end-points 2. The Register APIs section of the CDR Register Design: https://cdr-register.github.io/register/#consumer-data-right-cdr-register-apis Question: For a data recipient, during communication(server to server API) with data holder or registry should we use client or server certificate? Answer: The Client certificate. Please look at my first answer in this list. Question: Also data recipient needs to host the jwks and revoke end points. In this case do these end points need to support two-way SSL(MATLS)? What is the type of certificate to be used here? Answer: No. Again, please again refer to the endpoints section of the Consumer Data Standards as it is specified there. TLS endpoints can be protected with either public or ACCC CA issued server certificates. CDR Support Portal Article |
| 384 | We have some questions regarding the Collection Arrangements outlined in this article: https://cdr-support.zendesk.com/hc/en-us/articles/900003114503-Collection-Arrangement So it is mentioned in the article that providers can perform the collection on behalf of a principal - so we would like to confirm at a high level how this will be supported by the CDR register. Currently it is our understanding based on the existing CDR documentation that registration and authentication for the software product with the CDR register is tied to the Data Recipient's brand ID so collection on behalf of principals is not supported in its current state? The article further mentions that as part of the upcoming incremental release in early 2021, there will be support to perform authentication with the software product instead of at the data recipient brand. So the questions we have are: 1. How will this affect the initial dynamic client registration process with the data holders? What changes will be required in the requests we send for the Dynamic Client Registration? Will the client ID returned in the response be for the Software Product or would it be for the Data Recipient itself? 2. Will the following scenario be possible under the aforementioned collection arrangement: where the Principal (as a Accredited person) has its own Software Product and for which it is registered with CDR and Data Holder to establish consent as part of the collection arrangement. Principal collects the consent from the own Software Product. The Principal software product passes the consent details to the provider software product(in the collection agreement) only for data retrievals from the data holder on behalf of the Principal. And if so how would initial established consent by the Principal be associated together with the CDR data collection by the Provider? Would it be via the same Software Product ID provided for both initial registration and through the authentication with the Data Holder? |
Question: So it is mentioned in the article that providers can perform the collection on behalf of a principal - so we would like to confirm at a high level how this will be supported by the CDR register. Currently it is our understanding based on the existing CDR documentation that registration and authentication for the software product with the CDR register is tied to the Data Recipient's brand ID so collection on behalf of principals is not supported in its current state? Answer: No this is not correct. The registration process is tied to the software product id. This is not changed by the introduction of the collection arrangement. Instead, the Provider will be positioned to manage the software product on behalf of the Principal and therefore collect consumer data on behalf of the Principal. Question: 1. How will this affect the initial dynamic client registration process with the data holders? What changes will be required in the requests we send for the Dynamic Client Registration? Will the client ID returned in the response be for the Software Product or would it be for the Data Recipient itself? Answer: It won't. Dynamic Client Registration is always in the context of the Software Product registering with a Data Holder Brand. This position does not change. The client ID returned by the Data Holder brand will be for the software product. Please refer to the Dynamic Client Registration section of the CDR Design. Question: 2. Will the following scenario be possible under the aforementioned collection arrangement: where the Principal (as a Accredited person) has its own Software Product and for which it is registered with CDR and Data Holder to establish consent as part of the collection arrangement. Principal collects the consent from the own Software Product. The Principal software product passes the consent details to the provider software product(in the collection agreement) only for data retrievals from the data holder on behalf of the Principal. And if so how would initial established consent by the Principal be associated together with the CDR data collection by the Provider? Would it be via the same Software Product ID provided for both initial registration and through the authentication with the Data Holder? Answer: 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. V1.3.0 of the CDR Register design adds functionality which allows the retrieval of an SSA from the CDR Register, using authentication at the software product level as well as the data recipient brand level. This is key as it allows us to define the access control of which software products the Principal can allocate to the Provider. This increases the types of models supported in the ecosystem. To repeat comments above, this new functionality does not impact the Dynamic Client Registration process. |
| 441 | In Scheduled Payments APIs, a DH should not be providing payeeID but full payee details when Bank Payee Scope is not consented to. Does the same principle apply for Basic Account Scope, i.e. if the ADR only has Scheduled Payments Scope consented to, should a DH provide accountID for scheduled payments between internal accounts, where accountID would apply? | yes the DH should respond with the accountID in accordance with the standards. The accountID is not a data field, it is an opaque, non-guessable identifier field created only for the CDR so it isn't an issue with it being shared. Technically an ADR can use the bulk scheduled payments end point to get a list of accountIDs and then call the account specific version of the scheduled payments APIs which would also be entirely acceptable. Also, with the introduction of amending consent in the v2 Rules, an ADR could have previously obtained an account list and now no longer have access to it if consent is amended to remove the account scopes. Whilst an ADR may obtain one or more accountIDs via the scheduled payment APIs, if the ADR does not have the consumer's consent to access the account data (e.g. bank:accounts.basic:read) then the DH would return an error if the Get Accounts API was called and would not return the account specific information. CDR Support Portal Article |
| 450 | In our bank the display name for online channels is following the next logic: if customer has given a Nickname to the account, only Nickname will be displayed; if no Nickname has been given, Product Name is displayed. In terms of account.productName, we can potentially show one of two options of granularity. Example for Term deposits: each term deposit depending on length will have a different internal product number, for example 2089, 2090, 2091. But in terms of product name, it will be just ‘Term Deposit’ (i.e. we don’t have an option Term Deposit 90 days, Term Deposit 120 days etc) To make sure we’re consistent with other banks, can you please advise which approach should we take? Option 1 account.displayName: nickname if exists, otherwise productName (as per current logic for online channels) account.nickname: name given by customer account.productName: product name such as Term Deposit, Savings Maximiser, Orange Everyday etc Option 2 account.displayName: product name such as Term Deposit, Savings Maximiser, Orange Everyday etc account.nickname: name given by customer account.productName: internal granular product number such as 2089, 2090, 2091. It won’t make much sense to data recipients unless overlaid with displayName Option 2 account.displayName: product name such as Term Deposit, Savings Maximiser, Orange Everyday etc account.nickname: name given by customer account.productName: same as account.displayName |
In regards to the 'productName' field, this field is designed to hold any identifier that the data holder wishes to provide for the product in any format. It is not expected to be displayable. As the option exists for a single conceptual product to be represented multiple times in the product reference data APIs (for instance a single branded term deposit may be represented once for retail customers and again for business customers), the productName is intended to be unique for the model or type of product. Essentially, the contents of this field is at the discretion of the data holder. In regards to the 'displayName' it is the name that the data holder would use for display purposes in other digital channels. The contents of this field is at the discretion of the data holder. CDR Support Portal Article |
| 451 - Part 1 | As per description, it specifies that ‘Fees and charges applicable to the account based on the equivalent structure in Product Reference’ Can you please clarify, does it mean that we need to return the exact same structure and data as in Product Reference API that is applicable for this particular account, or if, for example, there is a fee that is usually applied to the type of product to which this account belongs, but this fee has been waived for this particular account, do we have to expose same structure as in Product Reference API but different data (showing that the fee that has been waived, or not showing that fee at all)? |
This sentence was 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. Noting that some fees and accounts may be grandfathered and no longer apply to the publicly available products so some variance is likely for some accounts. 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). |
| 451 |
Question 1. Via Get Product Details API we show that for a product Orange Everyday, there is a fee for ‘International ATM withdrawal’, and ‘International purchase’. There is also an eligibility based discount, if a customer does specific actions each month (When you deposit $1,000 or more per month and make 5+ card purchases that are settled (not pending) each month.), the above fees will be refunded. Is the response for the above fees and discount via Get Account Details API supposed to be different from Get Product Details API? For example, do we need to indicate in some way that a customer has met eligibility for this month, but not for the next month on an account level? Or would the responses via both APIs be identical in this scenario? Question 2. Below is an example of a response from Products API for a late payment fee for a credit card: Insert Table here If on an account level, a customer has negotiated a discount for this fee, does it mean that in a response from Get Account Details API we will should populate the ‘discounts’ field that was empty in Products API response with a ‘-20.00’ amount (if the discount was 100%)? If on an account level, a customer has negotiated a discount for this fee for one time only, but this same fee might be applied in future, how should we show this in a response from Get Account Details API? Should we introduce new types of discounts, which are not part of Products API response? |
Question 1a: Is the response for the above fees and discount via Get Account Details API supposed to be different from Get Product Details API? DSB Answer: The fees shown in the Get Account Details API should be the same types of fees shown in the PRD endpoint however they may have negotiated rates specific to the account. Broadly speaking, the way you are representing the fees should be the same if they apply to the account. There may also be account specific fees that do not apply to the publicly offered products presented in PRD. Question 1b: For example, do we need to indicate in some way that a customer has met eligibility for this month, but not for the next month on an account level? **DSB Answer: **This would be a good idea. In the example you gave about discounted fees based on deposit amount or number of card purchases, you could use discountType = DEPOSITS and discountType = ELIGIBILITY_ONLY respectively to represent these discount conditions. For discountType = DEPOSITS, additionalValue should be set to $1000. additionalInfo can be used to note whether the customer has satisfied this condition, however it is not mandatory to do so because it is assumed the ADR can infer this from the balance and transactions list. For discountType = ELIGIBILITY_ONLY, the associated BankingProductDiscountEligibility must be populated. In the situation you describe, discountEligibilityType would be 'OTHER' and the additionalValue populated with something like '5+ card purchases that are settled (not pending) each month'. additionalInfo may be used to denote whether the customer has qualified for this, but it is not mandatory because it is assumed the ADR can infer this from the transactions list. Question 1c: Or would the responses via both APIs be identical in this scenario? DSB Answer: Since you have the context of the customer's transactions, you can present additional information if the customer has qualified for the discount and/or satisfied the eligibility criteria but it is not mandatory and left to the DH to decide. **Question 2a: **If on an account level, a customer has negotiated a discount for this fee, does it mean that in a response from Get Account Details API we will should populate the ‘discounts’ field that was empty in Products API response with a ‘-20.00’ amount (if the discount was 100%)? DSB Answer: Yes, you should populate the discount object with the negotiated discount. The amount would be a positive value because discount implies it is to be deducted from the base fee. Question 2b: If on an account level, a customer has negotiated a discount for this fee for one time only, but this same fee might be applied in future, how should we show this in a response from Get Account Details API? DSB Answer: This isn't specified in the standards how DHs should handle this. You may do as you have described and use an ELIGIBILITY_ONLY discountType with discountEligibilityType of 'OTHER', the additionalValue representing the negotiated amount and additionalInfo qualifying that this is a once-off discount. Alternatively, one time only discounts could be shown as fee waiver transactions on an account. Question 2c: Should we introduce new types of discounts, which are not part of Products API response? DSB Answer: If the list of discountTypes are insufficient we'd welcome change requests raised on our standards-maintenance GitHub repository. You cannot create a discount type that does not exist in the standards, so we need to go through the change process to incorporate it into the standards. This would be excellent to raise if you have identified different discount types that warrant inclusion. Likewise, if you feel there are gaps or areas where the standards could be clearer in these respects, I am sure other DHs would benefit if you wish to raise a change request. CDR Support Portal Article |
| 454 | The expiry for Long Term Polling is 7 days, but what is the expiry period defined for Short Term Polling? Can you please advise? | The Short Term Polling retry period is 10 minutes. For reference: https://cdr-register.github.io/register/#backoff-patterns CDR Support Portal Article |
| 480 | On the consent stop sharing section, the "Historical data required" section indicates the date to which the collected data might go back to. Is there any mandate which suggests we need to show the date from when we might be collecting user's data? Just to clarify, this date is way before the consent duration (Consent Start - End Dates) |
Q: Is there any mandate which suggests we need to show the date from when we might be collecting user's data? Yes. For completeness, this response covers the following areas where historical data requirements and recommendations exist: 1. ADR consent step 2. ADR dashboard 3. DH authorisation step 4. DH dashboard ADR consent step During the consent process, ADRs must explain how the collection and use of CDR data complies with the data minimisation principle, including that (Rule 4.11(3)(c)). That includes explaining that the ADR will not collect more historical data than they reasonably require for the provision of the service. Item C.34 in OAIC's CDR guidelines also reflects this requirement. The revamped CX guidelines will provide an example of this in the consent step, e.g. ‘If available, we will collect data dating back to 10 Feb 2021 to [value proposition] and comply with our [obligations].’ ADR dashboard ADRs are not required to present the historical range on dashboards under rule 1.14, but the CX Guidelines recommend that they do (p.96 of v1.4.0). However, this information may end up on the dashboard indirectly in relation to Privacy Safeguard 5. DH authorisation step Rule 4.23(b) requires data holders to 'state the period of time to which the CDR data that was the subject of the request relates'. The CX Guidelines demonstrate this with a note that this data may date back to 1st January 2017 (exampled on p.83 of v1.4.0). This generic date was chosen to reflect the legislation and because DHs will not know the specific historical range the ADR intends to collect. DH dashboard DHs are not required to show the historical data range on dashboards, but the CX guidelines (p.109) recommend it be shown to achieve consistency with rule 4.23(b) and the ADR recommendations. Similar to ADR dashboards, however, this information may end up on DH dashboards indirectly as a result of Privacy Safeguard 10. CDR Support Portal Article |
| 483 | Do we just need to show the names of the accredited third parties in the consent or do we also need to: - display their ADR numbers? - show their institutional logos? - any other details? The short question is - would it suffice if we just show their Institution names, comma separated? |
This enquiry has been addressed in Ticket #434 with the subject 'Showing Two ADR Numbers on Consent Page and Downloadable PDF'. With regard to logos and other details, the v2 rules wireframes provide a recommendation of what to include in the 'Supporting Parties' wireframe for '7.3 Separate Consents |
| 504 | Just wondering if middle initials, or what could potentially be a single letter middle names would be considered OK in the middleNames array of the person schema, or should we only include values if they appear to be full middle names (i.e. greater than 1 char.)? (ref. guidance on fully formatted phone numbers etc.) - https://consumerdatastandardsaustralia.github.io/standards/#tocScommonperson |
Regarding your question relating to middle initials for names. There is no hard and fast answer to this and we would expect the DH to apply their own discretion. That said, the general guidance would be: - If you know it is only an initial (i.e. it is stored in a "MiddleInitial" field or similar) then it would probably be more appropriate to leave it out. - If it is a case of some of the entries in the internally stored middle name field only include initials then there is no requirement to apply analytics or logic to correct the data on egress (although data clean up is probably good practice in general). CDR Support Portal Article |
| 506 | Can you please clarify which products are encompassed within 'Business Finance' at sub paragraph (a) within the Phase 3 product list in cl 1.4 of Schedule 3 of the Rules; and whether products such as a Business Savings Account (i.e. https://mystate.com.au/business/savings-investments/business-online-saver/) and Term Deposits for Business Banking (i.e. https://mystate.com.au/business/savings-investments/term-deposit/) fall under Phase 3 (as Business Finance Products) or Phase 1 (as a Savings Account / Term Deposit. The separate listing of: (c) a line of credit (personal); (d) a line of credit (business); (e) an overdraft (personal); (f) an overdraft (business); under Phase 3 creates some ambiguity in this regard, as to whether other products that are similarly offered separately to both business and personal customers are within the scope of phase 3, as Business Finance, or another phase if listed there without differentiation between (business) or (customer). |
‘Business finance’ is intended to cover business lending products, rather than deposit products. An example of a business finance product would be a ‘business loan’. Savings accounts and term deposits wouldn’t be categorised as ‘business finance’ products. We are unable to provide definitive advice in relation to every banking product that may fall within the product list. However, for further assistance in identifying which products are in-scope for the CDR, please see our guidance material here. |
| 509 | As per CDR rules, a person who is accredited at the unrestricted level must: “be a member of a recognised external dispute resolution scheme in relation to consumer complaints;” And Rule 6.1 says: “Data holders are required to be a member of a recognised external dispute resolution scheme in relation to CDR consumer complaints. Accredited data recipients are also required to be a member of the scheme under the accreditation rules. For the banking sector, the ACCC intends to recognise AFCA.” A company that provides digital identity verification for AML/KYC purposes, based on CDR data, must be a member of AFCA? |
That’s correct – the CDR Rules require that all Data Holders and Accredited Data Recipients be a member of a recognised external dispute resolution scheme in relation to CDR consumer complaints [sub-r 5.12(1) and r 6.2]. The Australian Financial Complaints Authority is the only external dispute resolution scheme recognised by the ACCC for banking CDR data: see Competition and Consumer (External Dispute Resolution Scheme–Banking Sector) Instrument 2019. CDR Support Portal Article |
| 510 | For Direct Debit - Authorised Entity where the description= the description of the authorised entity derived from previously executed direct debits, can you please provide the purpose of this attribute and provide an example? | The authorised entity is the originating source of the debit from the customer's account. This is the merchant the customer has given authorisation to debit an account directly. An example would be AGL for a quarterly direct debit for an electricity bill, or Telstra for a monthly phone or internet bill. The following articles might also be useful: https://cdr-support.zendesk.com/hc/en-us/articles/900001966566-Direct-Debits https://cdr-support.zendesk.com/hc/en-us/articles/900004993163-Definition-of-Financial-Institution https://cdr-support.zendesk.com/hc/en-us/articles/900004393806-External-vs-Internal-Direct-Debits |
| 513 | We are wondering if it is mandatory that a DH allow a consent (i.e. for customer details, payees) with no associated accounts. This may occur due to either (a) customer doesn't want to select any accounts in the Account selection step, or (2) the customer has no available eligible accounts to select. Can they still request their customer data only? The CX Guidelines seem to suggest it is optional to offer this: Pg 80: "Data holders MUST allow the consumer to select which of their accounts to share data from if the data request includes account-specific data and if there are multiple accounts available. ● Data holders MAY omit this step if none of the data being requested is specific to an account (e.g. Saved Payees)." However the CDR Rules suggest this may be mandatory, given the use of the word "or" when detailing "customer data" as a sub-type of "required consumer data" - 3.2(1) (1) For these rules, subject to this clause, required consumer data, in relation to the banking sector, means CDR data for which there are one or more CDR consumers: (a) that is within a class of information specified in the banking sector designation instrument; and (b) that is: (i) customer data in relation to a CDR consumer; or This new query builds on this existing question (https://cdr-support.zendesk.com/hc/en-us/articles/900003286226-Consent-with-no-attached-accounts-), which confirmed these no-account consents can exist. |
It is mandatory for a data holder to allow a consent with no associated accounts, meaning that a CDR consumer may request their customer data only. This is the position under both the CDR Rules and the technical data standards. The CX Standards/Guidelines only refer to the account selection step being optional where the requested data does not relate to accounts (e.g. only customer data is requested). This is to support scenarios where data unrelated to accounts is being requested. CDR Support Portal Article |
| 515 | We have grandfathered products that are not publicly offered, but have these products on accounts are still active. 2 questions: 1) If the accounts are still active, but not product publicly available, should we be including in PRD? 2) If they are grandfathered, and not in PRD, how should they be displayed if the customer chooses to share? We have tested one and it showed NULL, which wouldn't be an ideal experience. After some guidance here. |
Q: If the accounts are still active, but not product publicly available, should we be including in PRD? A: No. PRD should only contain products that are actively offered on market, about to be offered on market or recently withdrawn (you can use the effective dates to ease products in and out prior and after availability). Q: If they are grandfathered, and not in PRD, how should they be displayed if the customer chooses to share? We have tested one and it showed NULL, which wouldn't be an ideal experience. After some guidance here. A: It isn't exactly clear where the null you refer to is being returned but I will try and provide clarify: - For accounts that are instantiated but the product is no longer available then they should not appear in the PRD end points. - For accounts that are active then a valid request for account details should return the fees, rates, features, etc for that product as it is instantiated (including any negotiated discounts or special arrangements). This should be information specifically for the account and not general information. For instance, a Term Deposit in PRD will have many rates as the actual rate depends on how long the arrangement is for and the starting balance. For an instantiated account there is no longer this flexibility. The duration and balance are known so there should only be one set of applicable rates. CDR Support Portal Article |
| 525 | Our developers are seeking clarification regarding the traffic threshold for unattended traffic, defined in the non-functional requirements of the CDS: https://consumerdatastandardsaustralia.github.io/standards/#traffic-thresholds Specifically, does the use of ‘data recipient’ in the requirement of ‘20 sessions per day, per customer, per data recipient’ mean this threshold should be applied at a brand level for data recipients, or should this limit be enforced per software product ID? |
This is per software product. The term Data Recipient in the data standards is defined in the CDR Federation section (https://consumerdatastandardsaustralia.github.io/standards/#cdr-federation) and there is a Definitions section (https://consumerdatastandardsaustralia.github.io/standards/#definitions) in the NFR section that might also be helpful to you. This is meant to be read as the oAuth client (ADR Software Product). |
| 528 | Are the APIs where bulk data is to be fetched like Get Bulk Balances and Get Bulk Scheduled payments in context of a customer like the Get Accounts API? Do we need to pass the Customer Id in the request? If yes, how will this be passed in the API request? |
all authenticated APIs should be responded to in the context of the consumer that authenticated with the Data Holder. The customer context is provided by way of the Access Token that the ADR sends to the DH in the Authorisation header, including for the two APIs you mention. CDR Support Portal Article |
| 529 | On receiving authorization by the customer, when an ADR calls the Data Holder's Get Account Details API with the Request URI GET /banking/accounts/{accountId} for disclosure of data, we understand that the ADR will provide a reference id generated by the Data Holder in accordance with the ID Permanence Rules. But, how would the ADR get the reference id in first place to pass it in the Get Account Details API request? |
the ADR would first call the Get Accounts API to get the list of accounts associated with the consumer's consent. The accountId is a response field in the BankingAccount object. CDR Support Portal Article |
| 530 | This is regarding the URI standards defined in the specification (https://consumerdatastandardsaustralia.github.io/standards/index.html#uri-structure) Here are our queries on the same: As we understand this is applicable for resource server only, are there structure standards defined for the security profile endpoints ? Standards allow different data holder paths for authenticated and unauthenticated endpoints. Can the data holders have different paths for security profile endpoints and banking endpoint ? Below are some of the examples based on the various combination, does this align with standards and best practices ? Unauthenticated Resource URL:- http://openbanking.api.bankname.com.au/cds-au/v1/banking/products Authenticated Resource URL:- http://openbanking-secure.api.bankname.com.au/cds-au/v1/banking/account Unauthenticated security profile URL:- http://openbankingidp.api.bankname.com.au/.well-known/openid-configuration Authenticated security profile URL :- http://openbankingidp-secure.api.bankname.com.au/arrangements/revoke |
Q: As we understand this is applicable for resource server only, are there structure standards defined for the security profile endpoints ? A: Yes the structure for these end points are defined by the normative standards that are referred to (specifically the structure is relatively open with the end points being defined by the DH in the OIDD compliant discovery document). Q: Standards allow different data holder paths for authenticated and unauthenticated endpoints. Can the data holders have different paths for security profile endpoints and banking endpoint ? A: Yes. The register specifically allows for multiple base URIs for multiple purposes. This is documented here. This includes a specific base URI for the Information Security profile end points. Note that you can reuse the base path for multiple entries but this is sometimes difficult due to the various TLS configurations that are required. Q: Below are some of the examples based on the various combination, does this align with standards and best practices ? Unauthenticated Resource URL:- http://openbanking.api.bankname.com.au/cds-au/v1/banking/products Authenticated Resource URL:- http://openbanking-secure.api.bankname.com.au/cds-au/v1/banking/account Unauthenticated security profile URL:- http://openbankingidp.api.bankname.com.au/.well-known/openid-configuration Authenticated security profile URL :- http://openbankingidp-secure.api.bankname.com.au/arrangements/revoke A: There is no real best practice define but the structure described above is aligned to what was intended and also compliant with the standards (noting that I have bolded the URL components that are specifically base paths). CDR Support Portal Article |
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.
| Ticket # | Question | Answer |
|---|---|---|
| # | Question | Answer/ Action |
|---|---|---|
| Organisation | Description | Link |
|---|---|---|
| OAIC | Main landing page for the Office of the Australian Information Commissioner and the Consumer Data Right | Link |