nils-work
commented
1 year ago Hi @aj-mozo
Re: the following -
- In many cases, important information about the nature of things is relegated to free text fields such as 'name' fields or 'additionalInformation' fields. While we can work with some ambiguity in Upfront and Periodic Fees, if there is no consistency in the labelling of Event-based fees then there is little hope of comparing apples with apples.
While fee names and associated free-text values are at the discretion of data holders, there may be an opportunity to define more granular classifications for EVENT or VARIABLE fees if that would improve the utility of the data.
EVENT fees are currently defined as:
A fee in relation to a particular event (e.g. ordering a new card, viewing a balance or stopping a cheque)
After reviewing a sample from the published product reference data, there appears to be some common themes, including:
- Card-related fees
- Statement, or letter fees
- Cheque, or chequebook-related fees
- ATM-related fees
- Missed/late payment, or default notice fees
- Loan variation or switching fees
- Government or legal fees.
The published VARIABLE fees have similar themes, and that data may also be improved by further classification.
Are you able to provide examples of the most important or common fee types that are difficult to group and/or compare currently?
Re: the following -
- If an Event fee is not mentioned, does that mean that the product has the feature but charges no fee, or that the product does not have the feature, or that the data is incomplete? We have seen a range of different approaches between banks, none the same as each other.
There may not always be an association between features and fees, but the expectation is that all fees applicable to a product are defined in responses.
If fee amounts or rates are not defined, the response may be non-compliant depending on the feeType specified; as the current description states:
One of amount, balanceRate, transactionRate and accruedRate is mandatory unless the feeType "VARIABLE" is supplied.
af-stayorgo
aj-mozo
The standards were designed in a way that gives data holders great flexibility. We believe too much flexibility! In the case of fees, this creates problems when trying to compare things.
In many cases, important information about the nature of things is relegated to free text fields such as 'name' fields or 'additionalInformation' fields. While we can work with some ambiguity in Upfront and Periodic Fees, if there is no consistency in the labelling of Event-based fees then there is little hope of comparing apples with apples.
If an Event fee is not mentioned, does that mean that the product has the feature but charges no fee, or that the product does not have the feature, or that the data is incomplete? We have seen a range of different approaches between banks, none the same as each other.