How to Preserve KYC Decision History Across Provider Changes

Engineering guide · Reviewed 14 October 2026

A new KYC provider can report that a customer passed verification while the operator still cannot explain why that customer was admitted last year. Migrating the latest status leaves the earlier decision behind. Preserve the observation that arrived, the rule that interpreted it and the internal decision that changed the customer's permitted activity. Those records answer different questions.

Consider a fictional customer reference K-17. Provider A returned a result for attempt A-17. Decision D-17 admitted that customer under policy P-4 and mapping M-2. After cutover C-17, Provider B produces a different result for attempt B-17. The migration packet contains that new observation, but no approved decision D-18. For this synthetic cohort, C-17 requires an explicit post-cutover disposition; D-17 is retained as historical admission only. Historical admission can be reconstructed if its sources remain available. The new provider's result alone leaves the customer's current permitted activity unresolved under that fictional rule.

Every identifier and outcome in this example is synthetic. No customer migration, verification exercise or production acceptance test was executed. The working method below helps an engineering team specify what a recipient should be able to inspect. It does not determine whether an earlier decision remains legally acceptable or whether a particular customer should be reverified.

Start with two questions the migrated record must answer

Ask what the operator decided at the earlier point, then ask which decision controls the customer now. A history screen that mixes those questions can turn an old approval into a current entitlement without showing who authorized that change. Give each decision its own identity and a reference to its source observations. The current-state view can select a decision without overwriting the historical record.

For K-17, D-17 answers the earlier admission question. B-17 answers what the replacement provider observed. Whether B-17 supports continued admission, a restriction or manual review belongs to the operator's effective policy and authorized decision process.

The absent D-18 must remain absent in the reconstruction; an interface should not fill the gap with a reassuring label.

Provider history becomes difficult to interpret when onboarding integrations retain only a current result. Pharos Production's KYC and AML onboarding engineering covers identity verification and customer risk scoring within its published MiCA software scope. A migration brief can therefore identify the decision-history gap as an engineering requirement. The source supports that service scope, not a claim that this fictional migration has been delivered or validated.

Inventory the evidence before negotiating the move

Start with one closed case and one unfinished attempt. Identify which evidence the operator already holds, which remains inside the supplier's account and which was never captured. Include manual review records where they influenced a decision. An export that contains all customer rows may still omit the observations needed to explain those rows.

Record the export's selection population and its boundaries. A source may exclude archived attempts, comments or superseded document versions. Missing evidence in that export does not establish that the supplier never produced it. Keep a retrieval owner beside the gap so that a later investigator knows whether the next action is another export, a permitted supplier request or a statement that reconstruction is unavailable.

Agree the evidence-transfer scope before old access ends. Reopening a sample under the recipient's permissions is a proposed acceptance check; an archive download completing is insufficient. The CASP evidence-store selection guide provides the broader storage decision. This article's narrower job is preserving the meaning of KYC decisions within that store.

Build a versioned decision envelope

Use an operator-controlled decision identifier as the record's anchor. Connect it to the customer reference and the verification attempt that supplied its observations. A provider applicant identifier is useful lineage, but it should not be the only identity joining every historical record. Another supplier may issue a different identifier for the same internal customer.

A proposed decision envelope contains these fields:

1. Decision identity: D-17, with customer reference K-17 and the decision type, such as initial admission or later restriction.

2. Provider lineage: Provider A, attempt A-17 and the source account or environment that produced the observation.

3. Original observation: the native outcome, its reason identifiers and a controlled reference to the retained response.

4. Interpretation basis: policy P-4 and mapping M-2, including the effective revision used for that decision.

5. Decision authority: the internal result, responsible role and approval reference where approval was required.

6. Time boundaries: the observation's source time, local receipt time and the decision's effective time, with their clock domains.

7. Evidence availability: retrievable source references, permitted retention boundaries and any missing material.

8. Revision relationship: a correction or reevaluation reference that links a later decision without replacing the earlier answer.

These are proposed record fields, not a provider payload specification. Preserve a reference to the actual implementation contract and its version. If an old policy document is unavailable, record the interpretation basis as unverified rather than attaching today's policy to yesterday's decision.

