Data Protection Impact Assessment (DPIA)
Data Protection Impact Assessment (DPIA)
Project: Drop — PSD2 Pass-Through Payment App Processing Activity: All personal data processing in Drop payment service Version: 1.0 Date: 2026-02-23 Author: Security Architect DPO: DPO ([email protected]) Status: Draft Reviewers: DPO, Legal Counsel, CTO Classification: Confidential Document-ID: DPIA-DROP-001
Document History
| Version | Date | Author | Changes |
|---|---|---|---|
| 0.1 | 2026-02-12 | ALAI Holding AS | Initial DPIA assessment (legal/dpia-vurdering.md) |
| 1.0 | 2026-02-23 | Security Architect | Formalized in compliance template format |
DPIA Trigger Checklist
A DPIA is required if ANY of the following apply (GDPR Art. 35):
| # | Trigger | Applies? | Notes |
|---|---|---|---|
| 1 | Systematic and extensive evaluation of personal aspects (profiling, automated decision-making with legal/significant effects) | YES | Automated fraud detection and AML transaction monitoring — flags transactions with legal/financial consequences for data subjects |
| 2 | Large-scale processing of special category data | NO | No health/religion/ethnicity data processed |
| 3 | Systematic monitoring of publicly accessible areas (CCTV, tracking) | NO | Not applicable |
| 4 | Processing of biometric or genetic data | NO | BankID is not biometric in Drop's processing scope |
| 5 | Processing of data concerning vulnerable data subjects | YES | General population including financially vulnerable users; minimum age 18 enforced via BankID fødselsnummer |
| 6 | Innovative use of technology with unpredictable privacy impact | YES | Open Banking PSD2 AISP/PISP integration; BankID OIDC — new technology combination |
| 7 | Cross-border transfer outside EEA without adequate protection | YES | Remittance to Serbia, BiH, Turkey, Pakistan — no adequacy decisions |
| 8 | Large-scale processing of financial data | YES | Transaction data, bank account numbers, cross-border payment flows |
DPIA Required: YES Reason: Triggers 1, 5, 6, 7, and 8 confirmed. Processing of financial data at scale with cross-border transfers to non-EEA countries and automated decision-making (fraud/AML systems).
Regulatory basis: GDPR Art. 35, personopplysningsloven (LOV-2018-06-15-38), Datatilsynets retningslinjer for DPIA
1. Processing Activity Description
1.1 Activity Overview
Activity Name: Drop Payment Service — Full Processing Scope System/Product: Drop — PSD2 pass-through payment app (getdrop.no) Business Unit: ALAI Holding AS (org.nr. 932 516 136) Processing Owner: CEO / Compliance Officer
Description of Processing: Drop is a payment service for all residents of Norway. It uses a pass-through model under PSD2 — Drop never holds customer money. Processing includes:
- User registration and identity verification via BankID OIDC — collection of name, fødselsnummer (national ID), birthdate (age verification), mobile number
- PSD2 AISP — reading bank account balances from user's bank via Open Banking API (with explicit user consent)
- PSD2 PISP — initiating payments from user's bank account (remittance to 30+ countries, QR payments in-store)
- KYC/AML compliance — customer due diligence per hvitvaskingsloven, transaction monitoring, PEP/sanctions screening
- Transaction history — storing remittance and QR payment records per bokføringsloven
Trigger / Business Justification: Provide affordable, accessible international remittance and QR payment services for all residents of Norway, compliant with PSD2, hvitvaskingsloven, and GDPR.
1.2 Processing Operations
| Operation | Data Category | Technology | Location |
|---|---|---|---|
| Collection (BankID) | Name, fødselsnummer, birthdate | BankID OIDC | Norway (BankID Norge AS) |
| Collection (user-entered) | Mobile number, email, recipient details | Next.js API | Norway (AWS App Runner) |
| Storage (identity) | Encrypted fødselsnummer, name, KYC status | SQLite → PostgreSQL | EEA (AWS) |
| Storage (transactions) | Amount, corridor, timestamp, recipient | SQLite → PostgreSQL | EEA (AWS) |
| Processing (AISP) | Bank balance, account number | PSD2 API → user's bank | EEA |
| Processing (PISP) | Payment instruction, amount, recipient IBAN | Open Banking API | EEA → remittance destination |
| Sharing (remittance) | Sender name, recipient name/IBAN, amount | SWIFT / correspondent bank | EEA → Serbia/BiH/HR/other |
| KYC/AML processing | Name, fødselsnummer, PEP/sanctions status | Sumsub + internal rules | EEA (Sumsub) |
| Deletion / Anonymization | All categories | Automated retention job | EEA |
2. Necessity & Proportionality Assessment
2.1 Purposes of Processing
| Purpose | Specific Description | Legitimate? |
|---|---|---|
| User authentication | BankID OIDC to verify identity and age (≥18) | YES — mandatory for financial services; hvitvaskingsloven § 12 |
| Payment execution | PISP from user's bank account for remittance/QR | YES — core service delivery |
| Balance reading | AISP to show user their bank balance | YES — explicit consent; Art. 6(1)(a) |
| KYC/AML compliance | Customer due diligence, transaction monitoring | YES — legal obligation; hvitvaskingsloven §§ 4, 10-18 |
| Transaction history | Records for user and for accounting | YES — bokføringsloven § 13; Art. 6(1)(c) |
| Fraud prevention | Automated fraud detection on transactions | YES — legitimate interest; PSD2 Art. 95 |
2.2 Data Minimization Assessment
| Data Element | Collected | Strictly Necessary? | Alternative If Not Necessary |
|---|---|---|---|
name |
YES | YES — required for identity, required on wire transfers (FATF Rec. 16) | N/A |
fødselsnummer (national ID) |
YES | YES — required for unique identification per hvitvaskingsloven § 12(1)(a) | N/A — BankID provides it |
birthdate |
YES (derived from fødselsnummer) | YES — age verification ≥18, required | Only birthdate stored (not full fødselsnummer in plaintext) |
mobile_number |
YES | YES — authentication factor, notification | N/A |
email |
YES | YES — account management, receipts | N/A |
bank_account_number |
YES (via AISP) | YES — balance display; PISP requires source account | Masked in API responses (last 4 only) |
account_balance |
YES (AISP, session only) | YES — user requested feature; PSD2 consent | Not persisted; ephemeral read only |
ip_address |
YES | YES — fraud prevention, rate limiting, GDPR accountability | Hashed/pseudonymized in logs after 3 months |
device_id |
YES | YES — session binding, fraud detection | N/A |
transaction_history |
YES | YES — bokføringsloven § 13; customer transparency | Retention limited to 5 years |
kyc_documents |
YES (EDD cases) | YES — hvitvaskingsloven §§ 17-18 | Only collected when EDD required |
Fields recommended for removal / minimization:
ip_addressin logs: Pseudonymize after 3 monthsuser_agent: Retain for security analysis only, not customer-facing
2.3 Lawful Basis
| Processing Activity | Lawful Basis | Justification |
|---|---|---|
| User registration + BankID verification | Contract (Art. 6(1)(b)) + Legal obligation (Art. 6(1)(c)) | Required to provide service + hvitvaskingsloven § 12 |
| Payment execution (PISP) | Contract (Art. 6(1)(b)) | Core service delivery |
| Account balance reading (AISP) | Consent (Art. 6(1)(a)) | PSD2 requires explicit consent for AISP |
| KYC/AML data collection | Legal obligation (Art. 6(1)(c)) | Hvitvaskingsloven §§ 4, 10-18, 30 |
| Fraud detection and monitoring | Legitimate interest (Art. 6(1)(f)) | LIA: fraud prevention necessity outweighs privacy intrusion; data minimized |
| Technical logs (IP, device) | Legitimate interest (Art. 6(1)(f)) | LIA: security and accountability; pseudonymized after 3 months |
| Transaction history storage | Legal obligation (Art. 6(1)(c)) | Bokføringsloven § 13 — 5-year accounting retention |
3. Data Subjects & Categories of Data
3.1 Data Subject Groups
| Group | Description | Estimated Volume | Vulnerability Level |
|---|---|---|---|
| Norwegian residents (users) | All Drop users — BankID-verified, age ≥18 | Up to all Norwegian residents | Medium (financial data) |
| Merchants | Businesses using Drop QR payments | Smaller subset | Medium |
| Remittance recipients | Individuals in 30+ countries receiving money | External — minimal data held | Low (only name + IBAN stored) |
3.2 Personal Data Categories
| Category | Data Elements | Sensitivity | Retention |
|---|---|---|---|
| Identity (Norwegian) | Name, fødselsnummer (encrypted), BankID reference | High — unique national identifier | 5 years after account closure |
| Contact | Mobile number (+47), email | Standard | Duration of account |
| Financial — transactions | Amount, corridor, timestamp, currency | High | 5 years (bokføringsloven) |
| Financial — banking (AISP) | Account number (last 4 shown), balance (session) | High | Not persisted; session only |
| Recipient data | Name, IBAN/account number, country | Standard | 5 years |
| KYC/AML | Risk classification, PEP status, EDD documents | Restricted | 5 years (hvvl. § 30) |
| Technical | IP address, device ID, session tokens | Standard | IP: 3 months; session: 24h |
| Behavioral | Login times, transaction patterns (for AML) | Standard | 5 years |
4. Data Processing Purposes & Legal Basis
| Processing Purpose | Personal Data Used | Legal Basis | Retention Period |
|---|---|---|---|
| User authentication (BankID) | Name, fødselsnummer, birthdate | Contract + Legal obligation | Account duration + 5 years |
| Remittance execution | Name, recipient IBAN, amount, currency | Contract (Art. 6(1)(b)) | 5 years (bokføringsloven § 13) |
| QR payment execution | Amount, merchant ref, timestamp | Contract (Art. 6(1)(b)) | 5 years |
| Balance display (AISP) | Account number (masked), balance | Consent (Art. 6(1)(a)) | Session only — not persisted |
| KYC customer due diligence | Name, fødselsnummer, risk classification | Legal obligation (Art. 6(1)(c)) | 5 years after account closure (hvvl. § 30) |
| AML transaction monitoring | Transaction patterns, amounts, corridors | Legal obligation (Art. 6(1)(c)) | 5 years |
| Fraud detection | IP, device ID, behavioral patterns | Legitimate interest (Art. 6(1)(f)) | 3 years after event |
| Technical operations | IP address, system logs | Legitimate interest (Art. 6(1)(f)) | 6 months (technical); 12 months (auth logs) |
| Legal compliance reporting | Transaction data, identity data | Legal obligation (Art. 6(1)(c)) | Per relevant law (min 5 years) |
5. Data Flow Mapping
flowchart TD
DS([Drop User / Data Subject]) -->|BankID OIDC| BANKID[BankID Norge AS\nNorway — Name, fødselsnummer, birthdate]
BANKID -->|id_token| API[Drop API\nAWS App Runner — Norway/EEA]
DS -->|Mobile, email, recipient details| API
API -->|Encrypted fødselsnummer\nName, contact, KYC status| DB[(PostgreSQL\nEEA — AES-256)]
API -->|Payment instruction\nSender name + recipient IBAN + amount| PISP[Open Banking PISP\nUser's bank — EEA]
PISP -->|Wire transfer\nSender name + recipient IBAN| CORR[Correspondent Bank\nDestination country]
CORR -->|Payment to recipient| RECIP([Recipient\nSerbia / BiH / HR / Other])
API -->|Balance read request| AISP[Open Banking AISP\nUser's bank — EEA]
AISP -->|Balance + masked account| API
API -->|KYC check| SUMSUB[Sumsub\nKYC/AML — EEA]
API -->|Error events| SENTRY[Sentry\nError monitoring — EEA]
API -->|Uptime + logs| BETTERSTACK[BetterStack\nLog monitoring — EEA]
DB -->|On erasure request| ANON[Anonymization job\nPersonal data removed]
DB -->|On data request| EXPORT[Data export to user\nJSON/CSV]
style DB fill:#ffcccc,stroke:#cc0000
style CORR fill:#ffe4cc
style SUMSUB fill:#ffe4cc
Data processors (GDPR Art. 28):
| Processor | Service | Data Shared | Country | DPA Status |
|---|---|---|---|---|
| BankID Norge AS | Norwegian eID authentication | Name, fødselsnummer, birthdate | Norway | Required |
| AWS (Amazon Web Services) | Application hosting + database | All app data | EEA (Frankfurt) | AWS DPA (standard) |
| Sumsub | KYC/AML identity verification | Name, fødselsnummer, KYC docs | EEA | Required |
| Cloudflare | WAF + CDN + DDoS | IP addresses, request metadata | EEA edge | Cloudflare DPA |
| Sentry | Error monitoring | Anonymized error data, no PII in events | EEA | Sentry DPA |
| BetterStack | Uptime + log monitoring | System logs (PII masked) | EEA | BetterStack DPA |
6. Risk Assessment Matrix
6.1 Risk Scoring Scale
| Score | Likelihood | Severity |
|---|---|---|
| 1 | Remote | Negligible |
| 2 | Unlikely | Limited — short-term minor impact |
| 3 | Possible | Significant — real non-negligible impact |
| 4 | Likely | Severe — serious impact on rights |
Risk Score = Likelihood × Severity
- 1-4: Low | 5-8: Medium | 9-12: High | 13-16: Critical
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, AES-256, RBAC, bcrypt, session revocation | MEDIUM → 4 after controls |
| R2 | Data used beyond stated purpose (purpose creep) | 1 | 3 | 3 | Purpose limitation policy, audit logs, DPA contracts | LOW |
| R3 | Inaccurate data causing wrong financial decisions | 2 | 2 | 4 | BankID provides verified identity; balance read from bank directly | LOW |
| R4 | Data retained beyond necessary period | 2 | 2 | 4 | Automated retention/deletion policy | LOW |
| R5 | Cross-border transfer without adequate protection (Serbia, BiH) | 3 | 3 | 9 | SCCs + TIA + data minimization + encryption in transit | MEDIUM → 6 after SCCs |
| R6 | Automated AML/fraud decision adversely affects data subject | 2 | 2 | 4 | Manual review on automated blocks; klageadgang (complaint right) | LOW |
| R7 | BankID session compromise / phishing | 1 | 4 | 4 | BankID Level 4, session timeout, device binding, anti-phishing info | LOW |
| R8 | Fødselsnummer exposure — high-sensitivity data | 2 | 4 | 8 | AES-256-GCM field-level encryption, separate KMS key, compliance-only access | MEDIUM → 4 after controls |
| R9 | Third-country government data access (Serbia, BiH authorities) | 2 | 3 | 6 | Minimal data transferred; only name + IBAN; SCCs; TIA | MEDIUM |
| R10 | Data subject unable to exercise rights (erasure) | 2 | 2 | 4 | DPO process, 30-day SLA; AML retention exceptions documented | 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 | Implement audit_log table for all sensitive operations | Engineering | Pre-production | Planned |
| R1 | External penetration test | Security | 2026-Q3 | Planned |
| R5 | Execute SCCs with all non-EEA correspondent banks | Legal / DPO | Pre-launch | In progress |
| R5 | Conduct Transfer Impact Assessments for Serbia, BiH, Turkey, Pakistan | Compliance | Pre-launch | In progress |
| R5 | Minimize transferred data — sender name only, no fødselsnummer | Engineering | ✓ Architecture decision | Done |
| R8 | Separate KMS key for fødselsnummer — not shared with other data | Engineering | Phase 2 | Planned |
| R9 | TIA per country assessing surveillance law | DPO | Pre-launch | Planned |
| R9 | Consider pseudonymization of sender reference for non-EEA wires (where legally permissible) | Legal | Review | Planned |
Residual risk after mitigation: All residual risks assessed as LOW or MEDIUM (max 6). No CRITICAL or HIGH residual risks remain after planned mitigations.
DPO Conclusion: ☐ Acceptable — proceed with processing (subject to planned mitigations being implemented before launch)
8. DPO Consultation Record
DPO Name: DPO / personvernombud ([email protected]) Consultation Date: 2026-02-12 (initial); ongoing DPO Input:
DPIA confirms that processing of fødselsnummer, bank account data, and cross-border transfers creates medium-level risks manageable with described controls. BankID integration is privacy-enhancing (reduces need to collect separate identity documents). Key pre-launch requirements: SCCs with non-EEA correspondent banks, TIAs for Serbia/BiH/Turkey/Pakistan, audit_log implementation, and formal registration with Datatilsynet behandlingsprotokoll (Art. 30).
DPO Recommendation:
- Conditional approval — subject to implementing mitigations before production launch
- Rejected
- Escalate to supervisory authority
DPO Signature: _________________________ Date: _____________
9. Supervisory Authority Consultation (if required)
Consultation Required: NO Reason: After planned mitigations, no residual risks exceed the HIGH threshold. GDPR Art. 36 prior consultation not required. Datatilsynet will be engaged as part of standard Finanstilsynet licensing process.
10. DPIA Review Schedule
Next scheduled review: 2027-02-23 (annual) OR when any of the following occurs:
- BankID integration implemented (Phase 2)
- Open Banking AISP/PISP integration implemented (Phase 2)
- New remittance corridor added (new TIA required)
- Real KYC/AML system integrated (Sumsub production)
- Migration from SQLite to PostgreSQL completed
- New regulations enter into force (DORA, updated hvitvaskingsloven)
- Any data breach related to this processing
Review Owner: DPO Review Log:
| Date | Reviewer | Changes Made | Outcome |
|---|---|---|---|
| 2026-02-12 | ALAI Holding AS | Initial DPIA (dpia-vurdering.md) | Approved with conditions |
| 2026-02-23 | Security Architect | Formalized in compliance template | Draft — DPO review pending |
Approval
| Role | Name | Date | Signature |
|---|---|---|---|
| Author | Security Architect | 2026-02-23 | |
| DPO | |||
| Processing Owner | CEO / Daglig leder | ||
| Legal Counsel | |||
| Management |