Boligøkonomisk overvågning

Boligøkonomisk overvågning samler kundens bolig, lån, aktuelle renter, Nasdaq-kurser, kommunal prisudvikling og ændringer i Tinglysningen. Når en af vores regler rammer, opretter Råd til Bolig en notifikation, som vises på boardet under "Overvågning" og kan sendes videre gennem API og webhooks.

Det betyder, at en virksomhed ikke selv skal forbinde tinglysningsdata, obligationsmarked, finansieringsregler og kundehændelser. Det samme datagrundlag, der bruges til at beregne boligens finansiering, bruges også til at holde øje med den.

Seks typer overvågning

Kun kundens gemte bolig og eksisterende lån overvåges. Midlertidige beregningsscenarier bliver ikke til notifikationer.

Konvertering, refinansiering, prisudvikling og kursalarmer kontrolleres fem gange på hverdage. Ændringer i Tinglysningen kontrolleres én gang dagligt.

Opkonvertering

Opkonvertering bliver kun undersøgt for fastforrentede lån. Vi sammenligner:

kursforbedring = nyt fastforrentet låns udbetalingskurs
                 - nuværende låns indfrielseskurs

Der oprettes et signal, når kursforbedringen er større end 10 kurspoint.

Hvis det nuværende lån kan indfries til kurs 86,0, og et tilsvarende nyt fastforrentet lån kan udbetales til kurs 98,5, er forskellen 12,5 kurspoint. Reglen rammer. Er forskellen præcis 10,0, rammer den ikke.

Indfrielseskursen beskriver, hvad de bagvedliggende obligationer kan købes tilbage til. Realkredit Danmark beskriver forskellen mellem opsigelse til kurs 100 og indfrielse til markedskurs. [3]

Kursen på det nuværende og det mulige nye lån kommer fra vores match til de danske realkreditobligationer i Nasdaqs nordiske marked. Nasdaq beskriver sine nordiske fixed-income-produkter som markeds- og referencedata for blandt andet børsnoterede obligationer, ISIN, kupon og udløb. [4] [5] Læs hvordan obligationsdata bliver renset og matchet til lån.

Nedkonvertering

Nedkonvertering bliver også kun undersøgt for fastforrentede lån. Begge betingelser skal være opfyldt:

nuværende rente - nyt låns rente >= 1,5 procentpoint
nyt låns udbetalingskurs > 98

Et lån med 4,0 pct. i rente og en kandidat med 2,5 pct. til kurs 98,8 rammer derfor reglen. Renteforskellen er præcis 1,5 procentpoint, og kursen er højere end 98. En kandidat til præcis kurs 98 rammer ikke.

Grænserne er Råd til Boligs overvågningsregler. De finder sager, som er relevante at beregne videre på. En konvertering afhænger også af blandt andet restgæld, løbetid, omkostninger, skat og boligejerens tidshorisont. Boligøkonomisk Videncenter viser netop, hvorfor enkle konverteringsregler skal bruges sammen med en konkret beregning. [1] Bolius beskriver de almindelige former for omlægning. [2]

Refinansiering

På lån, der ikke er fastforrentede, oprettes et signal, når refinance_date er senest 182 dage fra dags dato.

Datoen kan komme fra lånet og blive beriget gennem match til den relevante obligations udløbsdato og lånets refinansieringsforløb. Reglen er konkret refinance_date <= i dag + 182 dage. En gammel dato opfylder derfor også betingelsen, hvis den stadig står på lånet. Hold refinansieringsdato og obligationsmatch aktuelle, så notifikationen beskriver det rigtige forløb.

Det samme lån giver ikke en ny eskalering, blot fordi datoen fortsat ligger i vinduet. For refinansiering bruges lånets aktuelle ISIN som identitet, når den findes. Et nyt ISIN kan derfor begynde et nyt overvågningsforløb.

Kommunal prisudvikling

Prisovervågningen begynder ved datoen for kundens seneste eksisterende lån på boligen. Vi finder prisniveauet omkring denne dato for samme ejendomstype i boligens kommune og sammenligner det med det seneste kommunale niveau:

prisstigning = (seneste kommunale pris / pris ved seneste lån - 1) × 100

