Architecture Decision Record — ADR-013
Architecture Decision Record — ADR-013
Project: Drop ADR Number: ADR-013 Title: Neonomics as Open Banking Aggregator for AISP/PISP Version: 1.0 Date: 2026-02-23 Author: Petter Graff, Senior Enterprise Architect Status: Proposed Reviewers: Alem Bašić (CEO), John (AI Director)
Document History
| Version | Date | Author | Changes |
|---|---|---|---|
| 0.1 | 2026-02-23 | Petter Graff | Initial draft |
ADR Numbering Scheme
Convention: ADR-{NNN}-{short-slug}.md — e.g., ADR-013-neonomics-open-banking-aggregator.md
Store in: docs/architecture/adr/
1. Context
1.1 Situation
Drop is a PSD2 pass-through payment application (ADR-003) that requires AISP (read bank balances) and PISP (initiate payments from user's bank) capabilities to function in production. The current MVP uses mock AISP/PISP — the NEXT_PUBLIC_SERVICE_MODE=mock flag returns simulated balances and payment confirmations without contacting real banks.
To go live (Phase 2), Drop must connect to the actual Open Banking APIs of Norwegian and Nordic banks (DNB, SpareBank 1, Nordea, Handelsbanken, etc.) using the Berlin Group NextGenPSD2 standard. Two strategic approaches exist: direct ASPSP integration (per-bank) or aggregator integration (single API covering all banks).
The previous planned provider, Swan (a BaaS provider), has been deprecated and removed from the codebase — it was not aligned with the PSD2 pass-through model (Swan offered embedded banking, not TPP-style AISP/PISP).
1.2 Forces & Constraints
Technical forces:
- Drop must integrate with 10+ Norwegian banks to provide meaningful coverage — each bank has slightly different PSD2 API implementations despite the Berlin Group standard
- eIDAS QWAC and QSeal certificates (required for direct ASPSP integration) take 4-8 weeks to obtain from Buypass or Commfides
- Drop's current backend is a single Hono API — minimal engineering bandwidth for multi-bank integration maintenance
Business forces:
- Time-to-market is critical; Phase 2 Open Banking MVP must launch within 3-4 months of Finanstilsynet license/agent arrangement
- Each direct bank integration requires a bilateral agreement and developer portal onboarding (2-6 weeks each)
- Revenue model depends on remittance transaction volume — delayed Open Banking = zero transaction revenue
Compliance & regulatory:
- Finanstilsynet PISP/AISP license not yet obtained; Drop may operate as an agent under a licensed PSP while license is pending
- GDPR: Data processed by aggregator requires a DPA (Data Processing Agreement) with the aggregator
- PSD2 RTS: SCA (Strong Customer Authentication) must be ASPSP-side — aggregator must support scaRedirect flow (not screen-scraping)
Existing decisions that constrain this:
- ADR-003: PSD2 pass-through model — constrains us to regulated TPP AISP/PISP, not BaaS wallet
- ADR-005: Monolith-first — constrains us to a single integration point, not microservice-per-bank
1.3 Problem Statement
We need to decide: Which Open Banking connectivity strategy should Drop adopt for Phase 2 production AISP/PISP — direct per-ASPSP integration or a single Open Banking aggregator?
2. Decision
We will: Use Neonomics as the primary Open Banking aggregator for both AISP (balance reads) and PISP (payment initiation) in the Norwegian and Nordic market.
Rationale (summary): Neonomics provides a single REST API endpoint covering 90%+ of Norwegian banks under the Berlin Group NextGenPSD2 standard, handles eIDAS certificate management and bank onboarding, and is a Norwegian company with strong local regulatory relationships — reducing Drop's time-to-market from 6-9 months (direct per-bank) to 6-8 weeks (aggregator contract + integration).
3. Alternatives Considered
Option A: Neonomics Aggregator ← Selected
Description: Contract with Neonomics (Norwegian Open Banking aggregator, Oslo HQ) for a single HTTPS REST API covering Norwegian + Nordic banks. Neonomics holds its own PISP/AISP registration with Finanstilsynet and eIDAS certificates — Drop operates as an agent or technology partner under Neonomics' regulatory umbrella initially.
Pros:
- Nordic focus: Deep coverage of DNB, SpareBank 1, Nordea, Sbanken, Handelsbanken, Skandiabanken (90%+ Norwegian market)
- Norwegian company: Strong FSA relationships, Norwegian language support, local regulatory expertise
- Single API: One integration maintains coverage across all banks — bank API updates handled by Neonomics
- eIDAS certs handled by Neonomics: Removes 4-8 week cert procurement from Drop's critical path
- Agent arrangement possible: Drop can operate under Neonomics' license while applying for own license
Cons:
- Per-transaction cost: Aggregator charges per API call / transaction — reduces margin compared to direct ASPSP integration at scale
- Data through third party: All AISP data transits Neonomics infrastructure — requires GDPR DPA
- Neonomics dependency: If Neonomics is acquired or raises prices, switching is a 2-3 month project
Cost/Effort: Contract negotiation 2-4 weeks; technical integration 2-4 weeks — total 6-8 weeks Risk: MEDIUM — Neonomics is a funded startup (not a Tier-1 bank); business continuity risk mitigated by Tink as backup
Option B: Direct Per-ASPSP Integration
Description: Integrate directly with each Norwegian bank's PSD2 developer portal: DNB API, SpareBank 1 Open Banking, Nordea Open Banking, etc. Each bank has its own onboarding process, bilateral agreement, and API specifics.
Pros:
- Lower per-transaction cost at scale: No aggregator margin once integrated
- Data stays bilateral: No third-party aggregator processes user financial data
- Full control: No dependency on aggregator's uptime or pricing
Cons:
- Time: Each bank takes 2-6 weeks to onboard — covering 5 banks = 10-30 weeks minimum
- Ongoing maintenance: Each bank independently updates their API — Drop must track all changes
- eIDAS certificates: Drop must obtain QWAC + QSeal independently (4-8 weeks, ~€3,000-5,000/year)
- Finanstilsynet license: Cannot make direct ASPSP calls without own license or agent arrangement — blocks Phase 2
Cost/Effort: 6-12 months engineering time + bank agreements + cert procurement Risk: HIGH — Timeline risk is critical; direct integration too slow for Phase 2 target
Why not chosen: Timeline incompatible with Phase 2 launch target; Direct integration is the long-term (Phase 3+) optimization once scale justifies the margin savings.
Option C: Tink (Visa) Aggregator
Description: Use Tink (acquired by Visa in 2022), the largest European Open Banking aggregator with 6,000+ banks across the EU.
Pros:
- Broadest coverage: 6,000+ banks — future-proof for any European expansion
- Visa backing: Financial stability, enterprise SLAs
Cons:
- Non-Norwegian HQ: Less Nordic specialization; support in English only
- Enterprise pricing: Higher minimum spend than Neonomics
- GDPR: Data processed in Sweden (EU) — adequate, but Neonomics processes in Norway
Cost/Effort: Similar to Neonomics — 6-8 weeks integration Why not chosen: Neonomics preferred for Phase 2 Norwegian launch due to local regulatory relationships and Norwegian bank specialization. Tink retained as Backup/Phase 3 (EU expansion) option.
Comparison Matrix
| Criterion | Weight | Option A: Neonomics (Selected) | Option B: Direct ASPSP | Option C: Tink |
|---|---|---|---|---|
| Time-to-market | 5 | 5 | 1 | 4 |
| Norwegian bank coverage | 5 | 5 | 3 | 4 |
| Per-transaction cost (3yr) | 3 | 3 | 5 | 3 |
| GDPR compliance complexity | 3 | 4 | 5 | 4 |
| Regulatory / license path | 4 | 5 | 2 | 4 |
| Vendor stability | 3 | 3 | 5 | 5 |
| Engineering effort | 4 | 5 | 1 | 4 |
| Weighted Total | 131 | 77 | 112 |
Score: 1 (poor) to 5 (excellent)
4. Consequences
4.1 Positive Consequences
- Phase 2 Open Banking live within 8 weeks of contract signing vs. 6-12 months for direct integration
- No eIDAS certificate management burden until Drop obtains its own Finanstilsynet license
- Single endpoint to maintain — bank API changes are Neonomics' responsibility
- Norwegian regulatory expertise from partner reduces compliance risk
4.2 Negative Consequences
- Aggregator per-transaction fee reduces remittance margin by ~0.1-0.3% at scale — Mitigation: Renegotiate pricing at 10K+ monthly transactions; plan direct integration for Phase 3
- GDPR DPA with Neonomics required before any AISP data can transit their infrastructure — Mitigation: DPA negotiated as part of commercial contract
- Vendor concentration risk — Mitigation: Document Tink integration as a 6-week fallback migration path
4.3 Neutral / Secondary Effects
- Drop's Hono API adds a single Neonomics client module (
lib/openbanking/neonomics.ts) — clean encapsulation means provider can be swapped - AISP and PISP are separate Neonomics API product lines — may have different pricing tiers
4.4 Technical Debt Created
- The
mock-swan.tsfile (deprecated Swan mock) must be removed and replaced with amock-openbanking.tscompatible with the Neonomics API schema — plan in Phase 2 sprint 1 - Acceptable because: Mock removal is low-risk (test infrastructure only) and unblocks clean integration
5. Compliance Impact
| Regulation | Impact | Notes |
|---|---|---|
| GDPR | MEDIUM | AISP balance data and PISP payment data transit Neonomics — GDPR DPA required; Neonomics is EU/EEA entity |
| PSD2 (Betalingstjenesteloven) | HIGH | Neonomics holds PISP/AISP registration; Drop operates as agent/technology partner until own license obtained |
| AML (Hvitvaskingsloven) | LOW | Transaction monitoring remains Drop's responsibility regardless of aggregator |
| DORA | MEDIUM | Neonomics is a critical third-party ICT provider — must be documented in Drop's ICT risk management framework |
Data residency implications: Neonomics processes data in Norway/EEA — no cross-border transfer to non-adequate countries.
6. Performance Impact
| Metric | Before (mock) | After (Neonomics production) | Source |
|---|---|---|---|
| AISP balance read latency | ~10ms (mock) | ~200-500ms (Neonomics + ASPSP) | Neonomics SLA + Berlin Group typical |
| PISP initiation latency | ~10ms (mock) | ~300-800ms (Neonomics + ASPSP) | Neonomics SLA |
| PISP SCA redirect latency | N/A (mock) | User-dependent (BankID at ASPSP) | External |
| Availability | N/A (mock) | 99.5% SLA (Neonomics) | Neonomics commercial SLA |
Performance testing plan: Load test AISP balance reads with 100 concurrent users against Neonomics sandbox before production launch.
7. Migration / Implementation Notes
7.1 Migration Plan
Phase 2a (Weeks 1-2): Contract + setup
- [ ] Sign Neonomics commercial contract
- [ ] Sign GDPR DPA
- [ ] Obtain Neonomics sandbox API credentials
- [ ] Create lib/openbanking/neonomics.ts client module
Phase 2b (Weeks 3-4): AISP integration (balance reads)
- [ ] Implement AISP consent flow (POST /v1/consents)
- [ ] Implement balance read (GET /v1/accounts/{id}/balances)
- [ ] Update bank_accounts table (add consent_id, consent_expires_at columns)
- [ ] Integration test against Neonomics sandbox with DNB test account
Phase 2c (Weeks 5-6): PISP integration (payment initiation)
- [ ] Implement PISP payment initiation (POST /v1/payments/sepa-credit-transfers)
- [ ] Implement SCA redirect flow + payment status polling
- [ ] Add payment webhook receiver for async status updates
- [ ] Integration test: full remittance flow against Neonomics sandbox
Phase 2d (Weeks 7-8): Production readiness
- [ ] Switch NEXT_PUBLIC_SERVICE_MODE from 'mock' to 'production'
- [ ] Production credentials (Neonomics production API key) in AWS Secrets Manager
- [ ] Remove deprecated mock-swan.ts
- [ ] Monitoring: Sentry alerts for Neonomics API errors
- [ ] Circuit breaker: 3 failures in 60s → 60s cooldown
7.2 Rollback Strategy
Can we roll back? YES — Feature flag NEXT_PUBLIC_SERVICE_MODE reverts to mock mode instantly
Rollback steps:
- Set
NEXT_PUBLIC_SERVICE_MODE=mockin AWS Secrets Manager - Restart App Runner instances — rollback complete in < 5 minutes
- Users see cached balance; payments queue for retry when production mode re-enabled
7.3 Feature Flags
| Flag | Purpose | Default |
|---|---|---|
NEXT_PUBLIC_SERVICE_MODE |
mock = simulated AISP/PISP; production = Neonomics live |
mock |
OPEN_BANKING_PROVIDER |
Future: switch between Neonomics and Tink | neonomics |
8. Related ADRs
| ADR | Relationship | Notes |
|---|---|---|
| ADR-003 | Prerequisite | PSD2 pass-through model requires AISP/PISP provider |
| ADR-005 | Constrained by | Single monolith means single aggregator integration point |
| ADR-007 | Related | BankID used for Drop login SCA; ASPSP-side SCA (for PISP) is separate via Neonomics scaRedirect |
9. Review Date
Next review: 2026-08-23 (6 months post-decision) or when Neonomics pricing changes by > 50%
Review trigger conditions:
- If Drop processes > 10,000 monthly transactions: evaluate direct ASPSP integration economics
- If Neonomics raises per-transaction pricing by > 50%: evaluate Tink migration
- If Neonomics experiences > 3 outages in 30 days: activate Tink fallback
Superseded by: — (fill in if this ADR is later superseded)
Approval
| Role | Name | Date | Signature |
|---|---|---|---|
| Author | Petter Graff | 2026-02-23 | |
| Tech Lead | John (AI Director) | ||
| Security (if compliance impact) | |||
| CEO | Alem Bašić |