Seu Template de dados para onboarding KYC de clientes
Seu Template de dados para onboarding KYC de clientes
- Atributos recomendados para coleta
- Principais atividades a acompanhar
- Orientações de extração para o ACTICO
Atributos da integração de clientes KYC
| Nome | Descrição | ||
|---|---|---|---|
| Hora do evento EventTime | O carimbo de data e hora que indica quando uma atividade específica começou ou ocorreu. | ||
| Descrição A hora do evento é a data e o horário exatos em que uma atividade foi registrada no sistema. Ela fornece a ordem cronológica de todos os eventos dentro de um único caso de solicitação do cliente, formando a linha do tempo da jornada de onboarding. Este atributo é fundamental para todas as análises baseadas em tempo. Ele é usado para calcular os tempos de ciclo entre atividades, identificar atrasos e tempos de espera, medir a duração total do caso e verificar a conformidade com os Acordos de Nível de Serviço (SLAs). A sequência desses carimbos de data e hora para um determinado caso permite que as ferramentas de Process Mining reconstruam o fluxo exato do processo como ele aconteceu. Por que isso importa Este atributo fornece a ordem cronológica dos eventos, essencial para calcular durações, descobrir gargalos e analisar a linha do tempo do processo. Onde obter Localizado nas tabelas de Event Log do ACTICO, este é o carimbo de data e 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 | |||
| Nome da atividade ActivityName | O nome do evento ou da tarefa comercial específica realizada no processo de onboarding do cliente. | ||
| Descrição Este atributo registra o nome de cada etapa ou atividade que ocorre durante o processo de KYC, como 'Solicitação enviada', 'Avaliação de risco realizada' ou 'Solicitação aprovada'. Ele fornece os blocos sequenciais que formam o mapa do processo. Analisar o nome da atividade permite visualizar o fluxo do processo, identificar atividades frequentes ou raras e detectar gargalos ou ciclos de retrabalho. É um elemento central para entender quais ações estão sendo realizadas e em que ordem, algo essencial para a análise de variantes e as verificações de conformidade. Por que isso importa Ele define as etapas do mapa do processo, permitindo visualizar o fluxo do processo, identificar desvios e analisar a frequência e a sequência das atividades. Onde obter Essas informações normalmente estão em uma tabela de Event Log no ACTICO, geralmente em um campo que descreve o tipo de evento ou tarefa. Consulte a documentação do ACTICO. Exemplos Solicitação enviadaAvaliação de risco realizadaRevisão de conformidade concluídaSolicitação rejeitada | |||
| Solicitação do cliente CustomerApplication | O identificador exclusivo de uma única solicitação de onboarding de cliente, usado como ID do caso para análise do processo. | ||
| Descrição A solicitação do cliente é o principal identificador do caso que agrupa todos os eventos e atividades relacionados à jornada de onboarding de um único cliente. Ela representa uma instância completa do processo de KYC, desde o envio inicial até a decisão final de aprovação ou rejeição. No Process Mining, esse atributo é essencial para reconstruir a jornada de ponta a ponta de cada solicitação. Ele permite que os analistas acompanhem a sequência de atividades, meçam os tempos totais de ciclo e comparem diferentes caminhos ou variantes do processo percorridos pelas solicitações. Todos os eventos que compartilham o mesmo ID da solicitação do cliente são considerados parte do mesmo caso. Por que isso importa Este é o atributo fundamental para Process Mining, pois conecta todos os eventos relacionados em uma única instância de processo coesa, permitindo a análise de ponta a ponta da experiência de onboarding de cada cliente. Onde obter Esta é uma chave primária nas principais tabelas de solicitações ou gerenciamento de casos do ACTICO. Consulte a documentação do ACTICO para conhecer os nomes específicos de tabelas e campos. Exemplos APP-2023-001234APP-2023-001235APP-2024-000001 | |||
| Sistema de origem SourceSystem | O sistema de registro de onde os dados dos eventos são originados. | ||
| Descrição Este atributo identifica o sistema de informação de origem onde os dados foram gerados. Para este processo, ele será sempre 'ACTICO', mas, em análises mais amplas que envolvem vários sistemas, ajuda a diferenciar as origens dos dados. No contexto de Process Mining, ele é fundamental para a governança e a validação dos dados. Garante que os dados sejam atribuídos corretamente à sua origem, o que é importante ao combinar dados de diferentes sistemas para criar uma visão holística do processo. Também ajuda a solucionar problemas de qualidade dos dados, rastreando-os até o sistema de origem. Por que isso importa Fornece contexto essencial sobre a origem dos dados, garantindo a linhagem e a governança dos dados, algo crítico ao combinar dados de várias fontes. Onde obter Normalmente, este é um valor estático ('ACTICO') adicionado durante o processo de extração e transformação dos dados para identificar o conjunto de dados. Exemplos ACTICOACTICO PlatformActico KYC Module | |||
| Última atualização dos dados LastDataUpdate | O carimbo de data e hora que indica a última vez em que os dados foram atualizados ou extraídos do sistema de origem. | ||
| Descrição Este atributo registra a data e o horário da extração mais recente de dados do ACTICO. É um campo de metadados que se aplica ao conjunto de dados inteiro, e não a eventos individuais, fornecendo contexto sobre a atualidade da análise. Em Dashboards e relatórios, essas informações são essenciais para que os usuários entendam o quanto os dados estão atualizados. Elas ajudam a alinhar as expectativas sobre a atualidade dos insights e são fundamentais para o monitoramento operacional quando dados quase em tempo real são importantes. Exibir esse carimbo de data e hora garante transparência e confiança nos dados apresentados. Por que isso importa Indica a atualidade dos dados, permitindo que os usuários entendam se estão analisando informações atualizadas, algo crítico para a tomada de decisões operacionais. Onde obter Este valor é gerado e armazenado durante o processo de extração, transformação e carregamento (ETL) dos dados. Ele reflete o carimbo de data e hora em que o job de ETL foi concluído com sucesso. Exemplos 2024-05-20T08:00:00Z2024-05-21T08:00:00Z | |||
| Data-alvo do SLA SlaTargetDate | A data até a qual se espera que o processo de onboarding do cliente seja concluído. | ||
| Descrição A Data-alvo do SLA é o prazo para concluir o onboarding de um cliente, conforme definido pelos acordos internos de nível de serviço. Essa data geralmente é calculada com base na data de envio da aplicação mais um tempo padrão de processamento. Esse atributo é essencial para monitorar a conformidade com o SLA. Comparando a data real de conclusão de um caso com a Data-alvo do SLA, o sistema pode determinar se o caso foi concluído no prazo ou se violou o SLA. Esse é o fundamento do Dashboard “Performance do SLA de Onboarding” e do KPI “Taxa de Cumprimento do SLA de Onboarding”. Por que isso importa Fornece a referência para medir a performance dentro do prazo, permitindo o monitoramento e a geração de relatórios sobre a conformidade com o SLA. Onde obter Pode ser armazenado como um campo na tabela principal de casos do ACTICO ou ser derivado com base em regras de negócio, por exemplo, 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 a equipe de negócio responsável por realizar a atividade. | ||
| Descrição Este atributo atribui uma atividade a uma unidade organizacional específica, como 'Conformidade', 'Equipe de onboarding' ou 'Relacionamento com clientes'. Ele fornece um contexto organizacional ao fluxo do processo. A análise por departamento é fundamental para entender como o trabalho é transferido entre diferentes áreas da organização. Ela ajuda a identificar gargalos entre departamentos, medir a eficiência departamental 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 suas equipes. Por que isso importa Fornece uma dimensão organizacional para a análise, permitindo identificar atrasos entre departamentos e avaliar a performance no nível da equipe. Onde obter Essas informações podem estar armazenadas diretamente com os dados do evento ou ser derivadas da combinação dos dados de usuários com uma tabela de dados mestres de RH que relaciona usuários a departamentos. Consulte a documentação do ACTICO. Exemplos ComplianceEquipe de onboardingAtendimento ao cliente | |||
| Hora de término EndTime | O carimbo de data e hora que indica quando uma atividade específica foi concluída. | ||
| Descrição A hora de término marca a conclusão de uma atividade. Junto com a hora de início (EventTime), ela permite calcular a duração precisa de cada tarefa, conhecida como tempo de processamento. Nem todos os eventos têm uma hora de término distinta, 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 criar Dashboards detalhados de performance, ajuda a identificar quais atividades consomem mais tempo e é essencial para calcular KPIs como 'Tempo médio de revisão de documentos'. Por que isso importa Permite calcular a duração precisa das atividades (tempo de processamento), algo fundamental para identificar gargalos de performance e analisar a eficiência dos recursos. Onde obter Assim como a hora de início, este dado normalmente está nas tabelas de Event Log do ACTICO. Alguns sistemas armazenam as horas de início e término em colunas separadas para um único registro de evento. 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 informado quando uma solicitação de cliente é rejeitada. | ||
| Descrição Quando o status final de uma solicitação é 'Rejeitada', este atributo informa a causa subjacente. Alguns exemplos são 'Documentação incompleta', 'Verificação de antecedentes reprovada' ou 'Perfil de alto risco'. Este é um atributo essencial para a análise de causas-raiz. Ao analisar a frequência dos diferentes motivos de rejeição, a empresa pode identificar problemas sistêmicos no processo ou nos envios dos clientes. Por exemplo, um número elevado de rejeições por documentação incompleta pode indicar que as instruções da solicitação não estão claras. Isso dá suporte direto ao Dashboard 'Taxa e motivos de rejeição de solicitações'. Por que isso importa Explica o motivo por trás das rejeições de solicitações, permitindo analisar as causas-raiz para reduzir a taxa de rejeição e melhorar a eficiência do processo. Onde obter Geralmente encontrado na tabela principal de casos ou solicitações do ACTICO, sendo preenchido apenas quando o status da solicitação é 'Rejeitada'. Exemplos Documentação incompletaFalha na verificação de identidadeCorrespondência com lista de sançõesPontuação de risco alta | |||
| Nível de risco RiskLevel | O nível de risco calculado para a solicitação 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 e aprovações adicionais em comparação com um cliente de baixo risco. No Process Mining, o Nível de Risco é uma dimensão poderosa para análises comparativas. Ele permite que os analistas verifiquem se o processo segue corretamente caminhos diferentes com base no risco, conforme planejado. Por exemplo, é possível confirmar se todos os clientes de alto risco passam por uma etapa aprimorada de due diligence. Esse atributo é essencial para o Dashboard “Fluxos do Processo de Avaliação de Risco”. Por que isso importa Permite segmentar os casos com base no risco, possibilitando analisar se o processo se adapta corretamente a diferentes perfis de risco, conforme exigido pelas políticas de conformidade. Onde obter Este é um dado importante armazenado no nível do caso, na tabela principal da aplicação dentro do ACTICO. Exemplos BaixoMédioAlto | |||
| Status da solicitação ApplicationStatus | O resultado final ou o estado atual da solicitação de onboarding do cliente. | ||
| Descrição Este atributo indica o desfecho final de um caso, normalmente 'Aprovado' ou 'Rejeitado'. Ele também pode mostrar o status de casos em andamento. É uma dimensão crítica para análises baseadas em resultados. Entender por que as solicitações são aprovadas ou rejeitadas é um dos principais objetivos do Process Mining de processos de KYC. Este atributo permite filtrar o mapa do processo para visualizar as jornadas típicas de solicitações aprovadas e rejeitadas, ajudando a identificar padrões que levam a resultados indesejados. Ele também é a base para calcular o KPI 'Taxa de rejeição de solicitações'. Por que isso importa Define o resultado de cada caso, permitindo comparar instâncias de processo bem-sucedidas e malsucedidas e calcular as taxas de rejeição. Onde obter Este é um atributo no nível do caso, geralmente encontrado na tabela principal de casos ou solicitações do ACTICO. Ele reflete o status final da solicitação. Exemplos AprovadoRejeitadoEm andamentoAguardando informações | |||
| Usuário iniciador InitiatingUser | O ID ou nome do funcionário que realizou a atividade. | ||
| Descrição Este atributo identifica o usuário específico ou o agente do sistema responsável por executar uma atividade. Ele vincula as etapas do processo às pessoas ou equipes que as realizaram. Analisar a performance por usuário é uma necessidade comum. Este atributo permite criar Dashboards que mostram a distribuição da carga de trabalho, os tempos de processamento individuais e comparações de performance entre usuários ou equipes. Ele ajuda a identificar profissionais de alto desempenho e aqueles que podem precisar de treinamento adicional, além de ser essencial para entender a alocação e a utilização de recursos. Por que isso importa Vincula as atividades do processo a usuários específicos, permitindo analisar a performance por pessoa ou equipe e ajudando a identificar necessidades de treinamento ou desequilíbrios de recursos. Onde obter Normalmente armazenado junto a cada evento no Event Log ou nas tabelas de histórico de transações do ACTICO. Consulte a documentação do ACTICO. Exemplos john.doejane.smithSYSTEM_USER | |||
| É automatizado IsAutomated | Um indicador que informa se uma atividade foi executada automaticamente pelo sistema ou manualmente por um usuário. | ||
| Descrição Este atributo booleano diferencia as tarefas executadas por um usuário humano daquelas realizadas por automação do sistema, como uma verificação de antecedentes automatizada ou uma pontuação de risco. Analisar esse atributo ajuda a avaliar a eficácia das iniciativas de automação. Ele permite comparar os tempos de processamento entre etapas automatizadas e manuais, identificar quais partes do processo ainda dependem muito de trabalho manual e destacar oportunidades de automação adicional para aumentar a eficiência e reduzir os custos operacionais. Por que isso importa Diferencia tarefas humanas e tarefas do sistema, algo essencial para medir o impacto da automação e identificar oportunidades futuras de ganho de eficiência. Onde obter Pode ser inferido a partir do atributo “InitiatingUser”, por exemplo, quando o usuário é “SYSTEM”, ou pode ser um indicador específico no Event Log. Consulte a documentação do ACTICO. Exemplos truefalse | |||
| É retrabalho IsRework | Um indicador calculado que identifica se uma atividade é uma etapa repetida ou faz parte de um loop de retrabalho. | ||
| Descrição Este atributo booleano sinaliza atividades executadas uma segunda vez ou mais dentro do mesmo caso, como uma “Revisão de Documento” realizada após uma solicitação de informações adicionais. Ele identifica ocorrências de retrabalho, que normalmente são uma fonte de ineficiência do processo. Identificar retrabalho é um dos principais objetivos do Process Mining. Esse indicador permite quantificar o retrabalho, por exemplo, calculando o KPI “Taxa de Retrabalho de Documentos”. No mapa do processo, os loops de retrabalho podem ser destacados para mostrar onde o processo volta sobre si mesmo. Isso ajuda a localizar problemas de qualidade ou áreas em que o processo não é executado corretamente na primeira vez. Por que isso importa Destaca ocorrências 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 dos dados para detectar atividades repetidas dentro do mesmo caso. Exemplos truefalse | |||
| 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 exigências regulatórias distintas, que podem acionar etapas adicionais ou alternativas no processo. Analisar o processo por país permite comparar a performance entre diferentes regiões. Isso ajuda a identificar se determinados países apresentam consistentemente tempos de ciclo mais longos ou taxas de rejeição mais altas, o que pode indicar atritos regulatórios ou desafios específicos do mercado. Essa visão geográfica é importante para organizações globais que buscam padronizar processos respeitando as necessidades locais de conformidade. Por que isso importa Fornece uma dimensão geográfica para a análise, ajudando a entender as variações do processo e as diferenças de performance entre diversas jurisdições regulatórias. Onde obter Esta é uma informação central do cliente, armazenada no nível do caso ou do cliente no sistema ACTICO. Exemplos USADEUGBRSGP | |||
| Status do SLA SlaState | Um status calculado que indica se o caso cumpriu, violou ou corre risco de violar o SLA. | ||
| Descrição Este atributo fornece uma avaliação categórica da performance de um caso em relação ao seu Acordo de Nível de Serviço. Ele é derivado comparando o tempo de conclusão do caso, ou o horário atual para casos abertos, com “SlaTargetDate”. Esse atributo simplifica os relatórios de SLA ao transformar comparações de datas em um status fácil de entender. Os Dashboards podem usá-lo para criar visualizações claras, como gráficos de pizza ou medidores que mostram o percentual de casos “Cumpridos” em comparação com os “Violados”. Ele é um elemento essencial do Dashboard “Performance do SLA de Onboarding” e dá suporte direto ao KPI “Taxa de Cumprimento do SLA de Onboarding”. Por que isso importa Fornece um status categórico claro da conformidade com o SLA para cada caso, simplificando os relatórios e facilitando a visualização da performance em relação às metas. Onde obter Este é um atributo calculado, derivado de uma lógica de negócio que compara o timestamp de conclusão do caso com “SlaTargetDate”. Exemplos Dentro do prazoFora do prazoEm risco | |||
| Tipo de cliente CustomerType | Classificação do cliente, como Pessoa Física ou Pessoa Jurídica. | ||
| Descrição Este atributo classifica o solicitante em diferentes categorias, por exemplo, uma pessoa física ou uma entidade corporativa. O processo KYC geralmente varia bastante entre esses tipos, e o onboarding de pessoas jurídicas costuma ser muito mais complexo. Usar o Tipo de Cliente como dimensão permite separar e comparar claramente esses processos distintos dentro do mesmo conjunto de dados. Os analistas podem filtrar o mapa do processo para visualizar apenas clientes “Pessoa Jurídica” e entender seus desafios, gargalos e tempos de ciclo específicos, sem que os dados sejam distorcidos pelo processo muito mais simples de clientes “Pessoa Física”. Por que isso importa Permite segmentar o processo para diferentes categorias de clientes, que geralmente apresentam fluxos e níveis de complexidade muito distintos, resultando em uma análise mais precisa. Onde obter Este é um atributo fundamental armazenado no nível do caso ou do cliente no ACTICO. Exemplos Pessoa físicaPessoa jurídicaPequena empresa | |||
Atividades de integração de clientes KYC
| Atividade | Descrição | ||
|---|---|---|---|
| Avaliação de risco realizada | Esta atividade representa a execução do mecanismo de decisão do ACTICO para calcular uma pontuação ou classificação de risco para a solicitação do cliente. Como uma função central do sistema, ela é registrada como um evento explícito quando o conjunto de regras de avaliação de risco é executado. | ||
| Por que isso importa A avaliação de risco é um ponto de decisão fundamental que geralmente determina o caminho seguinte do processo. Analisar essa atividade ajuda a entender como os níveis de risco influenciam as variantes e os prazos do processo. Onde obter Este é um evento central no ACTICO e deve ser registrado nos logs de decisão ou execução. Esses logs normalmente contêm o ID do caso, as regras executadas e a pontuação 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 | |||
| Documentos do cliente enviados | Esta atividade ocorre quando o cliente fornece os documentos de identificação e comprovação exigidos por meio de um portal ou outro canal integrado ao ACTICO. Cada envio de documento geralmente é registrado como um evento explícito e distinto no sistema de gerenciamento de documentos ou no log do caso. | ||
| Por que isso importa Isso marca um marco importante que depende do cliente. Acompanhar esse evento é fundamental para medir o tempo de resposta do cliente e analisar a duração da etapa seguinte de revisão de documentos. Onde obter Procure Event Logs relacionados ao tratamento de documentos ou aos anexos do caso da solicitação. Eles costumam ser registrados em tabelas específicas de documentos ou gerenciamento de evidências no banco de dados do ACTICO. Captura Evento registrado pelo sistema quando um documento é anexado ao caso. Tipo de evento explicit | |||
| Onboarding do cliente concluído | Esta é a atividade final do processo, indicando que o cliente concluiu o onboarding e que o caso da solicitação foi encerrado. Ela é inferida a partir da aplicação de um status final e terminal, como 'Onboarded' ou 'Encerrado - aprovado', ao caso. | ||
| Por que isso importa Como principal evento de encerramento bem-sucedido, esta atividade é essencial para calcular o tempo de ciclo de ponta a ponta de todos os clientes que concluíram o onboarding. Ela fornece o carimbo de data e hora final para a análise do caminho ideal. Onde obter Inferida a partir do campo de status final do caso da solicitação do cliente. Procure um carimbo de data e hora associado à mudança do caso para um status terminal de sucesso. Captura Inferida a partir da atualização do status final do caso para 'Concluído' ou 'Encerrado'. Tipo de evento inferred | |||
| Revisão de conformidade concluída | Marca o fim da revisão manual pelo departamento de conformidade, com uma decisão de aprovar, rejeitar ou solicitar uma ação adicional. Essa atividade é inferida a partir de uma mudança de status do caso de 'Aguardando revisão de conformidade' para um estado seguinte, como 'Conformidade aprovada'. | ||
| Por que isso importa Este é o evento de encerramento da etapa de revisão de conformidade. Ele é essencial para calcular a duração total da revisão de conformidade e analisar a capacidade de processamento da equipe. Onde obter Inferida a partir do log de histórico de status da solicitação. Procure o carimbo de data e hora em que o caso sai do estado 'Em revisão de conformidade', indicando que uma decisão foi tomada. Captura Inferida a partir da mudança do status do caso de 'Aguardando conformidade' para 'Conformidade aprovada' ou similar. Tipo de evento inferred | |||
| Revisão de conformidade iniciada | Marca o início da etapa de revisão manual pelo departamento de conformidade, geralmente para solicitações de alto risco ou sinalizadas. Normalmente é inferida a partir de uma mudança no status do caso para 'Aguardando revisão de conformidade' ou da atribuição do caso à fila de trabalho de um responsável por conformidade. | ||
| Por que isso importa 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 nessa etapa essencial. Onde obter Inferida a partir do histórico de status ou da trilha de auditoria da solicitação. Procure um carimbo de data e hora associado à mudança de status para 'Em revisão de conformidade' ou à atribuição a um grupo de usuários relacionado à conformidade. Captura Inferida a partir da mudança do status do caso para 'Aguardando conformidade' ou da atribuição à equipe de conformidade. Tipo de evento inferred | |||
| Solicitação aprovada | Esta atividade representa a decisão comercial final de aprovar a solicitação do cliente para onboarding. É um marco importante, normalmente registrado como uma mudança de status distinta e final no ciclo de vida da solicitação. | ||
| Por que isso importa Este marco antecede a criação da conta e representa um resultado bem-sucedido. Analisar o tempo até esse ponto é fundamental para entender a duração do 'caminho ideal'. Onde obter Inferida a partir do campo de status final na tabela principal de solicitações ou casos. Procure um status como 'Aprovada', 'Aprovação concluída' ou outro estado positivo terminal semelhante. Captura O status final do caso é atualizado para 'Aprovado' nos dados mestres do caso. Tipo de evento inferred | |||
| Solicitação enviada | Esta atividade marca o início do processo de onboarding de KYC, quando uma nova solicitação de cliente é recebida formalmente pelo sistema ACTICO. Ela é registrada como um evento explícito, normalmente com um carimbo de data e hora preciso no momento da criação de um novo caso ou registro de solicitação. | ||
| Por que isso importa Como principal evento de início, esta atividade é essencial para calcular o tempo total do ciclo de onboarding e acompanhar o volume de solicitações. Ela serve como carimbo de data e hora de referência para todas as medições posteriores de performance do processo. Onde obter Normalmente, esta é uma entrada explícita em um log de criação de solicitação ou caso no ACTICO. Procure tabelas relacionadas a eventos de envio de solicitações ou ao carimbo de data e hora de criação do registro principal do caso. Captura Evento registrado após a criação de uma nova instância de caso de solicitação. Tipo de evento explicit | |||
| Solicitação rejeitada | Representa a decisão final de rejeitar a solicitação do cliente, encerrando o processo de onboarding. É um estado final crítico, capturado por meio de uma mudança de status final no registro da solicitação. | ||
| Por que isso importa Este é o principal evento de encerramento malsucedido. Analisar os casos que terminam com esta atividade é fundamental para entender as taxas de rejeição, os motivos das falhas e como melhorar o rendimento geral do processo. Onde obter Inferida a partir do campo de status final na tabela principal de solicitações ou casos. Procure um status terminal como 'Rejeitada', 'Recusada' ou 'Encerrada - rejeitada'. Captura O status final do caso é atualizado para 'Rejeitado' nos dados mestres do caso. Tipo de evento inferred | |||
| Conta criada | Após a aprovação, esta atividade marca a criação técnica da conta do cliente no sistema bancário central ou no sistema de gerenciamento de usuários. Geralmente é um evento explícito registrado pelo ACTICO após o recebimento de uma confirmação de sucesso do sistema subsequente. | ||
| Por que isso importa Esta atividade confirma que o processo resultou em um desfecho comercial concreto. O tempo entre 'Solicitação aprovada' e 'Conta criada' pode revelar atrasos de integração ou ineficiências nas etapas finais de provisionamento. Onde obter Essas informações provavelmente estão nos logs de integração ou de interfaces do sistema no ACTICO, que registram o resultado das chamadas a sistemas externos para provisionamento de contas. Captura Evento registrado após o recebimento de uma resposta de API bem-sucedida do sistema central de contas. Tipo de evento explicit | |||
| Informações adicionais solicitadas | Representa um evento em que um revisor, geralmente da área de conformidade ou subscrição, precisa de mais informações ou documentos do cliente. Essa ação costuma ser registrada explicitamente, pois geralmente envolve o envio de uma notificação ao cliente e a pausa do caso. | ||
| Por que isso importa Esta atividade é uma das principais causas de retrabalho e aumento do tempo de ciclo. Acompanhar sua frequência e seu impacto é essencial para identificar pontos em que a coleta inicial de dados pode ser melhorada. Onde obter Provavelmente, este é um evento explícito registrado no histórico do caso ou no log de comunicações. Procure eventos como 'RFI enviado' (solicitação de informações) ou uma mudança de status específica, como 'Aguardando 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 indica que um agente terminou de revisar os documentos enviados pelo cliente. Normalmente, ela é inferida a partir de uma mudança de status do documento ou do caso como um todo, por exemplo, 'Documentos verificados' ou 'Revisão concluída'. | ||
| Por que isso importa Este é um marco importante para medir a eficiência do processo de tratamento de documentos. O tempo entre 'Documentos do cliente enviados' e esta atividade é um KPI crítico para identificar atrasos no processamento manual. Onde obter Inferida a partir dos logs de histórico de status do caso da solicitação ou de documentos individuais. Uma mudança no status de um documento de 'Aguardando revisão' para 'Aprovado' ou 'Revisado' indica esta atividade. Captura Inferida 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 da solicitação enviada, feita por uma regra automatizada ou por um agente, para verificar a completude e a elegibilidade básica. Essa atividade costuma ser inferida a partir de uma mudança de status da solicitação, por exemplo, de 'Enviada' para 'Em revisão'. | ||
| Por que isso importa Analisar o tempo necessário para concluir essa primeira revisão ajuda a identificar atrasos no processamento inicial. Também fornece insights sobre quantas solicitações passam por esse primeiro gate sem problemas. Onde obter Inferida a partir de tabelas de histórico de status ou logs de auditoria associados ao caso da solicitação do cliente. Compare o carimbo de data e hora em que o status muda de 'nova' ou 'enviada' para um status de 'revisão'. Captura Detectar a mudança de status de 'Enviada' para 'Em revisão' no log do 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 com base em fontes de dados externas ou internas. Geralmente é registrada como um evento explícito quando uma chamada de API é feita para um serviço de verificação de terceiros e uma resposta é recebida. | ||
| Por que isso importa Esta atividade é uma etapa crítica de conformidade. Analisar sua duração e seus resultados ajuda a identificar dependências de serviços externos e possíveis gargalos no processo de verificação. Onde obter Essas informações normalmente estão nos logs de integração ou em tabelas de eventos específicas que registram os resultados de verificações automatizadas e chamadas a serviços de terceiros vinculadas ao caso da solicitação. 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 momento em que verificações automatizadas ou manuais de antecedentes, como análises de AML ou do histórico de crédito, são iniciadas. Geralmente é registrada como um evento explícito quando o sistema aciona essas verificações, que podem envolver provedores de serviços externos. | ||
| Por que isso importa Iniciar verificações de antecedentes é um marco importante no processo de due diligence. Acompanhar essa etapa ajuda a entender as dependências e os prazos associados aos provedores de dados externos. Onde obter Procure registros nos logs do sistema ou em uma trilha de auditoria que indiquem o acionamento dos procedimentos de verificação de antecedentes. Eles costumam estar vinculados ao ID principal do caso da solicitação. 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: faça login na plataforma ACTICO, como o Visual Modeler ou um console de administração dedicado, usando credenciais com permissões suficientes para acessar e configurar exportações de dados.
- Localize o módulo de exportação: acesse a área de administração ou configuração do sistema. Encontre a seção responsável por trilhas de auditoria, registros ou exportações de dados. Ela pode estar identificada como “Audit Export” ou “Business Object Export”.
- Crie uma nova configuração de exportação: inicie o processo para criar uma nova definição de exportação. Informe um nome descritivo para a configuração, por exemplo, “KYC_Onboarding_ProcessMind_Export”.
- Defina a fonte de dados: especifique o principal Business Object a ser exportado, que é o
CustomerApplication. É fundamental aplicar um filtro de intervalo de datas para limitar o escopo da exportação, por exemplo, aos últimos 6 meses, garantindo tamanhos de arquivo e performance gerenciáveis. - Configure o arquivo de saída: defina o formato de saída como CSV. Informe o nome do arquivo, por exemplo,
kyc_event_log.csv, e confirme o delimitador, normalmente uma vírgula. Garanta que os campos de texto estejam devidamente entre aspas para lidar com caracteres especiais. - Mapeie o identificador do caso: designe o identificador exclusivo do Business Object
CustomerApplicationcomo o ID do caso para a análise de Process Mining. Isso vincula todos os eventos relacionados a um único caso de onboarding. - Defina os mapeamentos de atributos: para cada coluna obrigatória do Event Log, faça o mapeamento para o atributo correspondente no modelo de Business Object do ACTICO. Isso inclui ID do caso, nome da atividade, timestamps e outros atributos recomendados, como status ou nível de risco.
- Configure os mapeamentos de eventos: esta é a etapa mais importante. Crie uma regra ou um mapeamento específico para cada uma das 14 atividades de negócio. Use gatilhos do sistema, como a criação de um objeto para “Application Submitted”, mudanças de status para etapas do Workflow, como “Application Approved”, e padrões específicos de mensagens do Audit Log para eventos técnicos, como “Identity Verification Performed”.
- Salve e valide a configuração: depois de definir todos os mapeamentos, salve o arquivo de configuração. Use as ferramentas de validação disponíveis no ACTICO para verificar erros de sintaxe ou caminhos de atributos incorretos.
- Execute e monitore a exportação: execute o job de exportação. Monitore o progresso pelo agendador de jobs ou pela interface de monitoramento do sistema. Verifique os logs em busca de erros após a conclusão.
- Recupere e prepare o arquivo: baixe o arquivo CSV resultante do caminho de saída designado no servidor. Antes de fazer o upload para o ProcessMind, abra o arquivo para verificar sua estrutura e garantir que os formatos de timestamp e data estejam consistentes e sejam interpretados corretamente.
Configuração
- Nível do Audit Log: o nível de registro de auditoria em todo o sistema deve estar configurado com um nível detalhado, 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 da exportação: a fonte de dados principal deve ser configurada para usar o Business Object
CustomerApplication. Talvez seja necessário fazer join ou referenciar objetos relacionados, comoCustomerDocument, para capturar todos os eventos relevantes. - Filtro de intervalo de datas: sempre use um filtro de intervalo de datas para controlar o volume de dados extraído. Para a análise inicial, recomenda-se um período de 3 a 6 meses. Em produção, esse período pode ser ajustado conforme as necessidades do negócio e a performance 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 explícitas de log (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. Verifique se a configuração de delimitadores e aspas de texto está correta para evitar problemas de interpretação dos dados.
- Pré-requisitos: este método exige permissões administrativas na plataforma ACTICO. É essencial ter um conhecimento aprofundado do modelo de Business Object do KYC, incluindo todos os campos de status e nomes de atributos relevantes, para configurar tudo corretamente.
a Consulta de exemplo xml
<!-- 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> Pronto para começar?
Use este Template para preparar seus dados com eficiência e acelerar sua jornada rumo a um onboarding KYC de clientes otimizado no ACTICO.
Otimize o onboarding KYC de clientes: reduza o tempo para 24 horas agora
Elimine abandonos e falsos positivos para obter resultados de onboarding sem atritos.
Não é necessário cartão de crédito. Comece a otimizar hoje.