Legal & Compliance

Regulatory framework, privacy, AML, DPAs, policies, terms

Regulatory Framework

Regulatory Framework

Regulatory Map

Drop Regulatory Map v2

Norwegian Financial Services Regulatory Framework

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

Table of Contents

  1. Finanstilsynet Licensing
  2. Betalingstjenesteloven / PSD2
  3. Hvitvaskingsloven / AML
  4. Personopplysningsloven / GDPR
  5. IKT-forskriften / DORA
  6. Finansforetaksloven
  7. Valutaregisterloven
  8. Consumer Protection
  9. DORA Timeline for Norway
  10. Regulatory Priority Matrix

1. Finanstilsynet Licensing

Applicable Law

License Options for Drop

Option A: Begrenset betalingsforetak (Limited Payment Institution)

Law: Betalingstjenesteloven (LOV-2018-11-23-85) SS 2-10c

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

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

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

Option B: Ordinaert betalingsforetak (Full Payment Institution)

Law: Betalingstjenesteloven SS 2-3 to SS 2-10

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

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

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

Option C: Agent Model (under existing licensee)

Law: Betalingstjenesteloven SS 2-12

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

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

Potential partners for agent model:

Required Documents for Licensing Application

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

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

2. Betalingstjenesteloven / PSD2

Applicable Law

Strong Customer Authentication (SCA)

Law: Betalingstjenesteloven SS 4-28, SS 4-29; Delegated Regulation (EU) 2018/389

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

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

Required implementation:

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

Open Banking (PSD2 Access to Account)

Law: Betalingstjenesteloven SS 4-40 to SS 4-46

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

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

Consumer Protection (PSD2)

Law: Betalingstjenesteloven kapittel 3 and 4

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

Required documents:

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

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

3. Hvitvaskingsloven / AML

Applicable Law

Customer Due Diligence (KYC)

Law: Hvitvaskingsloven SS 10 to SS 18

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

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

Required implementation:

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

Transaction Monitoring

Law: Hvitvaskingsloven SS 24, SS 25

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

Transaction monitoring rules to implement:

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

PEP and Sanctions Screening

Law: Hvitvaskingsloven SS 18; Various sanctions forskrifter

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

Required integrations:

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

AML Risk Assessment

Law: Hvitvaskingsloven SS 6, SS 7

Drop must conduct and document a risk assessment covering:

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

Required documents:

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

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

4. Personopplysningsloven / GDPR

Applicable Law

Data Processing Requirements

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

DPIA (Data Protection Impact Assessment)

GDPR Article 35; Datatilsynet guidelines

A DPIA is MANDATORY for Drop because:

  1. Processing of financial data at scale
  2. Systematic monitoring of individuals (transaction monitoring)
  3. Cross-border data transfers (remittance to 30+ countries)
  4. Vulnerable groups potential (newly arrived residents, etc.)
  5. New technology use (mobile payments, QR)
DPIA Requirement What Drop Must Document
Processing description All personal data flows in the app
Necessity and proportionality Why each data element is needed
Risk assessment Risks to data subjects from processing
Mitigating measures Technical and organizational safeguards
Datatilsynet consultation Required if residual risk remains high after mitigations (Art. 36)

Cross-Border Transfers

GDPR Chapter V (Art. 44-49)

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

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

Required Documents

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

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

5. IKT-forskriften / DORA

Applicable Law

Current IKT-forskriften Requirements

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

DORA Requirements (coming for Norway)

Regulation (EU) 2022/2554 -- Applies to payment institutions

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

Required Documents

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

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

6. Finansforetaksloven

Applicable Law

Governance Requirements

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

Capital Requirements

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

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

Required Documents

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

Priority: CRITICAL -- Required for license application

7. Valutaregisterloven

Applicable Law

Cross-Border Reporting Requirements

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

Implementation requirements:

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

Required Documents

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

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

8. Consumer Protection

Applicable Law

Angrerettloven (Right of Withdrawal)

Sections relevant to financial services:

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

Finansavtaleloven (Financial Contracts Act)

New version effective 2023 -- significant consumer protection enhancements

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

Finansklagenemnda (Financial Complaints Board)

Law: Finansklagenemndloven (LOV-2016-06-17-29)

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

Markedsfoeringsloven (Marketing)

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

Required Documents

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

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

9. DORA Timeline for Norway

Background

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

Expected Timeline

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

Current Status (February 2026)

Practical Implication for Drop

10. Regulatory Priority Matrix

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

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

Phase 2: Launch + 6 Months

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

Phase 3: Scaling (12+ Months)

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

Summary: Required Document Inventory

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

End of Drop Regulatory Map v2

Regulatory Framework

Compliance Gap Analysis

Drop Gap Analysis v2

Regulatory Compliance Gap Assessment

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

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

Executive Summary

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

Overall compliance readiness: 8/100

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

1. Licensing Gap Analysis

Current State

Gap Table

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

Recommendation

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

