> Melhoria contínua de processos > Integração de clientes KYC > Refinitiv World Check > Template de dados

Seu Template de dados para integração de clientes no processo KYC

Refinitiv World-Check

Atributos da integração de clientes no processo KYC(19) Atividades da integração de clientes no processo KYC(14) Guias de extração(2)

Seu Template de dados para integração de clientes no processo KYC

Este Template orienta você na coleta dos dados essenciais para analisar o processo de integração de clientes no KYC. Ele apresenta os principais atributos a serem registrados, as atividades importantes a serem acompanhadas e orientações para extrair essas informações dos sistemas de origem. Use este material para reunir os dados necessários para analisar e melhorar o processo.

Atributos recomendados para coleta
Principais atividades a acompanhar
Orientações para extração

Novidade em Event Logs? Saiba como criar um Event Log para Process Mining.

Baixar Template

Atributos da integração de clientes no processo KYC

Estes são os campos de dados recomendados para incluir no Event Log e fazer uma análise completa da integração de clientes no processo KYC.

3 Obrigatório 5 Recomendado 11 Opcional

	Nome	Descrição
	Horário do evento EventTime	Data e hora que indicam quando uma atividade ou um evento específico ocorreu.
Descrição O horário do evento informa a data e a hora exatas em que uma atividade foi registrada. Ele é a base cronológica do processo e permite ordenar os eventos corretamente para reconstruir o histórico do caso. Esse atributo é fundamental para todas as análises de Process Mining baseadas em tempo. Ele é usado para calcular a duração entre atividades, incluindo tempos de ciclo e de espera, medir a duração total do caso, analisar a performance do processo ao longo do tempo e verificar a conformidade com os acordos de nível de serviço (SLAs). Sem horários precisos, não é possível entender a performance do processo nem identificar gargalos relacionados ao tempo. Por que isso importa Registrar data e hora de cada atividade é essencial para calcular métricas de duração, descobrir a sequência do processo e analisar gargalos. Onde encontrar Esse é um campo padrão em qualquer Event Log ou tabela de trilha de auditoria, muitas vezes chamado de 'Timestamp', 'EventDate' ou 'CreationDate'. Exemplos 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:15Z
	Nome da atividade ActivityName	Nome de um evento de negócio ou de uma tarefa específica ocorrida no processo de integração KYC.
Descrição O nome da atividade descreve uma etapa ou um evento específico na jornada de integração do cliente, como 'Solicitação enviada', 'Revisão do analista iniciada' ou 'Triagem concluída: sem correspondências'. Essas atividades formam os nós do mapa do processo e detalham o fluxo de trabalho de ponta a ponta. Analisar as atividades é a base do Process Mining. Ao acompanhar a sequência e a frequência das diferentes atividades, os analistas descobrem o fluxo real do processo, identificam os caminhos mais comuns, detectam desvios do procedimento padrão e localizam etapas específicas que causam atrasos ou retrabalho. Esse atributo é fundamental para criar mapas de processo e calcular métricas por atividade. Por que isso importa Esse atributo define as etapas individuais do processo, algo essencial para descobrir e visualizar o fluxo do processo e identificar gargalos. Onde encontrar Essas informações costumam estar nos logs de eventos ou nas tabelas da trilha de auditoria, geralmente associadas a mudanças de status na entidade de gerenciamento de casos. Exemplos Possível correspondência identificadaRevisão do analista iniciadaFalso positivo confirmadoSolicitação aprovada
	Solicitação do cliente CustomerApplication	Identificador exclusivo de uma solicitação de integração de cliente, usado como ID principal do caso.
Descrição A solicitação do cliente é o identificador central do caso, que agrupa todos os eventos e atividades relacionados ao processo de integração de um cliente. Ela permite acompanhar, em ordem cronológica, o progresso de cada cliente ao longo de todo o processo Conheça Seu Cliente (KYC), desde o envio inicial até a decisão final. Na análise de Process Mining, esse atributo é fundamental para reconstruir a jornada completa de cada solicitação. Ele permite visualizar os fluxos do processo, calcular o tempo total de ciclo e identificar variantes. Ao analisar os casos agrupados por esse identificador, as organizações entendem os diferentes caminhos que uma solicitação pode seguir, identificam gargalos e comparam a eficiência dos vários processos de integração. Por que isso importa Esse é o identificador essencial do caso, que conecta todas as atividades relacionadas e permite analisar o processo de integração do cliente de ponta a ponta. Onde encontrar Esse identificador costuma ser a chave primária na tabela principal de solicitações ou de gerenciamento de casos do sistema Refinitiv World-Check ou de um CRM integrado. Exemplos APP-2023-00123APP-2023-00124APP-2023-00125
	Data-limite do SLA SlaTargetDate	Data até a qual o processo de integração do cliente deve ser concluído.
Descrição A data-limite do SLA é o prazo para concluir todo o caso de integração, definido pelo acordo de nível de serviço com o cliente ou pelas políticas internas. Essa data serve de referência para comparar o prazo real de conclusão. Esse atributo é fundamental para o Dashboard 'Análise de cumprimento e violações de SLA'. Ele é usado para calcular se o caso foi concluído dentro do prazo. Analisar as violações de SLA ajuda a identificar problemas sistêmicos que causam atrasos e permite que a organização tome medidas corretivas para melhorar a pontualidade e atender aos requisitos de conformidade. Por que isso importa É a referência para medir o cumprimento dos prazos e é fundamental para calcular a taxa de cumprimento do SLA e analisar as violações. Onde encontrar Essa data costuma ser calculada com base na data de envio da solicitação e nas regras de negócio. Ela pode ser armazenada em um campo do registro do caso. Exemplos 2023-11-10T17:00:00Z2023-11-15T17:00:00Z2023-11-20T17:00:00Z
	Departamento DepartmentName	Departamento ou equipe funcional responsável por realizar a atividade.
Descrição Esse atributo especifica a unidade de negócio ou a equipe à qual o usuário pertence, como 'Integração de clientes', 'Conformidade' ou 'Garantia da qualidade'. Ele permite analisar o processo em um nível organizacional mais amplo do que o individual. Analisar os dados por departamento é fundamental para identificar gargalos entre departamentos e medir o tempo das transferências. Isso ajuda a visualizar como o trabalho passa de uma equipe para outra e onde ocorrem atrasos nessas transições. Essa visão é muito útil para simplificar a colaboração entre áreas e melhorar a eficiência geral do processo. Por que isso importa Permite analisar a performance do processo por departamento e é essencial para identificar atrasos nas transferências entre equipes. Onde encontrar Essas informações podem estar armazenadas no perfil do usuário no sistema ou em um sistema de RH associado. Talvez seja necessário combiná-las com os dados dos eventos usando o ID do usuário. Exemplos Equipe de integração de clientesRevisão de conformidadeAlta gestão
	Horário de término do evento EventEndTime	Data e hora que indicam quando uma atividade ou um evento específico foi concluído.
