• This is the first meeting for MI 23, the purpose is to identify candidates for consultation.

• Current version is 1.34.1
• Changes arising from MI 22 will be published in version 1.35.0 in the coming weeks
• Changes resulting from this MI will be published in version 1.36.0 or later

Energy 662 - Extend Get Generic Plan Detail to include a new field: tariffCode

• This issue was consulted on in MI22 and carried over to MI23 while the DSB seeks Policy advice. This provides an opportunity for participants to propose alternative solutions.

Banking Issue number TBA - Potential new issue relating to banking issues included, but deferred in Decision 338

• ACTION: Frollo to summarise key aspects from issues #283, #284, #567 and #569 in a new issue to be considered as a candidate.

Holistic

690 - Maintenance Iteration 23 Holistic Feedback

• New issue, proposed as a candidate
• A clarification on TLS examples has been suggested.

CX

684 - CX Guidelines - ADI or NBL to hold CDR data as a DH

• Carried over from MI22, proposed as a candidate
• An overview of the draft guidance for ADRs who are ADIs or Non-Bank Lenders, available in this comment was provided.
• Clarification on the deadline for feedback was requested. DSB confirmed we're aiming to finalise the guidance as part of MI23. The sooner feedback is received, the easier we’ll be able to wrap it up in this MI. Late feedback may cause the issue to be carried over to MI24.

691 - CX Guidelines - Expanding Amending BCDC CX Guidelines

• New issue, proposed as a candidate
• An overview of the issue was provided.
• One participant committed to providing feedback as it's relevant to their requirements, particularly with regard to points relating to the bundling of multiple consents.

693 - CX Guidelines - Historical date ranges for Authorisations

• New Issue, proposed as a candidate
• An overview of the issue was provided.
• In some circumstances DHs are providing more history than the 2 years. There is interest in whether MUST or SHOULD will apply. What affect is there on reporting where DHs already provide more than 7 years, does it need to be disclosed?
• The DSB invites the community to post these questions on GitHub for further consideration.

Register

679 - Update SSA specification

• Carried over from MI22, proposed as a candidate
• Options in the original post on the issue provide for participants changing details.
• ACCC requested feedback from participants as to whether brand and software product ID values presented on the CDR Provider page should be included in the SSA specification.
• The DSB is keen to learn of any challenges data holders may experience in supporting option 2.

665 - Review Register error code documentation

• Proposed as a candidate
• Aligns Register endpoint error codes to be consistent with all other endpoints defined in the Standards

NFR

660 - Revise the Availability Requirements NFRs

• Carried over from MI22, proposed as a candidate
• Reporting on outages covers unscheduled outages. The intention is to include scheduled outages in reporting and provide a mechanism enabling ADRs to better manage impacts on their customers when frequent and extended outages occur.
• DSB to update this issue to propose solutions discussed in MI22

Energy

680 - Jurisdiction Code of ISO

• Carried over from MI22
• Voluntary data sharing relies on CDR eligibility, therefore consumer data for NMIs with a Jurisdiction code of ISO are not eligible CDR consumers and therefore data cannot be provided voluntarily.
• This issue will be closed.

686 - Superfluous timeZone property for EnergyPlanTariffPeriod schema

• Proposed as a candidate.

Banking

687 - Bank account balance calculation time is indeterminate

• Carried over from MI22, proposed as a candidate
• UK Open banking has a similar field, therefore the DSB is keen to understand the feasibility and cost of providing this detail.
• One participant supported this change.

688 - BankingBalancePurse currency field is optional

• New issue, proposed as a candidate
• Intention is to make this field mandatory.
• DSBs would like to understand if this change would have any impact to participants as the value should be expected if an 'amount' is included in the array.
• ACTION: CBA agreed to check their multicurrency accounts to provide a view on impact to their implementation.

694 - Add a Card identifier to the Transaction endpoint

• New issue completing an outstanding action for #471 raised in MI22, proposed as a candidate
• Concern over different DH having different IDs so consistency across DHs may be difficult.
• Suggestion to generate a unique Hash for each card holder was proposed to manage privacy concerns and enable mapping. It wouldn't matter what the hashed value format was across DHs as long as it was consistent for each card holder when generated.
• Credit card renewals may also present challenges as this generally means a new account is created, therefore a card holder may require a new hashed value when this occurs.
• ACTION CBA and ANZ agreed to investigate their systems to advise what might be possible in the next call.

Banking

689 - Missing Mandatory Data

• This may relate to data quality issues raised in 673 - Banking transaction data quality
• DSB to review proposal

692 - ISO 8601 - Home Loan Repayments

• DSB to review proposal

Common

685 - Organisation isACNCRegistered values are unclear

• Proposal to change value from Boolean to ENUM for consistency.
• Not proposed as a candidate

Security

Potential issue to be raised by SISS for consideration as a candidate in this Iteration that deals with token endpoint compliance.

CX

ADR details shown on Dashboards and in Consent Flow

• SISS mentioned different data holders are displaying ADR details differently (i.e. referencing different fields) in the authorisation flow and on consumer dashboards, providing an inconsistent experience for consumers. For example:
  • DH1 might show SISS Data Services Pty Limited (legal entity name) in authorisation and dashboards
  • DH2 might show ACSISS (brand name)
  • DH3 might show ACSISS My Data (Software product name)
  • other data holders might show all three, i.e. SISS Data Services Pty Limited ACSISS ACSISS My Data
• This is more complex for some ADRs, where their names are vastly different from each other (e.g. Adatree Pty Ltd as legal entity name, Adatree as the Brand name and Sherlok as the Software product name where CDR Representatives are involved)
• The issue is further compounded with BCDC models, where there is a third party, for example an accounting platform, who will receive access, though this isn't referenced by the DHs. It's a lot of names for a consumer to parse and understand, and it's an inconsistent experience across data holders creating further confusion.
• DSB acknowledged this is an existing and well known issue, first contemplated in DP229, and that the CX Team has been exploring the issue in recent consent drop off research, which corroborated SISS's point regarding confusion.
• DSB highlighted the CX guidelines currently do recommend that DHs show the legal entity name, brand name and software product name on the dashboard for completeness, though these are all only guidelines and not rules or standards. The Authorisation to Disclose CX Guidelines also specify that the Legal Entity Name must be used in the authorisation flow, and that the rules prevent DHs from providing any other information in the authorisation flow.
• Relevant resources:
  • DP229
  • CX Guidelines - Consent Management, Data holder: Authorisations, specifically noting annotations 5CM1.00.11 and 5CM1.00.23
  • CX Guidelines - Authorisation to disclose, specifically noting annotations 3AU.00.01, 3AU.00.02 and 3AU.02.15
• It was noted the guidelines may be broad enough to leave room for interpretation, leading to differing implementations from different DHs. Participants suggested the guidelines be strengthened and clarified, and if this continues to present an issue, new CX or Technical standards may be necessary to force compliance and consistency as a last resort.