2. PSD2 / Betalingstjenesteloven Gap Analysis

Current State (from code review)

Gap Table

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

Technical Gaps in Code

File: lib/auth.ts

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

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

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

3. AML / Hvitvaskingsloven Gap Analysis

Current State (from code review)

Gap Table

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

Technical Gaps in Code

File: lib/db.ts

File: lib/services/mock-sumsub.ts

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

Database schema missing tables:

4. GDPR / Personopplysningsloven Gap Analysis

Current State (from code review)

Gap Table

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

Technical Gaps in Code

File: lib/db.ts

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

Cross-border transfer data flow:

5. IKT-forskriften / DORA Gap Analysis

Current State (from security rapport and code review)

Gap Table

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

Security Rapport Findings Impact on Compliance

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

6. Finansforetaksloven / Governance Gap Analysis

Current State

Gap Table

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

7. Valutaregisterloven Gap Analysis

Current State

Gap Table

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

Technical Gaps in Code

File: lib/db.ts

8. Consumer Protection Gap Analysis

Current State

Gap Table

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

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

Documents That Exist

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

Documents That Are Completely Missing

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

10. Technical Gap Summary

Database Schema Gaps

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

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

API Route Gaps

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

Infrastructure Gaps

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

Phase 0: Documentation Sprint (Weeks 1-4)

No code changes. Produce regulatory documents.

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

Phase 1: Critical Technical (Weeks 3-8)

Code changes to close critical security and compliance gaps.

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

Phase 2: Compliance Infrastructure (Weeks 6-12)

Build compliance operational capability.

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

Phase 3: License Application (Weeks 8-16)

Submit license application with supporting documentation.

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

Alternative Fast Track: Agent Model

If speed to market is critical:

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

12. Risk Summary

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

End of Drop Gap Analysis v2

Regulatory Framework

License Application Prep

Konsesjonssøknad — Forberedelse

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

1. Konsesjonskrav — oversikt

1.1 Type konsesjon

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

Drop tilbyr to typer betalingstjenester:

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

1.2 Relevante konsesjonstyper

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

1.3 Anbefalt strategi

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

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

2. Kapitalkrav

2.1 Startkapital

Jf. finansforetaksloven §3-4 og CRD-kravene:

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

2.2 Løpende kapitalkrav

Jf. kapitalkravsforskriften for betalingsforetak:

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

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

2.3 Sikring av kundemidler

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

3. Organisatoriske krav

3.1 Ledelse og styre — egnethetsvurdering

Jf. finansforetaksloven §3-5 (egnethetskrav):

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

3.2 Egnethetskrav — «Fit & Proper»

For styremedlemmer, daglig leder og andre nøkkelpersoner, jf. finansforetaksloven §3-5:

Se eget dokument: egnethetsvurdering.md

3.3 Organisasjonsstruktur — minimumskrav

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

4. Dokumentasjonskrav for søknaden

4.1 Sjekkliste — vedlegg til søknad

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

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

4.2 Tilleggskrav for PISP/AISP (PSD2)

5. Prosess og tidslinje

5.1 Søknadsprosess hos Finanstilsynet

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

5.2 Milepæler

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

M = måned fra prosjektstart

5.3 Kostnadsoversikt

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

6. Regulatorisk landskap

6.1 Relevant lovgivning

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

6.2 Tilsynsmyndigheter

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

7. Risikoer ved søknadsprosessen

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

8. Anbefalinger

8.1 Umiddelbare tiltak

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

8.2 Parallelle løp

9. Endringslogg

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

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

Regulatory Framework

Business Plan (Regulatory)

Virksomhetsplan — Drop (ALAI Holding AS)

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

1. Selskapsinformasjon

1.1 Oversikt

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

1.2 Eierstruktur

Eier Eierandel Type
Alem Cerimagic 100% Privatperson

1.3 Konsernstruktur

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

2. Virksomhetsbeskrivelse

2.1 Forretningside

Drop er en betalingsapp for alle innbyggere i Norge og Skandinavia som tilbyr to kjernetjenester:

  1. Pengeoverføringer til utlandet (remittance) — rimeligere grensekryssende overføringer til 30+ land
  2. QR-betalinger i butikk — betalinger via QR-kode med lavere gebyrer enn eksisterende løsninger

2.2 Visjon

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

2.3 Misjon

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

2.4 Verdier

3. Forretningsmodell

3.1 Pass-through-modell (PSD2)

Drop opererer en pass-through-modell. Selskapet holder aldri kundemidler:

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

3.2 Tjenester

3.2.1 Pengeoverføringer (Remittance)

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

3.2.2 QR-betalinger

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

3.3 Autentisering og sikkerhet

4. Målgruppe og marked

4.1 Målgruppe

Drop retter seg mot alle innbyggere i Norge og Skandinavia som ønsker:

  1. Rimeligere måter å sende penger til utlandet
  2. Billigere betalingsløsninger i butikk
  3. En moderne betalingsapp med gode brukeropplevelser

