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

Seu Template de dados para onboarding de clientes KYC

Refinitiv World-Check

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

Seu Template de dados para onboarding de clientes KYC

Este Template orienta você na coleta dos dados essenciais para analisar seu processo de onboarding de clientes KYC. Ele apresenta os principais atributos a serem capturados, as atividades mais importantes a serem acompanhadas e orientações para extrair essas informações dos sistemas de origem. Use este recurso para garantir que você tenha todos os dados necessários para uma análise e melhoria eficazes do processo.

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

Novo em Event Logs? Aprenda como criar um Event Log de Process Mining.

Baixar Template

Atributos da integração de clientes KYC

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

3 Obrigatório 5 Recomendado 11 Opcional

	Nome	Descrição
	Hora do evento EventTime	O timestamp que indica quando uma atividade ou evento específico ocorreu.
Descrição A hora do evento fornece a data e a hora exatas em que uma atividade foi registrada. Esse timestamp é a base cronológica do processo, permitindo ordenar corretamente os eventos para reconstruir o histórico do caso. Este atributo é essencial para todas as análises baseadas em tempo no Process Mining. Ele é usado para calcular as durações 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 timestamps precisos, é impossível entender a performance do processo e identificar gargalos temporais. Por que isso importa O timestamp de cada atividade é essencial para calcular todas as métricas baseadas em duração, descobrir a sequência do processo e realizar análises de gargalos. Onde obter Este é um campo padrão em qualquer Event Log ou tabela de trilha de auditoria, geralmente chamado de 'Timestamp', 'EventDate' ou 'CreationDate'. Exemplos 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:15Z
	Nome da atividade ActivityName	O nome de um evento ou tarefa de negócio específico que ocorreu no processo de onboarding KYC.
Descrição O nome da atividade descreve uma única etapa ou evento na jornada de onboarding do cliente, como 'Solicitação enviada', 'Análise do analista iniciada' ou 'Triagem concluída - sem correspondência'. Essas atividades formam os nós do mapa do processo, oferecendo uma visão detalhada do Workflow de ponta a ponta. Analisar atividades é o núcleo do Process Mining. Ao acompanhar a sequência e a frequência de diferentes atividades, os analistas conseguem descobrir o fluxo real do processo, identificar caminhos comuns, detectar desvios do procedimento padrão e localizar etapas específicas que causam atrasos ou retrabalho. Este atributo é essencial para criar mapas de processo e calcular métricas no nível da atividade. Por que isso importa Este atributo define as etapas individuais do processo, sendo essencial para descobrir e visualizar o fluxo do processo e identificar gargalos. Onde obter Essas informações normalmente são encontradas em Event Logs ou tabelas de trilha de auditoria, muitas vezes associadas a alterações de status na entidade de gerenciamento de casos. Exemplos Potencial correspondência identificadaAnálise do analista iniciadaFalso positivo confirmadoSolicitação aprovada
	Solicitação do cliente CustomerApplication	O identificador exclusivo da solicitação de onboarding de um único cliente, usado como identificador principal do caso.
Descrição A solicitação do cliente é o identificador central do caso que agrupa todos os eventos e atividades relacionados à jornada de onboarding de um único cliente. Ela permite acompanhar de forma completa e cronológica o progresso de cada cliente durante todo o processo de Know Your Customer (KYC), desde o envio inicial até a decisão final. Na análise de Process Mining, este atributo é fundamental para reconstruir a jornada completa de cada solicitação. Ele permite visualizar os fluxos do processo, calcular os tempos de ciclo totais e identificar variantes. Ao analisar casos agrupados por esse identificador, as organizações conseguem entender os diferentes caminhos que uma solicitação pode seguir, identificar gargalos e comparar a eficiência de vários processos de onboarding. Por que isso importa Este é o identificador essencial do caso que conecta todas as atividades relacionadas, permitindo analisar o processo de onboarding do cliente de ponta a ponta. Onde obter Este identificador normalmente é 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-alvo do SLA SlaTargetDate	A data-alvo até a qual o processo de onboarding do cliente deve ser concluído.
Descrição A data-alvo do SLA é o prazo para concluir todo o caso de onboarding, conforme definido pelo acordo de nível de serviço com o cliente ou pelas políticas internas. Essa data é a referência usada para comparar os tempos reais de conclusão. Este atributo é fundamental para o Dashboard 'Análise de cumprimento e violações de SLA'. Ele é usado para calcular se um caso foi concluído dentro do prazo. Analisar violações de SLA ajuda a identificar problemas sistêmicos no processo 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 Esta é a referência para medir a performance dentro do prazo e é essencial para calcular a taxa de cumprimento do SLA e analisar violações. Onde obter Essa data costuma ser calculada com base na data de envio da solicitação e em regras de negócio. Ela pode ser armazenada como um campo no registro do caso. Exemplos 2023-11-10T17:00:00Z2023-11-15T17:00:00Z2023-11-20T17:00:00Z
	Departamento DepartmentName	O departamento ou a equipe funcional responsável por executar a atividade.
