Decision Proposal 276 - July 2023 Rules | Standards Impacts

[CDR-CX-Stream]

Friday 22 September: Decision Proposal Published The July 2023 rules introduce a range of new provisions for data holders (DHs) and accredited data recipients (ADRs).

The purpose of this paper is to determine the appropriate options and scope of data standards to be made in support of the July 2023 rules.

The specific topics identified by the DSB include:

• Business consumer statements
• Business consumer disclosure consents (BCDC)
• DH Dashboards
• Representation of CDR Participants
• CDR Representatives
• Dashboards in sponsorship arrangements

Decision Proposal 276 can be found below: DP276 - July 2023 Rules - Standards Impacts.pdf

The community is invited to provide feedback on this paper by Friday 20 October 2023.

[nils-work]

The 'v5' Rules Amendments are available here - Competition and Consumer (Consumer Data Right) Amendment Rules (No. 1) 2023

[CDR-CX-Stream]

Decision Proposal 276 has now been posted and can be found in the original post.

The community is invited to provide feedback on this paper by Friday 20 October 2023.

[MrWoo16]

What other standards or considerations should be made: 4.26A Notifications of expired authorisations New rule - 4.26A Notifications of expired authorisations - was introduced as part of the July amendments requiring a data holder to notify the accredited person when an authorisation expires. This new rule replaced 4.25(2)(b) which required data holders to only notify the accredited person when the authorisation was withdrawn via the data holder's Consumer Dashboard or alternative method.

This Decision Proposal makes no reference to this new rule and provides no proposal options for notifying the accredited person when an authorisation expires.

Given the accredited person should be fully aware when the authorisation is due to expire, or when their accreditation is revoked or surrendered, is the Decision Proposal silent on this new rule as either:

• there are no plans to update the standards to support the notification when an authorisation expires, or
• no change is required as the existing data recipient's CDR Arrangement Revocation End Point must be called by the data holder as the notification method when an authorisation expires

[CDR-API-Stream]

Thanks for the question MrWoo16.

It is our understanding that the term expire in the rules can be considered more broadly than the simple definition that the time of a consent disclosure has run out. For instance, if a customer ceases to be eligible then their disclosure consents will cease but will not have been withdrawn (ie. actively revoked). This situation, however, still comes under the definition of an expired consent.

This has been previously stated position of the DSB. Specifically:

• If a consent ceases to be active because of an event on the data holder side (ie. withdrawal, eligibility change, etc) then the data holder should call the revocation endpoint of the data recipient (as the ADR would otherwise not know of the change of consent status)
• If the time of the consent runs out naturally without an event then there is no need for the data holder to contact the data recipient as they have already been informed of the expiry date and time during consent authorisation. If the ADR lose this data then they are also able to confirm the expiration date via the token introspection endpoint

As this is the current position and we have not interpreted the rule change as requiring standards or guidance changes we have taken the position that no change is needed.

If we have misunderstood this situation then we would appreciate this feedback and will consider a change to the standards as part of this consultation.

[CDR-Engagement-Stream]

Hi all,

Video on Decision Proposal 276 on the Data Standards Body YouTube channel.

Thank you!

[MrWoo16]

DP276 Video - Representation of CDR participants The section within this video (8 mins 6 secs) states: "In the authorisation flow, the CDR Rules require Data Holders to refer to ADRs by their legalEntityName, obtained from the CDR Register"

Whilst the CX Guideline 3AU.02.15 reflects the above, the following guidance and technical standards reflect different requirements:

• CX Guideline 2AU.00.16 states "Data Holders should use the Brand Name of the data recipient whenever the data recipient is referenced in consumer-facing authentication processes, including cancellation screens and One Time Password (OTP) delivery.

• the CDS v1.26.0 confirms the "org_name" of the Accredited Data Recipient Brand is to be presented to the end user during authorization.

In addition CX Guideline 2AU.00.16 states "Data holders should not present the Software Product Name in relation to these processes". However, the technical standards reflect that the "client_name" being the human-readable string name of the software product is presented to the end-user during authorization

As CDR rule 4.23(1)(a) confirms "the name of the accredited person that made the request" rather than the Legal Entity Name or Org Name / Brand Name, can this proposal confirm, subject to the proposal outcome:

