Important
This article refers to changes in Version 1.4.0 of the Consumer Data Standards. Refer to the latest version of the Standards before implementing this advice.
Question
Version 1.4.0 of the Consumer Data Standards introduced a new feeType
enumerated value of VARIABLE
in the BankingProductFee schema. Could you please clarify if this new feeType
is applicable ONLY for Version 3 (Get Product Detail API) or for Version 2 also?
As a Data Holder, the VARIABLE
feeType
is applicable to our Home loan product suite, and our data sharing obligations commence (for this product) in Feb 2021. This is in line with when version 3 needs to be implemented. We need to support version 2 simultaneously. We would like to get guidance on how we should represent these VARIABLE
fees in version 2.
If we represent these fees with any of the enumerated values other than VARIABLE
, then based on the standards, we would be expected to provide a value in at least one of these conditional fields – amount
, balanceRate
, transactionRate
, accruedRate
. Unfortunately none of these additional fields is applicable for these fees. For example, Search fees or Govt Fees as these differ by state.
Please provide guidance on which of options we should implement, in order to be compliant from a Rules and Data standards perspective.
- Use ‘variable’
feeType
in version 2 and 3 – Guidance required on whether thisfeeType
is acceptable in version 2 - Use ‘variable’
feeType
in version 3 and classify the same fee as anotherfeeType
in version 2 – Please provide guidance on the value to be provided in the following fields as none of them is applicable for this fee -amount
,balanceRate
,transactionRate
,accruedRate
, - Use ‘variable’
feeType
in version 3 and NOT provide/send this fee in version 2 - Do not provide this variable fee type in either version.
Answer
Options that are available to the data holder in this circumstance are:
- Provide a schema compliant response that is as accurate as possible. In the case of a variable fee this may be achieved by selecting a different fee type and specifying an appropriate indicative amount for the fee. In many circumstances this will be entirely acceptable. This is option 2 in the question.
- Exclude the record entirely. In the case of a product fee this is not desirable but, for minor fees that are infrequently applied, it may be considered less inaccurate than choosing a fee type that could be misleading to a customer. This is option 3 in the question.
The choice of these options is up to the data holder and should be made considering all regulatory obligations, including those unrelated to the CDR.
Note that option 1 is not acceptable as it would result in a non-compliant payload according to the standard. This should never be considered a viable option for dealing with difficult to represent CDR data.
Comments
0 comments
Please sign in to leave a comment.