Noting Paper 273 - Consent Review

[CDR-CX-Stream]

Wednesday 16 November 2022: Noting Paper 273 Published
The Data Standards Body (DSB) and Treasury are exploring opportunities to simplify the Consumer Data Right (CDR) consent rules and standards to support a better consumer experience while maintaining key consumer protections.

The purpose of this noting paper is to accompany a workshop on 22 November to gather CDR community views on preliminary change proposals and the priority of items that may be considered for future amendments to rules and standards.

The noting paper can be found below:
Noting Paper 273 - Consent Review.pdf

Outcomes from this consultation will inform proposals for a joint Treasury/DSB rules and standards design paper in early 2023.

The noting paper will be open for feedback until 9 16 December 2022.

Anyone unable to attend the workshop may provide written feedback via this GitHub page by this date.

---

Edit: Deadline extended from 9 to 16 December 2022.
Edit: Placeholder context removed, noting paper published

[CDR-CX-Stream]

Noting Paper 273 has now been published and can be found in the original post.

Feedback is open until 9 December 2022.

[CDR-CX-Stream]

Wireframes outlining current state examples and potential future state simplifications can be found below. These artefacts are included in the 22 November workshop.

Consent-review_Wireframes_and_proposed-changes.pdf

[CDR-CX-Stream]

The contributions to the 22 November workshop can be found here: https://miro.com/app/board/uXjVPGFW_t8=/?share_link_id=739147468903

[CDR-CX-Stream]

The following is a breakdown of participant types from the 22 November workshop.

Participant type	Number of participants
ADR	7
Data holder	26
ADR and Data holder	6
Service provider	19
Other	13

The workshop was attended by representatives from energy, telco, and banking sectors.

[CDR-CX-Stream]

A summary table outlining feedback from the Nov 22 workshop can be found below.

Change proposals	Supported	Opposed
1: Pre-selected and actively selected options	Broadly support. Current requirements lead to false choices and increase cognitive load.	Little to no opposition. Concerns that consent would not be 'express' and concerns of ADR asking for more than required (against DMP).
2: Data language standards	Broadly support as conversational tone may be easier to understand.	Low to broad opposition as current requirements seem to work, and are necessary for ensuring ADR/DH consistency.
3: Withdrawal of consent information	Broadly support as receipts/dashboards are the more appropriate place for information on withdrawal instructions and consequences.	Low opposition, some details about consequences may still be useful to include.
4: Authentication information	Broadly support. The fact that personal passwords are not required are more relevant to the user. Authentication references also need to remain flexible for emergent methods.	Low opposition. Referring to authentication method can help user understand next steps.
5: Supporting parties	Broadly support for simplification overall, mixed support on whether to show more or less info in consent flow.	Some opposition around providing this information in the consent flow, seen as confusing for the consumer, and listing too many parties may cause consumers concern.
6: 90-day notifications	Broad to unanimous support of amending rules on 90-day notifications, particularly consolidation (but this could be optional rather than mandatory).	Some opposition related to consolidating and especially tailoring notifications, or to ADRs providing 90-day notifications at all.
7: Dark patterns	Broadly support including principle-based prohibition of dark patterns, with some requesting a more prescriptive approach and/or detailed guidelines/examples on what not to do.	Low opposition for introducing a prohibition of dark patterns. Those who oppose it don't see a need for it, or think the line is too fine between UX patterns and dark patterns.
8: Dashboards for once-off consents	Some support, with record of once-off better off in CDR receipts (without need to authenticate customer).	Some opposition to dropping dashboards for once-off consents, as maintaining a persistent record seen as important.
9: CDR receipts	Broadly support, with many requesting for CX Guidelines to make receipts more consistent across the board.	No opposition noted.
10: Separation of consents (bundling)	Broad support in principle for bundling necessary types of consent (i.e. collect and use consents) but marketing consents should remain separate. Some unsure how this would work in practice.	Low opposition. There are concerns around consents being watered down via bundling (especially with more complex consents like Action Initiation coming up).
11: De-identification and Consent	Many agree that de-identification requirements are confusing for ADRs and consumers. De-identification is difficult to implement and achieve - standards, removal of the de-identification option, or greater focus on DMP might be preferable. Some support deletion by default. It is less confusing for the consumer and will cause less harm.	No opposition to reviewing this area was noted.
Other things that should be covered, general concerns, and priorities etc.	Amending consent simplification should be considered, including the simplification/removal of the authorisation flow when re-authenticating to extend the consent. The consent flow for intermediaries should be improved, such as for CDR reps, TAs etc., where in many cases ADRs are primarily a background enabler. Consistency of presentation needs to be considered further - on both the ADR and DH side, e.g. the ADR's legal name vs brand name vs software product name. This is particularly problematic for CDR representative, TA etc. use cases. Further consideration for how CDR consents interacts with other mechanisms/industries necessary for an ADR's business model, such as where screen scraping is also used (but not always clearly distinguished). DH-side authorisation and dashboard requirements and functionality should be reviewed, such as where a consumer doesn't select a required account during the account selection step; the duplication of info between ADR and DH, which may not be required; and the sharing of 'purpose' information to DH dashboards to support informed authorisation management/withdrawal. Trust-promoting elements should be considered further, so consumers can be confident they are sharing data with genuine ADRs.	Consideration needs to be made for how a desire for principles-based approaches removes useful detail, which could in turn make the CDR less consistent and see the introduction of more 'dark patterns'. Impacts on existing implementations will need to be considered.

