Skip to main content

Architecture Decision Record (ADR)

Architecture Decision Record — ADR-013{{NUMBER}}

Project: Drop{{PROJECT_NAME}} ADR Number: ADR-013{{NUMBER}} Title: Neonomics as Open Banking Aggregator for AISP/PISP{{SHORT_DECISION_TITLE}} Version: 1.0 Date: 2026-02-23{{DATE}} Author: Petter Graff, Senior Enterprise Architect{{AUTHOR}} Status: Proposed | Accepted | Deprecated | Superseded by ADR-{{NEW_NUMBER}} Reviewers: Alem Bašić (CEO), John (AI Director){{REVIEWERS}}

Document History

Version Date Author Changes
0.1 2026-02-23{{DATE}} Petter Graff{{AUTHOR}} Initial draft
1.0{{DATE}}{{AUTHOR}}Accepted after review

ADR Numbering Scheme

Convention: ADR-{NNN}-{short-slug}.md — e.g., ADR-013-neonomics-open-banking-aggregator.001-use-postgresql.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).{{DESCRIBE_THE_SITUATION_REQUIRING_A_DECISION}}

1.2 Forces & Constraints

Technical forces:

  • Drop must integrate with 10+ Norwegian banks to provide meaningful coverage{{TECHNICAL_FORCE_1}} — eache.g., bank"We need horizontal scalability for 100K+ concurrent users"
  • {{TECHNICAL_FORCE_2}} — e.g., "The team has slightlystrong differentexpertise PSD2in APITypeScript implementationsbut despitelimited theGo Berlin Group standardexperience"
  • 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{{TECHNICAL_FORCE_3}}

Business forces:

  • {{BUSINESS_FORCE_1}} — e.g., "Time-to-market is critical; Phase 2 Open Banking MVP must launch withinin 3-43 months of Finanstilsynet license/agent arrangementmonths"
  • Each direct bank integration requires a bilateral agreement and developer portal onboarding (2-6 weeks each)
  • Revenue model depends on remittance transaction volume{{BUSINESS_FORCE_2}} — delayede.g., Open"Budget Bankinglimits =managed zeroservices transactionto revenueunder $2K/month"

Compliance & regulatory:

  • Finanstilsynet{{COMPLIANCE_FORCE}} PISP/AISP— licensee.g., not yet obtained; Drop may operate as an agent under a licensed PSP while license is pending
  • GDPR: Data processed by aggregator"GDPR requires adata DPAresidency (Datain Processing Agreement) with the aggregator
  • PSD2 RTS: SCA (Strong Customer Authentication) must be ASPSP-side — aggregator must support scaRedirect flow (not screen-scraping)EEA"

Existing decisions that constrain this:

  • ADR-003{{PARENT_NUMBER}}: PSD2 pass-through model{{PARENT_DECISION}} — constrains us to regulated TPP AISP/PISP, not BaaS wallet{{CONSTRAINT}}
  • ADR-005:Existing Monolith-firstinfrastructure: — constrains us to a single integration point, not microservice-per-bank{{EXISTING_SYSTEM}}

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?{{CLEAR_ONE_SENTENCE_PROBLEM_STATEMENT}}

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.{{CLEAR_DECISION_STATEMENT}}

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).{{ONE_PARAGRAPH_WHY}}

3. Alternatives Considered

Option A: Neonomics Aggregator{{OPTION_A_NAME}} ← 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.{{OPTION_A_DESCRIPTION}}

Pros:

  • Nordic{{PRO_1}}: focus: Deep coverage of DNB, SpareBank 1, Nordea, Sbanken, Handelsbanken, Skandiabanken (90%+ Norwegian market){{EXPLANATION}}
  • Norwegian{{PRO_2}}: company: Strong FSA relationships, Norwegian language support, local regulatory expertise{{EXPLANATION}}
  • Single{{PRO_3}}: 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{{EXPLANATION}}

Cons:

  • Per-transaction{{CON_1}}: cost: Aggregator charges per API call / transaction — reduces margin compared to direct ASPSP integration at scale{{EXPLANATION}}
  • Data{{CON_2}}: 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{{EXPLANATION}}

Cost/Effort: Contract negotiation 2-4 weeks; technical integration 2-4 weeks{{ESTIMATE}} — total{{NOTES}}

6-8 weeks

Risk: MEDIUM{{RISK_LEVEL}} — Neonomics is a funded startup (not a Tier-1 bank); business continuity risk mitigated by Tink as backup{{RISK_DESCRIPTION}}

Option B: Direct Per-ASPSP Integration{{OPTION_B_NAME}}

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.{{OPTION_B_DESCRIPTION}}

