swissfintechinnovations / ca-mortgage Goto Github PK

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]

The description seems to be a copy / paste error.”Preferred contact language of the applicant”

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:

• refurbishmentComponentType (string, enum: see above)
• yearOfRenovation (same as "renovationYear" but different name)
• renovationCost (see your Standard for "amount")

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:

• replacedTrancheAmount
  description: The amount of the replaced tranche
  type: see Amount
• replacedTrancheExpiry
  description: The expiry date of the replaced tranche
  type: see Date
• replacedTrancheIssuer
  description: The institute who has issued the replaced tranche
  type: string

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":

• rating
  description Solvency rating of the applicant
  type: integer
• ratingDate
  description: Date of the solvency rating
  type: see Date

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:

• minergie-a
• minergie-a-eco

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:

• 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".

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"?

• incrementType
  description: The type of increment
  type: string, enum: [direct, indirect]
• incrementAmount
  description: The amount of the periodic increment
  type: see Amount
• incrementStart
  description: Start date of increment
  type: see date
• incrementPeriodicity
  description: The periodicity the increment is paid
  type: string, enum [yearly, quarterly, monthly]
• incrementAccountNr
  description: the account number from which the increment is paid
  type: string

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:

• statisticalPriceRangeMax
  description: Estimated statistical price range maximum
  type: see Amount
• statisticalPriceRangeMin
  description: Estimated statistical price range minimum
  type: see Amount
• yearlyRentalIncome
  description: Estimated rental income per year
  type: see Amount

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":

• renovationAmount
  description: Amount needed to pay the planned renovation (Renovationsbetrag)
  Type: see "Amount"
• investmentCost
  description: Total amount needed to pay object price and planned renovation (Total Anlagekosten)
  Type: see "Amount"
• collateralValue
  description: Value of the property as base for the securization applying the lowest value principle (Belehnungsbasis)
  Type: see "Amount"
• limitForLandEncumbrances
  description: The limit for land encumbrance according to Bundesgericht über das bäuerliche Bodenrecht, SR 211.412.11 (Belastungsgrenze BGBB)
  Type: see "Amount"

We have two more options of "marital status":

• legally separated - gerichtlich getrennt
• Partnership dissolved - aufgelöste Partnerschaft

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:

• surrender value / Rückkaufswert
• insurance sum / Versicherungssumme
  Both of them will be entered in the core banking system. So we would like to transfer both amounts.

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.

• name
• surname
• address
• birthdate
• maritalstatus
• gender

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