Meeting Notes

• This meeting was the first for MI 21. The purpose of this meeting was to identify the change request candidates for this iteration.
• Participants also reviewed the issues backlog and performed prioritisation and grooming on the oldest issues.
• An initial list of candidates was proposed by participants and the DSB. This list is available via the Standards Maintenance board. Items in Requirements Analysis and Iteration Candidates are currently shortlisted. Final review will consider any additional candidates proposed in the DP 356 thread.

Release Plan

• The changes arising from Maintenance Iteration 20 are planned to be published in v1.32.0. Date to be advised.

Maintenance Iteration 21 Candidate Selection

The following changes were proposed in the meeting by participants

Requirements Analysis

• 573: Clarification on handling of standard claims in request object
  • Further analysis is required by the DSB. It was proposed this issue be left in Requirements Analysis and not progresses as an iteration candidate in this MI.
• Guidance for account removal and the impacts to active consents
  • A participant has outlined several scenarios via email to the DSB seeking clarity on expected responses.
  • An energy participant asked whether there is a parallel in Energy where the retailer is no longer the FRMP - in which case the Secondary Data Holder is then obliged to reject it.
  • In this scenario a primary retailer “SHOULD” know that they aren’t the FRMP
  • As such, when the retailer realises they are no longer the FRMP for the NMI then they should no longer call AEMO
  • It was discussed that this might be a compliance issue due to existing requirements
  • Banking data holders were also supportive of getting this clarity
  • It was agreed by the DSB that taking a use case based approach to guidance would benefit all participants
  • ACTION DSB to provide use cases and expected outcomes for authorisations based on account removal scenarios
  • Issue raised: 669 - Guidance for accounts becoming unavailable

Holistic Changes

• Not discussed

Security

• 649: Inconsistent JARM error responses
  • The change pertains to consistent error reporting where issues occur regarding the formatting of JARM error responses and the errors that occur during authorisation
  • ADRs supported prioritising this change
• 666: Retirement of OIDC Hybrid Flow
  • Supported for prioritisation in the MI - this issue deals with the retirement of Hybrid Flow
  • A large banking data holder stated that only a few ADRs continue to provide client registrations including OIDC Hybrid Flow
• 540: Data Recipient Software Product unable to indicate optional idtoken encryption requirement
  • This issue related to #666 and can be closed based on the conclusion of #666 because ID token encryption is only required for OIDC hybrid flow
• 667: Clean up of Refresh Token requirements
  • Hygiene change to remove ambiguity with refresh token cycling
  • Supported by participants

CX

• 659: Enhancing CDR Adoption: Streamlining Account Selection and Improving Data Transparency
  • Proposed by participants as an iteration candidate for MI21

Banking

• 656: A status of POSTED should indicate the final update for a transaction
  • This change relates to different interpretations between Data Holders for different states of a transaction
  • A data holder questioned whether there was a reason why it is not a data quality issue?
  • An ADR indicated that there was room for interpretation and they Want a clear standard in regards to data quality
• 553: Running balance available under transaction detail
  • This issue was supported by ADRs for prioritisation in this MI
• 657: Addition of LVR in the enumerated values list for constraintType
  • Proposed by a Data Holder participant for consideration in this MI
• 664: New Enums for Voluntary disclosure of additional service overlays
  • Strong support from ADRs to prioritise this change
  • This change relates to #229

Energy

• No changes were proposed by participants

Admin

• 655: Get Metrics V5 error metrics documentation
  • Discussed the views of some participants that it is a breaking change
  • Participants supported this issue being prioritised

NFRs

• 660: Revise the Availability Requirements NFRs
  • ADRs indicated support for stronger requirements regarding outages to ensure CDR outages are dealt with commensurate to a Data Holder's other digital channels.

Documentation

• 473: Add RFC8174 to list of normative references and update the use of Requirements Levels
  • Proposed as a simple clean up of the documentation to use capitalised requirement levels for RFC4122 references as this reference is used extensively in response payload descriptions.
  • Refer to comment.

Backlog grooming

Issues to remain open

• 427: Standards & Guidelines regarding Sponsored Accreditation
  • Remain open
  • Original poster shall review to see whether this is required.
• 468: Secondary user approvals withdrawal standards
  • Remain open
  • CX to check on whether latest rules consultation will impact the CR.
• 470: Overloading of banking language for scopes / data clusters
  • Remain open
  • Noted that this is dependent on FAPI 2.0 transition, so will stay in backlog for now
• 173: Behaviour where posted transactions only have an associated date.
  • Remain open: Still an issue
  • Lack of clarity on how DHs indicate no posting time - some DHs providing 00:00.000 but in GMT. This results in a compliance issue as it then indicates a posting time 10AM AEST which ADRs interpret as a valid time.
  • Discussed changes in the wording to provide clarity. This has been raised as a compliance issue.
  • Related to issue #658