A hash can help identify a retained file; it cannot recover a file the team never preserved.

Keep native outcomes beside the operator's interpretation

The current Sumsub verification-result documentation distinguishes the provider's GREEN and RED review answers. It also distinguishes FINAL from RETRY rejection types. Those fields illustrate why flattening every unsuccessful observation into one internal failure status loses meaning. The documentation describes a provider result, not the operator's permission for a customer to use a particular service.

Retain the native result before translating it. The mapping should state its input scope, internal output and revision. If two provider outcomes map to the same internal state, keep both original outcomes available to an authorized reviewer. Internal workflow convenience does not make the source observations equivalent. Provider B in the example is fictional. Suppose its native outcome requires manual review while Provider A's earlier outcome supported admission. That difference does not prove either supplier was wrong. Compare the check scope and evidence population before comparing the labels. A fresh document check, an earlier identity assessment and a changed risk rule may concern different assertions.

Treat identity linking as a controlled relationship

Link the old and new provider references through the internal customer record. Record how that relationship was established and which source supports it. An alias saying that A-17 and B-17 belong to K-17 is a migration assertion. It is not evidence that Provider B repeated every check that Provider A previously performed. Handle collisions explicitly. A customer may have several attempts with one supplier, and a single provider record may not represent every business relationship in the operator's system. If a match is ambiguous, place it in a review queue rather than silently choosing the most recent row. Retain the conflicting references and the criteria needed to resolve them.

Name changes and corrected attributes need their own history. A corrected current name should not rewrite the raw source observation that an earlier reviewer saw. Restrict access to sensitive attributes while keeping an authorized route for justified reconciliation. The public or routine review copy should use internal references rather than real identity-document details.

Make the cutover record decide event ownership

A wall-clock timestamp alone is a weak basis for deciding which provider attempt owns an event. An old supplier callback can arrive after a new supplier becomes the default. Connect the callback to its originating attempt and the cutover routing rule. Receipt after C-17 should not automatically make an observation part of B-17. The cutover record should identify the scope switched, the previous routing rule and the replacement rule. Record how unfinished attempts are handled: completed under the old provider, transferred under an explicit handover or closed with a stated unresolved result. Choose that behavior for the actual workflow and record its acceptance owner. A default-provider setting does not express all those choices.

For the proposed K-17 exercise, inject an A-17 observation after C-17 and inspect its assignment. The desired demonstration preserves old-attempt lineage and creates any new internal decision through the declared process. This test has not been run. If chronology affects the finding, use the CASP conflicting-clock reconstruction guide and retain supported causal relationships alongside raw timestamps.

Preserve duplicate deliveries without duplicating decisions

Receiving the same observation twice and making the same decision twice are separate behaviors. Retain delivery identities where the source supplies them, together with the operation or attempt they concern. Declare the deduplication boundary in the integration contract. Do not assume that two matching-looking payloads are duplicates when their source identities or check scopes differ.

A proposed duplicate-delivery check sends the same synthetic A-17 observation twice. Inspect whether the operator records both receipts while applying only the intended business transition. The expected relationship should be visible in the evidence packet. A clean final customer state can conceal a duplicated notification, unnecessary restriction or repeated manual-review assignment.

A later correction is also different from a replay. If the source changes a reason or result, retain the earlier observation and identify the corrective relationship. The mapping revision should explain whether that change triggers a new internal review. Do not discard an unfamiliar correction because its customer reference matches an already processed event.

Distinguish continuity from a requirement to reverify

A provider replacement does not itself establish that every previously admitted customer needs a fresh verification run. Determine whether the operator's applicable policy allows an existing decision to continue, requires additional evidence or calls for a new disposition. Preserve that governing rule in the migration packet. Do not infer a universal legal requirement from the synthetic C-17 exercise.

Where continuity is permitted, the current view should reference the retained decision and its declared continuing basis. A new provider observation can enter the history without automatically replacing that authority. Where a new assessment is required, define its scope and the owner who can accept the result. A migration engineer should not quietly choose between those policies through a database default.