4.2 Kundesegmenter

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

4.3 Markedsstørrelse

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

4.4 Konkurransesituasjon

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

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

5. Organisasjonsplan

5.1 Organisasjonsstruktur (ved konsesjonssøknad)

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

5.2 Bemanning — planlagt utvikling

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

5.3 Outsourcing

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

6. Teknisk plattform

6.1 Arkitektur

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

6.2 Sikkerhet

7. Inntektsmodell

7.1 Inntektsstrømmer

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

7.2 Prissammenligning

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

8. Finansielle prognoser (3 år)

8.1 Forutsetninger

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

8.2 Resultatprognose

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

8.3 Likviditetsprognose

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

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

8.4 Kapitalbehov

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

9. Risikoer

9.1 Strategiske risikoer

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

9.2 Operasjonelle risikoer

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

10. Lanseringsstrategi

10.1 Faser

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

10.2 Go-to-market

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

11. Compliance-rammeverk

11.1 Oversikt

Selskapet har utarbeidet følgende compliance-dokumentasjon:

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

11.2 Tilsynsrapportering

Selskapet vil rapportere til følgende myndigheter:

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

12. Milepælsplan

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

13. Endringslogg

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

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

Regulatory Framework

Compliance Gap (Feb 2026)

Drop Compliance Gap Analysis — Overnight Sprint

2026-02-16

TL;DR

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

We have more than we think:

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

GAP MATRIX: IMAMO vs TREBA

BACKEND

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

FRONTEND

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

MOBILE / PWA

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

CANNOT DO TONIGHT (Requires External)

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

OVERNIGHT SPRINT PLAN

Phase A — Database Schema (foundation, do first)

Files: src/lib/db.ts Tasks: B2, B3, B10

Add to users table:

Add to transactions table:

New tables:

Phase B — Backend APIs (compliance endpoints)

Tasks: B1, B4, B5, B6, B7, B8, B9, B11, B12, B13, B14

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

Phase C — Frontend UI (compliance screens)

Tasks: F1-F11

TASK SPLIT FOR AGENTS

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

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

AFTER TONIGHT

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

Remaining blockers (external):

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

Privacy & Data Protection

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:

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

4.2 Kontaktopplysninger

4.3 Finansielle opplysninger

4.4 Tekniske opplysninger

4.5 Bruksmønster

4.6 KYC/AML-relaterte opplysninger

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)

5.2 Rettslig forpliktelse — GDPR art. 6(1)(c)

5.3 Samtykke — GDPR art. 6(1)(a)

5.4 Berettiget interesse — GDPR art. 6(1)(f)

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

Regulatoriske myndigheter (rettslig forpliktelse):

Tjenesteleverandører (databehandlere):

7.2 Databehandleravtaler

Alle databehandlere har inngått databehandleravtale (DPA) i samsvar med GDPR artikkel 28. Databehandleravtalene regulerer:

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:

Overføringsgrunnlag:

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:

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

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:

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:

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:

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:

Se vår IKT-sikkerhetspolicy for utfyllende informasjon.

13. Personvernbrudd

Ved brudd på personopplysningssikkerheten vil vi:

  1. 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.
  2. Informere berørte registrerte uten ugrunnet opphold dersom bruddet sannsynligvis medfører høy risiko, jf. GDPR artikkel 34.
  3. 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

14.2 Analytiske cookies (krever samtykke)

14.3 Markedsføringscookies (krever samtykke)

15. Endringer i erklæringen

Vi kan oppdatere denne personvernerklæringen ved behov. Ved vesentlige endringer vil vi informere deg via:

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:

Denne personvernerklæringen er sist oppdatert 2. mars 2026.

Privacy & Data Protection

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

1.3 Omfang

Denne DPIA dekker all behandling av personopplysninger i Drop-tjenesten, inkludert:

2. Systematisk beskrivelse av behandlingen

2.1 Tjenestebeskrivelse

Drop er en betalingstjeneste for alle innbyggere i Norge som tilbyr:

  1. Utenlandsoverføringer (remittance): Send penger til mottakere i 30+ land. Mottaker trenger ikke Drop-konto.
  2. QR-betalinger: Betal hos forhandlere ved å skanne QR-kode. Lavere gebyrer enn tradisjonelle løsninger.
  3. Lommebok: Betalinger og daglig bruk.

2.2 Teknisk arkitektur

Drop opererer etter en pass-through-modell:

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

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

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

4.2 Identifiserte risikoer

R1: Uautorisert tilgang til finansielle data

R2: Datalekkasje ved sikkerhetsbrudd

R3: Ulovlig profilering gjennom transaksjonsdata

R4: Manglende kontroll ved tredjelandsoverføringer

R5: Feilaktig avvisning av transaksjoner (svindeldeteksjon)

R6: Manglende sletting etter oppbevaringstidens utløp

R7: Kompromittering av BankID-sesjon

R8: Datatilgang fra tredjelandsmyndigheter

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

