ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 1st of September 2022

CDR Implementation Call Banner

Agenda & Meeting Notes

When: Weekly every Thursday at 3pm-4.30pm AEST
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: [email protected]

Phones - AUDIO ONLY

Primary Australia: +61-2-9338-2221
Quick Dial: +61-2-9338-2221,,1650705270##
Other Global Numbers: https://treasuryau.webex.com/cmp3300/webcomponents/widget/globalcallin/globalcallin.do?MTID=m311f46c87a3ab9ae5335a6c0ea431da4&MTID=m311f46c87a3ab9ae5335a6c0ea431da4&MTID=m311f46c87a3ab9ae5335a6c0ea431da4&MTID=m311f46c87a3ab9ae5335a6c0ea431da4&serviceType=MC&serviceType=MC&serviceType=MC&siteurl=treasuryau&siteurl=treasuryau&siteurl=treasuryau&apiname=globalcallin.php&apiname=globalcallin.php&apiname=globalcallin.php&rnd=6124483603&rnd=6124483603&rnd=6124483603&tollFree=0&tollFree=0&tollFree=0&ED=1403111402&ED=1403111402&ED=1403111402&needFilter=false&needFilter=false&needFilter=false&actappname=cmp3300&actappname=cmp3300&actname=/webcomponents/widget/globalcallin/gcnredirector.do&actname=/webcomponents/widget/globalcallin/gcnredirector.do&renewticket=0
Meeting Number/Access Code: 165 070 5270

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.18.0 Published	Link to change log here
Maintenance	Maintenance Iteration 12	Met on the 31st of August 2022 Agenda here
Maintenance	Decision Proposal 259 - Maintenance Iteration 12	Changes, meeting notes and updates for the iteration can be found here
TSY Newsletter	To subscribe to TSY Newsletter	Link here
DSB Newsletter	To subscribe to DSB Newsletter	Link here
TSY Newsletter	31st of August 2022	View in browser here
DSB Newsletter	26th of August 2022	View in browser here
Consultation	Normative Standards Review (2021)	No Close Date Link to consultation
Consultation	Decision Proposal 229 - CDR Participant Representation	Placeholder: no close date Link to consultation
Noting Paper	Noting Paper 255 - Approach to Telco Sector Standards	Link to consultation
Noting Paper	Noting Paper 258 - Independent Information Security Review	Link to consultation
Consultation	Decision Proposal 262 - Telco Product Reference Payloads Feedback closes: 5th of September 2022	Link to consultation
Consultation	Decision Proposal 263 - Telco Accounts Payloads Feedback closes: 16th of September 2022	Link to consultation
Consultation	Decision Proposal 267- CX Standards Telco Data Language Feedback closes: 15th of September 2022	Link to consultation
Video	[32] Consent Flow - Part 2 - with James Bligh (29/08/2022)	Link to Data Standards Body Video 32
Feedback	Feedback on the CDR Implementation Call Seeking informal feedback on the CDR Implementation Call. What we can improve, what you find value with and any other ideas	Link to survey
Feedback	Articles changes in the last 7 days	Link to CDR Support Portal
Action	Privacy response on Ticket 1663	Answered below on Ticket 1663

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	Emma Harvey
ACCC	CTS	Priyanka Patel
DSB	CX Standards	Eunice Ching
DSB	Technical Standards - Energy	Hemang Rathod
DSB	Technical Standards - Banking	Mark Verstege
DSB	Technical Standards - Telecommunications	Brian Kirkpatrick
DSB	Technical Standards - Engineering & Register	James Bligh

Presentation

