CX Guidelines

Latest version

Version Date released Change log
1.4.0 12.08.2020 View

 

Archived versions

Version Date released Change log
1.3.0 17.04.2020 View
1.2.0 31.01.2020 View
1.0.1 12.11.2019 View
1.0.0 30.09.2019  
0.9.5 17.07.2019  

The Data Standards Body (DSB) recognises that the consumer experience (CX) 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.

Versions 1.0.0 and later of the  CX Guidelines include a corresponding version of the CX Standards.

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.

Feedback

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 cx@consumerdatastandards.gov.au. 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 cx@consumerdatastandards.gov.au.


Keep in touch

4 comments

  1. 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 (https://consumerdatastandardsaustralia.github.io/standards/#authentication-flows), 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?

    1. Hi David,

      Are you able to elaborate on what is meant by ‘the consumer CDR registration process’?

      If your comment is about authentication flow wireframes, the CX Guidelines contain these (see pp.69 – 74). The CX Guidelines can be found in the above table and at https://consumerdatastandards.org.au/wp-content/uploads/2019/11/CX-Guidelines-v1.0.1.pdf.

      An example for OTP delivery using SMS is provided in the CX Guidelines to reflect how verification codes are commonly delivered, and the channel determined based on how the data holder already interacts with that consumer.

      However, the actual delivery channel ‘is at the discretion of the data holder.’ The standards don’t prescribe the channel, only that it ‘must align to existing and preferred channels for the customer and must not introduce unwarranted friction’ in the flow.

      ‘Unwarranted friction’ is defined in line with CDR Rule 4.24 and is considered to include:

      – the addition of any requirements beyond normal data holder practices for verification code delivery
      – providing or requesting additional information beyond normal data holder practices for verification code delivery
      – offering additional or alternative services
      – reference or inclusion of other documents

      As an example, if allowing ‘the customer to choose how they want the OTP sent’ is part of the existing and preferred experience then it would appear to be aligned.

      For how this works in the back-end, please see the security profile authentication flow section references to OIDC and FAPI, if you haven’t already. Specifically here:

      https://consumerdatastandardsaustralia.github.io/standards/#authentication-flows
      https://openid.net/specs/openid-connect-core-1_0.html](https://openid.net/specs/openid-connect-core-1_0.html
      https://openid.net/wg/fapi/](https://openid.net/wg/fapi/
      – and especially the Hybrid Flow outlined in section 3.3 here: https://openid.net/specs/openid-connect-core-1_0.html#HybridFlowAuth)

      Hope this helps.

      Best,

      CX Workstream

  2. 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?

    Thanks,

    Mat

    1. 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 [https://treasury.gov.au/sites/default/files/2019-03/Review-into-Open-Banking-_For-web-1.pdf] 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.

      Best

      CX Workstream

Leave a Reply to David Pickering Cancel reply

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