Operations

Ongoing monitoring

Onboarding produces a classification; keeping it true is a different job. Four operational cycle triggers, structured alert handling, a four-eyes approval flow with its own question round, and — for customers registered as high risk — a regime with annual duties. This page is what keeps running after the kundetiltak ("customer measures") wizard has closed.

Operational cycles — PER, HND, MAN and OFF

Kundetiltak are no longer produced by onboarding alone: four operational triggers are in production. All four use the same engine and the same rules as onboarding (ONB) — one open cycle per company, a frozen model version, the company-template gate — and all four are assessed in the same «Vurder syklusen» ("assess the cycle") workspace. The deadline is 30 days, configurable per instance.

Code	What it means	What drives it	What it produces
PER	Periodisk gjennomgang — the scheduled review. The clock on the file.	The class's own review interval, read from the frozen model: next due date = last classification + interval. Opened by hand from the «Åpne syklus» menu, which asks first («Periodisk gjennomgang … Vil du åpne den nå?») and hints at the interval.	A cycle plus a status track: OK / forfaller snart ("due soon", ≤ 14 days, orange) / forfalt ("overdue", red) / pågår ("in progress"). Concluding it re-baselines the class and restarts the clock.
HND	Hendelse — the event cycle. Something happened to this customer.	An alert. «Håndter varsel» in the menu, offered only while the company has open alerts — or «Åpne ny syklus» inside the close-alert dialog.	A cycle created straight away. Opened from the dialog it remembers which alert triggered it, and that alert is closed into it as evidence.
MAN	Manuell revurdering — a human observation, not a system signal.	What someone saw. The «Manuell revurdering» intake dialog is mandatory, so a MAN cycle can never exist without a written reason.	A cycle carrying the observation, shown as a «Trigger:» note in the workspace and repeated in the conclusion snapshot. The observation is also logged on the customer.
OFF	Offboarding — ending the customer relationship.	«Avslutt kundeforhold» in the menu, behind a red confirmation naming the five-year retention duty («… oppbevaringsplikt (5 år) …»).	In this version, a cycle that concludes like the other operational ones: «Behold kundeforholdet» registers the class. The wind-down machinery itself comes later.

Each creation raises its own toast — «Periodisk gjennomgang åpnet», «Hendelses-syklus åpnet», «Manuell syklus åpnet», «Offboarding-syklus åpnet». Only HND has no confirmation step: it is created directly.
The MAN intake dialog is the only mandatory form. Kategori ("category": Medieoppslag / Kundemøte / Intern observasjon / Annet, with Medieoppslag preselected), Kilde ("source") and Beskrivelse ("description") required — «Kilde og beskrivelse er obligatoriske.» — and an optional Observert ("observed") date. The dialog says what it does with the text: «Observasjonen loggføres på kunden».
PER opens by hand, on purpose. No nightly job opens periodic reviews for you. The due date is computed and the status track turns orange and then red, but the cycle exists only once somebody opens it.
Start an operational cycle from the portfolio list's detail panel and you are taken to the company card's AML-risiko tab, which is where the cycle is assessed. Both surfaces are described in Risk classification The company card.

Which cycle a customer is on, and why

Because only one cycle can be open per company, "which cycle" is never ambiguous — but it is also never a name. The trigger is the reason: PER means the clock ran out, HND means a signal arrived, MAN means a person made an observation, OFF means someone is ending the relationship.

The open cycle is on the «Aktiv syklus» card on the AML-risiko tab, with its trigger chip, its opening date and its caseworker.
The closed ones are in the history card, as a table of Trigger / Periode / Klasse / Lukket av, with «Vis konklusjon» ("show conclusion") on each concluded row.
Model-version switches are part of the same history. Rows reading «Modellversjon oppdatert vN → vX · dato · av hvem» are merged in chronologically, so a class that moved because the model changed is not mistaken for a class that moved because the customer did.

A cycle has no name — it is named by its trigger and its opening date. Nowhere in the system does a cycle carry a name: it has an internal id plus trigger, status and opening date. The label is therefore assembled on every surface — «Periodisk · åpnet 1. juni 2026» — instead of showing the id. That holds for the «Aktiv syklus» chip, the workspace's two top chips, the history table, the conclusion snapshot, the «Lukk varsel» dialog and the «Konkluder syklus» dialog. The id is not gone: it sits in the hover text on every one of those surfaces, because it is the only handle support has for finding a cycle again. One deliberate exception: the kundetiltak wizard's assessment step shows the trigger word alone («Onboarding»), because the data behind it has no opening date — nothing is invented.

