Comments (11)
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.
Related Issues (20)
- Improved structure for Solar Time Varying Tariffs HOT 15
- Additional field to support Step Tariff calculations HOT 18
- AuthorisationMetricsV2 abandonmentsByStage property descriptions and CDS Guide HOT 14
- EnergyPlanTariffPeriod - Change to daily supply charge HOT 13
- Addition of a DH-side endpoint for querying the status of a consent establishment flow HOT 13
- Maintenance Iteration 18 Holistic Feedback HOT 14
- Commercial Credit Card Structure under Get Account Details call
- Updates to 'Revoking consent' Standards HOT 4
- Concurrent consent support and cdr_arrangement_id HOT 4
- Collection Consents - Authorisation Amendment HOT 8
- Potential error in Telco specification HOT 2
- Include "Provider number" in GetDataHolderBrands Response HOT 1
- Remove BankingTransactionDetail and incorporate extendedData into BankingTransaction HOT 19
- Review Register API descriptions HOT 3
- Maintenance Iteration 19 Holistic Feedback HOT 3
- Retirement date for Get Generic Plan Detail v2 and Get Energy Account Detail v3 HOT 2
- Update CDS documentation to clarify expected rate value 'sign' (+/-) for each RateType HOT 6
- Update guidance for Banking account rate detail HOT 2
- Update TLS cipher suite requirements to address DHEat Attacks and Raccoon Attack vulnerabilities HOT 3
- AmountString field type impractical for energy tariffs HOT 12
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from standards-maintenance.