Descrição Este atributo especifica a unidade de negócio ou a equipe, como 'Onboarding', 'Conformidade' ou 'Garantia da qualidade', à qual o usuário pertence. Ele permite analisar o processo em um nível organizacional mais amplo do que o usuário individual. Analisar por departamento é essencial para identificar gargalos entre departamentos e medir os tempos de transferência. Isso ajuda a visualizar como o trabalho flui entre diferentes equipes e onde ocorrem atrasos nessas transições. Essa visão é muito valiosa 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 diferentes equipes. Onde obter Essas informações podem ser armazenadas no perfil do usuário no sistema ou em um sistema de RH associado. Talvez seja necessário relacioná-las aos dados dos eventos usando o ID do usuário. Exemplos Equipe de onboardingAnálise de conformidadeAlta administração
	Hora de término do evento EventEndTime	O timestamp que indica quando uma atividade ou evento específico foi concluído.
Descrição A hora de término do evento marca a conclusão de uma atividade. Embora muitos eventos possam ser modelados como instantâneos, com StartTime igual a EndTime, algumas atividades têm uma duração mensurável, como 'Análise do analista iniciada' e 'Análise do analista concluída'. Ter os horários de início e término permite medir o tempo de processamento com precisão. Na análise de processos, ter um horário de término é essencial para calcular o tempo exato de processamento de uma atividade, em vez do tempo de ciclo, que inclui o tempo de espera. Isso ajuda a diferenciar o tempo em que um caso está sendo trabalhado ativamente do tempo em que permanece parado em uma fila. Essa distinção é fundamental para otimizar recursos e analisar a eficiência. Por que isso importa Permite calcular com precisão o tempo de processamento da atividade, separando o tempo de trabalho ativo do tempo de espera ocioso para uma análise de performance mais precisa. Onde obter Para atividades com duração, esse dado pode ser armazenado em um campo separado, como 'CompletionDate' ou 'EndDate', nas tabelas de Event Log ou de trilha de auditoria. Exemplos 2023-10-26T10:45:00Z2023-10-26T12:00:00Z2023-10-27T15:00:00Z
	ID do analista ReviewerId	O identificador do usuário, analista ou agente automatizado que executou a atividade.
Descrição O ID do analista, ou usuário, indica quem executou uma determinada tarefa no processo KYC. Pode ser um analista de conformidade, um especialista de onboarding ou uma conta de sistema para atividades automatizadas. Acompanhar essas informações oferece visibilidade sobre a distribuição da carga de trabalho e a performance individual. Este atributo é essencial para análises baseadas em recursos. Ele ajuda a entender diferenças de performance entre usuários ou equipes, identificar necessidades de treinamento e otimizar o equilíbrio da carga de trabalho. Também é um componente importante para analisar transferências, redes sociais e a utilização de 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, o que é essencial para otimizar recursos. Onde obter Normalmente encontrado em Event Logs ou trilhas de auditoria, muitas vezes com nomes como 'UserID', 'PerformedBy' ou 'Owner'. Exemplos analyst_jdoesystem_auto_screenermanager_bsmith
	Nível de risco RiskLevel	A 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 crítica nos processos KYC, pois determina o nível 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 do negócio. Essa classificação pode influenciar significativamente o caminho seguido pela solicitação. Na análise de processos, segmentar os casos por nível de risco é essencial. Isso ajuda a explicar variações nos tempos de ciclo e nos fluxos do processo. Por exemplo, solicitações de alto risco podem exigir mais etapas e levar mais tempo. Este atributo é fundamental para os Dashboards 'Taxa e motivos de rejeição de solicitações' e 'Tempo de ciclo para iniciar a verificação de antecedentes', ajudando a entender como o risco afeta os resultados e a eficiência. Por que isso importa Segmentar o processo por nível de risco é essencial para entender por que determinados casos demoram mais ou seguem caminhos diferentes e para analisar as taxas de rejeição. Onde obter Este é um dado central do registro da solicitação do cliente ou do caso. Consulte o módulo de gerenciamento de casos no Refinitiv World-Check. Exemplos BaixoMédioAlto
	Canal da solicitação ApplicationChannel	O 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 a origem do envio da solicitação do cliente. Diferentes canais podem apresentar níveis variados de completude e qualidade dos dados, além de perfis demográficos distintos, o que pode afetar o processo subsequente. Este 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 diferentes canais, a organização consegue identificar quais são mais eficientes e quais podem exigir melhorias no processo. Essa análise apoia decisões estratégicas sobre alocação de recursos e investimentos nos canais. Por que isso importa Ajuda a analisar a performance e a eficiência de diferentes canais de envio, apoiando decisões estratégicas sobre tecnologia e experiência do cliente. Onde obter Essas informações normalmente são capturadas no início do processo e armazenadas como um atributo no registro da solicitação. Exemplos Portal onlineAplicativo móvelNa agênciaGerente de relacionamento
	É automatizado IsAutomated	Um indicador que informa se a atividade foi executada por um sistema (verdadeiro) ou por uma pessoa (falso).
