ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 13th of April 2023

CDR Implementation Call Banner

Agenda & Meeting Notes

When: Weekly every Thursday at 3pm-4:30pm AEST
Location: Microsoft Teams
Meeting Details: Join on your computer, mobile app or room device Click here to join the meeting
Meeting ID: 446 019 435 001
Passcode: BU6uFg
Download Teams | Join on the web
Join with a video conferencing device
[email protected]
Video Conference ID: 133 133 341 4
Alternate VTC instructions Or call in (audio only)
+61 2 9161 1229,,715805177# Australia, Sydney Phone Conference ID: 715 805 177# Find a local number | Reset PIN
Learn More | Meeting options

Agenda

Introductions
Actions
CDR Stream updates
Presentation
Q&A
Any other business

Introductions

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

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.

House Keeping

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 [email protected] should they have any further questions or wish to have any material redacted from the record.

Community Guidelines

By participating in the Consumer Data Right Implementation Call you agree to the Community Guidelines. These guidelines intend to provide a safe and constructive space for members to discuss implementation topics with other participants and members of the ACCC and Data Standards Body.

Updates

Type	Topic	Update
Standards	Version 1.22.1 published 22nd of March 2023	Version 1.22.1 Change Log
Standards	Proposed next versions of the Consumer Data Standards: 1.23.0 and 1.24.0	Version 1.23.0 is Change 576 Version 1.24.0 is planned to contain changes from Maintenance Iteration 14
Maintenance	Iteration 14 Working Group agenda for 5th of April 2023 published	Check out the agenda here
Maintenance	Iteration 14 is complete!	All the Meetings notes
Maintenance	Iteration 15 is planned to commence on the 3rd of May 2023 Invitations and details to be sent	Intent is release Versions 1.23.0 and 1.24.0 of the Consumer Data Standards prior to the commencement of MI15
TSY Newsletter	To subscribe to TSY Newsletter	Link here
DSB Newsletter	To subscribe to DSB Newsletter	Link here
TSY Newsletter	21st of March 2023	View in browser here
DSB Newsletter	6th of April 2023	View in browser here
Consultation	Decision Proposal 229 - CDR Participant Representation	Placeholder: no close date Link to consultation
Consultation	Decision Proposal 267- CX Standards Telco Data Language	Feedback extended with an end date to be determined pending the making of the telco rules. Link to consultation
Consultation	Decision Proposal 275 - Holistic Feedback on Telco Standards	No Close Date Link to consultation
Consultation	Noting Paper 276 - Proposed v5 Rules & Standards Impacts	No Close Date Link to consultation
Consultation	Noting Paper 279 - Accessibility Improvement Plan	No Close Date Link to consultation
Consultation	Noting Paper 280: The CX of Authentication Uplift	UPDATE: See NP296 for continuation of consultation
Consultation	Noting Paper 296 - Offline Customer Authentication	Feedback 17th of April 2023 Link to consultation Video 55 of NP296
Consultation	Noting Paper 289 - Register Standards Revision	Feedback 28th of April 2023 Link to consultation Video 56 of NP289

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	Eva
ACCC	CTS	Andrea
DSB	CX Standards	Amy
DSB	Technical Standards - Banking & Infosec	Mark
DSB	Technical Standards - Energy & Register	Hemang
DSB	Technical Standards - Telco	Brian

Presentation

None this week.

Q&A

Questions on Notice

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

In regards to topics for questions, we ask the participants on the call to consider the Community Guidelines when posing questions to the subject matter experts.

Answer provided

