Data Protection Impact Assessment (DPIA)
Data Protection Impact Assessment (DPIA)
Project: Drop — Fintech Payment App (ALAI Holding AS) Processing Activity: All personal data processing in Drop payment services Version: 1.0 Date: 2026-02-23 Author: ALAI Compliance Team DPO: TBD — appointment required ([email protected] — planned) Status: Draft — DPO Review Required Reviewers: DPO, Legal Counsel, CTO Classification: Confidential
Document History
| Version | Date | Author | Changes |
|---|---|---|---|
| 0.1 | 2026-02-12 | Compliance Agent (ALAI) | Initial DPIA draft (legal/dpia-vurdering.md) |
| 1.0 | 2026-02-23 | Security Architect (ALAI) | English compliance template format |
Source document: legal/dpia-vurdering.md — DPIA-DROP-001 (v1.0, approved 2026-02-12)
DPIA Trigger Checklist
A DPIA is required under GDPR Art. 35 if ANY of the following apply:
| # | Trigger | Applies? | Notes |
|---|---|---|---|
| 1 | Systematic and extensive evaluation of personal aspects (profiling, automated decision-making with legal/significant effects) | YES | Automated AML/fraud transaction monitoring |
| 2 | Large-scale processing of special category data | NO | No health, religion, or other special category data |
| 3 | Systematic monitoring of publicly accessible areas | NO | Not applicable |
| 4 | Processing of biometric or genetic data | PARTIAL | BankID uses biometric identity verification (handled by BankID — not Drop) |
| 5 | Processing of data concerning vulnerable data subjects | YES | General population including potentially vulnerable individuals |
| 6 | Innovative use of technology with unpredictable privacy impact | YES | Open Banking (PSD2 PISP/AISP), BankID OIDC integration, QR payments |
| 7 | Cross-border transfer outside EEA without adequate protection | YES | Remittance to 30+ countries — Serbia, Bosnia, Turkey, Pakistan lack adequacy decisions |
| 8 | Processing data that prevents data subjects from exercising rights | NO | Not applicable |
DPIA Required: YES Reason: Multiple triggers apply: automated transaction monitoring, innovative Open Banking technology, large-scale financial data processing, cross-border transfers to non-adequate countries.
1. Processing Activity Description
1.1 Activity Overview
Activity Name: Drop Payment Services — All Personal Data Processing System/Product: Drop (getdrop.no) — Remittance + QR Payment App Business Unit: ALAI Holding AS — Drop product Processing Owner: CEO / CISO ([email protected])
Description of Processing: Drop is a payment application for all residents of Norway providing:
- Remittance — international money transfers to 30+ countries via PSD2 PISP
- QR Payments — in-store QR code payments via PSD2 PISP
- Account Information — reading bank balances via PSD2 AISP
Drop operates a pass-through model: it never holds customer funds. All payments are initiated directly from the user's bank account via Open Banking APIs. User authentication occurs via BankID (OIDC, security level "høyt" — eIDAS High).
Trigger / Business Justification: Providing accessible, low-cost payment and remittance services to all Norwegian residents. Norwegian-registered residents can send money abroad at lower fees than traditional services. Financial inclusion for all communities.
1.2 Processing Operations
| Operation | Data Category | Technology | Location |
|---|---|---|---|
| Collection — Registration | Identity (name, fødselsnummer, DOB), contact (phone, email) | BankID OIDC, web form | Norway (EEA) |
| Collection — AISP | Financial (bank account number, balance) | PSD2 Open Banking API (Neonomics) | Norway (EEA) |
| Collection — PISP | Financial (bank account, amount, recipient) | PSD2 Open Banking API (Neonomics) | Norway (EEA) |
| Collection — KYC/AML | Identity documents, PEP status, risk profile | Sumsub SDK | EU (EEA) |
| Storage | All above | SQLite (MVP) → PostgreSQL (Phase 2) | Norway (EEA) |
| Processing — AML monitoring | Transaction patterns, amounts, corridors | Automated rules engine | Norway (EEA) |
| Sharing — Remittance | Sender name, recipient name/account, amount | SWIFT/correspondent banks | EEA + non-EEA |
| Deletion / Anonymization | All categories | Automated deletion jobs (planned Phase 2) | Norway (EEA) |
2. Necessity & Proportionality Assessment
2.1 Purposes of Processing
| Purpose | Specific Description | Legitimate? |
|---|---|---|
| Identity verification | Verify user is who they claim, minimum age 18, Norwegian residency | YES — required by hvitvaskingsloven § 12 and PSD2 SCA |
| Payment initiation (PISP) | Initiate payments from user's bank account | YES — core service delivery |
| Account information (AISP) | Read bank balances for user dashboard | YES — core service delivery, with explicit consent |
| AML/transaction monitoring | Detect and prevent money laundering | YES — legal obligation (hvvl. §§ 24-25) |
| KYC compliance | Customer identification and risk assessment | YES — legal obligation (hvvl. §§ 10-18) |
| Fraud detection | Detect unauthorized transactions | YES — legitimate interest (PSD2 Art. 2) |
| Technical logging | System error tracking, debugging, security | YES — legitimate interest (security requirement) |
2.2 Data Minimization Assessment
| Data Element | Collected | Strictly Necessary? | Justification |
|---|---|---|---|
| Full name | YES | YES | Identity verification (hvvl. § 12), payment routing |
| Fødselsnummer (11 digits) | YES | YES | Unique identification (hvvl. § 12(1)(a)), age verification (min 18) |
| Date of birth | YES (derived from fødselsnummer) | YES | Age verification |
| Email address | YES | YES | Account notifications, login |
| Phone number (+47) | YES | YES | Norwegian residency verification, 2FA (planned) |
| Bank account number | YES | YES | AISP balance reading, PISP payment initiation |
| Transaction data (amount, recipient, currency) | YES | YES | Service delivery, AML monitoring, Bokføringsloven § 13 |
| IP address | YES | YES | Security monitoring, rate limiting, fraud detection |
| Device ID | YES | YES | Session management, fraud detection |
| KYC documents (passport, national ID) | YES | YES | Hvitvaskingsloven § 12 identity verification |
| PEP status | YES | YES | Hvitvaskingsloven § 18 |
| Marketing preferences | NO | NO | Not collected — no marketing processing |
Fields recommended for removal: None identified. All fields are necessary for regulatory compliance or service delivery.
2.3 Lawful Basis
| Processing Activity | Lawful Basis | Justification |
|---|---|---|
| Account creation, identity verification | Contract (Art. 6.1.b) | Required for service delivery |
| Payment initiation (PISP) | Contract (Art. 6.1.b) | Core service |
| Bank account reading (AISP) | Consent (Art. 6.1.a) | PSD2 requires explicit PSU consent |
| AML/KYC processing | Legal obligation (Art. 6.1.c) | Hvitvaskingsloven §§ 4, 10-18 |
| Transaction monitoring | Legal obligation (Art. 6.1.c) | Hvitvaskingsloven §§ 24-25 |
| Fraud detection | Legitimate interest (Art. 6.1.f) | PSD2 Art. 2 |
| Security logging | Legitimate interest (Art. 6.1.f) | DORA Art. 10, security requirement |
3. Data Subjects & Categories of Data
3.1 Data Subject Groups
| Group | Description | Estimated Volume | Vulnerability Level |
|---|---|---|---|
| Registered users | Adults (18+) residing in Norway, all backgrounds | TBD (launch target: 10,000 — Year 1) | Low-Medium |
| Merchants | Legal entities registering for QR payment acceptance | TBD (launch target: 500 — Year 1) | Low |
| Payment recipients | Persons abroad receiving remittances | TBD | Low (data minimized — name + account only) |
3.2 Personal Data Categories
| Category | Data Elements | Sensitivity | Retention |
|---|---|---|---|
| Identity | Full name, fødselsnummer, date of birth | High (L4 for fødselsnummer) | 5 years after account closure (hvvl. §30) |
| Contact | Email, phone number | Standard (L3) | Duration + 2 years |
| Financial | Bank account number, balance (AISP), transaction history | High (L3-L4) | 5 years (Bokføringsloven) |
| KYC/AML | Identity documents, PEP status, risk profile | High (L4) | 5 years after account closure (hvvl. §30) |
| Behavioral | Transaction patterns, device ID, IP address | Standard (L3) | 12-24 months (security logs), 5 years (AML) |
| Biometric | None collected directly (BankID handles) | — | — |
4. Data Processing Purposes & Legal Basis
| Processing Purpose | Personal Data Used | Legal Basis | Retention Period |
|---|---|---|---|
| User registration and authentication | Name, fødselsnummer, email, phone | Contract (Art. 6.1.b) | Duration + 2 years |
| BankID SCA verification | Name, fødselsnummer (via BankID) | Contract + Legal obligation | Session only |
| AISP bank balance reading | Bank account number, balance | Consent (Art. 6.1.a) | Until consent withdrawn |
| PISP payment initiation | Bank account, amount, recipient details | Contract (Art. 6.1.b) | 5 years (Bokføringsloven) |
| Remittance — cross-border transfer | Sender name, recipient name/account, amount | Contract (Art. 6.1.b) | 5 years |
| KYC identity verification | Full identity data, documents, PEP status | Legal obligation (Art. 6.1.c) — hvvl. §§ 10-18 | 5 years (hvvl. §30) |
| Transaction monitoring (AML) | Transaction data, patterns, amounts | Legal obligation (Art. 6.1.c) — hvvl. §§ 24-25 | 5 years |
| Fraud detection | Transaction patterns, IP, device ID | Legitimate interest (Art. 6.1.f) | 2 years |
| Security logging | IP, user_id, action, timestamp | Legitimate interest (Art. 6.1.f) | 12 months auth logs, 24 months security |
| Suspicious Transaction Reporting (EFE) | Identity + transaction data | Legal obligation (Art. 6.1.c) — hvvl. §26 | 5 years |
5. Data Flow Mapping
User → BankID (SCA authentication)
→ Drop Platform (Norway — AWS EEA)
├── Registration data → PostgreSQL DB (Norway)
├── KYC data → Sumsub (EU EEA) → Drop DB
├── AISP: Bank balance → Neonomics → User's bank → Drop dashboard
├── PISP: Payment instruction → Neonomics → User's bank → Recipient bank
│ └── For remittance: → Correspondent bank → Recipient country bank
├── Errors → Sentry (EU EEA)
└── Suspicious transactions → EFE (Altinn — Norway)
Data processors (GDPR Art. 28):
| Processor | Service | Data Shared | Country | DPA Signed |
|---|---|---|---|---|
| BankID Norge AS | Identity verification | Name, fødselsnummer | Norway (EEA) | Required — planned |
| Sumsub | KYC/AML document verification | ID documents, biometric liveness | EU (EEA) | Yes — legal/dpa-sumsub.md |
| Neonomics | PSD2 AISP/PISP | Bank account data, payment instructions | EU (EEA) | Required — planned |
| Swan | Banking/payment rails | Transaction data | EU (EEA) | Yes — legal/dpa-swan.md |
| AWS | Infrastructure hosting | All data (encrypted) | EU (EEA — Frankfurt/Ireland) | AWS DPA |
| Sentry | Error monitoring | Error context, user IDs | EU (EEA) | Yes — legal/dpa-sentry.md |
| Correspondent banks | Remittance routing | Sender name, amount, recipient | Non-EEA (per corridor) | SCCs required |
6. Risk Assessment Matrix
6.1 Risk Scoring Scale
| Score | Likelihood | Severity |
|---|---|---|
| 1 | Remote — unlikely to occur | Negligible — minimal impact |
| 2 | Unlikely — exceptional circumstances | Limited — short-term, minor inconvenience |
| 3 | Possible — could occur | Significant — real impact on rights |
| 4 | Likely — will probably occur | Severe — serious impact on rights and freedoms |
Risk Score = Likelihood × Severity | Low: 1-4 | Medium: 5-8 | High: 9-12 | Critical: 13-16
6.2 Risk to Data Subjects
| Risk ID | Risk to Data Subjects | Likelihood | Severity | Score | Existing Controls | Residual Risk |
|---|---|---|---|---|---|---|
| R1 | Unauthorized access to financial data (breach) | 2 | 4 | 8 | TLS 1.3, bcrypt, JWT httpOnly, parameterized SQL, session revocation | MEDIUM |
| R2 | Data breach exposing PII or fødselsnummer | 2 | 4 | 8 | Encryption at rest planned, access controls | MEDIUM |
| R3 | Unlawful profiling through transaction data | 1 | 3 | 3 | Purpose limitation, data minimization, no secondary use | LOW |
| R4 | Third-country transfer without adequate protection (remittance corridors) | 3 | 3 | 9 | SCCs planned, data minimization (name + account only in transfer) | HIGH → MEDIUM with TIA |
| R5 | False positive — legitimate transaction blocked by AML rules | 2 | 2 | 4 | Manual review within 24h, complaint handling | LOW |
| R6 | Data retained beyond legal requirement | 2 | 2 | 4 | Automated deletion planned Phase 2 | LOW |
| R7 | BankID session compromise via phishing/MitM | 1 | 4 | 4 | BankID security (handled by BankID Norge AS), session timeout | LOW |
| R8 | Third-country authorities accessing data via remittance partners | 2 | 3 | 6 | SCCs + TIA + data minimization | MEDIUM |
| R9 | Identity fraud — someone impersonating user | 1 | 4 | 4 | BankID Level High (eIDAS), Norwegian BankID only | LOW |
7. Mitigation Measures
| Risk ID | Mitigation Measure | Owner | Deadline | Status |
|---|---|---|---|---|
| R1 | Field-level AES-256-GCM encryption for fødselsnummer | Engineering | Phase 2 | Planned |
| R1 | AWS KMS key management for database encryption keys | Platform | Phase 2 | Planned |
| R2 | PostgreSQL with TDE (Transparent Data Encryption) via AWS RDS | Platform | Phase 2 | Planned |
| R2 | Penetration test before production launch | Security | Pre-launch | Planned |
| R4 | SCCs with all remittance corridor correspondent banks | Legal | Phase 2 | Planned |
| R4 | Transfer Impact Assessments per destination country | DPO/Legal | Phase 2 | Planned |
| R4 | Minimize transferred data (name, account, amount ONLY — no fødselsnummer) | Engineering | MVP | Implemented |
| R6 | Automated data retention + deletion jobs (5-year AML, 2-year other) | Engineering | Phase 2 | Planned |
| R8 | TIA for high-risk corridors (Pakistan, Turkey, Serbia, Bosnia) | DPO/Legal | Phase 2 | Planned |
Residual risk after mitigation: All residual risks assessed as LOW or MEDIUM. No HIGH or CRITICAL residual risks after Phase 2 mitigations are implemented.
DPO Conclusion: Conditional — Processing may proceed for MVP (no live transactions). Prior to live transactions: BankID SCA required, KYC implemented, SCCs in place, DPO appointed.
8. DPO Consultation Record
DPO Name: TBD — DPO appointment required before Phase 2 launch Consultation Date: TBD DPO Input: Pending appointment
DPO Recommendation (required before live transactions):
- Approved — risks are acceptable and adequately mitigated
- Conditional approval — subject to implementing Phase 2 mitigations
- Rejected — requires redesign
DPO Signature: _________________________ Date: _____________
9. Supervisory Authority Consultation
Consultation Required: NO — based on current risk assessment (all residual risks LOW-MEDIUM after mitigation) Basis: GDPR Art. 35(7) — Residual risks after mitigations are acceptable. No prior consultation with Datatilsynet required.
Monitoring: If Phase 2 implementation reveals new risks (e.g., from real-world transaction data), this assessment will be reviewed and Datatilsynet consultation may be required.
10. DPIA Review Schedule
Next scheduled review: 2027-02-12 (annual) OR when any of the following occurs:
- BankID integration implemented (Phase 2)
- Live PSD2 AISP/PISP transactions commenced
- New remittance corridors added
- Sumsub or KYC vendor changed
- Data breach incident related to this processing
- Change in applicable Norwegian or EU regulations
- DORA implementation in Norway (expected 2026 H2)
Review Owner: DPO (once appointed)
Review Log:
| Date | Reviewer | Changes Made | Outcome |
|---|---|---|---|
| 2026-02-12 | Compliance Agent (ALAI) | Initial DPIA (legal/dpia-vurdering.md) |
Draft |
| 2026-02-23 | Security Architect (ALAI) | English compliance template format | Draft — awaiting DPO review |
Approval
| Role | Name | Date | Signature |
|---|---|---|---|
| Author | ALAI Security Team | 2026-02-23 | |
| DPO | TBD — appointment required | ||
| Processing Owner | Alem Bašić (CEO/CISO) | ||
| Legal Counsel | TBD | ||
| Management | Alem Bašić |