# Regulatory Framework

# Regulatory Map

# Drop Regulatory Map v2
## Norwegian Financial Services Regulatory Framework

**Date:** 2026-02-12
**Prepared for:** ALAI Holding AS / Drop Payment App
**Scope:** All regulations applicable to a payment app serving ALL residents of Scandinavia
**App model:** Pass-through payments (remittance + QR in-store), no deposit-taking

---

## Table of Contents
1. [Finanstilsynet Licensing](#1-finanstilsynet-licensing)
2. [Betalingstjenesteloven / PSD2](#2-betalingstjenesteloven--psd2)
3. [Hvitvaskingsloven / AML](#3-hvitvaskingsloven--aml)
4. [Personopplysningsloven / GDPR](#4-personopplysningsloven--gdpr)
5. [IKT-forskriften / DORA](#5-ikt-forskriften--dora)
6. [Finansforetaksloven](#6-finansforetaksloven)
7. [Valutaregisterloven](#7-valutaregisterloven)
8. [Consumer Protection](#8-consumer-protection)
9. [DORA Timeline for Norway](#9-dora-timeline-for-norway)
10. [Regulatory Priority Matrix](#10-regulatory-priority-matrix)

---

## 1. Finanstilsynet Licensing

### Applicable Law
- **Finanstilsynsloven** (Lov om Finanstilsynet, LOV-1956-12-07-1)
- **Betalingstjenesteloven** kapittel 2 (licensing provisions)
- **Finansforetaksloven** (LOV-2015-04-10-17) for broader financial enterprise requirements

### License Options for Drop

#### Option A: Begrenset betalingsforetak (Limited Payment Institution)
**Law:** Betalingstjenesteloven (LOV-2018-11-23-85) SS 2-10c

| Requirement | Detail |
|-------------|--------|
| Monthly transaction volume | Max 6 million NOK/month average over 12 months |
| Capital requirement | None (simplified regime) |
| Application | Simplified application to Finanstilsynet |
| Passporting | NO -- Norway only, no EEA passport |
| Fit & proper | Directors and beneficial owners must pass fit & proper assessment |
| AML | Full AML compliance still required |
| PSD2 SCA | Required |
| Safeguarding | Client funds must be safeguarded (segregated account or insurance) |

**Pros:** Faster to obtain (3-6 months), lower capital cost, suitable for MVP launch.
**Cons:** Volume ceiling, no passporting to Sweden/Denmark, must upgrade if volume exceeds threshold.

**Drop fit:** Good for initial launch. 6M NOK/month allows approximately 3,000 remittances of 2,000 NOK average.

#### Option B: Ordinaert betalingsforetak (Full Payment Institution)
**Law:** Betalingstjenesteloven SS 2-3 to SS 2-10

| Requirement | Detail |
|-------------|--------|
| Initial capital | 125,000 EUR (approx. 1.4M NOK) for payment services incl. money remittance |
| Ongoing capital | Higher of: initial capital, OR calculated based on method A/B/C in SS 2-9 |
| Application timeline | 6-12 months (Finanstilsynet review) |
| Passporting | YES -- EEA-wide via notification to host state supervisors |
| Governance | Board, compliance officer, internal audit function |
| Safeguarding | Client funds in segregated account OR insurance/guarantee |
| Fit & proper | All board members, CEO, compliance officers |
| Reporting | Annual reports, quarterly capital adequacy, incident reports |

**Pros:** No volume limit, EEA passporting to Sweden/Denmark, full credibility.
**Cons:** Higher capital, longer timeline, heavier governance burden.

**Drop fit:** Target license for scaling to all of Scandinavia. Apply after MVP validates market.

#### Option C: Agent Model (under existing licensee)
**Law:** Betalingstjenesteloven SS 2-12

| Requirement | Detail |
|-------------|--------|
| Concept | Drop operates as agent of an existing licensed payment institution |
| Registration | The principal (licensee) registers Drop as agent with Finanstilsynet |
| Capital | None required from Drop -- principal is responsible |
| AML | Principal's AML program applies; Drop must comply operationally |
| Liability | Principal is liable for Drop's actions |
| Speed | Fastest route to market (1-3 months) |

**Pros:** Fastest launch, no capital requirement, leverage existing compliance infrastructure.
**Cons:** Revenue share with principal, less control, dependent on partner's license scope.

**Potential partners for agent model:**
- Licensed Norwegian payment institutions (e.g., smaller PSPs)
- Licensed EMIs operating in Norway via passporting
- BaaS providers (Swan, Modulr, Banking Circle) with appropriate licenses

### Required Documents for Licensing Application
1. Business plan with 3-year financial projections
2. Description of payment services to be offered (SS 2-4)
3. Organizational chart with fit & proper documentation for all key persons
4. AML/CFT policy and procedures (full program)
5. Operational procedures and internal control description
6. IT security policy and business continuity plan
7. Client fund safeguarding arrangements
8. Capital adequacy calculations and evidence of initial capital
9. Outsourcing policy (if using third-party services)
10. Complaint handling procedures

### Priority: CRITICAL -- Must be resolved before any live transaction

---

## 2. Betalingstjenesteloven / PSD2

### Applicable Law
- **Betalingstjenesteloven** (LOV-2018-11-23-85) -- Norwegian implementation of PSD2
- **Betalingssystemloven** (LOV-1999-12-17-95) -- Payment systems
- **Forskrift om betalingstjenester** (FOR-2019-02-15-152) -- Regulation on payment services

### Strong Customer Authentication (SCA)
**Law:** Betalingstjenesteloven SS 4-28, SS 4-29; Delegated Regulation (EU) 2018/389

| Requirement | Section | What Drop Must Do |
|-------------|---------|-------------------|
| SCA for electronic payments | SS 4-28 | Apply SCA for all payment initiation and online access |
| Two of three factors | Art. 6-8 (Del. Reg.) | Combine: knowledge (PIN/password), possession (phone/device), inherence (biometrics) |
| Dynamic linking | Art. 5 (Del. Reg.) | Transaction amount and payee must be linked to authentication code |
| Exemptions | Art. 10-18 (Del. Reg.) | Low-value transactions (<500 NOK contactless), trusted beneficiaries, recurring payments |
| 90-day re-authentication | Art. 10 (Del. Reg.) | Re-authenticate if account not accessed for 90 days |

**Current state:** Drop uses email+password login with JWT. BankID is mentioned but not implemented. No SCA compliance.

**Required implementation:**
1. BankID integration for initial authentication (covers possession + knowledge)
2. Transaction signing with BankID or app-based second factor for payments
3. Dynamic linking: display amount + payee in BankID signing dialog
4. Session timeout and re-authentication after 5 minutes of inactivity (for payment sessions)

### Open Banking (PSD2 Access to Account)
**Law:** Betalingstjenesteloven SS 4-40 to SS 4-46

| Requirement | Section | Relevance to Drop |
|-------------|---------|-------------------|
| AISP (Account Information) | SS 4-41 | If Drop reads user bank balances via Open Banking |
| PISP (Payment Initiation) | SS 4-44 | If Drop initiates transfers from user bank accounts |
| Dedicated interface (API) | SS 4-40 | Drop must use banks' PSD2 APIs |
| PSU consent | SS 4-41(2) | Explicit user consent required before accessing accounts |
| No storing of credentials | SS 4-44(3) | Drop must NOT store user's bank login credentials |

**Architecture note:** Drop's stated pass-through model relies on Open Banking. This requires either AISP/PISP license or agent arrangement with a licensed AISP/PISP.

### Consumer Protection (PSD2)
**Law:** Betalingstjenesteloven kapittel 3 and 4

| Requirement | Section | What Drop Must Do |
|-------------|---------|-------------------|
| Pre-contractual information | SS 3-1 to SS 3-8 | Provide framework agreement with all fees, exchange rates, execution time |
| Information per transaction | SS 3-22 to SS 3-26 | Receipt with amount, fees, exchange rate, reference, date |
| Execution time | SS 4-15 | Remittance: must credit recipient's PSP by end of next business day (EEA), D+4 for non-EEA |
| Refund rights | SS 4-19 to SS 4-22 | Unauthorized transactions: user liable max 450 NOK if negligent, full refund if not |
| Value date | SS 4-18 | Credit value date = date amount received by recipient's PSP |
| Charges transparency | SS 3-23 | All charges must be disclosed BEFORE transaction is authorized |
| Exchange rate | SS 3-24 | Actual exchange rate and reference rate must be disclosed |

**Required documents:**
1. Framework agreement / user terms (rammeavtale)
2. Fee schedule (gebyroppstilling)
3. Transaction receipts (per transaction)
4. Pre-authorization disclosure (amount, fees, FX rate, ETA)

### Priority: CRITICAL -- PSD2 is the legal basis for operating

---

## 3. Hvitvaskingsloven / AML

### Applicable Law
- **Hvitvaskingsloven** (LOV-2018-06-01-23) -- Anti-Money Laundering Act
- **Hvitvaskingsforskriften** (FOR-2018-09-14-1324) -- AML Regulation
- **Sanksjonsforskrifter** -- Various sanctions regulations

### Customer Due Diligence (KYC)
**Law:** Hvitvaskingsloven SS 10 to SS 18

| Requirement | Section | What Drop Must Do |
|-------------|---------|-------------------|
| Identity verification | SS 12 | Verify name, DOB, national ID number (fodselsnummer) using valid ID document |
| Electronic verification | SS 12(3) | BankID qualifies as electronic verification for Norwegian residents |
| Beneficial owner (individuals) | SS 13 | For individual customers: the customer themselves |
| Purpose of relationship | SS 12(1)d | Document why the customer is using the service |
| Ongoing monitoring | SS 24 | Monitor transactions for unusual patterns |
| Enhanced due diligence | SS 17-18 | Required for higher-risk customers, countries, or transaction patterns |
| Simplified due diligence | SS 16 | Possible for lower-risk, low-value services (not recommended for remittance) |
| Record keeping | SS 30 | Store KYC data for 5 years after relationship ends |
| Re-verification | SS 24(3) | When risk profile changes or doubts about existing data |

**Current state:** Drop has a `kyc_status` field (pending/approved/rejected) and mock Sumsub integration. No real KYC implementation.

**Required implementation:**
1. BankID integration for Norwegian residents (covers identity verification)
2. ID document verification for non-BankID eligible (passport/national ID via Sumsub/Onfido)
3. Address verification (e.g., Folkeregisteret lookup or utility bill)
4. Source of funds declaration for transfers above thresholds
5. Risk categorization per customer (low/medium/high)

### Transaction Monitoring
**Law:** Hvitvaskingsloven SS 24, SS 25

| Requirement | Section | What Drop Must Do |
|-------------|---------|-------------------|
| Ongoing monitoring | SS 24 | Automated monitoring of all transactions |
| Unusual transactions | SS 25 | Investigate transactions inconsistent with customer profile |
| STR filing | SS 26 | File Suspicious Transaction Reports with EFE (Ekonomisk kriminalitet enheten) |
| No tipping off | SS 28 | NEVER inform the customer that an STR has been filed |
| Internal procedures | SS 8 | Written AML procedures, appointed AML officer |
| Training | SS 36 | Regular AML training for all relevant staff |

**Transaction monitoring rules to implement:**
1. Structuring detection (multiple transactions just below reporting thresholds)
2. Rapid movement (funds in/out within short timeframe)
3. Unusual corridors (sudden changes in destination countries)
4. Volume spikes (significantly above normal pattern)
5. High-risk country flags (FATF grey/black list countries)
6. PEP matching (see below)

### PEP and Sanctions Screening
**Law:** Hvitvaskingsloven SS 18; Various sanctions forskrifter

| Requirement | Section | What Drop Must Do |
|-------------|---------|-------------------|
| PEP screening | SS 18(1) | Screen all customers against PEP lists at onboarding and ongoing |
| Enhanced due diligence for PEPs | SS 18(2-3) | Senior management approval, source of wealth, enhanced monitoring |
| Sanctions screening | Sanctions regulations | Screen against UN, EU, and Norwegian sanctions lists |
| Ongoing screening | SS 18(5), SS 24 | Continuous monitoring, not just onboarding |
| Close associates | SS 18(1)b | Screen family members and known close associates of PEPs |

**Required integrations:**
1. PEP database (ComplyAdvantage, Refinitiv World-Check, or similar)
2. Sanctions list screening (EU consolidated list, UN Security Council list, Norwegian MFA list)
3. Ongoing batch screening (daily or real-time for new entries)

### AML Risk Assessment
**Law:** Hvitvaskingsloven SS 6, SS 7

Drop must conduct and document a risk assessment covering:

| Risk Factor | Assessment for Drop |
|-------------|-------------------|
| Customer risk | General population of Scandinavia; some customer segments may be higher-risk based on occupation or source of funds |
| Product/service risk | Remittance services are inherently higher-risk (FATF typology); QR payments are lower-risk |
| Channel risk | Mobile/digital-only = moderate risk (no face-to-face) |
| Geographic risk | Corridors to 30+ countries, some high-risk jurisdictions. Turkey, Pakistan on FATF monitoring. Serbia, Bosnia lower-risk but outside EU |
| Transaction risk | Variable amounts, cross-border nature |

**Required documents:**
1. Enterprise-wide AML risk assessment (virksomhetsrettet risikovurdering)
2. AML policy and procedures manual (AML-handbok)
3. STR reporting procedures
4. Customer risk categorization model
5. Training plan and records
6. AML officer appointment letter

### Priority: CRITICAL -- Operating without AML compliance is a criminal offense (SS 49)

---

## 4. Personopplysningsloven / GDPR

### Applicable Law
- **Personopplysningsloven** (LOV-2018-06-15-38) -- Norwegian implementation of GDPR
- **GDPR** (Regulation (EU) 2016/679) -- Incorporated via EEA Agreement
- **Forskrift om behandling av personopplysninger** (FOR-2018-06-15-876)

### Data Processing Requirements

| Requirement | GDPR Article | What Drop Must Do |
|-------------|-------------|-------------------|
| Lawful basis | Art. 6 | Contract performance (Art. 6(1)(b)) for core service; Legal obligation (Art. 6(1)(c)) for AML; Consent (Art. 6(1)(a)) for marketing |
| Special category data | Art. 9 | Avoid processing unless necessary; biometric data for KYC requires explicit consent or legal obligation |
| Transparency | Art. 13-14 | Privacy policy in Norwegian (nb), covering all processing activities |
| Purpose limitation | Art. 5(1)(b) | Only process for stated purposes |
| Data minimization | Art. 5(1)(c) | Collect only what is necessary |
| Storage limitation | Art. 5(1)(e) | Define retention periods (AML: 5 years; transactions: 5 years; marketing: until consent withdrawn) |
| Accuracy | Art. 5(1)(d) | Keep data up to date; allow corrections |
| Data subject rights | Art. 15-22 | Access, rectification, erasure, portability, restriction, objection |
| Records of processing | Art. 30 | Maintain a Register of Processing Activities (behandlingsprotokoll) |

### DPIA (Data Protection Impact Assessment)
**GDPR Article 35; Datatilsynet guidelines**

A DPIA is MANDATORY for Drop because:
1. Processing of financial data at scale
2. Systematic monitoring of individuals (transaction monitoring)
3. Cross-border data transfers (remittance to 30+ countries)
4. Vulnerable groups potential (newly arrived residents, etc.)
5. New technology use (mobile payments, QR)

| DPIA Requirement | What Drop Must Document |
|-----------------|------------------------|
| Processing description | All personal data flows in the app |
| Necessity and proportionality | Why each data element is needed |
| Risk assessment | Risks to data subjects from processing |
| Mitigating measures | Technical and organizational safeguards |
| Datatilsynet consultation | Required if residual risk remains high after mitigations (Art. 36) |

### Cross-Border Transfers
**GDPR Chapter V (Art. 44-49)**

| Destination | Transfer Mechanism Required |
|-------------|---------------------------|
| EEA countries | No restriction (free flow) |
| Adequacy decision countries (UK, Japan, etc.) | No additional safeguard needed |
| Serbia | No adequacy decision -- needs SCCs (Standard Contractual Clauses) + TIA |
| Bosnia & Herzegovina | No adequacy decision -- needs SCCs + TIA |
| Turkey | No adequacy decision -- needs SCCs + TIA |
| Pakistan | No adequacy decision -- needs SCCs + TIA; higher supplementary measures |
| Poland | EEA member -- no restriction |

**Transfer Impact Assessment (TIA):** Required for each non-adequate country. Must assess local surveillance laws and determine if SCCs provide sufficient protection.

### Required Documents
1. Privacy policy (personvernerklaering) -- Norwegian language
2. DPIA (vurdering av personvernkonsekvenser)
3. Register of processing activities (behandlingsprotokoll)
4. Data processing agreements (databehandleravtale) with all processors
5. Standard Contractual Clauses for non-EEA transfers
6. Transfer Impact Assessments per destination country
7. Cookie/consent management policy
8. Data breach response plan (bruddhandteringsplan)
9. Data subject rights procedures (innsynsprosedyre)
10. Data retention schedule (lagringstidsplan)

### Priority: HIGH -- Must be in place before processing any personal data

---

## 5. IKT-forskriften / DORA

### Applicable Law
- **IKT-forskriften** (FOR-2003-05-21-630) -- Current IT security regulation for financial institutions
- **DORA** (Regulation (EU) 2022/2554) -- Digital Operational Resilience Act
- **Proposed Norwegian DORA implementation** -- Expected via amendment to Finanstilsynsloven or separate act

### Current IKT-forskriften Requirements

| Requirement | Section | What Drop Must Do |
|-------------|---------|-------------------|
| IT strategy | SS 3 | Document IT strategy aligned with business strategy |
| Risk assessment | SS 4 | IT risk assessment, updated annually |
| Security measures | SS 5 | Technical and organizational security controls |
| Access control | SS 6 | Role-based access, principle of least privilege |
| Change management | SS 7 | Documented procedures for system changes |
| Incident management | SS 8 | Incident detection, response, reporting to Finanstilsynet |
| Business continuity | SS 9 | BCP/DRP with regular testing |
| Outsourcing | SS 10 | Due diligence on IT outsourcing partners |
| Audit trail | SS 11 | Logging of all significant events |
| Testing | SS 12 | Regular security testing (pen tests, vulnerability scans) |

### DORA Requirements (coming for Norway)
**Regulation (EU) 2022/2554** -- Applies to payment institutions

| DORA Requirement | Article | What Drop Must Do |
|-----------------|---------|-------------------|
| ICT risk management framework | Art. 5-16 | Comprehensive ICT risk management framework |
| ICT incident management | Art. 17-23 | Classify, manage, report ICT incidents |
| Major incident reporting | Art. 19 | Report to Finanstilsynet within 4 hours (initial), 72 hours (intermediate), 1 month (final) |
| Digital operational resilience testing | Art. 24-27 | Regular testing including TLPT (threat-led penetration testing) for significant entities |
| Third-party risk management | Art. 28-44 | Contractual requirements for ICT service providers |
| Register of ICT providers | Art. 28(3) | Maintain register of all third-party ICT providers |
| Information sharing | Art. 45 | Participate in threat intelligence sharing |

### Required Documents
1. IT security policy (IKT-sikkerhetspolicy)
2. IT risk assessment (IKT-risikovurdering)
3. Business continuity plan (beredskapsplan)
4. Disaster recovery plan (katastrofegjenopprettingsplan)
5. Incident response plan (hendelseshandteringsplan)
6. Change management procedures
7. Access control policy
8. Third-party/outsourcing assessment register
9. Penetration test reports (annual minimum)
10. Vulnerability scan reports (quarterly minimum)

### Priority: HIGH -- Required for license application and ongoing compliance

---

## 6. Finansforetaksloven

### Applicable Law
- **Finansforetaksloven** (LOV-2015-04-10-17) -- Financial Enterprises Act
- Applies to payment institutions via betalingstjenesteloven SS 2-7 cross-references

### Governance Requirements

| Requirement | Section | What Drop Must Do |
|-------------|---------|-------------------|
| Board composition | SS 8-4 | Board with adequate competence, independent members recommended |
| CEO/management | SS 8-7 | Appointed CEO with fit & proper documentation |
| Fit & proper | SS 3-5 to SS 3-7 | All board members and senior management: police certificate, CV, qualifications assessment |
| Internal control | SS 13-2 | Internal control system, compliance function |
| Compliance officer | SS 13-4 | Designated compliance officer |
| Internal audit | SS 8-18 | Internal audit function (can be outsourced for smaller institutions) |
| Risk management | SS 13-3 | Risk management framework proportionate to size |
| Outsourcing | SS 13-7 | Notification to Finanstilsynet for material outsourcing |
| Reporting | SS 14-1 | Regular reporting to Finanstilsynet (annual accounts, etc.) |

### Capital Requirements

| License Type | Initial Capital | Ongoing Capital |
|-------------|----------------|-----------------|
| Begrenset betalingsforetak | None specified (simplified) | Must have adequate resources |
| Ordinaert betalingsforetak (money remittance) | 20,000 EUR | Method A/B/C calculation or initial capital, whichever higher |
| Ordinaert betalingsforetak (payment services broader) | 125,000 EUR | Method A/B/C calculation or initial capital, whichever higher |

**Note:** Drop's combined remittance + QR payment services likely falls under the 125,000 EUR tier.

### Required Documents
1. Articles of association (vedtekter)
2. Board member CVs and fit & proper declarations
3. Police certificates for board/management
4. Organizational chart with reporting lines
5. Internal control framework description
6. Compliance function description
7. Risk management policy
8. Capital adequacy plan

### Priority: CRITICAL -- Required for license application

---

## 7. Valutaregisterloven

### Applicable Law
- **Valutaregisterloven** (LOV-2004-12-17-109) -- Foreign Exchange Register Act
- **Valutaregisterforskriften** (FOR-2005-02-10-121) -- Foreign Exchange Register Regulation

### Cross-Border Reporting Requirements

| Requirement | Section | What Drop Must Do |
|-------------|---------|-------------------|
| Registration | SS 3 | Register as reporting entity with Statistisk sentralbyra (SSB) |
| Reporting obligation | SS 4 | Report all cross-border payment transactions |
| Transaction data | SS 5 | Report: amount, currency, country, payer/payee, purpose code |
| Threshold | Forskriften SS 4 | All cross-border transactions must be reported (no minimum threshold for payment institutions) |
| Reporting frequency | Forskriften SS 5 | Monthly electronic reporting to SSB |
| Data retention | SS 6 | 5 years |
| Large cash transactions | SS 4a | Not applicable (Drop is digital-only) |

**Implementation requirements:**
1. Assign purpose codes (SWIFT MT103 / ISO 20022 purpose codes) to all remittances
2. Collect destination country per transaction (already in DB schema: `recipients.country`)
3. Build monthly reporting extract for SSB
4. Register with SSB as reporting entity

### Required Documents
1. SSB registration as valutaregisterpliktig
2. Monthly reporting procedures
3. Purpose code mapping for transaction types
4. Reporting archive (5-year retention)

### Priority: HIGH -- Must be in place before first cross-border transaction

---

## 8. Consumer Protection

### Applicable Law
- **Angrerettloven** (LOV-2014-06-20-27) -- Right of Withdrawal Act (distance selling)
- **Finansavtaleloven** (LOV-2020-12-18-146) -- Financial Contracts Act (replaces 1999 version, effective 2023)
- **Markedsfoeringsloven** (LOV-2009-01-09-2) -- Marketing Act
- **Finansklagenemnda** -- Financial Complaints Board (external dispute resolution)

### Angrerettloven (Right of Withdrawal)
**Sections relevant to financial services:**

| Requirement | Section | What Drop Must Do |
|-------------|---------|-------------------|
| Right of withdrawal | SS 22 | 14-day withdrawal right for framework agreement (user registration) |
| Exception for executed transactions | SS 22(2)g | No withdrawal right for fully executed payment transactions |
| Pre-contractual information | SS 8 | Provide all required information before contract conclusion |
| Withdrawal form | SS 11 | Provide standard withdrawal form |
| Confirmation | SS 9 | Written confirmation of agreement on durable medium |

### Finansavtaleloven (Financial Contracts Act)
**New version effective 2023 -- significant consumer protection enhancements**

| Requirement | Section | What Drop Must Do |
|-------------|---------|-------------------|
| Duty to advise | SS 3-1 | Assess customer needs before recommending services |
| Pre-contractual information | SS 3-23 to SS 3-38 | Extensive pre-contractual disclosure requirements |
| Framework agreement | SS 4-1 | Written framework agreement for recurring payment services |
| Unauthorized transactions | SS 4-30 | Refund unauthorized transactions immediately (max 450 NOK customer liability if negligent) |
| Misdirected payments | SS 4-33 | Assist in recovering misdirected payments |
| Complaint handling | SS 3-53 | Internal complaint handling procedure, respond within 15 business days |
| Fee transparency | SS 3-25 | All fees disclosed upfront in standardized format |
| Exchange rate disclosure | SS 3-34 | Actual rate + reference rate + markup disclosed before transaction |
| Execution time | SS 4-12 | Payment execution times must be disclosed and adhered to |

### Finansklagenemnda (Financial Complaints Board)
**Law:** Finansklagenemndloven (LOV-2016-06-17-29)

| Requirement | Detail |
|-------------|--------|
| Membership | Mandatory for all financial service providers in Norway |
| Cost | Annual membership fee based on number of complaints |
| Compliance | Must comply with Finansklagenemnda decisions |
| Information | Must inform customers about right to complain to Finansklagenemnda |

### Markedsfoeringsloven (Marketing)
| Requirement | Section | What Drop Must Do |
|-------------|---------|-------------------|
| No misleading marketing | SS 6-8 | Do not overstate benefits or understate costs/risks |
| Price information | SS 10 | Clear, accurate pricing in all marketing |
| Comparison claims | SS 9 | Substantiate any claims of being "cheaper than Vipps" |
| Spam/electronic marketing | SS 15 | Opt-in consent required for electronic marketing |

### Required Documents
1. Framework agreement (rammeavtale) with all financial terms
2. Fee schedule (gebyrliste) in standardized format
3. Withdrawal form (angrerettskjema)
4. Internal complaint handling procedure (klageprosedyre)
5. Finansklagenemnda membership registration
6. Privacy-compliant marketing consent mechanism

### Priority: HIGH -- Consumer protection failure leads to Finanstilsynet enforcement and reputational damage

---

## 9. DORA Timeline for Norway

### Background
DORA (Digital Operational Resilience Act, Regulation (EU) 2022/2554) applies in the EU from **17 January 2025**. Norway, as an EEA member, must incorporate DORA via the EEA Agreement.

### Expected Timeline

| Date | Milestone |
|------|-----------|
| 17 Jan 2025 | DORA applicable in EU |
| 2025 Q1-Q2 | EEA Joint Committee decision to incorporate DORA into EEA Agreement (ongoing) |
| 2025 H2 - 2026 H1 | Norwegian legislative process (Prop. to Stortinget) |
| 2026 H2 (estimated) | Norwegian DORA implementation enters force |
| 2026-2027 | Transition period for Norwegian financial entities |

### Current Status (February 2026)
- EU DORA has been applicable since January 2025
- The Norwegian government has proposed incorporation into the EEA Agreement
- Finanstilsynet has communicated expectations that Norwegian firms prepare for DORA
- The existing IKT-forskriften remains in force and is substantially aligned with DORA, but DORA adds:
  - More prescriptive ICT incident reporting (4h/72h/1mo)
  - Threat-Led Penetration Testing (TLPT) for significant entities
  - Third-party ICT provider oversight framework
  - Information sharing requirements

### Practical Implication for Drop
- **Now:** Comply with IKT-forskriften (current regulation)
- **2026 H2:** Expect DORA requirements to apply
- **Strategy:** Build ICT risk management framework aligned with DORA from the start, so no retrofit is needed
- Payment institutions are explicitly within DORA scope (Art. 2(1)(d))

---

## 10. Regulatory Priority Matrix

### Phase 1: Pre-Launch (Must-Have for First Transaction)

| # | Regulation | Key Action | Documents |
|---|-----------|------------|-----------|
| 1 | License | Apply for begrenset betalingsforetak OR establish agent arrangement | Application package |
| 2 | AML | Full AML program: risk assessment, KYC procedures, STR process | AML handbook, risk assessment |
| 3 | PSD2 | SCA implementation (BankID), framework agreement, fee disclosure | Rammeavtale, gebyrliste |
| 4 | GDPR | DPIA, privacy policy, processing register | DPIA, personvernerklaering |
| 5 | Governance | Fit & proper, compliance officer, internal control | Board docs, compliance framework |

### Phase 2: Launch + 6 Months

| # | Regulation | Key Action | Documents |
|---|-----------|------------|-----------|
| 6 | Valutaregisteret | Register with SSB, establish monthly reporting | SSB registration, reporting procedures |
| 7 | IKT-forskriften | IT security policy, BCP, pen test | IKT policy, BCP, test reports |
| 8 | Consumer protection | Finansklagenemnda membership, complaint handling | Membership, klageprosedyre |
| 9 | AML ongoing | Transaction monitoring system, PEP/sanctions screening | TM rules, screening integration |
| 10 | Capital | Secure initial capital if pursuing ordinaert license | Capital evidence |

### Phase 3: Scaling (12+ Months)

| # | Regulation | Key Action | Documents |
|---|-----------|------------|-----------|
| 11 | License upgrade | Apply for ordinaert betalingsforetak for Scandinavia expansion | Full application |
| 12 | DORA | Full DORA compliance (incident reporting, TLPT, third-party oversight) | DORA compliance framework |
| 13 | Passporting | Notify host state supervisors (Finansinspektionen SE, Finanstilsynet DK) | Passporting notification |
| 14 | PCI-DSS | If issuing/processing cards: PCI-DSS certification | SAQ/ROC depending on volume |

---

## Summary: Required Document Inventory

| # | Document | Regulation | Priority |
|---|----------|-----------|----------|
| 1 | License application package | Betalingstjenesteloven | CRITICAL |
| 2 | AML risk assessment | Hvitvaskingsloven SS 6 | CRITICAL |
| 3 | AML policy and procedures | Hvitvaskingsloven SS 8 | CRITICAL |
| 4 | KYC procedures | Hvitvaskingsloven SS 10-18 | CRITICAL |
| 5 | STR reporting procedures | Hvitvaskingsloven SS 26 | CRITICAL |
| 6 | Framework agreement (rammeavtale) | Betalingstjenesteloven SS 3-1 | CRITICAL |
| 7 | Fee schedule | Betalingstjenesteloven SS 3-23 | CRITICAL |
| 8 | Privacy policy | GDPR Art. 13 | CRITICAL |
| 9 | DPIA | GDPR Art. 35 | CRITICAL |
| 10 | Register of processing activities | GDPR Art. 30 | HIGH |
| 11 | Data processing agreements | GDPR Art. 28 | HIGH |
| 12 | Standard Contractual Clauses (non-EEA transfers) | GDPR Art. 46 | HIGH |
| 13 | Transfer Impact Assessments | GDPR Schrems II | HIGH |
| 14 | IT security policy | IKT-forskriften SS 3 | HIGH |
| 15 | Business continuity plan | IKT-forskriften SS 9 | HIGH |
| 16 | Incident response plan | IKT-forskriften SS 8 | HIGH |
| 17 | Internal control framework | Finansforetaksloven SS 13-2 | HIGH |
| 18 | Fit & proper documentation | Finansforetaksloven SS 3-5 | HIGH |
| 19 | Complaint handling procedure | Finansavtaleloven SS 3-53 | HIGH |
| 20 | Withdrawal form | Angrerettloven SS 11 | HIGH |
| 21 | SSB registration and reporting | Valutaregisterloven SS 3 | HIGH |
| 22 | Third-party outsourcing register | DORA Art. 28 | MEDIUM |
| 23 | Penetration test reports | IKT-forskriften SS 12 | MEDIUM |
| 24 | AML training records | Hvitvaskingsloven SS 36 | MEDIUM |
| 25 | Data retention schedule | GDPR Art. 5(1)(e) | MEDIUM |

---

*End of Drop Regulatory Map v2*

# Compliance Gap Analysis

# Drop Gap Analysis v2
## Regulatory Compliance Gap Assessment

**Date:** 2026-02-12
**Prepared for:** ALAI Holding AS / Drop Payment App
**Source code reviewed:** `/Users/makinja/ALAI/products/Drop/src/drop-app/src/`
**Security rapport:** `/Users/makinja/ALAI/products/Drop/security/drop-security-rapport.md`
**QA rapport:** `/Users/makinja/ALAI/products/Drop/project/docs/drop-qa-rapport.md`

> **NOTE (2026-03-03):** This analysis was performed on 2026-02-12. ADR-014 (2026-03-03) removed SQLite and replaced it with PostgreSQL 16 in all environments (AWS RDS, AES-256 at rest). All SQLite-specific gaps in this document (single-file DB, no HA, no backup, no retention policy tooling) are resolved by the PostgreSQL migration. Review and update this document against the current PostgreSQL 16 architecture.

---

## Executive Summary

Drop is an MVP-stage Next.js payment app (remittance + QR payments) with SQLite backend. The codebase has solid fundamentals (parameterized SQL, JWT auth, atomic transactions) but has **zero regulatory compliance infrastructure**. Every regulatory area has critical gaps. The app cannot legally process a single real transaction in its current state.

**Overall compliance readiness: 8/100**

| Area | Readiness | Critical Gaps |
|------|-----------|---------------|
| Licensing | 0% | No license applied for, no agent arrangement |
| PSD2/SCA | 10% | No BankID, no SCA, no Open Banking integration |
| AML/KYC | 5% | Mock KYC only, no real identity verification, no transaction monitoring |
| GDPR | 15% | Landing page has terms, but no DPIA, no processing register, limited privacy notice |
| ICT Security | 25% | Basic security controls exist but no formal policies, no BCP, no pen tests |
| Governance | 5% | No compliance officer, no internal control framework documented |
| Valutaregisteret | 0% | No SSB registration, no reporting capability |
| Consumer Protection | 10% | Basic terms exist but incomplete, no Finansklagenemnda membership |

---

## 1. Licensing Gap Analysis

### Current State
- No Finanstilsynet license applied for
- No agent arrangement with licensed institution
- App is running as a standalone MVP/demo

### Gap Table

| Requirement | Required State | Current State | Gap | Priority |
|------------|---------------|---------------|-----|----------|
| Payment institution license | Valid license from Finanstilsynet | None | **FULL GAP** | CRITICAL |
| Client fund safeguarding | Segregated account or insurance | Not applicable (demo mode) | **FULL GAP** | CRITICAL |
| Initial capital | 20,000-125,000 EUR depending on scope | Not secured | **FULL GAP** | CRITICAL |
| Business plan with projections | 3-year financial plan | Exists as business case (`project/docs/zica-business-case-v2.md`) | PARTIAL -- needs licensing-format update | HIGH |
| Agent arrangement (alternative) | Registered agent under licensed PSP | None | **FULL GAP** | CRITICAL |

### Recommendation
**Fastest path to market:** Establish agent arrangement with a licensed Norwegian payment institution while simultaneously preparing full license application. The agent model allows live transactions within 1-3 months; own license takes 6-12 months.

---

## 2. PSD2 / Betalingstjenesteloven Gap Analysis

### Current State (from code review)
- **Auth:** `lib/auth.ts` -- JWT with HS256, cookie-based, 24h expiry
- **SCA:** None. Login is email + password only. No second factor.
- **BankID:** Not integrated. CLAUDE.md mentions it as a requirement but it is not implemented.
- **Open Banking:** Not integrated. Architecture doc mentions pass-through model but all balance/transaction data is local SQLite.
- **Fee disclosure:** Remittance shows fee (0.5%) and QR shows fee (1%) in API responses, but no pre-contractual disclosure framework.
- **Framework agreement:** Landing page has `vilkar.html` (terms) but not compliant with betalingstjenesteloven SS 3-1 format.

### Gap Table

| Requirement | Law Reference | Current State | Gap | Priority |
|------------|--------------|---------------|-----|----------|
| Strong Customer Authentication | SS 4-28, 4-29 | Email + password only (single factor) | **FULL GAP** -- No SCA | CRITICAL |
| BankID integration | SS 4-28 (Norwegian SCA) | Not implemented; mentioned in architecture doc | **FULL GAP** | CRITICAL |
| Dynamic linking (amount+payee to auth) | Del. Reg. Art. 5 | Not implemented | **FULL GAP** | CRITICAL |
| Open Banking AISP/PISP | SS 4-40 to 4-46 | Not implemented; balance is local | **FULL GAP** | CRITICAL |
| Framework agreement | SS 3-1 to 3-8 | Basic terms page exists (`vilkar.html`) | **PARTIAL** -- needs betalingstjenesteloven format | HIGH |
| Per-transaction receipt | SS 3-22 to 3-26 | API returns transaction data; no formal receipt | **PARTIAL** -- needs formatting to comply | HIGH |
| Fee transparency pre-auth | SS 3-23 | Fee shown in API response after submission | **GAP** -- fee must be shown BEFORE authorization | HIGH |
| Exchange rate disclosure | SS 3-24 | Rate shown in API response; no reference rate markup | **PARTIAL** -- needs reference rate + markup | HIGH |
| Execution time disclosure | SS 4-15 | Remittance returns `eta: "1-2 business days"` hardcoded | **PARTIAL** -- needs accurate per-corridor times | MEDIUM |
| Unauthorized transaction refund | SS 4-19 to 4-22 | No refund mechanism exists | **FULL GAP** | HIGH |
| Session management / token revocation | Related to SCA | Sessions table exists but unused (`lib/db.ts:97-104`). Security report H1 confirms no revocation. | **FULL GAP** | HIGH |

### Technical Gaps in Code

**File: `lib/auth.ts`**
- Line 18-20: JWT_SECRET uses dev fallback in non-production. Production enforcement is correct.
- Line 48-54: Cookie settings are solid (httpOnly, secure, sameSite strict). Good foundation.
- **Missing:** No BankID callback handler, no OIDC/OAuth flow, no second factor.

**File: `app/api/auth/register/route.ts`**
- Line 20-29: Registration collects email, password, firstName, lastName, phone. No DOB field.
- Line 27: Password validation is length-only (>= 8 chars). No complexity requirements.
- **Missing:** Age verification (18+), BankID verification, Norwegian residency check.

**File: `app/api/transactions/remittance/route.ts`**
- Line 21: KYC check exists (`kyc_status !== "approved"` returns 403). Good gate, but KYC is fake.
- Line 60: Fee calculation (0.5%) is hardcoded. No disclosure step before authorization.
- **Missing:** Pre-authorization disclosure screen, SCA for transaction signing.

**File: `app/api/transactions/qr-payment/route.ts`**
- No KYC check (QA rapport H-11 confirms this). A user with pending KYC can make QR payments.
- **Missing:** KYC gate for QR payments, SCA for transaction signing.

---

## 3. AML / Hvitvaskingsloven Gap Analysis

### Current State (from code review)
- **KYC:** `users.kyc_status` field exists (pending/approved/rejected) but verification is mocked.
- **Sumsub integration:** `lib/services/mock-sumsub.ts` -- fully mocked, no real API calls.
- **Transaction monitoring:** None. No rules, no alerts, no flagging.
- **STR filing:** No mechanism.
- **PEP/Sanctions screening:** None.
- **AML officer:** Not appointed.
- **Risk assessment:** Not conducted.

### Gap Table

| Requirement | Law Reference | Current State | Gap | Priority |
|------------|--------------|---------------|-----|----------|
| AML risk assessment | SS 6, 7 | Not conducted | **FULL GAP** | CRITICAL |
| AML policy & procedures | SS 8 | Not created | **FULL GAP** | CRITICAL |
| AML compliance officer | SS 8(5) | Not appointed | **FULL GAP** | CRITICAL |
| Customer identity verification | SS 12 | Mock only (`mock-sumsub.ts`); `kyc_status` field is manually set | **FULL GAP** | CRITICAL |
| BankID as identity verification | SS 12(3) | Not integrated | **FULL GAP** | CRITICAL |
| Ongoing customer monitoring | SS 24 | None | **FULL GAP** | CRITICAL |
| Transaction monitoring system | SS 24, 25 | None -- no rules, no alerts | **FULL GAP** | CRITICAL |
| STR reporting to EFE | SS 26 | No mechanism exists | **FULL GAP** | CRITICAL |
| PEP screening | SS 18 | None | **FULL GAP** | CRITICAL |
| Sanctions screening | Sanctions regulations | None | **FULL GAP** | CRITICAL |
| Record keeping (5 years) | SS 30 | SQLite local file, no retention policy | **PARTIAL** -- data stored but no policy | HIGH |
| Customer risk categorization | SS 12(4) | No risk model | **FULL GAP** | HIGH |
| Source of funds documentation | SS 17(2) | Not collected for any transaction | **FULL GAP** | HIGH |
| AML training | SS 36 | No training program | **FULL GAP** | MEDIUM |
| Ongoing PEP/sanctions rescreening | SS 18(5), 24 | None | **FULL GAP** | HIGH |

### Technical Gaps in Code

**File: `lib/db.ts`**
- Line 29: `kyc_status` field exists with proper enum. Good schema foundation.
- **Missing:** No `risk_level` column, no `pep_status`, no `sanctions_check_date`, no `kyc_verified_at`, no `kyc_method` (BankID vs document vs simplified).

**File: `lib/services/mock-sumsub.ts`**
- Entire file is a mock. Lines 204-224 show random 90% approval logic.
- Sumsub interface has proper checks modeled (documentAuthenticity, livenessCheck, facematch, sanctionsCheck, pepCheck) but all mocked.
- **Missing:** Real Sumsub API integration, BankID integration for Norwegian residents.

**File: `app/api/transactions/remittance/route.ts`**
- Line 21: KYC gate exists. Good.
- Line 40: Amount limits (100-50,000 NOK). Good.
- **Missing:** Transaction monitoring hooks, suspicious pattern detection, cumulative daily/monthly limit checks, corridor risk assessment.

**Database schema missing tables:**
- `aml_alerts` -- transaction monitoring alerts
- `str_reports` -- suspicious transaction report records
- `pep_screening_results` -- PEP check results per user
- `sanctions_screening_results` -- sanctions check results
- `customer_risk_profile` -- risk categorization per user
- `kyc_documents` -- verified identity documents
- `audit_log` -- comprehensive audit trail (also noted in security rapport L3)

---

## 4. GDPR / Personopplysningsloven Gap Analysis

### Current State (from code review)
- Landing page has terms (`vilkar.html`) and presumably a privacy notice
- No DPIA conducted
- No Register of Processing Activities
- No data processing agreements with service providers
- No data subject rights procedures implemented
- No cookie consent mechanism
- No data retention schedule implemented

### Gap Table

| Requirement | GDPR Reference | Current State | Gap | Priority |
|------------|---------------|---------------|-----|----------|
| DPIA | Art. 35 | Not conducted | **FULL GAP** | CRITICAL |
| Privacy policy (nb) | Art. 13 | Basic terms exist; unclear if full privacy notice | **PARTIAL** | CRITICAL |
| Register of processing activities | Art. 30 | Not created | **FULL GAP** | HIGH |
| Lawful basis documentation | Art. 6 | Not documented | **FULL GAP** | HIGH |
| Data processing agreements | Art. 28 | None (no real processors yet, but mock services reference Swan, Stripe, Sumsub) | **FULL GAP** for production | HIGH |
| SCCs for non-EEA transfers | Art. 46 | Not prepared (remittance to RS, BA, TR, PK requires SCCs) | **FULL GAP** | HIGH |
| Transfer Impact Assessments | Schrems II | Not conducted | **FULL GAP** | HIGH |
| Data subject access procedure | Art. 15 | No API endpoint or process for data access requests | **FULL GAP** | HIGH |
| Right to erasure procedure | Art. 17 | No deletion capability (AML retention conflicts need mapping) | **FULL GAP** | HIGH |
| Data portability | Art. 20 | No export mechanism | **FULL GAP** | MEDIUM |
| Cookie consent | Art. 6(1)(a), ePrivacy | No consent mechanism | **FULL GAP** | MEDIUM |
| Retention schedule | Art. 5(1)(e) | No schedule; data stored indefinitely | **FULL GAP** | MEDIUM |
| Data breach response plan | Art. 33-34 | Not created | **FULL GAP** | HIGH |
| DPO appointment | Art. 37 | Not appointed (may not be required for small PSP but recommended) | **GAP** | MEDIUM |

### Technical Gaps in Code

**File: `lib/db.ts`**
- All personal data stored in plaintext SQLite: name, email, phone, bank accounts, transaction history.
- Card data stored in plaintext (security rapport C1). PCI-DSS violation AND GDPR security adequacy issue.
- No encryption at rest.
- No field-level encryption for sensitive data.
- No `deleted_at` or soft-delete mechanism for data subject erasure.
- No data export endpoint.

**File: `app/api/auth/register/route.ts`**
- Collects personal data (email, name, phone) with no consent mechanism.
- No link to privacy policy during registration.
- No purpose disclosure.

**Cross-border transfer data flow:**
- Remittance sends data to recipients in RS, BA, TR, PK (non-EEA countries).
- No SCCs or TIAs prepared for these transfers.
- Recipient data (name, bank account) is processed for non-EEA delivery.

---

## 5. IKT-forskriften / DORA Gap Analysis

### Current State (from security rapport and code review)
- JWT auth with proper cookie config (positive)
- Parameterized SQL throughout (positive)
- Security headers configured (CSP, X-Frame, X-Content-Type, Referrer-Policy, Permissions-Policy) (positive)
- Rate limiting exists but in-memory only (security rapport H2)
- No formal IT security policy document
- No BCP/DRP
- No pen test conducted
- No incident response plan
- No change management procedures
- No audit logging (security rapport L3)

### Gap Table

| Requirement | IKT-f. / DORA | Current State | Gap | Priority |
|------------|---------------|---------------|-----|----------|
| IT security policy | IKT SS 3 | Not documented | **FULL GAP** | HIGH |
| IT risk assessment | IKT SS 4 | Security rapport exists (2026-02-12) but not a formal risk assessment | **PARTIAL** | HIGH |
| Access control | IKT SS 6 | JWT-based, user-scoped queries. Good code-level controls. No admin access control. | **PARTIAL** | HIGH |
| Audit trail | IKT SS 11, DORA Art. 12 | No audit logging (security rapport L3) | **FULL GAP** | HIGH |
| Incident management | IKT SS 8, DORA Art. 17-23 | No incident response plan | **FULL GAP** | HIGH |
| Business continuity | IKT SS 9, DORA Art. 11 | No BCP/DRP. SQLite single-file DB = single point of failure. | **FULL GAP** | HIGH |
| Penetration testing | IKT SS 12, DORA Art. 24-27 | No pen test conducted. Security rapport is code review, not pen test. | **FULL GAP** | HIGH |
| Change management | IKT SS 7 | No documented procedures | **FULL GAP** | MEDIUM |
| Third-party management | IKT SS 10, DORA Art. 28-44 | Mock services only; no real third-party integrations yet. No vendor assessment framework. | **FULL GAP** for production | MEDIUM |
| ICT incident reporting | DORA Art. 19 | No reporting capability | **FULL GAP** | MEDIUM |
| Register of ICT providers | DORA Art. 28(3) | Not maintained | **FULL GAP** | MEDIUM |
| HSTS header | Best practice | Missing (security rapport M2) | **GAP** | MEDIUM |
| CSP tightening | Best practice | `unsafe-inline` and `unsafe-eval` in script-src (security rapport M1) | **GAP** | MEDIUM |
| Distributed rate limiting | IKT SS 5 | In-memory Map, resets on restart (security rapport H2) | **GAP** | HIGH |
| Session revocation | IKT SS 6 | Table exists but unused (security rapport H1) | **GAP** | HIGH |

### Security Rapport Findings Impact on Compliance

| Finding | Regulatory Impact |
|---------|------------------|
| C1: Card PAN/CVV in plaintext | PCI-DSS violation; GDPR Art. 32 security adequacy failure |
| C2/C3: Hardcoded demo credentials | IKT-forskriften SS 5 security measures failure |
| C4: SHA-256 legacy passwords | GDPR Art. 32 -- inadequate cryptographic protection |
| H1: No session revocation | PSD2 SCA non-compliance; IKT-forskriften SS 6 access control gap |
| H2: In-memory rate limiting | IKT-forskriften SS 5 -- unreliable security control |
| H5: Top-up without payment verification | Betalingstjenesteloven violation -- fictitious value creation |
| L3: No audit logging | Hvitvaskingsloven SS 30; IKT-forskriften SS 11; DORA Art. 12 |

---

## 6. Finansforetaksloven / Governance Gap Analysis

### Current State
- ALAI Holding AS is registered (org.nr 932 516 136)
- No compliance officer appointed
- No formal internal control framework
- No board-level governance documented for Drop specifically

### Gap Table

| Requirement | Law Reference | Current State | Gap | Priority |
|------------|--------------|---------------|-----|----------|
| Board competence | SS 8-4 | Alem is sole director of ALAI Holding | **GAP** -- may need additional board members with financial competence | HIGH |
| Fit & proper documentation | SS 3-5 to 3-7 | Not prepared | **FULL GAP** | HIGH |
| Compliance officer | SS 13-4 | Not appointed | **FULL GAP** | CRITICAL |
| Internal control system | SS 13-2 | Not documented | **FULL GAP** | HIGH |
| Internal audit function | SS 8-18 | Not established | **FULL GAP** | MEDIUM |
| Risk management framework | SS 13-3 | Not documented | **FULL GAP** | HIGH |
| Outsourcing policy | SS 13-7 | Not documented | **FULL GAP** | MEDIUM |
| Capital adequacy plan | SS 2-9 | Not prepared | **FULL GAP** | HIGH |
| Organizational chart for license | SS 3-3 | Exists in ALAI CLAUDE.md but needs formal version | **PARTIAL** | MEDIUM |

---

## 7. Valutaregisterloven Gap Analysis

### Current State
- Remittance to 6 currencies (RSD, BAM, PLN, PKR, TRY, EUR) is implemented
- Transaction records store: amount, currency, country (via recipient), date
- No SSB registration
- No reporting capability
- No purpose codes assigned

### Gap Table

| Requirement | Law Reference | Current State | Gap | Priority |
|------------|--------------|---------------|-----|----------|
| SSB registration | SS 3 | Not registered | **FULL GAP** | HIGH |
| Monthly reporting | SS 4, Forskrift SS 5 | No reporting extract or process | **FULL GAP** | HIGH |
| Purpose codes | Forskrift SS 4 | Not assigned to transactions | **FULL GAP** | HIGH |
| Country-level data | SS 5 | `recipients.country` captures this | **OK** | -- |
| Currency data | SS 5 | Transaction records include currency | **OK** | -- |
| 5-year retention | SS 6 | Data stored, no retention policy | **PARTIAL** | MEDIUM |

### Technical Gaps in Code

**File: `lib/db.ts`**
- `transactions` table has amount, currency, recipient_id (links to country). Good foundation.
- **Missing:** `purpose_code` column in transactions table.
- **Missing:** Reporting extract query/export function.

---

## 8. Consumer Protection Gap Analysis

### Current State
- Landing page has `vilkar.html` (terms of service)
- Remittance shows fees and exchange rate in API response
- No framework agreement in betalingstjenesteloven format
- No Finansklagenemnda membership
- No complaint handling procedure
- No withdrawal form

### Gap Table

| Requirement | Law Reference | Current State | Gap | Priority |
|------------|--------------|---------------|-----|----------|
| Framework agreement | Betalingstjenesteloven SS 3-1 | Basic terms only | **PARTIAL** -- needs full PSD2-format agreement | HIGH |
| Pre-contractual information | Finansavtaleloven SS 3-23 | Incomplete | **GAP** | HIGH |
| Fee schedule | Betalingstjenesteloven SS 3-23 | Fees hardcoded in API (0.5% remittance, 1% QR). No published schedule. | **GAP** | HIGH |
| 14-day withdrawal right | Angrerettloven SS 22 | Not implemented | **FULL GAP** | HIGH |
| Withdrawal form | Angrerettloven SS 11 | Not created | **FULL GAP** | MEDIUM |
| Complaint handling | Finansavtaleloven SS 3-53 | No procedure | **FULL GAP** | HIGH |
| Finansklagenemnda membership | Finansklagenemndloven | Not member | **FULL GAP** | HIGH |
| Unauthorized transaction refund | Finansavtaleloven SS 4-30 | No mechanism | **FULL GAP** | HIGH |
| Marketing substantiation | Markedsfoeringsloven SS 9 | "Enklere betalinger. Lavere gebyrer." -- "Lavere gebyrer" needs substantiation if compared | **RISK** | MEDIUM |

---

## 9. Document Inventory: What Exists vs. What Is Needed

### Documents That Exist

| Document | Location | Compliance Value |
|----------|----------|-----------------|
| Terms of Service (vilkar.html) | Landing page | Partial -- needs PSD2 upgrade |
| Security Audit Rapport | `security/drop-security-rapport.md` | Useful for risk assessment but not a formal pen test |
| QA Code Quality Rapport | `project/docs/drop-qa-rapport.md` | Identifies technical debt |
| Architecture Document | `project/architecture/architecture-document.md` | Foundation for IT documentation |
| Business Case | `project/docs/zica-business-case-v2.md` | Foundation for license business plan |
| Feature Flags System | `lib/feature-flags.ts` | Good for controlling feature rollout |
| Mock Service Interfaces | `lib/services/mock-*.ts` | Defines integration requirements |

### Documents That Are Completely Missing

| Document | Regulation | Priority |
|----------|-----------|----------|
| Finanstilsynet license application | Betalingstjenesteloven kap. 2 | CRITICAL |
| AML risk assessment | Hvitvaskingsloven SS 6 | CRITICAL |
| AML policy and procedures manual | Hvitvaskingsloven SS 8 | CRITICAL |
| KYC procedures document | Hvitvaskingsloven SS 10-18 | CRITICAL |
| STR reporting procedures | Hvitvaskingsloven SS 26 | CRITICAL |
| DPIA | GDPR Art. 35 | CRITICAL |
| Privacy policy (full, nb) | GDPR Art. 13 | CRITICAL |
| Register of processing activities | GDPR Art. 30 | HIGH |
| Data processing agreements | GDPR Art. 28 | HIGH |
| SCCs for non-EEA transfers | GDPR Art. 46 | HIGH |
| Transfer Impact Assessments | Schrems II | HIGH |
| IT security policy | IKT-forskriften SS 3 | HIGH |
| Business continuity plan | IKT-forskriften SS 9 | HIGH |
| Disaster recovery plan | IKT-forskriften SS 9 | HIGH |
| Incident response plan | IKT-forskriften SS 8 | HIGH |
| Framework agreement (PSD2 format) | Betalingstjenesteloven SS 3-1 | HIGH |
| Fee schedule | Betalingstjenesteloven SS 3-23 | HIGH |
| Complaint handling procedure | Finansavtaleloven SS 3-53 | HIGH |
| Internal control framework | Finansforetaksloven SS 13-2 | HIGH |
| Fit & proper documentation | Finansforetaksloven SS 3-5 | HIGH |
| Withdrawal form | Angrerettloven SS 11 | MEDIUM |
| Data breach response plan | GDPR Art. 33-34 | HIGH |
| Data retention schedule | GDPR Art. 5(1)(e) | MEDIUM |
| Change management procedures | IKT-forskriften SS 7 | MEDIUM |
| Capital adequacy plan | Betalingstjenesteloven SS 2-9 | HIGH |

---

## 10. Technical Gap Summary

### Database Schema Gaps

The current schema (`lib/db.ts`) needs these additions for compliance:

| Table/Column | Purpose | Regulation |
|-------------|---------|-----------|
| `users.dob` | Age verification (18+) | Betalingstjenesteloven (vilkar) |
| `users.national_id_hash` | Fodselsnummer hash for verification | Hvitvaskingsloven SS 12 |
| `users.risk_level` | Customer risk categorization | Hvitvaskingsloven SS 12(4) |
| `users.pep_status` | PEP flag | Hvitvaskingsloven SS 18 |
| `users.sanctions_cleared` | Sanctions clearance status | Sanctions regulations |
| `users.kyc_method` | How KYC was performed (BankID/document/etc.) | Hvitvaskingsloven SS 12 |
| `users.kyc_verified_at` | When KYC was completed | Hvitvaskingsloven SS 30 |
| `transactions.purpose_code` | Valutaregister reporting | Valutaregisterloven SS 5 |
| `audit_log` (new table) | All sensitive operations | IKT-forskriften SS 11; Hvitvaskingsloven SS 30 |
| `aml_alerts` (new table) | Transaction monitoring alerts | Hvitvaskingsloven SS 24 |
| `str_reports` (new table) | STR filings | Hvitvaskingsloven SS 26 |
| `screening_results` (new table) | PEP/sanctions screening results | Hvitvaskingsloven SS 18 |
| `consents` (new table) | GDPR consent records | GDPR Art. 7 |
| `data_access_requests` (new table) | DSAR tracking | GDPR Art. 15-22 |

### API Route Gaps

| Route | Gap | Regulation |
|-------|-----|-----------|
| `POST /api/auth/register` | No age check, no BankID, no consent | PSD2, AML, GDPR |
| `POST /api/auth/login` | No SCA (single factor only) | PSD2 SS 4-28 |
| `POST /api/transactions/remittance` | No pre-auth disclosure, no SCA signing, no TM hooks | PSD2, AML |
| `POST /api/transactions/qr-payment` | No KYC gate, no SCA signing | PSD2, AML |
| `POST /api/users/top-up` | No payment verification (infinite money) | PSD2 -- not a valid payment service |
| `POST /api/cards` | PCI-DSS violations (plaintext PAN/CVV) | PCI-DSS, GDPR Art. 32 |
| ALL routes | No audit logging | IKT-forskriften, AML |
| MISSING | `GET /api/user/data-export` (DSAR) | GDPR Art. 15, 20 |
| MISSING | `DELETE /api/user/account` (erasure) | GDPR Art. 17 |
| MISSING | `POST /api/auth/bankid/callback` | PSD2 SCA |
| MISSING | `GET /api/compliance/screening/:userId` | AML SS 18 |
| MISSING | Transaction monitoring middleware | AML SS 24 |

### Infrastructure Gaps

| Component | Current | Required | Priority |
|-----------|---------|----------|----------|
| Database | SQLite (single file) | PostgreSQL or similar (HA, encryption at rest, backup) | HIGH |
| Rate limiting | In-memory Map | Redis/Upstash distributed limiter | HIGH |
| Session management | Stateless JWT only | Session table + revocation | HIGH |
| Audit logging | None | Immutable audit log (append-only) | HIGH |
| Encryption at rest | None | AES-256 for sensitive fields or full-disk | HIGH |
| Backup | None | Automated daily backup with tested restore | HIGH |
| Monitoring | None | Application + security monitoring | HIGH |
| Card data | Plaintext in SQLite | Tokenized via PCI-compliant issuer (Stripe Issuing) | CRITICAL |
| KYC provider | Mock Sumsub | Real Sumsub/Onfido + BankID | CRITICAL |
| BaaS | Mock Swan | Real BaaS provider for IBAN accounts | CRITICAL |

---

## 11. Recommended Phasing

### Phase 0: Documentation Sprint (Weeks 1-4)
**No code changes. Produce regulatory documents.**

| # | Deliverable | Owner | Weeks |
|---|------------|-------|-------|
| 1 | AML risk assessment | Compliance advisor + Alem | 1-2 |
| 2 | AML policy and procedures | Compliance advisor | 2-3 |
| 3 | DPIA | Legal/Compliance advisor | 2-3 |
| 4 | Privacy policy (full, nb) | Legal | 1-2 |
| 5 | IT security policy | Tech Lead | 1-2 |
| 6 | Framework agreement (PSD2 format) | Legal | 2-3 |
| 7 | Internal control framework | Compliance advisor | 2-4 |
| 8 | Business plan (licensing format) | Alem + advisor | 1-3 |

**Cost estimate:** Legal/compliance advisory engagement (100-200k NOK).

### Phase 1: Critical Technical (Weeks 3-8)
**Code changes to close critical security and compliance gaps.**

| # | Task | Dependency | Weeks |
|---|------|-----------|-------|
| 1 | BankID integration (authentication + SCA) | BankID test agreement | 3-5 |
| 2 | Real KYC integration (Sumsub production) | Sumsub contract | 3-5 |
| 3 | Remove plaintext card storage (use Stripe Issuing or tokenization) | Stripe contract | 3-4 |
| 4 | Audit logging implementation | None | 3-4 |
| 5 | Session revocation (activate existing sessions table) | None | 3-4 |
| 6 | Remove top-up endpoint / integrate real payment processor | Payment partner | 4-6 |
| 7 | PEP/sanctions screening integration | Screening provider contract | 4-6 |
| 8 | Gate seed data behind NODE_ENV | None | 3 (quick fix) |

### Phase 2: Compliance Infrastructure (Weeks 6-12)
**Build compliance operational capability.**

| # | Task | Dependency | Weeks |
|---|------|-----------|-------|
| 1 | Transaction monitoring engine (rules + alerts) | Phase 1 audit logging | 6-9 |
| 2 | STR filing workflow | AML procedures doc | 7-10 |
| 3 | Valutaregister reporting (SSB monthly extract) | SSB registration | 7-10 |
| 4 | DSAR endpoint (data export + erasure) | GDPR procedures | 6-8 |
| 5 | Consent management | GDPR procedures | 6-8 |
| 6 | Distributed rate limiting (Redis) | Infrastructure upgrade | 6-7 |
| 7 | Database migration to PostgreSQL | Infrastructure plan | 8-12 |
| 8 | Complaint handling system | Consumer protection docs | 8-10 |

### Phase 3: License Application (Weeks 8-16)
**Submit license application with supporting documentation.**

| # | Task | Dependency | Weeks |
|---|------|-----------|-------|
| 1 | Compile license application package | All Phase 0 documents | 8-10 |
| 2 | Secure initial capital (if full license) | Financial planning | 8-12 |
| 3 | Submit to Finanstilsynet | Complete package | 10-12 |
| 4 | OR: Establish agent arrangement | Partner identified | 8-12 |
| 5 | Finansklagenemnda membership application | Complaint handling ready | 10-12 |
| 6 | SSB registration | Reporting capability ready | 8-10 |
| 7 | Pre-launch security pen test | Phase 1-2 complete | 12-16 |

### Alternative Fast Track: Agent Model
If speed to market is critical:
1. **Weeks 1-4:** Identify and negotiate with licensed payment institution
2. **Weeks 2-6:** Complete Phase 0 documentation (still required by principal)
3. **Weeks 4-8:** Phase 1 critical technical fixes
4. **Weeks 6-10:** Agent registration by principal
5. **Week 10-12:** Soft launch under agent model
6. **Weeks 12+:** Continue Phase 2-3 in parallel, pursue own license

---

## 12. Risk Summary

| Risk | Likelihood | Impact | Mitigation |
|------|-----------|--------|------------|
| Operating without license | CERTAIN if launched as-is | Criminal liability (betalingstjenesteloven SS 11-1), Finanstilsynet enforcement | Obtain license or agent status before first live transaction |
| AML non-compliance | CERTAIN if launched as-is | Criminal liability (hvitvaskingsloven SS 49), license revocation | Full AML program before launch |
| Data breach (plaintext card data) | HIGH given current architecture | GDPR Art. 83 fines (up to 4% of turnover or 20M EUR), reputational damage | Remove plaintext storage immediately |
| PSD2 SCA non-compliance | CERTAIN if launched as-is | Finanstilsynet enforcement, liability for unauthorized transactions | Implement BankID + SCA |
| GDPR non-compliance | HIGH if launched without DPIA | Datatilsynet fines, processing ban | Complete DPIA before any real data processing |
| Consumer complaint to Finansklagenemnda | MEDIUM after launch | Reputational damage, binding ruling | Join Finansklagenemnda, establish complaint handling |

---

*End of Drop Gap Analysis v2*

# License Application Prep

# Konsesjonssøknad — Forberedelse

**Dokument:** Forberedelse til søknad om konsesjon som betalingsforetak
**Hjemmel:** Finansforetaksloven (LOV-2015-04-10-17), betalingssystemloven (LOV-1999-12-17-95)
**Virksomhet:** ALAI Holding AS, org.nr 932 516 136
**Produkt:** Drop — betalingsformidling og pengeoverføringer
**Versjon:** 1.0
**Dato:** 2026-02-12
**Utarbeidet av:** Compliance
**Status:** Forberedende

---

## 1. Konsesjonskrav — oversikt

### 1.1 Type konsesjon
ALAI Holding AS må søke om konsesjon som **betalingsforetak** hos Finanstilsynet, jf. finansforetaksloven kapittel 2 og betalingssystemloven.

Drop tilbyr to typer betalingstjenester:
1. **Betalingsinitieringstjeneste (PISP)** — igangsetter betaling fra kundens bankkonto (PSD2), jf. finansavtaleloven §1-7 bokstav h
2. **Kontoinformasjonstjeneste (AISP)** — leser saldo og transaksjonshistorikk fra kundens bankkonto, jf. finansavtaleloven §1-7 bokstav i
3. **Pengeoverføringstjeneste** — grensekryssende overføringer (remittance), jf. finansavtaleloven §1-7 bokstav f

### 1.2 Relevante konsesjonstyper

| Type | Hjemmel | Relevant for Drop | Merknad |
|------|---------|-------------------|---------|
| Betalingsforetak (full) | Finansforetaksloven §2-10 | Ja | Dekker alle tjenester |
| Betalingsforetak (begrenset) | Finansforetaksloven §2-10c | Mulig startpunkt | Begrenset volum |
| E-pengeforetak | Finansforetaksloven §2-10a | Nei | Drop utsteder ikke e-penger |
| Registrert AISP | Finansforetaksloven §2-10d | Delvis | Kun kontoinformasjon |

### 1.3 Anbefalt strategi
**Fase 1:** Søk konsesjon som betalingsforetak (full) med PISP, AISP og pengeoverføringstjenester. Pass-through-modellen forenkler kapitalkravene, men full konsesjon gir størst fleksibilitet for fremtidig vekst.

**Alternativ:** Begrenset betalingsforetak som startpunkt dersom kapitalgrunnlaget er utilstrekkelig for full konsesjon.

---

## 2. Kapitalkrav

### 2.1 Startkapital
Jf. finansforetaksloven §3-4 og CRD-kravene:

| Konsesjonstype | Startkapital (minimum) |
|----------------|----------------------|
| Betalingsforetak — PISP/AISP | EUR 50 000 (ca. NOK 575 000) |
| Betalingsforetak — full (inkl. overføringer) | EUR 125 000 (ca. NOK 1 437 500) |
| Begrenset betalingsforetak | Ingen fast grense, men tilstrekkelig |

### 2.2 Løpende kapitalkrav
Jf. kapitalkravsforskriften for betalingsforetak:

| Metode | Beregning |
|--------|-----------|
| Metode A | 10% av faste kostnader foregående år |
| Metode B | Skala basert på betalingstransaksjonsvolum |
| Metode C | Inntektsbasert beregning |

Finanstilsynet bestemmer hvilken metode som skal benyttes. For en oppstartsbedrift vil typisk Metode A være mest relevant.

### 2.3 Sikring av kundemidler
Pass-through-modellen innebærer at Drop **aldri holder kundemidler**. Alle transaksjoner initieres direkte fra kundens bankkonto via PSD2. Dette eliminerer behovet for sikring av kundemidler etter finansforetaksloven §16-7, men må dokumenteres grundig overfor Finanstilsynet.

---

## 3. Organisatoriske krav

### 3.1 Ledelse og styre — egnethetsvurdering
Jf. finansforetaksloven §3-5 (egnethetskrav):

| Krav | Beskrivelse | Status |
|------|-------------|--------|
| Daglig leder | Egnethetsvurdert, relevant erfaring, hederlig vandel | Må oppnevnes |
| Styreleder | Egnethetsvurdert, uavhengig, relevant kompetanse | Må oppnevnes |
| Styremedlemmer | Minimum 3, egnethetsvurdert, mangfoldig kompetanse | Må oppnevnes |
| Hvitvaskingsansvarlig | Utpekt, uavhengig stilling, rapporterer til styret | Må oppnevnes |
| Compliance-funksjon | Uavhengig kontrollfunksjon | Kan kombineres med hvv.ansvarlig initialt |
| Risikostyringsfunksjon | Identifisere og håndtere operasjonell risiko | Kan kombineres initialt |

### 3.2 Egnethetskrav — «Fit & Proper»
For styremedlemmer, daglig leder og andre nøkkelpersoner, jf. finansforetaksloven §3-5:

- **Vandel:** Politiattest (intet rulleblad), ingen konkurshistorikk
- **Kompetanse:** Relevant utdanning og erfaring innen finans, teknologi, compliance
- **Kapasitet:** Tilstrekkelig tid og ressurser til å utføre vervet
- **Uavhengighet:** Ingen vesentlige interessekonflikter

Se eget dokument: `egnethetsvurdering.md`

### 3.3 Organisasjonsstruktur — minimumskrav

```
┌─────────────────────────────┐
│         STYRET               │
│  (min. 3 medlemmer)         │
│  Godkjenner strategi,       │
│  risikoappetitt, rutiner    │
└──────────┬──────────────────┘
           │
┌──────────▼──────────────────┐
│     DAGLIG LEDER             │
│  Operativ drift,            │
│  ansvarlig overfor styret   │
└──────────┬──────────────────┘
           │
     ┌─────┴──────────────┐
     │                    │
┌────▼─────┐    ┌────────▼────────┐
│  DRIFT/  │    │  COMPLIANCE/    │
│  TECH    │    │  HVITVASKING    │
│          │    │  (uavhengig)    │
└──────────┘    └─────────────────┘
```

---

## 4. Dokumentasjonskrav for søknaden

### 4.1 Sjekkliste — vedlegg til søknad

Finanstilsynet krever følgende dokumentasjon, jf. finansforetaksloven §2-11 og tilsynets veiledning:

| Nr | Dokument | Status | Referanse |
|----|----------|--------|-----------|
| 1 | Søknadsskjema (Finanstilsynets mal) | Ikke startet | Finanstilsynet.no |
| 2 | Virksomhetsplan (3 år) | Utarbeidet | `virksomhetsplan.md` |
| 3 | Organisasjonsplan med ansvarsfordeling | Utarbeidet | `internkontroll.md` |
| 4 | Egnethetsvurdering — styre og ledelse | Utarbeidet | `egnethetsvurdering.md` |
| 5 | Politiattester for nøkkelpersoner | Ikke innhentet | — |
| 6 | CV for alle nøkkelpersoner | Ikke innhentet | — |
| 7 | Hvitvaskingsrutiner | Utarbeidet | `hvitvaskingsrutiner.md` |
| 8 | Virksomhetsinnrettet risikovurdering | Utarbeidet | `risikovurdering-hvitvasking.md` |
| 9 | Internkontrollrutiner | Utarbeidet | `internkontroll.md` |
| 10 | Kapitaldokumentasjon (revisorgodkjent) | Ikke innhentet | — |
| 11 | Vedtekter | Eksisterer | Brønnøysundregistrene |
| 12 | Aksjonæroversikt med eierandeler | Eksisterer | Brønnøysundregistrene |
| 13 | Konsernstruktur | Utarbeidet | Se virksomhetsplan |
| 14 | IT-sikkerhetspolicy | Delvis | `../security/` |
| 15 | Personvernerklæring og DPIA | Ikke startet | — |
| 16 | Avtale med BaaS-partner(e) | Ikke inngått | — |
| 17 | Avtale med PEP/sanksjonsscreeningsleverandør | Ikke inngått | — |
| 18 | Beredskapsplan | Ikke startet | — |
| 19 | Revisors bekreftelse av startkapital | Ikke innhentet | — |
| 20 | Gebyrstruktur og prismodell | Utarbeidet | Se virksomhetsplan |

### 4.2 Tilleggskrav for PISP/AISP (PSD2)
- Dokumentasjon av sikkerhet for Open Banking-grensesnitt
- Strong Customer Authentication (SCA)-prosedyre
- Ansvarsfordelingsavtale med kontoførende bank (ASPSP)
- Hendelseshåndteringsprosedyre

---

## 5. Prosess og tidslinje

### 5.1 Søknadsprosess hos Finanstilsynet

| Fase | Aktivitet | Estimert varighet |
|------|-----------|-------------------|
| 1 | Forberedelse av søknad og all dokumentasjon | 2-4 måneder |
| 2 | Innlevering av søknad til Finanstilsynet | — |
| 3 | Finanstilsynets foreløpige gjennomgang | 2-4 uker |
| 4 | Eventuell tilleggsforespørsel fra tilsynet | 2-8 uker (vår respons) |
| 5 | Finanstilsynets vurdering | 3-6 måneder |
| 6 | Vedtak (innvilgelse/avslag) | — |
| **Totalt estimat** | | **6-12 måneder** |

### 5.2 Milepæler

| Milepæl | Frist | Ansvarlig |
|---------|-------|-----------|
| Egnethetsvurdering av styre og ledelse fullført | M+1 | Daglig leder |
| Politiattester innhentet | M+1 | Daglig leder |
| Kapitaldokumentasjon klar | M+2 | CFO/Revisor |
| Alle compliance-dokumenter ferdigstilt | M+2 | Compliance |
| IT-sikkerhetspolicy ferdigstilt | M+2 | Tech Lead |
| BaaS-partneravtale inngått | M+3 | Daglig leder |
| PEP/sanksjonsscreeningsavtale inngått | M+2 | Compliance |
| Intern kvalitetsgjennomgang av søknad | M+3 | Styre |
| Ekstern juridisk gjennomgang | M+3 | Advokat |
| Innlevering av søknad | M+4 | Daglig leder |

*M = måned fra prosjektstart*

### 5.3 Kostnadsoversikt

| Post | Estimert kostnad (NOK) |
|------|----------------------|
| Juridisk rådgivning (finansregulatorisk) | 100 000 - 200 000 |
| Startkapital (EUR 125 000) | ~1 437 500 |
| PEP/sanksjonsscreening (årlig) | 30 000 - 80 000 |
| Revisorhonorarer | 30 000 - 50 000 |
| Finanstilsynets gebyr | 15 000 - 25 000 |
| IT-sikkerhetsgodkjenning | 50 000 - 100 000 |
| **Totalt (ekskl. startkapital)** | **~225 000 - 455 000** |
| **Totalt (inkl. startkapital)** | **~1 662 500 - 1 892 500** |

---

## 6. Regulatorisk landskap

### 6.1 Relevant lovgivning

| Lov/forskrift | Relevans |
|---------------|----------|
| Finansforetaksloven (LOV-2015-04-10-17) | Konsesjonskrav, egnethetskrav, kapital |
| Betalingssystemloven (LOV-1999-12-17-95) | Betalingssystemer og tjenester |
| Finansavtaleloven (LOV-2020-12-18-146) | Rettigheter og plikter i kundeforhold |
| Hvitvaskingsloven (LOV-2018-06-01-23) | AML/KYC-krav |
| Personopplysningsloven (LOV-2018-06-15-38) | GDPR, personvern |
| Betalingstjenestedirektivet (PSD2) | PISP/AISP-regulering |
| EUs anti-hvitvaskingsdirektiv (AMLD6) | Harmoniserte AML-krav |

### 6.2 Tilsynsmyndigheter

| Myndighet | Rolle |
|-----------|-------|
| Finanstilsynet | Konsesjon, løpende tilsyn, egnethetsvurdering |
| Økokrim/EFE | Mottaker av mistenkelige transaksjonsrapporter |
| Datatilsynet | Personvernregelverket |
| Forbrukertilsynet | Forbrukerbeskyttelse, markedsføring |

---

## 7. Risikoer ved søknadsprosessen

| Risiko | Sannsynlighet | Konsekvens | Mitigering |
|--------|---------------|------------|------------|
| Manglende kapitalgrunnlag | Middels | Avslag | Sikre finansiering tidlig, vurdere begrenset konsesjon |
| Utilstrekkelig egnethetsvurdering | Lav | Forsinkelse | Grundig forberedelse, eventuelt rekruttere styre med regulatorisk erfaring |
| Manglende BaaS-partneravtale | Middels | Forsinkelse | Parallelle forhandlinger med flere partnere |
| Finanstilsynet krever vesentlige endringer | Middels | Forsinkelse | Tidlig dialog med tilsynet (forhåndsmøte) |
| Regulatoriske endringer underveis | Lav | Tilpasning | Løpende overvåking av regelverk |

---

## 8. Anbefalinger

### 8.1 Umiddelbare tiltak
1. **Forhåndsmøte med Finanstilsynet** — be om møte for å presentere forretningsmodellen og få uformell tilbakemelding
2. **Engasjere finansregulatorisk advokat** — spesialist på betalingsforetak og PSD2
3. **Rekruttere styre** — identifisere kandidater med relevant kompetanse og erfaring
4. **Sikre kapitalisering** — avklare finansiering av startkapital og driftskostnader

### 8.2 Parallelle løp
- Teknisk utvikling av compliance-systemer (PEP-screening, transaksjonsovervåking) bør pågå parallelt med søknadsforberedelsen
- BaaS-partnerforhandlinger bør starte umiddelbart
- Personvernkonsekvensvurdering (DPIA) bør gjennomføres

---

## 9. Endringslogg

| Versjon | Dato | Endring | Godkjent av |
|---------|------|---------|-------------|
| 1.0 | 2026-02-12 | Førstegangs utarbeidelse | Daglig leder |

---

*Dokumentet er utarbeidet som forberedelse til søknad om konsesjon hos Finanstilsynet. Søknaden skal kvalitetssikres av ekstern finansregulatorisk rådgiver før innlevering.*

# Business Plan (Regulatory)

# Virksomhetsplan — Drop (ALAI Holding AS)

**Dokument:** Virksomhetsplan for søknad om konsesjon som betalingsforetak
**Formål:** Vedlegg til konsesjonssøknad til Finanstilsynet
**Virksomhet:** ALAI Holding AS, org.nr 932 516 136
**Produkt:** Drop (getdrop.no)
**Versjon:** 1.0
**Dato:** 2026-02-12
**Utarbeidet av:** Ledelsen
**Planperiode:** 2026-2029 (3 år)

---

## 1. Selskapsinformasjon

### 1.1 Oversikt

| Felt | Verdi |
|------|-------|
| Selskapsnavn | ALAI Holding AS |
| Organisasjonsnummer | 932 516 136 |
| Selskapsform | Aksjeselskap (AS) |
| Stiftelsesdato | Se Brønnøysundregistrene |
| Forretningsadresse | Oslo, Norge |
| Daglig leder | Alem Cerimagic (CEO/Founder) |
| Produktnavn | Drop |
| Domene | getdrop.no |
| Bransje | Betalingsformidling og pengeoverføringer |

### 1.2 Eierstruktur

| Eier | Eierandel | Type |
|------|-----------|------|
| Alem Cerimagic | 100% | Privatperson |

### 1.3 Konsernstruktur

```
ALAI Holding AS (932 516 136)
├── Drop (produkt — betalingsformidling)
└── Basic Consulting (datterselskap — konsulentvirksomhet)
```

---

## 2. Virksomhetsbeskrivelse

### 2.1 Forretningside
Drop er en betalingsapp for alle innbyggere i Norge og Skandinavia som tilbyr to kjernetjenester:
1. **Pengeoverføringer til utlandet (remittance)** — rimeligere grensekryssende overføringer til 30+ land
2. **QR-betalinger i butikk** — betalinger via QR-kode med lavere gebyrer enn eksisterende løsninger

### 2.2 Visjon
Gjøre internasjonale pengeoverføringer og daglige betalinger enklere og rimeligere for alle i Skandinavia.

### 2.3 Misjon
Levere en brukervennlig, sikker og rimelig betalingsplattform som kombinerer grensekryssende overføringer og butikkbetalinger i en app.

### 2.4 Verdier
- **Tilgjengelig** — for alle, uansett bakgrunn
- **Transparent** — klare gebyrer, ingen skjulte kostnader
- **Sikker** — BankID-verifisering, robust AML-program, datakryptering
- **Rimelig** — lavere gebyrer enn etablerte aktører

---

## 3. Forretningsmodell

### 3.1 Pass-through-modell (PSD2)
Drop opererer en **pass-through-modell**. Selskapet holder aldri kundemidler:

```
┌──────────┐   PSD2 PISP    ┌──────────┐   BaaS-partner   ┌──────────┐
│ Kundens  │───────────────▶│   DROP    │─────────────────▶│ Mottaker │
│ Bank     │  (initiering)  │  (PISP)  │  (gjennomføring) │ (utland) │
└──────────┘                └──────────┘                   └──────────┘
```

- **PISP (Payment Initiation Service Provider):** Drop initierer betaling fra kundens norske bankkonto via PSD2-grensesnitt
- **AISP (Account Information Service Provider):** Drop leser saldo/transaksjonshistorikk (med kundens samtykke)
- **BaaS-partner:** Utfører den faktiske grensekryssende overføringen via sine lisenser og korrespondentbanknettverk

### 3.2 Tjenester

#### 3.2.1 Pengeoverføringer (Remittance)
| Aspekt | Beskrivelse |
|--------|-------------|
| Hva | Grensekryssende overføring fra Norge til mottaker i utlandet |
| Korridorer | 30+ land (oppstart med EUR, PLN, RSD, BAM, TRY, PKR) |
| Mottaker | Trenger **ikke** Drop-appen — mottar på bankkonto eller cash pickup |
| Gebyr | 0,5% av beløpet (vs. 0,7-1,5% hos Wise, 5-10% hos Western Union) |
| Leveringstid | 1-2 virkedager (avhengig av korridor) |
| Beløpsgrenser | Inntil NOK 50 000 per transaksjon (standard), høyere etter EDD |

#### 3.2.2 QR-betalinger
| Aspekt | Beskrivelse |
|--------|-------------|
| Hva | Betaling i butikk via QR-kode |
| Merchant-gebyr | 1% (vs. 1,75-2,75% hos Vipps) |
| Settlement | Daglig batch-utbetaling til merchants bankkonto |
| Onboarding | Merchant registrerer seg i appen, mottar QR-kode |
| Teknologi | Statisk QR per merchant, skannes av kundens app |

### 3.3 Autentisering og sikkerhet
- **BankID:** Obligatorisk ved registrering — sikrer identitet og alder (18+)
- **PIN/biometri:** For daglig bruk i appen
- **SCA (Strong Customer Authentication):** For transaksjoner over terskelverdi, jf. PSD2

---

## 4. Målgruppe og marked

### 4.1 Målgruppe
Drop retter seg mot **alle innbyggere i Norge og Skandinavia** som ønsker:
1. Rimeligere måter å sende penger til utlandet
2. Billigere betalingsløsninger i butikk
3. En moderne betalingsapp med gode brukeropplevelser

### 4.2 Kundesegmenter

| Segment | Beskrivelse | Estimert størrelse | Behov |
|---------|-------------|-------------------|-------|
| **1. Regelmessige avsendere** | Personer som jevnlig sender penger til utlandet | ~200 000 (Norge) | Lave gebyrer, rask overføring, enkel app |
| **2. Prisbevisste forbrukere** | Alle som ønsker lavere betalingsgebyrer i butikk | ~2 000 000 (Norge) | Lavere priser, enkel betaling |
| **3. Merchanter** | Butikker og tjenesteytere som ønsker lavere gebyrer | ~195 000 SMB (Norge) | Lavere merchant-gebyrer, rask settlement |
| **4. Teknologiinteresserte** | Brukere som ønsker en moderne betalingsapp | ~500 000 (Norge) | God UX, innovative funksjoner |

### 4.3 Markedsstørrelse

| Metrikk | Verdi | Kilde |
|---------|-------|-------|
| Remittance fra Norge (årlig) | NOK 5,7 mrd | World Bank |
| Antall SMB i Norge | ~195 000 | SSB |
| Betalingstransaksjoner i Norge (årlig) | ~3,5 mrd | Norges Bank |
| Korttransaksjoner i butikk (årlig volum) | ~NOK 800 mrd | Norges Bank |

### 4.4 Konkurransesituasjon

| Aktør | Remittance | QR/butikkbetaling | Gebyr (remittance) | Gebyr (merchant) |
|-------|-----------|-------------------|-------------------|-----------------|
| Vipps | Nei (kun innenlands) | Ja | N/A | 1,75-2,75% |
| Wise | Ja | Nei | 0,7-1,5% | N/A |
| Revolut | Ja (generisk) | Begrenset | 0,5-1,5% | N/A |
| Western Union | Ja | Nei | 5-10% | N/A |
| **Drop** | **Ja** | **Ja** | **0,5%** | **1%** |

**Differensiering:** Ingen eksisterende aktør kombinerer grensekryssende overføringer og QR-butikkbetalinger i en plattform.

---

## 5. Organisasjonsplan

### 5.1 Organisasjonsstruktur (ved konsesjonssøknad)

```
┌───────────────────────────────┐
│           STYRET              │
│   Minimum 3 medlemmer         │
│   Strategisk styring          │
└──────────────┬────────────────┘
               │
┌──────────────▼────────────────┐
│       DAGLIG LEDER            │
│   Alem Cerimagic              │
│   Operativt ansvar            │
└──────────────┬────────────────┘
               │
    ┌──────────┼──────────┐
    │          │          │
┌───▼───┐ ┌───▼────┐ ┌───▼────────┐
│ TECH  │ │COMPLNC │ │ BUSINESS   │
│       │ │  / AML │ │ DEVELOPMENT│
│CTO/TL │ │  CCO   │ │            │
└───────┘ └────────┘ └────────────┘
```

### 5.2 Bemanning — planlagt utvikling

| Rolle | Ved søknad | År 1 | År 2 | År 3 |
|-------|-----------|------|------|------|
| Daglig leder / CEO | 1 | 1 | 1 | 1 |
| CTO / Tech Lead | 1 | 1 | 1 | 1 |
| Compliance / AML | 0,5 (ekstern) | 1 | 1 | 2 |
| Utviklere | 1 | 2 | 3 | 5 |
| Kundeservice | 0 | 1 | 2 | 3 |
| Business Development | 0 | 1 | 1 | 2 |
| **Totalt** | **3,5** | **7** | **9** | **14** |

### 5.3 Outsourcing

| Funksjon | Partner | Begrunnelse |
|----------|---------|-------------|
| Grensekryssende overføringer | BaaS-partner (Wise API/Thunes) | Lisensiert partner med korrespondentbanknettverk |
| PEP/sanksjonsscreening | Refinitiv / Dow Jones | Spesialisert dataleverandør |
| Revisjon | Ekstern revisor | Lovkrav |
| Juridisk rådgivning | Finansregulatorisk advokatfirma | Spesialisert kompetanse |

---

## 6. Teknisk plattform

### 6.1 Arkitektur

| Komponent | Teknologi |
|-----------|-----------|
| Frontend | React Native (mobil), Next.js (web) |
| Backend | Node.js / Next.js API Routes |
| Database | PostgreSQL (produksjon) |
| Autentisering | BankID + JWT (httpOnly cookies) |
| Hosting | Norsk skytjeneste (GDPR-compliant) |
| PSD2-integrasjon | Open Banking API (PISP/AISP) |
| BaaS-integrasjon | Wise API / Thunes API |

### 6.2 Sikkerhet
- Kryptering i transit (TLS 1.3) og ved lagring (AES-256)
- BankID for sterk kundeautentisering (SCA)
- Automatisert transaksjonsovervåking
- Penetrasjonstesting (årlig)
- Hendelseshåndtering og beredskapsplan
- OWASP Top 10 som utviklingsstandard

---

## 7. Inntektsmodell

### 7.1 Inntektsstrømmer

| Inntektsstrøm | Gebyr | Beregningsgrunnlag |
|----------------|-------|-------------------|
| Remittance-gebyr | 0,5% | Av overført beløp |
| Merchant QR-gebyr | 1,0% | Av transaksjonsbeløp |
| FX-spread (vekslingspåslag) | 0,2-0,4% | På valutaveksling |

### 7.2 Prissammenligning

| Tjeneste | Drop | Wise | Vipps | Western Union |
|----------|------|------|-------|---------------|
| Overføring NOK 5 000 til Serbia | 25 NOK | 50-75 NOK | N/A | 250-500 NOK |
| Merchant-gebyr (kjøp NOK 200) | 2 NOK | N/A | 3,50-5,50 NOK | N/A |

---

## 8. Finansielle prognoser (3 år)

### 8.1 Forutsetninger

| Parameter | År 1 | År 2 | År 3 |
|-----------|------|------|------|
| Remittance-brukere (kumulativt) | 3 000 | 8 000 | 15 000 |
| Aktive merchanter | 200 | 500 | 1 000 |
| Snitt remittance per bruker/mnd | 2 000 NOK | 2 500 NOK | 3 000 NOK |
| Snitt omsetning per merchant/mnd | 50 000 NOK | 75 000 NOK | 100 000 NOK |
| Gjennomsnittlig remittance-gebyr | 0,5% | 0,5% | 0,5% |
| Merchant-gebyr | 1,0% | 1,0% | 1,0% |

### 8.2 Resultatprognose

| Post | År 1 (NOK) | År 2 (NOK) | År 3 (NOK) |
|------|-----------|-----------|-----------|
| **Inntekter** | | | |
| Remittance-gebyr | 360 000 | 1 200 000 | 2 700 000 |
| Merchant QR-gebyr | 1 200 000 | 4 500 000 | 12 000 000 |
| FX-spread | 144 000 | 480 000 | 1 080 000 |
| **Sum inntekter** | **1 704 000** | **6 180 000** | **15 780 000** |
| | | | |
| **Kostnader** | | | |
| Personalkostnader | 4 200 000 | 5 850 000 | 9 100 000 |
| BaaS/partnergebyrer | 240 000 | 600 000 | 1 200 000 |
| IT-infrastruktur og drift | 180 000 | 300 000 | 500 000 |
| Compliance (screening, revisjon) | 200 000 | 300 000 | 400 000 |
| Markedsføring | 600 000 | 1 200 000 | 2 000 000 |
| Kontor og administrasjon | 120 000 | 200 000 | 300 000 |
| **Sum kostnader** | **5 540 000** | **8 450 000** | **13 500 000** |
| | | | |
| **Resultat før skatt** | **-3 836 000** | **-2 270 000** | **2 280 000** |

### 8.3 Likviditetsprognose

| Post | År 1 (NOK) | År 2 (NOK) | År 3 (NOK) |
|------|-----------|-----------|-----------|
| Likviditet ved periodens start | 2 000 000 | -1 836 000 | -4 106 000 |
| Netto kontantstrøm fra drift | -3 836 000 | -2 270 000 | 2 280 000 |
| Kapitaltilskudd / finansiering | 0 | 0 | 0 |
| **Likviditet ved periodens slutt** | **-1 836 000** | **-4 106 000** | **-1 826 000** |

**Merknad:** Selskapet vil trenge ekstern finansiering (investorkapital, lån, tilskudd) for å dekke negativt resultat i år 1-2. Innovasjon Norge-tilskudd (NOK 150 000) er ikke medtatt i prognosen.

### 8.4 Kapitalbehov

| Post | Beløp (NOK) |
|------|-------------|
| Startkapital (lovkrav EUR 125 000) | 1 437 500 |
| Driftsfinansiering år 1-2 | 6 106 000 |
| Buffer | 500 000 |
| **Totalt kapitalbehov** | **~8 044 000** |

---

## 9. Risikoer

### 9.1 Strategiske risikoer

| Risiko | Sannsynlighet | Konsekvens | Mitigering |
|--------|---------------|------------|------------|
| Konsesjon avslås | Lav | Kritisk | Grundig forberedelse, juridisk rådgiver, forhåndsmøte med tilsynet |
| Vipps lanserer remittance | Middels | Høy | Fokus på pris og brukeropplevelse, etablere markedsandel tidlig |
| BaaS-partner avslutter samarbeid | Lav | Høy | Multi-partner-strategi (Wise + Thunes) |
| Tregere vekst enn forventet | Middels | Middels | Justere kostnader, fokusere på best-performing segmenter |
| Regulatoriske endringer (strengere krav) | Middels | Middels | Løpende regelverksovervåking, fleksibel arkitektur |

### 9.2 Operasjonelle risikoer

| Risiko | Sannsynlighet | Konsekvens | Mitigering |
|--------|---------------|------------|------------|
| Sikkerhetsbrudd / datalekkasje | Lav | Kritisk | Robust IT-sikkerhet, penetrasjonstesting, beredskapsplan |
| Systemnedetid | Lav | Høy | Redundans, overvåking, failover-prosedyrer |
| Svindel / misbruk | Middels | Høy | AML-program, transaksjonsovervåking, beløpsgrenser |
| Nøkkelpersonrisiko | Middels | Høy | Dokumentasjon, kunnskapsdeling, gradvis teamutvidelse |

---

## 10. Lanseringsstrategi

### 10.1 Faser

| Fase | Tidsrom | Aktivitet | Mål |
|------|---------|-----------|-----|
| **Pre-lansering** | M1-M4 | Konsesjonssøknad, partneravtaler, tech-utvikling | Konsesjon innlevert |
| **Soft launch** | M5-M6 | Begrenset brukerbase, testing av systemer | 200 brukere, 20 merchanter |
| **Full lansering** | M7-M12 | Markedsføring, onboarding i Oslo-området | 3 000 brukere, 200 merchanter |
| **Vekst** | År 2 | Utvide til Bergen, Stavanger, Trondheim | 8 000 brukere, 500 merchanter |
| **Skalering** | År 3 | Hele Norge, vurdere Sverige/Danmark | 15 000 brukere, 1 000 merchanter |

### 10.2 Go-to-market

| Kanal | Tiltak | Målgruppe |
|-------|--------|-----------|
| Digitalt | Google Ads, Meta Ads, influencer-samarbeid | Alle segmenter |
| Merchant-onboarding | Direkte oppsøkende salg i bydeler med mange SMB | Merchanter |
| Partnerskap | Samarbeid med BaaS-partnere, banker, organisasjoner | Alle segmenter |
| Referralprogram | Eksisterende brukere inviterer venner (belønning) | Eksisterende brukere |
| PR/media | Pressedekning, bransjearrangementer | Alle segmenter |

---

## 11. Compliance-rammeverk

### 11.1 Oversikt
Selskapet har utarbeidet følgende compliance-dokumentasjon:

| Dokument | Referanse | Status |
|----------|-----------|--------|
| Hvitvaskingsrutiner (AML/KYC) | `hvitvaskingsrutiner.md` | Utarbeidet |
| Virksomhetsinnrettet risikovurdering | `risikovurdering-hvitvasking.md` | Utarbeidet |
| Internkontrollrutiner | `internkontroll.md` | Utarbeidet |
| Egnethetsvurdering | `egnethetsvurdering.md` | Utarbeidet |
| Personvernpolicy / DPIA | Planlagt | Påkrevet |
| Beredskapsplan | Planlagt | Påkrevet |

### 11.2 Tilsynsrapportering
Selskapet vil rapportere til følgende myndigheter:

| Myndighet | Rapporteringstype | Frekvens |
|-----------|------------------|----------|
| Finanstilsynet | Konsesjonskrav, COREP, årsrapport | Årlig + ad hoc |
| Økokrim/EFE | Mistenkelige transaksjoner (MT) | Ved forekomst |
| Datatilsynet | Personvernbrudd (72t) | Ved hendelse |
| Skatteetaten | MVA-melding | Terminvis |
| Brønnøysundregistrene | Årsregnskap | Årlig |

---

## 12. Milepælsplan

| Nr | Milepæl | Frist | Avhengigheter |
|----|---------|-------|---------------|
| 1 | Styre oppnevnt og egnethetsvurdert | M+1 | — |
| 2 | Startkapital sikret | M+2 | Finansiering |
| 3 | BaaS-partneravtale signert | M+3 | Partner-dialog |
| 4 | Compliance-dokumentasjon ferdig | M+2 | — |
| 5 | Konsesjonssøknad innlevert | M+4 | 1-4 |
| 6 | Tech-plattform MVP ferdig | M+5 | — |
| 7 | PEP/sanksjonsscreening implementert | M+5 | 3 |
| 8 | Transaksjonsovervåking operativ | M+5 | 6 |
| 9 | Konsesjon innvilget (estimat) | M+10 | 5 |
| 10 | Soft launch | M+11 | 9 |
| 11 | Full lansering | M+13 | 10 |

---

## 13. Endringslogg

| Versjon | Dato | Endring | Godkjent av |
|---------|------|---------|-------------|
| 1.0 | 2026-02-12 | Førstegangs utarbeidelse | Daglig leder |

---

*Denne virksomhetsplanen er utarbeidet som vedlegg til søknad om konsesjon som betalingsforetak hos Finanstilsynet. Planen oppdateres årlig og ved vesentlige endringer i virksomheten.*

# Compliance Gap (Feb 2026)

# Drop Compliance Gap Analysis — Overnight Sprint
## 2026-02-16

---

## TL;DR

**Readiness: 8/100** (per gap-analysis-v2.md, 2026-02-12)

We have more than we think:
- 14 substantive legal draft documents (6,238 lines total)
- 36 API endpoints, security hardened (0 CRITICAL, 0 HIGH)
- Session management, rate limiting, CSRF, security headers all done
- CI/CD pipeline, test suite (40 tests), deployed on Vercel + Fly.io

The gap is NOT documentation — it's **code infrastructure for compliance**. The legal docs exist but the app has zero compliance plumbing.

---

## GAP MATRIX: IMAMO vs TREBA

### BACKEND

| # | Component | IMAMO | TREBA | Gap | AI Tonight? |
|---|-----------|-------|-------|-----|-------------|
| B1 | Audit logging | Nothing | Immutable audit_log table + middleware on all sensitive ops | FULL | YES |
| B2 | DB schema: compliance columns | users.kyc_status only | users.dob, national_id_hash, risk_level, pep_status, sanctions_cleared, kyc_method, kyc_verified_at | FULL | YES |
| B3 | DB schema: compliance tables | None | audit_log, aml_alerts, str_reports, screening_results, consents, data_access_requests | FULL | YES |
| B4 | Transaction monitoring | Nothing | Rule engine: structuring, velocity, corridor risk, volume spike, PEP | FULL | YES |
| B5 | GDPR: Data export (DSAR) | Nothing | GET /api/user/data-export — full user data JSON | FULL | YES |
| B6 | GDPR: Account deletion | Nothing | DELETE /api/user/account — soft-delete with AML retention | FULL | YES |
| B7 | Consent management API | Nothing | POST /api/consents, GET /api/consents — track GDPR consents | FULL | YES |
| B8 | Pre-auth disclosure | Fee shown AFTER submission | GET /api/transactions/disclosure — fees, rate, ETA BEFORE auth | FULL | YES |
| B9 | Transaction receipt | API returns tx data | GET /api/transactions/[id]/receipt — PSD2 formatted receipt | FULL | YES |
| B10 | Purpose codes | No field | transactions.purpose_code column + API support | FULL | YES |
| B11 | QR KYC gate | Missing (QA H-11) | KYC check in QR payment route | FULL | YES |
| B12 | Password complexity | Length-only (>=8) | Uppercase + lowercase + digit + min 8 | PARTIAL | YES |
| B13 | Cookie consent API | Nothing | POST /api/consents/cookies — track cookie preferences | FULL | YES |
| B14 | Complaint handling API | Nothing | POST /api/complaints, GET /api/complaints — track complaints | FULL | YES |

### FRONTEND

| # | Component | IMAMO | TREBA | Gap | AI Tonight? |
|---|-----------|-------|-------|-----|-------------|
| F1 | Cookie consent banner | Nothing | GDPR cookie consent with preferences (necessary/analytics/marketing) | FULL | YES |
| F2 | Pre-payment disclosure | Goes straight to submit | Screen showing: amount, fees, exchange rate, ETA, total BEFORE confirm | FULL | YES |
| F3 | Transaction receipt view | Basic tx detail | PSD2-compliant receipt: amount, fees, rate, ref, date, payee | FULL | YES |
| F4 | Data export request | Nothing | Settings → "Download my data" button → triggers DSAR | FULL | YES |
| F5 | Account deletion | Nothing | Settings → "Delete account" with confirmation, AML warning | FULL | YES |
| F6 | Complaint form | Nothing | Help → "File complaint" form (Finansavtaleloven §3-53) | FULL | YES |
| F7 | Fee schedule page | Nothing | Public page: all fees, rates, corridors (Betalingstjenesteloven §3-23) | FULL | YES |
| F8 | Consent in registration | No consent checkbox | Checkbox: "I accept terms" + "I accept privacy policy" with links | FULL | YES |
| F9 | Privacy policy page | Only landing vilkar.html | In-app /privacy page with full personvernerklaering content | FULL | YES |
| F10 | Terms page | Only landing vilkar.html | In-app /terms page with full brukervilkar content | FULL | YES |
| F11 | Withdrawal form | Nothing | In-app /withdrawal page (Angrerettloven §11) | FULL | YES |

### MOBILE / PWA

Same as frontend — Drop is a PWA, no native app yet.

### CANNOT DO TONIGHT (Requires External)

| # | Component | Why Not |
|---|-----------|---------|
| X1 | BankID integration | Needs test agreement + banking partner |
| X2 | Real KYC (Sumsub) | Needs Sumsub production contract |
| X3 | Open Banking AISP/PISP | Needs banking partner (SpareBank1/Swan) |
| X4 | PostgreSQL migration | Infrastructure decision needed |
| X5 | Penetration test | External firm required |
| X6 | Finansklagenemnda membership | Registration process |
| X7 | SSB/Valutaregister registration | Government registration |
| X8 | License application | Needs legal advisor + Alem |
| X9 | Compliance officer appointment | Human decision |
| X10 | PEP/Sanctions screening | Needs provider (ComplyAdvantage/Refinitiv) |

---

## OVERNIGHT SPRINT PLAN

### Phase A — Database Schema (foundation, do first)
**Files:** `src/lib/db.ts`
**Tasks:** B2, B3, B10

Add to users table:
- `risk_level TEXT DEFAULT 'low'` (low/medium/high)
- `pep_status TEXT DEFAULT 'not_checked'`
- `sanctions_cleared INTEGER DEFAULT 0`
- `kyc_method TEXT` (bankid/document/simplified)
- `kyc_verified_at TEXT`
- `national_id_hash TEXT`
- `deleted_at TEXT` (soft delete for GDPR)

Add to transactions table:
- `purpose_code TEXT` (ISO 20022 purpose codes)

New tables:
- `audit_log` (id, timestamp, user_id, action, resource_type, resource_id, details, ip_address, user_agent)
- `aml_alerts` (id, user_id, alert_type, severity, transaction_id, details, status, reviewed_by, reviewed_at, created_at)
- `str_reports` (id, user_id, alert_id, report_type, status, filed_at, reference_number, details)
- `screening_results` (id, user_id, screening_type, provider, result, match_details, screened_at)
- `consents` (id, user_id, consent_type, granted, granted_at, withdrawn_at, ip_address)
- `data_access_requests` (id, user_id, request_type, status, requested_at, completed_at, download_url)

### Phase B — Backend APIs (compliance endpoints)
**Tasks:** B1, B4, B5, B6, B7, B8, B9, B11, B12, B13, B14

1. **Audit logging middleware** — wraps all API routes, logs to audit_log table
2. **Transaction monitoring** — post-transaction hook: checks rules, creates aml_alerts
3. **GDPR endpoints** — /api/user/data-export, /api/user/account (DELETE)
4. **Consent API** — /api/consents (GET, POST)
5. **Pre-auth disclosure** — /api/transactions/disclosure (GET)
6. **Receipt endpoint** — /api/transactions/[id]/receipt (GET)
7. **Complaint API** — /api/complaints (GET, POST)
8. **QR KYC gate** — add kyc_status check to qr-payment route
9. **Password complexity** — upgrade validation in register route

### Phase C — Frontend UI (compliance screens)
**Tasks:** F1-F11

1. **Cookie consent component** — banner + preferences modal
2. **Pre-payment disclosure** — step before payment confirm in send-money flow
3. **Receipt view** — enhanced transaction detail with PSD2 fields
4. **Settings compliance** — data export, account deletion buttons
5. **Legal pages** — /privacy, /terms, /fees, /withdrawal, /complaints
6. **Registration consent** — checkboxes in register flow

---

## TASK SPLIT FOR AGENTS

| Task | Scope | Agent Type | Est. Files |
|------|-------|------------|-----------|
| T1: Schema upgrade | Phase A (all DB changes) | Builder | 1 (db.ts) |
| T2: Audit logging | B1 (middleware + table) | Builder | 2-3 |
| T3: Transaction monitoring | B4 (rule engine) | Builder | 2-3 |
| T4: GDPR endpoints | B5, B6, B7, B13 | Builder | 4-5 |
| T5: Payment compliance APIs | B8, B9, B11, B14 | Builder | 4-5 |
| T6: Auth hardening | B12 (password rules) | Builder | 1-2 |
| T7: Frontend legal pages | F7, F9, F10, F11 | Builder | 4-5 |
| T8: Frontend compliance UI | F1, F2, F3, F4, F5, F6, F8 | Builder | 6-8 |

**Dependency:** T1 must complete first (schema), then T2-T8 can run in parallel.

---

## AFTER TONIGHT

With these tasks done, compliance readiness jumps from **8/100 to ~35-40/100**.

Remaining blockers (external):
- BankID + SCA (CRITICAL — needs banking partner)
- Real KYC (CRITICAL — needs Sumsub)
- Open Banking (CRITICAL — needs partner)
- License application (CRITICAL — needs legal advisor)

But we'll have the **infrastructure ready** — when the partner comes, we plug in real providers and the compliance plumbing is already there.