Alerts — the deep dive and «Lukk varsel»

Both the portfolio list's detail panel and the company card's AML-risiko tab carry full alert handling, and the notification centre continues alongside them; older closures made without a structured outcome stay valid. A screening alert means a PEP or sanctions hit from Stø, the external screening and monitoring provider Visena checks customers against, and screening alerts are offered a different set of outcomes from the rest.

«Vis detaljer» — the deep-dive window

The window is non-modal and movable: drag the title bar, resize it from the corner, and Esc closes the topmost one.
One section per change type in the alert — BRREG roles, key information, address, company sanction, person sanction and PEP details.
For an open alert the window itself carries a «Lukk varsel» ("close alert") button, and a confirmed closure closes both windows.

«Lukk varsel» — the four outcomes

Which outcomes appear, and which one is preselected, depends on the alert type and on whether the company already has a cycle running.

Outcome	When	Effect
Falsk positiv ("false positive")	Screening alerts only; preselected there.	The alert is closed as a mis-hit.
Marker som ikke-relevant ("mark as not relevant"; on screening alerts «Bekreftet treff — ikke relevant»)	Always visible — never preselected.	The alert is closed with no further measure.
Knytt til pågående syklus ("link to the ongoing cycle")	Only when the company has an active cycle; preselected for non-screening alerts that have one, with an «Anbefalt» ("recommended") badge.	The alert is closed and attached to the cycle as evidence, where it appears under «Tilknyttede varsler» in the workspace.
Åpne ny syklus ("open a new cycle")	Preselected for non-screening alerts with no cycle. With a cycle running it is shown locked, with a red chip «Sperret — <syklus> må fullføres eller lukkes først»; hidden entirely for screening. One alert at a time.	An event cycle (HND) is created in the same operation, and the alert is closed attached to it.

A reason of at least three characters is always required, and the button text follows the chosen outcome — «Marker som falsk positiv», «Lukk og knytt til syklus», «Lukk og åpne syklus».
Reopening a closed alert clears both the outcome and the cycle link.
After a closure the list, the KPI strip and the panel or tab reload, with the toast «Varselet er lukket.» A refusal from the server — the race where the company has just been given an active kundetiltak, for instance — is shown inside the dialog.

The alert lifecycle. An open alert may be inspected in the movable deep-dive window (dashed, optional) or closed straight from the card, and it always closes with one of four outcomes. Only «Åpne ny syklus» creates a cycle — an HND — in the same operation.

The «Vurder syklusen» workspace

«Vurder syklusen» on the AML-risiko tab turns the tab into a focused assessment surface — the same surface for every operational trigger. An onboarding cycle is sent back where it belongs («Denne syklusen er et kundetiltak (onboarding) — vurderingen gjøres i kundetiltak-veiviseren.»), and while a cycle waits for approval the surface is locked for editing. The top line also carries the frozen «AML-konfig vN» chip with an «Oppdater til vX» button when a newer model has been published.

Card 1 · Grunnlag

«Grunnlag — endringer siden forrige vurdering» ("basis — changes since the last assessment") shows FØR/NÅ ("before"/"now") rows per model category, hides the unchanged lines, and spells out the arithmetic: «<FØR> (klassifisert) ±Δ = <NÅ> poeng → <klasse>».
Open alerts are a hard gate. A red bar reads «N åpne varsler må lukkes før konklusjon (behandles i varselpanelet på fanen).»
The panel «Tilknyttede varsler» ("linked alerts") lists the alerts that were closed into this cycle, each with its outcome badge and its reason quoted.

Card 2 · Betingede steg

The card lists the control measures the frozen model has triggered, each with its name and the reason it fired. It is interactive: an open step is handled with «Behandle →» ("handle") — an inline form with conclusion choices shaped to the step type plus a reason of at least three characters — then «Lagre & marker fullført».
The alternative «Mangler dokumentasjon — send portal-skjema» opens the KYC dispatch dialog and puts the step in «Venter kunde-svar» ("waiting for the customer's answer") with its status track. The step completes itself when the signed answer arrives. The dispatch, the portal and the signing are described in The KYC portal.
Open steps block the conclusion: «Betingede steg må fullføres før syklusen kan konkluderes.» Concluding a step that is waiting for a customer answer cancels the outstanding round, so a step can always be closed by hand.
Steps the model no longer derives after a model switch are marked, never deleted.

Card 3 · Vurder & beslutt