Pros:

  • Lower{{PRO_1}}: per-transaction cost at scale: No aggregator margin once integrated{{EXPLANATION}}
  • Data{{PRO_2}}: stays bilateral: No third-party aggregator processes user financial data
  • Full control: No dependency on aggregator's uptime or pricing{{EXPLANATION}}

Cons:

  • Time:{{CON_1}}: Each bank takes 2-6 weeks to onboard — covering 5 banks = 10-30 weeks minimum{{EXPLANATION}}
  • Ongoing{{CON_2}}: maintenance: Each bank independently updates their API — Drop must track all changes{{EXPLANATION}}
  • eIDAS{{CON_3}}: 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{{EXPLANATION}}

Cost/Effort: 6-12{{ESTIMATE}} months— engineering{{NOTES}}

time + bank agreements + cert procurement

Risk: HIGH{{RISK_LEVEL}} — Timeline risk is critical; direct integration too slow for Phase 2 target{{RISK_DESCRIPTION}}

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.{{SPECIFIC_REASON_REJECTED}}

Option C: Tink (Visa) Aggregator{{OPTION_C_NAME}}

Description: Use Tink (acquired by Visa in 2022), the largest European Open Banking aggregator with 6,000+ banks across the EU.{{OPTION_C_DESCRIPTION}}

Pros:

  • Broadest{{PRO_1}}: coverage: 6,000+ banks — future-proof for any European expansion
  • Visa backing: Financial stability, enterprise SLAs{{EXPLANATION}}

Cons:

  • Non-Norwegian{{CON_1}}: HQ: Less Nordic specialization; support in English only{{EXPLANATION}}
  • Enterprise{{CON_2}}: pricing: Higher minimum spend than Neonomics
  • GDPR: Data processed in Sweden (EU) — adequate, but Neonomics processes in Norway{{EXPLANATION}}

Cost/Effort: Similar{{ESTIMATE}}

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.{{SPECIFIC_REASON_REJECTED}}

Comparison Matrix

Criterion Weight Option A: NeonomicsA (Selected) Option B: Direct ASPSPB Option C: TinkC
Time-to-market{{CRITERION_1}} 5{{1-5}} 5{{SCORE}} 1{{SCORE}} 4{{SCORE}}
Norwegian bank coverage{{CRITERION_2}} 5{{1-5}} 5{{SCORE}} 3{{SCORE}} 4{{SCORE}}
Per-transaction cost (3yr){{CRITERION_3}} 3{{1-5}} 3{{SCORE}} 5{{SCORE}} 3{{SCORE}}
GDPRTeam complianceexpertise4{{SCORE}}{{SCORE}}{{SCORE}}
Operational complexity 3 4{{SCORE}} 5{{SCORE}} 4{{SCORE}}
RegulatoryCost /(3-year license pathTCO) 4 5{{SCORE}}{{SCORE}}{{SCORE}}
Community/support 2 4
Vendor stability{{SCORE}} 3{{SCORE}} 355
Engineering effort4514{{SCORE}}
Weighted Total 131{{TOTAL_A}} 77{{TOTAL_B}} 112{{TOTAL_C}}

Score: 1 (poor) to 5 (excellent)

4. Consequences

4.1 Positive Consequences

  • Phase{{POSITIVE_1}}: 2 Open Banking live within 8 weeks of contract signing vs. 6-12 months for direct integration{{DETAIL}}
  • No{{POSITIVE_2}}: eIDAS certificate management burden until Drop obtains its own Finanstilsynet license{{DETAIL}}
  • Single{{POSITIVE_3}}: endpoint to maintain — bank API changes are Neonomics' responsibility
  • Norwegian regulatory expertise from partner reduces compliance risk{{DETAIL}}

4.2 Negative Consequences

  • Aggregator{{NEGATIVE_1}}: per-transaction fee reduces remittance margin by ~0.1-0.3% at scale{{DETAIL}} — Mitigation: Renegotiate pricing at 10K+ monthly transactions; plan direct integration for Phase 3{{MITIGATION}}
  • GDPR{{NEGATIVE_2}}: DPA with Neonomics required before any AISP data can transit their infrastructure{{DETAIL}} — Mitigation: DPA negotiated as part of commercial contract
  • Vendor concentration risk — Mitigation: Document Tink integration as a 6-week fallback migration path{{MITIGATION}}

4.3 Neutral / Secondary Effects

  • Drop's{{NEUTRAL_1}}: Hono API adds a single Neonomics client module (lib/openbanking/neonomics.ts) — clean encapsulation means provider can be swapped{{DETAIL}}
  • AISP{{NEUTRAL_2}}: and PISP are separate Neonomics API product lines — may have different pricing tiers{{DETAIL}}

4.4 Technical Debt Created

  • The{{DEBT_ITEM}}: 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{{PLAN_TO_ADDRESS}}
  • Acceptable because: Mock removal is low-risk (test infrastructure only) and unblocks clean integration{{REASON}}

