Meeting Minutes

Release Plan

Standards version for this iteration is TBC, considering the Data Standards Chair approved Decision Proposal 322 - Update Get Metrics Endpoint Schedule to be considered as an urgent change. The urgent change release may include documentation and other minor changes not requiring a decision of the Chair.

Outstanding Actions

None. New actions from this call marked with ⚡

Maintenance Iteration 16 Candidates

The issues listed below have been proposed for consultation in this iteration or for further review by DSB. The DSB encourages participants to review these and post comments for consideration in developing solution proposals.

CX:

• None proposed

Security:

• None proposed

Register:

• It was noted that issue #480 1.13.0 appears to have broken pseudonymity of Pairwise Identifiers had been suggested for consideration as a Decision Proposal.
  • DSB will review the issue, no comments as yet.

Banking:

• #229 – Service field in the Get Transaction Details API
  • The DSB is seeking feedback on whether this item should be prioritised for this iteration.
• #593 – Interest paid at maturity guidance for applicationFrequency in BankingProductDepositRate
  • Noted a warning that there is a semantic difference, this issue was raised because there was some inconsistency between data holders and the way term deposits are presented.
  • Some restructuring of payloads may be required to adhere to this proposed change of standards.
  • Participants are encouraged to add comments to the issue if there are any concerns. ⚡
• #595 – Use of additionalValue field in Product Eligibility Types
  • Proposing the use of the additionalValue field for certain product eligibility types.
  • Participant comments welcome to inform and confirm the nature of this change. ⚡

Energy:

• None proposed

Common:

• #376 - Include FAX as CommonPhoneNumber purpose
  • DSB is seeking further feedback on this issue in order to prioritise it for this iteration.
  • Please review and provide comments to assist. ⚡
  • If no comments are received it may be removed from the list of candidates.

Schema:

• #469 – Add isQueryParamUnsupported to MetaPaginated for schema validation
  • Potential candidate carried over from MI15. This change could resolve a gap in the current specification of the Get Transactions For Account endpoint.

Errors:

• #412 – Proposal to change specific error codes from MUSTs to SHOULDs
  • Minor corrections to errors have been included in the holistic issue.
  • DSB is seeking comments on prioritisation and whether this should be considered in this iteration. ⚡

NFRs:

• None proposed
• (NFR-related items noted under 'Other business')

Operational:

• None proposed

Documentation:

• None proposed
• See #599 – Maintenance Iteration 16 Holistic Feedback for minor documentation updates and other amendments.

Other business

• Discussion on issue 596 and use of DOMESTIC type for Payees that have details in an international format.
  • Participant was requested to review the INTERNATIONAL schema as an alternative. ⚡
• Discussion on 'Customer Present' and Performance Requirements of secondary data holders
  • For customer present calls the x-fapi-customer-ip-address is not passed to the secondary data holder however the response time for those calls includes the secondary data holder which is consistently above 1.5 seconds.
  • It was not DSBs intention to include the secondary data holder response times in Get Metrics for primary data holders.
  • Change Requests #602 and #605 have been raised and will be considered during this MI, raised with AEMO, and added to the agenda for NFR Workshops scheduled in August. ⚡
• Discussion on expected behaviour for calls with large numbers of accounts
  • e.g. 1,000, particularly C&I customers
  • DSB did not anticipate large numbers in these calls
  • Potential solution is to change the pagination limit for the API
  • Change Request #604 has been raised and will be considered for this MI, raised with AEMO, and added to the agenda for NFR Workshops scheduled in August. ⚡
• Discussion on whether primary data holders are expected to enforce thresholds for the secondary data holder
  • The secondary data holders have no visibility of consent, start time of session etc so are unable to manage this.
  • Change request #603 has been raised and AEMO has been asked to investigate and advise on whether they can enforce the NFRs. ⚡

Next Steps

• DSB encourages the community to review the proposed candidates for this iteration and post comments on the respective issues if there are any concerns or implications to consider. ⚡
• DSB will review the proposed candidates and monitor for comments to assist with analysis.