Worried a KYC switch will cost you customers? Here’s how to protect the move.

You have found a KYC provider that looks better for your business. Then someone asks the question that stops the project: will every existing customer have to upload an ID and take a selfie again?

That question needs an evidence review before it gets a yes or no. Some records may remain suitable under your obligations and policy. Others may be incomplete, outdated or impossible to retrieve. Treating everyone the same can create unnecessary friction or carry an old weakness into the new system.

The move is ready when your team knows what it can preserve, what it must refresh and how to reverse the cutover if something breaks.

Separate the vendor change from the customer decision

Switching the service that performs future checks does not, by itself, explain what evidence each existing customer needs next. Have your compliance owner determine that for your jurisdictions, products and customer risks.

Do not treat a previous provider's “approved” label as portable proof. You need to understand the checks behind it and whether the underlying record remains accessible and sufficient.

FATF's digital identity guidance (opens in a new tab) discusses the suitability of digital identity for due diligence and distinguishes third-party reliance from outsourced services. Where reliance is permitted, responsibility does not simply move to the third party. A technology migration is not blanket permission to accept every historic result.

Build an evidence map before moving traffic

For a representative sample of customers, establish what you actually hold: - Your stable customer identifier and the old provider's identifiers. - The evidence checked, when it was checked and the source. - The scope of the checks, results, review notes and final decision. - Expiry dates, outstanding gaps and the next review trigger. - Where the original record lives and who can retrieve it.

Then assign each record a documented route: retain the existing evidence with an approved mapping, refresh a specific gap, or complete a new verification.

For example, an illustrative customer may have a retrievable identity record but an expired address document. That calls for a decision about address evidence, not an automatic demand to repeat every step. Another customer may have only a pass flag with no supporting record. That is a different problem.

Map meanings, not just status names

“Verified” can mean different things across providers. One result may reflect a document check. Another may include a government record and face comparison. A manual approval may have an exception attached.

Create a mapping for the evidence and outcomes your business uses. Include inconclusive, unsupported document, provider error, pending review and expired evidence. An unavailable service must not silently become an approval.

Test those states against the actions your application takes. Can a customer transact while a review is pending? Does an old webhook overwrite a newer decision? Can a callback from the former provider change an account after the cutover?

These are migration questions even when both SDKs look fine.

Run a small cutover you can reverse

Start in a test environment with the countries, ID types, devices and failure cases you expect. Compare decisions where you have a lawful basis to use the test data. Use a limited production cohort only after agreeing the acceptance criteria.

Route each customer journey deliberately. Avoid sending duplicate customer prompts from two providers. If you run checks in parallel, document the purpose, extra cost and data handling before doing so.

Give one owner authority to stop the rollout. Agree which changes in completion, errors, latency, reviews or decision quality should trigger a pause. Prepare the routing change that returns new journeys to the previous path, while preserving the work already completed.

Do not end access to the old provider until the required records are retrievable and your exit obligations are resolved.

Tell customers exactly what they need to do

Where a fresh check is necessary, explain what you need, why you need it and what happens to access. Ask for the missing evidence through a recognisable, secure journey.

Where no action is necessary, avoid creating a verification task simply to announce a vendor change. Apply any separate privacy notice or communication requirements your review identifies.

Our perpetual KYC guide covers ongoing refresh triggers after migration. Keep those triggers separate from the cutover plan.

Planning a move to Toden

Toden Workflows supports configurable checks and versioned decision rules. Use a proposed workflow to test new journeys against your current requirements.

Before committing to a migration, ask us to review your evidence formats, customer identifiers and required checks. Do not assume historic decisions, biometric templates or provider records can be imported unchanged. Compatibility and evidence acceptance need confirmation.

Talk to Toden with a sample record structure and your busiest customer journey. That gives the migration discussion a concrete starting point.