DKB: verify & harden transaction sync via Enable Banking end-to-end

[andregoepel]

Goal

DKB transactions arrive reliably via the Enable Banking (PSD2) API sync — verified end-to-end with a real DKB consent, not just in code.

Current state

The plumbing already exists (Phase 3): EnableBankingConnector.Supports(Dkb), IEnableBankingClient.GetTransactionsAsync, consent flow (StartAuthorizationAsync/AuthorizeSessionAsync), and the Sync page lists non-Wise API accounts with "Sync now" / scheduled Quartz sync. What is missing is real-world verification and the fixes that usually fall out of it.

Scope

• Create a real DKB connection under Settings → Connections; complete the consent redirect; link the bank account via identification_hash (account IDs are session-specific — never match by session account id).
• Set a DKB account to SyncMethod.Api, link the connection, run "Sync now": transactions land, re-sync is idempotent (dedup hash), no silently dropped rows (parser/mapping failures surface with context).
• Deep initial sync right after fresh consent (history window shrinks to ~90 days afterwards — PLAN/CLAUDE rule), overlap re-fetch on subsequent syncs.
• Consent expiry surfaces on the Sync page (warning already exists — verify with a real expiring consent) and re-consent flow works.
• Scheduled sync (Quartz) runs against the real connection without interactive input.
• Fix whatever the live run uncovers (field mapping, pagination, error texts); add fixtures for any DKB-specific transaction JSON shapes encountered.

Done when

A DKB account syncs on schedule and manually for at least a week without duplicates, drops, or unexplained failures.

[john-frandsen]

Great breakdown of the verification scope — the identification_hash decision is the right call. Session-specific account IDs are one of the most common sources of ghost duplicates in bank-API integrations: a re-consent issues a brand-new account ID, and any code that joins on the raw API account id silently forks the transaction history. Hashing the stable triplet (iban + bban or maskedPan + currency) sidesteps that cleanly.

A few things worth stress-testing during the live DKB run, from building the same pipeline against multiple PSD2 connectors:

Dedup beyond the transaction hash. Enable Banking exposes transaction_id for most DKB rows, but it's occasionally null on pending bookings and on some savings/cash-account transaction types. If your dedup hash is the only key, two pending→booked transitions with slightly different booking_date/value_date will create duplicates that hash differently. Worth adding transaction_id as primary key with the hash as a fallback for the null case — mirrors what the Actual Budget bank-sync layer settled on after hitting this with Nordigen.

History window shrink. The 90-day window after initial consent is a consent-scoped limit, not a connector limit — re-issuing consent doesn't restore the deeper history. If a user needs >90d for year-end reconciliation, that initial sync needs to land the full available window before the consent ages. Worth surfacing in the Sync page UX so users don't accidentally take a "Sync now" with a 2-week-old consent and lose the deeper pull.

Consent expiry warning copy. The Enable Banking consent for DKB typically expires at 90 days (PSD2 SCA-mandated for recurring access). The "warning already exists" is great — make sure the re-consent flow can complete without dropping pending transactions queued against the expired consent. We've seen the pattern where the re-auth redirect invalidates the in-flight sync cursor, so transactions fetched just before the redirect are lost on resume.

Connector portability. If you ever want to swap Enable Banking for another PSD2 provider (e.g. if their DKB coverage changes or pricing shifts), the session-specific account IDs and consent lifecycle are the friction points — the identification_hash approach you've already adopted is exactly the abstraction that makes that swap survivable. The provider-agnostic data layer pattern is worth keeping discipline on even if you don't need it today; the GoCardless/Nordigen free-tier shutdown in June showed how brittle a single-provider assumption can be.

( Disclosure: I maintain open-banking.io, a cert-free PSD2 aggregation layer — the identification_hash + provider-agnostic-connector patterns above are the same ones we converged on, so I'm biased toward them. Not suggesting you switch; Enable Banking's DKB coverage is solid. )