← Back to Adapters

Calculate LTV

Loan-to-value calculation — submit the state slices the collateral analysis reads, receive the LTV ratio

Calculate LTV

Loan-to-value calculation. Served by the calculate-ltv-adapter component, which runs a full collateral analysis in the engagement-collateral-analysis (ECA) blocc module and returns the single ratio out of it.

Endpoint:

  • POST / — Calculate loan-to-value ratio

The path key is relative to the component's adapter route (/calculate-ltv), so consumers call http://integration-proxy-api/calculate-ltv.

Calculate LTV

POST / — Submit the state slices the analysis reads, receive the LTV ratio.

Request body — CalculateLtvRequest. Each collection $refs the standard-model schema this market ships (@repo/standard-model-no, json/mortgage-no/state/*), so the contract tracks the model instead of restating it:

| Field | Required | Notes | |-------|----------|-------| | financing | yes | Existing loans and credits | | collateralObjects | yes | Objects the collateral agreements are registered on | | collateralAgreements | yes | Deeds/pledges. Carry the coverage links — no coverage, no LTV | | parties | yes | Owners and debtors referenced by the agreements | | assets | yes | Market valuations live here, not on the collateral object | | changes | yes | The proposed scenario; must carry the applied-for loan | | scenarios | no | Defaults to one synthetic scenario over every change | | households | no | case.households, flattened; enables the per-household branch |

The mortgage-no variant is deliberate, not mortgage-no-integration: the latter also requires entityType and externalId on every party, which internal state does not carry — ECA's own regression payload fails against it.

Response — CalculateLtvResponse:

  • ltv (required): the ratio as a percentage. The highest ratio among the individual collateral objects — the object-level figure, which accounts for additional collateral and is what the Norwegian credit rules are written against. The adapter logs the per-object and per-loan breakdown behind it.

Two ways to get a meaningless answer

Both return a plausible number rather than an error:

  1. No applied-for loan in changes. LTV comes from applied amounts, which only exist for financing in the analysed scenario. Send only current state and you get the customer's current ratio. Model the application as a CREATE_ELEMENT LOAN or a LOAN_INCREASE.
  2. No coverage links in collateralAgreements. With no coverage there is no applied amount, and the ratio comes back as 0.

Examples

Three validated request examples live in examples/ and are inlined into the bundled spec:

| Example | Shows | |---------|-------| | purchase.yaml | New loan, object and deed, all as changes | | loan-increase.yaml | Established engagement as current state plus one LOAN_INCREASE | | third-party-pledge.yaml | Realkausjon — two objects, prior liens; ECA's own regression case |

They are derived from real payloads rather than written by hand, because the standard model requires far more per element than a hand-written example tends to carry. Note what loan-increase.yaml documents: promoting an element out of a CREATE_ELEMENT change into current state is not a copy — the state collections require fields the change payloads omit (termAmount.termAmount, marketValuation.marketValueType, mortgagor share/externalId, a currency on shareOfCommonDebt) and reject collateralObjectLiens outright.