The distinction matters for incomplete transfers. A missing historical document can limit reconstruction even when an applicable current decision exists. Conversely, a readable historical archive does not establish that the operator has met a new assessment requirement. Keep those findings separate and escalate the governing-policy question to its responsible owner.

Separate reevaluation from correcting the historical record

A new verification run creates new evidence. It does not retroactively prove what the earlier provider observed. Record the new attempt and its decision as a later event, with the scope of checks actually performed. A new successful identity check may leave a historical source gap unresolved even when the current onboarding process can continue under the responsible policy.

Correcting an old internal interpretation answers another question. Suppose mapping M-2 translated the retained source result incorrectly. A correction should identify the affected decision, the mapping defect and the authorized change. Preserve the original recorded result and its correction relationship under the applicable record policy. Do not silently replace M-2 with M-3 throughout the archive.

For K-17, D-18 remains unverified until the packet includes the actual authorized decision and its evidence basis. A reviewer may be able to reconstruct D-17 and still be unable to accept current activity. Record those findings separately. Historical interpretability, migration completeness and current customer permission should not share one completion flag.

Retain manual-review authority and its limits

A manually resolved case needs more than a comment saying that it was approved. Identify the responsible role and the action it performed. Connect that action to the observations reviewed and any conditions applied. If the process required a second approval, retain its reference; a workflow configuration requiring approval does not establish that approval occurred. Different copies serve different recipients. A routine operations view may need the disposition and escalation owner without sensitive investigation details. An authorized reviewer may need a controlled path to the fuller basis. Preserve that distinction in the access model. Removing restricted comments from a shared export should not remove the reference showing that those comments influenced the internal decision.

If the approval evidence is missing, leave that aspect of reconstruction unverified. Contacting the original reviewer can create a later explanation, but it does not create a contemporaneous approval record. Label the time and basis of that explanation. The migration should expose the difference between evidence retained from the original decision and information supplied during a later review.

Set retention and disclosure boundaries before copying evidence

Preserving history does not mean copying every identity image into every destination indefinitely. Determine the applicable purpose, legal basis and retention rule with the responsible compliance and privacy owners. The engineering task is to implement that agreed boundary and report what can no longer be retrieved. This guide supplies no universal retention period.

Where GDPR applies, Article 5(1)(c) of the European Parliament and Council's regulation describes personal data as:

adequate, relevant and limited to what is necessary

The official GDPR text connects that phrase to the purposes for which the data is processed. Design the migration copy around the evidence needed for its permitted review purpose. A lightweight decision record and a controlled reference may be appropriate where a broader duplicate of documents would be unnecessary or unauthorized.

References still need lifecycle controls. When a source is deleted under an applicable policy, retain only whatever metadata that policy permits and state the resulting reconstruction limit. A reference or checksum is not a loophole around retention duties. Likewise, pseudonymous internal identifiers do not justify claiming that the entire packet is anonymous or outside privacy requirements.

Reconstruct a decision without the former provider's portal

Ask a recipient to explain D-17 using the retained packet under its own access. The recipient should locate the original A-17 observation, resolve P-4 and M-2, then identify the authorized internal action. Record any step that still requires the former supplier's portal. A screenshot of the old interface may show a label while leaving its effective interpretation unavailable.

Keep the reviewer copy and the source reference connected. If the migration transformed a field, retain the transformation rule and source version. A normalized reason code is useful for reports, but the investigator needs to know which original value it represents. A report generated today should identify its own generation time without presenting that time as the historical decision date.

Missing context should produce a bounded finding. For example, the packet may establish the provider observation and the internal recorded state while leaving the approval evidence unavailable. State that limit and the owner of the next retrieval action. Do not call the entire migration failed or accepted solely because one selected case can be partially reconstructed.

Reconcile the exported population before declaring completion