None.

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.

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
433	Email 'nudges' based on derived CDR data sent to consumers Schedule 2 Part 2 requires ADRs to implement data loss and leakage prevention mechanisms to prevent data leaving the CDR data environment, including, but not limited to: (c) email filtering and blocking methods that block emails with CDR data in text and attachments. Can an ADR send a consumer a 'nudge' via an email, where the email nudge would be based on data derived from CDR data e.g. we see that your loan may not be on a competitive rate, login to review your options and compare other loans, you see have an upcoming bill payment but don't have enough money in your account.	Please refer to our article: ADRs sending CDR data to consumers (e.g. via email or direct messaging) and the Schedule 2 Security Provisions.
1481	Regarding Rule 1.15(g)(3): "For paragraph (1)(b) and paragraph (5)(a), the information is the following for each authorisation: ... (g) for a disclosure of CDR data that relates to the authorisation but that was pursuant to a request under subsection 56EN(4) of the Act—that fact." We acknowledge the requirement to inform the consumer within 5 or 10 days regarding a data quality issues and to confirm its correction. What is not clear is whether - under this clause (g)(3) - the Regulator expects the data correction to appear on the Consumer Dashboard, or via the Data Sharing Summary. The closest guidance article we can find is this, but it does not answer this question: https://cdr-support.zendesk.com/hc/en-us/articles/900004502046-Data-holder-dashboards-disclosure-on-consent Under "Rule 9.3 (1) Records to be kept and maintained (data holder)", We are capturing a log of each authorisation, amendment, withdrawal (of consent and approval), expiry, and scopes requested by an ADR during consumer data sharing. But we do not keep a log of data corrections in this same 'data sharing summary' database, and do not expose these on the consumer dashboard. They are certainly available and can be retrieved and reported on. So the question is concerned with regulator's expectation of exposing 'data correction' details through consumer dashboard or other channels?	Rule 1.15(3)(g) requires the data holder to provide information regarding a disclosure related to an authorisation that was made pursuant to a request under subsection 56EN(4). This means the data holder must disclose the relevant information regarding corrected data under 1.15(3)(g) on the consumer dashboard. Rule 7.15(c) requires a data holder to provide the consumer a written notice via electronic means outlining the matters relating to the correction request under Privacy Safeguard 13. We note rule 1.15(3)(g) does not require the data holder to include any further information about data corrected (including data corrected under Privacy Safeguard 13) on the consumer dashboard. However, we consider it best practice for a data holder to update the consumer dashboard to reflect any Privacy Safeguard 13 correction requests it has received, provided the consumer dashboard has such a functionality. Furthermore, we note rule 9.3(1)(d) requires data holders to keep and maintain records that record and explain disclosures of CDR data made in response to consumer data requests. If corrected data is disclosed under Privacy Safeguard 11 (rule 7.10), we consider that the data holder must keep and maintain a record of both the initial disclosure in which incorrect CDR was disclosed, and the subsequent disclosure in which the corrected data was disclosed. There is no requirement, however, to record the disclosure as either ‘correct’ or ‘incorrect’ pursuant to rule 9.3(1)(d). Please refer to the OAIC’s Privacy Safeguard Guidelines for further information on Privacy Safeguard 11 and Privacy Safeguard 13.
1663	I wish to find out if the account number in email notifications (for Joint accounts) are considered to be Personally identifiable information, and if it needs to be masked in the emails?	The OAIC suggests a cautious approach when disclosing any information about an individual to anyone other than the individual. The CDR participant should consider if the account number is ‘personal information’ i.e. information about an identified individual or an individual who is reasonably identifiable. If it is, then they should consider redacting it from the information being disclosed. We also note that a data holder will not be held liable for failing to disclose any information in response to a valid consumer data request if they believe doing so could result in physical, psychological or financial harm or abuse to any person (CDR rule 4A.15).
1685	Can we apply the account disclosure option to non-individual trust accounts as a way to control CDR data sharing ? If yes, this means it will follow the same methodology of proposing pre-approval and non-disclosure options.	The disclosure options specified in Division 4A.2 of the CDR rules only apply to joint accounts and are relevant when an accredited person makes a consumer data request on behalf of a joint account holder or a secondary user of the joint account under Part 4. Rule 1.7 of the CDR Rules specifies that a joint account means a joint account with a data holder for which there are 2 or more joint account holders, each of which is an individual who is acting in their own capacity and is eligible in relation to the data holder. We encourage you to seek independent advice if you require further information about the application of the CDR Rules to a specific scenario.
1685	The Business would like to adopt DOMS as a mechanism for multiple nominated representatives to control the sharing of accounts. This would cater for situations where one nominated representatives come in and out of this role. We just want to ensure that we’re not contravening any CDR Rules by adopting DOMS.	Rule 1.13 states that data holders much provide their non-individual and partnership customers with a service to nominate one or more nominated representatives who can grant and manage authorisations to disclose consumer data on the business’ behalf. We note that the obligation to provide a disclosure option management service only applies to joint accounts as stated in rule 4A.6. For further information on nominated representatives, please refer to our guidance on Nominated representatives, non-individuals, and partnerships in the CDR, particularly the section Can authorisations be transferred between nominated representatives? which provides guidance in relation to the scenario where a nominated representative may change. We encourage you to seek independent advice if you require additional information about the application of the rules to a specific scenario as the ACCC cannot provide specific compliance advice.
1586	Refresh token expiry after September 16th 2022 (FAPI 1.0 Migration Phase 2) With the possible retirement of `sharing_expires_at` and `refresh_token_expires_at` claims from September 16th 2022 (FAPI 1.0 Migration Phase 2), would you kindly be able to advise on how an ADR could retrieve the consent's expiry time (which would also be the consent's refresh token expiry time) from the response of refresh token request? * One option would be to include an `exp` claim inside the ID token in the response - the issue with approach is that the `exp` claim inside the ID token is used to announce the expiry of the ID token itself, not the refresh token * The other option would be to include an `exp` claim inside the refresh token response (https://openid.net/specs/openid-connect-core-1_0.html#RefreshTokenResponse) but this doesn't seem to be a standard approach Understanding that a clarification on this matter would benefit all participants, it would be great if CDS could be amended with enough information and sample to avoid any ambiguity which may lead to misaligned implementation among the different participants on the obligation date. Many thanks in advance.	You can call the token introspection endpoint to obtain the "exp" value of the refresh token. If you feel retaining the sharing_expires_at claim is important, I would encourage you to raise a change request.
1115	We would like to clarify rules 1.15(5)(b)(i) and 4.6A(a)(ii). Rule 1.15(5)(b)(i) requires the Data Holder to provide functionality to the account holder to allow them to indicate that they no longer approve CDR data relating to a particular account being disclosed to a particular accredited person when the request is made by a Secondary User. Further the note to this clause states: “If the account holder makes an indication in accordance with subparagraph (5)(b)(i), the data holder will no longer be able to disclose CDR data relating to that account to that accredited person: see subrules 4.6(2) and (4) and subrule 4.6A(1).” This rule implies that once the account holder has made an indication, the Data Holder is not to disclose any CDR data relating to that account to the accredited person altogether. This potentially impacts other active consents to that accredited person which include the relevant account. Example for clarification (please see the attachment for Table): The Account Holder has two Secondary Users. The Account Holder along with both Secondary Users have granted consents to the accredited person Money Manager. A total of three separate consents exist. The Account Holder indicates they no longer approve CDR Data relating to consent 2, granted by Secondary User 1 to Money Manager. Westpac believes that data sharing should continue for consent 1 and 3. Can we please clarify that this rule is requiring the Data Holder to stop sharing CDR data for consent 2 granted by the Secondary User 1 alone? And that CDR data sharing to the accredited person under different consents, for example by the Account Holder or a different Secondary User can continue.	In relation to secondary users, rule 1.15(5)(b)(i) states that data holders must provide the account holder with a service that allows account holders to give the indication referred to in subparagraph 4.6A(a)(ii) in relation to a particular accredited person. Rule 4.6A(a)(ii) states that this indication is that the account holder no longer approves CDR data relating to that account being disclosed to “that accredited person” in response to consumer data requests made by “that” secondary user. This indicates that the scope of the indication in 4.6A(a)(ii) only applies to requests made to an accredited person made by that secondary user. As such, we agree with the outcome in the example you have provided.
1628	Regarding Demand Fields in Account Details and Billing API Can you please clarify the expected mapping for below fields 1. EnergyPlanTariffPeriod: EnergyPlanTariffPeriod – Consumer Data Standards (consumerdatastandardsaustralia.github.io) Description of minDemand and maxDemand states “Minimum or maximum demand for this demand tariff in kW” but the format of field is AmountString. As per the description, minimum KW seems to be expected here and not the amount. Can you please clarify. 2. EnergyBillingDemandTransaction EnergyBillingDemandTransaction – Consumer Data Standards (consumerdatastandardsaustralia.github.io) Rate field states “The rate for the demand charge in kVA”. Is this expected to map to demand usage? If yes, demand usage billed can be in KW or KVA. How is this expected to be mapped?	Question: 1. EnergyPlanTariffPeriod: EnergyPlanTariffPeriod – Consumer Data Standards (consumerdatastandardsaustralia.github.io) Description of minDemand and maxDemand states “Minimum or maximum demand for this demand tariff in kW” but the format of field is AmountString. As per the description, minimum KW seems to be expected here and not the amount. Can you please clarify. Answer: It seems this field should be a number instead of AmountString. Given we are very close to energy go-live and everyone is mid implementation, changing the type could be a breaking change. You could still provide the demand tariff in kW as per description as it will still be schema compliant as AmountString is a type of number. We can then raise a CR to consult and have this changed to the correct type for post-go live. Question: 2. EnergyBillingDemandTransaction EnergyBillingDemandTransaction – Consumer Data Standards (consumerdatastandardsaustralia.github.io) Rate field states “The rate for the demand charge in kVA”. Is this expected to map to demand usage? If yes, demand usage billed can be in KW or KVA. How is this expected to be mapped? Answer: You are correct, it is representing demand charge rate in kVA. This was defined based feedback received during energy standards consultation. Any changes to cater for both types will need to be consulted via a CR. Similar to above, making a change at this time would have impact on 15th Nov go live. For nov-15 I would recommend providing the rates in kVA (convert any KW to kVA). We can then raise a CR to consult on a potential solution for post go live.
1629	highlighted the following parameters would be included as part of v1.17.0 of the data standards for ## Request GET /.well-known/openid-configuration HTTP/1.1 (https://consumerdatastandardsaustralia.github.io/standards/?examples#security-endpoints) - "response_types" field values ["code"] - "authorization_signed_response_alg" , - "authorization_encrypted_response_alg", - "authorization_encrypted_response_enc" In 1.17, this is not updated. Please could you confirm whether these could be included in the response for the September release? If yes, when this would be included in CDS document?	This is still under development. There was a discussion in the maintenance iteration around encryption support with JARM. This is under consultation, hence the non-normative example is yet to be updated.
1666 P1	We have implemented PKCE use only in case of authorization code flow and not hybrid flow. Do we have to implement PKCE use for hybrid flow too?	yes from September 2022, the data standards adopt the FAPI 1.0 Advanced profile. The FAPI standards require Authorisation Servers supporting PAR RFC9126 to also support PKCE. See clause 18 of section 5.2.2 shall require PAR requests, if supported, to use PKCE (RFC7636) with S256 as the code challenge method.
1666 P2	In the document specified there is nowhere mentioned Hybrid + PKCE and all the examples for PKCE is with only “code” (i.e. Authorization code flow) as response type. Hence, I am still not sure we must implement PKCE for Hybrid flow too.	FAPI applies PKCE as a blanket requirement for all authorisation flows when PAR is used.
1670	The following statements relate to the info provided at: https://consumerdatastandardsaustralia.github.io/standards/index.html#request-object 1. "Data Holders MUST support [RFC9126] (PAR) using [PKCE] ([RFC7636])" 2. "Data Recipients MUST ONLY send authorisation request data using [RFC9126] (PAR) and use [PKCE]" Q1. Is our understanding correct that PAR should be the only way for the ADR to initiate the consent flow with the DH post 16th of September? Direct calls to Authorize endpoint should not be supported..? Q2. Once we as a DataHolder transition over to the PKCE, we will reject any calls made by an ADR without the PKCE claims. Can you confirm this is correct? Our assumption is that the ADRs MUST have also transitioned over to use PKCE on the 16th of Sep. Please confirm that the assumption that ADRs MUST also use PKCE on the 16th of Sep is correct	Question 1: Is our understanding correct that PAR should be the only way for the ADR to initiate the consent flow with the DH post 16th of September? Answer 1: That is correct Question 2: Q2. Once we as a DataHolder transition over to the PKCE, we will reject any calls made by an ADR without the PKCE claims. Can you confirm this is correct? Our assumption is that the ADRs MUST have also transitioned over to use PKCE on the 16th of Sep. Please confirm that the assumption that ADRs MUST also use PKCE on the 16th of Sep is correct Answer 2: This is correct from 16th of September. Whereby DHs must support PKCE for PAR requests. As such you would be rejecting an ADR request that is not correctly supporting PKCE from that date.
1671	Clarify FAPI 1.0 Migration Phase 1 and Phase 2 Obligations related to "nbf" value of request object with respect to myCDR data According to [1], From July 4th 2022 (FAPI 1.0 Migration Phase 1), Data Recipients Software Products MUST send request object containing a "nbf" claim and an "exp" claim that has a lifetime of no longer than 60 minutes after the "nbf" claim. From September 16th 2022 (FAPI 1.0 Migration Phase 2), Data Holders MUST require the request object to contain an "exp" claim that has a lifetime of no longer than 60 minutes after the "nbf" claim in accordance with [FAPI-1.0-Advanced] section 5.2.2. But myCDR data does not contain the 'nbf' value as reported by one of our customers. Therefore the consent flow is failing in UAT due to missing 'nbf' value. Hence consent flow might also fail in production if the 'nbf' validation is not mandatory. Therefore we want to clarify the following concerns. 1. Is the 'nbf' value mandatory in the request object sent by the DR from 4th of July 2022 onwards? 2. Is it mandatory for the DH to validate whether the 'nbf' value is present in the request object from 16th September 2022 onwards? [1] https://consumerdatastandardsaustralia.github.io/standards/#request-object	DH requirements are introduced from September 2022. As a DH you may reject requests from ADRs that do not satisfy their July 2022 obligations for providing a valid "nbf" and "exp". However during consultation, it was acknowledged that achieving mandatory validation by July 2022 was not possible for all DHs hence the September date was chosen.
1672	Seek Information around consuming live data via apis As part of our exploration on CDR requirement, we would like to thank you guys for setting up the mock sandbox environment in azure cluster. Really appreciate the effort put-in in setting up the mock-up tool for audience to understand the CDR ecosystem. So, as part of our exploration, we were also looking for getting details around exploring/consuming the live data feeds via apis. It would be a great help if you can get us with some information/documentation around onboarding details for CDR entities to consume live data from CDR ecosystem	From your query it looks like you are seeking information on how to become an Accredited Data Recipient in the CDR ecosystem. The following link will provide to with more details on the Accreditation and onboarding processes. https://www.cdr.gov.au/for-providers. We hope this information is useful.
1675	Client registration There are few questions around the requirement, “Data Holder Brands MUST ignore unsupported authorisation scopes presented in the SSA for the creation and update of Client Registrations.” Q1: If no scopes presented in the SSA are supported by Data Holder Brand, then do we need to create client with no scope? Q2: Do we register client, when GetSSA contains no scopes (empty string), not even OpenID and profile? Appreciate response considering the obligation date on the above requirement.	Q1: If no scopes presented in the SSA are supported by Data Holder Brand, then do we need to create client with no scope? Answer 1: This is a good question. In practice this should never happen. If the ADR does not present the openid scope for example, then the Authorisation Server could not perform the OIDC Hybrid Flow. Nevertheless an Authorisation Server should still issue a valid authorisation response even if no scopes are supported (provided that does not violate other aspects of the request like requiring openid for Hybrid Flow). It is possible that an ADR may request only individual claims rather than any scopes for consumer data. The FAPI 1.0 Baseline profile has additional details. Q2: Do we register client, when GetSSA contains no scopes (empty string), not even OpenID and profile? Answer: Yes on the proviso that this does not violate other client requirements (e.g. registering for Hybrid Flow could not be supported without at least the openid scope). Practically this will not occur because the SSA will include openid if the ADR is using the Hybrid Flow and will also include all accredited scopes.
1688	toUType and scheduled payments For a joint account, if the scheduled payment is to a payee that matches a unique registered payee in the customer's address book (based on matching PayID or matching bsb and account number or matching biller code and customer reference number) and the payment is not to an account that the current customer holds and the payee scope is included in the customer's consent, should the toUType of the payment for that customer be payeeId ?	my understanding of the question you are asking is: if the payment is to an account in the consumer's payees address book and the consumer has consented to sharing payee data, should the toUType be payeeId? If this is the question, then that is correct. You can provide the payeeId which is the linking reference to the payee record the ADR could call using the Get Payee Detail API.
1697	Decision 237 (Maintenance Iteration 10) In regards to the feedback provided for decision 237, do banks need to do anything in relation to issue # 444 , 465 , 452 , 488 and 452 ?	Please refer to the Decision 237: https://github.com/ConsumerDataStandardsAustralia/standards/issues/237#issuecomment-1124413332 and the Change log for the Consumer Data Standards 1.17.0: https://consumerdatastandardsaustralia.github.io/standards/includes/releasenotes/releasenotes.1.17.0.html#v1-17-0-release-notes as the best sources to guide your assessment of change.
1698	Decision 249 (Maintenance Iteration 11) Can you please confirm if Banks need to make any changes in relation to issue # 521 & 507 ?	In regards to the above issues please refer to the Final Decision on DP249: https://github.com/ConsumerDataStandardsAustralia/standards/issues/249#issuecomment-1201899581 and the Change Log for Consumer Data Standards V1.18.0: https://consumerdatastandardsaustralia.github.io/standards/includes/releasenotes/releasenotes.1.18.0.html#v1-18-0-release-notes
1699	Unsupported scopes - DCR and authorisation request As an outcome of Maintenance Iteration 11, the obligation for Data Holders to ignore unsupported scopes was brought forward to 31st August 2022 from 15th November 2022. "Data Holder Brands MUST ignore unsupported authorisation scopes presented in the SSA for the creation and update of Client Registrations." We had received earlier guidance (attached) from CDR TechOps for authorisation requests: “Data Holders SHOULD ignore the scopes that are unsuppor ted/ extraneous rather than rejecting the request”. In regards to the above FDO and taking the previous guidance into account, we seek clarity on the exact requirements that Data Holders (DHs) must support. Questions: 1. Why will Data Holders need to ignore unsupported / extraneous scopes during authorisation, if the Data Holder has already provided the set of supported scopes during registration? 2. Combining the earlier guidance and the FDO, is an acceptable approach for a Data Holder to register an ADR with all scopes listed in the SSA, and then ignore the unsupported scopes during authorisation? For example: DH-B (a bank) registers a ‘cross-sector’ ADR with banking scopes and also energy scopes. During authorisation, DH-B ignores the unsupported scopes, but proceeds with the authorisation request with the scopes it supports. 3. Following from Q2, would this potentially result in DH-B being listed as a data provider for the energy sector in the ADR’s app?	Question 1: Why will Data Holders need to ignore unsupported / extraneous scopes during authorisation, if the Data Holder has already provided the set of supported scopes during registration? Answer: There are two reasons. The ACCC is updating its Register APIs including the Get SSA API for ADRs. This API will return ALL scopes an ADR is accredited for by the ACCC and no sectorial filtering will be applied. As such, ADRs will receive both Banking and Energy scopes from the 15th of November 2022. This is because at present, ADRs have a blanket accreditation for all data clusters in all sectors. v2 of the Get SSA API is being phased out. As such, sectorial constrained Data Holders will receive SSAs in their Dynamic Client Registration requests that include Energy scopes the do not support. These need to be ignored. The second reason is a consequence of the first reason: to maintain cross-sectoral interoperability without breaking integrations. Question 2: Combining the earlier guidance and the FDO, is an acceptable approach for a Data Holder to register an ADR with all scopes listed in the SSA, and then ignore the unsupported scopes during authorisation? For example: DH-B (a bank) registers a ‘cross-sector’ ADR with banking scopes and also energy scopes. During authorisation, DH-B ignores the unsupported scopes, but proceeds with the authorisation request with the scopes it supports. Answer: Currently the Data Standards require Data Holders to ignore unsupported scopes at the DCR endpoint. Whilst the option you present may be possible, it would need to go through the change request process and filtering would still need to occur just in a different location. Question 3: Following from Q2, would this potentially result in DH-B being listed as a data provider for the energy sector in the ADR’s app? Answer: This would achieve the same outcome but the standards currently require Data Holders to ignore unsupported scopes at the DCR endpoints.
1710 P1	Get Product Details v4 In release v1.15.0 the release notes state that a change has been made to Ge Product Details providing the note "Support for secondary additional information URIs for banking product references." I can't find any change for additional URIs. Where is the change or changes? (the version delta shows nothing)	I had a look through and DP212: https://github.com/ConsumerDataStandardsAustralia/standards/issues/212 has all the Changes incorporated in to V1.15.0 of the Consumer Data Standards. I believe the issue you were referring to is Issue 401: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/401
1710 P2	I found these changes but the release notes states "Support for secondary additional information URIs for banking product references." and this would read as if it were something else. I guess that is a comment on release notes and the need for them to be descriptive of the change/s made.	From Version 1.17.0 we have been including the links to the changes in the Maintenance Iteration: https://consumerdatastandardsaustralia.github.io/standards/includes/releasenotes/releasenotes.1.17.0.html#high-level-standards Unfortunately this doesn't apply retrospectively. However from 1.17.0 onwards it should be easier to trace the origin and discussion on the change.
1713	Passing deferral/ Payment extension/ Once off payment detail within GET AGREED PAYMENT SCHEDULE API As Get agreed payment schedule is to provide the information on how the consumer has elected to pay for their account, based on this wanted to know that is there any obligation to provide within the GET AGREED PAYMENT SCHEDULE CDR API the details of any once off payment arrangements or payment extension such as deferrals (delaying the payment for a stipulated time with a specific deferred date) or any once off top-up plans? e.g., Customer usually pays $50 every fortnight via direct debit and consumer seeks a 21-day deferral to pay for their upcoming payment their account in this scenario is it correct we pass only the usual PAYMENT SCHEDULE details i.e., rather than the deferral details i.e., pass in this API response amount=50 paymentscheduleUtype = directdebit PaymentFrequency = fortnightly	Question: e.g., Customer usually pays $50 every fortnight via direct debit and consumer seeks a 21-day deferral to pay for their upcoming payment their account in this scenario is it correct we pass only the usual PAYMENT SCHEDULE details i.e., rather than the deferral details i.e., pass in this API response amount=50 paymentscheduleUtype = directdebit PaymentFrequency = fortnightly Answer: This is correct.