ConsumerDataStandardsAustralia / standards

Work space for data standards development in Australia under the Consumer Data Right regime
Other
319 stars 56 forks source link

Decision Proposal 338 - Updates to Banking Products and Accounts - Binding Standards #338

Open CDR-API-Stream opened 10 months ago

CDR-API-Stream commented 10 months ago

Thursday 16 November 2023: Decision Proposal Published

Decision Proposal 338 proposes the Candidate Standards for Banking Decision Proposal 306 be made Binding with Future Dated Obligations.

The Decision Proposal can be found below: Decision Proposal 338 - Banking Products and Accounts.pdf

The specific topics covered in this paper are:

This consultation progresses from Decision 306 which provided the Candidate Standards.

Community views are now being sought before these standards are proposed to be made binding.

This consultation will close on Friday 15 December 2023.

CDR-API-Stream commented 10 months ago

The original post for Decision Proposal 338 has been updated and the document is now attached. The DSB welcomes your review and feedback.

da-banking commented 10 months ago

DP 338 presents proposed changes to Product Catalogue in addition to Get Account Detail. Several of our clients have recently been advised that their Term Deposit rate tiers are not presenting correctly. The expectation is that a Term Tier should be present in addition to a value tier, within the same rate block.

We feel that this is not clear in the current version of the standards. Having reviewed other DH interpretation it appears only a couple of DHs are conforming to this requirement, hence indicating lack of clarity in the standards.

Therefore, DA Banking feels that DP 338 should include a documentation update to the Rate Tiers in the standards advising of this so that all DHs can conform by the DP 338 obligation dates or soon after.

CDR-Engagement-Stream commented 10 months ago

For those interested, the team have put together a short video introducing Decision Proposal 338.

anzbankau commented 10 months ago

@da-banking,

In regards to:

The expectation is that a Term Tier should be present in addition to a value tier, within the same rate block.

I presume this relates to the multi-dimensional aspect of tiers e.g., the term of the term deposit in combination with the range of funded amount qualifies a product/account for the rate containing the tiers.

We agree that this model has required guidance in the past, so would support additional descriptive language in the data standards. We also recognise that guidance has been provided in the CDR Support Portal:

  1. Representing multi-tiered product rates
  2. Representing multiple or tiered rates in BankingAccountDetail
commbankoss commented 10 months ago

CBA does not believe that the scale of changes proposed in DP 338 are warranted when considering value to consumers, investment across 114 data holders and the policy objectives outlined by the Assistant Treasurer (Minister Jones) in his Address to the Committee for Economic Development of Australia on 7 June 2023. Minister Jones communicated that the Government’s intent is to slow down, take stock and fix what is not working in the CDR. The following were the stated focusses: • “Improving data quality and deepening participation in the existing sectors….; • cyber security improvements…..; and • expanding awareness of CDR….” We believe DP 338, which followed on from DP 306, is a reactive approach to requests from some ecosystem participants. Our response to DP 306 Updates to Banking Product and Account Detail requested: • further impact assessments for the respective proposals, • substantiation of consumer benefits, and • articulation of viable use cases to support prioritisation of the changes, above uplifts to cyber security, consent etc. Given the high effort to implement, it is surprising that these requests have not been taken on board in DP 338.
The implications of DP 338 are more detailed schemas and data fields, and in our view this contradicts our understanding of Minister Jones’s stated policy aims by complicating existing sectors, and creating new requirements rather than improving existing implementation, particularly with regard to cyber security. CBA is therefore of the view that it is not appropriate to prioritise the changes in DP 338 as a binding standard. CBA recommends a pause and review of DP 338, and respectfully requests detailed substantiation of consumer benefits and articulation of viable use cases to support prioritisation of each of the proposed changes.

Mekaal commented 10 months ago

Bendigo and Adelaide Bank support @commbankoss comments above.

markskript commented 10 months ago

Upon review of the changes it appears to me that the majority of them relate to filling in gaps in the product data specifications and reducing opportunity for misinterpretations of existing parts of the standard.

I would have thought that this would firmly fall under the "improving data quality" mandate from the Minister as quoted above by @commbankoss.

Further, it appears that not making these changes makes it harder for use cases that rely on comparing products to be successful. If so, that would also fall under the Minister's desire to "deepening participation in the existing sectors".

