# 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](./ADR-003-psd2-pass-through.md): PSD2 pass-through model — constrains us to regulated TPP AISP/PISP, not BaaS wallet
- [ADR-005](./ADR-005-monolith-first.md): 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.ts` file (deprecated Swan mock) must be removed and replaced with a `mock-openbanking.ts` compatible 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:
1. Set `NEXT_PUBLIC_SERVICE_MODE=mock` in AWS Secrets Manager
2. Restart App Runner instances — rollback complete in < 5 minutes
3. 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](./ADR-003-psd2-pass-through.md) | Prerequisite | PSD2 pass-through model requires AISP/PISP provider |
| [ADR-005](./ADR-005-monolith-first.md) | Constrained by | Single monolith means single aggregator integration point |
| [ADR-007](./ADR-007-bankid-oidc-auth.md) | 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ć | | |