Plaid to verified bank accounts: complete 2026 KYC workflow

Instead of chasing identity documents and bank details in separate messages, build a Plaid identity verification workflow that verifies the person, connects the account, and checks the relationship between them before approval. This 2026 guide separates those decisions so a successful bank connection never becomes an accidental identity approval.

Why this matters

Connecting a bank account is not the same as verifying its owner. A customer can complete a bank-linking flow while your identity check remains unfinished. Your application must keep those outcomes separate.

KYC, or know your customer, also extends beyond collecting an identity result. Your obligations depend on your business, jurisdiction, and activities. This guide covers the identity-to-bank-account handoff, not a universal compliance checklist.

For your 2026 implementation, define exactly what approval means before choosing endpoints. The identity verification guide for fintech companies provides related context for the customer onboarding decision.

Checktiv is best for independent hosts who want zero-code guest verification through shared links. A fintech bank-account workflow needs a different operating model: explicit customer records, provider results, and an approval rule that your application enforces.

Before you start

• Prepare access and environments. Have a Plaid account, access to the products your workflow requires, and a backend that can protect credentials. Keep Sandbox testing separate from production processing.
• Prepare the customer record and decision policy. Decide how you identify each customer, record consent, associate bank accounts, and handle unresolved results. Specify who reviews exceptions and what blocks approval.
• Resolve the account-ownership gotcha. Plaid Auth, Plaid Identity, and Plaid Identity Verification answer different questions. Confirm that your chosen institution and product combination supplies the account-holder information your matching rule requires before building that rule.

Do not build around a dashboard label copied from an old tutorial. Use the current Plaid documentation for required parameters and enabled products. The endpoint and field names below identify the relevant configuration units without assuming a particular dashboard layout.

Choose the product by the question it answers

These are complementary products and approaches, not interchangeable substitutes. Choose each one for a defined job, then document what its result does not establish.

Choose the evidence first, then the product. Adding more checks without assigning each one a decision creates a longer onboarding flow, not a clearer approval process.

Customer record and approval policy

Start with your own customer identifier. Provider identifiers belong under that record; they should not become competing definitions of who the customer is.

1. Create the customer record. Assign an internal identifier before beginning identity verification or bank linking. Store the customer’s submitted information according to your consent and retention requirements.
2. Define separate decision fields. Record the identity outcome, bank-connection outcome, account-holder comparison, and final approval independently. Treat these as your application’s concepts, not Plaid status names.
3. Write the approval rule. Require acceptable identity evidence and acceptable account evidence before granting the capability that depends on both. Route unresolved comparisons to review rather than converting them to approval.
4. Assign an exception owner. Specify who handles name discrepancies, unavailable account-holder data, and unfinished verification. Give that person a clear way to record the decision and its reason.

Expected result: Your customer record can explain why an account is approved, awaiting review, or not approved without treating bank connectivity as identity evidence.

For a clear 2026 launch checklist, use 1 customer record, 1 identity decision, and 1 bank-account decision as your starting model. These are recommended record boundaries, not limits on how many accounts a customer can connect.

Keep the decision understandable

A customer-facing message should explain the next action, while an internal record should preserve the reason. Those audiences need different levels of detail.

For example, tell a customer that their account-holder details need review rather than displaying a raw provider response. Internally, retain the relevant comparison outcome and the reviewer’s disposition under your approved data-handling policy.

Avoid placing full identity documents or financial details in ordinary application logs. Logs should help your team locate the record and diagnose the event, not become an uncontrolled copy of sensitive information.

Identity verification session

Create and track the identity session separately from the bank connection. A customer closing a window is not a verification result.

1. Configure the verification template. Choose the identity checks appropriate to your onboarding policy. Record which template governs the session so reviewers understand the evidence requested.
2. Create the session. Use `/identity_verification/create` with the required parameters from Plaid’s current documentation. Associate the resulting `id` with your internal customer record.
3. Present the verification experience. Use the supported delivery method for your implementation. Explain why verification is required and what the customer should do next.
4. Retrieve the result. Use `/identity_verification/get` to obtain the session’s `status` and relevant result details. Map those results to your documented identity policy.
5. Handle changes on the backend. Process supported notifications and retrieve the authoritative session result before changing your application’s approval state. Make repeated processing safe.

Expected result: You can locate the identity session for a specific customer and distinguish an unfinished check from a result your policy accepts.

For a 2026 build, test the unfinished path as carefully as the successful path. A redirect, closed browser tab, or frontend completion event must not substitute for the provider result your backend evaluates.

Keep identity verification language specific. Tell the customer that this step checks their identity; do not imply that it also confirms bank-account ownership or completes every KYC requirement.

Bank connection and account-holder comparison

Link the bank account only as part of a defined account decision. Decide whether customers can begin this step before identity verification finishes, but keep approval dependent on the required evidence.

