Data Protection Impact Assessment (DPIA)

Data Protection Impact Assessment (DPIA)

Project: {{PROJECT_NAME}}Drop — PSD2 Pass-Through Payment App Processing Activity: {{PROCESSING_ACTIVITY_NAME}}All personal data processing in Drop payment service Version: {{VERSION}}1.0 Date: {{DATE}}2026-02-23 Author: {{AUTHOR}}Security Architect DPO: {{DPO_NAME}}DPO ({{DPO_EMAIL}})[email protected]) Status: Draft | DPO Review | Approved | Requires Supervisory Authority Consultation Reviewers: {{REVIEWERS}}DPO, Legal Counsel, CTO Classification: Confidential Document-ID: DPIA-DROP-001

Document History

Version	Date	Author	Changes
0.1	{{DATE}}2026-02-12	{{AUTHOR}}ALAI Holding AS	Initial draftDPIA assessment (legal/dpia-vurdering.md)
1.0	{{DATE}}2026-02-23	{{DPO_NAME}}Security Architect	DPOFormalized reviewedin andcompliance approvedtemplate format

---

DPIA Trigger Checklist

A DPIA is required if ANY of the following apply:apply (GDPR Art. 35):

#	Trigger	Applies?	Notes
1	Systematic and extensive evaluation of personal aspects (profiling, automated decision-making with legal/significant effects)	{{YES/NO}}YES	{{NOTES}}Automated fraud detection and AML transaction monitoring — flags transactions with legal/financial consequences for data subjects
2	Large-scale processing of special category data (health, religion, ethnicity, sexual orientation, criminal records)	{{YES/NO}}NO	{{NOTES}}No health/religion/ethnicity data processed
3	Systematic monitoring of publicly accessible areas (CCTV, tracking)	{{YES/NO}}NO	{{NOTES}}Not applicable
4	Processing of biometric or genetic data	{{YES/NO}}NO	{{NOTES}}BankID is not biometric in Drop's processing scope
5	Processing of data concerning vulnerable data subjects (children, employees, patients)	{{YES/NO}}YES	{{NOTES}}General population including financially vulnerable users; minimum age 18 enforced via BankID fødselsnummer
6	Innovative use of technology with unpredictable privacy impact	{{YES/NO}}YES	{{NOTES}}Open Banking PSD2 AISP/PISP integration; BankID OIDC — new technology combination
7	Cross-border transfer outside EEA without adequate protection	{{YES/NO}}YES	{{NOTES}}Remittance to Serbia, BiH, Turkey, Pakistan — no adequacy decisions
8	ProcessingLarge-scale processing of financial data that prevents data subjects from exercising rights	{{YES/NO}}YES	{{NOTES}}Transaction data, bank account numbers, cross-border payment flows

DPIA Required: YES / NO Reason: {{REASON_IF_TRIGGERED}}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: {{PROCESSING_ACTIVITY_NAME}}Drop Payment Service — Full Processing Scope System/Product: {{SYSTEM_NAME}}Drop — PSD2 pass-through payment app (getdrop.no) Business Unit: {{BUSINESS_UNIT}}ALAI Holding AS (org.nr. 932 516 136) Processing Owner: {{OWNER_ROLE}}CEO ({{OWNER_EMAIL}})/ Compliance Officer

Description of Processing: {{DETAILED_DESCRIPTION_OF_WHAT_IS_BEING_PROCESSED_AND_HOW}}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:

1. User registration and identity verification via BankID OIDC — collection of name, fødselsnummer (national ID), birthdate (age verification), mobile number
2. PSD2 AISP — reading bank account balances from user's bank via Open Banking API (with explicit user consent)
3. PSD2 PISP — initiating payments from user's bank account (remittance to 30+ countries, QR payments in-store)
4. KYC/AML compliance — customer due diligence per hvitvaskingsloven, transaction monitoring, PEP/sanctions screening
5. Transaction history — storing remittance and QR payment records per bokføringsloven

