Switching a KYC or KYB Vendor Without Losing Your Audit History

Why teams switch

Four reasons drive most KYC and KYB vendor swaps:

Pricing. The vendor raises rates 20-40% at renewal. Growth-stage volume means a 30% increase is a real budget line. Some vendors front-load discounts in year one knowing renewal margins are where the unit economics work.
Coverage. The team expands into a geography or a vertical the incumbent does not handle well. Persona is strong in the US; Sumsub is stronger across EMEA. Middesk leads on US business verification; Trulioo and Baselayer push deeper internationally.
Performance. Pass-through rates degrade as the vendor tunes for false-positive control across its whole customer base. False positives become operational drag. The cheapest fix is sometimes to swap.
Compliance pressure. A sponsor bank or examiner asks the team to use a different vendor for specific risk areas. Sponsor banks sometimes prescribe a tool for their oversight; growth fintechs accommodate. Examiners less often, but it happens after a finding.

The engineering for the swap itself is well understood: integrate the new API, run parallel for a window, cut over, deprecate. Most teams plan for that part. The audit-history problem is the part most teams discover later, often during a sponsor-bank quarterly review that spans the cutover date.

What you lose if the history lives in the vendor

When the customer's verification history lives in the vendor's console, it lives there in the vendor's shape. The console knows the customer by the vendor's ID, not yours. The console knows the verification by the vendor's object model (Persona has “inquiries” and “reports”; Sumsub has “applicants” and “verification levels”; Middesk has “businesses” and “results”). After a vendor swap, the customer's history becomes three things:

The old vendor's history, in the old vendor's shape, accessible as long as the contract stays active.
The new vendor's history, in the new vendor's shape, starting from the cutover date.
A gap at the cutover that has to be reconciled if the same customer appears on both sides.

When the sponsor bank asks “what did you know about customer X on April 14, 2026,” the team that has the history in the vendors has to assemble across three sources, in two formats, with reconciliation logic that did not exist before the question came in. Teams that have hit this report that the first such request after a vendor swap takes 2-3 weeks to answer cleanly.

What you keep if the history lives on a record beneath

The fix is structural: put the audit history on the customer record, not in the vendor console. Then the vendor change is a signal-source swap, not an audit-history event. Specifically, the record below holds:

The customer's identity in your canonical shape (a Subject).
Every signal the vendor produced about that customer, normalized to a canonical signal type (a KYC pass, a KYB UBO confirmation, a sanctions clear, etc.), with the vendor named as the source.
The decision your rulebook or your analyst made on the signal, and the policy version that applied.
A hash chain (see tamper-evident audit trail) that proves continuity across the chain.

When the old vendor goes away and the new vendor takes over, the only thing that changes is the “source” field on new signals. The customer's history continues without a break. The sponsor-bank's query about April 14 returns one record with continuous signals from both vendors, in the shape the bank expects.

The five components of a vendor-portable audit history

Canonical Subject identity. Your customer ID is the anchor, not the vendor's. Each vendor knows the customer by the vendor's ID, but those IDs map back to one Subject on the record.
Canonical signal types. KYC, KYB, sanctions, document, ownership, fraud. Each vendor produces in its own object model; the record normalizes to one canonical shape so a KYC pass from Persona looks the same on the record as a KYC pass from Sumsub.
Source tagging on every signal. The canonical signal includes the vendor that produced it. An examiner can ask “show me only the Persona signals” or “show me only the post-Sumsub signals” and the query is a filter, not a different store.
Decision lineage. The decision your team made stays on the record with the signal it stood on. A KYC pass that drove an account-open decision is linked to that decision permanently, regardless of which vendor produced the pass.
Hash chain across the swap. The chain on the Subject record does not restart at the vendor change. Last event from the old vendor is hashed by the next event from the new vendor. The chain is unbroken.

A worked example: Persona to Sumsub

A growth-stage US-EU neobank decides to swap Persona for Sumsub in Q2. Volume is 18k onboardings per month, split 70/30 US/EU. The sponsor bank's next quarterly review is in Q3, after the swap.

