New Product Fee Type - CALCULATED (to address issue #161)

[DG-TMBL]

Description

Brief description of the issue that is leading to the change being required

#161

Our organisation see's the suggestion of using $0.00 in the amount as an unacceptable risk, in that it could be misleading information.

It should be noted that one of the big banks is listing fees with $0.00 in their product reference data as a way of emphasising that the fee is in fact free or not charged (for instance: Transaction Fee $0.00 where account has unlimited free transactions.). By listing as $0.00 instead of just leaving it unlisted, this increases the risk to us that a calculated fee listed at $0.00 could be misleading.

Area Affected

Describe the area of the standard that is proposed to be amended. This could be one or more API end points or a specific section of the information security profile

https://consumerdatastandardsaustralia.github.io/standards/#product-amp-account-components

Specifically - Product Fee Types.

Change Proposed

A detailed description of the specific change (or options for change) proposed. The more specific the proposal the easier investigation and consultation on the issue will be

Could an option be to add a new feeType enumeration like 'CALCULATED' and have the Description for amount changed to -
'The amount charged for the fee. One of amount, balanceRate, transactionRate and accruedRate is mandatory unless feeType is CALCULATED'

The may be other ways to achieve the same objective, and we are open to suggestions.

[RobHale-RAB]

Regional Australia Bank supports a move to revisit how At Cost fees are handled. We feel that inaccurate or misleading fee disclosure could result in disputes and complaints, increasing the administrative burden on DHs and not in the spirit of consumer transparency.
The suggestion to use 'calculated' appears useful, perhaps 'variable' might make a good alternative.

[anzbankau]

ANZ supports the addition of a 'VARIABLE' (preferred) or 'CALCULATED' feeType enumeration for both BankingProductFee (applying to BankingProductDetail and BankingAccountDetail). 'VARIABLE' indicates the result whereas 'CALCULATED' implies the mechanism, which is not really relevant.

[CDR-API-Stream]

Hi @DG-TMBL, @DG-TMBL, @anzbankau, @nils-work,

Based on the comments so far the consensus appears to be inclusion of a new feeType = VARIABLE.

Looking at the different types of at-cost fees that are charged by ADIs, these may be conditional fixed cost fees applied if a condition is met or event occurs, but they may also be percentage-based as a derivative of some cost, value or amount (see the table below for some examples in ADI fee schedules).

Is there a view on whether having just a feeType = VARIABLE is sufficient since none of the AmountString or RateString attributes would be applicable. It is important that there is sufficient information to describe the fee even when the feeType = VARIABLE.

Perhaps using the additionalValue could be used to denote the treatment of the fee (e.g. percentage-based on dollar-based) with additionalInfo and additionalInfoUri being used to better describe the fees. In this instance, is there any benefit in making any of those conditionally required for at-cost and variable fees?

If the at-cost fee is not applied in AUD, the currency field would also be important.

Any worked examples that you can provide would also be helpful including.

Examples

ADI	At Cost Fee	Description	Comments	Reference
Police Bank	We receive commission equal to 1% of the value issued to you	A fee is calculated for each money transfer service, based on the amount of money to be transferred and the destination country.	Percentage-based variable cost	https://www.policebank.com.au/pdf/Schedule_of_fees_and_charges.pdf
bankfirst	Settlement Fees   1. Settlement (Attendance) Fee   2. Settlement Cheque Fee	This fee applies if the settlement occurs outside the CBD area or attendance at settlement by Bank First representative	Conditional but fixed fee cost May be tiered (based on location of travel)	https://bankfirst.com.au/-/media/PDFs/TermsandConditions/tc_part_b.pdf
Teachers Mutual Bank Limited	Tele Transfer Fee	Cuscal fee for processing payments and receipts of real time irrevocable cleared funds	May be fixed fee or percentage-based	https://www.tmbank.com.au/-/media/global/pdfs/fees-and-charges.ashx
Teachers Mutual Bank Limited	Title search	Fee applies for additional title searches that may be required in addition to those already included in the Establishment fee and Top up fee.	Conditional but fixed fee cost	https://www.tmbank.com.au/-/media/global/pdfs/fees-and-charges.ashx
RACQ Bank	Enforcement expenses	Enforcement expenses	Conditional but fixed fee cost	https://www.racq.com.au/-/media/racq/banking/pdfs/downloads/bqto24-fees-and-charges-schedule.pdf
RACQ Bank	Cash request fees	Cash delivery charges, levied by the cash provider to RACQ Bank, are passed on at cost for large withdrawals. The charge is determined at the time of the request and may vary according to location.	Conditional but fixed fee cost May be tiered (based on location)	https://www.racq.com.au/-/media/racq/banking/pdfs/downloads/bqto24-fees-and-charges-schedule.pdf
Rural Bank	PPSR fees	EQUIPMENT FINANCE FEES AND CHARGES	Conditional but fixed fee cost	https://www.bendigobank.com.au/globalassets/documents/disclosures/rural-bank-schedule-of-fees-and-charges.pdf

[anzbankau]

We suggest that ProductFee.feeType = 'VARIABLE' with the amount, balanceRate, transactionRate and accruedRate properties becoming optional, together with additional text in the descriptions to retain the conditional nature of these properties unless feeType = 'VARIABLE', is sufficient.

Given that additionalValue is singular/elementary, it would suffer from the same limitation on representing complex calculations as the above-mentioned properties and the meaning would be ambiguous - unlike the specific descriptions in the 'Use of additionalValue Field' column in the 'Product & Account Components' tables.

The additionalInfo and additionalInfoUri should not be conditionally required as it would not be consistent with the way these properties are used throughout the standards. additionalInfo is free text (so a single punctuation character would meet the requirement) and additionalInfoUri is often not required or available when additionalInfo provides sufficient information.

The examples provided seem to cover a reasonable variety of variable fee types for the proposal. We have fee tiers (refer to Tiered fees in Product Reference data #10), complex calculations that can't be represented by the amount/balanceRate/transactionRate/accruedRate properties (either in combination or singly with additional factors) and external charges/at-cost - including those that depend upon other factors such as jurisdiction (e.g. stamp duties determined by state/territory Titles Offices).

[commbankoss]

We suggest that ProductFee.feeType = 'VARIABLE' with the amount, balanceRate, transactionRate and accruedRate properties becoming optional, together with additional text in the descriptions to retain the conditional nature of these properties unless feeType = 'VARIABLE', is sufficient.

Commonwealth Bank supports ANZ's statements above, including the addition of feeType "VARIABLE", with the properties amount, balanceRate, transactionRate and accruedRate becoming optional when feeType="VARIABLE".

Further, Commonwealth Bank recommends the conditional additionalValue be NA for "VARIABLE" feeType.

[CDR-API-Stream]

Thanks @commbankoss this was reviewed in the Maintenance call yesterday. There was consensus on the use of feeType=VARIABLE. Thanks for providing your feedback on support.

As for using "NA" for additionalValue how would this provide any more meaning to an empty string implying that the fee is an at-cost fee?

[commbankoss]

Thanks for your response @CDR-API-Stream . To clarify, we are not suggesting that additionalValue for feeType "VARIABLE" be "NA". In the Standards, the conditional field contains NA to identify that it is an optional field:

The following example, checked by the conformance test suites, uses feeType WITHDRAWAL and suggests that NA denotes additionalValue is optional:
{
"name": "Cash advance fee",
"feeType": "WITHDRAWAL",
"transactionRate": "0.03",
"currency": "AUD",
"additionalValue": "3.00",
"additionalInfo": "This fee is charged for cash advances obtained: Over the counter at CommBank branches or other Australian financial institutions, through CommBank or other Australian ATMs and at an overseas terminal or financial institution. $3.00 or 3.00% of the transaction amount - whichever is greater. Capped at a maximum fee of $300.00 (or $3 if your closing balance was in credit the previous business day)."
}

We are recommending that this fee type is the same, and that additionalValue should be an optional string for it, denoted as "NA" as is shown in the pictures of the standards above.

[jwaltonBF]

Bank First support the proposal of the Variable feeType, has a decision be made to incorporate this into the standards? If yes, is there an indication on when this will be added?

[CDR-API-Stream]

Thanks @commbankoss that makes sense - appreciate you clearing that up.

Hi @jwaltonBF, yes this change has been supported and it will be published in 1.4.0 of the data standards. A date has not been set for publishing this version as the current maintenance iteration is still in flight and the DSB is seeking to resolve any remaining "urgent" issues for July. A date for the new standards release will be published in due course.

[nils-work]

Hi @CDR-API-Stream
I think this issue can be closed now?

[deepsol-oba]

@CDR-API-Stream - apologies if this has been asked before ... x-v 2 and 3 need to be supported currently concurrently. What is the expected behaviour for v2 if a product has a fee with fee type "VARIABLE". What is the DSB expecting where the VARIABLE fee type for v2 would be represented (as it obviously needs to be as otherwise the data holder would not disclose a fee). Obviously, if v3 is requested, it will show as a VARIABLE fee type, but if v2 is requested?
Hope the question makes sense.

[nils-work]

Hi @deepsol-oba
It was asked in #317 :)

[deepsol-oba]

@nils-work - thanks for that ... need to learn to search better. Will continue there.

[CDR-API-Stream]

A change to the data standards was approved by the Data Standards Chair for inclusion in v1.4.0.

This issue will be closed accordingly.