Skip to content

ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 27th of January 2022

Jump to bottom
elizabetharnold edited this page Jan 28, 2022 · 18 revisions

ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes

When: Weekly every Thursday at 3pm-4.30pm AEDT
Location: WebEx, quick dial +61-2-9338-2221,,1650705270##

Meeting Details:

Desktop or Mobile Devices https://treasuryau.webex.com/treasuryau/j.php?MTID=m9614a7c6166155d3d950a8999e437f9f 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: 1650705270@webex.com

Phones - AUDIO ONLY

Agenda

  1. Introductions
  2. Actions
  3. CDR Stream updates
  4. Presentation
  5. Q&A
  6. Any other business

Introductions

  • 5 min will be allowed for participants to join the call.

Recording

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.

Acknowledgement of Country

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.

Updates

Type Topic Update
Standards Version 1.15.0 Published Link to change log here
Maintenance 10th Maintenance Iteration To commence on 16th of February 2022
TSY Newsletter To subscribe to TSY Newsletter Link here
DSB Newsletter To subscribe to DSB Newsletter Link here
TSY Newsletter 25th of January 2022 View in browser here
DSB Newsletter 21st of January 2022 View in browser here
Consultation Normative Standards Review (2021) No Close Date
Link to consultation
Consultation Decision Proposal 225 - Data Recipient Security Standards Feedback closes 18th of February 2022
Link to consultation
Consultation Decision Proposal 229 - CDR Participant Representation Placeholder: no close date
Link to consultation

CDR Stream Updates

Provides a weekly update on the activities of each of the CDR streams and their stream of work

Organisation Stream Member
ACCC CDR Register Hopeson Chiao
ACCC CTS Andrea Gibney
ACCC Onboarding Christine Atkins
DSB CX Standards Michael Palmyre
DSB Technical Standards - Register Ivan Hosgood
DSB Technical Standards - Energy James Bligh
DSB Technical Standards - Banking Mark Verstege
DSB Technical Standards - Engineering James Bligh

Presentation

Data Standards Body - Tomas Schier - API postman tests and schemas.

  1. Demonstrate how DSB schema definitions are being used in a Postman collection
  2. Demonstrate the use of the Postman collection and how these tests can be run against APIs

The Postman collection can be found in the public dsb-schema-tools repository here: https://github.com/ConsumerDataStandardsAustralia/dsb-schema-tools

Q&A

Questions will be received by the community via WebEx chat before the questions are opened to the floor. Participants can submit questions outside of the CDR Implementation Call to the CDR Support Portal.

We are using Sli.do for Question and Answer. Join our Q&A live here: https://www.sli.do/ Code: #169517

Answer provided

The following table will be updated after the meeting.