Trigger / Business Justification: {{WHY_IS_THIS_PROCESSING_NECESSARY_BUSINESS_CASE}}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)	{{DATA_CATEGORY}}Name, fødselsnummer, birthdate	{{METHOD}}BankID OIDC	{{LOCATION}}Norway (BankID Norge AS)
Collection (user-entered)	Mobile number, email, recipient details	Next.js API	Norway (AWS App Runner)
Storage (identity)	{{DATA_CATEGORY}}Encrypted fødselsnummer, name, KYC status	{{DB_TECHNOLOGY}}SQLite → PostgreSQL	{{LOCATION}}EEA (AWS)
Storage (transactions)	Amount, corridor, timestamp, recipient	SQLite → PostgreSQL	EEA (AWS)
Processing / Analysis(AISP)	{{DATA_CATEGORY}}Bank balance, account number	{{TOOL}}PSD2 API → user's bank	{{LOCATION}}EEA
Processing (PISP)	Payment instruction, amount, recipient IBAN	Open Banking API	EEA → remittance destination
Sharing / Transfer(remittance)	{{DATA_CATEGORY}}Sender name, recipient name/IBAN, amount	{{PROTOCOL}}SWIFT / correspondent bank	{{RECIPIENT_LOCATION}}EEA → Serbia/BiH/HR/other
KYC/AML processing	Name, fødselsnummer, PEP/sanctions status	Sumsub + internal rules	EEA (Sumsub)
Deletion / Anonymization	{{DATA_CATEGORY}}All categories	{{METHOD}}Automated retention job	{{LOCATION}}EEA

---

2. Necessity & Proportionality Assessment

2.1 Purposes of Processing

Purpose	Specific Description	Legitimate?
{{PURPOSE_1}}User authentication	{{SPECIFIC_DESCRIPTION}}BankID OIDC to verify identity and age (≥18)	YES — {{JUSTIFICATION}}mandatory for financial services; hvitvaskingsloven § 12
{{PURPOSE_2}}Payment execution	{{SPECIFIC_DESCRIPTION}}PISP from user's bank account for remittance/QR	YES — {{JUSTIFICATION}}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
{{FIELD_1}}name	YES	YES — {{WHY}}required for identity, required on wire transfers (FATF Rec. 16)	N/A
{{FIELD_2}}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 — {{WHY}}authentication factor, notification	N/A
{{FIELD_3}}email	YES	PARTIALYES — {{EXPLAIN}}account management, receipts	Collect only {{SUBSET}}N/A
{{FIELD_4}}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	NOYES — {{WHY}}fraud prevention, rate limiting, GDPR accountability	RemoveHashed/pseudonymized fromin collectionlogs 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:removal / minimization:

{{FIELDS_TO_REMOVE}}

• ip_address in logs: Pseudonymize after 3 months
• user_agent: Retain for security analysis only, not customer-facing

2.3 Lawful Basis

Processing Activity	Lawful Basis	Justification
{{ACTIVITY_1}}User registration + BankID verification	Contract (Art. 6.1.6(1)(b)) + Legal obligation (Art. 6(1)(c))	{{JUSTIFICATION}}Required to provide service + hvitvaskingsloven § 12
{{ACTIVITY_2}}Payment execution (PISP)	Contract (Art. 6(1)(b))	Core service delivery
Account balance reading (AISP)	Consent (Art. 6.1.6(1)(a))	{{JUSTIFICATION}}PSD2 requires explicit consent for AISP
{{ACTIVITY_3}}KYC/AML data collection	Legal obligation (Art. 6(1)(c))	Hvitvaskingsloven §§ 4, 10-18, 30
Fraud detection and monitoring	Legitimate interest (Art. 6.1.6(1)(f))	LIA: {{LIA_REF}}fraud prevention necessity outweighs privacy intrusion; data minimized

Technical

For special category datalogs (ifIP, applicable):

device) interest

