Meeting Notes

• This meeting was the second last for MI 21. The purpose of this meeting was to discuss and progress the candidate change requests.

Maintenance Iteration 21 Candidate Discussion

663 - Maintenance Iteration 21 Holistic Feedback

• Discussed current list of minor changes.

661 - Obligation milestones for 2026 and 2027

• Proposed obligation dates for 2026 and 2027 for community feedback.

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

• DSB noted that draft guidance has been published for community feedback.

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

• DSB provided overview of draft CX guidelines demonstrating how data holders may, under the existing CX standards, voluntarily implement 'select all' functionality for account selection.
• DSB also noted that the separate technical request that would indicate the number of accounts that were available for sharing and the number of accounts the consumer choose not to share cannot be currently supported as it does not satisfy the rules for privacy considerations.
• DSB is seeking feedback on the above along with making a CX standards change that would require all DHs to include a "select all" ability for consumers account selection.

655 - Get Metrics V5 error metrics documentation

• DSB provided an overview of the proposed options and is seeking feedback.

666 - Retirement of OIDC Hybrid Flow

• DSB provided an overview of the proposed transitional stage change that allows support of Hybrid Flow up until the proposed retirement date of Y25 # 2: 2025-05-12, noting that DHs can stop support if they wanted prior to that date. It has been staged for review.
• DSB also noted the intended target state is staged and available for review. This change would no longer support Hybrid Flow and would take affect after the above noted retirement date. This would make the standards align with FAPI 2 security profile.
• DSB is seeking feedback on the above, including the proposed retirement date.

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

• DSB noted that this change would not be required due to the proposed change in #666 which will remove support for Hybrid Flow, resulting in ID Tokens no longer being delivered via the front channel.
• DSB is seeking feedback on the above and if the CR can be closed with no change.

667 - Clean up of Refresh Token requirements

• The change has been staged for review.
• It was noted that this is a breaking change.
• ACTION: DSB to propose an FDO. This action is completed with a proposed obligation date of Y25 # 2: 12th May 2025 being noted in the original comment.

654 - Clarify Transaction Security requirements

• ADR Participant noted no issues with the proposed documentation improvement changes in security sections of the standards.
• Pending any further feedback, DSB will proceed with recommending the changes.

664 - New Enums for Voluntary disclosure of additional service overlays

• DSB noted that whilst the original request by NAB was proposing a voluntary change to help provide new NPP service overlays, as it falls within required transaction data, the change would be mandatory.
• DSB provided an overview of the two options proposed in this comment.
• ADR participant noted they are currently experiencing issues where some DHs are providing new NPP overlay codes via the standards and they have had to update their code to cater for it. They suggested a change to extend the ENUM values of service field to help address the issue whilst options that result in structural changes are being considered.
• It was clarified that DHs are currently providing service values in the service ENUM field which are currently not specified in the standards. It was confirmed that this makes the DH non compliant, however there is a clear consumer benefit in introducing changes that would allow sharing of such overlay codes in a compliant manner.
• Participants noted that, for a strategic solution, option 2 was preferred.
• DH participant noted that making a simple change as a tactical solution would also be breaking and would result in multiple releases required to get to the final solution, resulting in more effort and potential cost requirement.
• ACTION: DSB to review feedback and revise proposed options that consider transitional stages with implications.

229 - Service field in the Get Transaction Details API

• Issue related to #664 and covered in previous discussion.

660 - Revise the Availability Requirements NFRs

• DSB provided an overview of the 4 proposed options.
• Through discussions, it was clarified that there are two types of outages being proposed, broad brush/overall outage and more granular outages which could cover specific products types that would not be available.
• ADR participant noted that the proposed options are great, however also acknowledged that the granular outage would potentially impose significant burden on DHs. They re-iterated that the original request was seeking to address the issue of daytime (business hour) outages which has more significant impact on serving their customers.
• DSB clarified that, upon investigation, some recent outages were unavoidable by the DH due to PS11 compliance requirement.
• ADR participant noted that there are multiple DHs that have scheduled daytime outages whilst their other services are not impacted.
• DH participant acknowledged that banks can choose not to display up to date data on other channels (by noting that it is stale data), however PS11 prevents them to do so in CDR.
• ADR participant noted that despite DHs not providing stale data to ADRs due to PS11 concerns, the ADRs end up having to provide stale data to their consumers. The preferred option would be for DHs to, in instances of PS11 impact, call a partial outage and keep the service up. It was noted that this would align closely to options 2 and 3 or a variation of option 1 where no account level attachments are made but more broad API level outages are noted.
• The partial outage solution could also help address daytime outages.
• DSB noted a new option 5 that would help deal with uptime and availability in general.
• DSB clarified that OAIC has also been engaged to help deal with PS11 issue, which can happen in parallel to the options being discussed as part of this CR.
• ADR participant requested if PS11 impacts could be removed from option 1. DSB will review and consider this.
• DSB asked if the error codes being returned as part of API requests during partial outages help address the issues. ADR participants noted that they would still have to call an API to get the error, and consumers would have already been engaged for consent which is not ideal. They would want to know of partial outages prior to making API calls.
• General view from ADR participants was that granular outage information is not necessarily required.
• DSB raised the question on any potential considerations for unscheduled outages.
• ADR participants noted it would be helpful but would welcome DH feedback on if it is achievable.
• ADR participant raised a question on current issue they are experiencing where a DHs page sizing is not working properly and if that constitutes a full or partial outage, and if there is a need to define what an outage is.
• DSB explained that being too exhaustive in defining an outage would result in issues, and this would be better dealt with via engagement with ACCC and helping understand the significance and criticality of such issues.
• ACTIONS:
  • ADR and DH to review proposed options and provide feedback.
  • DSB to review feedback and revise options as required.

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

• DSB clarified purpose is this documentation correction is to ensure consistency in documentation and hygiene maintenance.

649 - Inconsistent JARM error responses

• DSB provided an overview of the recent comment noting that providing specific error codes in JARM responses would override upstream oAuth specs and could be problematic for DHs using IAM vendor products.
• The lodged-intent approach adopted by the UK was proposed for consideration as an alternative.
• ADR participants suggested that the standardisation approach (i.e. error codes in JARM responses) might be a quick win and would want to hear DHs views on it. The cost/benefit of better solutions might not stack up, and some structured field data will give them something.
• A CDR vendor noted their observations that some DHs struggle to provide appropriate error codes during the consent flow and suggested that standardising error codes via JARM would not work. It was hypothesised it might be easier for DHs to implement error codes outside the consent flow, which would involve a Job ID which could be used to poll the status of a consent. This would de-couple it from JARM and response modes.
• ADR participants reiterated they just want to know where the failure is to provide better support for the consumer, as not receiving an OTP is much different to leaving at account selection, or abandoning at the end of the consent flow.
• CDR vendor reminded everyone that explicit errors won’t solve someone closing the browser. Only 50% of the problems would be recorded with either solution.
• ACTION: Data Holders and ADRs to provide feedback on the above views discussed during the call.

Other business

None

Next Steps

DSB will stage the changes for candidates discussed in this iteration for community review. The community is invited to contribute to the discussion on issues affecting them.