Ticket # Question Answer
939 We think the concept of a Reciprocal Data Holder applies to our clients, but are confused as to how it works and what they will need to have in place to comply with CDR participation. Your site suggests the following: "An accredited person may be subject to reciprocal data holder obligations. This means that an accredited person may be required to share particular CDR data at particular times in accordance with the obligations of a data holder under the CDR Rules, separate to the obligations of an accredited person." What is the difference between an "Accredited Person" and "Data Holder" obligations? In our potential client scenario we see the entity (Lender) being someone - "where the data is generated in respect of a product that is publicly offered by the accredited person to consumers and generally known as one of the types of products in Phase 1, Phase 2 or Phase 3 products." Therefore is the "Accredited Person" the entity offering the product and if so, how do they become "Accredited" and is it as a DH or ADR to be recognised as a "Reciprocal Data Holder"? An accredited data recipient will be a data holder for certain data where the entity holds data specified in the designation instrument and that data was not transferred to it under the consumer data rules (or derived from such data) [subsection 56AJ(3) of the Competition and Consumer Act]. This could occur where the accredited data recipient provides similar services to an entity listed in the designation instrument. For example, a non-ADI lender would hold transaction information about credit provided to its customers but as it is not an ADI it would not be a designated data holder under the relevant designation instrument. Please note there is some information in the ACCC's revised Accreditation Guidelines on reciprocal data holder obligations that may assist with your enquiry. The revised Guidelines are available at https://www.cdr.gov.au/sites/default/files/2021-10/CDR-accreditation-guidelines-v3-published-29-October-2021.pdf
958 "Is it a mandatory requirement for Data Holders to retain customer's transaction data of Open accounts for 7 years? as there are organisations that regularly purge the data or just keep the 12 months data in core banking system. Its bit confusing from the following rule: CDR data is not required consumer data at that time: (a) transaction data in relation to a transaction that occurred more than 7 years before that time;" Where purging has occurred a data holder may no longer have access to transaction data accessible on their core banking system that dates back 7 years (or to the earliest required date of 1st January 2017). We note that one of the rules relating to Required Consumer Data is that it is held by the data holder in a digital form which indicates purged transactions are no longer required consumer data. Can you please confirm if the question raised in the implementation call has been responded to or alternately provide clarification on this scenario? Is it a requirement for data holders to ensure that transactions remain accessible for a 7 year period moving forward? The current CDR rules state that required consumer data includes transaction data that is dated after 1 January 2017, held in a digital form and is not data from a transaction that occurred more than 7 years ago. Under the current rules, it is expected that data holders retain their customer’s transaction data of open accounts for a period of 7 years unless the data holder has received an exemption granted by the ACCC under section 56GD of the Competition and Consumer Act 2010 (Cth). It is also expected that data holders’ data purging practices align with this requirement. If a data holder has concerns about meeting this obligation, we suggest they engage with Treasury (as the rule maker) to express concerns about this requirement.
987 If a product is not available to customers via a digital channel currently, is the DH still required to share that data? Good example is Equipment loan, as mentioned in this Knowledge article https://cdr-support.zendesk.com/hc/en-us/articles/900003420066-Guidance-for-data-holders-CDR-products-and-eligible-consumers-updated-20-January-2021- If the DH is not exposing this information to consumers is any of their digital channels do we still need to expose this as CDR Data? The document refers to : "Product can be obtained by means other than via a relationship manager " as an application factor. If there is no digital channel and we are forced to expose this data via CDR, it means the bank should also expose this data via their digital channel. It would be strange to expose data only to an ADR via the CDS APIs and the customer can't access it digitally via their DH applications. In my mind, things were simple - Only products that were digitally exposed by the DH will become an eligible product in the CDR regime. As set out in the guidance, we note that data holder must provide a service enabling an eligible CDR consumer to make consumer data requests in relation to the in-scope products provided to them by the data holder. The ACCC considers it appropriate for a data holder to meet CDR obligations by leveraging (at a minimum) its primary retail and primary business digital banking channels. More information about how to assess whether a product is 'in scope' is available in the guidance.
993 To comply with 9.3 (1)(g) the processes by which the data holder asks CDR consumers for their authorisation to disclose CDR data and for an amendment to their authorisation, including a video of each process - are we able to make the video recording of our test environment using test data or do we need to record this from our production environment? The video process of the authorisation flow required to be kept and maintained under rule 9.3(1)(g) should demonstrate the real-life consumer experience for a consumer seeking to authorise data sharing by the data holder. We understand there may sometimes be changes between activities occurring in the test environment and in the production environment. If there are any such changes to the authorisation process following the deployment into the production environment, we would expect the data holder to record the process the consumer would see.
1054 As a Data Holder, we are currently working through the reporting & audit requirements and would like confirmation on our understanding of the below. Division 9.3 Reporting, record keeping and audit Subdivision 9.3.1 Reporting and record keeping 9.3 Records to be kept and maintained Records to be kept and maintained—data holder 1. A data holder must keep and maintain records that record and explain the following: b. amendments to or withdrawals of authorisations to disclose CDR data; Is it correct to assume for item b. that amendments to an authorisation can be grouped under the same scenario of a withdrawal, since they both follow the same technical treatment. Therefore, we don’t need to spit these out in our records? While a data holder might technically treat amendments to an authorisation and withdrawals of an authorisation in the same way, it is expected that these records would record and explain whether the relevant record relates to an amendment or a withdrawal of an authorisation.
1064 Non-account data on Secondary User consent arrangements: Is there in rules or guidance relating to what non-account data is to be shared under consent arrangements entered into be Secondary Users? There is a knowledge base article clarifying the customer detail of the Secondary User is to be shared when that SU has authorised data sharing that includes a secondary user account. However, what is to happen if the scope includes other non-account data such as saved payees? Does this include saved payees of the Secondary User, Account Holder or both?
1085 For the required Internal resolution process, CDR, Data Sharing and Data Security Policies which need to be developed as part of the accreditation process, are there any templates which can be used or specific guidelines around the format and content which needs to be followed? Who would normally develop those policies and are there any specific criteria which need to be fulfilled i.e. “needs to be signed by lawyer, developed by authorised auditor” etc.? In relation to Internal Dispute Resolution, policies must comply with the ASIC Regulatory Guide 271 https://download.asic.gov.au/media/3olo5aq5/rg271-published-2-september-2021.pdf in relation to the items specified at schedule 3, clause 5.1 of the CDR Rules. In relation to required Data Security Policy, please refer to the ACCC's Supplementary Accreditation Guidelines: Information Security https://www.accc.gov.au/system/files/CDR%20Accreditation%20-%20Supplementary%20Accreditation%20Guidelines%20Information%20Security%20-%20April%202021.pdf. For further information about requirements for CDR Accreditation please see the ACCC's Accreditation Guidelines https://www.accc.gov.au/system/files/CDR%20-%20Accreditation%20Guidelines_0.pdf.
1126 In GetMetrics API, if an authenticated High tier API(let's say Get Accounts) responds back with 404 Not Found and 405 Method not allowed, do we have to count those requests as valid invocation? If the answer is yes, where do we capture that count, in the authenticated section or in unattended section? Examples: GET /banking/account -> Response for 404 (resources not found due to missing s in the URL) DELETE /banking/accounts -> Response for 405. Will above cases need to count in GetMetrics? This is an interesting question. In both situations you describe an invalid resource request. For 405 this implies an invalid method is attempted against a resource. This would mean that there is no invocation from the perspective of the data standards because the method plus resource do not exist. For 404, if the error is resulting from an invalid (permanently unavailable or unknown) resource, this wouldn't be an invocation. This would mean that there is no invocation from the perspective of the data standards because the resource does not exist. If the error is a 404 due to a temporarily unavailable account, it would be considered an invocation. This answer is specific to the error codes you have provided. If the error is related to a known resource and an error (such as 400) is raised, this would be considered as an invocation of the API.
1133 With regard to once-off consent, how should it be presented on the data recipient's dashboard (via collection arrangement)? 1. Do we need to allow hard-deletion of the once-off consent (after the data has been used - given the duration of the consent is absent or 0)? Or could we still retain the data by de-identifying it and marking it as "deleted" for the end user? AND 2. Do we still need to display "Additional uses of data" and "Third Parties" in case of a once-off consent? We cannot provide individual compliance advice and we recommend that CDR participants seek advice from their internal or external advisors. It is the responsibility of CDR participants to determine how they will comply with the CDR Rules. However, we note the following: Without being exhaustive, you may find the following rules to be relevant to your first question: 4.11(1)(e), 4.11(3)(h), 4.16, 4.17, 4.18A, 7.2, 7.12 and 7.13. You can also find information about Privacy Safeguard 12 (Security of CDR data and destruction or de-identification of redundant CDR data) on the OAIC’s website. Note that accredited data recipients of CDR data must also take the steps set out in the CDR Rules (see subdivision 1.4.5) to destroy or de-identify any CDR data that is no longer needed for: the purposes permitted under the CDR Rules, or any purpose for which the information may be used or disclosed under the privacy safeguards. Consumers can request that their CDR data be deleted once it is no longer needed. Accredited data recipients of CDR data must delete CDR data that is subject to a deletion request unless an exception applies. An ADR cannot state they are deleting data if they are actually de-identifying it. In response to your second question – note that once of consents are subject to the same consent requirements as ongoing consents. See CDR rule 1.14 for information about what must be included about consent on an ADR’s dashboard and Division 4.3 for more information about the process for consent.
1156 1 Trusted Advisers a. A mortgage broker has need to share data with their Licensee and Aggregator for compliance purposes. They also utilise aggregator CRM’s and Loan Management systems. Given that data provided is deemed to have ‘left the CDR ecosystem’, is this data distributed by a TA deemed to be CDR Data or derived CDR data and hence subject to the Privacy Principles? 2) Outsourced Service Providers – As per Rule 1.10, Meaning of outsourced service provider and CDR outsourcing arrangement :  an outsourced service provider is a person to whom an accredited person discloses CDR data under a CDR outsourcing arrangement  person (the discloser) discloses CDR data to another person (the recipient) under a CDR outsourcing arrangement if it does so under a written contract between the discloser and the recipient under which: (a) the recipient will provide, to the discloser, goods or services using CDR data; a. Has further guidance or clarification been issued on the definition of ‘disclosure’ and provision of ‘goods and services’? b. For example, i. Cloud hosting services ii. Document storage facilities including CRM’s (which don’t access the data) iii. Loan lodgement systems which facilitate transfer of data b) Regarding CDR Representative Engagement using a Third Party• Example – If an ADR “ABC” wishes to enroll Fintech “XYZ” as a CDR Representative and Fintech “XYZ” utilizes Cloud Service providers ML services for running machine learning algorithms on CDR data then ADR “ABC” will need to enrol the Cloud Services Provider as its OSP so that Fintech “XYZ” continue to use it services under CDR Rules, please confirm? • Example – If in the above scenario, Fintech XYZ wishes to have the direct relationship with Cloud Service provider for using its ML services then Fintech XYZ has be become an Affiliate to have an Outsourcing Arrangement with the Cloud Service provider to disclose CDR data to obtain its services, please confirm? 3) Data retention a. Those who participate in consumer lending have an obligation to retain supporting documentation for a period of 7 years. Has any guidance been issued to indicate exemption and/or additional disclosures required regarding data deletion / de-identification While we cannot provide specific compliance advice, we hope the below information will assist. For information about the privacy obligations of trusted advisors, you may wish to review this guidance produced by the Office of the Australian Information Commissioner (https://www.oaic.gov.au/consumer-data-right/guidance-and-advice/trusted-advisers-in-the-Consumer-Data-Right-system). The OAIC has also recently published guidance on the privacy obligations of outsourced service providers, CDR representatives and CDR principals and sponsors that may assist with your second question – these documents can be accessed on the OAIC’s website here (https://www.oaic.gov.au/consumer-data-right/guidance-and-advice). However, we note that neither a CDR representative or an affiliate can directly engage an outsourced service provider. With regard to your third question - note that under section 56EO of the Competition and Consumer Act 2010, if a CDR entity is required to retain the redundant data by or under an Australian law, then the obligations specified in the consumer data rules to destroy or de-identify the redundant data do not apply to that data.
1184 1. Would it be in the scope of the rules if we auto-allocate Nominated Representative status to all individuals who are listed as owners on the accounts of the Non-Individual entity or partnerships (e.g. for a company - the directors, or for a partnership - the partners), given they will have the power to make / revoke the nominations anyway? Or is it mandatory that electing the nominated representatives be opt-in (i.e. a specific positive instruction by the relevant owners of the non-individual entity)? 2. Can you have a Secondary User on a Non-Individual Account? 3. Do Secondary Users and Nominated Representatives need to meet the same eligibility criteria as a CDR consumer, to be able to be nominated? I.e. do they need to be over 18 and have online access to the account? 1. Rule 1.13(1)(c) is intended to be non-prescriptive and does not prevent a data holder automatically assigning a nominated representative to a particular account if that is consistent with the way the business consumer usually manages the account with the data holder. Where a data holder prefers to adopt an automated process for nominating individuals and there are multiple individuals listed as owners of a non-individual or partnership account, the data holder should inform the consumer of its process of automatically nominating representatives and provide them with the opportunity to choose not to be nominated. 2. The secondary user rules only apply to accounts held by individual/s aged 18 years or older 3. A secondary user must be a person that is an individual who is 18 years of age or older that has account privileges in relation to an account that is in-scope for the CDR (see definition of ‘secondary user’ at rule 1.7). A nominated representative must be an individual aged 18 years of age or older, who has been nominated by a non-individual consumer or partnership using the service provided by the data holder under rule 1.13(1)(c). The nominated representative does not need to have online access to the account prior to being nominated.
1208 Please provide a few examples of what "outsourced service providers" could be? The meaning of outsourced service provider is outlined in rl 1.10 of the CDR Rules. The ACCC’s Supplementary Accreditation Guidelines – Information Security gives a non-exhaustive list of situations where an accredited person may choose to use an outsourced service provider which include: data centres and backup providers, SaaS (Software as a service) providers, PaaS (Platform as a service) providers, and cloud based service providers.
1244 Question on notice CDR Implementation Call 9th of December 2021. Requesting clarifying statement from the ACCC on where the liability rests with Joes Finance (CDR Rep or Affiliate) if they misuse data. Liability of CDR representatives and affiliates. Please note that the OAIC has recently published guidance on the privacy obligations of CDR representatives and affiliates at https://www.oaic.gov.au/consumer-data-right/guidance-and-advice. In general, as an affiliate and their sponsor are both accredited persons, each entity will be liable in their own right for their handling of CDR data. In addition, where a sponsor collects a consumer’s CDR data at the request of their affiliate, that data is taken also to have been collected by the affiliate (CDR Rule 7.6(3)). This ensures that the limitations on permitted uses and disclosures in Subdivision 7.2.3 apply to affiliates when they have used their sponsor to collect data from data holders. In contrast, a CDR representative is unaccredited. A CDR representative receives CDR data from their CDR principal, and uses that CDR data to provide goods or services directly to the consumer. Under this arrangement, the CDR principal is liable for the actions of the CDR representative. More information about sponsorship arrangements and CDR representative arrangements, including examples of when each could be used, is available in the explanatory statement to the amending instrument for the Version 3 CDR Rules (https://www.legislation.gov.au/Details/F2021L01392/Explanatory%20Statement/Text). Dashboard/software product issue Under 7.9(1)(c) a data holder is required to update the consumer dashboard to indicate the accredited data recipient to whom CDR data has been disclosed to, identified in accordance with any entry on the Register of Accredited Persons specified as being for that purpose. For sponsor/affiliate relationships – if the unrestricted ADR/sponsor uses a single software product for multiple sponsored affiliates and the data holder is unable to readily identify the relevant affiliate on whose behalf a sponsor is making a consumer data request, it would be sufficient for the data holder to provide the details of the sponsor ADR on its consumer dashboard.
1258 1. Response Code: As part of rule 4.7, if Data Holder refuses to provide any information, then need to inform ADR. As per Accounts that cannot be shared – Consumer Data Standards Australia (zendesk.com), I think DH will have to use 422 response code (unavailable Energy Account) for such scenario but would like to understand how this refusal can be communicated when there are some accounts of a customer can be shared and not all. In GetEnergyAccount API, there is no 422-response code. In this case, how does DH communicate to ADR? OR When there are some set of specific account IDs passed in following API and only few accounts data can be shared (not all), Can DH respond with negative response (422) for whole API call? Get Invoices For Specific Accounts Get Billing for Specific Accounts Get Invoices for Specific Accounts
2. Following APIs are to provide the response based on the list of Accounts passed in the request. Is there any maximum limit on the number of Accounts to be passed by ADR to DH? Get Invoices For Specific Accounts AND Get Billing for Specific Accounts AND Get Invoices for Specific Accounts
3. Cancelled/Reversed Bills - Are Data Holders expected to provide cancelled bills to ADR? If yes, what field is used to use to denote the status of transactions? Relevant APIs referred here,Get Invoices Get Billing
4. EA understands the data latency requirement being the same as the incumbent primary digital channel; however, in the events where this may not be possible, EA is keen to understand if there are any allowable data latency in relation to customer, account and billing data
5. Similar to Question #1, we will also have similar issue for Bulk API calls (following APIs) GetBulkInvoices and GetBulkBilling. Example Scenario: if a request to provide the invoices of all authorised accounts (Say Customer has 2 Accounts) via GetBulkInvoices API call but no Invoices are yet issued on these two accounts, what response code should be returned for Bulk API call? Note: As this question #5 is similar to question #1, have posted in the existing request.		 1. You can use other error codes apart from the ones specified in the API response section. The section highlights the error codes that MUST be supported for that API. The Error Codes section of the standards provide a complete list of all the codes that MUST, SHOULD and MAY be supported across the standards. If the reason/context for error is appropriate, you could use 422 for GetEnerygAccount API. With regards to which error code to use if DH refuses to provide information, it would depend on the reason for refusal. If it is to do with protecting the consumer from potential harm (as per 4.7 (a)) you could use 422 if the request account was in the body or 404 if the requested account was specified in the path or you could use one of the general errors. You would want to minimise the details in the response as it can cause potential harm if more error information is disclosed. 2. There is no upper bound on number of accounts that could be requested, however there is an upper bound of 1000 records on pagination in the response. In reality though, we should (hopefully) never see a situation where there will be 1000’s of accounts in request. 3. This is a rules question, TBA. 4. It is important to have the same experience for a consumer as the DH’s primary digital service/channel, accordingly the data latency should be commensurate to data presented via DHs other primary digital channels. We wouldn’t want a situation where, for e.g., a customer can get their latest bill from DH’s digital channel but would have to wait for 24 hours to get it via CDR. What scenario/example did you have in mind where the data latency would be different? 5. Since the accounts are valid and exist (and assuming the request is well formed and consumer has given consent) you would return a 200 OK response with empty array.
1268 Please could you validate my assumptions regarding documentation and endpoint versioning? 1. Documentation major version changes may cause a change in some, but not necessarily all, endpoint versions, e.g. a change in security profile would not change the version of unauthenticated endpoints 2. Documentation major version changes will impact the segment of all endpoint URIs, even if the change does not specifically relate to a particular class of endpoints, e.g. a change in security profile and unauthenticated endpoints 3. Multiple documentation major version endpoints (e.g. v1 and v2) will need to be available in production, even if the reason for the documentation version change does not specifically relate to a particular class of endpoints, e.g. a change in security profile would still require unauthenticated endpoints v1 and v2 to be available, until the v1 retirement date 4. Endpoint version changes generally occur due to response schema changes, e.g. BankingProductFeatureV2 and the new featureType enum values 5. Endpoint version changes would also occur due to query parameters changes. 6. An endpoint version is related to a documentation major version such that an endpoint version is supported by a data holder from its binding date and from the documentation major version in which it was first introduced. For example, endpoint x-v 2 introduced under CDS v2 would not be supported under CDS v1, and this is true irrespective of whether endpoint x-v 2 is backwards compatible with CDS v1, i.e. a change in security profile and unauthenticated endpoints Q: Documentation major version changes may cause a change in some, but not necessarily all, endpoint versions, e.g. a change in security profile would not change the version of unauthenticated endpoints A: We define a 'major' change as, by definition, changing all APIs as it would result in a regime wide change to the version in the base path. We don't anticipate changes like this occurring very often. Q: Documentation major version changes will impact the segment of all endpoint URIs, even if the change does not specifically relate to a particular class of endpoints, e.g. a change in security profile and unauthenticated endpoints. A: Yep! Q: Multiple documentation major version endpoints (e.g. v1 and v2) will need to be available in production, even if the reason for the documentation version change does not specifically relate to a particular class of endpoints, e.g. a change in security profile would still require unauthenticated endpoints v1 and v2 to be available, until the v1 retirement date. A: This is a fair assumption but we've never tested it because it hasn't happened yet. We wouldn't do this without consultation. Q: Endpoint version changes generally occur due to response schema changes, e.g. BankingProductFeatureV2 and the new featureType enum values. A: Yes, although they can change due to underlying logic also. Basically, anything that would be breaking for the client with a heavy bias towards assuming a change is breaking. Q: Endpoint version changes would also occur due to query parameters changes. A: If it was considered breaking. For instance, removing support for an existing query parameter maybe wouldn't require a version change. We specifically don't have a definition of 'breaking change' and consult case by case. Q: An endpoint version is related to a documentation major version such that an endpoint version is supported by a data holder from its binding date and from the documentation major version in which it was first introduced. For example, endpoint x-v 2 introduced under CDS v2 would not be supported under CDS v1, and this is true irrespective of whether endpoint x-v 2 is backwards compatible with CDS v1, i.e. a change in security profile and unauthenticated endpoints. A: Our intention is that when we introduce major version 2 we would go back to v1 for all endpoints because they would be on different paths entirely. There is likely to be a requirement to maintain v1 for a parallel period though. Further clarification on this final question Q: To clarify, are you saying that a major version change (e.g. v2) would cause all endpoint versions to be reset back to x-v 1, and under the previous major version (e.g. v1) those same endpoints would still be at whatever version they got to. A: Yes.
1272 How should the profile scope be represented in sharing request details screen for Individual consumer? if OIDC profile, and common:customer.detail:read are both requested, instead of a merged cluster information, are we expected to display: Name - Full name and title(s) Contact Details - Phone number;Email address;Mail address; Name, occupation, contact details ‡ - Name;Occupation;Phone;Email address;Mail address;Residential address; This would mean that the Name and Contact information is being displayed twice to the user ? How should the profile scope be represented in the sharing request details screen for Non-individual consumer? if OIDC profile, and common:customer.detail:read are both requested, are we expected to display: Name - Full name and title(s) Contact Details - Phone number;Email address;Mail address; Organisation profile and contact details *‡ - Agent name and role;Organisation name;Organisation numbers (ABN or ACN),†Charity status;Establishment date;Industry;Organisation type;Country of registration;Organisation address;Mail address;Phone number The data language should not be merged. It is intended to be shown separately. Refer to: https://consumerdatastandardsaustralia.github.io/standards/index.html#profile-scope The data language provides information to the consumer on the data clusters (and data represented within those data clusters) they are consenting to. [Question] This would mean that the Name and Contact information is being displayed twice to the user ? [Answer] Each data cluster and subsequent language must be shown to the consumer separately. The CX guidelines may be useful in this respect: https://www.notion.so/Collection-and-use-consents-fcf5e47455274d26b028d218b22f017a [Question] How should the profile scope be represented in the sharing request details screen for Non-individual consumer? [Answer] The data language standards provide requirements for displaying non-individual consumer customer data. The data language for the profile scope would be the same because the profile scope represents data related to the authenticated end user.
1281 Per the rules definition of Secondary User: -- Secondary user: a person is a secondary user for an account with a data holder in a particular designated sector if: (a) the person is an individual who is 18 years of age or older; and (b) the person has account privileges in relation to the account; and (c) the account holder or account holders: (i) are individuals each of whom is 18 years or older; and (ii) in accordance with the requirements for the account, have given the data holder an instruction to treat the person as a secondary user for the purposes of these rules. And per the meaning of written for account privileges: -- 2.2 Meaning of account privileges—banking sector (1) This clause is made for the purposes of the definition of account privileges in subrule 1.7(1) of these rules. (2) For the banking sector, a person has account privileges in relation to an account with a data holder if: (a) the account is for a phase 1, a phase 2 or a phase 3 product; and (b) the person is able to make transactions on the account. Can I confirm that even if the account is closed, that does not construed it mean that the person has now lost the ability to make transactions ( since no one can) ? And therefore, it SHOULD not be a condition to consider the person is now ineligible as a secondary user. And they should still be able to share the closed account if the account holder has provided Secondary User Instruction for them. There are actually two different points here so I'll respond to them separately. I'll also caveat that these are really rules questions which the rules team have said that data holders need to be make their own assessments of so I can only provide my expert opinion on these topics. Q: Can I confirm that even if the account is closed, that does not construed it mean that the person has now lost the ability to make transactions ( since no one can) ? And therefore, it SHOULD not be a condition to consider the person is now ineligible as a secondary user. A: Yes, this would appear to be a valid interpretation. Note that for a user to have permission to transact on an account is different to their ability to actually perform a transaction. For instance, they would not be able to transact if the balance was zero, the account was locked or if they had reached a daily transaction limit. Their status as having permission is different from a transaction actually being executable. In this context their permission status hasn't changed as it was never revoked. They still have permission to transact (which is the part that is important for the rules) they just can't because the account is closed. Even the primary account holder can't transact on a closed account. Q: And they should still be able to share the closed account if the account holder has provided Secondary User Instruction for them. A: Yes, but even if the answer to the first question was "no" then data sharing would still occur. If a secondary user ceases to have account privileges then they lose their ability to influence data sharing at all as they no longer have influence over the account.
1301 Based on the shared responsibility definitions in v1.15.0 and consultation #192, AEMO (secondary Data holder) exposing around 6 end points to meet the 8 APIs defined by DSB. Would like to understand the list of details (like NMI or from FRMP ID etc.,) that AEMO expecting (in request) from Primary Data Holder to provide response as per DSB schema? Would like to know if there is any AEMO technical document published with details and specification of these 6 end points? You can find the details around AEMO endpoints on the standards page here - https://consumerdatastandardsaustralia.github.io/standards/#shared-responsibility. The endpoints implemented by AEMO will be identical to retailer exposed endpoints with some variations (e.g. populating servicePointID attribute with NMI) which are listed on the above link. The information security profile to be used between retailers and AEMO was consulted on in DP 191 - https://github.com/ConsumerDataStandardsAustralia/standards/issues/191, the decision (based on feedback) stipulating the use of existing AEMOs e-hub security profile with AEMO being delegated the responsibility of documentation of the security profile.

Useful Links

View a number of informative and useful links in the Consumer Data Standards Implementation Guide on Information Links.

Getting Started

Meetings

Maintenance Iterations

CDR Implementation Call

Clone this wiki locally