Legitimate
Data	Special Category	(Art. 96(1)(f)) Basis	LIA: security and accountability; pseudonymized after 3 months
{{HEALTH_DATA}}Transaction history storage	HealthLegal obligation (Art. 9.2.h)6(1)(c))	ExplicitBokføringsloven consent§ +13 healthcare— provision5-year accounting retention

---

3. Data Subjects & Categories of Data

3.1 Data Subject Groups

Group	Description	Estimated Volume	Vulnerability Level
{{GROUP_1}}Norwegian residents (users)	{{DESCRIPTION}}All Drop users — BankID-verified, age ≥18	{{N}}Up recordsto all Norwegian residents	Low / Medium /(financial Highdata)
{{GROUP_2}}Merchants	{{DESCRIPTION}}Businesses using Drop QR payments	{{N}}Smaller records	Low / Medium / High
Employees	Internal staff	{{N}} recordssubset	Medium
MinorsRemittance (< 18)recipients	{{IF_APPLICABLE}}Individuals in 30+ countries receiving money	{{N}}External records— minimal data held	HighLow (only name + IBAN stored)

3.2 Personal Data Categories

ID 5

Category	Data Elements	Sensitivity	VolumeRetention
ContactIdentity information(Norwegian)	Name, email,fødselsnummer phone(encrypted), BankID reference	High — unique national identifier	5 years after account closure
Contact	Mobile number (+47), email	Standard	{{N}}Duration of account
IdentityFinancial — transactions	DateAmount, ofcorridor, birth,timestamp, nationalcurrency	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	{{N}}5 years
LocationKYC/AML	Risk classification, PEP status, EDD documents	Restricted	5 years (hvvl. § 30)
Technical	IP address, physicaldevice addressID, session tokens	Standard	{{N}}IP: 3 months; session: 24h
Behavioral	UsageLogin patterns,times, preferencestransaction patterns (for AML)	Standard	{{N}}
Financial	{{IF_APPLICABLE}}	High	{{N}}
Health	{{IF_APPLICABLE}}	Special category	{{N}}
Biometric	{{IF_APPLICABLE}}	Special category	{{N}}years

---

4. Data Processing Purposes & Legal Basis

Processing Purpose	Personal Data Used	Legal Basis	Retention Period
{{PURPOSE_1}}User authentication (BankID)	{{DATA_FIELDS}}Name, fødselsnummer, birthdate	Contract + Legal obligation	Account duration + 5 years
Remittance execution	Name, recipient IBAN, amount, currency	Contract (Art. 6.1.6(1)(b))	{{PERIOD}}5 years (bokføringsloven § 13)
{{PURPOSE_2}}QR payment execution	{{DATA_FIELDS}}Amount, merchant ref, timestamp	Contract (Art. 6(1)(b))	5 years
Balance display (AISP)	Account number (masked), balance	Consent (Art. 6.1.6(1)(a))	UntilSession withdrawnonly — not persisted
{{PURPOSE_3}}KYC customer due diligence	{{DATA_FIELDS}}Name, fødselsnummer, risk classification	LegitimateLegal interestobligation (Art. 6(1)(c))	{{PERIOD}}5 years after account closure (hvvl. § 30)
AML transaction monitoring	Transaction patterns, amounts, corridors	Legal obligation (Art. 6(1)(c))	5 years
Fraud detection	BehavioralIP, +device financialID, behavioral patterns	Legitimate interest (Art. 6(1)(f))	23 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	IdentityTransaction +data, transactionidentity data	Legal obligation (Art. 6(1)(c))	{{REGULATORY_PERIOD}}Per relevant law (min 5 years)

---

5. Data Flow Mapping

