Setup

The risk model

AML-konfig is where your firm decides what risk means: which factors award points, which classes those points fall into, and which control measures follow. Everything on the Risikomodell tab is a draft until you publish it, and every assessment already made stays frozen on the version it was made on.

Access and structure

AML-konfig ("AML configuration") lives at /admin/product/aml-config, a menu item with a slider icon. It appears only when the feature is enabled for the instance, and only administrators may open it — anyone else is turned away with «Krever administrator-tilgang».

• Two tabs: Risikomodell ("risk model") and Skjemabygger ("form builder"). You can link straight to a tab and a section, the address updates as you navigate, browser back and forward work, and Ctrl/Cmd-clicking a tab opens it in a new window.
• The configuration selector is the Konfigurasjon dropdown at the top. Everything you edit — the risk model and the forms — belongs to the selected AML configuration, not to the instance. A firm may keep one per department, or just the one that ships («Standard»). «+ Ny konfigurasjon» creates a new one by copying an existing one (a name plus «Kopier fra»), so you never start from an empty page.
• Switching tabs with unsaved form changes asks first: «Ulagrede endringer … Vil du forkaste dem?».

Configurations and who they apply to

• One AML configuration owns one risk model — with its own history of one draft, one published version and archived predecessors — and its own set of KYC forms. There used to be exactly one of each per instance; "one" is now "one per configuration".
• The link is made on the group, not on the customer: Rediger gruppe ("edit group") has a field «AML-konfigurasjon» defaulting to «Arv fra overordnet gruppe». Many groups may point at the same configuration.
• The lookup follows the company's department, not yours. It starts at the customer's owner group and walks up the group tree until it finds a group with a configuration; if none has one, the default configuration applies. Handle a customer owned by another department and it is that department's rules that count.
• Exactly one configuration is the default, and it cannot be archived («Standardkonfigurasjonen kan ikke arkiveres») — make another one default first. Archived configurations are hidden from the selector, but groups already pointing at them keep them.

The Risikomodell tab

The top of the tab names the configuration you are editing and the active version («v1 · aktiv»), adds an «Endringer ikke publisert» label once a draft exists, and carries Forkast endringer ("discard changes"), Forhåndsvis konsekvens ("preview impact") and Publiser ny versjon ("publish new version") — the last two disabled until something changes. A submenu on the left lists the eight sections, with counts for factors, classes, service areas and measures. Draft, publishing and history are per configuration: a draft in «Revisjon» does not touch «Standard».

1. Your first edit creates the draft — a copy of the published version, numbered vN+1.
2. You keep editing; it autosaves. The published version goes on serving every new kundetiltak ("customer measure") meanwhile.
3. «Forhåndsvis konsekvens» rehearses it against the real portfolio. Read-only.
4. «Publiser ny versjon» makes the draft active and archives the previous version, which stays readable as history. Assessments already made stay frozen on theirs.
5. «Forkast endringer» deletes the draft and leaves the published version untouched.

Section 1 · Risikofaktorer

• All 15 risk factors sit in five categories — Kunde / Screening / Tjeneste / Transaksjon / Annet. Each carries a colour dot and an aggregation badge, «Aggregering: SUM» or MAX; MAX means only the strongest signal in the category counts.
• Per factor: an on/off switch, a Norwegian name and description, a source badge («BRREG», «Stø», «NACE + manuell», «Origo oppdrag», «Regnskap», «Onboarding + manuell» …) and a «Kundeflagg» label where a customer flag mirrors the factor. An inactive factor awards no points and disappears from the form builder's risk links and from measure conditions; its card is dimmed.
• Per outcome: editable, signed points — PEP is «Ingen treff» 0 / RCA / PEP. Negative points reduce risk; an outcome of +200 is a deliberate hard stop that guarantees the class Høy. The factor Tjenestetype shows «Redigeres under Tjenesteområder» instead of editable points.
• Threshold rows (cash turnover, cash counterparty, foreign payments …) carry an editable NOK amount, formatted «1 000 000 kr» when you leave the field; the points awarded when a reported value strictly exceeds it; an on/off switch; and a copy button for the parameter {{threshold.<id>}}, which you paste into question texts («Kopiert!»).
• Every numeric field is guarded: digits only, pasted text cleaned, minimum and maximum enforced, arrow keys and the spinner stepping the value (Shift for a large step).