A class picker sits over the published class bands, with threshold labels («0–9», «60+») and a «Foreslått av modellen» ("proposed by the model") badge. In this version the class follows the points: a divergent choice is refused with «Klassen følger poengsummen — bruk justeringen for å endre klasse.»
Manual adjustment ±25, with a reason required whenever it is not zero («… påkrevd, loggføres i revisjonssporet.») and the note «Justeringen løper ut ved neste periodiske gjennomgang.» Everything on the card autosaves.
The four-eyes banner appears when the measure setup requires approval from the HVA (hvitvaskingsansvarlig, the designated AML-responsible officer): «Betingelsene for 4-øyne konfigureres i AML-konfig → Kontrolltiltak.» The HVA picker preselects the company's designated officer. A separate optional checkbox adds the engagement partner: «Send til oppdragsansvarlig for gjennomgang før konklusjon».
The button «Send MF-rapport til Økokrim» opens the «Registrer MF-rapport» dialog for a report of suspicious circumstances under hvitvaskingsloven § 25 — see Reports and exports.

Concluding the cycle

The cycle finishes with «Send til godkjenning» when approval is required, or «Fullfør syklus» when it is not. Both go through a confirmation dialog that shows the FØR → «Etter (Vurdert)» classes and lists what is about to happen: «Når du bekrefter, blir følgende gjort:».
An operational cycle always concludes with «Behold kundeforholdet» ("keep the customer relationship"). The risk class is registered, mirrored to the older risk value, and becomes the new baseline for the preliminary engine. No customer number and no projects are created — those are onboarding effects.
The server enforces the gates, not just the interface; breaches come back as one red list.
«Vis konklusjon» opens a non-modal, movable conclusion snapshot holding the frozen values: class before → after, point groups per category, the manual adjustment with its reason, the approvals (attestation and the question round included), the observation for MAN and HND, and the number of linked alerts. The decision reads «Kunde opprettet», «Kundeforhold videreført» or «Kunde avvist».

The four-eyes gate in depth

When the model's conditions call for it, the cycle is decided by someone other than the caseworker — the four-eyes gate, «fire øyne». The approval surface is the detail panel's approval tab; the flow it drives is below.

Attestation. «Godkjenn syklus» requires the approver to tick a declaration — «… i tråd med internkontrollen for hvitvasking. Min 4-øyne-signatur knyttes til konklusjonen.» — before «Signer og godkjenn» becomes active. The attestation is stored on the approval and shown in the conclusion snapshot.
«Spør om mer info» ("ask for more information"). Rather than deciding, the approver can send a question of at least five characters back to the caseworker. The request moves to «Venter svar» ("awaiting answer"), and the caseworker's answer returns it to «Til godkjenning». One active round at a time — a new question replaces the previous pair — and the cycle stays in waiting-for-approval throughout.
Rejection needs a reason of at least five characters and sends the cycle back to the caseworker.
OA before HVA. When both the oppdragsansvarlig (OA, the engagement partner) and the HVA have been asked, the OA must decide first; an OA approval alone never concludes a cycle, because the HVA requirement stands.
Severity is visible. The HVA banner turns red when the proposal lands in the model's top class, or jumps two classes or more.

The approval deep flow. The caseworker sends the cycle up; when both have been asked, the oppdragsansvarlig decides before the hvitvaskingsansvarlig. «Spør om mer info» parks the request in «Venter svar» without deciding, and «Avvis» returns the whole cycle to the caseworker.

HVA administration — designating a hvitvaskingsansvarlig

The admin page Relasjoner ("relations", /admin/associations) carries the card «Hvitvaskingsansvarlig»: designate a person as HVA for a user group. One active designation per group — a new one replaces the old — and «Avslutt» ends a designation behind a confirmation. It is ended, not deleted; the history stands.
The lookup walks upwards. A company's HVA is found by starting at the company's owner group and walking up the group tree to the first group with an active designation (the newest wins if a group has several). One HVA can therefore be set at the top and overridden per department.
The designated HVA is preselected as approver in the four-eyes flow, in the wizard and in the workspace alike. Without a designation, any active user can be chosen: a missing HVA never blocks the approval flow.

⚑

Two duties are the HVA's alone, and a missing designation is visible in both. Only the company's current HVA may sign the annual confirmation of enhanced measures, and that is enforced on the server. The escalation log notifies the HVA by name; with nobody designated it still writes the row, marked «Ikke varslet — ingen hvitvaskingsansvarlig». Designating an HVA per group is therefore what turns those two records from a gap into a signature.

