Skip to main content

Architecture Decision Record (ADR)

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

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

Document History

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

ADR Numbering Scheme

Convention: ADR-{NNN}-{short-slug}.md — e.g., ADR-001-use-postgresql.013-neonomics-open-banking-aggregator.md Store in: docs/architecture/adr/

1. Context

1.1 Situation

{{DESCRIBE_THE_SITUATION_REQUIRING_A_DECISION}}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:

  • {{TECHNICAL_FORCE_1}}Drop must integrate with 10+ Norwegian banks to provide meaningful coverage — e.g.,each "Webank needhas horizontalslightly scalabilitydifferent PSD2 API implementations despite the Berlin Group standard
  • eIDAS QWAC and QSeal certificates (required for 100K+direct concurrentASPSP users"integration) take 4-8 weeks to obtain from Buypass or Commfides
  • {{TECHNICAL_FORCE_2}}Drop's current backend is a single Hono API — e.g.,minimal "Theengineering teambandwidth hasfor strongmulti-bank expertiseintegration in TypeScript but limited Go experience"
  • {{TECHNICAL_FORCE_3}}maintenance

Business forces:

  • {{BUSINESS_FORCE_1}} — e.g., "Time-to-market is critical; Phase 2 Open Banking MVP must launch inwithin 33-4 months"months of Finanstilsynet license/agent arrangement
  • {{BUSINESS_FORCE_2}}Each direct bank integration requires a bilateral agreement and developer portal onboarding (2-6 weeks each)
  • Revenue model depends on remittance transaction volume — e.g.,delayed "BudgetOpen limitsBanking managed= serviceszero totransaction under $2K/month"revenue

Compliance & regulatory:

  • {{COMPLIANCE_FORCE}}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 — e.g.,aggregator "GDPRmust requiressupport datascaRedirect residencyflow in(not EEA"screen-scraping)

Existing decisions that constrain this:

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

1.3 Problem Statement

We need to decide: {{CLEAR_ONE_SENTENCE_PROBLEM_STATEMENT}}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: {{CLEAR_DECISION_STATEMENT}}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): {{ONE_PARAGRAPH_WHY}}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: {{OPTION_A_NAME}}Neonomics Aggregator ← Selected