Descrição O horário de término do evento marca a conclusão de uma atividade. Muitos eventos podem ser modelados como instantâneos, com o horário de início igual ao de término. Outras atividades têm uma duração mensurável, como 'Revisão do analista iniciada' e 'Revisão do analista concluída'. Registrar os horários de início e término permite medir o tempo de processamento com precisão. Na análise do processo, o horário de término é essencial para calcular o tempo exato de processamento de uma atividade, sem incluir o tempo de espera, que faz parte do tempo de ciclo. Isso ajuda a diferenciar o tempo em que um caso está sendo trabalhado ativamente do tempo em que fica parado em uma fila. Essa distinção é importante para otimizar recursos e analisar a eficiência. Por que isso importa Permite calcular com precisão o tempo de processamento das atividades e separar o tempo de trabalho ativo do tempo de espera, para uma análise de performance mais precisa. Onde encontrar Para atividades com duração, esse dado pode ser armazenado em um campo separado, como 'CompletionDate' ou 'EndDate', nas tabelas do Event Log ou da trilha de auditoria. Exemplos 2023-10-26T10:45:00Z2023-10-26T12:00:00Z2023-10-27T15:00:00Z
	ID do revisor ReviewerId	Identificador do usuário, analista ou agente automatizado que realizou a atividade.
Descrição O ID do revisor, ou usuário, indica quem executou uma tarefa específica no processo KYC. Pode ser um analista de conformidade, um especialista em integração de clientes ou uma conta do sistema responsável por atividades automatizadas. Acompanhar essas informações permite entender como a carga de trabalho está distribuída e avaliar a performance individual. Esse atributo é essencial para análises baseadas em recursos. Ele ajuda a entender as diferenças de performance entre usuários ou equipes, identificar necessidades de treinamento e equilibrar a carga de trabalho. Também é importante para analisar transferências de trabalho, redes sociais e o uso dos recursos de conformidade. Por que isso importa Permite analisar a distribuição da carga de trabalho, a performance dos usuários e as transferências entre departamentos, algo fundamental para otimizar recursos. Onde encontrar Geralmente encontrado em logs de eventos ou trilhas de auditoria, com nomes como 'UserID', 'PerformedBy' ou 'Owner'. Exemplos analyst_jdoesystem_auto_screenermanager_bsmith
	Nível de risco RiskLevel	Classificação de risco calculada para a solicitação do cliente, como baixo, médio ou alto.
Descrição O nível de risco é uma informação fundamental nos processos KYC, pois determina o grau de diligência necessário. Ele costuma ser definido com base em fatores como o tipo de cliente, a localização geográfica e a natureza da atividade. Essa classificação pode influenciar significativamente o caminho que a solicitação percorre. Na análise do processo, é essencial segmentar os casos por nível de risco. Isso ajuda a explicar variações no tempo de ciclo e nos fluxos do processo. Por exemplo, solicitações de alto risco podem exigir mais etapas e levar mais tempo. Esse atributo é fundamental para os Dashboards 'Taxa e motivos de rejeição de solicitações' e 'Tempo de ciclo até o início da verificação de antecedentes', que ajudam a entender como o risco afeta os resultados e a eficiência. Por que isso importa Segmentar o processo por nível de risco é fundamental para entender por que alguns casos demoram mais ou seguem caminhos diferentes e para analisar as taxas de rejeição. Onde encontrar Esse é um dado essencial do registro da solicitação do cliente ou do caso. Consulte o módulo de gerenciamento de casos do Refinitiv World-Check. Exemplos BaixoMédioAlto
	Canal da solicitação ApplicationChannel	Canal pelo qual a solicitação do cliente foi enviada, como portal online, agência ou aplicativo móvel.
Descrição O canal da solicitação indica por onde ela foi enviada. Os diferentes canais podem variar em completude e qualidade dos dados e no perfil demográfico dos clientes, o que pode afetar as etapas seguintes do processo. Esse atributo é essencial para o Dashboard 'Volume de solicitações por canal'. Ao analisar o volume, o tempo de ciclo e os resultados das solicitações de cada canal, a organização pode identificar quais são mais eficientes e quais precisam de melhorias no processo. Essa análise ajuda a tomar decisões estratégicas sobre a alocação de recursos e os investimentos em cada canal. Por que isso importa Ajuda a analisar a performance e a eficiência dos diferentes canais de envio e orienta decisões estratégicas sobre tecnologia e experiência do cliente. Onde encontrar Essas informações costumam ser registradas no início do processo e armazenadas como um atributo do registro da solicitação. Exemplos Portal onlineAplicativo móvelAgênciaGerente de relacionamento
	É automatizada IsAutomated	Indica se a atividade foi realizada por um sistema (verdadeiro) ou por uma pessoa (falso).
Descrição Esse atributo booleano diferencia as tarefas automatizadas pelo sistema das atividades manuais realizadas por usuários. Por exemplo, “Triagem automatizada realizada” seria marcada como automatizada, enquanto “Análise do analista iniciada” seria manual. Essa distinção é essencial para a análise de automação. Ela ajuda a medir o impacto da automação na eficiência do processo, identificar tarefas manuais que podem ser automatizadas no futuro e entender a interação entre pessoas e sistemas. Também permite separar claramente o tempo de processamento do sistema do tempo de execução manual. Por que isso importa Diferencia as atividades realizadas por sistemas daquelas realizadas por pessoas, o que é essencial para medir o impacto da automação e identificar novas oportunidades de automatização. Onde encontrar Normalmente, esse valor é definido com base no nome da atividade ou no ID do usuário associado ao evento, por exemplo, quando o usuário é uma conta de “sistema”. Exemplos truefalse
	É retrabalho IsRework	Indica se uma atividade está sendo realizada pela segunda vez ou mais no mesmo caso.
Descrição IsRework é um atributo booleano calculado que identifica quando uma atividade se repete no mesmo caso de solicitação de um cliente. Por exemplo, se “Avaliação de risco realizada” ocorrer mais de uma vez em uma solicitação, as ocorrências seguintes serão marcadas como retrabalho. Esse atributo é essencial para identificar ineficiências, ciclos e repetições desnecessárias no processo. Ele dá suporte direto ao Dashboard “Retrabalho e eficiência na avaliação de risco” e ao KPI “Taxa de retrabalho na avaliação de risco”. A análise do retrabalho ajuda a revelar problemas de qualidade, clareza das informações ou tomada de decisão, que geram esforço desperdiçado e aumentam o tempo de ciclo. Por que isso importa Evidencia ineficiências no processo ao sinalizar atividades repetidas, permitindo analisar ciclos de retrabalho para melhorar a qualidade e reduzir o tempo de ciclo. Onde encontrar Esse valor é calculado durante a transformação dos dados, analisando a sequência de atividades de cada caso e sinalizando todas as ocorrências de uma atividade que não sejam a primeira. Exemplos truefalse
	ID da correspondência MatchId	Identificador exclusivo de uma possível correspondência encontrada durante uma triagem do World-Check.
Descrição Quando o processo de triagem automatizada encontra uma possível correspondência em listas de sanções, listas de PEPs ou notícias negativas, geralmente é gerado um ID de correspondência para identificar o resultado específico. Esse ID vincula o caso da solicitação ao registro específico no banco de dados World-Check que gerou o alerta. Esse atributo é útil para uma análise detalhada de conformidade. Ele permite que analistas investiguem a natureza das correspondências, acompanhem a resolução de alertas específicos, como a confirmação de um falso positivo ou de uma correspondência verdadeira, e entendam quais tipos de alerta são mais comuns ou levam mais tempo para serem resolvidos. Assim, é possível analisar com mais detalhes a atividade “Possível correspondência identificada”. Por que isso importa Vincula os resultados específicos da triagem, permitindo analisar com mais profundidade os tempos de resolução das correspondências e os tipos de alerta. Onde encontrar Esse ID seria gerado pelo mecanismo de triagem do World-Check e registrado no caso da solicitação quando uma possível correspondência fosse encontrada. Exemplos WC-MATCH-459021WC-MATCH-459022WC-MATCH-459023
	ID do cliente CustomerId	Identificador exclusivo do cliente que está passando pelo processo de integração.