5. Compliance Impact

Regulation Impact Notes
GDPR MEDIUM{{NONE/LOW/MEDIUM/HIGH}} AISP balance data and PISP payment data transit Neonomics — GDPR DPA required; Neonomics is EU/EEA entity{{DETAILS}}
PSD2 (Betalingstjenesteloven)PCI-DSS HIGH{{NONE/LOW/MEDIUM/HIGH}} Neonomics holds PISP/AISP registration; Drop operates as agent/technology partner until own license obtained{{DETAILS}}
AML (Hvitvaskingsloven)HIPAA LOW{{NONE/LOW/MEDIUM/HIGH}} Transaction monitoring remains Drop's responsibility regardless of aggregator{{DETAILS}}
DORASOC2 MEDIUM{{NONE/LOW/MEDIUM/HIGH}} Neonomics is a critical third-party ICT provider — must be documented in Drop's ICT risk management framework{{DETAILS}}

Data residency implications: Neonomics{{NONE processes/ data in Norway/EEA — no cross-border transfer to non-adequate countries.DATA_MUST_STAY_IN_REGION}}

6. Performance Impact

Metric Before (mock) After (Neonomics production)Expected) Source
AISPLatency balance read latency(p99) ~10ms (mock){{BEFORE}} ~200-500ms (Neonomics + ASPSP){{AFTER}} Neonomics SLA + Berlin Group typical{{BENCHMARK_SOURCE}}
PISP initiation latencyThroughput ~10ms (mock){{BEFORE}} ~300-800ms (Neonomics + ASPSP){{AFTER}} Neonomics SLA{{BENCHMARK_SOURCE}}
PISPMemory SCA redirect latencyfootprint N/A (mock){{BEFORE}} User-dependent (BankID at ASPSP){{AFTER}} External{{BENCHMARK_SOURCE}}
AvailabilityCost (monthly) N/A (mock){{BEFORE}} 99.5% SLA (Neonomics){{AFTER}} Neonomics commercial SLA{{ESTIMATE_SOURCE}}

Performance testing plan: Load test AISP balance reads with 100 concurrent users against Neonomics sandbox before production launch.{{HOW_WILL_WE_VALIDATE}}

7. Migration / Implementation Notes

7.1 Migration Plan

Phase 2a1 (Weeks 1-2){{DURATION}}): Contract + setup{{PHASE_1_DESCRIPTION}}
  - [ ] Sign Neonomics commercial contract{{TASK_1}}
  - [ ] Sign{{TASK_2}}

GDPRPhase DPA2 ({{DURATION}}): {{PHASE_2_DESCRIPTION}}
  - [ ] Obtain Neonomics sandbox API credentials{{TASK_3}}
  - [ ] Create lib/openbanking/neonomics.ts client module{{TASK_4}}

Phase 2b3 (Weeks 3-4){{DURATION}}): AISP integration{{PHASE_3_DESCRIPTION}} (balanceif reads)needed)
  - [ ] 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{TASK_5}}

7.2 Rollback Strategy

Can we roll back? YES{{YES/NO/PARTIAL}} — Feature flag NEXT_PUBLIC_SERVICE_MODE reverts to mock mode instantly{{EXPLANATION}}

RollbackIf steps:yes: {{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{{FLAG_NAME}} mock = simulated AISP/PISP; production = Neonomics live{{PURPOSE}} mock
OPEN_BANKING_PROVIDERFuture: switch between Neonomics and Tinkneonomics{{DEFAULT_VALUE}}
ADR Relationship Notes
ADR-003{{N}} Prerequisite PSD2 pass-through model requires AISP/PISP provider{{HOW_IT_RELATES}}
ADR-005{{N}} Constrained bySupersedes SingleThis monolithdecision meansreplaces single aggregator integration point{{OLD_DECISION}}
ADR-007{{N}} RelatedAffected BankIDThis useddecision forimpacts Drop login SCA; ASPSP-side SCA (for PISP) is separate via Neonomics scaRedirect{{HOW}}

9. Review Date

Next review: 2026-08-23 (6 months post-decision){{REVIEW_DATE}} or when Neonomics pricing changes by > 50%{{TRIGGER_CONDITION}}

Review trigger conditions:

  • {{TRIGGER_1}} — e.g., "If Dropload processesexceeds >500K 10,000req/day, monthlyrevisit transactions:caching evaluate direct ASPSP integration economicsstrategy"
  • {{TRIGGER_2}} — e.g., "If Neonomics raises per-transactionvendor pricing changes by >more than 50%: evaluate Tink migration"
  • If{{TRIGGER_3}} Neonomics— experiencese.g., >"After 36 outagesmonths in 30 days: activate Tink fallbackproduction"

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)
CEOCTO / Architect Alem Bašić
Back to top