Seu Template de dados para onboarding de clientes KYC
Seu Template de dados para onboarding de clientes KYC
- Atributos recomendados para coleta
- Principais atividades para acompanhar
- Orientações para extração de dados
Atributos da integração de clientes KYC
| Nome | Descrição | ||
|---|---|---|---|
| Hora de início EventStartTime | O carimbo de data e hora que indica quando uma atividade ou um evento começou oficialmente. | ||
| Descrição Este atributo registra a data e a hora exatas em que uma atividade específica começou. Ele fornece a ordem cronológica necessária para reconstruir o fluxo do processo e é essencial para todas as análises baseadas em tempo. No Process Mining, a hora de início é usada para calcular a duração das atividades, o tempo de espera entre elas e o tempo total do ciclo do caso. Ela forma a base temporal do Event Log e é fundamental para analisar a performance e os gargalos. Por que isso importa Este carimbo de data e hora é essencial para ordenar os eventos cronologicamente e calcular todas as métricas baseadas em tempo, como tempos de ciclo e durações. Onde obter Está localizado nas tabelas de trilha de auditoria, Event Log ou histórico de Workflow do Fenergo, geralmente com nomes como 'Timestamp', 'StartDate' ou 'CreationDate'. Exemplos 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z | |||
| Nome da atividade ActivityName | O nome do evento ou da tarefa de negócio específica que ocorreu em determinado momento do processo de onboarding. | ||
| Descrição O nome da atividade descreve uma única etapa ou marco na jornada de onboarding do cliente, como 'Triagem inicial realizada' ou 'Solicitação aprovada'. Essa sequência de atividades forma a base do mapa do processo. Analisar esse atributo permite visualizar o fluxo do processo, identificar caminhos comuns e alternativos e medir a frequência de cada etapa. Ele é essencial para entender quais ações estão sendo realizadas e em que ordem. Por que isso importa Este atributo define as etapas do processo, permitindo criar um mapa do processo e analisar o fluxo e as variações do processo. Onde obter Essas informações normalmente estão nas tabelas de Workflow ou de log de auditoria do Fenergo, associadas a transições de estado do caso ou à conclusão de tarefas. Exemplos Dados e documentos solicitadosRevisão de Conformidade iniciadaSolicitação aprovada | |||
| Solicitação do cliente CustomerApplication | O identificador exclusivo de uma única jornada de onboarding do cliente, usado como identificador principal do caso. | ||
| Descrição A solicitação do cliente é o identificador central que agrupa todas as atividades e os eventos relacionados ao processo de onboarding KYC de um único cliente. Ela permite acompanhar a solicitação de ponta a ponta, desde o envio inicial até a resolução final, seja ela aprovada, rejeitada ou encerrada. No Process Mining, esse atributo é fundamental para reconstruir a jornada completa de cada solicitação. Ele permite analisar fluxos de processo, tempos de ciclo, variações e gargalos por solicitação, oferecendo uma visão clara de como cada caso é tratado. Por que isso importa Este é o Case ID essencial que conecta todos os eventos relacionados, permitindo analisar o processo de onboarding do cliente de ponta a ponta. Onde obter Normalmente, esta é a chave primária da entidade principal de gerenciamento de casos ou de gestão do ciclo de vida do cliente no Fenergo. Exemplos APP-2023-00123APP-2023-00124APP-2023-00125 | |||
| Sistema de origem SourceSystem | O sistema de registro do qual os dados foram extraídos. | ||
| Descrição Este atributo identifica o sistema de origem dos dados dos eventos. Neste processo, ele será sempre o Fenergo, mas, em conjuntos de dados combinados, ajuda a diferenciar as fontes de dados. Seu principal uso na análise é filtrar dados de sistemas específicos ou verificar a procedência dos dados. Ele garante clareza em ambientes nos quais dados de vários sistemas podem ser combinados para oferecer uma visão holística do processo. Por que isso importa Identifica a origem dos dados, o que é essencial para a governança e a validação dos dados e para garantir que a análise use a fonte correta. Onde obter Normalmente, este é um valor estático adicionado durante a extração dos dados para identificar a origem dos registros. Exemplos FenergoFenergo CLM | |||
| Última atualização dos dados LastDataUpdate | O carimbo de data e hora que indica a última vez em que os dados deste processo foram atualizados ou extraídos. | ||
| Descrição Este atributo registra a data e a hora da atualização mais recente dos dados. Ele contextualiza o nível de atualização dos dados analisados e é importante para entender a atualidade dos insights. Em Dashboards e relatórios, essas informações são usadas para informar aos usuários quando os dados foram atualizados. Isso ajuda a alinhar as expectativas sobre se a análise reflete as operações em tempo real ou uma visão histórica. Por que isso importa Fornece um contexto essencial sobre a atualização dos dados, garantindo que os usuários entendam o quão atual é a análise do processo. Onde obter Este valor é gerado e registrado no conjunto de dados durante o processo de extração e carregamento de dados (ETL). Exemplos 2024-05-21T02:00:00Z2024-05-22T02:00:00Z | |||
| Data-alvo do SLA SlaTargetDate | A data até a qual se espera que o caso de onboarding do cliente seja concluído. | ||
| Descrição A data-alvo do SLA representa o prazo acordado para concluir todo o processo de onboarding de uma solicitação de cliente. É um parâmetro essencial para medir a performance real. Este atributo é fundamental para o Dashboard 'Monitoramento da conformidade com o SLA' e para calcular o KPI 'Taxa de cumprimento de SLA'. Ele permite gerenciar proativamente os casos em risco de violar o SLA e ajuda a priorizar o trabalho. Por que isso importa Define a data-alvo de conclusão, essencial para monitorar a conformidade com o SLA e priorizar casos em atraso. Onde obter Essa data geralmente é calculada com base na data de envio da solicitação e nas regras de negócio configuradas no módulo de gerenciamento de SLA do Fenergo. Exemplos 2023-11-15T23:59:59Z2023-12-01T23:59:59Z | |||
| Departamento do usuário UserDepartment | O departamento ou a unidade de negócio à qual pertence o usuário que iniciou a atividade. | ||
| Descrição Este atributo fornece o contexto organizacional do usuário que realizou uma atividade, como 'Conformidade', 'Operações de onboarding' ou 'Vendas'. Geralmente, ele é derivado das informações do perfil do usuário. Essa dimensão é essencial para analisar as transferências do processo entre diferentes departamentos e identificar gargalos entre áreas. Ela dá suporte direto ao Dashboard 'Distribuição das atividades da equipe', permitindo agregar o trabalho por equipe ou departamento. Por que isso importa Permite analisar a performance do processo por departamento, destacando transferências entre áreas, atrasos e distribuição da carga de trabalho. Onde obter Talvez seja necessário fazer uma junção com uma tabela separada de usuários ou dados mestres de RH usando o ID 'InitiatingUser'. O Fenergo também pode armazenar essa informação como parte do perfil do usuário. Exemplos ComplianceIntegração de clientesGarantia da qualidade | |||
| Hora de término EventEndTime | O carimbo de data e hora que indica quando uma atividade ou um evento foi concluído. | ||
| Descrição Este atributo registra a data e a hora exatas em que uma atividade específica terminou. Ele complementa a hora de início para definir a duração ativa de uma tarefa. No Process Mining, a hora de término é usada com a hora de início para calcular o tempo de processamento de cada atividade. Isso é essencial para identificar quais etapas do processo consomem mais tempo e analisar a eficiência dos recursos. Por que isso importa Permite calcular os tempos de processamento das atividades, algo fundamental para identificar tarefas demoradas e gargalos de performance. Onde obter Está localizado nas tabelas de trilha de auditoria ou histórico de Workflow do Fenergo, geralmente com nomes como 'EndDate' e 'CompletionDate', ou é derivado da hora de início do evento seguinte. Exemplos 2023-10-26T11:30:00Z2023-10-26T15:00:10Z2023-10-27T11:45:00Z | |||
| Pontuação de risco RiskScore | Uma pontuação numérica que representa o nível de risco calculado do cliente. | ||
| Descrição A pontuação de risco é uma medida quantitativa do risco potencial associado a um cliente, calculada com base em diversos fatores, como jurisdição, setor e resultados das triagens. O mecanismo de regras do Fenergo geralmente calcula essa pontuação. Este atributo permite correlacionar os níveis de risco com o comportamento do processo. Por exemplo, a análise pode revelar se clientes de alto risco têm tempos de ciclo mais longos ou exigem mais intervenção manual, o que é útil para o Dashboard 'Análise aprofundada da revisão de risco e Conformidade'. Por que isso importa Quantifica o risco do cliente, permitindo analisar como os níveis de risco afetam a duração do processo, o retrabalho e os resultados. Onde obter Este é um resultado importante do módulo Client Risk Assessment da Fenergo. Ele é armazenado no caso ou na entidade do cliente. Exemplos 154585 | |||
| Status da solicitação ApplicationStatus | O resultado atual ou final da solicitação do cliente. | ||
| Descrição Este atributo indica a situação da solicitação ao final do processo ou seu estado atual, caso ainda esteja em andamento. Os valores comuns incluem 'Aprovado', 'Rejeitado' ou 'Em andamento'. Esta é uma dimensão crítica para analisar resultados. Ela permite filtrar e comparar fluxos de processo com base no resultado final, o que é essencial para o Dashboard 'Retrabalho e rejeição de solicitações' e para calcular KPIs como a Taxa de rejeição de solicitações. Por que isso importa Define o resultado de um caso, permitindo comparar de forma aprofundada os caminhos das solicitações aprovadas e rejeitadas e entender as taxas de sucesso. Onde obter Normalmente, este é o status final registrado na entidade do caso no sistema de gerenciamento de casos do Fenergo. Exemplos AprovadoRejeitadoAguardando conformidadeEncerrado | |||
| Usuário que iniciou InitiatingUser | O ID ou nome do usuário que realizou a atividade. | ||
| Descrição Este atributo identifica o funcionário ou usuário do sistema responsável por executar determinada tarefa ou evento. Pode ser um ID de usuário exclusivo, um nome ou uma função. Analisar os dados por usuário ajuda a entender a distribuição da carga de trabalho, a performance individual e as necessidades de treinamento. É essencial para o Dashboard 'Distribuição das atividades da equipe' e para detalhar as atividades realizadas por pessoas ou equipes específicas. Por que isso importa Registra qual usuário realizou uma ação, permitindo analisar a distribuição da carga de trabalho, a performance da equipe e a alocação de recursos. Onde obter Essas informações normalmente ficam armazenadas nos logs de auditoria ou nas tabelas de histórico de tarefas do Fenergo, junto aos detalhes do evento, geralmente em campos como 'UserID', 'UserName' ou 'ModifiedBy'. Exemplos j.doea.smithSYSTEM | |||
| Canal da solicitação ApplicationChannel | O canal pelo qual a solicitação do cliente foi enviada. | ||
| Descrição Este atributo identifica a origem do envio da solicitação, por exemplo, um portal online, uma agência física ou um gerente de relacionamento. A origem pode influenciar a qualidade dos dados e os requisitos de processamento. Essa dimensão é usada no Dashboard 'Eficiência por origem e tipo de solicitação' para comparar a performance de diferentes canais. Ela ajuda as empresas a entender quais canais são mais eficientes e quais podem exigir otimização do processo. Por que isso importa Identifica a origem das solicitações, permitindo analisar a eficiência, o custo e a experiência do cliente por canal. Onde obter Essas informações podem ser capturadas em um formulário inicial de entrada de dados no Fenergo ou recebidas de um sistema upstream. Exemplos Portal onlineAgênciaGerente de relacionamentoAplicativo móvel | |||
| Contagem de solicitações de informações adicionais AdditionalInfoRequestCount | O número total de vezes que informações adicionais foram solicitadas para uma solicitação. | ||
| Descrição Esta métrica conta as ocorrências da atividade 'Additional Information Requested' para cada caso. Uma contagem mais alta indica mais comunicação de ida e volta, o que pode atrasar o processo e gerar uma experiência ruim para o cliente. Este atributo dá suporte direto ao KPI 'Cases with Additional Info Requests'. Ele é usado para identificar solicitações com excesso de pedidos de informação, o que pode apontar problemas na coleta inicial de dados ou requisitos complexos do caso. Analisar esse indicador ajuda a simplificar a coleta de informações. Por que isso importa Quantifica o atrito para o cliente e os atrasos no processo causados por informações iniciais incompletas, ajudando a melhorar a etapa de coleta de dados. Onde obter Esta é uma métrica calculada, derivada da contagem do número de eventos 'Additional Information Requested' para cada ID de 'CustomerApplication'. Exemplos 013 | |||
| É automatizado IsAutomated | Um indicador booleano que mostra se a atividade foi executada por um sistema, e não por um usuário humano. | ||
| Descrição Este atributo diferencia as tarefas executadas automaticamente pelo sistema, como a triagem inicial e as verificações do sistema, daquelas realizadas manualmente por um usuário. Isso geralmente é determinado verificando se o usuário executor é um sistema ou uma conta de serviço. Analisar esse indicador é essencial para entender o nível de automação do processo. Ele ajuda a quantificar o impacto da automação na eficiência, nos custos e na velocidade, além de identificar oportunidades para automatizar ainda mais. Por que isso importa Diferencia atividades humanas e do sistema, algo essencial para analisar a automação e entender os custos de recursos. Onde obter Normalmente, isso é derivado com base no campo 'InitiatingUser'. Uma lista de IDs de usuários de sistema conhecidos é usada para definir esse indicador como verdadeiro. Exemplos truefalse | |||
| É retrabalho IsRework | Um indicador booleano que mostra se uma atividade faz parte de um loop de retrabalho. | ||
| Descrição Este atributo identifica atividades que representam um retrocesso no processo, como retornar a 'Document Review' depois que uma 'Compliance Review' já começou ou qualquer ocorrência de 'Additional Information Requested'. Identificar o retrabalho é essencial para entender a ineficiência e os pontos de atrito do processo. Este indicador permite calcular diretamente o KPI 'Rework Loop Rate' e ajuda a visualizar e quantificar o impacto de etapas repetitivas e que não agregam valor no fluxo do processo. Por que isso importa Destaca loops de retrabalho ineficientes no processo, ajudando a quantificar desperdícios e identificar áreas de melhoria para aumentar as taxas de acerto na primeira execução. Onde obter Este indicador é derivado usando técnicas de Process Mining que analisam a sequência de atividades. Por exemplo, se a 'Activity A' for seguida pela 'Activity B' e depois a 'Activity A' aparecer novamente para o mesmo caso, a segunda 'Activity A' será considerada retrabalho. Exemplos truefalse | |||
| Está em conformidade com o SLA IsSlaCompliant | Um indicador booleano que mostra se o caso foi concluído até a data-alvo do SLA. | ||
| Descrição Este atributo é um indicador binário da performance do SLA para um caso concluído. Ele recebe o valor 'true' quando o registro de data e hora da atividade final de encerramento é igual ou anterior à 'SlaTargetDate', e 'false' caso contrário. Este campo calculado simplifica o monitoramento e os relatórios de SLA. Ele permite agregar os dados facilmente para calcular o KPI geral de 'SLA Adherence Rate' e filtrar os casos para analisar as características de processos em conformidade e fora de conformidade. Por que isso importa Mede diretamente a performance do SLA, permitindo calcular facilmente o KPI SLA Adherence Rate e filtrar os casos fora de conformidade. Onde obter Isso é derivado comparando o registro de data e hora da atividade final do caso, como 'Application Approved' ou 'Application Rejected', com a 'SlaTargetDate'. Exemplos truefalse | |||
| ID do cliente CustomerId | Um identificador exclusivo do cliente ou da entidade jurídica que está passando pelo onboarding. | ||
| Descrição O Customer ID é a referência exclusiva da entidade do cliente no sistema de dados mestre. Enquanto o número da solicitação é o ID do caso no processo, o Customer ID vincula a atividade de onboarding a um cliente específico. Este atributo permite analisar o histórico de onboarding de um único cliente, por exemplo, verificando se ele passou por vários processos de onboarding ao longo do tempo. Ele também permite combinar os dados do processo com outros dados relacionados ao cliente, proporcionando uma visão de negócio mais completa. Por que isso importa Vincula o processo de onboarding a uma entidade de cliente exclusiva, permitindo uma análise centrada no cliente e o enriquecimento dos dados. Onde obter Este ID é armazenado no registro do cliente ou da entidade jurídica na Fenergo e associado ao caso de onboarding. Exemplos CUST-98765CUST-98766CUST-98767 | |||
| Motivo da rejeição RejectionReason | Um código ou uma descrição que explica por que uma solicitação foi rejeitada. | ||
| Descrição Quando o status final de uma solicitação é 'Rejeitado', este atributo informa o motivo específico. Alguns exemplos são 'Verificação de antecedentes reprovada', 'Documentação incompleta' ou 'Perfil de alto risco'. Este é um atributo essencial para a análise das causas-raiz de solicitações malsucedidas. Ele dá suporte direto ao Dashboard 'Retrabalho e rejeição de solicitações' ao categorizar as falhas, ajudando a empresa a identificar problemas recorrentes e implementar ações corretivas para melhorar a taxa de aprovação na primeira tentativa. Por que isso importa Fornece um insight essencial sobre os motivos das falhas nas solicitações, permitindo analisar as causas-raiz e reduzir as taxas de rejeição. Onde obter Normalmente, é encontrado em um campo de código do motivo ou de observações associado ao status final de rejeição no Workflow do caso no Fenergo. Exemplos Correspondência com lista de sançõesDocumentos inválidosViolação de políticaCliente desistiu | |||
| País Country | O país de domicílio ou a jurisdição da solicitação do cliente. | ||
| Descrição Este atributo especifica o país associado ao cliente, que geralmente determina as regras regulatórias e os fatores de risco aplicáveis ao processo de onboarding. Analisar o processo por país permite comparar tempos de ciclo, níveis de risco e complexidade do processo entre jurisdições. Isso ajuda a entender como as diferenças regionais afetam a performance operacional e a garantir a conformidade com as regulamentações locais. Por que isso importa Permite segmentar o processo por localização geográfica, algo essencial para analisar o impacto regulatório e a performance regional. Onde obter Essas informações fazem parte dos dados principais do cliente, coletados durante o processo de solicitação e armazenados na entidade do cliente no Fenergo. Exemplos USAGBRSGPDEU | |||
| Responsável pelo caso CaseOwner | O usuário ou time principal responsável por gerenciar a solicitação durante todo o seu ciclo de vida. | ||
| Descrição O responsável pelo caso é a pessoa ou o grupo que assume a responsabilidade principal por um caso de onboarding. Essa pessoa normalmente responde pela conclusão pontual e bem-sucedida do caso. Este atributo ajuda a analisar a carga de trabalho e a performance no nível do gerente de casos. Ele pode ser usado para verificar se determinados responsáveis têm tempos de ciclo mais longos ou taxas de rejeição mais altas, o que pode indicar necessidades de treinamento ou desequilíbrios na alocação de recursos. Por que isso importa Identifica a pessoa ou o time responsável por um caso, permitindo analisar a performance dos gerentes de casos. Onde obter Normalmente, este é um campo específico da entidade principal do caso na Fenergo, indicando a atribuição do caso. Exemplos s.jonesonboarding_team_am.chen | |||
| Tipo de cliente CustomerType | A classificação do cliente que está passando pelo onboarding, como pessoa física, empresa ou trust. | ||
| Descrição Este atributo segmenta os clientes em diferentes categorias com base em sua estrutura jurídica ou relação com a instituição financeira. Diferentes tipos de cliente geralmente seguem caminhos de onboarding distintos, com níveis variados de complexidade e requisitos de diligência. Analisar o processo por tipo de cliente ajuda a identificar diferenças de performance entre os segmentos. É essencial para o Dashboard 'Eficiência por origem e tipo de solicitação', permitindo comparar tempos de ciclo e taxas de aprovação e definir melhorias específicas para cada segmento. Por que isso importa Permite comparar a performance do processo entre diferentes segmentos de clientes, que geralmente têm níveis distintos de complexidade e SLAs. Onde obter Essas informações normalmente ficam armazenadas na entidade de cliente no Fenergo e vinculadas ao caso da solicitação. Exemplos Pessoa físicaPessoa jurídicaTrustSociedade de pessoas | |||
Atividades de integração de clientes KYC
| Atividade | Descrição | ||
|---|---|---|---|
| Avaliação de risco concluída | Representa a conclusão do processo interno de classificação de risco, no qual o cliente recebe uma classificação de risco com base em diversos fatores. Isso é inferido a partir de uma mudança de status ou do preenchimento de um campo de classificação de risco. | ||
| Por que isso importa Este é um marco importante para a tomada de decisão e geralmente determina o caminho seguinte do Workflow. Analisar sua duração ajuda a simplificar uma etapa crítica de Conformidade e garante consistência na avaliação de risco. Onde obter É inferido a partir do log do histórico do caso, identificando quando o caso muda para um status como 'Risco avaliado' ou quando o campo final 'Classificação de risco do cliente' é preenchido com um valor. Captura Use o carimbo de data e hora em que a classificação de risco é finalizada ou um status relacionado é definido. Tipo de evento inferred | |||
| Caso criado | Esta atividade marca o início do processo de onboarding KYC, quando uma nova solicitação de cliente é criada formalmente no Fenergo. Normalmente, trata-se de um evento explícito, registrado com um carimbo de data e hora específico no primeiro salvamento do registro do caso. | ||
| Por que isso importa Como evento inicial, esta atividade é essencial para calcular o tempo total do ciclo de onboarding e analisar o throughput. Ela fornece a base para todas as medições posteriores do processo e para o acompanhamento de SLA. Onde obter Normalmente, esse dado é capturado do carimbo de data e hora de criação da entidade principal do caso no Fenergo, geralmente em tabelas relacionadas a casos ou Workflows de onboarding de clientes. Captura Use o carimbo de data e hora de criação do registro do caso de onboarding. Tipo de evento explicit | |||
| Caso encerrado | Esta é a atividade final, indicando que o caso de onboarding foi encerrado administrativamente no Fenergo, sem previsão de novas ações. Isso se aplica tanto a solicitações aprovadas quanto rejeitadas e é inferido a partir de um status final de 'Encerrado'. | ||
| Por que isso importa Esta atividade funciona como o ponto final definitivo de todo o processo. Ela garante cálculos precisos do tempo de ciclo para todos os casos, independentemente do resultado, e confirma que o processo foi concluído. Onde obter É inferido a partir do log de auditoria do caso no Fenergo, identificando o carimbo de data e hora em que o status do caso é definido como 'Encerrado', 'Concluído' ou outro estado terminal. Captura Identifique o carimbo de data e hora da mudança final de status para 'Encerrado' ou 'Concluído'. Tipo de evento inferred | |||
| Revisão de Conformidade concluída | Marca a aprovação formal pelo departamento de Conformidade, indicando que todos os requisitos regulatórios foram atendidos. Isso é inferido a partir da conclusão de uma tarefa ou de uma mudança de status para 'Conformidade aprovada'. | ||
| Por que isso importa Como um marco importante, a conclusão desta atividade é fundamental para o tempo total do ciclo. Ela é o ponto final para medir o 'Tempo médio de revisão de Conformidade' e identificar gargalos na função de Conformidade. Onde obter É inferido a partir do carimbo de data e hora de conclusão da tarefa 'Revisão de Conformidade' no Workflow do Fenergo ou do evento de atualização de status no histórico do caso. Captura Use o carimbo de data e hora de conclusão da tarefa de revisão de Conformidade ou da atualização de status. Tipo de evento inferred | |||
| Revisão de Conformidade iniciada | Esta atividade marca o início da revisão pelo departamento de Conformidade, uma etapa crítica e muitas vezes demorada. Ela é inferida quando o caso é atribuído à fila de trabalho de Conformidade ou quando seu status muda para 'Aguardando revisão de Conformidade'. | ||
| Por que isso importa Esta atividade é o ponto de partida para medir o KPI 'Tempo médio de revisão de Conformidade'. Ela ajuda a identificar quanto tempo os casos aguardam antes de serem efetivamente trabalhados pela equipe de Conformidade. Onde obter É inferido a partir do log de auditoria do caso no Fenergo, capturando o carimbo de data e hora da mudança de status para 'Em revisão de Conformidade' ou da atribuição do caso a um responsável ou equipe de Conformidade. Captura Identifique o carimbo de data e hora da mudança de status para 'Em revisão de Conformidade' ou do evento de atribuição. Tipo de evento inferred | |||
| Revisão de documentos concluída | Indica a conclusão do processo manual ou automatizado de verificação da autenticidade e da correção de todos os documentos enviados pelo cliente. Esse evento geralmente é inferido a partir da conclusão de uma tarefa do Workflow ou de uma mudança de status no Fenergo. | ||
| Por que isso importa Este é um marco crítico, no qual ocorrem muitos atrasos. Analisar a duração e os resultados dessa atividade ajuda a identificar gargalos no processamento de documentos e dá suporte a KPIs como 'Taxa de aprovação na primeira tentativa'. Onde obter É inferido a partir do carimbo de data e hora de conclusão da tarefa 'Verificação de documentos' no Workflow do caso ou de uma atualização de status para 'Documentos aprovados' no log do histórico do caso. Captura Use o carimbo de data e hora de conclusão da tarefa de revisão de documentos ou de uma mudança de status relacionada. Tipo de evento inferred | |||
| Solicitação aprovada | Esta atividade representa a decisão final de aprovar a solicitação de onboarding do cliente. Ela é inferida a partir da mudança do status do caso para um estado final de 'Aprovado' ou 'Onboarding aprovado'. | ||
| Por que isso importa Este marco importante indica um resultado bem-sucedido antes das etapas finais de ativação da conta. Ele é essencial para calcular as taxas de aprovação e analisar as características dos clientes integrados com sucesso. Onde obter É inferido a partir do histórico ou do log de auditoria do caso, localizando o carimbo de data e hora da mudança final de status para 'Aprovado' ou um estado positivo terminal semelhante. Captura Identifique o carimbo de data e hora da mudança final de status para 'Aprovado'. Tipo de evento inferred | |||
| Solicitação rejeitada | Esta atividade é um evento terminal que representa a decisão final de rejeitar a solicitação do cliente. Ela é inferida a partir da mudança do status do caso para um estado final de 'Rejeitado' ou 'Recusado'. | ||
| Por que isso importa Como um ponto final importante do processo, esta atividade é essencial para calcular a 'Taxa de rejeição de solicitações' e analisar os motivos das falhas. Ela ajuda a identificar pontos comuns de rejeição e melhorar a qualidade das solicitações. Onde obter É inferido a partir do log de auditoria do caso, capturando o carimbo de data e hora em que o status final muda para 'Rejeitado'. O motivo da rejeição geralmente é armazenado em um campo relacionado. Captura Identifique o carimbo de data e hora da mudança final de status para 'Rejeitado'. Tipo de evento inferred | |||
| Conta ativada | Indica que a conta do cliente foi criada e ativada com sucesso no sistema bancário principal ou no sistema downstream relevante após a aprovação. Isso pode ser inferido a partir de uma atualização final de status no Fenergo após a aprovação. | ||
| Por que isso importa Esta atividade confirma a transferência bem-sucedida do processo de onboarding para o status de cliente ativo. Medir o tempo entre a aprovação e a ativação pode revelar atrasos na configuração operacional. Onde obter Isso pode ser inferido a partir de um status do caso como 'Conta ativa' ou 'Onboarding concluído'. Também pode ser um evento explícito registrado por uma integração com um sistema downstream. Captura Procure uma mudança de status após a aprovação ou um evento de sucesso no log da integração. Tipo de evento inferred | |||
| Dados e documentos solicitados | Este evento indica que o sistema ou um agente de onboarding solicitou formalmente ao cliente as informações e os documentos necessários. Geralmente, é capturado como um evento explícito quando uma comunicação padronizada é enviada. | ||
| Por que isso importa Esta atividade marca o início de uma fase que depende do cliente. Medir o tempo entre este ponto e o recebimento dos documentos é essencial para analisar a jornada do cliente e identificar atrasos na comunicação. Onde obter É capturado em um Event Log associado às comunicações com o cliente ou em um log de conclusão de tarefa para 'Solicitar documentos'. Também pode ser inferido a partir de uma mudança de status para 'Aguardando informações do cliente'. Captura Procure um evento registrado de comunicação com o cliente ou a conclusão de uma tarefa. Tipo de evento explicit | |||
| Documentos recebidos | Esta atividade indica que o cliente carregou ou enviou os documentos necessários, que agora estão disponíveis no Fenergo para revisão. Normalmente, é inferida quando o status do caso é atualizado para 'Documentos recebidos' ou 'Aguardando revisão'. | ||
| Por que isso importa Isso marca o fim do período de espera do cliente e o início do ciclo de revisão interna. É essencial para medir os tempos de resposta do cliente e os tempos de espera na fila de processamento interno. Onde obter É inferido a partir da trilha de auditoria do caso, que registra o carimbo de data e hora da mudança de status para 'Documentos recebidos' ou um estado semelhante. Também pode estar associado a eventos de upload de documentos. Captura Identifique o carimbo de data e hora da mudança de status para 'Documentos recebidos' ou 'Pronto para revisão'. Tipo de evento inferred | |||
| Informações adicionais solicitadas | Representa um ciclo de retrabalho no qual a equipe de onboarding precisa voltar ao cliente para esclarecer informações ou solicitar documentos ausentes. É um evento explícito, normalmente registrado quando uma comunicação é enviada ao cliente. | ||
| Por que isso importa Esta atividade é um dos principais indicadores de ineficiência do processo e de uma experiência ruim para o cliente. Acompanhar sua frequência ajuda a identificar as causas-raiz do retrabalho e dá suporte ao KPI 'Taxa de ciclos de retrabalho'. Onde obter É capturado em um Event Log de comunicações com o cliente ou em uma mudança de status para 'Aguardando informações adicionais'. A primeira opção é mais precisa para registrar o momento exato da solicitação. Captura Procure eventos de comunicação registrados ou uma mudança de status para 'Aguardando resposta do cliente'. Tipo de evento explicit | |||
| Triagem inicial realizada | Representa a conclusão de verificações preliminares automatizadas ou manuais, como validação básica de dados ou consulta a listas de sanções. Muitas vezes, é inferido a partir de uma mudança de status no Workflow do caso no Fenergo, por exemplo, de 'Novo' para 'Triagem concluída'. | ||
| Por que isso importa Acompanhar esse marco inicial ajuda a identificar problemas de qualidade dos dados e gargalos na etapa de pré-qualificação. Ele separa a fase automatizada inicial dos processos mais intensivos de revisão manual. Onde obter É inferido a partir do histórico do caso ou do log de auditoria, identificando o carimbo de data e hora em que o status do caso muda para um estado que indica a conclusão da triagem, como 'Triagem aprovada' ou 'Aguardando documentos'. Captura Identifique no histórico do caso a mudança de status para 'Triagem concluída' ou equivalente. Tipo de evento inferred | |||
| Verificações de antecedentes iniciadas | Esta atividade marca o momento em que são acionadas verificações externas de antecedentes, AML ou crédito. Geralmente, é um evento explícito registrado quando uma integração com um serviço de terceiros é chamada. | ||
| Por que isso importa Acompanhar o início e a conclusão dessas verificações é essencial para entender os atrasos causados por dependências externas. Isso ajuda a separar o tempo do processo interno do tempo de espera externo. Onde obter Normalmente, é capturado nos logs do sistema que registram chamadas de API para provedores externos de triagem ou na criação de uma tarefa específica de 'Verificação de antecedentes' no caso do Fenergo. Captura Procure logs de integrações com serviços externos ou a criação de uma tarefa de 'Triagem'. Tipo de evento explicit | |||
Guias de extração
Etapas
- Acesse o módulo de relatórios: entre no aplicativo Fenergo com uma conta de usuário que tenha permissões suficientes para o módulo Reporting & Analytics. Acesse o módulo, normalmente encontrado no menu principal do aplicativo.
- Crie um novo relatório: inicie a criação de um novo relatório personalizado. Escolha um nome e uma descrição que identifiquem claramente sua finalidade, por exemplo, 'KYC Onboarding Event Log for Process Mining'.
- Defina a fonte de dados principal: selecione o objeto ou a visualização de dados central que registra as informações do ciclo de vida do caso. Geralmente, é uma visualização pré-configurada, como
[CaseWorkflowHistory]ou[LifecycleEventsView]. Esse objeto deve conter identificadores de caso, nomes ou status de eventos e registros de data e hora. - Configure as colunas do relatório (atributos): use a interface de criação de relatórios para adicionar colunas. Mapeie os campos de origem do modelo de dados da Fenergo para os atributos necessários do Event Log. Por exemplo, mapeie
CaseIDda Fenergo paraCustomerApplication,EventTimestampparaEventStartTimeeEventPerformerparaInitiatingUser. - Crie a lógica das atividades: esta é a etapa mais importante. O relatório deve ser configurado para gerar uma linha separada para cada uma das 14 atividades necessárias. Para isso, crie blocos lógicos ou conjuntos de dados filtrados para cada atividade e combine-os usando uma UNION ou função equivalente no criador de relatórios.
- Defina a lógica de 'Case Created': crie o primeiro bloco. Filtre a fonte de dados pelo evento inicial de criação do caso. Isso geralmente se baseia no registro de data e hora mais antigo associado ao caso ou em um tipo de evento chamado 'Case Created'. Mapeie
CreationDateparaEventStartTime. - Defina a lógica das atividades baseadas em status: para atividades inferidas a partir de alterações de status, como 'Documents Received' e 'Application Approved', crie blocos separados. Filtre a fonte de dados pelo valor específico do campo
Statuse useStatusChangeDatecomoEventStartTime. - Defina a lógica das atividades baseadas em tarefas: para atividades vinculadas a tarefas do Workflow, como 'Compliance Review Completed', crie blocos que filtrem por
TaskNameeTaskCompletionDate. Use a data de conclusão comoEventStartTime. - Defina os filtros globais do relatório: aplique filtros no nível do relatório para delimitar os dados. Defina um intervalo de
Date Rangeespecífico paraEventStartTimee evite exportações excessivamente grandes. Para a análise inicial, recomenda-se um período de 3 a 6 meses. Filtre pelo tipo específico de caso, como 'KYC Customer Onboarding'. - Execute e visualize o relatório: execute o relatório na interface da Fenergo. Visualize as primeiras 100 a 200 linhas para garantir que a estrutura dos dados esteja correta, que todas as colunas estejam preenchidas conforme esperado e que diferentes atividades estejam presentes.
- Exporte os dados: exporte os resultados completos do relatório para um arquivo CSV ou Excel. Esse será o arquivo bruto do Event Log.
- Prepare os dados finais: abra o arquivo CSV exportado. Se as colunas
SourceSystemeLastDataUpdatenão puderem ser geradas diretamente pelo relatório, adicione-as manualmente. Defina 'Fenergo' comoSourceSystemem todas as linhas e use o registro de data e hora da exportação comoLastDataUpdate.
Configuração
- Pré-requisitos: o usuário precisa ter acesso ao módulo Reporting & Analytics da Fenergo, com permissão para criar e executar relatórios personalizados.
- Fontes de dados principais: o relatório deve ser criado principalmente a partir dos objetos de gerenciamento de casos e histórico de Workflow da Fenergo. As fontes comuns incluem
[CaseDetails],[CaseStatusHistory]e[WorkflowTaskHistory]. Os nomes exatos podem variar de acordo com a configuração da sua Fenergo. - Intervalo de datas: é essencial definir um filtro de intervalo de datas no registro de data e hora do evento para controlar a performance. Comece com um período recente de 3 a 6 meses. Para análises históricas, execute o relatório em lotes, por exemplo, trimestrais ou anuais.
- Filtros principais: filtre sempre pelo processo ou tipo de caso específico, como 'KYC Customer Onboarding', para excluir dados irrelevantes. Dependendo dos objetivos da análise, talvez também seja necessário filtrar pelo tipo de entidade jurídica ou pela jurisdição.
- Definição das atividades: cada atividade deve ser definida usando critérios de filtro específicos em campos como
Status,TaskNameou um campoEventTypededicado. Usar esses campos é essencial para isolar cada evento exclusivo do processo. - Considerações de performance: relatórios que combinam muitas fontes de dados ou analisam um intervalo de datas amplo podem ser lentos. Se possível, programe o relatório para ser executado fora do horário de pico. Evite incluir colunas desnecessárias na exportação, pois isso aumenta o tempo de processamento.
a Consulta de exemplo sql
/*
This is a logical representation of the configuration needed in the Fenergo Reporting & Analytics module.
The module uses a graphical interface, but this query structure illustrates the required data sources, filters, and unions.
Fields like [CaseLifecycleData].[CaseID] are placeholders for actual Fenergo fields selected in the UI.
*/
-- Base data selection for common attributes
WITH CaseAttributes AS (
SELECT
C.CaseID AS CustomerApplication,
C.SlaTargetDate AS SlaTargetDate,
C.FinalRiskScore AS RiskScore,
C.CurrentStatus AS ApplicationStatus
FROM [CaseDetails] C
WHERE C.CaseType = 'KYC Customer Onboarding'
)
-- 1. Case Created
SELECT
A.CustomerApplication,
'Case Created' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
L.CompletionTimestamp AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'CASE_CREATED'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 2. Initial Screening Performed
SELECT
A.CustomerApplication,
'Initial Screening Performed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Initial Screening' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 3. Data & Documents Requested
SELECT
A.CustomerApplication,
'Data & Documents Requested' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'CUSTOMER_COMMUNICATION' AND L.TemplateName = 'Initial Document Request'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 4. Documents Received
SELECT
A.CustomerApplication,
'Documents Received' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Pending Review'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 5. Document Review Completed
SELECT
A.CustomerApplication,
'Document Review Completed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Document Verification' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 6. Background Checks Initiated
SELECT
A.CustomerApplication,
'Background Checks Initiated' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'EXTERNAL_CHECK_INITIATED'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 7. Risk Assessment Completed
SELECT
A.CustomerApplication,
'Risk Assessment Completed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Risk Assessment' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 8. Compliance Review Initiated
SELECT
A.CustomerApplication,
'Compliance Review Initiated' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Pending Compliance Review'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 9. Additional Information Requested
SELECT
A.CustomerApplication,
'Additional Information Requested' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'CUSTOMER_COMMUNICATION' AND L.TemplateName = 'Additional Information Request'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 10. Compliance Review Completed
SELECT
A.CustomerApplication,
'Compliance Review Completed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Compliance Review' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 11. Application Approved
SELECT
A.CustomerApplication,
'Application Approved' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Approved'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 12. Application Rejected
SELECT
A.CustomerApplication,
'Application Rejected' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Rejected'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 13. Account Activated
SELECT
A.CustomerApplication,
'Account Activated' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Active'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 14. Case Closed
SELECT
A.CustomerApplication,
'Case Closed' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Closed'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]' Pronto para começar?
Ao aproveitar este Template de dados, você estará no caminho certo para descobrir ineficiências e simplificar seu processo de onboarding de clientes KYC na Fenergo. Comece hoje sua jornada rumo a operações otimizadas e maior satisfação dos clientes.
Simplifique o onboarding de clientes KYC e obtenha aprovações mais rápidas hoje
Junte-se às empresas que estão reduzindo o tempo de onboarding para apenas 24 horas.
Não é necessário cartão de crédito. Comece em poucos minutos.