Loan and Guarantee system

Konkurransen (competitive dialogue) gjelder anskaffelse av et Loan and Guarantee Management System for Eksfin. Løsningen skal støtte hele livsløpet for lån og garantier inkl. portal for dialog med banker, kredittsaksbehandling, etablering av transaksjons-/avtalestrukturer (inkl. disbursement- og utilization schedules), beregninger (renter/kommisjoner/risk premium/fees), løpende overvåking og oppfølging, endringer/restrukturering, samt integrasjon mot eksisterende systemer (CRM, regnskap, dokumenthåndtering) og relevante eksterne data. Kontraktens varighet anslås 10–15 år (SSA-standardavtaler benyttes som utgangspunkt).

• Leverandøren må være registrert i foretaksregister/profesjonsregister/handelsregister i landet den er etablert.

  Dokumentasjon: • Norske selskaper: Certificate of Registration / registreringsbevis i foretaksregister/profesjonsregister • Utenlandske selskaper: Offisielt dokument som viser registrering i tilsvarende register i etableringslandet

  Kilde: Eksfin Competition Rules, kap. 2.3.1 (Qualification phase) – Supplier's Registration, Authorisation etc.
• Leverandøren skal ha tilstrekkelig økonomisk og finansiell kapasitet til å kunne gjennomføre kontrakten.

  Dokumentasjon: • Regnskap/finansregnskap for siste tre år • Kredittvurdering basert på senest kjente finansielle tall, utført av kredittopplysningsbyrå lisensiert til slik virksomhet (Evt. annet dokument dersom legitime grunner til manglende dokumentasjon.)

  Kilde: Eksfin Competition Rules, kap. 2.3.1 – Supplier's Economic and Financial Capacity
• Leverandøren skal ha betalt alle skatter og avgifter. (Kun relevant for norske leverandører.)

  Dokumentasjon: Skatteattest for merverdiavgift og skatteattest for skatt (for norske leverandører). Attest må ikke være eldre enn 6 måneder regnet fra fristen for å sende request to participate.

  Kilde: Eksfin Competition Rules, kap. 2.3.1 – Tax Certificate
• Leverandøren skal ha profesjonell kompetanse: minst tre relevante og sammenlignbare leveranser/prosjekter knyttet til digital løsning for behandling og forvaltning av lån og/eller garantier i finansmiljø.

  Dokumentasjon: For hver referanse: kundens navn og kontaktinfo, omfang/verdi/varighet, beskrivelse av hva som inngikk i leveransen, kort begrunnelse for relevans, samt opplysning om hvor stor andel samarbeidende enheter hadde i leveransen.

  Kilde: Eksfin Competition Rules, kap. 2.3.1 – Supplier’s Technical and Professional Qualifications (Professional capabilities 1)
• Leverandøren skal beskrive hvordan løsningen muliggjør effektiv og moderne støtte for Eksfins kjerneprosesser for lån/garantier (teknisk/operasjonell evne).

  Dokumentasjon: Beskrivelse av hvordan leverandørens løsning støtter Eksfins kjerneprosesser (effektiv og moderne support).

  Kilde: Eksfin Competition Rules, kap. 2.3.1 – Supplier’s Technical and Professional Qualifications (Professional capabilities 2)
• Leverandøren skal ha tilstrekkelig kapasitet og kompetanse/organisasjon til å gjennomføre kontrakten.

  Dokumentasjon: Oversikt/beskrivelser av: organisasjonsstruktur inkl. teknisk personell/enheter, setup av verdikjede og subcontractors, styring av leverandørkjede og sporingssystemer, hvilke deler som eventuelt subcontractes, nødvendige materialer/teknisk utstyr for å utvikle/forvalte digitale løsninger, samt hvordan implementering ved Eksfin utføres.

  Kilde: Eksfin Competition Rules, kap. 2.3.1 – Organisation and Capacity
• Kvalitetsstyring: leverandøren skal ha etablerte rutiner/praksis for kvalitetssikring.

  Dokumentasjon: Kopi av ISO 9001 (eller tilsvarende) utstedt av akkreditert sertifiseringsorgan, eller alternativt beskrivelse av leverandørens kvalitetssikringssystem.

  Kilde: Eksfin Competition Rules, kap. 2.3.1 – Quality Management
