CX Guidelines

Read first CX Checklist attributesArea 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

(1) When asking a CDR consumer to authorise the disclosure of CDR data, or amend a current authorisation, a data holder must give the CDR consumer the following information about the authorisation or amendment: (a) subject to subrule (2), the name of the accredited person that made the request;

CDR Rule 4.23(1)(a)

3AU.00.01

02

CDR Rule
MUST NOT

When asking a CDR consumer to authorise the disclosure of CDR data or to amend a current authorisation, the data holder must not do any of the following: (a) add any requirements to the authorisation process beyond those specified in the data standards and these rules; (b) provide or request additional information during the authorisation process beyond that specified in the data standards and these rules; (c) offer additional or alternative services as part of the authorisation process; (d) include or refer to other documents.

CDR Rule 4.24

3AU.00.02

03

CDR Rule
MUST

(1) When asking a CDR consumer to authorise the disclosure of CDR data, or amend a current authorisation, a data holder must give the CDR consumer the following information about the authorisation or amendment: (c) the types of CDR data for which the data holder is seeking an authorisation to disclose;

CDR Rule 4.23(1)(c)

3AU.02.03

04

CDR Rule
MUST

(1) When asking a CDR consumer to authorise the disclosure of CDR data, or amend a current authorisation, a data holder must give the CDR consumer the following information about the authorisation or amendment: (b) the period of time to which the CDR data that was the subject of the request relates;

CDR Rule 4.23(1)(b)

3AU.02.04

05

CDR Rule
MUST

(1) When asking a CDR consumer to authorise the disclosure of CDR data, or amend a current authorisation, a data holder must give the CDR consumer the following information about the authorisation or amendment: (e) if authorisation is being sought for disclosure over a period of time―what that period is;

CDR Rule 4.23(1)(e)

3AU.02.05

06

CDR Rule
MUST

(1) When asking a CDR consumer to authorise the disclosure of CDR data, or amend a current authorisation, a data holder must give the CDR consumer the following information about the authorisation or amendment: (d) whether the authorisation is being sought for: (i) disclosure of CDR data on a single occasion; or (ii) disclosure of CDR data over a period of time of not more than 12 months; Note: While certain consents by a CDR business consumer can have a period of 7 years, a corresponding authorisation cannot be for more than 12 months before renewal under subparagraph (1)(d)(ii).

CDR Rule 4.23(1)(d)

3AU.02.06

07

CDR Rule
MUST

(1) When asking a CDR consumer to authorise the disclosure of CDR data, or amend a current authorisation, a data holder must give the CDR consumer the following information about the authorisation or amendment: (f) a statement that, at any time, the authorisation can be withdrawn;

CDR Rule 4.23(1)(f) | CX Research 30, 32

3AU.02.07

08

CDR Rule
MUST

(1) When asking a CDR consumer to authorise the disclosure of CDR data, or amend a current authorisation, a data holder must give the CDR consumer the following information about the authorisation or amendment: (g) instructions for how the authorisation can be withdrawn.

CDR Rule 4.23(1)(g) | CX Research 30, 32

3AU.02.08

09

CDR Rule
MUST

(1) A CDR consumer who has given an authorisation to a data holder to disclose particular CDR data to an accredited person may withdraw the authorisation at any time: (a) by using the data holder’s consumer dashboard; or (b) by using a simple alternative method of communication to be made available by the data holder for that purpose.

CDR Rule 4.25(1) | CX Research 30, 32

3AU.02.09

10

CDR Rule
MUST

(2) If the withdrawal was in accordance with paragraph (1)(b), the data holder must give effect to the withdrawal as soon as practicable, and in any case within 2 business days after receiving the communication. Note: This subrule is a civil penalty provision (see rule 9.8).

CDR Rule 4.25(2)

3AU.02.10

11

CDR Rule
MUST

For paragraph 56ED(7)(b) of the Act, the CDR entity must make its CDR policy readily available through each online service by means of which the CDR entity, or a CDR representative of the CDR entity, ordinarily deals with CDR consumers.

CDR Rule 7.2(8)

3AU.02.11

12

CX Standard
MUST

Data holders MUST allow the consumer to select which of their accounts to share data from if the data request includes account-specific data and if there are multiple accounts available. The Data holder MAY omit this step if none of the data being requested is specific to an account (e.g. Saved Payees).

Authorisation Standards, Authorisation: Account selection | CX Research 9

3AU.01.12

13

CX Standard
MUST

Data holders MUST show which accounts the data is being shared from prior to confirming authorisation if the data request includes account-specific data. The data holder MAY omit this information if none of the data being requested is specific to an account (e.g. Saved Payees).

Authorisation Standards, Authorisation: Account confirm

3AU.02.13

14

CX Standard
MUST

