Escola de Engenharia - Universidade do Minho · Outubro de 2010 Universidade do Minho Escola de...
218
Outubro de 2010 Universidade do Minho Escola de Engenharia João Batista da Costa Lopes Utilização de Técnicas de Profiling na Detecção de Fraude em Sistemas de Telecomunicações UMinho|2010 João Batista da Costa Lopes Utilização de Técnicas de Profiling na Detecção de Fraude em Sistemas de Telecomunicações
Transcript of Escola de Engenharia - Universidade do Minho · Outubro de 2010 Universidade do Minho Escola de...
Outubro de 2010
Universidade do MinhoEscola de Engenharia
João Batista da Costa Lopes
Utilização de Técnicas de Profiling na Detecção de Fraude em Sistemas de Telecomunicações
UM
inho
|201
0Jo
ão B
atis
ta d
a C
osta
Lop
esU
tili
zaçã
o d
e T
écn
ica
s d
e P
rofi
lin
g n
a D
ete
cçã
o
de
Fra
ud
e e
m S
iste
ma
s d
e T
ele
com
un
ica
çõe
s
Dissertação de MestradoMestrado em Informática
Trabalho efectuado sob a orientação doProfessor Doutor Orlando Manuel de Oliveira Belo
Outubro de 2010
Universidade do MinhoEscola de Engenharia
João Batista da Costa Lopes
Utilização de Técnicas de Profiling na Detecção de Fraude em Sistemas de Telecomunicações
É AUTORIZADA A REPRODUÇÃO PARCIAL DESTA DISSERTAÇÃO APENAS PARA EFEITOSDE INVESTIGAÇÃO, MEDIANTE DECLARAÇÃO ESCRITA DO INTERESSADO, QUE A TAL SECOMPROMETE;
Universidade do Minho, ___/___/______
Assinatura: ________________________________________________
i
A todos aqueles que sempre confiaram em mim...
ii
iii
Agradecimentos
Um trabalho como este é o resultado de empenhamento, concentração, conhecimentos e vivências
adquiridas ao longo de uma vida. É resultado, também, de conselhos, acompanhamento e estímulo de
docentes e colegas. Não é uma realização cujo mérito seja de apenas de uma só pessoa.
Quero, por isso, agradecer em primeiro lugar a todo o Departamento de Informática da Universidade
do Minho, em especial ao corpo docente do Mestrado de Informática, pelos conhecimentos que me
transmitiram, e pelo exemplo de competência e excelência.
O meu profundo e sentido agradecimento às empresas PT Inovação e TelBit por me terem dado a
oportunidade de trabalhar num projecto tão interessante, e com grande relevância na área de
sistemas de telecomunicações.
Agradeço também aos meus orientadores pela atenção e pela ajuda, conselhos e compreensão das
minhas dificuldades, sem nunca descurar o empenho no cumprimento dos objectivos inicialmente
propostos para a dissertação.
Por último, agradeço à minha família e amigos por toda a ajuda que me deram, pela força e por
acreditarem em mim. Muito obrigado a todos.
iv
v
Resumo
Utilização de Técnicas de Profiling na Detecção de Fraude em Sistemas
de Telecomunicações
Com a expansão da tecnologia moderna o fenómeno de fraude cresce dramaticamente, resultando
na perda de biliões de euros todos os anos em todo o mundo. Apesar das técnicas de prevenção
serem uma óptima solução para reduzir a fraude, os criminosos adaptam-se e, com tempo,
normalmente encontram outras formas de contornar tais medidas. Um dos objectivos desta
dissertação é perceber como está a fraude a ser utilizada actualmente contra as organizações e as
limitações dos métodos existentes para detectá-la. Inicialmente é feita uma contextualização da
fraude na área das telecomunicações, pretende-se compreender qual o seu grau de importância e
a necessidade que existe em resolver o problema. São estudados alguns dos tipos de fraude mais
frequentes e as suas diversas formas de actuação. Numa fase posterior, alguns dos métodos de
detecção mais importantes na área de telecomunicações são analisados em detalhe, e são
relatadas algumas das experiências que têm sido feitas com os mesmos. De acordo com a
evolução da fraude nos tempos emergentes, pretende-se escolher a técnica que vai mais de
encontro com as necessidades das organizações. Uma das formas mais eficientes para
acompanhar o comportamento dos clientes e as suas alterações de utilização é através da técnica
de profiling. Esta técnica permite manter um perfil actualizado de cada cliente consoante a sua
utilização diária, qualquer desvio anômalo poderá assim ser detectado. Nesta dissertação foi
implementada a técnica de profiling baseada em assinaturas. Depois de um estudo pormenorizado
das técnicas existentes, esta mostrou ser a mais indicada para o problema em questão. Este
trabalho foi realizado junto de uma operadora móvel de telecomunicações. O protótipo
vi
implementado foi integrado no sistema de gestão de fraude que está actualmente em
funcionamento. A fase de análise e validação de resultados foi feita com recurso a transacções
reais dos seus clientes. O facto de estar junto de uma empresa e conseguir analisar o problema tal
como este decorre no mundo real é uma mais valia para perceber o impacto que o protótipo pode
ter. No final é feita uma retrospectiva de todo o trabalho realizado. O documento termina com um
resumo geral dos resultados obtidos e os próximos passos a realizar num futuro próximo.
vii
Abstract
Use of Profiling Techniques for Fraud Detection in Telecommunications
Systems
Fraud is increasing dramatically with the expansion of modern technology, resulting in the loss of
billions of euros worldwide each year. Although prevention technologies are the best way to reduce
fraud, fraudsters are adaptive and, given time, will usually find ways to circumvent such measures.
One of the objectives of this dissertation is to understand how fraud is being used against
organizations and the limitations of existing methods to detect it. Initially, a contextualization of
fraud in the telecommunications área is done. It seeks to understand the existing importance and
need in solving the problem of fraud. Some of the most common types of fraud and their various
forms of action are studied. At a later stage, some of the most important methods of detection in
the telecommunications area are carefully analyzed, associated experiences that have been made
are also explained. According to the evolution of fraud in the emerging times, it is intended to
choose the technique that better meets the organizations needs. One of the most efficient ways to
track the customers behavior and their usage variations is through the technique of profiling. This
technique allows to maintain an updated profile of each customer depending on their daily usage,
any anomolous deviation can thus be detected. On this dissertation, the technique of profiling
based on signatures was implemented. After studying in detail the existing techniques, this one
proved to be the most appropriate for the problem concerned. This work was done together with a
mobile network operator. The implemented prototype was integrated in the fraud management
system currently in operation. To accomplish the analysis and validation of results stage, samples
of customers transactions were used. Being near a company and having the opportunity to analyze
viii
the problem exactly how it happens in the real world is a surplus value in order to understand the
impact that the prototype may have. In the end a retrospective of all the work is done. The
document ends with an overview of the obtained results and the next steps to do in a near future.
ix
Índice
1 Introdução .................................................................................................................... 1!
1.1! Contextualização ..........................................................................................................1!
1.2! Motivação ....................................................................................................................3!
1.3! Objectivos ...................................................................................................................4!
1.4! Organização do documento...........................................................................................5!
2 Fraude nas Telecomunicações ...................................................................................... 7!
2.1! Possíveis Fraudes .........................................................................................................8!
2.2! Fraude Interna........................................................................................................... 10!
2.3! Fraude Externa .......................................................................................................... 11!
3 Abordagens para a Detecção de Fraude ..................................................................... 13!
3.1! Data Mining ............................................................................................................... 13!
3.2! Perfis de Utilizador ..................................................................................................... 14!
3.3! Técnicas para a Detecção de Fraude............................................................................ 18!
3.3.1! Detecção baseada em Regras ............................................................................... 18!
3.3.2! Detecção baseada em Redes Neuronais ................................................................. 20!
3.3.3! Detecção baseada em Redes Bayesianas ............................................................... 24!
3.3.4! Detecção através de técnicas de Raciocínio baseado em Casos................................ 29!
3.3.5! Detecção baseada em Assinaturas......................................................................... 34!
4 Implementação de Abordagens para a Detecção de Fraude ...................................... 43!
4.1! Um Sistema baseado em Regras e Redes Neuronais ..................................................... 43!
x
4.2! Detecção de Fraude baseada num modelo de Comutação de Regime............................. 47!
4.3! Detecção de Fraude utilizando métodos Neuronais e Probabilísticos ............................... 50!
4.4! Detecção de Fraude utilizando Rede Neuronal Supervisionada ....................................... 55!
4.5! Detecção de anomalias em padrões de utilização baseada em Regras ............................ 56!
4.6! Conclusão e análise das abordagens estudadas ............................................................ 57!
5 Um Sistema para a Detecção de Fraude em Telecomunicações ................................. 61!
5.1! Análise e justificação da viabilidade do projecto............................................................ 61!
5.2! Contextualização do Sistema Centaur .......................................................................... 62!
5.3! Identificação e caracterização dos Perfis dos Utilizadores do Sistema ............................. 68!
5.4! Especificação de Requisitos......................................................................................... 68!
5.5! Descrição Funcional do Sistema................................................................................... 74!
5.6! Design Estrutural........................................................................................................ 77!
6 Problemas Importantes na Implementação do Sistema Protótipo ............................ 83!
6.1! Definição dos Pesos dos Atributos ............................................................................... 83!
6.2! Tuning do Sistema ..................................................................................................... 86!
6.3! Fórmulas utilizadas..................................................................................................... 87!
6.4! Inicialização de Clientes e criação de Modelos de Fraude............................................... 91!
7 Análise e Validação de Potenciais casos de Fraude .................................................. 103!
7.1! Análise Geral de Alarmes .......................................................................................... 103!
7.2! Análise Detalhada de Casos ...................................................................................... 113!
8 Conclusões e Trabalho Futuro................................................................................... 129!
8.1! Comentários Finais ................................................................................................... 129!
8.2! Algumas Orientações para Trabalho Futuro ................................................................ 131!
Bibliografia................................................................................................................... 133!
Referências WWW ....................................................................................................... 139!
Anexo A ........................................................................................................................ 141!
Algoritmo de Processamento .......................................................................................... 141!
Anexo B ........................................................................................................................ 145!
xi
Requisitos de Objectivos de Concepção........................................................................... 145!
Anexo C ........................................................................................................................ 153!
Use Cases ..................................................................................................................... 153!
Anexo D........................................................................................................................ 156!
Diagramas de Actividades .............................................................................................. 156!
Anexo E ........................................................................................................................ 159!
Requisitos de Hardware e Software ................................................................................ 159!
Anexo F ........................................................................................................................ 161!
Modelação Conceptual ................................................................................................... 161!
Anexo G........................................................................................................................ 185!
Modelação Lógica .......................................................................................................... 185!
xii
xiii
Índice de Figuras
Figura 1 - Perdas da fraude na indústria de telecomunicações (Larrañaga, 2009)..........................7!
Figura 2 - Três factores que levam à ocorrência de fraude (Mohay, et al., 2003) ..........................9!
Figura 3 - Três dos mais importantes tipos de fraude e como são aplicados contra as organizações
...................................................................................................................................... 12!
Figura 5 - O modelo é construído assumindo um comportamento (c1), algum desvio em relação ao
comportamento definido é classificado como fraude........................................................... 15!
Figura 4 - Ambos os modelos de comportamento normal (c1) e comportamento fraudulento (c2) 15!
Figura 6 - Ilustração de um neurónio....................................................................................... 22!
Figura 7 - Determinar se o somatório dos pesos associados ao nodo de uma rede neuronal,
multiplicado pelas suas entradas, ultrapassa o limiar definido. ............................................ 23!
Figura 8 - Exemplo de uma estrutura de uma rede bayesiana.................................................... 27!
Figura 9 - Exemplo de migração de clusters ............................................................................. 41!
Figure 10 - Resultado com o conjunto de teste......................................................................... 45!
Figura 11 - Resultado com o conjunto de treino ....................................................................... 46!
Figura 12 - Curvas de ROC para a detecção em tempo real ....................................................... 49!
Figura 13 - Curvas de ROC para a classificação retrospectiva..................................................... 49!
Figura 14 – Experiência com apendizagem supervisionada ........................................................ 51!
Figura 15 - Experiência com aprendizagem não superviosionada ............................................... 53!
Figura 16 – Exemplo de uma rede Bayesiana ........................................................................... 54!
Figura 17 - Experiência com aprendizagem supervisionada combinado com aprendizagem não
supervisionada ................................................................................................................ 55!
Figura 18 - Integração do componente de assinaturas na arquitectura de 3 camadas do Centaur 65!
xiv
Figura 19 - Arquitectura tecnológica do Centaur ....................................................................... 66!
Figura 20 - Fluxo da informação no sistema de detecção Centaur .............................................. 67!
Figura 21 - Exemplo de um caso de uso do sistema protótipo.................................................... 72!
Figura 22 - Exemplo de um diagrama de actividades do sistema protótipo ................................. 73!
Figura 23 - Fluxo de informação dos eventos mais importantes que ocorrem com as assinaturas . 76!
Figura 24 - Diagrama Conceptual ............................................................................................ 78!
Figura 25 - Passos que compõe a transacção A sem redundância .............................................. 81!
Figura 26 - Passos que compõe a transacção A com redundância .............................................. 81!
Figura 27 - Exemplo de parte de um ficheiro ARFF ................................................................... 95!
Figura 28 - Lista de resultados obtidos na criação de classes de Assinaturas no Weka................. 97!
Figura 29 - Parte do código utilizado para obter a informação do histórico de casos de fraude... 101!
Figura 30 - Fluxo da informação durante o processo de criação de modelos de fraude .............. 102!
Figura 31 – Lista de alarmes gerada pelo sistema protótipo..................................................... 106!
Figura 32 – Número de alarmes gerados durante o período de processamento ......................... 108!
Figura 33 – Percentagem de ocorrências de cada atributo durante o período de processamento 109!
Figura 34 – Top 10 dos alarmes ordenados pelo valor de distancia .......................................... 110!
Figura 35 – Valores de distancia nos dias de processamento para o cartão 964042*** ............. 111!
Figura 36 – Distâncias e atributos de maior impacto, em cada dia de processamento, para o cartão
927792*** ................................................................................................................... 112!
Figura 37 – Variação de comportamento do cartão 927010***................................................ 114!
Figura 38 – Variação de comportamento do cartão 961911***................................................ 115!
Figura 39 – Variação de comportamento do cartão 927253***................................................ 116!
Figura 40 – Variação de comportamento do cartão 925971*** em dias úteis ........................... 120!
Figure 41 – Variação de comportamento do cartão 925971*** em fins de semana ................... 120!
Figura 42 – Variação de comportamento do cartão 965173***................................................ 123!
Figura 43 – Variação de comportamento do cartão 926224***................................................ 125!
Figura 44 - Diagrama de Use-Cases: Parâmetros .................................................................... 153!
Figura 45 - Diagrama de Use-Cases: Análise .......................................................................... 154!
Figura 46 - Diagrama de Use-Cases: Exportar ........................................................................ 155!
Figura 47 - Diagrama de Actividades: Parâmetros................................................................... 156!
Figura 48 - Diagrama de Actividades: Análise ......................................................................... 157!
Figura 49 - Diagrama de Actividades: Exportar ....................................................................... 158!
Figura 50 - Diagrama Lógico ................................................................................................. 197!
xv
Índice de Tabelas
Tabela 1 - Resultados para desvios grandes e pequenos no período de teste (Gopal and Meher,
2007) ............................................................................................................................. 57!
Tabela 2 – Tabela de Requisitos.............................................................................................. 69!
Tabela 3 – Exemplo de um requisito do sistema ....................................................................... 71!
Tabela 4 - Resultados antes da desnormalização ...................................................................... 82!
Tabela 5 - Resultados após desnormalização............................................................................ 82!
Tabela 6 – Lista de atributos utilizados para criar as classes de equivalência .............................. 96!
Tabela 7 – Modelos de fraude obtidos no Weka através do algoritmo EM ................................. 102!
Tabela 8 - Tempos de processamento e número de registos diários no período de detecção...... 104!
Tabela 9 – Lista de casos classificados como fraude ............................................................... 105!
Tabela 10 – Tabela com as medidas mais importantes, durante o período de processamento, do
cartão 965873*** ......................................................................................................... 117!
Tabela 11 – Tabela com valores das medidas mais importantes durante o período de
processamento do cartão 926224***.............................................................................. 125!
Tabela 12 – Tabela com valores do sumário do dia 01/07/2010, valores da assinatura associada
(cartão 963015***) e o modelo de assinatura fraudulenta mais próximo do sumário.......... 127!
Tabela 13 – Tabela resumo dos resultados obtidos durante o período de processamento .......... 128!
Tabela 14 – Use Case 1 (Criar as tabelas necessárias para o sistema de detecção baseado em
Assinaturas) .................................................................................................................. 145!
Tabela 15 – Use Case 2 (Inicializar Assinaturas de clientes já existentes) ................................. 145!
Tabela 16 – Use Case 3 (Criar modelos de Assinaturas Fraudulentas) ...................................... 147!
Tabela 17 – Use Case 4 (Criar Classes de clientes com base nas Assinaturas existentes) ........... 148!
xvi
Tabela 18 – Use Case 5 (Transferir os registos necessários das tabelas PUMP_VOICE e PUMP_SMS
para as tabelas LOADING_ASSINATURA) ........................................................................ 148!
Tabela 19 – Use Case 6 (Processar Sumários ) ....................................................................... 151!
Tabela 20 – Use Case 7 (Regularizar Casos Suspeitos)............................................................ 151!
Tabela 21 – Use Case 8 (Actualizar as Classes de Assinaturas) ................................................ 151!
xvii
Acrónimos e Abreviaturas
TI Tecnologias de Informação
SGF Sistema de Gestão de Fraude
KD Knowledge Discovery
CDR Call Detail Record
PABX Private Automatic Branch Exchange
GSM Global System for Mobile Communications
CBR Case Base Reasoning
ROC Receiver Operating Characteristic
AUC Área Under Cover
ETL Extract, Transform and Load
SMS Short Message Service
OLTP Online Transaction Processing
SGBD Sistema Gestor de Base de Dados
SAS Serial Attached SCSI
SATA Serial Advanced Technology Attachment
xviii
QDR Quad Data Rate
IOPS Input/Output Operations Per Second
GUI Graphical User Interface
VPS Virtual Private Server
GPRS General Packet Radio Service
SQL Structured Query Language
PL/SQL Procedural Language/Structured Query Language
DAG Directed Acyclic Graph
CRUD Create, Retrieve, Update and Delete
UML Unified Modeling Language
BD Base de Dados
IMSI International Mobile Subscriber Identity
NIF Número de Identificação Fiscal
Introdução
1
Capítulo 1
1Introdução
1.1 Contextualização
Diariamente lidamos com campanhas de empresas de telecomunicações que anunciam e
promovem novos produtos e serviços. A oferta e a variedade destes produtos é tão grande que
quase sempre lhes prestamos alguma atenção. Em algumas situações seguimos os anúncios e
acabamos por comprar o produto. As estratégias de marketing das empresas de telecomunicações
são muito importantes no processo de sobrevivência num mercado competitivo. O nível tecnológico
e a sofisticação dos produtos têm contribuído de forma significativa para o processo de adopção
ser relativamente fácil. No entanto, nesta área, as coisas não são assim tão simples. Com o
aparecimento de novos produtos e serviços, também surgem novas formas de os utilizar de forma
ilegal. Estamos a lidar com situações típicas de fraude que, obviamente, prejudicam as empresas
de telecomunicações. As perdas são enormes e as empresas precisam de encontrar soluções para
combater o problema. As organizações têm estado bastante activas em adoptar e aplicar novas
tecnologias nos seus serviços mais críticos, desenvolvem novos produtos que contribuem
significativamente para um melhoramento na vida das pessoas. Contudo, as empresas têm sido
confrontadas com situações que comprometem os seus ganhos, os seus resultados provenientes
do investimento, causando a perda de grandes quantidades de receita todos os anos. Estas
situações resultam, quase sempre, da grande diversidade de tipos de fraude que surgem todos os
dias. A fraude é um obstáculo bastante sério quando se pretende assegurar a qualidade dos
Introdução
2
serviços disponibilizados pelas empresas de telecomunicações. Devido à dificuldade crescente que
existe para detectar a fraude, as empresas são forçadas a investir mais, tanto em termos
financeiros como em termos dos seus recursos humanos, de forma a encontrar métodos eficientes
para combater a fraude.
A comunicação tem sido um dos pontos mais importantes no crescimento na nossa cultura e
sociedade. Sem ela muitas coisas seriam impossíveis, as pessoas estariam mais separadas, não
haveria tanta partilha de informação e consequentemente o mundo não seria o mesmo. As
telecomunicações, isto é, a transmissão de sinais sobre uma determinada distância com o
propósito de comunicação, também são bastante importantes. O negócio criado pelas
telecomunicações é crucial para a economia mundial. Fornecem dinheiro e estabilidade no mercado
como um produto de si próprias, criam uma comunidade mais ligada permitindo a partilha de
informação e uma maior capacidade de resposta em certo período de tempo.
A contribuição para a ciência é também um ponto importante a considerar. A investigação e
desenvolvimento na área de telecomunicações tem sido a base para muitas outras tecnologias.
Têm sido feitos muitos melhoramentos na transmissão de ondas de rádio, nas viagens espaciais e
marítimas etc. A possibilidade de enviar informação de um sítio para outro em tempo real tem
permitido à ciência evoluir em áreas onde a monitorização directa ou visível não é possível. O
impacto das telecomunicações no mundo que nos rodeia é evidente. São das principais
responsáveis por o mundo ter crescido tão rápido e ter-se tornado ciente de inúmeras questões. As
telecomunicações promovem uma sociedade mais informada, ajudam no desenvolvimento de
soluções e na construção de suporte para diversos problemas.
De acordo com Boonton (2007), uma investigação feita pelo Insight N.J., prevê-se que a receita
das telecomunicações globais aumente de !1.18 triliões em 2008 para mais de !1.88 triliões em
2013. Apesar do clima económico que se vive neste momento, existem muitas perspectivas para
certos serviços de telecomunicações em determinados mercados. Áreas como a América Latina e
Ásia do Pacífico vão ser um “estrondo” para os mercados nos próximos anos. Através do estudo
em questão e de acordo com Gartner (2008), a região da Ásia/Pacífico vai atingir a maior taxa de
crescimento dos próximos cinco anos, cerca de 16%. Os países com elevada densidade
populacional, tal como a China e a Índia, irão ter as taxas mais elevadas. A curto prazo, as
empresas de telecomunicações estão susceptíveis a ter uma caída devido à pressão económica. No
Introdução
3
entanto, haverá um crescimento significativo em algumas áreas, como por exemplo a wireless
(rede pessoal sem fios). De acordo com o estudo feito pelo Insight (Boonton, 2007), as receitas do
serviço wireless terão um crescimento anual de 14,4% até 2013.
1.2 Motivação
Com o crescimento contínuo nas área das TI, são cada vez mais as ferramentas e soluções de
Data Mining disponíveis. Entre todas as aplicações existentes, todas têm a característica em
comum de utilizar diversos algoritmos e técnicas de mineração de dados para ajudar na descoberta
de conhecimento. Diversos modelos de extracção de conhecimento têm sido desenvolvidos
utilizando paradigmas de diferentes áreas de estudo, tais como Inteligência Artificial e Estatística
(Mitchell, 1997). Existem assim diversos algoritmos de aprendizagem, todos eles com as suas
vantagens e desvantagens, podendo apresentar desempenhos diferentes com amostras de dados
diferentes. Como consequência, nem sempre é fácil comparar os resultados de diversas técnicas e
ferramentas de forma a escolher a melhor solução para o problema em causa. Mesmo assim, é
muito importante fazer um estudo experimental de forma a esclarecer quais os melhores caminhos
a seguir.
No âmbito da área de detecção de fraude, existe um conjunto de técnicas que conseguiram
cultivar uma posição de relevo, tanto pelos bons resultados obtidos como pela facilidade existente
em traduzir os mesmos para a linguagem humana. Vários algoritmos têm sido optimizados,
adaptados e muitos têm sido utilizados em conjunto de forma a combater o problema de fraude.
Apesar de todos os esforços, ainda existem muitas limitações nas capacidades de detecção das
técnicas utilizadas. A cada dia que passa os criminosos e vão-se adaptando ás soluções existentes
e surgem novos tipos de fraude.
O comportamento passado de um utilizador pode ser acumulado de forma a construir um perfil ou
um dicionário de utilizador com o que é esperado que sejam os atributos que traduzem o seu
comportamento. Os perfis podem ser implementados sumariando o histórico de transacções dos
clientes e podem ser definidos pelos analistas ou identificados através de técnicas autónomas.
Estes perfis contêm valores numéricos agregados que reflectem a aparência de um
comportamento ou de um padrão comportamental multi-variante. Depois, é possível comparar o
perfil habitual de um utilizador com o seu perfil mais actual. Com base nos resultados obtidos
Introdução
4
podem ser definidos novos perfis de fraude emergentes através das variáveis adequadas. As
comparações efectuadas poderão ser implementadas através de algoritmos de aprendizagem, tais
como Redes Neuronais, Redes Bayesianas ou Assinaturas por exemplo.
1.3 Objectivos
Com a expansão da tecnologia moderna o fenómeno de fraude cresce dramaticamente. Apesar das
técnicas de prevenção serem uma óptima solução para reduzir a fraude, os criminosos adaptam-se
e, com tempo, normalmente encontram outras formas de contornar tais medidas. Pretende-se
perceber como está a fraude a ser utilizada actualmente contra as organizações e as limitações dos
métodos existentes para detectá-la. De acordo com a evolução da fraude nos tempos emergentes,
pretende-se escolher a técnica que vai mais de encontro com as necessidades das organizações.
Um dos principais objectivos desta dissertação consiste em implementar e integrar um protótipo
num sistema de gestão de fraude actualmente em funcionamento. Pretende-se aumentar as
capacidades do sistema e disponibilizar aos analistas resultados adequados aos tipos de fraude
actuais. Este protótipo assenta na utilização de princípios metedológicos, técnicas de profiling,
modelos, estratégias, identificação e tranformação de dados. É muito importante que as
organizações possuam a informação certa em tempo útil de forma a agir atempadamente e tomar
as decisões correctas, de forma eficaz e eficiente. Assim, é necessário conhecer o mundo das
telecomunicações, todas as formas de actuação de fraude nesta área, os métodos existents para
combater a mesma e possíveis melhoramentos ou inovações a aplicar.
Na sequência da concretização dos objectivos gerais em cima mencionados, estão enunciados de
seguida um conjunto de objectivos com um carácter mais específico. Assim sendo, pretende-se
também que esta dissertação nos permita:
1. Perceber a importância do mercado de telecomunicações e o seu impacto na sociedade
actual.
2. Estudar e aprofundar conceitos gerais de detecção de fraude em sistemas de
telecomunicações.
3. Estudar e perceber o sistema onde vai ser integrado o protótipo a implementar. Entender
as suas limitações e pontos a serem melhorados.
Introdução
5
4. Tomar conhecimento das principais técnicas e algoritmos de Data Mining utilizados na
detecção de fraude em sistemas de telecomunicações.
5. Estudo de métodos de detecção através de perfis de utilização, relacionar as técnicas e
algoritmos estudados.
6. Levantamento e validação de abordagens de implementação de técnicas de detecção de
fraude. Escolha e justificação de um caminho a seguir.
7. Desenvolvimento e teste de um protótipo para detecção de fraude com recurso à técnica
de profiling seleccionada.
8. Integração e consolidação do protótipo no SGF Centaur e validação em ambiente real.
9. Analisar e validar os resultados obtidos de forma a comprovar a sua utilidade ou vantagem
em relação aos métodos existentes.
1.4 Organização do documento
Além do presente, esta dissertação integra mais sete capítulos. O segundo capítulo aborda o tema
da fraude em telecomunicações. Aqui é explicado o que acontece nas situações fraudulentas, as
perdas que as empresas têm com este fenómeno, os tipos de fraude que existem e os factores
chave que levam à ocorrência de fraude. No capítulo seguinte, é explicado o conceito de Data
Mining e as técnicas mais comuns existentes na detecção de fraude nos sistemas actuais. O
capítulo quatro relata experiências efectuadas com algumas das técnicas descritas no capítulo
anterior, de forma a avaliar o seu desempenho e alcance, e por fim, uma breve conclusão com
uma comparação das diversas técnicas estudadas e a explicação do porquê da escolha do método
baseado em Assinaturas para o problema proposto. A seguir, no quinto capítulo, apresentam-se
todas as fases importantes relativas à implementação do protótipo de detecção de Fraude baseado
em Assinaturas e uma contextualização do sistema onde este vai ser integrado. No capítulo seis
são apresentados alguns dos problemas mais importantes durante o desenvolvimento do
componente de detecção. Passando ao capítulo sete, este suporta a validação da escolha do
método utilizado através da análise de resultados e estudo individual de casos alarmados. O último
capítulo procura fazer uma retrospectiva do trabalho realizado, uma análise dos resultados obtidos,
uma avaliação do impacto do protótipo num sistema real de telecomunicações, uma análise de
possíveis deficiências no processo de validação de resultados, uma comprovação efectiva de casos
classificados como fraude por uma operadora real de telecomunicações, e, por fim, alguns dos
Introdução
6
próximos passos a realizar no âmbito deste estudo e possíveis evoluções a realizar no sistema
protótipo implementado.
Fraude nas Telecomunicações
7
Capítulo 2
2Fraude nas Telecomunicações
De acordo com (Larrañaga, 2009), um survey global lançado em Março de 2008 posiciona as
perdas devido à fraude nas telecomunicações em !38.68 até !41.89, o que corresponde a 52% de
aumento em relação ao último survey lançado em 2003, a 85% de correspondentes que dizem que
as perdas devido à fraude estão a aumentar e a 65% de corespondentes que confirmaram uma
tendência de subida da fraude nas telecomunicações (Figura 1).
Figura 1 - Perdas da fraude na indústria de telecomunicações (Larrañaga, 2009)
Fraude nas Telecomunicações
8
As perdas da fraude na indústria das telecomunicações traduzem cerca de 5% das receitas. Muito
desse dinheiro é reencaminhado por diversos países para suportar o crime mundial, incluindo o
terrorismo. Hoje em dia, a fraude é sem dúvida o factor responsável pelas grandes perdas que
ocorrem nas empresas de telecomunicações. A título de curiosidade, os cinco principais países com
maiores índices de fraude são: o Paquistão, as Filipinas, Cuba, a Índia e o Bangladesh (Larrañaga,
2009).
2.1 Possíveis Fraudes
A fraude pode ser simplesmente descrita como uma representação falsa ou intenção enganosa que
um indivíduo tem conhecimento e que resulta num benefício não autorizado para ele próprio ou
para outra pessoa (Hollmén, 2000). Com a expansão da tecnologia e da comunicação global, a
fraude aumenta dramaticamente. É importante fazer a distinção entre a prevenção de fraude e a
detecção de fraude. A prevenção de fraude descreve medidas para evitar a ocorrência de fraude.
Isto inclui restrições de acesso a controlo de utilização e depende da implantação de facilidades de
segurança, tais como a autenticação de identidades ou autorizações baseadas em políticas, e
envolve processamento à priori (Hilas and Sahalos, 2005). Por outro lado, a detecção de fraude é o
processo de identificar a fraude o mais rápidamente possível depois da sua ocorrência (Hilas and
Sahalos, 2005). A detecção de fraude é utilizada logo após o insucesso da prevenção de fraude,
contudo, a detecção de fraude deve ser constantemente utilizada, não existe nenhum método de
prevenção perfeito e normalmente existe um problema com a eficiência. A detecção de fraude é
uma área que evolui continuamente e o desenvolvimento de novos métodos torna-se cada vez
mais difícil devido à limitação que existe no acesso à informação. Os dados não estão disponíveis e
os resultados provenientes da fraude não são apresentados ao público.
Muitos problemas de detecção de fraude envolvem grandes conjuntos de dados que estão
constantemente a crescer. As empresas de telecomunicações têm de lidar com milhões de
transacções por ano e para processar toda a informação, de forma a encontrar transacções
fraudulentas, é necessário ter algoritmos rápidos e eficientes onde as técnicas de mineração de
dados possam ser aplicadas. Como consequência, existe outro problema que deve ser considerado
de forma a manter a segurança dos sistemas e a credibilidade dos resultados. Com o tempo as
técnicas utilizadas serão conhecidas pelos criminosos e estes irão adaptar as suas estratégias e
tentar outras diferentes. Para compreender o que leva uma pessoa a cometer fraude, existem
Fraude nas Telecomunicações
9
alguns factores chave do trabalho de Mohay, et al. (2003) que irão ser analisados. Tipicamente, o
comportamento fraudulento deriva de três factores chave: motivo, oportunidade e benefício. Todos
estes factores, quando combinados, constituem aquilo que é chamado o triângulo de fraude
(Figura 2). Quando os três factores se manifestam a probabilidade ou a oportunidade de haver
actividade fraudulenta é significativamente maior, resultando num aumento do risco de fraude
para a organização em causa.
O motivo é o factor principal no comportamento fraudulento. Alguns dos motivos que levam à
ocorrência de fraude são o orgulho pessoal, a vingança, dívidas etc. Com a expansão do comércio
online a fraude tem aumentado e os motivos também. Hoje em dia, existem pessoas que cometem
crimes apenas por orgulho pessoal ou mesmo para mostrar que são capazes de o fazer. A
oportunidade faz os meios pelo qual a fraude ocorre. A oportunidade aparece quando existem
falhas nos sistemas de controlo ou segurança, neste caso são identificadas e exploradas. Muitas
fraquezas, tais como a impossibilidade de identificar uma pessoa e a escassez de controlos de
acesso podem providenciar uma oportunidade. O benefício é o resultado da actividade fraudulenta.
O propósito de cometer fraude é para beneficiar. O benefício pode ser adquirido directamente pela
pessoa que cometeu fraude ou por outra pessoa. Alguns exemplos de benefícios são: aquisição de
bens, vingança e vantagem financeira.
A fraude pode ser dividida, essencialmente, em duas categorias principais: fraude de subscrição e
fraude de superposição. A fraude de subscrição ocorre quando as pessoas que cometem fraude
obtêm uma conta sem qualquer intenção de a pagar. Nestes casos, verifica-se uma utilização
Figura 2 - Três factores que levam à ocorrência de fraude (Mohay, et al., 2003)
Fraude nas Telecomunicações
10
anormal durante o período activo da conta. A conta é normalmente utilizada para vender
chamadas ou para uso pessoal intensivo. Os casos de dívidas, onde os utilizadores não pagam as
contas e não têm necessariamente intenções fraudulentas, também pertencem a esta categoria. A
fraude de superposição ocorre quando os criminosos “pegam” numa conta legítima. A técnica mais
comum para identificar a fraude de superposição é comparar o comportamento recente de
chamadas de um cliente com um perfil do seu passado, utilizando técnicas de detecção de
anomalias e má utilização (Fawcett and Provost, 1998). A origem da fraude tem impacto directo na
identificação, preservação e análise de evidência electrónica. Quando a fraude vem de um fonte
externa, pouco se sabe acerca da identidade do criminoso e sobre as potenciais fontes de
evidência, isto requer mais recursos e tempo de investigação na organização. Mais ainda, os
problemas de jurisdição que podem ter impacto na investigação da fraude externa são muito
pequenos. De seguida algumas das principais diferenças entre fraude interna e fraude externa.
2.2 Fraude Interna
A fraude interna é um tipo de fraude que tem origem no interior de uma organização e é
inicializada ou realizada por um funcionário ou administrador da organização (Mohay, et al., 2003).
A fraude interna normalmente é realizada quando os controles internos da organização estão mal
implementados. As organizações contêm indivíduos que estão em posições capazes de tomar
decisões, a necessidade de controles internos eficazes e independentes é essencial. Os controles
internos devem ser capazes de distinguir negócio legítimo de actividade potencialmente
fraudulenta. Habitualmente, isto é possível utilizando mecanismos como a reconciliação,
segregação de funções e auditorias internas. Devido ao tempo e custo necessário para
implementar estes processos manualmente, não é surpreendente encontrar ferramentas
automáticas para tratar a detecção de fraude. Neste processo de detecção, as vantagens de
diminuição de tempo e reduzida intervenção humana providenciam um benefício significativo para
a organização. A fraude interna pode ter diversas variedades, dependendo da natureza e do
tamanho do negócio. No entanto, é possível listar alguns dos tipos de fraude interna mais comuns,
nomeadamente:
• Ghosting – Obter taxas gratuitas ou a preços inferiores através de meios técnicos capazes
de contornar a rede. Isto pode ser feito, por exemplo, alterando o conteúdo da base de
dados através do comando 'alter' sobre os registos das chamadas. Este tipo de fraude
Fraude nas Telecomunicações
11
também pode ser realizado externamente (Cortesão, et al., 2005).
• Divulgação de informação sensível – Obter informação valiosa e vendê-la a entidades
externas (Cortesão, et al., 2005).
• Comissões secretas – Benefícios não declarados, tais como prémios, são recebidos ou
pagos em troca de manutenção ou estabelecendo a venda de bens ou serviços (Taylor, et
al., 1999).
2.3 Fraude Externa
A fraude externa é realizada contra uma organização por uma pessoa ou um grupo de pessoas que
não estão empregadas nessa organização. É normalmente efectuada com o propósito de obter
algum tipo de ganho, poderá ser lucro ou mesmo a utilização grátis de um serviço ou produto
(Mohay, et al., 2003). Tal como na fraude interna, o sucesso da fraude externa é dependente dos
controles da organização. As organizações que têm os seus controles mal implementados têm
maior risco de se tornarem vítimas de fraude do que organizações que têm as suas estratégias de
detecção de fraude consistentes. Com o crescimento do comércio electrónico, o risco da fraude
online tem aumentado significativamente. Quer seja tradicional ou online, a fraude externa pode
ser efectuada de diversas formas - algumas foram já explicadas na fraude interna. Refira-se em
particular:
• Fraude de subscrição – É a fraude mais comum de se encontrar na rede GSM. Uma
pessoa utiliza uma entidade falsa para usufruir de um serviço. A fraude de subscrição pode
ser utilizada para uso pessoal ou para fins lucrativos. (Taylor, et al., 1999).
• Venda de chamadas – Vender tarifários de chamadas abaixo do seu valor no mercado
com o objectivo de iludir o pagamento à operadora (Cortesão, et al., 2005).
• Surfing – Utilizar o serviço de outra pessoa sem autorização. Por exemplo, através da
clonagem de cartões SIM ou quando os criminosos obtêm a password para o serviço PABX
(Cortesão, et al., 2005).
• Fraude de retribuição de chamadas – Existem países onde as chamadas internacionais
são muito caras. A fraude ocorre quando a chamada é efectuada para um número mas
antes é redireccionada para um outro país que retorna a chamada com o seu respectivo
sinal de linha. A pessoa pode assim usufruir dessas taxas independentemente da direcção
Fraude nas Telecomunicações
12
da chamada (Worldxs, 1995).
• Fraude de tarifas premium – Abuso dos serviços de tarifas premium. Existem diversas
maneiras desta fraude ocorrer. Por exemplo, uma pessoa pode configurar uma linha de
tarifa premium com um operador, este é obrigado a pagar a essa pessoa a percentagem
do lucro obtido. O criminoso pode utilizar um telefone fraudulento e outras pessoas para
realizar chamadas de longos períodos. Isto gera altos lucros e a pessoa não paga as suas
próprias chamadas (Cortesão, et al., 2005; Taylor, et al., 1999).
• Roubo de conteúdo – Obter conteúdo (vídeos, musica, jogos etc) de alto valor
gratuitamente. Isto é feito contornando o sistema de pré-pagamento em tempo real ou
evitando o pagamento das contas (Cortesão, et al., 2005).
• Roubo de telefone – Roubar um telefone de subscrição e enquanto não for detectado o
criminoso efectua um número elevado de chamadas (Taylor, et al., 1999).
• Fraud de Roaming – O criminoso aproveita-se dos atrasos existentes na transferência de
CDRs (Registo de Chamadas Detalhadas) através de roaming numa operadora estrangeira
(Taylor, et al., 1999).
Na figura 3 podemos ver três dos mais importantes tipos de fraude e as várias formas em como
elas são utilizadas contra as organizações.
Figura 3 - Três dos mais importantes tipos de fraude e como são aplicados
contra as organizações
Abordagens para a Detecção de Fraude
13
Capítulo 3
3Abordagens para a Detecção de Fraude
3.1 Data Mining
Com a constante evolução tecnológica nos dias de hoje e com a informatização geral de sistemas,
as organizações na área da ciência e comércio têm ganho novas formas de produzir a acumular
grandes volumes de informação. Esta informação, até recentemente, não era analisada para apoio
a actividades de suporte à decisão, ou quando era, o trabalho era efectuado manualmente por
especialistas. Infelizmente com o crescimento do volume e complexidade dos dados, a análise
manual deixa de ser uma solução viável. De forma a ultrapassar este problema surgiu a descoberta
de conhecimento, ou Knowledge Discovery (KD) (Abidogun, 2005). A descoberta de conhecimento
permite a extracção de conhecimento implícito, anteriormente desconhecido e potencialmente útil,
de grandes quantidades de dados. Esta disciplina, assim como outras, é extremamente específica
em termos de aplicação, negócio e objectivos, necessitando de profissionais treinados para a sua
correcta aplicação.
Actualmente, vivemos numa sociedade que depende da tecnologia, a maior parte das organizações
ligadas à ciência, marketing, finanças, saúde e retalho instalaram sistemas informáticos para a
automatização de processos e suporte na tomada de decisão. Felizmente, com a diminuição dos
custos de hardware, depois da instalação dos sistemas, tem sido possível guardar e acumular toda
a informação gerada pela actividade nas organizações para posterior análise.
Até bem há pouco tempo, em muitas organizações, a tarefa de análise de dados era
exclusivamente da responsabilidade dos analistas de dados. O analista, profissional altamente
Abordagens para a Detecção de Fraude
14
especializado e intimamente integrado com o negócio e a informação existente, pesquisa e estuda
os dados manualmente, procurando padrões, associações ou qualquer outro tipo de conhecimento
que possa ser útil e benéfico para a empresa. Porém, o grande volume de informação armazenada
e a sua crescente complexidade tornam a análise manual impraticável e cada vez menos produtiva.
Para encontrar padrões de utilização anteriormente desconhecidos e relações, a KD envolve a
utilização de ferramentas de análise sofisticadas com grandes quantidades de dados. A KD não se
resume apenas à utilização simples de uma ferramenta moderna, é um processo global de
descoberta de conhecimento útil a partir dos dados existentes. Este processo envolve um
entendimento do negócio, estudo de preparação dos dados, criação e avaliação de modelos etc.
Grande parte das organizações utilizam abordagens de KD para apoiar e suportar o negócio,
principalmente em áreas como: a Banca; os Seguros; as Telecomunicações; e o Marketing. As
empresas de telecomunicações e as de seguros utilizam KD para construir perfis de fraude e
detectar novos casos que sejam semelhantes. Os bancos utilizam dados armazenados ao longo do
tempo para avaliar o risco de um crédito, identificar fraudes e branqueamento de capital. Na área
de marketing a KD é usada para prever o comportamento dos clientes, agrupá-los em grupos
distintos e lançar campanhas de marketing específicas para “alvos” concretos.
Devido ao conhecimento vasto e específico necessário para lidar com processos de KD, que inclui
campos como Aprendizagem Computacional, Reconhecimento de Padrões, Bases de Dados,
Estatística, Inteligência Artificial, Sistemas Periciais, Visualização de Dados e Computação de Alto
Desempenho, é considerada uma área para especialistas e não para o utilizador comum. Um dos
problemas da área é que estes especialistas estão normalmente vinculados a uma ferramenta em
concreto e à sua metodologia, o que levanta bastantes dificuldades na migração para diferentes
metodologias e técnicas, impossibilitando a criação de um standard de indústria.
3.2 Perfis de Utilizador
Nas redes de telecomunicações, a fraude é caracterizada por cenários. Isto é feito de forma a
descrever como obtém o criminoso acesso ilegal à rede. Os métodos de detecção que são
elaborados para um cenário específico de fraude não são reutilizáveis para todos os outros casos.
A origem da fraude, com a evolução tecnológica, mudou de fraude de clonagem para fraude de
subscrição, o que torna as metodologias de detecção especializada inadequadas. As metodologias
de detecção utilizadas para detectar instâncias de clonagem de telefones móveis provavelmente
Abordagens para a Detecção de Fraude
15
não conseguirão detectar nenhum caso de fraude de subscrição. No entanto, o foco principal está
nas metodologias de detecção relacionadas com a actividade das chamadas, que por sua vez
podem ser divididas em duas categorias: análise absoluta e análise diferencial (Burge, et al.,
1997).
Na análise absoluta, a detecção está principalmente focada na actividade das chamadas de
comportamento fraudulento e de comportamento normal. A análise diferencial lida com o problema
de detecção de fraude através de mudanças repentinas no comportamento. Utilizando a análise
diferencial, tipicamente, os métodos alarmam diferenças em relação aos padrões de utilização que
estão previamente estabelecidos. Quando o comportamento actual difere do seu modelo
comportamental estabelecido, é gerado um alarme. Em ambos os casos, os métodos de análise
são normalmente implementados através de modelos probabilísticos, redes neuronais, sistemas
baseados em regras ou assinaturas. Ambos os casos estão ilustrados nas figuras (Figura 4 e 5) em
baixo. A área sombreada indica as regiões a serem classificadas como fraudulentas.
Figura 5 - O modelo é construído assumindo um comportamento (c1), algum desvio em relação ao
comportamento definido é classificado como fraude
Figura 4 - Ambos os modelos de comportamento normal (c1) e comportamento
fraudulento (c2)
Abordagens para a Detecção de Fraude
16
A ideia principal quando se fala de perfis de utilização é que o comportamento passado de um
utilizador pode ser acumulado de forma a construir um perfil ou um dicionário de utilizador,
através dos atributos que traduzem o seu comportamento. Este perfil contém valores numéricos
agregados que reflectem a aparência de um comportamento ou de um padrão comportamental
multi-variante. O comportamento futuro do utilizador pode depois ser comparado com o seu perfil
para verificar se a situação está normalizada ou se houve alguma alteração anormal que possa ser
sinónimo de actividade fraudulenta. Um problema que se deve ter sempre em conta é que nunca
se pode ter a certeza se o caso em questão é mesmo fraudulento. Como consequência deve haver
sempre uma investigação cuidadosa e profunda daquilo que foi observado.
Existem algumas técnicas de mineração de dados que podem ser utilizadas com os dados de
telecomunicações para detecção de fraude. Tipicamente, as técnicas podem ser divididas em
aprendizagem Supervisionada e Não Supervisionada. Nas técnicas Supervisionadas, amostras de
comportamento normal e fraudulento são utilizados para construir modelos, isto permite ao
sistema assinalar novas observações para cada classe. Apenas é possível detectar fraude de um
tipo que foi previamente registado. Por outro lado, as técnicas Não Supervisionadas procuram
obter tipos de fraude que não foram anteriormente descobertos e que podem a partir daquele
momento ser detectados, normalmente procuram observações anormais. Ambos os métodos
apenas nos dão a indicação de existir a possibilidade de haver fraude. Qualquer análise estatística,
por si só, não pode assegurar que uma situação em particular é fraude, apenas pode indicar que é
mais provável ser fraudulenta do que outros casos. Muitas vezes, ambas as técnicas são utilizadas
em conjunto para construir um sistema híbrido capaz de melhorar os resultados esperados (Hilas
and Sahalos, 2005).
Hoje em dia o termo “mineração de dados” é vendido a preço de ouro. Supostamente é uma
solução para tudo. Se for este o caso, porque é que ainda existe fraude? Infelizmente a utilização
das técnicas de mineração de dados envolve muitas condições. A mineração de dados é diferente
das técnicas de análise de dados tradicionais e muitas vezes é utilizada incorrectamente. Os
resultados bem sucedidos esperados estão normalmente associados a casos de aprendizagem
Supervisionada. Os perfis de utilizador podem ser construídos utilizando características de
utilização apropriadas. O objectivo é distinguir um utilizador normal de um fraudulento. Todos os
dados necessários a serem estudados pelo sistema estão contidos nos CDRs, cada registo traduz
uma chamada realizada numa rede de telecomunicações e tem informação suficiente para
Abordagens para a Detecção de Fraude
17
descrever pormenorizadamente uma chamada. Os CDRs contêm dados como a duração da
chamada, o ID da pessoa que efectuou a chamada, data e hora da chamada etc. Para construir
um perfil de utilizador, o primeiro passo é construir a base necessária que é a unidade
fundamental de comparação. Deverá ser possível seleccionar diferentes unidades de comparação,
dependendo do tipo de fraude e do ambiente em utilização.
Foram identificados alguns indicadores típicos que podem ser utilizados para detecção de fraude
realizada em telefones móveis (Burge, et al., 1997). Para avaliar a capacidade de indicadores
específicos identificarem uma fraude em particular, estes foram classificados pelo seu tipo,
nomeadamente:
• indicadores de utilização – que estão relacionados com a forma como o telefone é
utilizado;
• indicadores de mobilidade – que estão relacionados com a mobilidade do telefone;
• indicadores dedutivos – que surgem como um subproduto do comportamento
fraudulento
Em muitos casos há indicadores que sozinhos fornecem informação suficiente para detectar fraude
(indicadores primários), noutros casos existem outros que, só por si, fornecem alguma informação
relevante, mas não suficiente (indicadores secundários). Finalmente existem indicadores que só
quando combinados com outros é que são capazes de fornecer informação útil (indicadores
terciários).
O indicador mais simples de se utilizador é a unidade básica de comparação e traduz a informação
de uma chamada, ou seja, a data, hora, ID da pessoa que realizou a chamada, número da
chamada e o custo da chamada. Outra unidade simples pode ser a informação relativa ao
resultado de todas a chamadas efectuadas num dia. Um exemplo final de outra unidade de
comparação poderá ser o comportamento acumulado por dia. Isto é uma sequência constituída
pelo número de chamadas para destinos locais, a duração ou custo das chamadas locais, o número
de chamadas para destinos móveis, a duração ou custo das chamadas para destinos móveis, o
número de chamadas para destinos nacionais ou internacionais e o seu período correspondente.
Este comportamento diário cumulativo de um utilizador é uma medida básica de utilização do seu
terminal e pode ser uma medida que o diferencia dos outros utilizadores.
Abordagens para a Detecção de Fraude
18
Existem alguns métodos para identificar fraude que não envolvem a comparação de
comportamento recente com comportamento passado. Os criminosos raramente trabalham
sozinhos. Por exemplo, os autores da fraude muitas vezes actuam como correctores e vendem
serviços ilegais a outros, enquanto que os compradores ilegais usam constantemente diferentes
contas para ligar para o mesmo número muitas vezes. Cortes e Pregibon (2001) exploraram este
comportamento reconhecendo que determinados números eram chamados a partir de contas
suspeitas e as chamadas para estes números eram um forte indicador de que a conta poderia
estar comprometida.
3.3 Técnicas para a Detecção de Fraude
3.3.1 Detecção baseada em Regras
Hoje em dia existem muitos sistemas de análise que utilizam um modelo baseado em regras, com
geração de alarmes, como método de detecção de fraude. Os sistemas baseados em regras
utilizam conhecimento humano especializado para resolver problemas do mundo real, estes
problemas normalmente requerem inteligência humana. O conhecimento especializado é
normalmente representado na forma de regras ou dados armazenados no computador.
Dependendo do problema em causa, as regras e os dados podem ser utilizados para resolver a
situação. Os sistemas baseados em regras têm desempenhado um papel importante nos sistemas
inteligentes modernos e na definição de metas estratégicas, planeamento, monitorização de falhas,
diagnósticos etc. Algumas das vantagens mais importantes dos sistemas baseados em regras são:
• As regras oferecem uma forma de representação intuitiva do conhecimento.
• Os mecanismos de inferência aproximam-se de estratégias comuns de resolução de
problemas.
• A estrutura de controlo é normalmente simples e intuitiva.
Os padrões de fraude são as regras do sistema. A geração automática de regras utilizando
conhecimento adquirido do passado é utilizada para encontrar novas regras. É assim possível
distinguir a utilização legítima da fraudulenta. No entanto, para encontrar as regras apropriadas
para o sistema o problema é mais delicado. É necessário encontrar regras onde as propriedades
Abordagens para a Detecção de Fraude
19
dos clientes vão de encontro com propriedades específicas de comportamento. A informação do
cliente é normalmente a sua idade, data de nascimento, tarifário etc.
Sumarizar a actividade das contas é um passo importante quando se desenha um sistema de
detecção de fraude, é muito difícil aceder ou analisar todos os registos de uma conta sempre que
esta é avaliada como fraude. Uma solução comum é reduzir os registos de chamadas de uma
conta para diversas estatísticas que são computadas em determinado período de tempo.
Tipicamente os atributos comportamentais do cliente podem ser, por exemplo, o número de
chamadas efectuadas diariamente, número de chamadas internacionais efectuadas diariamente
etc. Os sumários de uma conta podem ser comparados com limiares em cada período, se os
sumários de uma conta excederem um limiar esta pode ser reencaminhada para ser avaliada como
possível situação de fraude.
Um sistema baseado em regras é constituído por instruções if-then (se-então), um conjunto de
factos, e um interpretador controlando a aplicação das regras, dados esses factos. Estas regras if-
then são utilizadas para formular as declarações que comprometem a base de conhecimento. Uma
regra simples tem o seguinte formato: “if x is A then y is B”. A parte do if da regra (“x is A”) é
chamado o antecedente e a parte then da regra (“y is B”) é chamado o consequente ou conclusão.
Para identificar fraude de superposição podem ser utilizados monitores comportamentais. Estes
monitores denotam o valor calculado em termos de desvios padrão a partir o valor da média. Se o
valor destes monitores for muito elevado isto é indicação de uma extrema subida na utilização, e
pode ser utilizado numa regra de fraude de sobreposição. As regras podem ser compostas por
mais do que uma condição, quando todas forem verdadeiras é gerado um alarme. O sucesso de
uma regra de fraude é determinada pelo número de alarmes verdadeiros identificados e pelo
número de falsos alarmes gerados. Um exemplo de uma regra que combina elementos de dados
comportamentais e de cliente pode ser dada por:
!
(price_ plan = X " internacional_calls_ day > 50" total_calls_ day < 60)# ALERT
Os alarmes são depois agrupados por casos para serem alvos de uma investigação manual, os
analistas são responsáveis por tentar determinar quais são os casos de fraude que são realmente
verdadeiros. Apesar do vasto conhecimento de alguns analistas, com o passar do tempo aparecem
novos padrões de fraude e a dificuldade para os detectar é elevada. Deverá haver um estudo
Abordagens para a Detecção de Fraude
20
constante dos dados históricos e o conhecimento recente deve ser utilizado para actualizar e
adaptar as regras existentes de forma a aumentar a eficácia dos alarmes gerados. Quando é
encontrada uma nova regra, pode ser adicionada ao conjunto de regras do sistema.
Existe um conjunto de critérios pelos quais se pode medir a qualidade de uma regra (Rosset, et al.,
1999). Esses critérios são:
• A alta precisão nos casos (a maior parte dos casos encontrados são realmente
fraudulentos).
• A alta cobertura de casos de fraude verdadeiros (a maior parte dos casos fraudulentos são
encontrados).
• A alta cobertura de alertas de fraude verdadeiros (os casos de fraude são detectados
rapidamente)
O desemepnho de cada regra individual não é o factor mais importante, o que realmente importa é
o desempenho do conjunto total de regras. O objectivo é obter bons resultados em todos os
critérios em cima mencionados e não numa única regra com propriedades específicas.
A análise das regras pode ser difícil de gerir, para se obter uma configuração apropriada é
necessário precisão e tempo para cada possível fraude. O problema do aparecimento constante de
novos tipos de fraude significa que as regras precisam de ser constantemente adaptadas para
prevenir a ocorrência de fraude no futuro. Nem sempre as regras constituem a forma mais natural
de representação do conhecimento e a aquisição do mesmo é difícil. Em certos domínios pouco
estruturados, não existe um corpo explícito de conhecimento estabelecido que permita a
construção de uma base de regras. Existe também um grande obstáculo na escalabilidade destes
sistemas. Quanto maior o conjunto de dados a processar, maior é a queda na performance.
3.3.2 Detecção baseada em Redes Neuronais
Uma rede neuronal artificial é um mecanismo computacional que tenta emular o funcionamento do
cérebro humano. Procura-se construir um computador que tenha circuitos que modelam os
circuitos cerebrais e espera-se ver comportamento inteligente, que nos conduza a aprendizagem
de novas tarefas, fazendo generalizações e descobertas. Estes circuitos neuronais artificiais
Abordagens para a Detecção de Fraude
21
deverão conseguir auto-organizar-se, quando em ambientes diferentes, criando novas
representações internas a apresentar comportamentos imprevisíveis. Os modelos baseados em
redes neuronais são uma boa alternativa para efectuar certos tipos de computações. A sua
principal utilização é direccionada para computações não estruturadas, tais como reconhecimento
de padrões, problemas de inteligência artificial e aproximações para grandes problemas de
optimização. Existem diversos factores que tornam a utilização de redes neuronais artificiais uma
solução bastante plausível, sendo de realçar:
• O comportamento inteligente é um fenómeno emergente.
• A utilização de um modelo computacional semelhante ao cérebro humano permite
encontrar soluções que seriam impossíveis com métodos tradicionais.
• É tolerante a falhas, visto que a rede pode ser organizada de forma a que as computações
não dependam de um conjunto fixo de ligações e nodos.
• O processamento local e autónomo de cada nodo é combinado com comportamento
semelhante de outros nodos, produzindo um comportamento global complexo.
As redes neuronais distinguem-se dos restantes métodos inteligentes na medida em que não são
baseadas em regras, é possível definir probabilidades de forma a quando receber os mesmos
inputs produzir acções diferentes. Comportamentos probabilísticos permitem ás redes neuronais
explorar o ambiente em maior detalhe e consequentemente atingir soluções melhores que os
métodos lineares. Devido à grande variedade de cenários de fraude que existe hoje em dia, as
redes neuronais são uma óptima solução quando se procura alta flexibilidade e adaptabilidade em
reconhecimento de padrões.
Para melhor perceber as redes neuronais será explicado o funcionamento do córtex cerebral. É
constituído por cerca de 100 biliões de minúsculas unidades denominadas por neurónios. O
neurónio é a unidade fundamental do sistema nervoso, está conectado a centenas de outros
neurónios e comunica com eles através de sinais nervosos eléctricos e químicos. A comunicação é
feita unidireccionalmente de forma descontínua, ou seja, por impulsos. Estes são activados em
cada neurónio sempre que determinado limiar de activação é ultrapassado em resultado da soma
dos sinais recebidos nas sinapses. As sinapses são as junções ou ligações entre os neurónios e
estão localizadas nas pontas das dendrites. As dendrites têm uma forma ramificada e são
responsáveis por receber os sinais eléctricos. O neurónio recebe continuamente sinais através dos
Abordagens para a Detecção de Fraude
22
inputs e depois faz a soma dos resultados obtidos, se o valor final for superior a determinado limiar
o neurónio dispara, gerando uma voltagem envia um sinal através do axónio. Normalmente cada
neurónio tem um axónio que cresce para fora a partir do corpo da célula e conduz o sinal eléctrico
gerado. O sinal é propagado aos outros neurónios novamente através das sinapses. Verifica-se que
as ligações mais usadas tornam-se mais consistentes e que os neurónios, por vezes, formam
novas ligações com outros neurónios. Estes mecanismos podem estar associados à habilidade de
aprendizagem.
A arquitectura das redes neuronais pode ser traduzida como um grafo não direccionado.
Normalmente, as ligações nos modelos são bidireccionais e simétricas. De seguida, na figura 6
apresentação uma ilustração de um neurónio:
Figura 6 - Ilustração de um neurónio
Uma rede neuronal artificial constitui um modelo computacional que é normalmente caracterizado
por:
• Um conjunto de elementos que simulam os neurónios biológicos e que se chamam de
unidades ou nodos.
• Uma rede com ligações direccionadas e com pesos associados entre os nodos.
• Os pesos podem ser números reais, positivos ou negativos.
• Cada unidade processa uma função com um número limitado de saídas provenientes de
outros nodos da rede.
• As saídas são posteriormente pesadas e tornam-se novos os inputs (entradas) do nodo.
• Para n entradas de um nodo, a saída será igual a
!
a = x1w1+ x
2w2
+ x3w3…x
nwn, onde
as entradas são representadas como
!
x1,x
2,x
3…,x
n e os correspondentes pesos são
Abordagens para a Detecção de Fraude
23
representados como
!
w1,w
2,w
3…,w
n. O valor do somatório dos pesos multiplicado pelas
entradas é o valor de activação a.
No caso de as variáveis serem binárias, cada nodo simula uma função de
!
0,1{ }M
" 0,1{ } . Se o
somatório exceder o limiar t, o output é definido com o valor 1, se for inferior a t é definido com o
valor 0 (Mostafa, 1989).
Normalmente, as redes neuronais contêm uma função de activação que determina o nível de
activação baseado no conjunto de todas as entradas, tomemos como exemplo uma função g. Para
cada unidade é também frequente a presença de uma entrada externa (offset ou bias) !. Este
valor é obtido passando o valor que traduz o limiar t para o lado esquerdo da igualdade
!
(x1w1+ x
2w2
+ x3w3
+…+ xnwn" t > 0) e multiplicando por -1 para manter a soma, ou seja,
!
x1w1+ x
2w2
+ x3w3
+…+ xnwn
+ ("1)t > 0. Assim sendo, a representação para a nova saída
seria dada por:
!
a = g(x1w1+ x
2w2
+ x3w3
+…+ xnwn + " > 0) , onde
!
" = (#1)t
Figura 7 - Determinar se o somatório dos pesos associados ao nodo de uma rede neuronal, multiplicado pelas suas entradas, ultrapassa o limiar definido.
Abordagens para a Detecção de Fraude
24
A aprendizagem nas redes neuronais pode ser efectuada de duas formas: aprendizagem não
supervisionada e supervisionada. Estas técnicas já foram anteriormente explicadas e serão agora
descritas de acordo com a sua aplicação nas redes neuronais. Na aprendizagem não
supervisionada os grupos da rede com padrões semelhantes devem ser agrupados em clusters.
Posteriormente, o utilizador terá de identificar quais as classes correspondentes e o que deverá ser
associado a cada cluster. Uma vez apresentados na rede, os padrões treinados são associados ao
cluster mais próximo, as suas classes são as classes do correspondente cluster. Na aprendizagem
supervisionada, os padrões são identificados à priori como pertencentes a uma classe. Durante o
processo de aprendizagem, a rede procura adaptar os seus elementos de forma a produzir a
identificação correcta dos seus outputs para cada padrão de treino. Uma vez terminado o treino,
os elementos ficam à espera que novos padrões sejam apresentados, estes serão depois
classificados de acordo com o output produzido pela rede.
A aprendizagem não supervisionada apresenta alguns problemas. Os padrões têm de ser
disponibilizados de forma a que seja possível agrupar os dados de comportamento fraudulento de
maneira distinta dos dados de utilização legítima. Outro problema é que com este método os
sistemas apenas podem ser treinados com dados limpos. Na aprendizagem supervisionada a
principal dificuldade é depois de receber um grande conjunto de dados fraudulentos ser capaz de
classifica-los como tal. O esforço para concretizar esta tarefa é muito significativo e é difícil lidar
com casos de fraude desconhecidos. Ambos os métodos têm vantagens e desvantagens, neste
momento nenhuma das aproximações se apresenta como a favorita.
3.3.3 Detecção baseada em Redes Bayesianas
Uma rede Bayesiana é um modelo gráfico para relacionamentos probabilísticos entre um conjunto
de variáveis. Ao longo da última década, as redes bayesianas tornaram-se uma representação
popular para codificar conhecimento incerto em sistemas especializados. Mais recentemente,
investigadores desenvolveram métodos de aprendizagem em redes bayesianas a partir de
conjuntos de dados. As técnicas que têm sido desenvolvidas são novas e continuam a evoluir,
mostrando-se extraordinariamente eficientes em alguns problemas de análise de dados.
Existem inúmeras representações disponíveis para a análise de dados, incluindo regras, árvores de
decisão ou redes neuronais artificiais. Para técnicas de análise de dados existem exemplos como
estimativas de densidade, classificação, regressão e clustering. De seguida, algumas das vantagens
Abordagens para a Detecção de Fraude
25
e funcionalidades das redes bayesianas e o que os métodos bayesianos têm para oferecer
(Heckerman, 1996).
• As redes bayesianas podem facilmente manipular conjuntos de dados incompletos. Por
exemplo, considerando um problema de regressão ou classificação onde duas das variáveis
de input estão fortemente não correlacionadas. Esta correlação não é problema para as
técnicas comuns de aprendizagem supervisionada, os inputs disponibilizados são medidos
em todos os casos. Quando algum input não é observado, porém, a maioria dos modelos
irá produzir uma previsão imprecisa pois não codificam a correlação entre as variáveis de
input. As redes bayesianas oferecem um maneira natural de codificar tais dependências.
• Com as redes bayesianas é possível aprender acerca de relacionamentos casuais. A
aprendizagem de relacionamentos casuais é importante por duas razões; o processo é útil
quando estamos a tentar perceber o domínio de determinado problema, por exemplo,
durante o processo exploratório de análise de dados. Para além disso, o conhecimento de
relacionamentos casuais permite fazer previsões na presença de intervenientes. Por
exemplo, um analista de fraude em telecomunicações poderá querer saber se vale ou não
a pena alterar os limiares definidos no sistema baseado em regras, que opera em conjunto
com a rede bayesiana, de forma a diminuir o número de falsos positivos. A utilização das
redes bayesianas ajuda a responder a este tipo de perguntas, mesmo quando não existe
nenhum conhecimento se os efeitos de exposição acrescida estão disponíveis.
• As redes bayesianas em conjunto com as técnicas estatísticas bayesianas facilitam a
combinação de conhecimento de domínio e dados. Alguém que fez análise sabe a
importância do conhecimento prévio ou conhecimento de domínio, especialmente quando
os dados são escassos. O facto de alguns sistemas comerciais poderem ser construídos
através de conhecimento é a prova do poder de conhecimento prévio. As redes bayesianas
têm uma semântica casual que faz a codificação de conhecimento prévio casual de forma
simples. As redes bayesianas codificam a força dos relacionamentos casuais com
probabilidades. Consequentemente, o conhecimento prévio e os dados podem ser
combinados com técnicas estatísticas bayesianas.
• Os métodos bayesianos em conjunto com as redes bayesianas e outros tipos de modelos
oferecem uma aproximação eficiente para evitar o overfitting. Podemos verificar que não
existe a necessidade de utilizar determinados dados para teste. Utilizando a aproximação
bayesiana, os modelos podem ser “alisados” de forma a que todos os dados disponíveis
Abordagens para a Detecção de Fraude
26
possam ser utilizados para treino.
Para perceber as redes bayesianas e as técnicas de aprendizagem associadas, é importante
perceber a aproximação bayesiana para probabilidades e estatísticas. Resumindo, a probabilidade
bayesiana de um evento x é o grau de confiança da pessoa nesse evento. Enquanto que a
probabilidade clássica é uma propriedade física do mundo (por exemplo, a probabilidade de atirar
uma moeda ao ar e sair cara), a probabilidade bayesiana é uma propriedade da pessoa que atribui
a probabilidade (por exemplo, o grau de confiança em como sai cara após o lançamento da
moeda). Para manter estes dois conceitos de probabilidade distintos, refere-se à probabilidade
clássica de um evento como a probabilidade verdadeira ou física desse evento, e refere-se ao grau
de confiança de um evento como a probabilidade bayesiana ou pessoal (Heckerman, 1996).
Uma crítica comum da definição bayesiana de probabilidade é que as probabilidades parecem
arbitrárias. Porque deverão os graus de confiança satisfazer as regras de probabilidade? A que
escala devem as probabilidades ser medidas? Em particular, faz sentido assinalar a probabilidade
zero ou um a um evento que irá ou não ocorrer, mas que probabilidades assinar a confianças não
extremas? De não surpreender, estas questões têm sido estudadas intensamente. Em geral, o
processo de medir o grau de confiança é normalmente referido como sendo uma probabilidade
avaliativa. Um problema existente com a probabilidade avaliativa é a precisão. Poderá dizer-se que
a probabilidade para um evento x é 0.701 e não 0.699? Normalmente não. Na maioria dos casos,
as probabilidades são utilizadas para tomar decisões, essas decisões não são sensíveis a pequenas
variações de probabilidade. Práticas de sensibilidade de análise ajudam a saber quando a precisão
adicional é desnecessária.
Considerando um conjunto finito
!
X = X1,…,X
n{ } de variáveis aleatórias onde cada variável
!
Xi
pode assumir um valor
!
xi do domínio Val(
!
Xi). As letras maiúsculas, tais como X, Y, Z, são usadas
para nomes de variáveis e as letras minúsculas, tais como x, y, z, para denotar valores específicos
obtidos das variáveis. Os conjuntos de variáveis são representados por letras maiúsculas em
negrito (X, Y, Z), e as assinaturas dos valores das variáveis nos conjuntos são representadas por
letras minúsculas em negrito (x, y, z). A representação I(X; Y | Z) significa que X é independente
de Y condicionado em Z: P(X|Y, Z) = P(X|Z) (Friedman, 2000).
Abordagens para a Detecção de Fraude
27
Figura 8 - Exemplo de uma estrutura de uma rede bayesiana.
A estrutura da figura 8 implica diversas declarações independentes: I(A;D,G), I(B;D,G | A),
I(C;A,D,G | B), I(D;A), I(E;A,B,F,G | C,D), I(F;A,B,D,E,G | C) e I(G;A,B,C,E,F | D). Também implica
que a distribuição conjunta tenha o seguinte produto: P(A,B,C,D,E,F,G) = P(A)P(B | A)P(C |
B)P(D)P(E | C,D)P(F | C)P(G |D).
Uma rede bayesiana é a representação de uma distribuição de probabilidade conjunta. Esta
representação é constituída por dois componentes. O primeiro componente, G, é um grafo acíclico
direccionado (DAG) cujos vértices correspondem ás variáveis aleatórias
!
X1, …,
!
Xn. O segundo
componente,
!
" , descreve uma distribuição condicional para cada variável, dados os parentes em
G. Juntos, os dois componentes especificam um distribuição única
!
X1, …,
!
Xn(Friedman, 2000). O
grafo G representa suposições de independência condicional que permitem à distribuição conjunta
ser decomposta, diminuindo o número de parâmetros. O grafo G codifica a suposição de Markov:
(*) Dados os parâmetros em G, cada variável
!
Xi é independente dos seus não descendentes.
Aplicando a regra da cadeia de probabilidades e propriedades de independências condicionais,
qualquer distribuição condicional que satisfaça (*) pode ser decomposta na forma de produto
!
P(X1,…, Xn) = P(X
i|Pa
G(X
i))
i=1
n
" ,
onde
!
PaG(X
i) é o conjunto de parentes de
!
Xi em G. A figura 8 demonstra um exemplo de um
grafo G e lista as independências de Markov.
Abordagens para a Detecção de Fraude
28
Um grafo G especifica uma forma de produto, tal como está representado na fórmula em cima.
Para especificar completamente uma distribuição conjunta, também é necessário especificar cada
uma das probabilidades condicionais na forma de produto. A segunda parte da rede bayesiana
descreve estas distribuições condicionais,
!
P(Xi|Pa
G(X
i)) para cada variável
!
Xi. Os parâmetros
que especificam estas distribuições são representados por
!
" (Friedman, 2000). Ao especificar
estas distribuições condicionais, podemos escolher dentro de diversas representações. Para este
caso irão ser utilizadas duas representações. Suponhamos que os ascendentes da variável X são
!
U1,…,U
k{ }. A escolha da representação depende do tipo das variáveis com que se está a lidar:
• Variáveis discretas – Se cada X e
!
U1,…,U
k tira valores discretos de um conjunto
finito, podemos então representar
!
P(X |U1,…,Uk) como uma tabela que especifica a
probabilidade de valores para X para cada atribuição conjunta
!
U1,…,U
k. Desta forma,
por exemplo, se todas as variáveis são binárias, a tabela especificará
!
2k distribuições. Isto
é uma representação geral que poderá descrever qualquer distribuição condicional
discreta. Assim, não se perde expressividade utilizando esta representação. Esta
flexibilidade tem um preço; o número de parâmetros livres é exponencial ao número de
parentes (Friedman, 2000).
• Variáveis contínuas – Ao contrário do caso das variáveis discretas, quando a variável X
e os seus ascendentes
!
U1,…,U
k contêm realmente valores, não existe representação que
consiga representar todas as densidades possíveis. A escolha natural para distribuições
multi-variadas contínuas é a utilização de distribuições Gaussianas. Estas podem ser
representadas numa rede bayesiana utilizando densidades condicionais lineares
Gaussianas. Nesta representação, a densidade condicional de X dados os seus ascendentes
é dada por:
!
P(X | u1,…, uk) ~ N(a0 + a
i" u
i
i
# ,$ 2).
em que X é normalmente distribuído por uma média que depende linearmente dos valores
dos seus parentes. A variância desta distribuição normal é independente dos valores dos
parentes. Se todas as variáveis na rede tiverem distribuições condicionais lineares
Gaussianas, então a distribuição conjunta é Gaussiana multi-variada (Friedman, 2000).
• Redes híbridas – Quando a rede contém uma mistura de variáveis discretas e contínuas,
é necessário considerar como representar a distribuição condicional para uma variável
Abordagens para a Detecção de Fraude
29
contínua com parentes discretos e para uma variável discreta com parentes contínuos.
Apenas será considerado o primeiro caso. Quando uma variável contínua X tem parentes
discretos, utilizamos distribuições Gaussianas condicionais em que, para cada atribuição
conjunta aos parentes discretos de X, dados os seus parentes contínuos representamos
uma distribuição linear Gaussiana de X (Friedman, 2000).
Dada uma rede bayesiana, poderá quer-se responder a vários tipos de perguntas que envolvem a
probabilidade conjunta (por exemplo, qual a probabilidade de X = x dada a observação de algumas
das outras variáveis?) ou independências no domínio (por exemplo, serão X e Y independentes
uma vez observado Z?). Existe um conjunto de algoritmos que conseguem responder a tais
perguntas de forma eficiente explorando a representação da estrutura.
3.3.4 Detecção através de técnicas de Raciocínio baseado em Casos
O Raciocínio Baseado em Casos (CBR) é um paradigma de solução de problemas que em muitos
aspectos é diferente de outras aproximações de inteligência artificial. Em vez de se focar apenas
no conhecimento geral de um domínio de problema, ou fazer associações ao longo de
relacionamentos generalizados entre descrições e conclusões de problemas, CBR é capaz de utilizar
conhecimento específico de situações problemáticas (casos) concretas anteriores. Uma outra
diferença importante é que CBR utiliza uma aproximação incremental com aprendizagem
sustentada, visto que uma nova experiência é retida cada vez que um problema é resolvido, esta
fica imediatamente disponível para ser utilizada em situações futuras. Basicamente, o CBR detecta
uma situação fraudulenta relembrando uma situação semelhante e reutilizando informação e
conhecimento dessa situação. Cada tarefa realizada por um dado utilizador representa uma
experiência que disponibiliza um agente de informação acerca dos hábitos e preferências desse
utilizador. As tarefas realizadas em situações passadas podem oferecer algumas indicações sobre o
comportamento que um utilizador pode ter numa situação nova semelhante. Os casos também
disponibilizam informação utilizada para detectar padrões no comportamento do utilizador e
determinar a sua rotina. Um novo caso, ou um caso não resolvido é a descrição de uma nova
situação fraudulenta que terá de ser resolvida. Cada caso contém os atributos ou as palavras
chave relacionadas com determinado utilizador (Aamodt and Plaza, 1994). Diversos estudos
atribuíram evidência empírica para o papel dominante dos casos na solução de problemas
humanos. Schank (1982) desenvolveu uma teoria de aprendizagem baseada no registo de
Abordagens para a Detecção de Fraude
30
experiências de forma dinâmica, envolvendo estruturas de memória. Anderson mostrou que as
pessoas utilizam casos passados quando aprendem a resolver problemas. O método CBR tem
crescido rapidamente ao longo dos últimos anos, isto verifica-se pelo crescente aumento de artigos
e documentação, ferramentas disponíveis e aplicações de sucesso.
Uma característica importante do método de detecção CBR é a sua capacidade de aprendizagem. A
notação de raciocínio baseado em casos não só denota um método de raciocínio em particular,
independentemente de como os casos são obtidos, mas também denota um paradigma de
machine learning que permite aprendizagem sustentada por actualização dos casos depois da
fraude ter sido detectada. Quando uma situação fraudulenta é detectada com sucesso, a
experiência é retida de modo a detectar situações semelhantes no futuro. Quando uma tentativa
de solucionar um problema falha, a razão que levou à falha é identificada e é relembrada de forma
a evitar os mesmos erros no futuro. Raciocínio baseado em casos favorece a aprendizagem através
de experiências, visto que é normalmente mais fácil aprender retendo um problema em concreto
de uma experiência resolvida do que generalizar através da mesma. Ainda assim, a aprendizagem
eficaz em CBR requer um conjunto de métodos bem trabalhados de forma a extrair conhecimento
relevante da experiência, integrar um caso numa estrutura de conhecimento existente, e indexar o
caso para depois associar com casos semelhantes (Aamodt and Plaza, 1994).
Em termos gerais, um ciclo geral CBR pode ser descrito pelos quatro processos seguintes (Aamodt
and Plaza, 1994):
• recuperar o caso ou os casos mais semelhantes;
• reutilizar a informação e o conhecimento nesse caso para detectar a fraude;
• revisar a solução proposta;
• reter as partes da experiência que possam ser úteis para detectar situações fraudulentas
no futuro.
Uma descrição inicial da fraude define um novo caso. Este novo caso é usado para recuperar um
caso da colecção de casos anteriores. O caso recuperado é combinado com o novo caso – através
da reutilização – resultando num caso resolvido, ou seja, uma solução proposta para o problema
inicial. Através do processo de revisão esta solução é testada para ser bem sucedida, como por
exemplo sendo aplicada ao ambiente do mundo real ou avaliada por um professor, e reparada em
Abordagens para a Detecção de Fraude
31
caso de falha. Durante a retenção, a experiência útil é retida para futura reutilização, e o caso base
é actualizado por um novo caso aprendido ou pela modificação de alguns casos existentes (Aamodt
and Plaza, 1994). Depois de se obterem os casos, o próximo passo consiste em classificaá-los por
ordem descendente do total de similaridade em relação ao caso de referência. Para fazer o cálculo
desta similaridade pode-se utilizar a seguinte fórmula (Almeida, et al., 2008):
!
CaseSim(C1,C2) =wi* AtrSim((A(i,C1), A(i,C2)))
ni=1
n
"
na qual:
• C1 é o caso de referência;
• C2 é o caso a ser comparado;
• n é o número de atributos a serem comparados;
• i é o índice de um atributo do caso;
• wi é o peso associado ao atributo i;
• CaseSim é a função de métrica de similaridade entre os dois casos, retorna um valor no
intervalo [0, 1];
• AtrSim é a função de métrica de similaridade entre dois atributos, retorna um valor no
intervalo [0, 1];
• A retorna o calor do atributo I do caso C;
•
!
wi" é 1.
Os valores para os pesos dos atributos são compilados numa lista, deve-se questionar os analistas
acerca da importância de certos atributos no processo de classificação, de maneira a que os casos
mais similares sejam os mais importantes para eles. Após ter o conhecimento dos atributos mais
importantes é também necessário fazer as devidas distinções entre os mesmos. Para a função
AtrSim, dependendo do atributo, podem ser utilizadas diferentes fórmulas. Um exemplo pode ser a
utilização de métricas logarítmicas, matrizes de similaridade e em alguns casos uma simples
condição que retorne 1 quando o valor for idêntico à referência AtrSim ou 0 para os restantes
casos. Um exemplo de uma métrica logarítmica aplicada a um atributo exemplo “data_de_criação”
é (Almeida, et al., 2008):
Abordagens para a Detecção de Fraude
32
!
0" 1#log3 ( CD1#CD2 +1)
3.5$ 0
1#log3 ( CD1#CD2 +1)
3.5" 1#
log3 ( CD1#CD2 +1)
3.5>0
% & '
( '
As técnicas de inteligência artificial têm sido aplicadas com sucesso na detecção de fraude e na
área de inteligência artificial aplicada ao domínio financeiro. Como metodologia emergente, o CBR
está agora a fazer uma contribuição muito significativa na tarefa de detecção de fraude. Na frente
de investigação nesta área está a aplicação de sistemas de aprendizagem híbridos e adaptáveis a
problemas que anteriormente eram considerados demasiado dinâmicos ou complexos para
conseguir modelar e prever com precisão (Wheeler and Aitken, 2000).
Os sistemas CBR têm bastantes vantagens em relação a outras técnicas de inteligência artificial,
tais como (Wheeler and Aitken, 2000):
• disponibilizam confiança com significado e medidas precisas do sistema;
• requerem aquisição de conhecimento especializado mínimo ou nulo;
• actualização e manutenção fácil;
• articulam claramente o raciocínio por detrás da tomada de decisão;
• são flexíveis e robustos em dados em falta ou com ruído;
• podem ter em conta a relação custo/eficácia da investigação de falsos positivos e advertir
consequentemente;
• são facilmente integradas em variadas bases de dados standard.
A adição de componentes CBR adaptáveis podem permitir ao sistema (Wheeler and Aitken, 2000):
• optimizar a precisão da classificação ajustando e actualizando dinamicamente os pesos da
estrutura;
• utilizar múltiplos algoritmos para melhorar a precisão do diagnóstico final;
• melhor diferenciação entre os tipos de irregularidades e desenvolvimento de um sentido de
anormalidade que tem influência na detecção de novos tipos;
Abordagens para a Detecção de Fraude
33
Hoje em dia, começam a emergir sistemas híbridos que utilizam técnicas de inteligência artificial e
metodologias para melhorar a precisão na detecção de fraude. Enquanto que o avanço mais
comum tem sido a utilização de redes neuronais para aprender, prever e adquirir padrões de
utilização para detectar utilizações fraudulentas, têm sido desenvolvidos alguns sistemas baseados
em casos e sistemas híbridos, ambos com resultados excelentes. Aproximações de sistemas
híbridos, ou múltiplas aproximações com uma Framework CBR comum, estão a aumentar e a
tornarem-se comuns. Em (Schiaffino and Amandi, 2000) pode-se ver um estudo no qual se
descobriu que um sistema CBR/Redes Neuronal, que divide a tarefa de detecção de fraude em dois
componentes separados, foi mais eficaz que um isolado. A rede neuronal aprende padrões de
utilização e má utilização enquanto o CBR procura por melhores combinações de acordo com o
caso base. Este por sua vez contém informação como datas de transacções e quantidades, datas
de roubo, locais das ocorrências, tipos de transacções, tipos de loja etc.
As ferramentas comerciais são necessárias de forma a facilitar o processo de selecção, indexação,
avaliação, adaptação e gestão dos casos. As ferramentas comerciais actuais estão principalmente
orientadas à aquisição e devolução de casos e á avaliação e adaptação dos mesmos. As mais
conhecidas são: o REMIND (Systems, 1996), é uma ferramenta interactiva genérica para
prototipagem rápida e desenvolvimento de aplicações CBR orientadas à classificação, previsão e
tarefas de data mining, e o ReCall (Isoft, 1990) que também é uma ferramenta genérica e tem
sido aplicada no desenvolvimento de aplicações de diagnósticos de falha, análise de crédito
bancário, ensino, análise de riscos, controlo e supervisão. Um aspecto interessante do ReCall é que
a linguagem de representação orientada aos objectos utilizada para representar os casos permite
representar conhecimento ambíguo. Outra ferramenta é o S3-Case do teclnno Gmbh, orientada ao
diagnóstico da solução de problemas (Mántaras and Plaza, 1997).
Em suma, podemos dizer que o CBR invoca uma maneira paradigmática de atacar questões de
inteligência artificial, nomeadamente métodos de raciocínio, aprendizagem, utilização de
conhecimento geral e específico, e combinando os diferentes métodos. Em particular, verifica-se
que CBR dá ênfase à solução de problemas e à aprendizagem como dois lados da mesma moeda:
por um lado a solução de problemas utiliza os resultados de episódios de aprendizagens do
passado, por outro lado disponibiliza a base da experiência pelo qual a aprendizagem evolui. O
estado da arte na Europa sobre CBR é caracterizada por uma forte influência das ideias
provenientes dos Estados Unidos e dos sistemas de CBR, contudo, a Europa está a evoluir na área
Abordagens para a Detecção de Fraude
34
e disponibiliza diferentes aproximações de CBR, particularmente nas suas diversas actividades
relacionadas com a integração de CBR e através do seu movimento perante o desenvolvimento de
aplicações orientadas a sistemas CBR (Aamodt and Plaza, 1994).
As tendências de desenvolvimento de métodos CBR podem ser agrupadas em quatro tópicos
principais: integração com outros métodos de aprendizagem, integração com outros componentes
baseados em raciocínio, incorporação de processamento paralelo e aplicação de métodos com foco
em novos aspectos cognitivos. As características das aplicações CBR indicam claramente que
iremos ver bastantes aplicações de apoio a utilizadores para suporte e resolução de problemas
técnicos em telecomunicações e tecnologias de informação em nosso redor. Este tipo de sistemas
pode adoptar uma solução mais geral do CBR, de sistemas de inteligência artificial em geral para
sistemas de informação. O uso de casos para pesquisa humana e tomada de decisão também
resulta num aumento de interesse em treino, ensino e aprendizagem auxiliada pelo computador. O
papel importante de interacção do utilizador, controlo flexível e o percurso perante a
interactividade total dos sistemas favorecem uma aproximação baseada em casos para assistência
inteligente, visto que os sistemas CBR são capazes de aprender continuamente e evoluir através de
experiências passadas que vão sendo capturadas. CBR possui, neste momento, um elevado grau
de optimismo em inteligência artificial e conhecimento baseado em sistemas de suporte em
particular. A quantidade crescente de investigação em CBR tem o potencial de aumentar as
inovações significativas de métodos e aplicações de inteligência artificial (Aamodt and Plaza, 1994).
3.3.5 Detecção baseada em Assinaturas
Basicamente, uma assinatura de um cliente é definida por um conjunto de variáveis cujos valores
sumarizam o comportamento típico de um utilizador em determinado período de tempo. As
variáveis podem ser simples, se contêm um valor atómico único, ou podem ser complexas, quando
contêm duas variáveis co-dependentes, normalmente a média e o desvio padrão. Quando se refere
a um utilizador de telefones móveis, a sua informação pode conter: o número de chamadas, o
tempo total de chamadas, a localização das chamadas etc. Se a qualquer momento um utilizador
desvia o comportamento típico expressado pela sua assinatura, isto pode ser motivo para lançar
um alarme indicando que a situação deverá ser investigada.
Abordagens para a Detecção de Fraude
35
A detecção em tempo real de comportamento fraudulento facilita a sua identificação preliminar e
permite o desenvolvimento atempado de estratégias de prevenção apropriadas. Devido ao grande
volume de informação que é processada nos sistemas on-line, é por vezes difícil perceber, e
correctamente analisar em tempo real, grandes conjuntos de dados que resultam das transacções
diárias. Como possível solução, alguns investigadores têm adoptado o uso de assinaturas para
descrever a diversidade dos padrões comportamentais. Estas assinaturas são essencialmente uma
representação matemática da actividade fraudulenta ou de outro comportamento anormal. Podem
ser utilizadas para detectar actividade fraudulenta através de um dos seguintes métodos:
1. detecção baseada em perfis
2. detecção baseada em anomalias
A detecção baseada em perfis envolve a comparação do comportamento resultante de transacções
recentes com comportamento fraudulento conhecido. Em contraste, a detecção baseada em
anomalias compara o comportamento das transacções recentes com comportamento legítimo
conhecido, este comportamento passado é representado por assinaturas. Para medir o nível de
actividade fraudulenta associada a uma ou mais transacções, existem duas medidas de
probabilidade que devem ser primeiramente calculadas. A primeira é a probabilidade da transacção
ser fraudulenta. Isto é feito comparando matematicamente assinaturas de fraude conhecidas com
a transacção que está a ser avaliada. A segunda medida é a probabilidade da transacção ser
legítima. Isto é efectuado comparando matematicamente o utilizador ou o perfil de entidade,
derivado de transacções legítimas do passado, com a transacção a ser medida. Depois das duas
medidas serem calculadas é possível atribuir um resultado global de fraude.
Existem dois modelos de processamento que são normalmente utilizados para actualizar
assinaturas, são eles: orientado ao tempo e orientado ao evento. Na actualização orientada ao
tempo, os registos são coleccionados e temporariamente armazenados em determinado período de
tempo. No fim desse tempo, os registos são agregados e a assinatura é actualizada. Na
actualização orientada ao evento, dependendo das entradas de novos registos, a assinatura
associada é constantemente actualizada. Cada um destes métodos tem as suas limitações e
tornam-se evidentes quando se considera o significado de actualização (Cortes and Pregibon,
2001). A actualização de uma assinatura é realizada em três passos principais: ler a assinatura do
disco ou memória, mudar o valor da assinatura utilizando um algoritmo estatístico e finalmente
Abordagens para a Detecção de Fraude
36
reescrever a assinatura no disco ou memória. O método orientado ao evento permite uma
actualização em tempo real, no entanto, a carga de I/O (input/output) pode ser demasiado grande
quando o tamanho dos dados da assinatura é muito elevado para ser armazenado em memória. O
método de processamento orientado ao tempo requer menos I/O, contudo, o espaço em disco que
é temporariamente necessário pode ser muito grande. Em sistemas de detecção de fraude, onde o
factor tempo é crucial, o método de processamento orientado ao evento é melhor. Os altos custos
resultantes da fraude ditaram este modelo como preferido.
De acordo com Cortes e Pregibon (2001) ambos os métodos de processamento, orientado ao
evento e orientado ao tempo, seguem o mesmo modelo computacional. Considere-se
!
St uma
assinatura e R um registo ou um conjunto de registos que estão disponíveis num determinado
período t. A assinatura
!
St é constituída por um conjunto de variáveis que podem ser distribuições
de probabilidade ou características de interesse, tais como o número total de chamadas por
exemplo. Os registos R devem ser processados antes da assinatura ser actualizada, o seu formato
deve ser idêntico ao de
!
St, o resultado da transformação de R será representado por
!
TR. No
momento t + 1 é necessário criar a nova assinatura
!
St+1 que é uma actualização de
!
St em
conjunto com
!
TR. Percorrendo todos os elementos, deve ser efectuada a actualização utilizando a
seguinte formula:
!
St+1 = " # S
t+ (1$") #T
R
A variável
!
" indica o peso das novas transacções
!
TR no valor da nova assinatura, determina a
quantidade de peso que é dado à informação nova ou se foi dado pouco peso aos dados antigos.
Para a actualização orientada ao tempo o valor de
!
" é normalmente constante. É possível ajustar
o valor de
!
" de acordo com o valor da janela temporal definida. Com a informação obtida até esta
fase obtém-se dois vectores com parâmetros diferentes, são o
!
TR e S. De acordo com Ferreira, et
al. (2006) estes vectores podem ser comparados e a distância entre eles pode ser calculada. Visto
que cada componente da assinatura pode ser simples ou complexo, devem ser avaliados por uma
sub-função em separado. Irão existir funções diferentes para definir a distância final, que é
traduzida pela seguinte fórmula genérica:
!
dist = "( f1, f
2, f
3,…)
Abordagens para a Detecção de Fraude
37
Desta forma é possível actualizar a assinatura se certo limiar ", definido pelos analistas, é atingido.
Se
!
dist(St,T
R) " # então a assinatura é actualizada, senão é gerado um alarme e o caso deverá
ser analisado e posteriormente validado. Para melhor compreender como é efectuado este cálculo,
no trabalho de Ferreira, et al. (2006) é apresentado um exemplo semi-formal para compreender
como é calculada a distância em maior detalhe. Consideremos uma assinatura
!
St, tal que
!
St
= (µa,"
a),µ
b,µ
c{ }, o primeiro elemento é complexo e os últimos dois elementos são simples.
Do mesmo modo, temos o exemplo de um conjunto de transacções
!
TR de determinado período de
tempo, já processadas, a sua representação é dada por
!
TR
= (µ'a," '
a),µ'
b,µ'
c{ } . Com base no
que foi anteriormente visto, a fórmula
!
dist(St,T
R) pode ser traduzida por:
!
dist(St ,TR ) ="1# f
1(St # a,TR # a) +"
2# f
2(St # b,TR # b) +"
3# f
3(St # c,TR # c)
Esta fórmula pode ser traduzida como combinação linear de cada uma das variáveis. Cada função
!
f é diferente dependendo se o tipo da variável é simples ou complexa. Finalmente a constante
!
"
é um factor de peso sobre cada uma das agregações utilizadas no cálculo da distância, desta
forma os analistas podem dar mais importância a atributos que considerem mais relevantes. Cada
uma das funções
!
f pode ser calculada de diversas formas, no trabalho de Ferreira, et al. (2006)
optaram por utilizar distribuições de probabilidade, para os casos de variáveis complexas foi
utilizada a distribuição Normal e para variáveis simples foi utilizada a distribuição de Poisson. De
qualquer forma, de notar que a função de distância tem diversas vertentes, o que foi referido aqui
pode ser modificado ou mesmo substituído caso seja necessário.
Muitas vezes, as actividades contínuas de determinados utilizadores reflectem comportamentos
que, na maior parte dos casos, aparentam ser fraudulentos. Por exemplo, se um utilizador efectuar
30 chamadas, cada uma com a duração inferior a um minuto, durante a noite, provavelmente a
informação será reencaminhada para os analistas como um caso suspeito. Infelizmente, nem
sempre estas situações devem ser alarmadas, mesmo que a actividade em questão seja
completamente diferente do que está armazenado no histórico. Por esse motivo, é necessário
reduzir o número de falsos positivos. Uma possível solução é manter uma assinatura legítima da
actividade das entidades na rede e manter também uma assinatura não real fraudulenta. Desta
maneira, é possível aplicar algoritmos probabilísticos que após a recepção de uma chamada, o
Abordagens para a Detecção de Fraude
38
sistema faz a computação da probabilidade de observar a chamada assumindo que esta é
proveniente de uma conta legítima, relativamente à probabilidade de observar a chamada
assumindo que esta vem de uma conta fraudulenta. De seguida a fórmula que reflecte a ideia aqui
exposta:
!
isFraude(chamada) =P(chamada | assinatura_ legítima)
P(chamada | assinatura_ frudulenta)
3.3.6 Migração de Assinaturas entre Clusters
Clustering o que faz é agrupar informação semelhante de um conjunto de dados em grupos bem
definidos. As semelhanças que derivam dos grupos dependem do objectivo ou foco em análise. As
técnicas de clustering são baseadas em padrões visuais que realçam as semelhanças e as
irregularidades em volumes de dados grandes. Quando os dados estão sujeitos a técnicas de
análise através de clustering, um conjunto de regras bem definidas são aplicadas ao conjunto de
dados e as equivalências resultantes são agrupadas segundo um padrão comum. O tamanho e a
densidade dos dados agrupados disponibilizam uma representação visual da frequência e robustez
de cada grupo em particular. Um grupo muito pequeno pode ser indicação de comportamento
irregular e deve ser analisado. Em (Ferreira, et al., 2007) foi feita alguma investigação adicional na
área de detecção de fraude, isto aconteceu porque foram encontradas alguns pontos susceptíveis
a análise no trabalho anterior de detecção de fraude baseado em assinaturas (Ferreira, et al.,
2006). Algumas linhas de trabalho que são normalmente utilizadas nos modelos de data mining,
baseadas em técnicas de clustering, poderiam ser aplicadas a cenários de detecção de fraude com
algum sucesso. Através da análise de semelhanças entre assinaturas pode ser construída uma
matriz de semelhanças onde é possível relacionar as semelhanças. Esta matriz pode ser definida
como um conjunto de valores
!
m " n ordenados, representado na forma de uma matriz com
!
m
linhas e
!
n colunas. Cada linha e cada coluna do vector recebe uma assinatura, o conjunto de
valores corresponde à similaridade entre as assinaturas. Tipicamente cada valor está contido no
intervalo
!
0,1[ ].
O processo de calcular a similaridade entre assinaturas está descrito pelas funções de distância em
baixo descritas (Ferreira, et al., 2007). Para dimensões do tipo simples a função é dada por:
Abordagens para a Detecção de Fraude
39
!
d(Mx, My ) = e"
M x "M y #C
Amp
$
%
& &
'
(
) )
onde, d(Mx, My )* 0,1[ ]
As variáveis
!
Mx e
!
My representam os valores das dimensões simples, o valor da variável C é
uma constante definida por defeito e o valor da variável Amp é a amplitude do tamanho observado
de todas as assinaturas.
Para as dimensões do tipo composto a função é:
!
d((Mx," x ),(My," y )) = d(Mx, My ) #X$Y
X%Y
onde, d((Mx," x ),(My," y ))& [0,1]
X = [Mx '" x;Mx +" x ] e Y = [My '" y;My +" y ]
!
(Mx,"
x) e
!
(My," y ) são dois valores complexos,
!
d(Mx, My ) é a função de distância
anteriormente representada para dimensões do tipo simples e
!
X"Y
X#Y é a percentagem da
intersecção entre as assinaturas e pertence ao intervalo
!
0,1[ ].
Finalmente, existe uma função de distância que combina as similaridades de cada dimensão das
assinaturas. O objectivo é medir a distância entre ambas, de acordo com todas as suas n
dimensões (Ferreira, et al., 2007). A função corresponde está em baixo representada:
!
D(x,y) = W1" d
1(x1,y1)2 +…+Wn " dn (xn ,yn )
2
onde, D(x,y)# 0,1[ ]
A variável
!
W representa o peso de cada dimensão, desta forma é possível atribuir diferentes
importâncias a cada dimensão. A matriz de similaridade resultante é depois processada por uma
Abordagens para a Detecção de Fraude
40
ferramenta de data mining e as assinaturas são distribuídas pelos diferentes clusters. Resumindo o
processo, temos, então, os seguintes passos principais:
1. Ler os dados de entrada;
2. Construir a matriz de semelhanças;
3. Processar a matriz com a ferramenta de data mining;
4. Gerar os resultados.
Finalmente, para perceber como são disponibilizados os perfis de utilização, será feita uma breve
explicação sobre os clusters das assinaturas. Para cada instância de um período de tempo é
disponibilizada uma topologia de cluster. Esta topologia descreve os padrões de utilização dos
clientes durante esse período. Cada cluster é traduzido pelas características do seu centróide. Este,
por sua vez, é definido como uma assinatura. Desta forma é possível fazer comparações directas
entre as assinaturas e os centróides dos clusters. A atribuição de uma assinatura a um cluster é
feita comparando cada assinatura com cada centróide dos clusters, o cluster com a distância mais
pequena é o escolhido.
Para fazer as comparações, existem duas medidas de similaridade que devem ser definidas,
similaridade absoluta e relativa. A similaridade absoluta define a similaridade entre o valor da
assinatura e do centróide num determinado momento temporal t, o valor é obtido através da
função de distância final. A similaridade relativa refere-se à similaridade absoluta entre o instante t
e t+1, disponibilizando a percentagem de variação entre duas instâncias temporais consecutivas. O
valor é obtido através da seguinte fórmula (Ferreira, et al., 2007):
!
R = 1"D(S
i, AssinCl S
i[ ]t+1)
D(Si, AssinCl S
i[ ]t)
# $ %
& ' ( )100%
A variável
!
Si corresponde à assinatura, e
!
AssinCl Si[ ] ao cluster a que
!
Si pertence no momento
t. A figura em baixo (Figura 9) mostra uma variação positiva, onde a assinatura
!
Si está mais
próxima do Cluster3 no instante t e mais próxima do Cluster1 no instante t+1.
Abordagens para a Detecção de Fraude
41
Figura 9 - Exemplo de migração de clusters
Abordagens para a Detecção de Fraude
42
Implementação de abordagens para a Detecção de Fraude
43
Capítulo 4
4Implementação de Abordagens para a Detecção
de Fraude
Para analisar a performance de cada método serão utilizadas curvas de ROC (Receiver Operating
Characteristic), método este utilizado na maior parte das experiências. Estas curvas debruçam-se
mais sobre a sensibilidade à assimetria do que sobre a sensibilidade ao custo. É possível analisar a
fracção entre a percentagem de verdadeiros positivos e falsos positivos. A área resultante chama-
se AUC (Area Under Cover) e representa a probabilidade de um classificador colocar um exemplo
positivo, escolhido aleatoriamente, mais alto na ordenação do que um exemplo negativo.
4.1 Um Sistema baseado em Regras e Redes Neuronais
Um dos objectivos do projecto Europeu ASPECT (Advanced Security for Personal Communication
Tecnologies) (Jefferies, 1998) foi o desenvolvimento de técnicas de detecção e gestão de fraude
para redes GSM. O grupo de investigação da Siemens desenvolveu uma ferramenta baseada em
Regras e um grupo de investigação da Universidade católica de Leuven, em conjunto com uma
equipa da Universidade Royal Holloway de Londres, implementaram uma ferramenta de Redes
Neuronais através de aprendizagem supervisionada e não supervisionada (Verrelst, et al., 1999).
Implementação de abordagens para a Detecção de Fraude
44
Para os exemplos de fraude utilizados nesta experiência foram coleccionadas amostras da rede
TACS de uma operadora móvel. Estes dados contêm um total de 317 utilizadores fraudulentos que
geraram 131.594 registos de chamadas. O exemplo de dados de utilização teve origem numa
amostra de três meses, a partir de 20.212 utilizadores, totalizando cerca de três milhões de
registos. O número de utilizadores fraudulentos neste conjunto de dados espera-se que seja
reduzido. Foram seleccionados 562 utilizadores do conjunto de dados, 62 desses utilizadores
foram seleccionadas dentro do conjunto de utilizadores que efectuaram chamadas internacionais.
Apenas foram considerados os registos dos primeiros quarenta dias. Os dados a avaliar foram
separados num conjunto de treino e num conjunto de teste (Verrelst, et al., 1999).
A principal característica da detecção de fraude é a importância que existe na relação entre a
detecção de utilizadores fraudulentos e a produção de falsos alarmes. Para avaliar a performance
de cada técnica, tal como foi descrito no início desta secção, nas experiência deste estudo serão
utilizadas as curvas de ROC para analisar a percentagem de utilizadores fraudulentos correctos
contra a percentagem de falsos alarmes de utilizadores não fraudulentos (Verrelst, et al., 1999).
Inicialmente, o sistema foi testado com a ferramenta de redes neuronais através de aprendizagem
não supervisionada com o objectivo de detectar alterações específicas de comportamento em
utilizadores que efectuam chamadas internacionais. A ferramenta monitoriza os países destino das
chamadas dos utilizadores de subscrição. Aos destinos das chamadas são atribuídos diferentes
pesos de forma a dar maior importância a destinos considerados fraudulentos. Os perfis são
mantidos como uma distribuição de probabilidade do destino da chamada para o perfil actual do
utilizador e para o perfil histórico. A ferramenta de fraude utiliza o registo do perfil, constituído
pelo perfil actual e histórico, como input e calcula uma distância modificada sobre todas as
entradas relativas ao perfil. A curva de ROC resultante obteve uma performance de 54,4% com o
conjunto de treino e 57,9% com o conjunto de teste (Verrelst, et al., 1999).
A mesma ferramenta foi depois utilizada com o objectivo de detectar alterações no comportamento
do utilizador normal. São gerados dois registos de perfil para cada utilizador considerando dois
intervalos de tempo diferentes sobre os registos das chamadas. A rede neuronal não
supervisionada tem como base uma técnica de prototipagem, formando uma representação óptima
de uma variável contínua. A curva de ROC resultante obteve uma performance de 54,56% com o
conjunto de treino e 57,75% com o conjunto de teste (Verrelst, et al., 1999).
Implementação de abordagens para a Detecção de Fraude
45
Numa fase posterior, a ferramenta de redes neuronais foi testada com aprendizagem
supervisionada. Esta técnica tem a vantagem de não ser necessário a intervenção de um
especialista para fazer o desenho de regras. O classificador utilizado neste sistema de detecção de
fraude é linear, com uma única camada de neurónios de sigmóide logística. Existem duas classes
problema onde é utilizado um erro quadrado pesado como função de custo. É efectuada a
minimização utilizando o algoritmo Levenberg-Marquardt. Para maximizar a performance de dados
ocultos, como procedimento de regularização, os pesos são diminuídos. São determinados os
pesos óptimos utilizando o procedimento de minimização, mas são inicializados vários ao mesmo
tempo para evitar mínimos locais. Estes procedimentos devem ser repetidos para as diferentes
arquitecturas da rede neuronal com o objectivo de encontrar a arquitectura óptima. Uma vez
encontrada, apenas é necessário utilizá-la para produzir um valor de alarme entre 0 e 1 cada vez
que registos de chamadas entram na ferramenta de detecção. A curva de ROC resultante obteve
uma peformance de 87,17% com o conjunto de treino e 85,63% com o conjunto de teste
(Verrelst, et al., 1999). De seguida os gráficos (Figura 10 e 11) que traduzem estes valores:
Figure 10 - Resultado com o conjunto de teste
Implementação de abordagens para a Detecção de Fraude
46
Hoje em dia praticamente todas as ferramentas de detecção são baseadas em regras ou então
contêm um componente que é baseado em regras. O sistema foi testado com uma ferramenta
baseada em regras através de aprendizagem supervisionada. Esta aproximação permite detectar
fraudes específicas com uma percentagem baixa de falsos alarmes. Este tipo de sistema está
implementado para que facilmente um alarme seja lançado. A estratégia utilizada é baseada em
profiling e tem funcionalidades semelhantes ás existentes na rede neuronal supervisionada. As
regras responsáveis pelo lançamento dos alarmes são desenhadas manualmente por especialistas.
A curva de ROC resultante obteve uma performance de 81,24% com o conjunto de treino e
85,63% com o conjunto de teste (Verrelst, et al., 1999).
No final, foram integradas as quatro técnicas de detecção de fraude num único sistema de
detecção ao qual chamaram de BRUTUS. O propósito desta junção é combinar e aproveitar os
pontos fortes de cada uma das técnicas. A ferramenta integrada processa os registos de
chamadas de forma sequencial, percorrem a arquitectura acumulando informação relativa à análise
em questão. Cada um dos componentes tem a habilidade de usar a informação para as suas
próprias decisões. Os alarmes gerados pelo sistema integrado são depois geridos por uma
ferramenta de monitorização que serve como interface gráfica para os analistas. A curva de ROC
resultante obteve uma performance de 88,45% com o conjunto de treino e 90,08% com o
conjunto de teste. A integração dos vários componentes permitiu um aumento de 2% na
Figura 11 - Resultado com o conjunto de treino
Implementação de abordagens para a Detecção de Fraude
47
performance das curvas de ROC em relação ao melhor resultado das técnicas utilizadas
separadamente, rede neuronal com aprendizagem supervisionada respectivamente. Mas a grande
vantagem é que o comportamento da ferramenta integrada na região dos falsos positivos
melhorou consideravelmente. Com 0.02% de falsos alarmes, a rede neuronal supervisionada
detecta 40% dos utilizadores fraudulentos com o conjunto de teste e com o conjunto de treino, a
ferramenta integrada detecta 45% dos utilizadores fraudulentos com o conjunto de treino e 50%
com o conjunto de teste. Foi gerada uma lista de 27 utilizadores suspeitos nos primeiros 40 dias de
dados onde 3 eram fraudulentos. De acordo com a operadora móvel em questão a proporção de
falsos alarmes é útil para as operações realizadas diariamente (Verrelst, et al., 1999).
4.2 Detecção de Fraude baseada num modelo de Comutação
de Regime
Nesta secção é apresentado um sistema de detecção em tempo real que é baseado num modelo
estocástico gerador. No modelo gerador é utilizada uma variável “vitimizado” que indica se a conta
foi vitimizada por um criminoso, e uma segunda variável “fraude” que indica se o criminoso em
determinado momento está a cometer fraude. Ambas as variáveis são ocultas. Também existe uma
variável “chamada” que indica se uma chamada está a ser efectuada no momento. As
probabilidades de transacção desde sem-chamada para chamada e desde chamada para sem-
chamada são dependentes do estado da variável “fraude”. Em geral, obtém-se um modelo de troca
de regimes de séries temporais (Hamilton, 1994), com a diferença de que as variáveis nas séries
temporais não são contínuas mas sim binárias e a variável de troca tem uma estrutura hierárquica.
A vantagem da estrutura hierárquica é que permite modelar as séries temporais em escalas de
tempo diferentes. Num nível mais baixo é modelado o comportamento dinâmico de chamadas
individuais, no nível intermédio é modelada a transacção de comportamento normal para
comportamento fraudulento, no nível superior é modelada a transacção que foi vitimizada. Como
as variáveis ocultas contêm um número pequeno de estados não é necessário trabalhar com
técnicas de aproximação complicadas (Hollmén and Tresp, 1999).
O problema de detecção é formulado como um problema de inferência no regime de
probabilidades baseado em dados de subscrição. São derivados algoritmos iterativos para estimar
as variáveis ocultas “fraude” e “vitimizado”, baseado em dados presentes e passados ou baseado
Implementação de abordagens para a Detecção de Fraude
48
num conjunto completo de dados observados. Através de dados observados, são apresentadas
regras EM para a aprendizagem de parâmetros no modelo. Foi desenvolvida uma abordagem
baseada em gradientes para fazer a afinação dos outputs de probabilidades do estado não-fraude
e melhorar a capacidade de distinção no modelo. Através de resultados experimentais verifica-se
que um sistema correctamente afinado com dados reais pode ser usado para detectar
comportamento fraudulento baseado em padrões de chamadas (Hollmén and Tresp, 1999).
Na configuração dos dados existentes não se sabe quando é que as contas fraudulentas foram
vitimizadas por fraude. Esta é a razão da utilização do algoritmo EM para a aprendizagem de dois
regimes de dados numa configuração incompleta. Sabe-se, no entanto, quais as contas que foram
vitimizadas por fraude (Hollmén and Tresp, 1999).
Para testar a abordagem descrita foi utilizado um conjunto de dados com 600 contas legítimas e
304 contas fraudulentas. A janela temporal para as contas legítimas foi de 49 dias e para as contas
fraudulentas 92 dias. Os dados foram divididos em dois conjuntos, um conjunto de teste e outro
de treino. Através dos dados não fraudulentos foram estimados os parâmetros descrevendo o
comportamento normal de chamadas. De seguida, foi fixada a probabilidade de uma determinada
conta ser vitimizada e a probabilidade de deixar de ser vitimizada. Deixando estes parâmetros
fixos, os restantes parâmetros foram treinados usando as contas fraudulentas e o algoritmo EM
anteriormente descrito. O treino foi feito com aprendizagem não supervisionada, sabia-se que as
contas eram afectadas mas não era claro determinar quando a intrusão ocorria. Depois da
aprendizagem não supervisionada a capacidade de distinção foi reforçada, o que
consequentemente ajudou a reduzir o número de falsos alarmes (Hollmén and Tresp, 1999).
Depois de treinado, o sistema foi testado utilizando os dados de teste. Infelizmente, não se sabe
quando é que as contas são afectadas por fraude, apenas se tem a noção que em determinado
ponto uma conta foi vítima de fraude. Assim sendo, assume-se que uma conta é vitimizada se a
variável “vitimizado” ultrapassa um limiar pré-definido (Hollmén and Tresp, 1999).
Implementação de abordagens para a Detecção de Fraude
49
Depois do treino discriminativo e do treino efectuado com o algoritmo EM, o modelo foi testado
com detecção em tempo real e com classificação retrospectiva. Com uma probabilidade fixa de
falso alarme de 0,3%, as probabilidades de detecção para o conjunto de treino foram de 97%
para a detecção em tempo real e 93% para a classificação retrospectiva. Com um conjunto de
treino e uma probabilidade fixa de falso alarme de 2%, foram obtidas probabilidades de detecção
de 92,8% e 92% para a detecção em tempo real e para a classificação retrospectiva
respectivamente (Hollmén and Tresp, 1999).
Figura 12 - Curvas de ROC para a detecção em tempo real
Figura 13 - Curvas de ROC para a classificação retrospectiva
Implementação de abordagens para a Detecção de Fraude
50
4.3 Detecção de Fraude utilizando métodos Neuronais e
Probabilísticos
Neste estudo são apresentados três diferentes métodos para a detecção de fraude. Inicialmente é
utilizada uma rede neuronal baseada em aprendizagem supervisionada para aprender uma função
não-linear discriminante, entre classes de fraude e não-fraude, e classificar utilizadores de
subscrição através de sumários estatísticos. De seguida, um modelo Gaussiano é utilizado para
modelar a densidade de probabilidade do comportamento passado dos utilizadores de subscrição,
desta forma a probabilidade do comportamento actual pode ser calculada para detectar anomalias
em relação a comportamento passado. Por fim, são utilizadas redes Bayesianas para descrever as
estatísticas de um utilizador em particular e as estatísticas de diferentes cenários de fraude. As
redes Bayesianas podem ser utilizadas para determinar a probabilidade de fraude dado o
comportamento dos utilizadores de subscrição. Os dados utilizados em todos os métodos provêm
de CDRs, registos de chamadas criados para cada chamada telefónica efectuada, inclui informação
como identificação da pessoa que efectua a chamadas, hora de início da chamada, duração da
chamada etc (Taniguchi, et al., 1998).
Inicialmente foi testada a técnica de redes neuronais com aprendizagem supervisionada. A rede
neuronal pode ser utilizada para representar um mapeamento arbitrário não-linear, visto que
existem dados que exemplificam o mapeamento como pares input-output. O problema da
aprendizagem supervisionada consiste em adaptar os pesos da rede neuronal de forma a que os
mapeamentos de input correspondam ás amostras de input-output já conhecidas (Taniguchi, et al.,
1998). Os atributos utilizados neste método foram:
1. média da duração das chamadas realizadas por dia;
2. média do número total de chamadas realizadas por dia;
3. desvio padrão da duração das chamadas por dia;
4. desvio padrão do número total de chamadas realizadas por dia;
5. duração máxima de uma chamada por dia num determinado período de tempo;
6. número total de chamadas por dia num determinado período de tempo.
Implementação de abordagens para a Detecção de Fraude
51
Os dados utilizados incluem 303 amostras de utilizadores que exibem comportamento fraudulento
e 2100 utilizadores que exibem comportamento legítimo. Os dados foram divididos num conjunto
de treino e num conjunto de teste. Os outputs obtidos na rede neuronal foram interpretados como
a probabilidade de ocorrer fraude dados os inputs. A performance do detector da rede neuronal já
treinada é mostrada na figura (Figura 14) em baixo (Taniguchi, et al., 1998):
Verifica-se que o método de redes neuronais detecta 85% dos casos de fraude existentes sem
causar falsos alarmes (Taniguchi, et al., 1998).
Posteriormente, foi testado um modelo Gaussiano através de aprendizagem não supervisionada.
O problema de estimar a densidade de probabilidade é modelar a função de densidade de
probabilidade, dado um número finito de pontos obtidos através dessa densidade. O processo
passa por estimar a função de densidade de probabilidade do comportamento passado dos
utilizadores de subscrição e depois computar a probabilidade da utilização actual. O modelo
Gaussiano utilizado é o somatório de densidades de componentes ponderados na forma Gaussiana
(Taniguchi, et al., 1998). Os parâmetros do modelo de Gauss podem ser estimados utilizando o
algoritmo EM. Este algoritmo é uma aproximação geral para iterativamente computar estimativas
de probabilidade máxima quando as observações podem ser vistas como dados incompletos
(Taniguchi, et al., 1998). Os atributos utilizados nesta experiência são:
Figura 14 – Experiência com apendizagem
supervisionada
Implementação de abordagens para a Detecção de Fraude
52
• duração das chamadas que ocorreram durante o horário de trabalho no país;
• número de chamadas que ocorreram num dia durante o horário de trabalho no país;
• duração das chamadas que ocorreram durante o fim da tarde no país;
• número de chamadas que ocorreram num dia durante o fim da tarde no país;
• duração das chamadas que ocorreram durante a noite no país;
• número de chamadas que ocorreram num dia durante a noite no país;
• duração das chamadas que ocorreram durante o horário de trabalho fora do país;
• número de chamadas que ocorreram num dia durante o horário de trabalho fora do país;
• duração das chamadas que ocorreram durante o fim da tarde fora do país;
• número de chamadas que ocorreram num dia durante o fim da tarde fora do país;
• duração das chamadas que ocorreram durante a noite fora do país;
• número de chamadas que ocorreram num dia durante a noite fora do país.
Estes atributos são utilizados como inputs e é estimada a função de densidade de probabilidade, a
isto é chamado modelo geral. Consoante os dados vão estando disponíveis, logo após cada período
de observações, o modelo geral é especializado dinamicamente através de uma nova estimação,
da mistura dos dados incompletos, em cada utilizador de subscrição. Considerando que as médias
e as variâncias dos modelos específicos dos utilizadores de subscrição são comuns, apenas as
misturas dos dados incompletos são diferentes entre os modelos dos utilizadores de subscrição.
Este método é motivado pela sua viabilidade computacional. A performance é mostrada na figura
15. Verifica-se que o modelo Gaussiano detecta 70% dos casos de fraude existentes sem causar
falsos alarmes (Taniguchi, et al., 1998). A modelação específica de utilizadores de subscrição
através de mistura de dados incompletos permite criar perfis de subscrição e alteração lenta de
comportamento. Visto que se trata de aprendizagem não supervisionada, os resultados são
bastante satisfatórios.
Implementação de abordagens para a Detecção de Fraude
53
No final, foi testada uma rede bayesiana com aprendizagem supervisionada e não supervisionada
simultaneamente. Não existem regras determinísticas que nos permitam identificar um utilizador
de subscrição como fraudulento. No melhor caso, podemos formular o nosso grau de confiança
num comportamento fraudulento. Os modelos gráficos, tais como as redes Bayesianas,
disponibilizam uma Framework genérica para lidar com incertezas numa configuração
probabilística. Todos os grafos de redes Bayesianas codificam uma classe de distribuições de
probabilidade. Os nodos dos grafos são as variáveis do problema em questão. As setas entre os
nodos traduzem as relações entre as variáveis. Dados os pais de cada nodo, as dependências
resultantes são quantificadas por distribuições condicionais. De seguida, um exemplo (Figura 16)
de uma rede Bayesiana (Taniguchi, et al., 1998):
Figura 15 - Experiência com aprendizagem não
superviosionada
Implementação de abordagens para a Detecção de Fraude
54
Figura 16 – Exemplo de uma rede Bayesiana
Um profissional na área pode desenhar um grafo de acordo com os impactos casuais entre as
variáveis. As correspondentes distribuições condicionais podem ser injectadas pelo profissional
também, ele toma decisões de acordo com relações casuais ou estimadas pelos dados que utilizam
métodos de estimação tradicionais. Depois de construída, é possível inserir na rede Baysiana
probabilidades para variáveis desconhecidas (Taniguchi, et al., 1998).
Nesta experiência, foram construídas duas redes Bayesianas para descrever o comportamento dos
utilizadores de subscrição em telecomunicações. Uma das redes modela o comportamento
considerando que o utilizador é fraudulento e a outra rede modela o comportamento considerando
que o utilizador é legítimo. Após configurar e inserir evidência nas redes construídas, é possível
obter a probabilidade de uma medida em duas hipóteses, ou seja, obter julgamentos para que
grau um determinado utilizador vai de encontro a comportamento fraudulento ou legítimo. A curva
de ROC obtida está apresentada na figura 17 – por aqui consegue-se verificar que o modelo de
redes Baysianas detecta 70% dos casos de fraude existentes sem causar falsos alarmes
(Taniguchi, et al., 1998).
Implementação de abordagens para a Detecção de Fraude
55
Figura 17 - Experiência com aprendizagem supervisionada combinado com aprendizagem não
supervisionada
As redes Bayesianas permitem a integração de conhecimento, tal como foi efectuado inicialmente
na experiência. O exemplo construído utiliza não só integração como também tem a capacidade de
aprender, esta combinação do modelo do utilizador e de fraude oferece uma avaliação dos dados
bastante fiável.
4.4 Detecção de Fraude utilizando Rede Neuronal
Supervisionada
Nesta experiência foi simulada uma rede de telecomunicações. De acordo com características pré-
definidas, foi criado um processo aleatório onde centenas de utilizadores realizaram várias
chamadas. Estes utilizadores pertencem a seis tipos, variando desde utilizadores locais que fazem
poucas chamadas até utilizadores de negócio que fazem muitas chamadas internacionais. Nestes
grupos existe uma variação aleatória, desta forma é muito improvável que existam utilizadores
com características idênticas. Para cada utilizador, foi criado um perfil histórico, a metade dos
utilizadores está associado um perfil fraudulento de utilização recente e aos restantes utilizadores é
atribuído um perfil de utilização recente coincidente com o seu histórico (Barson, et al., 1996). Foi
criado um conjunto de treino para a rede neuronal a partir de todos os perfis de utilização.
Durante os testes, foi utilizado o mesmo conjunto de utilizadores mas com diferentes perfis de
Implementação de abordagens para a Detecção de Fraude
56
utilização recente, no entanto, em termos de percentagem, metade do conjunto pertence na
mesma a casos fraudulentos.
Com os dados de teste utilizados verifica-se um desempenho do sistema muito eficiente, os
resultados demonstram que 92.5% dos dados foram classificados correctamente . Porém, devem
ser analisados alguns pontos importantes relativamente ao sistema. O tamanho da janela temporal
utilizada para criar um perfil de comportamento recente tem grande influência na sua
performance, uma janela muito extensa pode resultar em situações onde a fraude ocorre sem ter
impacto suficiente no perfil de utilização normal, não sendo assim detectada. Por outro lado, se a
janela for muito pequena, variações normais podem resultar em falsos alarmes de comportamento
fraudulento. Outro ponto importante é o facto deste sistema não conseguir dar mais importância a
dados recentes. Finalmente, verifica-se alguma dificuldade da rede lidar com casos de
comportamento fraudulento desconhecido (Barson, et al., 1996).
4.5 Detecção de anomalias em padrões de utilização
baseada em Regras
Nesta experiência foi utilizado um modelo simples baseado em regras. O método desta experiência
utiliza CDRs de dois períodos: período de estudo e período de teste. O período de estudo contém
registos de clientes com comportamento legítimo e tem como propósito estudar o seu
comportamento normal e obter os valores apropriados para serem utilizados como limiares. Para
cada período foi desenvolvido um modelo probabilístico para descrever a sua utilização. Depois, foi
utilizada uma estimativa de probabilidade máxima para estimar os parâmetros do comportamento
das chamadas. Os parâmetros foram depois comparados com os limiares definidos. Qualquer
desvio que ultrapasse o limiar é utilizado para lançar um alarme. O método foi testado com 90 dias
de dados de estudo e 10 dias de dados de teste, foram considerados 500 clientes. Na janela de
teste, desde desvios médios até desvios grandes, o método foi capaz de identificar 90% do
comportamento anómalo com menos de 1% de falsos alarmes (Gopal and Meher, 2007). Na tabela
1 podemos observar os resultados obtidos para pequenos e grandes desvios verificados no período
de teste considerado.
Implementação de abordagens para a Detecção de Fraude
57
!"#$%
!
M2%&'(%
)*"#+%
,-.'/"01$%2$#%
3"-$/'#%)$#%
4"/5('./$#%
67('/$%(8)*$%)'%
9:"(")"#%
;</"01$%
(8)*"%)"%
9:"(")"%
&'(%
#'=<2)$#+%
67('/$%
)'%
9-*'2.'#%
><'%#'%
)'#3*"/"(%
?'#<-.")$%
!" !#" $%&'()"
*+,&-"."/0"1+%"
2)3&'&"
4&,5"."!0")3"!0"
(6&2"
7'8)%5"."!#"1+%"392"
*+,&-"."
:##"
4&,5"."0##"
7'8)%5"."
:##"
0##";%),62<+"."
!##="
/" !#" 1)>?)'&"
*+,&-"."!0"1+%"
2)3&'&"
4&,5"."@")3"!0"
(6&2"
7'8)%5"."0"1+%"392"
*+,&-"."
A/#"
4&,5"."B:#"
7'8)%5"."
B:#"
A0C";%),62<+"."
D!="
B" D#" 1)>?)'&"
*+,&-"."!0"1+%"
2)3&'&"
4&,5"."@")3"!0"
(6&2"
7'8)%5"."0"1+%"392"
*+,&-"."
A/#"
4&,5"."B:#"
7'8)%5"."
B:#"
A@0";%),62<+"."
DC="
A" D#" ')'E?3&"
*+,&-"."!B"1+%"
2)3&'&"
4&,5"."0")3"!0"
(6&2"
7'8)%5"."B"1+%"392"
*+,&-"."
B##"
4&,5"."B##"
7'8)%5"."
B##"
A";%),62<+"."
#5@="
Tabela 1 - Resultados para desvios grandes e pequenos no período de teste (Gopal and Meher,
2007)
Este método tem algumas desvantagens, a definição de limiares tem alguns problemas. Muitos dos
limiares variam consoante o tipo de conta, o tipo de chamada e a hora do dia. Esta situação pode
levar a geração de alarmes em contas legítimas.
4.6 Conclusão e análise das abordagens estudadas
Tal como foi visto na secção relacionada com a técnica de detecção baseada em redes neuronais,
esta apresenta bastantes dificuldades na aprendizagem não supervisionada para agrupar
separadamente os dados fraudulentos e os dados com utilização legítima. Facilmente se verifica
que, quando utilizada a mesma técnica, as experiências com aprendizagem não supervisionada
obtêm piores resultados do que com aprendizagem supervisionada. Esta situação é um pouco
Implementação de abordagens para a Detecção de Fraude
58
previsível na medida em que é mais difícil detectar uma situação fraudulenta se não existir
qualquer modelo de comparação. Isto não significa que a aprendizagem não supervisionada deve
ser “descartada”. Visto que não se baseia em amostras conhecidas, este tipo de aprendizagem
pode ser muito importante na descoberta de situações anómalas novas. Mesmo as métricas das
amostras conhecidas podem mudar com o tempo, devido ao avanço da tecnologia e a possíveis
mudanças na rotina de utilização dos clientes. Verifica-se assim que ambas as aprendizagens são
importantes e complementam-se, podendo muitas vezes ter objectivos diferentes na detecção. Por
exemplo, as situações novas resultantes da aprendizagem não supervisionada podem ser
armazenadas e utilizadas na aprendizagem supervisionada. Os valores obtidos nas experiências
confirmam esta afirmação, quando as técnicas de detecção são combinadas num sistema híbrido, é
possível melhorar os resultados esperados e diminuir o número de falsos alarmes. Estes sistemas
são mais completos, cada componente é mais específico e o sistema aprende mais rapidamente
com os casos que vão aparecendo.
Com base nos valores obtidos das curvas de ROC de todas as experiências, apesar de não terem
sido submetidos às mesmas condições, pode-se concluir que a técnica isolada (sem qualquer
combinação com outra técnica) que obteve melhores resultados foram as redes neuronais. Com
quantidades de dados e janelas temporais diferentes, as redes neuronais obtiveram sempre
resultados superiores.
A utilização de assinaturas para detectar fraude em tempo real tem muitas vantagens em relação a
outras técnicas. As assinaturas requerem muito menos recursos de armazenamento, são uma
representação dos dados e não a duplicação de todos os registos do conjunto de dados. As
assinaturas têm a capacidade de evoluir consoante o processamento das transacções. O número
de recursos necessários no processo de aprendizagem é significativamente reduzido, sempre que
uma transacção é processada as assinaturas são actualizadas, isto leva a pequena ou nenhuma
necessidade de calcular novamente a assinatura da fonte de dados. Para além disto, as assinaturas
são iniciadas a partir de dados legítimos de inúmeras possibilidades, portanto, é possível detectar
fraude de subscrição. Esta capacidade é muito importante no cenário de fraude que se vive
recentemente, com o avanço da tecnologia têm-se verificado uma mudança nos tipos de fraude,
principalmente na passagem da fraude de clonagem de cartões para a fraude de subscrição. Um
sistema capaz de acompanhar a evolução e as mudanças do tipo de fraude em tempo reduzido
poderá ser crucial para as organizações. Isto permite aos analistas perder menos tempo na gestão
Implementação de abordagens para a Detecção de Fraude
59
dos modelos existentes e dedicaram-se a outros tipos de problemas. Finalmente, as assinaturas
são relativamente rápidas a processar, o que reduz o impacto do processamento das transacções
em tempo real. As assinaturas podem ser adaptadas a qualquer tipo de fraude onde estejam
envolvidas transacções de contas de utilização. Isto inclui fraude de cartões de crédito, fraude na
área da saúde etc. Enquanto é necessário fazer investigação para trabalhar os detalhes de
aplicações em particular, o conceito de assinatura é amplo e potencialmente valioso para um
grande leque de aplicações.
Existe um problema muito comum nas técnicas de detecção baseadas em regras ou com limiares.
Depois de um cliente ter uma situação de alarme e entrar na lista de suspeitas, e se depois houver
a confirmação de que este era legítimo, quando este manifestar um tipo de utilização idêntico ao
que o alarmou vai voltar para a lista de suspeitas. Isto poderá ter consequências junto do cliente e
consome recursos e tempo que podem ser aproveitados para analisar outros casos fraudulentos. A
aproximação baseada em assinaturas é uma solução elegante para ultrapassar este tipo de
situações. Com esta técnica a assinatura vai-se adaptando à utilização do cliente, desta forma ele
não precisa de alterar o seu comportamento para não ser alarmado.
O sistema onde vai ser integrado o novo componente de detecção já possui um componente de
detecção baseado em regras e está em desenvolvimento um componente CBR. Neste sentido, e
com a análise efectuada, a escolha destas técnicas foi posta de parte. Pretende-se incluir um novo
componente que em conjunto com as técnicas existentes seja capaz de melhorar os resultados
existentes.
Pelos motivos até agora descritos, a técnica que vai mais de encontro ás necessidades do mercado
de telecomunicações neste momento é a técnicas baseada em assinaturas.
Implementação de abordagens para a Detecção de Fraude
60
Um Sistema de Detecção de Fraude em Telecomunicações
61
Capítulo 5
5Um Sistema para a Detecção de Fraude em
Telecomunicações
5.1 Análise e justificação da viabilidade do projecto
Antes de se avançar com uma análise detalhada dos requisitos deste projecto, pretende-se
verificar a viabilidade da implementação de um sistema piloto baseado em assinaturas para a
detecção de comportamentos desviantes em sistemas de telecomunicações. O objectivo é,
essencialmente, certificamo-nos de que, de um ponto de vista tecnológico e organizacional, o
projecto é viável. Para fazer esta avaliação procurou-se obter algumas respostas através da
interacção com pessoas interessadas e envolvidas no projecto, de forma a tentarmos obter uma
resposta para algumas questões importantes, em particular, se:
3. Dadas as restrições tecnológicas e temporais associadas ao projecto, será que o sistema
poderá ser implementado?
4. Se existir necessidade de integrar o sistema num sistema diferente, será que é possível?
A primeira questão foi bastante problemática na avaliação do projecto. Devido ao grande volume
de dados existente, e sabendo-se que o número de clientes cresce dia-para-dia, foi necessário
fazer um estudo pormenorizado. Sabia-se desde o início que a carga computacional para processar
Um Sistema de Detecção de Fraude em Telecomunicações
62
as assinaturas dos clientes poderia ser elevada. Decidiu-se, então, fazer uma análise para
encontrar a janela temporal mais adequada para a actualização das assinaturas. Era necessário ter
em conta que, a determinada altura, depois dos registos de chamadas serem armazenados, seria
preciso calcular os sumários desses registos, ler as assinaturas existentes, calcular a distância
entre as assinaturas e os sumários e, finalmente, voltar a reescrever as novas assinaturas ou
guardar novos casos suspeitos. Sabia-se portanto que havia alguma exigência computacional.
Como o sistema piloto ia correr numa máquina de teste, optou-se por ir “afinando” o sistema com
o desenrolar da experiência. No final, quando o protótipo fosse integrado como componente na
máquina do sistema principal, estará já configurado para a melhor performance. Quanto ás
restrições temporais, não houve qualquer problema. Desde início que estava definido no plano de
trabalho o tempo necessário para implementar o protótipo. Como não ocorreu nenhum atraso nas
fases anteriores, estava tudo como previsto. A segunda questão também estava incluída no plano
de trabalho. Era suposto implementar o protótipo de forma a ser possível a sua integração num
sistema de detecção de fraude já existente. Este sistema chama-se Centaur (Telbit, 1998) e foi
desenvolvido em conjunto pelas empresas TelBit e PT Inovação. Uma das vantagens do Centaur é
a sua escalabilidade. O sistema está desenhado de forma a que seja bastante fácil incluir novos
sistemas de detecção.
No desenvolvimento do protótipo foram considerados, no tratamento e transformação de
informação, os dados unificados do sistema Centaur. Visto que os dados já são tratados na rotina
de mediação e detecção do sistema Centaur foi uma mais valia. Apesar de ter sido um objectivo a
integração do protótipo no sistema Centaur, este foi desenvolvido de forma a que a integração em
qualquer outro sistema seja um processo rápido e simples.
5.2 Contextualização do Sistema Centaur
A arquitectura do Centaur foi concebida para permitir a inclusão de novas técnicas de detecção
sempre que necessário. Neste momento encontram-se em processo de introdução as técnicas de
fingerprinting (com recurso a acumuladores por cartão e por destino), assinaturas, clustering e
técnicas de CBR para a identificação de casos semelhantes. Desta forma é possível garantir a
constante evolução do sistema. Actualmente o Centaur suporta a definição de processos de
detecção em regras, com recurso a wizards, que simplificam o processo e permitem o cruzamento
das diversas fontes de informação disponíveis. Actualmente existem wizards para detectores de
Um Sistema de Detecção de Fraude em Telecomunicações
63
eventos e de agregação. Ainda não existem Wizards para detectores de acumuladores, de
plataformas ou detectores externos.
Vários processos de detecção geram alarmes quando identificam situações suspeitas, passíveis de
análise. Os alarmes gerados são prioritizados de acordo com critérios que replicam as prioridades
dos analistas e gestores de fraude. De forma a tornar o processo de decisão mais expedito, o
sistema permite a integração, cruzamento e agregação de todas as fontes de informação
relevantes para a análise e investigação.
As principais características do sistema de gestão de fraude Centaur são:
• detecção precoce e eficaz de fraude em vários sistemas e serviços;
• processos de detecção facilmente adaptáveis às diferentes vertentes de fraude e a novos
métodos para a sua detecção;
• rapidez na inclusão de novas fontes de informação, de natureza díspar, resultantes da
introdução de novas tecnologias ou sistemas;
• facilidade na definição de processos de detecção, recorrendo a diversas fontes de
informação (tráfego, dados de cliente, facturação, etc.) em simultâneo;
• capacidade de processar grandes volumes de informação;
• valorização eficaz do tráfego para evitar discrepâncias significativas;
• manutenção de um repositório centralizado com toda a informação necessária para a
investigação expedita das situações suspeitas;
• inclusão de um gestor de casos adequado aos processos internos do operador;
• disponibilização de métricas que permitam avaliar quantitativamente os resultados –
relatórios de ganhos decorrentes da detecção precoce de situações fraudulentas, avaliação
da performance dos analistas e análise geral do desempenho do sistema.
A aplicação Centaur tem uma arquitectura baseada em componentes, que permite a utilização de
diferentes tipos de colectores adaptáveis a todas as fontes de informação do operador. Estes
colectores garantem a fácil integração de novas fontes de informação. A escalabilidade da solução
é garantida pela adequada distribuição dos componentes pelos diversos servidores aplicacionais,
Um Sistema de Detecção de Fraude em Telecomunicações
64
sendo que a carga a que o sistema está sujeito varia fundamentalmente pelo número de clientes e
fontes de informação. A valorização do tráfego é efectuada utilizando um motor de tarifação e
permite replicar os diversos planos comerciais do operador.
Arquitectura do Sistema
A arquitectura do sistema está organizada em três camadas: dados; negócio ou lógica; e interface
ou apresentação. A divisão nestas camadas pretende isolar o acesso a dados (camada de dados),
o funcionamento propriamente dito do programa (camada de negócio) e a interface com o
utilizador (camada de interface). De seguida, apresentamos algumas vantagens da arquitectura de
3 camadas:
• cada camada está num componente isolado;
• cada camada apenas depende da camada seguinte;
• é possível a alteração em qualquer uma das camadas sem interferência nas outras;
• potencia a separação de responsabilidades;
• permite a especialização da equipa de desenvolvimento;
• potencia a facilidade de manutenção do código;
A camada de dados deve ser responsável por gerir todas as estruturas de dados básicas e fazer a
ligação com a base de dados, devendo isolar das camadas restantes qualquer acesso directo a
recursos de dados do sistema. A camada de negócio é responsável pela execução do algoritmo
principal, gerir todo o programa e manipular as diversas camadas de dados. Nesta camada devem
também estar estruturas de dados avançadas (estruturas de dados que não só utilizam as
estruturas de dados básicas da camada de dados, mas que as manipulam e efectuam operações
importantes do algoritmo principal). A camada de negócio representa o núcleo da aplicação em
termos de processamento. A camada de apresentação compreende os vários Graphical User
Interfaces (GUI). Esta camada, assim como a camada de dados, não deve executar nenhuma parte
importante do algoritmo mas passar o controlo à camada de negócio. Fornece a interacção entre o
utilizador e a aplicação. Na figura 18 podemos ver a introdução do componente de detecção
baseado em assinaturas na arquitectura de 3 camadas do sistema.
Um Sistema de Detecção de Fraude em Telecomunicações
65
Figura 18 - Integração do componente de assinaturas na arquitectura de 3 camadas do Centaur
Arquitectura tecnológica
Os processos de manipulação de dados e de detecção correm sobre os sistemas de gestão de
bases de dados instalados nas diversas máquinas que compõem o Centaur. Os processos de
análise e de investigação levados a cabo pelos analistas são efectuados com recurso a uma
aplicação cliente construída em Java e que corre nas suas máquinas locais. A definição da
arquitectura tecnológica para cada operador depende da análise do número de fontes de
informação, do volume de tráfego a processar e da identificação das distintas vertentes de fraude
a combater. Na figura 19 pode-se verificar a arquitectura do Centaur, baseada em quatro
Um Sistema de Detecção de Fraude em Telecomunicações
66
servidores aplicacionais. Foi neste tipo de arquitectura que o novo componente de assinaturas foi
integrado.
Figura 19 - Arquitectura tecnológica do Centaur
Arquitectura aplicacional
A arquitectura por componentes do Centaur permite uma grande flexibilidade de configuração e
reutilização de software. Os componentes do Centaur são os seguintes:
• Colecta – que integra os processos responsáveis pela recolha e carregamento dos dados
do operador;
• Mediação – que é constituída pelos processos responsáveis pela mediação dos dados dos
formatos originais do operador para os formatos internos do Centaur;
Um Sistema de Detecção de Fraude em Telecomunicações
67
• Marcação – que suporta os processos que complementam a informação de algumas fontes
com dados de diversas proveniências - um dos marcadores mais importantes é o que
efectua o cálculo do preço das chamadas.
• Detecção – que acolhe os processos responsáveis pela geração de alarmes, tendo a
possibilidade de utilizar diversas fontes de informação em simultâneo.
• Monitoria – que recebe os processos responsáveis pela monitorização do sistema.
Neste tipo de sistema existem vários fluxos de informação. Tipicamente, existe um fluxo distinto
para cada tipo de tráfego (voz, SMS, etc.). No entanto, o encadeamento dos diversos componentes
é igual (Figura 20).
Figura 20 - Fluxo da informação no sistema de detecção Centaur
O novo componente baseado em assinaturas irá complementar a fase de detecção. Depois de os
dados passarem a fase de marcação e de estarem nos formatos unificados do sistema, faz-se o
armazenamento da informação necessária de SMS e de voz para depois ser agregada e
processada. No final da detecção são gerados os alarmes e respectivos casos suspeitos.
Um Sistema de Detecção de Fraude em Telecomunicações
68
5.3 Identificação e caracterização dos Perfis dos Utilizadores
do Sistema
Na empresa onde será integrado o protótipo existem diversos métodos de trabalho. Para melhorar
a organização do trabalho foram definidas várias hierarquias de utilizadores, para as quais será
necessário considerar, no sistema informático, diversos perfis de utilização. Para se entender
melhor a responsabilidade e o cargo dos utilizadores, irá ser demonstrada a organização do
sistema Centaur. Desta forma, será mais fácil entender os diversos perfis de utilização. Os que
existem no sistema actual serão os mesmos que irão actuar sobre o sistema de detecção baseado
em assinaturas. A hierarquia dos perfis de utilização a actuar na organização é a seguinte:
Grupo de Informática – Este é o grupo principal que irá lidar directamente com o sistema. Todo
o tratamento de hardware, software e dados é da responsabilidade destes técnicos. O grupo de
informática pode ser dividido em dois sub-grupos principais, nomeadamente:
1. Programadores – Este sub-grupo tem como principal objectivo fazer a implementação dos
sistemas, desde o levantamento dos seus requisitos até à arquitectura base do sistema e
seus interfaces. Regularmente, são adicionadas ao sistema novas funcionalidades, de
forma a reflectir as situações novas detectadas ploos analistas de fraude.
2. Analistas – Este sub-grupo tem como principal objectivo analisar os dados e os padrões
obtidos através dos sistemas implementados pela equipa de desenvolvimento. Sempre que
são detectadas novas situações, e que necessitam de ser resolvidas, esta equipa informa a
equipa de desenvolvimento.
5.4 Especificação de Requisitos
Na construção de qualquer sistema de software, as fases anteriores ao desenvolvimento são muito
importantes. É frequente que muitas equipas tendam a dar maior importância à fase arquitectural
e desenvolvimento do que as fases de análise e especificação. O resultado destes comportamentos
é um maior custo de tempo no processo de desenvolvimento. Desta maneira, optou-se por fazer
uma análise detalhada que respondesse ás seguintes necessidades:
Um Sistema de Detecção de Fraude em Telecomunicações
69
• identificar os requisitos do sistema
• identificar as funcionalidades do protótipo
• elaborar um documento de especificação para ser utilizado nas fases seguintes do projecto
Os requisitos foram correctamente definidos para garantir uma qualidade acrescida no sistema que
foi desenvolvido. No entanto, o processo de fazer a sua colecta foi relativamente complexo. Foi
feito um estudo para obter o maior conhecimento possível do sistema e saber quais os tipos de
requisitos necessários para o problema em causa. O objectivo foi elaborar documentação que
representasse o funcionamento do sistema e não explicar como este funciona.
Para ilustrar e descrever os requisitos foi utilizada uma linguagem de modelação capaz de
representar todas as funcionalidades do sistema. A linguagem escolhida foi UML (Unified Modeling
Language) pois, contém um conjunto de regras formais e consistentes, consegue descrever as
várias formas e estados que o sistema pode ter e, é bastante legível ao ponto de todos os
utilizadores a interpretarem da mesma maneira. Outro motivo que nos levou a escolher esta
linguagem foi a possibilidade de trabalhar com os modelos antes do sistema estar desenvolvido.
Isto permitiu uma validação atempada de todos os requisitos que iam surgindo. Depois de uma
análise detalhada do sistema, foram encontrados os seguintes requisitos gerais:
ID Descrição Prioridade
(Essencial, Útil, Desejável)
Depende de
1 Criar as tabelas necessárias para o sistema de detecção baseado em Assinaturas. Essencial
2 Inicializar Assinaturas de clientes já existentes.
Essencial 1
3 Criar modelos de Assinaturas Fraudulentas.
Útil 1
4 Criar Classes de clientes com base nas Assinaturas existentes.
Essencial 2
5 Transferir os registos necessários das tabelas PUMP_VOICE e PUMP_SMS para as tabelas LOADING_ASSINATURA
Essencial 1
6 Processar Sumários
Essencial 5
7 Regularizar Casos Suspeitos
Essencial 6
8 Actualizar as Classes de Assinaturas
Desejável 4
Tabela 2 – Tabela de Requisitos
Um Sistema de Detecção de Fraude em Telecomunicações
70
Os requisitos listados na tabela 2 são os objectivos de concepção do sistema, também podem ser
incluídos nos requisitos não funcionais. Representam as características e funcionalidades que o
sistema deve possuir. No caso do desenvolvimento deste protótipo, estes requisitos foram
descritos em linguagem natural para simplificar a o processo de desenvolvimento. Cada um destes
requisitos está detalhadamente especificado no Anexo B, como exemplo ilustrativo de seguida está
especificado um dos objectivos de concepção do sistema:
Requisito 06 Processar Sumários
Objectivo
Actualizar as assinaturas dos clientes existentes, detectar situações suspeitas
de fraude, criar assinaturas para novos clientes com base nas classes de
utilização da tabela Assinatura_Classe, e não tratar os telefones com casos
suspeitos por resolver.
Pré-condições
A troca de partições entre as tabelas LOADING_ASSINATURA_Voz e
PUMP_ASSINATURA_SMS, e LOADING_ASSINATURA_SMS e
PUMP_ASSINATURA_SMS deverá ser efectuada com sucesso.
Permissões de CRUD no sistema de detecção do Centaur.
Condição final de Sucesso
As Assinaturas são actualizadas correctamente na tabela ASSINATURA.
Os casos suspeitos são adicionados à tabela Caso_Suspeito.
São criadas assinaturas novas na tabela Assinatura para clientes inexistentes.
Clientes com casos suspeitos por resolver são adicionados à tabela
Sumario_Temporario.
Condição final de Insucesso Algumas ou nenhuma assinatura é processada.
É lançada uma excepção para notificar o erro.
Actores Sistema de detecção
Descrição Passo Acção
1
O conteúdo do útlimo dia de tráfego nas tabelas
LOADING_ASSINATURA_Voz e LOADING_ASSINATURA_SMS deve
ser trocado pelo conteúdo vazio das tabelas
PUMP_ASSINATURA_Voz e PUMP_ASSINATURA_SMS
respectivamente.
2
A informação das tabelas PUMP_ASSINATURA_Voz e
PUMP_ASSINATURA_SMS deve ser agregada e os sumários dos
clientes deverão ser calculados.
3
Os sumários de clientes com casos suspeitos por resolver deverão
ser inseridos na tabela Sumario_Temporario.
3
Os sumários de clientes que não existem na tabela Assinatura
devem ser utilizados para criar novas assinaturas dos mesmos
com auxílio das classes de utilização da tabela Assinatura_Classe.
Um Sistema de Detecção de Fraude em Telecomunicações
71
3
Os sumários de clientes com casos suspeitos resolvidos e
fraudulentos são ignorados.
3
Os sumários sem casos suspeitos ou com casos suspeitos
resolvidos e não fraudulentos deverão ser comparados com as
suas Assinaturas. É calculado um valor de distância e um limiar
pré-definido* poderá ser ultrapassado.
4
Se o limiar pré-definido* for ultrapassado é adicionado um novo
caso suspeito na tabela Caso_Suspeito.
4
Se o limiar pré-definido* não for ultrapassado os sumários são
comparados com os modelos de fraude existentes na tabela
Assinatura_Fraude. É calculado um valor de distância e um limiar
pré-definido** poderá ser ultrapassado.
5
Se o limiar pré-definido** for ultrapassado é adicionado um novo
caso suspeito na tabela Caso_Suspeito.
5
Se o limiar pré-definido** não for ultrapassado as assinaturas na
tabela Assinatura são actualizadas com base nos valores dos
sumários.
Tabela 3 – Exemplo de um requisito do sistema
Este requisito foi dos mais importantes no desenvolvimento do protótipo e tem algumas
particularidades. Para perceber algumas das dificuldades associadas ao requisito serão
apresentados alguns promenores que foram considerados durante o desenvolvimento. No processo
de inserção dos registos das tabelas loading_assinatura para as tabelas pump_assinatura,
a chave primária é removida para aumentar a eficiência do processo. No fim de todos os registos
serem replicados, a chave é novamente criada para garantir que não são criados registos
duplicados.
O cálculo dos sumários é realizado com os registos que estão nas tabelas pump_assinaturas.
Os registos são devidamente agregados e as medidas de perfil calculadas. Depois de obter os
perfis de comportamento recentes de cada cliente, e se estes não tiverem casos suspeitos por
resolver e se existirem na BD, são comparados com as suas assinaturas através do auxílio da
tabela Assinatura. O algoritmo que deverá ser aplicado no processamento das assinaturas é
apresentado no Anexo A.
Todos os sistemas de software, normalmente, não funcionam sem interagirem com os utilizadores.
Os requisitos até aqui mencionados são independentes dos utilizadores do sistema, no entanto,
Um Sistema de Detecção de Fraude em Telecomunicações
72
existem funcionalidades presentes no protótipo que permitem a comunicação com eles. Para
representar esta interacção entre o utilizador e o sistema serão utilizados use cases. A identificação
destes casos de uso é muito importante pois permite recolher os requisitos funcionais do sistema
que vai ser modelado. Estes modelos permitem representar tudo o que pode ser feito no sistema,
associar os actores envolvidos e perceber quais as funcionalidades que estes invocam. A figura 21
apresenta um diagrama de casos de uso do protótipo que permite ao analista fazer a exportação
de resultados. Os restantes casos de uso podem ser consultados no Anexo C.
Figura 21 - Exemplo de um caso de uso do sistema protótipo
Cada caso de uso pode ter um processo de negócio associado. Este processo é representado em
UML através de diagramas de actividade, é uma descrição do problema onde é representado o
fluxo de controlo dos dados associados.
Neste projecto foram criados diagramas de actividade para cada um dos use cases, alguns dos
utilizadores do sistema colaboraram na especificação dasta tarefas. As tarefas de maior
importância são as ditas actividades ou conjunto de acções que estão desenhadas nos diagramas.
A escolha deste tipo de modelação está associada à facilidade que existe em interpretar os
gráficos, a notação simples e a complexidade reduzida na sua construção. Todos os diagramas de
actividade contêm um estado inicial e um estado final, descrevem todas as acções e variações de
fluxo, podem apresentar escolhas de condições booleanas e têm a capacidade de representar
Um Sistema de Detecção de Fraude em Telecomunicações
73
diferentes acções em paralelo.
A figura 22 apresenta o diagrama de actividades que está associado ao use case da figura 21
(exportação de resultados por parte dos analistas). Os restantes diagramas de actividade podem
ser consultados no Anexo D.
Figura 22 - Exemplo de um diagrama de actividades do sistema protótipo
No diagrama verifica-se que existe um comportamento condicional de decisão. A certa altura, o
analista pode escolher se pretende exportar a informação de casos suspeitos ou de assinaturas, ou
mesmo ambos.
As representações gráficas apresentadas são independentes das metodologias e linguagens de
programação que foram utilizadas no desenvolvimento do protótipo. Porém, influenciaram muito
em certas decisões ao longo do processo. A documentação escrita permite a futuras equipas de
projecto, que poderão dar continuidade ao trabalho realizado, perceber de forma rápida e simples
todo o mecanismo de funcionamento e todas as acções envolvidas, poupando tempo e sem
necessitar de nenhum conhecimento de programação.
Um Sistema de Detecção de Fraude em Telecomunicações
74
5.5 Descrição Funcional do Sistema
Para perceber como é reencaminhada toda a informação no sistema e as funcionalidades mais
importantes envolvidas, será resumido o comportamento do protótipo desde o seu estado inicial,
quando recebe os dados provenientes do Centaur, até aos diferentes estados finais possíveis, onde
as assinaturas são actualizadas ou os alarmes são lançados por exemplo. Este tipo de abordagem
permite fazer uma análise geral do funcionamento do sistema independentemente de qualquer
software ou hardware em específico.
O sistema recebe os registos de voz e SMS previamente tratados no sistema Centaur, filtra os
atributos necessários e copia os mesmos para as tabelas loading_assinaturas_voz e
loading_assinaturas_sms. Estas tabelas contêm no mínimo duas partições, uma relativa ao
tráfego do dia anterior e outra do dia de tráfego mais actual. As assinaturas são actualizadas uma
vez por dia, preferencialmente nas horas de menor tráfego. Existem duas tabelas,
pump_assinaturas_voz e pump_assinaturas_sms, com os mesmo atributos das tabelas
loading_assinaturas_voz e loading_assinaturas_sms respectivamente. Estas tabelas
são populadas com o último dia de tráfego na hora de actualização das assinaturas. No início do
processo, as tabelas estão vazias e a sua informação é trocada pela informação das tabelas de
loading, desta forma as tabelas loading estão aptas a continuamente receber os próximos registos
de chamadas e SMS. As tabelas pump, durante este processo de troca, não contêm chave primária
para aumentar a eficiência deste passo. Quando as tabelas pump estão totalmente populadas a
chave primária é novamente criada para garantir que registos duplicados não são carregados. A
informação resultante é depois utilizada para calcular em run-time os sumários mais recentes. No
final, as tabelas pump são novamente limpas. O sistema calcula os sumários relativos ao dia
anterior. Se algum cliente tiver casos suspeitos por resolver, os seus sumários são incluídos nos
sumários temporários para processá-los futuramente caso seja necessário. Os sumários dos
clientes que não têm casos suspeitos por resolver deverão ser comparados com as suas
assinaturas.
Se a assinatura de um cliente não existir o seu sumário é imediatamente comparado com as
assinaturas de fraude existentes. Se não for semelhante a nenhum modelo de fraude então os
sumários são comparados com os modelos legítimos existentes, os sumários tomam o valor da
assinatura com a classe mais equivalente. No entanto, se houver algum modelo de fraude
semelhante, o caso é guardado como suspeito. Quando a assinatura do cliente existe, é calculado
Um Sistema de Detecção de Fraude em Telecomunicações
75
o valor de distância entre a assinatura e o seu sumário recente, se o valor de limiar pré-definido no
cálculo de distância for ultrapassado, é disparado um alarme e é criado um novo caso suspeito. Se
o limiar não for ultrapassado os sumários são comparados com os modelos de assinaturas de
fraude existentes, podendo mesmo assim ser adicionados como casos suspeitos. Se não houver
semelhanças com nenhum modelo de fraude as assinaturas são finalmente actualizadas tendo em
conta os valores dos sumários. A qualquer altura o sistema permite a exportação de informação
para análise. Também é possível editar os parâmetros de processamento (limiares e pesos) e
alterar o estado de uma assinatura e respectivo caso suspeito (resolvido é fraude, resolvido não é
fraude, não resolvido).
O evento de processar os sumários, que foi até agora descrito, acontece diariamente. Contudo,
existem outros eventos que também fazem parte do funcionamento do sistema mas que
acontecem mensalmente, ou semanalmente dependendo do número de clientes na BD. Estes
eventos estão relacionados com a actualização dos modelos de fraude e das classes de clientes
legítimos. De forma a melhor compreender como toda esta informação é processada e
encaminhada com o decorrer do tempo, será demonstrado um fluxo (Figura 23) que resume os
eventos mais importantes do protótipo.
Um Sistema de Detecção de Fraude em Telecomunicações
76
Figura 23 - Fluxo de informação dos eventos mais importantes que ocorrem com as assinaturas
Dependendo do evento em causa, a informação pode atingir diferentes estados finais. Para os
casos em que nenhum alarme é disparado, a informação é actualizada ou novas assinaturas são
criadas dependendo dos diferentes inputs. Em caso contrário, o cliente é adicionado à lista de
casos suspeitos e deverá posteriormente ser investigado pelos analistas de fraude. Assim que a
situação é resolvida, os registos temporários são processados e o cliente atinge um estado activo
novamente. Se for caso de fraude a conta é suspensa e novos registos, que poderão surgir
entretanto, não são processados.
O desempenho do sistema, a processar todos os eventos descritos, para além de depender da
qualidade do protótipo construído, depende também do hardware e do software que é utilizado
para suportar todo o processo. Desta forma, foi feito um estudo para encontrar os requisitos de
software e hardware essenciais para obter o melhor desempenho possível no problema em
questão. Estes requisitos podem ser consultados no Anexo E.
Um Sistema de Detecção de Fraude em Telecomunicações
77
5.6 Design Estrutural
Neste projecto, o design estrutural que suporta o armazenamento de toda a informação envolvida
foi criado segundo a metodologia de Connolly and Begg (2004). Esta escolha deve-se a inúmeros
factores, entre eles a vantagem de ser bastante legível para utilizadores técnicos e não técnicos, e
por já ter sido testada inúmeros vezes em diversas empresas e universidades. O processo de
construção da estrutura passou por três fases principais: a fase conceptual, lógica e física. Na
primeira fase de modelação conceptual foi produzido um modelo independente de qualquer
consideração física. Alguns passos importantes desta modelação podem ser consultados no Anexo
F. O modelo foi depois refinado na segunda fase num modelo lógico através da remoção de
conceitos que não podem ser representados num sistema relacional. Esta modelação também pode
ser consultada através da informação do Anexo G. No final, o modelo lógico foi traduzido para um
desenho físico compatível com o SGBD Oracle 10g. Nesta fase foi necessário tomar em
consideração as estruturas de armazenamento e os métodos de acesso necessários para uma
interligação segura e eficiente com a base de dados. Por motivos de legibilidade e para facilitar o
processo de análise do modelo construído, apenas será mostrado o diagrama conceptual obtido, e
serão explicados os detalhes mais importantes associados ao seu processo de construção.
A modelação conceptual da base de dados é o processo de construir o modelo de dados que vai
ser utilizado para o protótipo, independentemente de qualquer consideração física, como por
exemplo, o SGBD, a linguagem de programação ou a plataforma de hardware utilizada. Mais
detalhadamente, este processo consiste em, para cada vista de utilizador: identificar as entidades,
relacionamentos, atributos e respectivos domínios; definir chaves primárias; verificar o modelo
desenvolvido; validar o modelo desenvolvido com as transacções dos utilizadores; por fim fazer
uma revisão dos modelos desenvolvidos com os utilizadores. No caso deste projecto, apenas existe
a vista do analista que engloba todas as entidades e toda a informação necessária. Foi realizada
uma abordagem global desta vista.
De seguida, o diagrama conceptual (Figura 24) resultante do estudo efectuado.
Um Sistema de Detecção de Fraude em Telecomunicações
78
Figura 24 - Diagrama Conceptual
Um Sistema de Detecção de Fraude em Telecomunicações
79
É num esquema semelhante ao da estutura apresentada na figura 24 que os dados ficam
armazenados. Como podemos ver, existem nove entidades e quatro relacionamentos. Os atributos
que estão com letras vermelhas (Medidas, Medidas_DP e Distâncias) são o conjunto das
medidas de perfil, os respectivos desvios padrões e as distâncias individuais obtidas no
processamento diário dos sumários.
Cada classe de assinatura legítima (Assinatura_Classe) pode ter várias assinaturas
(Assinatura) associadas, e cada uma das assinaturas pode ter muitos casos suspeitos
(Caso_Suspeito) associados. Dentro deste conjunto de casos suspeitos apenas um poderá estar
por resolver. Estes casos não resolvidos poderão ter vários sumários temporários
(Sumario_Temporario) associados, que são os casos em que as suas assinaturas não são
actualizadas e a agregação dos registos diários vão ficando em stand by. Os casos suspeitos, em
que o valor do atributo alarme está associado a uma fraude de supervisionada, estão associados à
entidade que armazena todos os modelos de fraude (Assinatura_Fraude) existentes. A
informação nestes modelos de fraude e nas classes de assinturas legítimas
(Assinatura_Classe) é actualizada mensalmente ou semanalmente.
As tabelas pump e loading, numa fase inicial, não têm qualquer chave primária, isto deve-se ao
facto destas entidades estarem constantemente a criar e a apagar a chave durante o período de
carregamento de tráfego. Podia-se, no entanto, representar as mesmas no diagrama exposto.
Como podemos ver esta estrutura não esta normalizada, a razão para este acontecimento está
explicada na próxima secção com o nome “Validação do Modelo”.
Apesar de não se verificar um crescimento de volume de dados tão grande como os diversos
métodos de detecção que foram estudados, mesmo assim este modelo armazena diariamente as
assinaturas dos novos clientes da operadora, a informação de todos os eventuais casos suspeitos e
todos os sumários temporários que ainda têm os casos por resolver.
!
Validação do Modelo
Por motivos de desempenho concluiu-se que seria melhor manter uma estrutura desnormalizada
da base de dados. O número de acessos e a correspondente volumetria (comprimento de registos
e número de linhas acedidas) ditou esta escolha como a mais acertada.
Para efeitos de avaliação de desempenho irá ser feita uma análise do desenho normalizado da
base de dados não tendo em conta qualquer condicionante ou simples indicação orientadora a
Um Sistema de Detecção de Fraude em Telecomunicações
80
nível de implementação física concreta, ou seja, de forma totalmente independente do Sistema de
Gestão de Base de Dados. Esta análise passa pela identificação dos caminhos de acesso em função
da estrutura lógica da base de dados para determinar:
• as transacções mais frequentes.
• das transacções críticas, isto é, daquelas que em maior tempo de execução acarretam uma
degradação significativa de desempenho.
De modo a ilustrar o procedimento enunciado vamos considerar que o atributo Telefone, que
está redundante na tabela Caso_Suspeito, não existe.
A transacção mais frequente onde está envolvido este atributo é:
A – Listar todos os casos suspeitos por resolver e respectivos números de telefone dos clientes.
Esta transacção pode ser decomposta nos seguintes passos:
A1 – Dado o estado do caso suspeito extrair da tabela Caso_Suspeito todos os identificadores
das assinaturas envolvidas (atributo id_assinatura).
A2 – Para cada identificador de assinatura extrair da tabela Assinatura todos os telefones dos
clientes associados (atributo Telefone).
Na figura seguinte (Figura 25) está representado esquematicamente os passos em que se
decompõe a transacção A. A representação baseia-se no esquema das tabelas envolvidas
(Caso_Suspeito e Assinatura) e com explicitação das chaves primárias e estrangeiras.
Um Sistema de Detecção de Fraude em Telecomunicações
81
Figura 25 - Passos que compõe a transacção A sem redundância
A solução passou por desnormalizar a tabela Assinatura pois tem bastante impacto na
transacção A, deixa de ser necessário proceder ao passo A2 uma vez que a informação do telefone
pode ser directamente extraída no passo anterior. No fim resulta apenas um passo A1’. De
seguida, o esquema da base de dados (Figura 26) resultante da desnormalização, e
consequentemente, os passos necessários para realizar a transacção A.
Figura 26 - Passos que compõe a transacção A com redundância
Embora a solução apontada de desnormalização possa parecer vantajosa, é necessário avaliar se
na prática existe, de facto, uma redução suficientemente drástica para ser se proceder à sua
implementação.
A avaliação será feita em termos do número de registos acedidos no desenho normalizado e no
desenho desnormalizado.
Foi considerado um número médio de acessos, numa fase em que o que sistema possui grande
parte das assinaturas dos seus clientes inicializadas. Temos então os seguintes valores:
1. 6 milhões de assinaturas
Um Sistema de Detecção de Fraude em Telecomunicações
82
2. 500 mil casos suspeitos por resolver.
Antes da desnormalização teríamos:
Transacção Passo Registos acedidos
A A1 Casos suspeitos com estado dado = 500000
A2 500 mil x 6 milhões = 3000000000000
Total
3000000500000
Tabela 4 - Resultados antes da desnormalização
Após a desnormalização temos:
Transacção Passo Registos acedidos
A A1’ Casos suspeitos com estado dado e
respectivo telefone
= 500.000
Total
500.000
Tabela 5 - Resultados após desnormalização
Esta avaliação revela um enorme impacto, validando portanto o processo de desnormalização.
O atributo Estado que existe na tabela Assinatura também poderia ser eliminado e a
informação poderia ser obtida através da junção com a tabela Caso_Suspeito. A justificação
para este atributo também ser redundante é idêntica á efectuado com o atributo Telefone.
Problemas importantes na implementação do Sistema Protótipo
83
Capítulo 6
6Problemas Importantes na Implementação do
Sistema Protótipo
Durante a implementação do sistema surgiram alguns problemas de alguma relevância que
merecem uma análise mais pormenorizada. Estes problemas estão associados a algumas
funcionalidades inexistentes no sistema de assinaturas apresentado por Ferreira, et al. (2006), tal
como a criação de modelos de fruade por exemplo, e também de alterações ás soluções
existentes, tal como a redefinição das fórmulas de distância. Outros problemas que irão ser
abordados neste capitulo estão relacionados com as necessidades das organizações envolvidas
(TelBit e PT Inovação), como por exemplo o objectivo de dar maior relevância às fraudes de
roaming e SMS, e melhoramentos de performance do sistema em geral.
6.1 Definição dos Pesos dos Atributos
Com base nos resultados anteriores do sistema de detecção Centaur, das organizações TelBit e PT
Inovação, foi-nos transmitido quais as maiores vulnerabilidades e deficiências na detecção de
determinados tipos de fraude. Para além destes casos, também nos foram listados alguns serviços
que mereciam uma maior atenção devido ás perdas de receita derivadas da fraude nos mesmos.
Uma das soluções que econtramos foi acrescentar algumas medidas de perfil na composição da
assinatura dos clientes e dar maior relevância a certos atributos no cálculo de distância com os
Problemas importantes na implementação do Sistema Protótipo
84
sumários resultantes da agregação diária de transacções. Para dar maior relevância a um atributo
foi necessário definir um peso para o mesmo.
Foi feito um estudo para verificar quais os atributos com maior importância ou se existia
necessidade de aumentar o grau de importância de determinado atributo devido tipos de fraude
específicos para o problema.
Visto que as fraudes de roaming são as mais dispendiosas para as operadores, e sabendo que é
um dos principais objectivos deste projecto conseguir detectar o maior número de casos deste
tipo, foi atribuído um peso maior aos atributos relacionados com as chamadas ou SMS do tipo
roaming. Desta forma, o algoritmo é mais sensível aos desvios relacionados com este tipo de
fraude. Poderão surgir mais casos suspeitos relacionados e um maior número de falsos alarmes,
mas os analistas por sua vez conseguirão perceber melhor o comportamento dos clientes que
praticam este tipo de crime e será possível detectar um maior número de casos classificados como
fraude.
Na atribuição de pesos aos atributos, foi também considerada uma estratégia baseada em
conjuntos. Explicando melhor, se assumirmos que os atributos
!
X e
!
Z são sub-conjuntos de um
atributo
!
Y , ou seja,
!
X " Y #Z " Y # X$Y = Z , caso o atributo
!
Y se desvie muito do seu valor
habitual então o atributo
!
X e /ou o atributo
!
Z também se vai desviar, logo faz sentido atribuir
maior peso ao atributo
!
Y . Por exemplo, seja
!
Y o atributo num_chamadas e sejam
!
X e
!
Z os
atributos num_chamadas_recebidas e num_chamadas_efectuadas respectivamente, se o
número de
!
Y variar muito então
!
X e/ou
!
Z também vai variar. Podemos assim concluir que a
partir de um atributo é possível determinar a variação de outros atributos, logo este poderá ter
maior peso. No entanto, o peso dado aos atributos que são “sub-conjuntos” também deverá ser
suficiente para detectar desvios muito anormais dentro de si próprios. Consideremos o seguinte
caso com os atributos anteriormente utilizados, seja
!
Y = num_chamadas ,
!
X =
num_chamadas_recebidas e
!
Z = num_chamadas_efectuadas:
Comportamento habitual de um cliente:
• num_chamadas = 100
• num_chamadas_recebidas = 1
• num_chamadas_efectuadas = 99
Problemas importantes na implementação do Sistema Protótipo
85
Resultados de um dia de tráfego para o mesmo cliente:
• num_chamadas = 100
• num_chamadas_recebidas = 99
• num_chamadas_efectuadas = 1
Nesta situação, como podemos observar, o atributo num_chamadas não é útil para detectar o
comportamento anormal do cliente. Apesar destes casos serem mais escassos e de não serem tão
relevantes como a alteração de comportamento do atributo num_chamadas, foi definido um peso
com um valor suficiente para alarmar nos casos susceptíveis a análise. Estes casos estão
normalmente associados a fraudes de roubo de telefone, o criminoso com comportamentos
diferentes é assim detectado com maior rapidez e eficácia.
Outro aspecto que foi considerado, devido ao crescimento das fraudes relacionadas com
mensagens escritas, foi distribuir os pesos com igualdade de importância entre os atributos de SMS
e voz. Visto que existem mais atributos de voz do que SMS nas assinaturas dos clientes, nos casos
em que existe um grau de importância semelhante entre dois atributos relacionados, o peso do
atributo de SMS será ligeiramente superior. Um exemplo desta distribuição de pesos é o caso dos
atributos num_chamadas_fim_de_semana com peso 0.4 e num_sms_fim_de_semana com
peso 0.45. De seguida a lista de todos os atributos com os respectivos pesos considerados:
• num_chamadas_efectuadas – 0.1
• num_chamadas_recebidas – 0.1
• duração_chamadas_nacionais – 0.3
• duração_chamadas_roaming – 0.4
• num_chamadas_roaming – 0.5
• num_chamadadas_roaming_efectuadas – 0.1
• num_chamadas_roaming_recebidas – 0.1
• num_chamadas_outra_operadora – 0.1
• num_chamadas_mesma_operadora – 0.1
• num_chamadas_dia_útil – 0.4
• num_chamadas_fim_de_semana – 0.4
• num_chamadas_dia – 0.1
• num_chamadas_noite – 0.1
Problemas importantes na implementação do Sistema Protótipo
86
• num_sms_enviadas – 0.1
• num_sms_recebidas – 0.1
• num_sms_roaming – 0.45
• num_sms_roaming_enviadas – 0.1
• num_sms_roaming_recebidas – 0.1
• num_sms_outra_operadora – 0.1
• num_sms_mesma_operadora – 0.1
• num_sms_dia_útil – 0.45
• num_sms_fim_de_semana – 0.45
• num_sms_dia – 0.1
• num_sms_noite – 0.1
A qualquer altura, dependendo dos objectivos dos analistas e do tipo de fraude a detectar, os
critérios utilizados neste projecto poderão ser descartados e facilmente se pode alterar os pesos
atribuídos.
6.2 Tuning do Sistema
Durante o processo de implementação do sistema foram efectuadas várias operações de forma a
aumentar a sua eficiência. Algumas foram já explicadas anteriormente, tais como a
desnormalização da base de dados, criação de partições nas tabelas
loading_assinaturas_sms e loading_assinaturas_voice para depois fazer a sua troca
com as tabelas pump_assinatura, removendo as respectivas chaves primárias antes. No
entanto, com o decorrer do projecto foram efectuadas constantes alterações de forma a melhorar,
ainda mais, o desempenho do sistema.
Um dos procedimentos efectuados foi a criação de índices sobre determinados atributos de
algumas tabelas. Foi realizado um estudo de forma a perceber quais as transacções que no futuro
iriam decorrer mais vezes, depois verificou-se quais os tipos de índices que poderiam ser criados
sobre as tabelas mais importantes e por fim foram realizados testes com diversos tipos de dados
para verificar se realmente valeria a pena a sua criação. Visto que na camada de negócio a maior
parte das operações são de agregação e não de pesquisa (clientes com atributos com
Problemas importantes na implementação do Sistema Protótipo
87
determinados valores por exemplo), os índices de maior relevância são os de ordenação, nesse
sentido, depois de alguns testes foi criado um índice b-tree na tabela Assinatura sobre o
atributo telefone e um índice b-tree na tabela Sumários_Temporários sobre o atributo
telefone. Para suportar esta decisão, para fazer o processamento de 1 dia de tráfego, foram
utilizados 25.000 registos aleatórios na tabela loading_assinatura_sms e 25.000 registos
aleatórios na tabela loading_assinatura_voice, estando presentes cerca de 20.000 clientes
na tabela Assinatura, 23.000 registos na tabela Assinatura_classe e 10 registos na tabela
Assinatura_fraude. Inserindo valores de limiar logicamente correctos, de acordo com os dados
utilizados, o processamento foi feito em +/- 65segundos. Com valores de limiar elevados, de forma
a obrigar o algoritmo a ser percorrido totalmente com todos os clientes, o processamento foi feito
em +/- 5min. Estes valores foram obtidos com os índices em cima referidos, sem os mesmos
ambos os processamentos demoram o dobro do tempo. Foi testada a criação de mais índices
sobre atributos de outras tabelas mas os resultados obtidos não demonstraram qualquer tipo de
melhoria.
Outro procedimento efectuado durante a implementação do sistema foi a optimização do código
das fórmulas utilizadas para efectuar os diversos cálculos e das queries que iam sendo criadas.
Todas as queries foram revistas de forma a diminuir o número de junções e/ou encontrar
alternativas para obter os resultados mais rapidamente.
6.3 Fórmulas utilizadas
Numa fase inicial o sistema foi testado com a fórmula de actualização de assinaturas do trabalho
de Cortes e Pregibon (2001), para o cálculo das distâncias as fórmulas propostas por Ferreira, et
al. (2006), distribuição normal e distribuição de poisson respectivamente. No entanto, existiram
alguns problemas no cálculo das distâncias simples através da distribuição de poisson. Vamos
então olhar para a fórmula e tentar perceber os problemas que apareceram:
!
P(N = k) =e"##k
k!, em que k = observado (parâmetro de uma transacção), e = 2.71828 e
!
"
= esperado (um sumário dentro da janela temporal)
Problemas importantes na implementação do Sistema Protótipo
88
Um dos primeiros problemas foi o facto de a linguagem PL/SQL não conter a função factorial pré-
definida. Para resolver esta situação foi efectuado um estudo de forma a encontrar o algoritmo
mais eficiente possível. Depois de implementar a função e de realizar alguns testes, descobriu-se
que o tipo de dados NUMBER a partir do factorial de 84 não consegue representar um número tão
extenso, arredondando para
!
1"10126 . Isto é um problema bastante grave pois diariamente grande
parte dos clientes envia mais de 83 SMS diárias, ou efectua mais de 83 chamadas (call centers por
exemplo). Outro grande problema desta fórmula é o facto do valor do denominador da divisão ser
muito grande, o Oracle arredonda o resultado final para o valor 0. Visto isto, foram feitas várias
alterações de forma a encontrar outras representações ou diferentes formas de fazer os cálculos.
Esta linguagem, ao contrário de FORTAN por exemplo, não é a mais indicada para cálculos de
grande complexidade. No entanto, já se sabia disto à partida na escolha da linguagem para
implementar a camada lógica pelo que foi necessário encontrar outras soluções. Foi efectuada um
pesquisa de forma a encontrar outras fórmulas de distância para comparar os sumários com as
assinaturas e com as assinaturas fraudulentas ou com os modelos de assinaturas legítimas. No
final, concluiu-se que as fórmulas mais indicadas para o problema proposto seriam a distância de
Hellinger e a distância Euclidiana Normalizada.
Distância de Hellinger
A distância de Hellinger é baseada numa análise diferencial nos perfis do utilizador, sendo definida
entre vectores com elementos positivos ou com valor 0. Em geral, é utilizado para comparação de
perfis. O sistema depois de calculada a distância verifica se o valor obtido é superior a determinado
limiar, depois é lançado um alarme de acordo com o valor de diferença entre ambos. Estes alarmes
são depois prioritizados para investigação. Algumas das vantagens da distância de Hellinger
segundo o trabalho de Rao (1995) são:
• A medida depende apenas dos atributos do perfil. Não é alterada quando existe uma
extensão dos atributos do perfil.
• A medida não depende do tamanho do perfil em que os atributos são estimados.
• Se uma representação diferente dos atributos é necessária consideramos
!
X = Q' , ou
seja, os elementos de
!
X são a raíz dos elementos de
!
Q' onde
!
Q era o valor definido.
Problemas importantes na implementação do Sistema Protótipo
89
!
dist(s,a) = si" a
i( )2
i=1
n
#$
% &
'
( )
1
2
, em que
!
s é o sumário resultante da agregação de um dia de
tráfego,
!
a é a assinatura do cartão em causa e
!
i representa cada uma das medidas de perfil.
Esta fórmula oferece grande estabilidade nos resultados obtidos e disponibiliza uma segurança
acrescida em perfis de diferentes tamanhos. Será assim utilizada para calcular a distância entre os
modelos de assinaturas fraudulentas e os sumários resultantes dos processamentos diários, e para
calcular a distância entre os sumários e os modelos de assinaturas legítimas na criação de
assinaturas de clientes não existentes. Nestas comparações de valores não é considerado qualquer
valor de desvio padrão.
Distância Euclidiana Normalizada
Para calcular a distância entre as os sumários e as respectivas assinaturas, a fórmula escolhida foi
a distância Euclidiana. É uma das fórmulas de distância mais antigas e mais utilizada para
situações semelhantes. A fórmula captura dois items e compara cada atributo de cada item para
determinar o grau de proximidade entre ambos, e o quanto ambos estão relacionados. Por outras
palavras, com esta fórmula, é possível considerar as características de perfil entre dois utilizadores,
e verificar o quanto ambos são semelhantes. No caso do nosso problema, são consideradas as
características de utilização do cliente em janelas temporais diferentes e verifica-se o quanto o seu
comportamento se desviou do habitual.
Uma vez efectuados os cálculos entre os utilizadores é devolvido um valor entre 0 e infinito.
Quanto maior o valor maior o desvio comportamental do cliente.
!
p1" q
1( )2
+ p2" q
2( )2
+!+ pn " qn( )2
= pi " qi( )2
i=1
n
# , em que
!
q é o sumário
resultante da agregação de um dia de tráfego,
!
p é a assinatura do cartão em causa e
!
i
representa cada uma das medidas de perfil.
Problemas importantes na implementação do Sistema Protótipo
90
A equação em cima traduz a versão curta e a versão expandida da fórmula em questão. Olhando
para a versão curta, a equação soma o valor das diferenças entre os atributos de dois objectos
especificados e depois é calculada a raíz quadrada. Para um objecto com apenas um atributo, a
equação calcula directamente a raíz quadrada da diferença do atributo e o cálculo termina.
Felizmente, a equação permite a utilização de mais do que um atributo por isso é somado o valor
das diferenças de todos os atributos até não existirem mais atributos para comparar.
Depois de testar a fórmula em cima referida foram identificados alguns problemas. Após a análise
de alguns clientes cujos valores de distância ultrapassavam o limiar estabelecido, concluiu-se que
muitos deles não eram de facto fraudulentos. Depois de estudar alguns casos em particular,
verificou-se que o problema era devido à ausência do valor de desvio padrão. Muitos dos casos, de
clientes relacionados com Call Centers por exemplo, efectuavam elevados números de chamadas
em apenas alguns dias da semana, nos restantes dias como as empresas em questão não
prestavam os mesmos serviços, o número de chamadas diminuia drasticamente. Consideremos o
caso de um cliente que ás segundas, terças e quartas contabilizava um total de 30.000 chamadas
diárias e nos restantes dias da semana o número média de chamadas por dia era de 600
chamadas.
De acordo com os atributos existentes, após a inicialização das assinaturas dos clientes de 40 dias
de tráfego, teríamos um número de chamadas em dias da semana médio de 16.500. Ora, ao fazer
o processamento diário de uma próxima sexta-feira, por exemplo, no cálculo da distância iríamos
obter um valor muito elevado, ou mesmo num dia normal de funcionamento quando em média são
realizadas 30.000 chamadas, o valor de distância também seria elevado pois como o desvio padrão
não é incluído assume-se que o numero de chamadas em dias da semana anda à volta de 16.500,
quando na realidade não é o que acontece. Devido ao número elevado de falsos alarmes deste tipo
de casos foi necessário introduzir o valor de desvio padrão nos atributos associados.
A situação foi contornada através da normalização da fórmula de distância Euclidiana. A
normalização foi efectuada dividindo cada valor da diferença dos atributos pelo valor do quadrado
do desvio padrão de cada atributo em questão, mantendo a soma dos valores resultantes e
calculando na mesma o valor da raíz quadrada no final. De seguida a equção com as alterações
efectuadas para o desvio padrão:
Problemas importantes na implementação do Sistema Protótipo
91
!
dist(s,a) =ai" s
i( )2
#i
2
i=1
n
$ , em que
!
s é o sumário resultante da agregação de um dia de
tráfego,
!
a é a assinatura do cartão em causa,
!
" é o valor de desvio padrão da medida em causa
e
!
i representa cada uma das medidas de perfil.
Esta fórmula será assim utilizada para comparar os valores dos sumários resultantes dos
processamentos diários e as assinaturas dos respectivos clientes.
Actualização das Assinaturas
No cálculo da actualização das assinaturas foi utilizada a fórmula apresentada por Cortes e
Pregibon (2001).
!
St+1 = b " S
t+ 1# b( ) "TR , em que
!
b representa a quantidade de peso dado à informação
nova,
!
St é uma assinatura,
!
St+1
é a actualização de
!
St resultando uma nova assinatura e
!
TR é o
resultado da transformação de um registo ou um conjunto de registos.
Esta mostrou-se bastante eficiente no tempo de processamento e muito fiável nos resultados. A
sua explicação detalhada encontra-se no Capítulo 3, secção 3.3.5, onde são apresentadas as
diversas técnicas utilizadas na detecção de comportamento fraudulento.
6.4 Inicialização de Clientes e criação de Modelos de
Fraude
Um dos objectivos deste projecto é a possibilidade de acrescentar assinaturas de clientes novos na
base de dados. Durante o processamento diário das assinaturas, poderão aparecer registos de
novos clientes, estes deverão ser tratados de forma a introduzir as novas assinaturas no sistema
ou então classificar os mesmos como fraude se for o caso.
Problemas importantes na implementação do Sistema Protótipo
92
Este processo pode tornar-se um pouco complicado, os métodos baseados em assinaturas
assumem que já existe uma assinatura para todas as entidades que aparecem na rede.
Diariamente aparecem novas entidades no sistema, constantemente novos números de telefone
ficam activos no sistema geral. Para suportar este comportamento, é necessário existir um método
robusto o suficiente que seja capaz de introduzir as novas assinaturas sem ser preciso esperar
semanas ou meses.
Depois de perceber o fluxo de dados e o funcionamento do algoritmo de processamento
estabelecido, surgiram algumas possíveis propostas de solução para a criação das assinaturas dos
clientes novos. De seguida a lista das soluções apresentadas e as respectivas desvantagens:
• Visto que os registos de clientes novos, que aparecem após o processamento de um dia de
tráfgo, são insuficientes para criar uma assinatura sólida capaz de traduzir o comportamento
habitual do cliente, a assinatura não seria criada nesse momento. Os registos de chamada e de
SMS seriam guardados numa estrutura de dados no sistema de detecção até completar uma
janela temporal definida.
Desvantagens – Caso sejam realmente situações de fraude estas podem não ser detectadas
em tempo útil. Pode tornar-se complexo saber quando fazer a inicialização dos clientes que já
completaram a janela temporal definida. É necessário maior espaço de armazenamento para a
informação temporária.
• Com base na informação existente dos sumários resultantes de um dia de tráfego dos clientes
novos, é criada uma assinatura cujos valores dos atributos são estimados. É criada uma média
de cada atributo e assume-se que o seu comportamento anterior e habitual é semelhante ao
dia de tráfego agregado.
Desvantagens - Os valores estimados podem não ser precisos e poderão surgir muitos falsos
alarmes.
• São criadas classes de equivalência com base nas assinaturas já existentes e é calculada a
evolução das mesmas periodicamente. Quando um novo cliente aparece no sistema, é
identificada a sua classe de equivalência e a sua assinatura toma o valor da sua classe.
Problemas importantes na implementação do Sistema Protótipo
93
Basicamente, é utilizada a informação das primeiras transacções para mapear os novos
clientes numa classe de equivalência. Por exemplo, consideremos o registo de duas chamadas
de um cliente novo. Através da informação da hora das chamadas e da duração das mesmas é
possível determinar de imediato se é um cliente de negócio ou normal.
Desvantagens – As acções de comparar os sumários diários de cada novo cliente com todas
as classes de equivalência e actualização períodica das classes de equivalência com base na
nova informação de todas as assinaturas aumenta a complexidade do sistema e a sua carga
computacional.
Depois de analisar as soluções existentes optou-se por escolher a úlima, baseada em classes de
equivalência. Para a finalidade que se pretende e como o projecto está em fase de protótipo,
apesar de eventuais problemas de performance que poderão surgir, a melhor solução é aquela que
reduz o número de falsos alarmes e que é capaz de detectar a fraude em tempo útil. As
desvantagens das duas primeiras soluções são, à primeira vista, mais graves do que a última. Após
a implementação da solução baseada em classes de equivalência, caso seja necessário, serão
feitos ajustes e melhoramentos de performance.
Para criar as classes de equivalência optou-se por utilizar a ferramenta de data mining Weka. Este
software possui algoritmos de clustering capazes de resolver o problema apresentado. Ao
introduzir a informação das assinaturas dos clientes como dados de input, é possível criar um
determinado número de clusters que representam as classes de equivalência que se pretende. As
assinaturas são agrupadas em função dos valores dos centróides de cada atributo no cluster. O
conjunto destes valores dos cenrtóides de cada cluster são os valores dos diferentes atributos das
diferentes classes de equivalência. Nas próximas secções será feita uma introdução ao software
Weka e serão descritos os vários passos realizados para a criação das classes de equivalência.
Software Weka
O software Weka (Waikato Environment for Knowledge Analysis) é constituído por um conjunto de
Problemas importantes na implementação do Sistema Protótipo
94
vários algoritmos de técnicas de Mineração de Dados. É uma ferramenta de KDD que engloba uma
série de algoritmos de preparação de informação, mineração e validação dos resultados. O Weka
foi desenvolvido na Universidade de Waikato em Nova Zelândia, inicialmente escrito na linguagem
C foi depois reescrito em Java. É código aberto e está disponível para download através da Web.
Uma das vantagens de estar escrito em Java é a possibilidade de correr em todas as plataformas,
aproveitando os benifícios de uma linguagem orientada aos objectos como polimorfismo,
modularidade, encapsulamento, reutilização de código etc.
Grande parte dos componentes que compõe o Weka são resultantes de diversos grupos de
investigação da Universidade de Waikato. Numa fase inicial, o software tinha como alvo técnicas
de machine learning, a sua aplicabilidade inicial foi direccionada para um dos sectores mais
importantes da economia na Nova Zelândia, a agricultura.
A interface gráfica incorporada é bastante amigável e os algoritmos existentes disponibilizam
relatórios com dados anlíticos e estatísticos do domínio em causa. Grande parte das
funcionalidades são acessíveis através da GUI, no entanto, os demais poderão ser utilizados
programaticamente através de API's. Existe também a documentação detalhada do código fonte
que está disponível online.
O Weka tem um formato próprio de arquivo de dados, chama-se ARFF e no seu conteúdo é
especificado o domínio dos atributos. Não é possível determinar o tipo dos atributos unicamente
através do seu valor, é necessário introduzir manualmente o seu domínio.
Antes de utilizar os dados no Weka é necessário convertê-los para o formato próprio ARFF. Este
formato segue um conjunto de regras que deverão ser cumpridas, de outra forma o ficheiro não
será reconhecido pelo programa. É necessário carregar o arquivo num editor de têxto e adicionar o
nome do conjunto de dados utilizando @relation nome_do_conjunto, para cada atributo utiliza-se
@attribute nome_do_atributo seguido do seu tipo (real, nominal, categórico etc), depois uma linha
com apenas @data e por baixo o conjunto de dados com os atributos separados por uma vírgula.
No final guarda-se o ficheiro com a extensão .arff. De seguida uma figura (Figura 27) com parte de
um ficheiro ARFF.
Problemas importantes na implementação do Sistema Protótipo
95
Figura 27 - Exemplo de parte de um ficheiro ARFF
Os dados utilizados para criar as classes de equivalência foram cerca de 600 registos de
assinaturas de clientes. São dados reais de 40 dias de tráfego da operadora em causa que estavam
a ser utilizados para fazer os testes com as funções de distância e definição dos limiares. Os dados
foram exportados do Oracle 10g para .csv apenas com os atributos necessários e depois o ficheiro
foi alterado com o formato em cima mencionado. De seguida a lista dos atributos importados para
o ficheiro ARFF.
CHAMADAS DESVIO PADRÃO
CHAMADAS SMS
DESVIO PADRÃO
SMS
duracao_chamadas_nac duracao_chamadas_nac_d num_sms_dias_uteis num_sms_dias_uteis_d
duracao_chamadas_roaming duracao_chamadas_roaming_d num_sms_fds num_sms_fds_d
num_chamadas_ef num_chamadas_ef_d num_sms_dia num_sms_dia_d
num_chamadas_rec num_chamadas_rec_d num_sms_noite num_sms_noite_d
num_chamadas_dias_uteis num_chamadas_dias_uteis_d num_sms_enviadas num_sms_enviadas_d
num_chamadas_fds num_chamadas_fds_d num_sms_recebidas num_sms_recebidas_d
num_chamadas_dia num_chamadas_dia_d num_sms_op_ig num_sms_op_ig_d
num_chamadas_noite num_chamadas_noite_d num_sms_op_dif num_sms_op_dif_d
num_chamadas_op_ig num_chamadas_op_ig_d num_sms_roaming num_sms_roaming_d
num_chamadas_op_dif num_chamadas_op_dif_d num_sms_roaming_en num_sms_roaming_en_d
Problemas importantes na implementação do Sistema Protótipo
96
num_chamadas_roaming num_chamadas_roaming_d num_sms_roaming_rec num_sms_roaming_rec_d
num_chamadas_roaming_ef num_chamadas_roaming_ef_d
num_chamadas_roaming_rec num_chamadas_roaming_rec_d
Tabela 6 – Lista de atributos utilizados para criar as classes de equivalência
De forma a testar as capacidades dos algoritmos para determinar o número óptimo de clusters,
foram realizadas várias experiências e os diversos resultados foram analisados e comparados. O
único algoritmo capaz de gerar um número de clusters razoável automaticamente, ou seja, sem
ser necessário introduzir o número de clusters a serem criados, foi o algoritmo Expectation
Maximization (EM). O tipo de resultados obtidos pelos algoritmos SimpleMeans e Xmeans também
é relevante, porém, o número de clusters é constante no caso do SimpleMeans ou inserido
manualmento no caso do Xmeans.
O ponto de referência para a escolha do algoritmo foi a percentagem obtida na distribuição das
diferentes assinaturas pelos clusters. A partir de determinada altura, com o aumento do número de
clusters, estes começam a ter valores muitos semelhantes nos seus centróides, tornando o
aumento do número de clusters não eficiente e impreciso.
Para tentar obter o número correcto de clusters foi necessário ajustar o valor de K nas
propriedades do algoritmo EM do Weka. Este valor é utilizado para inicializar o número gerador
aleatório. Os centróides iniciais são inicialmente definidos seleccionando aleatoriamente instâncias
do conjunto de treino.
Uma estratégia simples passa por encontrar o valor óptimo de K. Através da soma dos erros
quadrados dos clusters é possível determinar a qualidade dos resultados. Quanto menor este valor
melhor. Para entender a variância dos centroides escolhidos aleatoriamente, foi necessário correr o
algoritmo K vezes com as diferentes sementes, e no final fazer a análise dos resultados. Um
problema desta abordagem é que, normalmente, quanto maior o valor de K melhor. O extremo de
ter o mesmo número de clusters como instâncias devolve como soma de erros quadrados o valor
0. Por este motivo, foi utilizada a validação cruzada como método para obter uma estimativa
menos tendenciosa na performance de clustering. Em vez de utilizar os dados de treino para
avaliar a performance, a validação cruzada simula a utlização de dados reais através da separação
dos dados de treino em conjuntos disjuntos. Dado isto, os melhores resultados foram obtidos com
o algoritmo EM, o valor de K foi ajustado para 80 e o número de clusters obtido com validação
cruzada foi 8. De seguida uma imagem (Figura 28) com parte dos resultados obtidos.
Problemas importantes na implementação do Sistema Protótipo
97
Figura 28 - Lista de resultados obtidos na criação de classes de Assinaturas no Weka
No final, estes resultados foram armazenados no sistema de detecção do protótipo, na tabela
Assinaturas_Classe, e o algoritmo de processamento foi adaptado para quando surgir um
cliente novo, o sumário é comparado com cada uma das classes existentes e a sua assinatura é
criada com os valores da classe mais semelhante. O processo de exportação e determinação das
classes de equivalência será executado uma vez por mês e os valores das classes antigas são
eliminados. Desta forma é possível manter as classes que traduzem o comportamento mais
recente de todos os clientes.
O método de detecção supervisionada, com base em modelos de fraude conhecidos à partida, é
uma mais valia para complementar o protótipo de assinaturas. Ao manter assinaturas com perfis
de fraude que traduzem comportamentos fraudulentos que ocorreram no passado, é possível
Problemas importantes na implementação do Sistema Protótipo
98
compara-las com os sumários que são processados diariamente e detectar tipos de fraude foram
classificados com sucesso. Este método permite identificar grande parte dos perfis de fraude
existentes. Por um lado são detectados desvios anómolos de comportamento e novos tipos de
fraude poderão ser encontrados, por outro lado os perfis previamente conhecidos são utilizados
para detectar comportamentos habituais de fraude. Este perfis conhecidos podem ser também
disponibilizados pelos restantes componentes de detecção do sistema. Os casos classificados como
fraude, através da aprendizagem não supervisionada, são armazenados e poderão posteriormente
ser utilizados na detecção supervisionada. Como podemos ver, ambos os métodos complementam-
se e são flexíveis.
Apesar do sistema implementado já possuir a estrutura necessária para armazenar os casos
classificados como fraude, visto que o protótipo está a ser testado pela primeira vez, ainda não
existem casos guardados. Para solucionar o problema serão utilizados casos de fraude detectados
pelo sistema de regras do Centaur. Depois de identificar os casos rotulados como fraude, o
comportamento dos clientes associados será agregado e a informação será exportada para uma
ferramenta de mining. Nesta ferramenta serão criados os modelos de fraude que traduzem o
comportamento ilegítimo.
Foi feito um estudo á estrutura de armazenamento e aos respectivos dados. Descobriu-se que
existem algumas tabelas essenciais para filtrar a informação necessária. Existe uma tabela
chamada Cases onde são armazenados todos os casos alarmados e toda a informação associada,
esta tabela contém várias tabelas associadas, das quais existem quatro que interessa analisar para
fazer a filtração correcta. De seguida a tabela principal onde são armazenados todos os casos
(Cases) e uma explicação breve dos atributos mais importantes.
Casos
• id_case – Identificador único do caso em questão.
• id_context – Atributo que identifica o contêxto associado ao caso, pode ser contêxto de cartão
de cliente, de célula, de conta de cliente, de país, de NIF, de IMSI etc.
• context – Atributo que representa o número associado ao contêxto, no caso do cartão de
Problemas importantes na implementação do Sistema Protótipo
99
cliente este atributo contém o número de telefone associado ao cartão.
• id_fraud – Este atributo identifica o tipo de fraude que está associado ao caso, pode ser fraude
interna, fraude de subscrição, fraude técnica etc.
• id_case_status – Este atributo identifica o estado actual do caso, se foi fechado, se está em
espera, ou se está em análise.
• id_classification – Atributo que representa a classificação atribuída a este caso, pode ser
fraude, desconhecido ou não fraude.
Depois de analisar a informação dos casos e clientes associados, foram encontradas algumas
limitações. Visto que os casos são eliminados algum tempo depois de serem fechados e como a
janela temporal dos mesmos é curta, optou-se por criar os modelos de fraude com base na
informação não só dos cartões classificados como fraude e fechados mas também de todos os
cartões que estão em análise ou em espera. Após alguns testes verifou-se que a informação
existente dos cartões classificados como fraude era muito escassa e produzia poucos resultados, e
muito superficiais para o que se pretende. Para efeitos de mineração de dados, para construir os
clusters relativos aos modelos de fraude, é necessário possuir determinada quantidade de dados
senão os modelos produzidos são demasiado genéricos e poderão depois originar falsos alarmes.
Numa fase inicial, de forma a testar o protótipo, foi obrigatório trabalhar com os dados existentes,
o sistema anterior não está preparado para este tipo de detecção supervisionada e
consequentemente existe pouca informação para obter resultados de elevada qualidade. Num
futuro próximo, é possível que haja uma remodelação da estrutura existente de maneira a
armazenar os casos que vão sendo classificados como fraude e periodicamente estes vão sendo
actualizados, tornando-se mais sólidos e fiáveis. Quanto maior o histórico de casos ilegítimos maior
a qualidade dos modelos de fraude produzidos. Estas assinaturas fraudulentas funcionam como o
perfil de assinaturas existente, as actualizações constantes tornam o perfil mais robusto e próximo
da realidade. As assinaturas fraudulentas também serão construídas com base nos registos diários
dos clientes, a única diferença é que a informação a agregar é relativa a comportamentos
fraudulentos. Existem assim dois pontos importantes a considerar:
Problemas importantes na implementação do Sistema Protótipo
100
• Os modelos de fraude construídos dependem da qualidade e quantidade de informação
existente.
• É necessário saber a partir de que momento se iniciou a fraude para não incluir
comportamento legítimo na agregação dos dados.
Para exportar a informação foi necessário identificar quais os contextos associados aos casos
alarmados que são relevantes para o problema, e depois retirar todas as transacções fraudulentas
associadas a esse contexto. Neste caso apenas nos interessa contêxtos associados ao cartão e os
tipos de fraude de subscrição e fraude técnica. Os restantes tipos de fraude não foram incluídos
pois não existem registos com contexto de cartão associados.
As interrogações efectuadas para extrair os contextos necessários foram:
select context from exp_cases where id_fraud = 3 and id_context = 1 select context from exp_cases where id_fraud = 4 and id_context = 1
Depois foi retirada e agregada a informação associada a esses contextos. De seguida, um pequeno
extracto do código utilizado (Figura 29):
Problemas importantes na implementação do Sistema Protótipo
101
Figura 29 - Parte do código utilizado para obter a informação do histórico de casos de fraude
Após a agregação dos dados estes foram exportados para .csv e depois disso submetidos a um
processo de mineração de dados. Este processo, responsável por construir os modelos de fraude,
foi idêntico ao que foi explicado para obter os clusters relativos ás classes de equivalência dos
perfis de clientes legítimos. A diferença foi que para os modelos de fraude foram utilizados
diferentes conjuntos de dados, cada um relativo a tipos de fraude diferentes, neste caso registos
de clientes com fraude de subscrição e registos de fraude técnica.
No final foram gerados quatro modelos de fraude de subscrição e quatro modelos de fraude
técnica. A figura 30 mostra o fluxo da informação de todo o processo efectuado e a tabela 7 o
resultado obtido após a mineração de dados onde é apresentado cada um dos modelos de fraude
obtidos com algumas das medidas de perfil.
Problemas importantes na implementação do Sistema Protótipo
102
Figura 30 - Fluxo da informação durante o processo de criação de modelos de fraude
Tabela 7 – Modelos de fraude obtidos no Weka através do algoritmo EM
Análise e Validação de Potenciais Casos de Fraude
103
Capítulo 7
7Análise e Validação de Potenciais casos de
Fraude
7.1 Análise Geral de Alarmes
Para a realização deste estudo foram disponibilizados registos CDR de chamadas e de SMS reais de
uma operadora móvel. Estes registos são relativos ao uso de 507 clientes. Destes clientes sabe-se
que 5 deles foram classificados como fraude pelo sistema de detecção de fraude sem o
componente de assinaturas. Os registos utilizados para a inicialização das assinaturas estão
compreendidos entre as datas 01-06-2010 e 25-06-2010. Foram utilizados 7057489 registos,
4285758 de SMS e 1107708 de voz. A máquina onde foram realizados todos os testes é um
servidor virtual dedicado (VPS – Virtual Dedicated Machine) que funciona sobre uma máquina física
na qual são partilhados todos os recursos. A base de dados de detecção e a componente lógica do
protótipo está suportada por uma instância Oracle, instalada na mesma máquina. De seguida
apresentamos, somente a título de referência, as características da máquina utilizada:
• Marca: HP.
• Modelo: Proliant DL-385 G1.
• Processadores: 2 x AMD Opteron(tm) Processor 275.
• Memória: 6GB.
Análise e Validação de Potenciais Casos de Fraude
104
• Discos: Raid 0 (250GB).
• Sistema Operativo: Oracle Enterprise Linux 5.3 64bit (kernel 2.6.22.19-vs2.3.0.34.1).
• Base de Dados: Oracle 10g_x64 (10.2.0.4).
• Rede: 100MB.
O tempo total para inicializar todas as assinaturas foi de 373,58 segundos. Para efeitos de análise
e de teste, foi feito o processamento diário desde o dia 26-06-2010 até 05-07-2010 (Tabela 8).
O processamento foi feito com valores de limiar na ordem dos 10.5, para a distância entre os
sumários diários e as assinaturas dos respectivos clientes, e 4, para a distância entre os sumários e
os modelos de assinaturas fraudulentas. Para todos os casos de sumários com valor de distância
superior a 10.5, em relação à sua assinatura, ou valor de distância inferior a 4, em relação a algum
modelo de assinatura fraudulenta, serão gerados os respectivos alarmes. De seguida, na tabela 8,
apresentamos os tempos de processamento de cada dia de tráfego.
DATA REGISTOS DE VOZ REGISTOS DE SMS TEMPO DE PROCESSAMENTO
26/06/2010 166574 13560 34,641
27/06/2010 147920 124573 36,547
28/06/2010 186059 141228 39,875
29/06/2010 189911 145029 64,797
30/06/2010 186384 142833 44,515
01/07/2010 161976 123446 51,422
02/07/2010 177205 141932 49,734
03/07/2010 145203 124836 49,047
04/07/2010 140067 123369 48,063
05/07/2010 162722 127708 42,266
Tabela 8 - Tempos de processamento e número de registos diários no período de detecção
Para verificar a eficácia do sistema na detecção de casos de fraude, foram disponibilizados alguns
casos (Tabela 9) com variações de comportamento em diferentes tipos de consumos, que
ocorreram dentro das datas nas quais vai ser testado o processamento diário – estes casos já
foram confirmados pelos analistas como sendo casos de fraude e além disso, foram detectados
Análise e Validação de Potenciais Casos de Fraude
105
também pelo sistema de regras já existente no Centaur. Por motivos de privacidade, os números
de telefone utilizados foram encriptados, sendo que nenhum dos números corresponde a um
número de um utilizador real. Optou-se por utilizar apenas os primeiros seis caracteres de cada
número, visto que todos os 507 números gerados são diferentes.
ID_CASE CONTEXT CREATION DATE
FRAUD TYPE MOTIVATION METHOD PROFILE
82289 927253*** 05-07-10 Subscricão Utilizacão Pessoal Consumos GPRS
Roaming
82291 965873*** 05-07-10 Subscricão Utilizacão Pessoal Consumos PRS SMS
82065 927010*** 29-06-10 Subscricão Utilizacão Pessoal Consumos PRS SMS
82061 961911*** 29-06-10 Subscricão Utilizacão Pessoal Consumos PRS SMS
81720 925971*** 28-06-10 Subscricão Utilizacão Pessoal Consumos Roaming
Tabela 9 – Lista de casos classificados como fraude
Como podemos verificar, no perfil destes clientes fraudulentos existem três tipos de consumos
diferentes, o que permitirá testar se o protótipo desenvolvido tem sensibilidade suficiente (ou não)
para fazer a sua detecção. É, também, uma maneira mais efectiva para verificar se os pesos nas
fórmulas de distância estão afinados e se as abordagens seguidas até ao momento estão
correctas.
Depois de se fazer o processamento dos dados disponíveis até ao dia 05/07/2010 foi feita uma
query à tabela dos casos suspeitos, filtrando os atributos mais importantes para a fase de análise
em causa. Os resultados obtidos, ordenados por ordem descendente de valor de alarme, podem
ser observados na figura 31.
Análise e Validação de Potenciais Casos de Fraude
106
Figura 31 – Lista de alarmes gerada pelo sistema protótipo
Análise e Validação de Potenciais Casos de Fraude
107
Com base nos valores obtidos nesse processamento, podemos de imediato constatar que foram
detectados 3 casos suspeitos, relativos a sumários semelhantes, a modelos de assinaturas
fraudulentas e 28 casos relativos à distância entre os sumários e as respectivas assinaturas. As
linhas preenchidas com a cor amarela são relativas aos casos que foram anteriormente
classificados pelos analistas como fraude.
Numa primeira abordagem, verificámos que o protótipo não só detectou todos os casos de fraude
disponibilizados como também conseguiu detectar as situações anómolas mais cedo que o sistema
de regras do Centaur. Na lista completa, 4 dos 5 casos de fraude disponibilizados estão nos
primeiros 8 lugares da tabela e têm um valor de alarme bastante elevado (>99). Outro facto muito
importante é a compatibilidade existente destes casos na variação do tipo de consumos. O sistema
não só aparenta ter os pesos devidamente afinados como descarta a hipótese de ser uma
coincidência. Vejamos então:
• O perfil de fraude do número 927010*** é de PRS SMS, o que coincide com o atributo que
obteve maior variação em relação ao comportamento habitual, ou seja, o atributo de maior
impacto foi Num_sms_dias_uteis com valor 446.
• O perfil de fraude do número 961911*** é de PRS SMS, o que coincide com o atributo que
obteve maior variação em relação ao comportamento habitual, ou seja, o atributo de maior
impacto foi Num_sms_dias_uteis com valor 269.
• O perfil de fraude do número 927253*** é de GPRS roaming, o que coincide com o atributo
que obteve maior variação em relação ao comportamento habitual, ou seja, o atributo de
maior impacto foi Num_sms_roaming com valor 6.
• O perfil de fraude do número 965873*** é de PRS SMS, o que coincide com o atributo que
obteve maior variação em relação ao comportamento habitual, ou seja, o atributo de maior
impacto foi Num_sms_dia com valor 21.
Apesar de terem sido detectados todos os casos disponibilizados, o perfil do último caso relativo ao
número 925971*** não coincide com o atributo de maior impacto na lista dos casos suspeitos
obtida. Através da tabela 9, com os dados dos clientes fraudulentos conhecidos, podemos verificar
que este caso tem um perfil de consumos roaming e na lista de alarmes do protótipo de
assinaturas verifica-se que este tem o Num_chamadas_fds como atributo de maior impacto.
Análise e Validação de Potenciais Casos de Fraude
108
Numa fase posterior, cada caso será estudado em detalhe, nessa altura irá ser possível verificar se
este caso está relacionado com algum problema de afinação dos limiares, se este alarme é a
representação de um começo da actividade fraudulenta, se o cliente teve diferentes
comportamentos fradulentos ou se foi apenas uma mera coincidência.
De seguida, vão ser analisados os atributos que tiveram maior impacto (ou importância) na
geração dos alarmes. Os atributos de maior impacto são facilmente determinados. No cálculo da
distância entre os sumários e as assinaturas, antes de somar a distância individual de cada
atributo, verifica-se qual o atributo que tem o maior valor. Esse atributo representa a variável que
mais se desviou do comportamento habitual. Este tipo de análise é bastante importante para os
analistas de fraude. Com os resultados obtidos é possível compreender as novas tendências de
fraude e consequentemente afinar os pesos e os limiares correctamente. Os próximos
processamentos e geração de alarmes poderão assim ser melhorados.
Para dar início à análise de resultados ao longo do processo, apresentamos na figura 32 um gráfico
que permite ver a quantidade de alarmes que foram lançados durante o período de processamento
dos dados.
Figura 32 – Número de alarmes gerados durante o período de processamento
Análise e Validação de Potenciais Casos de Fraude
109
Olhando para esse gráfico, rapidamente se conclui que os dias em que se registou o maior número
de alarmes foram os dias 01-07-2010 e 02-07-2010. Estas duas datas, para além de serem as que
obtiveram o maior número de alarmes, estão uma a seguir à outra e correspondem precisamente
ao início do mês de Julho. Outro facto a registar é que, a maior parte dos alarmes ocorreram em
dias úteis da semana e não ao fim de semana. Em ambos os Sábados que foram processados, dias
26-06-2010 e 03-07-2010 respectivamente, foram lançados o mesmo número de alarmes, três
alarmes. Na quarta-feira, dia 30-06-2010, não houve o registo de nenhum alarme.
Este tipo de análise também é bastante relevante para os analistas, com esta informação é
possível afinar e preparar o sistema de forma diferente consoante os dias ou momentos em
questão. Também é possível estudar as causas dos acontecimentos e desta forma aumentar a
eficácia na prevenção de fraude. Na figura 33 pode-se verificar a percentagem de ocorrências de
cada atributo durante o período de processamento (26-06-2010 até 05-07-2010). Podemos
rapidamente concluir que os atributos que tiveram maior impacto durante todo esse período foram
a Duracao_chamadas_nacional e Num_sms_roaming, sendo o primeiro destes atributos o
mis relevante.
Figura 33 – Percentagem de ocorrências de cada atributo durante o período de processamento
Análise e Validação de Potenciais Casos de Fraude
110
Apesar dos valores obtidos, a informação por si só pode induzir em erro. Poderá acontecer que a
maior parte dos alarmes que envolveram o atributo de maior impacto
(Duracao_chamadas_nacional) sejam aqueles que tiveram o menor valor de alarme. Neste
caso podem existir outros atributos que não tenham tantas ocorrências, mas que são responsáveis
pelos alarmes com maior significado. Para verificar se a lista de alarmes corresponde a esta
situação, a figura 34 mostra os 10 primeiros alarmes, ordenados pelo seu valor de distância, e os
atributos de maior impacto.
Figura 34 – Top 10 dos alarmes ordenados pelo valor de distancia
Olhando para os valores apresentados no gráfico, podemos verificar que apesar do atributo
Duracao_chamadas_nacional ser o atributo com maior impacto na totalidade dos alarmes.
Mas, considerando os 10 alarmes com maior valor de distância, o atributo com maior impacto é o
Num_sms_roaming com 3 ocorrências. Também se pode verificar que os atributos relacionados
com o serviço se mensagens escritas têm maior peso do que os atributos relacionados com o
serviço de chamadas de voz. De salientar que nenhum dos atributos que têm maior impacto na
lista de todos os alarmes, ou na lista dos 10 mais importantes, é responsável pelo alarme que
Análise e Validação de Potenciais Casos de Fraude
111
aparece em primeiro lugar com valor superior a 1400, para este o caso o atributo responsável é
Num_sms_dias_uteis.
Para perceber a variação dos valores de distância no processamento diário de um único cliente foi
escolhido ao acaso um cartão da lista de casos suspeitos. A figura 35 apresenta os valores de
distância obtidos em cada dia de processamento desse cliente. A linha vermelha representa o valor
de limiar definido, desta forma é possível verificar quantas vezes foi ultrapassado o limiar após o
dia de alarme.
Figura 35 – Valores de distancia nos dias de processamento para o cartão 964042***
Pelos resultados obtidos (Figura 35) podemos deduzir que o cliente manteve sempre um
comportamento regular. Apenas no dia do alarme se verifica uma diferença grande no resultado da
distância, ultrapassando muito o limiar estabelecido (10.5). Nos dias após o dia de alarme, o valor
de distância não ultrapassou o valor de limiar. Muitos clientes desviam gradualmente o seu
comportamento até ao ponto de o fazerem em demasiado, o que não é o caso deste cartão. Esta
análise é bastante importante. Através deste gráfico é possível verificar a evolução dos valores de
distância do cliente e também verificar se o cliente após o alarme mantém o comportamento
Análise e Validação de Potenciais Casos de Fraude
112
fraudulento ou não.
Para entender melhor a principal causa do valor de distância, ou seja o atributo que teve o maior
valor de distância individual, será feita uma análise semelhante mas desta vez considerando os
atributos de maior impacto. Com o gráfico seguinte será possível determinar se o atributo impacto,
com mais ocorrências antes do alarme, é o mesmo do dia de alarme, se os atributos impacto vão
variando etc. Esta informação também é importante para os analistas pois permite perceber que
tipo de serviços estão a ser excessivamente utilizados, se o tipo de utilização varia antes e depois
do alarme, ou mesmo se o valor de distância com determinado atributo impacto em diferentes dias
são indícios de algum tipo de fraude conhecido. De seguida, na figura 36 apresentamos um gráfico
de um cliente escolhido aleatoriamente da lista de casos suspeitos.
Figura 36 – Distâncias e atributos de maior impacto, em cada dia de processamento, para o cartão
927792***
Análise e Validação de Potenciais Casos de Fraude
113
Olhando para o gráfico da figura 36, rapidamente se pode concluir que o atributo de maior impacto
no dia de alarme não é o mesmo que aqueles obtidos até esse dia. Verifica-se que o atributo
impacto com maior peso nas distâncias até o dia de alarme doi o atributo
Duracao_chamadas_nac. Depois do dia de alarme, verifica-se que o cliente manteve sempre o
mesmo comportamento anómolo, o atributo impacto no dia de alarme e após o mesmo foi o
Num_sms_roaming, os valores de distância obtidos afastam-se exageradamente do valor de
limiar definido (10,5).
7.2 Análise Detalhada de Casos
Casos de fraude detectados pelo sistema de regras e presentes na lista
de casos suspeitos
Cartão 927010*** – Valor de alarme 1493,9
Este utilizador tem apenas 1 registo de SMS, no dia 09-06-2010, antes de ser detectado Esse
registo é relativo à recepção de uma mensagem escrita de um cliente de outra operadora. Com
base na informação obtida até o dia de alarme, podemos deduzir que ou o cliente já estava
registado no sistema antes do dia 01-06-2010, e nunca enviou ou recebeu qualquer SMS ou
chamada para além do registo do dia 09-06-2010, ou então o utilizador tornou-se cliente da
operadora em causa no dia 09-06-2010 e nunca mais foi registada qualquer transacção até o dia
28-06-2010. Depois da inicialização da assinatura do cliente, o comportamento habitual deste é
praticamente nulo, apenas existe o registo de uma transacção. No dia 28-06-2010, foram
registadas 446 mensagens escritas e 2 chamadas de voz associadas à conta do cliente,
comportamento completamente diferente do habitual. Para tentar compreender melhor a situação
vai ser relatado também o seu comportamento nos dias seguintes até 05-07-2010. Um dia depois
do alarme, no dia 28-06-2010, o comportamento do cliente varia ainda mais em relação ao
habitual. São registadas 743 mensagens escritas e nenhuma chamada de voz, foi neste dia que o
sistema baseado em regras do Centaur lançou o alarme. Nos dias seguintes, são registadas 63
mensagens escritas. No dia 30-06-2010 e depois o cliente volta ao comportamento habitual, não
Análise e Validação de Potenciais Casos de Fraude
114
existindo o registo de mais nenhuma mensagem ou chamada de voz. De seguida um gráfico
(Figura 37) que ajuda a perceber a variação de comportamento deste cliente ao longo do tempo.
Figura 37 – Variação de comportamento do cartão 927010***
Como podemos ver, este cliente foi detectado com sucesso pelo protótipo de assinaturas. O
execessivo registo de SMS nos dias 28-06-2010 e 29-06-2010 vão de encontro ao que foi relatado
pelo sistema de regras do Centaur. Este comportamento anómalo pode ter a ver com alguma
fraude técnica, ou alguma fraude provocada por outro utilizador através do roubo do telefone ou
mesmo fraude de subscrição. No tabela produzida pelo sistema de regras pode-se verificar que
este caso está rotulado como fraude de subscrição, no entanto, não se sabe se esta atribuição foi
efectuada pelo próprio sistema ou pelos analistas.
Cartão 961911*** – Valor de alarme 408,2
Este utilizador apresenta registos de tráfego a partir do dia 18-06-2010 até o dia de alarme (26-01-
2010). Antes dessa data, ou seja, a partir do início de inicialização das assinaturas (01-06-2010)
até 18-06-2010, o cliente não tem qualquer transacção registada. Tal como o caso anterior, ou o
utilizador já estava registado no sistema, e nunca enviou ou recebeu SMS ou chamadas até o dia
18-06-2010, ou então tornou-se cliente da operadora no dia do primeiro registo. Do dia 18-06-
2010 até ao dia de alarme, os valores registados traduzem uma média de 5 chamadas de voz e 3
SMS diários. No dia 26-06-2010, foram registadas 384 SMS e 34 chamadas de voz associadas à
conta do cliente, o que revela um comportamento muito diferente do habitual, principalmente em
relação ao número médio de SMS. Para tentar compreender melhor a situação vai ser relatado
também o comportamento do cliente nos dias seguintes até 05-07-2010. A partir do dia do alarme
até ao dia 01-07-2010, o cliente apresenta uma média de 199 SMS e 14 chamadas de voz. O
número de SMS registado nestes dias continua a ser muito diferente do habitual, já o número de
Análise e Validação de Potenciais Casos de Fraude
115
chamadas de voz aproxima-se um pouco mais do normal. A partir do dia 01-07-2010 até o último
dia de processamento, apenas se verifica o registo de mais uma SMS no dia 03-07-2010. De
seguida apresentamos um novo gráfico (Figura 38) que ajuda a perceber a variação de
comportamento deste cliente ao longo do tempo.
Figura 38 – Variação de comportamento do cartão 961911***
Como podemos ver este cliente foi detectado com sucesso pelo protótipo de assinaturas. O
excessivo registo de SMS a partir do dias 26-06-2010 até ao dia 01-07-2010 vai de encontro ao
que foi relatado pelo sistema de regras do Centaur. De salientar que o sistema de regras alarmou
este caso no dia 29-06-2010. O facto do cliente diminuir o número de registos a partir do dia 01-
07-2010 pode ter a ver com o facto do mesmo ter sido abordado pelas entidades responsáveis ou
então, caso seja um telefone roubado, o utilizador fraudulento pode ter deixado de ter em sua
posse o cartão em causa.
Cartão 927253*** – Valor de alarme 108,1
Este utilizador, apenas apresenta três registos na janela temporal utilizada para construir a sua
assinatura. Esses três registos são de SMS (não roaming) e ocorreram nos dias 05-06-2010, 06-06-
2010 e 07-07-2010 respectivamente. Nos restantes dias não existe mais nenhuma transacção de
SMS nem chamada de voz. A partir do primeiro dia de processamento, dia 26-06-2010, até ao dia
de alarme (01-07-2010), apenas existe o registo de duas transacções relativas a mensagens
escritas de serviço de roaming. Ambas as SMS foram registadas no dia 30-06-2010 e,
naturalmente, não foram motivo para lançar qualquer tipo de alarme. O comportamento do cliente
até ao dia 30-06-2010 manteve-se dentro dos valores da média do seu comportamento normal.
No dia do alarme, dia 01-07-2010 foram registadas 15 mensagens SMS, 6 delas referentes a
serviço de roaming. Para além do número de SMS ser muito diferente do comportamento habitual,
o número de SMS roaming também não corresponde ao habitual. Visto que o sistema está afinado
Análise e Validação de Potenciais Casos de Fraude
116
para detectar com mais facilidade os casos suspeitos de roaming, devido ao prejuízo que este tipo
de serviços causa ás empresas de telecomunicações, os números obtidos foram suficientes para
alarmar. Para tentar compreender melhor a situação vai ser relatado também o comportamento do
cliente nos dias seguintes até 05-07-2010. Foram registadas também 3 SMS no dia 02-07-2010, 2
das quais referentes a serviço de roaming, depois foram registadas 7 SMS no dia 03-07-2010, 3
das quais também referentes a serviço de roaming. Nos últimos dois dias de processamento não
houve mais qualquer registo. Em nenhuma ocasião se verificou o registo de transacções de
chamadas de voz. Nos últimos dias de processamento verifica-se uma descida no número de SMS
registadas, aproximando-se do comportamento habitual. Na figura 39 apresentamos um gráfico
que ajuda a perceber as variações relatadas ao longo do tempo para este cliente.
Figura 39 – Variação de comportamento do cartão 927253***
Como podemos ver, este cliente foi detectado com sucesso pelo protótipo de assinaturas. A
variação de comportamento no dia 01-07-2010 vai de encontro ao que foi relatado pelo sistema de
regras. O perfil de fraude não é o mesmo, mas em ambos os casos se verifica problemas nos
serviços de roaming. O componente de assinaturas implementado, não está ainda a tratar os
registos de GPRS. De salientar que o sistema de regras alarmou este caso no dia 05-07-2010, data
referente ao último dia de processamento onde já não foi possível obter informação completa. O
facto de o protótipo não tratar registos de GPRS e mesmo assim conseguir antecipar o
comportamento fraudulento de roaming através de variações de comportamento nas SMS significa
que os pesos, para situações de roaming, estão bem afinados. No entanto, o valor de limiar poderá
ser muito baixo e podem estar a aparecer alguns falsos alarmes. Esta situação será analisada nas
secções seguintes.
Análise e Validação de Potenciais Casos de Fraude
117
Cartão 965873*** – Valor de alarme 99,61
Ao contrário dos cartões até agora vistos, este cartão não apresentou qualquer registo durante o
período de inicialização das assinaturas, de 01-06-2010 a 25-06-2010. Isto significa que o
utilizador, durante o processamento diário, não tinha nenhuma assinatura associada e, portanto,
não houve qualquer comparação com assinaturas no aparecimnto da primeira transacção. De
seguida, apresentamos a tabela 10 com o registo das medidas mais importantes durante o período
de processamento.
Tabela 10 – Tabela com as medidas mais importantes, durante o período de processamento, do
cartão 965873***
O primero registo deste utilizador foi identificado no dia 01/07/2010, tal como se pode verificar na
tabela 10, o seu comportamento traduziu-se na recepção de apenas duas mensagens escritas.
Visto que a sua assinatura não existia, o sumário diário foi comparado com as classes de
equivalência. A classe que passou a traduzir o comportamento deste utilizador apresenta as
seguintes características:
• duracao_chamadas_nac - 109,31292976463
• duracao_chamadas_roaming - 0,365908474323285
• num_chamadas_ef - 30,7973483207669
• num_chamadas_rec - 11,8071835967001
• num_chamadas_dias_uteis - 63,2626984126984
• num_chamadas_fds - 55,4080498866213
• num_chamadas_dia - 38,5873769659197
• num_chamadas_noite - 4,57579083457833
• num_chamadas_op_ig - 37,5972430752679
• num_chamadas_op_dif - 5,56592472523017
• num_chamadas_roaming - 0,0127811713191024
• num_chamadas_roaming_ef - 0,0102304734537493
• num_chamadas_roaming_rec - 0,00255069786535304
Análise e Validação de Potenciais Casos de Fraude
118
• num_sms_dias_uteis - 220,864285714286
• num_sms_fds - 157,524744897959
• num_sms_dia - 129,774549044994
• num_sms_noite - 15,6627221956973
• num_sms_enviadas - 135,828050428563
• num_sms_recebidas - 9,11035418651267
• num_sms_op_ig - 137,71029856936
• num_sms_op_dif - 7,72697267133169
• num_sms_roaming - 0,043549705801861
• num_sms_roaming_en - 0,00960960591133005
• num_sms_roaming_rec - 0,0339400998905309
Os valores de desvio padrão dos atributos serão mencionados quando necessários na análise da
comparação com os sumários dos processemantos diários seguintes. Os registos seguintes deste
utilizador foram relativos ao processamento do dia 03/07/2010. Neste dia foram registadas 21
transacções associadas à recepção e envio de mensagens escritas. Depois da comparação com os
valores da assinatura atribuída, neste dia não houve qualquer tipo de alarme, a assinatura foi
actualizada normalmente e o comportamento do cliente mantêve-se dentro da normalidade. No dia
de alarme, dia 04-07-2010, foram registadas 602 SMS. Este valor é muito diferente do
comportamento habitual do cliente, os valores de desvio padrão não são elevados o suficiente de
forma a não alarmar este caso. Se compararmos com os valores obtidos durante o processamento,
sem a atribuição dos valores da sua classe de equivalência, a varição de comportamento ainda é
maior. No último dia de processamento, dia 05-07-2010, foram registadas 293 SMS, o número de
SMS desceu bastante mas mantêve-se superior ao número médio. Em nenhuma ocasião se
verificou o registo de transacções de chamadas de voz. Como podemos ver, este cliente foi
detectado com sucesso pelo protótipo de assinaturas. A variação de comportamento no dia 04-07-
2010 vai de encontro ao que foi relatado pelo sistema de regras. De salientar que o sistema de
regras do Centaur alarmou este caso um dia depois do protótipo implementado, no dia 05-07-
2010, data referente ao último dia de processamento. O perfil de fraude, da tabela (Tabela 9) de
casos fraudulentos disponibilizados, coincide com o atributo de maior impacto. O facto de não
existirem registos durante o período de inicialização das assinaturas e depois existir um
comportamento anómolo nos primeiros dias de processamento vai de encontro ao tipo de fraude
que foi rotulado para este caso, fraude de subscrição.
Análise e Validação de Potenciais Casos de Fraude
119
Cartão 925971*** – Valor de alarme 10,87
Este utilizador apresenta registos de tráfego a partir do dia 17-06-2010 até o dia de alarme (27-06-
2010). Antes dessa data, ou seja a partir do início de inicialização das assinaturas (01-06-2010) até
17-06-2010, o cliente não teve qualquer transacção registada. Neste caso, ou o utilizador já estava
registado no sistema e nunca enviou ou recebeu SMS ou chamadas até o dia 17-06-2010 ou então
tornou-se cliente da operadora no dia do primeiro registo. Do dia 18-06-2010 até ao dia de alarme,
os valores registados traduzem uma média de 5 chamadas de voz em dias úteis e 1 chamada aos
fins de semana, dessas chamadas em média uma é relativa a serviço de roaming. Quanto às
mensagens escritas, os valores que traduzem o comportamento habitual do utilizador são 8 SMS
em dias úteis e 6 sms em dias de fim de semana - em média, destas sms 3 são relativas a serviço
de roaming. O dia de alarme foi num dia de fim de semana, dia 27-06-2010, em que se registaram
37 chamadas de voz, 1 relativa a serviço de roaming, e 48 mensagens escritas, 7 relativas a
serviço de roaming. Podemos de imediato verificar a diferença, relativamente acentuada, no
número médio de chamadas ao fim de semana e no número médio de SMS. Infelizmente, ao
contrário do que está na tabela 9 de fraudes disponibilizada, não se verifica nenhuma mudança
acentuada nos valores relativos ao serviço de roaming no dia de alarme. Porém, irá ser analisado o
próximo, e único dia que também tem tráfego, nos dias de processamento. O último dia, após o
dia de alarme, em que houve o registo de transacções, foi no dia 28-06-2010. Este dia é relativo a
um dia de semana e foram registadas dez transacções de chamadas de voz, sendo todas elas de
serviço de roaming. Quanto ao número de SMS, registaram-se 10 transacções, 8 relativas a serviço
de roaming. Verifica-se assim um aumento de registos relativos a serviços de roaming, porém,
devido aos valores de desvio padrão calculados (num_sms_roaming_desvio_padrao = 11,6 e
num_chamadas_roaming_desvio_padrao = 4,3) os valores de distância resultantes não
demonstram uma alteração muito significativa de comportamento. De seguida os gráficos que
ajudam a perceber a variação de comportamento deste cliente ao longo do tempo. O primeiro
gráfico (Figura 40) traduz o comportamento do cliente em dias úteis e o segundo gráfico (Figura
41) em fins de semana.
Análise e Validação de Potenciais Casos de Fraude
120
Figura 40 – Variação de comportamento do cartão 925971*** em dias úteis
Figure 41 – Variação de comportamento do cartão 925971*** em fins de semana
Como podemos verificar, este cliente foi detectado com sucesso pelo protótipo de assinaturas. O
excessivo registo de chamadas de voz no dia 27-06-2010 vai de encontro ao que foi relatado pelo
sistema de regras. Apesar de o perfil de fraude não ser de roaming como no sistema de regras,
verifica-se um aumento de transacções de roaming no dia em que o sistema de regras alarmou. O
motivo que pode ter levado o protótipo de assinaturas a não alarmar pelos mesmos motivos pode
ser por este não captar, por enquanto, todo o tipo de registos existentes. O perfil fraudulento
detectado pode ter sido relativo a transacções de mms por exemplo. A ausência de registos nos
restantes dias de processamento, ou seja, depois do dia 28-06-2010, pode ter a ver com o facto
do mesmo ter sido abordado pelas entidades responsáveis.
Análise e Validação de Potenciais Casos de Fraude
121
Casos escolhidos aleatoriamente da lista de casos suspeitos
Depois de analisados os alarmes lançados pelo protótipo de assinaturas e confirmados pelos
analistas como sendo realmente casos fraudulentos, irão agora ser analisados alguns alarmes com
características diferentes que não foram identificados pelo sistema de regras. Vão ser escolhidos
alarmes de diferentes valores na tabela para estudar também a eficácia do valor de limiar definido.
Inicialmente, vai ser resumido o comportamento de dois utilizadores que a determinada altura se
verifica um desvio anómolo nas suas utilizações diárias, no final vai ser relatado o caso de um
cartão que se começa a aproximar bastante de um perfil de fraude conhecido.
Cartão 965173*** – Valor de alarme 91,67
Ao contrário dos utilizadores que vimos até agora, este é um utilizador mais regular. Para este
cliente registaram-se chamadas de voz e mensagens escritas todos os dias, desde o primeiro dia
(01-06-2010) de inicialização das assinaturas. Para perceber o comportamento do utilizador serão
reportados os valores médios diários de algumas das medidas mais importantes que compõe a sua
assinatura.
• Num_sms_dias_úteis - 1118,47058823529
• Num_sms_fds - 436,285714285714
• Num_sms_roaming - 0
• Num_chamadas_dias_uteis - 32,2352941176471
• Num_chamadas_fds - 11
• Num_chamdas_roaming - 0
• Num_sms_dias_úteis_desvio_padrão - 805,447316025532
• Num_sms_fds_desvio_padrão - 461,072780419249
• Num_sms_roaming_desvio_padrão - 0
• Num_chamadas_dias_uteis_desvio_padrão - 15,6555013711919
• Num_chamadas_fds_desvio_padrão - 6,28490254498827
• Num_chamdas_roaming_desvio_padrão - 0
Através das medidas mencionadas podemos desde já tirar algumas conclusões acerca do
comportamento deste cliente: nunca são utilizados serviços de roaming, quer em chamdas de voz
ou mensagens escritas; o utilizador é mais activo durante os dias úteis; e a sua principal utilização
Análise e Validação de Potenciais Casos de Fraude
122
é através de mensagens escritas. Verifica-se uma utilização bastante elevada no serviço de
mensagens escritas.
Vamos agora perceber os valores obtidos no dia de alarme (02-07-2010) e verificar as suas causas.
De notar que o dia de alarme foi num dia útil, portanto, serão omitidos os valores relativos ao fim
de semana.
• Num_sms_dias_úteis - 1003
• Num_sms_roaming - 126
• Num_chamadas_dias_uteis - 14
• Num_chamdas_roaming – 0
Olhando para os valores obtidos no dia de alarme, rapidamente ser verifica que o utilizador
manteve o seu comportamento habitual no número de mensagens escritas e no número de
chamadas de voz. O problema está no número de mensagens através do serviço de roaming.
Sabe-se pela sua assinatura que o utilizador nunca antes tinha enviado ou recebido qualquer SMS
roaming, pelo que o número obtido é muito elevado. O alarme é assim mais que compreensível, e
sabendo que o sistema está afinado de forma a ser mais sensível aos casos de fraude relacionados
com roaming, esta situação deverá ser analisada pelas entidades responsáveis. Iremos de seguida
verificar o comportamento do cliente nos dias seguintes de processamento para ver se este
mantém a utilização supostamente fraudulenta. Existem registos nos restantes dias até ao último
dia (05-07-2010) de processamento. Em todos os dias o utilizador mantém o seu comportamento
habitual no número de mensagens escritas e chamadas de voz. Contudo, este também mantém o
comportamento fraudulento até ao penúltimo dia (04-07-2010) de processamento. No dia 03-07-
2010 foram registadas 179 mensagens escritas através do serviço de roaming e no dia 04-07-2010
foram registadas 129. No último dia de processamento, o utilizador apresenta valores considerados
normais e o número de SMS roaming é nulo. De seguida, na figura 42, apresentamos um gráfico
que ajuda a perceber a variação de comportamento deste cliente ao longo do tempo.
Análise e Validação de Potenciais Casos de Fraude
123
Figura 42 – Variação de comportamento do cartão 965173***
Esta variação de comportamento pode ser devido a inúmeras razões, a maior parte das SMS de
roaming foram SMS recebidas, o que pode significar que alguém conhecido pode estar no
estrangeiro. No entanto, devido aos elevados custos derivados da fraude de roaming, estes casos
deverão sempre merecer uma análise cuidadosa, ainda para mais com o número elevado de SMS
obtido. Apesar de não ser possível determinar se esta situação é realmente fraude ou não,
conclui-se que faz todo sentido o sistema alarmar este caso.
Cartão 926224*** – Valor de alarme 10,8
Durante o período de processamento diário este utilizador apresenta registos de SMS em 9 dias.
Estes registos não são seguidos, estão dispersos aleatoriamente. Apenas em uma ocasião se
verifica a ocorrência de transacções em três dias seguidas, de 09-06-2010 até 11-06-2010. Quanto
a registos de voz, durante o período de inicialização, verificam-se transacções em praticamente
todos os dias. Irá ser agora listada a média diária de algumas das medidas mais importantes que
compõe a assinatura deste utilizador durante o período de inicialização.
• Num_sms_dias_úteis - 8,76470588235294
• Num_sms_fds - 1,14285714285714
• Num_sms_roaming - 0
• Num_chamadas_dias_uteis - 171,764705882353
• Num_chamadas_fds - 177,857142857143
• Num_chamdas_roaming - 0
• Num_sms_dias_úteis_desvio_padrão - 25,9719788449226
• Num_sms_fds_desvio_padrão - 1,5028317941009
Análise e Validação de Potenciais Casos de Fraude
124
• Num_sms_roaming_desvio_padrão - 0
• Num_chamadas_dias_uteis_desvio_padrão - 151,248819664244
• Num_chamadas_fds_desvio_padrão - 155,049289946537
• Num_chamdas_roaming_desvio_padrão - 0
Através das medidas em referidas podemos tirar algumas conclusões acerca do comportamento
deste cliente. Nunca são utilizados serviços de roaming, quer em chamadas de voz ou mensagens
escritas, a actividade do utilizador nas chamadas de voz é bastante semelhante durante os dias
úteis e durante o fim de semana. Quanto às mensagens escritas o utilizador é mais activo em dias
úteis. A principal utilização deste cartão, ao contrário do caso anterior (965173***), é através de
chamadas de voz. Vamos agora perceber os valores obtidos no dia de alarme (28-06-2010) e
verificar as suas causas. De notar que o dia de alarme aconteceu num dia útil da semana,
portanto, serão omitidos os valores relativos ao fim de semana.
• Num_sms_dias_úteis - 172
• Num_sms_roaming - 0
• Num_chamadas_dias_uteis - 234
• Num_chamdas_roaming - 0
Olhando para os valores obtidos no dia de alarme, rapidamente ser verifica que o utilizador
manteve o seu comportamento habitual no número de chamadas de voz e na ausência de
transacções de serviços roaming. O problema está no número de mensagens escritas registadas.
Pela sua assinatura, facilmente se verifica que o valor de SMS obtido se distancía demasiado do
comportamento normal. O alarme é assim compreensível, no entanto, serão analisados os dias de
processamento seguintes para ver se este mantém a utilização supostamente fraudulenta. De
seguida, os valores das medidas em cima mencionadas nos restantes dias de processamento. Os
valores das medidas de roaming foram omitidos pois mantiveram-se sempre nulos.
Análise e Validação de Potenciais Casos de Fraude
125
Tabela 11 – Tabela com valores das medidas mais importantes durante o período de
processamento do cartão 926224***
Figura 43 – Variação de comportamento do cartão 926224***
Através da figura 43 e da tabela 11, rapidamente se conclui que o comportamento do cliente não
só se manteve diferente do habitual como se desviou ainda mais em relação aos valores obtidos na
data do alarme. O número de mensagens escritas aumentou ainda mais em relação ao habitual e o
número de chamadas de voz diminuiu consideravelmente. O alarme lançado é assim mais do que
justificável, este caso tem vários motivos para merecer uma profunda análise pelas entidades
responsáveis. Apesar do valor de alarme ser baixo, o desvio comportamental obtido é suficiente
para prever o “ponto de viragem”. O aumento de SMS, a diminuição brusca de chamadas de voz e
o registo de transacções em todos os dias de processamento pode significar uma fraude
relacionada com o roubo ou clonagem do cartão. Conclui-se assim que faz todo sentido o sistema
alarmar este caso e que o valor de limiar definido (10,5) não é demasiado pequeno.
Cartão 963015*** - Valor de alarme 3,9
O valor deste alarme, ao contrário de todos vistos até ao momento, é inferior ao valor de limiar
(10,5). Esta situação deve-se ao facto deste alarme ser relativo à distância dos valores dos
sumários derivados do processamento diário com os valores de modelos de assinaturas
Análise e Validação de Potenciais Casos de Fraude
126
fraudulentas. Nestes casos, é utilizada uma função de distância diferente (distância de Hellinger) e
o valor de limiar foi fixado em 4, ou seja, apenas são alarmados os casos com valor igual ou
inferior a 4 e, quanto mais próximo do valor 0 mais próximo é o sumário da assinatura fraudulenta.
Para analisar este caso, numa fase inicial será comparado o comportamento do cliente no dia do
alarme com os valores da sua assinatura, depois, os mesmos valores serão comparados com os
valores do modelo da assinatura fraudulenta. Com isto, deverá ser possível compreender a
semelhança entre o comportamento do cliente e o tipo de fraude obtida, fraude técnica. De notar
que o dia de alarme aconteceu num dia útil da semana (01-07-2010), portanto, serão omitidos os
valores relativos ao fim de semana. De seguida uma tabela (Tabela 12) com os valores do sumário
resultante do processamento diário no dia de alarme, a assinatura associada ao cartão e o modelo
de assinatura fraudulenta que está mais próxima do sumário com valor de distância inferior a 4.
Assinatura Sumário Modelo – Fraude
DUR_CHAMADAS_NAC 265,04914022273 250,6 175,432642916194
DUR_CHAMADAS_ROAM 0 0 0
NUM_CHAMADAS_EF 47,655172413793 25 19,2241153
NUM_CHAMADAS_REC 21,275862068965 4 6,57298492791612
NUM_CHAMADAS_DU 91,235294117647 30 26,9363941677588
NUM_CHAMADAS_DIA 66,931034482758 29 22,6664072739187
NUM_CHAMADAS_NOITE 8,3448275862069 1 3,94081749672346
NUM_CHAMADAS_OP_IG 64,655172413793 29 22,8512860419397
NUM_CHAMADAS_OP_DIF 10,620689655172 1 3,75593872870249
NUM_CHAMADAS_ROAM 0 0 0
NUM_CHAM_ROAM_EF 0 0 0
NUM_CHAM_ROAM_REC 0 0 0
NUM_SMS_DIAS_UTEIS 366,17647058823 25 20,9306602228047
NUM_SMS_DIA 266,17241379310 14 25,2918577
NUM_SMS_NOITE 20,275862068965 11 3,7674
NUM_SMS_ENVIADAS 263,17241379310 18 13,7007699868938
NUM_SMS_RECEBIDAS 23,275862068965 7 15,2779325032765
NUM_SMS_OP_IG 268,20689655172 21 15,7298492
NUM_SMS_OP_DIF 18,241379310344 4 13,329415
Análise e Validação de Potenciais Casos de Fraude
127
NUM_SMS_ROAMING 0 0 0
NUM_SMS_ROAMING_EN 0 0 0
NUM_SMS_ROAMING_REC 0 0 0
Tabela 12 – Tabela com valores do sumário do dia 01/07/2010, valores da assinatura associada
(cartão 963015***) e o modelo de assinatura fraudulenta mais próximo do sumário
Numa primeira análise, pode-se verificar através da assinatura do cliente que este utilizou com
maior frequência o serviço de mensagens escritas durante o período de inicialização. Porém, com
base nos valores do sumário do dia (01-07-2010), o seu comportamento ficou mais equilibrado,
igualando a utlização das SMS com o serviço de chamadas de voz, tal como acontece no modelo
de fraude. Olhando para a tabela 12, podemos constatar que, apesar dos valores obtidos no
sumário continuarem dentro da normalidade, estes aproximam-se demasiado do modelo de
fraude. Os valores do sumário relativos ás medidas de SMS baixaram consideravelmente, contudo,
devido ás oscilações registados no período de inicialização, a presença dos valores de desvio
padrão no cálculo da distância normalizam a situação. O comportamento do cliente mantém-se
assim dentro do habitual no dia de alarme em relação à sua assinatura, apesar das diferenças nos
valores obtidos, as variações de comportamento do utilizador mantêm-se proporcionais ás
variações na assinatura. Estas variações nas medidas também são semelhantes às variações
presentes no modelo de fraude. Sabemos, através da análise dos alarmes do sistema de regras do
Centaur, que todos os clientes com um perfil semelhante a este foram classificados como
fraudulentos ou estão sobre investigação. Com uma descida demasiada precisa nos valores das
medidas em relação ao modelo, será necessário uma análise cuidadosa deste cartão. Este caso
poderá ser uma coincidência, no entanto, o valor de limiar foi definido de forma a alarmar apenas
casos muito idênticos aos modelos de fraude e diminuir o maior número de falsos alarmes
possíveis. Assim sendo, apesar de não ser possível concluir de imediato se este caso é ou não
fraudulento, faz todo sentido estudar a situação.
De forma a resumir os resultados da análise efectuada para a lista de alarmes obtida durante o
período de processamento, na tabela 13 podemos ver um sumário da contagem e os valores de
alarme listados pelo protótipo de assinaturas. Esta tabela permite obter uma visão generalista do
que aconteceu durante a janela temporal estabelecida.
Análise e Validação de Potenciais Casos de Fraude
128
Tabela 13 – Tabela resumo dos resultados obtidos durante o período de processamento
Dia do processamento Nº de alarmes de casos novos
Nº de alarmes de casos conhecidos de fraude
Nº de alarmes de distâncias entre assinaturas
Nº de alarmes de distâncias entre modelos de fraude
Valor máximo de alarme
Valor mínimo de alarme
Valor médio de alarme
Atributo impoacto com mais ocorrências
26/06/2010 2 1 3 0 408,1950346
15,59273076
146,8840926
Num_sms_noite
27/06/2010 0 1 1 0 10,86920729
10,86920729
10,86920729
Num_chamadas_fds
28/06/2010 3 1 3 1 1493,878923
10,78075602
505,4686106
Num_sms_dias_uteis
29/06/2010 1 0 1 0 12,18317414
12,18317414
12,18317414
Num_chamadas_dias_uteis
01/07/2010 5 1 5 1 117,5964469 12,36671923 58,16895455 Num_sms_roaming
02/07/2010 7 0 7 0 320,2676566 11,41395531 85,76271995 Duracao_chamadas_nacional
03/07/2010 3 0 3 0 511,0847305 23,91539471 211,537402
Num_sms_roaming
04/07/2010 4 1 5 0 51,41740232
10,51179468
20,83239821
Duracao_chamadas_nacional
05/07/2010 1 0 0 1 - - - -
Total 26 5 28 3
Conclusões e Trabalho Futuro
129
Capítulo 8
8Conclusões e Trabalho Futuro
8.1 Comentários Finais
Olhando para o trabalho realizado, de uma forma geral, podemos afirmar que os objectivos
inicialmente defnidos foram cumpridos. O estudo inicial relativo ao estado da arte foi fundamental
para perceber o problema em si e para escolher o caminho correcto a seguir. Depois de perceber
as exigências actuais na área de telecomunicações e as novas vulnerabilidades existentes nas
organizações, a escolha de técnicas baseadas em profiling com o método de Assinaturas foi uma
mais valia. Foi possível desenvolver uma solução flexível e adaptável a qualquer sistema já em
funcionamento.
O método de detecção de Assinaturas implementado foi totalmente “feito à medida”, ou seja, cada
funcionalidade ou característica do software foi pensada de forma a responder às necessidades do
problema apresentado pela TelBit e PT Inovação para a área de fraude nas telecomunicações.
Nenhuma das soluções de Data Mining que encontrámos tinha o algoritmo ou a “receita”
pretendida. Apesar da técnica de Assinaturas ainda estar um pouco presa na área de investigação,
concluiu-se que após alguns melhoramentos e alterações às ideias existentes, nomeadamente nos
trabalhos de Cortes e Pregibon (2001) e Ferreira, et al., (2006), é possível obter resultados
bastante satisfatórios da sua aplicação na área da detecção e controlo de fraude em
telecomunicações.
Conclusões e Trabalho Futuro
130
O método desenvolvido permite atribuir diferentes pesos aos atributos das medidas de perfil, no
cálculo da distância dos sumários diários, de forma a que os resultados da detecção se enquadrem
com os tipos de fraude mais relevantes no momento. Também é possível alterar os valores dos
limiares das fórmulas de distância utilizadas no cálculo do processamento diário dos sumários caso
se pretenda obter mais alarmes com variações de comportamento menos acentuadas e fazer
outros tipos de estudos. Visto que se pretendia aumentar as funcionaliades e a eficácia do
protótipo, foi implementado um mecanismo de aprendizagem supervisionada que permite criar
modelos legítimos e fraudulentos para reforçar o processo de detecção e criação de novas
Assinaturas. Tal como se pretendia, foram detectados novos casos suspeitos que não tinham sido
detectados pelo sistema Centaur actualmente em funcionamento. Infelizmente, não existe forma
de verificar se tais casos são realmente casos de fraude ou não. A solução para este problema
seria disponibilizar os casos aos analistas de fraude para estes os estudarem e aprofundarem junto
dos clientes e das entidades responsáveis. Contudo, visto que o protótipo do sistema baseado em
assinaturas ainda está na sua primeira fase de teste, e que o histórico disponibilizado não é
suficiente para construir um perfil de comportamento sólido e modelos de fraude robustos, não é
viável por agora gastar mais tempo na procura de soluções para este tipo de procedimentos.
Suponhamos, no entanto, que o protótipo está em produção à bastante tempo e que as
assinaturas calculadas traduzem um comportamento bastante preciso dos clientes. Tendo isto em
considerção, podemos dizer que os alarmes lançados pelo protótipo demonstraram ser de todo
relevantes para análise. Alem disso, verificou-se que o comportamento dos utilizadores variava de
forma muito invulgar, e isso foi provado através de um estudo pormenorizado do comportamento
diário durante todo o período de inicialização e processamento das assinaturas (ou dos sumários).
Quanto aos casos que foram classificados como fraude e disponibilizados para teste, todos eles
foram detectados, e os respectivos alarmes lançados, mais cedo que o sistema de regras do
Centaur - os valores de alarme e os atributos de maior impacto confirmaram os resultados obtidos.
O protótipo obteve assim uma eficácia de 100% na detecção destes casos. Isso já pôde ser
demonstrado anteriormente no Capítulo 7 onde foi possível apresentar a comprovação de que os
atributos de maior impacto coincidem com os perfis de fraude detectados.
Através dos resultados obtidos é possível perceber o impacto que este componente pode ter ao ser
adicionado a um sistema real de detecção de fraude. Quando comparado com o sistema de regras
do Centaur, o sistema baseado em assinaturas demonstrou ser mais rápido a detectar os casos de
Conclusões e Trabalho Futuro
131
fraude. De referir que, também foi possível descobrir potenciais casos de fraude que o sistema de
regras deixou passar.
O protótipo implementado tem a grande vantagem de permitir fazer a comparação individual do
comportamento habitual de cada cliente com o seu comportamento mais actual. Ao fazer este tipo
de abordagem é possível encontrar novos tipos de fraude, o que pode ser utilizado para reforçar o
método de detecção supervisionada e consequentemente contribuir para a obtenção de resultados
mais precisos de alarme.
O sistema de regras tem a desvantagem de fazer uma comparação geral de regras com o
comportamento actual dos clientes o que pode provocar a geração de falsos alarmes. Neste
sentido, o componente de assinaturas poderá ser um bom complemento para os sistemas de
fraude já existentes. No caso do sistema onde o protótipo foi testado, a sua capacidade de
detectar novos casos de fraude e casos de subscrição poderá melhorar as regras existentes e
permitir a introdução de novas regras que correspondem a novos tipos de fraude. As regras
existentes no Centaur também poderão ajudar a construir os modelos de fraude do sistema de
assinaturas para os casos em que se utilize detecção supervisionada. Este complemento permitá ás
operadoras de telecomunicações perder menos tempo com casos de falsos alarmes, detectar mais
rapidamente e com maior precisão casos que são realmente fraude, acompanhar e estudar e
evolução dos novos tipos de fraude e, consequentemente, reduzir a quantidade de dinheiro que
perdem todos os anos com este problema.
8.2 Algumas Orientações para Trabalho Futuro
Durante a análise e validação de resultados foram encontrados alguns casos de clientes com
mudanças de comportamento um pouco diferentes das que estavam previstas. Normalmente, os
casos de fraude estão relacionados com um aumento significativo na média de um ou mais
atributos. Visto que o sistema foi implementado para detectar qualquer tipo de variação, também é
possível detectar casos de clientes que de um momento para outro diminuem muito a média
habitual de chamadas ou mensagens escritas associadas a um ou mais atributos. Estes casos
podem não corresponder efectivamente a casos de fraude mas sim a casos relacionados com outro
tipo de fenómeno denominado vulgarmente por Churn. Em termos muito simplistas, podemos dizer
que o Churn é a proporção de clientes que aderiram a um serviço de uma organização e que a
Conclusões e Trabalho Futuro
132
determinado momento começaram a deixar de os usar para usufruir, eventualmente, dos serviços
de uma organização concorrente (Qian, et al., 2006). Com alguns ajustes nas fórmulas de distância
que utilizámos neste trabalho, refinando os pesos dos atributos e alterando os valores dos limiares,
é possível detectar de forma eficiente os casos de clientes que começam a deixar de usar os
serviços da operadora. Para além de detectar estes casos, é possível verificar quais os atributos
responsáveis e comparar com outros casos. Desta forma, a operadora poderia ficar mais prevenida
relativamente a este tipo de situação e fazer alguns esforços no sentido de prevenir o afastamento
de mais clientes, tentando-os conquistar de novo e alterarando as suas condições de serviço, se
for caso para tal. Cada vez mais a concorrência entre as organizações é maior e é fundamental
manter os bons clientes. Como trabalho futuro, poderá ser útil estudar esta área e ponderar uma
evolução no protótipo de forma a aumentar as suas capacidades de detecção. Todavia, os
próximos passos relacionados com a implementação efectuada estão relacionados com a melhoria
do desempenho do sistema, em particular no que diz respeito aos tempos de processamento e de
inicialização das assinaturas dos clientes. Apesar dos resultados obtidos até ao momento serem
bastante satisfatórios no âmbito da dissertação, para um ambiente real onde poderão ser utilizadas
transacções diárias de milhões de utilizadores, é necessário processar tudo em tempo útil (por
exemplo num período nunca superior a 120 minutos, para um caso de detecção com 1milhão de
clientes) para manter as assinaturas actualizadas e detectar os casos de fraude atempadamente.
Também será necessário, antes de qualquer passo, criar os modelos de fraude com base na
informação do histórico de casos classificados como fraude. Até ao momento, isso não foi realizado
pelo simples facto de não terem sido disponibilizados dados suficientes para criar modelos de
fraude capazes de traduzir perfis de comportamento com um grau de confiança mínimo para
utilização. Finalmente, está previsto uma melhoria no processo de sincronização com os restantes
componentes de detecção já existentes no Centaur. O funcionamento em conjunto do protótipo de
assinaturas com os restantes componentes deverá acontecer de forma automática e transparente,
do ponto de vista do utilizador este não deverá aperceber-se da arquitectura e das dependências
existentes no sistema.
Bibliografia
133
Bibliografia
AAMODT, A. AND PLAZA, E. 1994. Case-Based reasoning: Foundation Issues, Methodological variations, and System Approaches. AI Communications IOS Press, 39-59.
ABIDOGUN, O., 2005. Data Mining, Fraud Detection and Mobile Telecommunications: Call Pattern
Analysis with Unsupervised Neural Networks. A Thesis Presented in Fulfillment of the Requirements for the Degree of Master of Science. 54-70.
ALHONIEMI, E., HOLLMÉN, J., SIMULA, O., AND VESANTO, J. 1999. Process monitoring and
modeling using the self-organizing map. Integrated Computer Aided Engineering 6, 3-14. ALMEIDA, J., JORGE, B., CORTESÃO, L., VIEIRA, M., AND GOMES, P. 2008. Supporting Fraud
Analysis in Mobile Telecommunications Using Case-Based Reasoning. ECCBR European Conference on Case-Based Reasoning, 562-572.
BARSON, P., FIELD, S., DAVEY, N., MCASKIE, G., AND FRANK, R. 1996. The Detection of Fraud in
Mobile Phone Networks. Neural Network World, Vol. 6, No 4. BISHOP, C. 1996. Neural Networks in Pattern Recognition. Oxford Press. BOLTON, R., AND HAND, D. 2002. Statistical Fraud Detection: A Review, Statistical Science, Vol.
17, No 3, 235-255. BOLTON, R. AND HAND, D. 2001, Unsupervised Proling Methods for Fraud Detection, Proc.
Credit Scoring and Credit Control VII, 5-7. BURGE, P., TAYLOR, J., COOKE, C., MOREAU, Y., PRENEEL, B., AND STORMANN, C. 1997. Fraud
detection and management in mobile telecommunications networks. Proceedings of the European Conference on Security and Detection ECOS 97 , 91–96.
CORTES, C. AND PREGIBON, D. 2001. Signature-based methods for data streams. Data Mining and
Knowledge Discovery , 167–182. CORTESÃO, L., MARTINS, F., ROSA, A., AND CARVALHO, P. 2005. Fraud management systems in
telecommunications: A practical approach. 12th International Conference on Telecommunications , 167–182.
Bibliografia
134
CONNOLLY, T., AND BEGG, C. 2004. Database Systems - A Practical Approach to Design, Implementation, and Management. Addison-Wesley Publishing Company, 4th edition. DANIEL W. 2002. Minimizing the Fraud Risk in Next Generation Networks. Chorleywood
Publication. ESTÉVEZ, P., HELD, C., AND Perez, C. 2005, Subscription Fraud Prevention in
Telecommunicationsusing Fuzzy Rules and Neural Networks. Expert Systems with Applications, Vol. 31, 337-344
FAWCETT, T. AND POVOST, F. 1998. Automated design of user profiling systems for fraud
detection. AAAI technical Report WS-98-07. FERREIRA, P., ALVES, R., BELO, O., AND CORTESÃO, L. 2006. Establishing fraud detection
Patterns based on signatures. Proceedings of 6th Industrial Conference on Data Mining . FERREIRA, P., ALVES, R., BELO, O., AND RIBEIRO, J. 2007. Detecting telecommunications fraud
based on signatures clustering analysis. Proceedings of Business Intel ligence Workshop of 13th Portuguese Conference on Artificial Intelligence.
FRIEDMAN, N., LINIAL, M. AND NACHMAN, I. 2000. Using Bayesian Networks to Analyze
Expression Data. Journal of Computation Biology, 601-620 GOPAL, R., AND MEHER, K. 2007. A Rule-Based Approach for Anomaly Detection in Subscriber
Usage Pattern. International Journal Of Mathematical, Physical and Engineering Sciences, Vol. 1, No 3.
GRAAFF, A., AND ENGELBRECHT, A. 2002, An Overview of Models to Detect and Analyze Fraud in
the Telecommunications Environment, Southem African Telecommunication Networks and Applications Conference, South Africa.
GRABEC, I. 1989. Self Organisation of Neurons Described by Second Maximal Entropy Principle.
Proceedings 1st IEE International Conference on Artificial Neural Networks, No. 313, 12-16.
GROSSER, H., Britos, P., AND GRACIA, R. 2005. Detecting Fraud in Mobile Telephony Using Neural
Networks. Innovation in Aplied Artificial Intelligence: LNCS, Springer Berlin/Heidelberg, Vol. 3533.
HAKIMA, S., TOLOO, M., AND WHITE, T. 1997, A Multi-Agent Systems Approach for Fraud
Detection in Personal Communication Systems, AAAI Technical Report WS-97-07, AAAIPress.
HAMILTON, J. 1994. Time Series Analysis. Prinveton University Press, Princeton, NJ. HECKERMAN, D. 1996. A Tutorial on Learning With Bayesian Networks. Technical Report MSR-TR-
95-06. HOLLMÉN, J. 2000, User profiling and classification for fraud detection in mobile communications
Bibliografia
135
networks, PhD Thesis, Helsinki University of Technology, Department of Cognitiveand Computer Science and Engineering, Espoo.
HOLLMÉN, J., AND TRESP, V. 1999. Call-Based Fraud Detection in Mobile Communication Networks
using a Hierchical Regime Switching Model. Proceedings of the 1998 conference on Advances in neural information processing systems II, MIT Press, 889-895.
HOLLMÉN, J., TRESP, V., AND SIMULA, O. 1999. A self organizing map for clustering probabilistic
models. Proceedings of the Ninth International Conference on Artificial Neural Networks (ICANN’99), Vol. 2, 946-951.
HILAS, C. AND SAHALOS, J. 2005. User profiling for fraud detection in telecommunication
networks. 5th International Conference on Technology and Automation. LARRAÑAGA, A. 2009. Fraud Prevention Strategies for the Multi-Play Service Provider. Next
Generation Billing & Revenue Management, Kuala Lumpur. LEE, G. 2008. Rule Based and Case-Based reasoning approach for internal audit of bank. ISSN:
0950-7051, Knowledge-Based Systems, 21, 140-147. LUNDIN, E. 2004. Logging for intrusion and fraud detection. PhD Thesis, Chalmers University of
Technology, Sweden JANS, M., LYBAERT, N., AND VANHOOF, K. 2007, Data Mining for Fraud Detection: Towards an
Improvement on Internal Control Systems?, European Accounting Association - Annual Congress, Lisbon.
JULISCH, K. 2003. Clustering instrusion detection alarms to support root cause analysis. ACM
Transactions on Information and Systems Security, Vol. 4, No. 6, 443-471. KOU, Y., LU, T., SIRWONGWATTANA, S., AND HUANG, Y. 2004, Survey of Fraud Detection,
Proceedings of 2004 IEEE Internacional Conference on Networking, Sensing and Control, Taipei, Taiwan.
MÁNTARAS, R., AND PLAZA, E. 1997. Case-Based Reasoning: an overview. IOS Press.
Aicommunications, 10, 21-29. MITCHELL, T. 1997. Machine Learning. Mc Graw Hill, USA. MOHAY, G., ANDERSON, A., COLLIE, B., VEL, O., AND MCKEMMISH, R. 2003. Computer and
Intrusion Forensics. Artech House. MOREAU, Y., PRENEEL, B., BURGE, P., TAYLOR, J., STOERMANN, C., AND COOKE, C. 1997, Novel
Technics for Fraud Detection in Mobile Telecommunication Networks, ACTS Mobile Summit, Granada, Spain.
MOSTAFA, Y. 1989. Information theory, complexity, and neural networks. IEEE Communications
Magazine. MUHAMED, A., BANDI, A., TAMRIN, A., JAAFAR, M., HASAN, S., AND J.FAEIZAH 2009.
Bibliografia
136
Telecommunication Fraude Prediction Using Backpropagation Neural Network. International Conference of Soft Computing and Pattern Recognition.
PHUA, C., LEE, V., SMITH, K., AND GAYLOR, R. 2005, A Comprehensive Survey of Data Mining
based Fraud Detection Research, Articial Intelligence Review. PHUA, C., ALAHAKOON, D., AND LEE, V. 2004, Minority Report in Fraud Detection: Classication of
Skewed Data, SIGKDD Explor. Newsl., Vol. 6, No. 1, 50-59. QUIAN, Z., JIANG, W., AND TSUI, K. 2006. Churn detection via custumer profile modelling.
International Journal of Production Research, Vol. 44, 2913-2933. RAO, C. 1995. Use of Hellinger distance in graphical displays. Multivariate statistics and matrices
in statistics. Leiden (Netherland): Brill Academic Publisher, 143-161. RAO, C. 1995. A review of canonical coordinates and an alternative to correspondence analysis
using Hellinger Distance. QuestiIIÓ, Vol. 19, 23-63. RIPLEY, B. 1996. Pattern Recongnition and Neural Networks. Cambridge University Press. ROSSET, S., MURAD, U., NEUMANN, E., IDAN, Y., AND PINKAS, G. 1999. Discovery of fraud rules
for telecommunications - challenges and solutions. Proceeding of SIGKDD99 , 409–413. SCHANK, R. 1982. Dynamic memory; a theory of reminding and learning in computers and people.
Cambridge University Press. SCHIAFFINO, S., AND AMANDI, A. 2000. User profiling with Case-Based Reasoning and Bayesian
Networks. International Joint Conference IBERAMIA-SBIA, 12-21. TANIGUCHI, M., HAFT, M., HOLLMÉN, J., AND TRESP, V. 1998. Fraud Detection In Communication
Networks Using Neural and Probabilistic Methods. Proceedings of the 1998 IEEE Int, 1241-1244.
TAYLOR, J., HOWKER, K., AND BURGE, P. 1999. Detection of fraud in mobile telecommunications.
Information Security Technical Report 4, 1, 16–28. YUHAS 1993. Toll-Fraude Detection. Proceedings of the International Workshop on Applications of
Neural Networks to Telecommunications, 239-244. WHEELER, R., AND AITKEN, S. 2000. Multiple algorithms for fraud detection. Knowledge-Based
Systems, 13, 93-99. WEISS, G. 2005, Data Mining in Telecommunications, Data Mining and Knowledge Discovery
Handbook: A Complete Guide for Practitioners and Researchers, Kluwer Academic Publishers, 1189-1201.
WEISS, G. 2008, Data Mining in Telecommunications Industry, Encyclopedia of Data Warehousing
and Mining, Second Edition, Information Science Publishing. VERRELST, H., LEROUGE, E., MOREAU, Y., VANDEWALLE, J., STORMANN, C. AND BURGE, P. 1999.
Bibliografia
137
A hybrid system for fraud detection in mobile communications. ESANN 1999, 447-454. XU, W., PANG, Y., MA, J., WANG, S., HAO, G., ZENG, S., ANS QIAN, Y. 2008, Fraud Detection in
Telecommunication: A Rough Fuzzy Set based Approach, Proceedings of the Seventh Internacional Conference on Machine Learning and Cybernetics, Kunming.
Bibliografia
138
Referências WWW
139
Referências WWW
BIOSS, 2004. Telecom Fraud on the Rise. Available at: <http://www.billingworld.com/articles/2004/07/telecom-fraud-on-the-rise.aspx> [Accessed 2 December 2009]
BOONTON, 2007. Worldwide Telecom Industry Growing Ten Percent Annually, Revenues Expected
to Reach $2.7 Trillion by 2013, says Insight Research Corp. Available at: <http://www.insight-corp.com/pr/11_13_07.asp> [Accessed 25 December 2009]
SYSTEMS, C., 1996. Cognitive Systems. Available at: <http://www.ai-cbr.org/tools/remind.html>
[Accessed 12 January 2010] DAN, O., 2007. TIA study: Global telecom market at $3 trillion. Available at:
<http://connectedplanetonline.com/voip/finance/tia_telecom_market_012607/> [Accessed 20 December 2009]
FISHER, K., 2002. Hancock. Available at: <http://www2.research.att.com/~kfisher/hancock/> [Accessed 16 April 2010] FREEMAN, J., 2005. Rule-Based Systems and Identification Trees. Available at:
<http://ai-depot.com/Tutorial/RuleBased.html> [Accessed 10 April 2010] GARTNER, 2008. Gartner Says Worldwide Telecom Market Revenue to Grow 7.6 Percent in 2008.
Available at: http://www.gartner.com/it/page.jsp?id=759312 [Accessed 12 December 2009]
ISOFT, 1990. Fraud Manager – Real Time Fraud Control. Available at:
<http://www.isoft.fr/html/soc_en.htm> [Accessed 12 January 2010] JEFFERIES, N., 1998. ASPECT – Advanced Security for Personal Communications Technologies.
Available at: http://www.esat.kuleuven.be/cosic/aspect/ [Accessed 20 February 2010] PADILLA, A., 2008. Comparing Distance Formulas. Available at:
<http://www.armando.ws/tag/euclidean-distance/> [Accessed 14 May 2010] RISK, 2005. Phreakin’ hell: phone hacking costing Australia millions. Available at:
Referências WWW
140
<http://www.riskmanagementmagazine.com.au/articles/F4/0C038BF4.asp?Type=124&Category=1240> [Accessed 26 November 2009]
SEEINFOBIZ, 2005. Fraud Management for Telecom Industry. Available at:
<http://www.seeinfobiz.com/fraudnew.htm> [Accessed 2 June 2010] TELBIT, 1998. Centaur. Available at: <http://www.telbit.pt/products/centaur> [Accessed 2
November 2009] THAKUR, P., 2001. Telecom fraud is big business now. Available at:
<http://timesofindia.indiatimes.com/articleshow/1460160415.cms> [Accessed 3 December 2009]
THEFREELIBRARY, 1998. Telecommunications fraud. Available at:
<http://www.thefreelibrary.com/Telecommunications+fraud-a020794166> [Accessed 12 February 2010]
WIKIPEDIA, 2008. Mahalanobis distance. Available at:
<http://en.wikipedia.org/wiki/Mahalanobis_distance> [Accessed 4 June 2010] WORLDXS, 1995. International Callback. Available at: <http://www.worldxs.net/callback.html>
[Accessed 10 December 2009]
Anexos
141
Anexo A
Algoritmo de Processamento
Neste anexo é apresentado o algoritmo que foi implementado no processamento diário das
assinaturas. Apenas é detalhado o procedimento principal de processamento, as sub-funções que
são chamadas ao longo do algoritmo não são especificadas, tal como os seus argumentos.
limiar = x;
limiar2 = y;
sumario[z];
/*Nesta instrução a variável v_ass_fraude toma o valor do número total de modelos de fraude existentes na tabela Assinatura_Fraude*/
select count(*) into v_ass_fraude from assinatura_fraude;
/*Para cada sumário irão ser executadas as instruções em baixo*/
For(inteiro i=0; i < length(sumario); i++)
/*Nesta instrução a variável v_telefone toma o valor do número total de assinaturas com o telefone igual ao do sumario, existentes na
tabela Assinatura*/
select count(*) into v_telefone from assinatura where telefone = sumario.telefone;
/*Esta instrução verifica se a assinatura relativa ao telefone sumario existe na base de dados. Em caso positivo as instruções relativas ao
"If" são executadas*/
if (v_telefone > 0) then
/*Esta instrução verifica se o estado da assinatura relativa ao telefone é igual a "0", ou seja, verifica se a assinatura não tem
nenhum caso suspeito por resolver. Em caso positivo as instruções relativas ao "If" são executadas*/
if (v_estado = 0) then
/*A variável "v_distancia" toma o valor do cálculo da distância entre o sumário i e a sua respectiva assinatura*/
v_distancia := calcDistancia();
/*caso a variável "v_distancia" seja superior ao limiar pré-definido (limiar1), as instruções relativas a este "If" são
executadas/*
if (v_distancia > limiar1) then
Anexos
142
/*esta função adiciona à tabela "Caso_Suspeito" o respectivo caso relativo ao sumário i. Também é actualizado o
atributo "estado", da assinatura associada, na tabela "Assinatura"/*
addCasoSuspeito();
/*como a assinatura do sumário não é actualizada, o sumário é adicionado aos sumários temporários, ou seja, à tabela
"Sumário_Temporário"*/
addSumarioTemp();
/*caso a variável "v_distancia" não seja superior ao limiar pré-definido (limiar1), as instruções relativas a este "Else" são
executadas*/
else
/*caso existam modelos de assinaturas fraudulentas na base de dados, as instruções relativas a este "If" são
executadas/*
if (v_ass_fraude > 0) then
/*a variável "v_distancia2" toma o valor do cálculo da comparação entre o sumário e as assinaturas de fraude da
tabela "Assinatura_Fraude"/*
v_distancia2 := comparaAssFraude();
/*caso a variável "v_distancia2" seja superior ao limiar pré-definido (limiar2), as instruções relativas a este "If"
são executadas/*
if (v_distancia2 <= limiar2) then
addCasoSuspeito();
addSumarioTemp();
/*caso a variável "v_distancia2" não seja superior ao limiar pré-definido (limiar2), as instruções relativas a este
Else" são executadas*/
else
/*esta função actualiza a assinatura em função dos valores do sumário obtidos no processamento diário*/
actualizaAssinatura();
end if;
/*caso não existam modelos de assinaturas fraudulentas na base de dados, as instruções relativas a este "Else" são
executadas/*
else
actualizaAssinatura();
end if;
end if;
Anexos
143
/*Se o estado da assinatura relativa ao telefone é igual a "1", ou seja, a assinatura tem um caso suspeito por resolver ou é uma
assinatura fraudulenta, as instruções relativas ao "Else" são executadas*/
else
addSumarioTemp();
end if;
/*Se a assinatura relativa ao telefone sumario não existe na base de dados, as instruções relativas ao "Else" são executadas*/
else
/*caso existam modelos de assinaturas fraudulentas na base de dados, as instruções relativas a este "If" são
executadas/*
if (v_ass_fraude > 0) then
v_distancia2 := comparaAssFraude();
if (v_distancia2 <= limiar2) then
addCasoSuspeito();
addSumarioTemp();
else
/*esta função cria uma nova assinatura, na tabela "Assinatura", relativa ao sumário. Este processo é efectuado com
auxílio das classes de utilização da tabela Assinatura_Classe*/
criarAssinatura();
end if;
else
criarAssinatura();
end if;
end if;
end for;
Anexos
144
Anexos
145
Anexo B
Requisitos de Objectivos de Concepção
Neste anexo são apresentados os requisitos de objectivos de concepção do sistema, também
podem ser incluídos nos requisitos não funcionais. Representam as características e
funcionalidades que o sistema deve possuir.
Requisito 01 Criar as tabelas necessárias para o sistema de detecção
baseado em Assinaturas.
Objectivo Obter a estrutura de dados necessária para o funcionamento
do sistema de detecção baseado em assinaturas.
Pré-condições Permissões de de criação, devolução, actualização e remoção
(CRUD) no sistema de detecção do Centaur.
Condição final de Sucesso Todas as tabelas são criadas no sistema de detecção do
Centaur.
Condição final de Insucesso É notificado um erro na criação de/das tabela(s).
Actores Sistema de detecção
Descrição Passo Acção
1
Criação das tabelas Loading_Assinatura_Voz e
Loading_Assinatura_SMS e respectivas partições de
dois dias de tráfego.
2
Criação das tabelas PUMP_ASSINATURA_Voz e
PUMP_ASSINATURA_SMS.
3
Criação das tabelas Assinatura com chave
estrangeira da tabela Assinatura_Classe,
Sumario_Temporario, Assinatura_Classe e
Assinatura_Fraude. Também poderá ser criada uma
tabela LOGIN para gestão de acessos numa futura
Anexos
146
interface a implementar.
4
Criação da tabela Caso_Suspeito com chave
estrangeira da tabela Assinatura.
Tabela 14 – Use Case 1 (Criar as tabelas necessárias para o sistema de detecção baseado em
Assinaturas)
Requisito 02 Inicializar Assinaturas de clientes já existentes.
Objectivo Obter as Assinaturas iniciais dos clientes com registos de
chamadas e SMS dos últimos 40 dias de tráfego.
Pré-condições Permissões de CRUD no sistema de detecção do Centaur.
Condição final de Sucesso As Assinaturas dos clientes são criadas com sucesso.
Condição final de Insucesso É lançada um excepção para notificar o erro.
Algumas ou todas as Assinaturas podem não ser criadas.
Actores Sistema de detecção
Descrição Passo Acção
1
Agregar a informação necessária das tabelas, já
existentes no sistema de detecção Centaur,
UNIFIED_VOICE e UNIFIED_SMS dos últimos 40 dias
de tráfego, calcular as Assinaturas dos respectivos
clientes e armazenar as mesmas na tabela
Assinatura.
Tabela 15 – Use Case 2 (Inicializar Assinaturas de clientes já existentes)
Requisito 03 Criar modelos de Assinaturas Fraudulentas.
Objectivo Obter modelos de Assinaturas fraudulentas para ajudar na
detecção de casos suspeitos.
Anexos
147
Pré-condições
Existir informação suficiente e fiável no sistema de detecção
para determinar modelos de fraude.
Permissões de CRUD no sistema de detecção Centaur.
Condição final de Sucesso Os modelos de Assinaturas fraudulentas são criados com
sucesso.
Condição final de Insucesso
A informação existente não é suficiente para criar modelos de
fraude.
É lançada uma excepção para notificar o erro.
Actores Sistema de detecção e grupo de informática
Descrição Passo Acção
1
Com base nas conclusões dos analistas, após a
certeza de determinado caso ser um modelo de
fraude conhecido, este é adicionado à tabela
Assinatura_Fraude.
Tabela 16 – Use Case 3 (Criar modelos de Assinaturas Fraudulentas)
Requisito 04 Criar Classes de clientes com base nas Assinaturas existentes.
Objectivo
A qualquer altura ser possível obter Classes de Assinaturas,
com base nas Assinaturas existentes, para dar suporte na
criação de novos clientes.
Pré-condições
Existirem Assinaturas disponíveis para criar as diversas
classes.
Permissões de CRUD no sistema de detecção do Centaur.
Condição final de Sucesso
Após reunir toda a informação das Assinaturas existentes as
diferentes classes de utilização são criadas na tabela
Assinatura_Classe.
Condição final de Insucesso
As classes não são criadas devido a problemas de cálculos ou
falta de informação.
É lançada um excepção para notificar o erro.
Anexos
148
Actores Sistema de detecção
Descrição Passo Acção
1
Através da informação existente na tabela
Assinatura, fazer as agregações e os cálculos
necessários para criar as diferentes classes de
utilização na tabela Assinatura_Classe.
Tabela 17 – Use Case 4 (Criar Classes de clientes com base nas Assinaturas existentes)
Requisito 05 Transferir os registos necessários das tabelas PUMP_VOICE e
PUMP_SMS para as tabelas LOADING_ASSINATURA
Objectivo
Obter os atributos necessários de todos os registos relativos
ao tráfego dos dois dias mais recentes nas tabelas
LOADING_ASSINATURA_Voz e LOADING_ASSINATURA_SMS
Pré-condições
Os registos de voz e SMS terem sido correctamente mediados
e transferidos para as tabelas PUMP_VOICE e PUMP_SMS do
sistema de detecção Centaur.
Permissões de CRUD no sistema de detecção Centaur.
Condição final de Sucesso
Os atributos necessários dos registos de voz e SMS das
tabelas PUMP_VOICE e PUMP_SMS são inseridos nas tabelas
LOADING_ASSINATURA_Voz e LOADING_ASSINATURA_SMS,
sempre que registos de chamadas e SMS entram no sistema
de detecção.
Condição final de Insucesso
Alguns ou todos os registos não são inseridos nas tabelas
LOADING_ASSINATURA_Voz e LOADING_ASSINATURA_SMS.
É lançada um excepção para notificar o erro.
Actores Sistema de detecção
Descrição Passo Acção
1
No momento em que os registos de voz e SMS são
copiados para as tabelas UNIFIED_VOICE e
Anexos
149
UNIFIED_SMS a partir das tabelas PUMP_VOICE e
PUMP_SMS, também deverão ser copiados os
registos com os atributos necessários para as tabelas
LOADING_ASSINATURA_Voz e
LOADING_ASSINATURA_SMS.
Tabela 18 – Use Case 5 (Transferir os registos necessários das tabelas PUMP_VOICE e PUMP_SMS
para as tabelas LOADING_ASSINATURA)
Requisito 06 Processar Sumários
Objectivo
Actualizar as assinaturas dos clientes existentes, detectar
situações suspeitas de fraude, criar assinaturas para novos
clientes com base nas classes de utilização da tabela
Assinatura_Classe, e não tratar os telefones com casos
suspeitos por resolver.
Pré-condições
A troca de partições entre as tabelas
LOADING_ASSINATURA_Voz e PUMP_ASSINATURA_SMS, e
LOADING_ASSINATURA_SMS e PUMP_ASSINATURA_SMS
deverá ser efectuada com sucesso.
Permissões de CRUD no sistema de detecção do Centaur.
Condição final de Sucesso
As Assinaturas são actualizadas correctamente na tabela
ASSINATURA.
Os casos suspeitos são adicionados à tabela Caso_Suspeito.
São criadas assinaturas novas na tabela Assinatura para
clientes inexistentes.
Clientes com casos suspeitos por resolver são adicionados à
tabela Sumario_Temporario.
Condição final de Insucesso Algumas ou nenhuma assinatura é processada.
É lançada uma excepção para notificar o erro.
Actores Sistema de detecção
Descrição Passo Acção
Anexos
150
1
O conteúdo do útlimo dia de tráfego nas tabelas
LOADING_ASSINATURA_Voz e
LOADING_ASSINATURA_SMS deve ser trocado pelo
conteúdo vazio das tabelas PUMP_ASSINATURA_Voz
e PUMP_ASSINATURA_SMS respectivamente.
2
A informação das tabelas PUMP_ASSINATURA_Voz
e PUMP_ASSINATURA_SMS deve ser agregada e os
sumários dos clientes deverão ser calculados.
3
Os sumários de clientes com casos suspeitos por
resolver deverão ser inseridos na tabela
Sumario_Temporario.
3
Os sumários de clientes que não existem na tabela
Assinatura devem ser utilizados para criar novas
assinaturas dos mesmos com auxílio das classes de
utilização da tabela Assinatura_Classe.
3
Os sumários de clientes com casos suspeitos
resolvidos e fraudulentos são ignorados.
3
Os sumários sem casos suspeitos ou com casos
suspeitos resolvidos e não fraudulentos deverão ser
comparados com as suas Assinaturas. É calculado
um valor de distância e um limiar pré-definido*
poderá ser ultrapassado.
4
Se o limiar pré-definido* for ultrapassado é
adicionado um novo caso suspeito na tabela
Caso_Suspeito.
4
Se o limiar pré-definido* não for ultrapassado os
sumários são comparados com os modelos de fraude
existentes na tabela Assinatura_Fraude. É calculado
um valor de distância e um limiar pré-definido**
poderá ser ultrapassado.
5
Se o limiar pré-definido** for ultrapassado é
adicionado um novo caso suspeito na tabela
Caso_Suspeito.
Anexos
151
5
Se o limiar pré-definido** não for ultrapassado as
assinaturas na tabela Assinatura são actualizadas
com base nos valores dos sumários.
Tabela 19 – Use Case 6 (Processar Sumários )
Requisito 07 Regularizar Casos Suspeitos
Objectivo Actualizar os casos suspeitos que já foram resolvidos e
actualizar as assinaturas caso não sejam situações de fraude.
Pré-condições
Os registos dos casos suspeitos a actualizar deverão estar na
tabela Caso_Suspeito e os respectivos sumários na tabela
Sumario_Temporario.
Condição final de Sucesso
O estado dos casos suspeitos na tabela Caso_Suspeito e
Assinatura são alterados e os respectivos sumários
temporários são removidos da tabela Sumario_Temporario. Se
os casos suspeitos não forem situações de fraude as
assinaturas da tabela Assinatura são actualizadas tendo em
conta a informação dos sumários temporários.
Condição final de Insucesso É lançada uma excepção para notificar o erro.
Actores Sistema de detecção e grupo de informática
Descrição Passo Acção
1
O estado do caso suspeito é alterado nas tabelas
Caso_Suspeito e Assinatura.
2
Se os casos suspeitos não forem uma situação de
fraude, os sumários temporários que estão na tabela
Sumario_Temporario são utilizados para actualizar as
respectivas assinaturas na tabela Assinatura. No final
os sumários temporários deverão ser removidos.
2
Se os casos suspeitos forem uma situação de fraude,
os respectivos sumários temporários da tabela
Anexos
152
Sumario_Temporario são removidos.
Tabela 20 – Use Case 7 (Regularizar Casos Suspeitos)
Requisito 08 Actualizar as Classes de Assinaturas
Objectivo
De acordo com as alterações de comportamento habituais dos
clientes, segundo uma janela temporal definida, actualizar as
classes de utilização existentes na tabela Assinatura_Classe
com as assinaturas da tabela Assinatura.
Pré-condições
Deverão estar disponíveis os registos mais recentes da tabela
Assinatura.
Permissões de CRUD no sistema de detecção do Centaur.
Condição final de Sucesso
As classes de utilização da tabela Assinatura_Classe são
actualizadas com a informação mais recente da tabela
Assinatura.
Condição final de Insucesso Não é possível actualizar as classes de utilização.
É lançada uma excepção para notificar o erro.
Actores Sistema de detecção
Descrição Passo Acção
1
Após uma janela temporal definida, o sistema deverá
reunir a informação existente na tabela Assinatura e
calcular os novos valores para as classes de utilização
da tabela Assinatura_Classe.
Tabela 21 – Use Case 8 (Actualizar as Classes de Assinaturas)
Anexos
153
Anexo C
Use Cases
Neste anexo são apresentados alguns dos use cases mais importantes criados na especificação de
requisitos. A cada use case está associado um diagrama de actividades do Anexo D.
Parâmetros
Figura 44 - Diagrama de Use-Cases: Parâmetros
Descrição: O utilizador pode alterar os valores padrão para o processamento das assinaturas. O
sistema deverá permitir editar o valor do limiar para o disparo do alarme, o valor dos pesos dos
atributos no cálculo da distância entre as assinaturas e o valor da janela temporal que traduz a
assinatura. O sistema deverá notificar o utilizador se os valores introduzidos não estiverem
correctos.
A qualquer altura o sistema deverá permitir ao utilizador cancelar as operações que está a efectuar
e sair da aplicação.
Anexos
154
Stakeholder: Programadores e analistas.
Análise
Figura 45 - Diagrama de Use-Cases: Análise
!
Descrição: O sistema deverá permitir ao utilizador personalizar as suas pesquisas de análise.
Deverá ser possível efectuar pesquisas como:
1. Listar todos os casos suspeitos com estado por resolver.
2. Listar todos os casos suspeitos com data de alarme superior a “X”
3. Casos suspeitos por resolver com valor de limiar superior a “Y”.
4. Casos suspeitos por resolver com atributo impacto igual a “Z”.
O sistema deverá notificar o utilizador se não for possível listar os valores da pesquisa pretendida
devido a valores incorrectos.
O sistema também deverá permitir ao analista alterar o estado do caso suspeito e da respectiva
assinatura. Por exemplo; passar todos os casos alarmados com atributo impacto igual a “E” para
Anexos
155
“resolvido e não fraudulento” ou caso suspeito com telefone igual a “M” para “resolvido e
fraudulento”.
A qualquer altura o sistema deverá permitir ao utilizador cancelar as operações que está a efectuar
e sair da aplicação.
Stakeholders: Analista.
Exportar
Figura 46 - Diagrama de Use-Cases: Exportar
Descrição: O sistema deverá permitir escolher os resultados produzidos na análise a exportar
para ficheiro. Poderão ser exportados vários resultados de uma vez e também deverá ser possível
incluir no(s) ficheiro(s) exportados informação associada à assinatura do caso suspeito.
O sistema deverá notificar o utilizador se não for possível exportar os resultados escolhidos.
A qualquer altura o sistema deverá permitir ao utilizador cancelar as operações que está a efectuar
e sair da aplicação.
Stakeholders: Analista.
Anexos
156
Anexo D
Diagramas de Actividades
Neste anexo são apresentados alguns dos diagramas de actividades mais importantes criados na
especificação de requisitos. A cada diagrama está associado um use case do Anexo C.
Parâmetros
Figura 47 - Diagrama de Actividades: Parâmetros
Anexos
157
Análise
!
Figura 48 - Diagrama de Actividades: Análise
Anexos
158
Exportar
Figura 49 - Diagrama de Actividades: Exportar
Anexos
159
Anexo E
Requisitos de Hardware e Software
Prevê-se uma elevada carga computacional para fazer o processamente diário das Assinaturas,
neste sentido será necessária a utilização de uma máquina com componentes preparados para o
efeito. Os componentes essenciais para o bom funcionamento do sistema são os módulos de
memória e o(s) processador(s). O armazenamento também é importante pois prevê-se um
aumento elevado do número de clientes todos os anos.
Visto que o sistema será integrado no Centaur e como o SGBD a utilizar será Oracle o 10g, depois
de algum estudo e investigação, uma possível solução seria a utilização do Sun Oracle Database
Machine em conjunto com o Exadata Storage Server, ou qualquer solução semelhante.
A máquina disponibiliza uma solução ideal para todas as bases de dados com elevada carga
computacional, desde aplicações de data warehousing exigentes até aplicações altamente
concurrentes OLTP. Com a combinação do Oracle Exadata Storage Server Software e com os
últimos componentes de hardware lançados pela Sun, a máquina oferece uma performance
excelente num ambiente de alta disponibilidade e alta segurança. Dependendo do tamanho e da
largura de I/O necessária, existem vários modelos de máquinas diferentes disponíveis . De
seguida, alguns dos componentes da configuração base:
• Servidores de Armazenamento Exadata que podem ser SAS ou SATA.
• Sistema Standard de base de dados Oracle 10g com: dois Intel Xeon , processadores
quad-core E5540 a 2.53Ghz, 72 GB de RAM, quatro 146 GB SAS, quatro portas Ethernet a
1 GB/segundo e fontes de alimentação reduntantes.
• Sun QDR com switches Infiniband e cabos de 40 Gb/segundo para a comunicação entre o
servidor de base de dados e o servidor de armazenamento Exdata.
Todos os componentes foram seleccionados para maximizar a performance do sistema e assegurar
a sua fiabilidade. De seguida algumas das capacidades de uma máquina semelhante à que foi em
cima descrita:
• Pesquisas de dados a velocidades de 500gb/segundo (quando pesquisando dados
Anexos
160
comprimidos)
• Permite até 1milhão de I/O por segundo (IOPS)
• Carregamentos a 5TB/hora
Esta seria assim a solução ideal, no entanto, dependendo das opções disponíveis, quanto mais
próxima desta solução melhor.
Anexos
161
Anexo F
Modelação Conceptual
Neste anexo é feita a modelação conceptual para a vista de utilizador do analista, esta vista
contém as restas vistas do sistema. São identificadas as entidades, relacionamentos, atributos e
respectivos domínios; são definidas as chaves primárias; o modelo desenvolvido é verficado; é
feita a validação do modelo desenvolvido com as transacções dos utilizadores; por fim é feita uma
revisão dos modelos desenvolvidos com os utilizadores.
Caracterização das entidades
Nesta secção apresentam-se as várias entidades que fazem parte do modelo conceptual da base
de dados.
Assinatura
Esta entidade é responsável por armazenar o perfil de cada cliente. Este perfil traduz o
comportamento do cliente até aos registos mais recentes que ainda não foram processados. É a
entidade mais importante pois permite, através da comparação com as transacções recentes,
verificar se o cliente se desviou da sua rotina habitual. É a base para a detecção de fraude.
Assinatura_Classe
Esta entidade representa classes de utilização de assinaturas legítimas. Estas classes são
actualizadas segundo uma janela temporal de acordo com as assinaturas dos clientes existentes.
As classes são comparadas durante o processamento das assinaturas, quando os sumários
agregados não contêm nenhuma assinatura associada e é necessário criar uma nova. Os sumários
tomam o valor da assinatura de classe mais equivalente.
Anexos
162
Assinatura_Fraude
Esta entidade representa perfis de fraude previamente conhecidos. Estes modelos são comparados
após o processamento das assinaturas para verificar se existe alguma semelhança e se pode ser
um caso suspeito.
Sumário_Temporário
Na actualização das assinaturas, os valores dos sumários que estão associados ás assinaturas que
foram identificadas como casos suspeitos são armazenados nesta entidade. Como a assinatura não
é actualizada enquanto o caso não for resolvido, poderia-se perder o comportamento intermédio
até a sua resolução. Desta forma, se o caso se provar legítimo, é possível voltar a reconstruir a
assinatura com os sumários que vão ficando armazenados.
Caso_Suspeito
Esta entidade representa todos os casos que alarmaram durante o processamento das assinaturas.
Se o limiar estabelecido na comparação do comportamento da assinatura recente com a antiga for
ultrapassado o caso é aqui armazenado. É possível verificar qual o atributo que teve maior peso na
geração do alarme, o valor do alarme e a data em que o mesmo foi disparado. Enquanto a
situação não for resolvida as próximas assinaturas dos clientes suspeitos não podem ser
actualizadas. Esta entidade é muito importante para a análise de situações fraudulentas.
Entidades de controlo e funcionalidades especiais
O sistema Centaur carrega todo o tráfego gerado pela sua operadora para uma Base de Dados já
existente. O tráfego chega ao Centaur na forma de ficheiros de texto. Estes ficheiros são depois
copiados para o sistema de mediação. De seguida, os ficheiros são carregados para a base de
Anexos
163
dados via Oracle SQL Loader e mediados para o formato unificado Centaur e colocados no sistema
de detecção. Depois dos dados estarem tratados é necessário adicionar e preparar o componente
de detecção baseado em assinaturas.
Loading_Assinatura_Voz
É nesta entidade onde vão ser armazenados os registos de voz necessários para calcular os
sumários e actualizar as assinaturas. O conteúdo necessário para criar os sumários e actualizar as
assinaturas é periodicamente trocado pelo conteúdo da entidade Pump_Assinatura_Voz.
Loading_Assinatura_SMS
É nesta entidade onde vão ser armazenados os registos de SMS necessários para calcular os
sumários e actualizar as assinaturas. O conteúdo necessário para criar os sumários e actualizar as
assinaturas é periodicamente trocado pelo conteúdo da entidade Pump_Assinatura_Voz.
Pump_Assinatura_Voz
Esta entidade é preenchida no processamento das assinaturas com a informação necessária para
construir os sumários da janela temporal definida. Na verdade, é trocada a informação da entidade
Loading_Assinatura_Voz pela informação desta entidade que inicialmente está vazia. Deverá ser
removida a chave primária da entidade Pump_Assinatura_Voz para o processo de inserção ser o
mais eficiente possível. A entidade Loading_Assinatura_Voz fica assim sem a informação relativa
aos registos associados ás assinaturas que já foram actualizadas e está preparada para continuar a
receber outros registos. Já com a informação na entidade Pump_Assinaturas_Voz, a chave primária
é novamente criada para garantir que não são carregados registos duplicados. Se a operação
falhar devido a registos duplicados, estes são removidos e a operação é novamente efectuada.
Anexos
164
Pump_Assinatura_SMS
Esta entidade é preenchida no processamento das assinaturas com a informação necessária para
construir os sumários da janela temporal definida. Na verdade, é trocada a informação da entidade
Loading_Assinatura_SMS pela informação desta entidade que está vazia. Deverá ser removida a
chave primária da entidade Pump_Assinatura_SMS para o processo de inserção ser o mais eficiente
possível. A entidade Loading_Assinatura_SMS fica assim sem a informação relativa aos registos
associados ás assinaturas que já foram actualizadas e está preparada para continuar a receber
outros registos. Já com a informação na entidade Pump_Assinaturas_SMS, a chave primária é
novamente criada para garantir que não são carregados registos duplicados. Se a operação falhar
devido a registos duplicados, estes são removidos e a operação é novamente efectuada.
Relacionamentos
Relacionamento entre as entidades Assinatura e Caso_Suspeito
Este relacionamento permite verificar quais os casos suspeitos que estão associados a um
cliente/assinatura. A assinatura pode não ter nenhum caso suspeito, poderá ter vários casos
suspeitos já resolvidos ou pode ter vários casos suspeitos resolvidos e um mais recente por
resolver.
Cardinalidade: 1 (Assinatura) para N (Caso_Suspeito)
Participação: P (Assinatura) : T (Caso_Suspeito)
Relacionamento entre as entidades Assinatura e Assinatura_Classe
Este relacionamento permite verificar quais as assinaturas que estão associados a uma classe de
assinatura. A assinatura tem sempre uma classe associada, na sua criação terá de ser associada a
um registo Assinatura_Classe
Cardinalidade: 1 (Assinatura_Classe) para N (Assinatura)
Anexos
165
Participação: T (Assinatura) : P (Assinatura_Classe)
Relacionamento entre as entidades Caso_Suspeito e Assinatura_Fraude
Este relacionamento permite verificar quais os casos suspeitos que têm uma assinatura de fraude
associada. Os casos suspeitos podem não ter nenhuma assinatura de fraude relacionada. Quando
o caso suspeito é relativo a um alarme de aprendizagem não supervisionada, ou seja, distância
entre um sumario temporário e a sua respectiva assinatura, não existe qualquer assinatura de
fraude associada.
Cardinalidade: 1 (Assinatura_Fraude) para N (Caso_Suspeito)
Participação: P (Caso_Suspeito) : P (Assinatura_Fraude)
Relacionamento entre as entidades Caso_Suspeito e Sumario_Temporario
Este relacionamento permite verificar quais os sumários temporários associados a um caso
suspeito. Os casos suspeitos podem não ter nenhum sumario temporário associado. Assim que um
caso seja resolvido e classificado como “Não Fraude”, o caso é fechado e os sumários temporários
após serem processados são eliminados.
Cardinalidade: 1 (Caso_Suspeito) para N (Sumario_Temporario)
Participação: P (Caso_Suspeito) : T (Sumario_Temporario)
Identificação dos atributos
Nesta secção vai ser apresentada a definição dos atributos para cada entidade. Todos os atributos
que podem conter o valor null serão explicitamente identificados. Grande parte dos atributos que
estão na entidade Assinatura são os mesmos que os que estão nas entidade Sumário_Temporário
e Assinatura_Fraude. O mesmo acontece nos casos das entidades Loading_Assinatura_Voz com
Pump_Assinatura_Voz e Loading_Assinatura_SMS e Pump_Assinatura_SMS. Para estes casos irei
Anexos
166
apenas identificar os atributos uma vez na entidade Assinatura, na entidade
Loading_Assinatura_Voz e Loading_Assinatura_SMS.
Assinatura
assinatura = {Id_assinatura, Telefone, Estado, Descrição, Data Inicial, Data Final,
Duração_chamadas_nacional, Duração_chamadas_roaming, Num_chamadas_efectuadas,
Num_chamadas_recebidas, Num_chamadas_semana, Num_chamadas_fds, Num_chamadas_dia,
Num_chamadas_noite, Num_chamadas_operadora_igual, Num_chamadas_outra_operadora,
Num_chamadas_roaming, Num_chamadas_roaming_efectuadas,
Num_chamadas_roaming_recebidas, Num_sms_semana, Num_sms_fds, Num_sms_dia,
Num_sms_noite, Num_sms_enviadas, Num_sms_recebidas, Num_sms_operadora_igual,
Num_sms_outra_operadora, Num_sms_roaming, Num_sms_roaming_enviadas,
Num_sms_roaming_recebidas, Duração_chamadas_nacional_dp, Duração_chamadas_roaming_dp,
Num_chamadas_efectuadas_dp, Num_chamadas_recebidas_dp, Num_chamadas_semana_dp,
Num_chamadas_fds_dp, Num_chamadas_dia_dp, Num_chamadas_noite_dp,
Num_chamadas_operadora_igual_dp, Num_chamadas_outra_operadora_dp,
Num_chamadas_roaming_dp, Num_chamadas_roaming_efectuadas_dp,
Num_chamadas_roaming_recebidas_dp, Num_sms_semana_dp, Num_sms_fds_dp,
Num_sms_dia_dp, Num_sms_noite_dp, Num_sms_enviadas_dp, Num_sms_recebidas_dp,
Num_sms_operadora_igual_dp, Num_sms_outra_operadora_dp, Num_sms_roaming_dp,
Num_sms_roaming_enviadas_dp, Num_sms_roaming_recebidas_dp}
Id_assinatura: Atributo unívoco para identificar cada assinatura. É auto incrementado pelo
sistema.
Domínio: Número inteiro.
Telefone: Este atributo representa o número de telefone associado à assinatura. Não existem
clientes com números de telefone iguais.
Domínio: Alfanumérico até 30 caracteres.
Anexos
167
Estado: Este atributo permite verificar se a assinatura tem algum caso suspeito por resolver ou
não.
Domínio: Numero inteiro, restringido a “1” (com caso suspeito por resolver) ou “0” (assinatura sem
casos suspeitos por resolver).
Descrição: Este atributo permite adicionar qualquer descrição ou comentário em particular à
assinatura em questão. Se existir alguma informação, relativa a uma assinatura em particular e
que deverá ser armazenada, é neste atributo.
Domínio: Alfanumérico até 100 caracteres ou null.
Data Inicial: Este atributo representa a data inicial a partir do qual a assinatura representa o
comportamento associado a um número de telefone.
Domínio: Data
Data Final: Este atributo representa a data até onde a assinatura representa o comportamento
associado a um número de telefone. Através deste atributo e da Data Inicial, é possível determinar
a janela temporal do perfil de um cliente.
Domínio: Data
De seguida as medidas de perfil que em conjunto representam o comportamento típico
de um utilizador.
Duração_chamadas_nacional: Atributo complexo que está dividido em dois atributos
(Duração_chamadas_nacional + Duração_chamadas_nacional_dp). Representa a duração média
das chamadas efectuadas em território nacional.
Domínio: Número decimal.
Duração_chamadas_roaming: Este atributo representa a duração média das chamadas
efectuadas em território internacional.
Domínio: Número decimal.
Num_chamadas_efectuadas: Este atributo representa o número médio de chamadas realizadas
por determinado número de telefone. Não são incluídas as chamadas recebidas.
Anexos
168
Domínio: Número inteiro.
Num_chamadas_recebidas: Este atributo representa o número médio de chamadas recebidas
em determinado número de telefone. Não são incluídas as chamadas efectuadas.
Domínio: Número inteiro.
Num_chamadas_dias_uteis: Atributo complexo que está dividido em dois atributos
(Num_chamadas_semana + Num_chamadas_semana_dp). Representa o número médio de
chamadas efectuadas e recebidas por determinado número de telefone em dias úteis.
Domínio: Número inteiro.
Num_chamadas_fds: Atributo complexo que está dividido em dois atributos
(Num_chamadas_fds + Num_chamadas_fds_dp). Representa o número médio de chamadas
efectuadas e recebidas por determinado número de telefone durante o fim de semana.
Domínio: Número inteiro.
Num_chamadas_dia: Este atributo representa o número médio de chamadas efectuadas e
recebidas durante o dia (desde as 7h até ás 24h).
Domínio: Número inteiro.
Num_chamadas_noite: Este atributo representa o número médio de chamadas efectuadas e
recebidas durante a noite (desde as 24h até ás 7h).
Domínio: Número inteiro.
Num_chamadas_operadora_igual: Este atributo representa o número médio de chamadas
efectuadas e recebidas por determinado número de telefone para a mesma operadora.
Domínio: Número inteiro.
Num_chamadas_outra_operadora: Este atributo representa o número médio de chamadas
efectuadas e recebidas por determinado número de telefone para uma operadora diferente da sua.
Domínio: Número inteiro.
Anexos
169
Num_chamadas_roaming: Este atributo representa o número médio de chamadas
internacionais efectuadas e recebidas por determinado número de telefone.
Domínio: Número inteiro.
Num_chamadas_roaming_efectuadas: Este atributo representa o número médio de
chamadas internacionais efectuadas por determinado número de telefone. Não são incluídas as
chamadas recebidas.
Domínio: Número inteiro.
Num_chamadas_roaming_recebidas: Este atributo representa o número médio de chamadas
internacionais recebidas em determinado número de telefone. Não são incluídas as chamadas
efectuadas.
Domínio: Número inteiro.
Num_sms_dias_uteis: Atributo complexo que está dividido em dois atributos
(Num_sms_semana + Num_sms_semana_dp). Número médio de mensagens escritas recebidas e
enviadas em determinado número de telefone em dias úteis.
Domínio: Número inteiro.
Num_sms_fds: Atributo complexo que está dividido em dois atributos (Num_sms_fds +
Num_sms_fds_dp). Número médio de mensagens escritas recebidas e enviadas em determinado
número de telefone durante o fim de semana.
Domínio: Número inteiro.
Num_sms_dia: Este atributo representa o número médio de SMS enviadas e recebidas em
determinado número de telefone durante o dia (desde as 7h até ás 24h).
Domínio: Número inteiro.
Num_sms_noite: Este atributo representa o número médio de SMS enviadas e recebidas em
determinado número de telefone durante a noite (desde as 24h até ás 7h).
Domínio: Número inteiro.
Anexos
170
Num_sms_enviadas: Este atributo representa o número médio de SMS enviadas por
determinado número de telefone.
Domínio: Número inteiro.
Num_sms_recebidas: Este atributo representa o número médio de SMS recebidas em
determinado número de telefone.
Domínio: Número inteiro.
Num_sms_operadora_igual: Este atributo representa o número médio de SMS recebidas e
enviadas em determinado número de telefone para a mesma operadora.
Domínio: Número inteiro.
Num_sms_outra_operadora: Este atributo representa o número médio de SMS recebidas e
enviadas em determinado número de telefone para uma operadora diferente da sua.
Domínio: Número inteiro.
Num_sms_roaming: Este atributo representa o número médio de SMS internacionais recebidas
e enviadas em determinado número de telefone.
Domínio: Número inteiro.
Num_sms_roaming_enviadas: Este atributo representa o número médio de SMS internacionais
enviadas por determinado número de telefone.
Domínio: Número inteiro.
Num_sms_roaming_recebidas: Este atributo representa o número médio de SMS
internacionais recebidas em determinado número de telefone.
Domínio: Número inteiro.
De seguida, os valores de desvio padrão relativos ás mesmas medidas de perfil em
cima mencionadas. Estes valores indicam a dispersão máxima que os atributos podem
ter. Desta forma é possível compreender as variações de comportamento dos
Anexos
171
utilizadores e efectuar cálculos de distancia de forma mais precisa. Todos estes
atributos são Numéricos Decimais. De seguida a lista dos atributos de desvio padrão.
1. Duração_chamadas_nacional_dp
2. Duração_chamadas_roaming_dp
3. Num_chamadas_efectuadas_dp
4. Num_chamadas_recebidas_dp
5. Num_chamadas_semana_dp
6. Num_chamadas_fds_dp
7. Num_chamadas_dia_dp
8. Num_chamadas_noite_dp
9. Num_chamadas_operadora_igual_dp
10. Num_chamadas_outra_operadora_dp
11. Num_chamadas_roaming_dp
12. Num_chamadas_roaming_efectuadas_dp
13. Num_chamadas_roaming_recebidas_dp
14. Num_sms_semana_dp
15. Num_sms_fds_dp
16. Num_sms_dia_dp
17. Num_sms_noite_dp
18. Num_sms_enviadas_dp
19. Num_sms_recebidas_dp
20. Num_sms_operadora_igual_dp
21. Num_sms_outra_operadora_dp
22. Num_sms_roaming_dp
23. Num_sms_roaming_enviadas_dp
24. Num_sms_roaming_recebidas_dp
Sumário_Temporário
sumário_temporario = {Id_sumário, Telefone, Descrição, Data Inicial, Data Final,
Duração_chamadas_nacional, Duração_chamadas_roaming, Num_chamadas_efectuadas,
Anexos
172
Num_chamadas_recebidas, Num_chamadas_semana, Num_chamadas_fds, Num_chamadas_dia,
Num_chamadas_noite, Num_chamadas_operadora_igual, Num_chamadas_outra_operadora,
Num_chamadas_roaming, Num_chamadas_roaming_efectuadas,
Num_chamadas_roaming_recebidas, Num_sms_semana, Num_sms_fds, Num_sms_dia,
Num_sms_noite, Num_sms_enviadas, Num_sms_recebidas, Num_sms_operadora_igual,
Num_sms_outra_operadora, Num_sms_roaming, Num_sms_roaming_enviadas,
Num_sms_roaming_recebidas}
Id_sumário: Atributo unívoco para identificar cada sumário. É auto incrementado pelo sistema.
Domínio: Número inteiro.
Telefone: Este atributo representa o número de telefone associado ao sumário. Não existem
clientes com números de telefone iguais.
Domínio: Alfanumérico até 30 caracteres.
Descrição: Este atributo permite adicionar qualquer descrição ou comentário em particular ao
sumário em questão. Se existir alguma informação, relativa a um sumário em particular e que
deverá ser armazenada, é neste atributo.
Domínio: Alfanumérico até 100 caracteres ou null.
Data Inicial: Este atributo representa a data inicial a partir do qual o sumário representa o
comportamento associado a um número de telefone.
Domínio: Data
Data Final: Este atributo representa a data até onde o sumário representa o comportamento
associado a um número de telefone. Através deste atributo e da Data Inicial, é possível determinar
a janela temporal do perfil de um cliente.
Domínio: Data
Os restantes atributos/medidas de perfil são idênticos aos descritos na entidade Assinatura, apenas
não existem os atributos de desvio padrão.
Anexos
173
Assinatura_Classe
assinatura_classe = {Id_assinatura_classe, Descrição, Duração_chamadas_nacional,
Duração_chamadas_roaming, Num_chamadas_efectuadas, Num_chamadas_recebidas,
Num_chamadas_semana, Num_chamadas_fds, Num_chamadas_dia, Num_chamadas_noite,
Num_chamadas_operadora_igual, Num_chamadas_outra_operadora, Num_chamadas_roaming,
Num_chamadas_roaming_efectuadas, Num_chamadas_roaming_recebidas, Num_sms_semana,
Num_sms_fds, Num_sms_dia, Num_sms_noite, Num_sms_enviadas, Num_sms_recebidas,
Num_sms_operadora_igual, Num_sms_outra_operadora, Num_sms_roaming,
Num_sms_roaming_enviadas, Num_sms_roaming_recebidas, Duração_chamadas_nacional_dp,
Duração_chamadas_roaming_dp, Num_chamadas_efectuadas_dp, Num_chamadas_recebidas_dp,
Num_chamadas_semana_dp, Num_chamadas_fds_dp, Num_chamadas_dia_dp,
Num_chamadas_noite_dp, Num_chamadas_operadora_igual_dp,
Num_chamadas_outra_operadora_dp, Num_chamadas_roaming_dp,
Num_chamadas_roaming_efectuadas_dp, Num_chamadas_roaming_recebidas_dp,
Num_sms_semana_dp, Num_sms_fds_dp, Num_sms_dia_dp, Num_sms_noite_dp,
Num_sms_enviadas_dp, Num_sms_recebidas_dp, Num_sms_operadora_igual_dp,
Num_sms_outra_operadora_dp, Num_sms_roaming_dp, Num_sms_roaming_enviadas_dp,
Num_sms_roaming_recebidas_dp}
Id_assinatura_classe: Atributo unívoco para identificar cada classe de assinatura. É auto
incrementado pelo sistema.
Domínio: Número inteiro.
Descrição: Este atributo permite adicionar qualquer descrição ou comentário em particular à
classe de assinatura em questão. Se existir alguma informação, relativa a uma classe de assinatura
que deverá ser armazenada, é neste atributo.
Domínio: Alfanumérico até 100 caracteres ou null.
Os restantes atributos/medidas são idênticos aos descritos na entidade Assinatura, incluindo os
atributos de desvio padrão.
Anexos
174
Assinatura_Fraude
assinatura_fraude = {Id_assinatura_fraude, Descricao, Duração_chamadas_nacional,
Duração_chamadas_roaming, Num_chamadas_efectuadas, Num_chamadas_recebidas,
Num_chamadas_semana, Num_chamadas_fds, Num_chamadas_dia, Num_chamadas_noite,
Num_chamadas_operadora_igual, Num_chamadas_outra_operadora, Num_chamadas_roaming,
Num_chamadas_roaming_efectuadas, Num_chamadas_roaming_recebidas, Num_sms_semana,
Num_sms_fds, Num_sms_dia, Num_sms_noite, Num_sms_enviadas, Num_sms_recebidas,
Num_sms_operadora_igual, Num_sms_outra_operadora, Num_sms_roaming,
Num_sms_roaming_enviadas, Num_sms_roaming_recebidas}
Id_assinatura: Atributo unívoco para identificar cada modelo de assinatura fraudulenta. É auto
incrementado pelo sistema.
Domínio: Número inteiro.
Descrição: Este atributo permite adicionar qualquer descrição ou comentário em particular à
assinatura de fraude em questão. Se existir alguma informação, relativa a à assinatura de fraude
em particular e que deverá ser armazenada, é neste atributo.
Domínio: Alfanumérico até 100 caracteres ou null.
Os restantes atributos/medidas são idênticos aos descritos na entidade Assinatura, apenas não
estão incluídos os atributos de desvio padrão.
Caso_Suspeito
caso_suspeito = {Id_caso_suspeito, Estado, Descrição, Data Inicial, Data Final, Data Resolução,
Telefone, Data_alarme, Valor_alarme, Atributo_impacto, Valor_atributo_impacto,
Distancia_num_chamadas_efectuadas, Distancia_num_chamadas_recebidas,
Distancia_duracao_chamadas_nacional, Distancia_duracao_chamadas_roaming,
Distancia_num_chamadas_roaming, Distancia_num_chamadas_roaming_efectuadas,
Distancia_num_chamadas_roaming_recebidas, Distancia_num_chamadas_outra_operadora,
Distancia_num_chamadas_operadora_igual, Distancia_num_chamadas_semana,
Anexos
175
Distancia_num_chamadas_fds, Distancia_num_chamadas_dia, Distancia_num_chamadas_noite,
Distancia_num_sms_enviadas, Distancia_num_sms_recebidas, Distancia_num_sms_roaming,
Distancia_num_sms_roaming_enviadas, Distancia_num_sms_roaming_recebidas,
Distancia_num_sms_outra_operadora, Distancia_num_sms_operadora_igual,
Distancia_num_sms_semana, Distancia_num_sms_fds, Distancia_num_sms_dia,
Distancia_num_sms_noite}
Id_caso_suspeito: Atributo unívoco para identificar cada caso suspeito. É auto incrementado
pelo sistema.
Domínio: Número Inteiro.
Estado: Este atributo permite verificar qual a situação actual do caso suspeito. É possível
determinar se este já foi resolvido e se foi classificado como fraude, se já foi resolvido e
classificado como não fraude ou se ainda não foi resolvido.
Domínio: Número inteiro, restringido a “0” (não resolvido), “1” (resolvido, é fraude), “2” (resolvido,
não é fraude).
Descrição: Este atributo permite adicionar qualquer descrição ou comentário em particular ao
caso suspeito em questão. Se existir alguma informação, relativa a um caso suspeito em particular
e que deverá ser armazenada, é neste atributo.
Domínio: Alfanumérico até 100 caracteres ou null.
Data Inicial: Este atributo representa a data inicial da assinatura associada ao caso suspeito.
Domínio: Data.
Data Final: Este atributo representa a data final da assinatura associada ao caso suspeito.
Domínio: Data.
Data Resolução: Este atributo representa a data em que o caso suspeito ficou resolvido.
Domínio: Date ou null.
Telefone: Este atributo representa o telefone da assinatura associada ao caso suspeito.
Domínio: Alfanumérico até 30 caracteres.
Anexos
176
Data_alarme: Este atributo representa a data em que o alarme foi criado ou disparado.
Domínio: Data
Valor_alarme: Este atributo representa o valor de alarme obtido no cálculo da distância entre a
assinatura mais recente e a assinatura antiga.
Domínio: Número decimal.
Atributo_impacto: Este atributo representa o atributo da assinatura associada ao alarme que
teve maior impacto na geração do caso suspeito.
Domínio: Numero inteiro, restringido a “1” (Duração_chamadas_nacional), “2”
(Duração_chamadas_roaming), “3” (Num_chamadas_efectuadas), “4”
(Num_chamadas_recebidas), “5” (Num_chamadas_semana), “6” (Num_chamadas_fds), “7”
(Num_chamadas_dia), “8” (Num_chamadas_noite), “9” (Num_chamadas_operadora_igual), “10”
(Num_chamadas_outra_operadora), “11” (Num_chamadas_roaming), “12”
(Num_chamadas_roaming_efectuadas), “13” (Num_chamadas_roaming_recebidas), “14”
(Num_sms_semana), “15” (Num_sms_fds), “16” (Num_sms_dia), “17” (Num_sms_noite), “19”
(Num_sms_enviadas), “20” (Num_sms_recebidas), “21” (Num_sms_operadora_igual), “22”
(Num_sms_outra_operadora), “23” (Num_sms_roaming), “24” (Num_sms_roaming_enviadas) e
“25” (Num_sms_roaming_recebidas).
Valor_atributo_impacto: Este atributo representa o valor obtido no atributo impacto que
pertence ao sumário resultante do processamento. Poderá servir para numa primeira análise
verificar se foi um valor muito alto ou muito baixo por exemplo.
Domínio: Número decimal.
De seguida, os valores de distância de cada atributo. Estes valores são relativos ao
sumario temporário responsável pelo caso suspeito. Durante o processamento das
assinaturas, se os limiares forem ultrapassados, é armazenada o valor de distância
entre cada atributo do sumário temporário e da assinatura. Desta forma, é possível
analisar rapidamente quais os atributos que tiveram maior importância na geração dos
alarmes. Todos estes atributos são Numéricos Decimais. De seguida a lista dos
atributos de distancia.
Anexos
177
• Distancia_num_chamadas_efectuadas
• Distancia_num_chamadas_recebidas
• Distancia_duracao_chamadas_nacional
• Distancia_duracao_chamadas_roaming
• Distancia_num_chamadas_roaming
• Distancia_num_chamadas_roaming_efectuadas
• Distancia_num_chamadas_roaming_recebidas
• Distancia_num_chamadas_outra_operadora
• Distancia_num_chamadas_operadora_igual
• Distancia_num_chamadas_semana
• Distancia_num_chamadas_fds
• Distancia_num_chamadas_dia
• Distancia_num_chamadas_noite
• Distancia_num_sms_enviadas
• Distancia_num_sms_recebidas
• Distancia_num_sms_roaming
• Distancia_num_sms_roaming_enviadas
• Distancia_num_sms_roaming_recebidas
• Distancia_num_sms_outra_operadora
• Distancia_num_sms_operadora_igual
• Distancia_num_sms_semana
• Distancia_num_sms_fds
• Distancia_num_sms_dia
• Distancia_num_sms_noite
Loading_Assinatura_Voz
loading_assinatura_voz = {Card, Event_Day, Event_Hour, Event_Time, A_Number, B_Number,
Roaming, Air_Time, Id_Transaction, Id_Record}
Card: Este atributo representa o número de telefone do responsável pelo pagamento da chamada
de voz.
Anexos
178
Domínio: Alfanumérico até 30 caracteres
Event_Day: Este atributo representa o dia em que foi efectuada a chamada de voz.
Domínio: Número Inteiro.
Event_Hour: Este atributo representa a hora em que foi efectuada a chamada de voz.
Domínio: Número Inteiro.
Event_Time: Este atributo representa a hora detalhada (ano, mês, dia, hora, minutos e
segundos) em que foi efectuada a chamada de voz.
Domínio: Data.
A_Number: Este atributo representa o número de telefone do originador da chamada de voz.
Domínio: Alfanumérico até 30 caracteres.
B_Number: Este atributo representa o número de telefone do destinatário da chamada de voz.
Domínio: Alfanumérico até 30 caracteres.
Roaming: Este atributo indica se a chamada de voz é uma chamada roaming ou não.
Domínio: Número inteiro, restringido a “0” (não é roaming) e “1” (é roaming).
Air_Time: Este atributo representa a duração efectiva da chamada.
Domínio: Número decimal.
Id_Transaction: Este atributo identifica o tipo de transacção em questão. Pode ser um chamada
de voz originada ou terminada, uma SMS enviada ou recebida, um fax enviado ou recebido, uma
chamada PABX originada ou terminada etc. É através deste atributo que se escolhe o tipo de
transacções necessárias para o estudo em questão, no processamento diário apenas é agregada a
informação de chamadas de voz e SMS.
Domínio: Número inteiro.
Id_Record: Este atributo representa o identificador único da transacção em questão.
Domínio: Número inteiro.
Anexos
179
Loading_Assinatura_SMS
loading_assinatura_sms = {Card, Event_Day, Event_Hour, Event_Time, A_Number, B_Number,
Roaming, Id_Transaction, Id_Record}
Card: Este atributo representa o número de telefone do responsável pelo pagamento da SMS.
Domínio: Alfanumérico até 30 caracteres
Event_Day: Este atributo representa o dia em que foi registada a SMS.
Domínio: Número Inteiro.
Event_Hour: Este atributo representa a hora em que foi registada a SMS.
Domínio: Número Inteiro.
Event_Time: Este atributo representa a hora detalhada (ano, mês, dia, hora, minutos e
segundos) em que foi registada a SMS.
Domínio: Data.
A_Number: Este atributo representa o número de telefone do originador da SMS.
Domínio: Alfanumérico até 30 caracteres.
B_Number: Este atributo representa o número de telefone do destinatário da SMS.
Domínio: Alfanumérico até 30 caracteres.
Roaming: Este atributo indica se a SMS é de chamada roaming ou não.
Domínio: Número inteiro, restringido a “0” (não é roaming) e “1” (é roaming).
Id_Transaction: Este atributo identifica o tipo de transacção em questão. Pode ser um chamada
de voz originada ou terminada, uma SMS enviada ou recebida, um fax enviado ou recebido, uma
chamada PABX originada ou terminada etc. É através deste atributo que se escolhe o tipo de
Anexos
180
transacções necessárias para o estudo em questão, no processamento diário apenas é agregada a
informação de chamadas de voz e SMS.
Domínio: Número inteiro.
Id_Record: Este atributo representa o identificador único da transacção em questão.
Domínio: Número inteiro.
Pump_Assinatura_Voz
pump_assinatura_voz = {Id_pump_voz, Telefone, Dia, Hora, Origem, Destino, Roaming,
Duracao_chamada}
Id_pump_voz: Atributo unívoco para identificar cada registo de chamada de voz. É auto
incrementado pelo sistema.
Domínio: Número Inteiro.
Os restantes atributos/medidas são idênticos aos descritos na entidade Loading_Assinatura_Voz.
Pump_Assinatura_SMS
pump_assinatura_sms = {Id_pump_sms, Telefone, Dia, Hora, Origem, Destino, Roaming}
Id_pump_sms: Atributo unívoco para identificar cada registo de mensagens escritas. É auto
incrementado pelo sistema.
Domínio: Número Inteiro.
Os restantes atributos/medidas são idênticos aos descritos na entidade Loading_Assinatura_sms.
!
Anexos
181
Verificação de Redundância no modelo
Re-Examinar os Relacionamentos de 1 para 1 (1:1)
Inicialmente havia, de facto, um relacionamento de 1:1 entre a entidade Caso_Suspeito e uma
entidade chamada Alarme. Esta entidade continha os atributos “Valor_alarme”, “Atributo_Impacto”
e “Data_alarme”. Depois de algum estudo constatou-se que faria mais sentido incluir estes
atributos na entidade Caso_Suspeito, não só pela performance das pesquisas mas também porque
estes atributos estão directamente ligados ao caso suspeito.
Remover os Relacionamentos Redundantes
No esquema proposto não existe nenhum caso de relacionamento redundante.
Validação do Modelo Conceptual de acordo com as transacções dos
utilizadores
Nesta secção pretende-se descrever e demonstrar as operações mais importantes suportadas por
este modelo.
Irão ser testadas as transacções de forma a manter a consistência nos pedidos à base de dados.
Identificação das transacções
Apenas irão ser consideradas as transacções de um analista, visto que este efectua todas as
transacções possíveis, e uma transacção importante efectuada automaticamente pelo próprio
sistema.
Transacção de um Analista
Anexos
182
• Alterar o estado “0” de uma assinatura para “1” e o respectivo caso suspeito.
Para efectuar esta operação será necessário utilizar a entidade Assinatura e a entidade
Caso_Suspeito
• Listar todos os casos suspeitos por resolver com atributo impacto igual a “1”.
Para efectuar esta operação apenas será necessário utilizar a entidade Caso_Suspeito.
• Verificar se a entidade Pump_Assinaturas_SMS tem algum conteúdo.
Para verificar se a entidade tem conteúdo apenas será necessário utilizar a entidade
Pump_Assinaturar_SMS.
• Remover todos os sumários temporários com telefone igual a “X”.
Para efectuar esta operação será necessário utilizar a entidade Sumario_Temporario.
• Verificar se existe algum modelo de fraude com “Num_chamadas_efectuadas”
maior que 200, “Num_chamadas_fds” maior que 160 e “Num_chamas_noite”
maior que 130.
Para efectuar esta operação é necessário utilizar a entidade Assinatura_Fraude.
• Listar todas as assinaturas que têm casos suspeitos com o atributo
“Valor_alarme” > 0.8.
Para concluir esta operação é necessário utilizar as entidades Assinatura e Caso_Suspeito.
• Listar todas as assinaturas de uma determinada classe.
Para efectuar esta operação será necessário utilizar as entidades Assinatura e
Assinatura_Casse.
• Listar todos os sumários temporários associados a um determinado caso
suspeito.
Para concluir esta operação é necessário utilizar as entidades Sumario_Temporario e
Caso_Suspeito.
• Listar os valores de uma assinatura de fraude associada a um determinado caso
Anexos
183
suspeito .
Para concluir esta operação é necessário utilizar as entidades Assinatura_Fraude e
Caso_Suspeito.
Transacção do Sistema
• Actualização das assinaturas.
Esta operação é concluído com sucesso através do uso das entidades
Loading_Assinaturas_Voz, Loading_Assinaturas_SMS, Pump_Assinaturas_Voz,
Pump_Assinaturas_SMS, Assinatura, Caso_Suspeito, Assinatura_Fraude, Assinatura_Classe
e Sumário_Temporário. De notar que nem sempre todas estas entidades são utilizadas, as
assinaturas do cliente podem não existir ou pode ser um caso suspeito. Apenas as
entidades Loading_Assinaturas_Voz, Loading_Assinaturas_SMS Pump_Assinaturas_Voz e
Pump_Assinaturas_SMS são sempre utilizadas.
Revisão do modelo de dados com os utilizadores
Após várias reuniões com os utilizadores que vão utilizar o sistema e que fazem parte do grupo de
informática responsável pelo Centaur, onde vai ser integrado o protótipo, chegou-se a um acordo
em que o modelo construído constitui uma representação válida para se passar à fase seguinte de
desenvolvimento.
Anexos
184
Anexos
185
Anexo G
Modelação Lógica
A modelação lógica da Base de Dados é o processo de construção de um modelo da informação
utilizada na empresa baseado num modelo de dados específico, mas independente de qualquer
consideração física, tal como o SGBD ou o hardware.
Traduzir o esquema Conceptual desenvolvido para o esquema Relacional
Entidades Fortes
Neste tópico irão ser identificadas as entidades que têm características próprias, ou seja, que são
de algum modo caracterizáveis e são as mais relevantes para o contexto do problema.
As entidades fortes do esquema ER que serão traduzidas em tabelas são as seguintes:
• Assinatura
• Caso_Suspeito
• Assinatura_Fraude
• Assinatura_Classe
• Sumário_Temporário
Entidades Fracas
Neste tópico irão ser identificadas as entidades que têm características próprias, ou seja, que são
de algum modo caracterizáveis mas que servem para completar a descrição ou a utilização de
outras entidades.
Anexos
186
• Loading_Assinatura_Voz
• Loading_Assinatura_SMS
• Pump_Assinatura_Voz
• Pump_Assinatura_SMS
Descrever os Relacionamentos
No Diagrama ER existem dois relacionamentos 1:N. Neste tipo de relacionamentos a entidade com
cardinalidade 1 será a entidade denominada “pai” e a entidade com cardinalidade N será a
entidade denominada “filha”, assim sendo, a chave estrangeira estará na entidade com
cardinalidade N.
Os relacionamentos presentes no Diagrama ER são os seguintes:
• 1 Assinatura para N Caso_Suspeito
• 1 Assinatura_Classe para N Assinatura
• 1 Caso_Suspeito para N Sumario_Temporario
• 1 Assinatura_Fraude para N Caso_Suspeito
Visto que não existem superclasses/subclasses, relacionamentos N:M ou 1:1, relacionamentos
complexos, relacionamentos recursivos nem atributos multi-valor, de seguida irão ser apresentados
os esquemas no modelo relacional.
4.6.2.3 Apresentação dos esquemas no Modelo Relacional
Irá ser criado um novo esquema que traduz as necessidades de armazenamento. Para todas as
entidades descritas nas secções anteriores, irá ser acrescentada a noção de chave estrangeira.
Os domínios dos atributos estão na secção da modelação conceptual e as chaves estrangeiras têm
o mesmo domínio que as chaves primárias correspondentes.
Anexos
187
Assinatura = {Id_assinatura, Id_assinatura_Classe, Telefone, Estado, Descrição, Data Inicial,
Data Final, Duração_chamadas_nacional, Duração_chamadas_roaming,
Num_chamadas_efectuadas, Num_chamadas_recebidas, Num_chamadas_semana,
Num_chamadas_fds, Num_chamadas_dia, Num_chamadas_noite,
Num_chamadas_operadora_igual, Num_chamadas_outra_operadora, Num_chamadas_roaming,
Num_chamadas_roaming_efectuadas, Num_chamadas_roaming_recebidas, Num_sms_semana,
Num_sms_fds, Num_sms_dia, Num_sms_noite, Num_sms_enviadas, Num_sms_recebidas,
Num_sms_operadora_igual, Num_sms_outra_operadora, Num_sms_roaming,
Num_sms_roaming_enviadas, Num_sms_roaming_recebidas, Duração_chamadas_nacional_dp,
Duração_chamadas_roaming_dp, Num_chamadas_efectuadas_dp, Num_chamadas_recebidas_dp,
Num_chamadas_semana_dp, Num_chamadas_fds_dp, Num_chamadas_dia_dp,
Num_chamadas_noite_dp, Num_chamadas_operadora_igual_dp,
Num_chamadas_outra_operadora_dp, Num_chamadas_roaming_dp,
Num_chamadas_roaming_efectuadas_dp, Num_chamadas_roaming_recebidas_dp,
Num_sms_semana_dp, Num_sms_fds_dp, Num_sms_dia_dp, Num_sms_noite_dp,
Num_sms_enviadas_dp, Num_sms_recebidas_dp, Num_sms_operadora_igual_dp,
Num_sms_outra_operadora_dp, Num_sms_roaming_dp, Num_sms_roaming_enviadas_dp,
Num_sms_roaming_recebidas_dp}
Chave Primária: Id_assinatura
Chave Estrangeira: Id_assinatura_classe
Caso_Suspeito = {Id_caso_suspeito, Id_assinatura, Id_assinatura_fraude, Estado, Descrição,
Data Inicial, Data Final, Data Resolução, Telefone, Data_alarme, Valor_alarme, Atributo_impacto,
Valor_atributo_impacto, Distancia_num_chamadas_efectuadas,
Distancia_num_chamadas_recebidas,
Distancia_duracao_chamadas_nacional, Distancia_duracao_chamadas_roaming,
Distancia_num_chamadas_roaming, Distancia_num_chamadas_roaming_efectuadas,
Distancia_num_chamadas_roaming_recebidas, Distancia_num_chamadas_outra_operadora,
Distancia_num_chamadas_operadora_igual, Distancia_num_chamadas_semana,
Distancia_num_chamadas_fds, Distancia_num_chamadas_dia, Distancia_num_chamadas_noite,
Anexos
188
Distancia_num_sms_enviadas, Distancia_num_sms_recebidas, Distancia_num_sms_roaming,
Distancia_num_sms_roaming_enviadas, Distancia_num_sms_roaming_recebidas,
Distancia_num_sms_outra_operadora, Distancia_num_sms_operadora_igual,
Distancia_num_sms_semana, Distancia_num_sms_fds, Distancia_num_sms_dia,
Distancia_num_sms_noite}
Chave Primária: Id_caso_suspeito
Chaves Estrangeiras: Id_assinatura e Id_assinatura_fraude
Assinatura_Fraude = {Id_assinatura_fraude, Descrição, Duração_chamadas_nacional,
Duração_chamadas_roaming, Num_chamadas_efectuadas, Num_chamadas_recebidas,
Num_chamadas_semana, Num_chamadas_fds, Num_chamadas_dia, Num_chamadas_noite,
Num_chamadas_operadora_igual, Num_chamadas_outra_operadora, Num_chamadas_roaming,
Num_chamadas_roaming_efectuadas, Num_chamadas_roaming_recebidas, Num_sms_semana,
Num_sms_fds, Num_sms_dia, Num_sms_noite, Num_sms_enviadas, Num_sms_recebidas,
Num_sms_operadora_igual, Num_sms_outra_operadora, Num_sms_roaming,
Num_sms_roaming_enviadas, Num_sms_roaming_recebidas}
Chave Primária: Id_assinatura
Chave Estrangeira: não tem
Sumário_Temporário = {Id_sumário, Id_caso_suspeito, Telefone, Descrição, Data Inicial, Data
Final, Duração_chamadas_nacional, Duração_chamadas_roaming, Num_chamadas_efectuadas,
Num_chamadas_recebidas, Num_chamadas_semana, Num_chamadas_fds, Num_chamadas_dia,
Num_chamadas_noite, Num_chamadas_operadora_igual, Num_chamadas_outra_operadora,
Num_chamadas_roaming, Num_chamadas_roaming_efectuadas,
Num_chamadas_roaming_recebidas, Num_sms_semana, Num_sms_fds, Num_sms_dia,
Num_sms_noite, Num_sms_enviadas, Num_sms_recebidas, Num_sms_operadora_igual,
Num_sms_outra_operadora, Num_sms_roaming, Num_sms_roaming_enviadas,
Num_sms_roaming_recebidas}
Anexos
189
Chave Primária: Id_sumário
Chave Estrangeira: Id_caso_suspeito
Loading_Assinatura_Voz = {Card, Event_Day, Event_Hour, Event_Time, A_Number,
B_Number, Roaming, Air_Time, Id_Transaction, Id_Record}
Chave Primária: não tem
Chave Estrangeira: não tem
Loading_Assinatura_SMS = {Card, Event_Day, Event_Hour, Event_Time, A_Number,
B_Number, Roaming, Id_Transaction, Id_Record}
Chave Primária: não tem
Chave Estrangeira: não tem
Pump_Assinatura_Voz = {Card, Event_Day, Event_Hour, Event_Time, A_Number, B_Number,
Roaming, Air_Time, Id_Transaction, Id_Record}
Chave Primária: Id_Record
Chave Estrangeira: não tem
Pump_Assinatura_SMS = {Card, Event_Day, Event_Hour, Event_Time, A_Number, B_Number,
Roaming, Id_Transaction, Id_Record}
Chave Primária: Id_Record
Chave Estrangeira: não tem
Anexos
190
Validação das relações com base nas transacções dos utilizadores
Neste tópico, o objectivo passa por testar os relacionamentos existentes no modelo de dados
lógico. Irão ser testadas as transacções verificadas na modelação conceptual de forma a manter a
consistência nos pedidos á base de dados.
Transacções de um Analista
• Alterar o estado “0” de uma assinatura para “1” e o respectivo caso suspeito.
Para efectuar esta operação será necessário utilizar a tabela Assinatura fazendo uma
junção com a tabela Caso_Suspeito através do atributo “id_assinatura”, que irá ser chave
estrangeira na tabela Caso_Suspeito e chave primária na tabela Assinatura. Depois de
alterar o estado da assinatura em questão e de obter os respectivos casos suspeitos, resta
alterar o estado do caso suspeito por resolver.
• Listar todos os casos suspeitos por resolver com atributo impacto igual a “1”.
Para efectuar esta operação apenas será necessário utilizar a tabela Caso_Suspeito e filtrar
os registos com o atributo impacto igual a “1”.
• Verificar se Pump_Assinaturas_SMS tem algum conteúdo.
Para verificar se a tabela tem conteúdo apenas será necessário utilizar a tabela
Pump_Assinaturar_SMS e fazer o “count” do número de registos. Se o resultado for
superior a 0 então o conteúdo não é vazio.
• Remover todos os sumários temporários com telefone igual a “X”.
Para efectuar esta operação será necessário utilizar a tabela Sumario_Temporario. Apenas
será necessário remover todos os registos com o atributo “Telefone” igual ao valor dado.
• Verificar se existe algum modelo de fraude com “Num_chamadas_efectuadas”
maior que 200, “Num_chamadas_fds” maior que 160 e “Num_chamas_noite”
maior que 130.
Anexos
191
Para efectuar esta operação é necessário utilizar a tabela Assinatura_Fraude. Apenas será
necessário efectuar uma pesquisa com as restrições escolhidas, se o resultado for
diferente de vazio então o modelo de fraude existe.
• Listar todas as assinaturas que têm casos suspeitos com o atributo
“Valor_alarme” > 0.8.
Para efectuar esta operação será necessário utilizar a tabela Assinatura fazendo uma
junção com a tabela Caso_Suspeito através do atributo “id_assinatura”, que irá ser chave
estrangeira na tabela Caso_Suspeito e chave primária na tabela Assinatura. Depois de
filtrar todos os casos suspeitos com o valor do atributo “Valor_alarme” maior que 0.8, faz-
se a junção em cima descrita e obtém-se as assinaturas correspondentes.
• Listar todas as asssinaturas de uma determinada classe.
Para efectuar esta operação será necessário utilizar a tabela Assinatura_Classe fazendo
uma junção com a tabela Assinatura através do atriuto “id_assinatura_classe”, que irá ser
chave estrangeira na tabela Assinaura e chave primária na tabela Assinatura_Classe.
Depois basta fltrar o resultado pelo classe pretendida.
• Listar todos os sumários temporários associados a um determinado caso
suspeito.
Para efectuar esta operação será necessário utilizar a tabela Caso_Suspeito fazendo uma
junção com a tabela Sumario_Temporario através do atriuto “id_caso_suspeito”, que irá
ser chave estrangeira na tabela Sumario_Temporario e chave primária na tabela
Caso_Suspeito. Depois basta fltrar o resultado pretendido.
• Listar os valores de uma assinatura de fraude associada a um determinado caso
suspeito.
Para efectuar esta operação será necessário utilizar a tabela Assinatura_Fraude fazendo
uma junção com a tabela Caso_Suspeito através do atriuto “id_assinatura_fraude”, que irá
ser chave estrangeira na tabela Caso_Suspeito e chave primária na tabela
Assinatura_Fraude. Depois basta fltrar o resultado pelo caso suspeito pretendido.
Anexos
192
Transacções do Sistema
• Actualização das assinaturas.
Para efectuar esta operação é necessário copiar os registos da partição correcta das
tabelas Loading_Assinaturas_Voz e Loading_Assinaturas_SMS para as tabelas
Pump_Assinaturas_Voz e Pump_Assinaturas_SMS respectivamente. Depois dos sumários
serem calculados as assinaturas poderão ser actualizadas na tabela Assinatura caso não
sejam suspeitas de fraude, ou os sumários podem ser directamente armazenados na
tabela Sumário_Temporário caso a assinatura tenha casos suspeitos por resolver, ou seja,
atributo “Estado” com valor 0. Os sumários também são comparados com os modelos de
fraude existentes na tabela Assinatura_Fraude. Se existirem casos suspeitos estes são
registados na tabela Caso_Suspeito com a valor de chave estrangeira (id_assinatura) da
assinatura correspondente. Se não existir nenhuma assinatura associada, os sumários são
comparados com as classes de assinatura existentes na tabela Assinatura_Classe e a mais
semelhante passa a ser o valor do sumário em questão.
Verificar as Restrições de Integridade
Atributos obrigatoriamente com valor
Alguns atributos não podem conter o valor nulo. Esta restrição está definida na secção da
modelação do modelo conceptual, onde se discute as restrições de cada atributo.
Restrições dos domínios dos Atributos
Alguns atributos só podem ter alguns valores pré-definidos. Definimos esta restrição na secção da
modelação do modelo conceptual, onde se discute as restrições de cada atributo.
Multiplicidade
Anexos
193
Os relacionamentos têm a si associados esta informação que diz quantos tuplos de uma tabela
estão ligados a cada um dos tuplos da outra. Esta restrição está definida na secção da modelação
do modelo conceptual, onde se discute as restrições aplicáveis a relacionamentos.
Integridade de Entidade
A chave primária de uma entidade não pode ser nula. Esta restrição também foi definida na secção
da modelação do modelo conceptual.
Integridade Referencial
A integridade referencial obriga a que os atributos de uma determinada tabela que sejam usados
como chave estrangeira proveniente de uma outra tabela, obriga a que o valor introduzido neste
atributo em cada registo exista na outra tabela.
Caso_Suspeito - A chave estrangeira id_assinatura na tabela Caso_Suspeito não poderá conter o
valor nulo. Em qualquer altura, todos os casos suspeitos terão de ter uma assinatura associada. O
mesmo não se verifica para a chave estrangeira Id_assinatura_fraude. Nesta situação o caso
suspeito pode ser relativo a uma distancia entre uma assinatura e o respectivo sumario, logo não
existe uma chave estrangeira proveniente da tabela Assinatura_Fraude.
Assinatura – A única chave estrangeira (Id_Assinatura_Classe) existente nesta tabela pode conter
o valor nulo. Numa primeira fase de inicialização das assinaturas, estas ainda não têm qualquer
classe de assinatura associada. Podem surgir casos de fraude em que uma assinatura deixa de
pertencer a determinada classe e consequentemente a chave estrangeira associada à tabela
Assinatura_Classe precise de ser eliminada.
Sumario_Temporário - A chave estrangeira Id_Caso_Suspeito na tabela Sumario_Temporario não
poderá conter o valor nulo. Em qualquer altura, todos os sumários temporários terão de ter um
caso suspeito associado.
Anexos
194
Restrições Gerais
A única restrição existente é o facto de quando se pretende criar ou eliminar um registo da tabela
Sumario_temporario é necessário verificar se o valor do atributo “Telefone” está associado a um
telefone de uma assinatura, ou seja, ao valor do atributo “Telefone” na tabela Assinatura.
Revisão do modelo de dados com os Utilizadores
Após várias reuniões com os utilizadores que vão utilizar o sistema e que fazem parte do grupo de
informática responsável pelo Centaur, onde vai ser integrado o protótipo, chegou-se a um acordo
em que o modelo lógico construído constitui uma representação válida para se passar à fase
seguinte de desenvolvimento.
Análise do crescimento futuro da Base de Dados
A base de dados desenvolvida, tal como foi explicado no arranque do projecto, tem como objectivo
a detecção de casos suspeitos de fraude. Visto que se trata de um protótipo, existe no entanto a
possibilidade de aumentar ou melhorar as suas funcionalidades num futuro próximo. Prevê-se que
a estrutura das tabelas de maior relevância, as tabelas Assinatura, Caso_Suspeito e
Sumario_Temporário, se mantenham inalteradas. É possível afirmar com alguma segurança que o
modelo lógico geral não terá problemas de maior importância.
As alterações possíveis poderão ser ao nível de alguns atributos ou a adição de algumas tabelas de
controlo. Poderá ser necessário guardar mais alguma informação do histórico de processamneto
diário ao adicionar alguma medida que seja relevante para análise. A informação anterior que
resume o perfil dos cartões e que identifica os casos suspeitos deverá manter-se sempre
inalterada.
Desde que o problema se mantenha sempre dentro dos objectivos gerais previstos, o crescimento
futuro da base de dados não representará qualquer preocupação de maior relevância.
Anexos
195
Diagrama Lógico
De seguida o diagrama lógico resultante do estudo efectuado até ao momento.
Anexos
196
Anexos
197
Figura 50 - Diagrama Lógico