[CDR-CX-Stream]

The following are responses to the unanswered parking lot questions from the Nov 22 workshop.

Participant question	TSY/DSB response
If live implementations are non-compliant in CDR receipts, what actions are taken to enforce compliance and by who?	Monitoring compliance and enforcement of the CDR regulatory obligations will be jointly conducted by the ACCC and the OAIC. See: https://www.cdr.gov.au/resources/guides/compliance-and-enforcement-policy
Where it impacts the CX, the rules/standards should always consider ensuring a reversal must always be provided. - case in point , the recent Ceasing sec user - blocking of ADR, does not requires the DH to provide a reversal if and when an account owner chooses to block the ADR. This would be poor CX.	Taken as comment.
Query/comment on the consent principles - (2) Consent is given freely and enthusiastically. How can this be enforced and possibly measured or monitored?	The consent principles are intended to guide the assessment and development of rules and standards, rather than as directly enforceable requirements.
Based on the launch date of the paper in January, when might we expect these rules to be implemented? - revisions to the rules/CX improvements	We're unable to provide definitive timing on the design paper or formal rules process at this at this point. Implementation of any new obligations will be a topic for further consultation.
If consents are to be bundled - will the categories of consent still be used so that the customer knows what consent they are providing? Ie. will the categories of consent be listed - with just one call to action for the customer? I'd like to understand how the categories of consent will continue to be used (if at all).	Categories of consent are closely linked to the rules against bundling via rule 4.11(1)(c). We anticipate covering categories of consent, with respect of bundling, in the design paper.
Does the consent bundling approach also consider action initiation?	We consider the approach to bundling are likely to be relevant to future rules for action initiation. We would welcome stakeholder comments on this point.
De-identification of data is a grey area - is a de-identification consent required when the de-identifiable data is part of the product or service delivered to the consumer as part of the collection consent? For example, providing consumers with individual behaviour vs. a group level comparison. In this example, the process of creating the insight makes the data unidentifiable as it is aggregated. Note, the above example doesn't fit either use cases - 1. selling/keeping de-identifiable data or 2. using de-identifying data for research purposes	Taken as comment
The rules concerning consent bundling imply that the only consent an app ever needs is the CDR consent. Unfortunately this is not the case. An app may need consent to setup payment, provides other services and more. The CDR consent should acknowledge that it is not the only consent being asked for - and should consider the UX implications for the app/service provider. By working in isolation, the end result will be more drop offs and more friction for the consumer. We should take into consideration the impact of the CDR CX flow on ADRs as a whole (ideally they have 1 consent flow not 1-5).	Taken as comment
Re bundling of consents - if they are bundled is the expectation that the customer is still able to independently manage each consent AFTER they have given consent. For example if they're bundled when collecting consent - will they be separated in the dashboard for the customer to independently withdraw / manage each consent category - or will the customer only be able to withdraw their consent altogether.	We would welcome stakeholder views on how bundled consents could apply in the consumer's ADR dashboard. One approach could be to allow the ADR to decide whether the consumer may separate and withdraw bundled consents.

[MichaelARCA]

ARCA is the peak industry association for businesses using consumer information for risk and credit management. Our Members include banks, credit unions, finance companies, fintechs and credit reporting bodies. In the context of CDR, our aim is to ensure the regime supports the access to and use of the data to improve the process of providing and managing credit.

Our previous submissions to Treasury and the ACCC have noted concerns that the consent process is overly complex and limiting, and stands in the way of the CDR system being used by credit providers. Essentially, the current rules (i) make the process too hard for consumers; and (ii) result in credit providers not obtaining the necessary disclosure and use consents (or, at least, not consistently receiving those consents). This feedback has been echoed by many of our Members and other relevant stakeholders. Feedback received from some credit providers is that they do not see the benefit of moving away from current screen scraping technology given the problems with the CDR consent process.

On that basis, we are strongly supportive of the proposal to simplify the CDR consent rules and standards.
In particular, we consider that proposals to allow for ‘bundling’ of consents will both support a better consumer experience and improve the usefulness of the system for credit providers. However, we recommend that this proposal also consider recommendation 6.20 (Industry recommended and endorsed consents) of the Inquiry into Future Directions for the Consumer Data Right. That is, where there is a relatively common use-case for accessing CDR data (such as when assessing a credit application), the ‘bundling’ could be done on a consistent basis using standardised wording across all providers. In this way, consumers would have a consistent experience across all such providers. (Of course, this would not prevent a provider using a bespoke form of consent if it was necessary.)

