Treat the migration as a controls and records transition. Operators should preserve prior decision logic, case notes, supporting evidence, and retention obligations so the new provider does not break continuity or make historical verification decisions impossible to defend.
What actually has to travel with the IDV switch?
The key is to move more than the vendor account and API connection. A defensible migration carries forward the decision trail: what was checked, what evidence supported the decision, who approved it, when it was made, and how long it must be retained. Without that, the new provider may authenticate future users, but it will not preserve the historical record behind past KYC outcomes.
That record set usually includes identity documents, liveness or biometric verification results, risk scores, case notes, exception handling, screening outcomes, and the version of the policy or workflow used at the time. The goal is continuity of controls and evidence, not a simple data export. If you cannot explain an old decision after the switch, the migration was incomplete even if onboarding continues to work.
For teams formalising the handover, the transition should be treated as identity proofing and KYC continuity, not just a software replacement. The practical question is whether the receiving platform can preserve the same assurance context, including the artifacts needed to justify prior verification outcomes.
How do you keep evidence usable after the vendor change?
Start by defining the minimum evidence package before cutover. That package should cover each customer record’s retained artifacts, the metadata needed to interpret them, and the retention or deletion rules that apply by jurisdiction, product, and customer type. If the source vendor stores evidence in a proprietary format, plan the export and rehydration path early enough to test it before the contract ends.
Good migrations also keep provenance intact. Operators should be able to show which vendor produced which evidence, which workflow version was used, and whether the evidence was generated during initial onboarding, a refresh event, or a remediation review. A clean export without lineage is risky because it makes the file technically present but operationally hard to trust.
This is also where vendor evaluation matters. A switching decision should be informed by whether the replacement platform can retain evidence, export case history cleanly, and support downstream audit use without forcing teams to reconstruct records manually. For that reason, many teams use an identity verification buyer’s guide during selection to test portability, privacy handling, and evidentiary continuity before renewal or exit becomes urgent.
Retention is not only a storage issue. If the old provider kept evidence under one schedule and the new provider applies a different one, you need a reconciliation decision for records already in flight. Otherwise you can end up deleting material too early, or keeping it longer than policy allows.
What breaks most often during KYC vendor migration?
The common failure is loss of interpretability, not loss of raw files. Teams export images, logs, or scores, but omit the context needed to defend the decision later. Another common break is inconsistent retention, where some artifacts move to the new system while others remain trapped in the old one or are deleted when the legacy contract expires.
Operationally, the hardest cases are exceptions and adverse decisions. Enhanced due diligence notes, manual overrides, failed verification attempts, and review outcomes often matter more than the initial pass or fail result. If those are missing, the institution may still know that an onboarding event happened, but it may not be able to explain why a specific customer was accepted, rejected, or escalated.
Cross-border programmes should also watch for legal hold and retention conflict. A vendor switch can accidentally shorten retention windows if teams assume the new platform’s defaults override the old records’ obligations. The safest assumption is that the evidence must remain available for the longest applicable retention period tied to the original decision.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 and GDPR define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-11 — Audit Record Retention | KYC evidence migration depends on keeping historical records available for later review. |
| MP-6 — Media Sanitization | Legacy vendor exit requires controlled disposition of retained customer evidence and copies. | |
| Recommendation — Preserve audit and case records across the vendor change for the required retention period. Sanitize or return migrated data and media according to the approved retention and exit plan. | ||
| ISO/IEC 27001:2022 | A.5.33 — Protection of Records | KYC files and decision logs are records that must remain protected and retrievable after migration. |
| Recommendation — Protect records so migrated and historical KYC evidence stays authentic and accessible. | ||
| GDPR | Art. 5 — Principles relating to processing of personal data | KYC evidence migration must preserve retention limits, minimization, and integrity of personal data handling. |
| Art. 32 — Security of processing | Vendor transition must keep personal data evidence secure during transfer and storage changes. | |
| Recommendation — Map each evidence class to lawful retention, minimization, and integrity requirements before switching vendors. Verify transfer, access, and storage safeguards for all KYC evidence during the migration. | ||
Practitioner Guidance
What to verify: Before signing off the migration, verify that every retained KYC decision has a recoverable evidence chain, a readable decision timestamp, and a clear retention owner. If the new platform cannot reproduce the original context, treat that record set as not yet migrated.
Decision rule: If an artifact could be needed to defend onboarding, refresh, remediation, or investigation decisions, move it with lineage intact rather than relying on a summary field. If it cannot be justified later, it was not enough evidence to retire the old system.
What practitioners underestimate: The riskiest gap is usually not the absence of data, but the absence of explainability. A migration is successful only when audit, compliance, and operations can still answer the same historical questions after the vendor relationship ends.
Practitioner takeaway: Treat vendor switching as a records-preservation exercise with a technology component, not the other way around; continuity of KYC evidence is what preserves defensibility.
Related resources from NHI Mgmt Group
- How should operators design KYC for Mexico iGaming environments with regulatory uncertainty?
- How should operators balance KYC friction with conversion in regulated iGaming?
- How should security teams reduce SaaS access review overhead without losing audit evidence?
- How should organisations automate GDPR access reviews without losing audit evidence?