- A KYC provider migration is never just an API swap. Data mapping, decision logic, fallback routing, and audit trail continuity each need dedicated owners before you cut traffic.
- Approval rate drops during migration almost always trace back to two causes: decision threshold mismatches between vendors and untested edge cases in your new waterfall.
- Running both providers in parallel for a defined shadow period is the single highest-impact risk control available. Skipping it to ship faster is how teams create compliance gaps they find three months later.
- Your compliance team, product team, and engineering team need separate sign-off gates. One owner for the whole project is a recipe for missed controls.
- Post-launch, track auto-approval rate, manual review queue volume, false positive rate, and average verification time side-by-side against your pre-migration baseline for at least 30 days.
Knowing how to switch KYC providers without breaking compliance or approval rates comes down to one discipline: map your existing decision logic and data fields to the new vendor before writing a line of integration code. From there, run both systems in parallel during a shadow period to compare approval outcomes, define rollback criteria in advance, and assign explicit ownership across compliance, product, and engineering. Done in four phases over six to ten weeks, a migration can preserve or improve approval rates while maintaining a complete audit trail.
Why KYC Migrations Fail Before the Integration Even Starts
Most teams that attempt a KYC vendor migration frame it as a technical project. That framing causes the most common failure mode: the integration works, but approval rates drop two to four weeks after go-live because the new vendor’s default risk thresholds are not equivalent to what the old vendor was actually doing.
Every KYC provider has tunable risk parameters. Your existing vendor accumulated months or years of tuning that your team may have documented poorly, or not at all. When you migrate, you are not porting an API. You are porting a set of decisions. If you do not extract and explicitly re-implement those decisions, the new vendor runs on defaults that were designed for a generic customer, not yours.
The second common failure is control coverage. Providers differ on which checks they run natively versus which they expect you to orchestrate externally. Watchlist screening, document authenticity checks, liveness detection, and database verification can all live in different places depending on whether you use Jumio, Persona, Sumsub, Onfido, or Alloy as an orchestration layer. A gap in coverage is a compliance gap, and it may not surface in testing if your test cases do not include the specific document types or geographies where that check matters.
What Is the FintechSpecs KYC Migration Stack Audit?
Before any vendor is contacted for a migration kickoff call, run what we call the FintechSpecs KYC Migration Stack Audit: a four-part inventory of what your current setup actually does, not what you think it does. The four components are Decision Logic, Data Fields, Control Coverage, and Failure Behavior. This taxonomy draws on the same categories that come up repeatedly in post-incident reviews and compliance audits , it is a practical checklist, not a proprietary discovery, and its value is in making sure nothing obvious gets skipped.
Decision Logic
Pull every rule your current vendor applies: which document types are accepted, what confidence thresholds trigger auto-approve versus manual review versus decline, and what overrides your ops team has applied over time. If your vendor provides a rules console, export it. If not, interview your compliance analyst who manages the queue.
Data Fields
List every data element your current vendor returns in its API response and map it to what your downstream systems consume. Candidate fields to audit include: verification status, confidence score, document type detected, match result for each field, extracted versus submitted name, date of birth, address, document number, expiry, and any risk signals the vendor surfaces. New vendors frequently use different field names, nested structures, or enumerated values for the same underlying data.
Control Coverage
Document which regulatory controls are satisfied by the vendor natively versus controls you have built yourself. Common examples of self-built controls: watchlist screening against OFAC using a separate API, PEP checks via a third-party database, or IP geolocation checks run in your own middleware. These controls will not automatically transfer to the new vendor, and their absence will not surface in a basic integration test.
Failure Behavior
Map every way the current integration can fail and what your system does in each case. Timeout behavior, partial response handling, error code interpretation, and what happens to a user’s session when the KYC call fails are all decisions that were made at some point and may only live in code comments. Failure behavior that is acceptable on your current vendor may have different latency characteristics on the new one.
How to Switch KYC Providers: Four-Phase Migration Structure
A KYC vendor migration that attempts to go from contract-signed to full cutover in under three weeks almost always requires a rollback. The phases below are designed for a 6-to-10-week window, which is realistic for a team with one dedicated engineer and a compliance lead who can commit 30 percent of their time.
Phase 1: Audit and Contract (Weeks 1-2)
Complete the Stack Audit above. Negotiate the vendor contract with specific SLA terms for uptime, response time, and support escalation. Confirm data processing agreements, sub-processor disclosures, and data residency commitments in writing before any user data is sent to the new vendor’s environment. Teams that skip the DPA before testing often discover a legal blocker after they have already built the integration.
Assign three owners explicitly: a Compliance Owner who signs off on control coverage and threshold configuration, an Engineering Owner who owns the integration and rollback plan, and an Operations Owner who manages the manual review queue configuration and team training. No single owner can hold all three roles on a live production migration without something being deprioritized under pressure.
Phase 2: Integration and Shadow Mode (Weeks 3-5)
Build the integration against the new vendor’s sandbox. Map every inbound and outbound field from the Stack Audit. Implement the new vendor’s decision logic to replicate your current thresholds, not their defaults. Then deploy both integrations to production simultaneously in shadow mode: every real verification is sent to both vendors, but only the existing vendor’s response drives any user-facing decision.
Shadow mode is not optional on a regulated KYC workflow. It is the only way to surface discrepancy patterns at production volume without affecting users. Run shadow mode for a minimum of 500 verifications or one full week, whichever comes first. If your volume is low enough that 500 verifications would take more than three weeks, extend Phase 2 accordingly and use synthetic test cases to fill the gap.
During shadow mode, log every case where the two vendors produce different outcomes. Categorize by document type, geography, and outcome type. A discrepancy rate above five percent warrants investigation before proceeding. Common causes include different OCR handling for non-standard document formats, different thresholds for name matching on accented characters, and different liveness detection pass rates by camera type.
Phase 3: Staged Rollout with Rollback Gates (Weeks 6-8)
Move traffic to the new vendor in tranches: 5 percent, then 20 percent, then 50 percent, then 100 percent. Each tranche requires a 48-hour observation window before advancing. Define the rollback gate before you start: if auto-approval rate drops more than three percentage points versus your shadow baseline, or if manual review queue volume increases by more than 25 percent, the Engineering Owner has authority to revert to the previous tranche without a committee decision. Pre-defining this threshold removes the political friction that causes teams to hold on too long.
Compliance and fraud considerations during staged rollout deserve specific attention. If your AML program requires consistent treatment across similarly situated customers, running two different KYC providers simultaneously on production traffic may require a note in your BSA/AML program documentation. Check with your compliance counsel before splitting traffic, particularly if you are subject to FinCEN program rules or a bank sponsor’s oversight requirements.
Phase 4: Full Cutover and Decommission (Weeks 9-10)
At 100 percent traffic on the new vendor, maintain the old vendor’s integration in a dormant state for at least 30 days before decommissioning it. This preserves your rollback option during the post-launch monitoring period. Coordinate the contract termination timeline with your legal team. Many KYC contracts auto-renew on 30- to 90-day notice windows, so the decommission date and notice-of-termination date are separate decisions.
What Data and Controls Must Transfer Before Go-Live?
The checklist below covers the items most frequently missed in migrations. Engineering items are the ones teams focus on. Compliance and operational items are where gaps actually emerge during audits.
| Category | Item | Owner | Common Miss |
|---|---|---|---|
| Data | Field mapping: all input and output fields documented and mapped | Engineering | Nested response structure differs from current vendor |
| Data | Historical verification records preserved or exported | Compliance | Existing records not exportable after contract ends |
| Data | Audit trail continuity: who verified whom and when, with what result | Compliance | New vendor uses different record identifiers; gap in linkage |
| Controls | Watchlist screening (OFAC, PEP, adverse media) confirmed active | Compliance | Assumed covered natively; actually requires separate configuration |
| Controls | Document authenticity and liveness detection thresholds set | Compliance + Engineering | New vendor defaults are more permissive than prior setup |
| Controls | Re-verification rules (e.g. on document expiry or address change) configured | Compliance | Not in scope for initial migration; discovered at next audit |
| Operations | Manual review queue configured and ops team trained | Operations | New vendor’s review UI differs enough to slow queue processing |
| Operations | Escalation paths and SLA targets set for edge cases | Operations | No internal owner defined for vendor escalation during first 30 days |
| Legal | Data processing agreement executed before any user data is shared | Legal | Testing starts before DPA is signed |
| Legal | Sub-processor and data residency requirements confirmed | Legal | Vendor uses sub-processors in jurisdictions not covered by privacy policy |
| Engineering | Timeout and error handling behavior tested and documented | Engineering | New vendor has different timeout window; session behavior breaks |
| Engineering | Rollback deployment scripted and tested in staging | Engineering | Rollback exists only as a plan; has never been executed |
The historical records item deserves emphasis. Once a KYC contract expires, access to the verification records your old vendor holds may be terminated or restricted. Export every verification record, document image (where permitted by your data retention policy), and decision log before the contract ends. Some providers will assist with a data export; others will not. Confirm this in writing during contract negotiation, not during offboarding.
How to Configure KYC Fallback Routing to Protect Approval Rates
KYC fallback routing means directing a verification request to a secondary provider when the primary provider returns an error, timeout, or inconclusive result. It is the most underbuilt safety mechanism in most KYC stacks, and it is worth thinking through before you migrate rather than after.
Fallback routing is distinct from switching providers. In a single-vendor setup, a timeout or API outage produces either a hard failure for the user or a deferred verification that creates queue backlog. In a multi-vendor setup with fallback routing, the same event routes the user to a second provider with no visible impact on the onboarding flow. Platforms that handle high verification volumes, or that serve geographies where document scanning is less reliable, often run a primary and secondary provider permanently rather than treating the secondary as a migration artifact.
The implementation mechanics are straightforward: define trigger conditions (timeout above X milliseconds, specific error codes, confidence score below threshold), route to the secondary provider, and log both the trigger event and the secondary result. The compliance consideration is that your secondary provider must meet the same control standards as your primary. Running OFAC screening on primary-provider verifications and not on fallback-routed verifications is a control gap. Alloy and Persona both support multi-vendor orchestration natively, which simplifies fallback configuration for teams that want it managed at the orchestration layer rather than in application code.
If you are evaluating whether to build fallback routing into your migration architecture, the KYC provider comparison on FintechSpecs covers which vendors support orchestration natively versus which require you to build it yourself.
Which Test Cases Must Pass Before You Move Traffic?
Test suites for KYC integrations are almost always too short. Most teams test the happy path (valid document, matching selfie, passing liveness) and one or two error states. The cases below are the ones that reveal real discrepancies between vendors and that surface compliance gaps before users encounter them.
Document Coverage Tests
Test every document type your users submit, not just the most common one. Passports, state-issued driver’s licenses (including less common US state formats), permanent resident cards, and any international documents relevant to your user geography each have different extraction reliability profiles across vendors. If your user base includes a significant share of users from countries where your current vendor had optimized OCR, verify that the new vendor performs equivalently on the same document samples.
Edge Case Identity Tests
Test names with accented or non-Latin characters. Test names with common mismatch patterns (hyphenated surnames, middle names used as first names, legal versus preferred name differences). Test documents where the date of birth field is formatted in a non-US convention. These cases are where OCR and match logic differences between vendors surface most visibly.
Failure Mode Tests
Simulate a vendor timeout. Confirm the user session does not corrupt and that the fallback behavior is what you intended. Simulate a partial API response. Confirm your application handles it without surfacing a raw error to the user or silently auto-approving. Simulate an expired document. Confirm the decline result is correctly logged and the user receives the right prompt.
Watchlist and Controls Tests
Submit a test identity that should trigger a watchlist hit and confirm the result is correctly classified as a manual review case, not an auto-approve. Confirm the watchlist hit is logged in the audit trail. If your compliance program requires adverse media screening or enhanced due diligence for specific customer types, test those paths explicitly.
Rollback Test
Execute the rollback procedure in staging before go-live. Confirm that reverting to the old vendor routes traffic correctly, that no session data is lost, and that the old vendor’s integration is still functional after the shadow period. A rollback plan that has never been tested is not a rollback plan.
What Owner Matrix Should Drive This Migration?
KYC migrations stall most often not because of technical complexity but because of ownership ambiguity. When something breaks, the question “whose problem is this?” should have a single-name answer. The matrix below is a starting point; adjust titles to match your org structure.
| Decision or Task | Owner | Approver | Consulted |
|---|---|---|---|
| Vendor selection and contract terms | Head of Compliance | CFO or CEO | Engineering Lead, Legal |
| Data processing agreement | Legal | Head of Compliance | Engineering Lead |
| Decision logic and threshold configuration | Head of Compliance | Head of Compliance | Engineering Lead, Risk Analyst |
| API integration and field mapping | Engineering Lead | Head of Engineering | Head of Compliance |
| Shadow mode analysis and discrepancy review | Risk Analyst | Head of Compliance | Engineering Lead |
| Staged rollout traffic decisions | Engineering Lead | Head of Compliance | Head of Product |
| Rollback trigger decision | Engineering Lead | Pre-authorized (no committee) | Head of Compliance notified |
| Manual review queue configuration | Operations Lead | Head of Compliance | Engineering Lead |
| Post-launch metric monitoring (30-day) | Risk Analyst | Head of Compliance | Engineering Lead |
| Old vendor contract termination | Head of Compliance | CFO | Legal |
The rollback trigger decision deserves special attention in the owner matrix. Pre-authorizing a single technical owner to execute rollback without a committee decision is not a shortcut. It is risk management. In production incidents, the time cost of convening approvers while approval rates are declining is real. Define the threshold, assign the authority, and document it in your runbook before Phase 3 begins.
What Failure Scenarios Should You Plan For Before Cutover?
Planning for failure scenarios before migration differs from debugging after an incident. The goal here is to have a documented, tested response for each scenario before any user traffic is affected.
Scenario 1: New Vendor API Outage During Staged Rollout
Response plan: route all traffic to the old vendor immediately. Confirm the old vendor integration is still hot (not decommissioned). Alert the new vendor’s support channel per the escalation path in your contract. Do not advance to the next traffic tranche until the outage postmortem from the new vendor is reviewed by your Engineering Owner.
Scenario 2: Auto-Approval Rate Drops More Than 3 Points Post-Cutover
Response plan: freeze tranche advancement. Pull a sample of newly declined cases and compare them against shadow-mode logs. If the declines trace to a threshold misconfiguration, adjust and re-test before advancing. If they trace to a genuine capability difference (the new vendor is legitimately stricter on a document type), escalate to the Compliance Owner to decide whether the new behavior is correct or needs configuration adjustment.
Scenario 3: Manual Review Queue Overflows
Response plan: first check whether the overflow is caused by a classification error sending auto-approve cases to review rather than genuine edge cases. If it is a classification error, fix the threshold. If it is a genuine volume increase, add temporary review capacity and investigate whether the new vendor’s uncertain-case rate is higher than expected. An elevated uncertain rate on a specific document type often means the vendor has not seen enough training data for that document format.
Scenario 4: Compliance Audit Surfaces a Gap During Migration Window
Response plan: document which verifications were processed by which vendor and when. Confirm the audit trail is complete for both systems for the period in question. If a control was temporarily uncovered during the migration window, document the gap, the cause, and the remediation in your compliance program records. Self-disclosure with documented remediation is generally treated more favorably by examiners than a discovered gap with no paper trail.
If your compliance program documentation is not already migration-ready, the Fintech Product and Compliance Readiness Checklist is a useful reference for what documentation your program should have before you introduce a new vendor.
What Post-Launch Metrics Indicate a Successful Migration?
A migration is not complete at 100 percent traffic cutover. It is complete when you have 30 days of post-launch data confirming that the new vendor is performing at or above baseline across the metrics that matter for both your business and your compliance program.
| Metric | Definition | Watch For | Measurement Window |
|---|---|---|---|
| Auto-approval rate | Percentage of verifications that pass without manual review | Drop vs. 30-day pre-migration baseline | Daily for first 30 days |
| Manual review queue volume | Absolute count of verifications entering review | Increase disproportionate to volume growth | Daily for first 30 days |
| False positive rate | Rate at which legitimate users are incorrectly declined or flagged | Increase vs. baseline | Weekly, requires ops team sampling |
| Average verification time | Median time from verification request to final decision | Increase vs. baseline (UX and ops impact) | Daily for first 30 days |
| Decline rate by document type | Decline breakdown segmented by document category | Unexpected concentration in a specific document type | Weekly for first 60 days |
| Watchlist hit rate | Rate of verifications triggering watchlist review | Significant drop may indicate a controls configuration gap | Weekly for first 30 days |
| API error rate | Rate of failed API calls (timeouts, 5xx errors) | Elevated vs. vendor’s stated SLA | Continuous; alert on threshold breach |
| Vendor response latency (p95) | 95th percentile API response time | Sustained elevation affecting onboarding completion | Continuous; alert on threshold breach |
The watchlist hit rate metric is the one most teams do not track during migration. A drop in watchlist hits is not necessarily good news. It may mean a controls gap: either the new vendor is not running the same screenings, or it is running them against a different list. Confirm with your Compliance Owner what an expected hit rate range looks like for your user population and treat a significant deviation in either direction as a signal to investigate.
For teams building out broader post-launch compliance monitoring, fintech metrics that actually matter beyond vanity growth covers the operational and compliance indicators worth tracking at the program level, beyond the KYC-specific view above.
How Do Vendor-Specific Implementation Details Affect Migration Risk?
The migration approach above applies regardless of which vendor you are moving to. But the implementation details do vary by platform, and understanding those differences before you start the integration reduces surprises.
Persona and Alloy both offer multi-step flow builders where the verification logic lives in a visual workflow editor rather than directly in application code. Migrating to either from a code-first integration means the decision logic transfer moves into their respective consoles rather than a configuration file. This is generally easier to iterate on but requires your Compliance Owner to be comfortable reviewing and approving configurations in a vendor UI rather than reviewing a pull request.
Onfido and Jumio are more document-verification-centric and have historically been deployed as point solutions within a broader identity stack. If your current setup uses either of these with separate AML screening and watchlist tools, the migration is effectively a data field mapping exercise plus confirming that your external controls still fire on the new verification payload structure.
Sumsub markets its migration support explicitly and offers data migration assistance as part of its onboarding process. That can reduce the audit trail continuity risk described above, but the details of what is exported and in what format should still be confirmed in the contract rather than assumed from marketing materials.
Whichever vendor you land on, the compliance and operational structure of your onboarding flow shapes how much of the migration effort sits in the vendor’s tooling versus your own infrastructure. That tradeoff is worth understanding before you sign. The KYC cost-per-verification pricing breakdown covers the pricing structures across major vendors, which is relevant when evaluating the total cost of a migration plus ongoing fees under the new contract.
Frequently Asked Questions
How long does a KYC provider migration take?
A realistic timeline for a mid-volume fintech with one dedicated engineer is six to ten weeks, broken into four phases: audit and contract (weeks one to two), integration and shadow mode (weeks three to five), staged rollout (weeks six to eight), and full cutover and decommission (weeks nine to ten). Teams that try to compress this to under three weeks almost always face a rollback or a compliance gap discovered after the fact. Lower verification volume can extend the shadow mode phase if you need 500 real verifications to generate meaningful comparison data.
Will approval rates drop during KYC vendor migration?
They can, and the cause is almost always one of two things: the new vendor’s default risk thresholds are more conservative than what your previous setup was actually doing, or edge cases in specific document types or geographies perform differently on the new vendor’s model. Both are preventable if you complete a decision logic audit before integration and run shadow mode long enough to surface discrepancies. A drop above three percentage points versus your shadow-mode baseline is a signal to pause and investigate before advancing the rollout.
How do you maintain a KYC audit trail during migration?
Export all historical verification records from your current vendor before the contract ends, as access may be restricted after termination. During the migration window, log which vendor processed each verification and when. Maintain a record linkage between old vendor identifiers and any new identifiers assigned by the new vendor. If you run both vendors in shadow mode simultaneously, log both results even though only one drives a user-facing decision. Confirm with your compliance counsel whether your BSA/AML program documentation requires a note about the vendor change.
What is KYC fallback routing and when do you need it?
KYC fallback routing directs a verification request to a secondary provider when the primary returns a timeout, error, or inconclusive result. You need it if your verification volume is high enough that a single-vendor outage would materially affect onboarding throughput, or if you serve geographies where one vendor has materially better document coverage than others. The compliance requirement for fallback routing is that the secondary provider must run the same controls as the primary. A fallback that routes around watchlist screening is a compliance gap.
Do you need to notify your compliance program or regulator when switching KYC vendors?
For most early-stage fintechs operating under a bank sponsor program, the sponsor bank likely requires notification before switching KYC vendors, and may require pre-approval. This is a common requirement in banking-as-a-service program agreements. For companies that hold their own licenses, the specific requirement depends on your license type and state. At minimum, the vendor change should be documented in your BSA/AML program as a material change to your CIP procedures. Check your program documentation and sponsor agreement before starting Phase 1.
Can you switch KYC providers without downtime?
Yes, with a shadow mode deployment running both providers in parallel before you move any user-facing traffic. During the shadow period, your users see no change because the old provider still drives all decisions. Traffic moves to the new provider only after shadow mode confirms equivalent outcomes, and only in staged tranches with rollback gates. The only period of meaningful risk is the staged rollout itself, and pre-defined rollback thresholds with pre-authorized engineering authority to execute them limit exposure there.
What should you check in a KYC vendor contract before migration?
Five things specifically: data export rights (can you get your records back before termination, and in what format), data processing agreement and sub-processor list, uptime SLA and the remedy for missing it, notice period for contract termination (usually 30 to 90 days, which affects your decommission timeline), and what happens to your data after contract end. Compliance programs that run under bank sponsor oversight should also confirm whether the sponsor bank needs to approve the new vendor before the contract is signed.
How to Decide You Are Ready to Decommission the Old Vendor
After 30 days of post-launch metrics at or above baseline, three criteria should be true before you initiate the old vendor’s decommission: your audit trail is complete and linkable for all historical verifications, your ops team is trained and processing the new vendor’s review queue without elevated error rates, and your rollback deployment has been formally retired from the runbook because the new vendor’s track record no longer warrants the fallback option. Decommissioning without all three is premature.
The decision to terminate the old contract is also the right moment to document the migration in your compliance program records. Note the vendor change, the date of full cutover, the control equivalency review you conducted, and any open items from the shadow mode discrepancy analysis. Auditors who find a vendor change in your transaction records without corresponding program documentation will ask questions that take longer to answer than the documentation takes to write.
A KYC migration done well looks invisible from the outside. Users experience the same or faster onboarding. Your compliance program has a cleaner record of the change than it had before. Your engineering team has a tested rollback procedure and a fallback routing architecture that reduces exposure to single-vendor risk going forward. That outcome is achievable in six to ten weeks with the right ownership structure and a methodical phase plan. What prevents it is not complexity but the persistent belief that “API project” and “compliance project” are the same thing. They are not, and treating them as one is where most migrations go wrong.