There is a sense out in the business community at the moment that uptake of the CDR is hampered by data quality issues. Doing whatever can to improve data quality can only further help deepen participation.

Susan-ING commented 9 months ago

ING also support @commbankoss comments above. The changes outlined in DP338 are significant and warrant a substantiation of consumer benefits before proceeding.

anzbankau commented 9 months ago

This decision proposal (and its predecessor DP 306) has focused on many items that are potentially high impact changes to the standards. DP 306 feedback from participants made suggestions that considered the holistic set of changes and alignment to the technical principles stated in the standards. The rationale to why these suggestions were not taken up is welcome, given the effort to deliver the changes.

Further, we restate our view that some of the proposals within DP 306 warrant dedicated consideration to adequately address their complexity, impact and value to consumers.

In addition to the compound nature of DP 338, challenges we have experienced with it are:

ANZ agrees with @commbankoss that the review of DP 338 be paused, and appropriate assessment of the proposed changes and their relevant use case and value be undertaken.

WestpacOpenBanking commented 9 months ago

Upon initial review of DP338 Westpac recommends a pause and further engage with Treasury to ensure alignment with the Government’s CDR Priorities.

As an ADR Westpac welcomes changes that will improve data within the CDR ecosystem; however, we are concerned that the proposed expansion of data attributes across both product and account APIs are extensive changes and adequate consultation with the industry has not taken place. There is a high risk that new data fields and rewriting of API schemas in DP338 will overburden data holders and hinder existing implementations or efforts to improve other aspects of CDR.

In a time of consolidation, an expansion which carries a high risk of exacerbating existing issues is not a wise investment. Such an extensive change in ecosystem should be proven with data-led evidence that the proposal will achieve its intended benefits and is aligned with the Government’s priorities, prior to finalising.

Westpac urges the DSB Chair to seriously consider these concerns and engage in a collaborative effort with Treasury and industry. This will ensure the future success of the CDR by: • Focusing on outcomes that deliver measurable value to consumers and the broader economy. • Engaging with industry to define datasets that can meet the quality and consistency requirements of the outcomes they are intended to support. • Implementing changes in a measured and well-coordinated manner

perlboy commented 9 months ago

Today during the implementation call it was indicated there would be a new Standards release on Monday. Is this release going to include changes from this DP? If so, how is feedback being considered, evaluated, processed, synthesised and delivered into a Standard the following day?

HarryKT28 commented 9 months ago

To DSB,

The following suggestions and issues faced are based on around 38k users in a span of 75 days who have used our app and the open banking platform via Basiq to verify their bank a/c.

Our app use case – we connect the user's bank a/c to our app, which we pay the refunds issued to our app users for depositing their empty containers in their respective state's container deposit scheme.

Issues observed while collecting Bank a/c information through the open banking platform - 1) Masked account no.s for some accounts (occurring randomly, mostly from major banks and a few lesser-known banks) 2) Data sent with extra padded zeros on some account no.s– it's difficult to remove extra zeros that are variable in range and prefixed to the account no. 3) Account holder name missing for some accounts (occurring randomly) not very important but still valid to keep an even format on the open banking platform 4) User Concern on Data Permission – Users have shared their concerns from the media to the government on the amount of data sharing requested to verify their bank account. 5) We take account details in order to pay customers. There is no way to know or validate if the account can receive a payment or not. As a result, we get a high percentage of accounts that cannot receive a payment. This results in irate customers, calls to customer service and technical issues.

Suggestions 1) Separate data/header line to allow 6-digit BSB to be sent and fetched via open banking architecture (as the data received by us is a joint data of BSB and Account no.) 2) Separate data/header line to allow only a minimum of 5 digits and a maximum of 9 digits to be sent and fetched via the open banking platform. ( If this standard is not valid, we request DSB/CDR to inform all ADR Accredited Data Recipient (ADR) Model participants on the accepted format they will receive.) 3) IMPORTANT: Assign a new attribute on the Open Banking Platform for the Payout use case. Allow Open Banking Partners to receive info on whether the account selected by the end user can receive a payment or not. 4) Instruct all Banking and Financial Institutions to follow the standard format without any masking/zero padding. 5) Reducing the minimum scope to – Name | BSB | Account no. | Account Type and adding attribute if the account can receive the payment or not for Instant Account Verification 6) Sharing/raising tickets about masked or zero-padded account information in the CDR Service Management Portal is labour-intensive for Basiq and us. Core reasons for the unevenness of data need to be addressed at a deeper level. This suggestion is to improve the end-user experience, so we don't allow them to wait for an unspecified time till the issue gets solved.

