Using Invunion guide

Reconnect, sync, or disconnect a bank

Use Sync on an active connection to request new transactions since the last successful account sync. Disconnect when you need to remove the provider connection; imported transactions are retained. Reconnect by creating a new authorization, especially after an expired or unusable session. The initial connection requests up to 90 days.

Browse documentation

The connection card offers two verified lifecycle actions: synchronize an active connection and remove a connection. A reconnection is a new authorization flow, not a repair button on an inactive session.

Icon placement and labels can change. The current dashboard uses a circular-arrow sync action and a delete action. Before acting, identify whether your goal is to fetch newer transactions, replace authorization, or stop future access.

Prerequisites

  • Permission to manage connected internal bank accounts.
  • Access to the dashboard connection card.
  • For reconnection, the ability to complete a new Enable Banking authorization.
  • For sandbox testing, tenant mode sandbox plus SI, Personal, and Mock ASPSP.

Steps

  1. Inspect connection status. Open Connected internal bank accounts and locate the connection. Note its active, expired, or error status, its account list, and each account’s last-sync timestamp.

  2. Choose Sync for an active connection. Use the sync icon when the connection is active and you only need to request newer provider transactions. The manual sync starts from the account’s last-sync time. On a first connection, or when no last-sync time exists, the request starts up to 90 days back.

  3. Wait for completion. The icon shows progress while Invunion processes connected accounts. When it finishes, the card reloads. Open Transactions and filter or sort by date to verify the expected entries.

  4. Understand duplicate handling. Provider transactions have a source identity. If a manual sync returns records already imported, Invunion skips those duplicates instead of inserting them again.

  5. Use a new connection for renewed authorization. If the existing connection is expired, in error, or no longer has a usable provider session, start Add and complete a fresh authorization. In sandbox, explicitly choose SI and Personal before selecting Mock ASPSP.

  6. Check the new account and data. After authorization, Invunion discovers accounts and performs the initial up-to-90-day sync. Existing payment-method records can be reused when the same account IBAN is recognized, which helps avoid creating a duplicate account record during reconnection.

  7. Disconnect only after reviewing impact. Select the delete action on the old connection. The confirmation explains that previously imported transactions are retained. Confirm only when future sync through that connection should stop.

  8. Verify the final state. Ensure the obsolete connection is gone, the intended connection is active, and imported transaction history remains available. If you reconnected, use the new card’s sync timestamp for future diagnostics.

Expected result

  • Sync: newer available transactions are imported, existing source records are skipped, and the displayed last-sync time updates after processing.
  • Reconnect: a new active provider authorization and account connection are created, followed by an initial transaction request.
  • Disconnect: the selected provider connection is removed while transactions already imported remain in Invunion.

Disconnecting does not serve as a transaction-deletion function. This prevents previously imported financial history from disappearing merely because provider access changes.

Edge cases and troubleshooting

  • Sync icon is disabled: the connection is not active or another action is already running. Record the status and use a new authorization if the session is unusable.
  • Sync finishes with no new rows: there may be no new provider transactions, or all returned items may already exist. Compare the date range and last-sync time before treating this as an error.
  • Some connected accounts fail: collect the account labels, visible status, attempt time, and last-sync times. Avoid disconnecting all accounts until the failure is understood.
  • Reconnection appears to duplicate data: compare transaction source, date, amount, and reference. Provider-source deduplication should prevent exact source duplicates, but do not delete records based only on similar amounts.
  • Wrong sandbox options were used: remove that test connection and repeat with SI and Personal. Business test data can contain no transactions.
  • Transactions remain after disconnect: this is expected verified behavior.
  • You need all test data removed: follow the product’s available data-deletion process or contact support. Removing the connection alone is insufficient.

Security and sandbox notes

Disconnect a connection when access should no longer continue, but first preserve any diagnostic information needed for an active investigation. Never send provider credentials, authorization codes, private keys, or bank passwords to support.

Sandbox reconnection uses simulated consent and synthetic data. Production is a separate mode and availability is not claimed by this article. In either mode, UI changes can move lifecycle controls, so rely on the confirmation text before removing a connection.

Next step

If an action fails or a connection remains active without transactions, use Troubleshoot a bank connection. For a support escalation, prepare the fields in Contact support with diagnostics.

Updated

Was this article helpful?

Feedback helps us improve the next version of this guide.

Tell us what is missing