Conhecer o seu cliente de serviços financeiros

Verificar a identidade

O primeiro passo para conhecer o seu cliente é verificar identidades sintéticas ou contas para rastrear ou possível lavagem de dinheiro, financiamento do terrorismo e qualquer outra coisa que um mau ator possa tentar realizar. Depois de recolher informações pessoais identificáveis (PII) dos seus clientes e implementar um verificador de identidade sintético, pronto para uso ou personalizado, pode usar o software Splunk para fazer qualquer um dos seguintes:

• Utilize o Splunk platform para monitorizar erros, latência e outros problemas de resolução de problemas com o seu verificador de identidade sintético.
• Utilização Splunk Infrastructure Monitoring e Splunk Application Performance Monitoring para garantir que a infra-estrutura e as transacções para as contas sintéticas funcionem sem problemas.
• Se o verificador de identidade sintético passar por registos do servidor Web, independentemente do canal, utilize o Splunk platform para:
  • Monitorize os IPs dos clientes do requerente para ver se estão nas proximidades do seu endereço residencial (assumindo que não estão numa VPN estrangeira).
  • Verifique se o cliente ou outros membros da família tentaram abrir contas recentemente com o mesmo FSI.
  • Crie regras conforme necessário. Por exemplo, pode ajustar os limiares para ajudar a descobrir novas anomalias à medida que surgem novos indicadores de roubo de identidade e identidades sintéticas.

Realizar a devida diligência

A verificação de identidade vai além de apenas saber que o cliente é quem afirma ser. A due diligence envolve a verificação de antecedentes, que estabelece o valor da conta e o nível de risco do cliente. Por exemplo, alguém que possui uma grande empresa ou é um líder de governo eleito tem um nível de risco diferente do que uma conta de pequeno valor detida por um indivíduo que não está sob os olhos do público.

Os registos do fluxo de trabalho de diligência devida podem ser monitorizados pelo Splunk platform para análise e resolução de problemas. À medida que os dados são descobertos, provavelmente irá armazená-los numa base de dados local como um sistema de registo de informações do cliente. Pode expor esses dados ao Splunk platform via capacidades de pesquisa enriquecer a informação do cliente em investigações posteriores.

Monitorizar continuamente

Vistos pela primeira vez para uma atividade e detecção de valores atípicos são dois excelentes pontos de dados para monitorizar.

Visto pela primeira vez pode significar:

• a primeira vez que o utilizador tentou abrir uma conta
• a primeira vez que iniciaram sessão numa conta
• a primeira vez que realizaram uma transação contra a conta

Cada um destes são acontecimentos dignos de nota quando levados em contexto. Por exemplo, se um potencial cliente está a solicitar a criação de uma nova conta, vale a pena verificar se já se inscreveu antes e a data da primeira vez que se candidatou. Isso pode dar contexto, se forem rejeitados por razões de regulamentação KYC na primeira vez que se candidataram.

Outro exemplo é a primeira vez que um cliente realizou uma ação de levantamento contra a conta, onde a conta ficou inativa após a abertura e quase todo o dinheiro foi retirado ao fim de 18 meses. Assim, a primeira vez vista para uma transação é 18 meses após a abertura e parece que o cliente decidiu desembolsar a conta. Poderia isto ser um exemplo de aquisição de conta ou de uma posição de detenção para continuar a branquear dinheiro? Em ambos os casos, a primeira vez que se vê é uma parte importante do KYC.

Vamos entrar em como Search Processing Language (SPL) pode ser usado para implementar isso.

Aqui estão alguns SPL para ver um cliente pela primeira vez depois de ele abrir uma conta. Estamos a chamar Last Touched campo como a primeira vez que abriram uma conta e depois ver quais clientes demoraram pelo menos 6 meses para realizar qualquer ação no banco. Isso não é necessariamente mau comportamento, mas aumenta a pontuação de risco do cliente.

index=transacations sourcetype=account_opening
|eval prev_epoch=strptime(last_touched, "%m/%d/%Y %H:%M:%S")
|sort - last_touched
|join customer [ index=transactions sourcetype=banking]
|where epoch>relative_time(prev_epoch, "+6mon")
|fields - prev_epoch, balance
|rename accountID AS current_accountID action AS current_action account_type AS current_account_type 
|eval current_balance=tostring(round(current_balance, 2),"commas"), other_balance=tostring(round(other_balance, 2),"commas")
|convert timeformat="%m/%d/%Y %H:%M:%S" ctime(epoch) AS current_time
|fields - epoch

Isto pode parecer um pouco envolvido, por isso vamos decompado-lo.

• A primeira e a segunda linhas reúnem todas as transações para abertura de conta e convertemos o último campo tocado, que é um carimbo de data/hora legível por humanos, em tempo de época, que é o número de segundos desde 1 de janeiro de 1970. É mais fácil fazer matemática de timestamp com números inteiros do que com texto legível por humanos.
• Em seguida, juntamos esses dados às transações bancárias atuais dos clientes. O where a cláusula faz o trabalho para o nosso outlier, pois encontra todos os eventos que têm um tempo de época atual que é maior do que o tempo da época de abertura da conta. Se for superior a 6 meses, este cumpre os nossos critérios de “primeira vista” para um cliente que não tocou na sua conta depois de abrir há pelo menos 6 meses.
• O resto do SPL é apenas formatação para tornar a tabela de saída mais bonita para transformar o tempo de volta num timestamp legível por humanos e converter a quantidade envolvida num número inteiro simples.

Os valores atóxicos são a outra característica da monitorização contínua. O SPL tem um comando chamado eventstats que encontra estatísticas para todos os eventos na pesquisa como um todo, e não altera os resultados da pesquisa. Isto é útil para encontrar a média e o desvio padrão de todos os eventos num conjunto de dados filtrado. Vamos usar isto num exemplo.

