Research & Business

Market research, banking providers, BankID, partnerships, business cases

Market Research

Market Research

Mobile Banking Research

Mobile Payment/Banking Application - Full Research Findings

Table of Contents

  1. Regulatory Requirements
  2. Technical Architecture
  3. Security & Compliance
  4. Market Analysis
  5. Key Success Factors

1. Regulatory Requirements

1.1 EU Payment Services Directive (PSD2/PSD3)

Current State (PSD2)

PSD2 has been the governing framework since 2018, establishing:

PSD3 Transition (2025-2028)

Timeline:

Key Changes in PSD3:

Compliance Actions for 2026:

  1. Implement Confirmation of Payee systems
  2. Upgrade SCA mechanisms for eIDAS 2.0 alignment
  3. Establish real-time fraud monitoring
  4. Prepare for API hardening requirements
  5. Build recovery assurance capabilities

1.2 Licensing Requirements

Electronic Money Institution (EMI) License

Capital Requirements:

Application Costs by Jurisdiction:

Country Application Fee Timeline Total Setup Cost
Lithuania EUR 1,463 6-9 months EUR 30K-50K
Malta EUR 2,000-5,000 ~6 months EUR 40K-60K
Ireland GBP 5,000 12-18 months EUR 200K-300K+
UK GBP 5,000 6-12 months EUR 100K-200K

Lithuania Advantages:

Ireland Advantages:

Payment Institution (PI) License

Alternative to EMI if not issuing e-money:

1.3 KYC/AML Requirements

EU AML Package 2025

New Framework:

Core KYC Requirements:

  1. Customer Due Diligence (CDD)

    • Identity verification (ID document + biometric)
    • Address verification
    • Source of funds verification
    • Beneficial ownership identification (UBO)

  2. Enhanced Due Diligence (EDD)

    • Required for high-risk customers/transactions
    • PEP (Politically Exposed Persons) screening
    • Ongoing monitoring requirements

  3. eKYC Standards (2025)

    • Mandatory electronic identification
    • eIDAS 2.0 compliance for digital identity
    • Remote verification capabilities required

Cash Transaction Limits:

1.4 Data Protection (GDPR)

Key Requirements for Financial Apps:

  1. Data Minimization

    • Collect only necessary data
    • Clear purpose limitation
    • Defined retention periods

  2. Privacy by Default

    • Location tracking disabled by default
    • Marketing communications opt-in only
    • Minimal data sharing defaults

  3. Consent Management

    • Explicit, active consent required
    • No pre-ticked boxes
    • Easy withdrawal mechanism
    • Granular consent options

  4. Data Subject Rights

    • Right to access (30-day response)
    • Right to portability
    • Right to erasure
    • Right to rectification

  5. Security Requirements

    • End-to-end encryption (TLS 1.3+)
    • AES-256 for data at rest
    • Data breach notification within 72 hours

  6. DPIA Requirements

    • Required for AI-powered decisions
    • Biometric authentication systems
    • Large-scale customer analytics

Penalties:

2. Technical Architecture

2.1 System Architecture Overview

Modern mobile banking requires a layered, microservices-based architecture:

┌─────────────────────────────────────────────────────────────┐
│                    PRESENTATION LAYER                        │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────────────┐  │
│  │  iOS App    │  │ Android App │  │    Web Dashboard    │  │
│  │  (Swift)    │  │  (Kotlin)   │  │     (React)         │  │
│  └─────────────┘  └─────────────┘  └─────────────────────┘  │
│         OR Cross-Platform: Flutter / React Native            │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│                      API GATEWAY                             │
│  (Authentication, Rate Limiting, Load Balancing)             │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│                   MICROSERVICES LAYER                        │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────────┐   │
│  │   Auth   │ │ Accounts │ │ Payments │ │    Cards     │   │
│  │ Service  │ │ Service  │ │ Service  │ │   Service    │   │
│  └──────────┘ └──────────┘ └──────────┘ └──────────────┘   │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────────┐   │
│  │   KYC    │ │   AML    │ │  Ledger  │ │ Notification │   │
│  │ Service  │ │ Service  │ │ Service  │ │   Service    │   │
│  └──────────┘ └──────────┘ └──────────┘ └──────────────┘   │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│                    DATA LAYER                                │
│  ┌──────────────┐  ┌───────────┐  ┌─────────────────────┐   │
│  │  PostgreSQL  │  │   Redis   │  │   Event Stream      │   │
│  │  (Primary)   │  │  (Cache)  │  │   (Kafka/RabbitMQ)  │   │
│  └──────────────┘  └───────────┘  └─────────────────────┘   │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│                 EXTERNAL INTEGRATIONS                        │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────────┐   │
│  │  BaaS    │ │   Card   │ │   KYC    │ │   Payment    │   │
│  │ Provider │ │ Issuer   │ │ Provider │ │   Rails      │   │
│  └──────────┘ └──────────┘ └──────────┘ └──────────────┘   │
└─────────────────────────────────────────────────────────────┘

2.2 Payment Processing Flow

1. User Initiates Payment
         │
         ▼
2. Mobile App → API Gateway
         │
         ▼
3. Authentication Service (verify session, 2FA if required)
         │
         ▼
4. Payment Service
   ├── Validate request
   ├── Check balance/limits
   ├── AML screening (real-time)
   └── Create payment intent
         │
         ▼
5. Ledger Service
   ├── Reserve funds (pending state)
   └── Create audit trail
         │
         ▼
6. External Payment Rail (SEPA, SWIFT, card network)
         │
         ▼
7. Confirmation
   ├── Ledger finalization
   ├── User notification
   └── Transaction record

2.3 Mobile Wallet Architecture

Core Components:

  1. Wallet Container

    • Multi-currency support
    • Real-time balance tracking
    • Transaction history
    • Spending analytics

  2. Card Management

    • Virtual card generation
    • Physical card ordering
    • Card controls (freeze, limits)
    • Push provisioning (Apple/Google Pay)

  3. Payment Methods

    • NFC tap-to-pay
    • QR code payments
    • P2P transfers
    • Scheduled payments
    • Bill payments

  4. Security Layer

    • Biometric authentication
    • Device binding
    • Transaction signing
    • Tokenization

2.4 Core Banking Integration Options

Option 1: Full BaaS

Option 2: Modular Integration

Option 3: Custom Build

2.5 API-First Design Principles

  1. RESTful APIs for standard operations
  2. WebSocket for real-time updates
  3. GraphQL for complex data queries (optional)
  4. Idempotency for payment operations
  5. Versioning for backward compatibility
  6. Rate limiting for security and stability

3. Security & Compliance

3.1 PCI DSS Compliance

Compliance Levels:

Key Requirements (v4.0.1):

Requirement Description
Req 3 Protect stored cardholder data
Req 4 Encrypt transmission of cardholder data
Req 6 Develop and maintain secure systems
Req 8 Identify users and authenticate access
Req 10 Log and monitor all access
Req 11 Regularly test security systems
Req 12 Maintain information security policy

Mobile-Specific Requirements:

Non-Compliance Penalties:

3.2 Strong Customer Authentication (SCA)

Two of Three Factors Required:

  1. Knowledge: PIN, password
  2. Possession: Phone, token, card
  3. Inherence: Biometrics (fingerprint, face)

SCA Exemptions:

3.3 Security Architecture

┌─────────────────────────────────────────────────────┐
│              SECURITY LAYERS                         │
├─────────────────────────────────────────────────────┤
│ Application Security                                 │
│ ├── Input validation                                │
│ ├── Output encoding                                 │
│ ├── Session management                              │
│ └── OWASP MASVS compliance                          │
├─────────────────────────────────────────────────────┤
│ Data Security                                        │
│ ├── AES-256 encryption (at rest)                    │
│ ├── TLS 1.3 (in transit)                            │
│ ├── Tokenization (sensitive data)                   │
│ └── Key management (HSM)                            │
├─────────────────────────────────────────────────────┤
│ Infrastructure Security                              │
│ ├── WAF (Web Application Firewall)                  │
│ ├── DDoS protection                                 │
│ ├── Network segmentation                            │
│ └── Intrusion detection                             │
├─────────────────────────────────────────────────────┤
│ Operational Security                                 │
│ ├── 24/7 monitoring                                 │
│ ├── Incident response                               │
│ ├── Penetration testing                             │
│ └── Vulnerability management                        │
└─────────────────────────────────────────────────────┘

3.4 Fraud Prevention

Real-Time Monitoring:

Required Capabilities (PSD3):

4. Market Analysis

4.1 European Digital Banking Market

Market Size:

Key Players:

4.2 Competitive Landscape

Neobank Industry Statistics (2025):

Success Factors:

  1. Differentiated value proposition
  2. Superior user experience
  3. Cost-efficient operations
  4. Multiple revenue streams
  5. Strong unit economics

4.3 Revenue Models

Primary Revenue Streams:

  1. Interchange fees: 0.2-0.3% of card transactions
  2. FX markup: 0.5-2% on currency conversion
  3. Subscription tiers: EUR 5-15/month premium plans
  4. Interest income: On deposits (if banking license)
  5. Lending: Personal loans, BNPL, overdrafts

Emerging Revenue:

5. Key Success Factors

5.1 Time to Market

Critical Milestones:

Accelerators:

5.2 User Acquisition

Strategies:

  1. Referral programs: Proven effective for neobanks
  2. Niche targeting: Specific customer segments
  3. Feature differentiation: Unique value proposition
  4. Partnership distribution: Through platforms/employers

Metrics to Track:

5.3 Operational Excellence

Key Capabilities:

  1. Customer support: 24/7, multi-channel
  2. Fraud management: Real-time, ML-powered
  3. Compliance: Continuous monitoring
  4. Engineering: Rapid iteration, reliability

Cost Optimization:

Sources and References

Regulatory

Technical

Market

Market Research

Banking Providers

Third-Party Providers Comparison

Architecture alignment note (2026-02-14): This document is pre-architecture research from the mobilebank-research phase. Drop ultimately chose a PSD2 pass-through model — no wallet, no balance held by Drop, no IBAN generation. BaaS providers listed here would serve as Open Banking (AISP/PISP) integration partners, not wallet infrastructure. Card issuing is a FUTURE feature (feature-flagged). This document is retained as provider research reference.

Table of Contents

  1. Banking-as-a-Service (BaaS) Providers
  2. Card Issuing Platforms
  3. Payment Processors
  4. KYC/Identity Verification Providers
  5. Virtual IBAN Providers
  6. Recommendation Matrix

1. Banking-as-a-Service (BaaS) Providers

Overview

BaaS providers enable fintech companies to offer banking services without obtaining their own banking license. They provide the regulatory infrastructure, APIs, and banking capabilities.

Provider Comparison

Solarisbank (Solaris SE)

Attribute Details
Headquarters Berlin, Germany
License Full German banking license + Digital Assets Custody
Coverage EU-wide (passporting)
Key Features Accounts, cards, lending, digital assets, compliance
Target Market Fintechs, enterprises, large card programs
Notable Clients Samsung, ADAC
Strengths Full-stack, modular APIs, banking license
Weaknesses Requires BaFin approval for new partners, financial challenges
Best For Enterprises needing complete banking capabilities

Services:

Swan

Attribute Details
Headquarters Paris, France
License EMI (French)
Coverage Eurozone (expanding)
Key Features IBANs, cards, embedded finance
Target Market Startups, SMEs, SaaS platforms
Strengths 5-minute integration, built-in KYC, fast time-to-market
Weaknesses Limited geographic coverage, cards/accounts focus
Best For Fast MVP launch, European startups

Key Differentiators:

Treezor (Societe Generale)

Attribute Details
Headquarters Paris, France
License EMI (European) + MasterCard Prepaid approved
Coverage EU (branches in Italy, Spain, Germany)
Key Features E-wallets, cards, marketplaces, crowdfunding
Target Market Neobanks, mobility, employee benefits
Strengths Backed by Societe Generale, SEPA network, 50M+ transactions/year
Weaknesses Best suited for eurozone transactions
Best For Euro-focused operations, established platforms

Services:

Railsr (formerly Railsbank)

Attribute Details
Headquarters UK
License EMI
Coverage Europe, Asia
Key Features BaaS, Cards-as-a-Service, payments, compliance
Target Market Fintechs, brands embedding finance
Strengths Flexible APIs, cards + payments combined
Weaknesses Financial challenges (acquired/recapitalized 2023)
Best For Card programs, embedded finance for brands

Other Notable Providers

Provider HQ Specialty Notes
Modulr UK Payments infrastructure EMI license, fast payments
Paynetics Bulgaria E-money, cards EU + UK licenses
Vodeno/Aion Poland/Belgium Full banking Acquired by UniCredit
OpenPayd UK Multi-currency accounts Virtual IBANs specialist

BaaS Selection Criteria

  1. Regulatory Coverage: Does license cover target markets?
  2. API Quality: Developer documentation, SDKs, sandbox
  3. Time to Market: Integration complexity, onboarding time
  4. Pricing Model: Setup fees, per-transaction, revenue share
  5. Financial Stability: Provider's funding, profitability
  6. Scalability: Can grow with your business
  7. Support: Technical support, account management

2. Card Issuing Platforms

Provider Comparison

Marqeta

Attribute Details
Headquarters US (global coverage)
Coverage 40+ countries
Key Features Virtual/physical cards, JIT funding, customization
PCI Compliance Level 1, tokenization
Pricing ~$0.50/virtual card, 0.5-1% transaction fee
Setup Cost $5,000-$50,000
Best For Custom card programs, expense management

Strengths:

Stripe Issuing

Attribute Details
Headquarters US (Ireland for EU)
Coverage US, EU expanding
Key Features Virtual/physical cards, webhooks, Stripe ecosystem
Integration Seamless with Stripe payments
Best For Existing Stripe users, developer-centric teams

Strengths:

Adyen Issuing

Attribute Details
Headquarters Netherlands
Coverage Global
Key Features Issuing + acquiring + processing combined
Integration Single API for all payment needs
Best For Enterprise with complex payment needs

Strengths:

Other Card Issuers

Provider Specialty Coverage
Paymentology Cloud-based issuing Global
Thredd (GPS) Prepaid programs EU, UK
Wallester European cards EU
Galileo Processing platform US, expanding

3. Payment Processors

Adyen

Attribute Details
Pricing Model Interchange++ (most transparent)
Processing Fee EUR 0.10-0.15 per transaction
Interchange Pass-through (EU capped: 0.2% debit, 0.3% credit)
Payment Methods Cards, local methods, wallets
Best For Large volume, international operations

Strengths:

Stripe

Attribute Details
Pricing 1.4% + EUR 0.25 (EU cards), 2.9% + EUR 0.25 (non-EU)
Features Payments, subscriptions, connect, treasury
Best For Startups, developer-first companies

Strengths:

Stripe Treasury (Embedded Finance)

Feature Capability
Financial Accounts Stored-value accounts for customers
Bank Integration Fifth Third Bank partnership
FDIC Insurance Pass-through eligible
ACH/Wire Supported
Use Case Embedded banking for platforms

Notable Implementation: Shopify Balance built on Stripe Treasury

Other Payment Processors

Provider Specialty Pricing Model
Checkout.com Enterprise payments Interchange++
Mollie European SMB Fixed % per method
Worldpay Global acquiring Custom
PayPal/Braintree Consumer payments Fixed %

4. KYC/Identity Verification Providers

Provider Comparison

Onfido

Attribute Details
Services ID scanning, facial recognition, risk scoring
Coverage Global (195+ countries)
Integration SDK (iOS, Android, Web) + API
Compliance GDPR, eIDAS, SOC 2
Best For High-volume onboarding, international

Sumsub

Attribute Details
Services KYC, AML screening, fraud prevention
Coverage 220+ countries
Features Bank verification, PEP/sanctions screening
Best For Growing fintechs, multi-region expansion

IDnow

Attribute Details
Services Video-based verification, eIDAS compliance
Coverage Europe focus
Compliance BaFin approved, full eIDAS
Best For German market, strict compliance requirements

Entrust

Attribute Details
Recognition Gartner Magic Quadrant 2025
Services AI-powered verification, digital onboarding
Best For Enterprise, banking institutions

Comparison Matrix

Provider Document Types Biometrics AML Screening Pricing Range
Onfido 4,500+ Face match Yes $$$
Sumsub 3,000+ Face + liveness Yes $$
IDnow EU focus Video + face Yes $$$
Ondato 2,000+ Photo/video Yes $$
Trulioo Global databases Limited Yes $$
iDenfy 3,000+ Face + liveness Yes $

5. Virtual IBAN Providers

Key Providers

OpenPayd

Attribute Details
IBAN Countries UK, FR, MT, NL
Features Named vIBANs, Target2 connectivity
API Simple (2 required params)
Best For Platforms needing named accounts

Banking Circle

Attribute Details
Headquarters Luxembourg
Features Named vIBANs, multi-currency (EUR, GBP, USD, AED)
Target High-volume PSPs, EMIs

Airwallex

Attribute Details
Coverage 60+ markets
Features Global accounts, FX, API automation
Best For International operations

Other Providers

Provider Specialty
Payset SME-focused, multi-currency
Clear Junction High-risk friendly
Currencycloud FX + accounts
Sharpay Instant issuance, SEPA/SWIFT