• 290: Bank initiated credit card account closures, and the impact on customer access to historical account data
  • Remain open: this remains an issue in relation to credit cards that are closed (e.g. for suspected fraudulent transactions) and there can be challenges for ADRs to determine how to relate the closed account to any new account.
  • New accounts may not be associated to the authorisation by default either
• 443: SSA definition: Deprecation of revocation_uri
  • Remain open: still relevant, but consider future packaging with other standards
• 470: Overloading of banking language for scopes / data clusters
  • Remain open: This remains relevant: if the data being disclosed is for a business consumer then the appropriate customer language should be surfaced, otherwise the DH may surface different language. This issue is related to support of RAR and richer authorisation messaging.
• 474: Update description of energy API attributes (where applicable) to specify which rates are GST exclusive
  • Remain open: review the rates and amounts in energy endpoints to be explicit which are inclusive or exclusive of GST - most describe that - still relevant
• 480: 1.13.0 appears to have broken pseudonymity of Pairwise Identifiers
  • Remain open: The original poster shall review and provide a view of priority
• 484: 1.13.0 Appears to have introduced new SSA error behaviours
  • Remain open: related to #480
• 508: Provide APIs to automate onboarding of software products and provisioning of certificates
  • Remain open: ACTION DSB shall follow up with ACCC to ascertain current support
• 518: Deliver V2 of the GetDataHolderBrandsSummary API
  • Remain open: the change was in regards to making interimId mandatory. ACTION DSB to refer the change back to ACCC
• 519: Billing API Change
  • Remain open: ACTION DSB to assess whether this change has been resolved
• 175: Premature Completion of Consent (Hybrid) Flow
  • Related to Zendesk #2395 where CX is working in the background.
  • ADR participants noted that guidance would be useful here as they currently don't display consents that are not technically functional, even though the consumer has granted consent to collect and the ADR has created an 'initialised' consent record.
  • There was concern raised that dashboards can become out of sync in other situations, including where a Data Holder shows an authorisation on their dashboard, but the ADR may not successfully complete token exchange. In this case, the Data Holder may show an entry, but the ADR may not.
  • An introspection endpoint was suggested as an option that could assist with keeping dashboards in sync (such as: #628 - Addition of a DH-side endpoint for querying the status of a consent establishment flow, or lodged intent or grant management)

Issues that will be closed

• 2: Address the data gaps identified in feedback by FinTech Australia
  • Close issue: Consensus to close this issue.
  • Owner occupied status is now in the stadards
  • DOB is precluded by the rules,
  • Listing guarantors is not permitted by the rules and raises privacy concerns,
  • Bank application details may be valuable especially where account origination were to be offered by Data Holders in future. If there is support in future, then the DSB encourages participants to raise a dedicated change request
  • Default status of consumer raises significant privacy concerns and lacked support by both ADRs and DHs
  • Asset management and securitisation of loans had no support in the call. If there is support in future, then the DSB encourages participants to raise a dedicated change request.
• 219: Allow retrieval of current refresh_token by arrangement ID
  • Close issue: in light of banning refresh token cycling this is no longer presenting the same prevalence or problem because loss of refresh token won't occur throughout the sharing duration
• 287: Why are non-ADI lenders excluded from CDR requirements?
  • Close issue - NBL is now a designated sector with rules and implementation dates TBA
• 291: Credit card loyalty program data: significant gaps and lack of structure
  • Close issue
  • There were no comments from Data Recipients on potential use cases or drivers for this change.
• 357: Travel Money Card Balance
  • Close issue: Original poster will close the issue
• 376: Include FAX as CommonPhoneNumber purpose
  • Close issue: Lack of support from ADRs indicating that FAX number is not important to their use cases
• 418: CDR Data Holders outbound connection whitelisting
  • Close issue: Unless there is further change supported by participants, it is proposed the change be closed.
• 464: Extra information in the release notes
  • Close issue: Unless there are further enhancements supported by participants, it is proposed the change be closed as all documentation improvements have been addressed.
• 467: Missing link between Account and Plan
  • Close issue: Plan ID was not included as plans change regularly.
• 466: Use of Open Data Principles
  • Close issue: This issue was not defined as a change request and it is unclear what change is being proposed. If the original poster wants to raise a CR in future it can be considered.
• 282: Product Reference Data - major inconsistencies in Residential Mortgages
  • Representational approaches by different Data Holders may impact the ability to successfully initiate actions for origination or comparison.

Issues being addressed through DP 306 / DP 338

• 283: Product Reference Data - Residential Mortgage package discounts
• 284: Product Reference Data - revert rates for fixed rate mortgages are absent
• 285: Product Ref Data - leeway within standards makes fee comparison difficult
• 292: Credit card balance plans and payment hierarchy: inadequate information within the CDS
• 316: Update description of features[].isActivated to remove default
• 387: PRD - Constraint types
• 390: Use of additionalValue field for ADDITIONAL_CARDS
• 408: Transaction Limits in Product Reference Data
• 471: Additional credit card fields

Other business

None

Next Steps

DSB will assess priority and determine capacity to address the candidates proposed for consideration in this iteration. The community is invited to comment on issues affecting them.