Check data freshness and get banking data faster

Banking data is synced from each institution after a consent is created, then refreshed on an ongoing basis. How quickly data lands varies by institution — data holders respond at different speeds, and a few only surface new transactions on their side after a delay.

See when data was last refreshed

Responses from GET /v1/banking/transactions include a meta block with, for each account, the account_id and an updated_at timestamp. updated_at is the last time the transaction data for that account was successfully refreshed from the institution — that is, the last successful check, not the time the institution posted the transactions.

Because the meta block describes accounts rather than pages, its contents repeat on every page of a paginated response. See the API reference for the full response schema.

Get data faster

1. Subscribe to sync webhooks instead of polling on a timer. The banking.transactions.basic.sync.completed event fires when basic transaction data is ready to query — query the API when you receive it, rather than waiting a fixed delay. See the webhooks guide.
2. Use basic transaction data for time-critical flows. Basic data completes syncing before detailed transaction data, so decisions like income detection can run sooner.
3. Stage your data pulls. If your flow has a fast step and a deep step (for example, a quick eligibility check followed by a full assessment), run the fast step from a recent window of basic data as soon as the sync webhook fires, and pull the full history afterwards.
4. Poll sensibly if you must poll. Use the meta.updated_at value to decide whether a re-query is worthwhile instead of re-pulling full history on a schedule.

Realistic expectations

• For most institutions, initial basic data is available within seconds to a couple of minutes of the bank being connected.
• Timing differs meaningfully between institutions, and large consents (many accounts, long history) take longer to complete.
• Some institutions only make new transactions available at their end after a delay — occasionally 24–48 hours. In those cases updated_at will advance while the newest transactions still lag; this is a data holder limitation.