6.3 Personvernrisikoer

6.4 Tiltak

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:

  1. Lovgivning: Har myndighetene vid tilgang til kommunikasjonsdata?
  2. Praktisk erfaring: Har vi mottatt forespørsler fra myndigheter?
  3. Dataminimering: Hvilke data overføres, og er de nødvendige?
  4. Tekniske tiltak: Kryptering, pseudonymisering, andre beskyttelser
  5. 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:

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

8.2 Ekstern konsultasjon

8.3 Brukermedvirkning

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:

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.

Privacy & Data Protection

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:

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.

Privacy & Data Protection

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:

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

  1. Ledelsesansvar: Styret og ledelsen har det overordnede ansvaret for all utkontraktering, jf. DORA art. 28(2). Utkontraktering fritar ikke selskapet fra regulatoriske forpliktelser.
  2. Risikostyring: All utkontraktering vurderes gjennom vårt IKT-risikostyringsrammeverk.
  3. Proporsjonalitet: Krav til leverandørstyring er proporsjonale med tjenestens kritikalitet.
  4. Konsentrasjonrisiko: Vi vurderer og unngår uhensiktsmessig konsentrasjon hos enkeltleverandører.
  5. 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:

2.3 Hva som ikke kan utkontrakteres

Følgende kan ikke utkontrakteres:

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

3.3 Register over utkontrakterte tjenester

Vi vedlikeholder et oppdatert register over alle utkontrakterte IKT-tjenester, jf. DORA art. 28(3), som minimum inneholder:

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

Standard tjenester — forenklet due diligence

4.2 Risikovurdering

Due diligence resulterer i en risikovurdering som dokumenterer:

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

5.1.2 Sikkerhet

5.1.3 Databehandling

5.1.4 Tilsyn og revisjon

5.1.5 Underleverandører

5.1.6 Kontinuitet og exit

5.1.7 Oppsigelse

5.2 Tilleggskrav for kritiske tjenester

For kritiske tjenester kreves i tillegg:

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:

6.3 Hendelseshåndtering

Ved hendelser hos leverandør:

  1. Leverandør varsler oss iht. avtalt prosedyre
  2. Vi vurderer konsekvens for Drop-tjenesten
  3. Vi aktiverer interne prosedyrer ved behov (se hendelseshaandtering.md)
  4. Vi rapporterer til Finanstilsynet ved vesentlig IKT-hendelse
  5. 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:

7.3 Spesifikke exit-strategier

Open Banking-leverandør (Kritisk)

Skyinfrastruktur (Kritisk)

BankID (Kritisk)

7.4 Testing av exit-strategi

8. Finanstilsynet — varsling og rapportering

8.1 Varsling

I henhold til Finanstilsynets retningslinjer og DORA varsles Finanstilsynet:

8.2 Informasjon til Finanstilsynet

Varsling inneholder:

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:

9.2 Mitigering

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

10.3 Andre linje — kontroll og risikostyring

10.4 Tredje linje — uavhengig kontroll

11. Revisjon og oppdatering

11.1 Gjennomgang

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

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:

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:

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

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

4.3.2 EDD-tiltak

4.4 PEP-screening — §18

4.4.1 Hvem er PEP

Politisk eksponerte personer inkluderer:

4.4.2 PEP-prosedyre

  1. Screening ved onboarding: Automatisk PEP-sjekk mot anerkjent database (f.eks. Refinitiv World-Check, Dow Jones)
  2. Løpende screening: Automatisk re-screening ved endringer i PEP-lister
  3. Positive treff: Manuell vurdering av hvitvaskingsansvarlig
  4. EDD ved bekreftet PEP: Tilleggsdokumentasjon, godkjenning av daglig leder, hyppigere overvåking

4.5 Sanksjonsscreening

4.5.1 Lister som sjekkes

4.5.2 Prosedyre

  1. Ved onboarding: Automatisk screening av kundens navn og fødselsdato mot alle sanksjonslister
  2. Ved hver transaksjon: Automatisk screening av mottaker mot sanksjonslister
  3. Positive treff: Transaksjon fryses automatisk. Hvitvaskingsansvarlig varsles.
  4. Bekreftet treff: Transaksjon avvises. Rapportering til Utenriksdepartementet og EFE.
  5. 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:

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

5.3 Oppdatering av kundeinformasjon

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:

  1. Gjennomføre nærmere undersøkelser — innhente tilleggsinformasjon om kundens identitet, midlenes opprinnelse, transaksjonens formål
  2. Dokumentere undersøkelsen — alle funn, vurderinger og konklusjoner nedtegnes
  3. Konkludere — enten avkreftes mistanken (dokumenteres) eller bekreftes (rapportering)

6.2 Rapportering til Økokrim/EFE

