DSB Maintenance Iteration 24: Meeting Notes (9 July 2025) - ConsumerDataStandardsAustralia/standards GitHub Wiki
- This was the first meeting for MI 24. The purpose was to identify candidates for consultation in this iteration.
- The current version is 1.34.1, published on 11 April 2025.
- A number of decisions are either anticipated or have been made by the Data Standards Chair in recent weeks, the proposed sequence of these releases is:
- V1.35.0
- Targeted V1.36.0
-
Consultation Draft 367 - March 2025 Rules - Draft Standards
- This decision includes Non-Bank Lending
-
Consultation Draft 367 - March 2025 Rules - Draft Standards
- Targeted V1.37.0
- Changes arising from this MI will be published in version 1.38.0 or later.
Register issue #695 Digicert Certificate Trust Chain Migration was consulted on in MI23 however a solution wasn't available in the final meeting. The ACCC has communicated DigiCert changes to all active participants and demonstrated amendments to the Certificate Management section of the Standards in the call.
-
ACTION: ACCC to post proposed content on the issue ASAP for inclusion in the Consultation Draft for MI23.
- Done, see this comment.
Issues that will continue to be analysed in MI24 Banking
- TBA - Outstanding Banking Issues
-
687 - Bank account balance calculation time is indeterminate
- Dependent on outcome of issue #656 in MI22 Decision
CX
-
684 CX Guidelines - ADI or NBL to hold CDR data as a DH
- Several guidelines relating to r7.2 in Schedule 3 have been published for community input. Additional guidelines are in development with CDR agencies, when they're ready they'll be posted for review.
-
693 CX Guidelines - Historical date ranges for Authorisations
- Relates to rule changes made earlier in the year that affect how data holders should refer to historical data in the authorisation flow and the last consumer change date in energy. The CX team is working with CDR agencies on guidelines which will be posted for review when they're ready.
Register
-
665 - Review Register error code documentation
- ACTION: ACCC to provide detail on which codes will change to confirm impact. This may support a non-breaking change.
- ACTION: ACCC to advise anticipated release of endpoints with updated error codes, and the subsequent deprecation of the current versions.
- A verbal update on these actions was provided at the last MI23 meeting, content is undergoing a final review and will be posted for community review as soon as possible.
Banking
-
173 -Behaviour where posted transactions only have an associated date
- Guidance changes proposed in MI23 will be included in the Consultation Draft for Issue 371.
- Further changes to the standards will be considered and consulted on in this iteration. Skript and SISS have provided details of DHs who will be affected by this change and will be contacted by DSB as needed.
Holistic
-
705 - Maintenance Iteration 24 Holistic Feedback
- No requests had been posted on this issue.
CX
-
700 - CX Guidelines - Redirect to App (R2A) CX Guidelines Changes
- This change proposes making updates to CX Guidelines that are impacted by Consultation Draft 369 - Redirect to App.
- If this issue is confirmed as a candidate for MI24 updated CX artefacts will be posted on the issue.
-
701 - CX Guidelines - Data Language Standards changes stemming from CD367
- This change proposes making updates to CX Guidelines that are impacted by Consultation Draft 367 - March 2025 Rules.
- If this issue is confirmed as a candidate for MI24 updated CX artefacts will be posted on the issue.
-
702 - CX Guidelines - Required and voluntary data - Authorisation
- This change proposes making updates to CX Guidelines that are impacted by the March 2025 Rules where changes to required and voluntary data, product and data sets and expanding to NBL have been made.
- This CR focuses on expanding the existing CX Guidelines for Unavailable Accounts Authorisations to better represent the amended rules.
- Items raised in this comment are being considered and a response on whether they're in or out of scope will be provided.
- If this issue is confirmed as a candidate for MI24 updated CX artefacts, currently in development with CDR agencies, will be posted on the issue for community feedback for 28 days.
-
703 - CX Guidelines - Pre-Consent
- The objective of this change is to leverage previous CX research findings to assist data recipients in facilitating trust in the CDR, increasing their propensity to consent, and increasing familiarity with the consent flow, with the aim of reducing drop off.
- Any guidelines proposed as a result of this work will be recommendations only and aren't related to rules or standards.
- Input from the community on any questions or concerns you'd like addressed in this work are welcome.
- DSB clarified the CDR Participant Journey Map workshops for ADRs and DHs are not related to this issue which discusses a Consumer's CDR journey.
- This triggered a discussion on Nominated Representatives, the biggest pain point experienced by ADRs in terms of Consumers being able to consent, particularly for business consumers. Data recipients indicated that if the issues with nominated representatives were fixed, there would be less of a need for a pre-consent experience.
- Data recipients also raised concerns when comparing CDR to Screen Scraping, where the process of logging in is familiar to users, and therefore no onboarding or pre-consent is are required. This makes the overall process much simpler and quicker without the drop-offs experienced in CDR, anecdotally 40-80%. Any friction at the start of the CDR process is a barrier to adoption despite the benefits of consumers using CDR in preference to Screen Scraping.
- ACTION: Skript and SISS to post details of current Nominated Representative experiences on this issue.
- ACTION: DSB to refer Nominated Representative comments from Skript and SISS to Treasury.
-
TBA - CX Guidelines - ACCC Onboarding - White Labelling Scenarios
- The purpose is to articulate the problem space and scenarios for white labelling, in particular the non bank lending sector and to invite community feedback on the proposed solution and any standards considerations.
- More information to follow.
- This issue will be considered under Requirements Analysis in MI24.
Banking
-
696 - BankingAccountV2: productName
- A proposed fix described in this comment was discussed.
- Product Id is being used as the Product Name in some circumstances, however a human readable value is expected.
- If changes are adopted an FDO aligned with NBL changes would be proposed.
- ANZ confirmed in the call they provide a human readable value for productName.
- Participants are operating on the assumption that the information provided is current.
- productIDs are not expected to be tied back to productIds provided in PRD.
- Consensus from attendees was to exclude productIdentifier and clean up values provided in productName.
- Participants agreed this issue should be considered as a candidate for MI24.
- ACTION Skript to post comments on the issue. DONE, see this comment.
- 697 - Commercial Credit Card Structure under Get Account Details
NOTE: As the Iteration progresses, to allow standards maintenance consultation to focus on the detail of unresolved issues, it is assumed that proposed solutions can be taken forward in a Consultation Draft for the Chairs approval unless there are opposing views raised before the final call of the iteration. The DSB encourages participants to post their views on issues as early as possible.
Register
-
Client authentication for Get Data Holder Brands
- Making this API public has been proposed. At the time the API was developed there had been suggestions the information was sensitive, however that was challenged. The API includes the public base uri, which is already public, for product, status and outages. The infosec base uri is essentially the well known configuration endpoint for the open ID provider, which is well known or intended to be well known for a reason.
- ACTION: Participant's views on whether the API could be made public, or if there are particular concerns or sensitivities around the information, are welcomed.
-
ACTION: DSB to raise an issue for Requirements Analysis before it's considered as a candidate for MI24.
- Done, refer to 706 - Client authentication for Get Data Holder Brands
- Making this API public has been proposed. At the time the API was developed there had been suggestions the information was sensitive, however that was challenged. The API includes the public base uri, which is already public, for product, status and outages. The infosec base uri is essentially the well known configuration endpoint for the open ID provider, which is well known or intended to be well known for a reason.