DPIA Assessment Vurdering av personvernkonsekvenser (DPIA) — Drop Dokument-ID: DPIA-DROP-001 Versjon: 1.0 Dato: 12. februar 2026 Utarbeidet av: ALAI Holding AS Behandlingsansvarlig: ALAI Holding AS, org.nr. 932 516 136 Status: Godkjent 1. Innledning og bakgrunn 1.1 Formål Denne vurderingen av personvernkonsekvenser (DPIA) er utarbeidet i henhold til GDPR artikkel 35 og Datatilsynets retningslinjer for vurdering av personvernkonsekvenser. Formålet er å identifisere, vurdere og redusere personvernrisiko forbundet med betalingstjenesten Drop. 1.2 Hvorfor DPIA er påkrevd En DPIA er påkrevd fordi behandlingen oppfyller flere av kriteriene i GDPR artikkel 35(3) og Artikkel 29-gruppens retningslinjer (WP 248 rev.01): Systematisk overvåking: Automatisert svindeldeteksjon og transaksjonsovervåking Sårbare grupper: Brukere med varierende digital kompetanse Ny teknologi: Open Banking (PSD2 PISP/AISP) og BankID-integrasjon Stor skala: Tjenesten er rettet mot alle innbyggere i Norge Finansielle data: Behandling av bankopplysninger og transaksjonsdata Grenseoverskridende overføringer: Pengeoverføringer til 30+ land 1.3 Omfang Denne DPIA dekker all behandling av personopplysninger i Drop-tjenesten, inkludert: Brukerregistrering og BankID-verifisering Kontoinformasjonstjenester (AISP) Betalingsinitieringstjenester (PISP) Utenlandsoverføringer (remittance) til 30+ land QR-betalinger i butikk KYC/AML-prosesser Svindeldeteksjon og -forebygging 2. Systematisk beskrivelse av behandlingen 2.1 Tjenestebeskrivelse Drop er en betalingstjeneste for alle innbyggere i Norge som tilbyr: Utenlandsoverføringer (remittance): Send penger til mottakere i 30+ land. Mottaker trenger ikke Drop-konto. QR-betalinger: Betal hos forhandlere ved å skanne QR-kode. Lavere gebyrer enn tradisjonelle løsninger. Lommebok: Betalinger og daglig bruk. 2.2 Teknisk arkitektur Drop opererer etter en pass-through-modell: Drop holder aldri kundemidler Betalinger initieres via PSD2 PISP direkte fra brukerens bankkonto Kontoinformasjon leses via PSD2 AISP med brukerens eksplisitte samtykke All autentisering skjer via BankID (nivå 4 — høyeste sikkerhetsnivå) 2.3 Dataflyt Bruker → BankID (autentisering) → Drop-plattform → Open Banking API (PISP/AISP) → Brukerens bank ↓ Korrespondentbank → Mottaker (for remittance) 2.4 Personopplysninger som behandles Kategori Opplysninger Kilde Rettslig grunnlag Identifikasjon Navn, fødselsnummer, fødselsdato BankID Avtale, rettslig forpliktelse Kontakt Mobilnummer, e-post Bruker Avtale Finansielt Kontonummer, saldo, transaksjoner PSD2 AISP Samtykke, avtale Transaksjoner Beløp, mottaker, valuta, tidspunkt Drop-tjenesten Avtale KYC/AML Legitimasjon, PEP-status, sanksjoner Bruker, tredjeparter Rettslig forpliktelse Teknisk IP, device ID, logger Automatisk Berettiget interesse 2.5 Involvert personell og systemer Driftsteam: Begrenset tilgang til produksjonsdata, kun via autoriserte systemer Kundeservice: Tilgang til nødvendige personopplysninger for å håndtere henvendelser Compliance: Tilgang til KYC/AML-data og transaksjonsrapporter Databehandlere: Open Banking-leverandører, skyinfrastrukturleverandører, BankID-leverandør 3. Nødvendighets- og proporsjonalitetsvurdering 3.1 Nødvendighet — GDPR art. 35(7)(b) Hver behandlingsaktivitet er vurdert mot nødvendighetsprinsippet: Behandling Nødvendig? Begrunnelse BankID-verifisering Ja Lovpålagt identitetskontroll (hvvl. § 12), sikkerhetsnivå 4 påkrevd for finanstjenester Fødselsnummer Ja Kreves for entydig identifisering jf. hvitvaskingsloven § 12(1)(a) Kontoinformasjon (AISP) Ja, med samtykke Nødvendig for å vise saldo og verifisere dekning Betalingsinitiering (PISP) Ja Kjernetjenesten — uten dette ingen betalinger Transaksjonsdata Ja Bokføringsloven § 13, kundeoversikt, kvitteringer KYC/AML-data Ja Hvitvaskingsloven §§ 4, 10-18 Svindeldeteksjon Ja PSD2 art. 2, Finanstilsynets krav Tekniske logger Ja Sikkerhetskrav, feilsøking, DORA 3.2 Proporsjonalitet Dataminimering: Kun nødvendige opplysninger samles inn. Fødselsnummer lagres kryptert og tilgjengeliggjøres kun for autorisert personell. Formålsbegrensning: Opplysninger benyttes kun til angitt formål. Lagringsminimering: Definerte oppbevaringstider med automatisk sletting. Nøyaktighet: BankID sikrer korrekte identitetsopplysninger. Transaksjonsdata genereres av bankenes systemer. 3.3 Vurdering av alternativer Alternativ Vurdert Konklusjon Anonymisering av transaksjonsdata Ja Ikke mulig — lovpålagt sporbarhet (hvvl. § 25) Pseudonymisering Ja Planlagt for intern analyse Mindre inngripende autentisering Ja BankID er minste nødvendige nivå for finanstjenester Desentralisert lagring Ja Ikke proporsjonalt gitt regulatoriske krav 4. Risikovurdering 4.1 Metodikk Risiko vurderes etter sannsynlighet og konsekvens på en skala fra 1 (lav) til 4 (svært høy): Risikonivå = Sannsynlighet × Konsekvens Lav: 1-4, Middels: 5-8, Høy: 9-12, Svært høy: 13-16 4.2 Identifiserte risikoer R1: Uautorisert tilgang til finansielle data Beskrivelse: Tredjeparter får tilgang til brukerens bankopplysninger Sannsynlighet: 2 (lav) Konsekvens: 4 (svært høy) Risikonivå: 8 (middels) Berørte rettigheter: Konfidensialitet, økonomisk tap R2: Datalekkasje ved sikkerhetsbrudd Beskrivelse: Personopplysninger eksponeres ved hacking eller teknisk feil Sannsynlighet: 2 (lav) Konsekvens: 4 (svært høy) Risikonivå: 8 (middels) Berørte rettigheter: Konfidensialitet, integritet R3: Ulovlig profilering gjennom transaksjonsdata Beskrivelse: Transaksjonshistorikk brukes til å profilere brukere ut over formålet Sannsynlighet: 1 (svært lav) Konsekvens: 3 (høy) Risikonivå: 3 (lav) Berørte rettigheter: Rett til ikke å bli profilert R4: Manglende kontroll ved tredjelandsoverføringer Beskrivelse: Personopplysninger overføres til land uten tilstrekkelig personvern Sannsynlighet: 3 (middels) Konsekvens: 3 (høy) Risikonivå: 9 (høy) Berørte rettigheter: Konfidensialitet, myndighetstilgang R5: Feilaktig avvisning av transaksjoner (svindeldeteksjon) Beskrivelse: Automatiserte systemer avviser lovlige transaksjoner Sannsynlighet: 2 (lav) Konsekvens: 2 (middels) Risikonivå: 4 (lav) Berørte rettigheter: Rett til korrekt behandling, økonomisk ulempe R6: Manglende sletting etter oppbevaringstidens utløp Beskrivelse: Personopplysninger oppbevares lenger enn nødvendig Sannsynlighet: 2 (lav) Konsekvens: 2 (middels) Risikonivå: 4 (lav) Berørte rettigheter: Rett til sletting, lagringsminimering R7: Kompromittering av BankID-sesjon Beskrivelse: Angriper overtar BankID-sesjon via phishing eller MitM Sannsynlighet: 1 (svært lav) Konsekvens: 4 (svært høy) Risikonivå: 4 (lav) Berørte rettigheter: Identitetstyveri, økonomisk tap R8: Datatilgang fra tredjelandsmyndigheter Beskrivelse: Myndigheter i mottakerland krever tilgang til overføringsdata Sannsynlighet: 2 (lav) Konsekvens: 3 (høy) Risikonivå: 6 (middels) Berørte rettigheter: Konfidensialitet, personvern 5. Risikoreduserende tiltak 5.1 Tiltak per risiko R1 & R2: Uautorisert tilgang og datalekkasje Tiltak Status Ansvarlig End-to-end-kryptering (TLS 1.3, AES-256) Implementert Drift BankID-autentisering (sikkerhetsnivå 4) Implementert Utvikling Rollebasert tilgangskontroll (RBAC) Implementert Drift Regelmessig penetrasjonstesting (min. årlig) Planlagt Sikkerhet Sikkerhetsovervåking 24/7 (SIEM) Planlagt Drift Hendelseshåndteringsplan Dokumentert Compliance Kryptering av fødselsnummer i hvile Planlagt Utvikling R3: Ulovlig profilering Tiltak Status Ansvarlig Formålsbegrensning i systemdesign Implementert Utvikling Pseudonymisering ved intern analyse Planlagt Data Forbud mot sekundærbruk uten samtykke Policy Compliance Revisjonslogg for datatilgang Implementert Drift R4 & R8: Tredjelandsoverføringer Tiltak Status Ansvarlig Standard personvernbestemmelser (SCCs) med alle partnere Pågående Juridisk Transfer Impact Assessment per mottakerland Pågående Compliance Minimering av data ved overføring (kun påkrevde felt) Implementert Utvikling Kryptering av data under overføring Implementert Drift Regelmessig gjennomgang av mottakerlands lovgivning Årlig Compliance R5: Feilaktig avvisning Tiltak Status Ansvarlig Manuell gjennomgang ved automatisk avvisning Planlagt Drift Klageadgang for brukere Implementert Kundeservice Regelmessig kalibrering av svindeldeteksjon Kvartalsvis Data Transparens om automatiserte avgjørelser Planlagt Compliance R6: Manglende sletting Tiltak Status Ansvarlig Automatisert sletterutine Delvis implementert Drift Kvartalsvis kontroll av oppbevaringstider Planlagt Compliance Slettingslogg Planlagt Drift R7: BankID-kompromittering Tiltak Status Ansvarlig Sesjonstimeout (15 minutter inaktivitet) Implementert Utvikling Enhetsgjenkjenning Planlagt Utvikling Varsling ved ny enhet Planlagt Utvikling Anti-phishing-informasjon til brukere Planlagt Kommunikasjon 6. Vurdering av BankID-integrasjon 6.1 Beskrivelse BankID benyttes som eneste autentiseringsmekanisme for Drop-brukere. Dette er Norges nasjonale eID-løsning med sikkerhetsnivå 4 (høyeste). 6.2 Personvernfordeler Sterk identitetsverifisering: Reduserer risikoen for identitetsbedrageri Minimering av datainnsamling: Drop trenger ikke samle inn pass/legitimasjon separat Brukerens kontroll: Bruker godkjenner hver transaksjon aktivt via BankID Regulatorisk samsvar: Oppfyller krav i hvitvaskingsloven §§ 12-13 6.3 Personvernrisikoer Avhengighet av tredjepart: BankID Norge AS er databehandler Fødselsnummer: Overføres via BankID — sensitivt identifikasjonsnummer Sporbarhet: BankID-logger kan kobles til brukerens aktivitet 6.4 Tiltak Databehandleravtale med BankID Norge AS Fødselsnummer krypteres umiddelbart etter mottak Kun fødselsdato (for aldersverifisering) og navn lagres i klartekst BankID-sesjonsdata slettes etter autentisering 7. Transfer Impact Assessment (TIA) — Tredjelandsoverføringer 7.1 Bakgrunn Drop tilbyr pengeoverføringer til 30+ land, hvorav flere er utenfor EØS og mangler adekvansbeslutning fra EU-kommisjonen. I tråd med Schrems II-avgjørelsen (C-311/18) og EDPBs anbefalinger 01/2020 gjennomfører vi TIA for hvert mottakerland. 7.2 Vurderingsmetodikk For hvert mottakerland vurderes: Lovgivning: Har myndighetene vid tilgang til kommunikasjonsdata? Praktisk erfaring: Har vi mottatt forespørsler fra myndigheter? Dataminimering: Hvilke data overføres, og er de nødvendige? Tekniske tiltak: Kryptering, pseudonymisering, andre beskyttelser Kontraktuelle tiltak: SCCs, tilleggsklausuler 7.3 Landkategorisering Kategori Beskrivelse Tiltak Adekvat (grønn) EU-adekvansbeslutning foreligger SCCs som tillegg Moderat (gul) Visse bekymringer, men akseptabel risiko SCCs + tekniske tilleggstiltak Høy risiko (rød) Betydelige bekymringer om myndighetstilgang SCCs + sterke tekniske tiltak + individuell vurdering 7.4 Overførte data ved remittance Kun følgende data overføres til mottakers bank: Avsenders fulle navn (lovpålagt) Mottakers fulle navn og kontonummer Beløp og valuta Referansenummer Fødselsnummer, fødselsdato, IP-adresse og annen teknisk informasjon overføres aldri til tredjeland. 8. Konsultasjon med berørte parter 8.1 Intern konsultasjon Utvikling: Teknisk gjennomførbarhet av tiltak Compliance: Regulatorisk samsvar Drift: Operasjonell gjennomførbarhet Ledelse: Godkjenning av restrisiko 8.2 Ekstern konsultasjon BankID Norge AS: Verifisering av sikkerhetsarkitektur Open Banking-leverandør: Datahåndtering og sikkerhet Ekstern personvernrådgiver: Uavhengig gjennomgang av DPIA 8.3 Brukermedvirkning Pilotbrukere har gitt tilbakemelding på personverninformasjon og samtykkeflyt Personvernerklæring testet for forståelighet 9. Restrisiko og konklusjon 9.1 Risikomatrise etter tiltak Risiko Opprinnelig nivå Etter tiltak Akseptabel? R1: Uautorisert tilgang 8 (middels) 4 (lav) Ja R2: Datalekkasje 8 (middels) 4 (lav) Ja R3: Ulovlig profilering 3 (lav) 2 (lav) Ja R4: Tredjelandsoverføringer 9 (høy) 6 (middels) Ja, med løpende TIA R5: Feilaktig avvisning 4 (lav) 2 (lav) Ja R6: Manglende sletting 4 (lav) 2 (lav) Ja R7: BankID-kompromittering 4 (lav) 2 (lav) Ja R8: Tredjelandsmyndigheter 6 (middels) 4 (lav) Ja, med løpende TIA 9.2 Konklusjon Etter implementering av de beskrevne tiltakene vurderes restrisikoene som akseptable. Ingen risikoer krever forhåndskonsultasjon med Datatilsynet jf. GDPR artikkel 36. Vurderingen skal gjennomgås: Årlig som del av complianceprogrammet Ved vesentlige endringer i tjenesten, teknologien eller lovgivningen Ved nye mottakerland — ny TIA gjennomføres 9.3 Godkjenning Rolle Navn Dato Signatur Behandlingsansvarlig Alem Bašić, ALAI Holding AS . .2026 ___________ Personvernombud Alem Bašić (alem@alai.no, +47 40 47 42 51) 02.03.2026 (oppnevnt) ___________ CTO ___________________ . .2026 ___________ 10. Vedlegg Vedlegg A: Dataflytdiagram Se egen teknisk dokumentasjon. Vedlegg B: Transfer Impact Assessments per land Se egen mappe: /legal/tia/ Vedlegg C: Databehandleravtaler (oversikt) Se egen mappe: /legal/dpa/ Vedlegg D: Interesseavveininger (LIA) Se egen dokumentasjon. DPIA utarbeidet i henhold til GDPR artikkel 35, Datatilsynets veileder for vurdering av personvernkonsekvenser, og Artikkel 29-gruppens retningslinjer WP 248 rev.01.