Date and time: 10/06/2021, 2pm - 3pm AEST
Location: WebEx
Dial-in details:

• https://csiro.webex.com/csiro/j.php?MTID=m64ff82797cdd2fb0779c845915fffcea
• Dial In Number: +61 2 6246 4433
• Dial In Access Code: 154 143 2512
• Quick Dial: +61262464433,1541432512%23%23

Chair: Mark Verstege, DSB
Maintenance overview: Further information
Maintenance project board: See here
Decision Proposal: This maintenance iteration is being consulted on under Decision Proposal 178

• Introductions

• Outstanding Actions

• Release plan: schedule of forwards looking standards releases

• Open Decision Proposals: key consultation dates

• Iteration 7 Issues: Change requests for review

• Normative standards review process

• Any other business

Meeting notes

• Meeting Notes
• Next steps

The purpose of the call this week is to review the prioritised backlog to select iteration candidates to be consulted on. The meeting will also review the process for consulting on the Future Plan's Normative Standards Review issue.

• Allow 5 min for participants to join
• Housekeeping
• Overview, purpose and intended outcomes of the meeting

• DSB to raise a Decision Proposal cover the Normative References Review item in the DSB's Future Plan.

The following release plan provides an upcoming view of the changes to be released:

• v1.10.0 was release June 1st.

• v1.11.0 Changes arising from DP160 and DP187, targeting pre-July

  • DP160 (consultation closed)
    • Updates to unavailable account standard for non-individuals, partnerships, secondary users
    • Secondary user instruction withdrawal standard
  • DP187 (consultation closing 18 June)
    • Disclosure consent standard
    • Update to ADR consent standard
    • Disclosure consent withdrawal standard

• Beyond v1.11.0: Priority changes for release will include enhanced NPP service overlay support and maintenance iteration 7 changes. Targeting July subject to consultation.

The following decision proposals are open for community feedback

DP #	Closing date	DP
166	11/06/2021	Decision Proposal 166 - CX metrics for Data Holders
180	11/06/2021	Decision Proposal 180 - Energy Draft Feedback Cycle 3
186	18/06/2021	Decision Proposal 186 - Engineering Support
187	18/06/2021	Decision Proposal 187 - CX Standards | Disclosure Consents
182	09/07/2021	Decision Proposal 182 - InfoSec Uplift for Write
183	Pending	Decision Proposal 183 - Purpose Based Consents

DP #	DP
176	Design Paper: an ‘opt-out’ data sharing model for joint accounts in the banking and energy sectors
177	Design Paper: a peer-to-peer data access model in the energy sector
168	Decision Proposal 168 - Separate Consents / Authorisation Withdrawal
162	Decision Proposal 162 - CX Standards / Joint Accounts / Authorisation Flow
160	Decision Proposal 160 - CX Standards / Non-individual Consumers / Business Partnerships / Secondary users
156	Decision Proposal 160 - CX Standards / Non-individual Consumers / Business Partnerships / Secondary users
155	Decision Proposal 160 - CX Standards / Non-individual Consumers / Business Partnerships / Secondary users
154	Decision Proposal 160 - CX Standards / Non-individual Consumers / Business Partnerships / Secondary users

Change Request

Update the description for transactionId to include "Mandatory if isDetailAvailable is set to true".

Context

This makes the implied requirement explicit and clear. It doesn't change or affect existing implementations.

Change Request

Introduce a new data field to denote when financialInstitution is not populated due to card scheme payment

Context

Given that the only condition imposed on this field for optionally omitting it is due to payments via card scheme, would it suffice to update the requirement of this field to conditional?

This would retain the implicit inference that the absence of the financialInstitution value means it is a card scheme payment however it would not create a breaking change: it would be a documentation fix to correctly highlight the conditional nature of the field value. Admittedly this is not an explicit indicator like your proposal.

Change Request

Make lastUpdateTime mandatory

Context

The lastUpdateTime field and updated_at claim should align. In other words, the same value should be responded to when the Data Holder has an update time or can infer a creation time for the customer information.

Regarding optional vs mandatory requirements for lastUpdateTime, at the time of initial consultation, several Data Holders indicated that they did not have a last update time and weren't able to derive the creation date.

Since the optional definition in the CDS means if you have the data you must supply it then it will be effectively mandatory unless a Data Holder doesn't hold update or creation time.

• https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/181
• https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/229

Change Request

Add support for other NPP service overlays such as X2P2 and X2P3

Context

Seeking input on whether any banks have implemented X2P2 and X2P3 service overlays. The DSB's understanding is that they are not currently implemented by any NPP participants and in the absence of a definition of the service overlay payloads, this would be premature.

There has been other discussion around providing better representation of existing payment schemes for instance, expanding transaction detail to clearly differentiate:

• BPay: BPAY reference id
• Traditional payments: BSB, Account Number etc
• International payments: Routing codes, payment instructions, intermediaries etc.
• NPP payments distinguished by service name and service version
• Internal Transfers: Source/Destination account
• Card payments

Change Request Remove references in the standards to obligations in the past

Change Request

Change or clarify the use of the term base path and base URI.

Link to the normative standards review can be found here: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/tree/master/reviews

Address any other business arising from the community

---

Issue #342 https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/342

• Treating the value as conditional was supported
• A community member raised an upcoming change from Visa will provide greater visibility on merchant details so this information may become more accessible even for card schemes
• It was suggested that the financialInsitution should be provided where possible for card schemes thus the proposed isCardSchemeDirectDebit approach wouldn't be the ideal way to deal with the issue
• The statement in the standards "Is required unless the payment is made via a credit card scheme" would still apply because there will be no value for historical card payments and may be limited early support for additional merchant details via card schemes. Where there is, the standards would require the population of the value because it is not optional from the perspective that it is at the discretion of the DH to provide.

Issue #181 https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/181

• It is understood based on feedback from community members in the iteration call and feedback from the NPPA that eftpos/BPAY service overlays X2P2 and X2P3 have been delayed. Proceeding with this change without sufficient informed data around the schemas for X2P2 and X2P3 data would be premature.
• DSB will seek feedback from other Data Holders whether there is any existing support for newer service overlays at this time

Issue #379 https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/379

• Preference expressed on the call was to retain recent future dated obligations for 3 months past their obligation date. Any past obligations older than 3 months from the current standards release date can be removed from the main standards FDO table

Issue #373 https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/373

• Community member raised that there is further ambiguity with holder path vs base path vs base URI
• Holder path is intended to be the root path set by the DH

• No other business was raised.

• N/A