• Miljøstyring: leverandøren skal ha etablerte rutiner/praksis for miljøstyring.

  Dokumentasjon: Kopi av ISO 14001 (eller tilsvarende) utstedt av akkreditert sertifiseringsorgan, eller alternativt beskrivelse av miljøstyringssystem.

  Kilde: Eksfin Competition Rules, kap. 2.3.1 – Environmental Management
• Informasjonssikkerhet: leverandøren skal ha etablerte tilfredsstillende metoder for informasjonssikkerhet.

  Dokumentasjon: Kopi av ISO 27001 (eller tilsvarende) utstedt av akkreditert sertifiseringsorgan, eller alternativt beskrivelse av informasjonssikkerhetssystem.

  Kilde: Eksfin Competition Rules, kap. 2.3.1 – Information Security
• Dersom leverandøren bruker underleverandører eller baserer seg på andre enheters kapasitet, må det dokumenteres at leverandøren disponerer nødvendige ressurser.

  Dokumentasjon: Letter of commitment (for å dokumentere ressursdisponering), samt separate ESPD-skjema for relevante underleverandører/partner(e). Endringer i samarbeidspartnere krever kontraktsmyndighetens skriftlige samtykke.

  Kilde: Eksfin Competition Rules, kap. 2.3.1 – Groups of Suppliers and Subcontractors

• Leverandøren må sende request to participate innen fristen og via e-procurement-verktøyet (KGV / eu-supply.com).Kilde: Eksfin Competition Rules, kap. 2.2 (Timetable) og kap. 2.3.1 (Request to Participate)
• Fylle ut elektronisk self-declaration form (ESPD) i KGV og bekrefte at kvalifikasjonskravene oppfylles.Kilde: Eksfin Competition Rules, kap. 2.3.1 – Qualification requirements
• Sende inn alle etterspurte dokumenter sammen med signert Appendix 2 Request Form (Request form 2026-10).Kilde: Eksfin Competition Rules, kap. 2.3.1 (Qualification requirements) og kap. 2.3.1 (Content and Structure of the Application to Participate)
• Ved innsendelse av request to participate: levere følgende dokumentasjon (opplistet i grunnlaget): application letter, Certificate of Registration, dokumentasjon for økonomisk og finansiell kapasitet, tax certificate (for norske), completed ESPD i KGV, og dokumentasjon for tekniske og profesjonelle kvalifikasjoner (professional capabilities, organisation/capacity, quality management, environmental management, information security).Kilde: Eksfin Competition Rules, kap. 2.3.1 – Content and Structure of the Application to Participate
• Appendix 2 Request Form: utfylle opplysninger om organisasjon/kontaktperson/elektronisk signering, og signere erklæringen.Kilde: Eksfin Appendix 2 – Request Form 2026-10 (Declaration and signature)
• Under competitive dialogue: levere solution proposal (og POC/clarifications) elektronisk via eu.eu-supply.com innen frister, og kommunikasjon via Teams og/eller på Eksfins lokasjon.Kilde: Eksfin Competition Rules, kap. 2.3.2 – Phase 2: Dialogue phase
• I tender phase: innlevere endelig tilbud elektronisk via eu.eu-supply.com innen frist; siste innleverte tilbud regnes som endelig.Kilde: Eksfin Competition Rules, kap. 2.3.3 – Submission of Tenders

Innleveringsvilkår fra kunngjøringen

Frist for forespørsel/tilbud

14.10.2026

Språk

norsk, English

Elektronisk katalog

Ikke tillatt