flowchart TD
    DS([Drop User / Data Subject]) -->|ProvidesBankID data|OIDC| COLLECT[CollectionBANKID[BankID Point\n{{FORM/API/IMPORT}}]Norge COLLECTAS\nNorway — Name, fødselsnummer, birthdate]
    BANKID -->|Validates|id_token| APP[ApplicationAPI[Drop Layer]API\nAWS APPApp Runner — Norway/EEA]
    DS -->|Stores|Mobile, DB[(Primaryemail, Database\n{{COUNTRY}}recipient —details| {{ENCRYPTION}})]API
    APPAPI -->|Logs|Encrypted LOGS[Logfødselsnummer\nName, System\n{{COUNTRY}}contact, KYC status| DB[(PostgreSQL\nEEA — PIIAES-256)]
    masked]
    DBAPI -->|Syncs|Payment DW[(Analytics\n{{COUNTRY}}instruction\nSender name + recipient IBAN + amount| PISP[Open Banking PISP\nUser's bank — Pseudonymized)]EEA]
    DBPISP -->|Transfers|Wire PROC1[Processortransfer\nSender 1\n{{PROCESSOR}}name —+ {{COUNTRY}}]recipient DBIBAN| CORR[Correspondent Bank\nDestination country]
    CORR -->|Transfers|Payment PROC2[Processorto 2\n{{PROCESSOR}}recipient| RECIP([Recipient\nSerbia / BiH / HR / Other])
    API -->|Balance read request| AISP[Open Banking AISP\nUser's bank — {{COUNTRY}}]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| EXPORT[DataANON[Anonymization Export\nBack tojob\nPersonal data subject]removed]
    DB -->|On erasure|data ANON[Anonymizationrequest| Service]EXPORT[Data ANONexport -->|Anonymized|to DBuser\nJSON/CSV]

    style DB fill:#ffcccc,stroke:#cc0000
    style DW fill:#ffffcc
    style PROC1CORR fill:#ffe4cc
    style PROC2SUMSUB fill:#ffe4cc

Data processors (GDPR Art. 28):

Processor	Service	Data Shared	Country	DPA SignedStatus
{{PROCESSOR_1}}BankID Norge AS	{{SERVICE}}Norwegian eID authentication	{{DATA_CATEGORIES}}Name, fødselsnummer, birthdate	{{COUNTRY}}Norway	Yes — {{DATE}}Required
{{PROCESSOR_2}}AWS (Amazon Web Services)	{{SERVICE}}Application hosting + database	{{DATA_CATEGORIES}}All app data	{{COUNTRY}}EEA (Frankfurt)	YesAWS —DPA {{DATE}}(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 — unlikely to occur	Negligible — minimal impact on data subjects
2	Unlikely — could occur in exceptional circumstances	Limited — short-term,term minor inconvenienceimpact
3	Possible — could occur in some circumstances	Significant — real,real non-negligible impact
4	Likely — will probably occur	Severe — serious impact on rights and freedoms
5	Near-certain — expected to occur	Maximum — irreversible harm (e.g., identity theft, discrimination, physical danger)

Risk Score = Likelihood × Severity

• 1-6:4: Low —| acceptable with basic controls
• 7-12:5-8: Medium —| requires mitigation
• 13-19:9-12: High —| requires strong mitigation before processing
• 20-25:13-16: Critical — consult supervisory authority before proceeding

6.2 Risk to Data Subjects

Risk ID	Risk to Data Subjects	Likelihood	Severity	Score	Existing Controls	Residual Risk
R1	Unauthorized access to personalfinancial data (breach)/ breach	32	4	128	Encryption,TLS access1.3, control,AES-256, MFARBAC, bcrypt, session revocation	MEDIUM → 4 after controls
R2	Data used forbeyond stated purpose beyond original consent (purpose creep)	21	3	63	Purpose limitation controls,policy, audit logs, DPA contracts	LOW
R3	Inaccurate data leadingcausing towrong incorrectfinancial decisions	32	32	94	DataBankID qualityprovides checks,verified subjectidentity; accessbalance read from bank directly	MEDIUMLOW
R4	Data retained beyond necessary period	2	2	4	Automated retentionretention/deletion jobspolicy	LOW
R5	{{SPECIFIC_RISK_1}}Cross-border transfer without adequate protection (Serbia, BiH)	{{L}}3	{{S}}3	{{L×S}}9	{{CONTROLS}}SCCs + TIA + data minimization + encryption in transit	{{RESIDUAL}}MEDIUM → 6 after SCCs
R6	{{SPECIFIC_RISK_2}}Automated AML/fraud decision adversely affects data subject	{{L}}2	{{S}}2	{{L×S}}4	{{CONTROLS}}Manual review on automated blocks; klageadgang (complaint right)	{{RESIDUAL}}LOW
R7	Cross-borderBankID transfersession withoutcompromise adequate/ protectionphishing	1	4	4	BankID Level 4, session timeout, device binding, anti-phishing info	LOW
R8	Fødselsnummer exposure — high-sensitivity data	2	4	8	SCCsAES-256-GCM infield-level place,encryption, adequacyseparate checksKMS 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
R8R10	Data subject unable to exercise rights (erasure/portability)erasure)	2	32	64	Self-serviceDPO endpoints,process, 30-day SLASLA; AML retention exceptions documented	LOW

---

7. Mitigation Measures

Risk ID	Mitigation Measure	Owner	Deadline	Status
R1	ImplementField-level field-levelAES-256-GCM encryption for {{HIGH_RISK_FIELDS}}fødselsnummer	Engineering	{{DATE}}Phase 2	TODOPlanned
R1	DeployImplement intrusionaudit_log detectiontable systemfor all sensitive operations	PlatformEngineering	{{DATE}}Pre-production	TODOPlanned
R3R1	AddExternal datapenetration validation at ingestion with rejection of invalid recordstest	EngineeringSecurity	{{DATE}}2026-Q3	TODOPlanned
R5	{{MITIGATION}}	{{OWNER}}	{{DATE}}	{{STATUS}}
R6	{{MITIGATION}}	{{OWNER}}	{{DATE}}	{{STATUS}}
R7	ConductExecute SCCs reviewwith forall {{TRANSFER}}non-EEA —correspondent verify adequacybanks	Legal / DPO	{{DATE}}Pre-launch	TODOIn 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 are(max acceptable for proceeding.6). No CRITICAL or HIGH residual risks remain.remain after planned mitigations.

DPO Conclusion: ☐ Acceptable — proceed with processing |(subject ☐to Requiresplanned supervisorymitigations authoritybeing consultationimplemented before launch)

---

8. DPO Consultation Record

DPO Name: {{DPO_NAME}}DPO / personvernombud ([email protected]) Consultation Date: {{DATE}}2026-02-12 (initial); ongoing DPO Input:

{{DPO_COMMENTS_AND_RECOMMENDATIONS}}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:

•  Approved — risks are acceptable and adequately mitigated
• Conditional approval — subject to implementing mitigations bybefore {{DATE}}production launch
• Rejected — risks not adequately addressed — redesign required
• Escalate to supervisory authority — high residual risk remains

DPO Signature: _________________________ Date: _____________

---

9. Supervisory Authority Consultation (if required)

Consultation Required: YES / NO Reason: {{REASON}}

After

Ifplanned YESmitigations, —no Priorresidual risks exceed the HIGH threshold. GDPR Art. 36 prior consultation details:not required. Datatilsynet will be engaged as part of standard Finanstilsynet licensing process.

• Authority contacted: {{DPA_NAME}} ({{COUNTRY}})
• Contact date: {{DATE}}
• Reference number: {{REF}}
• Outcome: {{OUTCOME}}
• Authority decision: {{DATE}} — {{DECISION}}

---

10. DPIA Review Schedule

Next scheduled review: {{DATE}}2027-02-23 or(annual) OR when any of the following occurs:

• SignificantBankID changeintegration 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 thePostgreSQL processing activity or technologycompleted
• DataNew regulations enter into force (DORA, updated hvitvaskingsloven)
• Any data breach or near-miss related to this processing
• New risks identified post-implementation
• Change in applicable regulations
• Processor relationship changes
• Annually (at minimum)

Review Owner: {{DPO_NAME}}DPO Review Log:

Date	Reviewer	Changes Made	Outcome
{{DATE}}2026-02-12	{{NAME}}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