Section 2 · Risikoklasser

The classes are data, not a fixed list. Each configuration owns its own ladder, and you can add and remove rungs («+ Legg til klasse», plus a delete icon per row). A new configuration ships with three:

Each row also has a colour dot, a proportional colour band across the point scale, a review interval of 1–60 months with a spinner and a readable reading of it («årlig», «hver 2. år», «hvert halvår», «N mnd»), and a «#» column («Kunder i klassen») holding a live count. Open ends show as −∞ and ∞ and cannot be edited; the top class is always open upwards.

• «Speiles som» ("mirrored as"). Each class chooses whether it counts as Lav, Middels or Høy risiko in the rest of Origo. It is this mirroring, not the class name, that decides the company card's risk value, whether enhanced ongoing monitoring engages, whether the escalation log records rows, and how strict the four-eyes gate is. A new class is proposed from its place on the ladder (bottom → Lav, top → Høy, otherwise Middels) and can be overridden.
• Remove a class that industry or country rows still point at and those rows move to the nearest remaining class; the confirmation says so («Rader som peker på klassen flyttes til nærmeste klasse»), so you never meet a technical error.
• The boundaries interlock. Change a class's Maks and the next class's Min follows to Maks+1, and the other way round; values are clamped so a class can never swallow its neighbour or be inverted, and each keeps a span of at least one point. What is still wrong is listed in a yellow hint («overlapp mellom …», «hull mellom … (X–Y er udekket)», «mangler maksgrense») ending «Endelig validering skjer ved lagring.» On save the server requires at least one class, unique keys and a contiguous scale with an open top.

Section 3 · Tjenesteområder

• A drag-ordered list of service areas — five by default: Revisjon, Regnskap, Skatt & MVA, Transaksjoner (attestasjoner) and Rådgivning. Name, short name and description are edited in the list and saved when you leave the field, beside an editable Poeng field, an on/off switch and a delete action.
• The points field carries the chip «poeng versjoneres med modellen»: these points are the Tjenestetype factor's outcomes and follow model publishing, while the name and the other fields save immediately.
• Deactivating an area linked to project templates warns first («…koblet til N prosjektmal(er) … Området skjules for nye oppdrag; eksisterende data beholdes»). Deletion is always confirmed, and an area in use cannot be deleted at all: a warning lists the blockers («i bruk: X prosjektmaler, Y publiserte skjema-tagger, Z modell-utfall. Deaktiver området i stedet.»).
• Project templates attach per area as chips with a remove cross, plus a «+ Legg til mal…» dropdown showing each template's current owner («— i dag: Regnskap») and the note «‹Mal› flyttes fra ‹Område›.» when you pick one owned elsewhere. The attachment is authoritative: the template is moved.
• «Nytt tjenesteområde» is a creation row taking a name and a short name; a stable key is derived from the name, with æ, ø and å transliterated.

Section 4 · Kontrolltiltak

• One card per measure. Four ship: four-eyes control (HVA approval), «Forsterket kundekontroll (KYC)», «Forsterket løpende overvåkning» and stricter transaction thresholds. Each has an icon, a type badge (Sperre / Steg / Løpende), a phase badge (I syklus / Løpende drift) and an on/off switch. Core measures — four-eyes control is required by the Money Laundering Act §35 — show «Kjerne — kan ikke slås av»: the switch is disabled and the system keeps them active.
• A condition builder per measure: «Slår inn når [minst én av | alle] betingelsene er oppfylt». Each row has an enable checkbox — disabled rows are kept but ignored, and the default four-eyes row «± mer enn 15» ships disabled — then a field, an operator belonging to that field, and value editing shaped to the operator.
• The fields are Vurdert (foreslått) klasse, Vurdert vs. Klassifisert, Manuell justering, Risikofaktor, Signal-kilde and Syklus-trigger. The operators are «er en av», «er minst», «er forskjellig/høyere/lavere enn Klassifisert», «endrer klassen», «± mer enn», «er over», «er under» and «har treff».
• Values are edited as class chips, a single class choice, a point number («± mer enn» is a magnitude, so no negatives), a factor choice limited to the nine discrete factors (PEP, Sanksjon, Geografi, Kontantintensiv, Eierstruktur, Fullmaktshaver, Virtuell valuta, Rapporteringspliktig, MF-rapport tidligere), source chips (Stø / BRREG / Altinn / Manuell) or trigger chips (Onboarding / Periodisk / Hendelse (varsel) / Manuell / Tjeneste-endring).
• Every condition is previewed as a Norwegian sentence, and a measure with none shows «Ingen betingelser — tiltaket slår aldri inn». «Legg til betingelse» adds a row; the four default measures also offer «Tilbakestill til standard», which confirms first («Egne betingelser på tiltaket går tapt»).

