> ## Documentation Index > Fetch the complete documentation index at: https://docs.synctera.com/llms.txt > Use this file to discover all available pages before exploring further. # FinTech Bank Migration Overview ## Executive summary A bank migration is not a single event. It is a controlled program that spans bank selection, legal and compliance readiness, customer communications, technical setup, new account opening, funds movement, card transition, legacy account closure, and post-migration support. In practice, most successful migrations follow one of three models: * \[For customers opting into migration] An opt-in rolling migration with a dual-bank period, where customers accept new terms, open a new account, and migrate in waves * \[For customers opting into migration] A bulk migration with a coordinated cutoff, where a large population is moved against a planned cutover date and tightly managed communications timeline * \[For customers who do not opt into migration] A wind-down path for customers, where legacy accounts are closed and residual funds are returned under the legacy bank's closure procedures The right model depends on the FinTech's customer base, product complexity, card program, operational capacity, compliance posture, and the new sponsor bank's willingness to rely on existing KYC/KYB results. ## How bank migrations work on Synctera At a high level, a migration on Synctera usually follows this pattern: * Synctera helps identify and align the FinTech with a new sponsor bank * A new tenant is established under the new bank * The FinTech configures the new tenant for the target program, including account templates, card products, spend controls, and operational settings * Customers are asked to accept the new bank's disclosures and account agreement * Customers and accounts are recreated on the new tenant * Old and new records are linked through migration mappings * Funds, cards, external account connections, and scheduled activity are transitioned according to the selected migration model * Legacy accounts are frozen and then closed once migration conditions are met * Residual issues such as disputes, statements, and support lookups continue to be managed through controlled wind-down procedures
A critical Synctera concept is that migrated resources are recreated, not simply moved in place. The public [Bank Migration Guide](https://docs.synctera.com/v2/docs/bank-migration) states that customers, accounts, and external accounts are recreated under the new bank's tenant, then linked via migration mappings that preserve continuity across tenants.
## Phase 1: Finding and matching with a new sponsor bank The migration starts before any customer-facing activity. The FinTech and Synctera first need to determine whether the target sponsor bank is a true fit. ### Materials typically needed for bank matching In Synctera practice, bank approval often requires current program documents, security policies, insurance documentation, third-party risk materials, penetration-testing status, and a program requirements document or similar package describing the FinTech's program, controls, customer segments, and flow of funds. ### Early decision points that shape the migration Before a FinTech commits to the new bank, several questions materially affect feasibility and customer experience:
* Can KYC/KYB be relied upon, or will users need to re-verify? * Can the new bank support the same account structure, rails, controls, and geography? * Will the FinTech run two banks in parallel for a period, or target a hard cutover? * How will residual balances be handled for users who never opt in?
These decisions should be made before customer communications begin. ## Phase 2: New-bank setup on Synctera Once the new sponsor bank is selected, Synctera and the FinTech prepare the new tenant. ### Synctera-led setup Typical Synctera setup activities include:
* Creating the new tenant under the new bank * Enabling the relevant payment rails and operational configurations * Setting up card products needed for reissuance, including submitting card art to the fulfillment vendor and the network * Supporting cross-tenant record linkage so old and new resources can be traced * Preparing migration reporting and support visibility ### FinTech-led setup The FinTech typically prepares or recreates:
* Account templates * Spend controls * Webhook subscriptions and downstream integrations * New API credentials for the new tenant * Internal operations procedures and reporting * Customer communications and migration UX in the app * Updated physical card art with the new sponsor bank named on the back of card
A practical implication is that the FinTech should treat the new tenant like a new production environment. ## Phase 3: Customer agreement, disclosures, and eligibility For most migrations, customers should actively agree to migrate to a new bank. The usual model is that the FinTech presents the new bank's disclosures and account agreement, and migration proceeds only after acceptance. ### Common eligibility rules A FinTech may choose to migrate:
* Active customers only * Customers with open accounts only * Customers above a certain balance threshold * Customers in products supported by the new bank * Customers whose risk profile remains acceptable under the new bank
Some FinTechs also choose not to migrate negative-balance deposit accounts, inactive users, or customer segments that would create outsized operational complexity during the initial move. ### KYC/KYB considerations This is one of the biggest branch points in the migration plan.
If the new sponsor bank accepts a reliance agreement, the FinTech may be able to avoid a full re-KYC or re-KYB event for the migrated population. If the new bank does not accept reliance, the migration becomes operationally much closer to a new onboarding program.
Even where reliance is permitted, many FinTechs still use the migration moment to refresh contact details, confirm mailing addresses, re-upload supporting documents where needed, and re-enroll users into ongoing monitoring required by the new tenant. ## The three migration models ## 1) Opt-in rolling migration with a dual-bank period This is often the most customer-friendly model and is frequently the best fit when a FinTech wants to reduce disruption. ### How it works * Existing users remain on the legacy bank initially * New users may begin onboarding directly to the new bank * Existing users are invited to accept new disclosures and open a new account with the new bank * Old and new accounts may coexist for a controlled period * Customers move their balances and payment activity over as they opt for a new account * Legacy accounts are closed only after the migration conditions are satisfied ### Why FinTechs choose it * Lower operational shock * More time to educate customers * Better for complex programs with cards, subscriptions, or external account links * Better when the FinTech wants to prioritize high-value or highly engaged users first ### Best-fit use cases * Consumer FinTechs with active balances and repeat card use * Programs where customer education matters * FinTechs that want to stage high-touch cohorts first ## 2) Bulk migration with coordinated cutoff This model compresses the transition into a shorter, more orchestrated event window. ### How it works * The FinTech sets a migration date and customer communications timeline * Users are notified on a structured cadence * New accounts are created in advance or close to cutover, depending on design * Funds transfer is coordinated as part of the cutover window * Old accounts are frozen and then closed on or near the target date ### Why FinTechs choose it * Faster exit from the old bank * More predictable internal staffing and project management ### Tradeoffs * Greater operational concentration risk * More pressure on communications and support readiness * Higher sensitivity to failures in transfers, card issuance, or verification flows * Less forgiving if users delay action ### Best-fit use cases * Smaller or less complex customer populations * Programs with simpler product sets and fewer dependent systems * FinTechs with strong operations capacity and direct customer communication channels ## 3) Wind-down path for non-migrating or inactive users This is not just a fallback. It is a necessary lane in almost every migration. ### How it works * Users who do not accept the new terms, are not selected for migration, or do not complete the process are offboarded from the legacy bank * The FinTech encourages those users to move funds out themselves where possible * Residual balances are returned using the legacy bank's approved closure process, which often includes mailed checks and may, in some circumstances, permit return to an external account * Accounts are closed and the FinTech maintains communications until the wind-down is complete ### Why FinTechs need this lane * Not every customer will respond on time * Some customers will not be eligible or desirable to migrate * Some users will have zero engagement and still require compliant closure treatment * The FinTech needs a clean end state at the old bank ### Best-fit use cases * Dormant populations * Users who reject the new account agreement * Users with balances that must be returned but not migrated * Customers in unsupported geographies or product configurations ## Recommended migration sequence on Synctera Regardless of model, the practical sequence is usually: ### 1. Program design and bank readiness * Finalize sponsor bank selection * Confirm product scope and any gaps relative to the old bank * Confirm KYC/KYB reliance posture * Confirm closure, funds-return, and residual-case procedures ### 2. New tenant configuration * Create the new tenant * Stand up account templates, spend controls, card products, webhooks, and required integrations * Establish new API access and environment readiness * Validate reporting and support workflows ### 3. Customer communication and consent design * Draft customer notices and disclosure flows * Define who is eligible for migration and in what sequence * Build reminders, deadline messaging, and support scripts * Decide what incentive or framing will encourage users to complete the move ### 4. New-customer and new-account creation * Recreate customers on the new tenant * Recreate business records and relationship structures where applicable * Record new disclosures and verification outcomes * Create new accounts  * Create migration mappings linking old and new records ### 5. Money movement and payment continuity * Support self-service or orchestrated balance transfer * Rebuild scheduled activity as needed * Provide a path to update routing and account numbers at employers, billers, and counterparties ### 6. Card transition * Issue virtual cards early where helpful to preserve continuity * Reissue physical cards with a confirmed shipping address * Guide users through digital wallet and card-on-file updates where needed ### 7. Freeze, closure, and old-bank wind-down * Set cutoffs for outgoing activity on the legacy account * Freeze accounts according to the migration runbook * Move residual funds under the approved method * Close legacy accounts * Preserve access to statements, support history, and unresolved cases for the required period ## Technical architecture considerations A Synctera migration is ultimately a data, controls, and orchestration problem. The most important technical considerations are below.
### Record recreation versus linking Synctera's migration framework assumes that the new customer and account are created on the new tenant, and then linked to the old tenant records using migration mappings. Those mappings provide continuity for operations and support, and can also support downstream processes such as preserving credit reporting continuity.
The important consequence is that FinTechs should plan for both data recreation and record-linking logic in their own systems. ### Customer and relationship recreation The FinTech should plan to recreate:
* Personal or business customer records * Ownership and beneficial-owner relationships * Account relationships * Required disclosures and acknowledgements
If the FinTech's application has internal customer IDs, those should remain the primary key for stitching the old-bank and new-bank records together in the app. ### Account templates and controls The new tenant needs the correct account templates, controls, and linked configurations before customer accounts are created. If a FinTech uses spend controls, partner configs, statement settings, or custom product logic, those should be validated before migration waves begin. ### External accounts and external cards External account migration may take different forms depending on how the old connection was established:
* Manually linked external accounts may be recreated more directly * Plaid-linked accounts may require relinking unless an approved migration path is available * External cards may need a separate strategy depending on network, token, and processor constraints
This is one of the areas where early technical discovery matters most. ### Scheduled activity and webhooks Scheduled transfers, recurring activity, webhook subscriptions, and downstream event consumers should all be reviewed. A common mistake is to focus on customer and account objects while overlooking the automation fabric around them. ### Search, support, and observability Support teams should be able to search by both old and new identifiers where possible. During a dual-bank period, customer support and operations will need visibility into migration state, linked records, incomplete transitions, and exception queues. ### Reporting and migration telemetry Useful migration reporting often includes:
* Customers invited * Customers who accepted the new agreement * Customers created on the new tenant * Accounts opened on the new tenant * Balances transferred * Cards issued and activated * Legacy accounts frozen * Legacy accounts closed * Exceptions opened and resolved * Customers who never completed migration ## Funds movement design choices Funds movement is usually the hardest operational step because it sits at the intersection of customer consent, rail limitations, cutover timing, and reconciliation. ### Common options * Customer-initiated ACH transfer from old to new account * Coordinated ACH transfer after customer authorization * Wire transfer for larger balances or time-sensitive cutovers * Prefunded migration model, where the FinTech or program prefunds transfers on the new-bank side and settles separately with the old-bank side ### Key considerations * Daily transfer limits and whether temporary limit increases are needed * Whether customer consent covers automated debiting of the legacy account * Whether there are pending transactions, holds, disputes, or interest accruals that make same-day final balance movement difficult * Whether the migration should occur in a single balance transfer or multiple tranches
In many migrations, the cleanest customer experience is not necessarily the simplest treasury or reconciliation design. Those choices should be made explicitly. ## Cards and payments continuity The FinTech should plan for:
* Immediate availability of a virtual card where supported * Updated mailing-address confirmation before physical-card issuance * Wallet-update instructions if tokenized cards do not automatically carry over * Merchant card-on-file continuity where card updater capabilities are available
The customer-facing copy should tell users exactly what will and will not continue automatically. ## UI and UX recommendations Migration success depends heavily on the FinTech's customer experience design.
### Design the migration as a guided journey, not a notice High-performing migrations usually frame the move as a controlled upgrade with clear customer actions rather than a confusing compliance event. ### Recommended UX patterns * A dedicated migration hub in the app that explains what is changing, by when, and what the user needs to do * A clear progress indicator, such as Agree, Open, Fund, Update, Confirm * Side-by-side explanation of old account versus new account state during overlap * Prominent deadline messaging with reminders tied to the migration stage * One-click entry points to accept disclosures, move funds, issue or activate a card, and confirm updated profile data * Inline education for fields that commonly cause KYC failures if re-verification is required * Clear handling for opt-out customers, including how funds will be returned and when accounts will close ### UI content users usually need * The name of the new bank * What is changing and what is not changing * Changes in routing and account numbers will change * Changes in cards * Whether subscriptions, digital wallets, and linked merchants need updates * What happens if the user does nothing * Where historic statements and legacy activity will remain accessible ### UX suggestions specific to dual-bank periods If the FinTech keeps both old and new accounts active temporarily, the app should make that visible. Customers should not be left guessing which account is the live spending account, which account should receive payroll or ACH credits, or why balances appear in two places. ## Old-bank wind-down and closure design This is often under-designed, but it is where compliance and customer experience issues accumulate.
### What wind-down should cover * Final notices and reminders * Freeze timing and customer restrictions during closure * Residual funds return method * Handling of negative balances, unpaid fees, and setoffs * Ongoing disputes, chargebacks, and recalls * Access to statements and historical transaction records * Escheatment handling where checks go uncashed * Clear ownership between the FinTech, old bank, and Synctera for post-closure issues ### Non-migrators need a full process, not just a closure flag A compliant wind-down path should specify:
* When the customer stops being able to transact * When funds will be returned * Whether the return method is check, external account, or another approved method * What address or destination is used * How the FinTech handles customers who contact support after closure ### Statements, history, and support continuity Even when balances are moved and old accounts close, customer support often still needs access to historic statements, legacy transactions, and prior case context. The FinTech should define what remains accessible in the app and what must be requested through support. ## Risks and mitigation checklist ### Legal and compliance * Confirm whether a reliance agreement is available * Confirm new disclosure requirements * Confirm customer-consent language for funds movement and closure * Confirm residual-funds return procedures ### Operations * Define exception queues and ownership * Train support teams on old/new account lookup * Prepare dispute and recall handling after cutover * Create daily migration reporting ### Product and UX * Build a dedicated migration experience * Keep messaging consistent across email, push, in-app, and support * Make the consequences of inaction explicit * Give users confidence that the move is controlled and legitimate ### Engineering * Recreate required resources on the new tenant * Maintain robust old-to-new mapping in internal systems * Validate webhooks and downstream dependencies ### Treasury and reconciliation * Pre-approve funds movement methods * Confirm prefunding expectations if using an instant or near-instant transfer model ## A practical point of view on successful migrations The most successful bank migrations are not the ones with the fewest technical tasks. They are the ones that reduce end-user confusion while keeping control of timing, money movement, and exception handling.
From a Synctera perspective, the strongest migrations usually share these characteristics:
* The new tenant is treated as a fully prepared launch environment * Customer communications are staged and specific * The FinTech chooses a migration model deliberately rather than defaulting into one * Record linking and operational visibility are built early * Wind-down at the old bank is designed as carefully as onboarding at the new bank ## Suggested next-step workstreams for a FinTech planning a migration Discuss and align with your Implementation Specialist on how you plan to migrate customers. We are here to make the process as painless as possible!