Meeting Notes

• This meeting was the third for MI 21. The purpose of this meeting was to discuss problem definitions and potential solutions to identified iteration candidates.

Maintenance Iteration 21 Candidate Discussion

663 - Maintenance Iteration 21 Holistic Feedback

• No new issues

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

• CX: The community was asked to provide feedback on a mandatory ‘select all’ on Github and during the call. No feedback has been received.
• Technical: The DSB are seeking views from ACCC and OAIC, but minded to that the tech component wouldn’t be supported under the rules due to privacy considerations.
• Action: The community to provide views on a mandatory 'select all' functionality in account selection

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

• No feedback has been received yet, so the DSB is proposing to move forward with what’s stated in the original post. The CX team noted that this list may be refined further over time as their analysis continues.

664 - New Enums for Voluntary disclosure of additional service overlays

• DSB indicated that the rules require the data to be shared and therefore it would be a mandatory change, not a voluntary change for Data Holders
• DSB presented further analysis and presented options for consideration
• Feedback indicated that all options would work well
• The DSB requested Data Holders review and provide comment on the options preference
• An ADR indicated that some DHs are already sending the additional X2P1 versions back despite what is defined the standards.

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

• Issue pertains to some Data Holders reporting pending transactions as posted
• There was general agreement in defining the a definition of posted such that the transaction does not change
• ADRs indicated that once posted, a transaction should be permanent expect for exceptional circumstances.
• Feedback from ADRs supported the DSB proposal
• Feedback from DHs indicated tentative support
• Action Data Holders to investigate and provide a response if the proposed changes would have any implementation considerations adopting the proposal.
• Action Data Holders to investigate and provide a response whether the lifecycle of transactions results in changes to posted transactions and what occurs in reversal scenarios - does this result in a change to the same transaction, or creation of a new transaction?

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

• Discussed whether Min and Max are negotiable and therefore there there could be both a max and a min in the same way that there is a headline interest rate.
• DSB clarified that this change is not related to account data, only product reference data

553 - Running balance available under transaction detail

• Discussed a key use case is allowing Trusted Advisors to properly audit bank accounts to confirm the balance at a point in time agains the transactions. This allows an auditor to verify the correctness of the accounts.
• A common issue that occurs with accounting platforms is the acceptance of imported transaction data that can be tampered with and there is no data integrity. CDR solves this by providing a bank feed from the source direct to the Trusted Advisor
• Discussed a combination of timestamp on balance plus a lastModified data on transactions to allow ADRs to determine a running balance
• Discussed whether banks have a finite set of formulas to calculate running balance which ADRs could use to determine the balance. This may differ across products.
• Potential for added complexity if ADRs need to know all formulas for balance calculation across all products and data holders
• It was noted that one Data Holder employs a system cache with an event-driven architecture that updates current and available balance in the cache when new events occur like a change in credit limit or a new transaction is posted.

660 - Revise the Availability Requirements NFRs

• Discussion focused on technical notification improvements

• A Data Holder identified that some outages are occurring to address PS11 compliance in regards to up to date data requirements

• Support for disclosing the list of affected endpoints in a partial outage

• Support for a technical explanation of an outage

• Feedback from Data Holders suggested Outages could also share the products that are affected

• It was noted this may create a lot of complexity

• Alternative solutions discussed included a notification at the account or transaction level

• Whilst more complicated, it was also asked what is the expectation if a consumer attempted a new consent. Should the DH display an outage notification or data latency notice during consent establishment?

  • this was deemed technically challenging and result in more implementation effort

• One Data holder indicated that rather than a full outage, declaring certain accounts as Temporally Unavailable could satisfy PS11. However this would still mean the account data would be unaccessible simply due to data latency issues

• Discussed consumer notifications - either the DH notifying the consumer through their existing channels or the ADR notifying the consumer. It was noted that this is only important where the consumer is present or there are time critical business functions otherwise for many batch data collection scenarios issues with data latency are not a problem

  • Discussed consumer messaging in existing channels to the effect that “if you share under CDR you wouldn’t have up to date data”

• Action DSB to draft the options for consideration

  • Option 1: Detailed technical outage information via Get Outages (including technical explanation, list of affected endpoints, list of affected data clusters, list of affected products or product categories, coded list of Data Quality and PS11 impacts)
  • Option 2: Allow DHs to deny data sharing at the account level via a Temporarily Unavailable error that is updated to include PS11 data latency issues
  • Option 3: Provide additional detail in the meta{} object for transactions and accounts where data latency is an issue
  • Option 4: Provide additional consumer notifications via the ADR, DH or both
  • These options are not mutually exclusive but can be considered in combination
  • It was noted that a clear problem that needs to be solved be stated for each option

• It was further discussed and supported that the Shared Signals Framework could be leveraged in future for DHs to notify ADRs when outages are occurring and what services are affected

655 - Get Metrics V5 error metrics documentation

• It was noted that the OpenAPI spec is intended to define API contract expectations so the defined error codes need to be listed, rather than inferred
• It was also noted that additionalProperties is optional however DHs must supply error-code level counts and they should be considered mandatory (or at least default to 0)
• It was also discussed that new error codes introduced by the data standards need to be managed and would result in breaking changes, including Get Metrics
• Implementers supported specific definition of the error codes defined by the standards with a future dated obligation
• Implementers supported the flexibility to add new error codes under the Extensibility framework

Security issues No security issues were discussed due to time constraints.

Backlog issues

No holistic backlog review was performed due to time constraints.

Other business

None

Next Steps