Latest version

DocumentVersionDate releasedChange log
CX Standards1.
CX Guidelines1.


Archived versions

DocumentVersionDate releasedChange log
CX Standards1.
CX Guidelines1.
CX Standards1.
CX Guidelines1.
Consumer Experience Standards1.
Consumer Experience Guidelines1.
Consumer Experience Guidelines0.9.517.07.2019


The Data Standards Body (DSB) recognises that the consumer experience is critical to success for the CDR regime. To help provider CDR consumers with simple, informed, and trustworthy data sharing experiences, the DSB has developed Consumer Experience (CX) Standards and Guidelines that identify a number of key elements to be aligned to across the regime.

The latest version of the CX Standards and CX Guidelines can be found on this page and have also been incorporated into the general technical standards on GitHub.

The CDR Rules (8.11) require data standards to be made for:

  • obtaining authorisations and consents, and withdrawal of authorisations and consents;
  • the collection and use of CDR data, including requirements to be met by CDR participants in relation to seeking consent from CDR consumers;
  • authentication of CDR consumers
  • the types of CDR data and descriptions of those types to be used by CDR participants in making and responding to requests

The CX Guidelines contain guidance and examples for putting key standards and CDR Rules into effect. As stated in the CDR Rules Explanatory Statement, ‘at a minimum, accredited persons will be guided by the language and processes of guidelines produced by the DSB.’ The CX Workstream emphasises that aligning to the non-mandatory items in the CX Guidelines will help achieve consistency, familiarity and, in turn, facilitate consumer trust and adoption.

The obligations on CDR participants to apply the published standards commence on the commencement of the Consumer Data Right rules:

  • where the rules require compliance with the standards, non-compliance with the standards may constitute a breach of the rules.
  • where the standards are specified as binding standards as required by the Consumer Data Right rules for the purposes of s56FA of the legislation, they apply as under contract between a data holder and an accredited data recipient. The legal effect of binding standards as between data holders and accredited data recipients is fully set out in s56FD and s56FE of the legislation.


The community is invited to provide feedback on the CX Standards, CX Guidelines, and CX-related decision proposals on the relevant CX consultation pages and on GitHub.

Feedback will also be accepted via email to [email protected]. In accordance with the regular practice of the Data Standards Body, email submissions will be posted on GitHub and the CX consultation page to ensure transparency of the consultation process.

Where participants believe they have sensitive information to convey we will consider those discussions and give guidance on our preferred disclosure approach prior to meeting to discuss such issues. To discuss, please email us at [email protected].

Keep in touch

8 thoughts on “Consumer Experience: Standards and Guidelines

  1. David Pickering Reply

    Was hoping to find some UX wireframes that help explain the consumer CDR registration process. Are there any wireframes published anywhere, as I can’t seem to find them…

    From reading the specs (, it says that a consumer should be asked to enter a “user identifier that can uniquely identify the customer”. However, there’s really not much clarity around how OTPs are sent, then entered by the consumer… After entering the User Identifier, should the UI make a call to a back-end service to retrieve the SMS and/or Email (likely need to only show last 3 characters to prevent phishing attacks) for that customer id (from the Digital Banking app), then allow the customer to choose how they want the OTP sent (SMS, Email, Push)? I’m assuming this is how it should work, but can you confirm if this flow has been thought out and whether this guidance will be provided in an upcoming version of these standards?

  2. Mathew Lyons Reply

    Hi there,

    Does the CDR / Open Banking framework make it possible for 3rd party apps to transfer money between the customer’s accounts and/or BPAYments or payments to others? If so when? And where can I find more information?



    • Consumer Data Standards Australia Post authorReply

      Hi Mathew,

      The CDR currently permits read access only, and as such does not provide for payment initiation.

      The Open Banking Review only relates to access to data (read access), though raises the option of an extension of the right in the future.

      See [] for more details on the potential for write access, including a suggestion that ‘Open Banking should be formally evaluated 12 months after the Commencement Date’ and that post-implementation considerations should include ‘the potential for future write access’. The current go-live date for CDR in the financial sector is mid-2020.


      CX Workstream

  3. Tonia Berglund Reply

    Is there specific terminology or data language standards that need to be used for when a customer chooses to access account information through a non-Open API (one that is screen scraped)? Eg. the question could be “link to non open banking accounts” which means the data will be acquired through screen scraping.

    • Consumer Data Standards Australia Post authorReply

      Hi Tonia,

      The data standards and guidelines do not provide for alternative methods of data sharing, such as screen scraping, but the CDR Rules do not prohibit them either. The ACCC’s position on screen scraping is as follows:

      – Anyone using alternative methods of data sharing will have to carefully design their consent flows and consider the impression created in their interactions with consumers, to ensure they comply with the CDR framework and are not likely to mislead consumers.

      – Any request to a consumer or agreement by a consumer to share data that is outside the CDR must not purport to be or be presented as part of the CDR consent flow, otherwise it may breach the rules relating to bundling, referring to other documents, and the requirement to make consent as easy to understand as practicable.

      – Any persons adopting such an approach to inform the consumer that to provide the service they intend to access non-CDR data also, and explain the consequences of doing so, including any risks which may arise from the alternative method of sharing.

      – Such approaches should not create the impression that data collected via mechanisms other than the CDR is subject to the same protections as CDR data when it is not, or otherwise lead a consumer to be misled about CDR.

      – CDR data must be treated in certain ways. Co-mingling CDR data with non-CDR data will not excuse anyone from adherence to these high standards, and anyone doing this may need to be prepared to treat all data co-mingled in one pool to those high standards.


      CX Workstream

    • Consumer Data Standards Australia Post authorReply

      Hi H P Alexis,

      If I understand the question correctly, working out who the authenticated customer is occurs through the use of oAuth access token provided in the authorisation header. It needs to be matched to the consent contract which can be retrieved by the authorisation server. You should be validating that the accountId requested is actually owned and consented to.

      For technical details related to API and information security I recommend raising queries on the maintenance site to get a response from the technical stream. You can find the page here:


      CX Workstream

Leave a Reply

Your email address will not be published. Required fields are marked *