Deviation alerts

When the system's preliminary class starts to diverge from the registered one, the company's responsible user gets a bell notification: «Foreløpig risikoklasse avviker for <navn>: <registrert> → <foreløpig>».
Only the transition notifies. A divergence that persists is silent on later recalculations; if the company comes back into agreement and then diverges again, it notifies again. Prospects, which have no registered class, are never notified about, and companies without a responsible user are skipped in silence.
The notification is pushed live to the bell, with no page refresh — as is the «KYC-svar mottatt» ("KYC answer received") notification.

Forsterket løpende overvåking — the regime in operation

Enhanced ongoing monitoring is switched on automatically by registered high risk, and "high" means the registered class is mirrored as «Høy risiko» in the model version the classification was frozen against — not that the class happens to be called «Høy». It switches off when a cycle concludes with a class that is not mirrored that way. The «Forsterket løpende overvåking» card at the foot of the AML-risiko tab is a real workspace: activation information, the halved thresholds, and three sections.

Section 1 · Annual source-of-funds documentation

«Registrer dokumentasjon» ("register documentation") has two modes. «Last opp ny fil» takes a file and a document type — «Konsernregnskap 2025», say — and archives the file as a company document. «Velg eksisterende dokument» opens a picker over the company's archived documents, newest first and searchable by name («Viser X av N — avgrens søket» when there are many hits); the document you choose is registered as documentation with no new file and no copy. Both routes log the event.
The section shows the document list, «Sist mottatt» ("last received"), «Neste forfall» ("next due" — last receipt plus one year, or the activation date when nothing has been received) and a status chip Ok / Snart forfalt (≤ 30 days) / Forfalt.
The due date is display only. Nothing runs at night to chase it.

Section 2 · Annual HVA confirmation

«Bekreft kontrolltiltak (HVA)» records the declaration «Du bekrefter som hvitvaskingsansvarlig at de forsterkede kontrolltiltakene fortsatt er forholdsmessige for kunden.» A reason of at least three characters is required.
Only the company's current HVA may confirm, and that is enforced on the server rather than only in the interface.
Afterwards the section reads «Sist bekreftet <dato> av <navn> (Hvitvaskingsansvarlig)», with the same due chips as section 1.

Section 3 · Escalation log

Rows are written automatically whenever a signal-driven recalculation — an alert opened or closed, a KYC answer received, the nightly sweep — moves the preliminary points or the preliminary class of a customer registered as high risk. Each row carries the date, a description, a ±points badge (red when the class changes, orange otherwise), «Varslet <HVA> <dato>» and the read state «Lest <dato>» / «Ulest» from the HVA's bell notification.
With nobody designated the event is still logged, marked «Ikke varslet — ingen hvitvaskingsansvarlig».
Deliberate acts never escalate. A re-baseline — a new classification — and a model publication are not signals, and write no rows.

«Be kunden om dokumentasjon»

The button opens the KYC dispatch dialog in source-of-funds mode: the funds questions are preselected and a mandatory upload field is added to the form automatically («Et obligatorisk opplastingsfelt legges automatisk til i skjemaet.»).
The request has its own e-mail text — the subject «Visena — forespørsel om kilde-til-midler-dokumentasjon (<firma>)» and an opening that explains the documentation is being asked for as part of enhanced monitoring of the relationship. The reminders carry matching text, and in the dispatch list the round is badged «Kilde-til-midler-forespørsel».
The request belongs to the company, not to a cycle. It survives the cycle being closed, and only one may be outstanding at a time — a chip «Forespurt — venter svar» carries the send date and the recipient.
When the customer submits and signs, every uploaded file is registered automatically as source-of-funds documentation in section 1.

Screening is not part of the regime. PEP and sanctions screening against Stø runs continuously for every customer whatever the class — a customer created in onboarding is put under monitoring against BRREG and Stø at that point, and stays there. What enhanced ongoing monitoring adds on top is the annual source-of-funds documentation, the annual HVA confirmation and the escalation log.

What is documented elsewhere

The portfolio list, its filters and views, the row detail panel and the company card's AML-risiko tab — Risk classification The company card.
KYC dispatch, the customer portal, the dispatch status track, SMS notification and BankID signing — The KYC portal.
The portfolio report, the Excel export and the MF report to Økokrim — Reports and exports.
Classes, «Speiles som», review intervals and the conditions behind the four-eyes gate — The risk model.
The onboarding cycle itself, step by step — The kundetiltak wizard The five steps.