IBAN Provider Selection Criteria

  1. Coverage: Which IBAN countries needed?
  2. Naming: Named vs. pooled IBANs
  3. Payment Rails: SEPA, SWIFT, Target2
  4. Currency Support: EUR, GBP, USD, others
  5. API Quality: Documentation, reliability
  6. Compliance: AML/KYC support
  7. Pricing: Per-account, per-transaction fees

6. Recommendation Matrix

By Company Stage

Stage BaaS Cards KYC Payments
MVP/Seed Swan Stripe Issuing Sumsub Stripe
Growth Treezor/Railsr Marqeta Onfido Adyen
Enterprise Solarisbank Marqeta/Adyen IDnow Adyen

By Use Case

By Budget

Sources

Market Research

MVP Specification

MVP Feature Specification

Architecture alignment note (2026-02-14): This document is pre-architecture research from the mobilebank-research phase. Drop ultimately chose a PSD2 pass-through model — no wallet, no balance held, no IBAN generation, no top-up. AISP reads bank balances, PISP initiates payments from the user's own bank account. Cards are a FUTURE feature (feature-flagged). This document is retained as research reference — it does NOT reflect the current Drop architecture.

Table of Contents

  1. MVP Philosophy
  2. Core Features
  3. Feature Specifications
  4. Timeline
  5. Success Metrics

1. MVP Philosophy

Focus Areas

What to Include

What to Exclude (MVP)

2. Core Features

Feature Priority Matrix

Feature Priority Complexity Timeline
User Onboarding P0 Medium Week 1-4
Digital KYC P0 High Week 2-6
Account Creation P0 Medium Week 4-8
IBAN Generation P0 Low Week 6-8
Virtual Card P0 High Week 8-12
P2P Transfers P0 Medium Week 10-14
Top-up (Card) P1 Medium Week 12-16
Bank Transfer P1 Medium Week 14-18
Transaction History P1 Low Week 8-10
Push Notifications P1 Low Week 10-12
Physical Card P2 High Post-MVP

3. Feature Specifications

3.1 User Onboarding

Goal: Complete signup in <3 minutes

Flow:

  1. Download app
  2. Enter phone number
  3. Verify via OTP
  4. Enter email
  5. Set password/PIN
  6. Accept T&C
  7. Start KYC

Requirements:

Acceptance Criteria:

3.2 Digital KYC (Know Your Customer)

Goal: Verify identity in <5 minutes

Flow:

  1. Select ID document type
  2. Capture front of ID
  3. Capture back of ID (if applicable)
  4. Take selfie (liveness check)
  5. Enter personal details
  6. Verification processing
  7. Result notification

Document Types:

Requirements:

Integration: Sumsub or Onfido API

Acceptance Criteria:

3.3 Account Creation

Goal: Generate EUR account with IBAN

Flow:

  1. KYC approved
  2. Account type selection (Personal)
  3. IBAN generation
  4. Account activated
  5. Welcome notification

Account Features:

Integration: BaaS provider (Swan/Treezor)

Acceptance Criteria:

3.4 IBAN Generation

Technical Requirements:

Provider Options:

Formats:

3.5 Virtual Card Issuing

Goal: Instant virtual Mastercard/Visa

Features:

Card Controls:

Security:

Integration: Marqeta or Stripe Issuing

Acceptance Criteria:

3.6 P2P Transfers

Goal: Send money to other users instantly

Transfer Types:

A) Internal (App-to-App)

B) SEPA Transfer

Flow:

  1. Select recipient method
  2. Enter/select recipient
  3. Enter amount
  4. Review details
  5. Authenticate (biometric/PIN)
  6. Confirmation

Requirements:

Limits (MVP):

Type Daily Monthly
Internal EUR 5,000 EUR 20,000
SEPA EUR 2,000 EUR 10,000

3.7 Top-up Methods

A) Card Top-up

B) Bank Transfer

C) Future: Apple Pay / Google Pay top-up

Integration: Stripe or Adyen for card payments

3.8 Transaction History

Features:

Categories:

3.9 Push Notifications

Mandatory Notifications:

Optional Notifications:

4. Timeline

Phase 1: Foundation (Months 1-2)

Week 1-4:

Week 5-8:

Phase 2: Core Features (Months 3-4)

Week 9-12:

Week 13-16:

Phase 3: Launch Prep (Months 5-6)

Week 17-20:

Week 21-24:

Milestones

Milestone Target Date Deliverable
Alpha Month 3 Core features working
Beta Month 5 500 beta users
Soft Launch Month 6 Public availability
GA Month 7-8 Marketing push

5. Success Metrics

Activation Metrics

Metric Target Threshold
Signup completion >80% >60%
KYC pass rate >85% >70%
First transaction >50% in 7 days >30%
Card activation >70% >50%

Engagement Metrics

Metric Target Threshold
MAU/DAU >30% >20%
Transactions/user/month >10 >5
App opens/week >3 >1

Quality Metrics

Metric Target Threshold
App crash rate <0.5% <1%
API latency (p95) <500ms <1000ms
Uptime >99.9% >99.5%
App store rating >4.5 >4.0

Business Metrics

Metric Target Threshold
CAC <EUR 30 <EUR 50
Monthly burn <EUR 50K <EUR 75K
Active users (6 months) >5,000 >2,000

Sources

Market Research

Cost Analysis

Cost Breakdown and Budget Estimates

Architecture alignment note (2026-02-14): This document is pre-architecture research from the mobilebank-research phase. Drop ultimately chose a PSD2 pass-through model — no wallet, no balance held, no own EMI license required for MVP. The pass-through model significantly reduces licensing and BaaS costs compared to the scenarios below. Card issuing is a FUTURE feature. This document is retained as cost research reference — actual Drop cost structure differs.

Table of Contents

  1. Executive Summary
  2. Licensing Costs
  3. Development Costs
  4. Third-Party Provider Costs
  5. Infrastructure Costs
  6. Operational Costs
  7. Budget Scenarios

1. Executive Summary

Total Investment Range

Approach Initial (Year 1) Monthly Ops Break-even
BaaS MVP EUR 150K-300K EUR 15-30K 18-24 months
Full Build EUR 500K-1.5M EUR 50-100K 24-36 months
Enterprise EUR 1.5M+ EUR 100K+ 36+ months

Key Cost Drivers

  1. Licensing strategy (own vs. BaaS)
  2. Development approach (in-house vs. outsource)
  3. Feature complexity
  4. Geographic scope
  5. Transaction volume

2. Licensing Costs

Option A: Own EMI License

Jurisdiction Application Capital Setup (Legal/Consulting) Timeline
Lithuania EUR 1,463 EUR 350,000 EUR 30-50K 6-9 months
Malta EUR 2-5K EUR 350,000 EUR 40-60K 6 months
Ireland EUR 4K EUR 350,000 EUR 200-300K 12-18 months
UK (FCA) GBP 5,000 GBP 350,000 GBP 100-200K 6-12 months

Lithuania Breakdown:

Option B: BaaS Partnership (No Own License)

Provider Setup Fee Monthly Minimum Per-Transaction
Swan EUR 0-10K EUR 500-2K Volume-based
Treezor EUR 10-50K EUR 2-5K Volume-based
Solarisbank EUR 50-100K EUR 5-10K Custom

Savings with BaaS:

3. Development Costs

MVP Development (4-6 months)

Component In-House (Western EU) Outsource (Eastern EU) Outsource (Asia)
Backend EUR 80-120K EUR 40-60K EUR 25-40K
Mobile (Flutter) EUR 60-100K EUR 30-50K EUR 20-35K
Frontend (Web) EUR 30-50K EUR 15-25K EUR 10-18K
DevOps/Infra EUR 20-40K EUR 10-20K EUR 8-15K
QA/Testing EUR 20-30K EUR 10-15K EUR 6-10K
Total EUR 210-340K EUR 105-170K EUR 69-118K

Feature-Level Costs

Feature Development Cost Notes
User onboarding EUR 8-15K Auth, registration
KYC integration EUR 15-30K Third-party API
Account management EUR 20-35K Core functionality
Virtual card EUR 25-40K Issuing integration
P2P transfers EUR 15-25K Internal + SEPA
Card top-up EUR 10-20K Payment gateway
Push notifications EUR 5-10K FCM/APNS
Transaction history EUR 8-12K UI + backend
Card controls EUR 10-15K Freeze, limits

Team Composition (MVP)

Role Count Monthly Cost (EU)
Tech Lead 1 EUR 8-12K
Backend Dev (Senior) 2 EUR 12-18K
Mobile Dev (Senior) 2 EUR 12-18K
DevOps 1 EUR 6-9K
QA 1 EUR 4-6K
Product Manager 1 EUR 6-10K
Designer 0.5 EUR 3-5K
Total 8.5 EUR 51-78K/month

Outsourcing Savings: 40-60% vs. Western EU rates

4. Third-Party Provider Costs

BaaS Provider Costs

Provider Setup Monthly Per Account Notes
Swan Free-10K EUR 500-2K EUR 0.50-2 Fast integration
Treezor EUR 10-30K EUR 2-5K Included SEPA optimized
Solarisbank EUR 50-100K EUR 5-10K Custom Full stack

Card Issuing Costs

Provider Setup Per Card Transaction Fee
Marqeta EUR 5-50K EUR 0.50-2 0.5-1%
Stripe Issuing Free EUR 0.10-0.50 Included
Adyen Custom Custom Custom

KYC/Identity Verification

Provider Per Verification Volume Discount
Sumsub EUR 0.50-2.00 Yes (>10K/month)
Onfido EUR 1.00-3.00 Yes
IDnow EUR 2.00-5.00 Yes

Example (10K users/month):

Payment Processing

Provider Setup Per Transaction Notes
Stripe Free 1.4% + EUR 0.25 (EU) Easy integration
Adyen Free EUR 0.10-0.15 + interchange Enterprise

Virtual IBAN

Provider Per IBAN Monthly Maintenance
OpenPayd EUR 1-5 EUR 0-1
Banking Circle Custom Volume-based
Usually included in BaaS - -

5. Infrastructure Costs

Cloud Infrastructure (AWS/GCP)

Component Monthly Cost Notes
Compute (K8s cluster) EUR 1,500-3,000 3-5 nodes
Database (RDS/Cloud SQL) EUR 500-1,500 Multi-AZ
Redis (ElastiCache) EUR 200-500 Cluster mode
Storage (S3) EUR 100-300 Documents, backups
CDN (CloudFlare) EUR 200-500 Pro/Business
Monitoring (Datadog) EUR 300-800 APM included
Total EUR 2,800-6,600 Scales with users

Cost Per User

Users Infrastructure Third-Party Total/User
1,000 EUR 3/user EUR 5/user EUR 8/user
10,000 EUR 1/user EUR 3/user EUR 4/user
100,000 EUR 0.50/user EUR 2/user EUR 2.50/user

6. Operational Costs

Monthly Operational Expenses

Category MVP Phase Growth Phase Scale Phase
Team (salaries) EUR 30-50K EUR 80-150K EUR 200K+
Infrastructure EUR 3-5K EUR 10-20K EUR 50K+
Third-party services EUR 5-10K EUR 20-50K EUR 100K+
Compliance EUR 5-10K EUR 15-30K EUR 50K+
Customer support EUR 2-5K EUR 10-20K EUR 30K+
Marketing EUR 5-15K EUR 30-100K EUR 200K+
Legal/Professional EUR 2-5K EUR 5-15K EUR 20K+
Office/Admin EUR 2-5K EUR 5-10K EUR 15K+
Total EUR 54-105K EUR 175-395K EUR 665K+

Per-User Economics

Metric Amount Notes
Customer Acquisition Cost EUR 20-50 Marketing + onboarding
First-year serving cost EUR 175 Fixed costs
Monthly serving cost EUR 5 Infrastructure + support
Required spend for breakeven EUR 750/month Year 1

Compliance Costs

Item Annual Cost
Compliance Officer (FTE) EUR 80-120K
AML monitoring tools EUR 20-50K
External audits EUR 30-60K
Regulatory reporting EUR 10-20K
Training & certification EUR 5-10K
Total EUR 145-260K

7. Budget Scenarios

Scenario A: Lean BaaS MVP

Assumptions:

Category Year 1 Monthly (Avg)
Development EUR 150,000 -
BaaS setup + fees EUR 20,000 EUR 2,000
KYC (5K verifications) EUR 10,000 EUR 1,000
Infrastructure EUR 36,000 EUR 3,000
Operations (lean) EUR 120,000 EUR 10,000
Marketing EUR 60,000 EUR 5,000
Legal/Compliance EUR 30,000 EUR 2,500
Buffer (15%) EUR 64,000 -
Total Year 1 EUR 490,000 EUR 23,500

Scenario B: Standard Build

Assumptions:

Category Year 1 Monthly (Avg)
EMI License EUR 450,000 -
Development EUR 300,000 -
Card program EUR 50,000 EUR 5,000
KYC (20K verifications) EUR 30,000 EUR 3,000
Infrastructure EUR 72,000 EUR 6,000
Operations EUR 480,000 EUR 40,000
Marketing EUR 200,000 EUR 17,000
Legal/Compliance EUR 150,000 EUR 12,500
Buffer (20%) EUR 346,000 -
Total Year 1 EUR 2,078,000 EUR 83,500

Scenario C: Enterprise Launch

Assumptions:

Category Year 1
EMI License (Ireland) EUR 800,000
Development EUR 800,000
Core banking platform EUR 300,000
Card program EUR 150,000
KYC (100K verifications) EUR 100,000
Infrastructure EUR 300,000
Operations EUR 1,500,000
Marketing EUR 1,000,000
Legal/Compliance EUR 400,000
Buffer (25%) EUR 1,337,500
Total Year 1 EUR 6,687,500

Cost Optimization Strategies

Development

Licensing

Operations

Marketing

Financial Model Summary

Unit Economics Target

Metric Target
CAC < EUR 30
LTV > EUR 150
LTV:CAC > 5:1
Payback period < 12 months
Gross margin > 60%

Revenue Model

Stream Revenue/User/Year
Interchange EUR 15-30
FX markup EUR 10-20
Premium subscription EUR 60-120
Interest income EUR 5-15
Total potential EUR 90-185

Break-even Analysis

Scenario Users Required Timeline
BaaS MVP 5,000-10,000 18-24 months
Standard 20,000-30,000 24-36 months
Enterprise 50,000+ 36+ months

Sources

Market Research

Technology Stack

Technical Stack Recommendations

1. Architecture Overview

Principles

  1. Microservices Architecture - Modular, independently deployable
  2. Cloud-Native Design - Containerized, elastic scaling
  3. Security by Design - Zero-trust, encryption everywhere

2. Backend Technology

Primary: Java/Spring Boot

Secondary: Node.js

Hybrid Approach

3. Mobile Development

Recommendation: Flutter

Criteria Flutter React Native Native
Performance Near-native Good Best
Code Sharing 95%+ 85-90% 0%
Market Share 46% 35% -

Why Flutter:

Stack: Bloc, GoRouter, Dio, Hive, local_auth

4. Database & Storage

5. Infrastructure

Cloud: AWS or GCP

Components:

6. Security

OWASP MASVS

7. MVP Stack

Market Research

BankID & Vipps Research

BankID and Vipps Login Authentication Research

Research Date: 2026-02-15 Project: Drop Fintech App Purpose: Evaluate feasibility of integrating BankID and Vipps as authentication methods

Executive Summary

Both BankID and Vipps Login are viable authentication options for Drop. Both support OIDC/OAuth2 integration with Next.js, have test environments, and can serve dual purposes as both authentication and PSD2 Strong Customer Authentication (SCA).

Critical Timeline Note: BankID is undergoing major changes with an April 1, 2026 deadline for migration to new infrastructure.

Key Considerations:

1. Norwegian BankID

What is it?

BankID is Norway's leading electronic identification system, issued through Norwegian banks. It enables secure authentication and digital signatures. BankID supports both traditional methods and the newer BankID with Biometrics (app-based solution using WebAuthn).

Major Change in 2026: BankID is moving to a single issuer (Stø AS) with critical infrastructure changes taking effect April 1, 2026. All integrations must migrate to the new Digital Trust Platform and OIDC-based approach before this deadline.

Integration Method

Technical Requirements:

Reference Implementation: GitHub - BankID OIDC Integration Examples

Requirements to Get Access

Mandatory Prerequisites:

  1. Company must be a customer of a Norwegian bank (within BankID network)
  2. Person signing the contract must have personal eID (Norwegian BankID, Swedish BankID, or Danish MitID)
  3. Completed "Getting Ready for Production" guide (step 5) to obtain production domain
  4. Register application in BankID Developer Portal (freely available)

Application Information Required:

Agreement Process:

  1. Submit application information
  2. Provider sends online agreement for signing
  3. Signed agreement forwarded to your bank for processing
  4. Bank issues client credentials

Cost

Direct from BankID Norge (Reseller Model):

Via Idura/Criipto Aggregator:

NEEDS VERIFICATION: Direct BankID pricing may have changed. Contact BankID Norge for current 2026 pricing.

Technical Complexity

Difficulty Level: Medium

Pros:

Cons:

Estimated Integration Time: 2-4 weeks (including testing and certification)

Timeline

Application to Production:

Critical Dates:

Action Required: Complete migration to Digital Trust Platform before April 1, 2026.

Sandbox/Test Environment

Test Access: Freely available

Test Environment Details:

Testing Tools:

Support: developer@bankidnorge.no

PSD2 Relevance

SCA Compliance: YES - Fully compliant

BankID with biometrics is approved for payments and meets Strong Customer Authentication (SCA) requirements according to PSD2 and 3D Secure standards.

Technical Details:

Use Cases for Drop:

  1. User authentication/login
  2. PSD2 payment authorization (SCA)
  3. Combined auth + payment flow

Alternative Providers

Aggregator Services (Recommended):

  1. Idura (formerly Criipto)

    • Bundles BankID + Vipps + other Nordic eIDs
    • Single integration point for multiple providers
    • Pricing: €65-€390/month + per-transaction fees
    • Website: idura.eu

  2. Signicat

    • Largest BankID provider in Norway (established 2007)
    • Enterprise-focused solution
    • Offers authentication + digital signatures
    • Pricing: Contact for quote
    • Website: signicat.com

  3. Curity

    • Identity platform with Norwegian BankID support
    • OIDC authenticator approach
    • Enterprise-grade solution
    • Website: curity.io

Recommendation: For Drop's use case (fintech startup), Idura offers the best balance of simplicity, cost-effectiveness, and multi-provider support.

2. Vipps Login

What is it?

Vipps is Norway's #1 mobile payment provider with near-ubiquitous adoption. Vipps Login is an authentication service that allows users to log in using their mobile number. The brand split: Vipps (Norway/Sweden) and MobilePay (Denmark/Finland) use the same API under Vipps MobilePay.

Scope: Login API confirms customer identity and provides access to verified data: name, birthdate, social security number, address, email, phone number.

Integration Method

Implementation Example:

import NextAuth from "next-auth"
import Vipps from "next-auth/providers/vipps"

export const { handlers, auth, signIn, signOut } = NextAuth({
  providers: [Vipps],
})

Test Mode Override:

Vipps({ issuer: "https://apitest.vipps.no/access-management-1.0/access/" })

Key Endpoint:

Requirements to Get Access

Application Process:

  1. Order product at vippsmobilepay.com
  2. Complete "Login checklist" for direct integration
  3. Partner application review
  4. Receive test credentials via email (test phone number + national identity number)

Company Requirements:

Technical Setup:

Cost

Per-Transaction Pricing:

Via Idura Aggregator:

Notes:

Technical Complexity

Difficulty Level: Low-Medium

Pros:

Cons:

Estimated Integration Time: 1-2 weeks

Timeline

Application to Production:

Recommendation: Contact Vipps developer support for exact onboarding timeline.

Sandbox/Test Environment

Test Environment: Merchant Test (MT) - Available to all API merchants

Access Details:

Test User Credentials:

Limitations:

Suitable For: Websites, e-commerce, apps, loyalty programs

PSD2 Relevance

SCA Compliance: YES - Fully compliant

Vipps has implemented PSD2-compliant Strong Customer Authentication with regulatory-approved delegated SCA from card issuers.

Technical Details:

Use Cases for Drop:

  1. User authentication/login
  2. PSD2 payment authorization
  3. Simplified payment flow (no separate 3DS step needed)

Advantage: Vipps SCA is transparent to users (already authenticated in app), creating smoother UX than traditional 3DS flows.

Alternative Providers

Same aggregators as BankID:

  1. Idura (formerly Criipto)

    • Bundles Vipps with BankID and other eIDs
    • Single integration, multiple auth methods
    • Transparent pricing model

  2. Signicat

    • Enterprise solution
    • Combined authentication suite
    • Contact for pricing

Recommendation: If implementing both BankID AND Vipps, use Idura aggregator to manage both via single integration point.

3. Aggregator Comparison

Why Use an Aggregator?

Benefits:

  1. Single integration point for multiple eID providers
  2. Simplified SDK/API (abstraction layer)
  3. Unified billing and reporting
  4. Faster time-to-market
  5. Reduced maintenance burden
  6. Future-proof (easy to add more eID methods)

Trade-offs:

  1. Additional monthly platform fee (€65-€390)
  2. Dependency on third-party service
  3. Potential slight latency increase

Idura (Criipto) - Recommended

What is it: European eID verification platform (formerly Criipto, rebranded to Idura)

Supported eIDs:

Pricing Structure:

Technical:

Best For: Drop's use case - need both BankID + Vipps with potential Nordic expansion

Signicat - Enterprise Alternative

What is it: Europe's largest eID and signature provider (established 2007)

Position: Largest BankID provider in Norway

Pricing: Contact for quote (not publicly listed)

Best For: Large enterprises, complex compliance needs, high-volume applications

Direct Integration vs Aggregator

For Drop, Recommend: Idura Aggregator

Reasoning:

  1. Supports both BankID and Vipps through one integration
  2. Transparent pricing (€140/month Medium tier likely sufficient)
  3. Future-proof for Nordic expansion
  4. Faster development (proven SDK)
  5. Lower maintenance burden
  6. Cost-effective at expected volume (<10,000 logins/month)

Break-even Analysis:

4. Implementation Recommendations

Phase 1: Email + Password (MVP)

Phase 2: Add BankID (Primary eID)

Phase 3: Add Vipps Login (Alternative)

Phase 4: Optimize Flow

Technical Architecture

Next.js 16 App Router
├─ Auth.js (NextAuth v5) - OIDC client
├─ Idura Verify - eID aggregator
│  ├─ Norwegian BankID
│  └─ Vipps Login
├─ jose - JWT signing/verification
└─ PostgreSQL - user sessions

Flow:

  1. User clicks "Log in with BankID" or "Log in with Vipps"
  2. Next.js redirects to Idura OIDC endpoint
  3. Idura redirects to BankID/Vipps
  4. User authenticates
  5. Idura returns to callback with ID token
  6. Next.js validates token, extracts claims (name, SSN, email)
  7. Create/update user in database
  8. Issue JWT session token (jose)
  9. User authenticated

Security Considerations:

Timeline Estimate

Development Timeline:

Total: 8 weeks to production-ready dual eID authentication

Cost Projection (First Year)

Assumptions:

Calculation:

At Scale (10,000 users):

Conclusion: Cost scales linearly with users, remains affordable for fintech startup.

5. Risks and Mitigations

BankID Migration Risk (Critical)

Risk: April 1, 2026 deadline for Digital Trust Platform migration

Impact: Service disruption if not migrated in time

Mitigation:

Age Verification Accuracy

Risk: Users might bypass age check with email/password

Mitigation:

User Adoption

Risk: Users unfamiliar with eID login may abandon signup

Mitigation:

Service Availability

Risk: BankID/Vipps downtime prevents login

Mitigation:

Regulatory Changes

Risk: PSD2/eIDAS requirements may change

Mitigation:

6. Questions Needing Verification

The following points require direct contact with providers for confirmation:

  1. BankID Direct Pricing: Current 2026 per-transaction costs (NOK 8,300/month model unclear on variable costs)
  2. Vipps Timeline: Exact onboarding timeline from application to production
  3. Vipps Active Users Model: Current 2026 pricing structure for active users billing
  4. Idura Large Tier: Volume thresholds for Small/Medium/Large tiers
  5. Minimum Requirements: Specific business registration requirements for Vipps merchant account
  6. SCA Dual-Use: Confirm BankID/Vipps can be used for BOTH login and payment authorization in same session
  7. April 2026 Migration: Detailed requirements if integrating direct BankID (not via aggregator)

7. Final Recommendation

Recommendation: Implement BOTH BankID and Vipps via Idura aggregator

Justification:

  1. Regulatory Compliance: BankID satisfies identity verification (18+, Norwegian resident)
  2. User Preference: Vipps more familiar, offers free login option
  3. PSD2 Dual-Use: Both serve as authentication AND SCA for payments
  4. Cost-Effective: Idura cheaper than direct integration until high volume
  5. Risk Mitigation: Idura handles April 2026 BankID migration
  6. Future-Proof: Easy to add Swedish/Danish eIDs for Nordic expansion
  7. Development Speed: Faster implementation with proven SDK

Implementation Priority:

  1. Phase 1: Email/Password (MVP launch)
  2. Phase 2: BankID via Idura (compliance requirement)
  3. Phase 3: Vipps via Idura (user convenience)

Next Steps:

  1. Contact Idura sales for Medium tier quote and setup
  2. Register test account and explore SDK documentation
  3. Validate integration with Next.js 16 App Router
  4. Architect user database schema (with eID verification fields)
  5. Implement BankID flow first (higher priority for compliance)
  6. Add Vipps as alternative option
  7. Load test authentication flow
  8. Production deployment with monitoring

Sources

BankID Sources

Vipps Sources

PSD2/SCA Sources

Aggregator Sources

Report Prepared By: John (AI Director) Last Updated: 2026-02-15 Status: Research complete, awaiting approval for implementation

Market Research

Cloud Cost Analysis

Drop — Cloud Deployment Cost Analysis

Date: 2026-02-11 Author: John (AI Director) Status: Historical — superseded by ADR-014 (PostgreSQL-only) and ADR-012 (AWS App Runner)

NOTE (2026-03-03): This analysis was written before ADR-014 mandated PostgreSQL 16 in all environments. SQLite references below reflect the old architecture and are no longer valid. Current deployment: AWS App Runner + AWS RDS PostgreSQL 16. See ADR-012 and ADR-014.

Current Tech Stack

Layer Tech Production Note
App Next.js 16 (App Router) Monolith, ~7 pages + API
Frontend React 19 + Tailwind v4 SSR/SSG
DB SQLite (better-sqlite3) Must migrate to PostgreSQL for production
Auth JWT (jose) httpOnly cookie OK for production
Dependencies bcryptjs, radix-ui, lucide, sonner Lightweight
Dev server Port 3001 (configured in project.json) Currently running locally

Key constraint: SQLite cannot handle concurrent writes (ADR-001). Must switch to PostgreSQL before launch.

Phase 1: MVP / Demo (now → 200 users)

Provider Plan Price/mo Notes
Vercel Pro Next.js native $20 (~215 NOK) No persistent FS — SQLite won't work without Turso/Neon
Railway Starter Next.js + persistent disk $5 + usage (~160 NOK) SQLite works here
Fly.io Hobby LiteFS support $5 + usage (~160 NOK) Great for SQLite
Hetzner VPS (shared) On same CPX41 +~0 NOK If already provisioned from system migration

Recommended Phase 1 Stack

Item Provider Cost/mo
App hosting Hetzner VPS (shared) or Railway 0-160 NOK
DB SQLite (local) 0
Domain getdrop.no (one.com) ~100 NOK/yr
SSL Let's Encrypt / Cloudflare 0
Total Phase 1 ~10-170 NOK/mo

Phase 2: Launch (200-3,000 users)

SQLite → PostgreSQL migration required. Need transactional email and SMS for auth.

Item Provider Cost/mo
App hosting Railway or Fly.io $10-20 (~110-215 NOK)
PostgreSQL managed Neon free→Pro $19 or Supabase free→$25 0-270 NOK
Transactional email Resend (3,000 free/mo) → $20 0-215 NOK
SMS (OTP auth) Twilio ~$0.05/SMS × 500/mo ~270 NOK
CDN Cloudflare Free 0
Monitoring Sentry free tier 0
BaaS (Wise API) Per-transaction fee Covered by tx fees
Total Phase 2 ~400-1,000 NOK/mo

Phase 3: Scale (3,000-15,000 users)

Fintech = reliability, backups, WAF, logging required.

Item Provider Cost/mo
App hosting (2 instances) Railway Pro or Fly.io $30-50 (~325-540 NOK)
PostgreSQL managed (HA) Neon Pro $69 or Supabase Pro $25+usage 270-750 NOK
Redis (caching/sessions) Upstash free→$10 0-110 NOK
Transactional email Resend Pro $20 215 NOK
SMS (OTP) Twilio × 3,000/mo ~1,600 NOK
CDN + WAF Cloudflare Pro $20 215 NOK
Monitoring Sentry Team $26 280 NOK
Logging Betterstack free→$25 0-270 NOK
Backup storage Backblaze B2 55 NOK
BaaS APIs (Wise/Thunes/Swan) Per-tx, variable Covered by tx fees
Total Phase 3 ~3,000-4,000 NOK/mo

Summary

Phase Users Infra cost/mo MRR (from business case) Margin
MVP 0-200 10-170 NOK 0-12,000 NOK — (pre-revenue)
Launch 200-3,000 400-1,000 NOK 12,000-130,000 NOK 90%+
Scale 3,000-15,000 3,000-4,000 NOK 130,000-650,000 NOK 97%+

Infrastructure cost is negligible vs revenue. Fintech margins on infra are excellent — biggest costs are marketing (30-50K/mo) and compliance, not hosting.

Shared Hetzner VPS Option

Drop can run on the same Hetzner CPX41 (from system migration analysis) for +0 NOK incrementally:

Only at 3,000+ users should Drop move to dedicated infrastructure.

Business & Partnerships

Business & Partnerships

Requirements Document

Requirements Document: [PROJECT NAME]

Version: 1.0 Date: YYYY-MM-DD Author: Business Analyst / Product Owner Status: Draft | In Review | Approved Client Sign-off: ☐

1. Introduction

1.1 Purpose

[Why this document exists, what it covers]

1.2 Project Reference

1.3 Stakeholders

Name Role Interest Contact

2. Functional Requirements

FR-001: [Feature Name]

FR-002: [Feature Name]

3. Non-Functional Requirements

3.1 Performance

Metric Target Measurement
Page load time < 2s Lighthouse
API response time < 500ms Server logs
Concurrent users [X] Load test

3.2 Security

3.3 Accessibility

3.4 Scalability

3.5 Reliability

4. Data Requirements

4.1 Data Entities

Entity Description Source Volume

4.2 Data Retention

Data Type Retention Period Deletion Method

5. Integration Requirements

System Direction Protocol Data Frequency
In/Out/Both REST/GraphQL/Webhook Real-time/Batch

6. Constraints

7. Assumptions

8. MoSCoW Prioritization Summary

Priority Count Items
Must Have FR-001, FR-002...
Should Have
Could Have
Won't Have

9. Sign-off

Role Name Date Approved
Product Owner ☐
Tech Lead ☐
Client ☐
Business & Partnerships

SpareBank1 Partnership Pitch

Drop x Sparebanken — Partnership Proposal

Prepared by: ALAI Holding AS Date: February 2026 Contact: Alem Bašić, CEO — alem@alai.no Confidential

The Opportunity

There are 1 million immigrants living in Norway. They send 5.7 billion NOK home every year. They shop at 30,000+ immigrant-owned businesses across the country.

Today, they use Western Union (5-10% fees), Wise (no local presence), or cash. Their local shops pay Vipps 1.75-2.75% per transaction. Neither side is well-served.

Drop fixes both — in one app.

What is Drop?

Drop is a fintech app for everyone in Norway with two core features:

1. Remittance

Send money to family abroad. Receiver needs no app — money arrives to their bank account or cash pickup point.

2. QR Merchant Payments

Pay at local shops by scanning a QR code. Cheaper than Vipps for merchants.

The Flywheel

User sends remittance → gets familiar with Drop → pays at local shop with QR
Merchant accepts QR → recommends Drop → more users send remittance
→ REPEAT

No one in Norway combines remittance + QR payments. That's our edge.

Why Sparebanken?

We're not building another bank. We're building the interface for a community that banks don't reach effectively. But we need a banking partner to do it right.

What we need from Sparebanken:

Capability Purpose
Open Banking (PSD2) AISP (account information) and PISP (payment initiation)
KYC/AML infrastructure Compliant onboarding for users and merchants
Payment rails Settlement, SEPA, domestic transfers
Regulatory umbrella Operate under Sparebanken's licence (agent model)
Trust A Norwegian bank brand behind the product

What Sparebanken gets:

1. Access to an underserved 1M-person market Immigrants in Norway are underbanked in cross-border services. Drop is the distribution channel into this community — a community that trusts word-of-mouth over advertising.

2. New revenue stream — zero development cost

3. Innovation & ESG story Financial inclusion for immigrants is a powerful narrative. Sparebanken gets positioned as the bank that actually serves all of Norway — not just ethnic Norwegians.

4. Fintech partnership without the risk Drop builds and operates the product. Sparebanken provides infrastructure. Low investment, high upside.

Market Size

Metric Value Source
Immigrants in Norway ~1,000,000 SSB
Annual remittance from Norway 5.7 billion NOK World Bank
Immigrant-owned businesses 30,000-50,000 SSB estimate
Average remittance transaction ~1,000 NOK World Bank
Vipps merchant fee 1.75-2.75% Vipps.no
Drop merchant fee 1.0% —

Serviceable market (Year 1): Balkan + Pakistani diaspora in Oslo area = ~200,000 people, ~5,000 businesses.

Financial Projections

Period Users Merchants Monthly Revenue
Month 1-3 200 20 12,000 NOK
Month 4-6 1,000 80 50,000 NOK
Month 7-12 3,000 200 130,000 NOK
Year 2 8,000 500 330,000 NOK
Year 3 15,000 1,000 650,000 NOK

Year 3 ARR: ~7.8M NOK