Dersom undersøkelsen ikke avkrefter mistanken:

  1. Rapport sendes til EFE (Enheten for finansiell etterretning) via Altinn-portalen
  2. Rapporten skal inneholde:
    • Identifikasjon av kunden (navn, fødselsnummer, adresse)
    • Beskrivelse av transaksjonen(e)
    • Grunnlag for mistanken
    • Resultater av undersøkelsen
    • Relevant dokumentasjon
  3. Tidsfrist: Uten ugrunnet opphold etter at undersøkelsen er fullført
  4. Konfidensialitet: Kunden skal ikke underrettes om at rapport er sendt (tipping off-forbud, §28)
  5. Transaksjoner kan holdes tilbake i inntil 2 virkedager etter rapportering, jf. betalingssystemloven

6.3 Statistikk og oppfølging

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

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:

9.2 Daglig leder

9.3 Styret

9.4 Alle ansatte

10. Opplæring — §36

10.1 Obligatorisk opplæring

Alle ansatte med kundetilgangs- eller transaksjonsrelaterte oppgaver skal gjennomføre opplæring i:

10.2 Frekvens

10.3 Dokumentasjon

11. Internkontroll og revisjon — §37

11.1 Internkontroll

11.2 Uavhengig gjennomgang

11.3 Avviksbehandling

12. Behandling av avviste eller avsluttede kundeforhold

12.1 Avvisning

Dersom kundetiltak ikke kan gjennomføres tilfredsstillende, jf. §21:

12.2 Avslutning av kundeforhold

13. Tekniske tiltak

13.1 Automatiserte kontroller i Drop-appen

13.2 Manuelt dashboard

14. Forholdet til personopplysningsloven (GDPR)

14.1 Behandlingsgrunnlag

14.2 Personvernserklæring

15. Endringslogg

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

16. Vedlegg

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

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

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:

  1. Pengeoverføringer (remittance): Grensekryssende overføringer fra Norge til 30+ land
  2. QR-betalinger: Betalinger i butikk via QR-kode, tilgjengelig for alle merchanter

2.2 Forretningsmodell

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

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:

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:

  1. BankID-verifisering — sikrer høyt identitetsnivå for alle kunder
  2. Pass-through-modell — Drop holder aldri kundemidler, noe som begrenser misbruksmuligheter
  3. Korridorbasert risikovurdering — differensierte tiltak etter mottakerland
  4. 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.

AML & Risk

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:

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:

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:

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:

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:

7.2 Oppbevaringstid

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:

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

Data Processing Agreements

DPA Template

Data Processing Agreement (DPA)

Between:

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

  1. Encryption: [e.g., TLS 1.3 in transit, AES-256 at rest]
  2. Access Control: [e.g., RBAC, MFA, least privilege]
  3. Logging: [e.g., audit logging for all data access]
  4. Backup: [e.g., daily encrypted backups]
  5. Incident Response: [e.g., documented plan]
  6. 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: ___________________________

Data Processing Agreements

DPA — Swan

Data Processing Agreement — Swan

Between:

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)

  1. Encryption: TLS 1.3 in transit; AES-256 at rest; HSM for cryptographic key management
  2. Access Control: RBAC with MFA, segregation of duties, principle of least privilege
  3. Data Residency: EU data centers (France) — all data processed within EEA
  4. Logging: Complete audit trail for all financial transactions and API access
  5. Data Retention: Transaction data retained per Controller instructions (aligned with bokfoeringsloven 5-year requirement); account data retained during relationship + regulatory period
  6. Incident Response: 24/7 security operations, breach notification within 24 hours
  7. Certifications: PCI DSS Level 1, licensed by ACPR (French banking regulator), PSD2 compliant
  8. Financial Regulations: Compliant with PSD2, EMD2, and applicable French/EU banking regulations

Additional Swan-Specific Terms

Regulatory Compliance

Payment Data

Data Subject Rights

Business Continuity

Signatures

Data Controller — ALAI Holding AS

Name: ___________________________ Title: ___________________________ Date: ___________________________

Data Processor — Swan SAS

Name: ___________________________ Title: ___________________________ Date: ___________________________

Data Processing Agreements

DPA — Sumsub

Data Processing Agreement — Sumsub

Between:

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)

  1. Encryption: TLS 1.3 in transit; AES-256 at rest for all stored documents and data
  2. Access Control: Role-based access, MFA for all staff, principle of least privilege
  3. Data Residency: EU data centers (primary processing within EEA)
  4. Logging: Comprehensive audit trail for all verification events and data access
  5. Data Retention: Verification data retained for the period specified by Controller (aligned with hvitvaskingsloven 5-year requirement), then securely deleted
  6. Incident Response: 24/7 security operations, breach notification within 24 hours
  7. Certifications: SOC 2 Type II, ISO 27001, PCI DSS compliant
  8. Sub-processors: List maintained and available at Sumsub's sub-processor page; 30-day advance notice of changes

Additional Sumsub-Specific Terms

Biometric Data

Data Subject Rights

Transfer Impact Assessment

Signatures

Data Controller — ALAI Holding AS

Name: ___________________________ Title: ___________________________ Date: ___________________________