Descrição O ID do cliente é o identificador exclusivo do perfil do cliente. Ele é diferente do ID da solicitação do cliente, pois um mesmo cliente pode enviar várias solicitações ao longo do tempo. Esse atributo vincula o processo de integração ao cadastro principal do cliente. Na análise, o ID do cliente permite acompanhar solicitações recorrentes do mesmo cliente e pode ser usado para enriquecer os dados do processo com outros atributos do cliente, vindos de um CRM ou sistema de dados mestres. Isso oferece uma visão mais completa da jornada do cliente, além de uma única etapa de integração. Por que isso importa Vincula o caso de integração a um cliente específico, permitindo analisar solicitações recorrentes e enriquecer os dados com informações do cadastro principal do cliente. Onde encontrar Esse seria um campo importante no registro da solicitação ou do caso, vinculando-o aos dados mestres do cliente. Exemplos CUST-98765CUST-98766CUST-98767
	Motivo da rejeição RejectionReason	Motivo específico informado quando uma solicitação de cliente é rejeitada.
Descrição Quando uma solicitação é rejeitada, o motivo da rejeição registra a razão da decisão. Entre os motivos possíveis estão 'Correspondência em lista de sanções', 'Documentação incompleta' ou 'Perfil de alto risco'. Essas informações estruturadas oferecem feedback valioso sobre a qualidade das solicitações recebidas e a eficácia do processo de triagem. Esse atributo é o principal dado do Dashboard 'Taxa e motivos de rejeição de solicitações'. Analisar os motivos ajuda a identificar as causas raiz das rejeições e pode levar a melhorias no processo, a uma comunicação mais clara com os solicitantes e à redução de rejeições desnecessárias. Ele complementa a métrica quantitativa da taxa de rejeição com contexto qualitativo. Por que isso importa Aponta a causa raiz das rejeições de solicitações, algo essencial para identificar oportunidades de melhoria no processo de integração e reduzir a taxa de rejeição. Onde encontrar Esse dado seria registrado quando ocorre o evento 'Solicitação rejeitada', provavelmente em um campo do registro do caso ou da solicitação. Exemplos Correspondência com PEPCorrespondência em lista de sançõesVerificação de documentos reprovadaMídia negativa
	País do cliente CustomerCountry	País de residência ou de constituição do cliente.
Descrição Esse atributo indica a localização geográfica do cliente. O país é um fator importante na avaliação de riscos e nos requisitos regulatórios dos processos KYC. Cada jurisdição tem regras próprias, que podem afetar o fluxo e a duração do processo. Analisar o processo por país permite comparar a performance entre regiões, identificar gargalos específicos de cada localidade e garantir a conformidade com as regulamentações locais. Essa dimensão geográfica da análise pode revelar diferenças operacionais importantes. Por que isso importa Permite analisar o processo por região e ajuda a identificar diferenças de performance, risco e requisitos de conformidade entre localidades. Onde encontrar Esse é um campo padrão do perfil do cliente ou do formulário de solicitação. Exemplos USAGBRSGPDEU
	Sistema de origem SourceSystem	Sistema do qual os dados do evento foram extraídos, neste caso, o Refinitiv World-Check.
Descrição Esse atributo identifica a origem dos dados do processo. Em uma extração de uma única fonte, ele pode ter um valor constante. Já quando dados de vários sistemas, como um CRM e o World-Check, são combinados para criar uma visão completa do processo, esse atributo se torna fundamental. Na análise, ele ajuda na governança de dados, na solução de problemas e na compreensão do contexto dos dados. Por exemplo, as atividades registradas em um sistema principal de triagem podem ter propriedades ou níveis de detalhe diferentes dos dados de um sistema periférico. Assim, a linhagem dos dados fica clara e pode ser auditada. Por que isso importa Identifica a origem dos dados, algo fundamental para a governança e a validação dos dados e para combinar informações de várias fontes. Onde encontrar Geralmente, é um valor estático adicionado durante o processo de extração, transformação e carregamento (ETL) para identificar o conjunto de dados. Exemplos Refinitiv World-CheckWorldCheckOne
	SLA violado SlaBreached	Indica se o caso de integração do cliente foi concluído após a data-limite do SLA.
Descrição Esse atributo calculado indica se um caso violou o acordo de nível de serviço. Para determinar isso, compara-se a data e hora da atividade final de conclusão, como “Solicitação aprovada” ou “Solicitação rejeitada”, com o campo “SlaTargetDate” do caso. Essa indicação serve de base para o Dashboard “Análise de cumprimento e violação de SLA” e para o KPI “Taxa de cumprimento de SLA”. Ela simplifica a análise, permitindo que os usuários filtrem rapidamente todos os casos com SLA violado. Ao analisar as características dos processos nesses casos, as organizações podem identificar as causas raiz dos atrasos e direcionar melhor os esforços de melhoria. Por que isso importa Mede diretamente o cumprimento dos acordos de nível de serviço e facilita a filtragem e a análise de causa raiz dos casos atrasados. Onde encontrar Esse valor é calculado durante a transformação dos dados, comparando a data e hora da atividade final de cada caso com o campo SlaTargetDate. Exemplos truefalse
	Tipo de cliente CustomerType	Classificação do cliente, como pessoa física, empresa ou trust.
Descrição O tipo de cliente classifica a entidade que está passando pelo processo de integração. Cada tipo de cliente costuma ter requisitos de integração, perfis de risco e obrigações regulatórias diferentes. Por exemplo, integrar uma empresa costuma ser mais complexo do que integrar uma pessoa física. Esse atributo é usado em análises de segmentação, especialmente no Dashboard 'Performance KYC por tipo de cliente'. Ele permite comparar a eficiência do processo, os tempos de ciclo e as taxas de rejeição entre diferentes segmentos de clientes. Assim, as organizações podem adaptar e otimizar a experiência de integração para cada tipo de cliente. Por que isso importa Permite comparar a performance entre diferentes segmentos de clientes e ajuda a adaptar e otimizar o processo de integração para cada tipo. Onde encontrar Esse é um atributo básico armazenado no registro do cliente ou da solicitação no sistema de origem. Exemplos Pessoa físicaEmpresaOrganização sem fins lucrativosTrust
	Última atualização dos dados LastDataUpdate	Data e hora da última atualização ou extração dos dados desse evento no sistema de origem.
Descrição Esse atributo indica o nível de atualização dos dados. Ele registra a data e a hora da última extração de dados do Refinitiv World-Check. Isso é importante para entender o quanto os dados dos Dashboards e das análises de Process Mining estão atualizados. Na análise, esse atributo permite saber se os dados são quase em tempo real ou se representam um instantâneo de um momento específico. Ele é essencial para a governança de dados e para alinhar as expectativas sobre a atualidade dos insights apresentados. Por que isso importa Fornece contexto importante sobre a atualização dos dados e ajuda a entender o quanto a análise do processo está atualizada. Onde encontrar Essa data e hora são geradas e adicionadas durante o processo de extração de dados (ETL). Exemplos 2023-11-01T02:00:00Z2023-11-02T02:00:00Z

Obrigatório Recomendado Opcional

Atividades da integração de clientes no processo KYC

Estas são as principais etapas e os marcos do processo que você deve registrar no Event Log para descobrir o processo com precisão.

8 Recomendado 6 Opcional

	Atividade	Descrição
	Conta ativada	A conta do cliente é criada e ativada no sistema principal, concluindo o processo de integração. Isso acontece após a aprovação final da solicitação e deixa a conta pronta para uso.
