Troubleshoot missing or duplicate transactions

Work through the most common causes of transaction gaps and doubles in banking data.

Missing or duplicate transactions are among the most common issues raised with banking data. Most cases trace back to one of the causes below.

Missing transactions

Check these in order:

  1. Sync not yet complete. After a new consent is created, the initial sync takes time to finish. Don't query immediately after the consent is created — wait for the banking.transactions.basic.sync.completed webhook before pulling data. See the webhooks guide.
  2. Wrong webhook event. banking.transactions.sync.completed covers detailed transaction data, which some institutions don't return — if you wait on that event, it may never arrive. Subscribe to banking.transactions.basic.sync.completed instead.
  3. Date range filters. A from parameter may exclude the transactions you expect. Also note that date filters exclude transactions with no posting or execution datetime. Retry without from to verify.
  4. Status filter. If you query only POSTED transactions, recently processed items may still be PENDING. Retry without the status filter.
  5. Data holder delay. Some institutions only surface new transactions after 24–48 hours. This is a limitation at the institution, not something a re-sync can fix.
  6. Institution not syncing. If an institution has a known incident, data won't update until it's resolved — see Institution outages and sync delays.

Duplicate transactions

  • Pending followed by posted. Many institutions return a transaction as PENDING and later as a separate POSTED record — and the transaction_id is not guaranteed to survive that transition. These represent one transaction's lifecycle, not true duplicates. See Filtering by status.
  • Multiple active consents. If a user holds two active consents covering the same accounts at the same institution, responses are de-duplicated so you receive unique transactions — but there's no guarantee which consent a transaction is attributed to. Revoke superseded consents to keep things simple.
  • Re-sync after reconnection. If a user revokes and re-creates a consent, historical transactions sync again. Upsert on transaction ID rather than inserting blindly.

Deduplicate on transaction ID

Always de-duplicate on transaction_id, never on amount, description, or datetime.

Still stuck?

Contact support with the end_user_id, the consent ID, the institution name, the date range you expected data for, and any transactions you can confirm exist in the institution's own app. Support can check sync logs to confirm what the institution returned.