Revenue split model TBD — we propose 70/30 (Drop/Sparebanken) on transaction fees, with Sparebanken retaining 100% of float income and cross-sell revenue.

Competitive Landscape

Remittance QR Payments Diaspora Focus Bank Partner
Vipps No Yes (expensive) No DNB
Wise Yes No No None in Norway
Western Union Yes (expensive) No Yes (bad UX) Various
Revolut Yes (generic) Limited No None in Norway
Drop Yes (cheap) Yes (cheap) Yes (core) Available

Drop is the only product in Norway that combines remittance + QR payments. First bank partner gets exclusivity.

Detailed Comparison: Drop vs Alternatives

Why not PayPal?

PayPal Drop
NOK → RSD/BAM corridor Not supported Core feature
NOK → PKR corridor Limited, poor rates Supported
Cross-border fee 3-5% + currency markup 0.5% flat
Receiver requirement Must have PayPal account No app needed — bank transfer or cash pickup
In-store QR payment Not available in Norway Core feature (1% merchant fee)
Target audience No — generic global Yes — built for everyone in Norway
Norwegian language Partial Full (nb/nn)
Local bank partner None in Norway SpareBank 1 (proposed)

PayPal does not support the corridors that matter most to Norwegian diaspora (Balkans, Pakistan, Turkey). Drop is purpose-built for these communities.

Why not Revolut?

Revolut Drop
Remittance Person-to-person only (both need account) Receiver needs NO app
Fee 0.5-1.5% + weekend markup 0.5% flat, no markup
Merchant payments Limited (no QR in Norway) QR code — 1% fee
Regulatory Lithuanian banking licence Norwegian bank partner (proposed)
Community Generic fintech Local community, word-of-mouth growth
Cash pickup Not available Planned for Phase 2

Revolut requires the receiver to also have a Revolut account. For a grandmother in rural Bosnia or Pakistan, that's not realistic. Drop sends directly to local bank accounts.

Why not Wise?

Wise Drop
Fee 0.7-1.5% (variable) 0.5% flat
QR payments None Core feature
Merchant services None Dashboard, settlement, QR
Norwegian presence No local office or support Norwegian company, Norwegian bank
Community features None Locally-focused UX and corridors

Wise is excellent for one-off international transfers but offers no merchant services, no QR payments, and no local banking relationship in Norway.

Security, Compliance & Trust

Regulatory Framework

Drop will operate under the agent model (betalingsforetak-agent) as defined in the Norwegian Financial Institutions Act (finansforetaksloven). This means:

Aspect Approach
Licence SpareBank 1 holds the licence; Drop operates as registered agent
Regulator Finanstilsynet (Norwegian FSA)
EU Directive PSD2 compliant — Strong Customer Authentication (SCA)
Pass-through Drop never holds customer money — PISP/AISP via Open Banking
Reporting All regulatory reporting through SpareBank 1's existing infrastructure

This model is proven — it's how Vipps originally launched under DNB's licence, and how several European fintech apps operate today.

AML/KYC — Anti-Money Laundering & Know Your Customer

Requirement Implementation
User onboarding ID verification via BankID or passport + selfie
KYC provider Flexible — Sumsub, Onfido, or SpareBank 1's existing KYC system
Risk scoring Automatic risk assessment at onboarding based on country, amount, frequency
Transaction monitoring Real-time screening against sanctions lists (EU, UN, OFAC)
Suspicious Activity Reports (SAR) Automated flagging + manual review, reported to Enheten for finansiell etterretning (EFE)
PEP screening Politically Exposed Persons check at onboarding and ongoing
Transaction limits Tiered limits based on KYC level (basic: 10,000 NOK/month, full: 50,000 NOK/month)
Record keeping All KYC data and transaction records stored for minimum 5 years per hvitvaskingsloven

Data Protection & Privacy

Aspect Implementation
GDPR compliance Full — data processing agreement (DPA) with SpareBank 1
Data residency All user data stored in EU/EEA (Norwegian data centres preferred)
Encryption in transit TLS 1.3 for all API communication
Encryption at rest AES-256 for stored personal data and credentials
Data minimisation Only necessary data collected per GDPR Art. 5(1)(c)
Right to deletion GDPR Art. 17 — users can request account deletion (except regulatory-required records)
Privacy policy Norwegian and English, clearly written for non-native speakers

Application Security

Layer Measure
Authentication JWT tokens in httpOnly cookies (XSS-resistant)
Password storage bcrypt hashing (never stored in plaintext)
SQL injection Parameterised queries throughout (prepared statements)
Rate limiting Per-IP rate limiting on all public endpoints
Input validation Server-side validation on all user input
CORS policy Strict origin policy — no wildcard
Dependency audit Automated npm audit in CI/CD pipeline
Penetration testing Planned before pilot launch — external auditor (e.g., mnemonic, NorSIS-certified)

Audit & Certification Roadmap

Milestone Timeline Description
Internal security review Before pilot Full codebase review, threat modelling
External penetration test Before pilot Third-party audit by certified Norwegian security firm
SOC 2 Type I Within 6 months of launch Controls documentation and assessment
SOC 2 Type II Within 12 months Operational effectiveness over time
ISO 27001 Year 2 target Information security management system certification
PCI DSS If card issuing implemented Payment card industry compliance

Fraud Prevention

Mechanism Description
Velocity checks Maximum transactions per hour/day per user
Amount thresholds Transactions above threshold require additional verification
Device fingerprinting Track trusted devices, flag new device logins
Geo-anomaly detection Flag transactions from unusual locations
Recipient patterns Alert on new recipients in high-risk corridors
Manual review queue Flagged transactions reviewed by compliance team before processing

Risk Assessment

Risk Probability Impact Mitigation
Corridor closure (geopolitical) Low High Multi-corridor strategy; no single-country dependency; partner with multiple payment providers
Regulatory change Medium High Agent model reduces direct regulatory burden; SpareBank 1 handles compliance changes
Fraud / money laundering Medium High Multi-layer AML/KYC; real-time monitoring; transaction limits; SAR reporting
User account compromise Medium Medium 2FA via BankID; device tracking; session management; instant account freeze
Technical outage Low Medium Cloud-hosted with redundancy; health monitoring; <1h recovery target
Competition (Vipps enters remittance) Medium Medium First-mover in diaspora niche; community lock-in; merchant network effect
Low adoption Medium Medium Word-of-mouth growth model; community ambassadors; zero marketing spend needed for pilot
Partner bank exit Low High Modular architecture allows switching BaaS provider; data portability by design

Product Status

Drop MVP is built and functional:

Ready for: BaaS integration, compliance review, pilot launch.

Proposed Partnership Model

Phase 1: Pilot (3 months)

Phase 2: Launch (6 months)

Phase 3: Scale (12+ months)

About ALAI Holding AS

ALAI Holding AS is an AI-native digital agency based in Norway. We build software, design, and infrastructure — powered by AI at every level.

Next Steps

  1. Intro meeting — 30 min, virtual or in-person
  2. Technical deep-dive — Drop architecture + Sparebanken BaaS capabilities
  3. Compliance review — Joint assessment of regulatory requirements
  4. Pilot agreement — Terms for Phase 1

We're ready when you are.

ALAI Holding AS — We build digital. You build business. Confidential — Not for distribution

Business & Partnerships

Features, Merchants & Rates

Drop — Merchant, Recipients & Rates

Note (2026-02-14): This document predates the current architecture. Drop now uses a pass-through PSD2 model (PISP/AISP) — Drop NEVER holds customer money. Some sections below reference wallet/balance concepts from the earlier BaaS design. The current architecture is defined in architecture-document.md and Drop CLAUDE.md.

1. Recipients

Data Model

interface Contact {
  id: string;
  name: string;
  iban: string;
  avatar: string;  // 2-char initials
}

Current Implementation

Sample contacts (hardcoded in src/app/send/page.tsx):

Name IBAN Country
Sara M. DE89370400440532013000 Germany
Amir K. FR7630006000011234567890189 France
Lejla H. AT611904300234573201 Austria

Mock contacts (src/lib/mockData.ts):

Name IBAN Country
John Doe DE89 3704 0044 0532 0130 00 Germany
Jane Smith FR76 3000 6000 0112 3456 7890 189 France
Mike Wilson GB29 NWBK 6016 1331 9268 19 UK

RecipientStep UI (src/app/send/page.tsx)

Send Money Flow (6 steps)

RecipientStep → AmountStep → ConfirmStep → Processing → Success/Error
  1. Recipient — select from contacts or search
  2. Amount — input + quick buttons (€10, €50, €100, €200) + optional note
  3. Confirm — review: amount, recipient, IBAN, note, fee (Free)
  4. Processing — loading animation
  5. Success — confirmation with amount and name
  6. Error — message + retry

API: Send Money

POST /api/transactions
Authorization: Bearer <jwt>
Body: { toIban: string, amount: number, reference?: string }

Validations:

Future (not yet implemented)

2. Merchant Payments

Current State: Demo Only

Merchant payments exist as:

Transaction Types

Type Direction Use Case
SepaCredit Debit Outgoing SEPA transfer
SepaDebit Credit Incoming SEPA transfer
CardTransaction Debit Card purchase at merchant

AppContext Method

const simulatePurchase = async (amount: number, merchant: string) => {
  // No-op — no API route for card purchases yet
  console.log("[AppContext] simulatePurchase not implemented:", { amount, merchant });
  return { id: 'demo_auth', amount, merchant };
};

Stripe Issuing Mock (src/lib/services/mock-stripe.ts)

Card authorization logic:

Transaction Display (src/components/TransactionItem.tsx)

Shows for each transaction:

Future (post-MVP)

3. Rates, Fees & Limits

Currency

MVP: EUR only (single account)

Formatting (src/lib/mockData.ts):

formatCurrency(amount, currency = "EUR")
// Uses Intl.NumberFormat("de-DE") → "€1.234,56"

Fees

Transaction Type Fee
SEPA transfer Free
Card top-up Free
Card payment Free (interchange 0.2-0.3% from merchant)

All transfers show "Free" in the UI confirmation step.

Transfer Limits (from MVP spec)

Type Daily Monthly
Internal P2P €5,000 €20,000
SEPA €2,000 €10,000

Top-up Limits

Parameter Value
Minimum €5
Maximum €10,000
Preset options €20, €50, €100, €200, €500

Card Spending

Parameter Value
Monthly limit (default) €5,000
Tracked via spent_this_month column

Revenue Model (post-MVP)

Stream Rate
Interchange fees 0.2-0.3% of card transactions
FX markup 0.5-2% on currency conversion
Premium subscription €5-15/month
Interest income On deposits
Lending Personal loans, BNPL, overdrafts

Multi-Currency (Future)

4. Database Schema Reference

transactions

CREATE TABLE transactions (
  id TEXT PRIMARY KEY,
  account_id TEXT NOT NULL REFERENCES accounts(id),
  type TEXT NOT NULL,        -- SepaCredit | SepaDebit | CardTransaction
  amount REAL NOT NULL,
  currency TEXT DEFAULT 'EUR',
  direction TEXT NOT NULL,   -- Credit | Debit
  status TEXT DEFAULT 'Pending',  -- Pending | Booked | Rejected
  counterparty TEXT,         -- Recipient IBAN or merchant name
  reference TEXT,            -- Payment note
  created_at TEXT DEFAULT (datetime('now'))
);

accounts

CREATE TABLE accounts (
  id TEXT PRIMARY KEY,
  user_id TEXT NOT NULL REFERENCES users(id),
  iban TEXT UNIQUE NOT NULL,   -- Format: BA393912XXXXXXXX
  bic TEXT DEFAULT 'FONLBA22',
  currency TEXT DEFAULT 'EUR',
  balance REAL DEFAULT 0,
  status TEXT DEFAULT 'Opened',
  created_at TEXT DEFAULT (datetime('now'))
);

cards

CREATE TABLE cards (
  id TEXT PRIMARY KEY,
  user_id TEXT NOT NULL REFERENCES users(id),
  type TEXT NOT NULL DEFAULT 'virtual',
  brand TEXT DEFAULT 'Visa',
  last4 TEXT NOT NULL,
  exp_month INTEGER NOT NULL,
  exp_year INTEGER NOT NULL,
  status TEXT DEFAULT 'active',
  spending_limit REAL DEFAULT 5000,
  spent_this_month REAL DEFAULT 0,
  cardholder_name TEXT,
  created_at TEXT DEFAULT (datetime('now'))
);

5. Open Tasks (Related)

Task Priority Description
#191 HIGH Wire /send page to /api/transactions/remittance
#192 HIGH Wire /scan page to /api/transactions/qr-payment
#193 HIGH Wire /merchant page to real APIs
#198 LOW Delete mock-data.ts and orphaned components

SpareBank 1 — Technical Stack Research

SpareBank 1 — Teknisk Stack Research

Dato: 2026-02-18 Formål: Forstå SpareBank 1s teknologivalg for å tilpasse Drops arkitektur

Oversikt

SpareBank 1 er Norges nest største finansgruppe med 13 selvstendige banker. De har en felles teknologiplattform kalt Eunomia som er bygget på Azure.

Teknisk Stack

Komponent Teknologi Detaljer
Sky Microsoft Azure Strategisk partnerskap med Microsoft
Sekundær sky AWS Mindre workloads
Backend Kotlin / Java Spring Boot-basert
Frontend React + TypeScript Moderne SPA-arkitektur
Orkestrering Kubernetes / OpenShift Container-basert deploy
Meldingskø Apache Kafka Event-drevet arkitektur
Autentisering BankID Norsk eID-standard
API Gateway Axway Enterprise API management
CI/CD GitHub Actions / Jenkins Automatisert pipeline

Eunomia-plattformen

Relevans for Drop

Hva vi bør kopiere:

  1. Azure som sky — reduserer friksjon ved partnerskap
  2. BankID-integrering — allerede implementert i Drop
  3. Containerisert arkitektur — Docker/Kubernetes for portabilitet
  4. Event-drevet design — viktig for sanntids transaksjoner

Hva vi IKKE trenger å kopiere:

  1. Kotlin/Java backend — TypeScript er tilstrekkelig for vår skala
  2. Kafka — overkill for MVP, kan vurderes senere
  3. Axway API Gateway — for enterprise, vi bruker enklere løsninger
  4. OpenShift — standard Kubernetes eller Cloud Run er nok

Regulatorisk Kontekst

Kilder

Gdje smo zapeli sa Dropom — Status Report (2026-02-20)

Gdje smo zapeli sa Dropom

Datum: 2026-02-20 Autor: John (AI Director)

Executive Summary

Drop je MVP demo — lijep UI, kompletna dokumentacija, security-hardened kod, ali nula pravih plaćanja. Kritični blocker: banking partner (SpareBank 1 pitch pending).

Svi sistemi koje Drop treba da bi radio

