ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 5th of August 2021 - ConsumerDataStandardsAustralia/standards GitHub Wiki

ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes

When: Weekly every Thursday at 3pm-4.30pm AEST
Location: WebEx, quick dial +61-2-9338-2221,,1650705270##

Meeting Details:

Desktop or Mobile Devices https://treasuryau.webex.com/treasuryau/j.php?MTID=m9614a7c6166155d3d950a8999e437f9f Once connected to your meeting remember to start your audio and video
Please mute when you are not speaking.

Video Conferencing (VC) Rooms
Use the remote control or touch panel and dial the number indicated below:
External VC Room: [email protected]

Phones - AUDIO ONLY

Agenda

  1. Introductions
  2. Actions
  3. CDR Stream updates
  4. Presentation
  5. Q&A
  6. Any other business

Introductions

  • 5 min will be allowed for participants to join the call.

Recording

The Consumer Data Right Implementation Calls are recorded for note taking purposes. All recordings are kept securely, as are the transcripts which may be made from them. No identifying material shall be provided without the participant's consent. Participants may [email protected] should they have any further questions or wish to have any material redacted from the record.

Acknowledgement of Country

We acknowledge the Traditional Custodians of the various lands on which we work today and the Aboriginal and Torres Strait Islander people participating in this call.We pay our respects to Elders past, present and emerging, and recognise and celebrate the diversity of Aboriginal peoples and their ongoing cultures and connections to the lands and waters of Australia.

Updates

Type Topic Update
Standards Version 1.11.0 Published Link to change log here
Standards Version 1.11.0+ Planned for End of July 2021
Maintenance 8th Maintenance Iteration Commenced Agenda from the 28th of July 2021 meet
Maintenance Decision Proposal 202 - Banking Maintenance Iteration 8 Link to consultation
DSB Newsletter To subscribe to DSB Newsletter Link here
TSY Newsletter To subscribe to TSY Newsletter Link here
TSY Newsletter 29th of July 2021 View in browser here
DSB Newsletter 30th of July 2021 View in browser here
Consultation Decision Proposal 180 - Energy Draft Feedback Cycle 3 Link to consultation
Consultation Decision Proposal 183 - Purpose Based Consents Link to consultation
Consultation Decision Proposal 186 - Engineering Support Link to consultation
Consultation Decision Proposal 191 - Retailer to AEMO InfoSec Profile Link to consultation
Consultation Decision Proposal 200 - Action Initiation Framework Link to consultation
Consultation Normative Standards Review (2021) Link to consultation
Consultation Decision Proposal 207 - Draft v3 Rules Analysis - Anticipated Data Standards Link to consultation
Action Question & Answer: ACCC Question: "Is there any survey or data collected from big banks that what are the nature of complaints received from consumers so far?" Answer: "Consumer reports provided directly to the ACCC are confidential and therefore not publicly disclosed."
Action Question & Answer: ACCC Question: "What are the implications of being late in responding to the rectification schedule?" Answer: "Any queries or concerns about rectification schedules can be sent to [email protected]"

CDR Stream Updates

Provides a weekly update on the activities of each of the CDR streams and their workplaces

Organisation Stream Member
ACCC CDR Register (Technical) Ivan Hosgood
ACCC CTS Andrea Gibney
ACCC Onboarding Jonathon Ingle
DSB CX Standards Michael Palmyre
DSB Technical Standards - Banking Mark Verstege
DSB Technical Standards - Energy & Engineering James Bligh

Presentation

None this week.

Q&A

Questions will be received by the community via WebEx chat before the questions are opened to the floor. Participants can pre-submit questions to the DSB mailing box.

We are trialling Sli.do for Question and Answer. Join our Q&A live here: https://www.sli.do/ Code: #169517

Answer provided

