Detecção de Intrusões Aplicação à detecção de fraude nos transportes … · transportes...
81
Detecção de Intrusões – Aplicação à detecção de fraude nos transportes públicos Gonçalo Manuel Mendes Duarte Gomes Ivo Dissertação para obtenção do Grau de Mestre em: Engenharia de Redes de Comunicações Júri Presidente: Professor Doutor Rui Jorge Morais Tomaz Valadas Orientador: Professor Doutor Alberto Manuel Ramos da Cunha Co-Orientador: Professor Doutor Carlos Nuno da Cruz Ribeiro Vogal: Professor Doutor Pável Pereira Calado Outubro 2009
Transcript of Detecção de Intrusões Aplicação à detecção de fraude nos transportes … · transportes...
Detecção de Intrusões – Aplicação à detecção de
fraude nos transportes públicos
Gonçalo Manuel Mendes Duarte Gomes Ivo
Dissertação para obtenção do Grau de Mestre em:
Engenharia de Redes de Comunicações
Júri
Presidente: Professor Doutor Rui Jorge Morais Tomaz Valadas
Orientador: Professor Doutor Alberto Manuel Ramos da Cunha
Co-Orientador: Professor Doutor Carlos Nuno da Cruz Ribeiro
Vogal: Professor Doutor Pável Pereira Calado
Outubro 2009
i
Agradecimentos A realização de um trabalho implica a entrega de quem o desenvolve, mas também a
ajuda de todos os que de uma forma mais ou menos (in)directa nele colaboram.
Ao longo desta jornada, muitos foram os que a tornaram possível.
Assim, começo por agradecer ao meu orientador Professor Doutor Alberto Cunha, por me
ter acompanhado ao longo da realização desta tese.
À Engenheira Ana Caçador que, devido à sua disponibilidade, experiência, vontade de
ajudar e sugestões, sempre pertinentes, foi mais que uma orientadora, a sua preciosa ajuda e
incentivo foram fundamentais na realização deste trabalho.
A todos os meus colegas na Link Consulting que, de uma maneira ou de outra me
apoiaram, em especial ao Engenheiro Tony Fiuza.
A todos os colegas que foram meus companheiros nesta jornada, pelo apoio, o querer, o
acreditar … pelas gargalhadas que amenizaram as longas horas de realização deste trabalho.
Por último, à minha família, sem a qual nunca poderia ter chegado até aqui,
nomeadamente aos meus pais, por todo o seu apoio e motivação.
Obrigado
Lisboa, Outubro 2009
Gonçalo Ivo
iii
Aos meus pais
“A nossa vida é desperdiçada pelo pormenor... Simplifica, simplifica.”
Thoreau
v
Resumo
Actualmente, o conceito de “fraude” tornou-se tão vulgar que ao seu grave significado
não é dada a devida consideração. Os transportes públicos não são excepção e nos locais
onde a sua utilização, e quiçá dependência, é mais elevada a fraude tende a aumentar. Assim
sendo, as operadoras de transportes públicos não podem ser permissivas para com estes
actos fraudulentos, encetando um combate feroz à fraude.
Este trabalho tem como focos principais a análise e compreensão da fraude a nível dos
transportes públicos de forma a possibilitar uma correcta prevenção e detecção da mesma.
Para tal, realizou-se um estudo sobre tipos de fraude, relevantes para esta área, e métodos já
utilizados para contrariar actos fraudulentos. Como resultado deste estudo foi proposta uma
solução adaptativa para detecção e prevenção de fraude que combina alguns dos métodos
estudados, de forma a tirar vantagens de cada um deles na resolução deste problema.
Da solução proposta foi concebido um protótipo com o intuito de conseguir realizar
análises de fraude. Esse protótipo foi validado, tendo-se conseguido obter quantificações
objectivas de fraude e definir metodologias para efectuar análises de fraude.
Palavras-chave: Fraude, Prevenção, Detecção, Transacção, Redes Neuronais, Redes Bayseanas, Regra, Bilhética Electrónica
vii
Abstract
Currently, the concept of "fraud" has become so common that its serious meaning is
repeatedly overlooked. Public transports are no exception and in places where its use, and
perhaps dependence, is higher the numbers of fraud tend to increase. Therefore, operators of
public transports can no longer be permissive to these fraudulent acts and are starting to
engage in fierce fraud combat.
This work main focuses is the analysis and understanding of fraud at the level of public
transports in order to enable its proper prevention and detection. To this end, we carried out a
study on types of fraud relevant to this area, and methods used to counter fraudulent. As a
result of this study was proposed an adaptive solution to detecting and preventing fraud that
combines some of the methods studied in order to take advantage of each one with this
problem.
Following the proposed solution was designed a prototype in order to be able to perform
fraud analysis. This prototype has been validated and is able to obtain objective measurements
of fraud and define methodologies for analysis of fraud.
Keywords: Fraud, Prevention, Detection, Transaction, Neural Networks, Bayesian Networks, Rule, Electronic Ticketing
ix
Índice
Índice .................................................................................................................................................... ix
Índice de Figuras ................................................................................................................................... xi
Índice de Tabelas ................................................................................................................................. xii
Lista de Acrónimos .............................................................................................................................. xiii
1 Introdução ..................................................................................................................................... 1
1.1 Motivação e Enquadramento ....................................................................................................... 1
1.2 Contribuições da Dissertação ....................................................................................................... 1
1.3 Organização da Dissertação ......................................................................................................... 1
2 Fraude nos Transportes Públicos .................................................................................................... 3
2.1 Funcionamento dos Transportes Públicos .................................................................................... 3
2.2 Fraude nos Transportes Públicos .................................................................................................. 4
2.3 Impacto da Fraude nos Transportes Públicos ............................................................................... 5
2.4 Metodologia e Soluções ................................................................................................................ 6
2.5 Classificação dos Tipos de Fraude ................................................................................................. 6
3 Controlo de Fraude: Passado e Presente ........................................................................................ 9
3.1 Soluções Existentes: Transportes Públicos .................................................................................... 9
3.2 Soluções Existentes: Áreas Similares .......................................................................................... 10 3.2.1 Características da solução MNT .......................................................................................... 12 3.2.2 Características da solução FCT ............................................................................................ 12
3.3 Trabalhos Relevantes .................................................................................................................. 14
4 Controlo de Fraude: Solução Proposta ......................................................................................... 17
4.1 Motor de Regras ......................................................................................................................... 17
4.2 Modelo de Análise ...................................................................................................................... 19 4.2.1 Fases do Modelo de Análise ............................................................................................... 20
4.3 Configuração & Apresentação .................................................................................................... 21 4.3.1 Apresentação de Resultados .............................................................................................. 21 4.3.2 Configuração ....................................................................................................................... 22
5 Controlo de Fraude: Solução Desenvolvida .................................................................................. 25
5.1 Arquitectura dos Dados .............................................................................................................. 25
5.2 Componentes: Motor de Regras ................................................................................................. 27 5.2.1 Motor de Regras: Implementação das Regras .................................................................... 27
5.2.1.1 Implementação das Regras: Linguagem Motor de Regras ............................................. 29 5.2.1.2 Implementação das Regras: Mapeamento entre Tipos de Fraude e Regras .................. 31
5.2.2 Motor de Regras: Interpretação das Regras ....................................................................... 32 5.2.2.1 Interpretação das Regras: Fluxo de Processamento ...................................................... 32
x
5.2.2.1.1 Interpretação das Regras: Tradução de LMR ........................................................... 33
5.3 Componentes: Configuração & Apresentação ............................................................................ 34 5.3.1 Configuração & Apresentação: Configuração ..................................................................... 34 5.3.2 Configuração & Apresentação: Apresentação .................................................................... 39
5.3.2.1 Apresentação: Consulta Global de Resultados ............................................................... 39 5.3.2.2 Apresentação: Consulta Detalhada de Resultados ......................................................... 40
5.3.2.2.1 Apresentação: Consulta dos Dados da Transacção .................................................. 42 5.3.2.2.2 Apresentação: Consulta dos Dados da Regra........................................................... 44 5.3.2.2.3 Apresentação: Consulta dos Dados do Bloco de Processamento ............................ 45
5.4 Validação da Solução .................................................................................................................. 47 5.4.1 Teste 1 – Cálculo do Tempo de Processamento Individual de cada Elemento .................. 48 5.4.2 Teste 2 – Cálculo do Tempo de Processamento Individual de cada Regra ......................... 50 5.4.3 Teste 3 – Análise de Fraude somente para Carregamentos ............................................... 50 5.4.4 Teste 4 – Análise de Fraude somente para Validações ...................................................... 54
6 Conclusões e Trabalho Futuro ...................................................................................................... 59
6.1 Conclusões .................................................................................................................................. 60
6.2 Trabalho Futuro .......................................................................................................................... 61
7 Referências .................................................................................................................................. 62
Anexos ................................................................................................................................................. 63
xi
Índice de Figuras
Ilustração 1 - Exemplo de Rede Neuronal .................................................................................................. 11
Ilustração 2- Diagrama de Blocos de “Supervised Learning” [14] ...................................................... 15
Ilustração 3 - Fluxo base de operação da solução. ..................................................................................... 17
Ilustração 4 - Estrutura típica de uma Regra de Decisão ............................................................................ 19
Ilustração 5 - Exemplificação do MA .......................................................................................................... 20
Ilustração 6 - Alguns Fluxos de utilização do componente C&A ........................................................ 22
Ilustração 7 - Overview da Solução ............................................................................................................. 23
Ilustração 8 - Tabelas directamente relacionadas com o MR..................................................................... 25
Ilustração 9 - Tabelas utilizadas para guardar os resultados das análises e as configurações do sistema . 26
Ilustração 10 - Vista utilizada para apresentar os resultados globais das análises .................................... 26
Ilustração 11 - Fluxo do MR ........................................................................................................................ 32
Ilustração 12 - Funcionalidade “Gerir Constantes” .................................................................................... 34
Ilustração 14 - Funcionalidade “Seleccionar Regras” ................................................................................. 38
Ilustração 16 - Funcionalidade “Consulta Detalhada de Resultados” ........................................................ 41
Ilustração 19 – Funcionalidade “Consulta dos Dados da Regra” ................................................................ 45
Ilustração 20 – Funcionalidade “Consulta dos Dados do Bloco de Processamento” ................................. 46
Ilustração 21 – Carregamentos: Tempo de Processamento vs Dimensão da Amostra .............................. 51
Ilustração 22 – Carregamentos: Tempo de Registo vs Dimensão da Amostra .......................................... 52
Ilustração 23 – Carregamentos: Tempo de Processamento, de Registo e de Análise vs Dimensão da
Amostra ...................................................................................................................................................... 52
Ilustração 24 – Validações: Tempo de Processamento vs Dimensão da Amostra ..................................... 54
xii
Ilustração 25 – Validações: Tempo de Registo vs Dimensão da Amostra .................................................. 55
Índice de Tabelas
Tabela 1 – Listagem de Fraudes conhecidas. ............................................................................................... 7
Tabela 2 - Redes Neuronais vs Redes Bayseanas ....................................................................................... 13
Tabela 3 - Constantes de Fraude ................................................................................................................ 37
Tabela 4 – Tempos de Processamento por Elemento ................................................................................ 49
Tabela 5 – Tempos de Processamento Calculados para cada Regra .......................................................... 49
Tabela 6 – Tempos de Processamento por Regra ...................................................................................... 50
Tabela 7 – Carregamentos: Tempos de Processamento, de Registo e de Análise ..................................... 51
Tabela 8 – Resultados de Fraude para Carregamentos .............................................................................. 53
Tabela 9 – Validações: Tempos de Processamento, de Registo e de Análise ............................................. 54
Tabela 10 – Resultados de Fraude para Validações ................................................................................... 56
Tabela 11 – Resultados de Fraude para Regras de Viagem I ...................................................................... 57
Tabela 12 – Resultados de Fraude para Regras de Viagem II ..................................................................... 58
xiii
Lista de Acrónimos C&A Configuração & Apresentação FCT Fractals LMR Linguagem do Motor de Regras MNT Minotaur MR Motor de Regras RBs Redes Bayseanas RL Reinforcement learning RNs Redes Neuronais SL Supervised learning UL Unsupervised learning
1
1 Introdução
1.1 Motivação e Enquadramento
“Acto de má-fé praticado com o objectivo de enganar ou prejudicar” [1] Esta é a definição
de fraude, conceito que se encontra de tal modo inserido na vida das pessoas que, por vezes,
passa totalmente despercebido. Fraude está sub-repticiamente presente em inúmeras
situações do nosso quotidiano, do simples acto de passar um cheque a operações bancárias
mais complexas ou mesmo na gestão de empresas. Não é, então, de estranhar que estes
actos fraudulentos afectem os transportes públicos, em especial nas grandes cidades, onde se
apresentem como um dos meios de transportes mais utilizados. Assim sendo, as operadoras
de transportes públicos tendem a implementar medidas de combate à fraude que vão deste
updates tecnológicos à criação/utilização de equipas e meios especializados para controlo de
fraude.
1.2 Contribuições da Dissertação
Nesta dissertação é feito um enquadramento detalhado da problemática da Fraude nos
Transportes Públicos, foram estudadas as soluções mais usadas para minimizar o impacto
deste fenómeno, quer nesta área quer em áreas semelhantes. Finda esta análise, a solução
proposta para um sistema de controlo de fraude levou ao desenvolvimento de um protótipo que
permite fazer uma abordagem à problemática da fraude nos transportes públicos. Através de
resultados obtidos na validação do protótipo foi possível efectuar quantificações objectivas de
fraude e definir metodologias para realizar análises de fraude.
1.3 Organização da Dissertação
Esta dissertação divide-se em 7 capítulos. Neste primeiro capítulo, “Introdução”,
apresenta-se a motivação e enquadramento deste trabalho, bem como a forma como se
encontra organizado. No capítulo segundo, “Fraude nos Transportes Públicos”, são
apresentados, de forma genérica, os processos de acesso e utilização dos transportes públicos
e a fraude a eles associada. No capítulo terceiro, “Controlo de Fraude: Passado e Presente”, é
apresentado o estudo realizado em relação às principais formas e soluções existentes para
realizar um controlo de fraude. O capítulo quarto, “Controlo de Fraude: Solução Proposta”,
descreve a solução proposta para um sistema de controlo de fraude aplicado aos transportes
públicos. No capítulo seguinte, “Controlo de Fraude: Solução Desenvolvida”, é apresentada a
solução desenvolvida, com base na solução proposta, e os testes de validação dessa solução.
Por fim, são apresentadas as conclusões deste trabalho e os temas para evolução do mesmo.
3
2 Fraude nos Transportes Públicos
2.1 Funcionamento dos Transportes Públicos
Para conseguir perceber a problemática da fraude associada aos transportes públicos é
necessário, em primeiro lugar, entender o funcionamento dos transportes públicos nos dias de
hoje.
Nos transportes públicos verifica-se presentemente a tendência para a utilização de
bilhetes electrónicos. Essa tendência resulta no desaparecimento dos bilhetes em papel (títulos
de transporte) por substituição de novos títulos de transporte que sejam o mais prático possível
(bilhetes electrónicos). Se tomarmos por exemplo a cidade de Lisboa, a maioria da rede de
transportes é acedida através do cartão LisboaViva1. Este cartão é um suporte sem contacto
que permite o carregamento de títulos próprios de cada operador, multimodais e combinados
(estes envolvendo vários operadores). Assim, cada utilizador da rede de transportes pode
carregar uma determinada quantidade de contratos (correspondente a títulos de transportes)
cuja validade pode variar consoante o tipo de contrato. A título de exemplo, com este tipo de
soluções é possível um utilizador possuir um contrato com uma validade mensal para um
determinado troço de um operador e, caso deseje, ou seja necessário pode ter na sua posse
outro contrato, distinto, com outro operador, sendo que ambos os contratos residem no
suporte, o cartão comum (LisboaViva por exemplo).
Para que um cidadão possa utilizar um sistema de bilhética como o mencionado no
exemplo anterior as noções principais a reter são as seguintes:
Carregamentos – Corresponde ao acto de adquirir (pela primeira vez ou renovação) um
título de transporte que fica disponível no suporte estipulado (LisboaViva por exemplo).
Pode ser efectuado em vários locais, desde máquinas de venda automáticas, pontos
de vendas dos operadores, quiosques e até via ATM.
Entradas/Saídas – Corresponde ao acto de aceder (ou terminar o acesso) à rede do
operador de transportes. Por norma, o título de transporte é validado à entrada e/ou á
saída da rede.
O sistema aparenta ser deveras simples e cómodo, mas é necessário ter em atenção
que para que esta facilidade seja possível é necessária a existência de um sistema central que,
por norma, implementa sistemas de bilhética electrónica que incluem a gestão de clientes,
emissão e gestão de cartões, gestão de contratos, vendas/carregamentos e carregamentos
embarcados ou remotos, gestão e controlo de vendas e validação, gestão de segurança e
compensação de receitas, para operadores de transportes públicos de passageiros.2
Outra particularidade associada à bilhética electrónica é as inúmeras possibilidades de
utilização em áreas geograficamente dispersas, sem ligação ao servidor central do operador.
1 Mais informações em www.lisboaviva.pt ou www.otlis.com.pt 2 Características tipo de um sistema central, baseadas numa solução da Link Consulting SA – www.link.pt
4
Continuando com o exemplo mencionado anteriormente, se por exemplo for realizada a
compra de um título de transporte via ATM (sem haver necessidade geográfica de ser realizada
em Lisboa) esse título fica imediatamente disponível, através do suporte (LisboaViva por
exemplo). Contudo, as transacções de carregamento associadas a esta aquisição não são
transmitidas de imediato para o sistema central, isto é, as transacções são efectuadas off-line e
são registadas no sistema central posteriormente (este registo não têm restrições temporais,
podendo portanto ser efectuado um dias ou uma semana após a realização da transacção). As
consequências negativas deste facto, as tecnologias que permitem a existência deste tipo de
sistemas nos transportes públicos e quais as suas vulnerabilidades que, por vezes, são
exploradas pelos utilizadores para cometer actos fraudulentos, são aprofundadas na secção
seguinte.
2.2 Fraude nos Transportes Públicos Com o elevado desenvolvimento dos transportes públicos crescem em simultâneo as
perdas provenientes da exploração das vulnerabilidades que as novas tecnologias introduzem
nos sistemas, assim como as já existentes, mas não colmatadas por estas tecnologias.
Destas novas tecnologias, existe uma que se pode considerar como a que acarretou
maior número de benefícios para os operadores de transportes, nomeadamente a redução da
fraude, quer por parte de passageiros quer de empregados funcionários, a redução dos atrasos
nas entradas para os transportes, a melhoria dos procedimentos monetários (por exemplo,
passou a existir uma maior facilidade de pagamento), a redução dos custos laborais e melhor
aproveitamento de recursos (por exemplo, menos empregados necessários menor número de
funcionários para realizar controlo de acessos que podem ver as suas funções reajustadas a
outras necessidades do operador) e uma maior flexibilidade na divisão de receitas. Essa
tecnologia é o SmartCard [2][3]. Dos benefícios mencionados, pretende-se destacar a redução
dos níveis de fraude, cujos números ainda continuam altos embora possam ser reduzidos. O
uso desta tecnologia não é 100% segura: os algoritmos criptográficos utilizados são facilmente
ultrapassados; se não forem tidos em consideração determinados padrões de uso dos cartões
utilizações atípicas podem passar despercebidas. Assim sendo podemos, desde já, diferenciar
dois problemas distintos: Falta de segurança no processamento3 de dados e Inexistência de
uma análise rigorosa e continuada dos mesmos. O primeiro problema está mais relacionado
com a tecnologia inerente aos SmartCards, com especial ênfase nos algoritmos criptográficos
utilizados pelos mesmos, e na troca segura de dados que circulam entre os diversos sistemas
da rede de transportes (por exemplo: garantir integridade e segurança das/nas transacções
que são enviadas para um sistema central), sendo que este trabalho não se debruça sobre
este problema.
O problema concreto abordado neste trabalho é a falta de análise rigorosa e
continuada dos dados provenientes dos sistemas presentes numa rede de transportes (mais
3 Processamento serve para referenciar todos os passos desde que os dados são gerados até ao momento em que são
armazenados no sistema central.
5
concretamente das transacções) para que os resultados dessa análise possam ser utilizados
no combate à fraude existente neste meio. O facto de estas análises serem efectuadas sobre
dados armazenados no sistema central de um operador de transportes, mais concretamente as
transacções que são efectuadas off-line e posteriormente transmitidas para esse sistema,
indica que a fraude não pode ser combatida em tempo real, pois pode ainda não existir no
sistema central informação relevante para as análises a efectuar. Assim sendo, essa análise
não é nem em tempo real (Online), nem em tempo perto do real (Near-Online) mas sim
realizada sem qualquer conexão temporal à origem dos dados (Offline). Esta desconexão
temporal pode não possibilitar resposta em tempo útil a situações pontuais de fraude, mas
permite analisar situações frequentes e sempre que desejado.
2.3 Impacto da Fraude nos Transportes Públicos
Nos dias de hoje, na maioria dos sistemas centrais dos operadores de transportes,
onde são armazenadas todas, ou grande parte, das transacções realizadas na sua rede, não é
efectuado qualquer tipo de análise rigorosa e continuada das mesmas. Como tal, está a ser
desperdiçada informação preciosa que poderia e/ou deveria estar a ser utilizada para conseguir
combater as usurpações que existem actualmente, nomeadamente, ao nível das entradas e
saídas de sistemas quer fechados (p.ex.: o metropolitano onde temos acesso controlado à
entrada e à saída por meio de postos de validação4) quer abertos (p.ex.: nos autocarros onde
não exista obrigatoriedade de realizar validações 62[4].
A falta de análise, anteriormente identificada como o problema a resolver, faz com que
não sejam determinados padrões entre as acções fraudulentas de determinados indivíduos e
as características de utilização desses mesmos indivíduos, ou mesmo entre acções
fraudulentas similares.
Por exemplo, se certas transacções com um elevado valor associado, que se desvia
dos padrões de comportamento normais, ocorrem sempre no mesmo dia, à mesma hora e com
origem no mesmo local, estes indicadores comuns deveriam ser tidos em consideração para
prevenir e idealmente impedir que acções semelhantes ocorram. Uma situação real que pode
ser aplicada ao exemplo anterior poderá ser o facto de um empregado passar a carregar
propositadamente mais viagens a um conhecido, sempre no mesmo dia do mês.
Conclui-se portanto que os operadores têm possibilidade de diminuir as perdas
financeiras derivadas de actos fraudulentos bastando para isso adoptar uma postura mais pro-
activa na análise de informação que já está na sua posse.
4 Postos de validação são os dispositivos colocados à entrada e/ou saída de um sistema de transportes (p.ex.:
metropolitano, autocarros, comboios) para registar as viagens dos passageiros.
6
2.4 Metodologia e Soluções
Sempre existiram, e irão existir, formas de combater este mal da sociedade, podendo
as mesmas ser categorizadas como de prevenção ou de detecção de fraude.
Na prevenção de fraude enquadram-se as medidas que são efectuadas para impedir
alguém de a cometer. Por norma esta prevenção é feita através da obrigatoriedade do
cumprimento de determinadas regras que definem o uso correcto de um dado sistema. No que
respeita à detecção de fraude, esta só tem lugar após a sua ocorrência. É através da busca de
comportamentos anormais, disruptivos ou não autorizados em/de determinados sistemas que
se tenta isolar casos possivelmente fraudulentos. Embora estas noções representem modos
distintos de “atacar” a fraude, usualmente, aparecem em conjunto no combate à mesma, de
forma a obter os melhores resultados possíveis. Como primeira etapa é comum que sejam
estipuladas (tomadas em consideração) medidas específicas para prevenir a ocorrência de
fraude, e somente quando existem casos que estas medidas não conseguem combater
correctamente, entra em acção a fase de detecção, que deverá isolar estes acontecimentos
díspares dos padrões normais de funcionamento dos sistemas. Num sistema ideal pode ainda
existir uma terceira fase onde, após análise rigorosa da informação proveniente da segunda
fase, isto é, aquando da percepção de determinados padrões de fraude, se devem retirar inputs
a ser usados na fase inicial (prevenção). É ainda importante referir que tanto a prevenção como
a detecção de fraude costumam ser feitas quer por equipas especializadas, que tendem a ser
demasiado dispendiosas e quiçá insuficientes para a processar e analisar a elevada
quantidade de dados existentes numa operadora de transportes, quer por sistemas
automatizados (maioritariamente programas de computadores concebidos especificamente
para efeitos de prevenção e detecção de fraude). Não é de estranhar que, nos dias de hoje e
no futuro, as equipas de prevenção e detecção de fraude, pelo menos nesta área de aplicação,
tendam a ser substituídas pelas máquinas. Porém, essa substituição não deverá ocorrer na
totalidade visto existirem situações que somente pessoas qualificadas conseguem detectar.
2.5 Classificação dos Tipos de Fraude
Os principais tipos de fraude, nos transportes públicos, encontram-se descritos na tabela
seguinte, Tabela 1. Estes são os tipos de fraude que a solução proposta visa combater.
Contudo, a complexidade de alguns desses tipos pode dificultar bastante essa tarefa, sendo
por isso plausível que somente alguns destes tipos sejam realmente abordados.
Tipos de Fraude Características
Skimming "Viagens" simultâneas
"Viagens" seguidas com tempos inexequíveis
Tempo de "Viagem" inexequível
7
Validação e carregamento de um cartão desconhecido
Cartão não registado no sistema é utilizado nas máquinas de carregamento
Cartão não registado no sistema é utilizado nos postos de validação
Validação e carregamento de um cartão inválido
Carregamento de Cartão que apresenta dados diferentes dos registados na BD central
Carregamento Cartão presente em Lista Negra5
Validação de Cartão que apresenta dados diferentes dos registados na BD central
Validação Cartão presente em Lista Negra
Validação de um contrato6 ou perfil desconhecido
Cartão carregado com contrato desconhecido
Cartão com perfil desconhecido
Validação de Cartão com contrato desconhecido
Certificados7 errados Certificados presentes no cartão e nas transacções a ele associadas são desconhecidos
Carregamentos e Validações com equipamentos desconhecidos
Contratos não foram carregados no cartão por um equipamento de um operador conhecido
Cartões não foram validados por um equipamento de um operador conhecido
Sequência de uso de um cartão de forma pouco comum
Entradas consecutivas
Saídas consecutivas
Pares entrada saída consecutivos
Evolução não usual dos contadores Valores dos contadores decrescem
Valores dos contadores crescem demasiado para a sua evolução habitual
Utilização diária não usual de um cartão
Mudança abrupta nos padrões diários de utilização do cartão
Utilização não usual de um cartão num determinado período ou região
Mudança abrupta nos padrões de utilização do cartão em determinados períodos ou regiões
Roubo Mudanças repentinas de hábitos de utilização (carregamentos, zonas de carregamentos, zonas de
utilização)
Utilização de cartão identificado como roubado
Empregados Irregularidades no funcionamento dos postos de validação
Irregularidades na contabilidade
Tabela 1 – Listagem de Fraudes conhecidas.
5 Representa grupos de cartões que deixaram de ser válidos no sistema (p.ex. foram reportados como roubados). 6 São os indicadores do número de contratos “vendidos” pelo SAM (Security Access Module) presente numa
máquina de vendas e/ou os indicadores do nº de validações efectuadas pelo SAM presente uma máquina de
validação 7 Meios e/ou formas de comprovar a autenticidade. (p.ex. Veririfcar se a máquina responsável pela venda de um certo
contrato é fidedigna).
9
3 Controlo de Fraude: Passado e Presente
Nesta secção vão ser apresentados algumas das soluções e trabalhos mais relevantes
para a resolução do problema identificado anteriormente. Estas soluções e trabalhos vão ser
apresentados nas subsecções 3.1 e 3.2, respectivamente.
3.1 Soluções Existentes: Transportes Públicos
Nos dias de hoje o problema de fraude, como foi anteriormente referido, não é algo
novo e a cada vez maior consciencialização deste facto por parte das entidades afectadas,
neste caso os operadores de transportes, leva a uma aposta por parte das mesmas em
sistemas denominados anti-fraude.
Destes sistemas anti-fraude aquele que mais se destaca, no ramo dos transportes
públicos, é o “Fraud Detector” da Spirtech [5], que tem como principais características:
- Gestão de uma base de dados central com todos os cartões, bilhetes e últimas
transacções;
- Análise automática de transacções;
- Verificação de assinaturas criptográficas;
- Geração de alertas aquando da suspeita de fraude (e-mail, RSS);
- Análise interactiva com os dados, no caso de existir suspeita de fraude;
- Envio de resultados e/ou relatórios para sistemas de detecção de fraude de outros
operadores, caso existam;
- Arquivo de registos (logs) de todas as operações realizadas;
- Garantia de uma administração remota e segura através de browser web;
Esta solução tem como pontos fortes o facto de conseguir ultrapassar os dois principais
problemas de fraude nos transportes públicos, descritos na secção anterior deste documento,
conseguindo realizar uma verificação criptográfica em simultâneo com uma boa análise de
dados (Consegue combater a totalidade dos tipos de fraude presentes na Tabela 1). Uma
lacuna nesta análise é a não percepção de como é feita efectivamente a detecção da fraude,
isto é, quais os métodos utilizados ou em que métodos esta solução se baseia, contudo é
aceitável que tal não seja revelado visto que esse pode ser o factor diferenciador em relação a
outras possíveis soluções. Para colmatar essa lacuna e visto não terem sido encontradas
outras soluções de relevo na área da detecção de fraude nos transportes públicos, efectuou-se
uma pesquisa de soluções numa área com funcionamento semelhante, os cartões de crédito.
10
3.2 Soluções Existentes: Áreas Similares
A decisão de estudar soluções de detecção de fraude em áreas similares à dos
transportes públicos, mais concretamente relacionadas com cartões de crédito, deve-se
principalmente ao modo similar de funcionamento entre os cartões de crédito e a tecnologia
mais predominante nos transportes, os SmartCards. Se tivermos ainda em consideração que a
detecção de fraude nesta área se encontra mais desenvolvida (o número de soluções
existentes é de tal maneira elevado e diferenciado que qualificá-las de forma objectiva para
uma comparação conjunta se torna extremamente complexo) e que a associação entre os
cartões de crédito e os operadores de transportes é cada vez mais uma realidade (por
exemplo, cartões bancários com zonas / áreas para utilização em transportes públicos, compra
de títulos de transportes através de Multibanco, utilização de cartões bancários para
pagamento de viagens ocasionais, etc.) esta análise começa a fazer cada vez mais sentido.
Dos sistemas analisados os mais relevantes foram:
- “Minotaur” da empresa Neural Technologies(MNT) [6][7];
- “Fractals” da empresa Alaric (FCT) [8][9];
A razão pela qual estas duas soluções foram as escolhidas prende-se com o facto de
apresentarem abordagens distintas, que se encontram comprovadas, para o mesmo problema.
Embora ambas as soluções tenham em comum a utilização de um motor de regras como
primeira fase de prevenção de fraude, a forma como a detecção vai ser feita é o factor
distintivo. A solução MNT realiza detecção de fraude através de Redes Neuronais (RNs) e
enquanto que a solução FCT utiliza Redes Bayseanas (RBs). As principais características
destas soluções vão ser apresentadas nas subsecções 3.2.1 e 3.2.2, respectivamente.
Antes de se apresentarem as principais características destas soluções há
necessidade de se fazer uma contextualização em relação às RNs e às RBs de forma a poder-
se compreender na totalidade o seu funcionamento. Mais tarde, na subsecção seguinte, alguns
dos trabalhos apresentados vão explorar mais aprofundadamente estas definições.
Tendo como base o funcionamento das redes neuronais biológicas, grupos de
neurónios interligados, foram criados modelos matemáticos ou computacionais que são
denominados de redes neuronais (RNs) artificiais [10][10]. Uma das principais características
das RNs é o reconhecimento de padrões proporcionado pela troca de informação realizada
pelos vários membros da rede (neurónios). Através de um processamento estatístico as RNs
conseguem inferir sobre a probabilidade de determinadas suposições, em relação aos dados
analisados. Assim, podemos ver as RNs como um modelo probabilístico que associa
probabilidades a padrões. O modo habitual de funcionamento das RNs consiste na geração de
outputs através do processamento de inputs, ou seja, existem dois extremos da rede, entrada e
saída, e pele meio existe uma rede complexa de “neurónios escondidos” que vão marcando os
11
inputs à medida que os processam, no final os outputs são gerados de acordo com as
marcações que os inputs sofreram. A Ilustração 1 é um exemplo simples de RNs.
Ilustração 1 - Exemplo de Rede Neuronal8
Um dos factores de maior interesse neste método é o facto de os “neurónios
escondidos” de marcação serem dotados de aprendizagem, isto é, alteram a sua forma de
marcar inputs consoante as suas acções passadas ou conhecimento adquirido dos seus
vizinhos. Os possíveis meios de aprendizagem por parte dos RNs vão ser apresentados com
mais pormenor na subsecção seguinte.
Em relação às RBs estas funcionam de forma semelhante às RNs só que os nós
equivalentes aos “neurónios escondidos” têm uma probabilidade associada, logo é mais fácil
saber a razão pela qual um determinado input originou um determinado output [11][12].Quando
aplicamos RBs na resolução do problema da fraude nos transportes públicos, pretendemos
descobrir a probabilidade de fraude dadas determinadas provas. Todavia, através de uma
análise histórica dos dados vai-se apenas conseguir determinar a probabilidade de uma dada
prova dado o facto que esta representa fraude. De acordo com Bayes, devem usar-se
probabilidades a priori para calcular a probabilidade posterior desejada (Este processo chama-
se inferência probabilística). Na fórmula 1 está representada esta forma de abordar o problema,
segundo Bayes, através de uma expressão de probabilidade condicional.
Fórm.1. Teorema de Bayes (contexto de fraude e provas)
À semelhança das RNs, as RBs são dotadas de aprendizagem, que consiste numa
actualização das probabilidades associadas a cada nó, mas, tal como dito anteriormente, este
tema será abordado com maior detalhe na subsecção seguinte, onde também vão ser
apresentados exemplos práticos de RBs.
De seguida, são enumeradas as principais características das soluções MNT e FCT e
vai ser realizada uma abordagem crítica das mesmas. Por fim, nesta subsecção é apresentado
um estudo comparativo de RNs e RBs.
8 Ilustração retirada de http://en.wikipedia.org/wiki/Artificial_neural_network em 03-01-2009
12
3.2.1 Características da solução MNT
As principais características da solução MNT são as seguintes:
- O uso de três técnicas distintas de detecção de fraude que podem ser aplicadas a
qualquer tipo de eventos ou dados do cliente; A maioria dos sistemas usa apenas
motores de regras e controlos de threshold de fraude, mas esta solução utiliza mais
duas técnicas (que podem ser vistas como um todo), para melhorar assim taxas de
sucesso e os rácios de falsos positivos, que são os modelos neuronais
comportamentais e análises preditivas neuronais;
- A capacidade de aceitar e analisar dados provenientes de qualquer sistema que
pertença a empresa;
- Não existe nenhuma restrição teórica ao número de regras que se podem aplicar;
- A solução pode ser adquirida por um preço associado ao desempenho da mesma.
Podemos, então, caracterizar como factor distintivo desta solução o uso de variadas
técnicas de detecção de fraude. Um outro ponto diferenciador desta solução é a forma como
ela pode ser comercializada, pelo facto do preço de aquisição estar associado à sua taxa de
sucesso e colocando, assim, alguma segurança nos compradores visto funcionar como
comprovativo de qualidade da solução. Um ponto negativo desta solução, ou pelo menos dos
dados fornecidos sobre ela, é o facto de se basear demasiado na prevenção e na detecção da
fraude, tal como acontecia na solução da Spirtech, que embora se saiba ser realizada por uso
de RN's, não é revelada pormenorizadamente.
3.2.2 Características da solução FCT
As principais características da solução FCT são as seguintes:
- O facto de ser uma framework unificada (ver figura 1 dos Anexos), capaz de detectar
qualquer tipo de fraude no âmbito dos cartões de crédito;
- Um sistema de regras poderoso que possibilita uma rápida e eficaz criação e
avaliação de regras;
- Uma detecção contínua que se optimiza através de estratégias que se adaptam e
optimizam automaticamente;
- Possibilidade de receber alertas provenientes de outras aplicações anti-fraude;
- Pode operar quer em tempo real, quer em tempo quase real ou offline;
- Possibilita uma personalização de estratégias de detecção específicas de padrões de
fraude e utilização.
Sobre esta solução, um dos seus pontos fortes é o facto de funcionar não como um
simples produto mas como uma framework unificada que possibilita a integração de variadas
funcionalidades (regras, alarmes, processamento de inputs de outros sistemas de fraude, etc.).
13
Outro factor interessante é os diferentes modos de operação (tempo real, quase real (near-
offline) e offline) que conferem a flexibilidade e adaptabilidade desejável para este tipo de
sistemas. Mais uma vez esta solução peca pela pouca informação revelada em relação ao
método de prevenção utilizado (RBs).Contudo, para mostrar que a sua solução FCT era, de
facto, melhor que aquelas que usam RNs, a empresa Alaric apresentou um estudo comparativo
entre o uso de RNs e RBs [13].
Na Tabela 2 são apresentadas as principais diferenças entre as RNs e RBs, do ponto de vista
da empresa Alaric.
Redes Neuronais Redes Bayseanas
Transparência dos
valores de percentagem
de fraude retornados
Não é imediatamente
perceptível o porquê de
determinados valores de
percentagem de fraude
terem sido retornados
È extremamente
perceptível o porquê de
determinados valores de
percentagem de fraude
terem sido retornados
Tamanho dos blocos de
informação a analisar
Somente para tamanhos
elevados se conseguem
treinar adequadamente
Funcionam quer para
tamanhos pequenos,
médios ou grandes,
embora idealmente para os
pequenos e médios.
Tempo de treino
Processo demorado e
possivelmente dispendioso
porque toda a rede tem de
ser actualizada
Processo rápido e pouco
dispendioso
Adaptabilidade
É complicado realizar
updates em tempo real
pois estes têm de ser
propagados por toda a
rede, para que seja
realizado um treino global
É fácil fazer updates em
tempo real, sendo o
modelo automaticamente
reajustado sem que tenha
de existir um treino global
Tabela 2 - Redes Neuronais vs Redes Bayseanas
É importante salientar que, embora na Tabela 2 seja referido que as RN's são
denotadas negativamente, em especial nos tempos de treino elevados, e, portanto, mais
14
dispendiosos, isso não quer dizer que estas não sejam igualmente eficazes e eficientes na
prevenção de fraude.
Como já foi referido anteriormente o assunto da aprendizagem quer das RNs quer das
RBs vai ser apresentado detalhadamente na subsecção seguinte, bem como outras
características e exemplos destes métodos.
3.3 Trabalhos Relevantes
Nesta subsecção vão ser apresentados alguns trabalhos que, após a análise -crítica
realizada inicialmente a soluções existentes para prevenir e detectar fraude, se revelaram
extremamente importantes para melhor compreender estas soluções, em especial os métodos
de detecção (RNs e RBs) por elas utilizados. Deste modo, o trabalho de maior relevo foi uma
tese de mestrado [14] onde são apresentadas várias técnicas que podem ser usadas para
combater fraude, centrando-se nas RNs e RBs e nas suas características de aprendizagem.
Nesse trabalho são apresentados os três paradigmas de aprendizagem associados a estes
métodos, sendo eles: “Unsupervised learning” (UL), “Reinforcement learning” (RL) e
“Supervised learning” (SL). É desde já importante referir que estes paradigmas se aplicam a
qualquer um dos métodos em questão, podendo a sua aplicabilidade estar dependente dos
algoritmos utilizados.
O paradigma UL [15] é caracterizado por, através da recepção dos dados (inputs) e de
uma função de custo, tentar minimizar (ou por vezes maximizar) essa função de custo. Esta
função de custo pode ser qualquer função que relacione os inputs e os outputs da rede. Ela
deve ser independente da tarefa desempenhada pelo modelo e das presunções efectuadas a
priori (as propriedades implícitas do modelo, os seus parâmetros e as variáveis observadas).
Um exemplo deste paradigma é o seguinte:
- Dados: ;
- Modelo: f( ) = (onde é uma constante) ;
- Função de custo: .
A minimização do custo irá resultar num valor de que será igual à média dos dados.
A função de custo presente neste exemplo é relativamente simples, porém se o modelo
apresentado fosse um modelo estatístico, essa função já poderia depender da probabilidade a
posteriori do modelo dado os seus dados. Quando se trata de UL, não existem quaisquer pistas
sobre o(s) output(s) correcto(s).
Resta dizer, sobre este paradigma, que é aplicável a problemas gerais de estimativas
que envolvam aplicações de/com clustering e estimativas de distribuições, compressões e
filtragens estatísticas.
Por norma, quando se fala de RL [16][17] os dados, ao contrário do paradigma anterior,
não são fornecidos, sendo gerados em instantes temporais variados por meio de uma
interacção entre um agente e o meio envolvente do modelo. Num dado instante de tempo (t), o
agente executa uma determinada acção (yt) e o meio envolvente gera uma observação (xt) e
15
um custo instantâneo (ct), de acordo com uma qualquer dinâmica (geralmente desconhecida).
Depois, o objectivo será descobrir uma política/padrão para seleccionar acções de forma a
minimizar uma medida do custo a longo prazo, ou seja, o custo acumulado esperado. Neste
paradigma, o meio envolvente é tipicamente formulado como um estado processo de decisão
de Markov finito [18], e os algoritmos de RL para este contexto estão relacionados às técnicas
de programação dinâmicas. As probabilidades de transição de estado e as probabilidades de
recompensa no processo de decisão de Markov finito são tipicamente estocásticas mas
estacionárias ao longo do problema.
As principais aplicações deste paradigma são o controlo de robôs, telecomunicações,
jogos (xadrez).
O último paradigma apresentado é o SL [19]. Este caracteriza-se por proporcionar uma
aprendizagem através de uma função determinada com a ajuda de dados de treino. Esses
dados de treino são compostos por pares de inputs (geralmente vectores – conjuntos de
múltiplas variáveis) e dos outputs desejados. Por sua vez, a função resultante deste processo
de aprendizagem pode ser um valor contínuo (quando se trata de uma modelo de análise
regressiva) ou pode servir para prever uma qualquer classificação para os inputs (Pensando no
problema abordado neste trabalho seria a classificação dum acto como fraudulento ou não).
Para que um sistema, que se reja pelo paradigma SL, o faça correctamente, tem de ser capaz
de prever as funções para quaisquer dados, após um período inicial onde recebe e processa os
dados de treino. Tal objectivo só é alcançável se, através de quaisquer dados processados, for
possível fazer uma generalização que permita inferir sobre situações não previstas até ao
momento.
Um bom exemplo de um método que siga este paradigma é uma RN que use o
algoritmo de propagação inversa, também denominado de propagação do erro (Ilustração 2).
Ilustração 2- Diagrama de Blocos de “Supervised Learning” [14]
Supondo que tanto o “professor” como a RN estão expostos a um vector de treino (que
descreve o estado do meio envolvente) e que o “professor” tem conhecimento prévio dos
resultados esperados (Do ponto vista de um sistema de detecção de fraude, o “professor” seria
16
um operador deste sistema, tendo assim conhecimento de quais as situações fraudulentas e
aquelas que não o são – excepção para casos novos de fraude e que portanto são
desconhecidos para o operador) podemos dizer que essa resposta esperada será a acção
óptima resultante como output da RN. Os parâmetros da rede (“neurónios escondidos”), que
qualificam os inputs para gerar os outputs, vão ser reajustados pela combinação de influências
do vector de treino e do sinal de erro. O sinal de erro corresponde à diferença entre a resposta
desejada (output ideal) e a resposta actual (output actual) da RN. Este processo de
aprendizagem é realizado iterativamente, passo a passo, tendo como um dos objectivos finais
a substituição do “professor” pela própria RN, ou seja, a RN ficará dotada de auto
aprendizagem [20].
No geral, todas as situações onde tanto os inputs como os outputs de um componente
podem ser facilmente percebidos pode ser denominada de SL.
Para concluir, no trabalho referido [14], as ideias apresentadas anteriormente de que as
RBs podem ser usadas para combater a fraude, em especial quando a quantidade de dados é
reduzida, e que as RNs possuem tempos de aprendizagem lentos, mas que quando
correctamente treinadas apresentam taxas de sucesso (falsos positivos vs fraude efectiva) e
tempos de processamento extremamente bons, são aqui realçadas.
17
4 Controlo de Fraude: Solução Proposta
Como já foi mencionado, uma solução completa que vise solucionar o problema global
de fraude deve reger-se por três ciclos base:
(1) Prevenção,
(2) Detecção,
(3) Aprendizagem.
Assim sendo, a solução proposta neste trabalho tem estas três fases representadas em 2
componentes, tendo depois um outro componente, que podemos dizer como final, de
apresentação de resultados. Nas subsecções seguintes vão ser explicados cada um dos
componentes em pormenor, bem como os passos necessários para que o processo de
prevenção e detecção de fraude ocorra com os resultados expectáveis.
4.1 Motor de Regras
O primeiro componente da solução proposta, responsável pela etapa de prevenção de
fraude, é denominado por Motor de Regras (MR). Este vai ser o responsável por filtrar, numa
etapa inicial, os possíveis actos fraudulentos.
Ele é composto por um conjunto de regras que se encontram adaptadas à realidade do
tipo de fraude que se pretende prevenir. Para essa adaptação, foi necessário um esforço inicial
de identificação dos tipos de fraude conhecidos nos transportes públicos e quais as suas
características distintivas, sendo que na tabela 1, anteriormente apresentada, se encontram os
resultados desse esforço. Com base neste quadro devem ser criadas as regras iniciais do
sistema, estando assim completa a fase inicial de prevenção. No entanto, estas regras estão
sujeitas a mudanças (adaptabilidade), visto a solução proposta ter uma fase de aprendizagem
onde são gerados novos inputs para essas regras de acordo com os outputs da componente
de análise (descrita em pormenor na subsecção seguinte). Por outro lado, estas mudanças
podem advir de uma reajustamento de regras e/ou criação de novas regras por parte dos
utilizadores da solução através do componente denominado apresentação de resultados. Esta
adaptabilidade corresponde às acções 3 e 5 da Ilustração 3, onde está representado o fluxo
base de operação da solução.
Ilustração 3 - Fluxo base de operação da solução.
18
Possíveis cenários de como este componente vai funcionar na realidade são apresentados
de seguida:
Cenário 1:
- Uma ou mais transacções entram no sistema;
- São processadas as regras definidas (No momento de entrada da transacção estas
regras podem ser as inicias do sistema, já terem sofrido modificações ou serem novas
regras);
- O resultado das regras vai ser transmitido para o componente de análise.
Cenário 2:
- Transacções que já tenham sido marcadas como <indefinidas>9 reentram no
processo de prevenção de fraude caso este tenha sofrido alterações (alteração nas
regras usadas na classificação inicial dessas transacções);
- São processadas as regras definidas (diferentes das inicialmente utilizadas para
marcar estas transacções);
- O resultado das regras vai ser transmitido ao componente de análise.
Cenário 3:
- Sempre que haja modificação de regras que tenham sido utilizadas para quantificar
transacções no estado <não fraude> essas transacções reentram no processo de
prevenção de fraude;
- São processadas as regras associadas a esta transacção;
- O resultado das regras vai ser transmitido ao componente de análise.
Uma outra particularidade deste componente é a atribuição de graus de prioridade às
regras. Vão existir as chamadas regras críticas (com maior prioridade) as quais por si só,
quando violadas, representam situações fraudulentas. Depois, temos outro conjunto de regras
de prioridade normal que vão gerar os inputs normais para o componente seguinte. Outra
característica importante de cada uma das regras é o registo, somente para efeitos estatísticos
e de apresentação de resultados, do número de transacções que violaram uma determinada
regra e foram consideradas como fraudulentas ou não. O operador poderá querer verificar a
aplicabilidade da regra através da verificação do número de transacções que violaram uma
determinada regra mas que, no final do processo de prevenção e detecção, não foram
consideradas fraudulentas.
Na Ilustração 4, é apresentada uma estrutura típica das regras aqui descritas.
Podemos verificar a presença de campos que representam a regra, o seu nível de prioridade e
as contagens anteriormente referidas.
9 Na subsecção seguinte são explicados detalhadamente os valores resultantes do Modelo de Análise
19
Ilustração 4 - Estrutura típica de uma Regra de Decisão
Este será o componente responsável pelo primeiro passo desta solução, gerando os
inputs necessários para que o segundo componente consiga quantificar a fraude.
4.2 Modelo de Análise
O segundo componente da solução proposta é o Modelo de Análise (MA), sendo este o
componente responsável pela detecção de fraude.
Com o uso de RNs e RBs, através de um faseamento do modo de operação deste
componente e, considerando os inputs provenientes do primeiro componente (regras), vai ser
atribuído um “nível de fraude” à transacção em questão. Este “nível de fraude” corresponde a
um de três possíveis valores: <fraude>, <não fraude> e <indefinido>. Os dois primeiros são os
mais óbvios correspondendo, respectivamente, a situações em que as transacções são
classificadas como fraudulentas, ou porque houve uma regra crítica na qual estas foram
identificadas ou porque foi detectado um novo padrão de fraude pelo MA, e situações em que
as transacções respeitam o funcionamento considerado normal do sistema. Por fim, uma
transacção será classificada como <indefinido> quando, durante a segunda fase do modo de
operação deste componente, explicada em detalhe na seguinte subsecção, os resultados do
MA através de RNs e de RBs diferir, ou seja, quando a transacção for marcada como <fraude>
e <não fraude> em simultâneo. É ainda importante referir que, tal como foi referido na secção
3.1, os outputs provenientes quer das RNs quer dos RBs são probabilidades de fraude, sendo
depois ajustadas a estes estados, de acordo com um valor mínimo de probabilidade da
transacção ser fraudulenta, denominado threshold de fraude. Sempre que uma transacção,
terminado o processo de detecção de fraude, apresente uma probabilidade associada superior
a este threshold, ela vai ser qualificada como <fraude> antes de ser transferida como resultado
para o componente seguinte. Na Ilustração 5 está representada uma exemplificação do
componente aqui descrito. Nela mostra-se que os seus inputs são influenciados pelo
componente MR e que os seus outputs são transferidos para o componente “Configuração &
Apresentação” (C&A). Para que os inputs originem os outputs, estes vão ter de ser
quantificados probabilisticamente ao logo de toda a rede e no final, de acordo com o valor de
threshold de fraude, escolher o estado da transacção.
20
Ilustração 5 - Exemplificação do MA
Foi anteriormente referido que a solução iria utilizar quer RNs quer RBs neste
componente e que tal ia ser conseguido através de um faseamento do seu modo de operação.
Na subsecção seguinte essa informação é aprofundada.
4.2.1 Fases do Modelo de Análise
Do estudo realizado e apresentado no capítulo anterior, concluiu-se que optar ou por
RNs ou por RBs e ignorar por completo o outro modo de análise seria um grande erro. Como
tal, a solução aqui proposta, mais concretamente o componente descrito nesta secção, foi
pensada de forma a combinar o uso de RNs e RBs para conseguir, assim, maximizar a
detecção de fraude.
Vimos anteriormente que RNs seriam ideais para detectar fraude em sistemas com
uma enorme quantidade de dados, ou seja, um sistema central de um operador de transportes
já em completo e prolongado funcionamento (quando as transacções diárias estiverem na
ordem das dezenas de milhar) Então se este componente tivesse como base somente RNs nos
primeiros tempos de funcionamento não estaríamos a realizar um combate à fraude correcto ou
mesmo real. Para colmatar esta falha o uso das RBs pode ser considerado como obrigatório.
Assim sendo, optou-se por separar o funcionamento deste componente em 3 fases distintas:
arranque do sistema, migração e estabilização. A cada uma destas fases corresponde a
utilização de um método de análise diferente, à excepção da fase intermédia onde os dois
métodos vão ser utilizados em simultâneo. No arranque do sistema, como o volume de dados
ainda vai ser de tal forma pequeno que não se justificava o uso de RNs, vão ser usadas RBs
para inferir sobre fraude. Na segunda fase, quando o volume de dados atingir um determinado
limite, as RNs vão ser activadas passando a funcionar em simultâneo com as RBs, devendo
esta operação em simultâneo durar o tempo necessário para uma correcta aprendizagem por
parte das RNs. Na fase final somente as RNs se vão encontrar em funcionamento, ou, caso o
operador deseje, a fase intermédia ou mesmo a inicial pode ser retomada.
21
Quando uma transacção for quantificada pelo componente aqui descrito, vai ser
transferida para o componente C&A responsável, em parte, pela apresentação do resultado da
quantificação aqui realizada. Na secção seguinte descreve-se este componente.
4.3 Configuração & Apresentação
O “último” componente da solução apresentada é aquele que torna todo o processo de
prevenção e detecção de fraude visível e acessível aos operadores. É através deste
componente que vai ser possível consultar os resultados da quantificação de fraude realizada
pelos outros dois componentes, decidindo o que fazer com eles. Essa decisão pode passar
pela refutação de resultados, isto é, quem tem a última decisão sobre se uma transacção é
fraudulenta ou não são os operadores podendo contradizer a quantificação gerada pelo
segundo componente (MA). Outra opção de decisão é o reajustamento do primeiro
componente (MR), ou seja, alterar regras existentes, ou a introdução de novas regras. Estas
duas principais funcionalidades são descritas mais detalhadamente nas subsecções seguintes.
4.3.1 Apresentação de Resultados
Esta funcionalidade vai ser uma das mais importantes de toda a solução visto ser
através dela que os operadores podem visualizar os resultados da prevenção e detecção de
fraude. Como tal, ela vai, através de uma interface web, apresentar uma lista com informação
resumida de transacções que foram quantificadas como fraudulentas, ou aceder a esta lista
após uma primeira visualização de gráficos relativos à fraude, dando depois a possibilidade de
decidir o que realizar com as mesmas. Algumas das acções disponíveis vão ser:
1 - Visualizar Detalhes, aqui podem ser consultadas as regras que a transacção violou,
a percentagem de fraude que lhe foi atribuída, entre outros aspectos;
1.1 – Realiza Nova Análise, possibilidade de realizar uma análise “instantânea” a uma
transacção, tendo em conta as regras que se encontram activas;
2 - Refutar a quantificação, possibilidade de alterar o estado da transacção de <fraude>
para <não fraude>;
3 - Gerar alertas, possibilidade de enviar alertas (emails, sms, etc.) para as pessoas
designadas no sistema como responsáveis de fraude;
4 - Verificar Regras, possibilidade de visualizar quais as regras que a transacção em
causa violou;
4.1 – Seleccionar Regras, possibilidade de alterar as regras anteriormente
seleccionadas;
5 - Gráficos de Fraude, possibilidade de visualizar gráficos que reúnem informação
variada sobre transacções fraudulentas e não fraudulentas.
22
Na Ilustração 6 estão representadas, nalguns fluxos de utilização, as acções anteriormente
descritas.
Ilustração 6 - Alguns Fluxos de utilização do componente C&A
Caso uma transacção viole um determinado limite de regras passa a ser considerada
como extremamente fraudulenta e os alertas mencionados anteriormente são gerados
automaticamente. A funcionalidade de “Seleccionar Regras” mencionada atrás vai ser descrita
com maior detalhe na subsecção seguinte.
4.3.2 Configuração
Esta funcionalidade vai permitir aos operadores consultarem as regras que estão a ser
usadas, definirem o nível dessas regras, criarem novas regras ou modificarem as já existentes,
configurando assim o sistema.
Através de uma interface web, os operadores podem pesquisar quais as regras que
estão a ser utilizadas no seu sistema de prevenção de fraude. De seguida podem proceder a
alterações dessas regras, modificando qualquer um dos seus constituintes (Ilustração 4). Uma
outra opção é a criação de regras novas, devendo nessa altura ser escolhido o nível de
prioridade a atribuir à regra, a sua prioridade e outras características.
Com a descrição deste componente e das suas funcionalidades, termina a descrição da
solução apresentada. Resta apenas dizer que esta solução tem como finalidade a integração
num módulo de Segurança e Fraude já existente que irá complementar as funcionalidades
desta solução (em especial a análise criptográfica de transacções, assinaturas digitais e
certificados, e os problemas que dai resultam) originando essa junção um novo módulo, mais
completo. Para finalizar esta secção é apresentada na Ilustração 7 aquele que se pode
denominar de overview da solução proposta.
23
Ilustração 7 - Overview da Solução
25
5 Controlo de Fraude: Solução Desenvolvida
Tendo em conta a complexidade da solução proposta, juntamente com a janela
temporal existente para a realização deste trabalho, optou-se por uma implementação e
optimização parcial dessa solução de modo a que os resultados obtidos e a validação fossem o
mais confiáveis possíveis. Assim sendo, dos três componentes propostos foram somente
implementados, validados e optimizados os componentes MR e C&A, ficando para trabalho
futuro o componente MA. Contudo, durante o desenvolvimento da solução a forma como esta
tinha sido inicialmente descrita foi algo alterada. Ao longo deste capítulo vão ser detalhadas as
alterações efectuadas à solução proposta em simultâneo com a forma adoptada para a
implementação e funcionamento dos vários componentes.
5.1 Arquitectura dos Dados
O modelo de dados que foi desenvolvido para poder realizar a implementação
respectiva a este trabalho é apresentado nas figuras seguintes.
Ilustração 8 - Tabelas directamente relacionadas com o MR
26
Ilustração 9 - Tabelas utilizadas para guardar os resultados das análises e as configurações do sistema
Ilustração 10 - Vista utilizada para apresentar os resultados globais das análises
As tabelas apresentadas servem para modelar as regras necessárias para o correcto
funcionamento do componente MR (Ilustração 8), para guardar os resultados da análise de
fraude e os valores de variáveis utilizadas durante essa análise ou durante a apresentação
desses resultados (Ilustração 9) e para obter as informações gerias dos resultados das
análises efectuadas (Ilustração 10). Ao longo da discrição dos vários componentes, nas
secções seguintes deste capítulo, estas tabelas vão ser referenciadas e a sua utilização vai ser
explicada em detalhe.
27
5.2 Componentes: Motor de Regras
Este componente, MR, vai ser o principal responsável pela detecção de fraude. Vai ser
através dele que, numa primeira fase, se vão classificar as transacções analisadas de acordo
com o seu grau de sub-repção. Aquando do término da sua acção, em relação a uma
determinada transacção, esta vai ser classificada com um dos possíveis estados de fraude
identificados anteriormente onde na solução proposta inicialmente, nem sempre se quantificava
fraude neste componente, sendo isso agora um requisito essencial. Esta classificação das
transacções como fraudulentas ou não fraudulentas após o término da acção deste
componente foi uma das alterações efectuadas em relação à solução proposta. Para conseguir
realizar a sua função este componente baseia-se na interpretação de um conjunto de regras
definidas numa linguagem própria, parametrizadas no componente C&A e aplicadas às
transacções em análise.
O principal pilar deste componente é o conjunto de regras, que servem para identificar
situações fraudulentas, e a sua interpretação face a uma determinada transacção. Nesta
secção vão ser apresentadas essas regras, mais concretamente a forma como estas foram
implementadas seguido da sua interpretação para análise de fraude.
5.2.1 Motor de Regras: Implementação das Regras
O conceito de regra é representado no modelo de dados pelas tabelas presentes na
Ilustração 8. Ai estão presentes as várias tabelas que definem ou se relacionam directamente
com uma regra. Essas tabelas são as seguintes:
RULE_TYPES, Esta tabela contém os possíveis tipos aos quais uma regra pode
pertencer, sendo que as possibilidades são as seguintes:
o Tipo 1- Regra para Validações;
o Tipo 2- Regra para Carregamentos;
o Tipo 3- Regra para Validações e Carregamentos;
RULE_LEVELS, Esta tabela contém os possíveis níveis de prioridade que podem ser
atribuídos a uma regra, sendo que as possibilidades são as seguintes:
o Low – Nível mais baixo; Representado pelo número um;
o Normal – Nível intermédio; Representado pelo número dois;
o High – Segundo nível mais prioritário; Representado pelo número três;
o Critic – Nível mais prioritário; Representado pelo número quatro;
RULE_ELEMENTS, Esta tabela contém os vários elementos que podem ser usados
pela Linguagem do Motor de Regras (LMR), descrita na próxima subsecção, para
definir uma regra. Um elemento é definido por uma query sql, pela enumeração dos
argumentos utilizados nessa query, pela enumeração dos elementos de retorno dessa
28
query, pelo tipo de regra onde esse elemento pode ser aplicado e por um nome
descritivo do elemento.
RULES, Esta tabela contém as várias regras que parameterizadas para utilização pelo
MR. Cada regra é identificada pelo seu nome, definida através da LMR, tem uma
prioridade associada (valores possíveis presentes na tabela RULE_LEVELS), esta
associada a um tipo de regra (valores possíveis presentes na tabela RULE_TYPES) e
pode estar activa individualmente, activa como parte de um grupo de regras ou
inactiva.
RULE_GROUPS, Esta tabela contém os grupos aos quais uma regra pode pertencer.
O intuito dos grupos de regras é para que se possam realizar análises mais
sistemáticas e menos pesadas, seleccionando amostras que coincidam melhor com o
tipo de regras em questão. Este matching deve ser feito não só para melhorar os
tempos de processamento mas também para que os resultados obtidos sejam os mais
fidedignos possíveis. Os grupos definidos para esta implementação foram os
seguintes:
o Card Rules – Grupo ao qual devem pertencer todas as regras que validem
informações referentes aos cartões, meio de suporte, utilizados nas
transacções em análise;
o Contract or Profile Rules – Grupo ao qual devem pertencer todas as regras
que validem informações referentes aos contratos ou perfis, utilizados nas
transacções em análise;
o Operator Rules – Grupo ao qual devem pertencer todas as regras que validem
informações referentes aos operadores, presentes transacções em análise;
o Trip Rules – Grupo ao qual devem pertencer todas as regras que validem
informações referentes a viagens e modos de utilização, referentes às
transacções em análise;
o No Group – Grupo ao qual devem pertencer todas as regras que não reúnam
condições necessárias par pertencer aos demais grupos;
RULE_TO_RULE_GROUPS, Nesta tabela são realizadas as associações entre as
várias regras e o grupo de regras a que pertencem. Para tal é necessário o
identificador da regra, o identificador do grupo, o tipo de regra e um campo que indica
se a relação se encontra activa ou inactiva (se deve ser usada durante o
processamento de regras de grupo ou não).
De seguida vai ser descrita em pormenor a LMR, vão ser apresentados exemplos da
implementação de algumas das regras usadas na implementação e por fim será apresentado o
29
mapeamento entre as regras implementadas e os tipos de regras identificados na fase inicial
deste trabalho (Tabela 1).
5.2.1.1 Implementação das Regras: Linguagem Motor de Regras
A definição de uma regra através da LMR deve seguir um formato específico, podendo
somente ser utilizados determinados elementos. Os elementos que podem ser utilizados para
definir uma regra são os seguintes:
Elementos registados na tabela RULE_ELEMENTS, cujo modo de utilização via
LMR vai ser detalhado numa fase posterior;
Outras Regras, através da simbologia R(id), onde id corresponde ao
identificador da regra referenciada;
Constantes, através da simbologia C(nome), onde nome corresponde ao nome
da constante cujo valor se pretende utilizar;
Distâncias entre Paragens, através da simbologia SD(paragem1|paragem2),
onde paragem1 corresponde ao identificador da paragem de origem e
paragem2 corresponde ao identificador da paragem de destino;
Operadores aritméticos, comparativos, de atribuição e lógicos que podem ser
utilizados da seguinte forma:
o +, Representa o operador aritmético de adição;
o -, Representa o operador aritmético de subtracção;
o *, Representa o operador aritmético de multiplicação;
o /, Representa o operador aritmético de divisão;
o <, Representa o operador comparativo “menor que”;
o >, Representa o operador comparativo “maior que”;
o <=, Representa o operador comparativo “menor ou igual que”;;
o >=, Representa o operador comparativo “maior ou igual que”;;
o <>, Representa o operador comparativo “diferente que”;
o ==, Representa o operador comparativo “igual a”;
o =, Representa o operador de atribuição;
o &&, Representa o operador lógico AND (e);
o ||, Representa o operador lógico OR (ou);
Números;
Valores booleanos, que devem ser representados da seguinte forma:
o true – para o valor booleano Verdadeiro;
o false – para o valor booleano Falso;
Estes elementos devem ser utilizados para construir uma expressão a avaliar e as
respectivas acções caso o resultado dessa avaliação seja verdadeiro ou falso. Para tal, a
estrutura base de uma regra tem de ser “ [expressão] TRUE acção FALSE acção ”, onde
30
expressão pode ser uma qualquer combinação dos elementos referidos anteriormente, desde
que o resultado dessa combinação seja um valor booleano e acção pode ser uma qualquer
combinação dos elementos referidos anteriormente. É importante referir que a expressão deve
estar sempre delimitada por parêntesis rectos, vulgos [ e ], e que pode ser constituída por
conjuntos de expressões, desde que cada uma delas também se encontre delimitada por
parêntesis rectos. Uma expressão composta poderia ser definida da seguinte forma:
[[expressão] operador [expressão]].
Como já tinha sido referido anteriormente, alguns dos possíveis elementos usados pela
LMR para a definição de uma regra são os elementos registados na tabela RULE_ELEMENTS.
Esses elementos podem ser utilizados na definição de uma regra através das seguintes
formas:
Rule Element (re) – Significa que o(s) objecto(s) de retorno da query correspondente
ao elemento definido na tabela RULE_ELEMENTS tabela vão ser utilizados no
processamento da regra sem qualquer alteração; Isto é, se o objecto retornado for um
número é processado como um número, se o objecto for um nome é processado como
texto, entre outros;
Rule Information (ri) – Significa que o retorno da query correspondente ao elemento
definido na tabela RULE_ELEMENTS tabela vai ser manipulado de forma a devolver
somente true (caso seja retornado algum objecto) ou false (caso não seja retornado
qualquer valor);
Rule Date (rd) – Significa que o retorno da query correspondente ao elemento definido
na tabela RULE_ELEMENTS tabela vai ser manipulado de forma a devolver o valor de
uma data em milissegundos;
A forma como estes elementos são utilizados na LMR é a seguinte:
re(objectId,elementId;arg1;arg
N-1;arg
N) (usando um Rule Element para exemplo, sendo que é
exactamente igual para os outros elementos identificados anteriormente). Onde objectId
corresponde ao identificador do objecto de retorno que se deseja utilizar, elementId
corresponde ao identificador do elemento a utilizar (vulgo, identificador da tabela
RULE_ELEMENTS), e os valores de arg1 a arg
N correspondem aos argumentos necessários para
a query do elemento em questão. Para melhor compreender esta situação apresenta-se de
seguida o seguinte exemplo onde o elemento em questão se encontra registado na tabela
RULE_ELEMENTS como apresentado na tabela seguinte.
RULE_ELEMENT_ID RULE_ELEMENT_DISPLAY_NAME RULE_ELEMENT_QUERY
1 Elemento de Exemplo 1 select nome, data_nascimento
from cliente where cliente_id = ?
RULE_ELEMENT_ARGUMENTS RULE_ELEMENT_PROPERTIES RULE_TYPE_ID ACTIVE
client_id nome;data_nascimento 4 1
31
Assim, se quisermos utilizar este elemento na definição de uma regra. Tal pode ser feito
nas seguintes formas:
re(1,1;clientId), esta utilização do elemento corresponde à obtenção do nome do
cliente identificado com o valor clientId;
re(2,1;clientId), esta utilização do elemento corresponde à obtenção da data de
nascimento do cliente identificado com o valor clientId;
ri(1,1;clientId), esta utilização do elemento corresponde à verificação da existência (na
base de dados) do nome do cliente identificado com o valor clientId, sendo retornado
true caso exista e false caso contrário;
ri(2,1;clientId), esta utilização do elemento corresponde à verificação da existência (na
base de dados) da data de nascimento do cliente identificado com o valor clientId,
sendo retornado true caso exista e false caso contrário;
rd(2,1;clientId), esta utilização do elemento corresponde à obtenção em milissegundos
da data de nascimento do cliente identificado com o valor clientId;
5.2.1.2 Implementação das Regras: Mapeamento entre Tipos de Fraude e Regras
Das situações típicas de fraude identificadas no inicio deste trabalho (Tabela 1)
somente algumas é possível combater com o componente MR. Para casos mais complexos,
como por exemplo alteração de padrões de utilização de um cartão (que poderia significar
roubo do mesmo) seria necessário o componente MA, que não foi implementado por razões
anteriormente explicadas. Assim sendo, na Tabela 1, em Anexo, é possível consultar as regras
que foram implementas para combater cada tipo de fraude. Ainda nesse Anexo, a tabela 2
corresponde à lista de todos os elementos da tabela RULE_ELEMENTS utilizados na
implementação e avaliação da mesma.
Somente a título elucidativo é de seguida apresentada a tradução de uma regra,
definida via LMR, para linguagem corrente. A regra escolhida foi a Regra 5 ("Validation -
Check Card Type Exsts") que se apresenta definida da seguinte forma:
[ri(4:1;re(8:3;system_item)) && ri(5:1;re(8:4;system_item))] TRUE false FALSE true
Se analisarmos os seus componentes individualmente o resultado é o seguinte:
ri(4:1;re(8:3;system_item)), Verificar se o modelo de cartão presente na validação
existe no sistema central, usando para isso o modelo de cartão presente na validação;
o re(8:3;system_item), Retorna o modelo de cartão presente na validação;
ri(5:1;re(8:4;system_item)), Verificar se o tipo de cartão presente na validação existe
no sistema central, usando para isso o tipo de cartão presente na validação;
o re(8:4;system_item), Retorna o tipo de cartão presente na validação;
&&, Representa o operador lógico AND (e);
32
false, Valor booleano falso, que é traduzido pelo MR como “não fraude” (mais
detalhes na secção seguinte);
true, Valor booleano verdadeiro, que é traduzido pelo MR como “fraude” (mais
detalhes na secção seguinte);
Traduzindo a regra para linguagem corrente obtemos a seguinte frase:
“Se o modelo de cartão presente na validação existir no sistema central e se o tipo de
cartão presente na validação existir no sistema central então não é fraude, caso contrário é
fraude”.
Findo este exemplo, na secção seguinte vai ser explicada a forma como o MR faz a
tradução das regras, aplicando-as a uma determinada transacção.
5.2.2 Motor de Regras: Interpretação das Regras
Tendo em conta que as análises de fraude devem ser feitas com alguma periodicidade
a utilização de um serviço periódico, mas cuja periodicidade pudesse ser facilmente alterável,
foi a solução encontrada para dar inicio ao processo de análise de fraude. Assim sendo, na
subsecção seguinte é apresentado o fluxo que se inicia ciclicamente aquando da chamada
desse serviço.
5.2.2.1 Interpretação das Regras: Fluxo de Processamento
Na (Ilustração 11) é apresentado um diagrama descritivo de todo o fluxo de
processamento associado ao MR.
Serviço
Existem
Regras?
Selecção Regras
Activas
Selecção Amostra de Dados
Nova Amostra
de Dados
Amostras
Independentes
?
Primeira
Amostra
?
Nova Amostra
de Dados
Amostra de
Dados Anterior
Sim Sim
Não Não
Sim
Não
Ilustração 11 - Fluxo do MR
33
O serviço que inicia o processo de análise tem uma periodicidade diária cujo tempo
inicial pode ser alterado sempre que se despoletar o início10 da análise de fraude.
Sempre que este serviço despoleta o início do processo de análise fá-lo através de
chamadas individuais, para cada tipo de regra existente (enumeradas em 5.2.1), de uma
função que tem como intuito verificar que regras estão activas, consoante o tipo de regra
fornecido, e caso haja regras activas nesse momento seleccionar a amostra de dados que
deve ser processada. Finda essa selecção, o próximo passo será a realização de uma análise
sintáctica de cada uma das regras activas, aplicada à amostra de dados seleccionada. É
importante referir que a selecção da amostra pode ser controlada de acordo com o tipo de
regra que se está analisar, sendo que tal efeito é conseguido através da manipulação de
algumas constantes configuradas no outro componente da solução implementada (a descrição
dessas constantes encontra-se em 5.3). Esse processamento efectivo passa pela tradução da
LMR que define cada uma das regras, aplicada à amostra seleccionada, Na subsecção
seguinte são apresentadas algumas particularidades da análise sintáctica a que são
submetidas as regras, aplicadas à amostra de dados seleccionada
5.2.2.1.1 Interpretação das Regras: Tradução de LMR
Como já foi referido nas secções 5.2.1.1 e 5.2.1.2 a LMR e o seu processamento são
os pilares do componente MR. Contudo resta dizer que nem sempre é realizado uma tradução
da LMR pois a utilização de um uma cache, por parte do MR, permite utilizar traduções antigas.
Isto é, se um dado elemento for usado múltiplas vezes na mesma regra ou em regras que
sejam processadas durante o mesmo fluxo de processamento, a tradução deste elemento só é
efectuada uma primeira vez, sendo depois guardado o valor correspondente a essa tradução
numa cache, cuja duração corresponde à duração de todo o fluxo de processamento, e usado
esse valor para traduções posteriores desse elemento.
O seguinte exemplo tende a exemplificar a situação aqui apresentada:
Regra: re(1:1:clientId) > re(2:1:clientId; re(1:1:clientId)) TRUE true FALSE false
Inicialmente será traduzido o elemento re(1:1:clientId), da forma descrita em 5.2.1, e
guardado o resultado dessa tradução na cache do MR. De seguida seria traduzido o
elemento > como sendo o operador comparativo “maior que”. Depois, para a tradução
do elemento re(2:1:clientId; re(1:1:clientId)) deveria ser novamente traduzido o
elemento re(1:1:clientId) contudo, como já tinha sido anteriormente traduzido e
guardado em cache o valor dessa tradução é esse o valor a ser utilizado. Assim, reduz-
se o tempo de processamento pois a consulta de cache é mais rápida que a tradução
de normal de um elemento11.
10 Ver no Anexo B a secção “Forçar início da Análise de Fraude” 11 Ver no capítulo 5.3 os testes que comprovam estas afirmações
34
5.3 Componentes: Configuração & Apresentação
O componente C&A representa todas as configurações necessárias para realizar
correctamente uma análise de fraude, assim como consultar os resultados provenientes dessa,
ou de outras, análises. Para tal, na solução desenvolvida, este componente é reflectido numa
interface web12 que possibilita a consulta e manipulação de todo o tipo de configurações e
resultados relacionados com a solução para controlo de fraude.
Nesta secção vai ser descrita essa interface, sendo separadas as funcionalidades que
correspondem à parte de configuração das funcionalidades unicamente relacionadas com os
resultados das análises.
5.3.1 Configuração & Apresentação: Configuração
As possibilidades de configuração da solução proposta variam desde o tamanho das
amostras de dados a analisar, à quantidade de regras a utilizar nas análises, ao tipo de análise
que se vai realizar, à prioridade das regras a utilizar nas análises, entre outros. A forma,
simples, como se podem configurar todos estes parâmetros é através da funcionalidade “Gerir
Contantes”.
Ilustração 12 - Funcionalidade “Gerir Constantes”
Nesta funcionalidade é apresentado, para consulta (apresentado na Ilustração 12) e,
caso se deseje, alteração, o conjunto de todas as constantes que servem para
configurar/parametrizar o sistema de controlo de fraude implementado. Essas constantes, a
sua descrição e os seus possíveis valores são apresentados na Tabela 3.
12 Definição disponível em http://en.wikipedia.org/wiki/Web_interface a 03-01-2009
35
Constantes Descrição Valores Possíveis
FRAUD_PAGE_SIZE
Esta constante define o nº de resultados de
análises que aparecem por cada página
resultante da funcionalidade “Consultar
Resultados de Fraude” (5.3.2.2)
Pode tomar valores
numéricos, inteiros entre 1 e
“mais infinito”
É recomendado o uso de
valores entre 10 e 30 por
questões visuais
RULE_ITEMS_NR
Esta constante define o nº de regras
associadas a cada transacção que devem
ser apresentadas na página resultante da
funcionalidade “Consultar Dados da
Transacção” (5.3.2.2.1)
Pode tomar valores
numéricos, inteiros entre 1 e
“mais infinito”
É recomendado o uso de
valores entre 1 e 10 por
questões visuais
INDEPENDENT_BLOCKS
Esta constante define a utilização, ou não,
de amostras distintas para cada grupo de
regras que se encontre activo aquando de
uma análise de fraude. Caso o seu valor
seja true serão usadas amostras distintas
para cada grupo de regras, e caso contrário
(com o valor false) a mesma amostra é
usada para todos os grupos e regras
Pode tomar os valores
booleanos: true e false
TX_TO_PROCESS
Esta constante define o nº de transacções a
serem processadas durante cada análise. A
sua utilização depende do valor configurado
para a constante INDEPENDENT_BLOCKS.
Somente quando essa constante tiver o
valor true é que o valor desta constante tem
influência na análise de fraude
Pode tomar valores
numéricos, inteiros entre 1 e
“mais infinito”
Os valores recomendados
variam consoante o tipo de
análise pretendida. Na
secção de validação da
solução são apresentadas
algumas possibilidades.
CARD_TXS_BLOCKS
Esta constante define o nº de transacções a
serem processadas, aplicadas ao grupo de
regras “Card Rules” (5.2.1), durante cada
análise. A sua utilização depende do valor
configurado para a constante
INDEPENDENT_BLOCKS. Somente quando
essa constante tiver o valor false é que o
valor desta constante tem influência na
análise de fraude
Pode tomar valores
numéricos, inteiros entre 1 e
“mais infinito”
Os valores recomendados
variam consoante o tipo de
análise pretendida. Na
secção de validação da
solução são apresentadas
algumas possibilidades.
36
CONTRACT_TXS_BLOCKS
Esta constante define o nº de transacções a
serem processadas, aplicadas ao grupo de
regras “Contract or Profile Rules” (5.2.1),
durante cada análise. A sua utilização
depende do valor configurado para a
constante INDEPENDENT_BLOCKS. Somente
quando essa constante tiver o valor false é
que o valor desta constante tem influência
na análise de fraude
Pode tomar valores
numéricos, inteiros entre 1 e
“mais infinito”
Os valores recomendados
variam consoante o tipo de
análise pretendida. Na
secção de validação da
solução são apresentadas
algumas possibilidades.
ENTITY_TXS_BLOCKS
Esta constante define o nº de transacções a
serem processadas, aplicadas ao grupo de
regras “Operator Rules” (5.2.1), durante
cada análise. A sua utilização depende do
valor configurado para a constante
INDEPENDENT_BLOCKS. Somente quando
essa constante tiver o valor false é que o
valor desta constante tem influência na
análise de fraude
Pode tomar valores
numéricos, inteiros entre 1 e
“mais infinito”
Os valores recomendados
variam consoante o tipo de
análise pretendida. Na
secção de validação da
solução são apresentadas
algumas possibilidades.
TRIP_TXS_BLOCKS
Esta constante define o nº de transacções a
serem processadas, aplicadas ao grupo de
regras “Trip Rules” (5.2.1), durante cada
análise. A sua utilização depende do valor
configurado para a constante
INDEPENDENT_BLOCKS. Somente quando
essa constante tiver o valor false é que o
valor desta constante tem influência na
análise de fraude
Pode tomar valores
numéricos, inteiros entre 1 e
“mais infinito”
Os valores recomendados
variam consoante o tipo de
análise pretendida. Na
secção de validação da
solução são apresentadas
algumas possibilidades.
CHECK_BY_RULE_LEVEL
Esta constante define a análise, ou não, de
amostras somente aplicadas a regras com
uma determinada prioridade das regras.
Caso o seu valor seja true somente serão
utilizadas na análise regras activas cuja
prioridade seja igual à definida pela
constante RULE_LEVEL, e caso contrário
(com o valor false) quaisquer regras activas
serão utilizadas na análise
Pode tomar os valores
booleanos: true e false
37
RULE_LEVEL
Esta constante define o nível de prioridade
das regras a utilizar durante cada análise. A
sua utilização depende do valor configurado
para a constante CHECK_BY_RULE_LEVEL.
Somente quando essa constante tiver o
valor true é que o valor desta constante tem
influência na análise de fraude
Pode tomar valores
numéricos, inteiros entre 1 e
4
Esses valores correspondem
aos níveis de prioridade
presentes na tabela
RULE_LEVELS (5.2.1)
MINIMUM_ENTRANCES_TIME
Esta constante define o tempo mínimo (em
milissegundos) entre entradas simultâneas
na mesma estação
Pode tomar valores
numéricos, inteiros entre 1 e
“mais infinito”.
É recomendado o uso de
valores que se adaptem à
realidade da rede de
transportes em análise
MINIMUM_EXITS_TIME
Esta constante define o tempo mínimo (em
milissegundos) entre saídas simultâneas na
mesma estação
Pode tomar valores
numéricos, inteiros entre 1 e
“mais infinito”.
É recomendado o uso de
valores que se adaptem à
realidade da rede de
transportes em análise
MINIMUM_TRIP_TIME
Esta constante define o tempo mínimo (em
milissegundos) entre uma entrada e uma
saída (ou vice-versa) simultâneas na mesma
estação
Pode tomar valores
numéricos, inteiros entre 1 e
“mais infinito”
É recomendado o uso de
valores que se adaptem à
realidade da rede de
transportes em análise
Tabela 3 - Constantes de Fraude
Ainda relativamente à funcionalidade “Gerir Constantes”, foi referido que esta permitia a
alteração dos valores de cada constante. Essa alteração é efectuada através do ícone que
conduz o utilizador para um novo ecrã (Ilustração 13) onde é identificada a constante que se
vai alterar, e um local onde deve ser colocado o novo valor a atribuir à constante. É importante
referir que nesta implementação não são validados os valores que cada utilizador atribui ás
constantes, sendo por isso da inteira responsabilidade do mesmo a introdução de valores que
não correspondam aos permitidos (ver Tabela 3), podendo levar a um funcionamento
incorrecto de todo o sistema de controlo de fraude.
38
Ilustração 13 – Finalizar Configurar Constante
Outra parametrização possível é relativa às regras a utilizar em cada análise. Para tal é
possível seleccionar quais regras ou quais grupos de regras devem ser utilizados numa
determinada análise. Essa selecção é feita através da funcionalidade “Seleccionar Regras”.
Através de simples checkboxes o utilizador consegue seleccionar grupos de regras,
e/ou regras individualmente, para serem usadas nas análises subsequentes. De forma a tornar
mais fácil a escolha ou detrimento de uma determinada regra, é possível, através da
funcionalidade “Consulta dos Dados da Regra” (5.3.2.2.2), acedida via ícone , consultar os
dados referentes a cada uma das regras. A Ilustração 14 representa esta funcionalidade.
Ilustração 14 - Funcionalidade “Seleccionar Regras”
39
5.3.2 Configuração & Apresentação: Apresentação
Relativamente à apresentação de resultados, através do componente C&A, é possível
consultar de variadas formas os resultados das análises de fraude realizadas pela solução de
controlo de fraude. Essas formas baseiam-se em funcionalidades deste componente e são as
seguintes:
Consulta Global de Resultados;
Consulta Detalhada de Resultados;
Nas seguintes sub-secções cada uma destas formas vai ser apresentada
detalhadamente.
5.3.2.1 Apresentação: Consulta Global de Resultados
Esta funcionalidade permite obter informações globais relativas às análises de fraude
efectuadas pelo sistema. Essa informação é compilada num tabela extraída via ficheiro Excel
que pode depois ser facilmente utilizada como “tabela pivot” para obter gráficos e outras
manipulações relevantes dos resultados. Um bom exemplo de como realizar essa acção são os
testes de validação desta solução (1.1), onde a maioria assenta em informação obtida através
desta funcionalidade e posteriormente manipulada como indicado. Ainda em relação à
manipulação à posteriori dos dados obtidos via esta funcionalidade, são apresentadas ao longo
dos testes e nas conclusões deste trabalho sugestões quanto a possíveis formas de manipular
os dados resultantes da análise de fraude.
A Ilustração 15 mostra um exemplo da tabela resultante do uso da funcionalidade aqui
descrita.
Block SizeLoading Time
(miliseconds)
Loading
Time
(minutes)
Processing
Time
(miliseconds)
Processing Time
(minutes)
Total Time
(miliseconds)
Total Time
(minutes)# Fraud
# Not
Fraud# Erros # Rules Rules
1 0 0 2453 0,040883333 2453 0,040883333 0 3 0 3 1-Loading - Check Card Exists;2-Loading - Check Card Type Exsts;3-Loading - Check Card Used while in BlackList
1 0 0 703 0,011716667 703 0,011716667 0 1 0 1 10-Validation - Check Operator Exists
1 0 0 703 0,011716667 703 0,011716667 0 1 0 1 8-Validation - Check Ticket Exists
1 16 0,000266667 2125 0,035416667 2141 0,035683333 0 3 0 3 4-Validation - Check Card Exists;5-Validation - Check Card Type Exsts;6-Validation - Check Card Used while in BlackList
1 0 0 812 0,013533333 812 0,013533333 0 1 0 1 9-Loading - Check Operator Exists
1 0 0 750 0,0125 750 0,0125 0 1 0 1 7-Loading - Check Ticket Exists
5 0 0 3563 0,059383333 3563 0,059383333 0 5 0 1 10-Validation - Check Operator Exists
5 0 0 3531 0,05885 3531 0,05885 0 5 0 1 8-Validation - Check Ticket Exists
5 0 0 3750 0,0625 3750 0,0625 0 5 0 1 9-Loading - Check Operator Exists
5 0 0 3922 0,065366667 3922 0,065366667 0 5 0 1 7-Loading - Check Ticket Exists
5 94 0,001566667 11688 0,1948 11782 0,196366667 0 15 0 3 4-Validation - Check Card Exists;5-Validation - Check Card Type Exsts;6-Validation - Check Card Used while in BlackList
5 79 0,001316667 16250 0,270833333 16329 0,27215 0 15 0 3 1-Loading - Check Card Exists;2-Loading - Check Card Type Exsts;3-Loading - Check Card Used while in BlackList
50 0 0 36704 0,611733333 36704 0,611733333 0 50 0 1 9-Loading - Check Operator Exists
50 0 0 36157 0,602616667 36157 0,602616667 0 50 0 1 8-Validation - Check Ticket Exists
50 0 0 36501 0,60835 36501 0,60835 0 50 0 1 10-Validation - Check Operator Exists
50 63 0,00105 109096 1,818266667 109159 1,819316667 0 150 0 3 4-Validation - Check Card Exists;5-Validation - Check Card Type Exsts;6-Validation - Check Card Used while in BlackList
50 0 0 36110 0,601833333 36110 0,601833333 0 50 0 1 7-Loading - Check Ticket Exists
50 156 0,0026 113018 1,883633333 113174 1,886233333 0 150 0 3 1-Loading - Check Card Exists;2-Loading - Check Card Type Exsts;3-Loading - Check Card Used while in BlackList
100 0 0 70970 1,182833333 70970 1,182833333 0 100 0 1 7-Loading - Check Ticket Exists
100 0 0 72096 1,2016 72096 1,2016 0 100 0 1 9-Loading - Check Operator Exists
100 0 0 75407 1,256783333 75407 1,256783333 0 100 0 1 8-Validation - Check Ticket Exists
Ilustração 15 - Funcionalidade “Consulta Global de Resultados”
É possível constatar que os campos extraídos desta análise são os seguintes:
Tamanho do Bloco de Processamento – Corresponde à dimensão da amostra
que foi processada;
Tempo de carregamento da amostra, em milissegundos;
40
Tempo de carregamento da amostra, em minutos;
Tempo de processamento da amostra, em milissegundos;
Tempo de processamento da amostra, em minutos;
Tempo total de análise, em milissegundos – Corresponde à soma dos tempos de
carregamento e de processamento da amostra, em milissegundos
Tempo total de análise, em minutos – Corresponde à soma dos tempos de
carregamento e de processamento da amostra, em minutos;
Número de Casos Fraudulentos detectados, na amostra em causa;
Número de Casos Não Fraudulentos detectados, na amostra em causa;
Número de Erros de processamento ocorridos, na amostra em causa;
Número de Regras utilizadas na análise da amostra em causa;
Regras utilizadas na análise da amostra em causa.
5.3.2.2 Apresentação: Consulta Detalhada de Resultados
Esta funcionalidade permite obter informações detalhadas relativas às análises de fraude
efectuadas pelo sistema. Essa informação é apresentada transacção a transacção, sendo a
pesquisa da mesma realizada através da conjugação de um ou mais filtros de procura. Os
factores que podem ser utilizados para seleccionar os detalhes a consultar são os seguintes:
Transacção – Identificador da transacção da qual se pretende consultar o
detalhe dos resultados; Este filtro deve ser usado quando, por exemplo, se
efectuou uma análise específica a uma ou mais transacções e queremos
consultar directamente o resultado para essa(s) transacção(ões).
Regra – Identificador da regra da qual se pretende consultar o detalhe dos
resultados; Este filtro deve ser usado quando, por exemplo, se efectuou uma
análise específica com uma determinada regra e queremos consultar
directamente os seus resultados.
Bloco de Processamento – Identificador do bloco de processamento, vulgo
conjunto de dados de uma análise concreta, do qual se pretende consultar o
detalhe dos resultados.
Estado – Representa os possíveis estados atribuídos a uma transacção, em
relação a uma regra, no término de uma análise; Permite seleccionar, por
exemplo, todas as transacções que foram consideradas fraudulentas; Se, por
exemplo, combinado com um identificador de uma regra poderia possibilitar a
consulta de todas as transacções que foram classificadas como fraudulentas em
relação à regra em questão.
Datas de Processamento – Representa o intervalo de datas nas quais foram
efectuadas as análises cujos resultados se vão consultar. Possibilita, por
exemplo, consultar os resultados de todas as análises realizadas durante um
determinado dia, semana ou mês do ano.
41
Datas de Transacções – Representa o intervalo de datas das transacções
analisadas13. Possibilita, por exemplo, consultar os resultados de todas as
análises realizadas a transacções de um determinado dia, semana ou mês do
ano.
Resultados por página – Representa o nº de resultados que vão ser
apresentados por cada página, sendo o seu valor inicial o correspondente ao
definido na constante “FRAUD_PAGE_SIZE” (Tabela 3).
Na Ilustração 16 é apresentada a funcionalidade aqui descrita.
Ilustração 16 - Funcionalidade “Consulta Detalhada de Resultados”
Finda a selecção dos filtros de procura, e realizada a mesma, os resultados são
apresentados (Ilustração 17) em forma de tabela e com os seguintes campos:
Estado – Representa o estado atribuído à transacção, em relação a uma regra, no término da análise à transacção em causa;
Transacção – Identificador da transacção analisada;
Nr da Regra – Identificador da regra usada na análise à transacção em causa;
Tempo de Processamento – Representa o tempo de processamento para
análise à transacção em causa;
Nr da Bloco de Processamento – Identificador do Bloco de Processamento ao
qual pertence a análise em causa;
Data de Processamento – Representa a data na qual foi efectuada a análise à
transacção em causa;
13 “Data da transacção” refere-se à data em que uma determinada transacção foi realizada e não a data em que esta foi
registada no sistema central
42
Ilustração 17 – Resultados da funcionalidade “Consulta Global de Resultados”
Adicionalmente, é possível aceder a outro tipo de detalhes, através do ícone , que
são os seguintes:
Consulta dos Dados da Transacção;
Consulta dos Dados da Regra;
Consulta dos Dados do Bloco de Processamento14;
5.3.2.2.1 Apresentação: Consulta dos Dados da Transacção
Esta funcionalidade permite aceder aos detalhes de uma determinada transacção. Esses
detalhes são apresentados em duas secções distintas:
Dados Genéricos – São apresentados o identificador da transacção em questão, a
data e tipo da transacção e o estado global que lhe é atribuído tendo em consideração
os resultados apresentados na secção “Informação das Regras”. Os estados globais
possíveis são:
o Possível Fraude – Se todos os resultados da secção “Informação das Regras”
estiverem no estado Fraude;
o Possível Não Fraude – Se todos os resultados da secção “Informação das
Regras” estiverem no estado Não Fraude;
14 Bloco de Processamento – Refere-se ao conjunto de transacções analisadas durante uma análise de fraude.
43
o Resultados Não Conclusivos – Se os resultados da secção “Informação das
Regras” apresentarem valores distintos (Por exemplo, duas Fraudes e uma
Não Fraude);
o Não Foi Processada Correctamente – Se todos os resultados da secção
“Informação das Regras” estiverem no estado Não Processada;
Informação das Regras – São apresentados os resultados da análise em relação a
cada uma das regras que foram aplicadas à transacção em questão. A informação
apresentada é a seguinte:
o Estado – Representa o estado atribuído à transacção, em relação a uma regra,
no término da análise à transacção em causa;
o Razão do Estado – Representa a razão que levou ao estado atribuído;
o Nome da Regra – Representa a nome da regra usada na análise;
o Tempo de Processamento – Representa o tempo processamento para análise
à transacção em causa;
o Bloco de Processamento – Identificador do bloco de processamento ao qual
pertence a análise em causa;
o Há ainda a possibilidade de consultar detalhes específicos da Regra ou Bloco
de Processamento em causa. Esses detalhes podem ser acedidos,
respectivamente, através das seguintes funcionalidades:
Consulta dos Dados da Regra;
Consulta dos Dados do Bloco de Processamento;
Nesta funcionalidade é ainda possível realizar uma análise de fraude somente para a
transacção em análise, sendo utilizadas as regras que estejam activas no sistema no momento
desse pedido. Para proceder a essa análise basta utilizar o botão “Processar”,
.
A Ilustração 18 representa a funcionalidade aqui descrita:
44
Ilustração 18 – Funcionalidade “Consulta dos Dados da Transacção”
5.3.2.2.2 Apresentação: Consulta dos Dados da Regra
Esta funcionalidade permite aceder aos detalhes de uma determinada regra. Esses
detalhes são apresentados em duas secções distintas:
Dados Genéricos – É apresentada a informação genérica referente à regra em
questão. A informação apresentada é a seguinte:
o Nr da Regra – É o identificador da regra;
o Nome da Regra
o Activa Individualmente – Indica se a regra está activa, ou não, individualmente;
o Activa como Grupo – Indica se a regra está activa, ou não, como parte de um
grupo de regras
o Tipo de Regra
o Grupo – É o identificador do grupo de regras ao qual a regra pertence;
o Prioridade – É o Nível de Prioridade associado à Regra ;
o Regra em LMR – É a definição da regra na Linguagem do Motor de Regras
(LMR);
Resultados de Fraude – São apresentados os resultados da análise de fraude em
relação à regra em questão. A informação apresentada é a seguinte:
o Número de Fraude – Apresenta o total de transacções que ficaram no estado
“Fraude” após analisadas pela regra em questão;
45
o “Número de Não Fraude – Apresenta o total de transacções que ficaram no
estado “Não Fraude” após analisadas pela Regra em questão;
o Número de Não Processadas – Apresenta o total de transacções que ficaram
no estado “Não Processada” após analisadas pela regra em questão;
o Há ainda a possibilidade de consultar os resultados específicos para cada um
dos valores apresentados nesta secção. Essa consulta é realizada através do
ícone , que conduz o utilizador aos resultados da funcionalidade “Consulta
Detalhada de Resultados” (5.3.2.2) com o identificador da regra em questão
utilizado como filtro na pesquisa.
A Ilustração 19 representa a funcionalidade aqui descrita:
Ilustração 19 – Funcionalidade “Consulta dos Dados da Regra”
5.3.2.2.3 Apresentação: Consulta dos Dados do Bloco de Processamento
Esta funcionalidade permite aceder aos detalhes de um determinado bloco de
processamento. Esses detalhes são apresentados em duas secções distintas:
Dados Genéricos – É apresentada a informação genérica referente ao bloco de
processamento em questão. A informação apresentada é a seguinte:
o Nr Bloco de Processamento – É o identificador do bloco de processamento;
o Nr de Transacções – É o tamanho do bloco do processamento, isto é, o
conjunto de transacções que foram analisadas;
46
o Nr de Regras – É o indicador no número de regras que foram utilizadas para
analisar as regras constituintes do bloco de processamento em questão;
o Tempo de Carregamento – Representa o tempo carregamento da amostra de
dados, isto é, o tempo que demora a colocar em memória os identificadores
das transacções constituintes do bloco de processamento em causa;
o Tempo de Processamento – Representa o tempo processamento para análise
do bloco de processamento em causa;
Resultados de Fraude – São apresentados os resultados da análise de fraude em
relação ao bloco de processamento em questão. A informação apresentada é a
seguinte:
o Número de Fraude – Apresenta o total de transacções, pertencentes ao bloco
em causa, que ficaram no estado “Fraude”;
o “Número de Não Fraude – Apresenta o total de transacções, pertencentes ao
bloco em causa, que ficaram no estado “Não Fraude”;
o Há ainda a possibilidade de consultar os resultados específicos para cada um
dos valores apresentados nesta secção. Essa consulta é realizada através do
ícone , que conduz o utilizador aos resultados da funcionalidade “Consulta
Detalhada de Resultados” (5.3.2.2) com o identificador do bloco de
processamento em questão utilizado como filtro na pesquisa.
A Ilustração 20 representa a funcionalidade aqui descrita:
Ilustração 20 – Funcionalidade “Consulta dos Dados do Bloco de Processamento”
47
5.4 Validação da Solução
A solução anteriormente descrita foi validada através da realização de um conjunto de
testes, aplicados a um conjunto de dados de operadores de transportes. Nalguns desses testes
foram realizadas múltiplas medições, derivadas da manipulação de componentes da solução
proposta, mais concretamente as constantes de fraude descritas em 5.3.1. Esta análise
minuciosa é de extrema importância pois, num contexto de utilização real de uma solução de
controlo de fraude, o volume de dados a analisar será, normalmente, bastante elevado.
Para uma correcta percepção e análise dos resultados obtidos é necessário ter em
conta as seguintes definições:
Tempo de processamento em cache – Corresponde ao tempo que demora a
processar um elemento que já se encontre em cache. Não depende do número de
argumentos desse elemento. Após várias medições chegou-se à conclusão que o
tempo de processamento para um elemento que é 0 (zero) milissegundos.
Tempo mínimo de processamento – Corresponde ao menor tempo possível para
cada um dos elementos de uma regra, ou seja, quando o tempo de processamento do
elemento não é demasiadamente influenciado pelo processamento dos elementos do
argumento. Estas situações são expectáveis quando a maioria dos argumentos de um
determinado elemento já se encontrar em cache, sendo por isso o seu tempo de
processamento muito reduzido.
Tempo máximo de processamento – Corresponde ao maior tempo possível para
cada um dos elementos de uma regra, ou seja, quando nenhum dos argumentos de um
elemento não se encontra em cache.
Tempo médio de processamento – Corresponde ao tempo médio de processamento,
expectável, para cada um dos elementos de uma regra. Este tempo é calculado
através da média de todos os tempos de processamento.
Tempo de registo de resultados – Corresponde ao tempo que demora, em média, a
registar o resultado da análise de uma regra aplicada a uma transacção. Após várias
medições verificou-se que, nas condições proporcionadas pelo ambiente de testes,
este tempo é em média 963 (novecentos e sessenta e três) milissegundos.15
É importante referir que o ambiente de testes utilizado foi o seguinte:
Máquina de Desenvolvimento, onde Solução Desenvolvida foi concebida e executada:
o Intel® Pentium® Core 2 Duo - 3.40 GHz
o 4 GB RAM
o Microsoft Windows XP Professional – Service Pack 3
Máquina com a Base de Dados, utilizada pela Solução Desenvolvida e partilhada por
outras aplicações:
15 Média calculada após medições de tempo de registo de resultados para aproximadamente cinquenta mil transacções
48
o Intel® Pentium® 4 - 2.66 GHz
o 1GB RAM
o Microsoft Windows Server 2000 – Service Pack 4
Os testes realizados são apresentados separadamente nas seguintes subsecções, sendo
eles os seguintes:
Cálculo do Tempo de Processamento Individual de cada Elemento
Cálculo do Tempo de Processamento Individual de cada Regra
Análise de Fraude somente para Carregamentos
Análise de Fraude somente para Validações
É ainda fundamental referir que alguns dos valores obtidos podem sofrer influências por
parte de uma variável que não foi totalmente estudada ao longo deste trabalho. Essa variável é
a base de dados, e a ligação à mesma, com a qual a solução desenvolvida comunicava.
Embora os testes tenham sido realizados em horas de menor sobrecarga, na utilização da
base de dados, por vezes existiam picos de actividade que afectavam os tempos de
processamento das regras, bem como, de forma mais drástica, os tempos de registo dos
resultados. O capítulo final é novamente abordado este tema, sendo sugeridas algumas
metodologias para evitar situações similares às aqui mencionadas.
5.4.1 Teste 1 – Cálculo do Tempo de Processamento Individual de cada Elemento
O primeiro teste consistiu na medição dos tempos de processamento menos
significativos de cada uma das regras, isto é, os tempos de processamento individuais dos
elementos de uma regra. Após consolidar os resultados obtidos foram inferidos os tempos
expectáveis para cada uma das regras definidas no MR.
Numa primeira fase deste teste realizou-se um levantamento de todos os elementos
utilizados nas regras pré-configuradas. De seguida, foram medidos os tempos de
processamento para cada um desses elementos, sendo que o número de medições realizado
neste teste foi de aproximadamente mil medições. Esse levantamento, respectivo
escalonamento por quantidade de argumentos e tempos de processamento encontram-se na
seguinte tabela:
49
Elementos Tempos Mínimo de Elementos
(MILISSEGUNDOS)
Tempos Máximo de Elementos
(MILISSEGUNDOS)
ri(7:1;re(6:1;re(1:1;system_item);re(1:2;system_item)); re(1:8;system_item);re(1:8;system_item))
39 837
ri(13:1;re(8:1;system_item);re(8:2;system_item);re(8:8;system_item)) 31 714
ri(9:1;re(1:9;system_item);re(1:10;system_item)) ri(11:1;re(1:3;system_item);re(1:4;system_item)) ri(11:1;re(1:3;system_item);re(1:4;system_item)) re(6:X;re(1:1;system_item);re(1:2;system_item)) ri(9:1;re(8:9;system_item);re(8:10;system_item))
25 313
ri(10:1;re(1:11;system_item)) ri(3:1;re(1:2;system_item)) ri(4:1;re(1:3;system_item)) ri(2:1;re(1:1;system_item) ri(5:1;re(1:4;system_item))
22 230
re(8:X;system_item) re(1:X;system_item) 20 224
Tabela 4 – Tempos de Processamento por Elemento
Na segunda fase deste teste foram determinados os tempos de processamento
esperados para cada uma das regras pré-configuradas na solução desenvolvida. Nesses
cálculos foram sempre utilizados os tempos mínimos de processamento para cada um dos
elementos, calculados na primeira fase deste teste. Os tempos determinados encontram-se
resumidos na Tabela 5:
Regra Tempos de
Regras
1-Loading - Check Card Exists 69
2-Loading - Check Card Type Exsts 44
3-Loading - Check Card Used while in BlackList 39
4-Validation - Check Card Exists 69
5-Validation - Check Card Type Exsts 44
6-Validation - Check Card Used while in BlackList 39
7-Loading - Check Ticket Exists 25
8-Validation - Check Ticket Exists 25
9-Loading - Check Operator Exists 22
10-Validation - Check Operator Exists 22
11-Trip Rule One (Skimming) 81
12-Trip Rule Two (Wrong Usage) 31
Tabela 5 – Tempos de Processamento Calculados para cada Regra
50
5.4.2 Teste 2 – Cálculo do Tempo de Processamento Individual de cada Regra
O segundo teste consistiu na medição dos tempos de processamento de cada uma das
regras. Foram realizadas aproximadamente mil medições e após consolidar os resultados
obtidos foi realizada uma comparação com os tempos inferidos no primeiro teste. Na tabela
seguinte encontram-se enumerados os resultados obtidos neste teste.
Regra Tempos de
Regras
1-Loading - Check Card Exists 31
2-Loading - Check Card Type Exsts 16
3-Loading - Check Card Used while in BlackList 47
4-Validation - Check Card Exists 15
5-Validation - Check Card Type Exsts 15
6-Validation - Check Card Used while in BlackList 47
7-Loading - Check Ticket Exists 16
8-Validation - Check Ticket Exists 16
9-Loading - Check Operator Exists 15
10-Validation - Check Operator Exists 15
11-Trip Rule One (Skimming) 16
12-Trip Rule Two (Wrong Usage) 16
Tabela 6 – Tempos de Processamento por Regra
Por comparação com os valores inferidos no primeiro teste (Tabela 5) pode-se concluir
que os valores aqui estão obtidos são inferiores aos valores expectáveis. Tal discrepância de
valores pode ser explicada com o facto de neste teste os elementos não serem testados
individualmente mas com uma sequência lógica (a das regras). Assim, as possibilidades de um
elemento já existir em cache aquando do seu parsing é muitíssimo mais elevada do que no
teste anterior. E, como os tempos de processamento em cache são nulos, o tempo global de
processamento de uma regra vai ser sempre inferior a um tempo calculado utilizando valores
calculados individualmente.
5.4.3 Teste 3 – Análise de Fraude somente para Carregamentos
O terceiro teste consistiu na realização de múltiplas análises de fraude, para
carregamentos. O facto de estas análises de fraude terem sido somente efectuadas para
carregamentos significa que as únicas regras activas aquando da realização do teste foram
todas as regras destinadas aos carregamentos (mapeamento das regras presente na Tabela 1,
51
em Anexo), numa totalidade de cinco regras. É ainda importante referir que era sempre usada
a mesma amostra para todos as regras (ver constantes de fraude na Tabela 3).
O objectivo deste teste era retirar informações relativas ao tempo de processamento,
tempo de registo de resultados, tempo global de análise da amostra bem como analisar os
resultados respeitantes à quantificação de fraude nas amostras seleccionadas.
Assim sendo, na Tabela 7 são apresentados os valores registados para os tempos de
processamento, de registo de resultados e os tempos globais de análise de fraude, consoante
as dimensões da amostra.
Amostra Tempo de
Processamento (milissegundos)
Tempo de Registo
(milissegundos)
Tempo de Análise
(milissegundos)
1 80 4910 4990
10 705 78050 78755
50 3280 234410 237690
100 5335 470755 476090
500 22420 2727515 2749935
1000 46955 5100415 5147370
5000 203830 25651170 25855000
10000 372085 51560350 51932435
50000 1633289,79 247945025,2 249578315
100000 2766451,975 505963681,3 508730133,3
Tabela 7 – Carregamentos: Tempos de Processamento, de Registo e de Análise
Nos gráficos seguintes é apresentada individualmente a evolução dos tempos de
processamento (Ilustração 21) e dos tempos de registo de resultados (Ilustração 22) e, por fim,
na Ilustração 23 é apresentada uma sobreposição dos gráficos anteriores mais a adição do
tempo global de fraude (resultante da soma entre o tempo de processamento e o tempo de
registo de resultados).
Ilustração 21 – Carregamentos: Tempo de Processamento vs Dimensão da Amostra
52
Ilustração 22 – Carregamentos: Tempo de Registo vs Dimensão da Amostra
Ilustração 23 – Carregamentos: Tempo de Processamento, de Registo e de Análise vs Dimensão da
Amostra
Pela análise da Ilustração 21 e da Ilustração 22 podemos concluir que tanto o tempo de
processamento como o tempo de registo de resultados são lineares, em relação ao tamanho da
amostra (número de transacções a analisar). Analisando os resultados mostrados na Ilustração
23 e na Tabela 7 podemos facilmente concluir que o tempo de processamento é praticamente
irrelevante face ao tempo de registo de resultados. Logo, tendo em conta que o tempo de
registo de resultados é fortemente influenciado pela base de dados utilizada, é plausível afirmar
que com outras condições de teste estes tempos iriam melhorar significativamente.
Em relação aos resultados de fraude, apresentados na Tabela 8, pode-se constatar
que nas cerca de 170000 (cento e sessenta mil) transacções analisadas somente quatro foram
consideradas como fraudulentas, com as regras utilizadas.
As classificações de transacções de carregamento como fraudulentas foram
efectuadas aquando da violação da regra número 6, isto é, quando os cartões foram
carregados enquanto se encontravam colocados em lista negra.
53
Tabela 8 – Resultados de Fraude para Carregamentos
Amostra Regra #
Fraude # Não
Fraude Amostra Regra
# Fraude
# Não Fraude
1
1-Loading - Check Card Exists 0 1 1000
1-Loading - Check Card Exists 0 1000
1
2-Loading - Check Card Type Exsts 0 1 1000
2-Loading - Check Card Type Exsts 0 1000
1
3-Loading - Check Card Used while in
BlackList 0 1 1000
3-Loading - Check Card Used while in
BlackList 0 1000
1
7-Loading - Check Ticket Exists 0 1 1000
7-Loading - Check Ticket Exists 0 1000
1
9-Loading - Check Operator Exists 0 1 1000
9-Loading - Check Operator Exists 0 1000
10
1-Loading - Check Card Exists 0 10 5000
1-Loading - Check Card Exists 0 5000
10
2-Loading - Check Card Type Exsts 0 10 5000
2-Loading - Check Card Type Exsts 0 5000
10
3-Loading - Check Card Used while in
BlackList 0 10 5000
3-Loading - Check Card Used while in
BlackList 0 5000
10
7-Loading - Check Ticket Exists 0 10 5000
7-Loading - Check Ticket Exists 0 5000
10
9-Loading - Check Operator Exists 0 10 5000
9-Loading - Check Operator Exists 0 5000
50
1-Loading - Check Card Exists 0 50 10000
1-Loading - Check Card Exists 0 10000
50
2-Loading - Check Card Type Exsts 0 50 10000
2-Loading - Check Card Type Exsts 0 10000
50
3-Loading - Check Card Used while in
BlackList 0 50 10000
3-Loading - Check Card Used while in
BlackList 4 10000
50
7-Loading - Check Ticket Exists 0 50 10000
7-Loading - Check Ticket Exists 0 10000
50
9-Loading - Check Operator Exists 0 50 10000
9-Loading - Check Operator Exists 0 10000
100
1-Loading - Check Card Exists 0 100 50000
1-Loading - Check Card Exists 0 50000
100
2-Loading - Check Card Type Exsts 0 100 50000
2-Loading - Check Card Type Exsts 0 50000
100
3-Loading - Check Card Used while in
BlackList 0 100 50000
3-Loading - Check Card Used while in
BlackList 0 50000
100
7-Loading - Check Ticket Exists 0 100 50000
7-Loading - Check Ticket Exists 0 50000
100
9-Loading - Check Operator Exists 0 100 50000
9-Loading - Check Operator Exists 0 50000
500
1-Loading - Check Card Exists 0 500 100000
1-Loading - Check Card Exists 0 100000
500
2-Loading - Check Card Type Exsts 0 500 100000
2-Loading - Check Card Type Exsts 0 100000
500
3-Loading - Check Card Used while in
BlackList 0 500 100000
3-Loading - Check Card Used while in
BlackList 0 100000
500
7-Loading - Check Ticket Exists 0 500 100000
7-Loading - Check Ticket Exists 0 100000
500
9-Loading - Check Operator Exists 0 500 100000
9-Loading - Check Operator Exists 0 100000
54
5.4.4 Teste 4 – Análise de Fraude somente para Validações
O quarto, e último, teste consistiu na realização de múltiplas análises de fraude, para
validações. Este teste apresenta duas fases distintas sendo que na primeira fase se realizam
medições idênticas às realizadas no teste anterior (5.4.3) e estando seleccionadas todas regras
de validações (à excepção das regras de viagem, regras 12 e 13 - regras presentes na Tabela
1, em Anexo), numa totalidade de cinco regras. Na segunda fase foram seleccionadas
amostras específicas de dados que correspondiam à selecção de transacções de cartões com
mais do que dez validações num dia.
Assim sendo, na Tabela 9 são apresentados os valores registados para os tempos de
processamento, de registo de resultados e os tempos globais de análise de fraude, consoante
as dimensões da amostra.
Amostra Tempo de
Processamento (milissegundos)
Tempo de Registo
(milissegundos)
Tempo de Análise
(milissegundos)
1 84 5401 5485
10 741 85855 86596
50 3444 257851 261295
100 5602 517830,5 523432,5
500 23541 3000266,5 3023807,5
1000 49303 5610456,5 5659759,5
5000 214022 28216287 28430309
10000 390689 56716385 57107074
50000 1714954 272739527,7 274454481,7
100000 2904775 556560049,4 559464824,4
Tabela 9 – Validações: Tempos de Processamento, de Registo e de Análise
Nos gráficos seguintes é apresentada individualmente a evolução dos tempos de
processamento (Ilustração 24) e dos tempos de registo de resultados (Ilustração 25Ilustração
22) e, por fim, na Ilustração 26 é apresentada uma sobreposição dos gráficos anteriores mais a
adição do tempo global de fraude (resultante da soma entre o tempo de processamento e o
tempo de registo de resultados).
Ilustração 24 – Validações: Tempo de Processamento vs Dimensão da Amostra
55
Ilustração 25 – Validações: Tempo de Registo vs Dimensão da Amostra
Ilustração 26 – Validações: Tempo de Processamento, de Registo e de Análise vs Dimensão da
Amostra
Pela análise dos gráficos presentes na Ilustração 24, na Ilustração 25 e na Ilustração 26 e dos
valores da Tabela 10, podemos retirar as mesmas conclusões que no teste anterior, ou seja,
que o tempo de processamento como o tempo de registo de resultados são lineares, em
relação ao tamanho da amostra (número de transacções a analisar) e que o tempo de
processamento é praticamente irrelevante face ao tempo de registo de resultados.
Em relação aos resultados de fraude, apresentados na Tabela 10, pode-se constatar que nas
cerca de 170000 (cento e sessenta mil) transacções analisadas não foi detectada qualquer
fraude com as regras utilizadas.
56
Amostra Regra #
Fraude # Não
Fraude Amostra Regra
# Fraude
# Não Fraude
1 4-Validation - Check
Card Exists 0 1 1000 4-Validation - Check
Card Exists 0 1000
1 5-Validation - Check
Card Type Exsts 0 1 1000 5-Validation - Check
Card Type Exsts 0 1000
1
6-Validation - Check Card Used while in
BlackList 0 1 1000
6-Validation - Check Card Used while in
BlackList 0 1000
1 8-Validation - Check
Ticket Exists 0 1 1000 8-Validation - Check
Ticket Exists 0 1000
1 10-Validation - Check
Operator Exists 0 1 1000 10-Validation - Check
Operator Exists 0 1000
10 4-Validation - Check
Card Exists 0 10 5000 4-Validation - Check
Card Exists 0 5000
10 5-Validation - Check
Card Type Exsts 0 10 5000 5-Validation - Check
Card Type Exsts 0 5000
10
6-Validation - Check Card Used while in
BlackList 0 10 5000
6-Validation - Check Card Used while in
BlackList 0 5000
10 8-Validation - Check
Ticket Exists 0 10 5000 8-Validation - Check
Ticket Exists 0 5000
10 10-Validation - Check
Operator Exists 0 10 5000 10-Validation - Check
Operator Exists 0 5000
50 4-Validation - Check
Card Exists 0 50 10000 4-Validation - Check
Card Exists 0 10000
50 5-Validation - Check
Card Type Exsts 0 50 10000 5-Validation - Check
Card Type Exsts 0 10000
50
6-Validation - Check Card Used while in
BlackList 0 50 10000
6-Validation - Check Card Used while in
BlackList 0 10000
50 8-Validation - Check
Ticket Exists 0 50 10000 8-Validation - Check
Ticket Exists 0 10000
50 10-Validation - Check
Operator Exists 0 50 10000 10-Validation - Check
Operator Exists 0 10000
100 4-Validation - Check
Card Exists 0 100 50000 4-Validation - Check
Card Exists 0 50000
100 5-Validation - Check
Card Type Exsts 0 100 50000 5-Validation - Check
Card Type Exsts 0 50000
100
6-Validation - Check Card Used while in
BlackList 0 100 50000
6-Validation - Check Card Used while in
BlackList 0 50000
100 8-Validation - Check
Ticket Exists 0 100 50000 8-Validation - Check
Ticket Exists 0 50000
100 10-Validation - Check
Operator Exists 0 100 50000 10-Validation - Check
Operator Exists 0 50000
500 4-Validation - Check
Card Exists 0 500 100000 4-Validation - Check
Card Exists 0 100000
500 5-Validation - Check
Card Type Exsts 0 500 100000 5-Validation - Check
Card Type Exsts 0 100000
500
6-Validation - Check Card Used while in
BlackList 0 500 100000
6-Validation - Check Card Used while in
BlackList 0 100000
500 8-Validation - Check
Ticket Exists 0 500 100000 8-Validation - Check
Ticket Exists 0 100000
500 10-Validation - Check
Operator Exists 0 500 100000 10-Validation - Check
Operator Exists 0 100000
Tabela 10 – Resultados de Fraude para Validações
57
Para a segunda fase deste teste foram seleccionadas duas amostras de dados,
pertencentes a dias distintos, que foram as seguintes:
447 Transacções que correspondiam a cartões que tivessem mais do que quinze
validações no mesmo dia.
364 Transacções que correspondiam a cartões que tivessem mais do que dez
validações no mesmo dia.
Estas transacções de validação foram analisadas com o intuito de detectar situações
fraudulentas do tipo de skimming e sequências de uso de um cartão de forma pouco comum.
Os resultados obtidos nessas análises encontram-se na Tabela 11, apresentada de seguida.
Amostra Regra #
Fraude # Não
Fraude Amostra Regra #
Fraude
# Não Fraude
447 11-Trip Rule One
(Skimming) 275 172 364 11-Trip Rule One
(Skimming) 126 238
447 12-Trip Rule Two (Wrong Usage) 304 143 364
12-Trip Rule Two (Wrong Usage) 135 229
Tabela 11 – Resultados de Fraude para Regras de Viagem I
Nestes resultados podemos concluir que em ambas as amostras foram detectadas várias
transacções fraudulentas. Quando se aprofundou o porquê de tamanha quantidade de fraude
detectada verificou-se que a primeira amostra seleccionada correspondia a cartões de
trabalhadores do operador de transporte que, por norma, estão a auxiliar pessoas que tenham
alguma dificuldade ou problema a aceder à rede de transportes através da passagem pelas
gates. Nestes casos é “normal” que sejam detectadas múltiplas entradas e múltiplas saídas, ou
mesmo entradas e saída consecutivas para o mesmo cartão. Já a segunda amostra
apresentava dados semelhantes aos da primeira mas também um conjunto elevado de
transacções pertencentes a utilizadores normais da rede de transportes, daí os resultados de
fraude já não serem tão elevados nesta amostra.
Um factor muito importante para a obtenção destas classificações foi os valores utilizados para
servir de base para a medição do tempo esperado de uma viagem entre duas estações, do
operador ao qual os dados pertencem. Esses valores de viagens encontram-se mapeados na
tabela STOPS_DISTANCE, 5.1 acima, que foi preenchida com valores reais retirados do simulador
de viagens do operador de transportes em questão. Há ainda outra constante da qual
dependeram os resultados dessa análise que é a constante que define o tempo mínimo que
deve durar uma viagem na mesma estação do operador. Essa constante denomina-se
MINIMUM_TRIP_TIME (Tabela 3) e o valor usado para obter estes resultados foi de 30000 (trinta
mil) milissegundos. Para clarificar melhor o efeito que a alteração desta constante pode ter
numa análise de fraude realizou-se uma alteração da mesma para 15000 (quinze mil)
milissegundos e repetiram-se as medições anteriormente efectuadas (Tabela 12).
58
Amostra Regra #
Fraude # Não
Fraude Amostra Regra #
Fraude
# Não Fraude
447 11-Trip Rule One
(Skimming) 110 337 364 11-Trip Rule One
(Skimming) 50 314
447 12-Trip Rule Two (Wrong Usage) 122 325 364
12-Trip Rule Two (Wrong Usage) 54 310
Tabela 12 – Resultados de Fraude para Regras de Viagem II
Nestes novos resultados pode-se observar que os números de fraude diminuíram
significativamente, em aproximadamente 40%. Destas duas últimas experiências é plausível
afirmar que uma correcta afinação das constantes que influenciam a análise de fraude é
essencial para conseguir obter resultados o mais ajustados possível a cada situação.
59
6 Conclusões e Trabalho Futuro
Como inicialmente referido, fraude existe e irá sempre existir, sendo, portanto, necessário
um combate eficiente da mesma. Esses meios anti-fraude podem ser variados, dependendo
das situações a que se aplicam.
Através do estudo realizado, tanto a nível das soluções para combater o problema
identificado a nível dos transportes públicos, como depois mais tarde em áreas semelhantes,
cartões de crédito, conseguiu-se identificar uma metodologia padrão para prevenir e detectar
fraude. Essa metodologia reside numa etapa inicial de prevenção onde se usam regras de
prevenção de fraude. Numa fase posterior, é aplicado um método de análise às transacções
donde vai resultar uma afirmação sobre o facto de a transacção em análise representar um
acto fraudulento ou não. Das regras de decisão, ficámos a saber que, por norma, resultam do
conhecimento prévio do sistema (ou de quem gere o sistema), devendo, por isso, ser
configuradas de acordo com as situações a detectar. Em relação ao método de análise,
verificou-se a utilização usual de um de dois métodos, Redes Neuronais ou Redes Bayseanas.
Em relação a estes métodos verificou-se que a escolha da sua utilização poderia residir no
facto de um dos sistemas (RBs) ser utilizado, nomeadamente, para quantidades de dados
relativamente reduzidas (ordem dos milhares de transacções), enquanto que o outro (RNs)
será o ideal para quantidades de dados mais elevados (acima das dezenas de milhar). Outro
factor distintivo, que influencia a escolha do método de análise a utilizar, é o tempo de
aprendizagem do método. Foram apresentados os vários paradigmas de aprendizagem
existentes neste tipo de análise, e em qual/quais destes paradigmas se enquadra cada um dos
métodos anteriormente referidos. Constatou-se que as RNs apresentam tempos de
aprendizagem superiores às RBs, visto na primeira essa aprendizagem ser, geralmente,
realizada por meio de um algoritmo de propagação do erro e, como tal, as alterações têm de
ser propagadas à totalidade da rede. Por outro lado, as RBs apresentam tempos de
aprendizagem relativamente mais rápidos, pois a aprendizagem pode ser realizada
individualmente (por exemplo com recurso a processos de decisão markovianos), não
havendo, assim, necessidade de esperar que toda a rede tenha sido actualizada.
Com base neste estudo projectou-se uma solução que, de forma eficaz, seja responsável
pela redução da fraude nos transportes públicos. Essa solução deverá ser composta por um
motor de regras, responsável pela etapa de prevenção de fraude, um componente de análise,
onde os métodos estudados são aplicados conjuntamente para uma detecção ideal de fraude,
e por um componente que permite ao utilizador aceder aos resultados da prevenção e
detecção de fraude assim como configurar o sistema. Tendo em conta a dimensão da solução
proposta e considerando o tempo disponível para conceder um protótipo o MA não foi
implementado e, para conseguir obter quantificações de fraude, o MR sofreu algumas
alterações mas, apesar disso, foi desenvolvida uma solução capaz de realizar análises de
fraude.
60
Essa solução foi validada (5.4) através da realização de análises de fraude a dados reais
de operadores de transportes e dos resultados provenientes dessa validação foi possível retirar
algumas conclusões essenciais para este trabalho, bem como algumas indicações sobre o
trabalho futuro a desenvolver.
6.1 Conclusões
Dos testes realizados (5.4) como forma de validação da solução podemos elencar as
seguintes conclusões:
O tempo global de análise de fraude é mais influenciado pelo tempo de registo de
resultados do que pelo tempo de processamento. Podemos então concluir que com uma
melhor configuração de testes, a nível da base de dados e na ligação à mesma, é plausível
esperar melhorias significativas no tempo de registo de resultados e consequentemente
melhorias no tempo global de análise de fraude. É importante salientar que estas conclusões
só dizem respeito aos tipos de fraude testados durante o processo de validação, pelo que não
é correcto assumir o mesmo comportamento para todos os tipos de fraude.
O tempo global de análise de fraude é linearmente proporcional ao tamanho da
amostra analisada e ao número de regras utilizadas. Podemos concluir que devido aos tempos
demasiado elevados para analisar amostra de grande dimensão16 é aconselhada a realização
de análises a amostras mais reduzidas e mais significativas.
Isto é, devem ser realizadas análises periódicas e sobre dados sobre os quais já exista
alguma suspeita de fraude. Por exemplo, se há mais de vinte validações no mesmo dia para o
mesmo cartão, essas validações (dados) são suspeitas de fraude.
A escolha das regras a analisar também será um factor importante a ter em
consideração nessas análises devendo por isso serem somente seleccionadas regras que
aparentem ser as mais relevantes para a análise em questão.
A dimensão de amostra aconselhada para cinco regras é de dez mil transacções, visto
ser espectável que com uma melhor configuração, nomeadamente uma melhor máquina e
acesso de base de dados, uma análise deste género deve ser inferior a 7 horas, possibilitando
assim a realização de análises sem afectar em demasia os sistemas centrais dos operadores.
Tendo em consideração todos os aspectos até agora mencionados nestas conclusões, é
pertinente referir que idealmente as análises de fraude devem ser realizadas num período de
menos sobrecarga do sistema e, se possível, o mais isoladas do sistema central dos
operadores quanto possível.
Uma correcta manipulação das constantes de fraude é essencial para obter resultados
plausíveis.
16 Por grande dimensão consideram-se amostras superiores a cem mil transacções.
61
É de extrema importância relembrar que sempre que os resultados de fraude, para uma
transacção em particular, causem dúvidas no responsável de fraude que os vai validar este
deve repetir as análises através da funcionalidade “Processar”, descrita na secção 5.3.2.2.1.
Esta funcionalidade é de elevada relevância no controlo de falsos positivos.
6.2 Trabalho Futuro
Embora deste trabalho tenham resultado contributos importantes que possibilitam uma
melhor compressão da problemática da fraude nos transportes públicos e a respectiva acção
correctiva, há ainda alguns aspectos a serem desenvolvidos no futuro. Esses
desenvolvimentos futuros são os seguintes:
Melhorar o componente C&A nos seguintes pontos:
o Possibilitar a criação a elementos de regras;
o Possibilitar a edição de regras;
o Possibilitar a criação de regras;
o Criar alarmes de fraude;
o Criar gráficos de fraude automaticamente.
Permitir o agendamento de análises de fraude. O protótipo desenvolvido iniciava
diariamente análises contudo seria interessante poder planear análises com
antecedência. Um exemplo deste planeamento seria agendar para o início da
semana uma análise a um determinado número de transacções e com um grupo
específico de regras e durante o fim-de-semana seleccionar “automaticamente”
mais regras e analisar um número diferente de transacções.
Implementar o componente MA e procurar um funcionamento do mesmo em
sintonia com o MR.
Integrar a solução desenvolvida num sistema central de um operador de
transportes e ajustar as regras à realidade desse operador.
62
7 Referências
[1] Porto Editora (Agosto de 2008), “Dicionário Editora da Língua Portuguesa 2009 –
Acordo Ortográfico”, ISBN-13: 978-972-0-01423-8. [2] Konstantinos Markantonakis, Keith Mayes, "Smart Card Technology in the Public
Transport Industry”, Secure Magazine - The Silicon Trust Report, Fevereiro de 2004.
[3] Noreen McDonald, "Multipurpose Smart Cards in Transportation: Benefits and Barriers
to Use", 8 de Dezembro de 2000.
[4] Gloger, Marcus. “Check In - Be Out, a breakthrough in electronic ticketing with
automatic passenger detection during the trip.” In: UITP World Congress, 56th. Junho,
2005, Roma. Public Transport 2020 Making the Connection People –Environment –
Business.
[5] Spirtech, “Fraud Detector – Ticketing System Supervision”, 2006.
[6] Neural Technologies, “Minotaur™ Fraud Management”.
[7] Neural Technologies, “Minotaur™ FMS Unique Benefits”.
[8] Alaric, “Fractals, Adaptive Solutions to Hi-tech Financial Crime”, 2007.
[9] Alaric, “Fractals, Adaptive Classification Engine”, 2007.
[10] Christopher M. Bishop, “Neural Networks, ACM Comput Surv” 28(1): 73-75, 1996.R.
Brause, T.Langsdorf, M. Hepp, “Neural Data Mining for Credit Card Fraud Detection”,
1999.
[11] I. Ben-Gal, “Bayesian Networks”, 2007.
[12] Zoubin Ghahramani, “Learning Dynamic Bayesian Networks”, Outubro de 1997.
[13] Alaric, ”Card Fraud Detection, Comparison of detection technologies”,2007 .
[14] S. Maes, K. Tuyls, B. Vanschoenwinkel “Machine Learning Techniques for Fraud
Detection”, 2000.
[15] Jaime Carbonell ,”Artificial Intelligence -- 15-381 Unsupervised Machine Learning
Methods”, 4 de Abril de 2000.
[16] Fu Wai-Tat, John R. Anderson, "From Recurrent Choice to Skill Learning: A
Reinforcement-Learning Model", 2006.
[17] Richard S. Sutton, Andrew G. Barto, “Reinforcement Learning: An Introduction”, MIT
Press, Cambridge, Massachusetts, 1998.
[18] C. Derman, “Finite State Markov Decision Process”, Academic Press, New York, 1970.
[19] S. B. Kotsiantis, “Supervised Machine Learning: A Review of Classification
Techniques”, 16 de Julho de 2007.
[20] Sykes, A.O. "An Introduction to Regression Analysis", Outubro 1993.
63
Anexos Tabela 1 – Mapeamento dos Tipos de Fraude ao Modelo de Regras
Tipos de Fraude Características Modelo de Regras
Skimming
"Viagens" simultâneas Regra 11 "Trip Rule One (Skimming)" [ri(13:1;re(8:1;system_item);re(8:2;system_item);re(8:8;system_item))] TRUE R(14) FALSE false
Regra 14 "Regra Auxiliar para Tempos de Viagens"
[[rd(8:8;system_item) - rd(8:8;re(13:1;re(8:1;system_item);re(8:2;system_item);re(8:8;system_item)))] < SD(re(8:13;system_item)|re(8:13;re(13:1;re(8:1;system_item);re(8:2;system_item);re(8:8;system_item))))] TRUE
true FALSE false
"Viagens" seguidas com tempos inexequíveis
Tempo de "Viagem" inexequível
Validação e carregamento de
um cartão desconhecido
Cartão não registado no sistema é utilizado nas
máquinas de carregamento
Regra 1 "Loading - Check Card Exists" [[ri(2:1;re(1:1;system_item)) && ri(3:1;re(1:2;system_item))] || [ri(11:1;re(1:3;system_item);re(1:4;system_item))]]
TRUE false FALSE true
Cartão não registado no sistema é utilizado nos
postos de validação
Regra 4 "Validation - Check Card Exists" [[ri(2:1;re(8:1;system_item)) && ri(3:1;re(8:2;system_item))] || [ri(11:1;re(8:3;system_item);re(8:4;system_item))]]
TRUE false FALSE true
Validação e carregamento de um cartão inválido
Carregamento de Cartão que apresenta dados
diferentes dos registados na BD central
Regra 2 "Loading - Check Card Type Exsts" [ri(4:1;re(1:3;system_item)) && ri(5:1;re(1:4;system_item))] TRUE false FALSE true
Carregamento Cartão presente em LN
Regra 3 "Loading - Check Card Used while in BlackList" [ri(7:1;re(6:1;re(1:1;system_item);re(1:2;system_item));re(1:8;system_item);re(1:8;system_item))]
TRUE true FALSE false
Validação de Cartão que apresenta dados
diferentes dos registados na BD central
Regra 5 "Validation - Check Card Type Exsts" [ri(4:1;re(8:3;system_item)) && ri(5:1;re(8:4;system_item))] TRUE false FALSE true
Validação Cartão presente em LN
Regra 6 "Validation - Check Card Used while in BlackList" [ri(7:1;re(6:1;re(8:1;system_item);re(8:2;system_item));re(8:8;system_item);re(8:8;system_item))]
TRUE true FALSE false
64
Validação de um contrato ou perfil
desconhecido
Cartão carregado com contrato desconhecido
Regra 7 "Loading - Check Ticket Exists" [ri(9:1;re(1:9;system_item);re(1:10;system_item))] TRUE false FALSE true
Cartão com perfil desconhecido
–
Validação de Cartão com contrato desconhecido
Regra 8 "Validation - Check Ticket Exists" [ri(9:1;re(8:9;system_item);re(8:10;system_item))] TRUE false FALSE true
Carregamentos e Validações com equipamentos desconhecidos
Contratos não foram carregados no cartão por um equipamento de um
operador conhecido
Regra 9 "Loading - Check Operator Exists" [ri(10:1;re(1:11;system_item))] TRUE false FALSE true
Cartões não foram validados por um
equipamento de um operador conhecido
Regra 10 "Validation - Check Operator Exists" [ri(10:1;re(8:11;system_item))] TRUE false FALSE true
Sequência de uso de um cartão de
forma pouco comum
Entradas consecutivas
Regra 12 "Trip Rule Two (Wrong Usage)" [[re(8:12;system_item) == 1] && [re(8:12;re(13:1;re(8:1;system_item);re(8:2;system_item);re(8:8;system_item))) == 4]]
TRUE R(14) FALSE R(13)
Regra 13 "Trip Rule (Wrong Usage) Aux I" [[re(8:12;system_item) == 4] && [re(8:12;re(13:1;re(8:1;system_item);re(8:2;system_item);re(8:8;system_item))) == 1]]
TRUE R(14) FALSE true
Regra 14 " Regra Auxiliar para Tempos de Viagens" [[rd(8:8;system_item) - rd(8:8;re(13:1;re(8:1;system_item);re(8:2;system_item);re(8:8;system_item)))] <
SD(re(8:13;system_item)|re(8:13;re(13:1;re(8:1;system_item);re(8:2;system_item);re(8:8;system_item))))] TRUE true FALSE false
Saídas consecutivas
Pares entrada saída consecutivos
65
Tabela 2 –Elementos presentes na tabela RULE_ELEMENTS
Identificador do Elemento
Query SQL do Elemento
1
select CARD_SERIAL_NR,CARD_NR,CARD_DATA_MODEL_ID,CARD_PHYSICAL_TYPE_ID,
TICK_RELO_DATE,TICK_RELO_MACH_CODE,TICK_RELO_NUMB_DAILY, TRANSACTION_DATE,TICK_CODE,TICK_OPER_CODE,LOAD_OPER from
transactions_rl where TRANSACTION_ID = ?
2 select SERIAL_NR from CARDS where SERIAL_NR = ?
3
select CARD_NUMB_ISSU_ENVI_APPL_ISSU||LPAD(CARD_NUMB_ISSU_CARD_NR,9,'0')
from cards where CARD_NUMB_ISSU_ENVI_APPL_ISSU||LPAD(CARD_NUMB_ISSU_CARD_NR,9,'0') =
?
4 select CARD_MODEL_TYPE_ID from CARD_MODEL_TYPES where
CARD_MODEL_TYPE_ID = ?
5 select CARD_TECK_TYPE_ID from CARD_TECK_TYPES where
CARD_TECK_TYPE_ID = ?
6 select CARD_ID from CARDS where SERIAL_NR = ? and
CARD_NUMB_ISSU_ENVI_APPL_ISSU||LPAD(CARD_NUMB_ISSU_CARD_NR,9,'0') = ?
7
select system_item_id from list_items where list_item_type_id = 1 and list_item_state_id = 1 and list_id = 1 and system_item_id = ?
and to_char(validity_start_date, 'YYYY-MM-DD HH24:MI:SS') <= ? and ? <= to_char(validity_end_date, 'YYYY-MM-DD HH24:MI:SS')
8
select CARD_SERIAL_NR,CARD_NR,CARD_DATA_MODEL_ID,CARD_PHYSICAL_TYPE_ID,
TICK_RELO_DATE,TICK_RELO_MACH_CODE,TICK_RELO_NUMB_DAILY, VALIDATION_DATE,TICK_CODE,TICK_OPER_CODE,EVENT_OPER, VALIDATION_TYPE_ID,STOP_INDEX_CODE from validations_rl where
VALIDATION_ID = ?
9 select ticket_id from tickets where tick_code = ? and tick_oper_code = ?
10 select entity_id from entities where entity_code = ?
11 select card_type_id from card_types where CARD_MODEL_TYPE_ID = ? and
CARD_TECK_TYPE_ID = ? and card_type_id in (2,4,5)
13 select validation_id from (select validation_id from validations_rl where card_serial_nr = ? and card_nr = ? and to_char(validation_date, 'YYYY-MM-DD HH24:MI:SS') < ? ORDER
BY validation_date DESC) where rownum = 1