Der oprettes et signal, når stigningen passerer 10, 20 eller 30 pct. Hvis flere grænser er passeret, viser notifikationen den højeste.

Feltet latest_snapshot indeholder blandt andet:

• adresse, ejendomstype og kommune
• datoen for det seneste lån
• dato og prisniveau for både udgangspunktet og den aktuelle statistik
• beregnet stigning og den passerede grænse

Det er kommunal markedsstatistik for ejendomstypen, ikke en ny individuel AVM-vurdering af boligen.

Ændringer i Tinglysningen

Hver dag henter vi Tinglysningens liste over ændrede ejendomme og matcher BFE-numrene til kundernes boliger. En ny ændringsdato opretter en notifikation med adresse og tidspunkt. Dataene kommer fra Tinglysningsrettens system-til-system-løsning eTl. [6]

Notifikationen fortæller, at boligens tingbog er ændret. Den fortæller ikke i sig selv, om ændringen vedrører et lån, en servitut, en ejeroplysning eller noget andet. Den fulde tingbog skal hentes og sammenlignes for at fastslå indholdet.

Det almindelige boligkald kan derefter opdatere de berigede tinglysningsdata, herunder hæftelser, tinglyst rente og den aktuelle rente, som Råd til Bolig finder efter vores regler.

Kursalarmer

En rådgiver kan oprette en kursalarm på en bestemt obligationsserie og vælge, om alarmen skal ramme over eller under et kursmål.

Obligationen matches på kupon, udløbsår og afdragsfri periode. Reglen bruger en streng grænse:

• "over" rammer først, når den aktuelle kurs er højere end målet
• "under" rammer først, når den aktuelle kurs er lavere end målet
• en kurs, der er præcis lig med målet, rammer ikke

Notifikationen indeholder kupon, udløbsår, afdragsfri periode, kursmål og den aktuelle kurs. Se sådan oprettes en kursalarm.

Fra signal til notifikation

En notifikation har en type, en status, et niveau, en revision, en kort titel og et øjebliksbillede af de data, der udløste den.

I den nuværende produktion bliver en notifikation kvitteret eller afsluttet gennem boardet eller API'et. Den bliver ikke automatisk afsluttet, alene fordi næste overvågningskørsel ikke finder det samme signal.

Et gentaget signal opretter heller ikke en ny hændelse hver gang. En åben eller kvitteret notifikation bliver først eskaleret, når ændringen er væsentlig efter reglerne for typen:

En oprettelse eller eskalering øger notifikationens revision. En kvittering gemmer den aktuelle revision i acknowledged_revision, og hændelser for kvittering og afslutning henviser til den samme aktuelle revision. Det gør det muligt for modtageren at behandle hændelser i den rigtige rækkefølge.

Notifikationer i API'et

Alle overvågningsendpoints ligger i version 2 af API'et:

GET /v2/notifications returnerer blandt andet notification_type, status, severity, revision, title, summary, latest_snapshot, created_at og updated_at. I det aktuelle svar hedder kundens nøgle PK, og notifikationens nøgle hedder SK.

Både ack og resolve skal have kundens nøgle:

{
  "customer_key": "customer:019..."
}

Et vellykket statusskift returnerer den hændelse, der blev oprettet. Hvis notifikationen allerede har den ønskede eller en senere status, returneres 204 No Content.

Webhooks sender ændringerne videre

Webhooks gør overvågningen hændelsesdrevet. En API-kunde kan abonnere på ændringer i notifikationernes livscyklus:

• notification.created
• notification.escalated
• notification.acknowledged
• notification.resolved

Det er hændelsestyper, ikke notifikationstyper. En subscription på notification.created kan derfor modtage både conversion.down, price_increase, tinglysning og de andre notifikationstyper.

Opret en webhook

POST /v2/webhooks
Content-Type: application/json

{
  "url": "https://example.com/webhooks/raad-til-bolig",
  "events": [
    "notification.created",
    "notification.escalated"
  ],
  "description": "Boligøkonomiske hændelser"
}

En virksomhed kan have op til 10 webhook-endpoints. Hvert endpoint skal abonnere på mindst én og højst fire forskellige hændelsestyper. Nye endpoints er som udgangspunkt enabled og kan ændres til disabled.

De tilhørende endpoints er:

