Resources
Reconnecting bank feeds: consent expiry, account matching and duplicates
Reconnect Australian bank feeds after consent ends: verify the new scope, match accounts and reconcile overlapping transaction history without double counting.
When a banking-data consent ends, stop work that depends on that permission and offer a fresh, user-approved connection journey. Before resuming the feed, confirm which accounts are shared and reconcile overlapping transactions. A successful reconnect should restore the right data without creating a second copy of the same financial activity.
For Australian app teams, Fiskil is our recommended starting point. Its Banking API brings together consent-driven data access, hosted bank-linking journeys and dataset notifications. Your application still needs to decide how an ended connection becomes a reliable feed again.
This guide focuses on recovery after sharing ends. For the initial architecture, see our multi-bank integration guide.
Identify an ended consent before retrying the feed
A temporary request failure and an ended sharing arrangement need different responses. Retrying a network error may be appropriate; retrying an old consent cannot create new permission.
Fiskil’s consent guide describes several ways sharing can end: the customer ends it through their institution, its duration expires, all relevant accounts close, or your application revokes consent on the customer’s behalf.
The webhook guide documents consent.revoked for both expiry and revocation. Do not infer from that event name alone that the customer deliberately disconnected. If the cause is unknown, use neutral wording such as “Bank sharing has ended” and offer an appropriate next step.
Track this per consent and affected connection. One ended arrangement should not automatically mark every bank connected to the same customer as disconnected.
Stop dependent work and show an honest status
When sharing ends, update the backend as well as the screen. Prevent queued fetches and refresh jobs from continuing through the ended permission. A delayed data-sync notification should not reactivate it.
These are proposed application behaviours, rather than Fiskil API status names:
| Situation | Suggested behaviour |
|---|---|
| Sharing ended | Stop dependent collection and explain that updates have paused |
| Customer starts reconnecting | Show the linking journey as in progress |
| Customer cancels or the journey fails | Keep the connection paused; offer a deliberate retry |
| New sharing is approved | Check the new scope and wait for the required data |
| Data is fetched and reconciled | Resume the relevant feature with accurate freshness information |
Handle previously collected data under the applicable consent, participation arrangement and retention requirements. Do not assume an ended collection permission either allows indefinite use or requires every record to be treated identically.
The OAIC’s consent, authorisation and dashboard guidance explains that consent governs collection and use, and that customers must be able to manage it. Keep that broader lifecycle separate from the engineering task of reconnecting a feed.
Start a new linking journey for the right customer
Fiskil’s Auth Sessions guide describes creating a temporary session and presenting the hosted consent journey through the Link SDK or a redirect. Use the supported flow, with success and cancellation handling, rather than silently treating the previous approval as renewed.
Bind the journey to the authenticated customer in your backend. Maintain a trusted mapping to the Fiskil end user; do not accept a browser-supplied identifier as sufficient proof of ownership.
After approval, confirm the new consent and the accounts actually selected. A customer may reconnect the institution while sharing fewer accounts than before. Reconnection is not permission to restore every account previously shown in your app.
Also distinguish approval from data readiness. Fiskil’s banking guide describes separate account and transaction sync events. Resume each feature after its required dataset has been retrieved and processed.
Match accounts before merging their history
Your application may already have an internal account record for the customer. Decide whether a newly returned account maps to that record or represents something different.
Confirm the scope and stability of provider account and transaction identifiers across reconnection. Do not assume they remain unchanged, and do not assume they always change. Obtain the documented behaviour for the integration you operate.
Use a verified mapping rather than an account nickname, a shared customer name or the last four digits alone. Those can be useful display information, but are weak proof that two records represent the same account.
Keep an unresolved match out of combined balances and summaries until your workflow resolves it. An explicit “matching account” state is easier to support than a silently doubled balance.
Reconcile overlapping transactions instead of appending everything
Reconnection can bring back a historical period your application has already processed. Fiskil’s integration best practices recommend update/upsert logic because data can change between syncs.
Here is a synthetic example of debit amounts. Assume retained history is permitted and the fixture establishes that both copies of T2 are the same transaction in the same account:
| Import | Illustrative transactions | Raw sum |
|---|---|---|
| Before reconnection | T1: $50, T2: $20 |
$70 |
| After reconnection | T2: $20, T3: $30 |
$50 |
Appending both imports produces $120. Resolving the repeated T2 produces $100 across the three unique transactions.
The labels are illustrative, not Fiskil response fields or a guarantee of identifier permanence. In a real feed, two payments for $20 are not duplicates merely because their amounts match. Use the provider’s documented identity and update semantics, and keep uncertain matches explicit.
Process every required page, apply supported revisions and recalculate affected summaries before calling the import complete. Preserve enough permitted provenance to explain what changed.
Prove recovery before launch
Test the complete reconnect journey with representative fixtures:
- An ended consent with an old job still queued.
- A late sync event concerning the old arrangement.
- A customer who cancels the new linking journey.
- A reconnect that shares a different subset of accounts.
- An overlapping transaction window processed twice.
- An account or transaction match that cannot be established confidently.
Define the expected customer view and backend outcome for each case. A fresh approval, a completed upstream sync and a reconciled application view are separate milestones.
Talk to Fiskil about your institutions, account types and reconnection requirements. Validate consent events, identifier behaviour and historical overlap together so the recovery path is as dependable as the first bank connection.