Section 5 · NACE-tabell (industries)

An info banner states that the points on each row come from the factor Bransje (NACE). The risk level column is the configuration's own risk classes — exactly the ones you edit in section 2, as coloured pills; there is no separate industry vocabulary beside the classes any more. The ladder card «Poeng per risikonivå» shows one chip per class with the points that factor awards it:

The chips are derived and read-only here; the points are edited on the factor, under Risikofaktorer, and a class with no outcome of its own contributes 0. A search field takes a code or an industry name and reports «N av M bransjer». The table — around 1 500 rows from the instance's own NACE register — has a class dropdown per row and a derived, read-only points column. New industries appear by themselves: the next time you open a draft, NACE codes added since the model was created are inserted mid-ladder.

Section 6 · Land-tabell

The country table scores foreign payments and geographic risk using the same risk classes as the industry table; there is no separate country scale with «Lavrisiko (Norden) / EØS-OECD / Forhøyet / FATF-listet / Sanksjonert». Its «Poeng per risikonivå» card shows one derived chip per class with the points the Geografi factor awards:

• Every country, not 39. The table is fed from Origo's own country register — the whole ISO 3166 list, some 249 countries — instead of a hardcoded 39, and new countries are added to the draft automatically. The default class comes from a curated list plus the country's region: the Nordics, the EU/EEA and North America start at Lav, the rest at Normal.
• Region is master data of its own. Every country belongs to one of ten regions — Norden · EU/EØS · Europa · Nord-Amerika · Latin-Amerika · Karibien · Asia · Midtøsten · Afrika · Oseania. Column and filter read from there, so the filter list is the same in every configuration.
• Search by country, code or region, filter by region, and a counter reports «N av M land». Rows carry the class dropdown and the derived points.

Section 7 · Reberegningstriggere

A list of switches over the events that trigger automatic rescoring. Each row carries a source badge — Visena, BRREG, Stø, Altinn or Bruker — naming where the signal comes from.

The Periodisk row carries the note «Frekvens per risikoklasse — konfigureres under Risikoklasser» and a live frequency chip computed from the classes in the draft, so it follows the configuration's own ladder: «Lav 24m · Normal 18m · Høy 6m» for a new configuration, and still four entries on an older four-class model.

Section 8 · Modellversjon

A read-only version history, newest first: version, a Norwegian date («8. mars 2026»), user and change note, under «Aktiv versjon vN — sist endret … av …». The section repeats the rule that matters most: assessments are frozen against the version they were made on.

Preview and publishing

Forhåndsvis konsekvens

The dialog runs the draft against the real customer portfolio and compares it with the published model: a KPI row (customers evaluated, upgrades, downgrades), the class distribution before → after, «Endrede parametre» — a plain-language summary of what you changed — and the customers that change class, worst first (upgrades at the top, then the highest new class, then the largest change in points), each with before → after class pills and a signed point difference. The list shows up to 500 rows, and the total is always stated. The dialog is read-only; publishing happens from the top of the tab.

Publiser ny versjon

1. Confirm. A dialog shows the change list and an editable change note, and proposes the next version number (v3.2 → v3.3).
2. The server validates the draft: a contiguous class band, an open top class, review intervals of 1–60 months, unique threshold parameters, a complete factor set and legal measure conditions. Breaches come back as Norwegian messages.
3. The draft becomes the new active version and the toast reads «Ny modellversjon er publisert.» Existing assessments stay frozen on their version; the new model governs future calculations and recalculations.

The other tab, Skjemabygger, builds the KYC forms these measures dispatch — see KYC form builder Conditions and skip rules.