-
Notifications
You must be signed in to change notification settings - Fork 56
ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes (4th of March 2021)
CDR API Stream edited this page Jul 6, 2021
·
4 revisions
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: 785383900@csiro.webex.com
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
- Actions
- CDR Stream updates
- Presentation
- Q&A
- Any other business
- 5 min will be allowed for participants to join the call.
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 contact@consumerdatastandards.gov.au should they have any further questions or wish to have any material redacted from the record.
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 |
|---|---|---|
| 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 underway for 2021 | Read about the Maintenance Iteration - If you would like to join these please reach out to contact@consumerdatastandards.gov.au |
| Maintenance | Decision Proposal 161 - Banking Maintenance Iteration 6 | Link to consultation |
| DSB Newsletter | To subscribe to DSB Newsletter | Link here |
| ACCC Newsletter | To subscribe to ACCC Newsletter | Link here |
| ACCC Newsletter | 3rd of March 2021 Edition | View in browser here |
| DSB Newsletter | 26th of February 2021 Edition | View in browser here |
| Consultations | Decision Proposal 158 - Participant capability discovery This decision proposal pertains to the consultation for a functional discovery mechanism pertaining to the DSB's Future Plan roadmap item published here: ConsumerDataStandardsAustralia/future-plan#5. Feedback is now open for this proposal. Feedback is planned to be closed on 5th March 2021. |
Link to consultation |
| Consultations | Decision Proposal 159 - v1.7.0 Placeholder for the 1.7.0 Release |
Link to consultation |
| Consultations | Decision Proposal 160 - CX Standards This is a placeholder issue for consultation on CX Standards for non-individual consumers, business partnerships, and secondary users. This proposal is not yet ready for publication. This placeholder issue has been opened to gather initial community commentary on the scope and content of the proposal. While the intention is for this consultation to focus on the relevant items raised in Noting Paper 157*, the DSB encourages feedback on any additional CX Standards and CX Guidelines that the community views as required for the purposes of non-individual consumers, business partnerships, and secondary users. *Items 12-14. Item 16 on secondary user withdrawal standards will be dealt with separately. - Non-individual Consumers - Business Partnerships - Secondary users |
Link to consultation |
| Consultation | Decision Proposal 162 - CX Standards | Joint Accounts |
| Consultation | Decision Proposal 164 - Endpoint Metrics | Link to consultation |
| Consultation | Decision Proposal 165 - Brand aware metrics | Link to consultation |
| Consultation | Decision Proposal 166 - CX metrics for Data Holders | Link to consultation |
| Consultation | Decision Proposal 167 - Direct to consumer | Link to consultation |
| Consultation | Decision Proposal 168 - Separate Consents | Authorisation Withdrawal |
| Consultation | Noting Paper - White Label Conventions | Link to consultation |
Provides a weekly update on the activities of each of the CDR streams and their workplaces
| Organisation | Stream | Member |
|---|---|---|
| Treasury | Roles & Functions | Kate O'Rourke & Jodi Ross |
| ACCC | CDR Register (Technical) | Ivan Hosgood & Elizabeth Arnold |
| ACCC | Onboarding | Chantelle Demian |
| DSB | CX Standards | Michael Palmyre |
| DSB | Technical Standards - Banking | Mark Verstege |
| DSB | Technical Standards - Energy & Engineering | James Bligh |
No presentation this week.
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:
| Ticket # | Question | Answer |
|---|---|---|
| 261 | To close this out, we also have a follow up question: when receiving a Get Accounts call, and either: - there's only 1 account on the consent, a joint account, with no active Joint Account nomination; or - there are multiple (and only) Joint Accounts on the consent, none with an active nomination, what should the response be in this scenario? Based on the DSB's response above, should the response also be 422? |
I understand the question correctly then in both situations all accounts that are associated with consent are awaiting consent election from the second joint account holder and the DH cannot share the data for the subject (customer who established consent with the ADR), is that correct? In this situation, 404 or 422 (as applicable) would be correct. Note that this guidance is subject to some change depending on the feedback and outcomes of the Enhanced Error Handling consultation. CDR Support Portal article |
| 548 | For a Data Holder, as per this article on CDS support portal, https://cdr-support.zendesk.com/hc/en-us/articles/900003831546-Consent-on-closed-accounts When a customer closes an account and becomes ineligible for online banking, all data sharing arrangements stand revoked. Could you please clarify: 1) For a customer that has multiple accounts and active data sharing arrangements, if a single account is closed, - Does the active consent authorisation related to only CLOSED account stand expired/revoked? - Since the consumer is still an eligible customer, Should Data Holder continue sharing/disclosing the CDR data for the Closed Account as well ? As per the rule Part 3— CDR data that may be accessed under these rules—banking sector- section3.2, Note 3, "So long as the CDR consumer is eligible to make a consumer data request in relation to a particular data holder, they will be able to make or cause to be made a consumer data request that relates to any account they have with the data holder, including closed accounts (subject to subclauses (4) and (5)) or accounts that cannot be accessed online" |
Where the customer has multiple open accounts with the data holder and closes one of their accounts, the authorisation for the closed account does not immediately expire [as it would e.g. by operation of Rule 4.26(1)(c)]. This is because the CDR consumer remains an eligible consumer [as defined in Schedule 3, clause 2.1(2)(b)]. The data holder is therefore authorised to disclose the CDR data that was the subject of the authorisation, even if it includes CDR data from a closed account [Schedule 3, Clause 3.2(1), note (3)] However, whether the data holder is required to provide CDR data from the closed account in response to a consumer data request depends on whether the data requested is ‘required consumer data’. To determine this, see Schedule 3, Clause 3.2(5). If Schedule 3, Clause 3.2(5) applies to the data, it is ‘voluntary consumer data’ and the data holder may choose to disclose the information (i.e. it is not compulsory to do so). CDR Support Portal article |
| 557 | we would like to understand if we can use value X2P1.01 overlay service when we can't determine the correct value (because currently we don't store this data in our core system) After reading the information supplied on this page ,https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/181, I came to know that there are additional values to consider. |
Some general guidance has previously been given for different scenarios where fulfilling the schema requirements is difficult due to the availability of internal data. The approach is up to the data holder. The DSB isn't prescriptive as the complexities of internal data holder data systems is not visible to us. The options you have, however, are: 1. You determine that you do not have the data to fulfil the extended data schema. In this case you would not provide the extended data and treat the request as a normal transaction 2. Define defaults so that the requirements of the schema can be fulfilled and the data you do have is shared (such as "Not known" as a default value for the extendedDescription field as an example) 3. Raising a change request to add additional flexibility in the schema for your scenario CDR Support Portal article |
| 577 | As per the CDR website – APCA number is an optional value to be returned by the Get transactions for account API. The understanding is that if the data is held then an optional field becomes mandatory to provide in the Open Banking API responses. Investigations have found the APCA number is received in the inbound file for direct entry transactions and it is used for processing but it is not stored in a database. Therefore the APCA number is not part of the transaction data. Given this is an optional field and the data is not held as part of the transaction, please confirm if APCA is still an optional value in this instance. |
An optional field indicates that a response will be valid if the field is not supplied but it is still required that the data be shared if held. In this case apcaNumber is labelled as optional and it would appear that you are not holding the data. In this case it would be valid to respond without the apcaNumber field populated. CDR Support Portal article |
| 595 | For closed loan accounts, nextInstallmentDate will not be available though spec mandates. Due to this, our implementation intercepts Closed LoanAccounts responses. Same issue had been raised by other banks and can you please advise when we can expect an update to spec to remediate this? https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/150 For testing to continue, we have temporarily set the nextInstallmentDate to loanEndDate |
The approach you outline seems reasonable. It would be schema compliant and offers a standardised approach for your responses. CDR Support Portal article |
| 599 | We would like to clarify the below aspect. For a sole trader, what's the 'GetCutomer' API response a Data Holder need to supply? Person or Organization details or both? | This is up to you as the data holder and you should align with your existing treatment in existing digital channels. If you treat the customer as a business with an agent you should respond as an organisation. If you treat the customer as an individual you should respond as a person. CDR Support Portal article |
| 600 | Referring to https://cdr-support.zendesk.com/hc/en-us/articles/900004490446-URI-structures I note that there are 4 different types of end URIs Unauthenticated Resource URL: Eg: http://openbanking.api.bankname.com.au/cds-au/v1/banking/products Authenticated Resource URL: Eg: http://openbanking-secure.api.bankname.com.au/cds-au/v1/banking/account Unauthenticated security profile URL: Eg: http://openbankingidp.api.bankname.com.au/.well-known/openid-configuration Authenticated security profile URL : Eg: http://openbankingidp-secure.api.bankname.com.au/arrangements/revoke How do these URL's represented in GetDataHolderBrands API response? |
"publicBaseUri": is the base path for all the public resource APIs including Get Products, Get Status and Get Outages "resourceBaseUri": is the base path for all protected CDR data APIs such as Get Accounts, Get Customer, Get Transaction Detail etc. "infosecBaseUri": is the base path for all InfoSec URLs CDR Support Portal article |
| 610 | According to CDR the definition of a Payee - description is the description of the payee provided by the customer. How is this different to a Payee Nickname and can you please provide an example? and if it is the same, why is one considered mandatory and the other not? | During the initial consultation some banks indicated that the allow the customer to label a payee and also provide an additional free form text field with more information. Other banks indicated that the only allowed the customer to label a payee with a single free form text string. This was highly dependent on the CX they offered their customers in existing channels. The schema was therefore designed to accommodate both standards but not force a data holder to change their existing channels to comply with the schema. In summary, if you allow a customer to specify a short name and a longer description for a payee you should populate both fields. If you only allow a single label to be defined you should only populate the mandatory field. If you do not allow the user to define any value you should determine one or more default values to supply in the mandatory field. CDR Support Portal article |
| 612 | What constitutes as a Payee? Previous CDR response was: The general rule of thumb in cases of ambiguity of this nature is to align the Consumer Data Right data with the data presented in existing digital channels. If the customer cannot see these payees in internet banking then presumably they would not be registered payees by the customer. Under this assumption it would be valid to leave them out. Question: You use the term "registered payees" above in your response. Is it only Payees that are registered for NPP that are considered in scope for Payees or is a Payee any recipient of a Payanybody, Bpay or International Transfer? |
the latter would apply. Payees includes saved payees in a customer's address book which may include BSB and account numbers, not just PayIDs. CDR Support Portal article |
| 616 | Can you please explain what you mean by concurrent consent? What is it? What problem does it solve? When will it be mandatory? Are there changes to the standards to accommodate it? I can't find anything about it on the standards page nor in Zen desk which is useful for me to get some context around what is "Concurrent Consent". |
concurrent consent allows the same ADR software product to establish more than one active consent with a Data Holder on the consumer's behalf. The purpose is to allow consents with different scopes, use cases or purposes to be established under one ADR application so that ADRs can correctly observe the Data Minimisation principle. This is achieved technically through the establishment of separate CDR Arrangement IDs for each individual consent. These requirements were introduced into the standards for compliance from November 1st 2020 - noting that for most non-majors that would mean a July 1st 2021 compliance date when they go live with consumer data sharing. CDR Support Portal article |
| 617 | When will non-majors need to support the ability to amend consent? We currently think this needs to happen by Nov 2021. My understanding is that the PAR endpoint will allow an ADR to initiate a process where the user can amend their consent. Can the user amend their consent from the Dashboard? What fields on a consent record can be amended? Duration, Scope, Associated Accounts etc? Are there any CX screens showing what a users 'amending' consent journey? |
Regarding your questions about amending consent. The standards do not actually support amending of a technical consent. Technically it supports the replacement of an existing consent with a new consent under the same arrangement. This means the following: - The new consent can be completely different. All aspects are able to be changed because it is technically a new OAuth consent. - For the new consent to be associated with the existing arrangement PAR needs to be used and the arrangement ID needs to be passed - The same consent flow, including the same screens, are required. There is currently no facility for simplified amendment - The ADR can initiate the consent flow from wherever they like in their experience including the dashboard The timeframe for all designated data holders in the banking sector to be compliant is not clear as it is possible that individual exemptions may be requested and granted. |
| 618 | From our reading of the standards, we have identified the following fields which need to undergo the ID Permanence translation. Can you please confirm this is correct? Get Accounts (Response Field: accountId) Get Bulk Balances (Response Field: accountId) Get Balances for Specific Accounts (Input Parameter: accountIds, Response Field: accountId) Get Account Balance (Input Parameter: accountId, Response Field: accountId) Get Account Detail (Input Parameter: accountId, Response Field: accountId) Get Transaction Account (Input Parameter: accountId. Response Field: accountId, transactionId) Get Transaction Detail (Input Parameter: acccountId, Response Field: accountId, transactionId) Get Direct Debits for Account (Input parameter: accountId, Response Field: accountId) Get Bulk Direct Debits (Response Field: accountId) Get Direct Debits for Specific Account (Input parameter: accountIds, Response Field: accountId) Get Scheduled Payments for Accounts (Input parameter: accountId, Response Field: scheduledPayementId, accountId) Get Scheduled Payments Bulk (Response Field: scheduledPaymentId, accountId) Get Scheduled Payment for Specific Accounts (Input parameter: accountIds, Response Field: scheduledPaymentId, accountId) Get Payees (Response Field: payeeId) Get Payee Detail (Input parameter: payeeId, Response Field: payeeId) |
We can confirm that the IDs you list (accountId, transactionId, scheduledPayementId and payeeId) are all subject to the ID permanence rules. Also, we can confirm that the endpoints you list do use the IDs you have also listed. We have not gone through the whole spec to determine if you have missed anything though. CDR Support Portal article |
Updating the table below - if your question/ ticket has not received a response yet the team continues to work on a response. We do apologise for the delay on some tickets, the teams are doing their best to get to everyone's questions.
| Ticket # | Question | Answer |
|---|---|---|
| # | Question | Answer/ Action |
|---|---|---|
| Organisation | Description | Link |
|---|---|---|
| OAIC | Main landing page for the Office of the Australian Information Commissioner and the Consumer Data Right | Link |
| DSB | CX Artefacts - The CX Guidelines provide optional examples of key requirements and recommendations to help organisations build best practice consent models. CDR Participants should also refer to the CDR Rules, data standards, and privacy guidelines for a complete view of obligations to facilitate compliance. | Link |
| DSB | Consumer Data Standards Main Page - | Link |
| DSB | The Consumer Data Standards - The technical standards for the Consumer Data Right | Link |
| DSB | The Banking Product Comparator - a demonstration of Product Reference Data from Data Holders as part of the Consumer Data Right | Link |
| ACCC & DSB | The Consumer Data Right Support Portal Knowledge base for the Consumer Data Right covering Rules through to Technical articles and questions |
Link |
| ACCC | ACCC Main focus area/ landing page for the Consumer Data Right | Link |
| ACCC | Register Standards | |
| ACCC | Consumer Data Right - Main Portal |