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

Meeting Notes

  • This is the second meeting for MI 23, the purpose is to finalise candidates for consultation.

Release Plan

  • The DSB has changed the format of consultation papers and managing the outcomes of maintenance iterations. The changes arising from MI 22 will be consulted on for a further 28 days, which have been staged and will be described in a Consultation Draft. Changes to the standards appearing in the Consultation Draft will be detailed in an Explanatory Statement.
  • Changes resulting from this MI will follow the same pattern, once the Iteration has concluded on 25 June, the changes will be staged and the DSB will consult on those changes for a further 28 days using the Consultation Draft and Explanatory Statement mentioned above.

Consultations

Requirements Analysis

Energy

Banking

  • Issue # TBA - Potential new issue relating to banking issues included, but deferred in Decision 338

    • ACTION: Frollo to summarise of key aspects from issues #283, #284, #567 and #569 in a new CR to be considered as a candidate in a future MI.

  • 692 - ISO 8601 - Home Loan Repayments

    • DSB is seeking feedback from Data Holders on the methods used to calculate repayments.

  • 697 - Commercial Credit Card Structure under Get Account Details

    • Skript proposing to discuss this in MI23
    • This issue is related to an open Jira ticket that's compliance related
    • Attempting to request account detail generates a 404 error code suggesting a temporary issue for account not being found but this is behaving as a block because the temporary issue is never resolved
    • Architecture of the CDR solution doesn't permit access to these fields but the same information is available from other DHs
    • Impact of proposed change would be significant across the ecosystem so not in favour of it proceeding.
    • Has implications with account authorisation - does the user with the card give consent or is it the account owner of the parent facility, therefore where does data and consent sit? Potentially permissions or entitlements for the users that are granted access to share certain data and how they align to the scopes.
    • This problem is exacerbated for ADRs where their frustrated clients have accounts with multiple banks and the CDR experience differs between them. These problems present as in issue for the ADR when it should be the DH.
    • DSB is working through the account and access issues with the CX team. Relates to card holder, account owner, nominated reps etc.
    • A relationship to issue #694 - Add a Card identifier to the Transaction endpoint was noted.

Documentation

  • 668 - Review References detail
    • DSB is proposing to include this as a candidate in MI23 and is seeking feedback from participants to confirm it is a non breaking change.

Proposed Candidates

MI23

CX

Register

  • 679 - Update SSA specification

    • ACCC and DSB are seeking participant feedback on preferences:
      • minimal change or
      • more comprehensive change suggested in the discussion thread and
      • whether it's beneficial to include product Ids
    • If no feedback is provided the proposed solution could be Option 2, to make everything modifiable.

  • 665 - Review Register error code documentation

    • Intention is to align register errors to be consistent with the standards.
    • Likely to be a staged change as the register team is unlikely to complete the work in this iteration and completion is more likely to align with the timing to introduction of Non Bank Lending.
    • ACCC welcomes comments from participants on their preferences and the impact of this change.

  • 695 - Digicert Certificate Trust Chain Migration

    • New issue proposed as a candidate.
    • 1 October 2025 migration to DigiCertONE.
    • All participant will need to trust an additional Intermediate certificate in their systems. Old certificates will continue to function normally.
    • CDR participants would be required to support both old and new certificates.
    • One participant raised a concern regarding the lead time for the change and asked if the date could be moved.
    • From one participant's perspective the complexity lies in supporting both certificates
      • ACTION: ACCC
        • Will prepare comms to send to all participants to make them aware of the issue
        • Is considering the request to move the date.

NFR

  • 660 - Revise the Availability Requirements NFRs
    • DSB proposed two solutions in this comment to cover two different aspects of the problem space for discussion
      • Change A proposes including planned and unplanned outages in NFR availability
      • Change B proposes additional ENUM values in technical outage messages.
    • A summary of the discussion on this issue has been posted in this comment.

Energy

Banking

  • 687 - Bank account balance calculation time is indeterminate

    • Skript acknowledges most DHs are providing data that's commensurate to internet banking channels, however the crux of the issue is there's no way in the current standards to successfully line up transaction and balance data. Suggestion is to change 'SHOULD' to 'MUST'. If there's another way to achieve that it would be useful to get that feedback.
      • ACTION: DSB to provide a view on key use cases such as accounting, data quality considerations and propose a solution for further discussion.

  • 688 - BankingBalancePurse currency field is optional

    • SISS support to make currency field mandatory.
      • ACTION IN PROGRESS: CBA agreed to check their multicurrency accounts to provide a view on impact to their implementation.

  • 694 - Add a Card identifier to the Transaction endpoint

    • SISS suggested limiting this change to credit cards because they're the accounts that are most likely to have multiple card holders, although there is value in having this detail for other accounts where applicable.
      • ACTION IN PROGRESS: CBA and ANZ agreed to investigate their systems to advise what might be possible.

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

    • Skript analysis indicates a majority of Data Holders and doing the right thing in regards to data quality, however some DHs don't store a time value against their transactions.
    • Suggested guidance article could be improved
    • Time zone value is used to manipulate data obtained from DHs across different time zones to align transactions to the time zone of the client.
    • If time is not stored it is hard coded which causes some transactions to appear as if they occurred in the future
    • Proposed solution is to remove time from transaction data and rely on date alone or to update guidance to assist in the resolution of a ticket that's been open with one DH for more than a year. ADRs are compensating for the absence of standardisation of time across all DHs.
    • DSB observation on this discussion is that ADRs require workarounds, however with a relatively minor change would mean new ADRs coming into the ecosystem wouldn't have to apply the same workarounds to deal with the same challenges and raise the same requests and issues. They can adopt the Standards and they should work. Therefore, minor documentation fixes or guidance updates should really help the ecosystem going forward, particularly with Non-Bank Lending on the horizon.
      • ACTION: SISS and Skript to email [email protected] with details of DHs that will likely be impacted by guidance changes.

Issue to be closed

Energy

  • 680 - Jurisdiction Code of ISO
    • CDR agencies have discussed this issue and take the view that while keen to enable voluntary data sharing the prerequisite is the consumer must be eligible to participate in CDR. Consumers in this scenario are not eligible as they're not part of the National Electricity Rules of Market. As a result this change will not be adopted and the issue will be closed.

Any other business

None