Such bundled consents would also need to include consents for ‘other purposes’ (as referred to in rule 1.8 Data Minimisation Principle). That is, the bundled consents must allow credit providers to use the data to develop/maintain their credit scoring algorithms using the data (i.e. where such use does not directly relate to the provision of the “requested goods or services” but which are vital to the efficient and responsible provision of credit to consumers.)

[Siewleeseow]

Hi team, appreciate it if you could grant a week extension for our submission to the noting paper 273, such that the new deadline is 16 December 2022.

[CDR-CX-Stream]

In response to community requests, this consultation will be extended to 16 December 2022.

[CDR-CX-Stream]

On 29 November, the DSB held a roundtable on the consent review noting paper with 8 different consumer advocate organisations. Contributions from the roundtable can be found here: https://miro.com/app/board/uXjVPAKSq-o=/?share_link_id=476440308007

A summary table outlining feedback from the session can be found below.

Change proposals	Themes supporting changes	Themes opposing changes
1: Pre-selected and actively selected options	No support. There is concern that consumers may 'gamify' consent by "playing" with different options until they're able to proceed. It is important for consumers to understand the implications of consent and be told why they can't continue without selecting every option that is essential to the provision of the service.	Broadly unsupported. Concerns cited around lack of choice, removal of positive friction, and the collection of more data than necessary (contrary to the Data Minimisation Principle) if consumers do not understand what is essential and what is not.
2: Data language standards	No comments in session	No comments in session
3: Withdrawal of consent information	Neither support/oppose. Instructions should not be necessary - it should be intuitive.	N/A
4: Authentication information	No comments in session	No comments in session
5: Supporting parties	Broadly support showing supporting parties. Important for consumers to understand who may access their data and its implications - but the presentation of this list should manage cognitive load through, for example, appropriate design choices.	No opposition
6: 90-day notifications	No comments in session	No comments in session
7: Dark patterns	Broadly supported. Dark patterns agreed to cause harm. Having principles and examples in relation to dark pattern prevention is necessary, which should evolve and expand as required. Requires strategy on regulating dark patterns.	No opposition
8: Dashboards for once-off consents	No comments in session	No comments in session
9: CDR receipts	No comments in session	No comments in session
10: Separation of consents (bundling)	No support. If implemented, consumers need to be able to de-select a bundled consent, and direct marketing consents should always be separate.	Broad opposition. The point of CDR was to address issues created by bundling. Without stronger structural protections, concerns exist about risk, disengagement, and onus being on the consumer to understand what they've consented to and what is essential.
11: De-identification and Consent	Broad support for deletion by default. Deletion by default helps reduce risk and simplifies consent. Research shows how de-identified data can be re-identified. Companies need to start thinking about data minimisation and their data footprint. Once the data has served its purpose, it should be deleted.	N/A

[NationalAustraliaBank]

Hi, please see NAB's response in the attached document.

NAB Submission on Noting Paper 273 - Consent (003).pdf

[CDR-CX-Stream]

The below feedback is being posted with permission on behalf of Drew MacRae of the Financial Rights Legal Centre.

---

Bundling consents

Stance: Generally opposed to this proposal
Feedback:

• There are serious concerns about any movement to bundling consent – the reason being that it will lead to tick and flick approaches, and a lack of engagement. Consumers won’t engage with the one element that they may not be comfortable with. By “hiding” it in the required fields, consumers may fall afoul of the problems of bundling that CDR was meant to resolve.
• This would be a real backward step to iTunes-like terms and conditions.
• How do we know that a use is required? This will need monitoring and oversight, including regular shadow shopping and other monitoring mechanisms. In particular, oversight needs to ensure that CDR participants comply with any rules relating to “required”, including:
  • the Data Minimisation Principle,
  • that consents must be specific to purpose, and
  • the requirement that the collection and use must be to provide goods/services in accordance with a consumer’s request/consent
• Without this oversight and monitoring, explanations of use cases will be open to interpretation and broad enough to drive a truck through. The financial services sector’s response to the Design and Distribution Obligation is a good example of this issue.

---

Pre-selecting required options

Stance: Generally opposed to this proposal
Feedback:

• This seems to go against the principle of consent being freely given and enthusiastic. Instead, it seems rather disengaged, since it is opt-out rather than in. This could very well lead to a lack of engagement with the data being collected at all.
• See feedback given on “bundling consents”, namely concerns around what oversight exists to ensure that the pre-selected options are indeed required and not simply wanted.
• Consideration should be given to explaining to consumers that certain data clusters are required and why they are required. Also consider the ability to uncheck all the boxes, even where “required”.
• Behavioural biases should not be used as justification to disempower people and fall back into the same traps we have currently. It should be made clear to people what data points are required, but still give them the choice to untick. This would then lead to a decision tree to leave the service. Either that or have a link to leave the service if people do not want to share a particular “required” data point.
• The assertion that the tick boxes “represent a false choice if the consumer can’t genuinely de-select” is rejected. The choice is between continuing with the on-boarding or exiting the on-boarding. By not allowing people the ability to make an express choice here – be it via a tick box or a button that says they don’t agree to those required datapoints – you are effectively disempowering the user. The result is that they are almost trapped into continuing on unless they close the app altogether.

---

Data language standards

Stance: No strong support or opposition, but consideration should be given to whether comprehension can always be achieved through “concise” statements.
Feedback:

• Comprehensibility and brevity are always at odds when trying to convey technical language in Plain English. If brevity is prioritised, obfuscation ensues; language becomes vague and can end up meaningless.
• Plain English-ing technical language means a lot more words, putting comprehensibility and brevity at odds. Obviously, some things can be edited down – but others simply can’t.

---

Withdrawal of consent

Stance: Broadly supportive of the proposed approach
Feedback:

• Reduce the amount of information provided re: withdrawal of consent warrants cynicism – it is in the interests of commercial entities to provide the least amount of information and increase friction for people to withdraw consent.
• That people are alerted to the fact that they are able to withdraw their consent at any time is the most salient point during the consent process (rather than instructions on how to withdraw being provided in the consent process).
• The fact that there is no way to withdraw consent from the Trusted Advisor side is problematic and creates yet another problem inherent to this category. Presumably, there will be situations where people would have deleted the ADR app because the information was obtained and used by the TA.

---

Dark patterns

Stance: Support for both principles based approach and prescription
Feedback:

• CPRC have identified plenty of dark patterns with examples.
• Principles based versus prescription is a common issue. Suggest that the principle is stated and then outline examples of those dark patterns (see ASIC and Explanatory Memoranda). It is important to include as many practical examples as possible – and provide scope to introduce new ones as they emerge.
• Who monitors and oversees dark patterns here? That is – they may be prohibited but how do we know CDR entities are complying? The critical part of principles based regulation is a proactive regulator.

---

De-identification

Stance: Support for deletion by default
Feedback:

• De-identification and deletion are confusing concepts for everyone (not just consumers). It could and should be simplified.
• Interested in understanding research findings into de-identification, including what reasons were given for de-identification, and why consumers may have consented to this, such as through dark patterns, a lack of understanding, or a compelling reason.
• The de-identification option presented to consumers represents a dark pattern and takes advantage of their lack of understanding. Reasons for de-identification need to be more specific. Altruistic reasons are few and far between in the commercial realm, so de-identification is sold to them in some way. This could easily veer into misleading and deceptive behaviour.

[commbankoss]

CBA appreciates the opportunity to provide feedback on this Noting Paper. Please see attached for our feedback.
CBA Submission Consent Review final 151222.docx

[CDR-CX-Stream]

The below feedback is being posted with permission on behalf of Australian Payments Network:

AusPayNet Submission to Noting Paper 273.pdf

[fdata-anz]

FDATA ANZ welcomes the opportunity to respond to Noting Paper 273. We applaud the approach to persistently improve the CX experience as this is one of the fundamental aspects that will support adoption of the CDR over the coming years. We are generally supportive of recommendations made from this research in the noting paper and believe that they will help to drive adoption of the CDR by addressing the considerable level of consent flow friction.

But there are a range of issues that are outlined below that warrant further consideration from the DSB and the broader community.

Pre-selected and actively selected options

If data is being requested that is not required for the proposition to be delivered then this contradicts the data minimisation principle. If data is being requested that is required for the provision of the good or service please see feedback on issues with consent needing to be voluntary.

Data language standards

Maintaining consistency in the language used to describe the data request is crucial. While mental models of consumers vary in how they understand data and it’s relationship to collection and use for a product or service the CDR also serves over time to support consistency in these mental models.

Conversational interfaces can be a more natural and intuitive way for people to interact but they also need to be designed well. If this direction is pursued the DSB should work on a consistent set of patterns and guidance to support best practice in this form of Human-to-Computer Interaction.

Withdrawal of consent information

We support the removal of detailed withdrawal instructions in the consent flow. A reference made to this is sufficient with details left for the CDR policy and within the ADR dashboard. However, withdrawal of consent should not be more difficult than giving it. There are considerations to the difficulty of withdrawing consent when a consumer has provided consent to many different ADRs which is likely as CDR expands. See feedback on issues with many dashboards.

Supporting parties