• Systemet skal fungere som “single source of truth”: data skal registreres én gang og gjenbrukes, og støtte høy datakvalitet via UI, valideringer, sjekklister og brukerveiledning.Kilde: Eksfin Appendix 1 – Statement of Requirements 2026-10, kap. 3 (Design principles and guiding requirements)
• API-first og event-driven arkitektur: støtte sømløs integrasjon med eksterne datakilder/offentlige registre og Eksfins støttesystemer; events/dataendringer skal kunne trigge prosesser/oppfølging; støtte automatiserte vurderinger/beslutninger basert på regler med menneskelig overstyring.Kilde: Eksfin Appendix 1, kap. 3
• Aktiv overvåking og kontroll: full sporbarhet og audit trail for beslutninger, endringer og dokumenter; automatiske varsler/notification for effektiv drift og oppfølging.Kilde: Eksfin Appendix 1, kap. 3
• Integrasjon og systemlandskap: støtte import/lagring av søknader, portal for bankers registrering/monitorering og kommunikasjon, samt integrasjon mot CRM, regnskap, dokumenthåndtering og Teams; overføring til NOARK5-arkivering (Elements/Sikri nevnes som i dag).Kilde: Eksfin Appendix 1, kap. 2.1 og kap. 4.1 (Portals and integrations) og kap. 4.2.1 (Document management)
• Traceability/audit: beslutninger og endringer skal være sporbart; audit trail for endringer/hendelser i livsløpet til lån/garantier.Kilde: Eksfin Appendix 1, kap. 3 og kap. 6.3 (Data security, integrity and compliance)
• Beregninger: parameterstyrt beregningsmotor som støtter renter (fast/flyting) med referanserater (NIBOR/EURIBOR/SOFR el. lign.), day count conventions, kommisjon/risk premium/fees for garantier, payment plans og utilization schedules, samt recalculations med effective dating.Kilde: Eksfin Appendix 1, kap. 5.2 (Calculations), spesielt 5.2.1–5.2.4 og 5.2.3
• Overvåking og oppfølging: kontinuerlig monitoring av forventede vs faktiske betalinger og avvik, utilization schedules, betalingshåndtering inkl. delbetalinger og endelig oppgjør, samt generering av betalingsvarsler/notices.Kilde: Eksfin Appendix 1, kap. 5.3 (Monitoring and follow-up) 5.3.1–5.3.3
• Skjemabasert bokføring: alle lån/garantier skal bokføres korrekt per regjeringsdefinerte scheme, med egne bankkontoer og rapportering; systemet må støtte allokering av én betaling på flere konti basert på schemefordeling.Kilde: Eksfin Appendix 1, kap. 5.3.3 (Payment handling)
• Endringer/restrukturering: støtte kontrollerte endringer i betaling/prising/valuta og evne til split/merge, konvertering (f.eks. garanti til krav, default til equity, realisasjon av sikkerheter), og refinancing/re-etablering av transaksjon.Kilde: Eksfin Appendix 1, kap. 5.4 (Amendments and changes to terms) og 5.4.2
• Teknologi/cybersikkerhet: leverandøren må dokumentere modern design, oppdatert teknologi, metode/prosesser for kontinuerlig modernisering; løsning designet med helhetlig sikkerhetsperspektiv og oppdatert sikkerhetspraksis.Kilde: Eksfin Appendix 1, kap. 6 (Technology and architecture), særlig 6.2
• Implementering/leveranse/operasjon: leverandøren skal beskrive implementasjonsmetode og leveransemodell, datamigrering, testing/QA, go-live strategi, samt support- og endrings-/release management i drift.Kilde: Eksfin Appendix 1, kap. 7 (Implementation project) og kap. 8 (Operations and system management)

• Endelig kravspesifikasjon (funksjonell scope, arkitektur, systemgrenser, leveranse-/kommersiell modell) er ikke endelig; den skal avklares og presiseres gjennom dialoguefasen (Appendix 1 kap. 1.3 og Competition Rules kap. 1.2.2).
• Finansiell ramme (totalverdi) i kunngjøringen er «høyst usikker» og ikke en fast grense; scope/delivery/architecture vil bli avklart i dialogen (Competition Rules kap. 1.2.3).
• Vekting og eventuelle sub-criteria for tildeling er ikke endelig; skal fastsettes i dialogen og senest i invitasjon til endelig tilbud (Competition Rules kap. 3.1).
• Kontraktsform/SSA-variant (SSA-L/K/V/S/O) og eventuell tilpasning av standardavtaler kan endres/avklares gjennom dialog, inkludert avhengig av on-prem vs cloud (Competition Rules kap. 1.2.4).
• Noen dokument-/implementeringsdetaljer (hvordan dokumenthåndteringsprosessen implementeres, og omfang/innhold av case task/POC) kan være under avklaring i senere faser.

