Decision Proposal 333 - Business Consumer Provisions

[CDR-CX-Stream]

Tuesday 28 November: Decision Made
The Data Standards Chair has approved this decision.

The decision record can be found below:
Decision 333 - Business Consumer Provisions.pdf

This decision takes effect immediately and, as such, the new July 2023 business consumer provisions are now considered permitted CDR functionality.

Tuesday 24 October: Decision Proposal Published
Decision Proposal 333 proposes data standards for the new business consumer provisions introduced in the July 2023 CDR Rules.

The decision proposal can be found below:
DP333 - Business Consumer Provisions.pdf

The specific topics covered in this paper are:

• Business consumer statements
• Business consumer disclosure consents (BCDC)

This consultation progresses from DP276 to outline which data standards are being proposed as binding. This paper reflects those proposals and, in response to feedback, incorporates minor wording changes in some instances for greater clarity.

Community views are now being sought before these standards are proposed to be made binding to support the 1 December 2023 obligation date for the new business consumer provisions.

This consultation will close on Tuesday 21 November 2023

[CDR-CX-Stream]

The decision proposal has now been published for consultation. The paper can be found in the original post.

This consultation will close on Tuesday 21 November 2023

[perlboy]

The definition of SHOULD means "that there may exist valid reasons in particular circumstances to ignore a particular item".

The proposed Standard suggests the introduction of statement into the non-accredited person disclosure notification:

This information SHOULD be immediately viewable by the consumer without further interaction.

Under what valid circumstances would this not be the case? At face value this statement should actually be a MUST so as to avoid the introduction of a new dark pattern by Recipients exposing Consumers to disclosure outside of the CDR that they were not aware of.

[joshuanicholson]

Could we clarify 'without further interaction' as well; would 'scrolling' be considered an interaction?

The current wireframe has the section "The data you share with [non-AP] is not subject to CDR protection at the bottom" of the consent. However, this would require a user to scroll, considering the level of information to be disclosed above.

An interaction is more like an 'event', for example, a consumer clicking on a button/link for a pop-up or clicking to open an accordion.

As an aside, we like this disclosure at the bottom of the consent next to the Approve or Deny options as it will be the last thing consumers will read before their consent.

[CDR-Engagement-Stream]

Hi all, to support the feedback upon this consultation. The team have put together a video summarising Decision Proposal 333.

[paige-skript]

Skript is supportive of the proposed standards for business consumer statements and disclosure consents.

Our assumption has been that scrolling does not constitute 'further interaction', especially given the wireframes where the disclosure is included at the bottom of a long screen. Agree with @joshuanicholson that this is a good spot for the disclosure.

[CDR-CX-Stream]

Thanks @perlboy, @joshuanicholson and @paige-skript for your comments.

Stu, as you’ve noted in your question, the meaning of SHOULD given in RFC2119 is that:

there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

If no valid reason exists, participants are expected to implement the standard. 

As Joshua has noted, valid reasons may exist for consumers to scroll on the consent screen before this information is actually visible. This is the type of interaction that was considered when wording the proposed standard as a SHOULD. Other implementations may exist where SHOULD provides an appropriate level of flexibility.

If an interaction such as scrolling is required, the expectation is that the content be immediately available to the consumer once they have scrolled to the relevant section. This content should be available without the consumer needing to engage in any further interactions, such as the expansion of an accordion. Under these circumstances, the need to scroll is permissible through the use of SHOULD.

[perlboy]

If no valid reason exists, participants are expected to implement the standard. 

In that case this standard isn't really worth much as it is going to be an extremely hard rule to enforce.

As Joshua has noted, valid reasons may exist for consumers to scroll on the consent screen before this information is actually visible. This is the type of interaction that was considered when wording the proposed standard as a SHOULD. Other implementations may exist where SHOULD provides an appropriate level of flexibility.
If an interaction such as scrolling is required, the expectation is that the content be immediately available to the consumer once they have scrolled to the relevant section. This content should be available without the consumer needing to engage in any further interactions, such as the expansion of an accordion. Under these circumstances, the need to scroll is permissible through the use of SHOULD.

If I was to (mis)read this statement I could also say that, after clicking a modal the disclosure is immediately made available. It was "necessary" because the screen was too small cause my hypothetical app is designed for desktop. The point I'm trying to make here is that a SHOULD is so soft particularly in a CX context it is borderline worthless for negative enforcement (it's useful for positive reinforcement where you say something like "Wording such as the following SHOULD be adopted"). Sure a lawyer could probably take it to court but not before potentially thousands of Consumers are misled.

