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

Meeting Notes

  • Meeting 3 of MI23 focused on requirements for the final list of candidates.

Requirements Analysis

Energy

Banking

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

    • ACTION: DSB to review issues #283, #284, #567 and #569 to determine the best way to proceed.

  • 692 - ISO 8601 - Home Loan Repayments

    • Seeking feedback from DHs on concepts around 48 and 52 weeks
    • Mismatch on payment amount and payment frequency, difficulty providing consistency on the way the amounts are calculated.
    • A definition for these payment frequencies is required.
    • 52 week default appears sensible to participants on the call and is proposed as a solution.
    • Will leave the issue open for further comment and to determine whether it should be picked up as a candidate in the next MI.

  • 697 - Commercial Credit Card Structure under Get Account Details

    • This issue relates to a card holder's lack of authority to share information about a facility and the way in which this is handled in the messaging when a request fails. Options to solve include:
      • Message detail advising the nominated representative doesn't have facility access;
      • Add a note on sharing permissions to explain some information may not be shown if you don't have access to it. Some complexities here in managing that interplay between a nominated representative and the account holder when the initial consent is established.
    • Participants acknowledged complexities in nominated representative processes and how that overlays with permissions.
    • ADRs suggested complexity for data holders managing permissions exists in their space too.
    • Suggestion to redirect access issues to the Account Holder rather than trying to solve at the Card Holder level.
    • General consensus:
      • a solution introducing complexity or a partial solution wouldn't be supported, and
      • the permission issues are likely to be limited to commercial card products, not retail accounts.

MI23 Candidates

MI23

  • 690 - Maintenance Iteration 23 Holistic Feedback
    • Two new comments from CBA on this issue, both relate to documentation fixes arising from devs working with AI more and more where there is a dependency on strict properly typed definitions. Data Holders are seeing increasing value in really well written standards and availability of non normative examples.
      • ACTION: CBA to respond on DSBs proposed description to resolve the issue.

CX

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

    • Not discussed in detail. Further draft guidance will be published once available.
    • Input from CDR participants on the draft guidance published to date is welcome.

  • 691- CX Guidelines - Expanding Amending BCDC CX Guidelines

    • This issue was discussed in detail. Participants confirmed the current Amending detached BCDC CX Guidelines are valuable for some implementers who would like to see these maintained.
    • A proposed approach is outlined in this comment. Feedback from participants is welcome.

  • 693 - CX Guidelines - Historical date ranges for Authorisations

    • Participants explored the detail in this comment. The DSB is investigating the concerns raised and will come back to the community with further thoughts.
    • One data holder queried whether the statement used in Authorisation could be generic, or if it needed to be unique to each consumer. The DSB suggested this could potentially be generic and is seeking input from other CDR agencies and will come back to the community once confirmed.
    • Once the above points are clarified, the DSB will put forward draft CX Guidelines for community consideration.
    • A summary of the discussion will be posted on the issue in due course.

Register

  • 679 - Update SSA specification

    • Following analysis on the change, the DSB is proposing to rationalise location of SSA content, which appears in a couple of different places, by moving it to the register section. This will clean up minor inconsistencies and rely on schema definition rather than tables to convey requirements.
    • The revocation URI field, currently defined in the SSA, was deprecated about four years ago; making these changes will provide an opportunity to remove that field.
      • ACTION: Data Holder feedback is required to assist in determining whether any impacts will arise from the ability to modify the legal entity ID and legal entity name in DCR requests.
      • ACTION: DSB to post details of proposed changes on SSA requirements on the issue for further discussion.

  • 665 - Review Register error code documentation

    • Inconsistencies in error responses between the register and all other standards was introduced when the register standards were merged with the data standards. DSB is working with the ACCC to standardise those errors, this change is likely to be implemented along with changes required to accommodate the NBL sector.
    • DSB welcomes feedback on the impact of changes to register error codes.

  • 695 - Digicert Certificate Trust Chain Migration

    • UPDATE ON ACTIONS:
      • ACCC is preparing comms to send to all participants to make them aware of the issue
      • ACCC has confirmed with the Vendor the date is fixed, therefore the date cannot be moved.
    • This change is a requirement for CDR participants to trust an additional intermediate certificate that will form part of the new trust chain. The root certificate remains the same. The change allows participants with two different certificates to establish the MTLS connection.
    • For MTLS, Data Holders will support two different trust certificates being presented by an ADR until the old one is deprecated.
    • Given this change is related to operational management of the CDR that doesn't rely on standards, DSB is proposing to remove the vendor name and certificate details from the standards.
      • ACTION: ACCC to consider proposal to remove certificate details from the standards for further discussion in the next meeting.

NFR

  • 660 - Revise the Availability Requirements NFRs
    • DSB provided an overview of the outcome from the last meeting, available in this comment was provided.
      • Change A aimed achieve parity with UK which calculates availability based on planned and unplanned outages and Change B additional technical detail on outages and statuses.
      • The goal is to reduce CDR outages without unintended consequences ensuring ADR to know what's happening.
      • Introduce different availability tiers and change SHOULD to MUST
      • ADRs care about consumer experience, so knowing whether authorisations and data sharing is available is important.
    • Intention is to focus on commensurate clause.
      • Participants raised concerns with change in commensurate provision with regard to cost of moving CDR Stack up a tier and having more components to minimise downtime.
      • DSB cautioned that small percentages of a banks customers impacted by an outage can translate to 100% of an ADRs customers.
      • DSB is interested to hear Data Holder views on architecture design, does it factor in time to upgrade or appropriate data sharing solutions, and impact of changing SHOULD to MUST in Availability Requirements.

Energy

Banking

  • 687 - Bank account balance calculation time is indeterminate

    • This proposal is to provide an optional 'effective at' time field for the balance, therefore the field is not required if the balance is real time.
    • Additionally, this issue is closely related to #656 A status of POSTED should indicate the final update for a transaction where clarification on when it's appropriate to use PENDING and POSTED is required.
      • Issue #656 was included in MI22 where late comments opposing the change have delayed a decision of the Chair.
    • ADRs require issues #687 and #656 to be dealt with together or to have #656 resolved first.
    • Concern around low velocity data sets (such as mortgages and term deposits) however, if transactions and balances pulled at the same time reconcile, an effective at value is not required.
    • ADRs report confidence in balances but reconciliation problems occur when transactions are missing or have the wrong status.
    • Providing an effective at time for balances allows ADRs to compare the time on transactions to resolve reconciliation issues when they emerge.
    • The intention of this change is to ensure Data Holders already doing the right thing don't have to make changes to their systems.

  • 688 - BankingBalancePurse currency field is optional

    • UPDATE ON ACTION:
      • CBA confirmed currency identifiers are available
    • DSB is proposing a hygiene fix to correct the field to show as Mandatory as originally intended.

  • 694 - Add a Card identifier to the Transaction endpoint

    • ACTION IN PROGRESS: CBA and ANZ agreed to investigate their systems to advise what might be possible on 14 May.
    • DSB has made a proposal to resolve this issue by adding a field to identify the card in this comment . Feedback from Data Holders is welcome.

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

    • A proposed solution to update guidance on transactions was posted by DSB in this comment
    • Feedback welcome.
      • ACTION IN PROGRESS: SISS and Skript to email [email protected] with details of DHs that will likely be impacted by guidance changes.

Documentation

  • 668 - Review References detail
    • Not discussed in detail.
    • Feedback from Data Holders is welcome to ensure there's no impact in the way the updates could be interpreted.

Any other business

None