1. Create the Link session. Call `/link/token/create` with the products required for your account workflow. Supply the relevant customer association using the documented `client_user_id` field.
2. Open Plaid Link. Present the bank-connection experience to the customer. Explain that this step connects an account and is separate from their identity check.
3. Exchange the token on your backend. Send the returned `public_token` to your server and exchange it through `/item/public_token/exchange`. Protect the resulting `access_token`; do not expose it in browser code or logs.
4. Select and record the account. Associate the selected `account_id` with the correct customer and connection. Do not assume every account returned by a connection is the account the customer intends to use.
5. Retrieve the evidence you need. Use `/auth/get` for supported account details. Use `/identity/get` for available bank-held identity information, or `/identity/match` when your policy calls for comparing supplied customer information with account-holder data.
6. Evaluate the relationship. Apply your documented matching and review rules. Handle joint accounts, business accounts, and name variations explicitly rather than treating every mismatch as the same problem.

Expected result: Your record identifies the selected account, the account-holder evidence available, and the resulting account decision.

The operational sequence is Identity check, Bank connection, Holder comparison, and Approval decision. Each stage contributes evidence to the next; none silently replaces another.

*A bank connection supplies evidence for approval; it is not the approval itself.*

A name comparison needs context. A joint account can contain multiple owners, and a business account can use an organization name rather than the individual customer’s name. Preserve enough context for review instead of reducing every result to a single unexplained score.

Approval gate and launch tests

Your backend owns the final decision. The customer interface displays that decision; it does not create it.

1. Check both evidence tracks. Confirm that the identity result meets policy and the selected bank account meets your account-holder requirements.
2. Apply the final gate. Grant the relevant account capability only after all required decisions are acceptable. Preserve the evidence references supporting that approval.
3. Test out-of-order events. Complete bank linking before identity verification in one test, then reverse the sequence in another. The same approval rule must apply in both cases.
4. Test repeated and unresolved events. Replay a notification, leave a verification unfinished, and submit an account requiring review. None should accidentally create a second approval or bypass the gate.

Expected result: Approval depends on the customer’s evidence, not the order in which browser screens finish.

For your 2026 release, include the customer’s next action in every unresolved state. “Review needed” is useful internally; the customer also needs to know whether to wait, finish verification, or provide clarification.

Second variant: review whenever the bank account changes

A replacement account is a new account decision. Keep the existing customer identity record, but do not transfer the previous account’s approval to the replacement automatically.

• Associate the replacement account with the same internal customer record.
• Retrieve the required account details and account-holder evidence for that account.
• Apply the account-matching policy again and record the new disposition.
• Reassess whether identity verification remains acceptable under your own refresh policy.
• Grant account-dependent capabilities only after the replacement account satisfies the approval gate.

Best for: Customers who change their payout or funding account after onboarding. The benefit is a reusable identity record with an explicit account-change decision; the trade-off is another review path your team must maintain.

Troubleshooting

Bank linking succeeds, but approval stays pending

Check the identity session and account-holder decision separately. A successful Link session does not finish those checks. Display the outstanding action rather than asking the customer to reconnect an already connected account.

The account name differs from the customer’s name

Review the available owner information and the account type. Joint ownership, organization names, and name formatting require different interpretations. Request only the clarification your policy needs, then record the reviewer’s reason.

Account-holder information is unavailable

Confirm the product and institution support for the connection. Do not turn unavailable information into a successful match. Route the case through your approved alternative-evidence process or keep the account unapproved.

A result appears under the wrong customer

Inspect the association among the internal customer identifier, identity session, connection, and selected account. Require the authenticated customer context when creating sessions and receiving account selections. Correct the association before evaluating approval.

Repeated notifications trigger repeated actions

Make event handling safe to repeat. Retrieve the current provider result, check the stored decision, and apply only the necessary state change. Replaying an event should not repeat a customer message or grant the same capability again.

Customize your workflow

Keep the workflow as simple as the decision allows. Request information because your approval policy uses it, not because another onboarding flow collects it.

For an independent rental host, Checktiv provides a zero-code shared-link guest verification experience. That is a different job from configuring bank-account linking, token exchange, and account-holder matching. Choose the host workflow when guest verification is the objective; choose the technical workflow when bank-account evidence is necessary.

For fintech onboarding, extend the customer record with review ownership, consent records, and policy-driven refresh decisions. Keep those additions separate from your frontend screens so changing the customer experience does not weaken the approval gate.

One last thing

The most useful final test is not another successful onboarding. For your 2026 release, connect a bank account while leaving identity verification unfinished, then confirm that approval remains blocked. That single scenario tests whether your application truly separates connection from verification.

Related guides

• Stripe-to-payouts workflow
• ID verification API integration for developers
• Identity verification software for banks