Finding a way to get to MUST would be a lot more explicit rather than relying on the interpretation of a cavalcade of lawyers to argue the point. Something like:

This information MUST be immediately viewable by the consumer in the default state of the consent screen.

"Default state" would allow for the scrolling but not allow a situation where a Recipient would deliberately hide important information (which they currently are) behind a clickable modal.

P.S. @perlboy or Stuart is fine. Thanks.

[CDR-CX-Stream]

Thanks for adding this detail @perlboy

We take your point about the use of a modal in that scenario, and the proposed standard is not intended to support this approach when implementing the disclosure notification.

We appreciate the alternative suggestion with the use of a MUST. The term 'default state', at least in design, can mean the state of the screen before scrolling, and as such may run into similar interpretation issues. For example, it could prescribe that ADRs display the notification immediately, such as at the top of a mobile screen, instead of a more contextually relevant area after scrolling, which we expect to be just before the affirmative action of consent.

We expect the dark patterns proposals from the consent review consultation would help avoid any intentional or unnecessary obfuscation of critical information in scenarios such as this one.

We can consider how a MUST could be used in this statement and invite views from those who have indicated support for the current proposal, e.g. @paige-skript, @joshuanicholson and @commbankoss.

However, given this amendment would apply to existing implementations for Trusted Adviser and Insight Disclosure Consents too, our preference would be to maintain the currently proposed SHOULD statement to afford flexibility during any requisite transitions.

The introduction of a MUST could then be assessed if issues are identified with business consumer disclosure consent implementations, and pending views raised in this consultation.

[joshuanicholson]

Dear @CDR-CX-Stream, thank you for providing us with additional information. We have already implemented our design with the aim of having the product ready for production by December 1st, 2023. Our design ensures that consumers do not need to take any further actions, as the disclosures are prominently displayed (i.e. MUST) without requiring the user to even scroll. We acknowledge that we have developed a solution that goes above and beyond the requirements, and our primary focus is aligned with potential changes from the consent review(s) while avoiding any dark patterns.

However, the use of the word "should" creates ambiguity, which could lead to friction between our clients and us. We firmly believe that these disclosures must be presented prominently to consumers, and we have designed our solution accordingly. As an ADR we accept the risks and liabilities of consumer consents with DH's, while many other organisations who will be the end beneficiaries of CDR data may prefer to minimise disclosures and create less friction for the consumer.

[commbankoss]

CBA supports the proposed Consumer Experience standards amendments in DP333 as these enhance transparency for consumers in relation to business consumer statements and disclosure consents.

[biza-io]

Please find attached Biza.io feedback regarding DP-333. Specifically, we wish to highlight our callouts regarding whether Business Consumer Consents are, in essence, the introduction of Nominated Representatives by another name and caution all participants that, if so, there is a level of deceptive complexity in technical delivery coupled with a lack of Rules/Standards specificity at this point in time.

DP-333 Business Consumer Provisions Response.pdf

[CDR-CX-Stream]

This consultation is now closed. Thank you to all who responded.

[CDR-CX-Stream]

The Data Standards Chair has approved this decision.

The decision record can be found in the original post.

This decision takes effect immediately and, as such, the new July 2023 business consumer provisions are now considered permitted CDR functionality.

The DSB will discuss the queries raised during this consultation with other CDR agencies, and will consider responses and/or CX Guidelines in due course.

[perlboy]

For the record, it is unclear how the Chair has appropriately considered his obligations under the Rules specifically with respect to clarifying the applicability of Privacy Safeguard violations as a result of permitted but poor CX experience as a result of these Standards.

[CDR-CX-Stream]

Thanks for this input @perlboy.

To help us consider this comment, could you please clarify:

• which Privacy Safeguard(s) you see as being violated;
• which standards you see as permitting what you've articulated; and
• what is meant by 'clarifying the applicability of Privacy Safeguard violations'

[perlboy]

Thanks for this input @perlboy.

To help us consider this comment, could you please clarify:

• which Privacy Safeguard(s) you see as being violated;
• which standards you see as permitting what you've articulated; and
• what is meant by 'clarifying the applicability of Privacy Safeguard violations'

Biza specifically asked questions in order to clarify what you are now seeking to clarify, restating them here:

In summary we ponder the following questions from an end-user context:

1. What are the implications of giving, or not giving, the statement that this is for business
   purposes? Especially for Sole Traders that might have a mix of personal and business
   Consumer data intermingled.
