DSB Maintenance Iteration 20: Meeting Notes (24 July 2024) - ConsumerDataStandardsAustralia/standards GitHub Wiki

Meeting Notes

Release Plan

  • The changes arising from Maintenance Iteration 19 were published in v1.31.0 on 3 July 2024.
  • The outcome of Maintenance Iteration 20 will likely be published in v1.32.0.

Prioritisation

Due to the large number of candidates proposed for Maintenance Iteration 20 the DSB asked participants to prioritise 10 issues requiring further analysis. image

4 votes

3 votes

Voting outcome

  • Issues #553 and #610 were prioritised for Requirements Analysis in Maintenance Iteration 20.
  • The DSB agreed to include Issue #627 as a candidate because it relates to an unresolved change that was made in Maintenance Iteration 18.
  • Capacity permitting #628, #636 and #651 may be discussed.

Maintenance Iteration 20 Candidates

Holistic Changes

  • #647 - Maintenance Iteration 20 Holistic Feedback
    • A number of minor fixes have been posted on this issue, they are simple typos and duplicate text that will be corrected.
    • ACTION Participants are requested to review the comments posted on this issue for details and advise of any concerns.

CX

  • #646 Clarify selection of Trusted Adviser in the CX Guidelines
    • Comments from an attendee who spoke to this issue in Meeting 1 on 10 July have not been posted on the issue yet.
    • The DSB is exploring how this issue can be resolved from a CX perspective.
    • ACTION DSB is requesting input from the community on this change.

InfoSec

  • #648 - Adopt BCP 195 for TLS ciphers

    • FAPI 2.0 is now aligned with BCP, while CDR is FAPI 1.0, we'll adopt the language to state only cipher suites, used for negotiation, recommended in BCP 195 shall be permitted and remove the list of standard ciphers currently included.
    • This comment, posted on #643 applies.
    • V1.13.0 of the standards includes a deprecation statement for the ciphers and when FAPI 1.0 includes an ERRATA the standards will refer to it.
    • ACTION participants are requested to consider whether the change from a specific suite of ciphers to those listed in BCP 195 would result in a breaking change and advise on a suitable Future Dated Obligation.

  • #650 - Weaken JARM Encryption Requirements for ADRs

    • A participant is compiling information on data holders who require encryption on JARM responses for discussion in a later meeting.

Banking

Energy

Requirements Analysis

Common

  • #610 - Addition of an (18 or over) Age Verification Flag
    • RECAP: Date of birth is not a permitted field in the CDR. Age ranges had been suggested to meet the requirement. DSB has also looked at it from the eligibility perspective, where the consumer needs to be 18 or over for data to be shared. Anyone younger than 18 is ineligible for CDR. Once a consumer turns 18 they become eligible and can share their transaction history.
    • Participants raised concerns around the legal implications of introducing an age related value, suggesting it's divergent from international practices and age or date of birth values may not be readily available in CDR datastores to enable a calculation.
    • The sentiment among participants is Verifiable Credential checks, such as age, may be better suited to a Digital Identity system.
    • Date of Birth is typically verified as part of Know Your Customer (KYC) practices which are separate to CDR concerns and are unlikely to be consistent across sectors.
    • Before looking at solution options, the DSB is inviting participants to compile use cases using age to understand the problem presented in this issue. This will assist in determining whether this is something the DSB would consider taking forward in the CDR or whether it fits elsewhere. Solutions can be considered in a future meeting if needed.
      • ACTION: Participants to provide examples of use cases.

Banking

  • #553 - Running balance available under transaction detail
    • In the call on 10 July, exploring a 'statement-like' solution, providing some type of snapshot of the balance at certain points in time, was proposed. A number of similar options, all related to improving the confidence in the accuracy of balances were explored in today's call.
    • Further discussion on the issue suggests the way in which 'available' and 'current' balances are calculated from 'reversed', 'posted', 'authorised' and 'pending' transactions likely vary between products, core banking systems and data holders.
    • The problem we're attempting to solve for is the inconsistency ADRs experience when applying a running balance calculation to transactions (from Data Holders) coupled with the discrepancies between an ADR calculated value and DH calculated values which can also differ between DH platforms for the same account.
    • This suggests the information returned in CDR is not aligning with the digital channels offered by Data Holders. This relates to rule Part 1, Division 1.1, 1.13(1)(a)(ii)) in Compilation 8.
    • Having a point in time to calculate from is an important factor in being able to determine an accurate 'current' or 'available' balance, however it is also important to understand how DHs calculate balances. Making these calculations available might assist in resolving the issue whereby an ADR could apply the calculation appropriate to the Data Holder.
    • Clarification on the difference between 'current' and 'available' balances would also help.
    • There is concern this issue stems from Data Quality and is therefore a compliance consideration rather than a standards change.
    • With regard to the use cases described in the original post on the issue, 1. would need to be calculated 2. would need to be calculated as well and 3. requires clarification
    • Acknowledged running balance will need to be calculated but choosing when to calculate from is the question.
      • ACTION ADR to clarify requirements in options proposed in original post.
      • ACTION ADRs to investigate whether information exists on differences between data holders that illustrate the problems with calculated balances.
      • ACTION DHs to provide clarification on the difference between 'current' and 'available' balances.
      • ACTION DHs to provide details on how balances are calculated.

With the remaining time in the call, issues prioritised with 3 votes were discussed with a view to including them if #610 and #553 don't progress.

Energy

  • #651 Supporting HTTP Status 429 passthrough from Secondary Data Holder
    • Already an optional header, requiring ADRs to obey messaging, preference is to change from SHOULD to MUST
    • Issue has been under discussion offline with participants having immediate need and ACCC
    • References to Secondary Data Holder in the standards are not clear in Energy
    • Concerns that trialling a change in behaviour could potentially disadvantage some DHs
    • AEMO has confirmed it can facilitate a trial
    • Request for DSB to communicate with impacted ADRs to advise the behavior is set to change for their awareness
    • Operationally long timeouts tie up more resources than frequent quick calls, so trialling may be worthwhile and requires coordination of ecosystem participants.
    • Reporting on 429 is in question here, would currently be interpreted as rate limiting but further consideration beyond the trial is required.
      • ACTION DSB to review scope of trial, including timing of change with AEMO and other impacted participants and coordinate communications with ACCC.

Extensibility

  • Biza is about to publish a number of optional standards, one in particular is bulk transactions for asynchronous bulk banking detail. Ideally Biza would like to be aligned with the consumer data standards however will proceed with publication without validation given the issue wasn't prioritised for this Maintenance Iteration.

Banking

  • #636 - Remove BankingTransactionDetail and incorporate extendedData into BankingTransaction
    • Outstanding actions are in progress.
    • An update on the outcome of earlier discussions has been posted in this comment and the DSB is looking for feedback from the community on it.
    • One participant suggested a bulk asynchronous endpoint would be a better solution paired with reducing attributes in the transaction API.
    • Calls for fields to be defined separately in the standards and optional due to the vast possibility for variation across systems and products.
      • OUTSTANDING ACTION: DSB to follow up with Dima on NPP opinion.
      • OUTSTANDING ACTION: DSB to schedule offline discussion with SISS (Josh) on data quality analysis.
      • ACTION Participants to provide feedback on summary of earlier discussions in comment.

Not discussed but prioritised

Security

Other business

None

Next Steps

DSB will progress analysis on solutions for Candidates for further discussion in the next meeting. The community is invited to comment on issues affecting them.