This is the official SFTI repo for the mortgage API. Documentations may be found in the Wiki.
An easy-to-read representation of the Mortgage API is accessible via the following link:
Common API for Mortgages
License: Apache License 2.0
This is the official SFTI repo for the mortgage API. Documentations may be found in the Wiki.
An easy-to-read representation of the Mortgage API is accessible via the following link:
In comparison to the existing Use Cases, TKB doesn't play pingpong between TPP and FI: On our platform "brokermarket" or "myhypo" the FI enters on a daily basis his conditions (interest rate, interest rate adjustments to the specific risks, forward interest rates). The user (broker or client) gives all the relevant information about his financing application. Then, the platform offers all conditions of all FI, and the user chooses one of these offers. After choosing one offer, our platform transfers all information to the FI.
Therefore, we need an endpoint where FIs can upload their condition rates to the TPP (brokermarket). The specific setup is not yet ready, can be provided by the TKB around february 2023.
How do you differentiate between asset and used asset?
e.g. if the applicant has cash CHF 200'000 and thereof he uses CHF 150'000 for financing the property as "Eigenmittel".
do you enter
CHF 200'000 in the "assets" in "financialSituation" as "assetType" cash
and CHF 150'000 in the "usedAsset" in "FinancingRequest" as "assetType" cash and "assetUsageType" withdraw?
If so, this makes sense. For new participants in the Common API community, this should be documented somewhere.
In the object "Estimation" you have the following fields:
estimationSourceType
amount
estimationDate
Estimation tools like WuP and IAZI know several "amounts". Therefore the field "Amount" is not meaningful. I suggest to rather call this field "marketValue".
Step 1 in next Release: description added : "Estimated Market value of the property"
Step 2 in Release V3.0: renaming of amount to "marketValue"
In our communication between TPP and FI, we use the TPP Applicant ID to refer to the client and we connect the dots of the different application using this key.
Therefore we would like to add to following new field in the Object "Party":
Name: tppPrimaryApplicantID
Description: ApplicantId for the applying party defined by TPP
Type: string, pattern: '^[a-zA-Z0-9]{6,10}$'
For the same reason, we need a new field in the Object "Applicant":
Name: tppApplicantID
Description: ApplicantId defined by TPP
Type: string, pattern: '^[a-zA-Z0-9]{6,10}$'
For the new Wüest Dimensions estimations, we miss a field in "Property Objects":
field name: heatEmission
description: Type of the heat emission
not required
array
string
enum: [floor, radiator, stove, other]
The schema PropertyIdentifier should be extended with a nullable EWID to identify the concrete apartment of the real estate
Possibility to return several error messages (list of errors).
The income and costs of other properties held by the applicant need to be considered in the affordability calculation. So, the FI needs to know the situation of additional properties.
In the object "financialSituation" we would like to have a new object "additionalProperties" as a list/array:
description: Information about additional property
required fields: valueAdditionalProperty, propertyTypeAdditionalProperty
In the new object "additionalProperties" are the following fields:
streetNameAdditionalProperty
description: Street name of the additional property
type: String, max. 70
valueAdditionalProperty
description Value of the additional property
type: see Amount
propertyTypeAdditionalProperty
description: The type of the additional property
type: string, enum: [single_family_house, condominium, vacation_house, vacation_condominium, agricultural_farm, 2or3_family_house, multi_family_house, residential_building_plot, building_plot_other, mixed_property, commercial_condominium, office_building, industrial_building, special_object]
We miss an important information about the property. In case of single family house / detached house we additionally need the information about the building type. Could be multi-family-house or terrace-house
Possibility to return several error messages (list of errors).
In our software we know two different channels, on which an application can be entered. The channel might have an influence on the price or on which client advisor is relevant for this application.
For this reason, we would like to have a new field in the object "application":
Name: channelType
Description: The type of the channel the application was generated
string
enum: [advisor, direct]
"advisor" could also be replaced by "broker"
In the field "otherFeatures" in the object "propertyBuildingInformation" and in the object "propertyFlatInformation", there is a grammar mistake in the enum ventilation_system_without_mingergie.
Could we correct that at both places?
I have added the new enum: ventilation_system_without_minergie -> for next release
we should delete enum: ventilation_system_without_mingergie in release V3.0
Wüest Dimensions differentiates not just renovation: true/false. Wüest Dimensions has different refurbishment Component Types:
total, interior_fittings_kitchen, interior_fittings_bathroom_sanitary, interior_fittings_floor_cover, interior_fittings_remaining
building_envelope_pitched_roof, building_envelope_flat_roof, building_services_heat_production, building_services_heat_emission, buildings_services_electrical_ventilation_elevator, work_on_surroundings, supporting_structure, building_envelope_windows, building_envelope_facade_balcony
renovation should therefore be built as an own object with a list/array:
For IAZI-estimations, the luxus flag is in "propertyObject" needed.
Name: luxusFlag
Description: If the property is luxury
not required field
String, enum: [0, 0.5, 1.0]
0 = Nein
0.5 = Teilweise
1.0 = Ja
In the Field "otherFeatures" in the Object "Property Building Information" for e.g. single family house some enum are missing for Wüest Dimensions. Could we please add the following enum:
indoor_pool, outdoor_pool, whirlpool_sauna, heated_conservatory, unheated_conservatory, security_system, chimney, passenger_elevator, freight_elevator
We have information about the replaced tranche which we would like to send to the FI. Therefore we need the following object:
"replaced tranches" with an array of all tranches.
A replaced tranche consists of 3 fields:
To avoid misunderstanding, we should swap the information max muster
An applicant of a mortgage can bring unpledged building plot as part of his assets (Eigenmittel). This enum is missing in the assetType.
Please add the enum: unpledged_building_plot
For the FI it makes a difference in the affordability calculation if the applicant is renter or home_owner. depending on that the bank needs to consider other costs.
Therefore, we would like to have a new field in the object "Financial Situation":
name: residentialSituation
Type: string, enum: [home_owner, renter]
Our service transfers data on the rating/solvency (CRIF Score) to the FI. We would like to have relevant fields in the object "Applicant":
For Wüest Dimensions estimations, we miss a field in "Property Objects":
field name: heatProduction
description: Type of the heat production
not required
array
string
enum: [oil, gas, wood, electric, geothermal_probe, district, solar_panel, solar_thermal_collector]
In the field "otherFeatures" in the object "propertyBuildingInformation" and in the object "propertyFlatInformation", there is a grammar mistake in the enum ventilation_system_without_mingergie.
Could we correct that at both places?
For Wüest Dimensions, we miss a field in "Property Objects":
field name: floorPlan
description: The efficiency of the floor plan
not required
string
enum: [efficient, average, inefficient]
We miss a field in "Property Objects":
field name: propertyType
description: The type of property
not required
string
enum: [single_family_house, condominium, vacation_house, vacation_condominium, agricultural_farm, 2or3_family_house, multi_family_house, residential_building_plot, building_plot_other, mixed_property, commercial_condominium, office_building, industrial_building, special_object]
Besides the current enum (none, minergie, minergie-p, minergie-eco, minergie-p-eco) IAZI now works with two additional minergieStandardTypes:
We should accept this two new types in our enum in the field "minergieStandardType".
For Wüest Dimensions, we miss a field in "Property Objects":
field name: numberOfRoomsInGrannyFlat
description: The number of the rooms in the granny flat
not required
number, double
In the object "Estimation" you have the following fields:
Estimation tools like WuP and IAZI know several "amounts". Therefore the field "Amount" is not meaningful. I suggest to rather call this field "marketValue".
We miss a field in "Property Objects":
field name: usageType
description: The type of usage of the financing property
not required
string
enum: [self, let]
Besides email of the applicant, the FI needs to know a phone number. So, we want to add a new field in the applicant Detail:
Name: phone
Description: Phone Number of the applicant
Type: string
You have the field "MaturityDate". I miss the field "StartDate" for the indication, when the mortgage starts.
Could we please have this new field before the field "MaturityDate"?
Type: see Date
What is meant with the field "increment"? Is it "Totalbetrag der Amortisation über gesamte Laufzeit"?
We need more detailled information about increment. Could we please add the following fields after "increment"?
What is meant with "interestBasis" in the object "Mortgage"?
There is no description provided for new community members.
For me, it is strange that on one hand the type is a string but on the other hand this field is required.
In the object "Estimation" I would like to add more fields to this object:
In comparison to the existing Use Cases, TKB doesn't play pingpong between TPP and FI: On our platform "brokermarket" or "myhypo" the FI enters on a daily basis his conditions (interest rate, interest rate adjustments to the specific risks, forward interest rates). The user (broker or client) gives all the relevant information about his financing application. Then, the platform offers all conditions of all FI, and the user chooses one of these offers. After choosing one offer, our platform transfers all information to the FI.
Therefore, we don't work with this process: application -> financing request -> offer -> order. And don't want to use the existing Use Cases or Endpoints /xxx.
We would like to have a new endpoint with all the data fields in one.
The other way would be if we transfer the datas in packages to the existing endpoints. In this case, a lot of required fields need to be "not required" because we do not have this fields, e.g. in the endpoint order, the UUID reference to the offer is mandatory. We don't have a UUID of the offer because we do not work with offers.
«Duration» at «Mortgage Product Variation» - Type: integer, int32, 1-20
«Duration» at «Mortgage Product Condition» - Type: string
«Duration Type» at "Mortgage": 1-10
How come that we have two fields "duration"? Is that technically no problem?
Do we need to rename?
What should we fill in the field if the mortgage has no duration (SARON or variable)?
FI can potentially offer fixed mortgage longer than 10 year, e.g. 20 years
We should allign the types of these 3 fields: "0-20" or just "string" without enum.
In addition to the enum "buy" and "replacement" we consider "Baufinanzierung" as well as a mortgage type.
In "mortgageType", we would like to extend the enum by "construction_financing".
You know the field "objectPrice". In my view, this is the "Kaufpreis". Besides the "Kaufpreis" more types of amounts are relevant for an application.
Can we add the following amounts after "object Price":
purchaseDate:
$ref: '#/components/schemas/Date'
description: 'Date of public notarization. Deprecated, will be removed in release v3.x'
publicNotarization:
$ref: '#/components/schemas/Date'
description: 'Date of public notarization.'
transferOfOwnershipDate:
$ref: '#/components/schemas/Date'
description: 'When the property was fully transfered to the new owner.'
We have two more options of "marital status":
Could we add these to the enum?
After multiple offers have been received, the tpp wants to get binding offers for just a few of them. This additional step seems to be important because the FIs usually have to block the money for the given binding offers.
For insurances (Asset Typ enum: life_insurance_3a, life_insurance_3b) two different types of amount are interesting for the FI:
Is it possible to add a new field in the object "Asset":
name: insurance sum
description: The amount of the sum insured
Type: see Amount
So, we can send the surrender value in the current field "amount" and send the insurance sum in the new field.
Some options are missing in the enum of the "income Types": leasing_payment, consumer_loan_payment, child_allowance_payment, rental_costs, costs_for_additional_properties
Please add these to the enum.
We need a field which transfer us the date, when the pricing for the offer has been done:
Name: "datePriceFixing" or "offerValidFrom"
description: "The date when the price has been fixed" OR "The date when the offer has been made"
Type: see Date
Can we add this field after the object "interest"?
To connect the done estimation in the core banking system with the estimation of the tpp in the external estimation tool, it would be useful if we can transfer the estimationId as a unique key.
Therefore I would like to add the following field in the object "Estimation":
name: estimationId
description: ID of the property estimation
Type: string, pattern: '^[a-zA-Z0-9]{6,10}$'
What is meant with the field "increment"? Is it "Totalbetrag der Amortisation über gesamte Laufzeit"?
I would rather suggest to call it amortization. Besides this Issue we developped a more precise setup for amortization in issue #23
For the property estimation service (Wüest Dimensions and IAZ), we miss a field in "Property Building Information" (for single family houses):
field name: environmentStandard
description: The rating type
not required
string
enum: [high-level, basic, low-level]
Which fields of the object "applicantDetail" are required?
Should we list some fields as required: e.g.
In our service, different Third Party Provider can apply for a mortgage. This is why we want to extend the object "tppAdvisorDetail" with a new field:
Name: nameTpp
Description: Firm of the TPP
Type: string, max 70
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.