Punkter der konkurransedokumentene åpner for tolkning, og der en presisering fra oppdragsgiver kan ha betydning for prising og risiko. Spørsmål kan stilles innen fristene som er angitt i konkurransegrunnlaget.

1. I Appendix 1 (Statement of Requirements) beskrives at systemet skal fungere som «single source of truth», og at «data shall be captured once and reused across the solution». Kan dere avklare hvilke sentrale datatyper og datakilder som i dag er «master» (CRM, regnskap, dokumenthåndtering, evt. andre) – og hvilke av disse dere ønsker at det nye låne- og garantisystemet skal bli master for?

   Hvorfor det er verdt å spørre: For å gi et presist og kostnadsriktig tilbud (datamodell, integrasjoner og migrering) må leverandøren vite hvilke systemer som skal være autoritative kilder og hva som skal synkroniseres/duplicate-res.

   Kilde: Appendix 1, kap. 3 «Design principles…» (single source of truth), samt kap. 2.2 «Eksfin’s system landscape»

2. I Appendix 1, kap. 4.1 beskrives en nettbasert portal for bankene med registrering/monitorering av «transactions and portfolios», inkludert at Eksfin skal håndtere premie- og garantibetalingsstrømmer og portefølje-basert regnskap/rapportering. Kan dere spesifisere forventet omfang/volum for (1) antall banker og aktive brukere per bank, (2) antall cases/år, og (3) antall samtidige porteføljer/transaksjoner?

   Hvorfor det er verdt å spørre: Tildelingsmodell og pris vil påvirkes sterkt av ytelse, lisenskostnader og dimensjonering i portal/integrasjon; uten volumanslag er det vanskelig å prise riktig.

   Kilde: Appendix 1, kap. 4.1 «Portals and integrations»

3. I Appendix 1, kap. 4.2.1 «Document management» står det at Teams brukes i dag for dokumentproduksjon, og at ferdige dokumenter skal overføres til et NOARK5-godkjent arkiv (Elements fra Sikri). Kan dere beskrive hvilken dokumenttype-/metadata-struktur og hvilke integrasjonspunkter dere forventer (f.eks. automatisk overføring ved «case completed», DOI/arkivnøkler, revisjonsversjonering, statusflyt)?

   Hvorfor det er verdt å spørre: Dokumentflyt og krav til metadata/arkivversjonering er ofte en stor kostnads- og risiko-driver; leverandøren trenger konkrete forventninger for å løse korrekt i implementering og drift.

   Kilde: Appendix 1, kap. 4.2.1 «Document management»

4. I Appendix 1, kap. 5 «Calculations» og særlig 5.2.3 «Recalculation and effective dating» beskrives behov for recalculations bakover/framover og sporbarhet. Kan dere avklare hva som skal være «rule of truth» ved recalculation: Er det (a) registrerte historiske beslutninger/effektivdatoer som låser beregningene, eller (b) er det ønsket at systemet skal re-kalkulere og korrigere tidligere periodiserte beløp etter nye vilkår?

   Hvorfor det er verdt å spørre: Dette påvirker både datamodell (versjonering), historikkbevaring, etterkontroll/revisjon og implementeringskompleksitet; leverandøren må forstå forventet regnskaps-/kontrolllogikk.

   Kilde: Appendix 1, kap. 5.2.3 «Recalculation and effective dating» (og evt. 5.2.5 «Periodization…»)

5. I Appendix 1, kap. 5.3.3 «Payment handling» beskrives at en enkelt betaling kan måtte allokeres til flere scheme-kontoer/ledgere («allocation and booking of a single payment across multiple accounts»). Kan dere avklare hvordan dere ønsker at allokeringen skal bestemmes i praksis (f.eks. faste fordelingsnøkler per scheme, prosent/andel per credit case, regelstyring basert på kontraktsparametere), og om allokering skal være fullt automatisert eller ha godkjenningsflyt?

   Hvorfor det er verdt å spørre: Allokeringsregler og godkjenningsløp påvirker både funksjon, brukerflyt og risiko ved feilprising/feil booking.

   Kilde: Appendix 1, kap. 5.3.3 «Payment handling»