Data Processor — Sumsub Limited

Name: ___________________________ Title: ___________________________ Date: ___________________________

Data Processing Agreements

DPA — Sentry

Data Processing Agreement — Sentry

Between:

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)

  1. Encryption: TLS 1.3 in transit; AES-256 at rest
  2. Access Control: SSO/SAML, RBAC, MFA enforcement, IP allowlisting available
  3. Data Residency: EU data region available (selected for Drop); data stored in EU
  4. Logging: Access audit logs available via Sentry dashboard
  5. Data Retention: Configurable retention (Controller sets to 90 days for error data); automatically purged after retention period
  6. Incident Response: Sentry security incident response per SOC 2 procedures
  7. Certifications: SOC 2 Type II
  8. 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:

Data Minimization

Data Subject Rights

Spike Protection

Signatures

Data Controller — ALAI Holding AS

Name: ___________________________ Title: ___________________________ Date: ___________________________

Data Processor — Functional Software, Inc. dba Sentry

Name: ___________________________ Title: ___________________________ Date: ___________________________

Policies & Internal Controls

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:

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:

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

3. IKT-risikostyringsrammeverk — DORA art. 6

3.1 Rammeverk

IKT-risikostyring følger et strukturert rammeverk basert på:

3.2 Risikovurdering

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:

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

5. Tilgangskontroll — DORA art. 9(4)

5.1 Tilgangsprinsipper

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:

5.4 Tilgangsgjennomgang

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

7. Applikasjonssikkerhet — OWASP

7.1 Sikker utviklingslivssyklus (SSDLC)

Alle utviklingsaktiviteter følger en sikker utviklingslivssyklus:

  1. Kravfase: Sikkerhets- og personvernkrav defineres
  2. Design: Trusselmodellering (STRIDE) gjennomføres
  3. Implementering: Sikre kodestandarder, code review
  4. Testing: Sikkerhetstesting (SAST, DAST, avhengighetsskanning)
  5. Lansering: Penetrasjonstesting før produksjonssetting
  6. 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:

8. Nettverkssikkerhet

8.1 Nettverksarkitektur

8.2 Brannmur og filtrering

8.3 Overvåking

9. Hendelsesdeteksjon og -overvåking — DORA art. 10

9.1 Overvåkingssystem

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

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

11.3 Oppfølging av funn

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

12.3 RTO og RPO

Se beredskapsplan.md for detaljerte RTO/RPO-krav per system.

13. Fysisk sikkerhet

13.1 Datasentre

13.2 Utviklingsmiljø

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

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:

16. Kontinuitetsplanlegging — DORA art. 11

Se separat dokument: beredskapsplan.md for detaljert kontinuitetsplan.

Denne IKT-sikkerhetspolicyen understøtter kontinuitetsplanlegging ved å sikre:

17. Revisjon og oppdatering

17.1 Gjennomgang

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

Denne IKT-sikkerhetspolicyen er eid av CISO og godkjent av styret i ALAI Holding AS.

Policies & Internal Controls

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:

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:

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:

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:

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:

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:

3.3 Hvitvaskingsansvarlig / Chief Compliance Officer

Ansvar:

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

  1. Identifisering: Kartlegge relevante risikoer per kategori
  2. Vurdering: Sannsynlighet x konsekvens (skala 1-4)
  3. Tiltak: Definere risikoreduserende tiltak
  4. Overvåking: Løpende overvåking av risikoindikatorer
  5. Rapportering: Kvartalsvise risikorapporter til styret
  6. 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:

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:

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:

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:

  1. Dokumenteres med beskrivelse og begrunnelse
  2. Testes i staging-miljø
  3. Godkjennes av tech lead og compliance (ved regelverksrelevante endringer)
  4. Rulles ut med rollback-plan
  5. 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.

Policies & Internal Controls

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:

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:

  1. Automatisert varsling til vaktteam via definerte kanaler
  2. Vaktteamet foretar innledende vurdering innen 15 minutter
  3. Hendelsen registreres i hendelseshåndteringssystemet
  4. Innledende klassifisering gjennomføres (se seksjon 3)
  5. 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):

Responstid: Umiddelbart Rapportering: Finanstilsynet innen 4 timer (initialrapport)

P2 — Høy

Kriterier (ett eller flere):

Responstid: Innen 30 minutter Rapportering: Finanstilsynet innen 4 timer dersom hendelsen anses som vesentlig

P3 — Middels

Kriterier (ett eller flere):

Responstid: Innen 2 timer Rapportering: Intern rapportering, Finanstilsynet ved behov

P4 — Lav

Kriterier (ett eller flere):

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:

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

5.2 Fase 2: Containment (Inneslutning)

Kortsiktig containment:

Langsiktig containment:

5.3 Fase 3: Eradication (Fjerning)

5.4 Fase 4: Recovery (Gjenoppretting)

5.5 Fase 5: Lessons Learned (Lærdommer)

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:

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:

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

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