• whether a correction is required to the technical standards to confirm the Legal Entity Name rather than the Org Name/Brand Name must / should be presented to the end user during authorization
• as the "legal_entity_name" is an optional field during the data recipient registration with a data holder, the "legalEntityName" value obtained from the CDR Register via the GET Data Recipients endpoint must always be used.

As there are different ADR names reflected in the technical standards and CX Guidelines a standard and consistent ADR name requirement for end user display should be defined and communicated.

[da-banking]

Question: In the Data holder Dashboard section, are the two options listed addressing completely separate issues? It reads that they are not options, but changes relating to two separate issues? Can you please confirm?

[CDR-CX-Stream]

Thanks for raising those points @MrWoo16. We're drafting a response that we will post here.

[CDR-CX-Stream]

@da-banking that is correct. The two proposals in the data holder dashboard section deal with separate issues.

They are termed 'options' for ease of reference, and are typically non-mutually exclusive, but appreciate that may have caused confusion.

[paige-skript]

Skript is supportive of the options outlined in this paper. The proposed standards around business consumer statements and business consumer disclosure consents provide clarity and control to consumers, but don't introduce excessive friction to the process.

[perlboy]

As per implementation call, it would be helpful for Option 2 |Authorisation management: Data recipient handling details if the DSB could add an additional MAY statement that specifies example and compliant wording as it has already done in the Withdrawal Standards.

[CDR-CX-Stream]

Thanks again @MrWoo16 for these comments.

The following response has been developed with the @CDR-API-Stream:

The CX Guidelines for the authorisation flow reflect the rules requirement for the legal entity name to be used. This is because the legal entity is the accredited person, and not the brand(s) or software product(s).

CDR Rule 4.23(1)(a) only applies to authorisation, not authentication. The CX Guidelines for authentication (2AU.00.16) suggest the use of brand, while the CX Guidelines for authorisation (3AU.02.15) reflect the rules requirement. Pending views raised in this consultation, the intention is for DP229 to address this inconsistency by proposing the use of the brand and/or software product name in the authorisation flow, in addition to the legal entity name.

The CX Guidelines will be amended as required when the DP276 and/or the DP229 consultations conclude and following any decisions made by the Chair.

In the Get Data Recipients endpoint the legalEntityName field is mandatory and should be used as the source for these details. A correction to the SSA field descriptions is required to better align to the CDR rules and any CX requirements. A change to the technical standards will be considered as a result of this consultation.

[WestpacOpenBanking]

Representation of CDR Participants Westpac notes the complexity of this issue and we suggest that matters related to how accredited data recipients and related third parties flow through the consent model requires significant consideration of issues and options across user experience, DR, DH, CDR registry. We strongly recommend that the DSB do not attempt to address DP229 concerns within this DP to ensure that all feedback and discussion is not scattered across two proposals.

Westpac welcomes a targeted workshop with representatives from different CDR roles to suitably develop and mature the options before putting them forward for the next consultation. Suggestions to initiate discussions may include: • Collating a few sample sentences that are commonly used across different DH’s consent flow or dashboards, so that ADRs (principals, affiliates, CDR representatives) can see how their representations are being displayed to their end-customers. This would allow the different ADR consent-models to be worked through and represented appropriately to the customer. • The representation field(s) to be provided directly by the ADR to the DHs instead of retrieval from the CDR register.

The suggestion that this change (if any) is to be implemented by 1 July 2024 is not aligned to standard/best practice; the date of the FDO should not be set without consultation on changes to the standards based upon selected options.

[anzbankau]

ANZ agrees with point made by Westpac that changes to the consent model require significant consideration, and that any input on this topic under DP276 be addressed as part of DP229.

ANZ also agrees that 1 July 2024 is not able to be stated as the future dated obligation date until the completion of DP229 and the subsequent release date of any related standards changes

[joshuanicholson]

Overall, we support the changes related to business disclosure consents & business consumer statements. We have a few points that we wish to raise, though