Descrição Este atributo booleano diferencia entre tarefas automatizadas do sistema e atividades manuais realizadas por usuários. Por exemplo, “Automated Screening Performed” seria marcado como automatizado, enquanto “Analyst Review Started” seria manual. Essa distinção é fundamental para analisar a automação. Ela ajuda a medir o impacto da automação na eficiência do processo, identificar quais tarefas manuais são candidatas à automação futura e entender a interação entre pessoas e sistemas. Assim, você consegue separar claramente o tempo de processamento do sistema do tempo de execução manual. Por que isso importa Diferencia atividades do sistema e atividades humanas, o que é essencial para medir o impacto da automação e identificar novas oportunidades de automação. Onde obter Normalmente, isso é definido com base no nome da atividade ou no ID do usuário associado ao evento, por exemplo, quando o usuário é uma conta do “sistema”. Exemplos truefalse
	É retrabalho IsRework	Um indicador que mostra se uma atividade está sendo realizada pela segunda vez ou mais dentro do mesmo caso.
Descrição IsRework é um atributo booleano calculado que identifica quando uma atividade é repetida dentro do mesmo caso de solicitação de um cliente. Por exemplo, se “Risk Assessment Performed” acontecer mais de uma vez para uma única solicitação, as ocorrências seguintes serão marcadas como retrabalho. Esse atributo é fundamental para identificar ineficiências, loops e repetições desnecessárias no processo. Ele dá suporte direto ao Dashboard “Risk Assessment Rework and Efficiency” e ao KPI “Risk Assessment Rework Rate”. 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 ciclos mais longos. Por que isso importa Evidencia ineficiências no processo ao sinalizar atividades repetidas, permitindo analisar loops de retrabalho, melhorar a qualidade e reduzir os tempos de ciclo. Onde obter Isso é calculado durante a transformação dos dados, analisando a sequência de atividades em cada caso e sinalizando todas as ocorrências de uma atividade que não sejam a primeira. Exemplos truefalse
	ID da correspondência MatchId	O 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 da correspondência para acompanhar essa descoberta específica. Esse ID conecta o caso da solicitação ao registro específico no banco de dados do World-Check que acionou o alerta. Este atributo é útil para análises detalhadas de conformidade. Ele permite que os 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 alertas são mais comuns ou demoram mais para ser resolvidos. Ele oferece um nível mais profundo de detalhe sobre a atividade 'Potencial correspondência identificada'. Por que isso importa Fornece uma conexão detalhada com os resultados específicos da triagem, permitindo uma análise mais profunda dos tempos de resolução e dos tipos de alerta. Onde obter 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	Um identificador exclusivo da entidade do cliente que está passando pelo onboarding.
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. Este atributo conecta o processo de onboarding 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 provenientes de um CRM ou sistema de dados mestres. Isso possibilita uma visão mais completa da jornada do cliente, além de uma única instância de onboarding. Por que isso importa Conecta o caso de onboarding a um cliente específico, permitindo analisar solicitações recorrentes e enriquecer os dados com informações do cadastro principal. Onde obter Este seria um campo importante no registro da solicitação ou do caso, conectando-o aos dados mestres do cliente. Exemplos CUST-98765CUST-98766CUST-98767
	Motivo da rejeição RejectionReason	O motivo específico informado quando uma solicitação de cliente é rejeitada.
Descrição Quando uma solicitação é rejeitada, o motivo da rejeição registra por que essa decisão foi tomada. Os motivos podem incluir 'Correspondência em lista de sanções', 'Documentação incompleta' ou 'Perfil de alto risco'. Isso fornece feedback estruturado e valioso sobre a qualidade das solicitações recebidas e a eficácia do processo de triagem. Este atributo é o principal direcionador do Dashboard 'Taxa e motivos de rejeição de solicitações'. Analisar esses motivos ajuda a identificar as causas-raiz das rejeições, o que pode levar a melhorias no processo, uma comunicação mais clara com os solicitantes e, potencialmente, à redução de rejeições desnecessárias. Ele fornece contexto qualitativo para o KPI quantitativo da taxa de rejeição. Por que isso importa Fornece a causa-raiz das rejeições de solicitações, o que é essencial para identificar áreas de melhoria no processo de onboarding e reduzir a taxa de rejeição. Onde obter Esse dado seria registrado quando ocorresse o evento 'Solicitação rejeitada', provavelmente como um campo no registro do caso ou da solicitação. Exemplos Correspondência com PEPOcorrência em lista de sançõesFalha na verificação do documentoMídia negativa
	País do cliente CustomerCountry	O país de residência ou de constituição do cliente.