As CDR expands across more sectors it is likely that additional OSPs will be involved and further representation of parties through the access models needed in the CX. Taking this into account for how this will be factored into the consent flow is important now. Research in this area indicates that disclosing parties that will have access to data before a consumer grants consent is desired for trust to be built. But transparency can also be to the detriment of conversion if consumers see representation of parties that they do not trust. A balance does need to be struck between the need for informed consent and the information provided in the consent flow vs the CDR policy.

A brief reference to these parties should be made available upfront in the initial agreement in the consent flow with further details made available in CDR policy.

This also highlights the challenges around informed consent and the need for comprehension. Language simplification and improving readability generally means more words. Increasing the time to comprehension. The CX metrics around comprehension, time to comprehension and propensity to willingly share are crucial here. There may well be correlations that increased time to comprehension impacts conversion when looking at stated preference (propensity to willingly share) vs revealed preference (actually converting). This is a research challenge for the CDR as gathering data and answering research questions around what people do vs what they say they'd do is valuable to improving the overall CX for CDR. Please see challenges for research in CDR.

Authentication information

Providing brief information to assuage concerns on security around passwords is important. Given the recent incidences and the increasing concern consumers have around phishing scams this should remain. However the exploration of additional methods of authentication aside from OTP such as through cascading models are likely to make this requirement redundant.

CDR receipts

We support improving the rules around what to include in this receipt to be made more explicit. A consent receipt standard was something that was being worked on through the Kantara Initiative which may warrant consideration on how to approach this.

We support keeping this included as the receipt forms the basis of a crucial record that can be referred back to by the consumer. This is noted as important as CDR expands and the needs of the consent agreement CX change. The receipt will serve an important function in supporting consumers in having more meaningful control and understanding all the data sharing agreements they have entered into.

90-day notifications

The 90 day notification requirement is plugging a gap in the design of CDR whereby consumers have no single place to manage the data sharing relationships with brands they have. This intersects with the many dashboards issues highlighted below. We support in the interim the proposal on consolidating notifications and enabling more preference control.

Dark patterns

The existing CDR rules framework may well provide a reference point for avoiding dark or deceptive UX patterns. Being:

• The data minimisation principle which prohibits ADRs from collecting more data than is reasonably needed to provide a consumer with the relevant good or services requested (CDR Rule 1.8);

• Granting of additional permissions or making consent withdrawal more difficult could be addressed by the requirements that consent be voluntary, easily withdrawn and not bundled. (CDR Rules 4.9 and 4.10)

But we support collaborative and principles based approaches from the governing bodies and the CDR community to explore how to address this challenge.

Being prescriptive in this area may well serve to increase regulatory complexity and hinder adoption of the CDR. It also creates more questions for monitoring and enforcement. Adding to the workloads of already resource constrained regulators like the ACCC and OAIC. In this light we suggest caution with encoding this type of requirement within the CDR standards. Principles based approaches and guidelines as suggested in the noting paper may well suffice but additional community discussion is needed on this. Hence we advocate for the creation of an open source design pattern library that serves as an educational resource with broader application as it falls into the responsible and ethical technology fields that are building in momentum in Australia and across the globe. This is helpful for CDR but also serves broader applications for other digital experience design.

Dashboards for one off consents

The need for data recipients to provide a dashboard to consumers for one off consent (e.g. for an affordability assessment on a loan) is an unnecessary cost. There is no benefit to consumers and it would be unlikely that any of them would access this dashboard.

We support the change to remove the requirement for dashboards to be provided to consumers if the only interaction they have with an ADR is based on a one off consent. But due consideration should be given to where retaining data is required for compliance with other legislation.

Data de-identification

Please refer to contributions from Dr Chris Culnane in the report for Phase 2 - Stream 2: CX Workstream on Consent Management and Revocation in 2019 outlining issues related to practicality and verifications of de-identification or deletion.

We support the DSB in inviting further community feedback on this.

Consent as voluntary

While this was not part of the review covered in the noting paper it is an inherently problematic part of the rules and consent being the only basis under which data can be shared.

For consent to be voluntary it must not be a precondition of service. Meaning that when a company requests consent from a consumer as the basis under which they collect and use data they are making consent a precondition of service. Under GDPR for instance this is why consent is one of many lawful basis under which data can be collected and used.

This conflicts with the notions put forward in pre-selected and actively selected options where actively selected options would be checked if they are essential to the provision of the good or service.

Consent is a very high bar to design for in data sharing interactions. Especially considering the demands consumers have for convenient and low friction digital experiences.

We could remove the voluntary from the CDR rules in the Act. While this may contradict the characteristics of consent as a legal construct defined in laws in other jurisdictions it does address this underlying issue in the definition we have within CDR.

In reality the high levels of friction in the current consent flow (not including the authentication and authorisation stages) are due to the high bar of these said characteristics expressed in the Act (CDR Rule 4.9).

Voluntary, informed, express, specific as to purpose, time limited and easily withdrawn.