A successful example establishes behavior for the assessed example, not coverage of the entire migration population. Define the customer cohort and source-attempt selection rule before comparing counts. A customer with several verification attempts can produce several evidence records. Comparing a count of customers with a count of provider attempts would conceal the very relationship the archive needs to preserve. Prepare a reconciliation record that links each selected source attempt to its transferred observation and any recorded internal decision. Distinguish a deliberately excluded attempt from an unexpected omission. Preserve the exclusion basis and its authorization where required. If a source offers only the latest result, state that earlier observations were outside the export rather than reporting complete historical coverage.

The destination should also explain records it could not import. An unsupported reason code, an ambiguous customer alias and a missing interpretation revision need different actions. Keep those items in the reconciliation population until their responsible owners resolve or explicitly accept the limits. An import tool's completed-job status cannot supply those decisions.

Finally, compare the reconciled population with the cutover routing scope. An old attempt still receiving callbacks needs a declared owner even if its initial archive copy transferred successfully. Record the relationship between the transfer manifest and the continuing event route. This is a proposed completeness check; no population reconciliation was executed for the fictional K-17 example.

Make K-17 a proposed acceptance exercise

Provide a synthetic packet with D-17, A-17, P-4 and M-2 present. Add B-17 after C-17, with D-18 absent. The recipient should reconstruct the earlier decision and identify that the new observation does not establish a new authorized internal disposition. This is the first expected result; it is not a recorded test outcome.

Then vary one source relationship at a time. Deliver A-17 late, repeat an observation and supply an ambiguous identity alias. Each variation should retain its own inputs and expected interpretation. Include a restricted-evidence case in which an authorized reviewer can resolve a source that the routine operations copy cannot expose. These checks assess the declared boundaries rather than a supplier's generic feature list.

The acceptance report should preserve failed checks and unresolved assertions. Link a later retest to the changed mapping or evidence input without erasing the earlier finding. Identify the population assessed and the cases excluded. Successful synthetic examples cannot establish that all historical customer records were transferred, that every provider result is equivalent or that the operator has permission to continue every affected relationship.

Hand over the history with a retrieval owner

An archive that depends on one engineer's supplier login is difficult to operate after that engineer leaves. Name the team that owns each evidence source, the recipient role that can retrieve it and the escalation path when access fails. Verify a sample using the recipient's access as part of the proposed handover. Do not publish credentials in the packet or expand permissions merely to make a demonstration work.

The handover should also explain how newly arriving observations enter the history after launch. Decide who maintains mappings and approves interpretation changes. A versioned repository helps identify the rule text, but ownership determines who may make it effective. Record the effective revision and the acceptance evidence for a change before relying on it in a live decision path.

Pharos Production's published MiCA compliance software development scope provides a relevant starting point when provider integration and internal onboarding decisions need an inspectable handover. Bring the source inventory and one disputed decision to that discussion. Keep compliance applicability and customer-release authority with the responsible operator; the proposed deliverable is a traceable engineering record, not a certification.

Choose the next action from the missing relationship

If the source observation is absent, request the permitted source export and its selection boundary. When the observation exists but the mapping is unavailable, recover the effective interpretation revision. A missing internal approval requires the decision owner. Choosing another verification provider does not resolve each of those problems automatically.

For K-17, record two conclusions: the available material can support reconstruction of D-17 only within its retained evidence boundary, while current activity remains unresolved without an authorized D-18 or another applicable decision. Keep the next retrieval action beside each gap. The CASP evidence engineering collection routes broader control and recovery questions to their corresponding guides.

A useful migration handover lets the next reviewer challenge the interpretation, retrieve the permitted source and see what remains undecided. Define that result before changing the default provider. It gives the implementation team a concrete evidence job and gives the operator a decision history it can assess without inventing missing approvals.

More insights to read

1. The Payment Recovery Fieldbook: Identity, Replay and Reconciliation

2. Blockchain Ledger Integration Hub: Contracts and Acceptance Evidence

3. FinTech Blockchain Procurement: Scope to Shortlist

4. Choosing a FinTech Blockchain Discovery Partner

5. How to Scope a FinTech Blockchain Discovery Sprint

About the author

Written by Dmytro Nasyrov PhD, software architect with 24 years of production experience. Dmytro is the founder and CTO of Pharos Production. He works on production software architecture for FinTech, AI, Web3 and blockchain systems.