Preocupado que uma mudança no processo de KYC (Conheça Seu Cliente) possa custar clientes? Veja como proteger sua decisão.

Você encontrou um KYC provedor que pareça melhor para o seu negócio. Então alguém faz a pergunta que paralisa o projeto: todos os clientes atuais terão que enviar um documento de identidade e tirar uma selfie novamente?

Essa questão exige uma análise das evidências antes de receber uma resposta afirmativa ou negativa. Alguns registros podem continuar adequados às suas obrigações e políticas. Outros podem estar incompletos, desatualizados ou impossíveis de recuperar. Tratar todos da mesma forma pode gerar atritos desnecessários ou perpetuar uma antiga fragilidade no novo sistema.

A mudança estará pronta quando sua equipe souber o que pode ser preservado, o que precisa ser atualizado e como reverter a transição caso algo dê errado.

Separe a mudança de fornecedor da decisão do cliente.

A simples troca do serviço que realiza as verificações futuras não explica, por si só, quais evidências cada cliente existente precisará em seguida. É necessário que o responsável pela conformidade determine isso de acordo com as jurisdições, os produtos e os riscos de cada cliente.

Não considere o selo de "aprovado" de um fornecedor anterior como prova definitiva. É preciso entender os mecanismos de verificação envolvidos e se o registro original permanece acessível e suficiente.

FATF As diretrizes de identidade digital da [empresa/organização] (abre num novo separador) discutem a adequação da identidade digital para a devida diligência e distinguem a dependência de terceiros dos serviços terceirizados. Quando a dependência é permitida, a responsabilidade não se transfere automaticamente para o terceiro. Uma migração tecnológica não significa permissão irrestrita para aceitar todos os resultados históricos.

Construa um mapa de evidências antes de movimentar o tráfego.

Para uma amostra representativa de clientes, estabeleça o que você realmente possui: - Seu identificador de cliente estável e os identificadores do provedor anterior. - As evidências verificadas, quando foram verificadas e a fonte. - O escopo das verificações, resultados, notas de revisão e decisão final. - Datas de expiração, lacunas pendentes e o gatilho para a próxima revisão. - Onde o registro original está armazenado e quem pode recuperá-lo.

Em seguida, atribua a cada registro uma rota documentada: mantenha as evidências existentes com um mapeamento aprovado, preencha uma lacuna específica ou conclua uma nova verificação.

Por exemplo, um cliente hipotético pode ter um registro de identidade recuperável, mas um documento de endereço vencido. Isso exige uma decisão sobre a comprovação do endereço, e não uma exigência automática de repetir cada etapa. Outro cliente pode ter apenas uma sinalização de aprovação, sem nenhum registro comprobatório. Esse é um problema diferente.

Significados dos mapas, não apenas nomes de status

O termo "verificado" pode ter significados diferentes dependendo do fornecedor. Um resultado pode refletir uma verificação de documentos. Outro pode incluir uma consulta a registros governamentais e comparação facial. Uma aprovação manual pode ter alguma exceção.

Crie um mapeamento das evidências e resultados que sua empresa utiliza. Inclua evidências inconclusivas, documentos sem comprovação, erros do fornecedor, evidências pendentes de revisão e evidências expiradas. Um serviço indisponível não deve ser automaticamente considerado uma aprovação.

Teste esses estados em relação às ações que seu aplicativo executa. Um cliente pode realizar transações enquanto uma revisão está pendente? Um webhook antigo sobrescreve uma decisão mais recente? Uma chamada de retorno do provedor anterior pode alterar uma conta após a migração?

Essas são questões de migração, mesmo quando ambos os SDKs parecem funcionar corretamente.

Faça um pequeno corte que você possa reverter.

Comece em um ambiente de teste com os países, tipos de identificação, dispositivos e casos de falha esperados. Compare as decisões onde você tem uma base legal para usar os dados de teste. Use um grupo limitado de produção somente após concordar com os critérios de aceitação.

Direcione cada jornada do cliente de forma criteriosa. Evite enviar solicitações duplicadas de dois fornecedores diferentes. Se realizar verificações em paralelo, documente a finalidade, os custos adicionais e o tratamento de dados antes de fazê-lo.

Atribua a um dos responsáveis ​​a autoridade para interromper a implementação. Defina quais alterações na conclusão, erros, latência, revisões ou qualidade da decisão devem acionar uma pausa. Prepare a alteração de roteamento que retorne as novas viagens ao caminho anterior, preservando o trabalho já concluído.

Não encerre o acesso ao provedor antigo até que os registros necessários possam ser recuperados e suas obrigações de rescisão sejam cumpridas.

Diga aos clientes exatamente o que eles precisam fazer.

Quando uma nova verificação for necessária, explique o que você precisa, por que precisa e o que acontece com o acesso. Solicite as evidências faltantes por meio de um processo seguro e facilmente reconhecível.

Nos casos em que nenhuma ação seja necessária, evite criar uma tarefa de verificação apenas para anunciar uma mudança de fornecedor. Aplique quaisquer avisos de privacidade ou requisitos de comunicação específicos que sua análise identificar.

Nosso perpétuo KYC Este guia aborda os gatilhos de atualização contínua após a migração. Mantenha esses gatilhos separados do plano de transição.

Planejando uma mudança para Toden

Toden Os fluxos de trabalho suportam verificações configuráveis ​​e regras de decisão versionadas. Use um fluxo de trabalho proposto para testar novas jornadas em relação aos seus requisitos atuais.

Antes de se comprometer com uma migração, solicite que analisemos seus formatos de evidências, identificadores de clientes e verificações necessárias. Não presuma que decisões anteriores, modelos biométricos ou registros de fornecedores possam ser importados sem alterações. A compatibilidade e a aceitação das evidências precisam ser confirmadas.

Falar com Toden Com uma estrutura de registro de exemplo e a jornada do cliente mais movimentada, você tem um ponto de partida concreto para a discussão sobre a migração.