Et webhook-endpoint skal bruge HTTPS, må ikke indeholde brugernavn eller adgangskode og skal pege på en offentlig adresse. localhost, private IP-adresser og redirects accepteres ikke. Modtageren har fem sekunder til at svare.

Leveringens JSON

Hver levering har både et hændelses-id og et leverings-id. Hændelses-id'et identificerer ændringen i notifikationen. Leverings-id'et identificerer leveringen til det bestemte webhook-endpoint og er det samme ved et nyt forsøg.

{
  "id": "notification_event:019...",
  "delivery_id": "webhook:019...#webhook_delivery:notification_event:019...",
  "type": "notification.created",
  "created_at": "2026-07-18T10:00:00Z",
  "company_id": "company:019...",
  "customer_id": "customer:019...",
  "notification_id": "notification:conversion:property_019...",
  "test": false,
  "payload": {
    "notification_type": "conversion.down",
    "status": "open",
    "severity": "warning",
    "source_key": "property:019...",
    "revision": 1,
    "title": "Nedkonvertering",
    "summary": "Der er en nedkonvertering på Eksempelvej 1",
    "fingerprint": "conversion.down:property:019...:Eksempelvej 1",
    "material_score": -2.5,
    "snapshot": {
      "address": "Eksempelvej 1",
      "current_interest_rate": 4.0,
      "candidate_interest_rate": 2.5,
      "candidate_redemption_rate": 98.8,
      "current_redemption_rate": 100.0,
      "redemption_rate_improvement": -1.2,
      "current_isin": "DK0000000000"
    }
  }
}

Felterne i snapshot afhænger af notifikationstypen. Behandl derfor den ydre struktur og felterne direkte under payload som den fælles kontrakt, og læs snapshot efter notification_type.

Kontrollér signaturen

Alle leverancer signeres med HMAC-SHA256. Signeringsnøglen begynder med whsec_ og returneres, når den oprettes eller udskiftes med POST /v2/webhook-settings/reset-secret. GET /v2/webhook-settings fortæller kun, om nøglen findes; det viser ikke selve nøglen igen.

De vigtigste headers er:

Signaturen beregnes over tidsstemplet, et punktum og den rå request body:

signed_content = X-Webhook-Timestamp + "." + raw_request_body
expected = "sha256=" + HMAC-SHA256-HEX(shared_secret, signed_content)

Brug den rå body, før JSON bliver læst og skrevet igen, og sammenlign signaturerne med en konstant-tids-funktion. Kontrollér også tidsstemplet og afvis gamle leverancer efter den tolerance, jeres integration bruger.

Virksomheden kan tilføje op til 10 egne headers med højst 1.024 bytes pr. værdi. PATCH /v2/webhook-settings erstatter hele listen. Standardheaders og navne, der begynder med X-Webhook-, kan ikke overskrives.

Svar og nye forsøg

Et HTTP-svar i 2xx-serien markerer leveringen som gennemført. Andre statuskoder, netværksfejl og timeout giver et nyt forsøg, dog højst fem leveringsforsøg i alt. Derefter markeres leveringen som udtømt.

POST /v2/webhooks/{webhook_id}/test sender én synkron testlevering og returnerer leveringsstatus, statuskode og en eventuel fejl. Testkaldet bruger samme JSON, headers og signatur som en almindelig levering, men sættes ikke i kø til automatiske nye forsøg.

Kilder

[1]: https://bvc.dk/media/1376/tommelfingerregler-for-konvertering-web.pdf Boligøkonomisk Videncenter: Tommelfingerregler for konvertering

[2]: https://www.bolius.dk/omlaegning-af-dit-realkreditlaan-17799 Bolius: Omlægning af realkreditlån

[3]: https://rd.dk/kundeservice/faq-and-guides/faq/hvad-betyder-indfrielse-af-laan Realkredit Danmark: Indfrielse af lån

[4]: https://www.nasdaq.com/solutions/data/market-data-catalog Nasdaq: Market Data Catalog – Nordic Fixed Income

[5]: https://www.nasdaq.com/solutions/data/nasdaq-nordic-reference-data-files Nasdaq: Nordic Reference Data Files

[6]: https://www.domstol.dk/tinglysningsretten/professionelle-brugere/etl/ Tinglysningsretten: eTl-systemdokumentation