DSB Maintenance Iteration 23: Meeting Notes (11 June 2025) - ConsumerDataStandardsAustralia/standards GitHub Wiki

Meeting Notes

  • Meeting 4 of MI23 focused on proposed solutions for the candidates that can be resolved by 25 June.

Requirements Analysis

Energy

  • 662 - Extend Get Generic Plan Detail to include a new field: tariffCode
    • No update; still waiting on Policy advice which is anticipated to take some time.
    • Alternate solutions welcomed.
    • This issue will be considered in Requirements Analysis for the remainder of this MI and if no policy advice or alternate solutions are available it will be moved to the backlog when the MI concludes.

Banking

MI23 Candidates

MI23

CX

  • 684 - CX Guidelines - ADI or NBL to hold CDR data as a DH

    • No update since the last call.
    • Draft guidance has been posted and there is more to come.
      • ACTION: Community views on draft guidance is welcome.

  • 691- CX Guidelines - Expanding Amending BCDC CX Guidelines

    • A summary of last meetings discussion and a proposed approach has been posted in this comment.
    • Draft guidance, retaining existing amending detached BCDC and adding a variant for amending a bundled BCDC, has been posted in this comment.
      • ACTION: Community views on draft guidance is welcome.

  • 693 - CX Guidelines - Historical date ranges for Authorisations

    • The DSB is currently seeking input from other CDR agencies on whether the statement made by Data Holders in the authorisation and amending authorisation flows about the historic date range needs to be specific to the consumer, or whether a generic statement can be used. We will come back to the community once confirmed.
    • Participants revisited the detail in this comment for further clarification.
    • The DSB is finalising draft CX Guidelines and will put this forward for community consideration as soon as possible.

Register

  • 679 - Update SSA specification

    • An overview of the proposed approach described in this comment was provided.
    • It was suggested that Data Holders could make details of supported SSA versions available via OIDD; this would require additional change. Proposal is for the new version to be available based on an FDO where the rectification schedule could be used if the FDO couldn't be met, although automated discovery may be preferred.
    • Use of the Metadata Update endpoint was discussed in relation to ADR metadata; either decommissioning it or implementing it to remove the need for Data Holders to poll every 5 minutes. ACCC believes 5 minute polling is scalable for the time being although acknowledges further thought is needed.
    • It was suggested that consideration of a discovery endpoint for a data holder instead of using the OIDD could be useful. In addition to the SSA version it could solve other problems such as PRD endpoints, policy uris etc which would leave the register to be a trust broker rather than a business register. The DSB has consulted on this previously however it was primarily in support of Action Initiation and wasn't progressed.
    • One concern with making broader change could mean the benefits of the original change may be delayed, meaning the operational issues could be experienced for longer.
      • When this occurs Data Holders with the constraint have suggested deleting client IDs so DCR can be repeated with updated information, however this is not ideal for established ADRs due to the impact on consents.
    • ACTION: DSB to note the alternative suggestion of a discovery endpoint to signal DH readiness. Done, see this comment.

  • 665 - Review Register error code documentation

    • This change relates to better specificity of errors, e.g. instead of getting a 404 a 400 error will be sent. This means it will be a breaking change, however it wont affect successful responses.
    • New participants joining the CDR are more likely be affected
    • Understanding the differences on what errors will be expected once the change occurs would be helpful.
      • 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.

  • 695 - Digicert Certificate Trust Chain Migration

    • Communications from ACCC to be sent shortly which will make clear how transition will work; for more information contact [email protected]
    • Some participants noted they rely on certificate information in the Standards.
    • DSB suggested an informative reference link could direct participants to certificate information hosted by the ACCC, or alternatively update standards in the Certificate Management section. This is to ensure ongoing ease of discovery.
    • ACCC advised there will not be a CTS test plan available for participants to test that both trust chains work at the same time.
      • ACTION: ACCC to post an update on the issue to confirm the date is fixed as notified in the last meeting.
      • ACTION: ACCC to provide views on updating content in the Certificate Management section of the standards.

NFR

Energy

Banking

  • 687 - Bank account balance calculation time is indeterminate

    • This issue proposes adding a new field to convey the time the balance was calculated and is related to issue 656.
    • Two participants suggested making the new field optional would be suitable given a majority of Data Holders calculate balances in real time. However other participants are concerned if the field is optional Data Holders can ignore the field effectively negating the change by inferring the balance has been calculated in real time.
    • In circumstances where the field is ignored, much the same way the current problem is ignored, ADRs will need to continue raising issues in ACCCs Service Management Portal in the hope DHs will comply with the standards.
    • DSB suggested that automated data validation should be preferable to requiring manual analysis to identify inconsistent data disclosures.
    • One participant suggested there is value in this issue, however, given the related issue 656 is in the Consultation Draft for MI22 it would be better to wait for an outcome on the Chairs decision before making further changes. The deadline for feedback on MI 22 Consultation Draft is 3 July.
      • ACTION: DSB to move issue to Requirements Analysis to continue discussion in MI24.

  • 688 - BankingBalancePurse currency field is optional

    • A proposal has been made to resolve this issue, described in this comment.
    • DSB is anticipating this is a non-breaking change because the information is already expected to be provided.
      • ACTION: Participants to provide feedback to confirm the change is non-breaking.

  • 694 - Add a Card identifier to the Transaction endpoint

    • A proposal has been made to resolve this issue, described in this comment.
    • Further discussion on the description of the new field is required.
    • Priority for this change is corporate credit cards as opposed to retail accounts.
      • ACTION: Participants to comment on field description.

  • 173 - Behaviour where posted transactions only have an associated date

    • Data Holder details have been provided by Skript, assumed to be the same for SISS.
      • ACTION: DSB to discuss behaviour with identified participants.
    • DSB is also looking for feedback on this proposal:
      • expectation of three fields and sequence of them; and
      • consideration of transaction time.
    • One participant confirmed the guidance meets their expectation in terms of being able to show time of transaction in relation to the time zone of the client.
    • Clarification sought on statement date, for CBA it is the execution date not the posted date. This experience differs across Data Holders.

Documentation

  • 668 - Review References detail
    • While the proposal appears innocuous concerns were raised with unintended consequences of changes to how upstream standards are referenced.
    • Clarification provided on nature of the changes, e.g. http to https anticipated to correct reference, DSB is not signalling a change to upstream standards as a result of these changes.
      • ACTION: Participants to check proposed updates and raise any concerns.

Any other business

DSB queried whether there are too many reminders coming from the Maintenance Iteration calendar event. While there are differences in the reminders that participants are seeing there is no need to make any changes to the event settings.