Meeting Notes

• This was the last meeting for MI 21. The purpose of this meeting was to confirm the candidates that will be proposed in MI 21. The Decision Document with approved candidates will be drafted and sent to the Chair for approval.

Actions

• 659: action to be closed as the CX issue will be dealt separate to the CR
• 656: no feedback received yet. Action and CR will be carried over to next MI

Maintenance Iteration 21 Candidate Discussion

663 - Maintenance Iteration 21 Holistic Feedback

• Staging done for most issues
• No concerns raised by participants.
• Changes will be recommended to Chair as Non breaking change

661 - Obligation milestones for 2026 and 2027

• DSB noted this is not a standards change, and is noting future schedule for potential obligation dates for CY 26 and 27. It follows convention from previous years and help ensure rules and standard releases can align to same dates
• No objection from participants
• Change will be recommended to Chair as Non breaking change

674 - CX Guidelines: Updates stemming from 2024 Consent Review changes

• DSB noted that the new rules have been announced and the team are working on updating draft CX guidelines to incorporate rules changes
• The updated CX guidelines will be published on this ticket in coming weeks
• Ticket will stay open beyond MI to allow participants to provide any feedback

659 - Enhancing CDR Adoption: Streamlining Account Selection and Improving Data Transparency

• The issue spans across multiple domains:
  • CX Guidelines - CX will publish draft guidelines as discussed in last call
  • CX Standards - DSB noted the need to assess the issue further and more community input is required to do proper due diligence
  • Technical standards - As noted in previous MI call, no change is proposed to technical standards
• Participants agree to above approach
• CR will be left open under Requirement Analysis to progress the assessment on CX standards change

655 - Get Metrics V5 error metrics documentation

• Participant feedback noted option 2.2 as preferred option
• Change will be recommended to Chair as Non breaking change

666 - Retirement of OIDC Hybrid Flow

• No further comments received on staged changes, including the proposed FDO of 12-05-2025
• No concern on proposed FDO or changes from participants
• Change will be recommended to Chair as Breaking change

540 - Data Recipient Software Product unable to indicate optional idtoken encryption requirement

• Issue and resolution related to CR 666
• Issue will be closed once changes from CR 666 are implemented

667 - Clean up of Refresh Token requirements

• DH participant noted 6 month lead time should be considered from release date of the standards and should be consistent across all changes with FDOs
• DSB acknowledged this and asked participants if they had any concerns with the current proposed 5 month FDO for this CR. Participants noted no issue
• Change will be recommended to Chair as Breaking change

654 - Clarify Transaction Security requirements

• Change will be recommended to Chair as Non breaking change

664 - New Enums for Voluntary disclosure of additional service overlays

