ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes (14th of January 2021) - ConsumerDataStandardsAustralia/standards GitHub Wiki
ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes (14th of January 2021)
When: Weekly every Thursday at 3pm-4.30pm AEDT
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
Agenda
- Introductions
- Actions
- CDR Stream updates
- Presentation
- Q&A
- 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.6.0 Published | Link to change log here |
| Standards | Version 1.7.0 Proposed | Link to Project Board with proposed changes here |
| Maintenance | 6th Maintenance Iteration planned for 2021 | Invitations to be sent out early next week |
| DSB Newsletter | To subscribe to DSB Newsletter | Link here |
| ACCC Newsletter | To subscribe to ACCC Newsletter | Link here |
| Consultations | Decision Proposal 149 - Energy Draft Feedback Cycle 1 Feedback is now open on any issue related to draft. This thread will remain open until February 12th 2021. At that time proposed changes will be incorporated and a second consultation cycle will commence. | Link to consultation |
| Consultations | Decision Proposal 145 - Strategy for Reporting & Metrics Feedback is now open for this proposal for an extended period to account for the end of year break. Feedback is planned to be closed on Friday 25th January 2021. | Link to consultation |
| Consultations | Decision Proposal 144 - Amending Consent Authorisation Flow Feedback is now open for this proposal for an extended period to account for the end of year break. This consultation window will close on ( extended to ) Monday, 1st February at 5pm. | Link to consultation |
CDR Stream Updates
Provides a weekly update on the activities of each of the CDR streams and their workplaces
| Organisation | Stream | Member |
|---|---|---|
| ACCC | Rules | Andrew Breeze |
| ACCC | CDR Register (Technical) | Ivan Hosgood |
| DSB | CX Standards | Michael Palmyre |
| DSB | Technical Standards - Banking | Mark Verstege |
| DSB | Technical Standards - Energy & Engineering | James Bligh |
Presentation
Paul Franklin of the ACCC will give an overview of the recent package of rules made on 22 December 2020, and share some thoughts on next steps for the CDR in 2021.
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.
Current received pre-submitted questions:
Answer provided
| Ticket # | Question | Answer |
|---|---|---|
| 48 | Under the Privacy Safeguard 12, one of the corrective actions to be taken is to include a “qualifying statement” with the CDR data. The privacy safeguard guidelines state: “CDR Rule 7.15 requires an entity that receives a correction request to either:• correct the CDR data, or • both:o include a qualifying statement with the data to ensure that, having regard to the purpose for which it is held, the data is accurate, up to date, complete and not misleading, and o where practicable, attach an electronic link to a digital record of the data in such a way that the statement will be apparent to any users of the data.” What is the mechanism by which a data holder can correct data to the data recipients? If by API: Is there any mechanism in the standards to describe such a correction, and, contain the electronic link? If the sharing arrangement was one-off, how should the correction be sent to the Recipient? If the sharing arrangement is recurring, should the corrected record be included in the next bulk refresh/access. How does the recipient know that the record is a correction? If by an out of bands means: What means are acceptable (letter, email, other)? How does the data holder gain access to this mean (eg email address)? Is it in the registry? How could corrected personal data be sent safely by an out of bands means? | CDR Support Portal Article |
| 338 | Im sure this has been asked before but I cant find relevant answer. Under PSG 11 and Rule 7.10 d) ii) a CDR participant must disclose corrected data if requested by the CDR Consumer. How do the Data Standards support this being achieved. I do not believe there is any mechanism to tell the ADR that previously disclosed data has changed. | CDR Support Portal Article |
| 355 | I’m seeking additional guidance please on what to do for that additional field for the scenarios where there is more than 1 current / effective interest rate for that specific account, e.g. PER_TIER interest. If the customer has $25,000 in their account and is receiving 0.2% on the first $15,000 and 0.5% on the next $10,000, what do we put for the additional depositRate field? Are we expected to calculate the effective interest rate as (0.2% x 15,000)+(0.5% x 10,000) = 0.32% and recalculate on a daily basis? This appears very onerous / close to impossible. Could a data standard change be considered instead, to allow more than one value? | Currently you would do the calculation as you suggest and then provide that. Bear in mind, if you don't, and only provide the component parts, then every ADR would have to implement the onerous calculation you describe to be able to simply show the customer their current effective rate. That is why that field was added to the standards. As with much of the standards the choices balance implementation costs and use across all participants. You can, of course, suggest a change in standards maintenance, however. CDR Support Portal Article CDR Support Portal Article CDR Support Portal Article CDR Support Portal Article |
| 407 | Requesting clarification if HoK is required to be implemented for the UserInfo endpoint. | Yes CDR Support Portal Article |
| 419 | Is the account.openStatus attribute of GetAccounts API is supposed to be used for determining eligibility of accounts statuses for Consent flow, such as all accounts that are marked as 'Open' are expected to be available to Customers when they reach Consent flow? Expanding from this, does it mean that only those accounts can be marked as 'Open' which are 'set up in such a way that it can be accessed online'? | the openStatus relates to whether the account is open and can be transacted on, or has been closed by the customer/bank. It is not supposed to be an exhaustive representations of the account lifecycle each bank uses for their accounts (e.g. frozen or suspended). Closed accounts are eligible accounts that should be shown in the consent flow's Account Selection step. Part 3.2 (4) of the Rules lays out the eligibility conditions for closed accounts and related data. Please note there are also phasing considerations for banks listed in Division 6.2 related to closed accounts. Related KB articles: - https://cdr-support.zendesk.com/hc/en-us/articles/900004434743-Offline-accounts - https://cdr-support.zendesk.com/hc/en-us/articles/900003831546-Consent-on-closed-accounts - https://cdr-support.zendesk.com/hc/en-us/articles/900002843943-Expected-API-Behaviour-for-Closed-Accounts CDR Support Portal Article |
| 421 | What is the order of precedence of following scenarios, when deciding the correct error response? - expired/invalid access token - expired/invalid/revoked consent - invalid SP status (Inactive, Removed) - invalid ADR status (Suspended, Revoked, Surrendered) | this is not defined by the data standards and is implementation specific. That said, it would make sense to consider coarse-grained errors first (e.g. validate the ADR status before the SP status, or validate the AT is valid before validating consent). CDR Support Portal Article |
| 422 | I would like to clarify the CDR error codes for following 2 scenarios 1. the value sent as "product-category" query parameter is not a valid product category according to CDS specification (AU.CDR.FieldType.Invalid.Field ?) 2. the value sent as "product-category" query parameter is a valid product category according to CDS specification, but it is not offered by the DH at the moment (AU.CDR.Invalid.Field ?) | If the value provided is not a valid value for a well-defined enumeration, then the HTTP status code would be 400 (Bad Request) because "request has malformed, missing or non-compliant JSON body or URL parameters". If the value is a valid enumeration value however the bank does not support that value, a 422 (Unprocessable Entity) would be most reasonable because "the request was well formed but was unable to be processed due to business logic specific to the request". CDR Support Portal Article |
| 261 | We are seeking clarification on the following scenario: Both Joint account holders provided their nominations on Joint Account A. JAH1 created a data sharing consent on the joint account. JAH2 then revokes their nominations. What should be returned for a generic Get Accounts call? Github post for reference: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/351 | ACCC Answer Where an election has been revoked by JAH B, data must no longer be shared on that joint account (clause 4.3 of Schedule 3). The data holder should not call the ADR’s revocation end point. Data on any other account should continue to be shared. As the ADR is not made aware of the account no longer being shared, the redundancy requirements under privacy safeguard 12 are not triggered. DSB Answer The HTTP status code will depend on the method the account is being requested. If the accountId is provided in the path of the URL then a 404 (Not Found) applies. If the accountId is requested via the request body (e.g. Get Balances For Specific Accounts) then a 422 (Unprocessable Entity) applies. We'll be publishing out updated proposal for error handling in a week or two and this will be a good scenario to review and make sure we are catering for. CDR Support Portal Article |
| 410 | Need clarification on Get Status API fields for the following scenarios– “Updatetime” – ( 1 ) Is the intent of this field is to share date and time when Data holder checks health of all endpoints (periodically every 5 mins as an example, irrespective of the status ) or (2) Date and time when “status” field (OK/PARTIAL_FAILURE/SCHEDULE OUTAGE/UNAVAILABLE) change its state i.e, Date and time at which OK was changed to PARTIAL FAILURE status. If second scenario follows – will “detectionTime” and “Updatetime” be same when status is changed from OK to PARTIAL_FAILURE / OK to UNAVAILABLE. | Regarding your question about the get status API. The API was designed to support scenarios where status is automatically detected but also scenarios where the response payload is manually created. In this context, the updateTime field represents the last time the information being presented was updated, modified or verified. The detectionTime field is when the issue was actually identified. For automatic update these may be the same if the status is updated immediately on detection. The updateTime may then change every five minutes until service is restored. For manual updates when the status changes the time stamps could be very divergent (ie. the outage was detected at 3pm but the status was only updated at 3:15pm). CDR Support Portal Article |
| 408 | Can you please provide clarification for the following scenario in Authorization request when using PAR, this is an issue we are facing with another Data Holder. The scenario is as follows 1. Client makes PAR request using request object including "redirect_uri" 2. Client gets back a request_uri 3. Client makes an authorization request using request_uri. client also includes client_id and scope parameters in the request. Client DOES NOT include "redirect_uri" as a parameter as it was included in the original request object. 4. Authorization server is rejecting the authorization request as "redirect_uri" is not present in the authorization request. Our interpretation is that since "redirect_uri" was supplied in the request object it is not required to be sent again in the authorization request. This is also in line with PAR Can you please provide guidance on this. | You are correct regarding redirect_uri. If the client lodges the authorisation request using PAR, the authorisation server should honour this and not return an error. Section 5.2.2 of FAPI-R (https://openid.net/specs/openid-financial-api-part-1-ID2.html#authorization-server) requires that the redirect_uri must be provided in the authorisation request. If the client is using PAR, then the client has pre-staged the authorisation request. If the client does not use PAR, then the redirect_uri must be present in the request object sent by value to the /authorise endpoint. Regarding the following: 9. shall require the redirect_uri parameter in the authorization request; 10. shall require the value of redirect_uri to exactly match one of the pre-registered redirect URIs; The redirect_uri should not be sent outside of a request object per the CDS spec. This is further clarified in more recent drafts of FAPI Part 2 advanced profile, section 5.2.2 and 5.2.5 (https://openid.net/specs/openid-financial-api-part-2.html). CDR Support Portal Article |
| 411 | Just to confirm, a pending transaction is just for a Visa transaction, where posted could apply to ANY posted transaction on the account (incl cash deposits, direct debits etc). | There are potentially many circumstances where a transaction could be marked as pending depending on the ledger system and payment method. The pending status could potentially apply to any transaction that has been recorded but not yet settled. The application is left to the data holder. CDR Support Portal Article |
| 413 | We understand that for industryCode, the expectation is that if we don't have the organisation's industry code in the ANZSIC format, we don't provide. However, if we only have the ANZSIC code to the 1st level of classification (e.g. A, which = Agriculture, Forestry and Fishing), is it acceptable to provide this? | Consistent with general advice, if you can provide the information in a valid type format then you should. If you do not have enough information to fulfil the schema then you consider the data not held. The usual example is a phone number that only has area code - this does not constitute a valid phone number. For industry code, if you are able to fulfil the standard for an ANZSIC code in one of the published versions then you should supply it. CDR Support Portal Article |
Response pending
| Ticket # | Question | Answer |
|---|---|---|
| 107 | Answer in progress | |
| 139 | Answer in progress | |
| 174 | Answer in progress | |
| 189 | Answer in progress | |
| 196 | Answer in progress | |
| 203 | Answer in progress | |
| 209 | Answer in progress | |
| 214 | Answer in progress | |
| 221 | Answer in progress | |
| 225 | Answer in progress | |
| 232 | Answer in progress | |
| 244 | Answer in progress | |
| 250 | Answer in progress | |
| 256 | Answer in progress | |
| 257 | Answer in progress | |
| 259 | Answer in progress | |
| 261 | Answer in progress | |
| 263 | Answer in progress | |
| 265 | Answer in progress | |
| 268 | Answer in progress | |
| 283 | Answer in progress | |
| 290 | Answer in progress | |
| 291 | Answer in progress | |
| 292 | Answer in progress | |
| 293 | Answer in progress | |
| 299 | Answer in progress | |
| 301 | Answer in progress | |
| 303 | Answer in progress | |
| 308 | Answer in progress | |
| 310 | Answer in progress | |
| 311 | Answer in progress | |
| 312 | Answer in progress | |
| 318 | Answer in progress | |
| 319 | Answer in progress | |
| 321 | Answer in progress | |
| 323 | Answer in progress | |
| 324 | Answer in progress | |
| 329 | Answer in progress | |
| 331 | Answer in progress | |
| 333 | Answer in progress | |
| 334 | Answer in progress | |
| 335 | Answer in progress | |
| 336 | Answer in progress | |
| 337 | Answer in progress | |
| 338 | Answer in progress | |
| 339 | Answer in progress | |
| 340 | Answer in progress | |
| 341 | Answer in progress | |
| 346 | Answer in progress | |
| 347 | Answer in progress | |
| 350 | Answer in progress | |
| 351 | Answer in progress |
Question and answers
| # | Question | Answer/ Action |
|---|---|---|