-
Notifications
You must be signed in to change notification settings - Fork 56
ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes (13th of August 2020)
CDR API Stream edited this page Aug 13, 2020
·
10 revisions
When: Weekly every Thursday at 3pm-4.30pm AEST
Location: WebEx, quick dial +61262464433,785383900%23%23
Meeting Details:
Desktop or Mobile Devices
https://csiro.webex.com/csiro/j.php?MTID=m7c39ee9db5e5892ab35cd0bd7bbf94ce
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
- Primary Australia: +61 2 6246 4433
- Quick Dial: +61262464433,785383900%23%23
- Other Global Numbers: https://conferencing.csiro.au/Call-in.php
- Meeting Number/Access Code: 785 383 900
- Introductions
- Outstanding actions
- CDR Stream updates
- Q&A
- Any other business
Meeting notes
- 5 min will be allowed for participants to join the call.
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.
| Type | Topic | Update |
|---|---|---|
| Questions and Answers | Please submit all new pre-submited questions to [email protected] | New process to triage, assign, track and respond to questions raised by the Community. Questions and Answers can be now be found here: CDR Support |
| Maintenance | Banking Maintenance Iteration 04 |
Key Phase Dates Phase 1: Retrospective and Backlog Grooming - 9th July 2020 commencement. 2 weeks duration Phase 2: Consultation - 22nd July 2020 commencement. 4 weeks duration Phase 3: Approvals and Documentation - 19th August 2020 commencement. 2 week duration Please contact [email protected] for an invite to the series |
| Maintenance | Banking Maintenance Iteration 04 |
Link to Summary Link to Board of changes |
| Standards | Version 1.4.0 Approved! | Approved list of changes is located here |
| Decision Proposal - All | Decision Proposal 135 - November 2020 Consent Obligations: fixes and clarifications | Decision Proposal 135 |
| Decision Proposal - All | Decision Proposal 136 - November 2020 Consent Transition Guidance | Decision Proposal 136 |
| Decision Proposal - Energy | Decision Proposal 111 - Generic Tariff Data Payload | Decision Proposal 111 |
| Event - Workshop | Enhanced Error Handling - Online Workshop 03 - Consumer Experience | Link to register is here |
| Event - Workshop | DSB & ACCC - Data Quality Workshop 01 | Link to register is here |
| Guidance | Joint Account Guidance | Find on the CDR-Support Portal here |
| Action | Change name of the call to be 'CDR Implementation Call' | Effective from 13th of August 2020 |
Provides a weekly update on the activities of each of the CDR streams and their workplaces
- ACCC Rules
- ACCC CDR Register (Technical)
- DSB CX Standards
- DSB Technical Standards - Energy & Banking
- Michael Palmyre will be taking us through the Phase 3 Consumer Experience Report and focusing on the 4th, 5th and 6th rounds of research.
These rounds of consumer research were focused on amending consent and the centered on extending duration, the separation of collect and use, adding and/or removing data clusters and uses, and the simplification of amending consent scenarios without compromising the quality of consent.
Find out more here: https://consumerdatastandards.gov.au/knowledgecentre/reports/reports-cx/phase-3-cx-reports/
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.
Currently received pre-submitted questions:
| Ticket # | Question | Answer |
|---|---|---|
| - | In the CX guidelines, there are requirements for the consent model to be WCAG complaint. For Data Holders, does this apply to only the pre-login Data consent portal (i.e. authenticating customers & capturing authorisation)? Or does the consent model also extends to the Data consent dashboard? | - |
| - | For QnA - is it required to send the x-fapi-interaction-id in the response in the case of an error response, a) if it is present in the request, b) if it is not present in the request | |
| - | On behalf of one of our member ADIs, do you know if certain products can be exempted from PRD oligations if they are going to be remoed from the suite of products offered by the ADI in due course? | Taken on notice |
| - | CDR allows a customer to request for data sharing arrangement information. Page 90 of the rules section 9.5 says "3) A request under this rule must be in the form (if any) approved by the commission for the purpose of this subrule" Q. Is this a physical form? If so, are ACCC going to provide an approved template or would you like each organisation to draft a form for approval? If the later, are there guidelines for how this process will work? | |
| 68 | #296 CX Stream: Use of ADR name and logo in CX: Where the CX designs refer to an ADR name and logo should this be ADR name/logo or where provided - Brand or Software product? The CX should be consistent from consent through to authorisation establishment and management #297 Rules Account Owners added after authorisation. For accounts (typically businesses) an account owner can be added after an account has been opened. If a data sharing consent has been established when only one owner was on the account and subsequently an additional owner was added does the data holder need to stop sharing the data on that account (Phase 1 only single account holder) or pause sharing until the second holder has provided authorisation (Phase 2) If a third owner is added should disclosure of that account then be stopped and the account become ineligible to share. Additionally – Im sure this has been raised before but I could find the status?? The privacy safeguards require Dataholders to provide customers the ability to have their data resent / qualified following a data correction. Is there a mechanism being developed in the standards to support this requirement? |
- |
| 67 | Do we have and updated timeline on results of the consultation on Intermediaries and next steps to reach final rules and standards or when further consultations may be carried out | - |
| 66 | Question relates to Part 7 – Rules relating to privacy safeguards, section 7.2.1. According to this rule, we need to include details of the complaints process on the CDR policy. We are already required by RG165 to provide details of our complaints process online. Just wanted to find out whether the following details need to be spelled out on the CDR policy OR whether we can refer customers to our generic complaints process that include the details below?
Note: This subrule is a civil penalty provision (see rule 9.8). |
- |
| 65 | Are there any Data Sovereignty requirements for a CDR solution developed by a FinTech on behalf of a Data Holder to be hosted in Australian Data Centres (either Cloud Provider or Hosted Solution)? There doesn't appear to be any mention of this in the available CDR specifications. | - |
| 61 | In respect of reporting requirements to the ACCC, the guidance for PRD-only reporting (https://www.cdr.gov.au/sites/default/files/2020-06/CDR%20-%20Reporting%20forms%20on%20product%20data-related%20obligations%20-%20Guidance%20for%20data%20holders.pdf) currently notes that the "Total number of complaints made to you by other CDR participants" uses the definition of a CDR Participant from the Act which specifically calls out Data Holders and Accredited Data Recipients. In view of the fact that the likely majority of users of the PRD APIs will be neither Data Holders nor ADRs, can you please confirm that reporting of complaints from these entities (e.g comparison web sites) is NOT required? This seems odd and I question whether this is the intent of the reporting requirement and whether a drafting amendment is needed? | - |
| - | Per the rule below, I please confirm: 1) whether we need to create a form for customers to request for data sharing arrangement information? 2) If the form needs to be approved by the Commission – what process do we use to get this approved? Rules: Page 90 Section 9.5 "3) A request under this rule must be in the form (if any) approved by the Commission for the purpose of this subrule" Is this a physical form? Do we need to create this OR will the Commission provide us one? |
- |
| 64 | Question re joint accounts. In the rules (Division 4.2, 4.4) we see the text “the data holder must also provide an equivalent consumer dashboard to the other joint account holder.” It is not clear what equivalent means in this context. In the scenario where customer A creates a consent with accounts X, Y, and Z (where account Z is a joint account owned with Customer B), we expect customer A to see the consent with all three accounts in their DH consumer dashboard. What does Customer B see – the full consent with Accounts X, Y, and Z or just the consent with Account Z? Is revocation of consent available to customer B? | Answer can be found here |
| 62 | 4x Question listed in Issue 294 | Answers have been provided in Issue 294 Knowledge article pending |
| 60 | Is there a mandatory combination of scopes that have to be requested? Does the DR need to request the Individual/ Business consumer details as a basis for requesting other scopes, i.e. transaction details? Can a DR request Payees information only without requesting any other scope? |
Answer can be found here Knowledge Article(s) Pending |
| 59 | Hi, Can you please clarify the ErrorMetrics in Get Metrics endpoint. The description on CDS says: 'Number of calls resulting in error due to server execution over time'. Does this include all 4xx and 5xx errors apart from 429? We assume it does not include 429 (too many request) errors as these are part of RejectionMetrics. Thanks | Answer can be found here |
| 58 | There are a few requests raised on github that I’m interested in, could someone please review/respond to these? – https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/274 https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/268 https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/255 |
All GitHub Issues have answers added to them |
| 57 | NPP onus transactions through payID are initially captured as an NPP payments in our digital channels, however, once its identified that payee is within our bank then NPP messages are not created for clearing purposes but payment transaction happens internally within our bank system as a fast payment . whether such transaction qualify as a NPP transaction hence to appear as part of transaction detail response or to throw a 404 error considering such transaction similar to a non NPP transaction? Please note: the transaction still has other NPP details such as extended details, payer, payee information except for service level details - which is applicable only in case of an actual NPP payment message being sent for NPP clearing. I believe this could be a case with some other institutes as well and would be beneficial to understand how to treat NPP ONUS payments for transaction detail endpoint as we will not be able to map a service level (which is only x2p1.01 now but as seen in other conversations this might be upgraded to support other levels). | Currently the extended transaction details requires the 'service' field as a mandatory field. There are a number of maintenance change requests to modify this so that the extended detail is able to support other scenarios. Until the standards are amended, however, any transaction that can not be presented int the transaction detail format successfully (ie. with the mandatory 'service' field populated) should be treated as if it does not have extended detail. The 'isDetailAvailable' field in the transaction list payload should be set to false and a 404 should be presented if detail is requested for the transaction. Knowledge Article Pending |
| 56 | As a data holder, how prescriptive are the CX guidelines as they apply to consent authorisation flow? Do I need to follow the exact process in the guideline or do I have flexibility to order the flow as I see fit and to introduce additional authentication procedures to improve security? I'm trying to determine how precisely I need to follow the consent flow designs and whether I'm allowed to materially change it provided I keep all the key elements or whether was is permissible to change is merely cosmetic in nature (branding, copy, imagery, CTA's, colour etc) | CDR participants have flexibility in how they implement provided the implementation is compliant with the relevant rules and standards. The CX Guidelines are non-mandatory examples of how to put key rules and standards into practice, as well as leading practice recommendations that are also optional. The CX Guidelines are component based to allow CDR participants to combine and deploy elements as required. On authentication and authorisation specifically: whilst the delivery channel for the One Time Password (OTP) used for authentication is flexible, it is non-compliant with the standards to add additional authentication. Rule 4.24 also states that the authorisation flow must not include additional requirements, information, services, or documents beyond those specified in the data standards and rules. These parameters in the rules and standards would prohibit the introduction of additional authentication procedures in the authorisation flow. Knowledge article pending |
| - | This questions refers to Traffic Thresholds for Public Traffic (for product data requests). The only threshold defined for public traffic is “300 TPS total across all consumers (additive to secure traffic)”. This is fine for all consumers, but what about 1 individual consumer? If 1 consumer tries to consume all 300TPS, it could starve others from the service. Can we define lower thresholds for individual consumers? So for example, if 1 IP Address source was to hit our product reference data with 50TPS, we could give them an error… even though we have not yet hit the 300TPS across all consumers, it is obvious that this one individual is doing too much. We propose that the unattended traffic thresholds be applied to individuals querying the public API’s. Is this the intent? | For unauthenticated accounts there is no reliable way to confirm that requests are being made from a single recipient so no recipient specific thresholds have been included. As the unauthenticated data sets are relatively non-volatileand are also highly cacheable the example given would be reasonably considered to be an invalid use of the APIs according to the standards. The recipient would be in breach of their own requirements: https://consumerdatastandardsaustralia.github.io/standards/#data-recipient-requirements. The intent of the standards is that a situation of this nature would reasonably be interpreted as having the form of a DDOS attack and the data holder is entitled to take action to protect their infrastructure. Knowledge article pending |
| 55 | In the CDR specification it states: Each API end point that can return multiple records will stipulate whether pagination is supported for the end point or not. For end points that will return less than a reasonably sized page of results in the majority of circumstances support for paging may not be included. In the case that a Data Holder doesn't support paging for an API does this mean that the page and page-size filters would be ignored by the Data Holder API and that no page links (first, next, pref, last) and meta data (totalRecords, totalPages) would be returned. | Answer can be found here |
| 54 | The CDR Specification only allows enumerated values of "X2P1.01" for attribute service in TransactionDetails. With reference to https://cdr-support.zendesk.com/hc/en-us/articles/900001832346-Get-Transaction-Details-Error-Return where service being empty string would be valid response if extendedData was not available. As we are using the swagger specification published by consumer data standards the models we generate only allow values of "X2P1.01". In this instance should we be modifying the swagger specification to allow enumerated service of NONE: "" so that we can set the service to "". | Discussion can be found here Correction to Knowledge Article here |
| - | We have a feature in our online banking which permits customers to upload an excel file in a specified format with payment to details (accounts and amounts). This supports payment disbursements, typically for payroll. The mechanics of the payment are that there is a single payment made from the customer’s source account (let’s call it account A) to a suspense account (let’s call it Account S) and then the disbursement payments to the specific destination accounts (let’s call them Accounts X, Y, and Z) contained in the excel file are made from the suspense account. Within the BankingScheduledPayment schema there is one object called from and also the paymentSet array. Which of the following three representations would you expect:
We would expect 2, but note that there will never be transactions corresponding to a payment from Account A to any of Accounts X, Y, or Z arising from this process. |
The response to this is similar to many such queries. The handling should be aligned to how the scheduled payment is communicated in your other digital channels. If this is option 2 in your example then that would be appropriate. In addition, if the standards should be amended to incorporate the concept of an optional suspense account so that it is possible to represent the richness of the capability offered the DSB would welcome a change request to that effect which can be opened for broad consultation. Knowledge article pending |
- TBA
| # | Question | Answer/ Action |
|---|---|---|
| # | ||
| # | ||
| # | ||
| # | ||
| # | ||
| # | ||
| # |
Other business
- TBA
- TBA
- TBA