Por que isso importa Essa é a etapa final do processo, que entrega valor ao cliente. O tempo entre o envio da solicitação e a ativação da conta é uma métrica importante para avaliar a eficiência operacional e a satisfação do cliente. Onde encontrar Esse evento não é registrado no World-Check. Ele é registrado no sistema bancário principal ou no sistema de contas de clientes e deve ser associado pelo ID da solicitação do cliente. Coleta Evento registrado no sistema principal de contas quando a conta é ativada. Tipo de evento explicit
	Correspondência verdadeira confirmada	Um analista confirma que a possível correspondência é de fato o cliente analisado, identificando um risco potencial. Esse é um marco crítico que normalmente leva a uma diligência adicional ou à rejeição da solicitação.
Por que isso importa Esse resultado é importante para a mitigação de riscos e representa um momento decisivo no processo. Ele influencia diretamente a decisão final sobre a solicitação do cliente e é fundamental para relatórios e análises de conformidade. Onde encontrar Essa é uma ação explícita do usuário: o analista classifica uma correspondência específica como 'Correspondência verdadeira' ou 'Correspondência confirmada'. O evento é registrado na trilha de auditoria do caso. Coleta Registrado quando um analista confirma formalmente uma correspondência no sistema. Tipo de evento explicit
	Revisão do analista iniciada	Um analista de conformidade inicia a investigação manual de possíveis correspondências em uma solicitação de cliente. Para isso, compara os detalhes das possíveis correspondências com as informações do cliente e avalia se são relevantes.
Por que isso importa Isso marca o início da revisão manual de conformidade, um gargalo comum. Medir o tempo entre 'Possível correspondência identificada' e essa atividade revela atrasos na fila, enquanto a duração da revisão indica a eficiência dos analistas. Onde encontrar Isso pode ser inferido quando um analista assume ou abre um caso na fila de revisão. O sistema também pode registrar o evento explicitamente na trilha de auditoria, quando o status do caso muda para 'Em revisão' ou o caso é atribuído a um usuário específico. Coleta Inferido pela mudança do status do caso para 'Em revisão' ou pela atribuição do caso a um analista. Tipo de evento inferred
	Solicitação de verificação criada	Um novo caso de verificação é criado oficialmente para uma solicitação de cliente no sistema Refinitiv World-Check. Isso é acionado por uma chamada de API ou por um registro manual em um sistema anterior e marca o início da verificação de inteligência de risco.
Por que isso importa Isso marca o início oficial do subprocesso de triagem. O intervalo entre o envio da solicitação e essa atividade revela atrasos nas transferências entre o sistema da área de negócio e a função de conformidade. Onde encontrar Registrado nos logs de gerenciamento de casos ou na trilha de auditoria do World-Check. Seriam usados o evento de criação e o horário registrado para o ID do caso ou da entidade em questão. Coleta Registrado automaticamente quando um novo caso de triagem é criado no sistema. Tipo de evento explicit
	Solicitação enviada	Esta atividade marca o início do processo de integração KYC, quando o cliente envia a solicitação. Em geral, esse evento é registrado em um CRM ou sistema central de solicitações, que então inicia o processo de verificação no Refinitiv World-Check.
Por que isso importa Este é o principal evento de início do processo de integração de clientes de ponta a ponta. Analisar o tempo entre este ponto e a conclusão permite medir o tempo total de ciclo da integração, essencial para avaliar a experiência dos clientes e o cumprimento dos SLAs. Onde encontrar Este evento não é nativo do World-Check. Ele precisa vir de um sistema anterior, como um CRM ou uma plataforma de gerenciamento de contas de clientes, e ser relacionado pelo ID da solicitação do cliente. Coleta Evento registrado no sistema de origem quando a solicitação é enviada pela primeira vez. Tipo de evento explicit
	Solicitação rejeitada	A solicitação do cliente é rejeitada formalmente, muitas vezes devido a uma 'Correspondência encontrada' no World-Check ou a outros fatores de risco. Esse evento representa o resultado negativo final do processo de integração.
Por que isso importa Esse é o principal ponto final de insucesso do processo. Analisar os eventos de rejeição, especialmente os motivos e as atividades anteriores, é fundamental para melhorar o processo e reduzir rejeições desnecessárias. Onde encontrar Essa decisão final de negócio é registrada no CRM ou no sistema principal de solicitações, não no próprio World-Check. Os dados devem ser obtidos desse sistema. Coleta Evento registrado no sistema de origem, muitas vezes com um código correspondente ao motivo da rejeição. Tipo de evento explicit
	Triagem concluída: correspondência encontrada	O caso de triagem é encerrado oficialmente com o resultado 'Correspondência encontrada', indicando a identificação de um risco confirmado. Essa decisão inicia outro processo subsequente, como uma diligência reforçada ou a rejeição da solicitação.
Por que isso importa Esse é o principal ponto final do caminho desfavorável do processo de triagem. Analisar esses casos ajuda a entender os perfis de risco e a eficácia dos controles de triagem. Onde encontrar Inferido pela mudança do status final do caso para 'Correspondência encontrada', 'Risco identificado' ou 'Encerrado: positivo'. Usa-se o horário dessa mudança final de status. Coleta Derivado do horário do status final do caso que indica uma correspondência confirmada. Tipo de evento inferred
	Triagem concluída: sem correspondências	O caso de triagem é encerrado oficialmente com o resultado 'Sem correspondências', ou seja, nenhuma correspondência verdadeira foi encontrada. Essa decisão é comunicada ao sistema de origem, permitindo que o processo de integração do cliente continue.
Por que isso importa Essa atividade representa a conclusão bem-sucedida do caminho ideal do processo de triagem. Ela é um ponto final importante para medir o tempo de ciclo de solicitações padrão e de baixo risco. Onde encontrar Inferido pela mudança do status final do caso para 'Sem correspondências', 'Concluído' ou 'Encerrado: nenhuma correspondência'. Usa-se o horário dessa mudança final de status. Coleta Derivado do horário do status final do caso que indica um resultado sem correspondências. Tipo de evento inferred
	Caso encaminhado para revisão	Um analista de primeiro nível encaminha um caso complexo ou de alto risco a um analista sênior ou gerente para uma decisão final. Esse é um ponto importante de transferência dentro da equipe de conformidade.
Por que isso importa Os encaminhamentos podem criar gargalos e aumentar o tempo de ciclo. Analisar a frequência e os motivos desses encaminhamentos pode revelar necessidades de treinamento para analistas juniores ou ambiguidades nas políticas de revisão. Onde encontrar Registrado como uma ação explícita no fluxo de trabalho do caso ou na trilha de auditoria. Também pode ser inferido pela mudança do usuário atribuído ao caso, especialmente quando ele passa para alguém com permissões mais elevadas. Coleta Registrado pelo botão específico 'Encaminhar' ou por uma ação do fluxo de trabalho dentro do caso. Tipo de evento explicit
	Falso positivo confirmado	O analista conclui que a possível correspondência não é a mesma pessoa ou entidade do cliente analisado. A correspondência é descartada e a triagem desse alerta é encerrada.
Por que isso importa Esse é um resultado comum do processo de revisão. Entender quanto tempo leva para encerrar falsos positivos ajuda a medir a eficiência dos analistas e a precisão da lógica de triagem automatizada. Onde encontrar Essa é uma ação explícita do usuário: o analista classifica uma correspondência específica como 'Falso positivo' ou 'Não é uma correspondência'. Essa ação costuma ser registrada no histórico do caso. Coleta Registrado quando um analista descarta formalmente uma possível correspondência no sistema. Tipo de evento explicit
	Informações adicionais solicitadas	O analista determina que precisa de mais informações para resolver a possível correspondência e as solicita à unidade de negócio. O caso fica pendente até que as informações sejam fornecidas.