index=payments
|stats avg(amount) AS avg_accountID BY accountID
|eventstats avg(avg_amountID) AS avg_amount stdev(avg_amountID) AS stdev_amount
|where avg_accountID>(3*stdev_amount + avg_amount)

Nesta pesquisa, calculamos primeiro o pagamento médio por ID da conta e depois calculamos o valor médio e o desvio padrão do valor do valor de todos os pagamentos num intervalo de tempo selecionado ou pesquisado pelo utilizador guardado, nenhum dos quais é mostrado aqui. O outlier é qualquer pagamento que seja superior ao valor médio mais três vezes o desvio padrão de todos os pagamentos no conjunto de dados. Esta é uma maneira bastante simples de encontrar valores discrepantes no comportamento do cliente, pois também pode usar uma média com multiplicador estático, médias móveis com desvio padrão e uma série de outras técnicas estatísticas . Para formas mais avançadas de detetar outliers, pode usar o serviço gratuito Kit de ferramentas de aprendizagem automática Splunk (MLTK) e utilizar métodos de aprendizagem automática para encontrar valores discrepantes, incluindo Função de Densidade, Fator Local Outlier e One Class SVM.

Tanto para a primeira vez como para a simples detecção de valores atípicos, codificar números e nomes de campo numa pesquisa que vai usar muitas vezes não faz sentido. É aí que Macros Splunk tornar-se útil. Existem macros vistas pela primeira vez e o exemplo de detecção de outlier no Splunkbase num pacote chamado TA For SplunkStart Basic Security Essentials que pode descarregar gratuitamente e extrair do macros.conf arquivo.

Criar linhas de base

Ao encontrar exceções, utilizando eventstats sobre uma população total não é uma boa ideia quando a população tem comportamentos diferentes devido à natureza intrínseca da forma como realiza transações rotineiras. Por exemplo, um cliente pode transferir rotineiramente 500 dólares por mês através de transferência bancária, enquanto outro pode transferir rotineiramente 50.000 dólares por mês. Nenhum destes comportamentos é fora do comum relativamente ao que fazem sozinhos, mas se agruparmos os dois clientes para encontrar um valor médio, é sem sentido e fortemente inclinado para a transferência maior.

Para contornar isso com a abordagem de outlier, pode ser uma boa ideia recolher regularmente dados transacionais por cliente numa base diária ou semanal para obter uma linha de base. Aqui está um exemplo do que pode obter usando o stats e collect comandos para recolher dados através de uma pesquisa agendada guardada para um valor médio transferido armazenado num índice de resumo.

Carimbo de data/hora	ID da conta	Montante
11/2/2022 5:06:30	123	50
11/2/2022 7:16:30	456	6345
11/7/2022 4:36:30	123	53
11/7/2022 1:16:30	456	4353
11/14/2022 9:46:30	123	51
11/14/2022 15:16:30	456	5345

Neste exemplo, agora pode usar stats para encontrar o valor médio transferido para qualquer ID de conta para obter uma linha de base das transações anteriores e compará-lo com o valor mais recente para ver se existe um outlier. Isto permite-lhe realizar uma monitorização contínua e comparar transações recentes com o comportamento esperado para o seu cliente. Sempre que o cliente realiza uma transação, uma pesquisa salva pode adicionar o novo valor ao índice de resumo e também comparar o valor atual com a média histórica para o cliente encontrar um outlier.

Aqui está um exemplo de pesquisa para esta situação que anexa a média e o desvio padrão do índice sumário para um ID de conta à transação corrente e compara o pagamento corrente (média dos pagamentos no intervalo de tempo atual) com as médias históricas mais um multiplicador do desvio padrão.

index=payments accountID=”456”
| append [ search index=payments_summary accountID=”456” earliest=-1Y
| stats avg(amount) AS avg_payment stdev(amount) AS stdev_payment]
|stats avg(amount) AS current_payment values(avg_payment) AS avg_payment values(stdev_payment) AS stdev_payment values(accountID) AS accountID
|where current_payment > avg_payment + (3*stdev_payment)

Para maior eficiência, se tiver milhões de contas, pode fazer mais sentido armazenar os dados resumidos das transações por dia ou por semana para cada ID de conta no armazenamento de valor de chave Splunk chamado KVStore . A KVStore é uma base de dados de uso geral que acompanha o Splunk platform para criar, modificar e eliminar capacidades utilizadas para enriquecer dados com outras pesquisas.

Calcule o risco

Os outliers nem sempre indicam um problema. Cada outlier deve ter uma pontuação de risco associada a ela que seja posteriormente avaliada em relação a todas as pontuações de risco para o cliente, como as desenvolvidas durante a due diligence. A acumulação de pontuações de risco por ID da conta impede falsos positivos e garante mais confiança em possíveis comportamentos nefastos. O software Splunk pode ajudá-lo a aplicar pontuações de risco às informações do cliente das seguintes maneiras:

• Use uma pesquisa para encontrar os dados de due diligence, que por sua vez são alimentados em outra pesquisa para encontrar um peso numérico para multiplicar a pontuação de risco inicial. À medida que a pesquisa é executada, salva toda a sua informação num índice de risco e pode iniciar alertas, se necessário.
• Automatize o conhecimento dos seus clientes, monitorizando continuamente o seu cliente quanto a anomalias e valores atópicos, adicionar pontuações de risco aos resultados.
• Se tem Splunk Enterprise Security , use o gratuito, suportado Aplicação Splunk para análise de fraude para descobrir a aquisição de contas e o abuso de conta, que são duas das características da monitorização e proteção dos seus clientes. A aplicação utiliza Splunk Enterprise Security 's Alerta Baseado em Risco (RBA) para pontuações de risco acumuladas.