Legal & Compliance Regulatory framework, privacy, AML, DPAs, policies, terms 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. Privacy & Data Protection Privacy Policy Personvernerklæring for Drop Sist oppdatert: 2. mars 2026 Behandlingsansvarlig: ALAI Holding AS, org.nr. 932 516 136 Kontakt: personvern@getdrop.no Nettsted: https://getdrop.no 1. Innledning Denne personvernerklæringen beskriver hvordan ALAI Holding AS («vi», «oss», «selskapet») behandler personopplysninger i forbindelse med betalingstjenesten Drop. Erklæringen er utarbeidet i samsvar med EUs personvernforordning (GDPR) artikkel 13 og 14, samt den norske personopplysningsloven (LOV-2018-06-15-38). Drop er en betalingstjeneste som tilbyr pengeoverføring til utlandet og QR-betalinger i butikk, tilgjengelig for alle innbyggere i Norge. Tjenesten opererer etter en pass-through-modell under PSD2 (EU-direktiv 2015/2366) og behandler aldri kundemidler direkte. 2. Behandlingsansvarlig ALAI Holding AS er behandlingsansvarlig for personopplysningene som behandles gjennom Drop-tjenesten, jf. GDPR artikkel 4 nr. 7. Kontaktinformasjon: Selskap: ALAI Holding AS Organisasjonsnummer: 932 516 136 E-post: personvern@getdrop.no Adresse: Se Brønnøysundregistrene 3. Personvernombud I henhold til GDPR artikkel 37 og personopplysningsloven (LOV-2018-06-15-38) har selskapet utnevnt et personvernombud (DPO). Gitt at selskapet behandler betalingsopplysninger og finansielle data i stor skala, er personvernombud formelt oppnevnt per 2. mars 2026. Personvernombud: Alem Bašić Selskap: ALAI Holding AS (org.nr. 932 953 736) E-post: alem@alai.no Telefon: +47 40 47 42 51 Oppnevnt: 2. mars 2026 — jf. GDPR artikkel 37–39 og personopplysningsloven § 23 4. Kategorier av personopplysninger 4.1 Identifikasjonsopplysninger Fullt navn (fra BankID) Fødselsnummer (fra BankID, kun for identitetsverifisering) Fødselsdato (utledet fra fødselsnummer for aldersverifisering, 18+) BankID-referanse 4.2 Kontaktopplysninger Mobilnummer (+47) E-postadresse Postadresse (ved behov) 4.3 Finansielle opplysninger Bankkontonummer (via PSD2 AISP) Kontosaldo (via PSD2 AISP, kun ved brukerens samtykke) Transaksjonshistorikk i Drop Betalingsmottakere og beløp Valutainformasjon ved utenlandsoverføringer Mottakerens bankopplysninger (for remittance) 4.4 Tekniske opplysninger IP-adresse Enhetsidentifikator (device ID) Operativsystem og appversjon Innloggings- og autentiseringslogger Brukeragent (browser/app) 4.5 Bruksmønster Tidspunkt for pålogging og transaksjoner Navigasjon i appen (anonymisert) Feillogger og krasjrapporter Push-varslingsinnstillinger 4.6 KYC/AML-relaterte opplysninger Legitimasjonsdokumenter (ved forsterket kundekontroll) PEP-status (politisk eksponert person) Sanksjonslistekontroll-resultater Risikoklassifisering 5. Rettslig grunnlag for behandlingen Vi behandler personopplysninger på følgende rettslige grunnlag, jf. GDPR artikkel 6: 5.1 Oppfyllelse av avtale — GDPR art. 6(1)(b) Gjennomføring av betalingstransaksjoner Kontoadministrasjon og brukerprofilhåndtering Transaksjonshistorikk og kvitteringer Push-varsler om transaksjoner Kundeservice 5.2 Rettslig forpliktelse — GDPR art. 6(1)(c) Hvitvaskingsloven (LOV-2018-06-01-23) §§ 4, 10-18 — kundekontroll Bokføringsloven (LOV-2004-11-19-73) § 13 — oppbevaring av regnskapsdokumentasjon Betalingssystemloven og PSD2-forordningen Personopplysningsloven — pliktig informasjon til den registrerte Skatteforvaltningsloven — rapportering til skattemyndighetene 5.3 Samtykke — GDPR art. 6(1)(a) Tilgang til kontosaldo via PSD2 AISP Markedsføringskommunikasjon Bruk av cookies utover det som er strengt nødvendig Deling av anonymiserte data for analyseformål 5.4 Berettiget interesse — GDPR art. 6(1)(f) Svindelforebygging og sikkerhetsovervåking Forbedring av tjenesten basert på anonymisert bruksdata Feilretting og teknisk feilsøking Intern statistikk og rapportering For behandling basert på berettiget interesse har vi gjennomført interesseavveining (LIA) i henhold til GDPR artikkel 6(1)(f). Dokumentasjon er tilgjengelig på forespørsel. 6. Formål med behandlingen Formål Rettslig grunnlag Oppbevaringstid Brukerregistrering og identitetsverifisering Avtale, rettslig forpliktelse Kontoens levetid + 5 år Gjennomføring av betalinger og overføringer Avtale 5 år (bokføringsloven) Kundekontroll (KYC/AML) Rettslig forpliktelse 5 år etter kundeforholdets opphør (hvvl. § 30) Svindelforebygging Berettiget interesse 3 år etter hendelse Kundeservice og klagebehandling Avtale, rettslig forpliktelse 3 år etter avslutning Markedsføring Samtykke Til samtykke trekkes tilbake Teknisk drift og feilretting Berettiget interesse 12 måneder Lovpålagt rapportering Rettslig forpliktelse I henhold til gjeldende lov 7. Deling av personopplysninger 7.1 Kategorier av mottakere Vi deler personopplysninger med følgende kategorier av mottakere: Betalingsinfrastruktur (nødvendig for tjenesten): Open Banking-leverandører (PSD2 PISP/AISP) — for å initiere betalinger og lese kontoinformasjon Korrespondentbanker i mottakerland — for gjennomføring av utenlandsoverføringer Betalingsnettverk — for QR-betalingsbehandling Regulatoriske myndigheter (rettslig forpliktelse): Finanstilsynet — tilsynsrapportering Datatilsynet — ved forespørsel eller avvik Økokrim/politiet — ved mistanke om hvitvasking eller terrorfinansiering Skattemyndighetene — lovpålagt rapportering Tjenesteleverandører (databehandlere): Skyinfrastrukturleverandører (hosting) Kundeserviceplattform Analyseverktøy (anonymiserte data) BankID-leverandør (autentisering) 7.2 Databehandleravtaler Alle databehandlere har inngått databehandleravtale (DPA) i samsvar med GDPR artikkel 28. Databehandleravtalene regulerer: Formålet med behandlingen Instrukser fra behandlingsansvarlig Sikkerhetstiltak Underdatabehandlere Bistandsplikt ved utøvelse av den registrertes rettigheter Sletting/tilbakelevering ved opphør 8. Overføring til tredjeland 8.1 Overføringer innenfor EØS Personopplysninger behandles primært innenfor EØS-området. All skyinfrastruktur er lokalisert i EU/EØS. 8.2 Overføringer utenfor EØS Ved utenlandsoverføringer (remittance) til land utenfor EØS er det nødvendig å overføre begrensede personopplysninger til mottakerens bank eller betalingsformidler. Dette gjelder: Mottakerens navn og kontonummer Avsenderens navn (lovpålagt ved internasjonale overføringer) Beløp og valuta Overføringsgrunnlag: EU-kommisjonens standard personvernbestemmelser (SCCs) — jf. GDPR artikkel 46(2)(c), vedtak (EU) 2021/914 av 4. juni 2021 Adekvansbeslutninger — for land med tilstrekkelig beskyttelsesnivå, jf. GDPR artikkel 45 Nødvendig for oppfyllelse av avtale — jf. GDPR artikkel 49(1)(b), der andre grunnlag ikke er tilgjengelige 8.3 Transfer Impact Assessment (TIA) For overføringer til tredjeland uten adekvansbeslutning har vi gjennomført Transfer Impact Assessment i henhold til Schrems II-avgjørelsen (C-311/18). Vurderingen omfatter: Lovgivningen i mottakerlandet vedrørende myndighetstilgang Tekniske og organisatoriske tilleggstiltak Praktisk erfaring med myndigheters tilgangsforespørsler Dokumentasjon av TIA er tilgjengelig på forespørsel til dpo@getdrop.no. 9. Oppbevaringstid og sletting Vi oppbevarer personopplysninger kun så lenge det er nødvendig for formålet med behandlingen, eller så lenge vi er rettslig forpliktet til det. 9.1 Hovedprinsipper Dataminimering: Vi samler kun inn opplysninger som er nødvendige for formålet, jf. GDPR artikkel 5(1)(c). Lagringsminimering: Opplysninger slettes når formålet er oppfylt, jf. GDPR artikkel 5(1)(e). Automatisk sletting: Systemer er konfigurert for automatisk sletting ved utløp av oppbevaringstid. 9.2 Spesifikke oppbevaringstider Datakategori Oppbevaringstid Hjemmel Transaksjonsdata 5 år etter regnskapsårets slutt Bokføringsloven § 13 KYC/AML-dokumentasjon 5 år etter kundeforholdets opphør Hvitvaskingsloven § 30 Innloggingslogger 12 måneder Berettiget interesse Kundeservicehenvendelser 3 år etter avslutning Avtale, foreldelsesloven Markedsføringssamtykker Til tilbaketrekking + 1 år dokumentasjon GDPR art. 7(1) Tekniske logger 6 måneder Berettiget interesse IP-adresser 3 måneder Berettiget interesse 9.3 Sletteprosedyre Ved sletting sørger vi for at personopplysninger fjernes fra alle systemer, inkludert sikkerhetskopier, innen rimelig tid (maksimalt 30 dager etter oppbevaringstidens utløp for sikkerhetskopier). 10. Den registrertes rettigheter I henhold til GDPR kapittel III har du følgende rettigheter: 10.1 Rett til innsyn (art. 15) Du har rett til å få bekreftet om vi behandler personopplysninger om deg, og i så fall få tilgang til opplysningene samt informasjon om behandlingen. Første kopi er gratis. 10.2 Rett til retting (art. 16) Du har rett til å få uriktige personopplysninger om deg rettet uten ugrunnet opphold. 10.3 Rett til sletting (art. 17) Du har rett til å få slettet personopplysninger om deg dersom: Opplysningene ikke lenger er nødvendige for formålet Du trekker tilbake samtykket Du protesterer mot behandlingen Opplysningene er behandlet ulovlig Unntak: Sletting kan nektes dersom behandlingen er nødvendig for å oppfylle en rettslig forpliktelse (f.eks. hvitvaskingsloven, bokføringsloven). 10.4 Rett til begrensning (art. 18) Du har rett til å kreve at behandlingen begrenses i visse situasjoner, for eksempel mens riktigheten av opplysningene kontrolleres. 10.5 Rett til dataportabilitet (art. 20) Du har rett til å motta personopplysninger du har gitt oss i et strukturert, alminnelig brukt og maskinlesbart format (JSON/CSV), og til å overføre disse til en annen behandlingsansvarlig. 10.6 Rett til å protestere (art. 21) Du har rett til å protestere mot behandling basert på berettiget interesse. Vi vil da stanse behandlingen med mindre vi kan påvise tvingende berettigede grunner som går foran dine interesser. 10.7 Rett til ikke å bli gjenstand for automatiserte avgjørelser (art. 22) Du har rett til ikke å bli gjenstand for en avgjørelse som utelukkende er basert på automatisert behandling, inkludert profilering, som har rettsvirkning eller tilsvarende betydelig påvirkning. Drop benytter automatiserte systemer for svindeldeteksjon. Ved automatisk avvisning av en transaksjon har du rett til: Manuell gjennomgang av avgjørelsen Å uttrykke ditt synspunkt Å bestride avgjørelsen 10.8 Rett til å trekke tilbake samtykke (art. 7(3)) Der behandling er basert på samtykke, kan du når som helst trekke dette tilbake. Tilbaketrekking påvirker ikke lovligheten av behandling som fant sted før tilbaketrekkingen. 11. Utøvelse av rettigheter 11.1 Hvordan utøve rettighetene Henvendelser om utøvelse av rettigheter kan sendes til: E-post: personvern@getdrop.no I appen: Under Innstillinger > Personvern > Mine rettigheter Post: ALAI Holding AS, [adresse], Norge 11.2 Identitetsverifisering For å beskytte dine opplysninger vil vi verifisere din identitet ved rettighetskrav, normalt gjennom BankID. 11.3 Svartid Vi besvarer henvendelser uten ugrunnet opphold, og senest innen 30 dager, jf. GDPR artikkel 12(3). Ved komplekse eller mange forespørsler kan fristen forlenges med ytterligere 60 dager, med informasjon til deg innen den første 30-dagersperioden. 11.4 Kostnad Utøvelse av rettigheter er i utgangspunktet gratis. Ved åpenbart grunnløse eller overdrevne krav kan vi kreve et rimelig gebyr eller nekte å etterkomme forespørselen, jf. GDPR artikkel 12(5). 12. Informasjonssikkerhet Vi har implementert egnede tekniske og organisatoriske sikkerhetstiltak for å beskytte personopplysninger, jf. GDPR artikkel 32: Kryptering: All dataoverføring er kryptert med TLS 1.3. Data i hvile er kryptert med AES-256. Tilgangskontroll: Rollebasert tilgangsstyring (RBAC), prinsippet om minste privilegium. Autentisering: BankID for brukere, MFA for ansatte. Logging: Komplett revisjonslogg for all tilgang til personopplysninger. Sårbarhetshåndtering: Regelmessig penetrasjonstesting og sårbarhetsskanning. Hendelseshåndtering: Etablerte prosedyrer for håndtering av sikkerhetsbrudd. Se vår IKT-sikkerhetspolicy for utfyllende informasjon. 13. Personvernbrudd Ved brudd på personopplysningssikkerheten vil vi: Melde til Datatilsynet innen 72 timer etter at bruddet ble oppdaget, jf. GDPR artikkel 33, med mindre bruddet sannsynligvis ikke medfører risiko for den registrertes rettigheter. Informere berørte registrerte uten ugrunnet opphold dersom bruddet sannsynligvis medfører høy risiko, jf. GDPR artikkel 34. Dokumentere alle brudd, uavhengig av alvorlighetsgrad, inkludert fakta, virkninger og korrigerende tiltak. 14. Cookies og sporingsteknikker Drop-appen benytter ikke tredjeparts sporingsteknikker. For nettsiden getdrop.no gjelder: 14.1 Nødvendige cookies Sesjonscookies for autentisering Sikkerhetscookies (CSRF-beskyttelse) Disse krever ikke samtykke, jf. ekomloven § 2-7b. 14.2 Analytiske cookies (krever samtykke) Anonymisert bruksstatistikk Aktiveres kun etter eksplisitt samtykke via cookiebanner 14.3 Markedsføringscookies (krever samtykke) Kun ved eksplisitt samtykke Kan til enhver tid trekkes tilbake via cookieinnstillinger 15. Endringer i erklæringen Vi kan oppdatere denne personvernerklæringen ved behov. Ved vesentlige endringer vil vi informere deg via: Push-varsling i appen E-post til registrert e-postadresse Melding ved neste pålogging Alle versjoner arkiveres og er tilgjengelige på forespørsel. 16. Klageadgang Dersom du mener at vår behandling av personopplysninger bryter med personvernlovgivningen, har du rett til å klage til: Datatilsynet Postboks 458 Sentrum 0105 Oslo Telefon: 22 39 69 00 E-post: postkasse@datatilsynet.no Nettsted: https://www.datatilsynet.no Du har også rett til å klage til tilsynsmyndigheten i det EØS-landet der du bor eller arbeider, jf. GDPR artikkel 77. 17. Kontakt oss For spørsmål om denne personvernerklæringen eller vår behandling av personopplysninger: Generelt: personvern@getdrop.no Personvernombud: Alem Bašić — alem@alai.no — +47 40 47 42 51 Post: ALAI Holding AS, [adresse], Norge Denne personvernerklæringen er sist oppdatert 2. mars 2026. DPIA Assessment Vurdering av personvernkonsekvenser (DPIA) — Drop Dokument-ID: DPIA-DROP-001 Versjon: 1.0 Dato: 12. februar 2026 Utarbeidet av: ALAI Holding AS Behandlingsansvarlig: ALAI Holding AS, org.nr. 932 516 136 Status: Godkjent 1. Innledning og bakgrunn 1.1 Formål Denne vurderingen av personvernkonsekvenser (DPIA) er utarbeidet i henhold til GDPR artikkel 35 og Datatilsynets retningslinjer for vurdering av personvernkonsekvenser. Formålet er å identifisere, vurdere og redusere personvernrisiko forbundet med betalingstjenesten Drop. 1.2 Hvorfor DPIA er påkrevd En DPIA er påkrevd fordi behandlingen oppfyller flere av kriteriene i GDPR artikkel 35(3) og Artikkel 29-gruppens retningslinjer (WP 248 rev.01): Systematisk overvåking: Automatisert svindeldeteksjon og transaksjonsovervåking Sårbare grupper: Brukere med varierende digital kompetanse Ny teknologi: Open Banking (PSD2 PISP/AISP) og BankID-integrasjon Stor skala: Tjenesten er rettet mot alle innbyggere i Norge Finansielle data: Behandling av bankopplysninger og transaksjonsdata Grenseoverskridende overføringer: Pengeoverføringer til 30+ land 1.3 Omfang Denne DPIA dekker all behandling av personopplysninger i Drop-tjenesten, inkludert: Brukerregistrering og BankID-verifisering Kontoinformasjonstjenester (AISP) Betalingsinitieringstjenester (PISP) Utenlandsoverføringer (remittance) til 30+ land QR-betalinger i butikk KYC/AML-prosesser Svindeldeteksjon og -forebygging 2. Systematisk beskrivelse av behandlingen 2.1 Tjenestebeskrivelse Drop er en betalingstjeneste for alle innbyggere i Norge som tilbyr: Utenlandsoverføringer (remittance): Send penger til mottakere i 30+ land. Mottaker trenger ikke Drop-konto. QR-betalinger: Betal hos forhandlere ved å skanne QR-kode. Lavere gebyrer enn tradisjonelle løsninger. Lommebok: Betalinger og daglig bruk. 2.2 Teknisk arkitektur Drop opererer etter en pass-through-modell: Drop holder aldri kundemidler Betalinger initieres via PSD2 PISP direkte fra brukerens bankkonto Kontoinformasjon leses via PSD2 AISP med brukerens eksplisitte samtykke All autentisering skjer via BankID (nivå 4 — høyeste sikkerhetsnivå) 2.3 Dataflyt Bruker → BankID (autentisering) → Drop-plattform → Open Banking API (PISP/AISP) → Brukerens bank ↓ Korrespondentbank → Mottaker (for remittance) 2.4 Personopplysninger som behandles Kategori Opplysninger Kilde Rettslig grunnlag Identifikasjon Navn, fødselsnummer, fødselsdato BankID Avtale, rettslig forpliktelse Kontakt Mobilnummer, e-post Bruker Avtale Finansielt Kontonummer, saldo, transaksjoner PSD2 AISP Samtykke, avtale Transaksjoner Beløp, mottaker, valuta, tidspunkt Drop-tjenesten Avtale KYC/AML Legitimasjon, PEP-status, sanksjoner Bruker, tredjeparter Rettslig forpliktelse Teknisk IP, device ID, logger Automatisk Berettiget interesse 2.5 Involvert personell og systemer Driftsteam: Begrenset tilgang til produksjonsdata, kun via autoriserte systemer Kundeservice: Tilgang til nødvendige personopplysninger for å håndtere henvendelser Compliance: Tilgang til KYC/AML-data og transaksjonsrapporter Databehandlere: Open Banking-leverandører, skyinfrastrukturleverandører, BankID-leverandør 3. Nødvendighets- og proporsjonalitetsvurdering 3.1 Nødvendighet — GDPR art. 35(7)(b) Hver behandlingsaktivitet er vurdert mot nødvendighetsprinsippet: Behandling Nødvendig? Begrunnelse BankID-verifisering Ja Lovpålagt identitetskontroll (hvvl. § 12), sikkerhetsnivå 4 påkrevd for finanstjenester Fødselsnummer Ja Kreves for entydig identifisering jf. hvitvaskingsloven § 12(1)(a) Kontoinformasjon (AISP) Ja, med samtykke Nødvendig for å vise saldo og verifisere dekning Betalingsinitiering (PISP) Ja Kjernetjenesten — uten dette ingen betalinger Transaksjonsdata Ja Bokføringsloven § 13, kundeoversikt, kvitteringer KYC/AML-data Ja Hvitvaskingsloven §§ 4, 10-18 Svindeldeteksjon Ja PSD2 art. 2, Finanstilsynets krav Tekniske logger Ja Sikkerhetskrav, feilsøking, DORA 3.2 Proporsjonalitet Dataminimering: Kun nødvendige opplysninger samles inn. Fødselsnummer lagres kryptert og tilgjengeliggjøres kun for autorisert personell. Formålsbegrensning: Opplysninger benyttes kun til angitt formål. Lagringsminimering: Definerte oppbevaringstider med automatisk sletting. Nøyaktighet: BankID sikrer korrekte identitetsopplysninger. Transaksjonsdata genereres av bankenes systemer. 3.3 Vurdering av alternativer Alternativ Vurdert Konklusjon Anonymisering av transaksjonsdata Ja Ikke mulig — lovpålagt sporbarhet (hvvl. § 25) Pseudonymisering Ja Planlagt for intern analyse Mindre inngripende autentisering Ja BankID er minste nødvendige nivå for finanstjenester Desentralisert lagring Ja Ikke proporsjonalt gitt regulatoriske krav 4. Risikovurdering 4.1 Metodikk Risiko vurderes etter sannsynlighet og konsekvens på en skala fra 1 (lav) til 4 (svært høy): Risikonivå = Sannsynlighet × Konsekvens Lav: 1-4, Middels: 5-8, Høy: 9-12, Svært høy: 13-16 4.2 Identifiserte risikoer R1: Uautorisert tilgang til finansielle data Beskrivelse: Tredjeparter får tilgang til brukerens bankopplysninger Sannsynlighet: 2 (lav) Konsekvens: 4 (svært høy) Risikonivå: 8 (middels) Berørte rettigheter: Konfidensialitet, økonomisk tap R2: Datalekkasje ved sikkerhetsbrudd Beskrivelse: Personopplysninger eksponeres ved hacking eller teknisk feil Sannsynlighet: 2 (lav) Konsekvens: 4 (svært høy) Risikonivå: 8 (middels) Berørte rettigheter: Konfidensialitet, integritet R3: Ulovlig profilering gjennom transaksjonsdata Beskrivelse: Transaksjonshistorikk brukes til å profilere brukere ut over formålet Sannsynlighet: 1 (svært lav) Konsekvens: 3 (høy) Risikonivå: 3 (lav) Berørte rettigheter: Rett til ikke å bli profilert R4: Manglende kontroll ved tredjelandsoverføringer Beskrivelse: Personopplysninger overføres til land uten tilstrekkelig personvern Sannsynlighet: 3 (middels) Konsekvens: 3 (høy) Risikonivå: 9 (høy) Berørte rettigheter: Konfidensialitet, myndighetstilgang R5: Feilaktig avvisning av transaksjoner (svindeldeteksjon) Beskrivelse: Automatiserte systemer avviser lovlige transaksjoner Sannsynlighet: 2 (lav) Konsekvens: 2 (middels) Risikonivå: 4 (lav) Berørte rettigheter: Rett til korrekt behandling, økonomisk ulempe R6: Manglende sletting etter oppbevaringstidens utløp Beskrivelse: Personopplysninger oppbevares lenger enn nødvendig Sannsynlighet: 2 (lav) Konsekvens: 2 (middels) Risikonivå: 4 (lav) Berørte rettigheter: Rett til sletting, lagringsminimering R7: Kompromittering av BankID-sesjon Beskrivelse: Angriper overtar BankID-sesjon via phishing eller MitM Sannsynlighet: 1 (svært lav) Konsekvens: 4 (svært høy) Risikonivå: 4 (lav) Berørte rettigheter: Identitetstyveri, økonomisk tap R8: Datatilgang fra tredjelandsmyndigheter Beskrivelse: Myndigheter i mottakerland krever tilgang til overføringsdata Sannsynlighet: 2 (lav) Konsekvens: 3 (høy) Risikonivå: 6 (middels) Berørte rettigheter: Konfidensialitet, personvern 5. Risikoreduserende tiltak 5.1 Tiltak per risiko R1 & R2: Uautorisert tilgang og datalekkasje Tiltak Status Ansvarlig End-to-end-kryptering (TLS 1.3, AES-256) Implementert Drift BankID-autentisering (sikkerhetsnivå 4) Implementert Utvikling Rollebasert tilgangskontroll (RBAC) Implementert Drift Regelmessig penetrasjonstesting (min. årlig) Planlagt Sikkerhet Sikkerhetsovervåking 24/7 (SIEM) Planlagt Drift Hendelseshåndteringsplan Dokumentert Compliance Kryptering av fødselsnummer i hvile Planlagt Utvikling R3: Ulovlig profilering Tiltak Status Ansvarlig Formålsbegrensning i systemdesign Implementert Utvikling Pseudonymisering ved intern analyse Planlagt Data Forbud mot sekundærbruk uten samtykke Policy Compliance Revisjonslogg for datatilgang Implementert Drift R4 & R8: Tredjelandsoverføringer Tiltak Status Ansvarlig Standard personvernbestemmelser (SCCs) med alle partnere Pågående Juridisk Transfer Impact Assessment per mottakerland Pågående Compliance Minimering av data ved overføring (kun påkrevde felt) Implementert Utvikling Kryptering av data under overføring Implementert Drift Regelmessig gjennomgang av mottakerlands lovgivning Årlig Compliance R5: Feilaktig avvisning Tiltak Status Ansvarlig Manuell gjennomgang ved automatisk avvisning Planlagt Drift Klageadgang for brukere Implementert Kundeservice Regelmessig kalibrering av svindeldeteksjon Kvartalsvis Data Transparens om automatiserte avgjørelser Planlagt Compliance R6: Manglende sletting Tiltak Status Ansvarlig Automatisert sletterutine Delvis implementert Drift Kvartalsvis kontroll av oppbevaringstider Planlagt Compliance Slettingslogg Planlagt Drift R7: BankID-kompromittering Tiltak Status Ansvarlig Sesjonstimeout (15 minutter inaktivitet) Implementert Utvikling Enhetsgjenkjenning Planlagt Utvikling Varsling ved ny enhet Planlagt Utvikling Anti-phishing-informasjon til brukere Planlagt Kommunikasjon 6. Vurdering av BankID-integrasjon 6.1 Beskrivelse BankID benyttes som eneste autentiseringsmekanisme for Drop-brukere. Dette er Norges nasjonale eID-løsning med sikkerhetsnivå 4 (høyeste). 6.2 Personvernfordeler Sterk identitetsverifisering: Reduserer risikoen for identitetsbedrageri Minimering av datainnsamling: Drop trenger ikke samle inn pass/legitimasjon separat Brukerens kontroll: Bruker godkjenner hver transaksjon aktivt via BankID Regulatorisk samsvar: Oppfyller krav i hvitvaskingsloven §§ 12-13 6.3 Personvernrisikoer Avhengighet av tredjepart: BankID Norge AS er databehandler Fødselsnummer: Overføres via BankID — sensitivt identifikasjonsnummer Sporbarhet: BankID-logger kan kobles til brukerens aktivitet 6.4 Tiltak Databehandleravtale med BankID Norge AS Fødselsnummer krypteres umiddelbart etter mottak Kun fødselsdato (for aldersverifisering) og navn lagres i klartekst BankID-sesjonsdata slettes etter autentisering 7. Transfer Impact Assessment (TIA) — Tredjelandsoverføringer 7.1 Bakgrunn Drop tilbyr pengeoverføringer til 30+ land, hvorav flere er utenfor EØS og mangler adekvansbeslutning fra EU-kommisjonen. I tråd med Schrems II-avgjørelsen (C-311/18) og EDPBs anbefalinger 01/2020 gjennomfører vi TIA for hvert mottakerland. 7.2 Vurderingsmetodikk For hvert mottakerland vurderes: Lovgivning: Har myndighetene vid tilgang til kommunikasjonsdata? Praktisk erfaring: Har vi mottatt forespørsler fra myndigheter? Dataminimering: Hvilke data overføres, og er de nødvendige? Tekniske tiltak: Kryptering, pseudonymisering, andre beskyttelser Kontraktuelle tiltak: SCCs, tilleggsklausuler 7.3 Landkategorisering Kategori Beskrivelse Tiltak Adekvat (grønn) EU-adekvansbeslutning foreligger SCCs som tillegg Moderat (gul) Visse bekymringer, men akseptabel risiko SCCs + tekniske tilleggstiltak Høy risiko (rød) Betydelige bekymringer om myndighetstilgang SCCs + sterke tekniske tiltak + individuell vurdering 7.4 Overførte data ved remittance Kun følgende data overføres til mottakers bank: Avsenders fulle navn (lovpålagt) Mottakers fulle navn og kontonummer Beløp og valuta Referansenummer Fødselsnummer, fødselsdato, IP-adresse og annen teknisk informasjon overføres aldri til tredjeland. 8. Konsultasjon med berørte parter 8.1 Intern konsultasjon Utvikling: Teknisk gjennomførbarhet av tiltak Compliance: Regulatorisk samsvar Drift: Operasjonell gjennomførbarhet Ledelse: Godkjenning av restrisiko 8.2 Ekstern konsultasjon BankID Norge AS: Verifisering av sikkerhetsarkitektur Open Banking-leverandør: Datahåndtering og sikkerhet Ekstern personvernrådgiver: Uavhengig gjennomgang av DPIA 8.3 Brukermedvirkning Pilotbrukere har gitt tilbakemelding på personverninformasjon og samtykkeflyt Personvernerklæring testet for forståelighet 9. Restrisiko og konklusjon 9.1 Risikomatrise etter tiltak Risiko Opprinnelig nivå Etter tiltak Akseptabel? R1: Uautorisert tilgang 8 (middels) 4 (lav) Ja R2: Datalekkasje 8 (middels) 4 (lav) Ja R3: Ulovlig profilering 3 (lav) 2 (lav) Ja R4: Tredjelandsoverføringer 9 (høy) 6 (middels) Ja, med løpende TIA R5: Feilaktig avvisning 4 (lav) 2 (lav) Ja R6: Manglende sletting 4 (lav) 2 (lav) Ja R7: BankID-kompromittering 4 (lav) 2 (lav) Ja R8: Tredjelandsmyndigheter 6 (middels) 4 (lav) Ja, med løpende TIA 9.2 Konklusjon Etter implementering av de beskrevne tiltakene vurderes restrisikoene som akseptable. Ingen risikoer krever forhåndskonsultasjon med Datatilsynet jf. GDPR artikkel 36. Vurderingen skal gjennomgås: Årlig som del av complianceprogrammet Ved vesentlige endringer i tjenesten, teknologien eller lovgivningen Ved nye mottakerland — ny TIA gjennomføres 9.3 Godkjenning Rolle Navn Dato Signatur Behandlingsansvarlig Alem Bašić, ALAI Holding AS . .2026 ___________ Personvernombud Alem Bašić (alem@alai.no, +47 40 47 42 51) 02.03.2026 (oppnevnt) ___________ CTO ___________________ . .2026 ___________ 10. Vedlegg Vedlegg A: Dataflytdiagram Se egen teknisk dokumentasjon. Vedlegg B: Transfer Impact Assessments per land Se egen mappe: /legal/tia/ Vedlegg C: Databehandleravtaler (oversikt) Se egen mappe: /legal/dpa/ Vedlegg D: Interesseavveininger (LIA) Se egen dokumentasjon. DPIA utarbeidet i henhold til GDPR artikkel 35, Datatilsynets veileder for vurdering av personvernkonsekvenser, og Artikkel 29-gruppens retningslinjer WP 248 rev.01. Data Processing Protocol Behandlingsprotokoll — Drop (ALAI Holding AS) Dokument: Protokoll over behandlingsaktiviteter (GDPR artikkel 30) Behandlingsansvarlig: ALAI Holding AS, org.nr. 932 516 136 Kontakt behandlingsansvarlig: personvern@getdrop.no Personvernombud: dpo@getdrop.no Produkt: Drop — betalingsformidling og pengeoverforinger Versjon: 1.0 Dato: 2026-02-17 Neste revisjon: 2027-02-17 1. Brukerregistrering og identitetsverifisering Felt Beskrivelse Formaal Registrere brukere i Drop-tjenesten og verifisere identitet gjennom BankID for aa oppfylle krav i hvitvaskingsloven og betalingstjenesteloven Rettslig grunnlag GDPR art. 6(1)(b) oppfyllelse av avtale; GDPR art. 6(1)(c) rettslig forpliktelse (hvitvaskingsloven ss 10-18) Kategorier av registrerte Fysiske personer bosatt i Norge som registrerer seg som brukere av Drop Kategorier av personopplysninger Fullt navn, foedselsnummer (via BankID), foedselsdato, mobilnummer (+47), e-postadresse, BankID-referanse Mottakere/overforinger BankID-leverandor (identitetsverifisering), Sumsub (KYC-prosessering) Overforinger til tredjeland Sumsub — EU SCCs iht. GDPR art. 46(2)(c) Oppbevaringstid Kontoens levetid + 5 aar etter avsluttet kundeforhold (hvitvaskingsloven s 30) Sikkerhetstiltak BankID hoyt sikkerhetsnivaa (eIDAS), kryptert lagring (AES-256), RBAC, komplett revisjonslogg 2. BankID-verifisering og autentisering Felt Beskrivelse Formaal Autentisere brukere ved innlogging og bekreftelse av transaksjoner gjennom BankID Rettslig grunnlag GDPR art. 6(1)(b) oppfyllelse av avtale; GDPR art. 6(1)(c) rettslig forpliktelse (sterk kundeautentisering, PSD2 art. 97) Kategorier av registrerte Alle registrerte Drop-brukere Kategorier av personopplysninger BankID-referanse, autentiseringslogger, tidspunkt for innlogging, IP-adresse, enhetsidentifikator Mottakere/overforinger BankID-leverandor Overforinger til tredjeland Ingen — BankID-infrastruktur er i Norge/EOS Oppbevaringstid Innloggingslogger: 12 maaneder; BankID-referanser: kontoens levetid + 5 aar Sikkerhetstiltak TLS 1.3, sesjonstokens med utloep, rate limiting, IP-blokkering ved gjentatte feilforsoek 3. Kundekontroll (KYC/CDD) Felt Beskrivelse Formaal Gjennomfoere lovpaalagt kundekontroll (Customer Due Diligence) iht. hvitvaskingsloven, inkludert PEP- og sanksjonsscreening Rettslig grunnlag GDPR art. 6(1)(c) rettslig forpliktelse (hvitvaskingsloven ss 10-18, s 30) Kategorier av registrerte Alle brukere ved registrering; brukere som utloeser forsterket kundekontroll (EDD) Kategorier av personopplysninger Identitetsdokumenter, PEP-status, sanksjonslistekontroll-resultater, risikoklassifisering, midlenes opprinnelse (ved EDD), formaal med kundeforhold Mottakere/overforinger Sumsub (KYC-prosessering), PEP/sanksjonslisteleverandor, Folkeregisteret (adresseoppslag) Overforinger til tredjeland Sumsub — EU SCCs; sanksjonslister (FN, EU, OFAC) behandles lokalt Oppbevaringstid 5 aar etter kundeforholdets opphoer (hvitvaskingsloven s 30) Sikkerhetstiltak Kryptert lagring (AES-256), separat tilgangskontroll for compliance-personell, komplett revisjonslogg for all tilgang 4. Gjennomfoering av betalingstransaksjoner Felt Beskrivelse Formaal Initiere og gjennomfoere utenlandsoverforinger (remittance) og QR-betalinger paa vegne av brukeren via Open Banking (PSD2 PISP) Rettslig grunnlag GDPR art. 6(1)(b) oppfyllelse av avtale; GDPR art. 6(1)(c) rettslig forpliktelse (bokfoeringsloven s 13) Kategorier av registrerte Brukere som gjennomfoerer transaksjoner; betalingsmottakere Kategorier av personopplysninger Avsenders navn og kontonummer, mottakers navn og kontonummer/referanse, beloep, valuta, vekslingskurs, formaalskode, tidspunkt, idempotency-noekkel Mottakere/overforinger Open Banking-leverandor (PISP), brukerens bank, korrespondentbanker i mottakerland, betalingsnettverk (QR) Overforinger til tredjeland Mottakers bank ved utenlandsoverforinger — EU SCCs iht. GDPR art. 46(2)(c) eller art. 49(1)(b) nodvendig for avtale Oppbevaringstid 5 aar etter regnskapsaarets slutt (bokfoeringsloven s 13) Sikkerhetstiltak TLS 1.3, BankID-bekreftelse per transaksjon, idempotency-kontroll, komplett revisjonslogg, beloepsgrenser 5. AML-overvaaking og mistenkelige transaksjoner Felt Beskrivelse Formaal Loepende overvaaking av transaksjoner for aa avdekke hvitvasking og terrorfinansiering iht. hvitvaskingsloven, inkludert automatisk flagging og manuell gjennomgang Rettslig grunnlag GDPR art. 6(1)(c) rettslig forpliktelse (hvitvaskingsloven ss 24-26) Kategorier av registrerte Alle brukere med transaksjoner; brukere med flaggede transaksjoner Kategorier av personopplysninger Transaksjonsmoenster, kumulative volumer, korridorrisikovurdering, AML-alarmer (type, alvorlighetsgrad), undersoekelsesstatus, STR-rapporter Mottakere/overforinger Oekokrim/EFE (ved rapportering via Altinn), Finanstilsynet (tilsynsrapportering) Overforinger til tredjeland Ingen — all rapportering til norske myndigheter Oppbevaringstid 5 aar etter kundeforholdets opphoer (hvitvaskingsloven s 30) Sikkerhetstiltak Automatisert regelbasert overvaaking, separat compliance-dashboard, revisjonslogg, tipping off-forbud (s 28) 6. Kontoinformasjonstjeneste (AISP) Felt Beskrivelse Formaal Hente og vise bankkontobalanse og kontoinformasjon fra brukerens bank via Open Banking AISP Rettslig grunnlag GDPR art. 6(1)(a) samtykke (bruker gir eksplisitt AISP-samtykke ved registrering) Kategorier av registrerte Brukere som har gitt AISP-samtykke Kategorier av personopplysninger Bankkontonummer, IBAN, banknavn, kontosaldo, saldosynkroniseringstidspunkt Mottakere/overforinger Open Banking-leverandor (AISP), brukerens bank Overforinger til tredjeland Ingen — norsk/EOS bankinfrastruktur Oppbevaringstid Saldo-cache: slettes ved neste synkronisering; kontokobling: kontoens levetid + 1 aar Sikkerhetstiltak Samtykkebasert tilgang, TLS 1.3, minimal datalagring (cache-modell), samtykke kan trekkes tilbake 7. Kundeservice og klagebehandling Felt Beskrivelse Formaal Behandle henvendelser, klagemaal og support-foresporsler fra brukere Rettslig grunnlag GDPR art. 6(1)(b) oppfyllelse av avtale; GDPR art. 6(1)(c) rettslig forpliktelse (PSD2 art. 101, betalingstjenesteloven) Kategorier av registrerte Brukere som henvender seg til kundeservice eller klager Kategorier av personopplysninger Navn, e-post, telefonnummer, klageinnhold (kategori, emne, beskrivelse), losningsstatus, behandlingshistorikk Mottakere/overforinger Kundeserviceplattform (databehandler); Finansklagenemnda ved eskalerte klager Overforinger til tredjeland Avhengig av kundeserviceplattform — EU SCCs Oppbevaringstid 3 aar etter avsluttet henvendelse (foreldelsesloven) Sikkerhetstiltak Tilgangskontroll for kundeservicepersonell, kryptering, revisjonslogg 8. Varsler og kommunikasjon Felt Beskrivelse Formaal Sende push-varsler, e-postvarsler og app-meldinger om transaksjoner, sikkerhet og tjenesteinformasjon Rettslig grunnlag GDPR art. 6(1)(b) oppfyllelse av avtale (transaksjonsvarsler); GDPR art. 6(1)(a) samtykke (markedsfoering) Kategorier av registrerte Alle registrerte brukere Kategorier av personopplysninger Bruker-ID, varslingstype, innhold, lest-status, push-abonnement (endpoint, noekler), e-postadresse, varslingsinnstillinger Mottakere/overforinger Push-varslingsleverandor (Apple APNs / Google FCM) Overforinger til tredjeland Apple (USA) og Google (USA) for push-varsler — EU SCCs Oppbevaringstid Varsler: 12 maaneder; markedsforingssamtykke: til tilbaketrekking + 1 aar dokumentasjon Sikkerhetstiltak Kryptering av push-innhold, samtykke for markedsfoering, opt-out mulighet 9. Teknisk drift, logging og feilsoking Felt Beskrivelse Formaal Sikre stabil drift av tjenesten, oppdage og rette feil, forhindre sikkerhetsbrudd, og opprettholde revisjonslogg Rettslig grunnlag GDPR art. 6(1)(f) berettiget interesse (IT-sikkerhet og driftsstabilitet); GDPR art. 6(1)(c) rettslig forpliktelse (revisjonslogg for finansielle tjenester) Kategorier av registrerte Alle brukere; systemadministratorer Kategorier av personopplysninger IP-adresse, brukeragent, enhetsidentifikator, feillogger, krasjrapporter, API-tilgangslogger, request-ID, revisjonslogg (handlinger, tidspunkt, ressurs) Mottakere/overforinger Sentry (feilrapportering, databehandler); skyinfrastrukturleverandor Overforinger til tredjeland Sentry — EU SCCs Oppbevaringstid Tekniske logger: 6 maaneder; IP-adresser: 3 maaneder; revisjonslogg: 5 aar Sikkerhetstiltak Strukturert JSON-logging med request-ID, tilgangskontroll til loggdata, automatisk sletting 10. Analyse og tjenesteforbedring Felt Beskrivelse Formaal Forbedre brukeropplevelsen, analysere bruksmoenstre og optimalisere tjenesten basert paa anonymisert/pseudonymisert data Rettslig grunnlag GDPR art. 6(1)(a) samtykke (analytiske cookies); GDPR art. 6(1)(f) berettiget interesse (intern statistikk paa anonymisert data) Kategorier av registrerte Brukere som har gitt samtykke til analytiske cookies; alle brukere (anonymisert/aggregert) Kategorier av personopplysninger Anonymisert navigasjonsdata, funksjonsbruk (aggregert), app-versjon, operativsystem, responstider (aggregert) Mottakere/overforinger Analyseverktoy (databehandler, anonymiserte data) Overforinger til tredjeland Avhengig av analyseverktoy — kun anonymiserte data Oppbevaringstid Anonymisert data: ingen begrensning; raadata: 12 maaneder Sikkerhetstiltak Dataminimering, anonymisering/pseudonymisering, cookie-samtykke (ekomloven s 2-7b), ingen re-identifisering Generelle sikkerhetstiltak (GDPR artikkel 32) Foelgende tiltak gjelder for alle behandlingsaktiviteter: Kryptering i transit: TLS 1.3 for all dataoverforing Kryptering i hvile: AES-256 for lagrede personopplysninger Tilgangskontroll: Rollebasert tilgangsstyring (RBAC), prinsippet om minste privilegium Autentisering: BankID for brukere, MFA for ansatte/administratorer Logging: Komplett revisjonslogg for all tilgang til personopplysninger (audit_log-tabell) Saarbarhetshåndtering: Regelmessig penetrasjonstesting og saarbarhetsskanning Hendelseshaandtering: Etablerte prosedyrer for sikkerhetsbrudd, 72-timers melding til Datatilsynet Backup: Daglig kryptert backup med kontrollert tilgang Sletting: Automatiserte sletteprosedyrer ved utloep av oppbevaringstid Databehandlere (GDPR artikkel 28) Databehandler Formaal Lokalisering Overforingsgrunnlag Swan (BaaS) Banking-as-a-Service, kontoforvaltning EU (Frankrike) Innenfor EOS Sumsub KYC/identitetsverifisering EU/UK EU SCCs Sentry Feilrapportering og ytelsesovervaaking EU/USA EU SCCs BankID Autentisering og identitetsverifisering Norge Innenfor EOS Skyinfrastrukturleverandor Hosting og databehandling EU/EOS Innenfor EOS Push-varslingsleverandor (APNs/FCM) Push-varsler USA EU SCCs Alle databehandlere har inngaatt databehandleravtale (DPA) iht. GDPR artikkel 28. Endringslogg Versjon Dato Endring Godkjent av 1.0 2026-02-17 Forstegangs utarbeidelse — 10 behandlingsaktiviteter Daglig leder Denne behandlingsprotokollen er utarbeidet iht. GDPR artikkel 30 og personopplysningsloven (LOV-2018-06-15-38). Protokollen skal vaere tilgjengelig for Datatilsynet paa forespørsel. Outsourcing Policy Utkontrakteringspolicy — Drop Dokument-ID: UTKONTR-DROP-001 Versjon: 1.0 Dato: 12. februar 2026 Eier: ALAI Holding AS, org.nr. 932 516 136 Klassifisering: Intern Regulatorisk grunnlag: DORA (EU) 2022/2554 art. 28-30, Finanstilsynets retningslinjer for utkontraktering 1. Innledning 1.1 Formål Denne policyen etablerer rammeverket for styring av utkontraktering og tredjepartsleverandører som understøtter Drop-tjenesten. Policyen sikrer at risikoen knyttet til utkontraktering identifiseres, vurderes og håndteres i samsvar med DORA og Finanstilsynets krav. 1.2 Virkeområde Policyen gjelder for: Alle IKT-tjenester som er utkontraktert til tredjeparter Alle tredjepartsleverandører som har tilgang til Drop-systemer eller -data Internt utkontrakterte tjenester (innen konsern) Underleverandører til våre tredjepartsleverandører (kjede) 1.3 Regulatorisk bakgrunn Regulering Artikler Beskrivelse DORA (EU) 2022/2554 Art. 28 Generelle prinsipper for IKT-tredjepartsrisiko DORA (EU) 2022/2554 Art. 29 Forhåndsvurdering av IKT-tredjepartsrisiko DORA (EU) 2022/2554 Art. 30 Kontraktuelle krav GDPR (EU) 2016/679 Art. 28 Databehandlere PSD2 (EU) 2015/2366 Art. 19 Agenter og utkontraktering Finanstilsynets rundskriv — Retningslinjer for utkontraktering IKT-forskriften — Krav til IKT-drift 2. Prinsipper 2.1 Overordnede prinsipper Ledelsesansvar: Styret og ledelsen har det overordnede ansvaret for all utkontraktering, jf. DORA art. 28(2). Utkontraktering fritar ikke selskapet fra regulatoriske forpliktelser. Risikostyring: All utkontraktering vurderes gjennom vårt IKT-risikostyringsrammeverk. Proporsjonalitet: Krav til leverandørstyring er proporsjonale med tjenestens kritikalitet. Konsentrasjonrisiko: Vi vurderer og unngår uhensiktsmessig konsentrasjon hos enkeltleverandører. Exit-strategi: Vi sikrer at vi kan avslutte eller overføre enhver utkontraktert tjeneste. 2.2 Hva som kan utkontrakteres Følgende kan utkontrakteres med adekvat risikostyring: IKT-infrastruktur (hosting, lagring) Open Banking-tjenester (PSD2 PISP/AISP) Autentiseringstjenester (BankID) Kundeserviceteknologi Analysetjenester (anonymiserte data) 2.3 Hva som ikke kan utkontrakteres Følgende kan ikke utkontrakteres: Overordnet risikostyring og compliance-overvåking Beslutninger om strategi og styring Overordnet ansvar for kundekontroll (KYC/AML) Regulatorisk rapportering (operasjonelt kan delegeres, ansvaret forblir) 3. Kritikalitetsklassifisering 3.1 Klassifiseringsmodell Klasse Beskrivelse Kriterier Eksempler Kritisk Bortfall medfører umiddelbar stans i kjernetjenester Betalingsbehandling, autentisering, datalagring Open Banking-leverandør, BankID, skyinfrastruktur, database Viktig Bortfall medfører vesentlig degradering Kundeservice, rapportering, overvåking Kundeserviceplattform, SIEM, analysetjenester Standard Bortfall medfører begrenset påvirkning Støttefunksjoner, utviklingsverktøy E-postleverandør, utviklingsmiljø, CI/CD 3.2 Kriterier for klassifisering Klassifisering baseres på: Konsekvens ved bortfall: Påvirkning på kjernetjenester og brukere Datatilgang: Tilgang til personopplysninger eller finansielle data Substituerbarhet: Mulighet for rask erstatning Regulatorisk relevans: Tjenestens rolle i regulatorisk etterlevelse Konsentrasjonsrisiko: Avhengighet til enkelteleverandør 3.3 Register over utkontrakterte tjenester Vi vedlikeholder et oppdatert register over alle utkontrakterte IKT-tjenester, jf. DORA art. 28(3), som minimum inneholder: Leverandørens navn, organisasjonsnummer og kontaktinformasjon Tjenestebeskrivelse Kritikalitetsklasse Dato for avtaleinngåelse og utløp Databehandlerstatus (ja/nei) Land der tjenesten utføres Underleverandører Dato for siste risikovurdering 4. Due diligence — DORA art. 29 4.1 Forhåndsvurdering Før inngåelse av avtale om utkontraktering gjennomføres due diligence proporsjonalt med tjenestens kritikalitet: Kritiske tjenester — utvidet due diligence Område Vurdering Finansiell stabilitet Kredittvurdering, årsregnskap, eierstruktur Teknisk kompetanse Referanser, sertifiseringer, teknisk arkitektur Sikkerhet Sikkerhetssertifiseringer (ISO 27001, SOC 2), penetrasjonstester Regulatorisk samsvar Relevante lisenser, tilsynsstatus, DORA-beredskap Operasjonell resiliens BCP/DR-kapasitet, SLA-historikk, hendelseshistorikk Personvern GDPR-samsvar, databehandleravtale, TIA ved tredjeland Konsentrasjonrisiko Leverandørens markedsandel, avhengigheter Underleverandører Oversikt og vurdering av kritiske underleverandører Exit-mulighet Dataportabilitet, overgangsperiode, migrasjonsplan Viktige tjenester — standard due diligence Teknisk kompetanse og referanser Sikkerhetssertifiseringer GDPR-samsvar og databehandleravtale SLA-betingelser Exit-klausuler Standard tjenester — forenklet due diligence Grunnleggende selskapsinfo Relevante sertifiseringer GDPR-samsvar der relevant Kontraktvilkår 4.2 Risikovurdering Due diligence resulterer i en risikovurdering som dokumenterer: Identifiserte risikoer per kategori Risikonivå (lav, middels, høy, kritisk) Anbefalte mitigerende tiltak Gjenværende risiko Anbefaling (godkjent, godkjent med betingelser, avvist) 4.3 Godkjenning Kritikalitet Godkjenner Kritisk Styret Viktig Daglig leder Standard CISO 5. Kontraktuelle krav — DORA art. 30 5.1 Obligatoriske kontraktbestemmelser Alle avtaler om utkontraktering av IKT-tjenester skal inneholde følgende, jf. DORA art. 30: 5.1.1 Tjenestebeskrivelse Detaljert beskrivelse av tjenesten Tjenestenivå (SLA) med målbare kriterier Rapporteringsforpliktelser 5.1.2 Sikkerhet Sikkerhetskrav i henhold til vår IKT-sikkerhetspolicy Hendelsesrapportering — varsling til oss uten ugrunnet opphold, senest innen 24 timer Sårbarhetshåndtering og patchkrav Krypteringskrav 5.1.3 Databehandling Databehandleravtale iht. GDPR artikkel 28 (for alle leverandører som behandler personopplysninger) Datalokalitet (EØS-krav) Sletting/tilbakelevering ved avtalens opphør Forbud mot sekundærbruk av data 5.1.4 Tilsyn og revisjon Vår rett til revisjon og inspeksjon, jf. DORA art. 30(3)(e) Finanstilsynets rett til tilgang og informasjon Samarbeid med tredjepartsrevisorer Rett til on-site inspeksjon ved kritiske tjenester 5.1.5 Underleverandører Forhåndsgodkjenning av kritiske underleverandører Varsling ved endring av underleverandører Samme kontraktuelle krav videreføres i kjeden Rett til å motsette seg bruk av spesifikke underleverandører 5.1.6 Kontinuitet og exit Leverandørens forpliktelser ved egen konkurs eller opphør Overgangsperiode ved oppsigelse (minimum tilstrekkelig for migrasjon) Bistand ved overføring til ny leverandør Dataportabilitet og -tilbakelevering Videreføring av tjeneste under overgangsperiode 5.1.7 Oppsigelse Gjensidig oppsigelsesrett med rimelig varsel Rett til umiddelbar oppsigelse ved vesentlig mislighold Rett til oppsigelse dersom leverandøren ikke oppfyller regulatoriske krav Rett til oppsigelse ved endringer som vesentlig påvirker risikoprofilen 5.2 Tilleggskrav for kritiske tjenester For kritiske tjenester kreves i tillegg: Detaljert BCP/DR-plan med testforpliktelse Dedikerte sikkerhetskontakter og eskaleringsprosedyrer Kvartalsvise ytelsesrapporter Årlig uavhengig sikkerhetsrevisjon (eller deling av SOC 2-rapport) Minimumsgaranti for tilgjengelighet (99,9% eller høyere) Penalty-klausuler ved gjentatte SLA-brudd 6. Løpende overvåking 6.1 Overvåkingsrammeverk Kritikalitet Frekvens for gjennomgang Revisjon SLA-rapportering Kritisk Kvartalsvis Årlig Månedlig Viktig Halvårlig Hvert 2. år Kvartalsvis Standard Årlig Ved behov Halvårlig 6.2 Løpende vurdering For alle utkontrakterte tjenester overvåkes: SLA-etterlevelse og tjenestekvalitet Sikkerhetshendelser og sårbarhetsstatus Regulatorisk etterlevelse Finansiell stabilitet (for kritiske leverandører) Endringer i underleverandørkjeden Endringer i risikoprofil 6.3 Hendelseshåndtering Ved hendelser hos leverandør: Leverandør varsler oss iht. avtalt prosedyre Vi vurderer konsekvens for Drop-tjenesten Vi aktiverer interne prosedyrer ved behov (se hendelseshaandtering.md ) Vi rapporterer til Finanstilsynet ved vesentlig IKT-hendelse Hendelsen dokumenteres og følges opp 6.4 Leverandørmøter Kritikalitet Frekvens Agenda Kritisk Kvartalsvis (min.) SLA-gjennomgang, sikkerhetsoppdatering, roadmap, hendelser Viktig Halvårlig SLA-gjennomgang, sikkerhetsoppdatering Standard Årlig Generell gjennomgang 7. Exit-strategi 7.1 Prinsipper For alle utkontrakterte tjenester av klasse Kritisk og Viktig skal det foreligge en dokumentert exit-strategi. Exit-strategien sikrer at tjenesten kan overføres til alternativ leverandør eller tas tilbake internt uten uakseptabel forstyrrelse. 7.2 Exit-plan per kritisk tjeneste Hver exit-plan inneholder: Trigger-hendelser: Scenarioer som utløser exit (oppsigelse, mislighold, konkurs, regulatorisk pålegg) Alternativ leverandør: Identifisert og prekvalifisert alternativ Migrasjonsprosedyre: Steg-for-steg-plan for overføring Tidsramme: Estimert tid for komplett migrasjon Ressursbehov: Personell, teknologi, budsjett Dataoverføring: Prosedyre for sikker overføring/sletting av data Testprosedyre: Verifisering av tjenestekvalitet hos ny leverandør Kommunikasjon: Plan for informasjon til brukere og myndigheter 7.3 Spesifikke exit-strategier Open Banking-leverandør (Kritisk) Sekundær leverandør identifisert og API-integrert (varm standby) Switchover testbar innen 4 timer Full migrasjon innen 30 dager Data: Transaksjonshistorikk overføres eller gjenopprettes fra egen database Skyinfrastruktur (Kritisk) Infrastruktur-som-kode (IaC) sikrer reproduserbarhet Sekundær region hos alternativ leverandør prekonfigurert Database-replikering til alternativ plattform Full migrasjon innen 14 dager BankID (Kritisk) Ingen realistisk alternativ autentiseringsløsning i Norge Exit-strategi: Degradert modus med midlertidig autentisering i begrenset periode Avhengigheten aksepteres som nasjonal infrastrukturrisiko 7.4 Testing av exit-strategi Tabletop-gjennomgang årlig for kritiske leverandører Teknisk exit-test (failover) halvårlig for leverandører med varm standby Dokumentasjon av testresultater og forbedringspunkter 8. Finanstilsynet — varsling og rapportering 8.1 Varsling I henhold til Finanstilsynets retningslinjer og DORA varsles Finanstilsynet: Før inngåelse: Av avtaler om utkontraktering av kritiske IKT-tjenester Ved vesentlige endringer: I eksisterende avtaler for kritiske tjenester Ved hendelser: Hos leverandører som påvirker vår tjenesteleveranse vesentlig 8.2 Informasjon til Finanstilsynet Varsling inneholder: Leverandørens identitet Tjenestens art og kritikalitet Risikovurdering Kontraktuelle beskyttelser Exit-strategi Konsekvenser for tjenesteleveranse 8.3 Register tilgjengelig for tilsyn Vi opprettholder et oppdatert register over all utkontraktering som gjøres tilgjengelig for Finanstilsynet på forespørsel, jf. DORA art. 28(3). 9. Konsentrasjonsrisiko — DORA art. 29(2) 9.1 Vurdering Vi vurderer regelmessig konsentrasjonsrisiko, inkludert: Avhengighet til enkelteleverandører for kritiske tjenester Geografisk konsentrasjon (alle tjenester i samme region/land) Teknologisk konsentrasjon (alle tjenester på samme plattform) Sektorkonsentrasjon (leverandørers avhengighet av samme bransje) 9.2 Mitigering Sekundære leverandører for kritiske tjenester Geografisk diversifisering av infrastruktur (flere regioner/soner) Unngå kritisk avhengighet til én enkelt skyplattform der mulig Regelmessig vurdering av leverandørmarkedet 10. Internkontroll 10.1 Roller og ansvar Rolle Ansvar Styret Godkjenning av policy og kritiske avtaler Daglig leder Overordnet ansvar for utkontraktering, godkjenning av viktige avtaler CISO Sikkerhetsvurdering, due diligence, løpende overvåking Compliance-ansvarlig Regulatorisk samsvar, Finanstilsynet-rapportering Innkjøpsansvarlig Kontraktshåndtering, leverandørkontakt Driftsteam Operasjonell oppfølging, SLA-overvåking 10.2 Første linje — operasjonell styring Daglig overvåking av tjenestekvalitet Oppfølging av SLA-etterlevelse Kontaktpunkt mot leverandør 10.3 Andre linje — kontroll og risikostyring Periodisk risikovurdering Due diligence-gjennomføring Policy-etterlevelse 10.4 Tredje linje — uavhengig kontroll Årlig gjennomgang av utkontrakteringspolicyen Stikkprøvekontroll av leverandøravtaler Rapportering til styret 11. Revisjon og oppdatering 11.1 Gjennomgang Årlig: Full gjennomgang av policyen Ved nye kritiske avtaler: Vurdering av behov for policyendringer Ved regulatoriske endringer: Oppdatering iht. nye krav Etter hendelser: Revisjon basert på hendelser hos leverandører 11.2 Versjonshistorikk Versjon Dato Endring Godkjent av 1.0 12.02.2026 Opprinnelig dokument ____________ Vedlegg Vedlegg A: Register over utkontrakterte tjenester Separat dokument — vedlikeholdes av CISO. Vedlegg B: Mal for due diligence-rapport Separat dokument — tilgjengelig ved forespørsel. Vedlegg C: Mal for exit-plan Separat dokument — tilgjengelig ved forespørsel. Vedlegg D: Sjekkliste for kontraktskrav (DORA art. 30) Separat dokument — brukes ved alle nye avtaler. Denne utkontrakteringspolicyen er eid av CISO og godkjent av styret i ALAI Holding AS. AML & Risk AML Procedures Hvitvaskingsrutiner — Drop (ALAI Holding AS) Dokument: Internrutiner for tiltak mot hvitvasking og terrorfinansiering Hjemmel: Lov om tiltak mot hvitvasking og terrorfinansiering (hvitvaskingsloven, LOV-2018-06-01-23) Virksomhet: ALAI Holding AS, org.nr 932 516 136 Produkt: Drop — betalingsformidling og pengeoverføringer Versjon: 1.0 Dato: 2026-02-12 Godkjent av: Daglig leder / Styre Neste revisjon: 2027-02-12 1. Formål og virkeområde 1.1 Formål Disse rutinene skal sikre at ALAI Holding AS («Selskapet») gjennom produktet Drop etterlever kravene i hvitvaskingsloven med forskrifter, og bidrar til å forebygge og avdekke hvitvasking og terrorfinansiering. 1.2 Virkeområde Rutinene gjelder for all virksomhet knyttet til Drop, herunder: Pengeoverføringer til utlandet (remittance) til 30+ land QR-baserte betalinger i butikk Kunderegistrering og -oppfølging Alle ansatte, styremedlemmer og tredjeparter som utfører oppgaver på vegne av Selskapet 1.3 Forretningsmodell — pass-through Drop opererer en pass-through-modell under PSD2 (PISP/AISP). Drop holder aldri kundemidler. Alle transaksjoner initieres via Open Banking-grensesnitt mot kundens egen bankkonto. Denne modellen reduserer enkelte risikoer, men endrer ikke de grunnleggende pliktene etter hvitvaskingsloven. 1.4 Regulatorisk klassifisering Selskapet søker konsesjon som betalingsforetak etter finansforetaksloven, jf. også hvitvaskingsloven §4 første ledd bokstav c (betalingsforetak). 2. Lovgrunnlag og sentrale bestemmelser Bestemmelse Innhold Hvvl. §4 Rapporteringspliktige — betalingsforetak er omfattet Hvvl. §6 Virksomhetsinnrettet risikovurdering Hvvl. §§7-8 Rutiner og internkontroll Hvvl. §§9-18 Kundetiltak (CDD) Hvvl. §§17-18 Forsterkede kundetiltak (EDD) Hvvl. §§24-25 Løpende oppfølging Hvvl. §26 Undersøkelsesplikt Hvvl. §26 tredje ledd Rapporteringsplikt til Økokrim/EFE Hvvl. §30 Oppbevaringsplikt (5 år) Hvvl. §§36-38 Internkontroll og opplæring Sanksjonslovgivningen FN, EU, norske sanksjonslister PEP-forskriften Politisk eksponerte personer 3. Virksomhetsinnrettet risikovurdering (§6) 3.1 Krav Selskapet skal gjennomføre og dokumentere en helhetlig risikovurdering av virksomheten, som identifiserer og vurderer risikoen for hvitvasking og terrorfinansiering. Risikovurderingen oppdateres minst årlig og ved vesentlige endringer. 3.2 Risikokategorier Risikovurderingen dekker følgende kategorier: Kundebasert risiko — risikobasert tilnærming basert på kundens adferd, transaksjonsvolum og korridorer Geografisk risiko — land og korridorer med høyere HV/TF-risiko Produkt- og tjenestebasert risiko — grensekryssende overføringer, QR-betalinger Kanal- og leveringsrisiko — digital onboarding, mobilapp Se eget dokument: risikovurdering-hvitvasking.md 3.3 Risikonivåer Nivå Beskrivelse Tiltak Lav Norsk bosatt, norsk BankID, lavrisiko-korridor Standard kundetiltak (CDD) Middels Høyere transaksjonsvolum, middels risiko-korridor Utvidet overvåking, mulig EDD Høy Høyrisiko-korridor, PEP, uvanlig transaksjonsmønster Forsterkede kundetiltak (EDD) Uakseptabel Sanksjonert person/land, bekreftet mistanke Avvisning eller avvikling av kundeforhold 4. Kundetiltak (KYC/CDD) — §§9-16 4.1 Når kundetiltak skal gjennomføres Kundetiltak skal gjennomføres ved: Etablering av kundeforhold (registrering i Drop), jf. §10 Enkeltstående transaksjoner over NOK 10 000 utenfor etablert kundeforhold, jf. §10 Mistanke om hvitvasking eller terrorfinansiering, uavhengig av beløp, jf. §10 Tvil om tidligere innhentede opplysninger, jf. §24 4.2 Standard kundetiltak (CDD) 4.2.1 Fysiske personer (alle kunder) Følgende opplysninger skal innhentes og verifiseres, jf. §12: Opplysning Kilde Verifisering Fullt navn BankID Automatisk via BankID-integrasjon Fødselsnummer (11 siffer) BankID Automatisk — brukes til alderskontroll (18+) og identifisering Adresse Kunde oppgir, sjekkes mot Folkeregisteret Folkeregisteroppslag Statsborgerskap Kunde oppgir Krysssjekk mot BankID-data Formål med kundeforholdet Kunde velger ved registrering Dokumenteres i kundeprofil 4.2.2 Juridiske personer (merchants) For merchanter som registrerer seg for QR-betalinger: Opplysning Kilde Verifisering Foretaksnavn og org.nr Kunde oppgir Brønnøysundregistrene Forretningsadresse Kunde oppgir Brønnøysundregistrene Reelle rettighetshavere Kunde oppgir Aksjonærregisteret, egenoppgave Daglig leder/kontaktperson Kunde oppgir BankID-verifisering av kontaktperson Formål med kundeforholdet Kunde velger Dokumenteres 4.2.3 Identitetsbekreftelse Primær metode: Norsk BankID (nivå «høyt» etter eIDAS) BankID gir verifisert navn, fødselsnummer og sikrer at kunden er den de utgir seg for Kunder uten gyldig norsk BankID kan ikke registrere seg i Drop Minstealder 18 år kontrolleres automatisk basert på fødselsnummer 4.3 Forsterkede kundetiltak (EDD) — §§17-18 Forsterkede tiltak skal gjennomføres når risikoen er vurdert som høy, herunder: 4.3.1 Situasjoner som utløser EDD Kunder som sender penger til høyrisikoland (jf. EUs liste over høyrisikoland og FATFs gråliste/svarteliste) Politisk eksponerte personer (PEP), jf. §18 Uvanlige eller mistenkelige transaksjonsmønstre Kunder med vesentlig høyere transaksjonsvolum enn oppgitt formål tilsier Kundeforhold der det er vanskelig å verifisere reelle rettighetshavere 4.3.2 EDD-tiltak Innhenting av tilleggsinformasjon om midlenes opprinnelse Innhenting av dokumentasjon for formålet med transaksjonen Hyppigere oppdatering av kundeinformasjon Økt transaksjonsovervåking (lavere terskelverdier) Godkjenning av kundeforholdet av hvitvaskingsansvarlig Risikovurdering dokumenteres i kundeprofilen 4.4 PEP-screening — §18 4.4.1 Hvem er PEP Politisk eksponerte personer inkluderer: Statsoverhoder, regjeringsmedlemmer, parlamentsmedlemmer Høyesterettsdommere, riksrevisorer, sentralbankstyremedlemmer Ambassadører, militære offiserer av høy rang Ledere av statsforetak Nære familiemedlemmer og kjente medarbeidere til ovennevnte 4.4.2 PEP-prosedyre Screening ved onboarding: Automatisk PEP-sjekk mot anerkjent database (f.eks. Refinitiv World-Check, Dow Jones) Løpende screening: Automatisk re-screening ved endringer i PEP-lister Positive treff: Manuell vurdering av hvitvaskingsansvarlig EDD ved bekreftet PEP: Tilleggsdokumentasjon, godkjenning av daglig leder, hyppigere overvåking 4.5 Sanksjonsscreening 4.5.1 Lister som sjekkes FNs konsoliderte sanksjonsliste EUs konsoliderte sanksjonsliste Norske forskrifter om sanksjoner (UD) OFAC SDN-listen (for USD-transaksjoner) 4.5.2 Prosedyre Ved onboarding: Automatisk screening av kundens navn og fødselsdato mot alle sanksjonslister Ved hver transaksjon: Automatisk screening av mottaker mot sanksjonslister Positive treff: Transaksjon fryses automatisk. Hvitvaskingsansvarlig varsles. Bekreftet treff: Transaksjon avvises. Rapportering til Utenriksdepartementet og EFE. Falske positive: Dokumenteres og godkjennes av hvitvaskingsansvarlig. 5. Løpende oppfølging — §§24-25 5.1 Transaksjonsinformasjon Alle transaksjoner skal inneholde følgende informasjon, jf. betalingssystemloven og EU-forordning 2015/847: Avsenders fulle navn, adresse, kontonummer Mottakers fulle navn, kontonummer/referanse Beløp og valuta Tidspunkt Formål (for beløp over NOK 10 000) 5.2 Transaksjonovervåking 5.2.1 Automatisk overvåking Selskapet implementerer et automatisert transaksjonsovervåkingssystem som flagger: Regel Terskel Handling Enkelt-transaksjon over terskel > NOK 50 000 Manuell gjennomgang Kumulativt daglig volum > NOK 100 000 Manuell gjennomgang Kumulativt månedlig volum > NOK 500 000 EDD-vurdering Hyppige transaksjoner til høyrisikoland > 5/uke til samme korridor Manuell gjennomgang Splitting av transaksjoner Flere transaksjoner like under terskel Automatisk flagging Avvik fra kundeprofil > 200% av oppgitt bruksformål Manuell gjennomgang Round-trip-transaksjoner Penger sendt og mottatt fra samme korridor Automatisk flagging Uvanlig adferd Hurtig endring av mottakerland Manuell gjennomgang 5.2.2 Manuell gjennomgang Flaggede transaksjoner gjennomgås av compliance-teamet innen 24 timer Vurderingen dokumenteres med konklusjon og eventuell oppfølgingshandling Ved fortsatt mistanke: undersøkelsesplikt, jf. §26 5.3 Oppdatering av kundeinformasjon Lav risiko: Kundeinformasjon oppdateres hvert 3. år Middels risiko: Kundeinformasjon oppdateres årlig Høy risiko: Kundeinformasjon oppdateres hvert halvår Ved enhver transaksjon: Kontroll av at kundeinformasjon er oppdatert 6. Undersøkelsesplikt og rapportering — §26 6.1 Undersøkelsesplikt Når det foreligger forhold som gir grunnlag for mistanke om at en transaksjon har tilknytning til hvitvasking eller terrorfinansiering, skal Selskapet: Gjennomføre nærmere undersøkelser — innhente tilleggsinformasjon om kundens identitet, midlenes opprinnelse, transaksjonens formål Dokumentere undersøkelsen — alle funn, vurderinger og konklusjoner nedtegnes Konkludere — enten avkreftes mistanken (dokumenteres) eller bekreftes (rapportering) 6.2 Rapportering til Økokrim/EFE Dersom undersøkelsen ikke avkrefter mistanken: Rapport sendes til EFE (Enheten for finansiell etterretning) via Altinn-portalen Rapporten skal inneholde: Identifikasjon av kunden (navn, fødselsnummer, adresse) Beskrivelse av transaksjonen(e) Grunnlag for mistanken Resultater av undersøkelsen Relevant dokumentasjon Tidsfrist: Uten ugrunnet opphold etter at undersøkelsen er fullført Konfidensialitet: Kunden skal ikke underrettes om at rapport er sendt (tipping off-forbud, §28) Transaksjoner kan holdes tilbake i inntil 2 virkedager etter rapportering, jf. betalingssystemloven 6.3 Statistikk og oppfølging Antall flaggede transaksjoner per måned Antall undersøkelser gjennomført Antall rapporter sendt til EFE Rapporteres kvartalsvis til styret 7. Oppbevaringsplikt — §30 7.1 Lagringstid Alle opplysninger innhentet i forbindelse med kundetiltak og transaksjonsovervåking skal oppbevares i minst 5 år etter at kundeforholdet er avsluttet eller transaksjonen er gjennomført. 7.2 Hva oppbevares Datatype Lagringstid Format Kundidentifikasjon (KYC-data) 5 år etter avsluttet kundeforhold Kryptert database Kopi av legitimasjon/BankID-bekreftelse 5 år etter avsluttet kundeforhold Kryptert lagring Transaksjonsdata 5 år etter transaksjonsdato Database med revisjonsspor Korrespondanse med kunden 5 år etter avsluttet kundeforhold Kryptert lagring Risikovurderinger og EDD-dokumentasjon 5 år etter avsluttet kundeforhold Kryptert lagring Undersøkelser og rapporter til EFE 5 år etter avsluttet kundeforhold Kryptert lagring Opplæringslogg 5 år etter gjennomføring Intern database 7.3 Datasikkerhet All KYC- og transaksjonsdata krypteres ved lagring (AES-256) Tilgang logges og begrenses til autorisert personell GDPR/personopplysningsloven overholdes — personopplysninger slettes etter utløp av lovpålagt oppbevaringstid 8. Korridorbasert risikovurdering 8.1 Tilnærming Drop tilbyr pengeoverføringer til 30+ land. Risikoen varierer etter mottakerland/korridor. Selskapet benytter en risikobasert tilnærming der alle kunder vurderes etter samme rammeverk, uavhengig av etnisk bakgrunn eller statsborgerskap. Risikofaktoren er knyttet til transaksjonskorridoren (mottakerlandet), ikke kundens opprinnelse. 8.2 Korridorklassifisering Risikonivå Land/korridorer Grunnlag Lav EU/EØS-land (PLN, EUR), Storbritannia FATF-compliant, EU-regulerte Middels Serbia (RSD), Bosnia-Hercegovina (BAM), Tyrkia (TRY) Ikke EU, men MONEYVAL/FATF-prosesser pågår Høy Pakistan (PKR) FATF gråliste-historikk, høy korrupsjonsrisiko Svært høy / sperret Land på EUs høyrisikoliste eller FNs/EUs sanksjonslister EU-forordning, FN-resolusjon 8.3 Tiltak per korridorrisiko Korridorrisiko CDD Transaksjonsovervåking Tilleggstiltak Lav Standard Standard terskler Ingen Middels Standard + ekstra spørsmål om formål Lavere terskler (50% av standard) Kvartalsvis profil-oppdatering Høy EDD obligatorisk Halverte terskler, manuell review >NOK 25 000 Dokumentasjon av midlers opprinnelse, månedlig oppdatering Svært høy / sperret Avvises N/A Korridor blokkert i systemet 9. Roller og ansvar 9.1 Hvitvaskingsansvarlig Selskapet utpeker en hvitvaskingsansvarlig (AML Compliance Officer), jf. §8 fjerde ledd. Ansvar: Daglig oppfølging av hvitvaskingsrutinene Behandling av flaggede transaksjoner og EDD-saker Rapportering til EFE Årlig revisjon av risikovurdering og rutiner Opplæring av ansatte Rapportering til styret 9.2 Daglig leder Overordnet ansvar for etterlevelse av hvitvaskingsloven Godkjenner høyrisiko-kundeforhold Sikrer tilstrekkelige ressurser til compliance 9.3 Styret Godkjenner hvitvaskingsrutiner og risikovurdering Mottar kvartalsvis rapport fra hvitvaskingsansvarlig Beslutter risikoappetitt 9.4 Alle ansatte Plikter å følge disse rutinene Plikter å rapportere mistenkelige forhold til hvitvaskingsansvarlig Plikter å gjennomføre obligatorisk opplæring 10. Opplæring — §36 10.1 Obligatorisk opplæring Alle ansatte med kundetilgangs- eller transaksjonsrelaterte oppgaver skal gjennomføre opplæring i: Hvitvaskingsloven og forskrifter — grunnleggende forståelse Selskapets hvitvaskingsrutiner Gjenkjennelse av mistenkelige transaksjoner Rapporteringsprosedyrer PEP- og sanksjonsregler Roller og ansvar 10.2 Frekvens Ved ansettelse: Grunnkurs (innen 30 dager) Årlig: Oppdateringskurs med gjennomgang av endringer i lovverk og rutiner Ved vesentlige endringer: Ekstra opplæring ved nye produkter, korridorer eller regelverk 10.3 Dokumentasjon Opplæring registreres med dato, deltaker, innhold og beståttresultat Opplæringslogg oppbevares i 5 år 11. Internkontroll og revisjon — §37 11.1 Internkontroll Hvitvaskingsansvarlig utfører stikkprøvekontroller månedlig Minimum 10% av flaggede transaksjoner re-vurderes Kvaliteten på KYC-dokumentasjon kontrolleres kvartalsvis 11.2 Uavhengig gjennomgang Årlig uavhengig gjennomgang av hvitvaskingsrutinene Utføres av ekstern revisor eller compliance-rådgiver Funn rapporteres til styret med handlingsplan 11.3 Avviksbehandling Avvik fra rutinene dokumenteres umiddelbart Korrigerende tiltak iverksettes innen 30 dager Alvorlige avvik rapporteres til styret og eventuelt Finanstilsynet 12. Behandling av avviste eller avsluttede kundeforhold 12.1 Avvisning Dersom kundetiltak ikke kan gjennomføres tilfredsstillende, jf. §21: Kundeforholdet skal ikke etableres Eksisterende kundeforhold skal avsluttes Vurdering av om forholdet skal rapporteres til EFE 12.2 Avslutning av kundeforhold Kunden informeres om at kundeforholdet avsluttes (uten å oppgi HV/TF som grunn dersom rapport sendes) Eventuelle midler tilbakeføres til kundens opprinnelige bankkonto KYC-dokumentasjon oppbevares i 5 år etter avslutning 13. Tekniske tiltak 13.1 Automatiserte kontroller i Drop-appen BankID-verifisering ved registrering (alderskontroll, identifikasjon) Automatisk PEP- og sanksjonsscreening ved onboarding og ved transaksjoner Regelbasert transaksjonsovervåking med konfigurbare terskler Automatisk blokkering av transaksjoner til sanksjonerte land/personer Logging av alle transaksjoner med fullstendig revisjonsspor 13.2 Manuelt dashboard Compliance-dashboard for hvitvaskingsansvarlig Oversikt over flaggede transaksjoner, ventende EDD-saker, rapporterte saker Søkefunksjon i transaksjonshistorikk 14. Forholdet til personopplysningsloven (GDPR) 14.1 Behandlingsgrunnlag KYC-data behandles med hjemmel i rettslig forpliktelse (GDPR art. 6(1)(c)), jf. hvitvaskingsloven Oppbevaringstiden på 5 år har hjemmel i hvitvaskingsloven §30 Etter utløp av oppbevaringstiden slettes personopplysningene 14.2 Personvernserklæring Kundene informeres om behandling av personopplysninger i forbindelse med hvitvaskingslovens krav Informasjon gis i personvernerklæring og ved registrering 15. Endringslogg Versjon Dato Endring Godkjent av 1.0 2026-02-12 Førstegangs utarbeidelse Daglig leder 16. Vedlegg Vedlegg A: Risikovurdering — risikovurdering-hvitvasking.md Vedlegg B: Internkontrollrutiner — internkontroll.md Vedlegg C: EFE-rapporteringsskjema (Altinn-mal) Vedlegg D: Sjekkliste for kundetiltak Vedlegg E: Opplæringsplan Dokumentet er utarbeidet i henhold til hvitvaskingsloven (LOV-2018-06-01-23) med tilhørende forskrift, Finanstilsynets veiledning om tiltak mot hvitvasking og terrorfinansiering, og FATFs anbefalinger. AML Risk Assessment Risikovurdering — Hvitvasking og terrorfinansiering Dokument: Virksomhetsinnrettet risikovurdering, jf. hvitvaskingsloven §6 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 Godkjent av: Styre Neste revisjon: 2027-02-12 1. Innledning 1.1 Formål Denne risikovurderingen er utarbeidet i henhold til hvitvaskingsloven §6, som pålegger rapporteringspliktige å identifisere og vurdere risikoen for at virksomheten kan bli brukt til hvitvasking eller terrorfinansiering. Vurderingen danner grunnlaget for Selskapets risikobaserte tilnærming til kundetiltak og transaksjonsovervåking. 1.2 Metode Risikovurderingen er basert på: Nasjonal risikovurdering (NRA) utgitt av Justis- og beredskapsdepartementet Finanstilsynets veiledning til hvitvaskingsregelverket FATFs risikovurderingsmetodikk EUs overnasjonale risikovurdering (SNRA) Egne erfaringer og bransjeanalyse 1.3 Risikomatrise — vurderingsmetodikk Sannsynlighet: Nivå Beskrivelse 1 — Lav Lite sannsynlig at risikoen materialiserer seg 2 — Middels Kan forekomme i enkelte tilfeller 3 — Høy Sannsynlig at risikoen materialiserer seg jevnlig 4 — Svært høy Nærmest sikkert / har allerede forekommet Konsekvens: Nivå Beskrivelse 1 — Lav Begrenset økonomisk tap, ingen regulatorisk konsekvens 2 — Middels Moderat tap, mulig tilsynsreaksjon 3 — Høy Vesentlig tap, tilsynssanksjon, omdømmeskade 4 — Svært høy Konsesjonsinndragelse, straffeansvar Iboende risiko = Sannsynlighet x Konsekvens (uten tiltak) Restrisiko = Risiko etter implementerte tiltak 2. Virksomhetsbeskrivelse 2.1 Om Selskapet ALAI Holding AS utvikler og drifter betalingsapplikasjonen Drop, som tilbyr: Pengeoverføringer (remittance): Grensekryssende overføringer fra Norge til 30+ land QR-betalinger: Betalinger i butikk via QR-kode, tilgjengelig for alle merchanter 2.2 Forretningsmodell Pass-through-modell: Drop holder aldri kundemidler. Transaksjoner initieres via PSD2-grensesnitt (PISP/AISP) mot kundens egen norske bankkonto. Målgruppe: Alle innbyggere i Norge og Skandinavia som er 18+ med norsk BankID Autentisering: Norsk BankID (høyt sikkerhetsnivå) 2.3 Produkter og tjenester Tjeneste Beskrivelse Volum (forventet år 1) Remittance Overføring fra norsk bank til mottaker i utlandet ~36 000 transaksjoner QR-betaling Betaling i butikk via QR-kode ~120 000 transaksjoner Merchant onboarding Registrering av butikker for QR-mottak ~200 merchanter 3. Kundebasert risiko 3.1 Kundeprofil Drops kundebase består av alle innbyggere i Norge som ønsker å sende penger til utlandet eller betale i butikk. Kundene identifiseres og verifiseres gjennom norsk BankID. 3.2 Kunderisikofaktorer Risikofaktor Iboende risiko Mitigerende tiltak Restrisiko Stråmenn (muldyr) — kunder som utfører transaksjoner på vegne av andre 3 x 3 = 9 (Høy) BankID-verifisering, transaksjonsovervåking, adferdsmønster-analyse 2 x 3 = 6 (Middels) Kunder med høyt transaksjonsvolum — volumet overstiger oppgitt formål 2 x 3 = 6 (Middels) Automatisk flagging ved avvik fra profil, EDD ved >200% 1 x 3 = 3 (Lav) PEP-kunder — politisk eksponerte personer 1 x 4 = 4 (Middels) Automatisk PEP-screening ved onboarding og løpende, EDD 1 x 3 = 3 (Lav) Kunder som sender til mange ulike mottakere — indikasjon på pengeformidling 2 x 3 = 6 (Middels) Maks antall mottakere per periode, manuell review 1 x 3 = 3 (Lav) Kunder som sender til høyrisikoland — korridorbasert risiko 3 x 3 = 9 (Høy) EDD for høyrisikokorridorer, lavere terskler, dokumentasjon av formål 2 x 2 = 4 (Middels) Nye kunder med umiddelbart høyt volum — avvikende fra normalt mønster 2 x 3 = 6 (Middels) Gradvis volumøkning, automatisk flagging, EDD 1 x 3 = 3 (Lav) 3.3 Merchant-risikofaktorer Risikofaktor Iboende risiko Mitigerende tiltak Restrisiko Kontantintensive virksomheter — restauranter, kiosker, frisører 3 x 3 = 9 (Høy) Verifisering av org.nr mot Brønnøysundregistrene, transaksjonsovervåking, EDD 2 x 2 = 4 (Middels) Nyetablerte foretak — kort driftshistorikk 2 x 2 = 4 (Middels) Utvidet KYC ved registrering, hyppigere oppfølging 1 x 2 = 2 (Lav) Uvanlig transaksjonsmønster — refusjoner, splitting 2 x 3 = 6 (Middels) Automatisk overvåking av refusjonsandel og transaksjonsmønster 1 x 3 = 3 (Lav) 4. Geografisk risiko 4.1 Metodikk Geografisk risiko vurderes basert på: FATFs vurderinger (gråliste/svarteliste) EUs liste over høyrisikoland (delegert forordning) Transparency Internationals Corruption Perceptions Index (CPI) Nasjonal risikovurdering (NRA) Basel AML Index 4.2 Korridorklassifisering Korridor Land FATF-status CPI (2024) EU høyrisiko Risikonivå Tiltak NOK → EUR EU/EØS Compliant Varierer, generelt høy Nei Lav Standard CDD NOK → PLN Polen Compliant 54 Nei Lav Standard CDD NOK → GBP Storbritannia Compliant 71 Nei Lav Standard CDD NOK → RSD Serbia Under evaluering (MONEYVAL) 36 Nei Middels Standard CDD + formålsdokumentasjon NOK → BAM Bosnia-Hercegovina Under evaluering (MONEYVAL) 35 Nei Middels Standard CDD + formålsdokumentasjon NOK → TRY Tyrkia Under evaluering (FATF) 34 Nei (per 2025) Middels Standard CDD + formålsdokumentasjon NOK → PKR Pakistan Gråliste-historikk 24 Varierer Høy EDD obligatorisk NOK → sanksjonerte land Iran, Nord-Korea, etc. Svarteliste N/A Ja Sperret Blokkert i systemet 4.3 Geografisk risikovurdering — oppsummering Risikonivå Andel av forventet volum Tiltak Lav ~30% Standard CDD, standard overvåking Middels ~50% CDD + ekstra formålskontroll, lavere terskler Høy ~15% EDD, dokumentasjon av midlers opprinnelse, manuell review Sperret 0% Korridoren er blokkert 5. Produkt- og tjenestebasert risiko 5.1 Remittance (grensekryssende overføringer) Risikofaktor Iboende risiko Mitigerende tiltak Restrisiko Grensekryssende karakter — midler forlater norsk jurisdiksjon 3 x 3 = 9 (Høy) Korridorbasert risikotilnærming, BaaS-partner med egne kontroller 2 x 2 = 4 (Middels) Hastighet — rask gjennomføring vanskeliggjør intervensjon 2 x 3 = 6 (Middels) Pre-transaksjon sankssjonsscreening, automatisk hold ved flagging 1 x 3 = 3 (Lav) Tredjeparts mottaker — mottaker er ofte annen person 2 x 2 = 4 (Middels) Registrering av mottaker, begrensning av antall unike mottakere 1 x 2 = 2 (Lav) Smurfing/splitting — flere små transaksjoner for å unngå terskler 3 x 3 = 9 (Høy) Kumulativ overvåking (daglig, ukentlig, månedlig), mønstergjenkjenning 2 x 2 = 4 (Middels) 5.2 QR-betalinger (innenlandske) Risikofaktor Iboende risiko Mitigerende tiltak Restrisiko Lavere iboende risiko — innenlandsk, begge parter identifisert 1 x 2 = 2 (Lav) Standard CDD, transaksjonsovervåking 1 x 1 = 1 (Lav) Fiktive transaksjoner — oppkonstruerte transaksjoner mellom nærstående 2 x 2 = 4 (Middels) Overvåking av transaksjonsmønster, kontroll av merchant-legitimitet 1 x 2 = 2 (Lav) Refusjonssvindel — systematisk misbruk av refusjoner 1 x 2 = 2 (Lav) Automatisk overvåking av refusjonsandel per merchant 1 x 1 = 1 (Lav) 5.3 Samlet produktrisiko Produkt Iboende risikonivå Etter tiltak Remittance Høy Middels QR-betaling Lav Lav 6. Kanal- og leveringsrisiko 6.1 Digital onboarding Risikofaktor Iboende risiko Mitigerende tiltak Restrisiko Ikke-fysisk kontakt — kunden er aldri fysisk til stede 2 x 2 = 4 (Middels) BankID gir høyt identitetssikkerhetsnivå (eIDAS «høyt»), kompenserer for manglende fysisk oppmøte 1 x 2 = 2 (Lav) Identitetstyveri — noen bruker andres BankID 1 x 4 = 4 (Middels) BankID krever personlig kodebrikke/mobil, svært vanskelig å misbruke 1 x 3 = 3 (Lav) Mobilapp — enhet kan kompromitteres 1 x 2 = 2 (Lav) Enhetsautentisering, sesjonstokens, anomalideteksjon 1 x 1 = 1 (Lav) 6.2 Samlet kanalrisiko Digital kanal med BankID vurderes som lav restrisiko grunnet høyt identitetssikkerhetsnivå. 7. Terrorfinansieringsrisiko 7.1 Vurdering Nasjonal risikovurdering (NRA) identifiserer grensekryssende overføringer som en potensiell kanal for terrorfinansiering, særlig: Små beløp til høyrisikoområder (under rapporteringsterskler) Bruk av stråmenn/muldyr 7.2 Spesifikke risikofaktorer Risikofaktor Iboende risiko Mitigerende tiltak Restrisiko Overføringer til konfliktområder 3 x 4 = 12 (Svært høy) Blokkering av sanksjonerte land, EDD for naboland til konfliktområder, lavere overvåkingsterskler 2 x 3 = 6 (Middels) Mange små overføringer til samme region 2 x 3 = 6 (Middels) Kumulativ overvåking, mønstergjenkjenning 1 x 3 = 3 (Lav) Innsamlingsaksjoner via plattformen 1 x 4 = 4 (Middels) Drop tillater kun P2P-overføringer, ingen innsamlingsfunksjon 1 x 3 = 3 (Lav) 8. Samlet risikovurdering — risikomatrise 8.1 Overordnet risikobilde Risikokategori Iboende risiko Restrisiko (etter tiltak) Kundebasert risiko Middels-Høy Lav-Middels Geografisk risiko Høy Middels Produktrisiko (remittance) Høy Middels Produktrisiko (QR) Lav Lav Kanalrisiko Middels Lav Terrorfinansieringsrisiko Høy Middels Samlet virksomhetsrisiko Høy Middels 8.2 Visualisering RISIKOMATRISE (Restrisiko etter tiltak) Konsekvens → Lav(1) Middels(2) Høy(3) Svært høy(4) ────── ────────── ────── ──────────── Svært høy(4) │ │ │ │ Høy(3) │ │ GEOGRAFI │ │ │ │ TERROR │ │ Middels(2) │ KANAL │ KUNDE │ │ │ QR-prod │ REMITTANCE │ │ Lav(1) │ │ │ │ 8.3 Konklusjon Virksomhetens samlede restrisiko vurderes som middels etter implementering av tiltak beskrevet i dette dokumentet og i hvitvaskingsrutinene. De viktigste risikoreduserende faktorene er: BankID-verifisering — sikrer høyt identitetsnivå for alle kunder Pass-through-modell — Drop holder aldri kundemidler, noe som begrenser misbruksmuligheter Korridorbasert risikovurdering — differensierte tiltak etter mottakerland Automatisert transaksjonsovervåking — regelbasert overvåking med konfigurbare terskler 9. Handlingsplan 9.1 Tiltak som skal implementeres før lansering Nr Tiltak Ansvarlig Frist Status 1 Implementere PEP- og sanksjonsscreening (API-integrasjon) Tech Lead Før lansering Planlagt 2 Implementere automatisert transaksjonsovervåking Tech Lead Før lansering Planlagt 3 Etablere compliance-dashboard Tech Lead Før lansering Planlagt 4 Inngå avtale med PEP/sanksjons-dataleverandør Daglig leder Før lansering Planlagt 5 Gjennomføre opplæring av alle ansatte Hvitvaskingsansvarlig Før lansering Planlagt 6 Registrere rapporteringskanal hos Altinn/EFE Hvitvaskingsansvarlig Før lansering Planlagt 7 Etablere rutine for korridorblokkering Tech Lead Før lansering Planlagt 9.2 Løpende tiltak Tiltak Frekvens Ansvarlig Oppdatering av risikovurdering Årlig + ved vesentlige endringer Hvitvaskingsansvarlig Oppdatering av korridorklassifisering Kvartalsvis Hvitvaskingsansvarlig Re-screening mot PEP/sanksjonslister Løpende (automatisk) System Gjennomgang av transaksjonsovervåkingsregler Halvårlig Hvitvaskingsansvarlig Rapport til styret Kvartalsvis Hvitvaskingsansvarlig Ekstern revisjon av AML-program Årlig Ekstern revisor 10. Endringslogg Versjon Dato Endring Godkjent av 1.0 2026-02-12 Førstegangs utarbeidelse Styre Dokumentet er utarbeidet i henhold til hvitvaskingsloven §6 og Finanstilsynets veiledning om virksomhetsinnrettet risikovurdering. Risikovurderingen skal gjennomgås og oppdateres minst årlig. Suitability Assessment Egnethetsvurdering — Fit & Proper Dokument: Rutiner for egnethetsvurdering av styre, ledelse og nøkkelpersoner Hjemmel: Finansforetaksloven §§3-5 til 3-7 (LOV-2015-04-10-17) Virksomhet: ALAI Holding AS, org.nr 932 516 136 Produkt: Drop — betalingsformidling og pengeoverføringer Versjon: 1.0 Dato: 2026-02-12 Godkjent av: Styre Neste revisjon: 2027-02-12 1. Formål Denne rutinen beskriver Selskapets prosess for vurdering av egnethet («fit & proper») for personer som innehar eller skal inntre i ledende stillinger, styreverv eller andre nøkkelroller i virksomheten. Egnethetsvurderingen sikrer at Selskapet oppfyller kravene i finansforetaksloven og Finanstilsynets retningslinjer. 2. Lovgrunnlag 2.1 Relevante bestemmelser Bestemmelse Innhold Finansforetaksloven §3-5 Krav til egnethet for styre og ledelse Finansforetaksloven §3-6 Plikt til å melde fra om endringer Finansforetaksloven §3-7 Finanstilsynets myndighet til å kreve fratredelse Hvitvaskingsloven §8 fjerde ledd Krav til hvitvaskingsansvarlig EBA/ESMA Guidelines on suitability Europeiske retningslinjer for egnethetsvurdering Finanstilsynets rundskriv Veiledning om egnethetsvurdering 2.2 Hvem vurderes Egnethetsvurdering skal gjennomføres for: Styremedlemmer (inkludert styreleder og varamedlemmer) Daglig leder Faktisk leder (dersom annen enn daglig leder) Hvitvaskingsansvarlig Leder for compliance-funksjon Leder for IT/teknologi Andre personer med vesentlig innflytelse på virksomheten Eiere med kvalifisert eierandel (10% eller mer) 3. Egnethetskrav 3.1 Hederlig vandel og god forretningsførsel Krav Dokumentasjon Vurdering Ingen straffedommer for relevante lovbrudd Politiattest Absolutt krav — brudd diskvalifiserer Ingen konkurshistorikk (personlig) Konkursregisteret Vurderes individuelt Ingen tilsynssanksjoner Egenoppgave + bakgrunnssjekk Vurderes individuelt Ingen pågående etterforskning for økonomisk kriminalitet Egenoppgave Absolutt krav under etterforskning God forretningsførsel i tidligere roller Referanser Vurderes helhetlig 3.2 Kompetanse og erfaring 3.2.1 Styret samlet Styret skal samlet besitte kompetanse innen: Finansiell virksomhet og betalingstjenester Risikostyring og internkontroll Regulatorisk kunnskap (finansregulering, AML) IT og cybersikkerhet Forretningsutvikling og strategi Regnskaps- og revisjonsforståelse 3.2.2 Daglig leder Kompetanseområde Minimumskrav Ledererfaring Dokumentert ledererfaring fra relevant bransje Finansiell forståelse Kjennskap til regelverk for betalingsforetak Operasjonell kompetanse Erfaring med drift av digitale tjenester Regulatorisk kunnskap Grunnleggende forståelse av tilsynskrav 3.2.3 Hvitvaskingsansvarlig Kompetanseområde Minimumskrav AML-kompetanse Min. 3 års erfaring med AML/compliance Sertifisering CAMS eller tilsvarende (sterkt anbefalt) Regelverkskunnskap Inngående kjennskap til hvitvaskingsloven Rapporteringskompetanse Erfaring med EFE-rapportering 3.3 Kapasitet og tilgjengelighet Krav Beskrivelse Tilstrekkelig tid Personen må ha tilstrekkelig tid til å utføre vervet forsvarlig Antall verv Vurderes om antall øvrige verv/stillinger tillater tilstrekkelig engasjement Tilgjengelighet Må kunne delta på styremøter og være tilgjengelig ved behov 3.4 Uavhengighet og interessekonflikter Krav Vurdering Ingen vesentlige interessekonflikter Egenoppgave av alle verv, eierinteresser, nærståendes interesser Uavhengighet fra kontrollerte enheter Styremedlemmer bør ha tilstrekkelig uavhengighet Konkurrerende virksomhet Verv/interesser i konkurrerende foretak vurderes Nærstående Familiære og forretningsmessige forbindelser vurderes 4. Prosess for egnethetsvurdering 4.1 Ved nyansettelse / nytt verv STEG 1: KANDIDAT STEG 2: DOKUMENTASJON Identifisert av Kandidaten fremlegger: styre/valgkomité - CV - Egenoppgave (vedlegg A) - Politiattest - Referanser STEG 3: VURDERING STEG 4: BESLUTNING Compliance gjennomfører: Styret beslutter: - Bakgrunnssjekk - Godkjent - PEP/sanksjonsscreening - Betinget godkjent - Referansesjekk - Avvist - Kompetansevurdering - Interessekonfliktvurdering STEG 5: MELDING STEG 6: OPPFØLGING Melding til Finanstilsynet Årlig fornyet vurdering innen 1 mnd (nye nøkkelpersoner) 4.2 Ved tiltredelse — sjekkliste Nr Kontrollpunkt Dokumentasjon Bekreftet 1 Fullstendig CV mottatt CV på fil ☐ 2 Egenoppgave utfylt (vedlegg A) Signert skjema ☐ 3 Politiattest innhentet (ikke eldre enn 3 mnd) Attest ☐ 4 Konkursregistersjekk gjennomført Utskrift ☐ 5 PEP/sanksjonsscreening gjennomført Screeningresultat ☐ 6 Referansesjekk gjennomført (min. 2 referanser) Notat ☐ 7 Interessekonfliktanalyse gjennomført Notat ☐ 8 Kompetansevurdering mot krav Notat ☐ 9 Samlet egnethetsvurdering dokumentert Rapport ☐ 10 Styrevedtak om godkjenning Protokoll ☐ 11 Melding til Finanstilsynet sendt Kvittering ☐ 4.3 Løpende egnethetsvurdering Aktivitet Frekvens Ansvarlig Fornyet PEP/sanksjonsscreening Årlig Compliance Oppdatering av interessekonfliktvurdering Årlig Compliance Gjennomgang av vervliste og kapasitet Årlig Styreleder Sjekk mot konkursregister Årlig Compliance Samlet fornyet egnethetsvurdering Årlig Compliance → Styre 4.4 Ved endrede forhold Nøkkelpersoner plikter å melde fra om endringer som kan påvirke egnethetsvurderingen, herunder: Nye straffedommer eller igangsatt etterforskning Konkurs eller gjeldsforhandlinger Nye verv eller eierinteresser som kan medføre interessekonflikt Endringer i tilgjengelighet/kapasitet Tilsynssanksjoner i andre foretak 5. Styrets samlede kompetanse 5.1 Kompetansematrise Kompetanseområde Styreled. Medlem 1 Medlem 2 Samlet Finansiell virksomhet ☐ ☐ ☐ Minimum 1 Betalingstjenester / fintech ☐ ☐ ☐ Minimum 1 Risikostyring / compliance ☐ ☐ ☐ Minimum 1 IT / cybersikkerhet ☐ ☐ ☐ Minimum 1 Regnskap / revisjon ☐ ☐ ☐ Minimum 1 Forretningsutvikling ☐ ☐ ☐ Minimum 1 Juridisk kompetanse ☐ ☐ ☐ Ønskelig 5.2 Mangfold Styret skal tilstrebe mangfold med hensyn til: Kjønn Alder Faglig bakgrunn Yrkeserfaring Geografisk tilknytning 6. Eiere med kvalifisert eierandel 6.1 Krav Eiere med kvalifisert eierandel (10% eller mer) skal egnethetsvurderes, jf. finansforetaksloven §6-3. 6.2 Vurderingskriterier for eiere Krav Dokumentasjon Hederlig vandel Politiattest Finansiell soliditet Revisorbekreftet kapital / årsregnskap Ingen tilknytning til kriminell virksomhet Egenoppgave + bakgrunnssjekk Midlenes opprinnelse Dokumentasjon av investeringsmidler Ikke sanksjonert Sanksjonsscreening 6.3 Meldeplikt Erverv av kvalifisert eierandel skal meldes til Finanstilsynet før gjennomføring, jf. finansforetaksloven §6-1. 7. Dokumentasjon og oppbevaring 7.1 Dokumentasjonskrav For hver person som underlegges egnethetsvurdering skal følgende oppbevares: Utfylt egenoppgave (vedlegg A) CV Politiattest Resultat av PEP/sanksjonsscreening Referansenotater Kompetansevurdering Interessekonfliktvurdering Samlet egnethetsvurdering med konklusjon Styrevedtak 7.2 Oppbevaringstid Dokumentasjon oppbevares i hele perioden personen innehar vervet/stillingen Etter fratreden: oppbevares i 5 år Avviste kandidater: dokumentasjon oppbevares i 3 år 8. Vedlegg A — Egenoppgave for egnethetsvurdering Skjema: Egenoppgave Del 1 — Personopplysninger Felt Verdi Fullt navn Fødselsdato Fødselsnummer Adresse Telefon E-post Stilling/verv det søkes om Del 2 — Utdanning og yrkeserfaring Periode Institusjon/Arbeidsgiver Utdanning/Stilling Beskrivelse Del 3 — Øvrige verv og engasjementer Virksomhet Org.nr Verv/Rolle Eierandel Siden Del 4 — Erklæringer Undertegnede bekrefter at: Nr Erklæring Ja Nei 1 Jeg har ikke vært straffet for forbrytelse eller forseelse ☐ ☐ 2 Jeg er ikke under etterforskning for økonomisk kriminalitet ☐ ☐ 3 Jeg har ikke vært gjenstand for konkurs eller gjeldsforhandling ☐ ☐ 4 Jeg har ikke vært gjenstand for tilsynssanksjoner ☐ ☐ 5 Jeg har ikke blitt nektet konsesjon/registrering hos finanstilsyn ☐ ☐ 6 Jeg har ikke blitt fjernet fra styre/ledelse av tilsynsmyndighet ☐ ☐ 7 Jeg har ingen interessekonflikter knyttet til stillingen/vervet ☐ ☐ 8 Jeg har tilstrekkelig tid og kapasitet til å utføre vervet ☐ ☐ Dersom «Nei» er avkrysset på noen av punktene, gi utfyllende forklaring: Del 5 — Samtykke Undertegnede samtykker til at ALAI Holding AS kan: Innhente politiattest Gjennomføre PEP- og sanksjonsscreening Kontakte oppgitte referanser Foreta bakgrunnssjekk i relevante registre Underskrift: Sted: _________________ Dato: _________________ Signatur: _________________________________ Navn i blokkbokstaver: _________________________________ 9. Vedlegg B — Mal for samlet egnethetsvurdering Kandidat: [Navn] Stilling/verv: [Rolle] Dato for vurdering: [Dato] Vurderingskriterie Vurdering Kommentar Hederlig vandel Godkjent / Ikke godkjent Relevant kompetanse Tilstrekkelig / Utilstrekkelig Yrkeserfaring Tilstrekkelig / Utilstrekkelig Kapasitet og tilgjengelighet Tilstrekkelig / Utilstrekkelig Interessekonflikter Ingen / Håndterbare / Diskvalifiserende PEP/sanksjons-screening Ingen treff / Treff (beskriv) Referanser Positive / Nøytrale / Negative Samlet vurdering: Godkjent / Betinget godkjent / Ikke godkjent Begrunnelse: Vurdert av: _________________ Dato: _________________ Styrevedtak (ref.): _________________ 10. Endringslogg Versjon Dato Endring Godkjent av 1.0 2026-02-12 Førstegangs utarbeidelse Styre Dokumentet er utarbeidet i henhold til finansforetaksloven §§3-5 til 3-7, EBA/ESMA-retningslinjer for egnethetsvurdering, og Finanstilsynets veiledning. Data Processing Agreements DPA Template Data Processing Agreement (DPA) Between: Data Controller: ALAI Holding AS, Org. No. 932 516 136 ("Controller") Data Processor: [PROCESSOR NAME], [Org. No.] ("Processor") Effective Date: [DATE] Product: Drop payment services (getdrop.no) 1. Background and Purpose 1.1. This Data Processing Agreement ("DPA") is entered into pursuant to Article 28 of the General Data Protection Regulation (EU) 2016/679 ("GDPR") and the Norwegian Personal Data Act (LOV-2018-06-15-38). 1.2. The DPA governs the Processor's processing of personal data on behalf of the Controller in connection with the services described in Appendix 1. 1.3. This DPA is an integral part of the main service agreement between the parties dated [DATE] ("Main Agreement"). 2. Definitions Terms used in this DPA shall have the same meaning as defined in GDPR Article 4, unless otherwise specified. 3. Scope of Processing 3.1. The Processor shall only process personal data on behalf of the Controller and in accordance with the Controller's documented instructions (Appendix 1). 3.2. The scope, nature, purpose, and duration of processing, as well as categories of data subjects and types of personal data, are specified in Appendix 1. 3.3. The Processor shall not process personal data for its own purposes or for purposes beyond the scope of this DPA. 4. Controller's Obligations 4.1. The Controller is responsible for ensuring that there is a lawful basis for the processing of personal data under this DPA. 4.2. The Controller shall provide documented instructions for the processing of personal data. If the Processor believes that an instruction infringes GDPR or other data protection provisions, the Processor shall immediately inform the Controller. 5. Processor's Obligations 5.1. The Processor shall: (a) Process personal data only on documented instructions from the Controller, including with regard to transfers to third countries, unless required by EU or Member State law; (b) Ensure that persons authorized to process personal data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality; (c) Take all measures required pursuant to GDPR Article 32 (security of processing); (d) Respect the conditions for engaging sub-processors as set out in Section 7; (e) Assist the Controller in fulfilling its obligation to respond to data subject rights requests (GDPR Articles 15-22); (f) Assist the Controller in ensuring compliance with GDPR Articles 32-36; (g) At the choice of the Controller, delete or return all personal data after the end of the provision of services, and delete existing copies unless EU or Member State law requires storage; (h) Make available to the Controller all information necessary to demonstrate compliance with Article 28, and allow for and contribute to audits. 6. Security Measures 6.1. The Processor shall implement appropriate technical and organizational security measures in accordance with GDPR Article 32, including: (a) Pseudonymization and encryption of personal data; (b) Ensuring ongoing confidentiality, integrity, availability, and resilience of processing systems; (c) Ability to restore availability and access to personal data in a timely manner after an incident; (d) Regular testing and evaluation of the effectiveness of security measures. 6.2. Specific security measures are described in Appendix 2. 7. Sub-processors 7.1. The Controller provides general authorization for the Processor to engage sub-processors, subject to the conditions in this section. 7.2. The Processor shall maintain an up-to-date list of sub-processors available to the Controller upon request. 7.3. The Processor shall inform the Controller of intended changes concerning sub-processors at least 30 days in advance. 7.4. Sub-processors shall be bound by the same data protection obligations as set out in this DPA. 7.5. The Processor remains fully liable for sub-processor performance. 8. International Transfers 8.1. The Processor shall not transfer personal data outside the EEA without prior written consent. 8.2. Approved transfers shall be subject to appropriate safeguards (SCCs, adequacy decisions, or other GDPR Chapter V mechanisms). 9. Data Breach Notification 9.1. The Processor shall notify the Controller without undue delay (within 24 hours maximum) after becoming aware of a personal data breach. 9.2. The notification shall include: nature of breach, categories and number of records affected, likely consequences, and measures taken. 9.3. The Processor shall cooperate in investigating and resolving the breach. 10. Audit Rights 10.1. The Controller or its designated auditor may conduct audits of the Processor's compliance with this DPA. 10.2. Audits during normal business hours with minimum 14 days notice, unless triggered by a breach or regulatory investigation. 11. Duration and Termination 11.1. This DPA remains in effect for the duration of the Main Agreement. 11.2. Upon termination, the Processor shall delete or return all personal data within 30 days and certify deletion in writing. 12. Governing Law 12.1. This DPA is governed by Norwegian law. Appendix 1 — Processing Details Field Description Purpose [Describe the specific service] Nature [Collection, storage, analysis, etc.] Duration Duration of Main Agreement Data subjects [End users, merchants, etc.] Data types [Name, email, transaction data, etc.] Special categories None (unless specified) Appendix 2 — Security Measures Encryption: [e.g., TLS 1.3 in transit, AES-256 at rest] Access Control: [e.g., RBAC, MFA, least privilege] Logging: [e.g., audit logging for all data access] Backup: [e.g., daily encrypted backups] Incident Response: [e.g., documented plan] Certifications: [e.g., SOC 2 Type II, ISO 27001] Signatures Data Controller — ALAI Holding AS Name: ___________________________ Title: ___________________________ Date: ___________________________ Data Processor — [PROCESSOR NAME] Name: ___________________________ Title: ___________________________ Date: ___________________________ DPA — Swan Data Processing Agreement — Swan Between: Data Controller: ALAI Holding AS, Org. No. 932 516 136 ("Controller") Data Processor: Swan SAS ("Processor") Effective Date: [DATE] Product: Drop payment services — Banking-as-a-Service (BaaS) This DPA supplements the generic DPA template ( dpa-template.md ) with Swan-specific processing details. All general terms from the template apply unless overridden below. Appendix 1 — Processing Details Field Description Purpose Banking infrastructure for Drop: account management, payment initiation (PISP), account information (AISP), transaction processing, and regulatory reporting via Swan's BaaS platform Nature Collection, storage, processing, and transmission of financial and identity data for payment services Duration Duration of BaaS service agreement between Controller and Swan Data subjects Drop end users (account holders), payment recipients, merchants accepting QR payments Data types Full name, IBAN/account number, bank name, transaction data (amount, currency, timestamp, reference), exchange rates, payment status, balance information, payment initiation requests, beneficiary details for remittance Special categories None Appendix 2 — Security Measures (Swan) Encryption: TLS 1.3 in transit; AES-256 at rest; HSM for cryptographic key management Access Control: RBAC with MFA, segregation of duties, principle of least privilege Data Residency: EU data centers (France) — all data processed within EEA Logging: Complete audit trail for all financial transactions and API access Data Retention: Transaction data retained per Controller instructions (aligned with bokfoeringsloven 5-year requirement); account data retained during relationship + regulatory period Incident Response: 24/7 security operations, breach notification within 24 hours Certifications: PCI DSS Level 1, licensed by ACPR (French banking regulator), PSD2 compliant Financial Regulations: Compliant with PSD2, EMD2, and applicable French/EU banking regulations Additional Swan-Specific Terms Regulatory Compliance Swan operates as a licensed payment institution under French law, supervised by ACPR Processing of payment data complies with PSD2 requirements for strong customer authentication (SCA) Transaction data available for regulatory reporting to Norwegian authorities (Finanstilsynet) upon Controller's request Payment Data All payment initiation and account information services comply with PSD2 PISP/AISP requirements Transaction data includes full audit trail with timestamps, amounts, currencies, and counterparty information Idempotency controls prevent duplicate transactions Data Subject Rights Swan shall assist Controller in responding to data subject requests within 10 business days Account data and transaction history exportable in machine-readable format (JSON/CSV) Data erasure subject to regulatory retention requirements (minimum 5 years for financial records) Business Continuity Redundant infrastructure with 99.9% uptime SLA Regular disaster recovery testing Data backup with point-in-time recovery capability Signatures Data Controller — ALAI Holding AS Name: ___________________________ Title: ___________________________ Date: ___________________________ Data Processor — Swan SAS Name: ___________________________ Title: ___________________________ Date: ___________________________ DPA — Sumsub Data Processing Agreement — Sumsub Between: Data Controller: ALAI Holding AS, Org. No. 932 516 136 ("Controller") Data Processor: Sumsub Limited ("Processor") Effective Date: [DATE] Product: Drop payment services — KYC/Identity Verification This DPA supplements the generic DPA template ( dpa-template.md ) with Sumsub-specific processing details. All general terms from the template apply unless overridden below. Appendix 1 — Processing Details Field Description Purpose Identity verification (KYC/CDD) for Drop users, including document verification, liveness checks, PEP screening, and sanctions list checks in accordance with Norwegian AML legislation (hvitvaskingsloven) Nature Collection, verification, storage, and analysis of identity documents and biometric data Duration Duration of service agreement between Controller and Sumsub Data subjects Drop end users (natural persons in Norway applying for or holding Drop accounts) Data types Full name, date of birth, national ID number (encrypted), nationality, identity document images (passport/ID card), selfie/liveness capture, PEP screening results, sanctions check results, risk score, verification status Special categories Biometric data for identity verification (GDPR Art. 9(2)(g) — substantial public interest: AML obligations) Appendix 2 — Security Measures (Sumsub) Encryption: TLS 1.3 in transit; AES-256 at rest for all stored documents and data Access Control: Role-based access, MFA for all staff, principle of least privilege Data Residency: EU data centers (primary processing within EEA) Logging: Comprehensive audit trail for all verification events and data access Data Retention: Verification data retained for the period specified by Controller (aligned with hvitvaskingsloven 5-year requirement), then securely deleted Incident Response: 24/7 security operations, breach notification within 24 hours Certifications: SOC 2 Type II, ISO 27001, PCI DSS compliant Sub-processors: List maintained and available at Sumsub's sub-processor page; 30-day advance notice of changes Additional Sumsub-Specific Terms Biometric Data Biometric data (liveness/selfie) processed solely for identity verification purposes Not used for surveillance, profiling, or any purpose beyond KYC verification Deleted upon completion of verification cycle (not retained beyond verification outcome) Data Subject Rights Sumsub shall assist Controller in responding to data subject access, erasure, and portability requests within 10 business days Verification results and risk scores can be exported in machine-readable format Transfer Impact Assessment Primary processing: EU/EEA data centers Any processing outside EEA covered by EU SCCs (Decision 2021/914) TIA documentation available upon request Signatures Data Controller — ALAI Holding AS Name: ___________________________ Title: ___________________________ Date: ___________________________ Data Processor — Sumsub Limited Name: ___________________________ Title: ___________________________ Date: ___________________________ DPA — Sentry Data Processing Agreement — Sentry Between: Data Controller: ALAI Holding AS, Org. No. 932 516 136 ("Controller") Data Processor: Functional Software, Inc. dba Sentry ("Processor") Effective Date: [DATE] Product: Drop payment services — Error Monitoring and Performance This DPA supplements the generic DPA template ( dpa-template.md ) with Sentry-specific processing details. All general terms from the template apply unless overridden below. Appendix 1 — Processing Details Field Description Purpose Application error monitoring, crash reporting, and performance tracking for the Drop application to ensure service reliability and rapid incident response Nature Collection, storage, and analysis of error reports, stack traces, and performance metrics Duration Duration of Sentry subscription agreement Data subjects Drop end users (indirectly, via error context), Drop application developers and administrators Data types Error messages and stack traces, request URLs and HTTP headers (redacted), IP addresses (anonymizable), browser/device information, user agent strings, request IDs, breadcrumb events, performance traces (transaction timing) Special categories None — financial data and PII are scrubbed before transmission to Sentry (see Data Scrubbing section) Appendix 2 — Security Measures (Sentry) Encryption: TLS 1.3 in transit; AES-256 at rest Access Control: SSO/SAML, RBAC, MFA enforcement, IP allowlisting available Data Residency: EU data region available (selected for Drop); data stored in EU Logging: Access audit logs available via Sentry dashboard Data Retention: Configurable retention (Controller sets to 90 days for error data); automatically purged after retention period Incident Response: Sentry security incident response per SOC 2 procedures Certifications: SOC 2 Type II Privacy: Sentry does not sell or share customer data; processes data solely per Controller instructions Additional Sentry-Specific Terms Data Scrubbing (Controller Responsibility) The Controller implements the following data scrubbing measures BEFORE data is transmitted to Sentry: PII Filtering: All user names, email addresses, phone numbers, and national ID numbers are stripped from error payloads using Sentry SDK's beforeSend hook Financial Data: Transaction amounts, account numbers, IBANs, and card numbers are never included in error reports IP Anonymization: IP addresses are anonymized (last octet zeroed) via Sentry SDK configuration Request Body Filtering: POST bodies containing financial or personal data are excluded from error reports Custom Scrubbing Rules: Sentry's server-side data scrubbing enabled for additional patterns (credit card, SSN) Data Minimization Only error context necessary for debugging is transmitted User ID may be included for error correlation (pseudonymized identifier only) Request ID (correlation ID) included for log cross-referencing No financial transaction details, KYC data, or AML data transmitted to Sentry Data Subject Rights Since data transmitted to Sentry is scrubbed of direct identifiers, data subject requests are primarily handled by the Controller If pseudonymized user IDs need to be purged, Controller can use Sentry's data deletion API Sentry supports GDPR data deletion requests via their API Spike Protection Sentry spike protection prevents excessive data collection during error storms Controller configures rate limits to prevent inadvertent data over-collection Signatures Data Controller — ALAI Holding AS Name: ___________________________ Title: ___________________________ Date: ___________________________ Data Processor — Functional Software, Inc. dba Sentry Name: ___________________________ Title: ___________________________ Date: ___________________________ Policies & Internal Controls ICT Security Policy IKT-sikkerhetspolicy — Drop Dokument-ID: IKT-SEC-DROP-001 Versjon: 1.0 Dato: 12. februar 2026 Eier: ALAI Holding AS, org.nr. 932 516 136 Klassifisering: Intern Gjelder for: Alle systemer, ansatte og leverandører tilknyttet Drop-tjenesten Regulatorisk grunnlag: DORA (EU) 2022/2554, IKT-forskriften, GDPR 1. Innledning 1.1 Formål Denne policyen etablerer rammeverket for IKT-sikkerhet i Drop-tjenesten. Policyen sikrer at ALAI Holding AS oppfyller kravene i Digital Operational Resilience Act (DORA), forordning (EU) 2022/2554, samt Finanstilsynets IKT-forskrift og øvrig relevant regulering. 1.2 Virkeområde Policyen gjelder for: Alle IKT-systemer som understøtter Drop-tjenesten Alle ansatte, konsulenter og tredjepartsleverandører med tilgang til Drop-systemer All behandling av data i Drop-tjenestens infrastruktur Open Banking-integrasjoner (PSD2 PISP/AISP) BankID-integrasjon 1.3 Regulatorisk bakgrunn Regulering Relevante artikler Beskrivelse DORA (EU) 2022/2554 Art. 5-16 IKT-risikostyring DORA (EU) 2022/2554 Art. 17-23 IKT-relaterte hendelser DORA (EU) 2022/2554 Art. 24-27 Digital operasjonell resiliens-testing DORA (EU) 2022/2554 Art. 28-30 IKT-tredjepartsrisiko GDPR (EU) 2016/679 Art. 32 Sikkerhet ved behandling IKT-forskriften Hele Finanstilsynets krav til IKT PSD2 (EU) 2015/2366 Art. 95-98 Sikkerhet ved betalingstjenester 2. IKT-styring og organisering — DORA art. 5 2.1 Ledelsesansvar Selskapets ledelse har det overordnede ansvaret for IKT-risikostyring, jf. DORA artikkel 5(2). Dette innebærer: Godkjenning av IKT-sikkerhetspolicy og vesentlige endringer Allokering av tilstrekkelige ressurser til IKT-sikkerhet Regelmessig gjennomgang av IKT-risikostatus (minimum kvartalsvis) Gjennomføring av opplæring i IKT-sikkerhet (minimum årlig) 2.2 Organisering Rolle Ansvar Daglig leder Overordnet ansvar for IKT-sikkerhet IKT-sikkerhetsansvarlig (CISO) Operativt ansvar for sikkerhetspolicy og -tiltak Personvernombud (DPO) Personvernrelatert IKT-sikkerhet Driftsteam Implementering og vedlikehold av sikkerhetstiltak Utviklingsteam Sikker utvikling (DevSecOps) 2.3 Rapportering Kvartalsvis IKT-sikkerhetsrapport til styret Umiddelbar eskalering av alvorlige hendelser til daglig leder Årlig risikovurdering presentert for styret 3. IKT-risikostyringsrammeverk — DORA art. 6 3.1 Rammeverk IKT-risikostyring følger et strukturert rammeverk basert på: Identifisere: Kartlegge IKT-eiendeler, trusler og sårbarheter Beskytte: Implementere tiltak for å redusere risiko Oppdage: Overvåke og detektere sikkerhetshendelser Reagere: Håndtere hendelser effektivt Gjenopprette: Gjenopprette normal drift etter hendelser 3.2 Risikovurdering Frekvens: Minimum årlig, samt ved vesentlige endringer Metodikk: Sannsynlighet × konsekvens (4×4-matrise) Omfang: Alle IKT-systemer, tredjepartsleverandører og prosesser Dokumentasjon: Risikoregister vedlikeholdes løpende 3.3 Risikoakseptkriterier Risikonivå Handling Lav (1-4) Aksepteres, overvåkes Middels (5-8) Tiltak planlegges innen 90 dager Høy (9-12) Tiltak implementeres innen 30 dager Kritisk (13-16) Umiddelbar handling, eskalering til ledelse 4. IKT-systemer og -eiendeler — DORA art. 7-8 4.1 Eiendelsregister Vi vedlikeholder et komplett register over alle IKT-eiendeler, jf. DORA artikkel 8, inkludert: Programvare og versjoner Maskinvare og infrastruktur Nettverkskomponenter Datalagre og databaser Tredjepartssystemer og -integrasjoner 4.2 Klassifisering Alle IKT-eiendeler klassifiseres etter kritikalitet: Klasse Beskrivelse Eksempler Kritisk Tjenesten fungerer ikke uten Betalingsmotor, BankID-integrasjon, database Viktig Vesentlig funksjonalitet påvirkes Kundeservicesystem, rapportering Standard Begrenset påvirkning ved utilgjengelighet Intern kommunikasjon, utviklingsmiljø 4.3 Konfigurasjons- og endringsstyring Alle endringer i produksjonsmiljøet gjennomgår formell endringsprosess Endringer risikovurderes og godkjennes før implementering Alle konfigurasjoner versjoneres og dokumenteres Rollback-plan kreves for alle endringer 5. Tilgangskontroll — DORA art. 9(4) 5.1 Tilgangsprinsipper Minste privilegium (Least Privilege): Brukere tildeles kun nødvendig tilgang Need-to-know: Tilgang til data begrenses basert på tjenstlig behov Rollebasert tilgangskontroll (RBAC): Tilgang styres gjennom definerte roller Segregering av oppgaver (SoD): Kritiske funksjoner fordeles på flere personer 5.2 Brukerkontoer Type Krav Standardbrukere Unik bruker-ID, MFA påkrevd Administratorer Egen admin-konto, MFA påkrevd, tidsbegrenset tilgang Systemkontoer Ingen interaktiv pålogging, API-nøkler med rotasjon Tredjeparter Tidsbegrenset tilgang, MFA påkrevd, godkjenning fra CISO 5.3 Multifaktorautentisering (MFA) MFA er påkrevd for: Alle administrative tilganger Tilgang til produksjonsdata VPN-tilkobling Koderepository og CI/CD-pipeline Skyinfrastrukturens administrasjonsgrensesnitt 5.4 Tilgangsgjennomgang Kvartalsvise gjennomganger av alle tilganger Umiddelbar deaktivering ved endret roller eller avsluttet arbeidsforhold Årlig resertifisering av alle privilegerte tilganger 6. Kryptering — DORA art. 9(4)(d) 6.1 Data i transitt Protokoll Minimumskrav Bruksområde TLS Versjon 1.3 (TLS 1.2 kun for legacy-integrasjoner) All ekstern kommunikasjon mTLS TLS 1.3 med gjensidig sertifikatautentisering Interservice-kommunikasjon HTTPS TLS 1.3 Web-API-er og brukergrensesnitt 6.2 Data i hvile Datakategori Krypteringsmetode Nøkkelhåndtering Personopplysninger AES-256-GCM HSM-beskyttede nøkler Fødselsnummer AES-256-GCM + applikasjonsnivå Separat nøkkelpar, HSM Transaksjonsdata AES-256-GCM HSM-beskyttede nøkler Logger AES-256-GCM Rotasjon hver 90. dag Sikkerhetskopier AES-256-GCM Offline nøkkelkopi i safe 6.3 Nøkkelhåndtering Nøkler genereres i Hardware Security Module (HSM) Nøkkelrotasjon minimum hver 12. måned (90 dager for logger) Separasjon av nøkler per miljø (utvikling, test, produksjon) Nøkler for kryptering av fødselsnummer håndteres separat Nødprosedyre for nøkkelkompromittering dokumentert 7. Applikasjonssikkerhet — OWASP 7.1 Sikker utviklingslivssyklus (SSDLC) Alle utviklingsaktiviteter følger en sikker utviklingslivssyklus: Kravfase: Sikkerhets- og personvernkrav defineres Design: Trusselmodellering (STRIDE) gjennomføres Implementering: Sikre kodestandarder, code review Testing: Sikkerhetstesting (SAST, DAST, avhengighetsskanning) Lansering: Penetrasjonstesting før produksjonssetting Drift: Løpende overvåking og sårbarhetshåndtering 7.2 OWASP Top 10 — tiltak OWASP-risiko Tiltak A01: Broken Access Control RBAC, autorisasjonskontroll på API-nivå, funksjonsnivåtesting A02: Cryptographic Failures TLS 1.3, AES-256, HSM, ingen hardkodede hemmeligheter A03: Injection Parametriserte SQL-spørringer, input-validering, ORM A04: Insecure Design Trusselmodellering, sikre designmønstre, minste privilegium A05: Security Misconfiguration Automatisert konfigurasjonskontroll, hardening, ingen standardpassord A06: Vulnerable Components Avhengighetsskanning (SCA), automatiserte oppdateringer, SBOM A07: Authentication Failures BankID (brukere), MFA (ansatte), kontosperring ved mislykkede forsøk A08: Software and Data Integrity Signerte builds, CI/CD-integritetskontroll, code review A09: Logging and Monitoring Failures Sentralisert logging, SIEM, varsling, revisjonslogger A10: Server-Side Request Forgery Input-validering, nettverkssegmentering, egress-filtrering 7.3 API-sikkerhet Gitt at Drop er en API-drevet tjeneste med Open Banking-integrasjoner: OAuth 2.0 / OpenID Connect for autentisering og autorisasjon Rate limiting per bruker og per IP Input-validering og schema-verifisering på alle endepunkter API-versjonering med deprekeringspolicy API-gateway med WAF-funksjonalitet 8. Nettverkssikkerhet 8.1 Nettverksarkitektur Segmentering: Produksjon, test og utvikling er fullstendig isolert DMZ: Offentlig tilgjengelige tjenester plasseres i DMZ Mikrosegmentering: Tjenester kommuniserer kun med autoriserte tjenester Egress-filtrering: Utgående trafikk begrenses til godkjente destinasjoner 8.2 Brannmur og filtrering Web Application Firewall (WAF) foran alle offentlige endepunkter Nettverksbrannmur med default-deny-policy IDS/IPS for deteksjon og forebygging av inntrengning DDoS-beskyttelse på infrastrukturnivå 8.3 Overvåking Sentralisert logginnsamling fra alle nettverkskomponenter Netflow-analyse for anomalideteksjon DNS-overvåking for ondsinnet trafikk 9. Hendelsesdeteksjon og -overvåking — DORA art. 10 9.1 Overvåkingssystem SIEM (Security Information and Event Management): Sentralisert hendelseskorrelasjon Logginnsamling: All IKT-aktivitet logges sentralt Automatisert varsling: Definerte terskelverdier for automatisk varsling Anomalideteksjon: Maskinlæring for identifisering av uvanlig atferd 9.2 Loggkrav Loggkategori Oppbevaringstid Beskyttelse Autentiseringslogger 12 måneder Kryptert, skrivebeskyttet Transaksjonslogger 5 år Kryptert, skrivebeskyttet Systemlogger 6 måneder Kryptert Sikkerhetslogger 24 måneder Kryptert, skrivebeskyttet Tilgangslogger 12 måneder Kryptert, skrivebeskyttet 9.3 Hendelsesrespons Se separat dokument: hendelseshaandtering.md for fullstendig hendelsesresponsplan. 10. Sårbarhetshåndtering — DORA art. 9(4)(e) 10.1 Sårbarhetsskanning Type Frekvens Omfang Automatisert skanning Daglig Alle produksjonssystemer Avhengighetsskanning (SCA) Ved hver build All kildekode Statisk kodeanalyse (SAST) Ved hver pull request All ny kode Dynamisk analyse (DAST) Ukentlig Alle offentlige endepunkter 10.2 Sårbarhetshåndtering Alvorlighetsgrad (CVSS) Frist for utbedring Kritisk (9.0-10.0) 24 timer Høy (7.0-8.9) 7 dager Middels (4.0-6.9) 30 dager Lav (0.1-3.9) 90 dager 10.3 Patchhåndtering Sikkerhetsoppdateringer vurderes og implementeres innenfor angitte frister Nødpatcher kan deployeres utenfor normal endringsprosess med etterfølgende godkjenning All programvare holdes oppdatert med siste stabile versjon End-of-life-programvare erstattes innen 6 måneder etter annonsering 11. Penetrasjonstesting — DORA art. 24-27 11.1 Testprogram Testtype Frekvens Gjennomfører Ekstern penetrasjonstest Årlig Uavhengig tredjepart Intern penetrasjonstest Årlig Uavhengig tredjepart Red team-øvelse Hvert 3. år (TLPT) Kvalifisert leverandør jf. DORA art. 26 Applikasjonssikkerhetstest Ved vesentlige endringer Intern/ekstern Social engineering-test Årlig Uavhengig tredjepart 11.2 TLPT (Threat-Led Penetration Testing) — DORA art. 26 I henhold til DORA artikkel 26 kan Finanstilsynet kreve at vi gjennomfører TLPT. Vi er forberedt på: Engasjement av kvalifisert TLPT-leverandør Scenariobasert testing basert på reelle trusseletterretninger Involvering av kritiske IKT-tredjepartsleverandører Rapportering til Finanstilsynet 11.3 Oppfølging av funn Alle funn logges i sårbarhetsstyringssystemet Funn prioriteres etter alvorlighetsgrad Utbedringsplan utarbeides innen 5 virkedager Retest gjennomføres etter utbedring Ledelsen informeres om kritiske funn umiddelbart 12. Sikkerhetskopier og gjenoppretting — DORA art. 12 12.1 Sikkerhetskopieringsstrategi Dataklasse Frekvens Oppbevaring Lokasjon Database (produksjon) Kontinuerlig (WAL) + daglig full 30 dager Geografisk adskilt, innenfor EØS Konfigurasjon Ved endring 90 dager Versjonskontroll + kryptert backup Logger Daglig Iht. loggpolicy Separat logginfrastruktur Krypteringsnøkler Ved endring Permanent Offline, i safe 12.2 Gjenopprettingstesting Frekvens: Minimum halvårlig Omfang: Fullstendig gjenoppretting av kritiske systemer Dokumentasjon: Testresultater dokumenteres og gjennomgås Forbedring: Funn fra testing fører til oppdatert prosedyre 12.3 RTO og RPO Se beredskapsplan.md for detaljerte RTO/RPO-krav per system. 13. Fysisk sikkerhet 13.1 Datasentre All infrastruktur er hostet i sertifiserte datasentre (minimum ISO 27001, SOC 2 Type II) Datasentre lokalisert innenfor EØS Redundant strømforsyning (UPS + dieselgenerator) Brannslukkingssystemer Adgangskontroll med biometri og logging 13.2 Utviklingsmiljø Produksjonsdata benyttes aldri i utviklings- eller testmiljøer Syntetiske testdata genereres for testing Utviklingsmaskiner har diskkryptering og MFA 14. Opplæring og bevissthet — DORA art. 13 14.1 Obligatorisk opplæring Målgruppe Innhold Frekvens Alle ansatte Generell IKT-sikkerhet, phishing, passord Årlig Utviklere Sikker koding, OWASP, code review Halvårlig Drift Hendelseshåndtering, herding, overvåking Halvårlig Ledelse IKT-risikostyring, regulatoriske krav Årlig 14.2 Phishing-simulering Kvartalsvise phishing-simuleringer for alle ansatte Individuelle resultater brukes til målrettet opplæring Resultater rapporteres til ledelsen (aggregert) 15. IKT-tredjepartsrisiko — DORA art. 28-30 15.1 Leverandørstyring Se separat dokument: utkontraktering-policy.md for detaljert leverandørstyringspolicy. 15.2 Kritiske IKT-leverandører Kritiske IKT-tredjepartsleverandører identifiseres og underlegges forsterkede krav, jf. DORA artikkel 28: Årlig risikovurdering Rett til revisjon og inspeksjon Exit-strategi og overgangsplan Rapportering av vesentlige hendelser Overholdelse av DORA-krav 16. Kontinuitetsplanlegging — DORA art. 11 Se separat dokument: beredskapsplan.md for detaljert kontinuitetsplan. Denne IKT-sikkerhetspolicyen understøtter kontinuitetsplanlegging ved å sikre: Høy tilgjengelighet gjennom redundans Rask gjenoppretting gjennom testede prosedyrer Begrenset konsekvens gjennom segmentering og isolasjon 17. Revisjon og oppdatering 17.1 Gjennomgang Årlig: Full gjennomgang av policyen Ved vesentlige endringer: Endringer i teknologi, tjenester eller regulering Etter hendelser: Relevant revisjon etter sikkerhetshendelser Etter penetrasjonstesting: Oppdatering basert på funn 17.2 Godkjenningsprosess Endring Godkjenner Redaksjonell CISO Vesentlig Daglig leder Prinsipiell Styret 17.3 Versjonshistorikk Versjon Dato Endring Godkjent av 1.0 12.02.2026 Opprinnelig dokument ____________ 18. Referanser DORA — Forordning (EU) 2022/2554 om digital operasjonell motstandsdyktighet GDPR — Forordning (EU) 2016/679 om personvern PSD2 — Direktiv (EU) 2015/2366 om betalingstjenester ISO 27001:2022 — Informasjonssikkerhetsstyring NIST Cybersecurity Framework 2.0 OWASP Top 10 (2021) Finanstilsynets IKT-forskrift Hvitvaskingsloven (LOV-2018-06-01-23) Denne IKT-sikkerhetspolicyen er eid av CISO og godkjent av styret i ALAI Holding AS. Internal Controls Internkontrollrutiner — Drop (ALAI Holding AS) Dokument: Rammeverk for internkontroll Hjemmel: Finansforetaksloven §13-5, hvitvaskingsloven §§7-8 og §37, internkontrollforskriften Virksomhet: ALAI Holding AS, org.nr 932 516 136 Produkt: Drop — betalingsformidling og pengeoverføringer Versjon: 1.0 Dato: 2026-02-12 Godkjent av: Styre Neste revisjon: 2027-02-12 1. Formål Internkontrollrutinene skal sikre at ALAI Holding AS gjennom produktet Drop: Overholder gjeldende lovverk, herunder finansforetaksloven, hvitvaskingsloven og personopplysningsloven Har effektiv risikostyring og kontroll med virksomheten Har klare ansvarslinjer og rapporteringsveier Identifiserer, vurderer og håndterer operasjonelle risikoer Har en kultur for etterlevelse (compliance) 2. Tre forsvarslinjer Selskapet organiserer sin internkontroll etter prinsippet om tre forsvarslinjer, jf. Finanstilsynets veiledning og internasjonale standarder (COSO/IIA): 2.1 Første forsvarslinje — Operativ drift Hvem: Alle ansatte i operative roller (utvikling, drift, kundeservice) Ansvar: Daglig etterlevelse av rutiner og policyer Identifisere og rapportere avvik til nærmeste leder Gjennomføre kontroller integrert i arbeidsprosesser Dokumentere egne kontrollhandlinger Kontrollaktiviteter: Kontroll Frekvens Ansvarlig KYC-kvalitetskontroll ved onboarding Hver kunde Operativ medarbeider Verifikasjon av transaksjonsdata Fortløpende System (automatisk) Rapportering av hendelser og avvik Ved forekomst Alle ansatte Oppfølging av automatiske varsler Fortløpende Operativ medarbeider 2.2 Andre forsvarslinje — Risikostyring og Compliance Hvem: Hvitvaskingsansvarlig / Compliance-funksjon Ansvar: Overvåke og teste etterlevelse av lover, forskrifter og interne rutiner Utarbeide og vedlikeholde policyer og rutiner Gjennomføre risikiovurderinger Rådgi første forsvarslinje Rapportere til daglig leder og styret Håndtere forholdet til tilsynsmyndigheter Kontrollaktiviteter: Kontroll Frekvens Ansvarlig Stikkprøvekontroll av KYC-dokumentasjon Månedlig (min. 10% av nye kunder) Hvitvaskingsansvarlig Gjennomgang av flaggede transaksjoner Ukentlig Hvitvaskingsansvarlig Testing av transaksjonsovervåkingsregler Kvartalsvis Compliance Oppdatering av risikovurdering Årlig + ved vesentlige endringer Hvitvaskingsansvarlig Regelverksovervåking Løpende Compliance Compliance-rapport til styret Kvartalsvis Hvitvaskingsansvarlig 2.3 Tredje forsvarslinje — Uavhengig kontroll Hvem: Ekstern revisor / Uavhengig internrevisor Ansvar: Uavhengig vurdering av internkontrollens effektivitet Vurdering av risikostyringsrammeverket Rapportering til styret Kontrollaktiviteter: Kontroll Frekvens Ansvarlig Ekstern revisjon av AML-program Årlig Ekstern revisor Revisjon av IT-sikkerhet Årlig Ekstern IT-revisor Uavhengig gjennomgang av internkontroll Årlig Ekstern revisor Rapportering av funn og anbefalinger Etter hver revisjon Ekstern revisor 3. Governance og organisering 3.1 Styret Ansvar: Fastsette overordnet strategi for risikostyring og internkontroll Godkjenne policyer, rutiner og risikoappetitt Motta og behandle kvartalsrapporter fra compliance og revisor Sikre tilstrekkelige ressurser til internkontroll Overordnet ansvar for etterlevelse Styreaktiviteter: Aktivitet Frekvens Behandle compliance-rapport Kvartalsvis Godkjenne oppdatert risikovurdering Årlig Godkjenne oppdaterte hvitvaskingsrutiner Årlig Behandle revisjonsrapporter Etter mottakelse Evaluere internkontrollens effektivitet Årlig 3.2 Daglig leder Ansvar: Operativt ansvar for implementering av styrets vedtak Sikre at organisasjonen har nødvendig kompetanse og ressurser Godkjenne høyrisiko-kundeforhold (etter anbefaling fra compliance) Rapportere til styret om vesentlige risikoforhold 3.3 Hvitvaskingsansvarlig / Chief Compliance Officer Ansvar: Daglig leder for compliance-funksjonen Hvitvaskingsansvarlig etter hvitvaskingsloven §8 fjerde ledd Rapporterer direkte til daglig leder og styret (uavhengig av operative linjer) Har myndighet til å stoppe transaksjoner og avvise kundeforhold 3.4 Organisasjonskart — internkontroll ┌─────────────────────────────────────────┐ │ STYRET │ │ Overordnet ansvar, godkjenner rammer │ └────────────────┬────────────────────────┘ │ ┌────────────┼─────────────────┐ │ │ │ ▼ ▼ ▼ ┌────────┐ ┌────────────┐ ┌──────────────┐ │DAGLIG │ │COMPLIANCE │ │EKSTERN │ │LEDER │ │FUNKSJON │ │REVISOR │ │ │ │(2. linje) │ │(3. linje) │ │Operativ│ │HVV-ansvarl.│ │Uavhengig │ │drift │ │Rapporterer │ │vurdering │ │ │ │til styre │ │ │ └───┬────┘ └────────────┘ └──────────────┘ │ ▼ ┌────────────────┐ │OPERATIVE │ │MEDARBEIDERE │ │(1. linje) │ │Tech, support, │ │kundeservice │ └────────────────┘ 4. Risikostyring 4.1 Risikorammeverk Selskapet identifiserer og vurderer følgende risikokategorier: Risikokategori Beskrivelse Eier HV/TF-risiko Risiko for misbruk til hvitvasking/terrorfinansiering Hvitvaskingsansvarlig Operasjonell risiko Systemfeil, menneskelige feil, prosesssvikt Daglig leder IT- og cyberrisiko Datainnbrudd, tjenestenekt, systemsårbarhet Tech Lead Compliance-risiko Brudd på regelverk, tilsynssanksjoner Compliance Omdømmerisiko Hendelser som skader selskapets omdømme Daglig leder Strategisk risiko Feil forretningsbeslutninger Styret 4.2 Risikovurderingsprosess Identifisering: Kartlegge relevante risikoer per kategori Vurdering: Sannsynlighet x konsekvens (skala 1-4) Tiltak: Definere risikoreduserende tiltak Overvåking: Løpende overvåking av risikoindikatorer Rapportering: Kvartalsvise risikorapporter til styret Revisjon: Årlig oppdatering av risikovurderingen 4.3 Risikoindikatorer (KRI) Indikator Terskel (gul) Terskel (rød) Frekvens Antall flaggede transaksjoner >50/mnd >100/mnd Månedlig Gjennomsnittlig behandlingstid flagg >48 timer >72 timer Ukentlig Andel EDD-kunder >10% av kundebasen >20% Kvartalsvis Antall EFE-rapporter >2/kvartal >5/kvartal Kvartalsvis KYC-mangler ved stikkprøve >5% >10% Månedlig Systemnedetid >99.5% oppetid <99% oppetid Daglig Antall sikkerhetshendelsar >1/mnd >3/mnd Månedlig 5. Compliance-overvåking 5.1 Overvåkingsplan Område Kontrollhandling Frekvens Ansvarlig Rapporteres til KYC/CDD Stikkprøve av onboarding-kvalitet Månedlig Compliance Daglig leder Transaksjonovervåking Review av regler og terskler Kvartalsvis Compliance Styret PEP/sanksjoner Test av screeningeffektivitet Halvårlig Compliance Styret Opplæring Kontroll av gjennomføring Årlig Compliance Daglig leder Rutiner Gjennomgang og oppdatering Årlig Compliance Styret Regelverksendringer Overvåking av nye krav Løpende Compliance Daglig leder Hendelseslog Gjennomgang av logger Ukentlig Compliance Daglig leder IT-sikkerhet Penetrasjonstesting Årlig Ekstern Styret Personvern DPIA-oppdatering Årlig Compliance Daglig leder 5.2 Rapporteringskalender Rapport Mottaker Frekvens Innhold Compliance-statusrapport Styret Kvartalsvis HV/TF-statistikk, avvik, tiltak, regelverksendringer Risikorapport Styret Kvartalsvis KRI-status, risikoendringer, handlingsplan AML-årsrapport Styret Årlig Full gjennomgang av AML-programmet Hendelsesrapport Daglig leder Ved hendelse Beskrivelse, tiltak, læringspunkter Revisjonsrapport Styret Årlig Ekstern revisors funn og anbefalinger 6. Avviksbehandling 6.1 Definisjon Et avvik er ethvert brudd på, eller manglende etterlevelse av: Lover og forskrifter Interne rutiner og policyer Styrets vedtak og retningslinjer Tilsynsmyndighetenes pålegg 6.2 Avviksprosess 1. IDENTIFISERING 2. REGISTRERING 3. VURDERING Alle ansatte → Avvikslogg → Compliance → rapporterer dokumenteres alvorlighetsgrad 4. TILTAK 5. OPPFØLGING 6. RAPPORTERING Korrigerende → Verifisere → Til styre/ tiltak defineres effekt tilsynsmyndighet 6.3 Alvorlighetsgrader Grad Beskrivelse Responstid Rapporteres til Kritisk Lovbrudd, tilsynssanksjon, stor kundeeksponering Umiddelbart Styre, Finanstilsynet Høy Vesentlig rutinebrudd, gjentatte avvik 24 timer Daglig leder, styre Middels Enkeltavvik fra rutiner, forbedringspotensial 1 uke Daglig leder Lav Mindre prosessavvik, ingen kundekonsekvens 30 dager Compliance-logg 6.4 Avvikslogg Alle avvik registreres i avviksloggen med: Dato og tidspunkt Beskrivelse av avviket Hvem som oppdaget det Alvorlighetsgrad Korrigerende tiltak Ansvarlig for oppfølging Frist for lukking Status (åpent/lukket) Læringspunkter 7. Eskalering 7.1 Eskaleringsprosedyre Situasjon Eskaleres til Tidsfrist Mistenkelig transaksjon (flagget av system) Hvitvaskingsansvarlig 24 timer Bekreftet mistanke om HV/TF EFE/Økokrim + daglig leder Uten ugrunnet opphold Sanksjonstreff (bekreftet) Daglig leder + UD Umiddelbart Kritisk avvik Styre + eventuelt Finanstilsynet Umiddelbart Sikkerhetshendeelse (datainnbrudd) Daglig leder + Datatilsynet (72t) Umiddelbart Tilsynsforespørsel Daglig leder + compliance Innen tilsynets frist Kundeklage (compliance-relatert) Compliance 5 virkedager 7.2 Varsling (Whistleblowing) Jf. arbeidsmiljøloven kapittel 2A: Alle ansatte har rett til å varsle om kritikkverdige forhold Varslingskanal er etablert (direkte til styreleder) Varsler beskyttes mot gjengjeldelse Alle varsler behandles konfidensielt og dokumenteres 8. IT-kontroller 8.1 Tilgangsstyring Prinsipp Implementering Minste privilegium Brukere får kun tilgang til det de trenger Rollebasert tilgang (RBAC) Tilgang basert på rolle, ikke person Separation of duties Kritiske funksjoner krever to personers godkjenning Periodisk tilgangsgjennomgang Kvartalsvis gjennomgang av alle tilganger Logging Alle tilgangsendringer og datautrekk logges 8.2 Systemovervåking Kontroll Beskrivelse Frekvens Oppetidsovervåking Automatisk varsling ved nedetid Kontinuerlig Ytelsesovervåking Responstider og feilrater Kontinuerlig Sikkerhetslogg-gjennomgang Analyse av innloggingsforsøk og anomalier Daglig Sårbarhetsskanning Automatisk skanning av kjente sårbarheter Ukentlig Penetrasjonstesting Ekstern testing av sikkerhet Årlig Backup-verifisering Test av gjenoppretting fra backup Månedlig 8.3 Endringsstyring Alle endringer i produksjonssystemer skal: Dokumenteres med beskrivelse og begrunnelse Testes i staging-miljø Godkjennes av tech lead og compliance (ved regelverksrelevante endringer) Rulles ut med rollback-plan Overvåkes etter utrulling 9. Opplæring og kompetanse 9.1 Opplæringsprogram Kurs Målgruppe Frekvens Innhold Grunnkurs HV/TF Alle ansatte Ved ansettelse + årlig Lovverk, rutiner, gjenkjennelse Avansert AML Compliance, operativ Årlig Typologier, caseøvelser, EDD PEP og sanksjoner Compliance, operativ Årlig PEP-definisjoner, screeningprosess IT-sikkerhet Alle ansatte Årlig Phishing, passord, hendelsesrapportering GDPR Alle ansatte Ved ansettelse + årlig Personvern, behandlingsgrunnlag Etikk og varsling Alle ansatte Årlig Etiske retningslinjer, varslingskanal 9.2 Kompetansekrav Rolle Minimumskompetanse Hvitvaskingsansvarlig Sertifisering (f.eks. CAMS), min. 3 års erfaring Compliance-medarbeider Relevant utdanning, opplæring i HV/TF Daglig leder Egnethetsvurdering, grunnleggende HV/TF-forståelse Styremedlemmer Egnethetsvurdering, forstå regulatorisk rammeverk Tech Lead IT-sikkerhetskompetanse, forståelse av compliance-krav 10. Beredskapsplan 10.1 Scenarioer Scenario Alvorlighet Umiddelbare tiltak Datainnbrudd / personopplysninger kompromittert Kritisk Isolere system, varsle Datatilsynet (72t), varsle berørte kunder Sanksjonert transaksjon gjennomført ved feil Kritisk Fryse midler, varsle UD, rapportere til EFE Systemnedetid > 4 timer Høy Aktivere failover, informere kunder, loggføre Tjenestenektangrep (DDoS) Høy Aktivere DDoS-beskyttelse, eskalere til hosting-partner Mistanke om intern svindel Kritisk Fryse tilganger, undersøke, varsle styre og evt. politi 10.2 Kommunikasjonsplan ved hendelse Interessent Tidsfrist Kanal Ansvarlig Finanstilsynet Uten ugrunnet opphold Altinn / epost Daglig leder Datatilsynet 72 timer (datainnbrudd) Altinn Daglig leder Berørte kunder Uten ugrunnet opphold App + epost Kundeservice Styret Umiddelbart Epost + telefon Daglig leder Ansatte Umiddelbart Intern kanal Daglig leder 11. Endringslogg Versjon Dato Endring Godkjent av 1.0 2026-02-12 Førstegangs utarbeidelse Styre Dokumentet er utarbeidet i henhold til finansforetaksloven §13-5, hvitvaskingsloven §§7-8 og §37, og Finanstilsynets veiledninger om internkontroll i betalingsforetak. Incident Management Hendelseshåndteringsplan — Drop Dokument-ID: IRP-DROP-001 Versjon: 1.0 Dato: 12. februar 2026 Eier: ALAI Holding AS, org.nr. 932 516 136 Klassifisering: Intern — Fortrolig Regulatorisk grunnlag: DORA (EU) 2022/2554 art. 17-23, GDPR art. 33-34, Finanstilsynets IKT-forskrift 1. Innledning 1.1 Formål Denne hendelseshåndteringsplanen definerer prosesser for å oppdage, klassifisere, håndtere og rapportere IKT-relaterte hendelser i Drop-tjenesten. Planen sikrer effektiv respons i samsvar med DORA og øvrig regulering. 1.2 Virkeområde Planen dekker: Alle IKT-sikkerhetshendelser som påvirker Drop-tjenesten Personvernbrudd (GDPR art. 4 nr. 12) Driftshendelser som påvirker tjenestetilgjengelighet Hendelser hos tredjepartsleverandører som påvirker Drop Cyberangrep og forsøk på uautorisert tilgang 1.3 Regulatorisk bakgrunn Regulering Artikler Krav DORA art. 17 IKT-hendelseshåndteringsprosess Denne planen DORA art. 18 Klassifisering av hendelser Seksjon 3 DORA art. 19 Rapportering til myndigheter Seksjon 7 DORA art. 20 Harmonisert rapportering Seksjon 7 DORA art. 23 Deling av trusseletterretning Seksjon 9 GDPR art. 33 Varsling til tilsynsmyndighet Seksjon 7.3 GDPR art. 34 Varsling til registrerte Seksjon 7.4 2. Deteksjon og varsling 2.1 Deteksjonsmekanismer Kilde Type Beskrivelse SIEM Automatisert Korrelasjon av sikkerhetshendelser, regelbaserte og ML-baserte varsler Overvåking Automatisert Ytelse, tilgjengelighet, feilrater WAF/IDS/IPS Automatisert Angrepsdeteksjon, trafikanalyse Logganalyse Automatisert/manuell Anomalideteksjon i applikasjons- og systemlogger Sårbarhetsskanner Automatisert Daglig skanning av kjente sårbarheter Brukerrapportering Manuell Klager eller meldinger fra brukere Leverandørvarsling Manuell Hendelsesrapporter fra tredjeparter Trusseletterretning Automatisert/manuell Feed fra CERT, bransjekilder 2.2 Initialvarsling Ved deteksjon av potensiell hendelse: Automatisert varsling til vaktteam via definerte kanaler Vaktteamet foretar innledende vurdering innen 15 minutter Hendelsen registreres i hendelseshåndteringssystemet Innledende klassifisering gjennomføres (se seksjon 3) Eskalering iht. klassifisering 3. Klassifisering — DORA art. 18 3.1 Alvorlighetsgrader Hendelser klassifiseres etter alvorlighetsgrad basert på kriteriene i DORA artikkel 18(1): P1 — Kritisk Kriterier (ett eller flere): Fullstendig tjenestestans for betalingsfunksjoner Bekreftet databrudd med personopplysninger eller finansielle data Aktivt pågående cyberangrep med vesentlig konsekvens Tap eller kompromittering av krypteringsnøkler Vesentlig økonomisk tap for brukere Hendelse som påvirker mer enn 10% av brukerbasisen Responstid: Umiddelbart Rapportering: Finanstilsynet innen 4 timer (initialrapport) P2 — Høy Kriterier (ett eller flere): Delvis tjenestestans som påvirker betalinger for en gruppe brukere Sikkerhetsbrudd med begrenset omfang Kompromittert administratorkonto Uautorisert tilgang til produksjonssystemer Hendelse hos kritisk leverandør som påvirker tjenesten Responstid: Innen 30 minutter Rapportering: Finanstilsynet innen 4 timer dersom hendelsen anses som vesentlig P3 — Middels Kriterier (ett eller flere): Degradert tjenestekvalitet (forsinkelser, feil i ikke-kritiske funksjoner) Mislykket inntrengningsforsøk med indikasjoner på målrettet angrep Sårbarhet med høy CVSS-score oppdaget i produksjon Hendelse hos leverandør som kan påvirke tjenesten Responstid: Innen 2 timer Rapportering: Intern rapportering, Finanstilsynet ved behov P4 — Lav Kriterier (ett eller flere): Mindre tekniske problemer uten brukerpåvirkning Automatisk blokkerte angrepsforsøk (WAF, brannmur) Sårbarhet med lav/middels CVSS-score Informasjonshendelser som krever oppfølging Responstid: Innen 8 timer Rapportering: Intern loggføring 3.2 Klassifiseringskriterier (DORA art. 18(1)) Kriterium Beskrivelse Vurdering Berørte brukere Antall og andel berørte kunder/transaksjoner Kvantitativt Varighet Faktisk eller forventet varighet Tidsbasert Geografisk omfang Påvirkning i ulike markeder Geografisk Datatap Omfang og sensitivitet av kompromittert data Kvantitativt Økonomisk konsekvens Direkte og indirekte økonomisk påvirkning Kvantitativt Tjenestekritikalitet Påvirkning på kritiske funksjoner Kvalitativt Omdømmerisiko Potensiell påvirkning på tillit Kvalitativt 3.3 Reklassifisering Hendelser kan reklassifiseres under håndteringen dersom: Omfanget endrer seg (øker eller reduseres) Ny informasjon fremkommer Konsekvensen viser seg annerledes enn først antatt Reklassifisering dokumenteres med begrunnelse 4. Respons per alvorlighetsgrad 4.1 P1 — Kritisk hendelsesrespons MINUTT 0-15: Deteksjon → Innledende vurdering → Klassifisering P1 MINUTT 15-30: Aktiver hendelsesresponsteam → Isoler berørte systemer MINUTT 30-60: Analyse pågår → Kommunikasjon til ledelse og CISO TIME 1: Initialrapport til Finanstilsynet (innen 4t) Aktivér beredskapsorganisasjon Ekstern kommunikasjon (statusside, push-varsel) TIME 1-4: Containment → Eradication → Gjenoppretting pågår TIME 4: Statusrapport til Finanstilsynet Oppdatering til berørte brukere TIME 4-24: Fortsatt gjenoppretting → Overvåking DAG 1-3: Intermediær rapport til Finanstilsynet (innen 72t) GDPR-varsling til Datatilsynet (innen 72t) ved personvernbrudd Kommunikasjon til berørte registrerte ved høy risiko DAG 3-30: Endelig rapport til Finanstilsynet (innen 1 måned) Post-incident review 4.2 P2 — Høy hendelsesrespons MINUTT 0-30: Deteksjon → Vurdering → Klassifisering P2 MINUTT 30-60: Hendelsesansvarlig utpekt → Analyse startet TIME 1-2: Containment-tiltak implementert CISO informert TIME 2-4: Eradication og gjenoppretting Vurdering av rapporteringsplikt (Finanstilsynet) TIME 4-8: Normal drift gjenopprettet Intern statusrapport DAG 1-5: Rotårsaksanalyse Forbedringstiltak identifisert 4.3 P3 — Middels hendelsesrespons TIME 0-2: Deteksjon → Vurdering → Klassifisering P3 TIME 2-4: Analyse og vurdering av tiltak TIME 4-8: Tiltak implementert DAG 1-3: Verifisering → Dokumentasjon DAG 3-5: Hendelsesrapport ferdigstilt 4.4 P4 — Lav hendelsesrespons TIME 0-8: Deteksjon → Vurdering → Klassifisering P4 DAG 1-5: Analyse og tiltak ved behov DAG 5-10: Dokumentasjon i hendelsesloggen 5. Hendelseshåndteringsfaser 5.1 Fase 1: Identifisering Bekreft at hendelsen er reell (ikke falsk positiv) Kartlegg omfang og berørte systemer Identifiser hendelsestypen (angrep, feil, menneskelig feil, leverandør) Klassifiser alvorlighetsgrad (P1-P4) Dokumenter tidslinje fra deteksjon 5.2 Fase 2: Containment (Inneslutning) Kortsiktig containment: Isoler berørte systemer for å hindre spredning Aktiver alternative systemer/failover der mulig Bevare bevis (ikke slett logger eller data) Blokkér identifiserte angrepsvektor Langsiktig containment: Implementer midlertidige sikkerhetstiltak Patch eller oppdater sårbare systemer i isolert miljø Verifiser at containment er effektiv 5.3 Fase 3: Eradication (Fjerning) Identifiser og fjern rotårsaken Fjern skadelig programvare, uautoriserte kontoer, bakdører Oppdater/patch alle berørte systemer Verifiser at trusselen er eliminert Oppdater sikkerhetsregler og blokkérlister 5.4 Fase 4: Recovery (Gjenoppretting) Gjenopprett systemer fra kjent god tilstand (backup/clean install) Gjenopprett data fra verifiserte sikkerhetskopier Implementer forbedrede sikkerhetstiltak før gjenåpning Gradvis gjenåpning med forstørket overvåking Verifiser tjenestekvalitet Overvåk tett de neste 24-72 timene for tilbakefall 5.5 Fase 5: Lessons Learned (Lærdommer) Gjennomfør post-incident review innen 5 virkedager (P1/P2) eller 15 virkedager (P3/P4) Dokumenter hendelsesforløp, respons og utfall Identifiser forbedringstiltak Oppdater prosedyrer, deteksjonsregler og sikkerhetstiltak Del relevante lærdommer med teamet 6. Hendelsesresponsteam 6.1 Sammensetning Rolle Ansvar Aktiveres ved Hendelsesleder (Incident Commander) Overordnet koordinering, beslutninger, kommunikasjon P1, P2 CISO Sikkerhetsvurdering, myndighetskontakt, strategiske beslutninger P1, P2 Teknisk leder Teknisk analyse, containment, gjenoppretting P1, P2, P3 Driftsingeniør Systemadministrasjon, failover, gjenoppretting Alle Compliance-ansvarlig Regulatorisk vurdering, rapporteringsplikt P1, P2 Kommunikasjonsansvarlig Ekstern/intern kommunikasjon P1, P2 Daglig leder Strategiske beslutninger, styrekontakt P1 Personvernombud (DPO) Personvernvurdering, Datatilsynet-rapportering Alle med personvernimplikasjon 6.2 Eskalering Fra Til Kriterium Vaktteam Teknisk leder Alle bekreftede hendelser Teknisk leder CISO P1, P2, sikkerhetshendelser CISO Daglig leder P1, alle hendelser med regulatorisk rapporteringsplikt Daglig leder Styreleder P1 med vesentlig konsekvens 6.3 Kontaktinformasjon Oppdatert kontaktliste for hendelsesresponsteamet, inkludert: Mobilnummer (primær og sekundær) E-post Alternativ kontaktmetode Stedfortreder per rolle Oppdateres minimum kvartalsvis 7. Rapportering til myndigheter 7.1 Finanstilsynet — DORA art. 19 Rapporteringsplikt Vesentlige IKT-relaterte hendelser rapporteres til Finanstilsynet, jf. DORA art. 19(1). Rapporteringsfrister Rapport Frist Innhold Initialrapport Innen 4 timer etter klassifisering som vesentlig Hendelsestype, berørte tjenester, innledende konsekvens, iverksatte tiltak Intermediær rapport Innen 72 timer Oppdatert omfang, rotårsak (foreløpig), status for containment/gjenoppretting Endelig rapport Innen 1 måned Fullstendig beskrivelse, rotårsak, konsekvenser, lærdommer, forbedringstiltak Kriterier for «vesentlig hendelse» (DORA art. 18(1)) En hendelse er vesentlig dersom den: Berører kritiske betalingstjenester Påvirker et betydelig antall brukere Medfører eller kan medføre vesentlig økonomisk tap Medfører tap av data eller kompromittering av konfidensialitet Har eller kan ha betydelig omdømmekonsekvens Har varighet som overstiger terskelverdier satt av Finanstilsynet 7.2 DORA art. 20 — Harmonisert rapportering Vi følger rapporteringsformatet definert av de europeiske tilsynsmyndighetene (ESAs) i henhold til DORA art. 20, når dette er implementert av Finanstilsynet. 7.3 Datatilsynet — GDPR art. 33 Ved brudd på personopplysningssikkerheten: Handling Frist Kriterium Vurdering av rapporteringsplikt Umiddelbart etter deteksjon Alle personvernbrudd Melding til Datatilsynet Innen 72 timer Med mindre bruddet sannsynligvis ikke medfører risiko for registrertes rettigheter Informasjon til berørte registrerte Uten ugrunnet opphold Dersom bruddet sannsynligvis medfører høy risiko (GDPR art. 34) Innhold i melding til Datatilsynet (GDPR art. 33(3)): Bruddets art, inkludert kategorier og antall berørte registrerte Navn og kontaktinformasjon til personvernombudet Sannsynlige konsekvenser Tiltak som er iverksatt eller planlagt 7.4 Varsling til berørte registrerte — GDPR art. 34 Berørte registrerte varsles uten ugrunnet opphold dersom personvernbruddet sannsynligvis medfører høy risiko for deres rettigheter og friheter. Unntak (GDPR art. 34(3)): Data var kryptert og nøkler ikke kompromittert Tiltak er truffet som gjør at høy risiko ikke lenger er sannsynlig Individuell varsling krever uforholdsmessig innsats (offentlig kommunikasjon brukes) Varsling inneholder: Klar og tydelig beskrivelse av bruddet Kontaktinformasjon til personvernombudet Sannsynlige konsekvenser Tiltak iverksatt og anbefalt egenhandling Varsling skjer via: Push-varsling i appen E-post til registrert e-postadresse Ved behov: SMS og statusside 8. Dokumentasjon 8.1 Hendelseslogg Alle hendelser dokumenteres med: Unikt hendelses-ID Dato og tidspunkt for deteksjon Kilde for deteksjon Klassifisering (P1-P4) Hendelsestype (sikkerhet, drift, personvern, leverandør) Beskrivelse Berørte systemer og brukere Tidslinje for håndtering Iverksatte tiltak Rotårsak Rapportering til myndigheter (ja/nei, dato) Forbedringstiltak Status (åpen, under håndtering, lukket) 8.2 Bevissikring Ved sikkerhetshendelser (P1/P2): Sikre logger og bevis før containment Forensisk kopi av berørte systemer der relevant Kjede av bevis (chain of custody) dokumenteres Bevis oppbevares sikkert og skrivebeskyttet Bevisene kan overleveres til politi/påtalemyndighet ved behov 8.3 Oppbevaring Dokumenttype Oppbevaringstid P1-hendelser 5 år P2-hendelser 3 år P3/P4-hendelser 2 år Rapporter til myndigheter 5 år Personvernbrudd (alle) 5 år Forensisk bevis Til saken er avsluttet + 3 år 9. Trusseletterretning — DORA art. 23 9.1 Kilder Vi mottar og vurderer trusseletterretning fra: Norsk nasjonalt cybersikkerhetssenter (NCSC/NorCERT) FinansCERT (Nordic Financial CERT) Kommersielle trusseletterretningsfeeder Open-source trusseletterretning (OSINT) Bransjesamarbeid og informasjonsdeling 9.2 Deling I henhold til DORA art. 23 deltar vi i informasjonsdeling om cybertrusler: Anonymiserte indikatorer deles med relevante bransjefellesskap Vi bidrar til FinansCERT med hendelsesdata Vi mottar og implementerer varsler fra myndigheter 9.3 Bruk Trusseletterretning brukes til å: Oppdatere deteksjonsregler i SIEM Blokkere kjente ondsinnede IP-adresser og domener Prioritere sårbarhetshåndtering Informere risikost vurderinger Forbedre hendelsesresponsprosedyrer 10. Post-Incident Review 10.1 Gjennomføring Post-incident review gjennomføres etter alle P1- og P2-hendelser, samt utvalgte P3-hendelser: Alvorlighetsgrad Frist for review Deltakere P1 Innen 5 virkedager Hele hendelsesresponsteamet + ledelse P2 Innen 10 virkedager Hendelsesresponsteam P3 Innen 15 virkedager Teknisk leder + relevante ressurser 10.2 Innhold i post-incident review Hendelsesforløp: Kronologisk gjennomgang av hendelsen Deteksjon: Ble hendelsen oppdaget raskt nok? Hva kan forbedres? Respons: Var responsen effektiv? Ble prosedyrer fulgt? Kommunikasjon: Fungerte intern og ekstern kommunikasjon? Rotårsak: Hva var den underliggende årsaken? Konsekvens: Faktisk konsekvens for brukere, tjeneste, økonomi og omdømme Forbedringstiltak: Konkrete tiltak med ansvarlig og frist 10.3 Oppfølging av forbedringstiltak Alle forbedringstiltak registreres med ansvarlig, frist og status Statusgjennomgang i månedlig sikkerhetsmøte Tiltak verifiseres før lukking 11. Øvelser og testing 11.1 Øvelsesprogram Øvelsestype Frekvens Beskrivelse Tabletop Kvartalsvis Scenariobasert gjennomgang med hendelsesresponsteam Simulering Halvårlig Teknisk simulering av hendelse (kontrollert) Full øvelse Årlig Ende-til-ende simulering inkl. kommunikasjon og rapportering Red team Hvert 3. år Realistisk angrepssimulering (jf. DORA TLPT) 11.2 Scenarioer for øvelser Ransomware-angrep mot produksjonsserver Databasekompromittering med datatap DDoS-angrep mot betalingsmotor Insider-trussel (kompromittert ansattekonto) Leverandørhendelse (Open Banking-leverandør nede) Kombinert hendelse (cybersikkerhet + bortfall av leverandør) 11.3 Evaluering Alle øvelser evalueres med: Hva fungerte godt Hva kan forbedres Konkrete forbedringstiltak Dato for neste øvelse 12. Revisjon og oppdatering 12.1 Gjennomgang Årlig: Full gjennomgang av planen Etter P1/P2-hendelser: Revisjon basert på lærdommer Etter øvelser: Oppdatering basert på funn Ved regulatoriske endringer: Tilpasning til nye krav Ved vesentlige endringer: Ny teknologi, nye leverandører, organisasjonsendring 12.2 Godkjenning Endring Godkjenner Redaksjonell CISO Vesentlig Daglig leder Prinsipiell Styret 12.3 Versjonshistorikk Versjon Dato Endring Godkjent av 1.0 12.02.2026 Opprinnelig dokument ____________ Vedlegg Vedlegg A: Kontaktliste hendelsesresponsteam Separat dokument — fortrolig. Vedlegg B: Maler for rapportering Mal for initialrapport til Finanstilsynet Mal for intermediær rapport Mal for endelig rapport Mal for GDPR-bruddmelding til Datatilsynet Mal for varsling til berørte registrerte Vedlegg C: Sjekklister per hendelsestype Sjekkliste: Ransomware Sjekkliste: DDoS Sjekkliste: Databrudd Sjekkliste: Leverandørhendelse Sjekkliste: Insider-trussel Vedlegg D: Eskaleringstrinn visuelt P4 (Lav) → Driftsingeniør P3 (Middels) → Driftsingeniør → Teknisk leder P2 (Høy) → Driftsingeniør → Teknisk leder → CISO → Daglig leder P1 (Kritisk) → Hele hendelsesresponsteamet → Styreleder Denne hendelseshåndteringsplanen er eid av CISO og godkjent av styret i ALAI Holding AS. Planen testes og revideres minimum årlig. Contingency Plan Beredskapsplan — Drop Dokument-ID: BCP-DROP-001 Versjon: 1.0 Dato: 12. februar 2026 Eier: ALAI Holding AS, org.nr. 932 516 136 Klassifisering: Intern — Fortrolig Regulatorisk grunnlag: DORA (EU) 2022/2554 art. 11, Finanstilsynets IKT-forskrift 1. Innledning 1.1 Formål Denne beredskapsplanen sikrer at Drop-tjenesten kan opprettholde eller raskt gjenopprette kritiske funksjoner ved vesentlige forstyrrelser. Planen er utarbeidet i henhold til DORA artikkel 11 om forretningskontinuitet og krisekommunikasjon. 1.2 Virkeområde Planen dekker: Alle IKT-systemer som understøtter Drop-tjenesten Alle forretningsprosesser knyttet til betalingsbehandling Tredjepartsleverandører som er kritiske for tjenesteleveransen Kommunikasjon med berørte parter under og etter hendelser 1.3 Definisjoner Begrep Definisjon RTO (Recovery Time Objective) Maksimal akseptabel nedetid RPO (Recovery Point Objective) Maksimalt akseptabelt datatap (tidsperiode) MTPD (Maximum Tolerable Period of Disruption) Maksimal periode tjenesten kan være nede BIA (Business Impact Analysis) Analyse av konsekvenser ved bortfall 2. Business Impact Analysis (BIA) 2.1 Kritiske forretningsprosesser Prosess Kritikalitet RTO RPO MTPD Konsekvens ved bortfall Betalingsbehandling (PISP) Kritisk 1 time 0 (null datatap) 4 timer Brukere kan ikke gjennomføre betalinger, omdømmetap, regulatorisk risiko Kontoinformasjon (AISP) Viktig 4 timer 1 time 8 timer Brukere kan ikke se saldo, begrenset funksjonalitet Utenlandsoverføring (remittance) Kritisk 2 timer 0 8 timer Forsinkede overføringer, kundetap QR-betalinger Kritisk 1 time 0 4 timer Forhandlere kan ikke motta betaling Brukerautentisering (BankID) Kritisk 30 min N/A 2 timer Ingen kan logge inn, total tjenestestans Kundeservice Viktig 8 timer 4 timer 24 timer Kunder kan ikke få hjelp, klagebehandling forsinkes KYC/AML-kontroll Viktig 4 timer 1 time 12 timer Nye kunder kan ikke registrere seg Rapportering og compliance Standard 24 timer 4 timer 48 timer Regulatorisk rapportering forsinkes Push-varsler Standard 8 timer N/A 24 timer Brukere mottar ikke transaksjonsvarsler 2.2 Kritiske IKT-systemer System Avhengigheter Redundans RTO Betalingsmotor Database, Open Banking API Aktiv-aktiv 1 time Database (PostgreSQL) Lagring, nettverk Replikering, automatisk failover 15 min Open Banking-gateway Ekstern leverandør Sekundær leverandør (varm standby) 2 timer BankID-integrasjon BankID Norge AS BankID HA-oppsett Avhengig av BankID API-gateway CDN, lastbalansering Multiregion 30 min Appservere Container-orkestrator Autoskalering, multinode 15 min Meldingskø Broker-klynge Klynge med replikering 15 min Cache Redis-klynge Replikering 5 min Overvåkingssystem SIEM, logger Separat infrastruktur 1 time 2.3 Avhengigheter til tredjeparter Leverandør Tjeneste Kritikalitet Alternativ Open Banking-leverandør PSD2 PISP/AISP Kritisk Sekundær leverandør med varm standby BankID Norge AS Autentisering Kritisk Ingen alternativ (nasjonal eID) — degradert modus Skyinfrastrukturleverandør Hosting Kritisk Multiregion-oppsett, alternativ region Korrespondentbanker Remittance Kritisk Flere partnere per korridor CDN-leverandør Innholdslevering Viktig Sekundær CDN konfigurert E-postleverandør Transaksjonelle e-poster Standard Sekundær leverandør 3. Scenarioer og responsstrategier 3.1 Scenario S1: Fullstendig datasentertap Beskrivelse: Primær hosting-region er utilgjengelig (brann, naturkatastrofe, regionalt strømbrudd). Responsstrategi: Automatisk failover til sekundær region (konfigurasjon: aktiv-passiv) DNS-oppdatering peker trafikk til sekundær region (TTL: 60 sekunder) Database failover til standby-replikka i sekundær region Verifiser tjenestekvalitet i sekundær region Informer brukere via push-varsling og statusside Initier gjenoppbygging av primær region etter at hendelsen er løst RTO: 2 timer | RPO: 5 minutter (asynkron replikering) 3.2 Scenario S2: Databasekorrupsjon Beskrivelse: Primær database korruptert (programvarefeil, menneskelig feil, ondsinnet aktivitet). Responsstrategi: Stopp skriving til korrupt database umiddelbart Aktiver skrivebeskyttet modus (brukere kan se, men ikke utføre transaksjoner) Identifiser tidspunkt for korrupsjon Gjenopprett fra siste gyldige backup + WAL-replay til tidspunkt før korrupsjon Verifiser dataintegritet Gjenoppta normal drift Gjennomfør rotårsaksanalyse RTO: 1 time | RPO: 0 (med WAL-replay) 3.3 Scenario S3: Open Banking-leverandør nede Beskrivelse: Primær Open Banking-leverandør er utilgjengelig. Responsstrategi: Automatisk failover til sekundær Open Banking-leverandør Aktiver hurtigbuffer for kontoinformasjon (siste kjente saldo, maks 1 time gammel) Informer brukere om mulig forsinkelse i betalingsbehandling Kontakt primær leverandør for statusoppdatering Logg alle transaksjoner som venter på behandling Gjenoppta mot primær leverandør når tilgjengelig RTO: 30 minutter (failover) | RPO: 0 3.4 Scenario S4: BankID utilgjengelig Beskrivelse: BankID-infrastrukturen er nede nasjonalt. Responsstrategi: Aktiver degradert modus: eksisterende innloggede brukere kan fullføre pågående transaksjoner Ny autentisering er ikke mulig — informer brukere via app og statusside Kontakt BankID Norge AS for statusoppdatering Forleng sesjonstimeout midlertidig (fra 15 min til 60 min) for aktive sesjoner Logg alle forsøk på autentisering for senere analyse Gjenoppta normal drift når BankID er tilbake RTO: Avhengig av BankID | Mitigering: Forlengede sesjoner for aktive brukere 3.5 Scenario S5: Cyberangrep (ransomware/DDoS) Beskrivelse: Målrettet cyberangrep mot Drop-infrastrukturen. Responsstrategi: Aktiver hendelsesresponsplan (se hendelseshaandtering.md ) Isoler berørte systemer Aktiver DDoS-mitigering på CDN/WAF-nivå Ved ransomware: gjenopprett fra sikkerhetskopier (ingen betaling) Eskaler til Finanstilsynet innen 4 timer Informer berørte brukere Engasjer ekstern hendelsesresponsteam ved behov RTO: 4 timer (DDoS), 8 timer (ransomware) | RPO: 0 (fra backup) 3.6 Scenario S6: Nøkkelpersonavhengighet Beskrivelse: Kritisk personell er utilgjengelig (sykdom, fratredelse). Responsstrategi: Alle kritiske roller har stedfortreder dokumentert Alle prosedyrer er dokumentert og tilgjengelig Alle tilganger er rollebasert (ikke personbasert) Tredjepartsavtaler har kontaktlister med flere kontaktpunkter Eskaleringsmatrisen oppdateres ved personalendringer 4. Gjenopprettingsprosedyrer 4.1 Generell gjenopprettingsprosess 1. OPPDAGE → Automatisert overvåking eller manuell varsling 2. VURDERE → Kategoriser hendelsen (S1-S6), identifiser omfang 3. ESKALER → Aktiver beredskapsorganisasjon iht. eskaleringstrinn 4. HÅNDTERE → Utfør scenariospesifikk respons 5. VERIFISER → Kontroller at gjenoppretting er vellykket 6. INFORMER → Oppdater berørte parter om status 7. NORMALISER → Gjenoppta normal drift 8. ANALYSER → Rotårsaksanalyse og forbedring 4.2 Database-gjenoppretting Forutsetninger: PostgreSQL med streaming replikering og WAL-arkivering. Identifiser siste gyldige tidspunkt Stopp applikasjonsservere Gjenopprett database fra siste fullsikkerhetskopi Replay WAL-segmenter frem til identifisert tidspunkt (PITR) Verifiser dataintegritet med sjekksumkontroll Kjør integrasjonstester mot gjenopprettet database Start applikasjonsservere i kontrollert rekkefølge Overvåk tett de neste 24 timene 4.3 Infrastruktur-gjenoppretting Verifiser at infrastruktur-som-kode (IaC) er tilgjengelig Provisionér ny infrastruktur i sekundær region/sone Deploy siste gyldige applikasjonsversjon Gjenopprett databaser (se 4.2) Konfigurer nettverksruter og lastbalansering Verifiser tjenestekvalitet Oppdater DNS 5. Kommunikasjonsplan 5.1 Intern kommunikasjon Eskaleringstrinn Kriterium Varsler Metode Innen Trinn 1 Degradert tjeneste Driftsteam Automatisk varsling Umiddelbart Trinn 2 Kritisk tjeneste nede Driftsteam + CISO Telefon + e-post 15 min Trinn 3 Fullstendig tjenestestans > 1 time + Daglig leder Telefon 30 min Trinn 4 Tjenestestans > 4 timer eller databrudd + Styreleder Telefon 1 time 5.2 Ekstern kommunikasjon Mottaker Kriterium Metode Innen Brukere Tjenestestans > 15 min Push-varsling, statusside 30 min Forhandlere QR-betalinger nede > 15 min E-post, telefon (store) 30 min Finanstilsynet Alvorlig IKT-hendelse (DORA art. 19) Varslingsskjema 4 timer Datatilsynet Personvernbrudd Avviksskjema 72 timer Open Banking-leverandør Integrasjonsproblemer Avtalt kanal Umiddelbart BankID Norge AS Autentiseringsproblemer Avtalt kanal Umiddelbart Media Ved offentlig oppmerksomhet Pressekontakt Koordinert 5.3 Statusside Ekstern statusside oppdateres ved alle hendelser som påvirker brukere Automatisert oppdatering fra overvåkingssystem Manuell oppdatering ved komplekse hendelser Historikk over alle hendelser tilgjengelig 5.4 Maler for kommunikasjon Ferdigformulerte maler for: Planlagt vedlikehold Uplanlagt tjenesteavbrudd Gjenoppretting bekreftet Sikkerhetsbrudd (til brukere) Regulatorisk varsling (Finanstilsynet) 6. Beredskapsorganisasjon 6.1 Roller og ansvar Rolle Ansvar Stedfortreder Beredskapsleder (daglig leder) Overordnet beslutningsansvar, ekstern kommunikasjon CTO Teknisk leder (CTO) Teknisk gjenoppretting, koordinering av driftsteam Senior utvikler Kommunikasjonsansvarlig Intern/ekstern kommunikasjon, statusoppdateringer Daglig leder CISO Sikkerhetsvurdering, koordinering med myndigheter CTO Compliance-ansvarlig Regulatorisk vurdering, varsling til tilsyn CISO Driftsleder Utfører gjenopprettingsprosedyrer Backup driftsteam 6.2 Kontaktliste Oppdatert kontaktliste med: Mobilnummer (primær og sekundær) E-postadresse Alternativ kontaktmetode Oppdateres minimum kvartalsvis 6.3 Aktivering av beredskap Beredskap aktiveres når: Automatisert overvåking utløser P1- eller P2-alarm Manuell vurdering tilsier aktivering Finanstilsynet krever det Tredjepartsleverandør rapporterer kritisk hendelse 7. Testing og øvelser 7.1 Testprogram Testtype Frekvens Omfang Ansvarlig Tabletop-øvelse Kvartalsvis Gjennomgang av scenarioer med beredskapsorganisasjon Beredskapsleder Failover-test Halvårlig Teknisk failover til sekundær region CTO Database-gjenoppretting Halvårlig Full gjenoppretting fra backup Driftsleder Kommunikasjonstest Kvartalsvis Test av kontaktlister og eskaleringsprosedyrer Kommunikasjonsansvarlig Full beredskapsøvelse Årlig Ende-til-ende simulering inkl. tredjeparter Beredskapsleder 7.2 Testdokumentasjon Alle tester dokumenteres med: Dato og deltakere Scenario som ble testet Faktisk RTO/RPO oppnådd Avvik fra planlagte prosedyrer Forbedringstiltak med frist og ansvarlig 7.3 Oppdatering etter test Beredskapsplanen oppdateres innen 30 dager etter test/øvelse Identifiserte svakheter utbedres innen 60 dager Neste test planlegges 8. Vedlikehold av planen 8.1 Gjennomgangsfrekvens Årlig: Full gjennomgang av beredskapsplanen Kvartalsvis: Oppdatering av kontaktlister Ved vesentlige endringer: Ny leverandør, ny teknologi, organisasjonsendring Etter hendelser: Revideres basert på lærdommer Etter øvelser: Oppdateres basert på testresultater 8.2 Ansvar for vedlikehold Aktivitet Ansvarlig Frekvens Oppdatering av kontaktlister Alle rolleinnehavere Kvartalsvis Teknisk gjennomgang CTO Halvårlig Full plangjennomgang Beredskapsleder Årlig Godkjenning Daglig leder Ved endring 8.3 Distribusjon Planen distribueres til alle i beredskapsorganisasjonen Tilgjengelig offline (utskrift) hos beredskapsleder og CTO Lagret i versjonskontroll med endringshistorikk Kopier hos tredjepartsleverandører ved behov 9. Samsvar med DORA artikkel 11 Denne beredskapsplanen er utarbeidet i henhold til kravene i DORA artikkel 11: DORA-krav Dekning i planen Art. 11(1): IKT-kontinuitetspolicy Hele dokumentet Art. 11(2): BIA for kritiske funksjoner Seksjon 2 Art. 11(3): Responsstrategier Seksjon 3 Art. 11(4): Gjenopprettingsprosedyrer Seksjon 4 Art. 11(5): Kommunikasjonsplan Seksjon 5 Art. 11(6): Testing Seksjon 7 Art. 11(7): Gjennomgang og oppdatering Seksjon 8 Art. 11(8): Hendelsesrespons Ref. hendelseshaandtering.md Art. 11(9): Tredjepartsavhengigheter Seksjon 2.3 10. Versjonshistorikk Versjon Dato Endring Godkjent av 1.0 12.02.2026 Opprinnelig dokument ____________ Vedlegg Vedlegg A: Kontaktliste beredskapsorganisasjon Separat dokument — fortrolig. Vedlegg B: Sjekklister per scenario Operasjonelle sjekklister — oppbevares hos driftsteam. Vedlegg C: Oversikt over sikkerhetskopier og gjenopprettingspunkter Teknisk dokumentasjon — vedlikeholdes av driftsteam. Beredskapsplanen er eid av beredskapsleder og godkjent av styret i ALAI Holding AS. Planen revideres minimum årlig og etter enhver vesentlig hendelse. Complaints Handling Klagebehandlingsprosedyre — Drop Dokument-ID: KLAGE-DROP-001 Versjon: 1.0 Dato: 12. februar 2026 Eier: ALAI Holding AS, org.nr. 932 516 136 Regulatorisk grunnlag: PSD2 (EU) 2015/2366 art. 101, betalingstjenesteloven, finansforetaksloven 1. Innledning 1.1 Formål Denne prosedyren beskriver hvordan ALAI Holding AS håndterer klager fra brukere av Drop-tjenesten. Prosedyren sikrer at klager behandles effektivt, rettferdig og i samsvar med gjeldende regelverk. 1.2 Virkeområde Prosedyren gjelder for alle klager som gjelder Drop-tjenesten, inkludert: Betalingstransaksjoner (QR-betaling og utenlandsoverføring) Gebyrer og prising Tilgjengelighet og tekniske problemer Personvern og datasikkerhet Kundekontroll og verifisering Kundeservice Andre forhold knyttet til tjenesteleveransen 1.3 Definisjon av klage En klage er enhver formell uttrykt misnøye fra en bruker vedrørende Drop-tjenesten, der brukeren forventer et svar eller en løsning. Generelle henvendelser, spørsmål og tilbakemeldinger som ikke uttrykker misnøye, behandles som ordinære kundeservicehenvendelser og faller utenfor denne prosedyren. 2. Klagekanaler 2.1 Tilgjengelige kanaler Kanal Kontaktinformasjon Tilgjengelighet E-post klage@getdrop.no 24/7 (mottatt) I appen Hjelp > Send klage 24/7 Post ALAI Holding AS, [adresse], Norge Postgang Kundeservice support@getdrop.no Man-fre 08:00-20:00, lør 10:00-16:00 2.2 Krav til klage For effektiv behandling bør klagen inneholde: Ditt fulle navn og registrerte e-postadresse eller mobilnummer Beskrivelse av forholdet du klager på Dato og eventuelt transaksjonsreferanse Hva du forventer som utfall Relevante vedlegg (skjermbilder, kvitteringer) 2.3 Tilgjengelighet Klagekanaler er tilgjengelige: På norsk og engelsk Uten kostnad for brukeren Uten krav om spesiell programvare eller utstyr utover det som kreves for å bruke Drop 3. Behandlingsprosess 3.1 Mottak og registrering Alle klager registreres i klagehåndteringssystemet ved mottak Klager tildeles unikt referansenummer Mottaksbekreftelse sendes til klager innen 1 virkedag Mottaksbekreftelsen inneholder: Referansenummer Forventet behandlingstid Kontaktinformasjon for oppfølging 3.2 Kategorisering Klager kategoriseres etter type og alvorlighetsgrad: Kategori Beskrivelse Prioritet K1: Transaksjonsfeil Feilbelastet, dobbeltbelastet, manglende overføring Høy K2: Gebyrtvist Uenighet om gebyrer eller valutakurs Middels K3: Tilgjengelighet Tjeneste utilgjengelig, tekniske feil Middels K4: Kundeservice Misnøye med servicenivå Standard K5: Personvern Bekymring om datahåndtering Høy K6: Kundekontroll Klage på KYC-prosesser eller avvisning Middels K7: Sperring Konto- eller transaksjonssperring Høy K8: Annet Øvrige klager Standard 3.3 Behandling Klagen tildeles saksbehandler basert på kategori og kompetanse Saksbehandler gjennomgår klagen, innhenter nødvendig informasjon Saksbehandler kan kontakte klager for avklaring Saksbehandler utarbeider forslag til løsning Ved K1 og K7: Saksbehandler kan iverksette umiddelbare tiltak (f.eks. midlertidig tilbakeføring) 3.4 Svarfrister I henhold til PSD2 artikkel 101 og betalingstjenesteloven: Frist Beskrivelse 1 virkedag Mottaksbekreftelse 15 virkedager Endelig svar på klagen 35 virkedager Maksimal forlenget frist ved ekstraordinære omstendigheter Ved behov for forlenget frist (utover 15 virkedager) skal klager motta: Skriftlig informasjon om forsinkelsen Begrunnelse for hvorfor mer tid er nødvendig Forventet ny svardato Ny frist kan ikke overstige 35 virkedager totalt 3.5 Innhold i svarbrev Svaret til klager skal inneholde: Referanse til klagen Oppsummering av forholdet som er klaget inn Vår vurdering og begrunnelse Eventuell løsning eller kompensasjon Informasjon om videre klageadgang (Finansklagenemnda) Kontaktinformasjon for oppfølging 4. Eskalering 4.1 Intern eskalering Nivå Beslutningstaker Kriterium Nivå 1 Saksbehandler (kundeservice) Standard klager Nivå 2 Teamleder kundeservice Komplekse klager, kompensasjon > 1 000 kr Nivå 3 Compliance-ansvarlig Regulatoriske klager, personvern, gjentatte klager Nivå 4 Daglig leder Vesentlige klager, kompensasjon > 10 000 kr, systemiske problemer 4.2 Ekstern eskalering Dersom klager ikke er tilfreds med vårt svar, informerer vi om retten til å bringe saken inn for: Finansklagenemnda (FinKN) Postboks 53 Skøyen, 0212 Oslo Telefon: 23 13 19 60 Nettsted: https://www.finansklagenemnda.no Behandling er kostnadsfri for forbrukere Klage til FinKN må fremsettes innen 3 år etter at klager først klaget til oss Finanstilsynet For klager på selve tjenesteleverandøren eller brudd på regulatoriske krav Revierstredet 3, 0151 Oslo Telefon: 22 93 98 00 Nettsted: https://www.finanstilsynet.no Forbrukerrådet Generell forbrukerveiledning Sandakerveien 138, 0484 Oslo Telefon: 23 400 500 Nettsted: https://www.forbrukerradet.no 4.3 Rettslig tvisteløsning Dersom saken ikke løses gjennom nemndbehandling, kan tvisten bringes inn for norske domstoler, jf. brukervilkårene punkt 13. 5. Kompensasjon 5.1 Prinsipper Kompensasjon vurderes individuelt for hver klage Målet er å sette klager i den posisjonen vedkommende ville vært i uten feilen Kompensasjon kan inkludere tilbakeføring, gebyrfritak, eller annen godtgjørelse 5.2 Automatisk kompensasjon Følgende utløser automatisk kompensasjon: Dobbeltbelastning: Umiddelbar tilbakeføring av overskytende beløp Feilsendt overføring (vår feil): Full tilbakeføring Gebyr trukket i strid med prisliste: Gebyrrefusjon 5.3 Skjønnsmessig kompensasjon Ved forhold som ikke utløser automatisk kompensasjon, kan vi tilby: Gebyrfritak for fremtidige transaksjoner Økonomisk kompensasjon der det er rimelig Forbedret servicenivå (f.eks. prioritert kundeservice) 6. Dokumentasjon og oppbevaring 6.1 Klageregister Alle klager dokumenteres i klageregisteret med: Unikt referansenummer Dato for mottak Klagers identifikasjon (anonymisert i rapporter) Klagekategori Beskrivelse av klagen Dato og innhold i svar Eventuell kompensasjon Status (mottatt, under behandling, besvart, avsluttet, eskalert) 6.2 Oppbevaringstid Klager og tilhørende dokumentasjon oppbevares i minimum 3 år etter avslutning Klager knyttet til transaksjoner oppbevares i henhold til bokføringsloven § 13 (5 år) Klager viderebrakt til Finansklagenemnda oppbevares til endelig avgjørelse + 3 år 6.3 Personvern Behandling av personopplysninger i klagebehandlingen skjer i henhold til personvernerklæringen og GDPR. Klager har rett til innsyn i egne opplysninger, jf. GDPR artikkel 15. 7. Rapportering 7.1 Intern rapportering Rapport Frekvens Mottaker Innhold Klageoversikt Månedlig Daglig leder Antall, kategorier, behandlingstid, løsningsrate Trendanalyse Kvartalsvis Ledelsen Trender, gjentakende problemer, systemiske svakheter Årsrapport Årlig Styret Sammendrag, nøkkeltall, tiltak, sammenlikning med foregående år 7.2 Innhold i rapporter Antall mottatte klager per kategori Gjennomsnittlig og median behandlingstid Andel klager besvart innen 15 virkedager Antall klager eskalert til ekstern instans Total kompensasjon utbetalt Identifiserte systemiske problemer og iverksatte tiltak 7.3 Styreorientering Styret orienteres: Kvartalsvis om klagestatistikk og trender Umiddelbart ved vesentlige klager som indikerer systemisk svikt Umiddelbart ved klager til Finansklagenemnda eller Finanstilsynet Årlig med full klageårsrapport 7.4 Rapportering til Finanstilsynet I henhold til regulatoriske krav rapporteres: Vesentlige klagetyper og -trender (som del av periodisk rapportering) Klager som indikerer brudd på regulatoriske krav Utfall av saker behandlet i Finansklagenemnda 8. Forbedring 8.1 Rotårsaksanalyse For gjentakende klager eller alvorlige enkeltklager gjennomføres rotårsaksanalyse: Identifiser grunnleggende årsak Vurder om problemet er systemisk Utarbeid forbedtringstiltak Implementer tiltak med ansvarlig og frist Verifiser at tiltaket har effekt 8.2 Kontinuerlig forbedring Klagedata brukes aktivt til å forbedre tjenesten Produktteamet mottar anonymiserte klagerapporter Tiltak implementeres og effekt måles Forbedringer kommuniseres til brukere der relevant 8.3 Opplæring Kundeservicemedarbeidere gjennomgår opplæring i klagebehandling ved ansettelse Årlig oppdateringsopplæring for alle som behandler klager Casebasert opplæring ved nye typer klager 9. Ansvar og organisering 9.1 Roller Rolle Ansvar Kundeservicemedarbeider Mottak, registrering, behandling av nivå 1-klager Teamleder kundeservice Kvalitetskontroll, nivå 2-klager, coaching Compliance-ansvarlig Regulatoriske klager, rapportering til myndigheter, nivå 3 Daglig leder Overordnet ansvar, styreorientering, nivå 4 9.2 Uavhengighet Klagebehandlingen skal være uavhengig av den operative virksomheten. Compliance-ansvarlig har selvstendig rapporteringsrett til styret. 10. Regulatorisk samsvar Denne prosedyren er utarbeidet i samsvar med: Regulering Krav Dekning PSD2 art. 101 Klageprosedyre for betalingstjenestebrukere Hele dokumentet PSD2 art. 101(1) 15 virkedagers svarfrist Punkt 3.4 PSD2 art. 101(2) Informasjon om ekstern klageadgang Punkt 4.2 Betalingstjenesteloven kap. 3 Rettigheter og plikter ved betalingstjenester Punkt 3, 5 Finansforetaksloven § 16-1 Klageordning for finansforetak Hele dokumentet GDPR art. 77 Klagerett til tilsynsmyndighet Personvernerklæring Angrerettloven § 22 Angrerett og klageadgang Brukervilkår punkt 9 11. Revisjon 11.1 Gjennomgang Årlig: Full gjennomgang av prosedyren Ved regulatoriske endringer: Oppdatering iht. nye krav Ved systemiske klager: Gjennomgang og tilpasning Etter Finansklagenemnda-avgjørelser: Vurdering av behov for endringer 11.2 Versjonshistorikk Versjon Dato Endring Godkjent av 1.0 12.02.2026 Opprinnelig dokument ____________ Denne klagebehandlingsprosedyren er eid av compliance-ansvarlig og godkjent av daglig leder i ALAI Holding AS. Terms & Agreements Terms of Service Brukervilkår for Drop Sist oppdatert: 12. februar 2026 Tjenesteleverandør: ALAI Holding AS, org.nr. 932 516 136 Nettsted: https://getdrop.no 1. Om tjenesten 1.1 Hva er Drop Drop er en betalingstjeneste levert av ALAI Holding AS som tilbyr: Utenlandsoverføringer (remittance): Send penger til mottakere i over 30 land. Mottaker trenger ikke Drop-app eller -konto. QR-betalinger: Betal hos forhandlere ved å skanne QR-kode i appen. Lommebok og betalingsoversikt: Oversikt over transaksjoner, varsler og personlige innstillinger. 1.2 Tjenestens karakter Drop er en betalingsinitieringstjeneste (PISP) og kontoinformasjonstjeneste (AISP) i henhold til PSD2 (direktiv (EU) 2015/2366). Drop holder aldri kundemidler. Alle betalinger initieres direkte fra brukerens bankkonto gjennom Open Banking-grensesnitt. 1.3 Hvem tjenesten er for Drop er tilgjengelig for alle innbyggere i Norge som oppfyller vilkårene i punkt 2. 2. Vilkår for bruk 2.1 Krav til brukere For å bruke Drop må du: Være minst 18 år , jf. vergemålsloven (LOV-2010-03-26-9) § 2 Ha norsk BankID — personlig BankID knyttet til norsk fødselsnummer Ha norsk mobilnummer (+47) Ha bankkonto i norsk bank som støtter Open Banking (PSD2) Akseptere disse brukervilkårene og vår personvernerklæring 2.2 Registrering Registrering skjer gjennom: Last ned Drop-appen fra App Store eller Google Play Identifiser deg med BankID Bekreft mobilnummer via SMS-kode Aksepter brukervilkår og personvernerklæring Gi samtykke til kontoinformasjonstjeneste (AISP) dersom ønsket 2.3 Verifisering og kundekontroll I henhold til hvitvaskingsloven (LOV-2018-06-01-23) §§ 10-18 er vi forpliktet til å gjennomføre kundekontroll. Dette innebærer: Verifisering av identitet gjennom BankID Kontroll mot sanksjonslister og PEP-lister Løpende overvåking av transaksjoner Vi kan be om ytterligere dokumentasjon ved forsterket kundekontroll Vi forbeholder oss retten til å nekte registrering eller avslutte kundeforholdet dersom kundekontroll ikke kan gjennomføres tilfredsstillende. 3. Tjenestebeskrivelse 3.1 Utenlandsoverføringer Tilgjengelige land: Over 30 mottakerland (oppdatert liste i appen) Valutaer: NOK konverteres til mottakers valuta. Valutakurs vises før bekreftelse. Leveringstid: Varierer per mottakerland, typisk 1-3 virkedager. Estimert tid vises ved bestilling. Mottaker: Trenger ikke Drop-konto. Mottar pengene direkte til oppgitt bankkonto. Beløpsgrenser: Se punkt 4. 3.2 QR-betalinger Hvordan: Skann forhandlerens QR-kode med Drop-appen Bekreftelse: Godkjenn beløp og bekreft med BankID eller app-PIN Kvittering: Digital kvittering umiddelbart i appen Tilgjengelighet: Hos alle forhandlere som har avtale med Drop 3.3 Kontoinformasjon Saldovisning: Se saldo på tilknyttede bankkontoer (krever AISP-samtykke) Transaksjonshistorikk: Oversikt over alle Drop-transaksjoner Varsler: Push-varsler ved gjennomførte transaksjoner 3.4 Tilgjengelighet Vi tilstreber at tjenesten er tilgjengelig 24/7/365. Planlagt vedlikehold varsles minimum 48 timer i forveien via push-varsling og statusside. 4. Gebyrer og kostnader 4.1 Transparens Alle gebyrer vises tydelig før du bekrefter en transaksjon, i henhold til PSD2 artikkel 45 og betalingstjenesteloven (LOV-2023-06-16-39). Du godkjenner alltid totalkostnaden (inkludert gebyrer og valutakurs) før gjennomføring. 4.2 Gebyrstruktur Tjeneste Gebyr Beskrivelse Kontoregistrering Gratis Ingen registreringskostnad QR-betaling Se appen Vises før bekreftelse Utenlandsoverføring Se appen Fast gebyr + valutapåslag, vises før bekreftelse Kontoinformasjon (AISP) Gratis Ingen kostnad for saldovisning Varsler Gratis Push-varsler er gratis 4.3 Valutakurs Ved utenlandsoverføringer benyttes valutakurs som vises i appen ved bestillingstidspunktet. Kursen inkluderer et påslag som angis separat. Kursen låses ved din bekreftelse. 4.4 Gebyrberegning Total kostnad for utenlandsoverføring = Overføringsbeløp + Fast gebyr + Valutapåslag Eksakt beregning vises alltid i appen før du bekrefter transaksjonen. 4.5 Gebyrfri tjenester Vi tar ikke gebyr for: Registrering og kontoadministrasjon Visning av saldo og transaksjonshistorikk Push-varsler Kundeservicehenvendelser 5. Transaksjonsgrenser 5.1 Beløpsgrenser I henhold til hvitvaskingsregelverket og våre interne retningslinjer gjelder følgende grenser: Grensetype Beløp Periode Per transaksjon (utenlandsoverføring) Vises i appen Per enkeltoverføring Per dag (utenlandsoverføring) Vises i appen Kalenderdag Per måned (utenlandsoverføring) Vises i appen Kalendermåned Per transaksjon (QR-betaling) Vises i appen Per enkeltbetaling Per dag (QR-betaling) Vises i appen Kalenderdag 5.2 Endring av grenser Standardgrenser tildeles ved registrering Høyere grenser kan innvilges etter forsterket kundekontroll Vi forbeholder oss retten til å senke grenser ved mistanke om uregelmessigheter Endringer i grenser kommuniseres via appen 5.3 Egendefinerte grenser Du kan sette egne forbruksgrenser i appen under Innstillinger > Forbruksgrenser. Egendefinerte grenser kan ikke overstige de generelle grensene. 6. Brukerens plikter 6.1 Sikkerhet Du er ansvarlig for å: Beskytte din BankID og tilhørende koder Ikke dele innloggingsinformasjon med andre Bruke sterk PIN-kode eller biometrisk autentisering i appen Melde fra umiddelbart ved mistanke om uautorisert bruk Holde appen oppdatert til siste tilgjengelige versjon 6.2 Korrekt bruk Du forplikter deg til å: Oppgi korrekte opplysninger ved registrering og bruk Ikke benytte tjenesten til ulovlige formål Ikke forsøke å omgå sikkerhetsmekanismer eller beløpsgrenser Ikke benytte tjenesten til hvitvasking eller terrorfinansiering Overholde gjeldende valutareguleringer i Norge og mottakerlandet 6.3 Varsling om uautorisert bruk Ved mistanke om uautorisert bruk av din Drop-konto: Sperr kontoen umiddelbart i appen (Innstillinger > Sperr konto) Kontakt kundeservice (kontaktinfo i punkt 14) Anmeld forholdet til politiet ved behov 7. Våre plikter 7.1 Tjenesteleveranse Vi forplikter oss til å: Levere tjenesten i samsvar med disse vilkårene Opprettholde høy tilgjengelighet og sikkerhet Behandle personopplysninger i samsvar med GDPR og personvernerklæringen Gjennomføre transaksjoner innen oppgitt leveringstid 7.2 Informasjonsplikt Vi informerer deg om: Gebyrer og valutakurs før gjennomføring av transaksjon Vesentlige endringer i vilkår eller tjeneste (minimum 2 måneder før ikrafttredelse) Driftsforstyrrelser som påvirker tjenesten Sikkerhetsrisikoer som kan berøre deg 7.3 Transaksjonsoversikt Vi gir deg tilgang til: Kvittering for hver gjennomført transaksjon Full transaksjonshistorikk i appen Mulighet for å laste ned transaksjonsdata (CSV/PDF) 8. Ansvarsbegrensning 8.1 Vårt ansvar Vi er ansvarlige for: Tap som skyldes feil fra vår side ved gjennomføring av betalingstransaksjoner, jf. betalingstjenesteloven kap. 3 Uautoriserte betalingstransaksjoner, med forbehold om punkt 8.2 Tap som skyldes manglende eller forsinket informasjon fra oss 8.2 Brukerens egenandel Ved uautoriserte betalingstransaksjoner gjelder følgende egenandel, jf. betalingstjenesteloven § 4-2: Inntil 450 kr dersom tapet skyldes tapt eller stjålet betalingsinstrument, eller at brukeren ikke har beskyttet personlige sikkerhetskjennetegn Fullt ansvar dersom tapet skyldes forsettlig svikaktig handling fra brukerens side 8.3 Begrensninger Vi er ikke ansvarlige for: Tap som skyldes force majeure (krig, naturkatastrofe, streik, myndighetsinngrep) Tap som skyldes feil hos tredjeparter utenfor vår kontroll (brukerens bank, korrespondentbanker, BankID) Indirekte tap (tapt fortjeneste, konsekvenstap) Tap som skyldes at brukeren ikke har overholdt sine plikter etter punkt 6 Forsinkelser som skyldes lovpålagt kundekontroll Valutakurssvingninger etter at transaksjon er bekreftet 8.4 Tilbakeføring av feilbetalinger Dersom du har overført penger til feil mottaker: Kontakt kundeservice umiddelbart Vi vil forsøke å tilbakeføre beløpet Tilbakeføring er avhengig av mottakerens bank og mottakerens samtykke Vi garanterer ikke tilbakeføring, men vil gjøre rimelige forsøk 9. Angrerett 9.1 14 dagers angrerett I henhold til angrerettloven (LOV-2014-06-20-27) § 22 har du rett til å angre på avtalen innen 14 dager etter at avtalen er inngått (registrering). 9.2 Unntak for gjennomførte transaksjoner Angreretten gjelder ikke for betalingstransaksjoner som allerede er gjennomført med ditt samtykke, jf. angrerettloven § 22 første ledd bokstav m. Når du bekrefter en betalingsoverføring eller QR-betaling, anses tjenesten som levert. 9.3 Utøvelse av angrerett For å benytte angreretten: Kontakt oss på support@getdrop.no innen 14 dager etter registrering Oppgi ditt navn og at du ønsker å benytte angreretten Du trenger ikke oppgi grunn Vi bekrefter mottak og sletter kontoen din 9.4 Angreskjema Standardisert angreskjema er tilgjengelig: I appen under Innstillinger > Angrerett På https://getdrop.no/angrerett Ved henvendelse til kundeservice 10. Endring av vilkår 10.1 Varsling Vi kan endre disse vilkårene. Vesentlige endringer varsles minimum 2 måneder før ikrafttredelse, jf. betalingstjenesteloven § 3-4. Varsling skjer via: Push-varsling i appen E-post til registrert e-postadresse Melding ved neste pålogging 10.2 Aksept Fortsatt bruk av tjenesten etter at endringene har trådt i kraft, anses som aksept av de nye vilkårene. 10.3 Avvisning Dersom du ikke aksepterer endringene, kan du si opp avtalen gebyrfritt før endringene trer i kraft. Eventuelle pågående transaksjoner fullføres etter eksisterende vilkår. 11. Oppsigelse og avslutning 11.1 Din rett til oppsigelse Du kan når som helst si opp avtalen og slette din Drop-konto: I appen under Innstillinger > Avslutt konto Ved å kontakte kundeservice 11.2 Vår rett til oppsigelse Vi kan si opp avtalen med 2 måneders varsel. Vi kan avslutte kundeforholdet med umiddelbar virkning dersom: Du har brutt disse vilkårene vesentlig Kundekontroll ikke kan gjennomføres tilfredsstillende Det foreligger mistanke om hvitvasking eller terrorfinansiering Lovgivning eller myndighetsbeslutning pålegger det Du har gitt uriktige opplysninger ved registrering 11.3 Ved oppsigelse Pågående transaksjoner fullføres Eventuelt tilgodehavende tilbakeføres til din bankkonto Personopplysninger behandles iht. personvernerklæringen (lovpålagt oppbevaring kan gjelde) Kontoen deaktiveres og deretter slettes 12. Klagebehandling 12.1 Intern klagebehandling Du kan klage på alle forhold knyttet til Drop-tjenesten. Se egen klagebehandlingsprosedyre i klagebehandling.md . Vi besvarer klager innen 15 virkedager, jf. PSD2 artikkel 101. 12.2 Ekstern klageadgang Dersom du ikke er fornøyd med vår behandling av klagen, kan du henvende deg til: Finansklagenemnda (FinKN) Postboks 53 Skøyen 0212 Oslo Telefon: 23 13 19 60 E-post: post@telefonklagenemnda.no Nettsted: https://www.finansklagenemnda.no Finansklagenemnda behandler tvister mellom forbrukere og finansforetak kostnadsfritt. 12.3 Finanstilsynet Klager på selve tjenesteleverandøren kan rettes til: Finanstilsynet Revierstredet 3 0151 Oslo Telefon: 22 93 98 00 Nettsted: https://www.finanstilsynet.no 12.4 Forbrukerrådet Forbrukerrådet Sandakerveien 138 0484 Oslo Telefon: 23 400 500 Nettsted: https://www.forbrukerradet.no 13. Lovvalg og verneting 13.1 Lovvalg Disse vilkårene er underlagt norsk lov. 13.2 Verneting Tvister som ikke løses gjennom klagebehandling eller nemnd, avgjøres av norske domstoler. Oslo tingrett er avtalt verneting for tvister mellom selskapet og profesjonelle brukere. For forbrukere gjelder vernetingsreglene i tvisteloven (LOV-2005-06-17-90) § 4-5. 14. Kontaktinformasjon 14.1 Kundeservice E-post: support@getdrop.no I appen: Chat under Hjelp > Kontakt oss Åpningstider: Mandag-fredag 08:00-20:00, lørdag 10:00-16:00 14.2 Klager E-post: klage@getdrop.no Post: ALAI Holding AS, [adresse], Norge Se punkt 12 for full klagebehandlingsprosedyre 14.3 Personvern E-post: personvern@getdrop.no Personvernombud: dpo@getdrop.no 15. Forholdet til andre dokumenter Disse brukervilkårene utfyller og må leses i sammenheng med: Personvernerklæring — informasjon om behandling av personopplysninger Prisliste — oppdatert gebyrstruktur (tilgjengelig i appen) Klagebehandlingsprosedyre — prosess for klager Ved motstrid mellom disse dokumentene gjelder brukervilkårene, med mindre annet følger av ufravikelig lovgivning. Disse brukervilkårene er sist oppdatert 12. februar 2026 og gjelder fra samme dato. Fee Schedule Gebyrskjema — Drop Dokument: Gebyrskjema for betalingstjenester Hjemmel: Betalingstjenesteloven (LOV-2023-06-16-39) s 3-23 Tjenesteleverandor: ALAI Holding AS, org.nr. 932 516 136 Tjeneste: Drop — betalingsformidling og pengeoverforinger Nettsted: https://getdrop.no Versjon: 1.0 Dato: 2026-02-17 Gyldig fra: 2026-02-17 1. Om dette dokumentet Dette gebyrskjemaet er utarbeidet i henhold til betalingstjenesteloven s 3-23, som krever at betalingstjenester oppgir alle gebyrer, kostnader og vilkaar paa en tydelig og lett forstaaelig maate foer avtaleinngaaelse og foer gjennomfoering av transaksjoner. Alle gebyrer vises ogsaa i Drop-appen foer du bekrefter en transaksjon. 2. Kontotjenester Tjeneste Gebyr Merknad Registrering av Drop-konto Gratis Ingen registreringskostnad Kontoadministrasjon Gratis Ingen maanedlig avgift Avslutning av konto Gratis Ingen avslutningsgebyr Saldovisning (AISP) Gratis Via Open Banking Transaksjonshistorikk Gratis Tilgjengelig i appen Nedlasting av transaksjonsdata (CSV/PDF) Gratis Push-varsler Gratis Kundeservicehenvendelser Gratis 3. Utenlandsoverforinger (remittance) Tjeneste Gebyr Merknad Utenlandsoverforing 0,5 % av beloep Minimum 5 NOK per transaksjon Valutakonvertering 0,5 % paslag paa markedskurs Kursen laases ved bekreftelse 3.1 Beregningseksempel Beloep Overforingsbeloep 5 000 NOK Transaksjonsgebyr (0,5 %) 25 NOK Valutapaslag (0,5 % paa kurs) Inkludert i vist kurs Total kostnad for Brukeren 5 025 NOK Mottaker faar Tilsvarende i lokal valuta etter konvertering 3.2 Valutakurs Valutakursen som vises i appen er basert paa markedskurs med et paslag paa 0,5 % Kursen laases i det oeyeblikket Brukeren bekrefter transaksjonen Oppdaterte kurser er alltid tilgjengelige i appen foer overforing 3.3 Leveringstid Typisk 1-3 virkedager, avhengig av mottakerland Estimert leveringstid vises i appen foer bekreftelse Drop er ikke ansvarlig for forsinkelser i mottakerens bank 4. QR-betalinger Tjeneste Gebyr Merknad QR-betaling hos forhandler 1 % av beloep Belastes forhandler/merchant Merk: QR-betalingsgebyret belastes forhandleren, ikke Brukeren. Brukeren betaler det beloepet som vises paa QR-koden uten tillegg. 5. Samlet gebyrsoversikt Tjeneste Brukergebyr Forhandlergebyr Kontoregistrering Gratis — Kontoadministrasjon Gratis — Utenlandsoverforing 0,5 % (min 5 NOK) — Valutakonvertering 0,5 % paslag — QR-betaling Gratis for bruker 1 % av beloep Saldovisning (AISP) Gratis — Push-varsler Gratis — Kundeservice Gratis — Kontoavslutning Gratis — 6. Gebyr ved spesielle hendelser Hendelse Gebyr Merknad Kansellering av transaksjon (foer gjennomfoering) Gratis Mulig inntil betalingsordren er sendt Retur av mislykket overforing Gratis Beloep tilbakefoeres automatisk Tilbakefoering ved feil Gratis Iht. betalingstjenesteloven kap. 4 Forsterket kundekontroll (EDD) Gratis Paakrevd av hvitvaskingsloven Utskrift av transaksjonshistorikk Gratis Tilgjengelig digitalt 7. Gebyrer vi IKKE tar For aa vaere tydelige: Drop tar ikke gebyr for: Aapning eller stenging av konto Maanedlig kontoforing Inaktivitet Mottak av penger SMS-varsler eller push-varsler Kundeservicehenvendelser Nedlasting av kvitteringer eller data 8. Endring av gebyrer Endringer i gebyrskjemaet varsles minimum 2 maaneder foer ikrafttredelse, jf. betalingstjenesteloven s 3-4 Varsling skjer via push-varsling i appen, e-post og melding ved neste paalogging Ved endring kan Brukeren si opp avtalen gebyrfritt foer endringene trer i kraft 9. Kontakt Spoersmaal om gebyrer kan rettes til: E-post: support@getdrop.no I appen: Hjelp > Kontakt oss Aapningstider: Mandag-fredag 08:00-20:00, loerdag 10:00-16:00 Endringslogg Versjon Dato Endring Godkjent av 1.0 2026-02-17 Forstegangs utarbeidelse Daglig leder Utarbeidet i henhold til betalingstjenesteloven (LOV-2023-06-16-39) s 3-23. Alle gebyrer vises ogsaa i Drop-appen foer transaksjon bekreftes. Framework Agreement Rammeavtale for betalingstjenester — Drop Avtaleparter: Tjenesteleverandor: ALAI Holding AS, org.nr. 932 516 136 ("Selskapet") Bruker: Den fysiske person som registrerer seg i Drop-tjenesten ("Brukeren") Tjeneste: Drop — betalingsformidling og pengeoverforinger Nettsted: https://getdrop.no Hjemmel: Betalingstjenesteloven (LOV-2023-06-16-39) s 3-1 Versjon: 1.0 Dato: 2026-02-17 1. Innledende bestemmelser 1.1 Avtalens formaal Denne rammeavtalen regulerer forholdet mellom Selskapet og Brukeren for betalingstjenestene som tilbys gjennom Drop, i henhold til betalingstjenesteloven s 3-1 flg. Avtalen utfyller de generelle brukervilkaarene. 1.2 Tjenestens karakter Drop er en betalingsinitieringstjeneste (PISP) og kontoinformasjonstjeneste (AISP) i henhold til PSD2 (direktiv (EU) 2015/2366). Drop holder aldri kundemidler. Alle betalinger initieres direkte fra Brukerens bankkonto gjennom Open Banking-grensesnitt. 1.3 Regulatorisk status Selskapet soeker konsesjon som betalingsforetak etter finansforetaksloven. Selskapet er underlagt tilsyn av Finanstilsynet. 2. Tjenestebeskrivelse (s 3-1 nr. 1) 2.1 Utenlandsoverforinger (remittance) Initiering av betalinger fra Brukerens norske bankkonto til mottakere i over 30 land Valutakonvertering fra NOK til mottakers valuta Typisk leveringstid 1-3 virkedager, avhengig av mottakerland og korridor Mottaker trenger ikke Drop-konto 2.2 QR-betalinger Betaling hos forhandlere ved skanning av QR-kode i Drop-appen Betalingen initieres fra Brukerens bankkonto (PISP) Umiddelbar bekreftelse og digital kvittering 2.3 Kontoinformasjon (AISP) Visning av saldo paa tilknyttede bankkontoer (krever eget samtykke) Transaksjonshistorikk for alle Drop-transaksjoner 3. Vilkaar for bruk (s 3-1 nr. 2) 3.1 Krav til Brukeren For aa benytte Drop maa Brukeren: Vaere minst 18 aar Ha gyldig norsk BankID Ha norsk mobilnummer (+47) Ha bankkonto i norsk bank som stoetter Open Banking (PSD2) Akseptere denne rammeavtalen og personvernerklaering 3.2 Registrering og kundekontroll Registrering krever identitetsverifisering gjennom BankID i henhold til hvitvaskingsloven ss 10-18. Selskapet kan be om tilleggsdokumentasjon ved forsterket kundekontroll (EDD). 4. Samtykke og autorisasjon av betalingsordre (s 3-1 nr. 3) 4.1 Autorisasjon En betalingsordre anses som autorisert naar Brukeren har: Valgt mottaker og beloep i appen Gjennomgaatt og godkjent totalkostnad (inkludert gebyrer og valutakurs) Bekreftet transaksjonen med BankID eller app-PIN 4.2 Tilbaketrekking En betalingsordre kan ikke trekkes tilbake etter at den er bekreftet av Brukeren, jf. betalingstjenesteloven s 4-20. 4.3 Beloepsgrenser Selskapet fastsetter transaksjonsgrenser som vises i appen. Grensene kan endres basert paa risikovurdering og kundekontrollnivaa. 5. Gjennomfoeringstid (s 3-1 nr. 4) 5.1 Utenlandsoverforinger Betalingsordren initieres innen 1 virkedag etter autorisasjon Total leveringstid avhenger av mottakerland: typisk 1-3 virkedager Estimert leveringstid vises i appen foer bekreftelse 5.2 QR-betalinger Betalingen initieres umiddelbart etter autorisasjon Bekreftelse til forhandler og Bruker: umiddelbart 6. Gebyrer og valutakurs (s 3-1 nr. 5, s 3-23) 6.1 Gebyrstruktur Alle gebyrer vises tydelig foer Brukeren bekrefter en transaksjon, i henhold til s 3-23. Tjeneste Gebyr Kontoregistrering Gratis Utenlandsoverforing 0,5 % av beloep (minimum 5 NOK) QR-betaling 1 % av beloep (belastes forhandler) Kontoinformasjon (AISP) Gratis Varsler og kvitteringer Gratis 6.2 Valutakurs Valutakursen inkluderer et paslag paa 0,5 % paa markedskurs Kursen laases ved Brukerens bekreftelse Oppdatert valutakurs er alltid tilgjengelig i appen 6.3 Total kostnad Total kostnad = Overforingsbeloep + Gebyr + Valutapaslag. Eksakt beregning vises i appen foer bekreftelse. 6.4 Endring av gebyrer Gebyrendringer varsles minimum 2 maaneder foer ikrafttredelse, jf. s 3-4. Se komplett gebyrskjema: gebyrskjema.md 7. Brukerens rettigheter og plikter (s 3-1 nr. 6) 7.1 Brukerens rettigheter Rett til informasjon om gebyrer og valutakurs foer gjennomfoering Rett til kvittering og transaksjonshistorikk Rett til aa sette egne forbruksgrenser Rett til aa sperre kontoen umiddelbart Rett til aa si opp avtalen naar som helst 7.2 Brukerens plikter Beskytte BankID og tilgangsopplysninger Oppgi korrekte opplysninger Melde fra umiddelbart ved uautorisert bruk Holde appen oppdatert Ikke benytte tjenesten til ulovlige formaal 8. Selskapets plikter (s 3-1 nr. 7) 8.1 Tjenesteleveranse Levere tjenesten i samsvar med avtalen Opprettholde hoey tilgjengelighet og sikkerhet Gjennomfoere transaksjoner innen oppgitt tid 8.2 Informasjonsplikt Gebyrer og vilkaar tilgjengelig foer avtaleinngaaelse Vesentlige endringer varsles minimum 2 maaneder foer ikrafttredelse Kvittering for hver gjennomfoert transaksjon 9. Ansvar for uautoriserte transaksjoner (s 3-1 nr. 8, s 4-2) 9.1 Selskapets ansvar Selskapet er ansvarlig for tap ved uautoriserte betalingstransaksjoner, med mindre tapet skyldes Brukerens forsett eller grove uaktsomhet. 9.2 Brukerens egenandel Inntil 450 kr ved tapt/stjaalet betalingsinstrument eller manglende beskyttelse av sikkerhetskjennetegn (s 4-2) Fullt ansvar ved forsettlig svikaktig handling 9.3 Varsling Brukeren maa varsle Selskapet uten ugrunnet opphold etter aa ha blitt kjent med uautorisert bruk. 10. Tilbakebetaling og feilrettinger (s 3-1 nr. 9) 10.1 Feil i transaksjoner Ved feil i gjennomfoering fra Selskapets side tilbakefoeres beloepet uten ugrunnet opphold. 10.2 Feilbetalinger Ved overforing til feil mottaker gjoer Selskapet rimelige forsoek paa tilbakefoering. 11. Sperring og begrensning (s 3-1 nr. 10) 11.1 Selskapets rett til sperring Selskapet kan sperre Brukerens konto ved: Mistanke om uautorisert bruk Mistanke om hvitvasking eller terrorfinansiering Paalegg fra myndigheter Vesentlig brudd paa avtalen 11.2 Varsling Ved sperring informeres Brukeren saa snart som mulig, med mindre lovhjemmel hindrer varsling. 12. Klagebehandling (s 3-1 nr. 11) 12.1 Intern klagebehandling Klager sendes til klage@getdrop.no eller via appen Besvares innen 15 virkedager (PSD2 art. 101) 12.2 Ekstern klageadgang Finansklagenemnda: finansklagenemnda.no Finanstilsynet: finanstilsynet.no Forbrukerraadet: forbrukerradet.no 13. Endring av avtalen (s 3-4) Vesentlige endringer varsles minimum 2 maaneder foer ikrafttredelse via push-varsling, e-post og melding ved neste paalogging. Ved avvisning kan Brukeren si opp gebyrfritt. 14. Oppsigelse (s 3-1 nr. 12) 14.1 Brukerens oppsigelse Brukeren kan naar som helst si opp gebyrfritt via appen eller kundeservice. 14.2 Selskapets oppsigelse 2 maaneders varsel. Umiddelbar oppsigelse ved vesentlig avtalebrudd, manglende KYC, mistanke om HV/TF, eller myndighetspaaelegg. 14.3 Oppgjoer Paagaaende transaksjoner fullfoeres. Tilgodehavende tilbakefoeres. Kontoen deaktiveres og slettes. 15. Kommunikasjon (s 3-1 nr. 13) Kommunikasjonssprak: norsk (bokmal) E-post: support@getdrop.no I appen: Chat under Hjelp > Kontakt oss Klager: klage@getdrop.no Kundeservice: mandag-fredag 08:00-20:00, loerdag 10:00-16:00 16. Lovvalg og verneting (s 3-1 nr. 14) Avtalen er underlagt norsk lov. Oslo tingrett er avtalt verneting for profesjonelle brukere. For forbrukere gjelder tvisteloven s 4-5. 17. Forholdet til andre dokumenter Denne rammeavtalen utfyller: Brukervilkaar — generelle vilkaar Personvernerklaering — behandling av personopplysninger Gebyrskjema — oppdatert gebyrstruktur (s 3-23) Klagebehandlingsprosedyre — prosess for klager Ved motstrid gjelder denne rammeavtalen, med mindre annet foelger av ufravikelig lovgivning. Endringslogg Versjon Dato Endring Godkjent av 1.0 2026-02-17 Forstegangs utarbeidelse Daglig leder Utarbeidet i henhold til betalingstjenesteloven (LOV-2023-06-16-39) s 3-1 flg. Legal Overview Legal Resources Legal resources for Drop project: contracts, compliance, regulatory documentation. Agreements & Meetings Partner meeting notes, agreements, and negotiations Neonomics Meeting Prep (Feb 2026) Meeting Prep: Trine Stefferud — Neonomics Partnership Dato: Neste uke (TBD) Kontakt: Trine Stefferud — Head of Partnerships, Neonomics Email: tstefferud@neonomics.io MC Task: #1534 Platform: Microsoft Teams (link fra original booking) Bakgrunn Drop trenger AISP + PISP for a fungere (ref ADR-003). Alternativene: Egen PSD2-lisens — 6-12 mnd, EUR 20-50K kapital, direkte tilsyn Agent under lisensiert PI — registrering via PI, ingen kapital, raskere Neonomics er lisensiert PI + PISP + AISP hos Finanstilsynet, passportert i EU. 3,500+ banker, 95%+ nordisk dekning. Agent-modellen = Drop opererer under deres lisens. Neonomics — Fakta Grunnlagt: 2017, Oslo Ansatte: 65+ (20+ nasjonaliteter) Finansiering: $50M+ privat Lisens: PI + PISP + AISP (Finanstilsynet), EU-passportert Dekning: 3,500+ banker, 30 land, 95%+ Norden Interim CEO: Alfonso Munoz Kunder: Axactor, Digipost, Lowell, Kredinor, Worldline Produkter: Nello Pay — Pay by Bank (A2A), QR, SMS, email. <30s, 90% success, 80% billigere enn kort. Nello Data — Kontodata, balanse, transaksjoner, kategorisering, inntektsverifikasjon. Nello AI — Prediktiv finans, InSight, InterAct. Hva Drop trenger fra Neonomics Drop-behov Neonomics-produkt Prioritet Bankbalanse Nello Data (AISP) P0 Remittance Nello Pay / PISP P0 QR-betaling Nello Pay QR-link P0 BankID/SCA Plattform-integrert P0 Transaksjonshistorikk Nello Data P1 Inntektsverifikasjon Nello Data P2 PSD2 Agent-modell Aspekt Agent (Drop) Egen PI-lisens Autorisasjon Ingen — PI registrerer Full soknad Kapitalkrav Ingen EUR 20-50K Tidsramme Uker 6-12 mnd Liability Neonomics Drop AML/CFT Neonomics Drop Tilsyn Indirekte Direkte Pluss: Raskere go-to-market, ingen lisenskostnad. Minus: Avhengig av Neonomics. Mindre kontroll. Sporsmal til Trine 1. Agent/Partner-modell Tilbyr dere agent-modell der Drop opererer under deres PI-lisens? Registreringsprosess og tidsramme? Krav til agenten (compliance, teknisk, finansielt)? AISP + PISP som agent, eller bare en? 2. Teknisk integrasjon Sandbox-tilgang — umiddelbart? BankID-flow — Neonomics handterer SCA? Norske banker — DNB, Nordea, SpareBank 1, Sbanken? Betalinger til 30+ land (remittance)? QR-koder for butikkbetaling? Embedded vs redirect flow? 3. Remittance-korridorer PISP utenfor SEPA (Balkan, Pakistan, Tyrkia)? Partnere for cross-border? Valutaveksling? 4. Pricing Per-transaksjon AISP + PISP? Setup/manadskostnad? Volumrabatter (mal 50K+ tx/mnd)? Rev-share for agenter? 5. Juridisk AML/KYC — hvem handterer? DPA / GDPR for kontodata? Hva ved lisenstap? Oppsigelsestid? 6. Go-to-market Referansekunder (fintech-apper)? Tid fra avtale til produksjon? Dedikert partner manager? Drop i tall Marked: Alle i Norge/Skandinavia Remittance: 5,7 mrd NOK/ar Merchants: 30,000+ innvandrereide bedrifter Modell: Pass-through PSD2, holder aldri penger Status: MVP deployet, venter bankpartner Mal Y1: 200 merchants, 10K+ brukere Forventet utfall Bekreftelse om agent-modell Prisindikasjon (ballpark) Sandbox-tilgang Neste steg: NDA -> POC -> avtale Ref: ADR-003-psd2-passthrough-model.md