Por que isso importa A ocorrência frequente dessa atividade indica problemas na qualidade dos dados iniciais fornecidos para a triagem. Ela causa atrasos significativos, pois depende de equipes externas, e é um dos principais fatores que prolongam o tempo de ciclo. Onde encontrar Pode ser uma ação explícita do usuário, registrada nas notas do caso ou no log de auditoria. Também pode ser inferida pela mudança do status do caso para 'Aguardando informações' ou 'Solicitação de informações'. Coleta Registrado quando um analista usa um recurso para sinalizar que o caso precisa de mais informações. Tipo de evento explicit
	Possível correspondência identificada	A triagem automatizada encontrou uma ou mais possíveis correspondências que precisam ser analisadas manualmente por um analista. Esse evento tira o caso do fluxo automatizado e o encaminha para uma fila de investigação manual.
Por que isso importa Essa atividade é um ponto crítico de ramificação do processo. Casos com possíveis correspondências seguem um caminho mais longo e complexo. Acompanhar esse fluxo ajuda no planejamento de recursos e na análise de gargalos da equipe de revisão. Onde encontrar Inferido pela mudança do status do caso para 'Revisão necessária', 'Possível correspondência' ou um status semelhante no módulo de gerenciamento de casos do World-Check. Coleta Derivado de uma mudança no status do caso que indica a necessidade de revisão manual. Tipo de evento inferred
	Solicitação aprovada	A solicitação do cliente foi totalmente aprovada após uma triagem KYC bem-sucedida e a conclusão de outras verificações necessárias. Esse evento costuma ocorrer no sistema de origem depois que ele recebe do World-Check um resultado 'Sem correspondências'.
Por que isso importa Isso marca o resultado de negócio bem-sucedido do processo de integração do cliente. Acompanhar o tempo entre o envio da solicitação e esse ponto revela quanto tempo leva para aprovar um novo cliente. Onde encontrar Esse evento não é nativo do World-Check. Ele deve vir do CRM ou do sistema principal de solicitações, que toma a decisão final de negócio. Coleta Evento registrado no sistema de origem quando a aprovação final é concedida. Tipo de evento explicit
	Triagem automatizada realizada	O sistema World-Check compara automaticamente os dados do cliente com seu banco de dados de inteligência de risco. Essa atividade conduzida pelo sistema gera um conjunto inicial de resultados, como possíveis correspondências ou um status sem correspondências.
Por que isso importa Essa atividade é a primeira etapa que agrega valor ao processo de triagem. Atrasos antes desse ponto indicam problemas de disponibilidade do sistema ou dos dados, enquanto o resultado determina o volume de trabalho manual nas etapas seguintes. Onde encontrar Esse evento pode ser registrado explicitamente na trilha de auditoria do caso ou inferido pelo horário em que os resultados da triagem inicial ficam disponíveis para o caso. Coleta Registro do sistema gerado após a conclusão da verificação automatizada no banco de dados. Tipo de evento explicit

Recomendado Opcional

Guias de extração

Como obter seus dados do Refinitiv World-Check

Etapas

Acesse o World-Check One: Entre no portal Refinitiv World-Check One usando suas credenciais.
Acesse o gerenciamento de casos: Abra a seção de gerenciamento de casos, onde os casos de triagem são armazenados e gerenciados.
Prepare a exportação do relatório de casos: Acesse o recurso de relatórios ou exportação na seção de gerenciamento de casos. Ele pode aparecer como “Exportar casos” ou “Relatório de casos”.
Configure o relatório de casos: Selecione as colunas que serão incluídas na exportação. Inclua os campos correspondentes ao ID do caso (CustomerApplication), à data de criação, à data de resolução, ao status do caso (por exemplo, Liberado, Correspondência encontrada) e ao nível de risco.
Exporte os dados de gerenciamento de casos: Defina o período, normalmente os últimos 3 a 6 meses de atividade. Aplique os filtros necessários, como grupo de usuários ou tipo de caso. Exporte os dados em um arquivo CSV com o nome case_report.csv.
Prepare a exportação do registro de auditoria: Acesse a seção de registro de auditoria ou de relatórios de auditoria do World-Check One. Ela contém o histórico detalhado de eventos de cada caso.
Configure e exporte o registro de auditoria: Selecione todas as colunas relevantes, incluindo o ID do caso, o nome ou a descrição do evento, a data e hora do evento e o usuário que realizou a ação. Exporte os dados para o mesmo período do relatório de casos. Salve o arquivo como audit_trail.csv.
Obtenha dados das etapas externas do processo: Reúna dados de atividades que ocorrem fora do World-Check, como Application Submitted, Application Approved, Account Activated e Application Rejected. Em geral, esses dados vêm de um CRM ou sistema bancário central. Exporte-os com o ID CustomerApplication e as datas e horas relevantes.
Combine e transforme os dados: Carregue os arquivos CSV exportados (case_report.csv, audit_trail.csv e os dados do sistema externo) em uma ferramenta ou script de preparação de dados.
Associe os eventos de auditoria às atividades: Processe o arquivo audit_trail.csv. Associe as descrições brutas dos eventos do registro de auditoria aos valores padronizados de ActivityName. Por exemplo, uma entrada como “Caso atribuído ao analista” passa a ser “Análise do analista iniciada”.
Associe as mudanças de status dos casos às atividades: Processe o arquivo case_report.csv para gerar atividades com base nas mudanças de status. Use a data de resolução e o status final do caso para criar os eventos “Triagem concluída - Liberado” ou “Triagem concluída - Correspondência encontrada”.
Crie o Event Log final: Una os dados processados dos diferentes arquivos de origem em um único arquivo CSV. Verifique se o arquivo final contém as colunas obrigatórias: CustomerApplication, ActivityName e EventTime, além dos atributos recomendados. Salve o arquivo para carregá-lo na ferramenta de mineração de processos.

Configuração

Tipos de relatório: Gere pelo menos dois relatórios separados: um resumo do gerenciamento de casos e um relatório detalhado do registro de auditoria.
Período: Para uma análise inicial, selecione um período de pelo menos 3 a 6 meses para incluir casos concluídos e em andamento em quantidade suficiente. Use o mesmo período em todos os arquivos exportados.
Formato de exportação: Escolha CSV (valores separados por vírgula) para facilitar o processamento.
Colunas principais (relatório de casos): Inclua na exportação o ID do caso, a data e hora de criação, a data e hora de resolução, o status final, o analista responsável e o nível de risco.
Colunas principais (relatório do registro de auditoria): Inclua na exportação do registro de auditoria o ID do caso, a descrição do evento, a data e hora do evento e o ID do usuário.
Pré-requisitos: É necessário ter acesso ao portal World-Check One com permissões para visualizar e exportar dados de gerenciamento de casos e do registro de auditoria. Talvez sejam necessárias permissões mais elevadas do que as de um perfil padrão de analista.

Consulta de exemplo sql

/*
This is a configuration and mapping guide, not an executable script. 
The process relies on manually exporting two reports from World-Check One and combining them with data from an upstream system (e.g., CRM).
*/

-- Step 1: Export 'Case Management Report' as case_report.csv
-- Step 2: Export 'Audit Trail Report' as audit_trail.csv
-- Step 3: Export relevant events from CRM/core system as source_system_events.csv

-- Step 4: Combine and map the files using a script or ETL tool to create the final event log.