2. What can/should a Consumer be expected to do if they accidently provide access to
   Individual data while agreeing to a Business Consumer Consent? Would this trigger
   Privacy Safeguards? Who would hold responsibility for this potential liability?
3. Should the CDR prevent end-users from completing this incorrect workflow? Put
   another way should a Data Recipient verify in some way that the entity disclosed is
   aligned with a Business Consumer Statement?
4. If a Business Consumer Statement is made by an end-user on behalf of a Non-Individual
   Consumer should other representatives (in Data Holder language “Nominated
   Representatives”) be able to view or modify this statement? What happens if the enduser authoriser leaves the Non-Individual Consumer?

I note that the Decision Record contained no response to these questions nor any other discussion around the feedback received. This is relevant because under Division 8.3, 8.10(b) the Chair "must have regard" for submissions received during public consultation. Given the speed of binding on this DP it seems unlikely this feedback was properly considered and promises to come back later do not meet the bar as far as the Chairs legal obligations.

At a personal level, the way this and #334 have been dealt with by the DSB is quite disappointing. Participants expend significant resources based on real world experience to provide constructive input in order to better the CDR ecosystem. To promise feedback but bind immediately essentially highlights that the DSB and the Chair appear to have little regard for the potential fallout that may result.

I'll try and answer your clarification request but it's pretty difficult without receiving clarification on the questions already posted.

Privacy Safeguards

It's honestly pretty disappointing that the DSB can't see the scenarios which are problematic but by way of sampling some and giving a free kick to help:

1. If a BCDC was given but the Consumer permitted Individual disclosure (i.e. chose the Individual profile) the Data Holder would disclose data within a context which would be, from the Consumer perspective, incorrectly permitted to be used for up to 7 years. If this is the case it could be a violation of Privacy Safeguard 11 which has obligations on Holders who couldn't successfully execute those because they would be unaware it was a BCDC context.
2. If a Recipient became aware that the Consumer who provided data in a BCDC context was in fact an Individual by way of notification from the Consumer (think "Why is my business data not showing?" type support ticket which is inevitable) the Recipient could have an obligation under Privacy Safeguard 13 to correct the data (in this case, probably delete it). This has notification requirements, it's also very unclear and technically impossible (i.e. human intervention required) how a Recipient would communicate such a correct to the Holder. What the Holder does with it is also undefined.
3. As a result of (3) and as documented in the page 15 the flow one effects of correcting the data may have flow on implications to Safeguard 5, 10, 11 and 12.
4. If a BCDC was received for a Sole Trader, in certain Holder implementations the Consumer may select accounts not related to the business itself (because there is no profile selection). There is no mechanism available for the Recipient to determine which accounts relate to the Sole Trader and which ones relate to, for instance, the individual consumers beer fund. Again this is possibly a violation of Safeguard 11 and 13 and therefore could cascade to Safeguard 5, 10, 11 and 12. Interrogation on this behaviour in implementation calls has resulted in Treasury officials considering this to be a feature of the Rules but the BCDC aspect now makes it highly problematic.

Finally, not so much a safeguard as much as a Rules violation, if a Data Recipient used data past a year on the basis of a BCDC but that data was, in fact, for an Individual Consumer (or a Sole Trader disclosed as an Individual but included non business related accounts), this would actually be a direct violation of the entire BCDC Rules structure because it does not apply to Individual Consumers.

Fundamentally it's unclear if the OAIC is even aware of this proposal (@OAIC-CDR?) as they seem best placed to provide guidance on the impact of the now binded Standard in relation to these safeguards. By binding this Standard with immediate effect the DSB has now permitted Recipients to place Holders in essentially undefined territory as far as how to deal with the inevitability of a human selecting the wrong profile. That is particularly relevant in the situation where the BCDC is incorporated in the standard consent flow which is why the Biza submission also included a recommendation on Page 3 of it's submission "Biza supports explicitly separating the collection of the Business Consumer Statement experience steps from the other consents currently collected by Data Recipients.". This statement was included specifically to attempt to ameliorate the likelihood the Consumer may select the incorrect profile (i.e. their individual consumer profile) when they get to the Holder, essentially "cognitive context loading". This suggestion also does not appear to have been considered.

Permitting Standards

As outlined in the Biza submission "Biza supports standardising copy content in simple and concise language for Business Consumer Statements but we note that the proposed Standards place significant responsibility on the end-user to complete the Data Holder workflow correctly. Specifically, the lack of a technical authorisation mechanism that would allow an ADR to request disclosure authorisation for a constrained set of profile types, i.e. Non-Individual Consumers.". Specifically, by binding a Standard enabling BCDC to occur on the Recipient side without solving for a signalling mechanism to the Holder of the intent of the arrangement setup it is impossible for the Holder to limit such options.

