ACCC & DSB Data Holder Working Group Agenda & Meeting Notes (2nd of July 2020) - ConsumerDataStandardsAustralia/standards GitHub Wiki
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.
Type | Topic | Update |
---|---|---|
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 |
Decision Proposal - Energy | Decision Proposal 110 - Additional Account Holders | Decision Proposal 110 |
Decision Proposal - All | Decision Proposal 119 - Enhanced Error Handling Payload Conventions | Decision Proposal 119 |
Decision Proposal - All | Decision Proposal 120 - CDR Error Codes for Enhanced Error Handling | Decision Proposal 120 |
Decision Proposal - All | Decision Proposal 121 - Application of existing HTTP Error Response Codes to Enhanced Error Handling | Decision Proposal 121 |
Decision Proposal - All | Decision Proposal 122 - Extension of Supported HTTP Response Codes for Enhanced Error Handling | Decision Proposal 122 |
Question | Confused. Do data holders also have to be accredited before getting the CDR logo for consent flow? (ie. specifically authentication and authorisation process) | Data Holders are not required to be accredited; however they must be registered and commence onboarding to gain access to the CDR Logo. |
Question | 4. Is there a specific requirement around displaying account details (BSB/account number) in full in the consent/authorization flow or can a DH show these details masked? | The rules require account numbers to be shared unless they are required to be masked by law or in accordance with applicable standards or industry practices. Technical requirements exist to mask and in some cases un-mask account numbers in various payloads. Beyond these requirements, showing account numbers in plain text is a policy decision for ADRs and DHs. The CX Guidelines take a conservative approach and provide an example of masked account numbers in the authorisation flow (see pp78-82 in the CX Guidelines), but this is not a requirement and no standards exist that specify this. |
Question |
Regarding the pushed authorization request endpoint which needs to be exposed by DH. The RFC states that the endpoint needs to be protected with authentication The standards documentation doesn't mention how this endpoint will be protected. We need to understand if there will be an access token issued though client credentials grant with client assertion JWT and then use this access token for calling pushed auth. request endpoint. If so, what would be the scope that would be used to get access token using client credentials grant? |
Issue 241 |
Question | Confirmation required – If an ADR chooses to invoke the DELETE operation on the Registration endpoint for a clientId, then this has the same result as the registry setting a software product status to “Removed” i.e. All consent agreements for the software product involved are revoked. | Issue 251 |
Question |
where an uaccredited entity is the initial recipient of consumer requess/ consents that it is then passed onto a ADR or its outsouced provider what is the initial compliance responsibility and who is responsible and then 2. where the ADR receives data from an ADH but then shares consumer requested data to the downstream entity re above question same applies for cancellation or renewal of consent. our view they stay with the accredited ADR who would then be responsible through contracts and third party management for the initial entity and anyone they provide the data. . appreciate confirmation |
ADRs are liable for all acts/omissions of their outsourced service providers. The CAP arrangement draft rules that the ACCC is currently consulting on have a different liability framework – because both parties are accredited in their own right. This will be discussed further at the upcoming workshop. |
Question | Will there be a formal definition of direct debits and scheduled payments forthcoming by the ACCC before November, seeing as these terms are in the CDR rules? At present the CDR standards definition are somewhat light and open to interpretation. | The terms are intended to have their ordinary meaning, as commonly understood by industry and customers, and in connection with Internet banking applications. A direct debit being an automatic transfer of money from one customer’s account to another account, and a scheduled payment being a payment that is scheduled for a specific date. If there are particular examples of instances that might be open to interpretation, please raise them in the DHWG. |
Question | Question for ACCC - Can Non Major ADI's share Product Reference data on Phase 2 products prior to 1 Feb 2021, if they are ready? Would this trigger any obligations under the concept of 'voluntary participating ADIs' and trigger any changes to other swim lane obligations (for PRD phase 3 and/or Consumer data)? | Early sharing of PRD is encouraged, and non-major ADIs are able to share product reference data early without this triggering any changes to their other data sharing obligations. The ACCC intends to remove the concept of voluntarily participating ADI from the rules. An updated version of the phasing table is available here. |
Question | If a data holder has a document in PDF, say a payslip that a borrower provided as part of a loan application, is that "in digital form" for CDR purposes? | The data held in digital form that must be shared is data which is in a format that could be shared under the standards. As the standards do not support the sharing of PDFs, the ACCC does not expect DHs to share PDFs, nor does the ACCC expect DHs to convert PDFs into a format that could be transferred under the standards. |
Question | Hi, just a quick clarification on corporate accounts. They would be put under the umbrella of joint accounts? | The ACCC is developing rules to bring in corporate and more complex accounts and will be consulting on draft rules in the future. |
Question | This question is further to the answer provided by the ACCC on PRD and retail Vs Wholesale product data. Just to clarify, for PDR, the expectation is that it only covers products available to Individuals, and there is no expectation to make available products used by Large corporates/wholesale products. E.g. Credit cards used by individuals are required, but Credit Cards/ Charge Cards used by Large Corporates are not required for Phase 1 PRD. | The PRD that is expected to be shared is not limited to only products offered to individuals. For example, several of the products listed in Phase 1, 2, 3 are business specific (e.g. a business overdraft). Provided the product is generally known as the type described in Phase 1, 2, 3 and publicly offered, it must be shared. The ACCC considers publicly offered to mean products that are generally advertised and have terms or conditions that are subject to low levels of negotiation, if any (i.e. standard form contracts). Often this will align with products available through a bank’s retail operations, rather than its wholesale operations, however, it could include business products that are generally available with standard terms and conditions to ‘wholesale’ (or, business) clients. Publicly offered does not mean available to the public at large, because eligibility requirements may apply. |
Question | quick clarification on the business accounts - are individuals who hold corporate cards (organisation is liable for credit but the card is in the individual's name) in scope for CDR? | A CDR consumer is eligible with respect to a particular data holder if the consumer is an individual (18 years or older) who is the account holder of at least one account with the data holder that is open and set up in such a way that it can be accessed online. This will therefore include individually held retail accounts as well as some small business accounts (for example, accounts held by sole traders). Provided the individual in question is the account holder (and not the company) – they are in scope. |
Question | How are joint accounts with more than 2 account holders handled? | Currently, the rules only cover joint accounts held in the name of two individuals. The ACCC will consider joint accounts with more than two account holders as part of the development of rules for more complex accounts. |
Question | Can you please conmfirm the go live date of the ACCC registry? Will there be a mock or pre-prod env for testing? | The CDR Register is live. The ACCC is working on a Test Strategy that will replace the Assurance Strategy used to inform Industry Testing. When information is available it will be released via the CDR Newsletter. |
Question | Can non-major banks whom are not going live till July 2021 obtain an early read only access to the Register in order to verify their internal solution? | The ACCC is working on a Test Strategy that will replace the Assurance Strategy used to inform Industry Testing. When information is available it will be released via the CDR Newsletter. |
Question | Is the 2-3 months required for DH to register what you want? We would want to maximise the period that we have access to the CTS. Can we start the process say 5 months out from our go live so that we get a good three months of testing time.... | The ACCC is working on a Test Strategy that will replace the Assurance Strategy used to inform Industry Testing. When information is available it will be released via the CDR Newsletter. |
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
- 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.
Currently received pre-submitted questions:
# | Question | Answer |
---|---|---|
#1 |
|
- |
#2 |
|
- |
#3 | It is our assumption based on the rules that sharing duration of any consent cannot be greater than 12 months even in the case of a consent renewal/linked consent (through use of CDR_arrangement_id). Can you please confirm the appropriate behaviour as DP 99 is a little unclear on this front? | - |
#4 | It is our assumption that the scope and the account list between linked consents (via CDR_arrangement_id) can differ between the two consents. Can DSB please confirm? | - |
#5 | What would be the error code provided by the data holder if an unauthorised tpp submitted a data request | - |
#6 | In the CX guidelines, it mentions "pending" consents. What is the meaning of "pending consents" pg. 106 |
The CX Guidelines state that ‘Data holders SHOULD prioritise information that is important to consumers. This MAY include using tabs (e.g. active, pending, archived), or presenting key details up front, such as when consent was granted.’ The pending example does not refer explicitly to a consent. ‘Pending’ may apply broadly to any situation where an action or activity relating to an authorisation is pending. It may be where disclosure itself is paused or interrupted because an ADR has been suspended, or the DH pauses disclosure due to suspicious activity. It may refer to an action required by the user, such as a joint account election needing to be approved. Or it may be that an ‘empty authorisation’ exists where a consent is active, but no data is being shared because no accounts are associated with that consent. The use of ‘pending’ does not necessarily mean that the consent itself is technically ‘pending’. The term ‘pending’ is only an example and should not be seen as prescriptive. How the previous examples are visually implemented are at the discretion of the DH. |
#7 | Also the the guidelines, it mentions paused/interrupted consents. pg. 108. What is a paused consent? | Similar to the response to DHQ211, it may be where disclosure itself is paused or interrupted because an ADR has been suspended, or the DH pauses disclosure due to suspicious activity. The use of the term ‘paused’ and ‘interrupted’ refers to the disclosure of data and does not necessarily mean that the consent itself is technically ‘paused’. How such scenarios are visually implemented are at the discretion of the DH. |
#8 |
|
- |
#9 | We have daily files from Cuscal including cleared credit card transactions. When member open either Mobile banking or Online Banking and look at their transactions, there is real time service calls to Cuscal to retrieve latest available balances and pending transactions. From Open Banking perspective, is it ok for us only provided the confirmed transactions and available balances from the daily file without querying Cuscal for the pending transactions please? | - |
#10 | The consumer data standards specify that only the following cipher suites SHALL be permitted but doesn’t not say that all four are mandatory. CloudFlare doesn’t support the TLS_DHE ciphers in their environment. The link below provides their reasoning. I have extract the follow summary: DHE ciphers should be completely disabled in Intermediate compatibility configuration to improve overall server stability and security. If DHE ciphers are disabled on server side - in this case server will be protected from DoS attacks via very expensive SSL handshakes with DHE ciphers. Allowing DHE ciphers opens an additional DoS vector through very expensive SSL handshakes. So, servers with disabled DHE ciphers are more protected from DoS attacks at TLS layer and this is means what such servers are more stable. https://github.com/mozilla/server-side-tls/issues/268 Is it okay that we will only have the 2 supported ciphers listed above? | - |
#11 | Under the current rules, a DH may refuse ask for authorization or refuse to disclose CDR data in relation to an account that is blocked or suspended – we would like to understand how a DH is meant to notify a DR about this refusal, within the current standards? | - |
#12 | would each blocked/suspended account (for example 3 blocked accounts not disclosed in Get Accounts response) be considered a separate refusal from a reporting perspective? | - |
- TBA
# | Question | Answer/ Action |
---|---|---|
#1 | - | - |
Other business
- TBA
- TBA
- TBA