Varsling inneholder:

Varsling skjer via:

8. Dokumentasjon

8.1 Hendelseslogg

Alle hendelser dokumenteres med:

8.2 Bevissikring

Ved sikkerhetshendelser (P1/P2):

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:

9.2 Deling

I henhold til DORA art. 23 deltar vi i informasjonsdeling om cybertrusler:

9.3 Bruk

Trusseletterretning brukes til å:

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

10.3 Oppfølging av forbedringstiltak

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

11.3 Evaluering

Alle øvelser evalueres med:

12. Revisjon og oppdatering

12.1 Gjennomgang

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

Vedlegg C: Sjekklister per hendelsestype

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.

Policies & Internal Controls

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:

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:

  1. Automatisk failover til sekundær region (konfigurasjon: aktiv-passiv)
  2. DNS-oppdatering peker trafikk til sekundær region (TTL: 60 sekunder)
  3. Database failover til standby-replikka i sekundær region
  4. Verifiser tjenestekvalitet i sekundær region
  5. Informer brukere via push-varsling og statusside
  6. 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:

  1. Stopp skriving til korrupt database umiddelbart
  2. Aktiver skrivebeskyttet modus (brukere kan se, men ikke utføre transaksjoner)
  3. Identifiser tidspunkt for korrupsjon
  4. Gjenopprett fra siste gyldige backup + WAL-replay til tidspunkt før korrupsjon
  5. Verifiser dataintegritet
  6. Gjenoppta normal drift
  7. 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:

  1. Automatisk failover til sekundær Open Banking-leverandør
  2. Aktiver hurtigbuffer for kontoinformasjon (siste kjente saldo, maks 1 time gammel)
  3. Informer brukere om mulig forsinkelse i betalingsbehandling
  4. Kontakt primær leverandør for statusoppdatering
  5. Logg alle transaksjoner som venter på behandling
  6. 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:

  1. Aktiver degradert modus: eksisterende innloggede brukere kan fullføre pågående transaksjoner
  2. Ny autentisering er ikke mulig — informer brukere via app og statusside
  3. Kontakt BankID Norge AS for statusoppdatering
  4. Forleng sesjonstimeout midlertidig (fra 15 min til 60 min) for aktive sesjoner
  5. Logg alle forsøk på autentisering for senere analyse
  6. 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:

  1. Aktiver hendelsesresponsplan (se hendelseshaandtering.md)
  2. Isoler berørte systemer
  3. Aktiver DDoS-mitigering på CDN/WAF-nivå
  4. Ved ransomware: gjenopprett fra sikkerhetskopier (ingen betaling)
  5. Eskaler til Finanstilsynet innen 4 timer
  6. Informer berørte brukere
  7. 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:

  1. Alle kritiske roller har stedfortreder dokumentert
  2. Alle prosedyrer er dokumentert og tilgjengelig
  3. Alle tilganger er rollebasert (ikke personbasert)
  4. Tredjepartsavtaler har kontaktlister med flere kontaktpunkter
  5. 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.

  1. Identifiser siste gyldige tidspunkt
  2. Stopp applikasjonsservere
  3. Gjenopprett database fra siste fullsikkerhetskopi
  4. Replay WAL-segmenter frem til identifisert tidspunkt (PITR)
  5. Verifiser dataintegritet med sjekksumkontroll
  6. Kjør integrasjonstester mot gjenopprettet database
  7. Start applikasjonsservere i kontrollert rekkefølge
  8. Overvåk tett de neste 24 timene

4.3 Infrastruktur-gjenoppretting

  1. Verifiser at infrastruktur-som-kode (IaC) er tilgjengelig
  2. Provisionér ny infrastruktur i sekundær region/sone
  3. Deploy siste gyldige applikasjonsversjon
  4. Gjenopprett databaser (se 4.2)
  5. Konfigurer nettverksruter og lastbalansering
  6. Verifiser tjenestekvalitet
  7. 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

5.4 Maler for kommunikasjon

Ferdigformulerte maler for:

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:

6.3 Aktivering av beredskap

Beredskap aktiveres når:

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:

7.3 Oppdatering etter test

8. Vedlikehold av planen

8.1 Gjennomgangsfrekvens

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

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.

Policies & Internal Controls

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:

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:

2.3 Tilgjengelighet

Klagekanaler er tilgjengelige:

3. Behandlingsprosess

3.1 Mottak og registrering

  1. Alle klager registreres i klagehåndteringssystemet ved mottak
  2. Klager tildeles unikt referansenummer
  3. Mottaksbekreftelse sendes til klager innen 1 virkedag
  4. 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

  1. Klagen tildeles saksbehandler basert på kategori og kompetanse
  2. Saksbehandler gjennomgår klagen, innhenter nødvendig informasjon
  3. Saksbehandler kan kontakte klager for avklaring
  4. Saksbehandler utarbeider forslag til løsning
  5. 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:

3.5 Innhold i svarbrev