Ticket # Question Answer
900 Hi! This article contradicts the CX guideline 3 on Unavailable accounts, paragraph 3, that states that 'Unavailable accounts may also include ineligible accounts which data holders may show to mitigate confusion,...' https://www.notion.so/Authorisation-to-disclose-38714508a17b46cb83931882558458d5 Could you please clarify what DHs should follow. Thanks for pointing this out - the CX Guideline you referenced contains the correct rules interpretation. That is, unavailable accounts may include ineligible accounts and may be shown to the consumer in the authorisation flow.
927 Are Credit Card transactions (where customer gives the Merchant her/his credit card number for periodic deductions ) In-Scope for Direct Debit APIs ? (we accept that periodic Credit Card balance or interest payments are In-Scope for Direct Debits) Periodic credit card payments are not considered direct debits. If the schedule is managed by the data holder then they may be considered scheduled payments.
940 1.We would like to confirm the intent and usage behind the fees to be returned as part of the Account Details API. Certain products and accounts have specified ongoing fees (monthly or annually), as well as known fees that will apply to the account at some stage in the future (example : a fee for discharging a loan) while other fees may only apply to an account IF a certain scenario or type of transaction occurred. (example, a fee for a dishonoured direct debit). - Which of the following are intended to be disclosed as part of this API - ongoing, future, event based or historical? Also could you provide some insights on how is the fee information returned as part of account details API intended to be used? 2. Fees are not stored in our core banking system, rather calculated at a point in time and once applied, available as part of the transaction history for the account. Currently, account fees are only available to our customers via the transaction list for the account/account statement. The fees that may apply on the account is not something we currently have available to view for our customers via our online banking channel. Based on the above, we are seeking guidance on what categories of fee information are required to be returned in the Account details API response and an accurate way to represent these for consumer benefit, over and above the information that is already available via the PRD API or fee transactions via the Transactions API? there may be process fees that may be charged that are not related to a product, Assumption is that these are not required to be shown as part of the account details API response? The intention is that all of the fee categories you have raised should be communicated via the Account Details schema if they are related to the account. This includes event and process related fees if they are related to the account. Fees that are charged for generic processes that are unrelated to the account (such as a fee for an assessment by a financial planner) do not need to be included but account related fees such as fees for paper statements, early exit, redraw fees, transaction fees, etc are intended to be included. It is understood that the details of these fees are not usually captured in core banking systems.
951 Schedule 3, Part 3, Rule 3.2(5)(a) States that 'For an account that is closed at a particular time, the following CDR data is not required consumer data at that time: account data that relates to an authorisation on an account for direct debit deductions'. I interpret this that the data holder does not have to share direct debits for a closed accounts. If my understanding is correct this would contradict the second last paragraph in the answer: 'For an account that is closed but still eligible for data sharing, the direct debits should be returned. Part of the reason for this is that it assists account switching scenarios which consider direct debits as part of the movement of a consumer's banking relationship to another institution' Could you please clarify if a data holder should or should not share direct debits for a closed account in the light of the Rule mentioned above? The support article recommends it but does not seek to overrule the Rules. The DH should observe their obligations defined by the rules and make a determination whether they provide the direct debit data for closed accounts in those situations.
952 The description for x-cds-client-headers states: The customer's original standard http headers Base64 encoded, including the original User Agent header, if the customer is currently logged in to the data recipient. Mandatory for customer present calls. Not required for unattended or unauthenticated calls. What is the expected functionality we should implement as a DH when validating the x-cds-client-headers in a Banking/Common API call? To be more precise, do we (as a DH) need to validate that the customer's original standard headers are faithfully reproduced here BEFORE we return any CDR data via a Banking/Common API? In other words, is this header acting as a sort of 'fingerprint' which adds another layer of security? If it is supposed to be checked by the DH, what is considered the 'original' standard http headers? Are these the headers present when the ADR requested an access token via the token endpoint? Or are they the headers present during the initial PAR request? Furthermore, which header parameters would you expect us to use in the 'finger' printing exercise? We are allowed to exclude security or custom headers, but we don't really know how the ADR would handle this on their side - they may include a header in their base64 encoding to populate the x-cds-client-headers parameter. In summary, it is unclear if DHs need to validate that an ADR is correctly populating the x-cds-client-headers parameter and whether or not this is required. Can you please advise? The statement in the standards is a requirement on the ADR. There is no requirement on the DH how to use this header. DH's are not required to use this field and would likely be unable to validate the header contents. The purpose of this header is to support behavioural monitoring processes that may (or may not) be implemented by a DH. A request should not be rejected based on the syntax of this header but the header may be used to identify fraudulent activity that could harm the consumer. If the potential for harm is identified then the DH can reject a transaction based on the associated exception in the rules. Note that rejections for harm must be reported on so it is not recommended to do this arbitrarily.
961 seeking confirmation if "alg" is a mandatory claim or not? In the UK specification, for FAPI R/W it is mandatory. the Consumer Data Standards defer to the FAPI upstream standards so it is mandatory where required in the FAPI specs.
963 Are Data Holders obligated to disclose Payees and Scheduled Payments on closed accounts, even though the Payees and Scheduled Payments would no longer be used/valid (since the account is closed)? We think the answer would be "no", but just wanting to check. The Payees API is at the customer level and not the account level so all registered Payees should be returned regardless of account status or account inclusion in the arrangement. For Scheduled Payments, it is expected that a closed account would no longer have any future payments scheduled as this would be logically inconsistent.
967 When a reversal transaction occurs for an ADI Data Holder, the ADI Data Holder can remove both the original transaction, as well as the reversal transaction from Internet Banking, so that the customer no longer sees them in their transactions when viewing their account. The issue with this is that the transaction data for Open Banking is kept in a separate data store, making it difficult to remove the original transaction from the data store when a reversal occurs. The simplest option for us is include both the original transaction as well as the reversal transaction in the data store for Open Banking, e.g. -$20 payment +$20 reversal The disadvantage of this, is that it's not exactly consistent with what the member would see in Internet Banking (both the above transactions would be removed in Internet Banking), however, it's much simpler than trying to remove previous transactions from the Open Banking data store. Is this approach acceptable? There is nothing in the standards that would make the approach you have described as being non-conformant. This space is largely left to the competitive space. While we have continually indicated that alignment to existing digital channels is a convention that should be honoured, in this scenario it is not explicitly required by the standards. It should be noted, however, that the resulting difference between the CDR channel and your normal digital channel may result in consumer experience issues or a potential complaint under the CDR complaint process. You may want to take this into account.

Useful Links

View a number of informative and useful links in the Consumer Data Standards Implementation Guide on Information Links.