Ausbanking1 commented 9 months ago

The ABA echoes the concerns raised by the banking industry. The changes proposed in DP338 are significant with substantial cost and resourcing implications. In particular, the ABA is concerned about:

Therefore, the ABA strongly recommends a pause of DP338 to enable:

perlboy commented 9 months ago

@HarryKT28 Much of your issues/suggestions seem to centre around BSB and Account Number. The Standards don't combine these and there is specific fields for unmasked account number. Consequently:

  1. Combining of BSB and Account Number is a Basiq artefact not a CDR one. Specifically the accountNo field in Get Accounts on the Basiq API.
  2. Masking of an account number is the difference between Account Basic and Account Detail scope. I'm unclear what scopes Basiq is using or what control you have over it but essentially for your use case you require Banking Account Detail. Possibly Basiq is transposing this data into the same field based on what they have available. That would explain the "random" part (spoiler alert: It isn't random the Consumer is only agreeing to Basic not Detailed).
  3. Including leading zeros but without spaces and hyphens is recommended by the Standards as "Is expected to be formatted as digits only with leading zeros included and no punctuation or spaces". That's not a binded statement though so perhaps it could be.

In summary it seems to me organisations are following the Standards and the issue here is a Recipient side combination of the Unrestricted Recipient transposing into another API and the downstream Recipient not understanding what the Standards mandate. If anything your response seems to be playing back the narrative of "it's the Holders" and yet that doesn't seem to actually be true.

Specifically for your use case I agree Consumers shouldn't have to give away such large swathes of data to achieve it. This isn't solved by changing the API contract for sharing though but rather specifically establishing an authorisation for the specific disclosure (i.e. a simple Action).

NPBS-OBTeam commented 9 months ago

Newcastle Permanent, part of NGM Group, welcomes the opportunity to provide feedback on Decision Proposal 338.

In respect of consultation question 3, the cardOption object should not assume that all cards on a product or account will be of the same type. The cardOption object should be specified as an array to support products that may allow a mix of card types or schemes on the account.

Regarding consultation question 5, our concern is that the proposed obligation and retirement timeframes are highly ambitious, given the scope and scale of the changes and the significant effort required to implement.

Delivering these proposed changes would require extensive and unplanned internal development work in the 2023-24 financial year. This would also require engagement with our API Manager (an external vendor on whom we have a dependency for our CDR solution) to plan, build, test and execute the changes within a compressed timeframe. Some of the proposed changes regarding credit cards would be complex to implement, as we do not have all the information required locally stored. We would have to scope out the changes with our card management vendor.

We are supportive of pausing the review of DP 338 and undertaking an assessment and prioritisation exercise regarding the proposed change items, with revised and phased timeframes for any binding updates to the CDR standards.

NationalAustraliaBank commented 9 months ago

Thank you for the opportunity to provide feedback on DP338. NAB has significant reservations with the decision proposal and respectfully recommends a pause in further consideration of DP338. Broadly, this is based on unclear customer benefit. More specifically:

af-stayorgo commented 9 months ago

StayorGo would like to thank the DSB for the opportunity to provide feedback on DP338. We are very supportive of the ongoing refinement of the data standards. Please find our detailed feedback attached.

DP338 Feedback STAY OR GO PTY LTD 2023-12-15.pdf

biza-io commented 9 months ago

Outside of the Information Security stream Biza.io lacks confidence the DSB is reasonably assessing feedback from participants and as such has chosen to avoid allocating limited resources to provide feedback we believe would be ignored anyway.

More broadly, the governance processes related to the Standards, and ostensibly the DSB, is poor and there are reasonable questions to ask with respect to whether the Chair is sufficiently conducting his obligations under the Rules.

Finally these changes relate in part to Non-Bank Lending which, at this stage, has no Rules instrument so verification of the proposed Standard will, by definition, be flawed.

af-stayorgo commented 5 months ago

@nils-work - its now been 4 months since the consultation closed. Are you able to provide an update on next steps?

nils-work commented 5 months ago

Hi @af-stayorgo

The next step will be an online workshop to determine a way forward with the changes proposed. For more details and to sign up, please see the event page for the Decision Proposal 338 Workshop.

Thanks