Descrição Este 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. Diferentes jurisdições têm regras distintas, que podem afetar o fluxo e a duração do processo. Analisar o processo por país permite comparar a performance entre diferentes regiões, identificar gargalos específicos de cada localidade e garantir a conformidade com as regulamentações locais. Isso acrescenta uma dimensão geográfica à análise do processo, revelando diferenças operacionais importantes. Por que isso importa Permite analisar o processo geograficamente, ajudando a identificar variações regionais de performance, risco e requisitos de conformidade. Onde obter Este é um campo padrão no perfil do cliente ou no formulário de solicitação. Exemplos USAGBRSGPDEU
	Sistema de origem SourceSystem	O sistema do qual os dados dos eventos foram extraídos, neste caso, o Refinitiv World-Check.
Descrição Este atributo identifica a origem dos dados do processo. Embora possa ter um valor constante em uma extração de fonte única, ele se torna essencial quando dados de vários sistemas, como um CRM e o World-Check, são combinados para criar uma visão completa do processo. Na análise, isso 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. Isso garante que a linhagem dos dados seja clara e auditável. Por que isso importa Identifica a origem dos dados, o que é essencial para a governança e a validação dos dados e para combinar dados de várias fontes. Onde obter Geralmente é um valor estático adicionado durante o processo de extração, transformação e carregamento (ETL) dos dados para identificar o conjunto de dados. Exemplos Refinitiv World-CheckWorldCheckOne
	SLA violado SlaBreached	Um indicador booleano que mostra se o caso de onboarding foi concluído depois da data-alvo do SLA.
Descrição Este atributo é um indicador calculado que mostra se um caso violou o SLA. Ele é determinado comparando o timestamp da atividade final de conclusão, como “Application Approved” ou “Application Rejected”, com o campo “SlaTargetDate” do caso. Esse indicador é a base do Dashboard “SLA Adherence and Breach Analysis” e do KPI “SLA Adherence Rate”. Ele simplifica a análise, permitindo que você filtre rapidamente todos os casos com SLA violado. Ao analisar as características desses casos, as organizações conseguem identificar as causas raiz dos atrasos e direcionar os esforços de melhoria com mais eficiência. Por que isso importa Mede diretamente a conformidade com os SLAs, facilitando a filtragem e a análise das causas raiz dos casos atrasados. Onde obter Isso é calculado durante a transformação dos dados, comparando o timestamp da atividade final de um caso com o campo SlaTargetDate. Exemplos truefalse
	Tipo de cliente CustomerType	A classificação do cliente, como Pessoa física, Empresa ou Trust.
Descrição O tipo de cliente categoriza a entidade que está passando pelo onboarding. Diferentes tipos de clientes costumam ter requisitos de onboarding, perfis de risco e obrigações regulatórias distintos. Por exemplo, fazer o onboarding de uma empresa normalmente é mais complexo do que o de uma pessoa física. Este atributo é usado para análises de segmentação, especialmente no Dashboard 'Performance por tipo de cliente KYC'. Ele permite comparar a eficiência do processo, os tempos de ciclo e as taxas de rejeição entre diferentes segmentos de clientes. Isso ajuda as organizações a adaptar e otimizar a experiência de onboarding para cada tipo de cliente. Por que isso importa Permite comparar a performance entre diferentes segmentos de clientes, ajudando a adaptar e otimizar o processo de onboarding para cada tipo. Onde obter Este é um atributo fundamental armazenado no registro do cliente ou da solicitação no sistema de origem. Exemplos Pessoa físicaPessoa jurídicaOrganização sem fins lucrativosTrust
	Última atualização dos dados LastDataUpdate	O timestamp em que os dados deste evento foram atualizados ou extraídos pela última vez do sistema de origem.
Descrição Este 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 a atualidade dos Dashboards e das análises de Process Mining. Para fins analíticos, ele permite saber se você está consultando dados quase em tempo real ou um retrato de um momento específico. É essencial para a governança de dados e para alinhar as expectativas dos usuários sobre a atualidade dos insights fornecidos. Por que isso importa Fornece um contexto importante sobre a atualização dos dados, garantindo que os usuários entendam o quanto a análise do processo está atualizada. Onde obter Este timestamp é gerado e adicionado durante o processo de extração de dados (ETL). Exemplos 2023-11-01T02:00:00Z2023-11-02T02:00:00Z

Obrigatório Recomendado Opcional