Svaret til klager skal inneholde:

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)

Finanstilsynet

Forbrukerrådet

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

5.2 Automatisk kompensasjon

Følgende utløser automatisk kompensasjon:

5.3 Skjønnsmessig kompensasjon

Ved forhold som ikke utløser automatisk kompensasjon, kan vi tilby:

6. Dokumentasjon og oppbevaring

6.1 Klageregister

Alle klager dokumenteres i klageregisteret med:

6.2 Oppbevaringstid

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

7.3 Styreorientering

Styret orienteres:

7.4 Rapportering til Finanstilsynet

I henhold til regulatoriske krav rapporteres:

8. Forbedring

8.1 Rotårsaksanalyse

For gjentakende klager eller alvorlige enkeltklager gjennomføres rotårsaksanalyse:

  1. Identifiser grunnleggende årsak
  2. Vurder om problemet er systemisk
  3. Utarbeid forbedtringstiltak
  4. Implementer tiltak med ansvarlig og frist
  5. Verifiser at tiltaket har effekt

8.2 Kontinuerlig forbedring

8.3 Opplæring

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

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

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:

2.2 Registrering

Registrering skjer gjennom:

  1. Last ned Drop-appen fra App Store eller Google Play
  2. Identifiser deg med BankID
  3. Bekreft mobilnummer via SMS-kode
  4. Aksepter brukervilkår og personvernerklæring
  5. 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:

Vi forbeholder oss retten til å nekte registrering eller avslutte kundeforholdet dersom kundekontroll ikke kan gjennomføres tilfredsstillende.

3. Tjenestebeskrivelse

3.1 Utenlandsoverføringer

3.2 QR-betalinger

3.3 Kontoinformasjon

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:

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

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

6.2 Korrekt bruk

Du forplikter deg til å:

6.3 Varsling om uautorisert bruk

Ved mistanke om uautorisert bruk av din Drop-konto:

  1. Sperr kontoen umiddelbart i appen (Innstillinger > Sperr konto)
  2. Kontakt kundeservice (kontaktinfo i punkt 14)
  3. Anmeld forholdet til politiet ved behov

7. Våre plikter

7.1 Tjenesteleveranse

Vi forplikter oss til å:

7.2 Informasjonsplikt

Vi informerer deg om:

7.3 Transaksjonsoversikt

Vi gir deg tilgang til:

8. Ansvarsbegrensning

8.1 Vårt ansvar

Vi er ansvarlige for:

8.2 Brukerens egenandel

Ved uautoriserte betalingstransaksjoner gjelder følgende egenandel, jf. betalingstjenesteloven § 4-2:

8.3 Begrensninger

Vi er ikke ansvarlige for:

8.4 Tilbakeføring av feilbetalinger

Dersom du har overført penger til feil mottaker:

  1. Kontakt kundeservice umiddelbart
  2. Vi vil forsøke å tilbakeføre beløpet
  3. Tilbakeføring er avhengig av mottakerens bank og mottakerens samtykke
  4. 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:

  1. Kontakt oss på support@getdrop.no innen 14 dager etter registrering
  2. Oppgi ditt navn og at du ønsker å benytte angreretten
  3. Du trenger ikke oppgi grunn
  4. Vi bekrefter mottak og sletter kontoen din

9.4 Angreskjema

Standardisert angreskjema er tilgjengelig:

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:

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:

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:

11.3 Ved oppsigelse

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

14.2 Klager

14.3 Personvern

15. Forholdet til andre dokumenter

Disse brukervilkårene utfyller og må leses i sammenheng med:

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.

Terms & Agreements

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

3.3 Leveringstid

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:

8. Endring av gebyrer

9. Kontakt

Spoersmaal om gebyrer kan rettes til:

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.

Terms & Agreements

Framework Agreement

Rammeavtale for betalingstjenester — Drop

Avtaleparter:

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)

2.2 QR-betalinger

2.3 Kontoinformasjon (AISP)

3. Vilkaar for bruk (s 3-1 nr. 2)

3.1 Krav til Brukeren

For aa benytte Drop maa Brukeren:

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:

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

5.2 QR-betalinger

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

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

7.2 Brukerens plikter

8. Selskapets plikter (s 3-1 nr. 7)

8.1 Tjenesteleveranse

8.2 Informasjonsplikt

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

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:

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

12.2 Ekstern klageadgang

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)

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:

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.

Terms & Agreements

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:

  1. Egen PSD2-lisens — 6-12 mnd, EUR 20-50K kapital, direkte tilsyn
  2. 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

Produkter:

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

2. Teknisk integrasjon

3. Remittance-korridorer

4. Pricing

5. Juridisk

6. Go-to-market

Drop i tall

Forventet utfall

  1. Bekreftelse om agent-modell
  2. Prisindikasjon (ballpark)
  3. Sandbox-tilgang
  4. Neste steg: NDA -> POC -> avtale

Ref: ADR-003-psd2-passthrough-model.md