Sikkerhed og tillid
Sikkerhed hos BankConnector
Vi sender betalingsinstrukser til banker på vegne af vores kunder. Vi opbevarer eller overfører aldrig selv penge. Her kan I se, hvordan vi beskytter instrukserne og de bankdata, vi får tilbage.
Sikkerhedskontroller
Sådan beskytter vi jeres betalinger
Sikkerhed i produktet
Godkendelse af betalinger
- Godkendelsesregler kan afhænge af beløbet, kræve flere godkendere eller kræve, at de godkender i en fast rækkefølge. En virksomhed kan bestemme, at ingen må godkende sine egne betalinger.
- Lempes en godkendelsesregel, skal en anden administrator også godkende ændringen. Ophæves forbuddet mod at godkende egne betalinger, får alle andre administratorer besked.
- Der bliver sendt præcis det, som godkenderne har godkendt: en betaling kan ikke ændres, når den er indsendt, og en betalingsfil, der indsendes to gange, markeres som en mulig dobbeltbetaling.
- Signerede betalingsfiler går direkte til banken. Vi sender aldrig en signeret fil tilbage til det system, der bad om den.
Jeres egne kontroller
- Administratorer kan kræve tofaktorgodkendelse for alle i virksomheden, og godkendere, der bruger den, indtaster en ny kode for at godkende.
- Der er tre roller: administrator, godkender og læser, der kun kan se og ikke kan ændre noget.
- Ved login tjekker vi adgangskoden mod ofte brugte og lækkede adgangskoder og bremser gentagne forsøg. En session afsluttes efter 30 minutter uden aktivitet eller efter 8 timer i alt. Brugerne kan se og afslutte deres egne sessioner og får en mail, når deres adgangskode eller tofaktorindstilling ændres, eller efter mistænkelige loginforsøg.
- I kan hente jeres aktivitetslog ind i jeres egen overvågning via API'et.
Kryptering
- Al trafik krypteres med TLS 1.2 eller nyere, også forbindelsen mellem applikationen og databasen.
- Diske, database og backups er krypteret ved lagring. Indholdet af betalinger, adgangsoplysninger til bankerne, signeringsnøgler og godkenderes identitetsdata krypteres desuden felt for felt med AES-256-GCM, før de når databasen.
Kunderne holdes adskilt
- Hver forespørgsel knyttes til virksomheden bag den person eller det system, der sender den, aldrig til et id i selve forespørgslen.
- Databasen håndhæver den samme adskillelse med sikkerhed på rækkeniveau (row-level security), så en databaseforespørgsel, der ikke er knyttet til en virksomhed, ikke returnerer noget.
Revisionsspor
- Hver ændring skrives i en log, som databasen ikke lader nogen ændre eller slette. Hver post er kædet sammen med den forrige, så en ændret, fjernet eller flyttet post afsløres, når kæden kontrolleres.
- I kan selv køre kontrollen fra aktivitetsloggen.
Bankforbindelser
- Hver bankforbindelse bruger den signering og kryptering, banken kræver: EBICS, webservices eller SFTP.
- Bankernes certifikater og servernøgler er fastlåst. Viser banken et andet certifikat eller en anden nøgle, stopper forbindelsen. Signeringsnøgler til banken kan ikke eksporteres fra platformen.
Infrastruktur og drift
Hosting
- Driftsmiljøet kører hos Amazon Web Services i Stockholm i Sverige, og kundedata opbevares samme sted.
- AWS står for den fysiske sikkerhed, og vi har gennemgået AWS' SOC 2 Type II-rapport.
- Cloudmiljøet er beskrevet i kode, så det kan genopbygges automatisk ud fra koden.
Netværk og administrativ adgang
- Kun webtrafik når serveren fra internettet. Databasen kan ikke nås fra internettet og tager kun imod forbindelser fra applikationsserveren.
- Medarbejdere kommer kun ind på cloudkontoen via single sign-on med flerfaktorgodkendelse og sessioner på højst fire timer.
- Hver administrativ handling på cloudkontoen registreres i en log, hvor ændringer ikke kan skjules.
Adgangsstyring
- Hver person har én identitet og kun de rettigheder, der er nødvendige. Delte konti er ikke tilladt.
- Login med flere faktorer er påkrævet på vores cloudkonto, vores kodeplatform, vores adgangskodeadministrator og administrationskonsollerne hos de leverandører, som vores tjeneste kører hos.
- Alle adgangsnøgler til systemer er registreret med ejer og med den dato, hvor de næste gang skal udskiftes.
Overvågning
- Cloudkontoen overvåges automatisk for trusler. Fund med middel eller højere alvorlighed bliver sendt til en medarbejder.
- Vi får alarmer om serverens tilstand, databasebelastning, mislykkede backups og mange applikationsfejl på kort tid.
- Vi tjekker tilgængeligheden hvert minut udefra, ikke fra vores egne servere, og viser den på vores statusside.
Backup og genetablering
- Databasen kan gendannes til ethvert tidspunkt inden for de seneste 14 dage. Derudover tages der hver time krypterede kopier med integritetskontrol, som gemmes i 90 dage.
- Vores mål er, at vi højst mister 15 minutters data, og at tjenesten kører igen inden for 2 timer. I vores seneste fulde gendannelsestest var data tilbage på cirka 10 minutter.
- Hver måned øver vi gendannelse fra de backups, der tages hver time.
- Vores beredskabsplan dækker tab af databasen, serveren, AWS-regionen, en vigtig leverandør eller en nøgleperson.
Ikke bundet til én cloududbyder
- Platformen kører på standardcontainere, PostgreSQL og S3-kompatibel lagring, og kernen bruger ingen tjenester, der kun findes hos AWS.
- Vores testmiljø (sandbox) kører allerede den samme applikation hos en anden udbyder.
Udvikling
Ændringsstyring
- Alle ændringer skal bestå vores frigivelseskontrol, før de kommer i drift: typetjek, linting, tjek af databasemigreringer, mere end 30.000 automatiske test, scanning for hemmeligheder, regressionstest af bankintegrationerne og en opstartstest af den færdigbyggede applikation.
- Ændringer i infrastrukturen udføres af en person efter en plan, der er gennemgået. Udgivelser er faste, mærkede versioner, der ikke kan ændres, og driftsmiljøet opdateres kun fra en mærket version.
Håndtering af sårbarheder
- Afhængigheder gennemgås ved hver ændring, og et fund med høj alvorlighed stopper buildet. Opdateringer af afhængigheder foreslås automatisk, og alt, der lægges op i kodebasen, scannes for lækkede hemmeligheder.
- Vores cloudopsætning, offentlige endpoints og kode scannes med open source-sikkerhedsscannere: Prowler, nuclei og Opengrep.
- Vi vedligeholder en trusselsmodel og en vurdering af hver enkelt kontrol efter OWASP ASVS niveau 2 og 3, og vurderingen tjekkes automatisk.
- Fristen for en rettelse afhænger af alvorligheden: kritisk inden for 7 dage, høj inden for 30, middel inden for 90.
Ledelse, risiko og hændelser
Ledelse og ansvar
- Vores COO har ansvaret for sikkerhedsarbejdet. Vores CTO står for de tekniske kontroller og leder håndteringen af hændelser.
- Ledelsen gennemgår sikkerheden hvert kvartal: kontroller, åbne fund, risici, hændelser og ændringer hos leverandører.
- Adgangen til alle systemer gennemgås hvert kvartal.
- Alle med adgang gennemfører sikkerhedstræning og underskriver vores sikkerhedserklæring, når de starter, og derefter hvert år.
- Et ugentligt compliancetjek markerer alle gennemgange, udskiftninger af adgangsnøgler og test, når de forfalder.
Risiko og leverandører
- Vi laver en fuld risikovurdering hvert år og efter enhver væsentlig ændring. Vurderingen dækker både svindel og sikkerhed: en ændret betaling, en tilføjet modtager, en omgået godkendelse eller en misbrugt bankadgang.
- Alle leverandører er registreret med, hvilke data de ser, og hvor kritiske de er. Vi gennemgår dem hvert år, også deres sikkerhedsrapporter.
- Vores sikkerhedspolitikker gennemgås hvert år og efter enhver væsentlig ændring eller hændelse.
Håndtering af hændelser
- Hændelser inddeles efter alvorlighed. Ved en kritisk hændelse reagerer vi inden for 2 arbejdstimer og giver jer en status hver 4. arbejdstime, som beskrevet i vores SLA.
- Rammer et brud på persondatasikkerheden jeres data, giver vi jer besked inden for 48 timer, efter at vi er blevet opmærksomme på det. Er en bankadgang involveret, får banken besked med det samme.
- Efter hver alvorlig hændelse laver vi en skriftlig gennemgang inden for fem arbejdsdage, og vi øver vores beredskab hvert år.
Databeskyttelse og opbevaring
- Vi er jeres databehandler efter en databehandleraftale i henhold til GDPR, og vi giver jer besked mindst 14 dage, før vi tager en ny underdatabehandler i brug.
- Betalinger og kontoudtog flyttes ud af den aktive database efter 90 dage, og de originale kontoudtogsfiler efter 30 dage. Arkivkopier slettes senest seks måneder efter, at de er oprettet. Revisionssporet gemmes i fem år. Når en aftale ophører, slettes kundedata efter aftalens bestemmelser.
- Godkenderes personnumre krypteres, maskeres på skærmen og skrives aldrig i logs.
Den aktuelle tilgængelighed kan ses på vores statusside.
Driftssikkerhed
Når noget er nede
Vi måler vores oppetid én gang i minuttet udefra, ikke fra vores egne servere, og viser den på vores statusside. Her kan I se, hvad der sker med jeres betalinger, hvis BankConnector eller en bank er nede.
Hvis BankConnector er nede
- Jeres betalinger bliver liggende i betalingskladden i jeres økonomisystem. Der går ikke noget tabt.
- Har en betaling ikke fået svar, står det på linjen. Send den igen, når vi er tilbage: BankConnector genkender betalingen og svarer med det første resultat, så den aldrig bliver betalt to gange.
- En betaling, der aldrig nåede frem til os, kan I bare sende igen.
- Kan en betaling ikke vente, kan I altid betale den i jeres netbank i stedet og derefter slette linjen i kladden. Har I allerede sendt den fra kladden, skal I kontakte vores support først, for den kan stadig blive betalt, når vi er tilbage.
Hvis en bank er nede
- BankConnector prøver selv igen flere gange i de næste minutter, så længe det står fast, at betalingen ikke er nået frem til banken.
- Er banken stadig nede derefter, bliver betalingen markeret som ikke leveret, og der bliver ikke betalt noget. Det står i jeres kladde, og I kan sende betalingen igen fra jeres økonomisystem.
- Afbrydes forbindelsen, efter at betalingen måske er nået frem til banken, bliver betalingen aldrig sendt igen automatisk. Den bliver holdt tilbage, og vi får besked, så vi kan undersøge den.
- BankConnector henter kontoudtog fra banken løbende hele dagen. Svarer banken ikke, bliver BankConnector ved med at prøve, og mangler kontoudtoget for sidste bankdag kl. 10, selv om der var grund til at vente et (banken har sendt et tomt før, eller der er gået penge ind eller ud), vises en advarsel i BankConnector og sendes til jeres webhooks; på mail, hvis I slår det til.
- Nedetid hos banken selv kan vi ikke styre, og den er derfor ikke dækket af vores SLA.
Support
- Vi giver support på dansk og engelsk.
- I kan skrive til support@bankconnector.com på hverdage kl. 9 til 17 dansk tid, undtagen på danske helligdage.
- En kritisk hændelse, hvor driften er nede, kan også meldes til urgent@bankconnector.com uden for supporttiden. Vi svarer så hurtigt som muligt.
- Det første svar kommer inden for 2 arbejdstimer ved en kritisk hændelse og inden for 4 ved en alvorlig, som beskrevet i vores SLA.
Til jeres sikkerhedsgennemgang
Tekniske detaljer
Detaljerne bag kontrollerne ovenfor.
Login
Adgangskoder hashes med scrypt, sammenlignes i konstant tid og tjekkes mod en liste over ofte brugte og lækkede adgangskoder. Tofaktorgodkendelse sker med TOTP. En brugt kode kan ikke genbruges inden for sit tidsvindue, og de ti reservekoder kan kun bruges én gang og gemmes som hash. API-nøgler har 256 bits entropi og gemmes kun som hash. Begrænsningen af loginforsøg gælder pr. identitet og pr. IP-adresse, og tællerne deles på tværs af instanser.
Sessioner
Sessioner er tokens på serveren uden læsbart indhold (opaque tokens). De gemmes som hash og sendes i en cookie med HttpOnly, Secure og SameSite=Strict. En session udløber efter 30 minutter uden aktivitet eller senest efter 8 timer i alt. Brugere kan se og afslutte deres sessioner, administratorer kan afslutte en brugers sessioner, og når tofaktorgodkendelse slås til eller fra, afsluttes alle andre sessioner. Følsomme ændringer kræver en ny tofaktorkode.
Adskillelse af kunder
Den autentificerede afsender afgør, hvilken kunde en forespørgsel hører til, og det tjekkes mod forespørgslen. PostgreSQL row-level security kører i FORCE-tilstand på alle kundetabeller, så den også gælder for tabellens ejer. Inden for en virksomhed er rollerne en positivliste: et nyt endpoint, der ændrer data, er lukket for brugere med læseadgang, indtil det udtrykkeligt åbnes.
Kryptering af lagrede data
Feltkryptering sker med AES-256-GCM i applikationen. Hver krypteret værdi er bundet til sin tabel, kolonne, kunde og række, så en kopieret værdi ikke kan dekrypteres et andet sted. Krypterede værdier indeholder et nøgle-id, så data stadig kan dekrypteres, når nøglen udskiftes, og et ukendt id giver en fejl. Nøglen, der signerer revisionssporet, er adskilt fra nøglen til feltkryptering.
Kryptering ved overførsel
Serveren starter ikke, hvis forbindelsen til databasen er ukrypteret eller ikke verificerer certifikatet. Udgående kald til banker og webhook-endpoints sker kun over HTTPS og verificerer certifikatet. De forbinder til den adresse, der blev tjekket, følger ingen omdirigeringer og har en grænse for svarets størrelse.
Kryptografi i bankkanalerne
Webservice-kanaler signerer og krypterer med RSA-SHA256, og indgående signaturer tjekkes mod et fastlåst certifikat. EBICS bruger XML-signaturer med kontrol mod signature wrapping-angreb. SFTP krypterer filer med bankens fastlåste nøgle og verificerer serverens host key. Hvor en bank offentliggør fingeraftryk af sine EBICS-nøgler, tjekker vi dem og afviser, hvis de ikke passer. Ellers registrerer vi bankens nøgle ved første kontakt og låser den fast fra da af. Fastlåste certifikater giver en advarsel, før de udløber.
Udgående forespørgsler
Hver udgående adresse tjekkes mod en positivliste og afvises, hvis den peger på maskinen selv (loopback), et privat netværk, en link-local-adresse eller cloududbyderens metadataadresse, også når IP-adressen er skrevet i et forklædt format. Forbindelsen låses til den tjekkede adresse for at forhindre DNS rebinding. Webhook-modtagere tjekkes igen ved levering.
Filer og XML
Uploadede filer har grænser for type og størrelse, komprimerede filer tjekkes for dekomprimeringsbomber, og filnavne tjekkes for path traversal. Alle XML-parsere afviser DOCTYPE, så angreb med eksterne entiteter og entitetsudvidelse bliver blokeret, før indlæsningen begynder. Databaseadgang er parametriseret, og indholdet af forespørgsler valideres mod strenge skemaer.
Hærdning af webapplikationen
HTTP-svar har en Content-Security-Policy, frame-ancestors none, nosniff, en referrer policy, headers til cross-origin-isolation og HSTS med preload. Cookies er Secure, HttpOnly og SameSite=Strict, og CSRF-tokens er bundet til sessionen. Forespørgsler med dobbelte parametre afvises.
Revisionslog
Der kan kun tilføjes nye poster til loggen. Det sikrer en databasetrigger, som også gælder for tabellens ejer. Posterne er HMAC-kædet pr. virksomhed med en nøgle, der opbevares uden for databasen, så skriveadgang til databasen ikke er nok til at omskrive kæden.
Konfiguration af driftsmiljøet
Driftsmiljøet nægter at starte med udviklingsnøgler, uden autentificering, uden verificeret TLS til databasen eller med en databaserolle, der kan omgå row-level security. Forbindelser i drift kan ikke pege på bankernes testendpoints. Fejlfindingsoutput er slået fra, og overvågningsendpoints kræver et token. Hemmeligheder og kontonumre fjernes fra logs ud fra feltnavn og mønster.
Softwareforsyningskæde
Vores planlagte CI-kørsler og udgivelseskørsler danner en stykliste (SBOM) i CycloneDX-format. Afhængigheder tjekkes mod den committede lockfile ved hver pull request og hvert push, og et fund med høj alvorlighed blokerer buildet. CI-actions fra tredjepart er låst til commit-hashes. Hvert push scannes for committede hemmeligheder. Udgivelser er tags, der ikke kan ændres, og vi udruller kun tags.
Dokumenter
Læs eller bed om dokumenterne
Offentligt tilgængelige
- Læs (EN) →Sikkerhedspolitik (Security Policy)Version 1.2, 9. oktober 2026. Indgår i vores kundeaftale
- Læs (EN) →Databehandleraftale (Data Processing Agreement)Version 1.1, 7. oktober 2026. Underdatabehandlere fremgår af bilag III
- Læs (EN) →SLA og supportpolitik (SLA and Support Policy)Version 1.2, 20. oktober 2026
- Læs (EN) →Privatlivspolitik (Privacy Policy)Version 1.5, 20. oktober 2026
På forespørgsel, i fortrolighed
- Bed om det på mail →InformationssikkerhedspolitikkerAdgang, ændringer, hændelseshåndtering, beredskab, leverandør- og risikostyring
- Bed om det på mail →Sammenfatning af sikkerhedsvurderingVores egen vurdering efter OWASP ASVS v5, niveau 2 og 3
Dokumenterne er på engelsk. Alle vores aftaler og politikker står på siden med juridiske dokumenter (EN). AWS' kunder kan hente AWS' egne SOC 2- og ISO-rapporter i AWS Artifact.
Ansvarlig offentliggørelse
Har I fundet en sårbarhed?
Skriv til security@bankconnector.com med en beskrivelse af, hvad I har fundet, og hvordan det kan genskabes. Vi bekræfter modtagelsen inden for to arbejdsdage og holder jer orienteret, indtil det er rettet.
Test kun i vores offentlige testmiljø (sandbox). Skaf jer ikke adgang til andres data, og ændr dem ikke. Giv os rimelig tid til at rette problemet, før I offentliggør det. Vi anlægger ikke sag mod nogen for undersøgelser, der er udført i god tro og efter disse vilkår.