Atividades de integração de clientes KYC

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

8 Recomendado 6 Opcional

	Atividade	Descrição
	Análise do analista iniciada	Um analista de conformidade inicia a investigação manual de possíveis correspondências para uma solicitação de cliente. Isso envolve avaliar os detalhes das possíveis correspondências em relação às informações do cliente para determinar a relevância.
Por que isso importa Isso marca o início da análise manual de conformidade, um gargalo comum. Medir o tempo entre 'Potencial correspondência identificada' e esta atividade revela atrasos na fila, enquanto a duração da análise indica a eficiência do analista. Onde obter Isso pode ser inferido quando um analista 'assume' ou abre um caso na fila de análise. O sistema pode registrar esse evento explicitamente em uma trilha de auditoria quando o status do caso muda para 'Em análise' ou quando o caso é atribuído a um usuário específico. Captura Inferido a partir da alteração do status do caso para 'Em análise' ou da atribuição do caso a um analista. Tipo de evento inferred
	Conta ativada	A conta do cliente é criada e ativada no sistema principal, concluindo a jornada de onboarding. Isso ocorre após a aprovação final da solicitação e deixa a conta pronta para uso.
Por que isso importa Esta é a etapa final que entrega valor no processo. A duração entre o envio da solicitação e a ativação da conta é uma métrica importante para a eficiência operacional e a satisfação do cliente. Onde obter Este evento não é capturado no World-Check. Ele é registrado no sistema bancário principal ou no sistema de contas de clientes e deve ser relacionado usando o ID da solicitação do cliente. Captura Evento registrado no sistema principal de contas após a ativação da conta. Tipo de evento explicit
	Correspondência verdadeira confirmada	Um analista confirma que uma possível correspondência é de fato o cliente analisado, identificando um risco potencial. Este é um marco crítico que normalmente aciona uma diligência adicional ou a rejeição da solicitação.
Por que isso importa Este é um resultado importante para a mitigação de riscos e um momento decisivo no processo. Ele influencia diretamente a decisão final sobre a solicitação do cliente e é essencial para relatórios e análises de conformidade. Onde obter Esta é uma ação explícita do usuário em que o analista classifica uma correspondência específica como 'Correspondência verdadeira' ou 'Correspondência confirmada'. Este evento é registrado na trilha de auditoria do caso. Captura Registrado quando um analista confirma formalmente uma correspondência no sistema. Tipo de evento explicit
	Solicitação de triagem criada	Um novo caso de verificação é criado formalmente para uma solicitação de cliente no sistema Refinitiv World-Check. Isso é acionado por uma chamada de API ou por uma entrada manual de um sistema anterior e representa o início da verificação de inteligência de risco.
Por que isso importa Isso marca o início oficial do subprocesso de verificação. O tempo entre Application Submitted e esta atividade revela atrasos nas transferências entre o sistema da área de negócio e a função de conformidade. Onde obter Registrado nos logs de gerenciamento de casos ou na trilha de auditoria do World-Check. O evento de criação e seu registro de data e hora para o caso ou ID da entidade específica seriam utilizados. Captura Registrado automaticamente quando um novo caso de verificação é criado no sistema. Tipo de evento explicit
	Solicitação enviada	Esta atividade marca o início do processo de onboarding de KYC, quando um cliente envia sua solicitação. Esse evento geralmente é registrado em um CRM ou sistema central de solicitações, que então aciona o processo de verificação no Refinitiv World-Check.
Por que isso importa Este é o principal evento de início da jornada de onboarding do cliente de ponta a ponta. Analisar o tempo entre este ponto e a conclusão fornece o tempo total do ciclo de onboarding, que é fundamental para medir a experiência do cliente e o cumprimento dos SLAs. Onde obter Este evento não é nativo do World-Check. Ele precisa ser obtido de um sistema anterior, como um CRM ou uma plataforma de gerenciamento de contas de clientes, e correlacionado pelo Customer Application ID. Captura Evento registrado no sistema de aplicação de origem no momento do envio inicial. Tipo de evento explicit
	Solicitação rejeitada	A solicitação do cliente é formalmente rejeitada, muitas vezes devido a uma 'Correspondência encontrada' no World-Check ou a outros fatores de risco. Este evento é o resultado negativo final do processo de onboarding.
Por que isso importa Este é o principal ponto final de falha do processo. Analisar os eventos de rejeição, especialmente os motivos e as atividades anteriores, é essencial para melhorar o processo e reduzir rejeições desnecessárias. Onde obter Esta decisão final de negócio é registrada no CRM upstream ou no sistema principal da aplicação, não no próprio World-Check. Os dados devem ser obtidos desse sistema. Captura Evento registrado no sistema de aplicação de origem, geralmente com um código de motivo de rejeição correspondente. Tipo de evento explicit
	Triagem concluída - correspondência encontrada	O caso de triagem é oficialmente encerrado com o resultado 'Correspondência encontrada', indicando que um risco confirmado foi identificado. Essa decisão aciona um processo subsequente diferente, como diligência reforçada ou rejeição.
