Skip to content

ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes (8th of October 2020)

Jump to bottom
CDR API Stream edited this page Oct 8, 2020 · 9 revisions

ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes (8th of October 2020)

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: 785383900@csiro.webex.com

Phones - AUDIO ONLY

Agenda

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

Meeting notes

Introductions

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

Recording

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.

Actions

Type Topic Update
Standards 1.5.1 Published Link to change log here
Maintenance 5th Maintenance Iteration underway List of scope and agenda(s) can be found here
Maintenance Next week's 5th Maintenance call will be moved to 2pm AEDT Thursday 15th of October 2020,originaly scheduled for 2pm AEDT Wednesday 14th of October 2020 Community to take note, update to invite to be sent shortly
Decision Proposals Decision Proposal 112 - Usage Data Payloads Link to Decision Proposal 112
Decision Proposals Decision Proposal 114 - Account Payloads Link to Decision Proposal 114
DSB Newsletter To subscribe to DSB Newsletter Link here
ACCC Newsletter To subscribe to ACCC Newsletter Link here
Banking Product Comparator For who wish to publish their endpoints on the Banking Product Comparator Tool we have put together some tips and simple instructions to get you going Check out the guide here at the CDR Support Portal
Request for clarification These are to be moved to the CDR Support Portal from Consumer Data Standards Maintenance GitHub Current requests will be answered and closed out, for new requests - we ask you raise these via the form here or via email to support@cdr-support.zendesk.com

CDR Stream Updates

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 - Banking
  • DSB Technical Standards - Energy & Engineering

Presentation

Conformance Test Suite (CTS) Update
Presented by Jason Pathmanathan (ACCC)
Slides can be found here

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:

Response pending

