Inclusion of repaymentType in the Product detail API about standards-maintenance HOT 11 CLOSED

Once approved we can work to the proposed standard so ANZ does not consider it necessary to disrupt the current iteration.

from standards-maintenance.

Westpac supports the inclusion of repaymentType in BankingProductLendingRate as detailed above.

We offer mortgages with an optional period of interest only repayments for a period at the start of the loan. We offer different interest rates based on whether the loan repayment type is interest only or principal and interest. Note that a fixed or variable interest rate may apply independently of the repayment type. Currently, it is not possible to represent the repayment type except by creating products for each case or by representing it as free text.

In addition, interest rates for mortgages can vary depending on loan purpose (i.e. owner occupied and investment), and we also suggest the addition of an loanPurpose field with enumerated values OWNER_OCCUPIED and INVESTMENT.

from standards-maintenance.

The change request to add fields repaymentType and loanPurpose to BankingProductLendingRate is supported. Both fields would be treated as optional.

repaymentType defined as enum {PRINCIPAL_AND_INTEREST, INTEREST_ONLY}. If absent, the lending rate is applicable to all repayment types.

loanPurpose defined as enum {OWNER_OCCUPIED, INVESTMENT}. If absent the lending rate is applicable to all loan purposes.

This will be incorporated into v1.3.0 (based off Maintenance Iteration #2). The change would be non-breaking and have a future dated obligation of July 2020 inline with the PRD Get Products V2 dates.

from standards-maintenance.

ANZ strongly support this proposal to include repaymentType in Product Detail. We also propose that repaymentType also be included in LendingRates. In the market, P&I and IO are presented as, and perceived to be, just a different interest rate (or set of interest rates if you include comparison rates) for the one product. Comparison applications could easily split them into separate products for presentation if necessary - as they may well do now. This was included as part of the RateTiers proposal. See the attached document in that proposal for single and separate products examples.

repaymentType was actually in Product Detail in the early days, after being proposed by ANZ and Macquarie, accepted by James in his reponse and in the final decision (page 12 - although I'm not sure where the enum 'NEGOTIABLE' came from, nor what it may mean or be used for). It was inherited by Account Detail but was then lost from Product Detail at some point.

from standards-maintenance.

Would this be considered an issue that needs to be addressed urgently or can it be addressed in the next maintenance iteration?

from standards-maintenance.

Making this change now directly impacts Biza's current sprint items for completion and this change directly impacts a product release we intend to complete soon after. Consequently, we request a decision from @CDR-API-Stream as soon as possible.

In addition we request clarification as to what issue classification framework is in use with respect to change prioritisation. Based on the Noting Paper for Revised Operating Model this change appears to be classified as:

The refactoring of existing properties for an existing API endpoint into a new structure

The timeline appears to be at Step 2 putting the change timeline at between 4-6 weeks.

Based on the the standards-maintenance README.md this appears to be entering the 4 week consultation period which aligns with the original Noting Paper timeline.

Having a clear classification framework of these change types, target timelines for implementation and flags of endpoint version backward compatibility, presumably based on their complexity, would greatly aid internal planning activities of all participants.

from standards-maintenance.

With this proposal still in the backlog and our desire to have products in the Open Banking product reference API that are directly relatable (by name) to products on our website (i.e. without P&I/IO in the name), ANZ will continue to work to the proposed standard rather than implement the current standard then go through another production change process.

from standards-maintenance.

With this proposal still in the backlog and our desire to have products in the Open Banking product reference API that are directly relatable (by name) to products on our website (i.e. without P&I/IO in the name), ANZ will continue to work to the proposed standard rather than implement the current standard then go through another production change process.

Considering ANZ is currently publishing product data with very little information beyond mandatory fields, it is difficult to understand what the concern specified relates to for your internal backlog.

I reiterate again a request for clarification of the change cycle the Standards are using here? Release timelines should be predictable so all parties can make an informed decision about resource scheduling. In the absence of this the ecosystem is going to start seeing payloads with x-v equality but structural differences.

If the addition of repaymentType is to proceed it implies that business decisioning for presentation would be based primarily off this field rather than inferred from the presence of more detailed rate specifications. Because of the type of business logic implied (repayment type is a critical element for financial advice disclosure) this looks like an opportunity to release a new payload version and rollup a number of other suggestions with respect to rates.

It's noteworthy to point out that data structures used for this communication are entirely absent from ANZ payloads but are present in various forms from CBA, Westpac and to a lesser extent NAB.

from standards-maintenance.

Re: Last paragraph of @WestpacOpenBanking 's [post]:(#48 (comment))

In addition, interest rates for mortgages can vary depending on loan purpose (i.e. owner occupied and investment), and we also suggest the addition of an loanPurpose field with enumerated values OWNER_OCCUPIED and INVESTMENT.

Please note that this has been proposed under #2 to support one item in the issue in this post. I would invite @WestpacOpenBanking (and others) to support this addition under that issue.

from standards-maintenance.

This will be incorporated into v1.3.0 (based off Maintenance Iteration #2). The change would be non-breaking and have a future dated obligation of July 2020 inline with the PRD Get Products V2 dates.

So it's still a V2 payload or is it now V3?

from standards-maintenance.

This change has been incorporated into v1.3.0 of the standards.

from standards-maintenance.