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
  2. Betalingstjenesteloven / PSD2
  3. Hvitvaskingsloven / AML
  4. Personopplysningsloven / GDPR
  5. IKT-forskriften / DORA
  6. Finansforetaksloven
  7. Valutaregisterloven
  8. Consumer Protection
  9. DORA Timeline for Norway
  10. Regulatory Priority Matrix

1. Finanstilsynet Licensing

Applicable Law

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:

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

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

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

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

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

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

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 (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)

Practical Implication for Drop

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

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)

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

File: app/api/auth/register/route.ts

File: app/api/transactions/remittance/route.ts

File: app/api/transactions/qr-payment/route.ts

3. AML / Hvitvaskingsloven Gap Analysis

Current State (from code review)

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

File: lib/services/mock-sumsub.ts

File: app/api/transactions/remittance/route.ts

Database schema missing tables:

4. GDPR / Personopplysningsloven Gap Analysis

Current State (from code review)

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

File: app/api/auth/register/route.ts

Cross-border transfer data flow:

5. IKT-forskriften / DORA Gap Analysis

Current State (from security rapport and code review)

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

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

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

8. Consumer Protection Gap Analysis

Current State

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

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

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:

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)

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

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

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) │
└──────────┘                └──────────┘                   └──────────┘

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

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

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:

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:

Add to transactions table:

New tables:

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

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):

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