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 Finanstilsynet Licensing Betalingstjenesteloven / PSD2 Hvitvaskingsloven / AML Personopplysningsloven / GDPR IKT-forskriften / DORA Finansforetaksloven Valutaregisterloven Consumer Protection DORA Timeline for Norway 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 Business plan with 3-year financial projections Description of payment services to be offered (SS 2-4) Organizational chart with fit & proper documentation for all key persons AML/CFT policy and procedures (full program) Operational procedures and internal control description IT security policy and business continuity plan Client fund safeguarding arrangements Capital adequacy calculations and evidence of initial capital Outsourcing policy (if using third-party services) 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: BankID integration for initial authentication (covers possession + knowledge) Transaction signing with BankID or app-based second factor for payments Dynamic linking: display amount + payee in BankID signing dialog 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: Framework agreement / user terms (rammeavtale) Fee schedule (gebyroppstilling) Transaction receipts (per transaction) 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: BankID integration for Norwegian residents (covers identity verification) ID document verification for non-BankID eligible (passport/national ID via Sumsub/Onfido) Address verification (e.g., Folkeregisteret lookup or utility bill) Source of funds declaration for transfers above thresholds 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: Structuring detection (multiple transactions just below reporting thresholds) Rapid movement (funds in/out within short timeframe) Unusual corridors (sudden changes in destination countries) Volume spikes (significantly above normal pattern) High-risk country flags (FATF grey/black list countries) 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: PEP database (ComplyAdvantage, Refinitiv World-Check, or similar) Sanctions list screening (EU consolidated list, UN Security Council list, Norwegian MFA list) 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: Enterprise-wide AML risk assessment (virksomhetsrettet risikovurdering) AML policy and procedures manual (AML-handbok) STR reporting procedures Customer risk categorization model Training plan and records 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: Processing of financial data at scale Systematic monitoring of individuals (transaction monitoring) Cross-border data transfers (remittance to 30+ countries) Vulnerable groups potential (newly arrived residents, etc.) 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 Privacy policy (personvernerklaering) -- Norwegian language DPIA (vurdering av personvernkonsekvenser) Register of processing activities (behandlingsprotokoll) Data processing agreements (databehandleravtale) with all processors Standard Contractual Clauses for non-EEA transfers Transfer Impact Assessments per destination country Cookie/consent management policy Data breach response plan (bruddhandteringsplan) Data subject rights procedures (innsynsprosedyre) 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 IT security policy (IKT-sikkerhetspolicy) IT risk assessment (IKT-risikovurdering) Business continuity plan (beredskapsplan) Disaster recovery plan (katastrofegjenopprettingsplan) Incident response plan (hendelseshandteringsplan) Change management procedures Access control policy Third-party/outsourcing assessment register Penetration test reports (annual minimum) 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 Articles of association (vedtekter) Board member CVs and fit & proper declarations Police certificates for board/management Organizational chart with reporting lines Internal control framework description Compliance function description Risk management policy 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: Assign purpose codes (SWIFT MT103 / ISO 20022 purpose codes) to all remittances Collect destination country per transaction (already in DB schema: recipients.country ) Build monthly reporting extract for SSB Register with SSB as reporting entity Required Documents SSB registration as valutaregisterpliktig Monthly reporting procedures Purpose code mapping for transaction types 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 Framework agreement (rammeavtale) with all financial terms Fee schedule (gebyrliste) in standardized format Withdrawal form (angrerettskjema) Internal complaint handling procedure (klageprosedyre) Finansklagenemnda membership registration 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: Weeks 1-4: Identify and negotiate with licensed payment institution Weeks 2-6: Complete Phase 0 documentation (still required by principal) Weeks 4-8: Phase 1 critical technical fixes Weeks 6-10: Agent registration by principal Week 10-12: Soft launch under agent model 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: Betalingsinitieringstjeneste (PISP) — igangsetter betaling fra kundens bankkonto (PSD2), jf. finansavtaleloven §1-7 bokstav h Kontoinformasjonstjeneste (AISP) — leser saldo og transaksjonshistorikk fra kundens bankkonto, jf. finansavtaleloven §1-7 bokstav i 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 Forhåndsmøte med Finanstilsynet — be om møte for å presentere forretningsmodellen og få uformell tilbakemelding Engasjere finansregulatorisk advokat — spesialist på betalingsforetak og PSD2 Rekruttere styre — identifisere kandidater med relevant kompetanse og erfaring 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: Pengeoverføringer til utlandet (remittance) — rimeligere grensekryssende overføringer til 30+ land 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: Rimeligere måter å sende penger til utlandet Billigere betalingsløsninger i butikk 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 Audit logging middleware — wraps all API routes, logs to audit_log table Transaction monitoring — post-transaction hook: checks rules, creates aml_alerts GDPR endpoints — /api/user/data-export, /api/user/account (DELETE) Consent API — /api/consents (GET, POST) Pre-auth disclosure — /api/transactions/disclosure (GET) Receipt endpoint — /api/transactions/[id]/receipt (GET) Complaint API — /api/complaints (GET, POST) QR KYC gate — add kyc_status check to qr-payment route Password complexity — upgrade validation in register route Phase C — Frontend UI (compliance screens) Tasks: F1-F11 Cookie consent component — banner + preferences modal Pre-payment disclosure — step before payment confirm in send-money flow Receipt view — enhanced transaction detail with PSD2 fields Settings compliance — data export, account deletion buttons Legal pages — /privacy, /terms, /fees, /withdrawal, /complaints 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.