Description: {{OPTION_A_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:

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

  • {{CON_1}}:Per-transaction {{EXPLANATION}}cost: Aggregator charges per API call / transaction — reduces margin compared to direct ASPSP integration at scale
  • {{CON_2}}:Data {{EXPLANATION}}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: {{ESTIMATE}}Contract negotiation 2-4 weeks; technical integration 2-4 weeks — {{NOTES}}

total

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

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

Description: {{OPTION_B_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:

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

Cons:

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

engineering

time + bank agreements + cert procurement Risk: {{RISK_LEVEL}}HIGH — {{RISK_DESCRIPTION}}Timeline risk is critical; direct integration too slow for Phase 2 target

Why not chosen: {{SPECIFIC_REASON_REJECTED}}Timeline incompatible with Phase 2 launch target; Direct integration is the long-term (Phase 3+) optimization once scale justifies the margin savings.

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

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

Pros:

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

Cons:

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

Cost/Effort: {{ESTIMATE}}

Similar

to Neonomics — 6-8 weeks integration Why not chosen: {{SPECIFIC_REASON_REJECTED}}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 AA: Neonomics (Selected) Option BB: Direct ASPSP Option CC: Tink
{{CRITERION_1}}Time-to-market {{1-5}}5 {{SCORE}}5 {{SCORE}}1 {{SCORE}}4
{{CRITERION_2}}Norwegian bank coverage {{1-5}}5 {{SCORE}}5 {{SCORE}}3 {{SCORE}}4
{{CRITERION_3}}Per-transaction cost (3yr) {{1-5}}3 {{SCORE}}3 {{SCORE}}5 {{SCORE}}3
TeamGDPR expertise4{{SCORE}}{{SCORE}}{{SCORE}}
Operationalcompliance complexity 3 {{SCORE}}4 {{SCORE}}5 {{SCORE}}4
CostRegulatory (3-year/ TCO)license path 4 {{SCORE}}5 {{SCORE}}2 {{SCORE}}4
Community/supportVendor stability 23 {{SCORE}}3 {{SCORE}}5 {{SCORE}}5
Engineering effort4514
Weighted Total {{TOTAL_A}}131 {{TOTAL_B}}77 {{TOTAL_C}}112

Score: 1 (poor) to 5 (excellent)

4. Consequences

4.1 Positive Consequences

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

4.2 Negative Consequences

  • {{NEGATIVE_1}}:Aggregator {{DETAIL}}per-transaction fee reduces remittance margin by ~0.1-0.3% at scale — Mitigation: {{MITIGATION}}Renegotiate pricing at 10K+ monthly transactions; plan direct integration for Phase 3
  • {{NEGATIVE_2}}:GDPR {{DETAIL}}DPA with Neonomics required before any AISP data can transit their infrastructure — Mitigation: {{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

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

4.4 Technical Debt Created

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

5. Compliance Impact

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

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

6. Performance Impact

Metric Before (mock) After (Expected)Neonomics production) Source
LatencyAISP (p99)balance read latency {{BEFORE}}~10ms (mock) {{AFTER}}~200-500ms (Neonomics + ASPSP) {{BENCHMARK_SOURCE}}Neonomics SLA + Berlin Group typical
ThroughputPISP initiation latency {{BEFORE}}~10ms (mock) {{AFTER}}~300-800ms (Neonomics + ASPSP) {{BENCHMARK_SOURCE}}Neonomics SLA
MemoryPISP footprintSCA redirect latency {{BEFORE}}N/A (mock) {{AFTER}}User-dependent (BankID at ASPSP) {{BENCHMARK_SOURCE}}External
Cost (monthly)Availability {{BEFORE}}N/A (mock) {{AFTER}}99.5% SLA (Neonomics) {{ESTIMATE_SOURCE}}Neonomics commercial SLA

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

7. Migration / Implementation Notes

7.1 Migration Plan

Phase 12a ({{DURATION}})Weeks 1-2): {{PHASE_1_DESCRIPTION}}Contract + setup
  - [ ] {{TASK_1}}Sign Neonomics commercial contract
  - [ ] {{TASK_2}}Sign PhaseGDPR 2 ({{DURATION}}): {{PHASE_2_DESCRIPTION}}DPA
  - [ ] {{TASK_3}}Obtain Neonomics sandbox API credentials
  - [ ] {{TASK_4}}Create lib/openbanking/neonomics.ts client module

Phase 32b ({{DURATION}})Weeks 3-4): {{PHASE_3_DESCRIPTION}}AISP integration (ifbalance needed)reads)
  - [ ] Implement AISP consent flow (POST /v1/consents)
  - [ ] Implement balance read (GET /v1/accounts/{{TASK_5}}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/NO/PARTIAL}}YES — {{EXPLANATION}}Feature flag NEXT_PUBLIC_SERVICE_MODE reverts to mock mode instantly

IfRollback yes:steps:

{{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
{{FLAG_NAME}}NEXT_PUBLIC_SERVICE_MODE {{PURPOSE}}mock = simulated AISP/PISP; production = Neonomics live {{DEFAULT_VALUE}}mock
OPEN_BANKING_PROVIDERFuture: switch between Neonomics and Tinkneonomics
ADR Relationship Notes
ADR-{{N}}003 Prerequisite {{HOW_IT_RELATES}}PSD2 pass-through model requires AISP/PISP provider
ADR-{{N}}005 SupersedesConstrained by ThisSingle decisionmonolith replacesmeans {{OLD_DECISION}}single aggregator integration point
ADR-{{N}}007 AffectedRelated ThisBankID decisionused impactsfor {{HOW}}Drop login SCA; ASPSP-side SCA (for PISP) is separate via Neonomics scaRedirect

9. Review Date

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

Review trigger conditions:

  • {{TRIGGER_1}} — e.g., "If loadDrop exceedsprocesses 500K> req/day,10,000 revisitmonthly cachingtransactions: strategy"evaluate direct ASPSP integration economics
  • {{TRIGGER_2}} — e.g., "If vendorNeonomics raises per-transaction pricing changes by more than> 50%": evaluate Tink migration
  • {{TRIGGER_3}}If —Neonomics e.g.,experiences "After> 63 monthsoutages in production"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)
CTO / ArchitectCEO Alem Bašić
Back to top