Data Recipients and Data Holders MUST use data language standards to describe data clusters and permissions in consumer-facing interactions. See the Banking Language section for language to be used when requesting banking data; and the Energy Language section for language to be used when requesting energy data. Data language standards MUST be used when CDR data is being requested, reviewed, or access to such data is withdrawn. Data Recipients and Data Holders MUST use the appropriate data standards language for business consumers as denoted with an '*' for the relevant data. Data Recipients and Data Holders SHOULD expand on the proposed language where appropriate to communicate further details of what is being shared. Additional details MAY include additional information in context, such as in-line help or tool tips, and/or additional permissions where they may exist. Examples of permission details that MAY be used and provided as in-line help are denoted with an '†' for the relevant data.

Data Language Standards: Common, Data Language Standards: Language to be used

3AU.02.14

15

CX Guideline
MAY

CDR Rules 4.23(1)(a) and (2) require data holders to refer to the accredited person's name using the legal entity name held in the Register during Authorisation.

CDR Rule 4.23(1)(a) and (2) | 10 Usability Heuristics for User Interface Design: Match Between the System and the Real World (Nielsen)

3AU.02.15

16

CX Guideline
MAY

Data holders can meet CX Standard on Authorisation: Account confirm with the account selection step only. The selected accounts do not need to be displayed again on the final confirmation page.

3AU.02.16

17

CX Guideline
MAY

For the purposes of CDR Rule 4.23(1)(b), data holders could refer to: • the earliest holding day as specified in the designation instrument; • a more recent date where the data has a shorter historical range. Note 1: For banking sector details on historical data access, refer to Schedule 3, Rules 3.2 (4) and (5), noting the earliest holding day specified in the Authorised Deposit-Taking Institutions designation instrument being 1 January 2017. Note 2: For energy sector details on historical data access, refer to Schedule 4 Rule 3.2(2)(b)(iii), noting the earliest holding day specified in the Energy Sector designation instrument of 1 July 2018. Note 3: A generic date may not be meaningful to a consumer whose data has a shorter historical range. For example, if a consumer only opened an account with a Data Holder on 10 February 2021, a Data Holder may wish to present this more precise and meaningful date for the purposes of 4.23(1)(b).

3AU.02.17

18

CX Guideline
MAY

Data holders should use plain language phrases such as 'stop sharing' to refer to how a consumer can withdraw authorisation.

CX Research 29

3AU.02.18

19

CX Guideline
MAY

In addition to providing withdrawal instructions, data holders should provide instructions for how to review sharing arrangements.

CX Research 20

3AU.02.19

20

CX Guideline
MAY

Data holders should include their CDR policy in the Authorisation flow.

3AU.02.20

21

CX Guideline
MAY

Data holders should use terms that align with equivalent authorisation actions already in use in their digital experiences. The chosen language should clearly communicate a final affirmative action to mitigate user error. CX research suggests that terms like 'confirm' and 'authorise' successfully and meaningfully communicate the final affirmative action.

10 Usability Heuristics for User Interface Design: Error prevention (Nielsen)

3AU.02.21

22

CX Guideline
MAY

Data holders should redirect the consumer back to the data recipient following the final affirmative action.

3AU.02.22

23

CX Guideline
MAY

Data holders should provide a CDR receipt to the consumer after they have authorised to share data. The receipt should provide the consumer with a record of their sharing arrangement, including details that relate to the authorisation. The CDR receipt should be given in writing and available through the data holder consumer dashboard.

CX Research 20

3AU.02.23

24

CX Standard
MUST

If a scenario requires it, Data Holders and Data Recipients MUST merge and amend Basic and Detailed data cluster and permission language to show that Detailed scopes include Basic data. Data Holders and Data Recipients MUST use the alternative language denoted with an '‡' for the relevant scope(s). See the Banking Language section for banking data and the Energy Language section for energy data. Example: A Data Recipient presents the Detailed data cluster in a data request to a consumer, but does not present the Basic data cluster. The Detailed scope includes Basic data, but this is not apparent to the consumer based on the data cluster language and permissions used for the Detailed scope.

Data Language Standards: Common, Data Language Standards: Detailed scope requests

3AU.02.24

25

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.

3AU.01.25

26

CDR Rule
MUST

If an authorisation to disclose particular CDR data to an accredited person is withdrawn or otherwise expires, the data holder must notify the accredited person in accordance with the data standards. Note: This rule is a civil penalty provision (see rule 9.8).

CDR Rule 4.26A

3AU.02.26

27

CX Standard
MAY

Data holders MAY include additional functionality to support account discovery and selection where further navigation or interaction is required to view all accounts. This may, for example, include search, sort, filter, scroll, grouping, and pagination, or other controls in line with existing consumer experiences. Any such functionality MUST NOT introduce unwarranted friction. Note: Unwarranted friction should have regard to CDR Rule 4.24 and is considered to include the addition of any requirements beyond normal data holder practices for an equivalent account selection process.

Authorisation Standards, Authorisation: Account selection functionality

3AU.01.27