Por que isso importa Este é o principal ponto final do 'caminho infeliz' do processo de triagem. Analisar esses casos ajuda a entender os perfis de risco e a eficácia dos controles de triagem. Onde obter Inferido a partir da alteração do status final do caso para 'Correspondência encontrada', 'Risco identificado' ou 'Encerrado - positivo'. É usado o timestamp dessa alteração final de status. Captura Derivado do timestamp do status final do caso que indica uma correspondência confirmada. Tipo de evento inferred
	Triagem concluída - sem correspondência	O caso de triagem é oficialmente encerrado com o resultado 'Sem correspondência', indicando que nenhuma correspondência verdadeira foi encontrada. Essa decisão é comunicada de volta ao sistema de origem, permitindo que o processo de onboarding avance.
Por que isso importa Esta atividade representa a conclusão bem-sucedida, o 'caminho feliz', do processo de triagem. Ela serve como um ponto final importante para medir o tempo de ciclo de solicitações padrão e de baixo risco. Onde obter Inferido a partir da alteração do status final do caso para 'Sem correspondência', 'Concluído' ou 'Encerrado - nenhuma correspondência'. É usado o timestamp dessa alteração final de status. Captura Derivado do timestamp do status final do caso que indica um resultado sem correspondência. Tipo de evento inferred
	Caso escalado para análise	Um analista de primeiro nível escala um caso complexo ou de alto risco para um analista sênior ou gerente tomar a decisão final. Este é um ponto importante de transferência dentro da equipe de conformidade.
Por que isso importa Os escalonamentos costumam criar gargalos e aumentar o tempo de ciclo. Analisar a frequência e os motivos dos escalonamentos pode destacar necessidades de treinamento para analistas juniores ou ambiguidades nas políticas de análise. Onde obter Registrado como uma ação explícita no Workflow ou na trilha de auditoria do caso. Também pode ser inferido por uma alteração no usuário atribuído ao caso, especialmente quando a atribuição passa para um usuário com permissões mais elevadas. Captura Registrado por meio de um botão 'Escalonar' dedicado ou de uma ação de Workflow dentro do caso. Tipo de evento explicit
	Falso positivo confirmado	O analista conclui que uma possível correspondência não é a mesma pessoa ou entidade do cliente analisado. A correspondência é descartada, e a triagem desse alerta específico é encerrada.
Por que isso importa Este é um resultado comum do processo de análise. Entender quanto tempo é necessário para classificar falsos positivos ajuda a medir a eficiência dos analistas e a precisão da lógica de triagem automatizada. Onde obter Esta é uma ação explícita do usuário em que o analista classifica uma correspondência específica como 'Falso positivo' ou 'Não é uma correspondência'. Essa ação normalmente é registrada no histórico do caso. Captura 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 são necessárias mais informações para resolver a possível correspondência e as solicita à unidade de negócio. Isso coloca o caso em estado pendente até que as informações sejam fornecidas.
Por que isso importa A ocorrência frequente desta atividade indica problemas na qualidade dos dados iniciais fornecidos para a triagem. Esta atividade introduz atrasos significativos, pois depende de equipes externas, e é um dos principais fatores para tempos de ciclo longos. Onde obter Pode ser uma ação explícita do usuário registrada nas notas do caso ou no log de auditoria. Como alternativa, pode ser inferida a partir da alteração do status do caso para 'Informações pendentes' ou 'RFI'. Captura Registrado quando um analista usa um recurso para sinalizar que o caso precisa de mais informações. Tipo de evento explicit
	Potencial correspondência identificada	O processo de triagem automatizada encontrou uma ou mais possíveis correspondências que exigem análise manual por um analista. Este evento transfere o caso de um estado automatizado para uma fila de investigação manual.
Por que isso importa Esta atividade é um ponto crítico de ramificação no processo. Casos com possíveis correspondências seguem um caminho mais longo e complexo, e acompanhar esse ponto ajuda no planejamento de recursos e na análise de gargalos da equipe de análise. Onde obter Inferido a partir da alteração do status do caso para 'Análise necessária', 'Potencial correspondência' ou um estado semelhante no módulo de gerenciamento de casos do World-Check. Captura Derivado de uma alteração no status do caso que indica a necessidade de análise 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 todas as outras verificações necessárias. Este evento normalmente ocorre no sistema de origem depois que o World-Check retorna um resultado 'Sem correspondência'.
Por que isso importa Isso marca o resultado de negócio bem-sucedido do processo de onboarding. Acompanhar o tempo desde o envio até este ponto revela o 'tempo até o sim' completo para um novo cliente. Onde obter Este evento não é nativo do World-Check. Ele deve ser obtido do CRM upstream ou do sistema principal da aplicação, que toma a decisão final de negócio. Captura Evento registrado no sistema de aplicação de origem após a aprovação final. Tipo de evento explicit
	Triagem automatizada realizada	O sistema World-Check verifica automaticamente os dados do cliente em sua base de inteligência de risco. Esta é uma atividade conduzida pelo sistema que produz um conjunto inicial de resultados, como possíveis correspondências ou um status sem correspondências.