Ticket #	Question	Answer
1904	The specifications under pagination state that data holders can implement cursor support or continuation tokens in place of pagination. In particular: "it is considered allowable to implement these patterns and expose them via the pagination links". The question I have is regards the LinksPaginated object. In that object the "last" parameter is "Mandatory if this response is not the last page". When using continuation tokens, where a link to the last page cannot be provided under that pattern, can you please provide guidance on what should be provided here? Also general guidance on how we should populate the pagination links when using continuation support would be greatly appreciated. We would still provide the 'self', 'first' and 'prev'. Though I would argue in modern design 'prev' in particular is better for the client to manage. User's generally go forward it would be straightforward for clients to cache previous results. But I digress. The 'last' link is what we would not be able to supply. The reason for this is the NoSQL database technology we are using. We can address all but 'last' relatively straightforwardly with that technology (out of the box or almost). I also understand 'last' is not something that is generally supported when using cursors/continuation tokens, which the specs say is an allowable approach. For endpoints with a large number of records, I think these are some possibilities: Get Telco Products - with a request with no filtering Get Telco Invoices - with multiple accounts and 24 months history Get Usage - with multiple accounts, services and 24 months history	Thanks for that detail. This subject has been raised previously, and the guidance/position remains (see 'Pagination' in this comment referring to earlier posts), which is that direct access will be supported through the link structure as defined, including the 'last' link. How that may be achieved with any particular pattern or implementation solution would be up to the participant.
1912 Part 1	Compliance guidance on Approval to Disclose : As discussed on the implementation call we have some confusion related to the newest guidance published for Joint Accounts (https://www.cdr.gov.au/sites/default/files/2022-12/Joint-account-implementation-guide-published-20-December-2022.pdf page 10): The non-requesting joint account holder must be allowed to withdraw an approval for each authorisation to disclose joint account data, regardless of whether there is a pre-approval or a co-approval disclosure option on the account. The question for us in this paragraph is whether "withdraw an approval for each authorisation to disclose joint account data" refers to the changing to Non Disclosure for a joint account OR whether the "authorisation to disclose" is on a per arrangement basis. If the former, this aligns with our understanding if the latter we are trying to understand how 4A.13 enables this functionality as it appears to relate specifically to the approval process (not the establishment of arrangements)? We will follow up with another ticket from our engineering team with respect to the CX Guidelines components.	Thank you for your query. In relation to your question, the position is the latter – the authorisation to disclose joint account data is on a ‘per arrangement’ basis. This is supported and intended by the CDR Rules. Under the CDR Rules, Part 4A deals with joint accounts. Division 4A.2 of the CDR Rules details the 3 disclosure options. These determine the level of approval that is required before data relating to a joint account may be shared when a consumer data request is made by one of the joint account holders. Disclosure options are set at the account level (so it would apply to all consumer data requests made in relation to the joint account). The functionality to select these disclosure options is known as DOMS (and was known as JAMS under previous versions of the Rules) and we believe this is what you were referring to as “authorisation to disclose”. Division 4A.3 is about consumer data requests that relate to joint accounts and applies in relation to a consumer data request made to a data holder under Part 4 where the CDR data requested includes joint account data – so establishing a data sharing arrangement. Under this Division and as per normal consumer data requests, when a requesting joint account holder wants to share CDR data from a joint account, they must provide an authorisation to the data holder in accordance with Part 4 (see rule 4A.10). When Division 4A.3 of the CDR Rules and our guidance refers to authorisations in relation to joint accounts, this is what it is referring to – the authorisation to share consumer data from the joint account. Once that authorisation is made, the non-requesting joint account holders must each provide an approval in order for the data to be disclosed. The references in this Division to “approvals” are in relation to approving the authorisation to share data pursuant to a consumer data request, not the overall disclosure option (so not the “authorisation to disclose”). If a pre-approval option applies to the account, each non-requesting account holder is taken to have approved the disclosure (see 4A.12(1)(b)). If a co-approval option applies to the account, the data holder must invite the approval of the non-requesting joint account holders in accordance with rule 4A.11. The CDR Rules in this Division then provide guidance on withdrawing these approvals – see rule 4A.12(2) which provide that an account holder may withdraw an approval given under this Division at any time, using their consumer dashboard and rule 4A.13 which outlines the functionality data holders need to provide. These Rules mean that disclosure options to share data at an account level and authorisations/approvals are two related but different concepts. The disclosure options apply at an account level and determines the level of approval that is required before data relating to a joint account may be shared when a consumer data request is made by one of the joint account holders. The references to authorisation and approvals relates to specific consumer data requests. This does mean that an approval to disclose data in a consumer data request may be withdrawn but it doesn’t change the overall disclosure option. Finally we would note that though our updated Joint Account guidance was published in December 2022, this same position was contained in our previous Joint Account guidance which was originally published in January 2022. Our updated guidance was also reviewed by other CDR agencies before its publication.
1912 Part 2	Thanks for your response however there appears to be some conflicting statements within it. Initially it is stated: "In relation to your question, the position is the latter – the authorisation to disclose joint account data is on a ‘per arrangement’ basis. This is supported and intended by the CDR Rules." However when discussing withdrawal of approval with a specific focus on Pre-approval: "The CDR Rules in this Division then provide guidance on withdrawing these approvals – see rule 4A.12(2) which provide that an account holder may withdraw an approval given under this Division at any time, using their consumer dashboard and rule 4A.13 which outlines the functionality data holders need to provide." 4A.12(2) relate to approval and when reviewing 4A.13 the obligation under 4A.13(1)(d)(i) states "can be used by the relevant account holder to manage approvals in relation to each authorisation to disclose joint account data made by a requester". This seems to read like if a Consumer withdraws their approval to disclose a specific account and there are arrangements in place those arrangements would now omit the account for which the approval was withdrawn - this would align with Option 1 I originally stated but would be in conflict with the opening statement? If the intent is indeed to allow a joint account holder who didn't setup the arrangement to specifically modify a specific arrangement to remove a joint account they share our follow on question would be where this is described and demonstrated in the Standards and Guidelines as per Rule 4.22(b) because it is essentially introducing multiparty fine grained consent for which there are many edge cases.	As mentioned, Division 4A.3 is about consumer data requests that relate to joint accounts and applies in relation to a consumer data request to a data holder under Part 4 where the CDR data requested includes joint account data. and as such all references to authorisations and approvals are to be taken in that context. When Division 4A.3 of the CDR Rules (and the provisions within it) refers to authorisations in relation to joint accounts it is referring to the authorisation to share consumer data from the joint account. Once that authorisation is made, the non-requesting joint account holders must each provide an approval in order for the data to be disclosed: - Pre-approval: if a pre-approval option applies to the account, each relevant account holder is taken to have approved the disclosure (see 4A.12(1)(b)). - Co-approval: if a co-approval option applies to the account, the data holder must invite the approval of the relevant account holders in accordance with rule 4A.11. These approvals are in relation to a specific consumer data request after the requesting data holder gave an authorisation to share data under the specific consumer data request. Rule 4A.12(2) provide that an account holder may withdraw an approval given under the Division (being Division 4A.3) at any time - this is referring to the approval given to share data under the consumer data request. Rule 4A.13(1)(d)(i) states "can be used by the relevant account holder to manage approvals in relation to each authorisation to disclose joint account data made by a requester" and again, this is referring to the approval to share data under the specific consumer data request, not the overarching disclosure option. To give an example, Joint Account Holder A made 3 consumer data requests to share data for their joint account, all of which were ongoing for a year (data sharing arrangements X, Y and Z) (in accordance with rule 4A.10). The pre-approval option applied to the joint account and so Joint Account Holder B is taken to have approved all 3 consumer data requests (in accordance with Rule 4.12(1)). Later in the year, Joint Account Holder B uses their consumer dashboard to withdraw their approval to share data under data sharing arrangement X (in accordance with Rule 4A.13(1)(d)). This means that data sharing arrangement X will stop, but data sharing arrangement Y and Z can continue. If a joint account holder wanted to change their overall disclosure option, they would be doing so in accordance with rules 4A.7 and 4A.8, through the disclosure option management service which is different to the authorisation and approval process for consumer data requests outlined in Division 4A.3.
1914	n order to meet the TPS and response time NFRs required by the CDR specifications, our plans to use an operational data store (ODS) that maintains a copy of source data stores. Our primary digital channels directly query source data stores.Based on the planned technical implementation, we are assuming an upper limit of 5 minutes data latency between the ODS and the source data stores. I understand the "commensurate" wording is deliberately ambiguous and left for data holders to interpret. However, as this relates to fundamental architecture decisions, to move forward with confidence Telstra needs guidance re: this 5 minutes latency. Can the CDR team please advise if this approach would be deemed compliant or if we are off track with the planned approach? In the response could consideration please be given the Telco data context, which potentially differs from a banking (or energy) context.	The DSB is unable to give specific guidance on the meaning of "commensurate" as this is up to the regulator to manage and the regulator has not been in the habit of providing specific answers to questions of this nature. That said, the requirement for commensurate data latency was to avoid situations where a customer uses both CDR and a proprietary channel and the difference is obvious to the customer to the point that the value of using CDR is undermined. Therefore the issue of latency can relate to the importance and relevance of the data being obtained. For instance, in banking, the current account balance needs to be very low latency as it can be used for making decisions around payments but the current rate of customer's mortgage may be less of a concern as it changes relatively infrequently. If the data for which there will be latency is not open to high velocity of change or is not highly relevant from a time perspective then 5 minutes is probably not going to be an issue. Your implementation team may want to take this into account and analyse if it would be of value to go to source for high velocity/high importance data fields or sets.
1921 Part 1	We are seeking clarification in relation to ‘optional’ data field. As per CDR rules, if the data for ‘optional’ field is held by the data holder then it should be treated as ‘mandatory’. However we have scenarios, where the data is held in a completely different system and that is not accessible, or it’s encrypted. An example is, we bill our customers through a billing system that applies debit on core banking and the information on the charges that make up that debit are contained in a separate system. The ‘additionalInfo’ field under ‘BankingProductFee’ schema is optional, however it’s inaccessible in our case. Hence, we wanted to check if this type of data is to be treated as ‘mandatory’ esp if the data for the optional field is inaccessible, or is a highly complex implementation to make it accessible. We have looked through a few of the zendesk articles, however it didn’t provide us enough clarity and hence seeking this information. Optional Fields: APCA – Consumer Data Standards Australia (zendesk.com) Data unavailable for BankingTransactionDetail fields – Consumer Data Standards Australia (zendesk.com)	I may not be able to give a definitive answer about whether you should determine a data element to be held or not, but I'm interested in the example you've provided. You mentioned there is a system that applies debit charges, and the detail may relate to a fee. Can you provide some pseudo code for the data fields you are able to provide (the direct debits, transactions, or fees), and give an indication of the expected fields/values that you may not be able to provide as easily (additionalInfo for a fee, for example.)
1921 Part 2	Sharing a few additional notes in response to your query around the example I have shared. - The billing system manages the fee billing and stores the breakdown of total fee, e.g. channel fee, balance fee, virtual account fee etc. It also generates invoice and send to client. It’s mandated in our T&C to bill via this billing system - The total fee gets debited from the customer account on our core banking system. Customer’s statement refers “invoice number” in transaction description for the fee debited - Most of our corporate customers have negotiated pricing. So, we provide the standard fee & charges via a link in response to the CDR API A quick snapshot in relation to the CDR API fields, See Appendix	Can I assume that you will share a fee name with each fee (mandatory in the schema), and that the fees relate to standard items listed in a fee schedule? Are you able to share a link to an example fee document? (the standard "fee & charges via link" you mentioned), or, can you provide a reference to the Product Detail for a relevant account with the fee mentioned? What would you consider to be relevant in the additionalInfo that you are unable to easily source? - a longer description about the fee, or the "invoice number" text that is used in the transaction description? Just by the way, I've noticed that the product below for example, has the wrong data type in the additionalValue field - "name": "Maintenance fee", "feeType": "PERIODIC", "amount": "250.00", "currency": "AUD", "additionalValue": "Monthly fee per physical account", // For a periodic fee, this field should contain - "The period of charge. Formatted according to ISO 8601 Durations" "additionalInfo": "Applicable to Traditional VA and Next Generation Virtual Account Management" https://public.ob.business.hsbc.com.au/cds-au/v1/banking/products/VA Is this the type of structure you are trying to replicate in accountDetail, with the name and additionalInfo?
1922	Would like to know about the Pagination requirement of CDR: (https://consumerdatastandardsaustralia.github.io/standards/#tocSlinkspaginated) %20%20) The CDR Pagination requirement says : "links":{"self":"string","first":"string","prev":"string","next":"string","last":"string"} but can we have as below which as per HATEOS specification (notice href present within and then url) "_links": { "first": { "href": "http://localhost:8080/api/v4/customers? firstNameFilter=R&lastNameFilter=S&sortList=firstName&sortOrder=ASC&page=0&size=10&sort=firstName,asc" }, "self": { "href": "http://localhost:8080/api/v4/customers?firstNameFilter=R&lastNameFilter=S&sortList=firstName&sortOrder=ASC&page=0&size=10&sort=firstName,asc" }, "next": { "href": "http://localhost:8080/api/v4/customers? FirstNameFilter=R&lastNameFilter=S&sortList=firstName&sortOrder=ASC&page=1&size=10&sort=firstName,asc" }, "last": { "href": "http://localhost:8080/api/v4/customers?firstNameFilter=R&lastNameFilter=S&sortList=firstName&sortOrder=ASC&page=15&size=10&sort=firstName,asc" } }	For the example given: no, that would not be schema compliant.
1926	Is there a central repository of changes to the CDR or energy sector specifically? I'm trying to reconcile initial requirements and assess against changes implemented in teir 1 go live for energy (Nov 22).	For all changes to the Consumer Data Standards. Please check out the Change Log for the Standards: https://consumerdatastandardsaustralia.github.io/standards/#change-log You can find changes for all sectors and areas in the Standards. For example in Version 1.20.0 (a few versions ago) you can see Energy Schema and Swagger updates. All Change Requests for the Consumer Data Standards are raised on our Standards Maintenance and Standards (Decision Proposals and Noting Papers) repositories.
1928	How can we access a list of hosts for energy APIs? Is there a list of hostnames for which we can make requests to for the 'Get Generic Plans' APIs? Has anyone implemented this yet?	The Australian Energy Regulator (AER) has the list of Data Holders for the Energy Product endpoints: https://www.aer.gov.au/consumers/energy-product-reference-data You can find the list of base URIs there.
1929	I was wondering if there is a list of API endpoints for 'Get Generic Plans'? I am not sure what to replace the placeholder environment variable {{primaryDataHolderUrl}} with (from this collection https://www.postman.com/winter-shadow-541400/workspace/dsb-schema-tests/request/8286723-c0ac0ef1-ad37-45f2-a414-d6611336563d). Could I please have help finding who the primary data holders are and how I can access their unauthenticated endpoints? Reference: Was reading this page? https://consumerdatastandards.gov.au/cdrsupport/engineering-tools-overview	For all Service Providers you can check out: https://www.cdr.gov.au/find-a-provider but there is a better way and that is to use the Register GET Data Holder Brands Summary endpoint: https://consumerdatastandardsaustralia.github.io/standards/#get-data-holder-brands-summary that should give you a list of baseuris and public details of the different data holders.