Ticket # Question Answer
173 Appreciate if we could get some answers to these github issues.
Expectations when a consumer closes their account/relationship with an ADR
Issue 313 		-
177 Hi – Just looking for an update on the required approach for use of ADR/brand/software product names and logos as requested through these issues. As the non-majors progress their builds it is becoming increasingly important to have direction on this to ensure consistency across the ecosystem.
https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/222
https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/296 		Taken on notice
189 I have been unable to find guidance on when a CDR Policy must be made available by Data Holders. A literal reading of the regulation would suggest that it should be made available as soon as any data sharing occurred (i.e 1 October for most data holders). However, the vast majority of a typical CDR Policy is only relevant for customer data sharing. Can you confirm that a Data Holder does not need to provide a CDR Policy until they begin customer data sharing? Taken on notice
190 I am seeking guidance on how "wholesale" products are handled in the CDR. In this context I'm talking about products that are sold via alternative channels, but branded by the Data Holder. Examples would be term deposits sold through marketplaces such as Australian Money Market or Cashworkz, or loans sold through brokers. In these cases, the terms and conditions may differ from directly sold retail products. As the channels are generally not ADIs and therefore not Data Holders, I would assume any obligations would fall back on the product originating ADI. It's unclear if these products are "publicly available" under the CDR definitions as they are not sold directly by the ADIs concerned. Additionally, the terms and conditions can vary across the re-sellers and so if required, how should they be exposed in the PRD APIs? A separate entry for each re-seller, or a generic entry with, for example, no rates given? Any additional guidance around "wholesale" products sold through alternate channels would be appreciated. Thanks. Taken on notice
192 We, are looking for clarity on requirements that are compulsory for account & transaction data on Phase 1 & 2 products, specifically for joint accounts. We understand that ACCC provided the Joint Account Guidance where scenarios are outlined. The question we have is on the status of Joint Account Guidance document – are the requirements derived from this document compulsory to implement, or only suggested but not compulsory? Specifically the next two requirements – are they compulsory to implement for account & transaction data on Phase 1 & 2 products release:
1. ‘Pause’ via JAMS (Scenario 4a & b)
If one of Joint Account Holders removes an election via JAMS for an account that is already in an active sharing arrangement with 3rd party, authorisation should not be withdrawn, but the data sharing for that account should be stopped. Removal of election via JAMS for joint account does not cause removal of this account from authorisation. It only caused the data sharing to stop for this account.
2. Resume via JAMS (Scenario 4c & 7)
After the requirement above, if both Joint Account Holders elect though JAMS for this same joint account that is ‘paused’ in an active sharing arrangement to be shared back (meaning this account is marked back as ‘available for data sharing’), the data sharing should continue as this account was never removed from authorisation in the first place.		 Taken on notice
195 Could you please provide clarity about what “a product that is publicly offered” (under the ACCC CDR Rules) and “products that are currently openly offered to the market” (under the CDR Standards for Banking APIs) means when it comes to sharing required PRD. Specifically, if a phase 1 product is currently only offered by direct invitation to existing customers (i.e. not through online application channels), is PRD required to be shared? Taken on notice
196 https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/329
https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/330 		Taken on notice
202 Seeking clarification on withdrawal of authorization at the Data Holder end.
Is the Data Holder mandated to provide an alternative for authorization withdrawal beyond the Consumer dashboard?
The rules (shown below at the end of this email) states two options using the "or" keyword implying that one or the other is adequate.
I would be well within the guidelines by providing this capability only in the Consumer dashboard.
However, I was wondering what if the Consumer Dashboard channel (say Internet Banking has an outage (not a common occurrence these days, however, we have seen these issues in the past). Also, Internet Banking can have scheduled maintenance say for 5-6 hours (e.g once a year scheduled maintenance), and if the consumer wants to withdraw authorization during this period they would be inconvenienced.
Would love to hear comments and thoughts from the experts at Data61 and ACCC.
The rules state the following:
4.25 Withdrawal of authorisation to disclose CDR data and notification
(1) The CDR consumer who gave, to a data holder, an authorisation to disclose particular CDR data to an accredited person may withdraw the authorisation at any time:
(a) by using the data holder’s consumer dashboard; or
(b) by using a simple alternative method of communication to be made available by the data holder for that purpose		 -
204 Clarification on Data holder providing link to CDR policy: This question relates to Part 7 – Rules relating to privacy safeguards, section 7.2.1.
According to this rule, a Data Holder (DH) will need to include details of the complaints process on the Consumer Data Right (CDR) policy..
The question is at which stage (wireframe) is the CDR policy expected to be shown on Data holder side.
As per the CX guidelines, the CDR policy is only visible on the Data recipient Consumer dashboard as attached.		 -

Answer provided

Ticket # Question Answer
175 Quick question around handling of x-v and x-min-v headers in couple of scenarios.
Where x-v = a supported version, and x-min-v is sent in the request, however a blank value is sent like shown below -
x-v = 2
x-min-v =
What should the expected response be - 200 OK or a failure response?. If the response should be a failure response, should it be a 406 or 400 response code? We have noticed 3 out of the big 4 (and few other non majors) responding differently to this scenario, and we were hoping to clarify the correct way to handle this.
Another rare scenario (however still possible I guess), where x-v or x-min = 0 or a negative integer, should the error response be 406 or 400 in this instance.
If the mandatory header x-v is not present in the request at all, should the response be a 406 or a 400 in this scenario? We are under the impression that this is a 400 bad request, however would like to clarify.		 Answered on call - knowledge article being created
178 Do we have any metrics and other info that shows what's working well and what is not?
There is no information available in the public domain.
Is there a plan to publish something similar to API performance that is published by the folks in the UK?
https://www.openbanking.org.uk/providers/account-providers/api-performance/ 		Idea taken on notice
182 The future date obligation date for PRD Phase 2 compliance is 1/2/2021 and version 3 PRD APIs are by 28/2/2021.
1. Can you please confirm that we can compliantly implement and support both v2 and v3 PRD APIs as at 1/2/2021.
2. Is there a proposed date to obsolete the v2 PRD APIs?		 Q1. Can you please confirm that we can compliantly implement and support both v2 and v3 PRD APIs as at 1/2/2021.
Answer: Yes. v3 for Get Product Details is to be made available no later than the end of February so you can go live with v3 any time earlier than this.
Q2. Is there a proposed date to obsolete the v2 PRD APIs?
Answer: We don't have a proposed obsoletion date for v2 as yet. We will look to provide guidance on this shortly.
184 Can you please advise when the Register might be made available for testing purposes to the Tier 2 banks for the July 2021 release so that we can factor this into our planning? Appreciate this might be early, but some visibility on indicative timeframes would help with our planning. Thanks. The ACCC does not currently have plans to make the CDR Register available for testing. Data Holders due to commence consumer data sharing in July 2021 will be able to access the Conformance Test Suite (CTS) once they commence On-boarding where tests to confirm connectivity with the CDR Register can be executed.
We encourage you to subscribe to ACCCs CDR Newsletter for further updates on On-boarding.
185 What would the purpose of this entity be for? Is the only scenario we would use this, if a consumer had a scheduled payment set up once every 28 days and therefore we return this entity with the last weekday? This scenario could also be returned under the BankingScheduledPaymentInterval entity - therefore, do we even need to use this entity? Are there any other scenarios we would use this entity for? When payment schedules were being consulted on some banks indicated that they offer payment schedules where a payment can be schedule on the last week day of a period (last Friday of the month, last Monday of the quarter, etc). This structure was included to allow for these schedules to be represented.
If a Data Holder does not support such schedules then you do not need to use the structure.
191 Could you please elaborate on what is meant by the agentRole? Is this referring to the job title of the individual or is it their account relationship type, e.g. signatory, business owner etc? For the record, agentRole is a free form text field to be populated by the Data Holder and is meant to indicate the capacity that the individual is operating when sharing the data of the organisation. Whatever role or function would be shown in your digital channels would be appropriate. A reasonable default value would be fine if such a field is not routinely captured.
193 Issue: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/327 Firstly, your diagram appears to be accurate to me.
In response to your questions:
Q: Transaction per second breakdown at the API end point level: For an example: Under the 300 TPS for secured calls, 50 TPS per data recipient with 10 TPS per Customer for customer present scenario, there are maximum transaction traffic from 6 ADRs, 30 customers per second to be supported. Are there any guidelines on how the TPS throttling break down into High Priority, Low Priority individual endpoints? Or is it to be implemented at DH's discretion? Same applies to unattended low traffic and public calls.
A: The TPS thresholds are split by authenticated and unauthenticated but not by end point performance classification. For the purposes of TPS all invocations are considered equal. If a TPS threshold is breached how a Data Holder manages traffic shaping is up to them.
Q: Can you give some insight in to how this was tested (300 tps ceiling threshold) during the industry testing phase with the big4? During those tests did they have any preferred transaction mix of APIs?
A: This was asked at the last implementation call. My understanding is that performance testing has been left to Data Holders to manage for themselves.
Q: Can CDS team confirm that unattended API calls during high traffic period does not have any performance NFRs and only best efforts? This is not explicitly mentioned in the standards, but believe confirmed in the forum.
A: That is correct. This is specifically to encourage ADRs to make unattended calls during low traffic periods.
I have also responded to the CBA request for clarification you linked to.
197 Could you please advise if the lastUpdateTime field relates to the information in the CommonOrganisation entity or is it the last time any information on this organisations account / profile was updated, which could be information that is not included in this entity?? It refers to the time the customer last updated any details contained in this CommonOrganisation response structure, not the last update time for information that is unrelated or not represented by this structure.
198 Guidance required from Data61 –
V1.4.0 introduced a new feeType of variable in the BankingProductFee schema. Could you please clarify if this new feeType is applicable ONLY for version 3 (Get Product Detail API) or for version 2 also? More detail below
Problem statement: As a Data holder, in our case, the ‘variable’ feeType is applicable to our Home loan product suite and our data sharing obligations commence (for this product) in Feb 2021 which is in line with when version 3 needs to be implemented. However, considering we would need to support version 2 as well simultaneously, we would like to get guidance on how we should represent these ‘variable’ fees in version 2.
If we represent these fees with any of the other enumerated values other than variable, then based on the standards, we would be expected to provide a value in at least one of these conditional fields – amount, balanceRate, transactionRate, accruedRate, and unfortunately none of these additional fields are applicable for these fees. (For example, Search fees or Govt Fees as these differ by state)
Please provide guidance around which option mentioned below we should go with, in order to be compliant from a Rules and Data standards perspective.
Use ‘variable’ feeType in version 2 and 3 – Guidance required on whether this feeType is acceptable in version 2 Use ‘variable’ feeType in version 3 and classify the same fee as another feeType in version 2 – Guidance will be required on value to be provided in one of these fields as none of them are applicable for this fee - amount, balanceRate, transactionRate, accruedRate,
Use ‘variable’ feeType in version 3 and NOT provide/send this fee in version 2
Do not provide this variable fee type in both versions		 That's correct the feeType=VARIABLE applied in Get Products Detail v3 but not v2.
This change was introduced to accomodate at-cost fees. I would assume if the fee is an at-cost fee and you wouldn't be able to express it under one of the other feeTypes. Because feeType is mandatory, it would mean these fees should be excluded in v2 but included in v3.
199 Hoping to clarify this with Data61 around versioning of API/schemas -
In V1.5.0 of the standards released on 16/9/20, a change was introduced to include occupationCodeVersion and industryCodeVersion into the CommonPerson and CommonOrganisation schemas respectively. However, the Get Customer API version remains unchanged at version 1 and so is the schema version.
Would like to understand if this is correct? If yes, would like to get clarity on what type of change will warrant a change to the version of the API and/or schema.		 Yes, the API and model versions did not change with the introduction of occupationCodeVersion and industryCodeVersion in v1.5.0 of the standards.
The reason for this was that the changes were considered non-breaking. There are no ADR implementations using customer end points yet as they haven't yet been exposed by any Data Holders and the new fields are optional with an assumed value if absent that matches the expected behaviour of the previous version of the APIs.
201 In the Noting Paper of GitHub #136, the following is described in relation to extending an existing consent arrangement for customers.
Data Holders must revoke any existing oAuth tokens associated to the “cdr_arrangement_id”. Regardless of whether or not a Data Holder physically represents the exchange as revoking one consent and creating a new consent the end result should be the full replacement of the active authorisation related to the “cdr_arrangement_id”.
    Please clarify:
    1. Is the statement allowing one DH to revoke previous consent and creating a new one? And another DH to revoke previous refresh tokens and creating new refresh tokens but not creating a new consent?
    2. MUST the DHs
      1. notifying DRs via CARE endpoint always for both cases above? Or
      2. notify DRs via CARE endpoint only when the consent is revoked but not when only the refresh token is revoked? Or
      3. not required to notify DRs via CARE at all?

    Furthermore, ADRs have the obligation to notify customers with Consent/Revocation Receipts for new/revoked consents. Is any of the actions above constitute as new/revoking consents? Assuming the answer is yes, is the below interpretation correct for #2?
    a. Notify customers with revocation receipt for previous consent and new consent receipt for new consent (with possibly new receipt being received before revocation receipt)
    b. Notify customers with revocation receipt only when CARE is called by DHs and a new consent receipt is sent all the time
    c. Only new receipt is sent to customers
 Q: Is the statement allowing one DH to revoke previous consent and creating a new one? And another DH to revoke previous refresh tokens and creating new refresh tokens but not creating a new consent?
A: The statement referred to was in the noting paper which was provided as clarification (like these responses). The actual part of the standard that us applicable is:
If a data recipient provides the cdr_arrangement_id claim in the request object to the data holder's PAR End Point, the data holder MUST revoke any existing tokens related to the arrangement once the new consent is successfully established and a new set of tokens has been provided to the data recipient.
How this is technically implemented in their system is entirely up to the Data Holder. I believe this was the intent of the statement in the noting paper.
Q: MUST the DHs
a. notifying DRs via CARE endpoint always for both cases above? Or
b. notify DRs via CARE endpoint only when the consent is revoked but not when only the refresh token is revoked? Or
c. not required to notify DRs via CARE at all?
A: The answer is 'c'. The DH only needs to notify the ADR of a revocation if it was initiated on the DH side (by form, phone or dashboard, etc). If it was initiated by the ADR there is no need to notify them.
Q: Furthermore, ADRs have the obligation to notify customers with Consent/Revocation Receipts for new/revoked consents. Is any of the actions above constitute as new/revoking consents? Assuming the answer is yes, is the below interpretation correct for #2?
a. Notify customers with revocation receipt for previous consent and new consent receipt for new consent (with possibly new receipt being received before revocation receipt)
b. Notify customers with revocation receipt only when CARE is called by DHs and a new consent receipt is sent all the time
c. Only new receipt is sent to customers
A: Until the rules change this process is no different to a manual revoke and manual re-establishment of consent. The ADR should inform the consumer according to the same requirements as if they consumer manually revoked and re-established consent. It should be noted that this also applies to the deletion/de-identification election.
203 Future Dated Obligations: The future date obligation date for PRD Phase 2 compliance is 1/2/2021 and version 3 PRD APIs are by 28/2/2021.
Risk based Scenario: One of the key items addressed by version 3 is the introduction of Fee Type “variable”, to be used for Fees that are not fixed, and charged “at cost” by third parties.
At Cost fees are incompatible with version 2 of the standards, and create a scenario where “workaround” to be used within the standards by publishing at cost fees with a $ amount which is incorrect. This could be potentially misleading to the consumer.
· Seeking guidance as a pragmatic approach might be to extend the ACCC obligation to align with the DSB obligation, so that we could go-live once, with version 3 supported, at the end of February		 The reason for retaining version 2 of the standards is that some clients have already implemented to this standard. Any ADR that is specifically relying on the fee structure to the degree that this issue is relevant will be motivated to upgrade to v3 as soon as possible but not all users of the APIs are using all of the data. There are a variety of use cases.
For this reason the DSB prefers to maintain support for older API versions for a period of time.

Notes

  • TBA

Question and answers

# Question Answer/ Action

Other business

  • TBA

Appendices

  • TBA

Next Steps

  • TBA

Getting Started

Meetings

Maintenance Iterations

CDR Implementation Call

Clone this wiki locally