Por que isso importa Esta atividade é a primeira etapa que agrega valor no processo de triagem. Atrasos antes desse ponto indicam problemas de disponibilidade do sistema ou dos dados, enquanto o resultado determina a carga de trabalho manual subsequente. Onde obter Este evento pode ser registrado explicitamente na trilha de auditoria do caso ou inferido a partir do timestamp em que os resultados da triagem inicial ficam disponíveis para o caso. Captura Entrada de log do sistema gerada após a conclusão da varredura automatizada do banco de dados. Tipo de evento explicit

Recomendado Opcional

Guias de extração

Como obter seus dados do Refinitiv World-Check

Etapas

Faça login no World-Check One: acesse o portal Refinitiv World-Check One usando suas credenciais.
Acesse o Case Management: abra a seção Case Management, onde todos os casos de screening são armazenados e gerenciados.
Prepare a exportação do relatório de casos: acesse o recurso de relatórios ou exportação no Case Management. Ele pode aparecer como “Export Cases” ou “Case Report”.
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, como Clear ou Match Found, e ao nível de risco.
Exporte os dados do Case Management: defina o intervalo de datas, normalmente cobrindo 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 como arquivo CSV e nomeie-o como case_report.csv.
Prepare a exportação do Audit Trail: acesse a seção de relatório do Audit Trail ou Audit Log do World-Check One. Ela contém o histórico detalhado de eventos de cada caso.
Configure e exporte o Audit Trail: selecione todas as colunas relevantes, incluindo o ID do caso, o nome ou a descrição do evento, o timestamp do evento e o usuário que realizou a ação. Exporte esses dados para o mesmo intervalo de datas do relatório de casos. Salve o arquivo como audit_trail.csv.
Obtenha as etapas externas do processo: extraia os dados das atividades que ocorrem fora do World-Check, como Application Submitted, Application Approved, Account Activated e Application Rejected. Normalmente, esses dados vêm de um CRM ou sistema bancário central. Exporte-os com o ID CustomerApplication e os timestamps 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.
Mapeie os eventos de auditoria para as atividades: processe o arquivo audit_trail.csv. Mapeie as descrições brutas dos eventos do Audit Log para os valores padronizados de ActivityName. Por exemplo, uma entrada do Audit Log como “Case Assigned to Analyst” se torna “Analyst Review Started”.
Mapeie as alterações de status do caso para as atividades: processe o arquivo case_report.csv para gerar atividades com base nas alterações de status. Use a data de resolução do caso e o status final para criar os eventos “Screening Completed - Clear” ou “Screening Completed - Match Found”.
Crie o Event Log final: una todos os dados processados dos diferentes arquivos de origem em um único arquivo CSV. Garanta que o arquivo final contenha as colunas obrigatórias: CustomerApplication, ActivityName e EventTime, além dos atributos recomendados. Salve esse arquivo para fazer o upload na ferramenta de Process Mining.

Configuração

Tipos de relatório: você precisará gerar pelo menos dois relatórios separados: um relatório resumido do Case Management e um relatório detalhado do Audit Trail.
Intervalo de datas: para uma análise inicial, selecione um intervalo de pelo menos 3 a 6 meses, capturando casos concluídos e em andamento suficientes. Garanta que o intervalo seja consistente em todos os arquivos exportados.
Formato de exportação: escolha CSV (valores separados por vírgula) como formato de exportação para facilitar o processamento.
Colunas principais (relatório de casos): garanta que a exportação de casos inclua ID do caso, timestamp de criação, timestamp de resolução, status final, analista responsável e nível de risco.
Colunas principais (relatório do Audit Trail): garanta que a exportação do Audit Log inclua ID do caso, descrição do evento, timestamp do evento e ID do usuário.
Pré-requisitos: é necessário ter acesso ao portal World-Check One com permissões para visualizar e exportar dados do Case Management e do Audit Log. Isso pode exigir privilégios superiores aos de uma função padrão de analista.

