swissfintechinnovations / ca-pension Goto Github PK

Description
Upon reviewing the API specification for the Policy schema, I've identified a enhancement opportunity: the inclusion of a pensionProvider field.
Currently the name of the pension provider (foundation) is not available.

Suggested Change
I propose the addition of the pensionProvider field to the policy schema:

Policy:
type: object
description: Details of policy
required:
- policyId
- personId
- policyNo
- entryDate
- salaryData
- retirementCapital
- riskBenefits
- financing
- pensionProvider --> NEW FIELD

  properties:

pensionProvider: --> NEW property
type: object
required:
- providerName
properties:
providerId:
type: string
description: Swiss Enterprise Identification Number UID
providerName:
type: string
description: The name of the pension provider (foundation).
providerAddress:
$ref: '#/components/schemas/Address'
description: Postal address of the pension provider.

Description
Currently, when requesting a policy response (GET /policies/{policyId}), the API schema states that the value of retirementCapital->projectedRetirementBenefits should be an array representing the projected retirement benefits for a series of retirement ages.

State of the Art Observations
We asked 3 pension funds to implement this API. None of them could provide us with an array of projected retirement benefits. Instead, they only provided the "real" projected retirement benefits corresponding to the client's official retirement age.

Suggested Change
I propose modifying the specification to return not an array, but just an object containing the projected retirement benefits for the client's official retirement age. If the request includes a specification in simulationData to retire before or after the retirement age (see issue 22), it should only return the resulting projected retirement benefits.

Description
Upon reviewing the API specification for the Policy schema, I've identified a enhancement opportunity: make the projection interest clearer, at the moment it is not clear if it is the projection interest rate or the actua.

Suggested Change
I propose the addition of a new interestRate property:

components:
schemas:
InterestRates:
type: object
description: Interest rates applicable to the retirement capital, including actual rates for mandatory and supplementary coverage and a projection rate for future value calculations.
properties:

interestRateProjectionEnveloping: --> NEW; REPLACE OTHER Enveloping interest rate and thus make naming clearer!
type: number
format: double
description: Projection interest rate for combined mandatory and supplementary coverage (in percent), used specifically for calculating projected future values.

Objective:
The current insurance schema includes a lumpSumDeathBenefit field that represents a one-off payment in the case of death. We aim to provide more detailed information on lump sum payments by splitting this field into two separate fields: lumpSumWithoutPensionBenefits and lumpSumWithPensionBenefits. This change will allow us to distinguish between lump sum payments made with and without concurrent pension benefits.

Suggested change
Remove the existing lumpSumDeathBenefit field from the RiskBenefits schema.
Add two new fields to the schema:

schemas:
RiskBenefits:
type: object
description: Benefits in case of death or disability to work
required:
- pensionDisabilityFromIllness
- childPensionDisabilityFromIllness
- partnerPensionDeathFromIllness
- orphanPensionDeathFromIllness
- lumpSumWithoutPensionBenefits --> NEW
- lumpSumWithPensionBenefits --> NEW

lumpSumWithoutPensionBenefits:
type: number
format: double
description: One-off payment in case of death where no other benefits are paid out

lumpSumWithPensionBenefits:
type: number
format: double
description: One-off payment in case of death where other benefits are paid out

Description

Upon reviewing the API specification for the InsuredPerson schema, I've identified a enhancement opportunity: the inclusion of an employer field. Currently, there is no provision to capture the employment details of the insured person.

Suggested Change

I propose the addition of an employer object to the InsuredPerson schema. In this object, only the name of the employer would be a required field. The schema could be structured as follows:

employer:
type: object
description: Details of the insured person's employer
required:
- name
properties:
employerId:
type: string
description: Swiss Enterprise Identification Number UID
name:
type: string
description: The name of the employer
address:
$ref: '#/components/schemas/Address'
description: The address of the employer
industry:
type: string
description: The industry or sector the employer operates in

Further considerations

The employer field is optional at the InsuredPerson level, as not all insured persons may have a current employer

Description
Upon reviewing the API specification for the Policy schema, I've identified a enhancement opportunity: the inclusion of a maxPurchaseAmount field.
Currently the maxPurchaseAmount for voluntary purchases is not available on the policies level but only on the "purchasesAPI".

Suggested Change
I propose the addition of the maxPurchaseAmount field to the Policy schema:

maxPurchaseAmount:
type: number
description: |
The maximum amount the insured person is permitted to voluntarily contribute to their pension plan.

Description
Upon reviewing the API specification for the Policy schema, I've identified a enhancement opportunity: the inclusion of a homeOwnershipWithdrawal field.
Currently the homeOwnershipWithdrawal amount is not available.

Suggested Change
I propose the addition of the homeOwnershipWithdrawal field to the vestedBenefits schema:

homeOwnershipWithdrawal:
type: number
description:
The total amount available for the insured person to withdraw or borrow against from their retirement capital for the purpose of financing home ownership.

Description
When asking for a simulation, it would be nice to be able to request the result of the simulation if the client wants to retire before or after the legal age.

Suggested Change
I propose the addition of a new query called nbYearBeforeAfterAgeRetirement in the Simulation Data:

nbYearBeforeAfterAgeRetirement  integer($int32)
default: 0
maximum: 5
minimum: -2

Allows you to specify the number of years anticipated or delayed before retirement (min: -2 , max: 5).