Plaid De-Duplication Logic for Unlink and Relink Cases
Last updated: August 27, 2026
Each new Plaid linkage for an institution comes with entirely new identifiers, even when it's the exact same account at the exact same bank. So when an institution is completely deleted and linked again later, Tight needs a way to recognize the new accounts as the ones that existed before. Otherwise every unlink and relink would leave the business owner with duplicate accounts.
How accounts are matched on relink
When an institution is relinked, Tight checks the new accounts against the previously linked ones in this order, and stops at the first match:
An exact match on account name, mask, and official name
Matches have to be exact
All three fields in check 3 have to match exactly. Accounts that only look similar are left alone, so a checking account never gets matched to a different checking account just because the name looks close.
The additional check for unlink and relink cases
One more check applies specifically when an account was removed through the API and later relinked: Tight will also match on mask plus account type and subtype. This catches cases where the name or official name shifted slightly between links but the account is otherwise clearly the same one.
Way to know if a bank account was deduped by Tight on relink
Tight does not directly expose a dedicated flag for knowing when a bank account was deduped on relink. However, you are able to use the /v5/banks/integrations endpoint with status ACTIVE and INACTIVE params to see the old linkage and new linkage from the same institution. Then, you can pull the audit trail for the bank account to find this information.
On a full relink, the old Plaid linkage goes INACTIVE and the new one comes back ACTIVE with a new apiAccountId and integrationId. If both change across that INACTIVE to ACTIVE transition, that's Tight deduping into the same bank account rather than creating a new one.