search

ConsumerDataStandardsAustralia / standards

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

Decision Proposal 306 - Updates to Banking Product and Account Detail #306

Closed CDR-API-Stream closed 1 year ago

CDR-API-Stream commented 1 year ago

The attached document describes proposed updates to Banking Product and Account Detail schemas.

Decision Proposal 306 - Updates to Banking Product and Account Detail.pdf

Consultation on this proposal will close on 28 July 2023.

Following an extension request, consultation on this proposal will close on 11 August 2023.

CDR-API-Stream commented 1 year ago

The opening comment has been updated and the Decision Proposal is now attached.

The Data Standards Body welcomes your feedback.

nils-work commented 1 year ago

This decision proposal references the following issues from Standards-Maintenance:

perlboy commented 1 year ago

Will review this internally but I think my first question would be what consideration there is for NBL related changes in this proposal. Based on the suggested FDOs the ecosystem could run out of windows to make further changes should they be required for NBL on overlapping endpoints.

nils-work commented 1 year ago

Hi @perlboy

Yes, some consideration has been given to the introduction of Non-Bank Lending (NBL) in this proposal, including the addition of card details and allowing for more specific rate information for distinct account types.

Obligation dates for future changes to the same endpoints would be consulted on as necessary, and aligning to these dates would be an option.

perlboy commented 1 year ago

Yes, some consideration has been given to the introduction of Non-Bank Lending (NBL) in this proposal, including the addition of card details and allowing for more specific rate information for distinct account types.

Ok, but what about things like BNPL? I'm reticent to start trying to tackle that sector but also cognoscente of the likely timeline challenges.

Obligation dates for future changes to the same endpoints would be consulted on as necessary, and aligning to these dates would be an option.

This seems to pre-suppose implementers for NBL wouldn't be the same ones for Banking. The reason this matters is that layering FDOs between Banking/NBL is likely to be highly problematic for providers of solutions operating in both (all) sectors. This is where my initial question came from because either FDOs are layered and implementors may respond by indicating they cannot service NBL (leaving very few options in market) or NBL FDOs are stuck behind bank ones for overlapping endpoints (leaving just Q3/Q4 2024 available).

da-banking commented 1 year ago

DA have reviewed the contents of the Decision Proposal. Changes to our core systems will be required to achieve what is being proposed.

DA Banking would like to propose that the obligation date of these changes be adjusted to accommodate the need to perform development on our core systems. We propose the following:

This would provide significant benefit to our client group, who are constantly in a state of UAT for compliance work (not limited to OB). It would also enable the core system changes to be fully scoped, tested and implemented.

biza-io commented 1 year ago

Due to the complexity of the decision proposal and resource constraints Biza.io request an extension on providing feedback.

nils-work commented 1 year ago

At the request of @biza-io, consultation on Decision Proposal 306 will be extended by two weeks to 11 August 2023.

As there are some areas of this proposal that may become relevant to the NBL sector, participants are encouraged to review it in conjunction with Decision Proposal 316 - Non-Bank Lending sector alignment.

cuctran-greatsouthernbank commented 1 year ago

Great Southern Bank welcomes the opportunity to provide feedback on Decion proposal 306 - Updates to Banking Product and Account Detail.

We have carefully considered the proposal given our size, delivery capacity and availability of data in our systems. Overall, this is a very big piece of work for Great Southern Bank to deliver.

Below is our feedback regarding the scope and timeline for the proposed changes.

Group 1 - Get Products and Get Product Detail We support both the proposed changes and the changes for consideration. We request the timeline for this change is July 2024.

Group 2 - Get Account Detail - loan UType We support the proposed changes in this group including the changes for consideration. However, we'd like to request a separate version of Get Account Detail for this group to ensure adequate analysis and testing. Requested timeline for this change is September 2024.

Group 3. Get Account Detail – creditCard UType This is the most complex change for us to implement as we do not have the information required locally stored. We will have to fully scope out the change with our card management vendor. The implementation cost is unknown to us at this stage. Therefore, we request a separate version of Get Account Detail for this group with obligation date beyond 2024.