-- Mapping logic for final_event_log.csv

-- Part A: Data from source_system_events.csv
SELECT
  ApplicationID AS CustomerApplication,
  'Application Submitted' AS ActivityName,
  SubmissionTimestamp AS EventTime,
  NULL AS EventEndTime,
  OriginatorID AS ReviewerId,
  OriginatingDept AS DepartmentName,
  RiskRating AS RiskLevel,
  SlaDate AS SlaTargetDate
FROM source_system_events.csv
WHERE EventType = 'Submission'

UNION ALL

SELECT
  ApplicationID AS CustomerApplication,
  'Application Approved' AS ActivityName,
  ApprovalTimestamp AS EventTime,
  NULL AS EventEndTime,
  ApproverID AS ReviewerId,
  ApprovingDept AS DepartmentName,
  RiskRating AS RiskLevel,
  SlaDate AS SlaTargetDate
FROM source_system_events.csv
WHERE EventType = 'Approval'

UNION ALL

SELECT
  ApplicationID AS CustomerApplication,
  'Account Activated' AS ActivityName,
  ActivationTimestamp AS EventTime,
  NULL AS EventEndTime,
  'SYSTEM' AS ReviewerId,
  'Operations' AS DepartmentName,
  RiskRating AS RiskLevel,
  SlaDate AS SlaTargetDate
FROM source_system_events.csv
WHERE EventType = 'Activation'

UNION ALL

SELECT
  ApplicationID AS CustomerApplication,
  'Application Rejected' AS ActivityName,
  RejectionTimestamp AS EventTime,
  NULL AS EventEndTime,
  ReviewerID AS ReviewerId,
  'Compliance' AS DepartmentName,
  RiskRating AS RiskLevel,
  SlaDate AS SlaTargetDate
FROM source_system_events.csv
WHERE EventType = 'Rejection'

-- Part B: Data from World-Check audit_trail.csv
UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Screening Request Created' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  UserID AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Case Created%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Automated Screening Performed' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  'SYSTEM' AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Automated Screening Completed%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Potential Match Identified' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  'SYSTEM' AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Potential Match Found%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Analyst Review Started' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  UserID AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Case Assigned%' OR EventDescription LIKE '%Review Started%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Additional Information Requested' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  UserID AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Information Requested%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Case Escalated for Review' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  UserID AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Case Escalated%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'False Positive Confirmed' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  UserID AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Match Dismissed as False Positive%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'True Match Confirmed' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  UserID AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Match Confirmed as True%'

-- Part C: Data from World-Check case_report.csv
UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Screening Completed - Clear' AS ActivityName,
  ResolutionTimestamp AS EventTime,
  NULL AS EventEndTime,
  ResolverID AS ReviewerId,
  'Compliance' AS DepartmentName,
  RiskLevel AS RiskLevel,
  NULL AS SlaTargetDate
FROM case_report.csv
WHERE FinalStatus = 'Clear'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Screening Completed - Match Found' AS ActivityName,
  ResolutionTimestamp AS EventTime,
  NULL AS EventEndTime,
  ResolverID AS ReviewerId,
  'Compliance' AS DepartmentName,
  RiskLevel AS RiskLevel,
  NULL AS SlaTargetDate
FROM case_report.csv
WHERE FinalStatus = 'Match Found'

Etapas

Pré-requisitos e configuração: Instale o Python 3.6 ou superior e as bibliotecas requests e pandas. Obtenha a chave e o segredo da API do World-Check One com seu representante da Refinitiv ou no portal para desenvolvedores. Armazene essas credenciais com segurança.
Desenvolva a lógica de autenticação: No script Python, crie uma função para enviar uma solicitação POST ao endpoint de autenticação do World-Check One. Use a chave e o segredo da API para obter um token bearer temporário, necessário para as chamadas seguintes à API.
Identifique os dados do sistema de origem: O processo começa e termina fora do World-Check. Identifique o sistema de origem, como um CRM ou uma plataforma bancária central, que armazena os dados iniciais da solicitação. Você precisará extrair desse sistema eventos como Application Submitted, Application Approved, Account Activated e Application Rejected. Isso pode ser feito por meio de uma consulta ao banco de dados ou de outra API.
Busque os casos do World-Check: Com o token autenticado, faça uma solicitação GET ao endpoint /cases da API do World-Check One. Use parâmetros de consulta para filtrar os casos por um período específico, por exemplo, pela data de criação ou de modificação.
Trate a paginação da API: As respostas da API do World-Check são paginadas. O script deve verificar os dados de paginação na resposta e percorrer todas as páginas para recuperar a lista completa de casos do período definido.
Recupere os detalhes e o histórico dos casos: Para cada ID de caso recuperado, faça solicitações GET adicionais a endpoints como /cases/{case_system_id} e /cases/{case_system_id}/audit-trail. Esses endpoints fornecem detalhes sobre mudanças de status, resoluções e ações dos usuários associadas ao caso.
Associe os dados brutos às atividades: Esta é uma etapa essencial da transformação. Crie uma lógica para percorrer os dados da resposta da API, incluindo os detalhes do caso e o registro de auditoria. Associe mudanças de status, códigos de resultado e eventos de auditoria específicos às atividades de negócio correspondentes. Por exemplo, um evento de criação de caso passa a ser Screening Request Created, e uma resolução com o resultado False Positive passa a ser False Positive Confirmed.
Combine as fontes de dados: Mescle os dados extraídos do World-Check com os dados do sistema de origem, obtidos na etapa 3. Use o ID CustomerApplication como chave comum para criar um Event Log completo, do início ao fim, para cada cliente.
Estruture e enriqueça os dados: Reúna todos os eventos associados em uma única lista de registros. Preencha em cada registro todos os atributos obrigatórios (CustomerApplication, ActivityName, EventTime) e os atributos recomendados. Quando possível, calcule EventEndTime, por exemplo, usando a data e hora do evento seguinte do mesmo caso.
Exporte para CSV: Converta a lista final de eventos em um DataFrame do pandas. Reordene as colunas conforme o formato obrigatório e exporte o DataFrame para um arquivo CSV. Salve o arquivo com codificação UTF-8 para garantir a compatibilidade com o ProcessMind.

Configuração

Credenciais da API: São necessárias uma chave e um segredo válidos para a API de triagem do World-Check One. As credenciais devem ter as permissões necessárias para ler os dados de casos e de auditoria.
URL base da API: Configure o script com a URL base correta para o ambiente da API do World-Check, por exemplo, https://api.world-check.com/v2/.
Período: Inclua no script os parâmetros start_date e end_date para definir o período de extração. Para a análise inicial, recomenda-se um período de 3 a 6 meses. Para o monitoramento contínuo, execute o script em intervalos menores, como o dia ou a semana anterior.
Conexão com o sistema de origem: Você precisará dos dados de conexão com os sistemas anteriores e posteriores ao processo, como CRM ou plataforma bancária central, para buscar os eventos que não são de triagem. Esses dados podem incluir uma string de conexão com o banco de dados ou o endpoint e as credenciais de outra API.
Tratamento da paginação: Ao listar casos por meio da API, o script deve especificar o tamanho da página, geralmente chamado de limit. Um valor entre 50 e 100 costuma ser eficiente. A lógica deve recuperar corretamente todas as páginas.

Consulta de exemplo python

import requests
import pandas as pd
from datetime import datetime, timedelta

class=class="hl-string">"hl-comment"># --- Configuration and Placeholders ---
WC_API_KEY = class="hl-string">'[Your World-Check API Key]'
WC_API_SECRET = class="hl-string">'[Your World-Check API Secret]'
WC_API_BASE_URL = class="hl-string">'https://api.world-check.com/v2' class=class="hl-string">"hl-comment"># Use correct URL for your environment

