Syncing Bank Transactions with Open Banking APIs in Production
A production-focused guide to PSD2 open banking sync: consent flows, token refresh, pagination, deduplication, and rate-limit handling with code examples.
This guide targets the production realities of PSD2 open banking integrations that most tutorials skip: the consent flow, initial historical data pull, scheduled incremental sync, and token refresh cycle. It highlights that PSD2 consent tokens expire after a maximum of 180 days (commonly defaulting to 90), requiring explicit user reauthorization rather than silent renewal. A provider comparison covers Plaid, TrueLayer, Tink, GoCardless, and open-banking.io, weighing eIDAS QWAC certificate requirements (costing €3,000-15,000 annually), pricing models, and bank coverage.
On the technical side, the guide walks through cursor-based pagination, exponential backoff on 429 responses using the Retry-After header, and deduplication strategies with code samples. It stresses that since a pending transaction's ID can change once it settles, reconciliation should rely on matching amount, date, and counterparty rather than trusting transactionId alone. It also warns that batch-onboarding users can cause consent expiries to cluster on the same day, overwhelming reauth notification queues unless onboarding is staggered or notification timing is jittered.
The core takeaway for engineers is that while open banking REST APIs look similar across providers, the real difficulty lies in managing the consent lifecycle, deduplication logic, and rate limits correctly — get these wrong and you end up with silent data loss, duplicate records, or seemingly random 429 errors in production.