Group 4. Get Account Detail – termDeposit UType and Group 5. Get Account Detail – other account types We support the proposed changes in this group with the implementation timeline being November 2024.

WestpacOpenBanking commented 1 year ago

Westpac welcomes the opportunity to provide feedback. Please find our response to the proposals attached. DecisionProposal306 Feedback.pdf

nils-work commented 1 year ago

Hi @WestpacOpenBanking

Thank you for your feedback.

On your response to the proposal relating to #471 - Additional credit card fields; the proposal did not suggest the inclusion of cardholder name or card expiry date. Examples of the proposed detail were provided on page 8 and 12 of the proposal (extracts below).

Get Products

"cardArt": [{
 "title": "string",
 "imageUri": "string",
+ "cardScheme": "AMEX / DINERS / EFTPOS / MASTERCARD / VISA / OTHER; mandatory",
+ "issuer": "string; mandatory",
+ "cardType": "CHARGE / CREDIT / DEBIT; mandatory"
 }],

Get Account Detail

 "specificAccountUType": "creditCard",
 "creditCard": {
+ "cardScheme": "AMEX / DINERS / EFTPOS / MASTERCARD / VISA; mandatory",
+ "cardType": "CREDIT / CHARGE / DEBIT; mandatory",
+ "issuer": "string; mandatory",
+ "cardLimit": "AmountString; optional",
+ "repaymentHierarchy": ["subAccountId", "subAccountId", ...],
nils-work commented 1 year ago

In relation to one of the additional issues for consideration; #387 - PRD - Constraint types further options have been provided here in response to feedback on that issue. Further feedback would be welcome. Thank you

aj-mozo commented 1 year ago

On https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/285, @nils-work posed a question about fee comparability which I'd like to reply to as part of the request for comment in Decision Proposal https://github.com/ConsumerDataStandardsAustralia/standards/issues/306:

1. Are you able to provide examples of the most important or common fee types that are difficult to group and/or compare currently?

Mozo believes that without significantly improved standardisation of the categorisation of fees, the CDR PRD dataset remains unusable for the programmatic comparison of products within an AFSL or ACL regulated environment.

Today there are just over 12,000 individual fee records in the Product Reference dataset of banking category TRANS_AND_SAVINGS_ACCOUNTS.

Of those, just over 50% are EVENT based fees. Unfortunately:

(a) There are 1,019 unique fee names given to those 6,300-odd EVENT fees. It's unclear what process PRD users are expected to use, to make any sense of 1,019 unique free text entries.

(b) Among the fees labelled as EVENT fees are things that should not be be categorised as Event, including:

Another approx 25% of fees are labelled TRANSACTION. Unfortunately:

(a) There is a fundamental logic flaw in the fee type naming schema: withdrawals, deposits, purchases and payments are subsets of the class 'transactions'. There is no consistency in how Data Holders determine whether a withdrawal transaction is a withdrawal or a transaction. With 598 unique TRANSACTION fees names plus another 335 unique fee names across the 4 subsets of transactions, and no consistency in the definition of fee type itself, comparability of fees is not possible.

I've attached a spreadsheet containing all 12,000 fees, and some simple analyses. CDR PRD fee names and types trans_savings 20230810.xlsx

aj-mozo commented 1 year ago

Also on https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/285, I posted my concern that it is not possible to determine whether the absence of a fee from a PRD record means that no fee is charged or that the action is not available or that the data is incomplete. I'd like to reiterate this point as part of the request for comment in Decision Proposal https://github.com/ConsumerDataStandardsAustralia/standards/issues/306:

Mozo believes that without significantly enhanced guidance and regulatory enforcement around definition and completeness of data, the CDR PRD dataset remains unusable for the programmatic comparison of products within an AFSL or ACL regulated environment.

I will simply give you a current example to demonstrate that the standards and/or compliance with standards is too loose for the data to be used to power reliable, accurate and compliant consumer information. It is worth noting that this example has been live in the market for at least 3 years:

Commbank Smart Access versus ANZ Access Advantage

Here's the fees that Commbank list in their PRD API for their transaction account:

And here is the complete list from the ANZ account:

Do you see the problem? ANZ charges many of the same fees as Commbank if you read page 11-12 of their booklet at https://www.anz.com.au/content/dam/anzcomau/documents/pdf/personal-account-fees-charges.pdf. But ANZ's CDR does not show this.

If ANZ was to publish a booklet containing just the 1 fee they would be engaging in misleading conduct. If I was to power a consumer-facing comparison with those fees I would be engaging in misleading conduct.

Why is the CDR data allowed to operate below the standards required elsewhere in the industry? If it is intended to be consumer-facing data then it needs to be held to the same standards as a PDS, website or advertisement. I urge the DSB to do more work in this area.

nils-work commented 1 year ago

Hi @WestpacOpenBanking

Regarding your response to the proposal relating to #132 - Determining Interest Rate of BankingTermDepositAccount; the proposal provided an example of the proposed change to Account Detail for a Term Deposit in Appendix 4 at the top of page 13.

In summary, it proposed to include the rate detail alongside each term deposit object, allowing for different rates on different terms, rather than leaving the single depositRates array applying to all term deposits. This was in response to the scenarios provided in issue 132.

NationalAustraliaBank commented 1 year ago

NAB welcomes the opportunity to provide the feedback for the issues collated in Decision Proposal 306. NAB has reviewed the contents of the Decision Proposal and due to implementation complexities. Changes to our core systems will be required to achieve what is being proposed. NAB proposes the following:

567 BankingProductLendingRateV2 - Lending Rates – FIXED/INTEREST_ONLY period end date cannot be determined

NAB’s Feedback: NAB supports Option 1 to provide two new date fields at the top of the BankingProductLendingRateV2 schema.

569 Home Loan Revert rate and product is not available

NAB’s Feedback: We support Westpac’s feedback which states “Revert rate is subjected to market conditions and can vary from what was fetched at the time of API call to when the loan gets converted from fixed to variable.”

316 Update description of features[].isActivated to remove default

NAB’s Feedback: We support Westpac’s and ANZ feedback. We agree, the isActivated field should be limited to the traditional boolean semantics implied by the 'is' prefix - with 3 values: True, False, Unknown/Not Applicable to support broad range of products and complex to determine activation status.

132 Determining Interest Rate of BankingTermDepositAccount

NAB’s Feedback: We support Westpac’s feedback which states “DSB to provide workable examples and guidance for any structural changes planned to the APIs to further analyse the issue”

anzbankau commented 1 year ago

ANZ's response to this decision proposal has been uploaded: ANZ feedback on DP306.pdf

We appreciate all the sample payloads provided in the change proposal and the considerable work that went into combining so many disparate change proposal with wide-ranging levels of detail.

CDR-API-Stream commented 1 year ago

The DSB are providing the linked response on behalf of CBA: CBA Responses - Decision Proposal 306 - 11 Aug 2023.pdf

nils-work commented 1 year ago

Hi @anzbankau

It may not change the general context of your feedback, but there appears to be an incomplete sentence near the top of page 11 of your submission, starting:

While we recognise that termDeposit was changed

Would you like to provide any missing detail?

anzbankau commented 1 year ago

Thanks for picking this up @nils-work.

Please ignore the incomplete sentence for #132. It was intended to point out that the termDeposit property in BankingAccountDetailV3 schema was changed from an object to an array without pluralising the name. Our suggestion to have a subAccounts array for the more general case would no longer require a termDeposits array because the anonymous subAccount object can be of any type (unless constrained by a homogeneous collection convention).

Conceptualisation of SubAccounts and Stages

The following snippets are provided only to demonstrate how the product/account phases and subAccount concepts described in our response might be represented. They are not intended to form part of a proposal, to encompass all the change proposals in this decision proposal (original or as suggested in this response) or to be in any way complete. They should be the subject of a separate decision proposal, given the substantial change suggested (though intended to be simpler to produce and consume than the related proposals in this decision proposal).

SubAccounts Example (subset)

{   "productCategory": "TERM_DEPOSITS             // Note: New enum(s) may be required for heterogeneous collections",
    "accountId": "string",
    "specificAccountUType": "termDeposit           // For a homogeneous collection",
#   "//Note: Additional fields representing the collective account": "",
+   "subAccounts": [
        {
+       "subAccountId": "Id Permanent",
        "specificAccountUType": "termDeposit           // For processing individual account",
        "termDeposit": [
            {
            "lodgementDate": "string",
            "maturityDate": "string",
            "maturityAmount": "string",
            "maturityCurrency": "string",
            "maturityInstructions": "PAID_OUT_AT_MATURITY"
            }
        "standardRate": "RateString; mandatory",
        "effectiveRate": "RateString; mandatory",
        "calculationFrequency": "ExternalRef ISO 8601 Durations; optional",
        "applicationFrequency": "ExternalRef ISO 8601 Durations; optional",
        "depositRates": [{}]
        },
        {
+       "subAccountId": "Id Permanent",
        "specificAccountUType": "termDeposit",
        "termDeposit": [
            {
            "lodgementDate": "string",
            "maturityDate": "string",
            "maturityAmount": "string",
            "maturityCurrency": "string",
            "maturityInstructions": "ROLLED_OVER"
            }
        "standardRate": "RateString; mandatory",
        "effectiveRate": "RateString; mandatory",
        "calculationFrequency": "ExternalRef ISO 8601 Durations; optional",
        "applicationFrequency": "ExternalRef ISO 8601 Durations; optional",
        "depositRates": [{}]
        }]}]}

Stages Example (subset)

{   "productCategory": "RESIDENTIAL_MORTGAGES",
    "accountId": "string",
    "specificAccountUType": "loan",
#   "//Note: Additional fields representing the collective account e.g., lendingFacility{}": "",
    "loan":
        {
            "startDate": "string              // Replaces originalStartDate since it's above the stages",
            "loanAmount": "string        // Replaces originalLoanAmount",
            "loanCurrency": "string       // Replaces originalLoanCurrency",
+           "stagesRate": {
#               "//Note.1": "Applies to all stages. Exclude property if in a stage as overriding would be inaccurate.",
                "calculationFrequency": "string",
                "applicationFrequency": "string",
                "interestPaymentDue": "IN_ADVANCE"
                },
+           "stages": [
+               {   "stageSequenceNumber": 1,
+                   "stagePeriod": "DateTimeString, optional                     // Product, replaces fixedPeriod",
+                   "stageStartDate": "DateTimeString, optional                // Account",
+                   "stageEndDate": "DateTimeString, optional                  // Account",
+                   "stageName": "Fixed Rate Period",
+                   "stageType": "FIXED",
                    "lendingRateType": "FIXED",
                    "standardRate": "RateString; mandatory",
                    "effectiveRate": "RateString; mandatory",
                    "lendingRates": [{}]
                },
+               {   "stageSequenceNumber": 2,
+                   "stageStartDate": "DateTimeString, optional                // Account",
+                   "stageEndDate": "DateTimeString, optional                  // Account",
+                   "stageName": "Variable Rate Period",
+                   "stageType": "VARIABLE",
                    "lendingRateType": "VARIABLE",
                    "standardRate": "RateString; mandatory",
                    "effectiveRate": "RateString; mandatory",
                    "lendingRates": [{}]
                }]}}
nils-work commented 1 year ago

The DSB would like to thank participants for their valuable engagement and feedback on this proposal. Submissions will now be considered and any outcomes from the consultation will be shared in due course.

nils-work commented 1 year ago

A decision has not yet been made on this proposal and an update will be provided once feedback on BNPL can also be considered.

The following two issues were consulted on in MI16 and the proposed changes to the Standards will be made together with the changes expected from DP306.

CDR-API-Stream commented 1 year ago

Decision 306 has been made by the Data Standards Chair: Decision 306 - Updates to Banking Products and Accounts - Candidate Standard Approved.pdf

This decision resulted in version 1.28.0 of the Data Standards being published on 10 November 2023, including a Candidate Standard to represent the changes proposed and feedback received on this issue. The Candidate also includes elements proposed in the Non-Bank Lending Draft Standards for completeness, as described in the Release Notes.

More detail about Candidate, Draft and Experimental Standards is provided in the Additional Standards section.

Further consultation on the Candidate Standard will continue in Decision Proposal 338.