As a community we need to explore other models for enabling CDR to scale, particularly when thinking about adding action initiation to the equation. There are reference points for alternatives to consent, notably covered in ‘Beyond Consent: A Right-to-Use License for Mutual Agency’ published in IEEE Communications Standards Magazine.

A series of design jams and/or hackathons could also be a way to incentivise innovation in this critical area. This benefits all CDR participants and in particular consumers. It also supports decision makers in other jurisdictions that are, and inevitably will, grapple with the same issues. FDATA ANZ is considering these approaches but support from the CDR governing bodies and other industry participants is necessary.

Many dashboards

Currently the rules prescribe that for each consent given the ADR must provide a dashboard to enable consent to be managed and revoked. This is crucial to consent being easily withdrawn. But as CDR moves beyond it’s current uptake and data from many sectors is shared, we can easily anticipate a consumer having numerous dashboards. Unmanageable even for the digitally competent.

If the spirit of the CDR is to give consumers more meaningful control over their data, the current approach to consent management needs serious attention. Having a dashboard in the data holder and recipient ends of the relationship is untenable as CDR expands and general action initiation comes online. The impact of this was explored in the Phase 2 - Stream 2: CX Workstream on Consent Management and Revocation in 2019. A recommendation was provided in that research report to address this issue earlier rather than later. Action initiation is anticipated to draw in more participating ADRs as AAIs into the ecosystem and further designations will increase the dashboards consumers will have.

As with many issues that exist with the current state of the CDR ecosystem delaying action risks systemic failure. With every new designation this all gets more complex. Combined with new access models, more recipient propositions will exacerbate the apathy that consumers already experience with control of their data in digital society and any agency they have in relationships with companies. Further cultivating digital resignation that already plagues modern digital life. See N. Draper and J. Turow, ‘The corporate cultivation of digital resignation’, (2019) New Media & Society

This fundamental flaw in the design means we must explore alternatives now before sunk costs become an overwhelming force of resistance to change.

Consent management is not a new thing, personal data and information management systems have been around for over a decade. Adaptations and alternatives to consent have been outlined by others that have spent many years thinking and working through these types of problems. Technical reference points like the Kantara Consent Receipt Specification, Grant Management for OAuth 2.0 and Verifiable Credentials are also there to inform community discussion and decision making.

The design and technical constraints are solvable, but political will and the optimal policy setting and standards shaping process is needed.

Challenges in research for CDR

FDATA ANZ believes that a persistent focus on improving the CX is a critical area for CDR adoption and ecosystem success.

More importantly, the challenge of CDR highlights the need for open innovation environments that blend CX, regulatory learning and standards development in a holistic way. Drawing on the brains trust of the diverse ecosystem and community that is coalescing around the CDR.

CX research methods used to gather data and evidence to test hypotheses and work through assumptions is an ongoing challenge. Much of CX research is primarily focused on gaining direct qualitative data across attitudinal and sometimes behavioural dimensions. The constraints on research cohort sample sizes with qualitative research are warranted. Larger sample sizes take much more effort, time and resources to execute. But both qualitative data and quantitative data across attitudinal and behavioural dimensions in research needs to be sought. Particularly as understanding what people actually do vs what they say they'll do is invaluable insights to inform standards development.

Much of the prescriptive approaches that have emerged over the last years are a result of the perceived need to protect consumers and pre-empting what is needed. Particularly when the data is outside the sphere of the meaningful control of consumers. This was highlighted in the research done in the Phase 2 - Stream 2: CX Workstream on Consent Management and Revocation in 2019 and additionally calling for an explicit Experimentation and Collaboration Framework.

We recommend that the governing bodies and the community explore the desirability, viability and feasibility of creating a Colab style environment. This should operate as an innovation environment guiding the CDR ecosystem participants and the governing bodies in a learn by doing approach that helps CDR evolve as a living framework.

[anzbankau]

Thank you for the opportunity to provide feedback on Noting Paper 273, please see below for feedback from ANZ:

Pre-selected and actively selected options

• Broadly supportive. Consumer should still have the option to de-select if they choose to do so
• Pre-selection options should be in keeping with data minimisation principles

Data language standards

• Broadly supportive of conversational language but should not come at the expense of transparency. Language should be clear and enable consumers to be informed

Withdrawal of consent information

• Broadly supportive

Authentication information

• Further research required, as authentication methods continue to evolve. As long as data holders continue to offer OTP capability, we believe the reference to OTP remains relevant and should be retained

Supporting parties

• Broadly supportive. Agree with ADR displaying names of sponsors and principles. Consider where it would be most appropriate to list OSPs which is both useful and accessible to a consumer

90-day notifications

• Whilst we acknowledge risk of “notification fatigue” we would recommend that approaches remain in the competitive space, rather than prescribing “tailored” solutions

Dark patterns

• Supportive of the intent though further research required as this is a developing field