1. The rules [1.10A(9)] indicate that an ADR must take reasonable steps to confirm that the consumer is a CDR Business consumer. We note the comment that an ADR should seek this evidence before inviting the consumer to share data. Does this mean an ADR could validate the 'business' without any UX or input from the consumer? (we appreciate the BCS is required regardless.), We were surprised there was no acknowledgement within the consent flow to provide evidence, like asking or validating an ABN.
2. Based on the above point, based on the wireframes, is the positive acknowledgment of the Business Consumer Statement enough evidence for ADR? In particular for scenarios where the consumer does not have an ABN.
3. There are scenarios where an ADR may have records of a consumer operating many businesses (ABNs). Is the current CX at the level of the person making the BCS, not the status of each business (ABN)?
4. Following on from the above point, should the consent be at the level of the person giving the BCS. Should the business or ABN used as evidence by ADR become inactive during the sharing period does this invalidate the consent?
5. There are scenarios where an ADR may already collect data from a DH. Can the ADR rely on this data as evidence of the consumer being a Business Consumer? (even though the BCS is still a requirement)
6. The example in the wireframes shows consent from a single bank being shared with a non-accredited person. Specifically, where an ADR may hold data before seeking a BCS, the consumer may wish to share many 'accounts' from many DHs. Is the wireframe suggesting a BCDC is for a single DH, or can the BCDC include data from many DHs (across many sectors)?
7. The BCDC include a purpose; we foresee some non-accredited parties having multiple purposes across multiple legal entities (businesses) of a consumer. Does this mean numerous consents to the same non-AP will be required? Or are ADRs allowed to list numerous purposes for a single BCDC? A practical example could be a bookkeeper for a business consumer with various legal entities, and the bookkeeper has been engaged to undertake multiple functions. We this being practically solved by the purpose being quite broad "business services" or "accounting and administration services". Are these broad purposes in inline with the principles of the CX standards?
8. If a BCS is presented to the consumer pre-consent with a DH, and the consumer then proceeds to share accounts that are for both business and 'individual' what obligations are placed on the ADR for the consumer selection, even though the ADR took reasonable steps to validate the consumer was indeed a business.
9. The person (secondary user) giving consent, in most cases, will not be an account owner. Therefore, has there been any consideration that the person making the Business Consumer Statement may not have the authority to make such a statement? Can the ADR rely on the fact that the DH has taken reasonable steps to validate the authority of this person (secondary user)?

[commbankoss]

Hi @CDR-CX-Stream ,

Please find attached CBA’s submission on DP276. CBA also recommends that the obligation date for the proposed changes be determined post further consultation on DP229.

Kind regards, CBA Team CBA Group Submission Decision Proposal 276 20 October 2023.pdf

[CDR-CX-Stream]

Thanks to all who provided feedback. The feedback period is now closed, and we are reviewing responses. Further consultations will be published shortly under DP333 - Business Consumer Provisions and DP334 - Data Holder Dashboards, where standards will be proposed as binding. The issues regarding CDR participant representation will be progressed in DP229 - CDR Participant Representation in due course for further consultation with the community.

[CDR-CX-Stream]

DP333 has now been published to finalise the standards consultation for the July 2023 business consumer provisions.

[CDR-CX-Stream]

DP334 has also been published to finalise the standards consultation on data holder dashboards in response to the July 2023 CDR Rules.

[CDR-CX-Stream]

Hi @joshuanicholson

Thanks for your questions relating to business consumer statements and business consumer disclosure consents (BCDC). The questions that you’ve raised are primarily rules interpretation issues. As such, we’ve shared your queries with ACCC for them to consider.

In relation to your question:

Is the wireframe suggesting a BCDC is for a single DH, or can the BCDC include data from many DHs (across many sectors)?

The wireframe uses a single DH for simplicity. ADRs are not restricted to disclosing data from a single DH for a BCDC, though the flow may need to be ordered in a way that differs to the wireframes if the ADR is yet to collect data from each DH. The consent process for a BCDC must still comply with other relevant Standards, including:

• Disclosure consent: Collection source;
• Disclosure Consent: Descriptions of Data to be Collected and Disclosed; and
• Disclosure Consent: Non-Accredited Person Disclosure Notification

The example wireframes for DP333 demonstrate that ADRs may disclose data from multiple data holders as part of a single BCDC, and also demonstrate how ADRs could comply with the above Standards. This reflects a similar implementation to the detached flow - default example for Trusted Adviser disclosure consents.

Hope this helps.

[CDR-CX-Stream]

The relevant CX data standards (see DP333 and DP334) and CX guidelines (see cx.cds.gov.au) have been published. This issue will now be closed.