CX Guidelines

Read first CX Checklist attributes ◦ Area refers to the stage in the consumer journey, such as Pre-consent, Consent, Authenticate, Authorise, or Consent Management. ◦ Focus area refers to a specific theme in each stage (e.g. 01. User Identifier). ◦ Checklist ref contains a unique reference number for the item. ▪ The first values refer to the Area (e.g. 0DL.xx.xx for data language; 2AU.xx.xx for authentication). ▪ The second set values refer to the Focus area (e.g. xxx.01.xx). ▪ The last values refer to the annotation number used on the wireframe, where available (e.g. xxx.xx.02; wireframes are linked to in the Example column). ◦ Type refers to the source of the statement: Rules, Standards and Guidelines. ◦ Participant refers to the relevant CDR Participant for the item. ◦ Requirement level refers to the level of obligation. For the data standards, the key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are to be interpreted as described in RFC2119. CX Guidelines provide optional examples and recommendations; as such, a MAY is used to denote a CX Guideline for the purposes of this checklist regardless of the language used in the guideline statement. ◦ Statement refers to the relevant requirement or recommendation as articulated in the rules, standards, or guidelines. ◦ References points to the requirement itself, or its location; typically a rule, standard, or research. ◦ Example links to the relevant artefact, such as the CX Guideline page, which includes wireframes of example implementations, or a table in the case of data language standards. ◦ Version introduced refers to the version of the data standards that was current when the item was introduced to the CX Guidelines, starting from version 1.4.0. Items noted as introduced in 1.4.0 or earlier are requirements that exist in v1.4.0 of the CX Guidelines (PDF). ◦ Date introduced refers to the specific date the item was introduced to the CX Checklist, using August 2020 as a starting point (when v1.4.0 was introduced). The date will typically be the date of the version release, but some new items may not constitute a standards change (e.g. a revised wireframe or rules change) and as such may not align with standards versioning. ◦ Date modified refers to when an existing CX Checklist entry was updated, which is not necessarily the date the corresponding requirement (Rule, Standard or Guideline) was changed. ◦ Status refers to whether the item is active or has been retired from the CX Guidelines. An 'active' item is applicable and current. A 'retired' item may be labelled as such because it no longer applies, has been merged with another item, or has been removed from the CX Guidelines. A 'retired' item may still be a requirement. These statuses are used in the live CX Checklist and CSV to highlight changes between versions of the CX Guidelines.

Wireframe ref	Type	Requirement level	Statement	Reference	Checklist ref	Focus area
01	CDR Rule	MUST	A data holder must update a CDR consumer’s consumer dashboard as soon as practicable after the information required to be contained on the dashboard changes.	CDR Rule 4.27	5CM2.00.01	00. Withdrawal
02	CX Standard	MUST	As part of the withdrawal process, the data holder MUST advise the consumer to review the consequences of withdrawal with the Data Recipient before they stop sharing their data. The data holder MAY consider using or paraphrasing the following message(s): • ‘You should check with [Data Recipient] before you stop sharing to understand the consequences.’ • ‘You should check with [Data Recipient] to see if your service will be impacted before you stop sharing.’	Withdrawal Standards, Withdrawing authorisation: Consequences	5CM2.00.02	00. Withdrawal
03	CX Standard	MUST	As part of the withdrawal process, the data holder MUST inform the consumer about the handling of redundant data and the right to delete. The data holder MAY consider using or paraphrasing the following message(s): • ‘CDR data is either deleted or de-identified when it is no longer required.’ • ‘[Data Recipient] will have specific policies on how to handle your data once it’s no longer required.’	Withdrawal Standards, Withdrawing authorisation: Redundant data	5CM2.00.03	00. Withdrawal
04	CX Guideline	MAY	Data holders should use the phrase 'Stop access', 'Stop sharing' or 'Stop data sharing' to refer to how a consumer can withdraw authorisation. A generic term like ‘stop access’ can refer to withdrawing authorisations or actions. If data holders use this wording, they should clarify its meaning with context-specific explanations. CX research found this wording easy to understand.	CX Research 29	5CM2.00.04	00. Withdrawal
05	CX Guideline	MAY	Data holders should introduce positive friction to the withdrawal flow to mitigate user error and unintended consequences. Data holders may choose to do this via a 2-step authorisation withdrawal process.	CX Research 32 \| 10 Usability Heuristics for User Interface Design: Error prevention (Nielsen)	5CM2.00.05	00. Withdrawal
06	CX Guideline	MAY	Data holders should provide a message to consumers that withdrawal was successful. This message should be clearly visible on the dashboard and shown as soon as withdrawal has taken place.	10 Usability Heuristics for User Interface Design: Visibility of system status (Nielsen)	5CM2.00.06	00. Withdrawal
07	CX Guideline	MAY	Data holders should provide CDR Receipts reflecting the details of the authorisation shown on a consumer's dashboard. CDR Receipts should be provided in writing, such as in an email, when: 1. Authorisations are successfully established 2. Authorisations are withdrawn 3. Authorisations expire 4. Authorisations are amended CDR receipts should also outline details on complaint handling and resolution processes. Dashboards should provide a way for consumers to request a copy of their CDR receipts.	CX Research 20	5CM2.00.07	00. Withdrawal
08	CDR Rule	MUST	(1) If a data holder receives a consumer data request from an accredited person on behalf of a CDR consumer, the data holder must, in the circumstances specified in a sector Schedule, ensure that it provides the CDR consumer with an online service that: (d) as part of the process of withdrawing an authorisation, displays a message, in accordance with the data standards, about the consequences of proceeding with withdrawing an authorisation;	CDR Rule 1.15(1)(d)	5CM2.00.08	00. Withdrawal
09	CDR Rule	MUST	(1) A data holder must keep and maintain records that record and explain the following: (b) amendments to or withdrawals of authorisations to disclose CDR data;	CDR Rule 9.3(1)(b)	5CM2.00.09	00. Withdrawal
10	CX Guideline	MAY	Data holders are expected to record how the withdrawal was requested by the consumer in relation to CDR Rule 9.3(1)(b), but the rules do not require the method of withdrawal to be shown on the dashboard. However, data holders may wish to do this on the dashboard and/or in any CDR Receipt they choose to provide.		5CM2.00.10	00. Withdrawal
11	CX Guideline	MAY	Data holders can refer to accounts using recognised nicknames, icons, account numbers, and account type. They can also include information on other elements the account may refer to such as any related plans, services, properties, numbers, and products.		5CM2.00.11	00. Withdrawal
12	CX Standard	MUST	Data holders MUST advise consumers to check with the relevant data recipient for information about how their data may be handled. The precise wording of this message is at the discretion of the data holder. The data holder MAY consider using or paraphrasing the following message: • ‘You should check with [ADR brand/the data recipient] for more information on how they are handling your data, and for any other permissions you may have given them. See [ADR]’s CDR policy or their Dashboard for more information.’	Dashboard Standards, Data Holder Dashboards, Data Holder Dashboard: Data recipient handling details	5CM2.00.12	00. Withdrawal