Dashboards for once-off consents

• Not supportive. Centralised record keeping for all consents, irrespective of duration, encourages transparency and enables issue resolution when required

CDR receipts

• Supportive. This will ensure that consumers are provided the minimum information required and consistency across all ADRs

Separation of consents (bundling)

• Broadly supportive. Consents should align with the ADR proposition and align to the consumer’s expectation

[SelenaLiuEA]

EnergyAustralia welcomes the opportunity to provide feedback on this Noting Paper, as attached.

EnergyAustralia - CDR Consent Review - feedback.pdf

[rob-hale]

Some great dialogue and discussion on this topic following a very worthwhile workshop. Congratulations to all involved. The outputs from that workshop as summarised above appear well considered and consistent with long-standing opinion within CDR on where consent optimisation effort should be expended for best consumer benefit. Some subsequent comments appear to challenge this broader opinion so I am offering the following additional context on two topics:

Bundling of consents already exists today - for example where consumers consent to collection and use of data. I am not aware of any issues having surface as a consequence of this. Provided these consent types are required in order to provide the service (as required within the current rules), I fail to see how continuation of this style of consent could be viewed as harmful or damaging. There are many established pre-existing controls in this space, including ADR accreditation, ACCC compliance and enforcement oversight and civil penalties.

Pre-selection of data scopes is a long-standing desire from those endeavouring to design a simple, clean and understandable consent experience. The simple suggested change to allow preselection where it is required in order to deliver a specific service will make a material difference to consent experience. It will reduce the cognitive load (within an already burdensome consent experience) on consumers and simplify and streamline the consent flow. The suggestions on this point within the Noting Paper make sense and, in my opinion, reflect consistent feedback gathered over the last 2+ years from ADRs attempting to design meaningful, informed consent experiences for consumers. This is perhaps the most simple, yet powerful and effective change that could be made to the current consent experience.

[Telstra-CDR]

Telstra welcomes the opportunity to provide feedback on this Noting Paper
Consent Feedback.docx

[joshuanicholson]

Pre-Selection
We broadly support the adoption of the pre-selection of data types to be shared. Our current consent screens indicate the data types we require and provide a validation message should the consumer not select the required data types. Should pre-selection be allowed, this will reduce the number of "clicks" consumers need to undertake and allow them to deselect the data types they wish not to share. We intend to maintain our validation messages to ensure consumers share the correct data (for accounting software, there is no benefit in collecting CDR data without transactions). Per our accreditation requirements, we intend to apply data minimisation principles, so data types that are not required will not be displayed, therefore, unable to be preselected or deselected; our UX will always attempt to reduce cognitive overload.

We appreciate and acknowledge that the consent process requires a level of disclosure and transparency; however, it should be recognised that many customers (businesses in particular) have become familiar with the screen scraping process, which is extremely simplistic and the CDR consent at first may be considered 'too much'.

Data Language Standards
We do support a review of the data language. However, we also note the competing requirements of language. The issue is having the flexibility of language being relevant & consistent to the ADR's product or service, v's a consistency of languages between the ADR & the Data Holder and the various language for consents across differing sectors. Perhaps the standards could be a selection of allowed terms, giving the ADR options to select the most appropriate terms for their product or service.

Another issue with the current standards is that an ADR is required to ask for "data" that may be collected, not actually used or saved. On the same note, consumers are presented with a list of data elements that MAY be shared instead of what the DataHolder is actually sharing. The combination of these two issues could materially misrepresent the shared data and negatively affect the consumers' decision to share. As an ADR, we believe in the principle of being precise with the data that will be used and how it will be used.

Withdrawal consent
We believe a significant simplification of the withdrawal wording/requirements should be made to the consent standards. Our view of simplification is that only a note to the consumer that the consent can be withdrawn and a link to further documentation. Rather than loading up the consent workflow with any additional requirements, we feel a better place for the withdrawal requirements is the ADR dashboard and the consent receipt (and 90-day notification depending on the outcome of that review). We would like only to have relevant information in the consent process and reduce the cognitive load on consumers. To extend this simplification, we would accept any reduction in the requirements for the consent to become a requirement for the dashboard, receipt & notifications. The idea that a consumer would consider withdrawing consent while initially giving consent is mixed messaging.

Authentication Information
Our experience with consent is mixed; consumers with extensive knowledge of technology or prior experience with OTP frameworks are quite comfortable with the term one time password (OTP). In contrast, consumers with less experience or knowledge find the word "password" confusing. The media have warned the public, as have Government education campaigns, family, friends and even the banks, to not disclose "passwords". We also note that some banks have not previously used an OTP framework with their customers; therefore, the OTP workflow within CDR is the first experience of the term and can be confronting due to the phrase "password" being used in a different context.