class=class="hl-string">"hl-comment"># Date range for the extraction
START_DATE = (datetime.now() - timedelta(days=90)).strftime(class="hl-string">'%Y-%m-%dT%H:%M:%SZ')
END_DATE = datetime.now().strftime(class="hl-string">'%Y-%m-%dT%H:%M:%SZ')

class=class="hl-string">"hl-comment"># --- MOCK FUNCTIONS (Replace with actual data source connections) ---

def get_source_system_events(application_ids):
    class="hl-string">"""Simulates fetching pre- and post-screening events from a CRM or core system."""
    print(fclass="hl-string">'Fetching source system events for {len(application_ids)} applications...')
    mock_events = []
    for i, app_id in enumerate(application_ids):
        class=class="hl-string">"hl-comment"># Simulate initial application events
        mock_events.append({class="hl-string">'CustomerApplication': app_id, class="hl-string">'ActivityName': class="hl-string">'Application Submitted', class="hl-string">'EventTime': (datetime.now() - timedelta(days=i+5)).isoformat() + class="hl-string">'Z', class="hl-string">'DepartmentName': class="hl-string">'Sales'})
        class=class="hl-string">"hl-comment"># Simulate final outcome events
        if i % 3 == 0:
            mock_events.append({class="hl-string">'CustomerApplication': app_id, class="hl-string">'ActivityName': class="hl-string">'Application Approved', class="hl-string">'EventTime': (datetime.now() - timedelta(days=i)).isoformat() + class="hl-string">'Z', class="hl-string">'DepartmentName': class="hl-string">'Onboarding'})
            mock_events.append({class="hl-string">'CustomerApplication': app_id, class="hl-string">'ActivityName': class="hl-string">'Account Activated', class="hl-string">'EventTime': (datetime.now() - timedelta(days=i-1)).isoformat() + class="hl-string">'Z', class="hl-string">'DepartmentName': class="hl-string">'Operations'})
        else:
            mock_events.append({class="hl-string">'CustomerApplication': app_id, class="hl-string">'ActivityName': class="hl-string">'Application Rejected', class="hl-string">'EventTime': (datetime.now() - timedelta(days=i)).isoformat() + class="hl-string">'Z', class="hl-string">'DepartmentName': class="hl-string">'Compliance'})
    return mock_events

def get_worldcheck_cases(token):
    class="hl-string">"""Simulates fetching a list of cases from the World-Check API."""
    print(class="hl-string">'Fetching World-Check cases...')
    class=class="hl-string">"hl-comment"># In a real implementation, you would call GET /cases with date filters and handle pagination
    mock_case_list = [
        {class="hl-string">'caseId': class="hl-string">'0a1b2c3d-case-001', class="hl-string">'name': class="hl-string">'John Doe', class="hl-string">'caseSystemId': class="hl-string">'WC-001', class="hl-string">'customReference': class="hl-string">'APP-1001', class="hl-string">'creationDate': class="hl-string">'2023-10-01T10:00:00Z', class="hl-string">'riskLevel': class="hl-string">'Medium'},
        {class="hl-string">'caseId': class="hl-string">'0a1b2c3d-case-002', class="hl-string">'name': class="hl-string">'Jane Smith', class="hl-string">'caseSystemId': class="hl-string">'WC-002', class="hl-string">'customReference': class="hl-string">'APP-1002', class="hl-string">'creationDate': class="hl-string">'2023-10-02T11:30:00Z', class="hl-string">'riskLevel': class="hl-string">'Low'},
        {class="hl-string">'caseId': class="hl-string">'0a1b2c3d-case-003', class="hl-string">'name': class="hl-string">'Peter Jones', class="hl-string">'caseSystemId': class="hl-string">'WC-003', class="hl-string">'customReference': class="hl-string">'APP-1003', class="hl-string">'creationDate': class="hl-string">'2023-10-03T09:05:00Z', class="hl-string">'riskLevel': class="hl-string">'High'}
    ]
    return mock_case_list