1. BANKING PARTNER (Blocker #1 — KRITIČNO)

Drop je PSD2 pass-through — nikad ne drži pare korisnika. Ali za to treba:

Potreba Opis Status
Open Banking API AISP za čitanje balansa, PISP za iniciranje plaćanja ❌ NEMA — mock only
BankID integracija Strong Customer Authentication — obavezna za svaku transakciju ❌ NEMA — demo mode
Settlement SEPA, domaći transferi ❌ NEMA
Regulatorna kišobran Agent model — Drop radi pod bankovnom licencom ❌ NEMA

SpareBank 1 Sør-Norge Partnership:

Bez banking partnera = Drop ne može:

2. KYC/AML SISTEM

Komponenta Status Napomena
Sumsub SDK ✅ Integriran (JEDINA produkcijska integracija) Auto-approve u demo modu
PEP screening ❌ NEMA Treba za compliance
Sanctions screening ❌ NEMA Treba za compliance
Transaction monitoring ❌ NEMA Obavezno za AML

3. REMITTANCE BACKEND

Potreba Status
Wise Business API ili Thunes ❌ Planirano, ništa integrirano
Koridor provideri (Srbija, BiH, Pakistan, Turska, Poljska, EU) ❌ Planirano
Exchange rate real-time feed ❌ Planirano

4. LICENCA (Finanstilsynet)

Opcija Timeline Kapital Status
Agent model (SpareBank) 1-3 mjeseca 0 EUR ❌ Čeka SpareBank odgovor
Begrenset betalingsforetak 3-6 mjeseci 0 EUR (limit 6M NOK/mj) ❌ Backup plan
Ordinaert betalingsforetak 6-12 mjeseci 125,000 EUR ❌ Full EEA opcija

Nije aplicirano ni za jednu opciju.

5. PAYMENT INFRASTRUKTURA

Komponenta Status
QR payment processing ❌ Treba settlement partner
Card issuing ❌ Stripe mock postoji, treba pravi partner
Exchange rate provider ❌ Za remittance konverzije

6. DATABASE MIGRACIJA

7. HOSTING / INFRASTRUKTURA

Komponenta Status
Landing page (getdrop.no) ✅ Vercel
Staging ✅ Fly.io (drop-staging.fly.dev)
Production ❌ Treba proper produkcijski setup

8. COMPLIANCE DOKUMENTACIJA

Overall compliance readiness: 8/100

9. CRM / MARKETING

Šta Drop TRENUTNO ima (šta radi)

Tech Stack

Šta radi u demo modu

Jedina prava integracija

Kritični path do Go-Live

1. Secure banking partner (SpareBank odluka ili pivot na Swan BaaS)
   ↓
2. PISP/AISP registracija sa Finanstilsynet (zahtijeva partnera)
   ↓
3. BankID integracija (zahtijeva partner API pristup)
   ↓
4. Real KYC aktivacija (Sumsub production mode)
   ↓
5. Transaction monitoring system (AML compliance)
   ↓
6. PostgreSQL migracija (skalabilnost)
   ↓
7. External penetration test (security validacija)
   ↓
8. GO LIVE

Timeline procjena:

Rizici

Rizik Vjerovatnoća Uticaj Mitigacija
SpareBank odbije SREDNJA KRITIČAN Pivot na Swan BaaS ili drugu banku
Finanstilsynet zahtijeva više SREDNJA VISOK 16 legal dokumenata već pripremljeno
Sumsub production problemi NISKA SREDNJI SDK već integriran, samo switch na prod
SQLite bottleneck NISKA SREDNJI PostgreSQL migracija planirana

Zaključak

Drop je tehnički spreman za integraciju — UI gotov, API gotov, security hardened, legal docs pripremljeni. Jedini pravi blocker je banking partner. Sve ostalo se može paralelizirati čim imamo partnera.

Sljedeći korak: Pratiti SpareBank odgovor i pripremiti backup plan (Swan BaaS ili direktna aplikacija za licencu).

Oppstartstilskudd 1 — Søknad (v2)

Søknad om Oppstartstilskudd 1

Drop — AI-drevet betalingsplattform for rimelige pengeoverføringer og sikre QR-betalinger i Norge

Søker: BASIC AS Organisasjonsnummer: 932 516 136 Opererer som: ALAI Kontaktperson: Alem Basic E-post: alem@alai.no Telefon: +47 40 47 42 51

Prosjektnavn: Drop — AI-drevet betalingsplattform med intelligent svindeldeteksjon, regulatorisk compliance-motor og sanntids valutahåndtering Søkt beløp: 150 000 NOK Prosjektperiode: 9 måneder Søknadsdato: 18. februar 2026

1. Prosjektbeskrivelse

1.1 Idé og Formål

Drop er en AI-drevet betalingsplattform som gjør kompleks finansteknologi usynlig enkel for sluttbrukeren. Bak den intuitive brukeropplevelsen ligger fire avanserte teknologiske systemer:

  1. AI-basert svindeldeteksjon som overvåker hver transaksjon i sanntid
  2. Automatisert regulatorisk compliance-motor som håndterer PSD2, AML, GDPR og SCA-krav på tvers av EØS-jurisdiksjoner
  3. Sanntids valutakursoptimalisering med intelligent routing mellom betalingskorridorer
  4. Ende-til-ende sikkerhetsarkitektur med BankID-autentisering, kryptert kommunikasjon og mønstergjenkjenning

Disse systemene muliggjør to brukerrettede tjenester:

  1. Remittance (pengeoverføringer): Send penger til 30+ land med 0,5% gebyr — langt under konkurrentene Wise (0,7-1,5%), Western Union (5-10%) og MoneyGram (4-8%)
  2. QR-betalinger: Betal i butikken ved å skanne en QR-kode, med 1% gebyr til merchant — billigere enn Vipps (1,75-2,75%)

Drop benytter en pass-through PSD2-modell (PISP/AISP) og holder aldri kundens penger. Alle betalinger initieres direkte fra brukerens bankkonto via Open Banking-integrasjon med BankID-samtykke. Denne tilsynelatende enkle modellen krever imidlertid omfattende regulatorisk compliance-automatisering — nettopp det Drop's teknologiske plattform er bygget for å håndtere.

1.2 Hvorfor Dette Er Viktig

Norge har rundt 1 million innbyggere med innvandrerbakgrunn (SSB) som årlig sender 5,7 milliarder NOK til utlandet (World Bank). Samtidig finnes det 30 000-50 000 lokale små bedrifter (kebab-sjapper, kiosker, bakerier, frisører, restauranter) som betaler 1,75-2,75% i Vipps-gebyrer for korttransaksjoner.

Ingen eksisterende aktør i Norge kombinerer disse to behovene. Drop skaper en flywheel-effekt: Brukere som sender remittance blir vant til appen → begynner å bruke QR-betaling lokalt → merchantene anbefaler appen → nye brukere sender også remittance.

1.3 Hva Er Nytt?

Forretningsmodell:

Teknologisk innovasjon:

1.3b Teknologisk Dybde

Drop's teknologiske kompleksitet ligger i fire parallelle systemer som arbeider sammen i bakgrunnen, usynlige for sluttbrukeren men kritiske for plattformens funksjon:

a) AI-basert svindeldeteksjon

En maskinlæringsmodell analyserer transaksjonsdata i sanntid og scorer risiko for hver transaksjon basert på:

Det som skiller Drop fra eksisterende løsninger er at modellen ikke er regelbasert (statiske terskelverdier), men adaptiv — den lærer kontinuerlig fra nye transaksjoner og tilpasser seg nye svindelmetoder uten manuell oppdatering. Dette er kritisk i et landskap der svindelmetoder endres raskt.

b) Regulatorisk compliance-motor

PSD2-modellen høres enkel ut — "vi holder ikke penger, bare initierer betalinger" — men i praksis krever det automatisering av kompleks regulatorisk logikk:

Motoren tilpasser seg automatisk til regulatoriske endringer gjennom konfigurerbare regelsett — kritisk for skalering til nye EØS-land uten at hver jurisdiksjon krever manuell kode-endring. Dette reduserer time-to-market fra måneder til dager.

c) Sanntids valutakursoptimalisering

Drop aggregerer valutakurser fra flere leverandører (banker, fintechs, valutavekslere) og evaluerer i sanntid hvilken korridor som gir best pris for brukeren:

Eksisterende aktører (Western Union, MoneyGram) bruker statiske kurser fra én leverandør. Drop's motor gjør betalingsruting til et optimaliseringsproblem — ikke en hardkodet tabell.

d) Sikkerhetsarkitektur

Drop's brukere er ofte sårbare for finansiell svindel (eldre, ikke-tekniske, språkbarrierer). Derfor er sikkerhetsarkitekturen designet for å beskytte uten å komplisere brukeropplevelsen:

Det er nettopp denne kombinasjonen — ekstrem enkelhet for brukeren, med avanserte systemer i bakgrunnen — som utgjør innovasjonen. Teknologisk kompleksitet er ikke synlig for sluttbrukeren, men er det som gjør plattformen trygg, billig og skalerbar.

1.4 Status Nå

Drop har allerede:

Hva mangler: Kundeinnsikt, juridisk struktur for PSD2-agentmodell, BankID-integrasjon, og pilottesting med reelle brukere og merchanter.

2. Marked og Muligheter

2.1 Målgruppe

Primær: Alle innbyggere i Norge som sender penger til utlandet eller ønsker billigere betalingsløsninger i lokale butikker.

Sekundær: SMB-bedrifter (spesielt i innvandrerrike områder) som ønsker lavere transaksjonsgebyrer enn Vipps/kortterminal.

2.2 Markedsstørrelse

Segment Volum Kilde
Innvandrere i Norge ~1 000 000 SSB
Årlig remittance fra Norge 5,7 milliarder NOK World Bank
Gjennomsnittlig remittance-transaksjon ~1 000 NOK World Bank
SMB-bedrifter i Norge ~195 000 SSB
Lokale bedrifter (estimat for QR) 30 000-50 000 SSB (beregning)

Serviceable Addressable Market (SAM): Med konservativt 10 000 aktive brukere som hver sender 3 transaksjoner per måned á 1 000 NOK (0,5% gebyr = 5 NOK), tilsvarer dette: 10 000 brukere × 3 tx/mnd × 5 NOK = 150 000 NOK/mnd fra remittance alene.

Med 500 merchanter som hver prosesserer 50 000 NOK/mnd (1% gebyr = 500 NOK): 500 merchanter × 500 NOK = 250 000 NOK/mnd fra QR-betalinger.

Totalt SAM: ~400 000 NOK/mnd = 4,8 millioner NOK/år.

2.3 Konkurransesituasjon

Aktør Remittance QR-betalinger Diaspora-fokus Gebyr
Vipps ❌ Kun Norge ✅ Men dyrt for merchant ❌ 1,75-2,75% (merchant)
Wise ✅ Cross-border ❌ Ingen merchant-tjeneste ❌ 0,7-1,5%
Revolut ✅ Men generisk ❌ Begrenset ❌ 0,5-1,5%
Western Union ✅ Men dyrt ❌ ✅ Men gammel UX 5-10%
MoneyGram ✅ Men dyrt ❌ ✅ Men gammel UX 4-8%
Drop ✅ Billig ✅ QR (1%) ✅ Alle i Norge 0,5% + 1%

Unikt konkurransefortrinn: Drop er den eneste aktøren i Norge som kombinerer rimelige pengeoverføringer med lokal QR-betaling. Dette skaper en dobbel verdiproposisjon og reduserer customer acquisition cost (CAC) gjennom gjensidig nettverkseffekt.

2.4 Remittance-korridorer

Prioriterte destinasjoner (basert på SSB-data om innvandrergrupper):

3. Teamet

3.1 Nøkkelpersoner

Alem Basic — Gründer, CEO og teknisk leder

SnowIT (snowit.ba) — Utviklingsteam

3.2 Kompetansebehov

Oppstartstilskuddet skal dekke:

  1. Juridisk rådgiver: PSD2-agentmodell, BankID-samtykke, hvitvaskingsloven, GDPR-compliance
  2. BankID/Open Banking-integrasjon: Teknisk partner for produksjonsmiljø
  3. UX-designer: Finpusse brukergrensesnitt basert på kundefeedback

4. Fremdriftsplan

4.1 Fase 1: Kundeintervjuer og Validering (Måned 1-3)

Mål: Verifisere at betalingsvillighet og brukerbehov stemmer med antakelsene.

Aktiviteter:

Leveranser:

Kostnader: 25 000 NOK (honorar til intervjuere, reise, rekruttering av respondenter)

4.2 Fase 2: Pilottesting (Måned 3-6)

Mål: Lansere begrenset pilot med 10 brukere og 5 merchanter for å teste full brukerflyt.

Aktiviteter:

Leveranser:

Kostnader:

4.3 Fase 3: Beta-lansering og Første Betalende Kunder (Måned 6-9)

Mål: Lansere til 20 betalende brukere og sikre 3-5 merchanter med aktive transaksjoner.

Aktiviteter:

Leveranser:

Kostnader:

5. Budsjett

Kostnadspost Måned 1-3 Måned 3-6 Måned 6-9 Total
Kundeintervjuer (honorar, reise, rekruttering) 25 000 — — 25 000
Juridisk rådgivning (PSD2, GDPR, agentmodell) 10 000 25 000 — 35 000
BankID/Open Banking-integrasjon — 30 000 — 30 000
UX/design (iterasjoner basert på feedback) — 10 000 10 000 20 000
Pilottesting (reise, incentiver, merchant-klistremerker) — 10 000 10 000 20 000
Reise (Oslo, Bergen, møter med partnere) 5 000 5 000 — 10 000
Rapportering og dokumentasjon — — 10 000 10 000
TOTAL 40 000 80 000 30 000 150 000 NOK

Budsjettnøkkel og Antagelser

6. Bærekraft og Samfunnsnytte

6.1 Økonomisk Inklusjon

Drop gjør finansielle tjenester billigere og mer tilgjengelige for grupper som tradisjonelt betaler høye gebyrer for pengeoverføringer. Ved å kutte gebyrer fra 5-10% (Western Union) til 0,5% sparer brukerne betydelige beløp årlig.

Eksempel: En person som sender 5 000 NOK per måned til familien i Serbia:

Med 10 000 brukere betyr dette 39 millioner NOK i årlige besparelser for norske husholdninger.

6.2 Reduksjon av Kontantbruk

Norge jobber mot et kontantfritt samfunn. Drop fremmer digital betaling i små bedrifter som tradisjonelt er avhengig av kontanter (kebab-sjapper, kiosker, taxier). QR-betaling eliminerer behovet for kontanttelling, bankbesøk og svart økonomi.

6.3 Støtte til Småbedrifter

SMB-bedrifter betaler 1,75-2,75% i Vipps-gebyrer. Drop tilbyr 1% gebyr — en besparelse på opptil 63%. For en liten restaurant med 100 000 NOK månedlig omsetning betyr dette:

Med 500 merchanter betyr dette 9 millioner NOK i årlige besparelser for norske småbedrifter.

6.4 Miljømessig Bærekraft

Digital betaling reduserer behovet for fysiske kontanttransporter, bankbesøk og papirbaserte kvitteringer. Drop integreres direkte med Open Banking (PSD2), noe som eliminerer mellomliggende infrastruktur og energiforbruk.

7. Utløsende Effekt (Addisjonalitet)

7.1 Uten Tilskudd

Uten Oppstartstilskudd vil Drop-utviklingen:

7.2 Med Tilskudd

Med Oppstartstilskudd kan Drop:

Konkret addisjonalitet: Tilskuddet muliggjør overgangen fra teknisk prototype til betalt kundevalidering og juridisk produksjonsklarhet — to kritiske milepæler som er nødvendige for videre funding og skalering.

8. Internasjonalt Potensial

8.1 Norden-ekspansjon (År 1-2)

Drop er utviklet med PSD2-modell (EU-standard) og kan derfor ekspandere til andre nordiske land uten å søke separate banklisenser i hvert land:

Teknisk infrastruktur er allerede klar for multi-currency (EUR, SEK, DKK). Eneste barrierer er lokalisering (språk) og markedsføring.

8.2 EU-ekspansjon (År 2-3)

PSD2-direktivet gjelder hele EØS-området. Drop kan derfor ekspandere til:

Skaleringsstrategi: År 1 = Norge (produkt-market fit, first revenue) År 2 = Norden (lokalisering, marketing) År 3 = EU core markets (Tyskland, Nederland, Belgia)

8.3 Hvorfor Dette Er Viktig for Norge

En vellykket norsk fintech-løsning som ekspanderer internasjonalt:

Vedlegg

Påkrevde dokumenter:

  1. ✅ Firmaattest (BASIC AS, org.nr 932 516 136)
  2. ☐ Årsregnskap 2024 (BASIC AS)
  3. ☐ CV — Alem Basic
  4. ✅ Budsjett (se seksjon 5)

Tilleggsdokumenter (valgfrie):

Kontaktinformasjon:

Alem Basic BASIC AS / ALAI alem@alai.no +47 40 47 42 51

Utkast utarbeidet: 20. februar 2026 Status: VERSJON 2 — OPPDATERT MED TEKNOLOGISK DYBDE

Funding & Grants

Funding & Grants

Innsendingsguide

Innsendingsguide — Oppstartstilskudd 1

Drop — Innovasjon Norge Søknad

Versjon: 1.0 Dato: 18. februar 2026 Søker: BASIC AS (org.nr 932 516 136) Søkt beløp: 150 000 NOK

A. FØR DU BEGYNNER

Forberedelser

  1. Logg inn på Innovasjon Norge:

    • URL: https://www.innovasjonnorge.no/
    • Klikk "Min side" → Logg inn med BankID (ID-porten)
    • Velg "Søk om finansiering" → "Oppstartstilskudd 1"

  2. Ha disse filene klare for opplasting:

    ✅ cv-alem-basic.pdf (Personlig CV)
✅ arsregnskap-2024.pdf (Årsregnskap BASIC AS 2024)
✅ firmaattest-932516136.pdf (Firmaattest fra Brønnøysund)

    Plassering: /Users/makinja/ALAI/finance/innovasjon-norge/vedlegg/

  3. Ha denne informasjonen tilgjengelig:

    • Org.nummer: 932 516 136
    • Kontaktperson: Alem Basic / Alem Bašić
    • E-post: alem@alai.no
    • Telefon: +47 40 47 42 51
    • Forretningsadresse: (fyll inn manuelt)
    • Kontonummer: 3606 18 56131 (Driftskonto)

B. FELTGUIDE — Eksakt tekst for hvert felt

SEKSJON 1: Organisasjonsinformasjon

Organisasjonsnummer:

932 516 136

Organisasjonsnavn:

BASIC AS

Handelsnavn / Opererer som:

ALAI

Forretningsadresse:

[FYLL INN MANUELT — ta fra Brønnøysundregistrene]

Kontaktperson:

Alem Basic

Alternativ stavemåte hvis systemet krever æ/ø/å: Alem Bašić

E-post:

alem@alai.no

Telefon:

+47 40 47 42 51

Kontonummer (for utbetaling):

3606 18 56131

SEKSJON 2: Prosjektinformasjon

Prosjektnavn:

Drop — Rimelig remittance og QR-betalinger for alle i Norge

(Hvis karakterbegrensning: "Drop — Fintech-app for rimelige pengeoverføringer og QR-betalinger")

Kort beskrivelse av ideen (maks 500 tegn):

Drop er en fintech-app som kombinerer to tjenester: (1) Rimelige pengeoverføringer til utlandet (0,5% gebyr) og (2) QR-betalinger i lokale butikker (1% gebyr). Vi bruker en pass-through PSD2-modell og holder aldri kundens penger. Målgruppe er alle som bor i Norge, med fokus på innvandrere som sender penger hjem og SMB-bedrifter som vil redusere Vipps-gebyrer.