T-90 days. Backfill historical Persona inquiries onto the Subject records. Pull the API; normalize each Persona inquiry to a canonical KYC signal with Persona named as source; hash into the per-Subject chain.
T-30 days. Start running Sumsub in parallel on new onboardings. Sumsub signals land on Subject records alongside Persona signals during the overlap. The rulebook decides which is authoritative per geography (Persona for US, Sumsub for EU during the overlap; both for ambiguous geos).
T-0 (cutover). All new onboardings route to Sumsub. Persona's API stays connected for read-only retrieval of historical inquiries on pre-cutover customers.
T+90 days (the Q3 sponsor-bank review). The bank asks for the verification history of 30 specific customers, half from before the cutover, half from after. The team answers with one query per customer; each returns one record with signals from both vendors in canonical shape and an unbroken hash chain. The review takes 2 days instead of 2 weeks.
T+180 days. Persona contract terminates. The historical Persona signals are already on the record, so the contract going away does not affect the audit history.

A checklist for a vendor swap that preserves the audit history

Decide where the audit history lives before you swap. Adding it during the swap is too late.
Normalize vendor signals into a canonical shape on your side. The vendor's object model is not your audit record.
Backfill historical signals from the outgoing vendor before cutover. One-time job; pays back across every future audit.
Run both vendors in parallel for 30-90 days. Use the overlap to verify the new vendor's outputs match the old vendor's for a known cohort.
Keep the source tag on every signal. An examiner asking “which vendor produced this” should be a filter, not a forensic exercise.
Confirm the hash chain crosses the cutover unbroken. The verification is a continuous job; do not save it for export time.
Communicate the migration plan to the sponsor bank ahead of the cutover, not after.

Frequently asked questions

Why do teams swap a KYC or KYB vendor in the first place?

Four reasons dominate. Pricing: the vendor raises rates 20-40% at renewal. Coverage: the team expands into a geography or a vertical the incumbent does not handle well. Performance: pass-through rates degrade, or false-positive rates climb. Compliance pressure: a sponsor bank or examiner asks the team to use a different vendor for specific risk areas. The switch itself is engineering work measured in weeks; the audit history is the part that quietly becomes years of lost continuity if it is not planned for.

If we keep the old vendor account open, doesn't that solve the history problem?

Partially. The data is still queryable in the old console as long as the contract stays active, which means an ongoing cost just to keep records readable. When you finally terminate the contract (usually 12-24 months later), the data export terms matter. Most vendors give you a one-shot export at termination; some delete after a retention window. Either way, the customer's history is now in three places: old vendor (frozen), new vendor (from the cutover forward), and possibly your own data warehouse if you preemptively exported. Examiners ask one question and you assemble across three sources.

What does the sponsor bank ask about a vendor swap?

Sponsor banks want to see continuity. The question is usually phrased as “how will you preserve the audit history of customers onboarded under the old vendor?” The good answer names the mechanism (an export from the old vendor that lands on your record with the original timestamps preserved, the new vendor's signals from cutover forward landing on the same record). The bad answer is “we will keep the old vendor account open.” That answers the data-retention question but not the continuity question.

Can a record beneath the vendors handle vendors that pre-date FinQub?

Yes. Backfill is a one-time engineering job: pull the historical events from the prior vendor's API or export, normalize them into the canonical signal shape, and land them on the corresponding Subject record with their original timestamps. The hash chain on the record bridges the pre-FinQub history into the going-forward FinQub-recorded events. Examiners see one continuous record; engineers see one backfill job and a cutover.

What about webhooks and live state during a cutover?

The trick is to run both vendors in parallel for a 30-90 day window before fully cutting over. Both feed signals into FinQub during the window; the rulebook decides which one is authoritative for each customer based on a routing rule (geography, tier, risk class, or whatever fits your migration plan). At the end of the window, the new vendor takes full responsibility; the old vendor stays connected for read-only retrieval of historical signals if needed. The record holds both vendors' signals across the overlap, so the cutover itself becomes a soft transition rather than a flag day.

FinQub is the single source of truth for fintech risk decisions, with vendor-portable history built in. See how the hash chain survives the swap, or book a short walkthrough below.

Switching a KYC or KYB vendor without losing your audit history