A loan may have no end date but loanEndDate is mandatory

[WestpacOpenBanking]

Description

• Some accounts associated with loan products do not have a loan end date, but loanEndDate in BankingLoanAccount is mandatory.
• Some accounts associated with loan products do not have an expected repayment frequency, but repaymentFrequency in BankingLoanAccount is mandatory.
• Some accounts associated with loan products do not have a next date for which an instalment is required, but nextInstallmentDate in BankingLoanAccount is mandatory.

Area Affected

loanEndDate, repaymentFrequency and nextInstallmentDate in BankingLoanAccount which are present in responses from the Get Account Detail endpoint.

Change Proposed

Change loanEndDate, repaymentFrequency and nextInstallmentDate to optional.

[perlboy]

@WestpacOpenBanking I guess this is related to credit line type loan accounts? Would potentially suggest a new type of account for these as I believe the original intention was focused on mortgages which do (always?) have a target end date?

Allowing nullable fields in this has detrimental impacts on rendering, would prefer if the endDate was set to something "known unknown" like the minimum/max of epoch or the MIN or MAX value of an OffsetDateTime:

[CDR-API-Stream]

This change request is being considered in the data standards 4th maintenance iteration.

@WestpacOpenBanking can you provide a list of the products you currently offer via PRD which are impacted by this change?

[WestpacOpenBanking]

We have edited the change request above to suggest that repaymentFrequency and nextInstallmentDate in BankingLoanAccount are made optional in addition to loanEndDate.

[CDR-API-Stream]

Thanks @WestpacOpenBanking. Can you provide a list of the products you currently offer via PRD which are impacted by this change?

[CDR-API-Stream]

This change request was discussed in the maintenance iteration call: https://github.com/ConsumerDataStandardsAustralia/standards/wiki/DSB-Maintenance-Iteration-4:-Iteration-checkpoint:-Agenda-&-Meeting-Notes-(5th-August-2020)

Hi @WestpacOpenBanking noting that further analysis and feedback is required to progress this change request.

[WestpacOpenBanking]

Closed accounts are an important example where a loanEndDate, repaymentFrequency or nextInstallmentDate may not be present. Examples of Westpac branded products which have accounts that may not have all of these fields once closed include:

• Westpac Home Loan
• Westpac Investment Property Loan
• Westpac Business Loan
• Westpac Business Overdraft
• Westpac Equity Access Loan
• Westpac Term Loan

Additionally we note that line of credit style loans, such as the St.George Portfolio Loan, do not have an end date.

[NationalAustraliaBank]

NAB supports the proposal to make repaymentFrequency, nextInstallmentDate, and loanEndDate in BankingLoanAccount optional. Similar to Westpac, NAB revolving lending products such as overdrafts and lines of credit don’t have defined end dates or set repayments. Interest only loans also don’t have any scheduled loan repayments.

[perlboy]

Why is this request In Progress when Maintenance Iteration 5 Consultation only starts today?

Making these items entirely optional introduces ambiguity into products that should have end dates is there opportunity to implement a conditional based on some sort of type or otherwise?

[CDR-API-Stream]

Hi @perlboy this issue was carried over from the previous maintenance iteration hence it was originally carried into 'In Progress'.

[CDR-API-Stream]

This issue was discussed in the maintenance iteration call held on 7/10/2020.

As @perlboy alludes to, the preference is not to just make these fields optional. This issue was discussed in the maintenance iteration call held on 07/10/2020. On the call, it was discussed that there are two issues at hand:

1. Closed loan accounts
2. Line of credit products

Closed Loan Accounts
In certain situations it was discussed that some closed loan accounts may not have one or all of loanEndDate, repaymentFrequency or nextInstallmentDate but the change request is not clear on which fields are proposed to be impacted where openStatus is 'CLOSED'.

It was noted that this issue does not impact all DHs but clearly impacts due to core banking solutions or definition of products.