(485 tegn)

Hva er innovasjonen? (maks 1000 tegn):

Drop er den eneste aktøren i Norge som kombinerer remittance og lokale QR-betalinger i én app. Konkurrenter som Vipps, Wise, Western Union og MoneyGram tilbyr bare én av disse tjenestene. Vårt pass-through PSD2-system holder aldri kunders penger — alle transaksjoner initieres direkte fra brukerens bankkonto via Open Banking med BankID-samtykke. Dette eliminerer behovet for banklisens og reduserer regulatorisk risiko. Vi skaper en flywheel-effekt: Brukere som sender remittance blir vant til appen → begynner å bruke QR-betaling lokalt → merchantene anbefaler appen → nye brukere sender også remittance. Teknisk innovasjon: Full Open Banking-integrasjon, sanntids valutakurser, automatisert KYC, merchant-dashboard for settlement.

(831 tegn)

Hvem er målgruppen? (maks 1000 tegn):

Primær målgruppe: Alle innbyggere i Norge som sender penger til utlandet eller ønsker billigere betalingsløsninger. Norge har ~1 million innbyggere med innvandrerbakgrunn (SSB) som årlig sender 5,7 milliarder NOK til utlandet (World Bank). Sekundær målgruppe: SMB-bedrifter (spesielt i innvandrerrike områder) som betaler 1,75-2,75% i Vipps-gebyrer. Estimert 30 000-50 000 lokale bedrifter (kebab-sjapper, kiosker, bakerier, frisører, restauranter) kan spare opptil 63% i transaksjonsgebyrer ved å bruke Drop. Vi er inkluderende — ikke bare diaspora, men ALLE som bor i Norge. QR-betalinger gjør appen relevant for daglig bruk, ikke bare for sporadiske overføringer.

(731 tegn)

Hva skal tilskuddet brukes til? (maks 2000 tegn):

Oppstartstilskuddet skal finansiere tre kritiske aktiviteter som kreves for å gå fra teknisk MVP til markedsklar løsning:

1. KUNDEINTERVJUER OG VALIDERING (25 000 NOK)
Gjennomføre 20-30 strukturerte dybdeintervjuer med målgruppen (innvandrere som sender penger hjem, merchant-eiere i innvandrerrike områder) for å verifisere betalingsvillighet, prioriterte remittance-korridorer, og UX-preferanser. Leveranse: Intervjurapporter, personas, prioritert liste over korridorer.

2. JURIDISK RÅDGIVNING (35 000 NOK)
PSD2-compliance (PISP/AISP), GDPR, hvitvaskingsloven, agentavtaler med bankpartnere, brukervilkår. Drop opererer i et strengt regulert miljø og trenger profesjonell juridisk veiledning før produksjonslansering. Leveranse: Compliance-dokumentasjon, PSD2-agentmodell, juridiske vurderinger.

3. BANKID OG OPEN BANKING-INTEGRASJON (30 000 NOK)
Teknisk integrasjon mot BankID for sterk kundeautentisering (SCA) og Open Banking API-er (AISP for saldovisning, PISP for betalingsinitierung). Leveranse: Fungerende BankID-login, Open Banking-kobling i produksjon.

4. UX/DESIGN (20 000 NOK)
Profesjonell UX-designer itererer på brukergrensesnitt basert på kundefeedback. Leveranse: Figma-design, UI-kit, brukertester.

5. PILOTTESTING (20 000 NOK)
Rekruttere 10 pilotkunder (remittance) og 5 pilot-merchanter (QR-betaling) for 30-dagers testing med reelle transaksjoner (demo-modus). Leveranse: Pilotrapport, brukerfeedback, CAC/LTV-data.

6. REISE OG MØTER (10 000 NOK)
Fysiske møter med partnere, potensielle kunder, bankpartnere, juridiske konsultasjoner, networking-events.

7. RAPPORTERING (10 000 NOK)
Sluttrapport til Innovasjon Norge med fremdriftsoppsummering, økonomisk rapportering, læringsutbytte.

(1990 tegn)

Hva er teamets kompetanse? (maks 1500 tegn):

ALEM BASIC — Gründer, CEO og teknisk leder
- 25+ års erfaring innen software-utvikling og systemarkitektur
- Nåværende stilling: Senior Tech Lead, Entur AS (Norges nasjonale reiseplanlegger)
- Kompetanse: Systemarkitektur, full-stack utvikling (React, Next.js, Node.js, Python), cloud (AWS, Azure, Fly.io), AI/ML, DevOps, sikkerhet
- Personlig motivasjon: Innvandrerbakgrunn fra Bosnia — kjenner remittance-problemet førstehånds
- Tidligere roller: Software Architect (VegVesen), Senior Developer (diverse fintech/transport-selskaper)
- Utdanning: Bachelor i Informasjonsteknologi

SNOWIT (snowit.ba) — Utviklingsteam
- 10+ erfarne utviklere basert i Bosnia-Hercegovina
- Kompetanse innen full-stack utvikling (React, Next.js, Node.js, Python), mobilutvikling (React Native, Swift, Kotlin), QA og testing
- Kostnadseffektivt nearshore-team med norsk ledelse og bosnisk leveranse
- Erfaring med fintech-prosjekter, betalingssystemer og compliance

KOMPETANSEBEHOV (dekkes av tilskudd):
- Juridisk rådgiver: PSD2-agentmodell, GDPR, hvitvaskingsloven
- BankID/Open Banking-integrasjon: Teknisk partner for produksjon
- UX-designer: Finpusse brukergrensesnitt basert på kundefeedback

(1339 tegn)

Internasjonalt potensial? (maks 1500 tegn):

Drop er utviklet med PSD2-modell (EU-standard) og kan ekspandere til andre europeiske land uten å søke separate banklisenser i hvert land.

NORDEN-EKSPANSJON (År 1-2):
- Sverige: 2,4 millioner innvandrere (SCB), lignende remittance-behov
- Danmark: 800 000 innvandrere (Statistics Denmark)
- Finland: 500 000 innvandrere (Statistics Finland)
Teknisk infrastruktur er allerede klar for multi-currency (EUR, SEK, DKK). Eneste barrierer er lokalisering (språk) og markedsføring.

EU-EKSPANSJON (År 2-3):
PSD2-direktivet gjelder hele EØS-området. Drop kan derfor ekspandere til:
- Tyskland: 22 millioner innvandrere (Destatis) — Europas største marked
- Nederland: 4,5 millioner innvandrere (CBS)
- Belgia: 2,5 millioner innvandrere (Statbel)
- Østerrike: 2,3 millioner innvandrere (Statistik Austria)

SKALERINGSSTRATEGI:
År 1 = Norge (produkt-market fit, first revenue)
År 2 = Norden (lokalisering, marketing)
År 3 = EU core markets (Tyskland, Nederland, Belgia)

VIKTIGHET FOR NORGE:
En vellykket norsk fintech-løsning som ekspanderer internasjonalt skaper høyt-kvalifiserte arbeidsplasser i Norge (engineering, compliance, kundesupport), posisjonerer Norge som fintech-hub i Norden, genererer eksportinntekter fra utenlandske markeder, og tiltrekker internasjonale investorer til norsk startup-økosystem.

(1493 tegn)

Bærekraft og samfunnsnytte? (maks 1500 tegn):

ØKONOMISK INKLUSJON:
Drop gjør finansielle tjenester billigere og mer tilgjengelige for grupper som tradisjonelt betaler høye gebyrer. Ved å kutte gebyrer fra 5-10% (Western Union) til 0,5% sparer brukerne betydelige beløp årlig. Eksempel: En person som sender 5 000 NOK/mnd til Serbia sparer 3 900 NOK/år. Med 10 000 brukere = 39 millioner NOK i årlige besparelser for norske husholdninger.

STØTTE TIL SMÅBEDRIFTER:
SMB-bedrifter betaler 1,75-2,75% i Vipps-gebyrer. Drop tilbyr 1% gebyr — en besparelse på opptil 63%. For en liten restaurant med 100 000 NOK månedlig omsetning betyr dette 18 000 NOK/år i besparelse. Med 500 merchanter = 9 millioner NOK i årlige besparelser for norske småbedrifter.

REDUKSJON AV KONTANTBRUK:
Norge jobber mot et kontantfritt samfunn. Drop fremmer digital betaling i små bedrifter som tradisjonelt er avhengig av kontanter (kebab-sjapper, kiosker, taxier). QR-betaling eliminerer behovet for kontanttelling, bankbesøk og svart økonomi.

MILJØMESSIG BÆREKRAFT:
Digital betaling reduserer behovet for fysiske kontanttransporter, bankbesøk og papirbaserte kvitteringer. Drop integreres direkte med Open Banking (PSD2), noe som eliminerer mellomliggende infrastruktur og energiforbruk.

(1396 tegn)

SEKSJON 3: Prosjektperiode og Budsjett

Prosjektperiode:

Start: [Dato etter tilsagn] — foreslått: 1. mars 2026
Slutt: 9 måneder senere — foreslått: 30. november 2026

Fyll inn datoer basert på forventet tilsagnsdato

Prosjektets totale kostnader (NOK):

150 000

Søkt beløp fra Innovasjon Norge (NOK):

150 000

Egenfinansiering (NOK):

0

Forklaring: Utviklingsarbeid (backend, frontend, mobil) dekkes av grunnlegger Alem Basic. Infrastruktur og hosting dekkes privat første 9 måneder.

Budsjettfordeling (detaljert):

Kostnadspost Beløp (NOK) Forklaring
Kundeintervjuer 25 000 20-30 intervjuer, honorar, reise, rekruttering
Juridisk rådgivning 35 000 PSD2, GDPR, agentmodell, samtykke (17,5t × 2000 NOK/t)
BankID/Open Banking 30 000 Teknisk partner, API-tilgang, integrasjon
UX/Design 20 000 Frilans-designer, iterasjoner (13t × 1500 NOK/t)
Pilottesting 20 000 Rekruttering, incentiver, merchant-klistremerker
Reise og møter 10 000 Oslo, Bergen, partner-møter, networking
Rapportering 10 000 Sluttrapport, dokumentasjon
TOTAL 150 000

SEKSJON 4: Status og Fremdrift

Prosjektets nåværende status:

Drop har allerede:
✅ MVP (Minimum Viable Product) deployet til staging-miljø
✅ 217 automatiserte tester
✅ Fullstendig teknisk arkitektur (Next.js 16, React 19, SQLite, BankID SCA)
✅ 9 frontend-sider (landing, pålogging, onboarding, dashboard, send penger, skann QR, transaksjonshistorikk, profil, merchant-dashboard)
✅ 24 API-ruter (autentisering, mottakere, remittance, QR-betalinger, kortstyring, merchant-registrering, valutakurser)
✅ Juridisk compliance-vurdering (ingen bruk av ordet "banking" uten lisens-disclaimer)
✅ Sikkerhetstrussel-modell (8 risikoområder identifisert og mitigert)

HVA MANGLER:
- Kundeinnsikt: 20-30 strukturerte intervjuer med målgruppen
- Juridisk struktur: PSD2-agentmodell, formelle partnerskapsavtaler
- BankID-integrasjon: Produksjonsklar løsning
- Pilottesting: 10 brukere + 5 merchanter i 30-dagers pilot

Forventede resultater etter 9 måneder:

1. KUNDEVALIDERING: 20-30 dokumenterte intervjuer, prioritert liste over remittance-korridorer
2. JURIDISK COMPLIANCE: PSD2-agentmodell dokumentert, GDPR-rutiner på plass
3. TEKNISK PRODUKSJON: BankID-integrasjon, Open Banking-kobling i produksjon
4. PILOTRESULTATER: 10 betalende kunder, 5 aktive merchanter, CAC/LTV-data
5. MARKEDSKLAR LØSNING: Klar for beta-lansering og videre funding

C. VEDLEGG — Filer til opplasting

Obligatoriske vedlegg

1. Firmaattest

2. Årsregnskap 2024

3. CV — Nøkkelperson

Valgfrie vedlegg (anbefalt)

4. Detaljert budsjett

D. SJEKKLISTE — Før du trykker "Send inn"

Før innsending

Etter innsending

E. KONTAKTINFORMASJON

Innovasjon Norge kundesenter:

Søker (BASIC AS):

F. TIPS OG RÅDFRA ERFARING

  1. Lagre ofte: Søknadsskjemaet lagrer automatisk, men gjør manuelle lagringer underveis
  2. Bruk PDF-forhåndsvisning: Sjekk hvordan søknaden ser ut før innsending
  3. Vær konkret: Unngå vage formuleringer som "vi planlegger å" — bruk "vi skal"
  4. Tall teller: Bruk konkrete tall og kilder (SSB, World Bank, etc.)
  5. Hold det enkelt: Ikke bruk jargong — skriv som om du forklarer til en venninne
  6. Vis fremdrift: Drop har allerede MVP — dette er IKKE en idé, det er et produkt som trenger markedsvalidering
  7. Konkurransefortrinn: Vær tydelig på hva som gjør Drop unik (kombinasjon av remittance + QR)

Versjonsinformasjon:

Lykke til med søknaden! 🚀

Pitch Materials

Investor and partner pitch materials

Pitch Materials

Pitch: Email Text

Email til Edis Sabaredzovic

Til: edis.sabaredzovic@sb1sornorge.no Fra: alem@alai.no Emne: Drop — Fintech-partnerskap for betalinger i Norge

Hei Edis,

Mitt navn er Alem Bašić, og jeg er CEO i ALAI Holding AS — et digitalt byrå basert i Norge.

Vi har bygget Drop, en fintech-app for alle i Norge som kombinerer to funksjoner ingen andre tilbyr sammen:

  1. Pengeoverføring til utlandet — 0,5 % gebyr (vs. Western Union 5–10 %)
  2. QR-betaling i butikk — 1 % butikkgebyr (vs. Vipps 1,75–2,75 %)

Med over 5,7 milliarder NOK i årlige overføringer ut av Norge og tusenvis av lokale butikker som betaler for høye Vipps-gebyrer, ser vi en stor mulighet — og vi leter etter riktig bankpartner.

Vedlagt finner du:

Appen er live og kan demonstreres når som helst.

Kunne vi tatt et kort møte — 30 minutter — for å gå gjennom dette? Jeg er tilgjengelig både virtuelt og i person.

Med vennlig hilsen,

Alem Bašić CEO, ALAI Holding AS alem@alai.no

Vedlegg:

  1. Drop-x-SpareBank1-Partnerskap.pdf
  2. App-skjermbilder (01-landing.png til 10-merchant.png)
  3. promo-video-storyboard.md
Pitch Materials

Pitch: Promo Video Storyboard

Drop — Promo Video Storyboard

For Sparebanken Partnership Pitch

Duration: 90 seconds Tone: Warm, modern, trustworthy Music: Upbeat ambient electronic, builds gradually Format: 1080p, 16:9 (LinkedIn/email) + 9:16 version (mobile)

Scene 1: The Problem (0:00 - 0:20)

Visual: Split screen — left: young man in Oslo apartment looking at phone, right: his mother in Sarajevo checking her old phone.

Voiceover (EN):

"Every month, people in Norway send money home. They pay too much. Wait too long. And use apps that weren't built for them."

Text overlay: "5.7 billion NOK sent abroad from Norway every year"

Cut to: Quick montage — Western Union storefront, confusing bank app, cash in envelope.

Scene 2: Introducing Drop (0:20 - 0:35)

Visual: Phone screen showing Drop landing page. Clean, green interface. Finger taps "Open App".

Voiceover:

"Meet Drop. One app. Two superpowers. Enklere betalinger. Lavere gebyrer."

Text overlay: Drop logo animates in. Tagline: "Enklere betalinger. Lavere gebyrer."

Visual: App transition to dashboard — linked bank balance visible, two big buttons: "Send penger" and "Skann QR".

Scene 3: Remittance Flow (0:35 - 0:55)

Visual: Screen recording of the app (or animated mockup):

  1. Tap "Send penger"
  2. Select recipient: "Mama Jasmina" with Serbian flag
  3. Enter amount: 2,000 NOK → shows "23,400 RSD" with fee "10 NOK (0.5%)"
  4. Confirm. Green checkmark animation.

Voiceover:

"Sending money home takes 30 seconds. Your mom doesn't need an app — money goes straight to her bank account. Fee? Half a percent. Not five. Not ten. Half."

Text overlay comparison:

Western Union: 5-10%
Wise: 0.7-1.5%
Drop: 0.5%

Cut to: Mother in Sarajevo smiles, picks up phone with SMS notification.

Scene 4: QR Payments (0:55 - 1:10)

Visual: Young man walks into a kebab shop in Gronland, Oslo. QR sticker on the counter.

Voiceover:

"Back in Oslo, pay at your favorite local shop. No card. No cash. Just scan."

Visual: Phone camera opens, scans QR code. Shows: "Ahmet's Kebab — enter amount". Types 129. Tap "Betal". Instant confirmation. Merchant's phone buzzes.

Text overlay: "Merchant fee: 1% — half of what Vipps charges"

Voiceover:

"The merchant saves on every transaction. You pay in a second. Everyone wins."