During the consultation, one Bank reference their phrase "One time code", and we have also seen terms like confirmation request, push notification & validation code; we feel these all represent a plain English description of the process the consumer is undertaking. We would like to see the CDR workflow distance itself as much as possible from screen scraping technology & therefore, emphasise that consumers are not sharing their credentials with third parties.

Despite the varied experience and some other issues, we remain somewhat comfortable with the phrase One Time Password or OTP; however, we do recommend some flexibility for Banks to utilise their own terms. Like the data language review, perhaps a range of allowed phrases could be utilised to give Banks the flexibility to ensure the language matches other banking experiences.

Support Parties
In theory, this change makes sense, and we generally support it. We are supportive of all parties being disclosed in a similar manner, with similar information and therefore reducing the cognitive load (that is, reducing the number of screens/pages, text & number of clicks). However, we also would like to mention that not all parties are "equal" in their roles; that is the level of data access, risk, insurance, use & storage of data, plus many other factors. A unified approach equalises all supporting parties and does not accurately inform the consumer of each party's role in the consent, collection, use & storage of their data.

90 Day Notification
We support some changes to this requirement, specifically the ability to consolidate notifications. We support multiple consents from the same or different banks to be consolidated into a single notification. We would also recommend that ADR be allowed to consolidate notifications due in a +/- 14-day period be consolidated into a single notification. For example, an ADR reducing four consents across three banks, given over a two-week period, could be consolidated into a single notification.

The majority of our user cases; are for businesses consenting to their accounting or administration systems, and this is an ongoing relationship, so our consumers would consider any notification to be "noise". The only exception is a reminder for the consumer to re-consent at the 12-month expiry. Despite this, a continuous reminder does provide some value and transparency so we recommend % of consent period approach; for example 50%, 80% & 95%, so the days between notifications are based on the period of consent.

Dark Patterns
Dark patterns are a fascinating topic worthy of discussion, some would say, with a beer or wine in hand. We believe anyone participating within the CDR system is, by definition, a good actor and not likely to be employing dark pattern tactics. Many of the approaches to avoiding dark patterns are a principle-based methodology rather than a prescriptive or standards-based approach. Based on the good standing of CDR participants and an inability to enforce a principle, we don't believe there is enough proposed detail to support this change. However, we are very supportive of the CX/UX team considering dark pattern avoidance when determining the standards.

Once-off Dashboard
We don't support the removal of the dashboard requirement for once-off consents. For an ADR who only requests once-off consents, removing this requirement may be applicable and reduce the build cost. However, for an ADR who has consented for two or more days, removing this requirement will save little time & cost. Our primary reason for not supporting this change (for ADR or DH) is the need for more accurate reporting to the consumer. Consumers should be provided with a complete history of their consent, whether from the ADR or DH perspective. We are concerned that removing a dashboard removes evidence of the consent and therefore relies on a consumer's "memory" of whom they gave their consent & data. While consent receipts are also a valuable requirement, files & emails are quickly deleted or lost; therefore, an ADR's most reliable evidence of consent is the dashboard.

CDR Receipts
SISS is broadly supportive of receipts and also supportive of more explicit information requirements. We are also supportive of an uplift in the CDR receipt requirements should changes be made to other requirements like 90-day notifications, withdrawal of consent or support parties.

Separation of consents (bundling)
SISS is very supportive of bundling of consents. At present, consumers may be required to give multiple consents to practically share their data. We believe bundling will consolidate the consents into a single streamlined process. This will provide less friction and cognitive load. We also agree with other comments that consumers may need to 'de bundle' individual consents. Alternatively, the consumer would need to withdraw the entire consent and re-consent.

We note comments from some parties that bundling may allow ADRs to over-collect or get consent for purposes not required. We reject these comments as the suggested changes are no different to the current process. There is technically nothing stopping an ADR from overreaching with their consent requests now. An ADR must comply with standards (that include data minimisation principles) and oversight from ACCC and other bodies, and there is no suggestion of this change. We want to point out that consumers initiate the entire consent process and they are not 'forced' to complete the consent workflow, and if they wish to deselect a dataset or type of consent, they can.

De-identification of Data
We have no issue with the current rules or proposal around the disclosure of how data could be used if the consumer elects data to be de-identified. We are an ADR that believes the default option should be to delete redundant data, the vast majority of our business cases, deletion is the preferred option. We have observed the same consumer difficulties in understanding the differences between the options. To compound this issue, most of our business cases have other legislative requirements to maintain data, for example, KYC, responsible lending, tax, accounting, audit or other compliance. Considerations of how these other legislative data retention requirements interact with CDR are taken into account in relation to the various. disclosure requirements.

[CDR-CX-Stream]

This consultation is now closed. The Treasury and DSB are now reviewing submissions.

Thanks to everyone for engaging and providing comprehensive feedback on this noting paper.

[CDR-CX-Stream]

The Consent Review Design Paper has now been published, and can be found on GitHub here: #321