Seu Template de Dados de Onboarding de Clientes KYC
Seu Template de Dados de Onboarding de Clientes KYC
- Atributos recomendados para coletar
- Atividades-chave a monitorizar
- Guia de extração para ACTICO
Atributos de Onboarding de Clientes KYC
| Nome | Descrição | ||
|---|---|---|---|
| Nome da Atividade ActivityName | O nome do evento de negócio ou tarefa específica realizada no processo de onboarding. | ||
| Descrição Este atributo registra o nome de cada etapa ou atividade no processo KYC, como 'Pedido Enviado', 'Avaliação de Risco Realizada' ou 'Pedido Aprovado'. Ele fornece os blocos de construção sequenciais do mapa do processo. Analisar o Nome da Atividade permite visualizar o fluxo, identificar atividades frequentes ou raras e detectar gargalos ou loops de retrabalho. É a base para entender quais ações estão sendo executadas e em que ordem, o que é crucial para a análise de variantes e verificações de conformidade. Por que é importante Define as etapas no mapa de processos, permitindo visualizar o fluxo, identificar desvios e analisar a frequência e sequência das atividades. Onde obter Essa informação costuma estar em uma tabela de Event Log no ACTICO, geralmente em um campo que descreve o evento ou tipo de tarefa. Consulte a documentação do ACTICO. Exemplos Candidatura enviadaAvaliação de Risco RealizadaRevisão de conformidade concluídaSolicitação rejeitada | |||
| Solicitação do cliente CustomerApplication | O identificador único de um pedido de onboarding, servindo como ID do case para análise do processo. | ||
| Descrição O pedido de abertura de conta (Customer Application) é o identificador principal do case que agrupa todos os eventos e atividades relacionados à jornada de onboarding de um único cliente. Ele representa uma instância completa do processo KYC, desde o envio inicial até a decisão final de aprovação ou rejeição. No Process Mining, este atributo é essencial para reconstruir a jornada de ponta a ponta de cada pedido. Ele permite que os analistas acompanhem a sequência de atividades, meçam os tempos totais de ciclo e comparem diferentes caminhos ou variantes percorridos pelos pedidos. Todos os eventos que compartilham o mesmo ID de Pedido são considerados parte do mesmo case. Por que é importante Este é o atributo fundamental para o Process Mining, pois conecta todos os eventos relacionados em uma única instância de processo, permitindo a análise de ponta a ponta da experiência de cada cliente. Onde obter Esta é a chave primária nas tabelas de gestão de pedidos ou cases no ACTICO. Consulte a documentação do ACTICO para nomes específicos de tabelas e campos. Exemplos APP-2023-001234APP-2023-001235APP-2024-000001 | |||
| Tempo do Evento EventTime | O registro de data e hora indicando quando uma atividade específica começou ou ocorreu. | ||
| Descrição O Event Time é a data e hora exatas em que uma atividade foi registrada. Ele fornece a ordem cronológica para todos os eventos em um único caso de onboarding, formando a linha do tempo da jornada. Este atributo é fundamental para análises baseadas em tempo. Ele serve para calcular o tempo de ciclo entre atividades, identificar atrasos e esperas, medir a duração total do caso e conferir a conformidade com SLAs. A sequência desses registros permite que as ferramentas de Process Mining reconstruam o fluxo exato do processo como ele realmente ocorreu. Por que é importante Este atributo fornece a ordem cronológica dos eventos, o que é essencial para calcular durações, descobrir gargalos e analisar a linha do tempo do processo. Onde obter Localizado nas tabelas de log de eventos do ACTICO, este é o carimbo de data/hora associado a cada atividade registrada. Consulte a documentação do ACTICO. Exemplos 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T15:45:10Z | |||
| Sistema de Origem SourceSystem | O sistema de registro de onde se originam os dados dos eventos. | ||
| Descrição Este atributo identifica o sistema de informação de origem onde os dados foram gerados. Para este processo, será consistentemente 'ACTICO', mas em análises amplas com múltiplos sistemas, ajuda a diferenciar as origens dos dados. No contexto de Process Mining, é crucial para a governança e validação de dados. Garante que as informações sejam atribuídas corretamente à sua fonte, o que é importante ao mesclar dados de diferentes sistemas para criar uma visão holística. Também auxilia na resolução de problemas de qualidade de dados, rastreando-os até o sistema de origem. Por que é importante Fornece contexto essencial sobre a origem dos dados, garantindo linhagem e governança, o que é crítico ao combinar dados de múltiplas fontes. Onde obter Geralmente é um valor estático ('ACTICO') adicionado durante a extração e transformação para rotular o conjunto de dados. Exemplos ACTICOPlataforma ACTICOMódulo KYC do Actico | |||
| Última Atualização de Dados LastDataUpdate | O timestamp que indica a última vez que os dados foram atualizados ou extraídos do sistema de origem. | ||
| Descrição Este atributo registra a data e a hora da extração de dados mais recente do ACTICO. É um campo de metadados aplicado a todo o conjunto de dados, fornecendo contexto sobre a atualidade da análise. Em Dashboards e relatórios, essa informação é vital para que os usuários saibam o quão recentes são os dados. Ajuda a gerenciar as expectativas sobre os insights e é crucial para o monitoramento operacional onde dados em tempo real são importantes. Exibir este registro garante transparência e confiança nas informações apresentadas. Por que é importante Indica a atualização dos dados, permitindo que os usuários saibam se estão analisando informações recentes, o que é crucial para decisões operacionais. Onde obter Este valor é gerado e armazenado durante o processo de extração, transformação e carga (ETL). Reflete o registro de data e hora de quando o trabalho de ETL foi concluído com sucesso. Exemplos 2024-05-20T08:00:00Z2024-05-21T08:00:00Z | |||
| Data Alvo do SLA SlaTargetDate | A data em que se espera que o processo de onboarding do cliente seja concluído. | ||
| Descrição A Data Limite do SLA (SLA Target Date) é o prazo para concluir o onboarding de um cliente, conforme definido pelos acordos de nível de serviço internos. Esta data costuma ser calculada com base na data de envio do pedido mais um tempo padrão de processamento. Este atributo é essencial para monitorar a conformidade do SLA. Ao comparar a data real de conclusão de um case com sua Data Limite, o sistema determina se o prazo foi cumprido ou violado. Esta é a base para o Dashboard de "Performance de SLA de Onboarding" e para o KPI de "Taxa de Adesão ao SLA". Por que é importante Estabelece o parâmetro para medir a performance de pontualidade, permitindo o monitoramento direto e o relato da conformidade do SLA. Onde obter Isso pode estar em um campo na tabela principal do case no ACTICO ou ser derivado por regras de negócio (ex: Data de Envio + 5 dias úteis). Exemplos 2023-11-01T17:00:00Z2023-11-02T17:00:00Z2023-11-03T17:00:00Z | |||
| Departamento Department | O departamento ou equipe responsável pela execução da atividade. | ||
| Descrição Este atributo atribui uma atividade a uma unidade organizacional específica, como 'Compliance', 'Equipe de Onboarding' ou 'Relacionamento'. Ele fornece um contexto organizacional ao fluxo do processo. A análise por departamento é crucial para entender como o trabalho é transferido entre diferentes partes da organização. Ajuda a identificar gargalos interdepartamentais, medir a eficiência e analisar a alocação de recursos entre as equipes. Os Dashboards podem ser filtrados por departamento para oferecer aos gestores uma visão da performance específica de seu time. Por que é importante Fornece uma dimensão organizacional para análise, permitindo a identificação de atrasos entre departamentos e a avaliação da performance das equipes. Onde obter Essa informação pode estar armazenada com os dados do evento ou ser derivada cruzando dados de usuários com uma tabela mestre de RH. Consulte a documentação do ACTICO. Exemplos ComplianceEquipe de onboardingServiço ao Cliente | |||
| End Time EndTime | O carimbo de data/hora (timestamp) que indica quando uma atividade específica foi concluída. | ||
| Descrição O Horário de Término (End Time) marca a conclusão de uma atividade. Junto com o Horário de Início (EventTime), ele permite o cálculo da duração precisa de cada tarefa, conhecida como tempo de processamento. Nem todos os eventos possuem um horário de término distinto, pois alguns podem ser instantâneos. Este atributo é fundamental para a análise de performance, especialmente para medir quanto tempo cada etapa leva. Ele permite a criação de Dashboards detalhados, ajuda a identificar quais atividades consomem mais tempo e é essencial para calcular KPIs como o 'Tempo Médio de Revisão de Documentos'. Por que é importante Permite o cálculo preciso da duração das atividades (tempo de processamento), essencial para identificar gargalos de desempenho e analisar a eficiência dos recursos. Onde obter Assim como a hora de início, isso geralmente é encontrado nas tabelas de event log do ACTICO. Alguns sistemas armazenam início e fim em colunas separadas. Consulte a documentação do ACTICO. Exemplos 2023-10-26T10:15:00Z2023-10-26T12:00:00Z2023-10-27T16:00:15Z | |||
| Motivo da Rejeição RejectionReason | O motivo específico fornecido quando o pedido de um cliente é rejeitado. | ||
| Descrição Quando o status final de um pedido é 'Rejeitado', este atributo indica a causa principal. Exemplos incluem 'Documentação Incompleta', 'Falha na Verificação de Antecedentes' ou 'Perfil de Alto Risco'. Este é um atributo vital para a análise de causa raiz. Ao analisar a frequência dos motivos de rejeição, a empresa identifica problemas sistêmicos no processo ou nos envios dos clientes. Por exemplo, muitas rejeições por documentação incompleta podem indicar que as instruções do pedido não estão claras. Isso apoia diretamente o Dashboard de 'Taxa e Motivos de Rejeição de Pedidos'. Por que é importante Fornece o "porquê" por trás das rejeições de pedidos, permitindo a análise de causa raiz para reduzir a taxa de rejeição e melhorar a eficiência do processo. Onde obter Geralmente encontrado na tabela principal de cases ou pedidos no ACTICO, sendo preenchido apenas quando o status do pedido é 'Rejeitado'. Exemplos Documentação IncompletaFalha na verificação de identidadeCorrespondência de SançõesPontuação de alto risco | |||
| Nível de Risco RiskLevel | O nível de risco calculado para o pedido do cliente, como Baixo, Médio ou Alto. | ||
| Descrição Este atributo representa a categoria de risco avaliada de um cliente, que geralmente determina a complexidade e o rigor do processo KYC subsequente. Um cliente de alto risco pode exigir verificações extras e aprovações em comparação a um de baixo risco. No Process Mining, o Nível de Risco é uma dimensão poderosa para análise comparativa. Ele permite verificar se o processo segue corretamente os caminhos previstos conforme o risco. Por exemplo, é possível validar se todos os clientes de alto risco passaram por uma diligência aprimorada. É fundamental para o Dashboard de fluxos de avaliação de risco. Por que é importante Permite segmentar os casos por risco, possibilitando analisar se o processo se adapta corretamente aos diferentes perfis exigidos pelas políticas de conformidade. Onde obter Este é um dado importante armazenado no nível do case na tabela principal de pedidos no ACTICO. Exemplos BaixoMédioAlto | |||
| Status da solicitação ApplicationStatus | O resultado final ou o estado atual do pedido de onboarding do cliente. | ||
| Descrição Este atributo indica a disposição final de um case, normalmente 'Aprovado' ou 'Rejeitado'. Também pode mostrar o status de cases em andamento. É uma dimensão crítica para análises baseadas em resultados. Entender por que os pedidos são aprovados ou rejeitados é um objetivo central do Process Mining em KYC. Este atributo permite filtrar o mapa para ver as jornadas típicas de pedidos aprovados versus rejeitados, ajudando a identificar padrões que levam a resultados indesejados. É também a base para o cálculo do KPI de 'Taxa de Rejeição de Pedidos'. Por que é importante Define o resultado de cada caso, permitindo a análise comparativa entre instâncias de sucesso e falha, além do cálculo das taxas de rejeição. Onde obter Este é um atributo do nível do case, geralmente na tabela principal de pedidos no ACTICO. Reflete o status final da solicitação. Exemplos AprovadoRejeitadoEm ProgressoInformação Pendente | |||
| Usuário solicitante InitiatingUser | O ID de usuário ou nome do funcionário que realizou a atividade. | ||
| Descrição Este atributo identifica o usuário específico ou agente do sistema responsável por executar uma atividade. Ele vincula as etapas do processo aos indivíduos ou equipes que as realizaram. A análise de performance por usuário é um requisito comum. Este atributo permite criar Dashboards que mostram a distribuição da carga de trabalho, tempos de processamento individuais e comparações entre usuários ou times. Ajuda a identificar talentos de alta performance e quem precisa de treinamento, sendo fundamental para entender a alocação e utilização de recursos. Por que é importante Vincula as atividades do processo a usuários específicos, permitindo analisar o desempenho por pessoa ou equipe e ajudando a identificar necessidades de treinamento ou desequilíbrio de recursos. Onde obter Geralmente armazenado junto com cada evento nas tabelas de log ou histórico de transações do ACTICO. Consulte a documentação do ACTICO. Exemplos john.doejane.smithSYSTEM_USER | |||
| É Automatizado IsAutomated | Um indicador que mostra se a atividade foi executada automaticamente pelo sistema ou manualmente por um usuário. | ||
| Descrição Este atributo booleano diferencia tarefas executadas por humanos daquelas realizadas por automação, como uma verificação de antecedentes automática ou pontuação de risco. Analisar esse atributo ajuda a avaliar a eficácia das iniciativas de automação. Ele permite comparar tempos de processamento entre etapas manuais e automáticas, identifica quais partes ainda são pesadamente manuais e destaca oportunidades de automação para aumentar a eficiência e reduzir custos operacionais. Por que é importante Diferencia tarefas humanas de tarefas do sistema, o que é fundamental para medir o impacto da automação e identificar oportunidades de ganho de eficiência. Onde obter Isso pode ser inferido do atributo 'InitiatingUser' (ex: se o usuário for 'SYSTEM') ou pode ser uma flag dedicada no Event Log. Consulte a documentação do ACTICO. Exemplos verdadeirofalse | |||
| É Retrabalho IsRework | Um indicador calculado que identifica se uma atividade é uma etapa repetida ou parte de um loop de retrabalho. | ||
| Descrição Este atributo booleano sinaliza atividades executadas pela segunda vez ou mais no mesmo case, como uma 'Revisão de Documentos' após um pedido de mais informações. Identifica instâncias de retrabalho, fonte comum de ineficiência. Identificar retrabalho é um objetivo central do Process Mining. Esta flag permite quantificar o retrabalho, como no cálculo do KPI de 'Taxa de Retrabalho Documental'. No mapa, os loops de retrabalho podem ser destacados para mostrar onde o processo está voltando sobre si mesmo, ajudando a localizar problemas de qualidade onde o processo não foi feito corretamente da primeira vez. Por que é importante Destaca casos de trabalho repetido, permitindo medir diretamente a ineficiência do processo e identificar atividades com problemas de qualidade ou clareza. Onde obter Este é um atributo calculado. A lógica é definida na ferramenta de Process Mining ou durante a transformação de dados para detectar atividades repetidas no mesmo case. Exemplos verdadeirofalse | |||
| Estado do SLA SlaState | Um status calculado indicando se o caso cumpriu, violou ou está em risco de violar seu SLA. | ||
| Descrição Este atributo oferece uma avaliação categórica da performance de um case em relação ao seu SLA. É derivado da comparação do tempo de conclusão (ou tempo atual para cases abertos) com a 'SlaTargetDate'. Este atributo simplifica os relatórios de SLA, convertendo comparações de datas em um status fácil de entender. Os Dashboards podem usar isso para visualizações claras, como gráficos de pizza que mostram a porcentagem de cases que 'Cumpriram' versus 'Violaram' o prazo. É um elemento essencial para o Dashboard de performance de SLA e suporta o KPI de 'Taxa de Adesão ao SLA'. Por que é importante Fornece um status categórico claro da conformidade do SLA para cada case, simplificando os relatórios e permitindo a fácil visualização da performance em relação às metas. Onde obter Este é um atributo calculado derivado da lógica de negócio que compara o timestamp de conclusão do case com a 'SlaTargetDate'. Exemplos AtingidoVioladoEm Risco | |||
| País Country | O país de residência do cliente que está solicitando o onboarding. | ||
| Descrição Este atributo especifica o país do cliente, o que pode impactar significativamente o processo KYC. Diferentes jurisdições têm requisitos regulatórios distintos, o que pode acionar etapas extras ou alternativas. Analisar o processo por país permite comparar a performance entre regiões. Ajuda a identificar se certos países têm tempos de ciclo mais longos ou taxas de rejeição maiores, indicando possíveis atritos regulatórios ou desafios de mercado. Essa visão geográfica é importante para empresas globais que buscam padronizar processos respeitando as necessidades locais. Por que é importante Oferece uma dimensão geográfica para análise, ajudando a entender variações de processo e diferenças de performance entre várias jurisdições regulatórias. Onde obter Esta é uma informação fundamental do cliente, armazenada no nível do case ou do cliente no sistema ACTICO. Exemplos EUADEUGBRSGP | |||
| Tempo de Processamento ProcessingTime | A duração do tempo gasto a trabalhar ativamente numa atividade. | ||
| Descrição O Tempo de Processamento é a duração calculada entre o início e o fim de uma atividade. Esta métrica representa o "tempo de toque" ou o tempo de trabalho ativo, em oposição ao tempo de espera entre as atividades. Este é um KPI crítico para medir a eficiência operacional. Tempos de processamento altos em certas atividades são indicadores claros de gargalos ou tarefas excessivamente complexas. Ao consolidar esta métrica, os gestores podem identificar quais etapas consomem mais recursos e priorizá-las para melhorias de processo ou iniciativas de automação. É um componente fundamental dos Dashboards de performance. Por que é importante Mede a duração do trabalho ativo em uma tarefa, ajudando a localizar atividades ineficientes que consomem mais tempo e recursos. Onde obter Esta é uma métrica calculada, subtraindo o 'EventTime' (Horário de Início) do 'EndTime' de cada atividade. Exemplos 864000003600000600000 | |||
| Tipo de Cliente CustomerType | Categorização do cliente, como Pessoa Física ou Pessoa Jurídica. | ||
| Descrição Este atributo classifica o solicitante em categorias, como pessoa física ou jurídica. O processo KYC costuma variar significativamente entre esses tipos, sendo o onboarding corporativo bem mais complexo. Usar o Tipo de Cliente como dimensão permite a separação e comparação desses processos distintos no mesmo conjunto de dados. Analistas podem filtrar o mapa para ver apenas clientes 'Corporate' para entender seus desafios, gargalos e tempos de ciclo únicos, sem que os dados sejam distorcidos pelo processo muito mais simples de clientes 'Pessoa Física'. Por que é importante Permite segmentar o processo por diferentes categorias de clientes, que costumam ter fluxos e complexidades distintas, resultando em análises mais precisas. Onde obter Este é um atributo fundamental armazenado no nível do case ou do cliente dentro do ACTICO. Exemplos Pessoa FísicaPessoa JurídicaPequena Empresa | |||
Atividades de Onboarding de Clientes KYC
| Atividade | Descrição | ||
|---|---|---|---|
| Avaliação de Risco Realizada | Esta atividade representa a execução do motor de decisão do ACTICO para calcular um score de risco para o pedido do cliente. Como uma função central do sistema, é capturada como um evento explícito quando o conjunto de regras de avaliação de risco é executado. | ||
| Por que é importante A avaliação de risco é um ponto de decisão crucial que geralmente dita o caminho seguinte no processo. Analisar esta atividade ajuda a entender como os níveis de risco influenciam as variantes e os prazos. Onde obter Este é um evento central do ACTICO e deve estar nos logs de decisão ou execução. Esses logs costumam conter o ID do case, as regras executadas e o score de risco resultante. Captura Evento registrado pelo mecanismo de decisão do ACTICO após a conclusão da pontuação de risco. Tipo de evento explicit | |||
| Candidatura enviada | Esta atividade marca o início do processo de onboarding KYC quando um novo pedido é formalmente recebido pelo sistema ACTICO. É capturada como um evento explícito, geralmente registrada com um timestamp preciso na criação de um novo case ou registro de pedido. | ||
| Por que é importante Como principal evento inicial, esta atividade é essencial para calcular o tempo total do ciclo de onboarding e rastrear o volume. Ela serve como a base temporal para todas as medições de desempenho subsequentes. Onde obter Geralmente é uma entrada explícita em um log de criação de pedido ou case no ACTICO. Procure por tabelas de eventos de envio ou pelo timestamp de criação do registro principal. Captura Evento registrado na criação de uma nova instância de caso de solicitação. Tipo de evento explicit | |||
| Documentos do cliente carregados | Esta atividade ocorre quando o cliente fornece a identificação e documentos obrigatórios através de um portal ou outro canal integrado ao ACTICO. Cada upload de documento costuma ser capturado como um evento explícito e distinto no log do case ou sistema de gestão documental. | ||
| Por que é importante Este marca um marco fundamental que depende do cliente. Rastrear este evento é crucial para medir os tempos de resposta do cliente e analisar a duração da fase seguinte de revisão documental. Onde obter Procure logs relacionados ao manuseio de documentos ou anexos do caso. Eles costumam ser registrados em tabelas dedicadas de gerenciamento de documentos ou evidências no banco de dados do ACTICO. Captura Evento registrado pelo sistema quando um documento é anexado ao caso. Tipo de evento explicit | |||
| Onboarding de cliente concluído | Esta é a atividade final do processo, indicando que o cliente está totalmente onboarded e o case foi encerrado. É inferida por um status terminal como 'Onboarded' ou 'Fechado - Aprovado'. | ||
| Por que é importante Sendo o principal evento final de sucesso, esta atividade é essencial para calcular o tempo de ciclo de ponta a ponta dos clientes integrados. Ela fornece o carimbo de data/hora final para a análise do fluxo ideal. Onde obter Inferido do campo de status final do caso de solicitação. Procure o carimbo de data/hora associado à mudança do caso para um status de sucesso terminal. Captura Inferido a partir da atualização final do status do caso para 'Concluído' ou 'Encerrado'. Tipo de evento inferred | |||
| Revisão de conformidade concluída | Marca o fim da revisão manual, com a decisão de aprovar, rejeitar ou pedir mais dados. Esta atividade é inferida pela mudança de status de 'Revisão de Conformidade Pendente' para um estado posterior, como 'Conformidade Aprovada'. | ||
| Por que é importante Este é o evento de encerramento da fase de revisão de conformidade. É essencial para calcular a duração total da revisão e analisar a produtividade da equipe. Onde obter Inferido do log de histórico de status da solicitação. Procure o carimbo de data/hora quando o caso sai do estado 'Em Revisão de Conformidade', indicando que uma decisão foi tomada. Captura Inferido a partir da mudança do status do caso de 'Conformidade Pendente' para 'Conformidade Aprovada' ou similar. Tipo de evento inferred | |||
| Revisão de conformidade iniciada | Marca o início da fase de revisão manual pela equipe de conformidade, geralmente para casos de alto risco. Costuma ser inferido pela mudança de status para 'Revisão de Conformidade Pendente' ou atribuição do caso a um revisor. | ||
| Por que é importante Esta atividade é o ponto de partida para medir o gargalo de conformidade. O tempo decorrido até 'Revisão de Conformidade Concluída' é um KPI crítico para identificar atrasos nesta fase crucial. Onde obter Inferido do histórico de status ou trilha de auditoria. Procure o registro de data/hora associado à mudança para 'Em Revisão de Conformidade' ou atribuição a um grupo de usuários de conformidade. Captura Inferido a partir da mudança do status do caso para 'Conformidade Pendente' ou atribuição à equipe de conformidade. Tipo de evento inferred | |||
| Solicitação aprovada | Esta atividade representa a decisão final de negócio para aprovar o pedido de onboarding do cliente. É um marco fundamental, capturado como uma mudança de status final e distinta no ciclo de vida do pedido. | ||
| Por que é importante Este marco precede a criação da conta e indica um desfecho positivo. Analisar o tempo para atingir este ponto é crucial para entender a duração do "caminho feliz". Onde obter Inferido do campo de status final na tabela principal. Procure por status como 'Aprovado', 'Aprovação Concluída' ou estado terminal positivo similar. Captura O status final do case é atualizado para 'Aprovado' nos dados mestres do case. Tipo de evento inferred | |||
| Solicitação rejeitada | Representa a decisão final de rejeitar o pedido do cliente, encerrando o processo de onboarding. Este é um estado final crítico, capturado através da mudança de status final no registro do pedido. | ||
| Por que é importante Este é o principal evento de falha final. Analisar cases que terminam com esta atividade é crucial para entender as taxas de rejeição, motivos de falha e melhorar o rendimento geral do processo. Onde obter Inferido do campo de status final na tabela principal. Procure por status terminais como 'Rejeitado', 'Recusado' ou 'Encerrado - Rejeitado'. Captura O status final do case é atualizado para 'Rejeitado' nos dados mestres do case. Tipo de evento inferred | |||
| Conta criada | Após a aprovação, esta atividade marca a criação técnica da conta do cliente no core banking. Geralmente é um evento explícito registrado pelo ACTICO após receber a confirmação de sucesso do sistema de destino. | ||
| Por que é importante Esta atividade confirma que o processo resultou em um desfecho de negócio tangível. O tempo entre 'Pedido Aprovado' e 'Conta Criada' pode revelar atrasos de integração ou ineficiências nas etapas finais de provisionamento. Onde obter Essa informação provavelmente estaria em logs de integração ou de interface no ACTICO, que registram o resultado de chamadas para sistemas externos para provisionamento de conta. Captura Evento registrado ao receber uma resposta de API bem-sucedida do sistema de contas principal. Tipo de evento explicit | |||
| Informações Adicionais Solicitadas | Representa um evento onde um revisor, geralmente de compliance ou análise de risco, solicita mais informações ou documentos ao cliente. Esta ação costuma ser capturada explicitamente, pois envolve o envio de uma notificação ao cliente e a pausa no case. | ||
| Por que é importante Esta atividade é um dos principais geradores de retrabalho e aumento nos tempos de ciclo. Acompanhar sua frequência e impacto é essencial para identificar onde a coleta inicial de dados pode ser melhorada. Onde obter Provavelmente é um evento explícito no histórico do case ou log de comunicação. Procure por eventos como 'RFI Sent' ou mudança de status para 'Pendente de Informações do Cliente'. Captura Um evento explícito acionado pelo usuário, como 'Enviar RFI', é registrado na trilha de auditoria do caso. Tipo de evento explicit | |||
| Revisão de documentos concluída | Esta atividade significa que um atendente terminou de revisar os documentos enviados pelo cliente. Geralmente é inferida a partir de uma mudança de status no documento ou no case, como 'Documentos Verificados' ou 'Revisão Concluída'. | ||
| Por que é importante Este é um marco importante para medir a eficiência do manuseio de documentos. O tempo entre 'Documentos do Cliente Enviados' e esta atividade é um KPI crítico para identificar atrasos no processamento manual. Onde obter Inferido pelos logs de histórico de status do caso ou de documentos individuais. Uma mudança de 'Revisão Pendente' para 'Aprovado' ou 'Revisado' indica esta atividade. Captura Inferido a partir da mudança do status do documento para 'Verificado' ou 'Revisado'. Tipo de evento inferred | |||
| Revisão inicial da solicitação | Representa a primeira revisão do pedido enviado, seja por uma regra automatizada ou por um atendente humano, para verificar se está completo e possui elegibilidade básica. Esta atividade costuma ser inferida por uma mudança de status, por exemplo, de "Enviado" para "Em Revisão". | ||
| Por que é importante Analisar o tempo desta primeira revisão ajuda a identificar atrasos iniciais e mostra quantas solicitações passam por este primeiro filtro sem problemas. Onde obter Inferido das tabelas de histórico ou logs de auditoria do caso. Compare o carimbo de data/hora de quando o status muda de 'novo' ou 'enviado' para o estado de 'revisão'. Captura Detectar mudança de status de 'Enviado' para 'Em Revisão' no log de histórico do caso. Tipo de evento inferred | |||
| Verificação de identidade realizada | Representa uma verificação automatizada ou manual para validar a identidade do cliente em relação a fontes de dados externas ou internas. Isso geralmente é registrado como um evento explícito quando uma chamada de API para um serviço de verificação de terceiros é feita e uma resposta é recebida. | ||
| Por que é importante Esta atividade é uma etapa crítica de conformidade. Analisar sua duração e resultados ajuda a identificar dependências de serviços externos e possíveis gargalos no processo de verificação. Onde obter Essa informação costuma estar em logs de integração ou tabelas de eventos específicas que registram os resultados de verificações automáticas e chamadas de serviços externos vinculados ao case. Captura Evento registrado a partir de uma chamada de integração para um serviço de verificação de identidade de terceiros. Tipo de evento explicit | |||
| Verificações de antecedentes iniciadas | Representa o ponto de início das verificações automáticas ou manuais, como AML ou histórico de crédito. Costuma ser registrado como evento explícito quando o sistema dispara essas verificações, que podem envolver provedores externos. | ||
| Por que é importante Iniciar a verificação de antecedentes é um marco importante na due diligence. Rastrear isso ajuda a entender dependências e prazos de fornecedores externos. Onde obter Procure registros nos logs do sistema ou trilha de auditoria que indiquem o disparo dos procedimentos de triagem de antecedentes. Geralmente estão vinculados ao ID do caso principal. Captura Evento registrado quando o mecanismo de workflow inicia chamadas para serviços de verificação de antecedentes. Tipo de evento explicit | |||
Guias de Extração
Etapas
- Obtenha acesso administrativo: Acesse a plataforma ACTICO, como o Visual Modeler ou o console de administração, usando credenciais com permissões suficientes para configurar exportações de dados.
- Localize o módulo de exportação: Navegue até a área de administração ou configuração do sistema. Procure a seção de trilhas de auditoria, logs ou exportação de dados (geralmente rotulada como 'Audit Export' ou 'Business Object Export').
- Crie uma nova configuração de exportação: Inicie a criação de uma nova definição de exportação. Dê um nome descritivo, como 'KYC_Onboarding_ProcessMind_Export'.
- Defina a fonte de dados: Selecione o objeto de negócio principal a ser exportado:
CustomerApplication. É crucial aplicar um filtro de intervalo de datas (por exemplo, os últimos 6 meses) para garantir que os arquivos sejam gerenciáveis. - Configure o arquivo de saída: Defina o formato como CSV. Nomeie o arquivo como
kyc_event_log.csve use a vírgula como delimitador padrão. Garanta que os campos de texto usem aspas para tratar caracteres especiais. - Mapeie o identificador do caso: Defina o identificador exclusivo do objeto
CustomerApplicationcomo o ID do caso para a análise de Process Mining. Isso vincula todos os eventos a um único processo de onboarding. - Defina o mapeamento de atributos: Para cada coluna do event log, faça o mapeamento para o atributo correspondente no modelo do ACTICO. Isso inclui ID do caso, nome da atividade, carimbos de data/hora e atributos como status ou nível de risco.
- Configure os mapeamentos de eventos: Esta é a etapa mais importante. Crie uma regra para cada uma das atividades de negócio. Use gatilhos do sistema, como criação de objeto para 'Application Submitted', mudanças de status para 'Application Approved' e padrões de log para eventos técnicos como 'Identity Verification Performed'.
- Salve e valide a configuração: Após mapear tudo, salve o arquivo. Use as ferramentas de validação do ACTICO para conferir erros de sintaxe ou caminhos de atributos incorretos.
- Execute e monitore a exportação: Inicie o trabalho de exportação. Monitore o progresso pelo agendador do sistema ou interface de monitoramento e verifique se há erros nos logs após a conclusão.
- Recupere e prepare o arquivo: Baixe o arquivo CSV gerado. Antes de carregar no ProcessMind, abra o arquivo para verificar a estrutura e garantir que os formatos de data e hora estejam consistentes e corretos.
Configuração
- Nível de Log de Auditoria: O nível de log de auditoria em todo o sistema deve ser definido com uma configuração detalhada, como INFO ou FINE. Um nível menos detalhado, como WARNING ou ERROR, não capturará as mudanças de status e execuções de regras necessárias para o Process Mining.
- Fonte de Dados de Exportação: A fonte de dados principal deve ser configurada para usar o objeto de negócio
CustomerApplication. Pode ser necessário unir ou referenciar objetos relacionados, como oCustomerDocument, para capturar todos os eventos relevantes. - Filtro de Intervalo de Datas: Sempre use um filtro de intervalo de datas para controlar a quantidade de dados extraídos. Para uma análise inicial, recomenda-se um período de 3 a 6 meses. Para produção, isso pode ser ajustado com base nas necessidades do negócio e no desempenho do sistema.
- Lógica de Mapeamento de Eventos: A precisão da extração depende muito de como os eventos são mapeados. Mudanças de status (
on="StatusChange") são comuns para inferir etapas de negócio. Entradas de log explícitas (on="LogEntry") são úteis para eventos técnicos ou chamadas de serviço. Execuções de regras (on="RuleExecution") são ideais para capturar etapas de decisão. - Formato de Saída: Selecione CSV como formato de saída para garantir ampla compatibilidade. Certifique-se de que a configuração de delimitadores e as aspas de texto estejam definidas corretamente para evitar problemas no processamento dos dados.
- Pré-requisitos: Este método exige permissões administrativas na plataforma ACTICO. É essencial ter uma compreensão profunda do modelo de objetos de negócio de KYC, incluindo todos os campos de status e nomes de atributos relevantes, para uma configuração precisa.
a Consulta de Exemplo config
<!-- This is a representative ACTICO export configuration in XML format. -->
<!-- Actual syntax may vary based on your ACTICO version. -->
<AuditExportConfiguration name="KYC_ProcessMind_Export">
<DataSource type="BusinessObject">
<ObjectName>CustomerApplication</ObjectName>
<DateRange from="[Start Date YYYY-MM-DD]" to="[End Date YYYY-MM-DD]"/>
</DataSource>
<OutputFile format="CSV" name="kyc_event_log.csv" delimiter=","/>
<CaseId mapping="customerApplication.id"/>
<Attributes>
<Attribute name="CustomerApplication" mapping="customerApplication.id"/>
<Attribute name="ActivityName" mapping="[generated_activity_name]"/>
<Attribute name="EventTime" mapping="[event_timestamp]"/>
<Attribute name="SourceSystem" value="ACTICO"/>
<Attribute name="LastDataUpdate" value="[CURRENT_TIMESTAMP]"/>
<Attribute name="EndTime" mapping="[event_timestamp]"/>
<Attribute name="InitiatingUser" mapping="event.user"/>
<Attribute name="Department" mapping="event.user.department"/>
<Attribute name="ApplicationStatus" mapping="customerApplication.status"/>
<Attribute name="RejectionReason" mapping="customerApplication.rejectionDetails.reasonCode"/>
<Attribute name="RiskLevel" mapping="customerApplication.risk.level"/>
<Attribute name="SlaTargetDate" mapping="customerApplication.slaDate"/>
</Attributes>
<EventMappings>
<Event on="Create" object="CustomerApplication">
<Set name="[generated_activity_name]" value="Application Submitted"/>
<Set name="[event_timestamp]" mapping="customerApplication.creationDate"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" from="Submitted" to="In Review">
<Set name="[generated_activity_name]" value="Initial Application Review"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="Create" object="CustomerDocument">
<Set name="[generated_activity_name]" value="Customer Documents Uploaded"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
<CaseId mapping="event.relatedObject.customerApplication.id"/>
</Event>
<Event on="LogEntry" object="CustomerApplication" messagePattern="IDV Service Call Completed.*">
<Set name="[generated_activity_name]" value="Identity Verification Performed"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" to="Documents Verified">
<Set name="[generated_activity_name]" value="Document Review Completed"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="LogEntry" object="CustomerApplication" messagePattern="Background Check Initiated.*">
<Set name="[generated_activity_name]" value="Background Checks Initiated"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="RuleExecution" object="CustomerApplication" ruleSet="KYC Risk Assessment">
<Set name="[generated_activity_name]" value="Risk Assessment Performed"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" to="Pending Compliance Review">
<Set name="[generated_activity_name]" value="Compliance Review Initiated"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" to="Pending Customer Information">
<Set name="[generated_activity_name]" value="Additional Information Requested"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" from="Pending Compliance Review" to="Compliance Approved">
<Set name="[generated_activity_name]" value="Compliance Review Completed"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" to="Approved">
<Set name="[generated_activity_name]" value="Application Approved"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="LogEntry" object="CustomerApplication" messagePattern="Account successfully created.*">
<Set name="[generated_activity_name]" value="Account Created"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" to="Closed - Approved">
<Set name="[generated_activity_name]" value="Customer Onboarding Completed"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" to="Rejected">
<Set name="[generated_activity_name]" value="Application Rejected"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
</EventMappings>
</AuditExportConfiguration>