ketl cloud
Sanksjons-screening — kunnskap
For bank og fintech

KYB-screening i 6 trinn — fra onboarding til mistanke-melding

Hvitvaskingsloven og FTs rundskriv 8/2024 setter forventninger til tempo og sporbarhet — men ikke konkrete SLA-tall. Sjekklisten under foreslår SLA per trinn slik at både onboarding, løpende batch-screening, transaksjons-screening og alarm-håndtering rammes av audit-bare timestamps.

hvitvaskingsloven §§ 4-30sanksjonsloven § 4FT-rundskriv 8/2024FATF Rec. 6 + 7

6 trinn — onboarding til myndighets-rapport

Trinnene er sortert etter tids-rekkefølge i compliance-livssyklusen, ikke etter SLA. Hvert trinn har trigger-fase og maks SLA.

  1. 1
    Initiell screening ved kundeforhold-etablering
    Screen hovedkunde + alle UBO-er (≥25 % eierskap) mot alle 5 lister. Krav per hvitvaskingsloven § 13. Block-screening hvis match — eskaler til AML-team.
    OnboardingSLA 2 t
  2. 2
    Risikoklassifisering
    Hvis treff (men ikke block) eller PEP-flagg: forsterket kunde-DD per § 17. Vurder geografisk risiko, transaksjonsmønster og kunde-segment.
    OnboardingSLA 24 t
  3. 3
    Daglig batch-screening av portefølje
    Re-screen alle aktive kunder mot oppdaterte lister. Maks 24 t latency mellom liste-publisering og oppdaget hit. FT-rundskriv 8/2024 krever dette for høyrisiko.
    LøpendeSLA 24 t
  4. 4
    Transaksjons-screening (real-time)
    Screen motpart i alle internasjonale betalinger > 100 000 NOK eller mot høyrisiko-jurisdiksjoner. Block ved bekreftet hit — ikke gjennomfør.
    TransaksjonReal-time
  5. 5
    Alarm-håndtering ved ny listing
    Eksisterende kunde kommer på liste: frys konto innen 24 t, varsle AML-team, vurder rapportering til Etterretningstjenesten (Økokrim).
    AlarmSLA 24 t
  6. 6
    Rapportering til myndighet
    Bekreftet treff: rapport til Etterretningstjenesten via AltinnSAF (mistanke-melding). Audit-logg: 5 år retensjon per § 30.
    AlarmSLA 72 t

Batch-screening-config (eksempel)

Pro-tier eksponerer batch-screening via REST og Cloud Scheduler. Eksempelet under er en typisk daglig kjøring som screener hele kundeportefølje + nye listings siden sist.

{
  "tenant": "fintech-as",
  "schedule": "0 6 * * *",          // 06:00 hver dag
  "scope": {
    "kunder": "alle-aktive",
    "ubo": true,                    // også UBO-kjeder ≥25%
    "lister": ["EU", "UN", "UK_OFSI", "US_OFAC", "NO_UD"]
  },
  "matching": {
    "fuzzy_threshold": 0.92,
    "include_aliases": true,
    "include_dob_match": true
  },
  "alarm": {
    "kanal": ["webhook:https://fintech.no/aml/sanksjon-hit"],
    "min_score": 0.85,
    "include_falsepositive_history": true
  },
  "audit": {
    "retain_years": 5,
    "format": "json",
    "include_decision_chain": true
  }
}

Roller og varslings-kjeder

AML-team

Vurderer treff fra batch og real-time screening. Avgjør om treff er reelt hit eller falsk positiv. SLA: 24 t.

MLRO

Money Laundering Reporting Officer — endelig beslutning om mistanke-melding til Etterretningstjenesten via AltinnSAF. SLA: 72 t.

Compliance-styre

Aktiveres ved alvorlige treff — vurderer kunde-frysing, lukking av forhold og rapportering til Finanstilsynet.

Audit-eksport for Finanstilsynet

Finanstilsynet krever sporbar logg med beslutnings-kjede. Hvitvaskingsloven § 30 definerer 5-års-retensjon — men flere banker velger lengre per egen risikovurdering.

Hva inngår
  • Per-kunde screening-historikk med tidspunkt
  • Treff og falsk-positiv-vurderinger med begrunnelse
  • Hvilke lister og versjoner ble brukt
Format
  • JSON (maskinlesbar)
  • PDF (signert, for arkivering)
  • CSV (for videre analyse)
Retensjon
  • Pro: 5 år (lov-minimum § 30)
  • Enterprise: konfigurerbar opp til 25 år
  • On-prem-mulighet for sensitiv portefølje

FAQ for bank og fintech

Trenger vi en separat OFAC-screening i tillegg?

Hvis dere prosesserer USD eller har korrespondent-bank-relasjoner: ja, OFAC SDN er obligatorisk. Ketl inkluderer SDN i konsolidert flate.

Hvor lenge må vi lagre screening-loggen?

Minst 5 år etter at kundeforhold er avsluttet (hvitvaskingsloven § 30). Enterprise-tier i ketl gir konfigurerbar retensjon opp til 25 år.

Hvordan håndterer ketl PEP-listene?

PEP-status er ikke en sanksjon i seg selv, men trigger forsterket DD. Ketl konsoliderer norske + internasjonale PEP-kilder som tilleggs-feed på Pro+.

Kan vi integrere ketl mot eksisterende KYB-system?

Ja. REST API (X-Cache-Status + RFC 7807-feil) eller MCP-tools (`sanksjoner_search`, `sanksjoner_entity`). Enterprise inkluderer custom batch-jobber via Cloud Scheduler.

Pilot for KYB-team

90-dagers pilot for fintech og banker som vil teste batch- screening, real-time transaksjons-screening og audit-eksport. Inkluderer onboarding mot eksisterende KYB-stack.

Pilot tilgjengelig fra Q3 2026 — connector-pipeline og batch- jobb-orkestrering er i sluttfasen.

ketl cloud
DataApperMCPPriser
AI-transparensPersonvernSikkerhet

© 2026 ketl cloud

build c372edd · 2026-05-11 14:18:12 UTC