6. I Appendix 1, kap. 5.3.4 «Monitoring of covenants, collateral and credit case conditions» fremgår det at systemet skal gi oversikt over forfalte/overdue/manglende items og støtte «structured finalization of transactions when obligations are fulfilled». Kan dere avklare hvilke covenants/kravstyper (minstekrav) som er prioriterte å støtte i første leveranse, og hva som er «must-have» vs «nice-to-have» før neste versjon?

   Hvorfor det er verdt å spørre: Uten prioritering på scope-nivå kan leverandøren ende opp med feil implementeringsrekkefølge og uklarhet rundt akseptanse for «finalization».

   Kilde: Appendix 1, kap. 5.3.4 «Monitoring of covenants…»

7. I Appendix 1, kap. 6 «Technology and architecture» og kap. 6.2–6.3 beskrives API-first, cyber security og tilgangsstyring/audit trail, men kontraktsform og deployment (on-prem vs cloud) er fortsatt åpent. Kan dere bekrefte om dere har preferanse for (1) driftmodell (on-prem/cloud/hybrid) og (2) hvordan dere forventer at identity/access (SSO) skal løses (f.eks. integrasjon mot eksisterende løsning hos Eksfin) for en offentlig virksomhet?

   Hvorfor det er verdt å spørre: Dette er avgjørende for arkitektur, sikkerhetsleveranse og integrasjonskostnader; leverandøren må vite hva som vektlegges før endelig tilbud.

   Kilde: Appendix 1, kap. 6 «Technology and architecture» samt Competition Rules kap. 1.2.4 (SSA/tilpasning knyttet til on-prem vs cloud)

8. I Appendix 1, kap. 7.5 «Implementation timeline» og kap. 7 generelt beskrives behov for plan, test, go-live og overgang til drift. Kan dere avklare hvilke milepæler og beslutningspunkter dere forventer i dialog/tender (f.eks. POC-kriterier, pilotperiode, akseptansekriterier for go-live), og om det legges opp til stegvis utrulling (incremental) eller «big-bang» for første produktgenerasjon?

   Hvorfor det er verdt å spørre: Plan og akseptansekriterier påvirker både prosjektkost og tilbudets gjennomførbarhet/risiko; leverandøren må kunne prise korrekt.

   Kilde: Appendix 1, kap. 7.5 «Implementation timeline» og 7.6 «Go-live strategy and stabilization»

9. I Appendix 1, kap. 8 «Operations and system management» beskrives support, incident/change og release management. Kan dere avklare forventet servicenivå i praksis (f.eks. SLA for P1/P2 hendelser, responstid, tilgjengelighet/uptime-forventning, og hvordan ønsket endringshåndtering ser ut for regel-/beregningsendringer som påvirker accounting)?

   Hvorfor det er verdt å spørre: Drifts- og vedlikeholdskrav er direkte kostnadsdrivere og påvirker hva som kan tilbys innenfor pris/risiko.

   Kilde: Appendix 1, kap. 8.1–8.3 (Support model, Incident/Change management, Deployment/release management)

10. I Appendix 1, kap. 9 «Pricing and price model» og Competition Rules kap. 3.1 fremgår det at både implementering og pågående kostnader vil vektlegges, men endelig prisramme er ikke avklart. Kan dere tydeliggjøre hvilke pris-komponenter dere forventer at leverandøren detaljerer i endelig tilbud (lisens/abonnement vs engang/opsjon, integrasjons- og migreringskost, videreutvikling/videreutviklingsrate, og eventuelle volumtrappetrinn)?

    Hvorfor det er verdt å spørre: Leverandøren må vite prissplitt/komponenter for å kunne svare på konkurransegrunnlag og sikre sammenlignbarhet mellom leverandører.

    Kilde: Appendix 1, kap. 9 «Pricing and price model» samt Competition Rules kap. 1.2.3 og 3.1 (høy/lav prioritet mellom kvalitet og pris)