I guess short version to answer the request for clarification, the Standard permitting this behaviour is allowing BCDC to be entirely Recipient side without ensuring consent workflow binds the requirement to filter to Non-Individual Consumers.

Clarifying applicability of Privacy Safeguard violations

I'm not sure if I'm repeating myself here but the issue this Standard now introduces is that an action by a Data Recipient (establishment of a BCDC) now potentially exposes the Holder directly to multiple Safeguard violations. Without going into too many specifics, Regulatory action (both Regulators) has been strong in this regard and procedurally are dealt in a very similar way to a Reportable Data Breach. Holders may now be significantly exposed based on the well meaning actions of a Data Recipient and a User who clicked one wrong button.

[CDR-API-Stream]

The code changes for this decision are staged for review - ConsumerDataStandardsAustralia/standards-staging@release/1.29.0...dp/333

[CDR-CX-Stream]

Hi @perlboy,

We have now discussed these queries with other CDR agencies and can provide the following response:

The general nature of these queries are considered rules rather than standards issues.

The Role of the Standards
While the making of these standards has allowed these provisions to be implemented slightly sooner than the 1 December 2023 date, Rule 1.10A(14)(b) permitted accredited persons to begin engaging with business consumers from 1 December 2023, regardless of whether the Chair had made relevant Standards. As such, the standards did not introduce this functionality.

The scenarios outlined in the feedback were identified early on and considered during the rule making process. The subsequent feedback provided on the standards in relation to these scenarios was considered. However, the cited scenarios were not considered to be standards-related/enabled because they go to the operation of the Rules and Privacy Safeguards.

Operation of the Provisions
The CDR rules relating to business consumer disclosure consents and business consumer statements require that the ADR take reasonable steps to confirm that the CDR consumer user has an active ABN or is a non-individual. That is, the person does not have to be a non-individual to share data in the capacity of a CDR business consumer, if the ADR has confirmed they have an active ABN.

The ADR is also required to obtain a business consumer statement from the CDR business consumer – this statement certifies that relevant consents are given for the purpose of enabling an accredited person to provide goods or services to the CDR business consumer in its capacity as a business (i.e. not an individual).

The rules do not constrain data access to non-individual data in relation to these provisions, provided these requirements are met. Flexibility has been provided for a CDR business consumer to share individual data, such as may occur when a sole trader with an active ABN uses their individual account for business purposes. Constraining or requiring data holders to only share non-individual data would be impractical and in conflict with the provisions in the CDR rules.

If a business consumer statement is not given, then an accredited person cannot ask for durations of up to 7 years for the relevant consents, and also cannot request a business consumer disclosure consent.

Privacy Safeguards
In relation to the privacy safeguards , the applicability of particular safeguards will depend on the specifics of each factual scenario, so it is not possible to provide definitive advice.

However, key issues to consider include:

• Whether data received by an accredited person was unsolicited data which needs to be dealt with in accordance with Privacy Safeguard 4
• If Privacy Safeguard 4 doesn’t apply:
  • relevant obligations under the data minimisation principle
  • an accredited data recipient’s obligations under Privacy Safeguard 12 for dealing with redundant data
  • rules around a consumer’s right to withdraw their consent to the collection and handling of their CDR data
• For a data holder’s Privacy Safeguard 11 and 13 obligations, whether or not CDR data is ‘correct’ depends on the purpose for which it is held by the data holder. This means that if a consumer mistakenly authorises disclosure of the wrong data set by their data holder, that data generally will not be ‘incorrect’ data for the purposes of PS 11 and 13 (assuming it is correct for the purpose the data holder holds it), and the data holder would not breach these safeguards.

If the CDR data was unsolicited by the ADR - i.e. the ADR had not sought to collect the particular data authorised by mistake – the ADR would generally need to destroy it under Privacy Safeguard 4.

If the CDR data was not unsolicited – i.e. the ADR did intend to receive the particular data – the consumer could then choose to withdraw their consent, and this would generally trigger an ADR’s Privacy Safeguard 12 obligation to delete or de-identify redundant CDR data.

As noted above, we have liaised with the other CDR agencies to provide this information. They will give further consideration to how best to clarify this in their respective guidance.

[CDR-CX-Stream]

This decision has been reflected in v1.29.0 of the published standards, so this issue will now be closed.