It may be that handling impacted fields for closed loan accounts could be conditionally optional or default values be applied if the account ``openStatus` is 'CLOSED'. This requires further feedback from DHs to understand requirements before a proposal can be made.

Can DHs comment on whether:

1. Whether loanEndDate cannot be populated when openStatus = 'CLOSED'
2. Whether nextInstallmentDate is not known when openStatus = 'CLOSED'
3. Whether repaymentFrequencycannot be populated when openStatus = 'CLOSED'

Line of Credit Products
Where a number of fields are always absent, this would suggest a different product category may be a better way to define these products.

Alternatively there was discussion regarding application of default fields as not all DHs experience the same issues identified in the CR.

Where the change request is considering line of credit products as different to the existing BankingLoanAccount representation, the DSB would welcome input on whether default values would suffice or alternatively a list of requirements where a new product type is proposed by DHs.

[WestpacOpenBanking]

Westpac confirms that all three numbered cases identified can occur and that the scenarios can also occur in other cases, including overdrafts, line of credits, closed accounts or when customers repay additional payments.

[NationalAustraliaBank]

NAB confirms that all 3 scenarios can occur for closed accounts, and similar to Westpac there are a number of other scenarios that could mean that these fields are either temporarily or never there. We still strongly recommend these fields are made optional due to these scenarios, and don’t support the introduction of complex conditional logic for these three fields.

[alex-histon]

Newcastle Permanent Building Society support making these fields optional, given there is no data for Line of Credit /equity loans and closed accounts. Also NPBS Bridging Loan does not require a repayment, so there are some other products outside LOCs that this issue may apply to, which would add complexity for a conditional path.
We believe the definition of Optional aligns with the intention of Westpac and NAB here ("optional fields indicate that data may sometimes not be held by a Data Holder and this is an expected scenario") - noting that it does NOT mean optionally implementable. We are not proposing to simply not provide this data where it is relevant, but as it does depend on product type and/or closed status, anything other that just making the fields optional will be overly complex.

[CDR-API-Stream]

Based on feedback to this thread and discussion at the first maintenance call for iteration 8, four options have been identified. The DSB is seeking feedback from the community of desirability of each option.

During original consultation on this issue, it was identified that for some loan accounts, banks may not hold a value for the three response parameters: loanEndDate, repaymentFrequency, nextInstallmentDate. This may occur where the account has been closed (and no future installments are possible) or the loan is a line of credit where the bank does not have an end date or fixed installment frequency. It was noted that this issue does not impact all banks because of the diversity of product design and different banks handle these situations in their core banking systems differently.

Option 1: Change loanEndDate, repaymentFrequency, nextInstallmentDate to be Optional

Change the three fields to from mandatory to optional. This would not be a breaking change for data holders but it would impact ADRs.

Considerations:

• Whilst optional, the data must still be provided by DHs if available
• Low interoperability and implementation certainty for ADRs
• Changes the endpoint versioning
• ADRs have to interpret null or missing fields as accounts where a loan end data is not defined
• ADRs do not know for what reason they are missing

Design questions:

• Do any ADRs or DHs not see this creating a breaking change and new endpoint version?
• What future dated obligations are considered reasonable?

Option 2: Define default values

Default values that explicitly denote they are not applicable for the loan account.

Proposed that the following defaults apply:

Response parameter	Proposed default	Description
loanEndDate	+999999999-12-31	The maximum epoch (future) defined in java.time.OffsetDateTime.MAX expressed as a DateString
repaymentFrequency	P0D	Where the loan has no further repayments or has end date, the repayment frequency is not applicable.
nextInstallmentDate	-999999999-12-31	The minimum epoch (past) defined in java.time.OffsetDateTime.MIN expressed as a DateString

Considerations:

• Good interoperability and implementation certainty for ADRs
• Less implementation impact compared to Option 3
• No change to the endpoint versioning: doesn't change the current response structure which reduces impacts to ADRs and DHs.
• ADRs will need to accommodate the new default values to understand the intended meaning
• DHs will need time to implement the default values

Design questions:

• Should the CDS look at well-defined default values across common field types?
• Should defaults be the same for common field types or should they be payload / parameter specific?
• What future dated obligations are considered reasonable?

Option 3: Define a new conditional loan account parameter

Introduce a new isLineOfCredit field and make loanEndDate, repaymentFrequency, nextInstallmentDate conditional.

Where the loan account's openStatus is CLOSED or isLineOfCredit is TRUE then loanEndDate, repaymentFrequency, nextInstallmentDate may be absent. Absence of these values shall be taken to mean that they are not applicable to the customer's loan account.

Considerations:

• Greatest interoperability and implementation certainty for ADRs
• Breaking change resulting in endpoint versioning
• Implementation impact for both ADRs and DHs

Design questions:

• What future dated obligations are considered reasonable?

Option 4: Do nothing

Where a bank has a customer account that does not have an end date, repayment frequency or next installment date, each bank provides a value that is appropriate for their systems.

The default values are left to the discretion of the individual banks.

Considerations:

• Increases interoperability complexity for ADRs
• Least interoperability and implementation certainty for ADRs
• No impact to data holders
• No breaking changes

[WestpacOpenBanking]

Westpac recommends changing loanEndDate, repaymentFrequency and nextInstallmentDate to optional as in Option 1. This approach is consistent with the one taken for other fields which are not always available at the data holder. It is the most flexible because it allows for any additional scenarios across data holders where loanEndDate, repaymentFrequency or nextInstallmentDate are not available in some combination. For example it might be possible for an account to be in a closing (as distinct from closed) state requiring a final balancing payment with no end date. It is also feasible that rather than storing an expected repayment frequency repayments may all be stored as scheduled payments.

We do not support defining default values as proposed in Option 2 as this approach is not consistent with the approach used for other APIs and we would argue that the change could still be breaking depending on the specifics of ADR implementations.

We do not oppose the inclusion of isLineOfCredit and openStatus fields to provide more information to ADRs, but per the above do not recommend that loanEndDate, repaymentFrequency or nextInstallmentDate are conditional based on the values of these fields as in Option 3.

We do not oppose explicitly allowing data holders to choose how to respond as in option 4, but remark that it causes possible interoperability and implementation certainty issues for ADRs as listed in the considerations.

[CDR-API-Stream]

This issue was discussed in the 9th maintenance iteration call. Pending any further feedback, the position is to adopt @WestpacOpenBanking's proposal to make these fields optional.

Implmentation Considerations

• This is a breaking change for client implementations. As a result, the associated Get Account Detail endpoint would be versioned to v2
• A future dated obligation needs to be agreed - the preference is this change should be bundled together with other changes to Get Account Detail to maximise value in versioning the endpoint
• Any Data Holder that cannot represent a loanEndDate, repaymentFrequency or nextInstallmentDate for an account's detail must not return the loan object represented by BankingLoanAccount. The guidance given in the past holds - if the Data Holder cannot syntactically comply with the schema, it cannot return the associated data. The response to the Account Detail API in this instance would return the rest of the account detail sans the loan object.

[CDR-API-Stream]

These changes have been staged for review: ConsumerDataStandardsAustralia/standards-staging@release/1.15.0...maintenance/150

[CDR-API-Stream]

This change was incorporated into release v1.15.0. Refer to Decision 212 for further details.