Scene 5: The Partnership Opportunity (1:10 - 1:25)

Visual: Clean white background. Animated infographic builds:

Voiceover:

"Billions in transactions. Thousands of businesses paying too much. An entire market — underserved by traditional solutions. Drop is the bridge. And we're looking for the right banking partner to build it with."

Scene 6: Call to Action (1:25 - 1:30)

Visual: Drop logo, centered. Below: "Drop x [Sparebanken logo]"

Text overlay:

"Let's talk." alem@alai.no

Voiceover:

"Drop. Enklere betalinger. Lavere gebyrer."

Music fades out.

Production Notes

Option A: AI-Generated Video (Budget: ~$50-100)

Option B: Screen Recording + Voiceover (Budget: $0)

Option C: Professional (Budget: 5,000-15,000 NOK)

Recommended: Option A + real app footage

Best balance of quality and speed. The app is live — record real screens. Add AI-generated scenes around it.

Voiceover Script (clean, for recording)

"Every month, people in Norway send money home. They pay too much. Wait too long. And use apps that weren't built for them.

Meet Drop. One app. Two superpowers. Enklere betalinger. Lavere gebyrer.

Sending money home takes thirty seconds. Your mom doesn't need an app — money goes straight to her bank account. Fee? Half a percent. Not five. Not ten. Half.

Back in Oslo, pay at your favorite local shop. No card. No cash. Just scan. The merchant saves on every transaction. You pay in a second. Everyone wins.

Billions in transactions. Thousands of businesses paying too much. An entire market — underserved by traditional solutions. Drop is the bridge. And we're looking for the right banking partner to build it with.

Drop. Enklere betalinger. Lavere gebyrer."

Project Documentation

Project charters, plans, pipeline reviews, incident reports

Project Documentation

Production Plan

Drop — Production Plan

Datum: 21. februar 2026 Status: Odobren (Alem) Cilj: Go-Live sa beta korisnicima

1. Arhitektura — Bez banke

Drop ne treba banku kao partnera. Neonomics (Bergen, Norveška) ima PSD2 licencu i konekcije sa svim norveškim bankama.

Korisnik → Drop app → Neonomics API → Korisnikova banka (DNB, SpareBank 1, Nordea...)
                ↓
          BankID (autentifikacija)

Drop nikad ne drži novac. Sve ide direktno sa bankovnog računa korisnika.

2. Revenue Model

2.1 QR plaćanja (merchant fee)

Stavka Vrijednost
Fee 1.0% od iznosa
Ko plaća Merchant (ne kupac)
Primjer Kupac plati 500 NOK → Merchant primi 495 NOK → Drop zaradi 5 NOK
Konkurencija Vipps 1.75%, Nets 2.0-2.75% → Drop je najjeftiniji

2.2 Remittance (transfer fee)

Stavka Vrijednost
Fee 0.5% od iznosa (min 10 NOK, max 500 NOK)
Ko plaća Pošiljalac
Primjer Pošalji 5.000 NOK u Srbiju → Fee 25 NOK → Drop zaradi 25 NOK
Konkurencija Western Union 5-10%, Wise 0.7-1.5% → Drop je najjeftiniji

2.3 FX Spread (faza 2)

Stavka Vrijednost
Markup 0.1-0.3% na mid-market rate
Ko plaća Ugrađeno u exchange rate (transparentno)
Primjer Mid-market 1 NOK = 10.17 RSD → Drop rate = 10.14 RSD → Spread profit

2.4 Revenue projekcija

Metrika Mjesec 6 Mjesec 12 Mjesec 24
Aktivni korisnici 500 5.000 25.000
QR transakcije/mj 2.000 30.000 200.000
Prosječna QR vrijednost 200 NOK 250 NOK 300 NOK
Remittance transakcije/mj 200 3.000 15.000
Prosječni remittance iznos 3.000 NOK 3.500 NOK 4.000 NOK
QR prihod 4.000 NOK 75.000 NOK 600.000 NOK
Remittance prihod 3.000 NOK 52.500 NOK 300.000 NOK
Ukupno mjesečno 7.000 NOK 127.500 NOK 900.000 NOK

2.5 Troškovi

Stavka Mjesečno
AWS infrastruktura ~1.000 NOK (€80-150)
Neonomics (per-transaction) ~0.50-5 NOK po transakciji
BankID Uključeno u Neonomics
Cloudflare Free
Apple Developer 99 USD/godišnje
Google Play 25 USD jednokratno
Ukupni fiksni troškovi ~1.500 NOK/mj

2.6 Break-even

Sa fiksnim troškovima od ~1.500 NOK/mj:

3. AWS Infrastruktura

Što imamo (spremno)

Mjesečni AWS trošak: ~€80-150

Servis Namjena Cijena
App Runner (×2) Web + API ~€10-20/mj
RDS PostgreSQL 16 Baza podataka ~€30-50/mj
ECR Docker registry ~€1/mj
Secrets Manager Ključevi i tajne ~€2/mj
CloudWatch Logovi + alarmi ~€5-10/mj
Cloudflare CDN + WAF + DNS Free
Route 53 DNS backup ~€1/mj

Region: eu-north-1 (Stockholm) — GDPR compliant, najbliže Norveškoj.

4. Kritični put do Go-Live

Faza 1: Neonomics + Infra (2-4 sedmice)

# Task Vlasnik Effort
1 Neonomics ugovor + API pristup Alem 1-2 sedmice
2 terraform apply — podigni AWS John 1 dan
3 Neonomics API integracija (PISP + AISP) John 2-3 sedmice
4 BankID sandbox → Neonomics BankID John 2 dana
5 Staging deploy + E2E test John 2 dana

Faza 2: Beta (2-4 sedmice)

# Task Vlasnik Effort
6 10 beta korisnika (prijatelji/porodica) Alem 1 sedmica
7 5 beta merchantov (lokalne radnje) Alem 2 sedmice
8 Bug fixing iz beta feedbacka John ongoing
9 App Store submit (iOS + Android) John + Alem 1 sedmica

Faza 3: Launch (2-4 sedmice)

# Task Vlasnik Effort
10 Production deploy John 1 dan
11 App Store approve + publish Apple/Google 1-2 sedmice
12 Prvih 100 korisnika Alem (marketing) ongoing
13 FX rate API integracija (Wise/CurrencyCloud) John 1 dan

Timeline

Sedmica 1-2:  Neonomics ugovor + terraform apply
Sedmica 3-4:  Neonomics API integracija
Sedmica 5-6:  Beta (10 korisnika + 5 merchantov)
Sedmica 7-8:  App Store submit + production
Sedmica 9+:   Launch + growth

Realistični Go-Live: ~8 sedmica od Neonomics ugovora.

5. Zašto ne treba banka

Pitanje Odgovor
Ko daje pristup bankama? Neonomics (PSD2 licenca, konekcije sa svim NO bankama)
Ko drži korisnikov novac? Korisnikova banka (Drop nikad ne drži novac)
Ko autentificira korisnika? BankID (via Neonomics ili direktno)
Ko izvršava plaćanje? Korisnikova banka (Drop samo inicira via PISP)
Ko ima PSD2 licencu? Neonomics (Drop radi kao njihov agent)
Šta Drop radi? Frontend + biznis logika + merchant mreža + UX

Drop je "samo" app — ali app koji je jeftiniji, brži i jednostavniji od konkurencije. Slično kao što Uber ne posjeduje aute, Drop ne posjeduje banke.

6. Konkurentska prednost

Faktor Drop Vipps Western Union Wise
QR merchant fee 1.0% 1.75% N/A N/A
Remittance fee 0.5% N/A 5-10% 0.7-1.5%
BankID login Da Da Ne Ne
Instant QR Da Da Ne Ne
Remittance Da Ne Da Da
Oboje u jednoj app Da Ne Ne Ne

Jedini koji nudi I QR plaćanja I remittance u jednoj app — po najnižim cijenama.

7. Rizici

Rizik Vjerovatnoća Uticaj Mitigacija
Neonomics odbije/kasni Nizak Visok Alternativa: Enable Banking, Yapily
Regulatorne promjene Nizak Srednji PSD3 je evolucija PSD2, ne revolucija
Merchant adoption spor Srednji Srednji Fokus na niche (diaspora radnje) pa širi
Vipps reagira snižavanjem cijena Srednji Nizak Vipps nema remittance — naša prednost ostaje
Cyber napad Nizak Visok WAF, rate limiting, BankID SCA, audit logs

Dokument kreirao: John (AI Director) Odobrio: Alem Bašić (CEO)

Project Documentation

Project Charter

Project Charter: [PROJECT NAME]

Date: YYYY-MM-DD Status: Draft | In Review | Approved Project Manager: [Name] Tech Lead: [Name] Client: [Name / Company]

1. Project Overview

Project Name: [Name] Client: [Company Name] Contact: [Name, email] Package: [Package name and price] Timeline: [X weeks from contract signing] Expected Start: [Date] Expected Completion: [Date]

2. Problem Statement

[What problem does this project solve? 2-3 sentences.]

3. Project Objectives

  1. [Objective 1]
  2. [Objective 2]
  3. [Objective 3]

4. Scope

In Scope

Out of Scope

5. Deliverables

# Deliverable Description Due
1 Week X
2 Week X
3 Week X

6. Timeline & Milestones

Milestone Date Gate
Kick-off Charter approved
Design Complete Design review passed
MVP / Alpha Core features working
Beta All features, testing
Launch UAT signed off

7. Team & RACI

Role Person/Agent R/A/C/I
CEO Alem A (approvals)
AI Director John A (delivery)
Project Manager [Agent] R (coordination)
Tech Lead [Agent] R (architecture)
Scrum Master [Agent] R (process)
Developer [Agent] R (implementation)
Designer [Agent/Human] R (design)
QA [Agent] R (testing)

8. Budget

Item Amount Notes
Total [NOK]
Deposit (50%) [NOK] Upon contract signing
Final (50%) [NOK] Upon delivery

9. Risk Register

# Risk Probability Impact Mitigation
1 L/M/H L/M/H
2 L/M/H L/M/H
3 L/M/H L/M/H

10. Success Criteria

11. Communication Plan

What How Frequency Who
Status update Standup file Daily PM → John
Sprint review Meeting notes Bi-weekly Team → Client
Decisions Decision record As needed John
Escalations Direct session Immediate John → Alem

12. Approvals

Role Name Date Signature
AI Director John ☐
CEO Alem ☐
Client ☐
Project Documentation

Risk Register

Risk Register: [PROJECT NAME]

Last Updated: YYYY-MM-DD Owner: Project Manager Review Frequency: Weekly (sprint planning)

Risk Matrix

Low Impact Medium Impact High Impact
High Prob Medium High Critical
Medium Prob Low Medium High
Low Prob Low Low Medium

Active Risks

ID Risk Description Category Probability Impact Score Mitigation Strategy Owner Status Date Identified
R-001 Technical / Resource / Client / External L/M/H L/M/H L/M/H/C Open / Mitigating / Closed
R-002

Risk Categories

Risk Response Strategies

Closed Risks

ID Risk Resolution Date Closed

Review Log

Date Reviewer Changes
Project Documentation

ZiCA Business Case

DEPRECATED (2026-02-14): This is version 1.0 of the business case, written under the original "Zica" name. It has been superseded by zica-business-case-v2.md which reflects the rebrand to Drop and the updated product model. Retained for historical reference only.

Zica — Business Case

Date: 2026-02-08 Version: 1.0 Compiled by: John (AI Director) Sources: 6 AI agents (nicksaraev, product, legal, finance, marketer, security)

Executive Summary

Zica je fintech payment aplikacija — rebrand FontelePay. Ovaj dokument pokriva kompletan biznis model, product strategiju, compliance, financijski model i go-to-market plan. Sve generirano od strane AI agent tima i konsolidirano od Johna.

1. Business Model (Agent: nicksaraev)

Revenue Streams

Stream Model Procjena
Transaction fee 0.5-1% po transakciji Primarni prihod
Premium subscription ~100 NOK/mj Više kartica, napredna analitika, priority support
Freemium base Besplatno Osnovne funkcije — privlači korisnike

Target Market

Go-To-Market

  1. Build MVP sa core funkcijama
  2. Soft launch — zatvorena beta sa 50-100 korisnika
  3. Iterate bazirano na feedbacku
  4. Javni launch sa marketing kampanjom
  5. Partner integracije (banke, e-commerce)

2. Product Strategy (Agent: product)

Unique Value Proposition

"Sigurna, lokalna i prilagodljiva fintech app dizajnirana za nordijsko tržište — fokus na SME i mlade profesionalce kojima Vipps ne nudi dovoljno, a Revolut je previše generic."

Differentiators

  1. Lokalna podrška — norveški jezik, norveški support, norveška firma
  2. SME fokus — invoice tracking, business accounts, spending kategorije
  3. Sigurnost — JWT httpOnly, encrypted data, GDPR-first dizajn

User Persone

Persona Opis Pain Point
Marko (SME vlasnik) Mala trgovina, treba pregled finansija Teško prati transakcije i troškove
Ana (finansijski menadžer) Srednje preduzeće, treba business tools Nedostaju personalizirana rješenja
Ivan (mladi profesionalac) Želi sigurnu app za osobne finansije Strah od nesigurnih aplikacija

Roadmap

Verzija Features Timeline
v1 (MVP) Auth, accounts, transactions, cards, history 5 sedmica
v2 Transfer novca, plaćanje računa, spending analitika +4 sedmice
v3 Business accounts, invoice integration, partner API +6 sedmica

Product-Market Fit signali

Licence (Finanstilsynet, Norveška)

Licenca Potrebna? Cijena Trajanje
E-money licence Da (za čuvanje sredstava) ~50,000-100,000 NOK godišnje 6-12 mj za dobijanje
Payment institution Da (za procesiranje) ~30,000-80,000 NOK godišnje 6-12 mj
BaaS alternativa DA — PREPORUČENO Ušteđuje licence Odmah

BaaS Partner opcija (PREPORUČENO za start)

Koristimo BaaS partnere → ne trebamo vlastitu licencu za start. Vlastita licenca je goal za Year 2+.

Compliance checklist

4. Financial Model (Agent: finance)

Startup Costs (realni za AI-first kompaniju)

Stavka Tradicionalno ALAI (AI-first) Ušteda
Development 500,000 NOK ~5,000 NOK (compute) 99%
Legal/licence 50,000 NOK 50,000 NOK 0%
Marketing (launch) 100,000 NOK 100,000 NOK 0%
Infrastruktura 20,000 NOK 5,000 NOK/god 75%
Osoblje (3 osobe × 12mj) 1,800,000 NOK 0 NOK 100%
UKUPNO 2,470,000 NOK ~160,000 NOK 93%

Monthly Costs (post-launch)

Stavka Iznos
BaaS partneri (Swan/Stripe) ~5,000-15,000 NOK
Hosting (Vercel Pro) ~1,000 NOK
Claude Code ~1,100 NOK
Monitoring/tools ~500 NOK
Marketing (ongoing) ~40,000-60,000 NOK
Legal (ongoing compliance) ~5,000 NOK
Mjesečni burn ~55,000-85,000 NOK

Revenue Projection

Period Korisnici MRR (NOK) Kumulativno
Mj 1-3 50-200 5,000-15,000 Soft launch
Mj 4-6 500-1,000 30,000-60,000 Growing
Mj 7-12 2,000-5,000 100,000-250,000 Scaling
God 2 10,000-20,000 500,000-1,000,000 Established
God 3 30,000+ 1,500,000+ Mature

Break-Even

Scenarij Break-even
Optimistički (brz rast) Mjesec 6-8
Realistički (umjeren rast) Mjesec 10-14
Pesimistički (spor rast) Mjesec 18-24

LTV:CAC

Metrika Vrijednost
CAC (customer acquisition cost) ~200 NOK
LTV (lifetime value, 24 mj) ~2,400 NOK (100 NOK/mj × 24)
LTV:CAC ratio 12:1 (odličan, target je >3:1)

Funding

Opcija Prednost Nedostatak
Bootstrap Puni control, nema dilucije Sporiji rast
Angel investor 500K-2M NOK, brži rast Dilucija 10-20%
Innovasjon Norge Grants, nema dilucije Spor proces, papirologije

Preporuka: Bootstrap MVP + apply Innovasjon Norge za marketing budget.

5. Marketing Strategy (Agent: marketer)

Brand Positioning

"Zica nije još jedna payment app — Zica je tvoj finansijski partner. Lokalna, sigurna, napravljena za nordijsko tržište."

Launch Plan: Soft Launch

  1. Mjesec 1-2: Closed beta (50-100 korisnika, invite-only)
  2. Mjesec 3: Public beta sa referral programom
  3. Mjesec 4-6: Paid acquisition + content marketing

Kanali

Kanal Budget Expected CAC
Instagram/TikTok (organic) 0 Low
Google Ads 20,000 NOK/mj ~200 NOK
Content/SEO 10,000 NOK/mj Dugoročno najjeftinije
Partnerships (e-commerce) Per deal Medium
Referral program ~50 NOK/referral Najjeftinije

Marketing budget Year 1: 500,000-750,000 NOK

KPIs

KPI Target
CAC < 200 NOK
Conversion (signup → active) > 20%
Retention (6 mj) > 70%
NPS > 30