• DSB recommendation to restructure standards to allow NPP data overlay (option 2)
• DSB asked participant feedback on FDO for new endpoint version for Get Transaction Detail if option 2 were to be adopted
• Vendor participant noted they can't comment on FDO, acknowledging it most likely can't be instant but shouldn't be 1-2 years otherwise no one will get value. Potentially 6-12 months
• ADR participant noted that if the issue is not resolved in this MI, they would need to raise a non-compliance complaint to ACCC to deal with non compliant data being provided by DH as the issue has been around for 2 years. They noted that as of now, ACCC have not prevented sharing of this data as more data is being shared. The participant had no preference in solution option as long as it is done asap
• Participants suggested the change can be proposed with presumption of 6 months FDO and gather feedback on it
• DH participants agreed to review and provide feedback on if 6 months FDO is feasible
• DH participants also noted that if the data is currently only being filtered, 6 months will be reasonable but would need to assess
• DSB clarified intent of change to ensure standards provide appropriate breadth to allow sharing of OSKO/NPP service overlay data without being specific
• DSB will recommend the change (option 2) to the Chair as Breaking change with 6 month FDO (FY25#3 2025-07-14). DHs to review the change option 2 and comment if 6 month FDO not achievable

229 - Service field in the Get Transaction Details API

• DSB noted this issue is a duplicate of CR 664, and will be addressed as part of it
• Issue will be closed once changes from CR 664 are implemented

660 - Revise the Availability Requirements NFRs

• DSB noted that this issue was presented as part of NFR presentation to DSAC
• CR will be carried over to next MI

656- A status of POSTED should indicate the final update for a transaction

• DSB provided overview of proposed changes (total 6) to help resolve issues discussed as part of this CR
• DH participant raised question if there are reconciliation challenges between different channels, resulting in different amounts (e.g. transaction) being displayed in CDR vs non CDR channels (such as internet banking), resulting in confusion. DSB acknowledged the feedback requesting examples from DHs to help assess. The DH agreed to investigate and provide any examples
• ADR participant provided example of when posted transactions have changed, specifically with regards to a core banking provider for a DH classifies authorised card (credit or debit) transactions as posted instead of pending. The noted that such authorised transactions are provided as posted with different id's resulting in duplication of data. Another scenario where a posted transaction can change is cases of fraud.
• ADR participants noted this issue would benefit from broader DH input
• DH participant suggested that some of the proposed options may be dealing with other scenarios and issues not related to the original problem raised in this particular CR
• ADR participant noted having a definition of what posted means in the standards would help. This would help clarify where transactions that have been authorised would or would not be classified as posted
• ADR participant will review and post comments with potentially new solution that would combine options 1 and 2, acknowledging this CR would need to be carried over to next MI
• CR will be carried over to next MI

657- Addition of LVR in the enumerated values list for constraintType

• No concerns from participants on proposed solution or FDO
• Change will be recommended to Chair as Breaking change

553 - Running balance available under transaction detail

• ADR participant noted the last comment on CR from Bendigo bank noting this is not required data under the rules. This implies that this CR requires escalation to TSY/ACCC as it would potentially be a rules change
• Another ADR participant agreed noting it may be better resolved via compliance
• DSB noted that feedback from DHs till date has indicated they do not hold running balance and is calculated as required. DSB asked if adding a timestamp field to the balance API indicating when the balance was sourced would help and if there are any concerns or issues on this from participants
• ADR participant noted it would help but said the fundamental question is if its ADRs responsibility to calculate this information (i.e. running balance) or DHs responsibility to provide it (deeming CDR data as high quality data that auditors can trust/use it). The answer would have implications to use cases such as auditing, where auditors would only accept information provided by DH
• Another ADR participant noted other use cases such as accounting, legal scenarios and financial planning, which require the assurance that the data is accurate and complete from the source.
• DSB asked if the initial change of adding timestamp (called lastUpdated or something similar) noting when the data was last updated could be done as part of this MI and the discussion on other changes (i.e. running balance) can be continued in future MIs
• DH participant noted it would be important to clarify what modified means in relation to capturing the timestamp as there will be lots of systems carrying out various jobs
• Participants agreed to proposing the timestamp field change as part of this CR as with staged FDO, where the field would be made optional with 6 months FDO, and mandatory after another additional 6 months FDO
• Change of introducing timestamp field will be recommended to Chair as Breaking change with staged FDO approach noted above
• Actions:
  • ADR to comment on proposals noting that ADR generated running balance may not meet the use case requirements and seek clarification from ACCC/TSY if running balance is classified as required consumer data

473 - Add RFC8174 to list of normative references and update the use of Requirements Levels

• No objection from participants
• Change will be recommended to Chair as Non breaking change

8 - Adoption of detached signatures

• CR to be kept open in backlog for consideration in future MIs

649 - Inconsistent JARM error responses

• DSB asked participants if, in cases where DHs are providing cancel or exit buttons in their CX flows, if providing some standardisation for error responses would be useful in the short term while other options are being progressed
• ADR participant noted it would be helpful to have some structured response as currently, when the user is redirected back to them, they get either no response or get a response with no JARM which may not be standards compliant. They have received different interpretations from ACCC as to whether JARM is mandatory
• DSB noted that there may be valid scenarios where JARM cannot be provided, such as session timeout occurring
• DSB further noted that if DHs are not providing error response where it is required, it would need to be treated as non-compliance issue. Also noting that JARM does not cover all scenarios where errors responses are provided and we would need to assess how they could be extended to support CDR use cases. There are potentially only 2 scenarios where JARM requires error response and they are during the authorisation
• ADR participants noted that if nominated-representative issues were resolved, the need for this change may not be there
• One DH participant noted that they could extend their authorisation solution to provide error responses in alignment with abandonment stages
• DH Vendor noted that changes from their perspective were also easy to implement
• ADR noted if there was a specific area in the standards they could refer to about JARM/error code response requirements, it would facilitate them in raising a non-compliance issue when required
• CR will be carried over to next MI

650 - Weaken JARM Encryption Requirements for ADRs

• CDR Vendor noted they raised this CR based on their observations coming into the recipient space, suggesting it is costly to force ADRs to implement JARM encryption when only a small minority of DHs are using it
• DSB clarified signing would still be required, the CR is only focusing on encryption requirements
• CR will be carried over to next MI

Other business

N/A

Next Steps

• DSB will prepare the MI decision proposal for the Chairs review and approval. Once approved, the changes will be incorporated into new standards version.
• The changes will also be staged for community review.