a 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: garanta que o Python 3.6 ou superior esteja instalado, junto com as bibliotecas requests e pandas. Obtenha sua API Key e seu API Secret do World-Check One com seu representante da Refinitiv ou no portal do desenvolvedor. Armazene essas credenciais com segurança.
Desenvolva a lógica de autenticação: no seu script Python, crie uma função para enviar uma solicitação POST ao endpoint de autenticação do World-Check One. Use sua API Key e seu Secret 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 eventos como Application Submitted, Application Approved, Account Activated e Application Rejected dessa origem. Isso pode ser feito por meio de uma consulta ao banco de dados ou de outra API.
Busque os casos do World-Check: usando 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 intervalo de datas específico, por exemplo, com base na data de criação ou modificação.
Trate a paginação da API: as respostas da API do World-Check são paginadas. Seu script deve verificar os detalhes de paginação na resposta e percorrer todas as páginas para recuperar a lista completa de casos do intervalo especificado.
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 as alterações detalhadas de status, os detalhes da resolução e as ações dos usuários associadas ao caso.
Mapeie os dados brutos para as atividades: esta é uma etapa crítica da transformação. Escreva uma lógica para percorrer os dados da resposta da API, incluindo os detalhes do caso e o Audit Trail, para cada caso. Mapeie alterações específicas de status, códigos de resultado e eventos de auditoria para as atividades de negócio necessárias. Por exemplo, um evento de criação de caso se torna Screening Request Created, e uma resolução com o resultado False Positive se torna False Positive Confirmed.
Combine as fontes de dados: una os dados extraídos do World-Check aos dados do sistema de origem, obtidos na etapa 3. Use o ID CustomerApplication como chave comum para criar um Event Log completo de ponta a ponta para cada cliente.
Estruture e enriqueça os dados: reúna todos os eventos mapeados em uma única lista de registros. Para cada registro, garanta que todos os atributos obrigatórios (CustomerApplication, ActivityName, EventTime) e os atributos recomendados estejam preenchidos. Calcule EventEndTime quando possível, talvez usando o timestamp do evento seguinte para o caso.
Exporte para CSV: converta a lista final de registros em um DataFrame do pandas. Reordene as colunas para corresponder ao formato obrigatório e exporte o DataFrame para um arquivo CSV. Garanta que o arquivo seja salvo com codificação UTF-8 para ser compatível com o ProcessMind.

Configuração

Credenciais da API: são necessárias uma API Key e um API Secret válidos para a Screening API do World-Check One. Eles devem ser provisionados com as permissões necessárias para ler dados de casos e auditoria.
URL base da API: o script deve ser configurado com a URL base correta para o seu ambiente da API do World-Check, por exemplo, https://api.world-check.com/v2/.
Intervalo de datas: implemente os parâmetros start_date e end_date no script para controlar o período de extração. Para a análise inicial, recomenda-se um intervalo de 3 a 6 meses. Para o monitoramento contínuo, execute o script de forma incremental em períodos menores, como o dia ou a semana anterior.
Conexão com o sistema de origem: são necessários os detalhes de conexão dos sistemas upstream e downstream, como CRM e plataforma bancária central, para buscar os eventos que não pertencem ao screening. Isso pode ser uma string de conexão com o banco de dados ou outro endpoint de API, com suas respectivas credenciais.
Tratamento da paginação: o script deve especificar um tamanho de página, geralmente chamado de limit, ao fazer chamadas de API para listar casos. Um valor entre 50 e 100 costuma ser eficiente. A lógica deve recuperar corretamente todas as páginas.

a 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 iniciar sua jornada de Process Mining no onboarding de clientes KYC. Seguindo estas orientações, você terá acesso a insights valiosos e poderá gerar melhorias significativas nas suas operações.

Voltar ao guia de melhoria Baixar Template

Otimize agora o onboarding de clientes KYC e fortaleça a conformidade

Ofereça um onboarding de clientes sem atritos e reduza o tempo para apenas 24 horas.

Começar o teste grátis

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

Seu Template de dados para onboarding de clientes KYC

Seu Template de dados para onboarding de clientes KYC

Atributos da integração de clientes KYC

Atividades de integração de clientes KYC

Guias de extração

Exportação de casos e do Audit Log do Refinitiv World-Check One

Etapas

Configuração

a Consulta de exemplo sql

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

Etapas

Configuração

a Consulta de exemplo python

Pronto para começar?

Otimize agora o onboarding de clientes KYC e fortaleça a conformidade

Seu Template de dados para onboarding de clientes KYC

Seu Template de dados para onboarding de clientes KYC

Atributos da integração de clientes KYC

Atividades de integração de clientes KYC

Guias de extração

Exportação de casos e do Audit Log do Refinitiv World-Check One

Etapas

Configuração

a Consulta de exemplo sql

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

Etapas

Configuração

a Consulta de exemplo python

Pronto para começar?

Otimize agora o onboarding de clientes KYC e fortaleça a conformidade

Valorizamos sua privacidade