def get_worldcheck_case_details(case_system_id, token):
    class="hl-string">"""Simulates fetching the audit trail and results for a single World-Check case."""
    print(fclass="hl-string">'Fetching details for case {case_system_id}...')
    class=class="hl-string">"hl-comment"># This mock data simulates a complex history for one case to generate multiple activities
    if case_system_id == class="hl-string">'WC-001':
        return {
            class="hl-string">'auditTrail': [
                {class="hl-string">'timestamp': class="hl-string">'2023-10-01T10:05:00Z', class="hl-string">'event': class="hl-string">'AUTOMATED_SCREENING', class="hl-string">'details': class="hl-string">'Screening performed', class="hl-string">'user': class="hl-string">'SYSTEM'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-01T10:06:00Z', class="hl-string">'event': class="hl-string">'MATCH_FOUND', class="hl-string">'details': class="hl-string">'Potential match identified', class="hl-string">'user': class="hl-string">'SYSTEM'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-02T14:00:00Z', class="hl-string">'event': class="hl-string">'REVIEW_STARTED', class="hl-string">'details': class="hl-string">'Case assigned', class="hl-string">'user': class="hl-string">'analyst1'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-02T15:30:00Z', class="hl-string">'event': class="hl-string">'MATCH_RESOLVED', class="hl-string">'details': class="hl-string">'Match resolved as False Positive', class="hl-string">'user': class="hl-string">'analyst1'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-03T11:00:00Z', class="hl-string">'event': class="hl-string">'ESCALATED', class="hl-string">'details': class="hl-string">'Case escalated to senior analyst', class="hl-string">'user': class="hl-string">'analyst1'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-04T09:00:00Z', class="hl-string">'event': class="hl-string">'INFORMATION_REQUESTED', class="hl-string">'details': class="hl-string">'Additional documents requested', class="hl-string">'user': class="hl-string">'senior_analyst'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-05T16:00:00Z', class="hl-string">'event': class="hl-string">'CASE_CLOSED', class="hl-string">'details': class="hl-string">'Case closed as Clear', class="hl-string">'user': class="hl-string">'senior_analyst'}
            ]
        }
    elif case_system_id == class="hl-string">'WC-003':
        return {
            class="hl-string">'auditTrail': [
                {class="hl-string">'timestamp': class="hl-string">'2023-10-03T09:10:00Z', class="hl-string">'event': class="hl-string">'AUTOMATED_SCREENING', class="hl-string">'details': class="hl-string">'Screening performed', class="hl-string">'user': class="hl-string">'SYSTEM'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-03T09:11:00Z', class="hl-string">'event': class="hl-string">'MATCH_FOUND', class="hl-string">'details': class="hl-string">'Potential match identified', class="hl-string">'user': class="hl-string">'SYSTEM'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-04T10:00:00Z', class="hl-string">'event': class="hl-string">'REVIEW_STARTED', class="hl-string">'details': class="hl-string">'Case assigned', class="hl-string">'user': class="hl-string">'analyst2'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-04T11:25:00Z', class="hl-string">'event': class="hl-string">'MATCH_RESOLVED', class="hl-string">'details': class="hl-string">'Match resolved as True Positive', class="hl-string">'user': class="hl-string">'analyst2'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-04T12:00:00Z', class="hl-string">'event': class="hl-string">'CASE_CLOSED', class="hl-string">'details': class="hl-string">'Case closed with matches', class="hl-string">'user': class="hl-string">'analyst2'}
            ]
        }
    else: class=class="hl-string">"hl-comment"># Simple class="hl-string">'Clear' case
        return {
            class="hl-string">'auditTrail': [
                {class="hl-string">'timestamp': class="hl-string">'2023-10-02T11:35:00Z', class="hl-string">'event': class="hl-string">'AUTOMATED_SCREENING', class="hl-string">'details': class="hl-string">'Screening performed', class="hl-string">'user': class="hl-string">'SYSTEM'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-02T11:36:00Z', class="hl-string">'event': class="hl-string">'CASE_CLOSED', class="hl-string">'details': class="hl-string">'Case closed as Clear', class="hl-string">'user': class="hl-string">'SYSTEM'}
            ]
        }

class=class="hl-string">"hl-comment"># --- Main Extraction Logic ---

def main():
    class="hl-string">"""Main function to run the extraction process."""
    class=class="hl-string">"hl-comment"># 1. Authenticate (real implementation)
    class=class="hl-string">"hl-comment"># token = get_wc_auth_token()
    token = class="hl-string">'mock_token' class=class="hl-string">"hl-comment"># Using a mock token for this example

    class=class="hl-string">"hl-comment"># 2. Get list of cases from World-Check
    cases = get_worldcheck_cases(token)
    if not cases:
        print(class="hl-string">'No cases found for the specified period.')
        return

    event_log = []

    class=class="hl-string">"hl-comment"># 3. Process each case from World-Check
    for case in cases:
        app_id = case.get(class="hl-string">'customReference')
        if not app_id:
            continue

        class=class="hl-string">"hl-comment"># Add class="hl-string">'Screening Request Created' event
        event_log.append({
            class="hl-string">'CustomerApplication': app_id,
            class="hl-string">'ActivityName': class="hl-string">'Screening Request Created',
            class="hl-string">'EventTime': case[class="hl-string">'creationDate'],
            class="hl-string">'ReviewerId': class="hl-string">'SYSTEM',
            class="hl-string">'DepartmentName': class="hl-string">'Compliance',
            class="hl-string">'RiskLevel': case.get(class="hl-string">'riskLevel')
        })

        details = get_worldcheck_case_details(case[class="hl-string">'caseSystemId'], token)
        for event in details.get(class="hl-string">'auditTrail', []):
            activity = None
            user = event.get(class="hl-string">'user', class="hl-string">'SYSTEM')
            department = class="hl-string">'Compliance' if user != class="hl-string">'SYSTEM' else class="hl-string">'System'
            
            class=class="hl-string">"hl-comment"># 4. Map audit trail events to activities
            if event[class="hl-string">'event'] == class="hl-string">'AUTOMATED_SCREENING':
                activity = class="hl-string">'Automated Screening Performed'
            elif event[class="hl-string">'event'] == class="hl-string">'MATCH_FOUND':
                activity = class="hl-string">'Potential Match Identified'
            elif event[class="hl-string">'event'] == class="hl-string">'REVIEW_STARTED':
                activity = class="hl-string">'Analyst Review Started'
            elif event[class="hl-string">'event'] == class="hl-string">'INFORMATION_REQUESTED':
                activity = class="hl-string">'Additional Information Requested'
            elif event[class="hl-string">'event'] == class="hl-string">'ESCALATED':
                activity = class="hl-string">'Case Escalated for Review'
            elif event[class="hl-string">'event'] == class="hl-string">'MATCH_RESOLVED' and class="hl-string">'False Positive' in event[class="hl-string">'details']:
                activity = class="hl-string">'False Positive Confirmed'
            elif event[class="hl-string">'event'] == class="hl-string">'MATCH_RESOLVED' and class="hl-string">'True Positive' in event[class="hl-string">'details']:
                activity = class="hl-string">'True Match Confirmed'
            elif event[class="hl-string">'event'] == class="hl-string">'CASE_CLOSED' and class="hl-string">'Clear' in event[class="hl-string">'details']:
                activity = class="hl-string">'Screening Completed - Clear'
            elif event[class="hl-string">'event'] == class="hl-string">'CASE_CLOSED' and class="hl-string">'matches' in event[class="hl-string">'details']:
                activity = class="hl-string">'Screening Completed - Match Found'

            if activity:
                event_log.append({
                    class="hl-string">'CustomerApplication': app_id,
                    class="hl-string">'ActivityName': activity,
                    class="hl-string">'EventTime': event[class="hl-string">'timestamp'],
                    class="hl-string">'ReviewerId': user,
                    class="hl-string">'DepartmentName': department,
                    class="hl-string">'RiskLevel': case.get(class="hl-string">'riskLevel')
                })
    
    class=class="hl-string">"hl-comment"># 5. Get events from source system
    application_ids = [case[class="hl-string">'customReference'] for case in cases if case.get(class="hl-string">'customReference')]
    source_events = get_source_system_events(application_ids)
    event_log.extend(source_events)

    class=class="hl-string">"hl-comment"># 6. Create and format DataFrame
    if not event_log:
        print(class="hl-string">'No events were generated.')
        return

    df = pd.DataFrame(event_log)
    df[class="hl-string">'EventTime'] = pd.to_datetime(df[class="hl-string">'EventTime'])
    df = df.sort_values(by=[class="hl-string">'CustomerApplication', class="hl-string">'EventTime'])

    class=class="hl-string">"hl-comment"># Add EventEndTime by shifting the EventTime of the next event
    df[class="hl-string">'EventEndTime'] = df.groupby(class="hl-string">'CustomerApplication')[class="hl-string">'EventTime'].shift(-1)
    
    class=class="hl-string">"hl-comment"># Add placeholder for non-extractable attribute
    df[class="hl-string">'SlaTargetDate'] = pd.NaT

    class=class="hl-string">"hl-comment"># 7. Finalize and Export
    output_columns = [
        class="hl-string">'CustomerApplication',
        class="hl-string">'ActivityName',
        class="hl-string">'EventTime',
        class="hl-string">'EventEndTime',
        class="hl-string">'ReviewerId',
        class="hl-string">'DepartmentName',
        class="hl-string">'RiskLevel',
        class="hl-string">'SlaTargetDate'
    ]
    class=class="hl-string">"hl-comment"># Ensure all required columns exist, even if empty
    for col in output_columns:
        if col not in df.columns:
            df[col] = None
    
    df = df[output_columns]

    output_filename = class="hl-string">'event_log_worldcheck.csv'
    df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%S.%fZ')
    print(fclass="hl-string">'Successfully exported event log to {output_filename}')

if __name__ == class="hl-string">'__main__':
    main()

Pronto para começar?

Use este Template de dados para dar início à mineração do processo de integração de clientes no KYC. Siga estas orientações para encontrar insights valiosos e promover melhorias significativas nas operações.

Voltar ao guia de melhoria

Baixar Template

Otimize agora a integração de clientes no KYC e reforce a conformidade

Ofereça uma integração de clientes sem atritos e reduza o prazo para apenas 24 horas.

Começar o teste grátis

Não é necessário informar o cartão de crédito. Experimente grátis por 14 dias.

Seu Template de dados para integração de clientes no processo KYC

Seu Template de dados para integração de clientes no processo KYC

Atributos da integração de clientes no processo KYC

Atividades da integração de clientes no processo KYC

Guias de extração

Exportação de casos e do registro de auditoria do Refinitiv World-Check One

Etapas

Configuração

Consulta de exemplo sql

Script Python usando a API de triagem do World-Check One

Etapas

Configuração

Consulta de exemplo python

Pronto para começar?

Otimize agora a integração de clientes no KYC e reforce a conformidade