6. Risk Matrix (Consolidated)

Rizik Severity Vjerovatnoća Mitigacija
Regulatorne prepreke HIGH Medium BaaS partneri pokrivaju licence
Vipps dominacija u Norveškoj HIGH High Fokus na niše (SME, business tools)
Security breach CRITICAL Low Threat model + security agent review
Spor user rast MEDIUM Medium Referral program + content marketing
BaaS partner promijena uslova MEDIUM Low Multi-provider strategija
Cash flow gap (pre break-even) HIGH Medium Innovasjon Norge grant

7. Decision: GO / NO-GO

Za GO:

Za NO-GO:

Preporuka

UVJETNI GO — Build MVP kao portfolio + beta test. Ako Product-Market Fit signali budu pozitivni (100+ korisnika, >40% retention), tada full commit sa marketing budgetom.

Agents koji su doprinijeli ovom dokumentu

Agent Kompanija Doprinos
nicksaraev ALAI Business model, pricing, GTM
product ALAI Product Product strategy, persone, roadmap
legal ALAI Legal Compliance, licence, regulativa
finance ALAI Finance Finansijski model, projections
marketer ALAI Marketing Team Marketing strategy, kanali, KPIs
security ALAI Security Threat model, hardening
dev ALAI Architecture, tech decisions

7 od 15 agenata aktivirano. Svi dali output.

Compiled: 2026-02-08 by John (AI Director) Awaiting: Alem (CEO) GO/NO-GO decision

Project Documentation

Workflow

Drop — Development Workflow

Overview

Drop development follows the GOTCHA framework workflow: Boot → Mission Control → Agent Spawn → Build → Validate → Done

1. Boot (boot.sh)

Every session starts with:

bash ~/system/boot.sh

This verifies all 6 GOTCHA layers:

Boot also reads HiveMind intel.

2. Mission Control — Task Management

Create a task

node ~/system/tools/mc.js add "Feature: Send Money" --desc "Wire /send to /api/transactions" --priority H --owner john

Start working

node ~/system/tools/mc.js start <id>

This creates /tmp/mc-active-task — required by enforcer hooks to allow Write/Edit operations.

Complete

node ~/system/tools/mc.js done <id> "Wired /send to API. Tests passing."

Other commands

mc.js list                    # All open tasks
mc.js list --owner john       # My tasks
mc.js pause <id>              # Pause (blocks Write/Edit)
mc.js resume <id>             # Resume paused task
mc.js block <id> "reason"     # Block with reason
mc.js show <id>               # Full details
mc.js active                  # Who's working on what

3. Agent Spawn — Builder/Validator Teams

For implementation tasks, John spawns Claude subagents:

Builder Agent

Spawn pattern:

Task tool → subagent_type: "general-purpose"
Prompt: "Implement feature X. Read the code first. Follow CLAUDE.md rules."

Validator Agent

Spawn pattern:

Task tool → subagent_type: "general-purpose"
Prompt: "Validate feature X. Check code quality, tests, no regressions."

Model Budget

Model When
Opus Alem session, planning — NEVER for agents
Sonnet Builders, validators — default for agents
Haiku Trivial tasks — file search, lint, git

4. Development Flow — Feature Lifecycle

[Pending] → mc.js start → [In Progress] → Build → Test → mc.js done → [Done]
                              ↓
                        spawn builder
                              ↓
                        spawn validator
                              ↓
                         HiveMind post

Feature Tracking

Drop uses a built-in feature tracking system (src/lib/features.ts) with 25 features across categories:

Category Features Status
Authentication Registration, PIN Login, Logout, Biometric 3/4 passing
KYC Identity Verification 1/1 passing
Banking IBAN, Balance, Send, Receive, History, Top-up 5/6 passing
Cards Virtual, Freeze/Unfreeze, Transactions, Physical 4/4 passing

Check feature status:

import { getFeatureStats, printFeatureReport } from '@/lib/features'
printFeatureReport() // ASCII status report

5. Architecture Quick Reference

Stack

API Endpoints

Endpoint Method Purpose
/api/auth/register POST Register (phone + PIN)
/api/auth/login POST Login
/api/account GET Account details + balance
/api/cards GET/POST List/create cards
/api/cards/[id] GET/PATCH Card details/freeze
/api/transactions GET/POST List/send money
/api/transactions/simulate POST Simulate incoming (demo)
/api/health GET Health check

Service Mocks (dev mode)

Service Provider Mock File
BaaS Swan src/lib/services/mock-swan.ts
Cards Stripe Issuing src/lib/services/mock-stripe.ts
KYC Sumsub src/lib/services/mock-sumsub.ts

Mode controlled by NEXT_PUBLIC_SERVICE_MODE env var (default: "mock").

Database Schema

4 tables: users, accounts, cards, transactions Schema defined in src/lib/db.ts

State Management

Global context via AppProvider (src/lib/context/AppContext.tsx):

6. Local Development

cd ~/ALAI/products/Drop/src/drop-app
npm install
npm run dev          # Dev server on localhost:3000
npm run build        # Production build
npm run test         # Jest tests (25 tests, 100% passing)
npm run lint         # ESLint

Test Results (Feb 7, 2026)

7. Deployment

8. Open Tasks (Drop)

Task Priority Owner Description
#191 HIGH john Wire /send page to /api/transactions/remittance
#192 HIGH john Wire /scan page to /api/transactions/qr-payment
#193 HIGH john Wire /merchant page to real APIs
#180 MED john E2E test: full remittance flow
#182 MED john Update design and layout
#196 MED john Document merchant, recipients, rates feature
#198 LOW john Delete mock-data.ts and orphaned components

9. Anti-Hallucination Rules

From ~/system/rules/agent-anti-hallucination.md:

Project Documentation

Incident Report

Incident Report: [INC-XXX] [Short Title]

Date: YYYY-MM-DD Severity: P1 Critical | P2 High | P3 Medium | P4 Low Status: Investigating | Mitigating | Resolved | Post-Mortem Complete Owner: [Name/Agent] Duration: [Start time] — [End time] ([X hours])

1. Summary

[1-2 sentence description of what happened and the impact]

2. Timeline

Time Event
HH:MM Incident detected — [how]
HH:MM Investigation started
HH:MM Root cause identified
HH:MM Fix deployed
HH:MM Incident resolved
HH:MM Monitoring confirmed stable

3. Impact

4. Root Cause

[What actually caused the incident. Be specific — not "human error" but "configuration file had incorrect database connection string because of merge conflict in PR #123"]

5. Resolution

[What was done to fix the issue]

  1. [Step 1]
  2. [Step 2]
  3. [Step 3]

6. What Went Well

7. What Went Wrong

8. Action Items

# Action Owner Due Date Status
1 [Preventive action] ☐
2 [Process improvement] ☐
3 [Monitoring improvement] ☐

9. Lessons Learned

[Key takeaways that should inform future work]

10. Approvals

Role Name Date Reviewed
Tech Lead ☐
John ☐
Project Documentation

Hallucination Analysis (Feb 2026)

Drop — Hallucination Analiza

Datum: 2026-02-09 Analyst: John (AI Director) Kontekst: Kod nastao kao demo (nije prošao factory workflow)

Executive Summary

Backend je solidan (22 API rute, sve realne). Frontend ima 3 stranice sa mock podacima umjesto pravih API poziva. Dokumentacija zaostaje ~2 faze za kodom. Phantom integracije (Wise, Swan, Thunes, Sumsub, Stripe) navedene u docs ali nemaju ni liniju koda.

Ukupna tačnost dokumentacije: ~65%

Kritični problemi

1. Tri stranice koriste lažne podatke

Stranica Problem Potreban fix
/send Klik "Bekreft og send" samo mijenja UI step, NE poziva API Wire POST /api/transactions/remittance
/scan Koristi mockMerchant iz mock-data.ts, nema QR payment Wire POST /api/transactions/qr-payment
/merchant Komplet dashboard je hardcoded mock data Wire GET /api/merchants/dashboard + /api/merchants/transactions

Impakt: Korisnik misli da je poslao novac, ali ništa se ne dešava u bazi.

2. Phantom integracije — 0 koda

Integracija Claim u docs Stvarnost
Wise API "Mock → real later" 0 referenci u kodu
Swan BaaS "Mock → real later" 0 referenci u kodu
Thunes "Remittance provider" 0 referenci u kodu
Sumsub KYC "Mock identity verification" 0 referenci u kodu
Stripe Issuing "Mock card management" 0 referenci u kodu

3. Nula testova

Srednje ozbiljni problemi

4. Pipeline status zaostaje 2 faze

5. ~40% koda nedokumentirano

Ove feature nemaju ni riječ u arhitekturi ili brief-u:

6. Legal compliance violation

7. localStorage — phantom feature

Šta radi ispravno

Dependencies — ČISTO

API rute — 22/22 REALNE

Svaka ruta ima:

Auth — 100% implementiran

SQLite baza — ispravna

Frontend — 7/10 stranica spojeno na API

Brojke

Kategorija Rezultat
API rute 22/22 real (100%)
Dependencies 0 phantom, build OK
TypeScript errors 0
Stranice 7/10 real, 3/10 mock
Komponente 7 korištenih, 7 orphaned
Testovi 0
Ext. integracije 0/5 implementirano
Dokumentacija ~65% tačna

Orphaned komponente (instalirane, nikad korištene)

Fajlovi analizirani

Intake & Brief

Initial project intake and client brief documents

Intake & Brief

Intake: First Contact

First Contact: Drop

Rebrand note (2026-02-14): Originally "Zica" / "FontelePay". Product rebranded to Drop. See Drop CLAUDE.md for current spec.

Date: 2026-02-08 Source: Internal project Status: Qualified Lead Agent: nicksaraev (llama3.1:70b)

Client Info

Project Summary

Drop — fintech payment aplikacija za sve stanovnike Norveške/Skandinavije. Remittance + QR plaćanja sa pass-through PSD2 modelom (Drop nikad ne drži novac korisnika).

Existing: MVP sa 9+ stranica, Next.js 16 + React 19 + Tailwind v4, PostgreSQL 16 backend (Drizzle ORM, ADR-014), JWT auth, 24 API routes.

Needs: Real backend (PostgreSQL + JWT), full persistence, toast notifikacije, transaction history, UI polish.

Lead Qualification (AI: nicksaraev)

Portfolio vrijednost: VISOKA

Tržišni potencijal: VISOK

Rizici

Decision

QUALIFIED — Projekat ide dalje u Discovery.

Next Phase

Phase 2: Discovery → project-brief.md

Intake & Brief

Intake: Project Brief

Project Brief: Drop

Note: Originally written as "Zica" / "FontelePay". Product has been rebranded to Drop. See Drop CLAUDE.md for current spec.

Date: 2026-02-08 (updated 2026-02-14) Version: 2.0 Author: product agent (llama3.1:70b) + John Status: Updated

1. Problem

FontelePay MVP postoji ali ima kritične nedostatke:

2. Solution

Drop — fintech payment aplikacija sa:

3. Target Users

4. Key Features (MoSCoW)

Must Have

Should Have

Could Have

Won't Have (v1)

5. Tech Stack

Layer Technology
Frontend Next.js 16, React 19, Tailwind v4, shadcn/ui
Backend Next.js API Routes
Database PostgreSQL 16 (Drizzle ORM) — ADR-014
Auth JWT (jose library) + BankID
External APIs Open Banking (AISP/PISP) via bank partner
Hosting TBD (Vercel candidate)

6. Budget

Interni projekat — nema eksternog budžeta.

7. Timeline

Faza Trajanje
Planning + Analysis 1 sedmica
Design (Architecture) 1 sedmica
Implementation 2 sedmice
Testing + Polish 1 sedmica
Total ~5 sedmica

8. Success Metrics

9. Risks

Rizik Vjerovatnoća Impact Mitigacija
JWT security rupe Medium High Security agent review
Mock → real migration complexity Medium Medium Phased approach
Fintech regulacije Low High Legal agent review
Design gap (nema vizualnih assets) High Medium AI image gen + CSS-first pristup
Bank partner onboarding delay Medium High Multiple bank targets, MVP ready for demo

10. Approval

Role Name Date Status
Product (AI) product agent 2026-02-08 Drafted
John (AI Director) John 2026-02-08 Reviewed
John (AI Director) John 2026-02-14 Updated (rebrand)
Alem (CEO) Pending

Pitch: Neonomics Talk

Drop — Neonomics Pitch Talk

Møte: Alem Bašić (ALAI Holding AS) + Neonomics (Bergen) Varighet: ~8 minutter Mål: Sikre agent-avtale for PISP + AISP under Neonomics' PSD2-lisens

1. INTRO (30 sekunder)

Talking Points:

Power Sentence: "Drop er den eneste appen i Norge som kombinerer QR-betaling og utlandsoverføringer — og vi er billigst på markedet."

(Notis: Vis appen på skjermen her hvis Neonomics har projector)

2. PROBLEM (1 minutt)

Talking Points:

Power Sentence: "Hvis du sender 5000 kr til Polen via Western Union, betaler du 400 kr i avgift. Med Drop: 25 kr."

3. SOLUTION (2 minutter)

Talking Points:

Power Sentence: "Drop er ikke en nisjeapp for innvandrere — det er en massemarkedsapp som tilfeldigvis også er best på remittance."

(Notis: Vis wireframes/mockups her — onboarding, QR scan, send til Polen)

4. HOW IT WORKS (1 minutt)

Talking Points:

Power Sentence: "Vi bygger UI og produkt. Neonomics bygger rails. Sammen lager vi noe ingen andre har."

(Notis: Vis arkitekturdiagram hvis du har — bruker → Drop app → Neonomics API → bank)

5. WHAT WE NEED FROM NEONOMICS (1 minutt)

Talking Points:

Power Sentence: "Vi trenger ikke å reinvente hjulet. Vi trenger en partner som allerede har løst Open Banking — så vi kan fokusere på å bygge beste produkt."

6. REVENUE & BUSINESS CASE (1 minutt)

Talking Points:

Power Sentence: "Dette er ikke et spørsmål om 'hvis' — det er et spørsmål om 'når'. Markedet er der. Produktet er der. Vi trenger bare riktig partner."

7. STATUS & TIMELINE (30 sekunder)

Talking Points:

Power Sentence: "Vi er ikke på idé-stadiet. Vi er på 'trykk deploy'-stadiet."

8. THE ASK (30 sekunder)

Talking Points:

Power Sentence: "Vi er klare. Spørsmålet er: Når kan vi starte?"

FREQUENTLY ASKED QUESTIONS

1. Hvorfor trenger dere Neonomics? Hvorfor ikke søke egen PSD2-lisens?

Svar: Egen PSD2-lisens tar 12-18 måneder og koster 500K-1M NOK (legal, compliance, Finanstilsynet-søknad). Vi ønsker å lansere om 6-8 uker, ikke om 18 måneder. Agent-modell lar oss operere under Neonomics' lisens — vi får markedsadgang umiddelbart, og Neonomics får revenue share.

2. Hvem er konkurrentene deres?

Svar:

Vår fordel: Vi er den ENESTE som kombinerer begge — og billigst på begge.

3. Hvordan håndterer dere compliance (AML/KYC)?

Svar:

4. Hva er revenue split-en mellom Drop og Neonomics?

Svar: Det er opp til diskusjon. Typisk agent-modell i fintech er:

Vi er åpne for å forhandle basert på Neonomics' kostnad og risiko.

5. Hva om Neonomics lanserer egen konkurrerende app?

Svar: Fair spørsmål. Vi foreslår:

Vi tror det er bedre for begge parter å samarbeide enn å konkurrere.

6. Hvordan skalerer dere hvis dere får 100K brukere?

Svar:

7. Hva om en bank nekter å la Drop bruke deres API via Neonomics?

Svar: PSD2 er EU-direktiv (implementert i Norge via Finansforetaksloven). Banker er PÅLAGT å gi tilgang til lisensierte PISP/AISP-leverandører. Hvis en bank nekter, kan Neonomics (som lisensiinnehaver) eskalere til Finanstilsynet. Dette er regulatorisk beskyttet.

8. Hvorfor Bergen som første marked?

Svar:

9. Hva er exit-strategien?

Svar: Vi ser tre scenarioer:

  1. Acquisition: Vipps/Nets/DNB kjøper Drop som remittance-løsning (2-3 år)
  2. Scale + egen lisens: Når vi har 100K+ brukere, søker vi egen PSD2-lisens og ekspanderer til EU (4-5 år)
  3. Revenue-fokusert: Fortsetter som profitable standalone app med Neonomics som partner (ongoing)

Alle tre scenarioer er bra for Neonomics — enten får dere exit-bonus (ved salg), eller langsiktig revenue share.

10. Kan vi se en demo?

Svar: Ja! (Vis appen her — onboarding, QR scan, send penger til Polen, transaction history)

(Notis: Ha appen klar på telefonen. Hvis ikke produksjonsversjon, vis wireframes + Figma prototype)

FOLLOW-UP ACTIONS (Post-Meeting)

For Neonomics:

For Drop/ALAI:

Timeline:

Kontaktinfo: Alem Bašić CEO, ALAI Holding AS alem@alai.no +47 40 47 42 51

Company: ALAI Holding AS Org.nr: 932 516 136 getdrop.no