Julio del 2013

Facultad de Ciencias Empresariales.

Departamento de Sistemas de
Información.

Profesor Guía Alumno

Clemente Rubio Manzano. Esteban Rivera Rodríguez.

1
 Sistema de Detección y Prevención
de Fraudes en Cajeros Automáticos
usando una Red Neuronal Artificial

Proyecto de Titulación presentado bajo los estándares

establecidos para obtener el Título de Ingeniero de Ejecución
en Computación e Informática

2
 Agradecimientos
En primera instancia quisiera agradecer a mi Familia y Amigos que tuvieron que lidiar con mi
persona y quienes aportaron indirectamente en este proceso, sin algunos de ellos la
realización de este proyecto hubiera sido muy complicado.

También quisiera agradecer a mi Profesor guía Clemente Rubio Manzano, quien tuvo la buena
disposición de aceptar ser el guía de este proceso.

Agradecer de igual manera a Eugenio Contreras del Instituto de Ciencias Tecnológicas por su
orientación en localización de archivos y a Daniel Rivera por la ayuda en soporte técnico
durante la etapa final del proyecto tesis y su buena disposición en general hacia mi persona,

Mis agradecimientos también a la Institución InnvaBiobio que financió el desarrollo y ejecución

del proyecto de tesis.

Finalmente pero no menos importante quiera agradecer a la incubadora de negocios CREando

UBB, especialmente a Gerardo Gonzáles quien me ha ayudado a postular a diversos fondos
con la realización de este proyecto.

A todos ellos simplemente gracias.

Esteban Rivera Rodríguez

3
 RESUMEN

Este proyecto se presenta para dar conformidad a los requisitos exigidos por la Universidad
del Bío-Bío en el proceso de titulación de la carrera de Ingeniería de Ejecución en

Computación e Informática, el proyecto busca bajar el índice de fraudes financieros a nivel

nacional desarrollando un prototipo de sistema de detección y prevención de fraudes para

ser implementado en cajeros automáticos, dicho sistema permite evaluar una transacción

en tiempo real en base al comportamiento histórico de cada usuario, la prevención del

fraude está dada por la integración de un dispositivo móvil al proceso de transacción de

giro, a través de una aplicación desarrollada bajo la plataforma de Android, con dicha
aplicación el usuario puede confirmar o rechazar una transacción que escape de lo habitual.
La documentación describe los principales tipos de fraudes, las técnicas de detección, el

ambiente de ingeniería de desarrollo y tópicos correspondientes a la ingeniería del

Software.
Palabras Claves: Análisis de transacciones, Fraude en Cajero, Patrones de Conducta

4
 ABSTRACT

This project is presented to provide pursuant to the requirements of the University of the
Bío-Bío in the process of titling Execution Engineering degree in Computer and Information,
the project seeks to lower the rate of financial fraud nationwide developing a prototype
system of fraud detection and prevention to be implemented at ATMs, the system allows to
evaluate a transaction in real time based on historical behavior of each user, fraud
prevention is given by the integration of a mobile device to process transaction rotation
through an application developed on Android platform, with the application the user can
confirm or reject a transaction exhaust than usual.
The documentation describes the main types of fraud detection techniques, environment
and development engineering topics relevant to software engineering.

Keywords: Análisis de transacciones, Patrones de conducta, fraude en cajero automático

5
 Índice General

RESUMEN .......................................................................................................................................................... 4
ABSTRACT .......................................................................................................................................................... 5
1 INTRODUCCION ........................................................................................................................................ 14
1.1 INTRODUCCIÓN ......................................................................................................................................... 14
1.2 MOTIVACIÓN ............................................................................................................................................ 15
2 DEFINICION DEL PROYECTO..................................................................................................................... 17
2.1 SITUACIÓN ACTUAL .................................................................................................................................... 17
2.2 OBJETIVOS DEL PROYECTO........................................................................................................................... 19
2.3 DEFINICIONES, SIGLAS Y ABREVIACIONES....................................................................................................... 20
2.4 PRINCIPALES FUNCIONES DE LA APLICACIÓN SW ............................................................................................ 24
2.5 ESTIMACIONES .......................................................................................................................................... 25
2.6 IDENTIFICACIÓN DE RIESGOS ........................................................................................................................ 25
2.6.1 RIESGOS ASOCIADOS AL DESARROLLO DEL PROYECTO.................................................................................. 25
2.6.2 RIESGOS ASOCIADOS AL SOFTWARE .......................................................................................................... 26
2.7 PLANIFICACIÓN TEMPORAL.......................................................................................................................... 27
2.8 PLAN DE TRABAJO ...................................................................................................................................... 27
2.9 AMBIENTE DE INGENIERÍA DE SW ................................................................................................................ 28
3 ESTADO DEL ARTE .................................................................................................................................... 30
3.1 TIPOLOGÍA DE FRAUDES EN TARJETAS DE CRÉDITOS Y DÉBITOS ......................................................................... 30
FRAUDE DE TARJETA-NO-PRESENTE (CNP): ..................................................................................................... 30
FRAUDE CON TARJETAS DE FALSIFICACIONES:................................................................................................... 30
FRAUDE CON TARJETAS PÉRDIDAS Y / O ROBADAS: ........................................................................................... 31
TARJETA DE IDENTIFICACIÓN DEL ROBO: .......................................................................................................... 31
CORREO NO RECIBO DE TARJETA DE FRAUDE: ................................................................................................... 31
3.2 DETECCIÓN DE FRAUDES ............................................................................................................................. 31
3.3 ESPECIFICACIÓN DE LAS TÉCNICAS DE DETECCIÓN DE FRAUDES......................................................................... 34
3.3.1 TÉCNICAS DESCRIPTIVAS DE DETECCIÓN DE FRAUDES................................................................................... 34
3.3.2 TÉCNICAS PREDICTIVAS DE DETECCIÓN DE FRAUDES .................................................................................... 36
3.4 SOFTWARE PARA DETECTAR FRAUDES FINANCIEROS ....................................................................................... 41
4 DEFINICION Y DESARROLLO DEL MODELO DE DETECCIÓN Y PREVENCIÓN DE FRAUDES................... 42
4.1 TÉCNICA DEL MODELO DE DETECCIÓN DE FRAUDE ......................................................................................... 42
4.1.1 EL PROCESAMIENTO DE LOS DATOS .......................................................................................................... 43
4.2 PERFIL DE COMPORTAMIENTO Y RECONOCIMIENTO DE PATRONES DE COMPORTAMIENTO ................................ 45
4.2.1 PERFIL DE COMPORTAMIENTO ................................................................................................................. 45
4.2.2 RECONOCIMIENTO DE PATRONES ............................................................................................................. 46
4.2.3 ENTORNO DE DESARROLLO ...................................................................................................................... 49
4.3 TÉCNICA DEL MODELO DE PREVENCIÓN DE FRAUDE ....................................................................................... 54
4.3.1 INTEGRACIÓN DEL DISPOSITIVO MÓVIL EN LA PREVENCIÓN DE FRAUDES ....................................................... 55
4.3.2 EL PROCESAMIENTO DE LOS DATOS .......................................................................................................... 55
4.3.3 SINCRONIZACIÓN DE DATOS..................................................................................................................... 55
4.3.4 ENTORNO DE DESARROLLO ...................................................................................................................... 56

6
5 ESPECIFICACIÓN DE REQUERIMIENTOS DE SOFTWARE ........................................................................ 59
5.1 ALCANCES ................................................................................................................................................. 59
5.2 OBJETIVO DEL SOFTWARE............................................................................................................................ 60
5.3 DESCRIPCIÓN GLOBAL DEL PRODUCTO.......................................................................................................... 60
5.3.1 INTERFAZ DE USUARIO ............................................................................................................................. 60
5.3.2 INTERFAZ DE HARDWARE ........................................................................................................................ 60
5.3.3 INTERFAZ SOFTWARE .............................................................................................................................. 60
5.3.4 INTERFACES DE COMUNICACIÓN ............................................................................................................... 61
5.4 REQUERIMIENTOS ESPECÍFICOS DEL SISTEMA EVALUADOR DE TRANSACCIÓN..................................................... 61
5.4.1 REQUERIMIENTOS FUNCIONALES DEL SISTEMA........................................................................................... 61
5.4.2 REQUERIMIENTOS NO FUNCIONALES DEL SISTEMA ..................................................................................... 61
5.4.3 INTERFACES EXTERNAS DE ENTRADA .......................................................................................................... 61
5.4.4 INTERFACES EXTERNAS DE SALIDA ............................................................................................................. 62
5.5 REQUERIMIENTOS ESPECÍFICOS DE APLICACIÓN DE CONFIRMACIÓN DE TRANSACCIÓN........................................ 62
5.5.1 REQUERIMIENTOS FUNCIONALES DEL SISTEMA........................................................................................... 62
5.5.2 REQUERIMIENTOS NO FUNCIONALES DEL SISTEMA ..................................................................................... 63
5.5.3 INTERFACES EXTERNAS DE ENTRADA .......................................................................................................... 63
5.5.4 INTERFACES EXTERNAS DE SALIDA ............................................................................................................. 63
5.6 ATRIBUTOS DEL PRODUCTO ......................................................................................................................... 64
5.6.1 FUNCIONALIDAD .................................................................................................................................... 64
5.6.2 FIABILIDAD............................................................................................................................................. 64
5.6.3 USABILIDAD ........................................................................................................................................... 65
5.6.4 EFICIENCIA............................................................................................................................................. 65
5.6.5 PORTABILIDAD ....................................................................................................................................... 65
6 FACTIBILIDAD ............................................................................................................................................ 67
6.1 FACTIBILIDAD OPERATIVA ........................................................................................................................... 67
6.2 FACTIBILIDAD TÉCNICA................................................................................................................................ 67
6.2.1 EQUIPOS ............................................................................................................................................... 67
6.2.2 DISPOSITIVOS......................................................................................................................................... 68
6.2.3 SOFTWARE ............................................................................................................................................ 68
6.3 FACTIBILIDAD ECONÓMICA.......................................................................................................................... 69
6.4 CONCLUSIÓN DE FACTIBILIDAD .................................................................................................................... 69
7 ANÁLISIS .................................................................................................................................................... 70
7.1 DIAGRAMA DE CASOS DE USO ...................................................................................................................... 70
7.1.1 ACTORES ............................................................................................................................................... 70
7.1.2 CASOS DE USO Y DESCRIPCIÓN ................................................................................................................. 70
7.1.3 ESPECIFICACIÓN DE LOS CASOS DE USO ..................................................................................................... 71
7.2 MODELAMIENTO DE DATOS ........................................................................................................................ 83
7.2.1 DIAGRAMAS DE CLASES: SISTEMA EVALUADOR DE TRANSACCIÓN .................................................................. 83
7.2.2 DIAGRAMA DE CLASES: APLICACIÓN DE CONFIRMACIÓN .............................................................................. 85
7.2.3 DIAGRAMA DE CLASES: SERVICIO WEB ...................................................................................................... 90
7.2.4 MODELO ENTIDAD RELACIÓN SQLITE: APLICACIÓN DE CONFIRMACIÓN. ....................................................... 90
7.2.5 MODELO ENTIDAD RELACIÓN: SERVICIO WEB ............................................................................................ 90
7.3 DIAGRAMA DE PAQUETES............................................................................................................................ 91
8 DISEÑO ...................................................................................................................................................... 93

7
8.1 DISEÑO DE ARQUITECTURA FUNCIONAL ........................................................................................................ 93
8.1.1 ARQUITECTURA FUNCIONAL DEL SISTEMA GLOBAL ...................................................................................... 93
8.1.2 ARQUITECTURA FUNCIONAL DE LA APLICACIÓN DE CONFIRMACIÓN DE TRANSACCIÓN ...................................... 93
8.1.3 ARQUITECTURA FUNCIONAL DEL SISTEMA EVALUADOR DE TRANSACCIÓN ....................................................... 94
8.2 DISEÑO INTERFAZ Y NAVEGACIÓN................................................................................................................. 94
8.2.1 DISEÑO DE INTERFAZ DE USUARIO DEL SISTEMA EVALUADOR DE TRANSACCIÓN .............................................. 94
8.2.2 DISEÑO DE INTERFAZ DE USUARIO DE LA APLICACIÓN DE CONFIRMACIÓN DE TRANSACCIÓN.............................. 96
8.2.3 MENÚ DE NAVEGACIÓN APLICACIÓN DE CONFIRMACIÓN ............................................................................ 99
8.3 DISEÑO LOGO SISTEMA ............................................................................................................................ 100
9 PRUEBAS ................................................................................................................................................. 101
9.1 ELEMENTOS DE PRUEBA ............................................................................................................................ 101
9.2 ESPECIFICACIÓN DE LAS PRUEBAS ............................................................................................................... 101
9.3 RESPONSABLES DE LAS PRUEBAS ................................................................................................................ 101
9.4 CALENDARIO DE PRUEBAS ......................................................................................................................... 102
9.5 DETALLE DE LAS PRUEBAS.......................................................................................................................... 102
9.5.1 PRUEBA DE FUNCIONALIDAD MÓDULOS................................................................................................... 102
9.5.2 PRUEBA DE RENDIMIENTO:.................................................................................................................... 105
9.6 CONCLUSIONES DE PRUEBA....................................................................................................................... 109
10 CONCLUSIONES .................................................................................................................................... 110
11 BIBLIOGRAFÍA ....................................................................................................................................... 111
12 ANEXO A: PLANIFICACION INICIAL DEL PROYECTO............................................................................ 113
12.1 PROGRAMA DE ACTIVIDADES................................................................................................................... 113
12.2 PLANIFICACIÓN...................................................................................................................................... 115
12.3 ESTIMACIÓN INICIAL DE ESFUERZO REQUERIDO .......................................................................................... 116
12.3.1 PUNTO CASO DE USO COMO METODOLOGÍA DE ESTIMACIÓN INICIAL DE ESFUERZO ..................................... 116
12.4 ESTIMACIÓN DEL TAMAÑO FINAL DEL SOFTWARE ...................................................................................... 121
12.4.1 PUNTO DE FUNCIÓN COMO METODOLOGÍA DE ESTIMACIÓN DE TAMAÑO .................................................. 121
12.4.2 CONTABILIZACIÓN REAL DEL SOFTWARE EN LÍNEAS DE CÓDIGOS .............................................................. 124
12.5 ESTIMACIÓN DEL BENEFICIO DEL SISTEMA ................................................................................................. 127
13 ANEXO B: RED DE CAJEROS AUTOMÁTICOS ...................................................................................... 130
13.1 ¿QUÉ ES UN CAJERO AUTOMÁTICO? ....................................................................................................... 130
13.2 ¿CÓMO FUNCIONA? .............................................................................................................................. 130
13.3 COMPONENTES DE UN ATM................................................................................................................... 131
13.4 HISTORIA.............................................................................................................................................. 132
13.5 CARACTERÍSTICAS TÉCNICAS ESTÁNDAR .................................................................................................... 132
13.6 RED DE ATM EN CHILE........................................................................................................................... 133
13.6.1 RED BANCARIA INTERCONECTADA (RBI) ............................................................................................... 133
13.6.2 RED DE SERVICIOS DE FINANCIEROS (RSF)............................................................................................. 134
13.6.3 BANCOS ASOCIADOS A LA SUPERINTENDENCIA DE BANCOS E INSTITUCIONES FINANCIERAS EN CHILE ............ 134
14 ANEXO C: MANUAL DE USUARIO........................................................................................................ 137
14.1 ¿QUÉ ES ANALISYSTEM? ........................................................................................................................ 137
14.2 CONOCIENDO LA INTERFAZ GRÁFICA DE USUARIO....................................................................................... 137
14.3 REQUERIMIENTOS BÁSICOS DEL DISPOSITIVO MÓVIL ................................................................................... 139

8
14.4 PREGUNTAS FRECUENTES ....................................................................................................................... 139
14.4.1 ¿CÓMO ACTIVAR LA PROTECCIÓN? ....................................................................................................... 139
14.4.2 ¿CÓMO CONFIGURAR MI CUENTA? ...................................................................................................... 139
14.4.3 ¿QUÉ ES EL NIVEL DE PROTECCIÓN? ...................................................................................................... 140
14.4.4 ¿PUEDO RECHAZAR UNA TRANSACCIÓN QUE NO ESTÉ REALIZANDO YO? .................................................... 140
14.4.5 ¿TENGO UNA CUENTA CORRIENTE Y ADEMÁS EN MI FAMILIA POSEEN UNA CUENTA ADICIONAL A LA MÍA, PUEDEN
OBTENER LA SEGURIDAD DEL SISTEMA? ................................................................................................................. 140
14.4.6 ¿NECESITO ESTAR SIEMPRE CONECTADO A INTERNET? ............................................................................ 140
15 ANEXO D: REDES NEURONALES ARTIFICIALES ................................................................................... 141
15.1 REDES NEURONALES ARTIFICIALES ........................................................................................................... 141
15.1.1 REDES NEURONALES ARTIFICIALES CONCEPTO Y EVOLUCIÓN .................................................................... 141
15.1.2 COMPONENTES Y CARACTERÍSTICAS DE UNA RNA .................................................................................. 141
15.1.3 TOPOLOGÍA ....................................................................................................................................... 142
15.1.4 APRENDIZAJE ..................................................................................................................................... 142
15.1.5 TIPO DE ENTRADA .............................................................................................................................. 143
15.1.6 APLICACIONES ................................................................................................................................... 143

9
 Índice Tablas

Tabla 1: Riesgos de Proyecto……………………………………………………………………………………………………... 21

Tabla 2: Riesgos de Software……………………………………………………………………………………………………... 21
Tabla 3: Resumen de técnicas de minerías de datos para la detección
De fraudes ………………………………………………………………………………………………………………………………… 34
Tabla 4: Representación de la Arquitectura de la Red.………………………………………………………………. 38
Tabla 5: Representación de las entradas de la red…………………………………………………………………….. 39
Tabla 6: Requerimientos funcionales del Sistema Evaluador de Transacción……………………………. 50
Tabla 7: Requerimientos No Funcionales del Sistema Evaluador de
Transacción………………………………………………………………………………………………………………………………. 50
Tabla 8: Interfaces externas de entrada Sistema Evaluador de Transacción ……………………………. 51
Tabla 9: Interfaces externas de salida Sistema Evaluador de Transacción………………………………… 51
Tabla 10: Requerimientos Funcionales de la Aplicación de Confirmación……………………………….. 51
Tabla 11: Requerimientos No Funcionales de la Aplicación de Confirmación………………………….. 51
Tabla 12: Interfaces externas de entradas de Aplicación de Confirmación………………………………. 52
Tabla 13: Interfaces externas de salida de Aplicación de Confirmación ………………………………….. 52
Tabla 14: Prueba de rendimiento día 1 sistema evaluador de transacciones………..…………………… 94
Tabla 15: Prueba de rendimiento día 2 sistema evaluador de transacciones………..…………………… 94
Tabla 16: Prueba de rendimiento día 3 sistema evaluador de transacciones………..………………….. 95
Tabla 17: Prueba de rendimiento día 1 aplicación de confirmación de transacción…………………… 95
Tabla 18: Prueba de rendimiento día 2 aplicación de confirmación de transacción………………….. 96
Tabla 19: Prueba de rendimiento día 3 aplicación de confirmación de transacción………………….. 96

10
 Índice Figuras

Figura 1: Número de ATM en Chile………………………………………………………………………………………….... 14

Figura 2: Números de Tarjetas de Crédito y débito en Chile ……………………………………………………… 15
Figura 3 Taxonomía: Técnicas de Minería de datos de detección de fraudes …………………………….. 29
Figura 4: Ejemplo de un Árbol de decisión ……………………………………………………………………………….. 32
Figura 5: Ejemplo de una Red Bayesiana ………………………………………………………………………………….. 33
Figura 6: Ejemplo de separador lineal de SVM …………………………………………………………………………. 34
Figura 7: Esquema Conceptual Técnica de Detección de Fraude ………………………………………………. 37
Figura 8: Estándar de transacción creado por el Comité Europeo de Estándares
Bancarios (ECSB) ………………………………………………………………………………………………………………………. 37
Figura 9: Formato de datos del usuario ……………………………………………………………………………………. 38
Figura 10: Formato de datos del Histórico del usuario.……………………………………………………………… 38
Figura 11: Cadena de datos del sistema …………………………………………………………………………………… 39
Figura 12: Imagen del Entorno de desarrollo Eclipse ………………………………………………………………… 43
Figura 13: Imagen Entorno de desarrollo Integrado MATLAB …………………………………………………… 44
Figura 14: Imagen Neural Network/Data Manager (nntool) ……………………………………………………… 46
Figura 15: Imagen del cuadro de diálogo Deploytool ………………………………………………………………… 47
Figura 16: Imagen de ventana Build Java Package……………………………………………………………………… 47
Figura 17: Esquema Conceptual Sincronización de Datos…………………………………………………………… 50
Figura 18: Imagen de la instalación del Plugins ADT…………………………………………………………………… 51
Figura 19: Imagen del Android SDK Manager ……………………………………………………………………………. 52
Figura 20: Representación conceptual de los alcances de sistema……………………………………………. 53
Figura 21: Arquitectura de referencia en la que se basa el sistema……………………………………………. 54
Figura 22: Diagrama de casos de usos……………………………………………………………………………………….. 61
Figura 23: Diagrama de Clases Sistema Evaluador paquete principal…………………………………………. 73
Figura 24: Diagrama de Clases Sistema Evaluador paquete entrada y salida de datos………………… 73
Figura 25: Diagrama de Clases Sistema Evaluador paquete evaluación……………………………………… 73
Figura 26: Diagrama de Clases Sistema Evaluador paquete comunicación…………………………………. 74
Figura 27: Diagrama de Clases Aplicación de Confirmación paquete principal…………………………… 75
Figura 28: Diagrama de Clases Aplicación de Confirmación paquete comunicación………………….. 75
Figura 29: Diagrama de Clases Aplicación de Confirmación paquete base de datos…………………… 76

11
Figura 30: Diagrama de Clases Aplicación de Confirmación paquete configuración usuario………. 77
Figura 31: Diagrama de Clases Aplicación de Confirmación paquete menú lista………………………… 78
Figura 32: Diagrama de Clases Aplicación de Confirmación paquete seguridad…………………………. 78
Figura 33: Diagrama de Clases Servicio Web……………………………………………………………………………… 79
Figura 34: Modelo Entidad Relación Aplicación de Confirmación……………………………………………… 79
Figura 35: Modelo Entidad Relación Aplicación de Confirmación……………………………………………… 79
Figura 36: Diagrama de paquetes Sistema Evaluador de Transacción………………………………………… 80
Figura 37: Diagrama de paquetes Aplicación de Confirmación………………………………………………….. 80
Figura 38: Diagrama de paquetes Sistema Global……………………………………………………………………… 80
Figura 39: Arquitectura funcional del Sistema Global………………………………………………………………… 84
Figura 40: Arquitectura funcional de la Aplicación de Confirmación………………………………………….. 84
Figura 41: Arquitectura funcional del Sistema Evaluador de Transacción ………………………………….. 85
Figura 42: Diseño de interfaz usuario sistema de Evaluación de Transacción- Análisis de
Transacción……………………………………………………………………………………………………………………………….. 85
Figura 43: Diseño de interfaz usuario sistema de evaluación de Transacción- Datos Clientes……. 86
Figura 44: Diseño de interfaz usuario Sistema de Evaluación de Transacción- Historial Cliente …. 86
Figura 45: Diseño de Interfaz Usuario Sistema de Evaluación de Transacción- Resultado
Análisis………………………………………………………………………………………………………………………………………. 87
Figura 46: Diseño de Interfaz Usuario Aplicación de Confirmación de Transacción-Menú
Principal …………………………………………………………………………………………………………………………………… 87
Figura 47: Diseño de Interfaz Usuario Aplicación de Confirmación de Transacción-Configurar
cuenta ……………………………………………………………………………………………………………………………………… 88
Figura 48: Diseño de Interfaz Usuario Aplicación de Confirmación de Transacción
Activar/Desactivar Aplicación ……………………………………………………………………………………………….. 89
Figura 49: Diseño de Interfaz Usuario Aplicación de Confirmación de Transacción-Mensaje de
Confirmación ………………………………………………………………………………………………………………………… 90
Figura 50: Diseño de Interfaz Usuario Aplicación de Confirmación de Transacción-Patrón
De Seguridad…………………………………………………………………………………………………………………………… 90
Figura 51: Menú de Navegación de Aplicación de Confirmación de Transacción ……………………… 91
Figura 52: Diseño logo oficial ……………………………………………………………………………………………………. 91
Figura 53: Diseño logo aplicación ……………………………………………………………………………………………… 91
Figura 54: Diseño logo 2 aplicación…………………………………………………………………………………………… 91

12
Figura 55: Administrador de tareas equipo desarrollador………………………………………………………….. 95
Figura 56: Simulador Dispositivo Android…………………………………………………………………………………. 96

13
1 INTRODUCCION

1.1 Introducción

El presente informe es el resultado de la actividad de titulación correspondiente al

desarrollo del proyecto de Tesis, que es requisito para obtener el título de Ingeniero

en Ejecución en Computación e Informática y que tiene como objetivo documentar

todo el proceso de investigación, análisis de software, diseño de software, entorno

de desarrollo y pruebas de sistema, todas estas etapas descritas bajo tópicos
correspondientes a la Ingeniería del Software. El informe está estructurado y divido
en 11 capítulos y 4 anexos, en el Anexo A se encuentra la planificación, estimación
de tamaño inicial y real del software utilizando dos metodologías diferentes y la
estimación del beneficio que se obtendría al implementar este sistema, en el Anexo
B esta la documentación recopilada acerca de la red de cajero que opera en Chile,
conceptos y definiciones básicas acerca del cajero como tal y las instituciones

financieras que se regulan por la Superintendencia de bancos, el Anexo C es una

manual instructivo básico para el usuario de la aplicación de confirmación, en el Anexo
D también es el resultado de una breve investigación acerca de las redes neuronales
artificiales que se utilizó en el sistema.

El capítulo 2 define la situación actual, objetivo general y objetivos específicos del

proyecto, estimación del proyecto, identificación de riesgos, planificación del proyecto

y el ambiente de ingeniería que se llevará a cabo, todo esto en marco de la definición

del proyecto como tal. Dentro del capítulo 3 se definen y se nombran el estado del
arte en tipologías de fraudes en el rubro financiero, además se definen los métodos
de detección de fraudes que existen en el mercado, es un resumen de una breve

investigación acerca de los distintos modos que operan los delincuentes para generar
fraudes en las tarjetas de créditos y débitos, y del como los sistemas actuales

detectan estos fraudes. El capítulo 4 es una definición completa al modelo de

detección de fraudes que se diseñó en el sistema y una definición al modelo de

prevención de fraudes, describe además la arquitectura en su conjunto y menciona el

14
 entorno de desarrollo, explicando brevemente como se utilizaron algunos programas
para el desarrollo del sistema. El capítulo 5 hace referencia a las especificaciones de
requerimiento del software se detalla en primera instancia los alcances del proyecto,

los requerimiento de sistema funcionales y no funcionales, los datos de entrada y los

datos de salida del sistema y finalmente los atributos del sistema como producto,. El

capítulo 6 es un estudio de factibilidad operativa, técnica y económica del proyecto.

El capítulo 7 es un análisis del proyecto se define los casos de usos, modelo de datos
del sistema y diagramas de clases divido en paquetes.

El capítulo 8 describe el diseño, tanto funcional o arquitectónico como el diseño de

interfaz de usuario del sistema. El capítulo 9 documenta las pruebas del sistema y los
resultados obtenidos para plasmarlos en el capítulo 10, capítulo dedicado a las
conclusiones académicas y personales, finalmente en el capítulo 11 se nombra la
bibliografía que se utilizó a lo largo del desarrollo del sistema.

1.2 Motivación

Recuerdo en una de las primeras clases de universidad un profesor nos dijo: “Las

oportunidades están ahí, pero no todos las ven, algunos solo ven los problemas,
ustedes como futuros ingenieros deben ser capaces de poder verlas”, y así fue, bastó
con encender el televisor para determinar cuál sería mi tema de tesis, si bien es una
problemática a nivel nacional, pensé en que algo se podía hacer, así fue como

empecé a investigar de a poco y unificando todos los conocimientos que adquirí a lo

largo de mi carrera, llegue a la conclusión de que podía hacer algo más que reclamar

más seguridad en las tarjetas de crédito y débito, podía diseñar y construir ¿Por qué
no? Un prototipo para solucionar o frenar esta problemática. En un principio me
pareció algo ambicioso y un poco arriesgado pero aun así decidí que eso es lo que

quería e hice la propuesta formal de proyecto de tesis, pues siempre he pensado que
asumir desafíos es avanzar como profesional y crecer como persona.
Esa frase que dijo mi profesor y las ganas de desarrollar dicho sistema, aplicando los

tópicos de asignaturas que me más me agradaron, de aquellos tópicos que había

15
quedado con las ganas de aprender más, y también por esos tópicos que me costó
aprender y ahora aplicarlo con toda normalidad y por su puesto la de asumir este
desafío, esa fue mi mayor motivación.

16
2 DEFINICION DEL PROYECTO

2.1 Situación actual

En la actualidad vivimos una de las revoluciones más importantes que han afectado
al consumidor financiero en los últimos tiempos en nuestro país,
hablo del uso de tarjetas de crédito y débito bancarias, que ha venido a desplazar
casi completamente al pago al contado y con cheque.
Para dimensionar el gran avance que ha tenido esta verdadera revolución en los
medios de pago, podemos señalar en el año 2002, el número de transacciones que
se realizó con estas tarjetas fue de 210.929.793, mientras que en el año 2012 se
realizaron 472.459.122 transacciones, hablamos de un incremento del 230,5%
durante ese periodo, según así lo informo la Superintendencia de Bancos e
Instituciones Financieras (Fuente: Diario Estrategia, 26 de Febrero de 2013).
Claro está que la tendencia del uso de tarjetas de créditos y débitos es al alza, y en
consecuencia a esto el número de cajeros automáticos en Chile también ha
aumentado cerca de un 151,5% en el mismo periodo (2002-2012) alrededor de 9238
cajeros distribuidos a lo largo del país. Este incremento sin duda también forma parte
de esta revolución financiera que es aceptada por la población principalmente por las
ventajas que ofrece en términos de eficiencia al transferir dinero y a los beneficios
que trae en cuanto al ahorro de tiempo.
Por otra parte este sistema de red de cajeros automáticos no está libre de
inconveniente y así lo demuestra el alto índice de fraudes financieros detectados en
este último período, Según el OS-9 de carabineros se han reportado en el país 18.927
denuncias de clonación de tarjetas entre el año 2010 y 2012, cabe destacar que solo
el año pasado(2012) se hicieron más de 8.000 denuncias, son cifras que realmente
preocupan a nivel nacional, además algo que también resulta ser alarmante es la
relación entre el monto máximo permitido en una transacción y el sueldo mínimo pues
son montos muy similares, suponiendo un contexto de un trabajador cuyo sueldo es
el mínimo y sea depositado en una tarjeta de débito, puede fácilmente perder un mes
de esfuerzo en solo una transacción fraudulenta.
Existen muchos factores que influyen en esta alza de índice, pero sin duda la
principal razón es la clonación de tarjetas debido a la simplicidad que resulta clonar
tarjetas de banda magnética dado el alto grado de sofisticación que tienen los
delincuentes, (conocimiento y manipulación de la tecnología), en consecuencia a

17
esto, bandas internacionales especializadas en la clonación de tarjeta han operado
en Chile trayendo consigo olas de fraudes y como principal actor involucrado; los
cajeros automáticos.
En resumen, nos encontramos en un escenario en donde el dinero plástico es cada
vez más utilizado a la hora de realizar una transacción financiera principalmente por
sus ventajas y beneficios, en consecuencia a esto, antisociales buscan la
vulnerabilidad del sistema, utilizando la conocida técnica de clonación de tarjetas,
provocando en algunos casos quiebres en el actual sistema (como el último caso de
clonación de tarjetas registrado en Temuco), lo que significa aumentar la seguridad
en cajeros automáticos y estar a la vanguardia en tecnología de la información.

Figura 1: Número de ATM en Chile

18
 Figura 2: Números de Tarjetas de Crédito y débito en Chile expresadas en miles.

2.2 Objetivos del proyecto

Objetivo general:

 Analizar y diseñar un sistema que permita reconocer fraudes financieros en

transacciones de giro en cajeros automáticos para tarjetas de cuenta vista y

cuenta corriente, a través de cambios de comportamientos susceptible que
puedan catalogarse como fraudulento utilizando una Red Neuronal Artificial
para construir patrones de conducta por usuario en base a su histórico.

Además de Diseñar, construir y vincular una aplicación de dispositivo móvil

Android para confirmar una transacción que el sistema califique como posible
fraude (fuera del patrón de conducta).

Objetivos específicos:

 Identificar transacciones financieras de giro fraudulentas en tarjetas de

Créditos y Débito en cajeros automáticos.

 Diseñar y construir un modelo de Red Neuronal Artificial que evalúe patrones

de conducta por usuario.

19
  Diseñar y construir una aplicación de dispositivo móvil Android de
confirmación de transacción.
 Diseñar y construir un Análisis de sensibilidad de fraudes configurable por el

usuario.

2.3 Definiciones, Siglas y Abreviaciones

Arquitectura de referencia: Arquitectura genérica de un sistema, esta es una

arquitectura ideal que incluye todas las características que los sistemas podrían
incorporar.

Automated Teller Machine (ATM): Hace referencia al cajero automático.

Base de Datos (BD): Es un conjunto de datos pertenecientes a un mismo contexto y

almacenados sistemáticamente para su posterior uso.

Clonación de tarjeta: Es el acto de duplicar una tarjeta, es decir copiar el contenido

de la banda magnética y transferir esa información a un plástico vacío.

Clustering: Agrupamiento de datos.

CSS: Es una especificación desarrollada por el W3C (World Wide Web Consortium)
para permitir la separación de los contenidos de los documentos escritos en HTML,
XML, XHTML, SVG, o XUL de la presentación del documento con las hojas de estilo,
incluyendo elementos tales como los colores, fondos, márgenes, bordes, tipos de
letra.

DBMS: (Data Base Management System). Son las siglas en inglés para
los Sistemas de Gestión de Bases de Datos (SGBD).

DFD: Los diagramas de flujo de datos son un tipo de herramienta de modelado,

permiten modelar todo tipo de sistemas, concentrándose en las funciones que realiza,

20
y los datos de entrada y salida de esas funciones.

Error: En RNA es la diferencia entre el objetivo y el resultado.

HTML: Siglas de HyperText Markup Language (Lenguaje de Marcado de Hipertexto),

hace referencia al lenguaje de marcado predominante para la elaboración de páginas
web que se utiliza para describir y traducir la estructura y la información en forma de
texto.

HTTP: Hypertext Transfer Protocol o HTTP (en español protocolo de transferencia de

hipertexto) es el protocolo usado en cada transacción de la World Wide Web.

HTTPS: Hypertext Transfer Protocol Secure (ó HTTPS) es una combinación del

protocolo HTTP y protocolos criptográficos. Se emplea para lograr conexiones más
seguras en la WWW, generalmente para transacciones de pagos o cada vez que se
intercambie información sensible (por ejemplo, claves) en internet.

IEEE: Corresponde a las siglas de (Institute of Electrical and Electronics Engineers)

en español Instituto de Ingenieros Eléctricos y Electrónicos, una asociación técnico-
profesional mundial dedicada a la estandarización, entre otras cosas. Con cerca de
400.000 miembros y voluntarios en 160 países, es la mayor asociación internacional
sin ánimo de lucro formada por profesionales de las nuevas tecnologías,
como ingenieros eléctricos, ingenieros en electrónica, científicos de la computación,
ingenieros en informática, ingenieros en biomédica, ingenieros en telecomunicación e
ingenieros en Mecatrónica.

Input: En RNA Son los datos para ser presentados en una red neuronal artificial.

Interfaz: Especificación de los atributos y operaciones asociados con un componente

software. La interfaz es utilizada como el medio de tener acceso a la funcionalidad
del componente.

Interfaz de Programación de Aplicaciones (API): Generalmente especifica un

conjunto de operaciones, definida por un programa de aplicación que permite acceder

21
a la funcionalidad del programa. Esto significa que no sólo se puede acceder a esta
funcionalidad a través de la interfaz de usuario, si no que otros programas que pueden
utilizarla directamente.

Java: Es un lenguaje de programación orientado a objetos desarrollado por la Sun

Microsystems, Java fue proyectado con la finalidad de obtener un producto de
pequeñas dimensiones, simple y portátil sobre diferentes plataformas.

Mantenimiento: Proceso de hacer cambios en un sistema después de que esté en

funcionamiento.

MER: Modelo Entidad Relación es una herramienta para el modelado de datos que
permite representar las entidades relevantes de un sistema de información así como
sus interrelaciones y propiedades.

Middleware: Infraestructura software en un sistema distribuido, Ayuda a gestionar

las interacciones entre las entidades distribuidas en el sistema y las bases de datos
del mismo.

MR: Modelo Relacional es un modelo de datos basado en la lógica de predicados y

en la teoría de conjuntos. Es el modelo más utilizado en la actualidad para modelar
problemas reales y administrar datos dinámicamente.

Open Source: Código abierto en español, es el término con el que se conoce

al software distribuido y desarrollado libremente. El código abierto tiene un punto de
vista más orientado a los beneficios prácticos de poder acceder al código, que a las
cuestiones éticas y morales las cuales se destacan en el software libre.

Outlier: Detección de un objeto de comportamiento atípico.

Outputs: Salidas en RNA son las Respuestas de una red a sus entradas.

Patrón de comportamiento: Es la manera constante de proceder que tienen las

personas, en relación con su entorno o mundo de estímulos. El comportamiento

22
puede ser consciente o inconsciente, voluntario o involuntario, público o privado,
según las circunstancias que lo afecten.

PHP: Es un lenguaje de programación de uso general de script del lado del servidor
originalmente diseñado para el desarrollo web de contenido dinámico.

Red Neuronal Artificial: (RNA en inglés) Son un

paradigma de aprendizaje y procesamiento automático inspirado en la forma en que
funciona el sistema nervioso de los animales. Se trata de un sistema de interconexión
de neuronas en una red que colabora para producir un estímulo de salida.

Servidor: Dentro del contexto un servidor es un ordenador remoto que provee los
datos solicitados por parte de los navegadores de otras computadoras.

Sistema crítico: Sistema informático cuyo fallo de funcionamiento puede causar

importantes pérdidas.

Sistema de procesamiento de transacciones: Sistema que asegura que las

transacciones se procesan de tal forma que no se interfieren ente sí y de modo que
el fallo de una transacción individual no afecte a otras transacciones o a la integridad
de los datos del sistema.

SOAP (Simple Object Access Protocol): Es un protocolo estándar que definen

como dos objetos en diferentes procesos pueden comunicarse por medio de un
intercambio de datos XML.

Target: Objetivo en RNA son los datos que definen las salidas de la red que desee.

TCI/IP: Son las siglas de Protocolo de Control de Transmisión/Protocolo de Internet

(en inglés Transmission Control Protocol/Internet Protocol), un sistema de protocolos
que hacen posibles servicios Telnet, FTP, E-mail, y otros entre ordenadores que no
pertenecen a la misma red.

Transacción: Unidad de interacción con un sistema informático. Las transacciones

23
 son independientes y atómicas (no se pueden dividir es unidades más pequeñas) y
son una unidad fundamental de recuperación, consistencia y concurrencia.

Validación: La validación es un proceso más general. Se debe asegurar que el

software cumple las expectativas del cliente. Va más allá de comprobar si el sistema
está acorde con su especificación, para probar que el software hace lo que el usuario
espera a diferencia de lo que se ha especificado.

Verificación: El papel de la verificación comprende en comprobar el software, si está

de acuerdo con su especificación. Se comprueba que el sistema cumple los
requerimientos funcionales y no funcionales que se le han especificado.

XML (Extensible Markup Language): Es un lenguaje de marcas desarrollado por el

W3C. Deriva del lenguaje SGML y permite definir la gramática de lenguajes
específicos (de la misma manera que HTML) para estructurar documentos grandes,
hoy en día es aceptado por la comunidad debido a su simplicidad y compatibilidad
que ofrece entre sistemas para intercambiar información de manera fiable, segura y
fácil.

2.4 Principales funciones de la aplicación SW

 Sistema evaluador de transacción

 Limpiar Datos.
 Recoger Datos.
 Leer Datos.
 Evaluar Transacción.
 Consumir Servicio Web.

 Confirmación de Transacción
 Sincronizar Datos.
 Configurar Cuenta.
 Confirmar Transacción
 Consumir Servicio Web.

24
2.5 Estimaciones

 Estimación de tamaño inicial en Anexo A

2.6 Identificación de riesgos

“El riesgo se define como la combinación de la probabilidad de que se produzca un

evento y sus consecuencias negativas”

Una tarea importante dentro de gestión del proyecto es anticipar los riesgos que
pueden afectar al proyecto como tal o a la calidad del software. Esta anticipación
tiene como objetivo comprender los riesgos a los que se enfrenta el sistema y así
generar requerimiento de confiabilidad para tratar dichos riesgos o plan de mitigación
y contingencia según sea el caso.

2.6.1 Riesgos Asociados al desarrollo del Proyecto

Riesgos identificados Acción de Mitigación y Contingencia

Subestimación o sobreestimación del Reevaluar la estimación del proyecto en

tamaño del proyecto base a datos históricos del desarrollador

Subestimación o sobreestimación de los Reevaluar la estimación del proyecto en

recursos del proyecto base a datos históricos del desarrollador

Requerimientos mal definidos Analizar el sistema en base a la

problemática y replantear requerimientos

Retraso en la Especificación Guiarse por la carta de Gantt

Retraso en el Diseño global y específico Guiarse por la carta de Gantt

25
 El entorno de desarrollo no se integra con Revisar tutorial del desarrollador oficial y
paquetes generados por MATLAB. visitar la Sitio Web oficial de MATLAB.

Inexperiencia con la tecnología Buscar información en la web y libros, y

solicitar orientación a expertos del tema.

Negación de información de apoyo por Desarrollar prototipo de solución en base a

parte de Redbanc la arquitectura de referencia e interfaces de
comunicación estándar para sistemas de
transacciones.

Tabla 1: Riesgos de Proyecto

2.6.2 Riesgos asociados al Software

Riesgos identificados Requerimiento de Confiabilidad

Caída en la conexión de interfaz de Procedimiento de abandono de la operación

comunicación y reporte

Inconsistencia de datos Procedimiento de abandono de la operación

y reporte.

Acciones frente a fallas de software Procedimiento de mantención y correctivos

agiles.

Resultados poco confiables Seguimiento del software para verificar la

calidad.

Tabla 2: Riesgos de Software

26
2.7 Planificación temporal

 Planificación en Anexo A.

2.8 Plan de trabajo

El plan de trabajo consiste principalmente en clasificar etapas y subdividirlas en tareas

en relación a dichas etapas, de esta forma organizar y planificar los recursos que se
tienen para el perfecto desarrollo del proyecto.

Para comenzar esta planificación de trabajo y como primera etapa; se recopilará

todos los antecedentes necesarios, se realizará un breve investigación acerca de las
clonación de tarjetas( definición, tipos, estadísticas, plan de mitigación, entre otros),
se investigará acerca del estado del arte en los sistema de detección de fraudes que
existen implementados y los que están por implementar, paralelamente a esta etapa
se investigará y se estudiará acerca de las Redes Neuronales Artificiales los diversos
modelos, tipo de aprendizaje (algoritmos), determinar los parámetros del
modelo(función de transferencia, el conjunto de pesos sinápticos, parámetro de
sesgo, etc.).

La etapa siguiente consiste en determinar en base a la información recopilada los

requerimientos funcionales y no funcionales de sistema, realizando un completo
análisis de la problemática, orientándose en los textos de estudio de Ingeniería del
Software que se mencionan en la referencia o bibliografía. Posteriormente se
modelará el sistema solución basándose en el objetivo general y los objetivos
específicos, esbozando el diseño arquitectónico, casos de usos, diagramas de clases
(Programación orientada a objetos) y diagramas de paquetes.

Una vez obtenida la visión panorámica acerca del diseño global se subdividirá el
sistema en sub-proyectos y se realizará el diseño detallado de cada uno de esta sub-
división, llevando a cabo la codificación, depuración y pruebas de cada módulo. Para
finalizar y se realizará una depuración y pruebas a nivel Global del sistema.

Todo el plan de trabajo indicado anteriormente se resume en la Carta de Gantt Anexo

A del presente documento.

27
2.9 Ambiente de ingeniería de SW

 Metodología de desarrollo:

Para el desarrollo del Software de aplicación se utilizará la Metodología de

Desarrollo Cascada con Sub-Proyecto, ya que permite la ejecución de algunas
tareas de cascada en forma paralela con una adecuada planificación, lo que permite
avanzar en ciertas tareas sin esperar una tarea “predecesora”.
Lógicamente para emplear esta metodología el sistema debe ser divisible en sub-
proyectos o módulos, para el adecuado desarrollo del Software de aplicación. El
sistema se dividirá en 3 módulos:

 Sistema evaluador de transacción.

 Simulador de cajero automático.
 Aplicación de confirmación de transacción Android.

La principal razón de la elección de la metodología es la que se mencionó en el primer

párrafo, al dividir en sub-proyecto permite realizar tareas paralelamente,
adicionalmente permite enfocar más detenidamente en estos módulos (dividir para
conquistar) y finalmente plantea organización en el proceso de desarrollo. De esta
manera la metodología queda planteada de la siguiente forma: análisis de
requerimientos y diseño global, las cuales se realizan linealmente, y luego propone
separar el proyecto global en sub-proyectos más pequeños de forma que las
siguientes fases: el diseño detallado, la codificación y depuración, y las pruebas de
sistema se realicen linealmente para cada sub-proyecto definido, logrando así que
cada módulo se desarrolle llevando a cabo tareas y técnicas particulares de acuerdo
a sus respectivas necesidades.
Obs: El simulador de transacciones bancarias es construido con la finalidad de
realizar las pruebas finales, no es parte del sistema como tal.

28
 Las técnicas y notaciones:

 Estándares de documentación: Adaptación basada en IEEE Software

requirements Specifications Std 830-1998.
 Diagramas de clases.
 Diagramas de paquetes.
 Árbol Arquitectónico.

 Herramientas de apoyo al desarrollo de software :

 Apache Versión 2.4.3:

 MySQL Versión 5.5.27:
 PHP Versión 5.4.7:
 phpMyAdmin Versión 3.5.2.2:
 Balsamiq Mockups Versión 2.2.2:
 Sublime Text 2 Versión 2.0.1:
 MATLAB r2012a:
 Eclipse Versión Juno 3.8.0:
 Samsung Kies Versión 2.5.1.12123_3:
 Netbeans IDE Versión 7.3
 GlassFish Versión 3.1.2
 Android Developer Tools Build Versión 21.0.1-543035:

 Lenguajes de programación:
 Java: Lenguaje de programación en el que se desarrollará el sistema de
evaluación de transacciones.
 Android: Lenguaje de programación en que se desarrollará la aplicación
de confirmación de transacciones.
 PHP: Lenguaje de programa en el que se desarrollará el simulador de
cajeros automáticos, con el fin de generar las pruebas correspondientes
del sistema.

29
 3 ESTADO DEL ARTE

Dentro de este capítulo se describen las bases teóricas en las que se rige el prototipo de
solución propuesto, en pocas líneas se resume el estado del arte tanto en tipología de
fraudes como en los sistemas actuales de detección del mismo. Para empezar este ítem
y a modo de introducción se detallan los Tipos de Fraudes en tarjetas de crédito y débito,
se mencionan los tipos de fraudes más conocidos y utilizados por los delincuentes, luego
se presenta el estado del arte de la Detección de Fraudes divididas en dos categorías:
“Técnicas tradicionales” y “Técnicas de minería de datos”, finalmente se hace énfasis
en las técnicas de minerías de datos, pues es la técnica más utilizada hoy en día en el
mercado para detectar fraudes.

3.1 Tipología de fraudes en tarjetas de Créditos y Débitos

“El Fraude es el engaño del cual se vale una persona para hacerse de un objeto de
procedencia ajena en perjuicio de otra, y de acuerdo con la legislación penal indica
una acción tendiente a alcanzar un lucro u obtener ilícitamente una cosa a través
del aprovechamiento de un error cometido por otras personas”.

 Fraude de Tarjeta-no-presente (CNP):

Este fraude ocurre cuando los estafadores utilizan robos de datos de la tarjeta para
comprar bienes o servicios en línea, por teléfono o por correo.

 Fraude con Tarjetas de Falsificaciones:

Este fraude ocurre cuando los defraudadores hacen una copia ilegal de su tarjeta
de crédito o débito (clonación de tarjetas). La mayor parte de este fraude consiste
en leer los datos de la tarjeta a través de la banda magnética para grabarlos en un
plástico nuevo usando un hardware llamado “Skimmers” , La simplicidad que
significa la clonación de tarjetas con bandas magnéticas ha generado que en
muchos países cambien este tipo de tecnología, reemplazándolas por tarjetas
inteligentes con chip incorporados. Chile es hoy en día unos de los pocos países
que aún opera con esta tecnología, y esta es la principal causa de ser un blanco de
ataque de bandas internacionales.

30
  Fraude con Tarjetas Pérdidas y / o Robadas:

Esto ocurre cuando la tarjeta de débito o tarjeta de crédito es robada o perdida

físicamente y luego utilizados por un criminal, haciéndose pasar por el cliente.

 Tarjeta de identificación del robo:

Esto ocurre cuando un criminal ha logrado obtener otros detalles de su tarjeta de
crédito o débito, tales como información personal robada, para abrir o hacerse cargo
de una nueva cuenta de tarjeta a su nombre.

 Correo no recibo de tarjeta de Fraude:

Este tipo de fraude se produce cuando un usuario abre una nueva cuenta y la nueva
tarjeta es robada antes de que llegue a las manos del beneficiario, es decir robo por
correo, es un tipo de fraude menor en comparación de los otros aun así las grandes
entidades bancarias lo consideran en sus estadísticas.

3.2 Detección de fraudes

Los fraudes pueden ser extremadamente costosos para las empresas. Estos actos
delictivos pueden ocasionar enormes pérdidas y hasta amenazar la subsistencia de
la organización es por ello que generar sistemas de detección de fraudes es
fundamental más aún si con dicho sistema podemos prevenir estos fraudes. Sin
embargo como se mencionó anteriormente la detección de fraudes financieros no es
un tema fácil y es que con el aumento de la tecnología, estos ilícitos se vuelven más
sofisticados. La elaboración del fraude de hoy en día no es el mismo que se hacía
hace algunos años atrás, las alternativas de hoy en día para detectar los fraudes
también han evolucionado, de las cuales se pueden clasificar en:

 Técnicas Tradicionales
 Técnicas de Minería de datos

3.2.1 Técnicas Tradicionales:

Las técnicas tradicionales de detección de fraudes consisten principalmente

31
 en una combinación de investigación y herramientas que reportan actividades
sospechosas como un software por ejemplo, algunas de estas técnicas son
muy sencillas y antiguas, sin embargo aún siguen operando mientras que
otras son más complejas y requieren mayor preparación a la hora de
implementar estos métodos, por lo demás las técnicas tradicionales son
variadas y podemos hacer una clasificación como la siguiente:

 Sistemas basados en la aplicación de reglas: Constan de sentencias SQL,

definidas con la ayuda de expertos. Esta estructura puede detectar sumas
acumulativas de dinero, ingresadas a una cuenta en un corto periodo de
tiempo, como un día.

 Métodos de análisis estadísticos; Los métodos de análisis estadísticos

son métodos representativos en donde se encargan de recolectar,
analizar e interpretar datos a partir de una muestra, Algunos de estos
métodos que se utilizan en la detección de fraudes son: el análisis de
regresión de datos, el análisis de correlación, el análisis de dispersión y el
análisis de frecuencia digital.

 Análisis de relaciones: Permite reconocer relaciones entre elementos de

información como transacciones, cuentas y participantes. Esta técnica
requiere de un esquema supervisado.

 Técnicas de análisis visual: El objetivo de este tipo de técnicas es

visualizar el conocimiento en la enseñanza-aprendizaje a través de la
percepción, algunas de estas técnicas son: análisis de relaciones, análisis
de línea de tiempo, gráficos de agrupamientos.

 Procedimientos analíticos de auditoria: Se definen como evaluaciones de

información financiera que se hacen mediante un estudio de
las relaciones entre datos financieros y no financieros como por ejemplo
el análisis vertical y horizontal de las cuentas de balance.

32
 3.2.2 Técnicas de minería de datos:

La minería de datos en una de las técnicas más utilizadas en a la hora de

trabajar con grandes volúmenes de datos. Consiste en obtener conocimiento
a través de estos, buscando patrones en estas cantidades de datos. Estas
son las técnicas existentes que son modeladas en distintos enfoques para
identificar casos de transacciones sospechosas:

 Modelos de datos inusuales: Con este modelo se pretende detectar

comportamientos raros en un dato respecto a su grupo de comparación o
con el mismo, por ejemplo la consignación de altas sumas de dinero en
efectivo. Para este caso se puede emplear técnicas de análisis de
clustering seguido de un análisis de detección de Outlier.

 Modelos de relaciones inexplicables: Con este modelo se pretende

encontrar relaciones de registros que tienen iguales valores para
determinados campos, resaltando el hecho que la coincidencia de valores
debe ser auténticamente inesperado, desechando similitudes obvias
como el sexo, la nacionalidad, por ejemplo la transferencia de fondos
entre dos o más compañías con la misma dirección de envío. Para este
caso se pueden aplicar técnicas de Clustering para encontrar grupos
sospechoso y reglas de asociación.

 Modelos de características generales. Con este modelo se pretende hacer

predicciones de futuros ingresos de transacciones sospechosas, una vez
detectado ciertos casos, Para estas predicciones usualmente se emplean
técnicas de regresión, árboles de decisión y redes neuronales.

33
 Cluster
Técnicas
Descriptivas
Detección de
anomalias

Máquinas de
Mineria de Datos
soporte vectorial

Arboles de
desición
Técnicas de
Predicción
Redes
Bayesianas

Red Neuronal
Artificial

Figura 3 Taxonomía: Técnicas de Minería de datos de detección de fraudes

3.3 Especificación de las Técnicas de detección de fraudes

3.3.1 Técnicas Descriptivas de detección de fraudes

El principal objetivo de este tipo de técnica de minería, es encontrar patrones

(correlaciones, tendencias, grupos, trayectorias y anomalías) que resuman
relaciones en los datos. El enfoque para predecir los fraudes pueden clasificarse
como:

 Detección de anomalía: La finalidad de la detección de anomalía, es encontrar

objetos diferentes de los demás, Normalmente estos objetos son conocidos como
“Outlier”, otra denominación para este tipo de detección es de “detección de
desviaciones”, pues los objetos anómalos que se identifican tienen valores de
atributos con una desviación significativa respecto a los valores típicos
esperados.
La identificación de los “Outlier” es una herramienta valiosa para encontrar
comportamientos atípicos en las operaciones bancarias que realiza el cliente en
una entidad financiera. La detección de “Outlier” se clasifican en:

34
  Técnicas basadas en Modelos: Basada en el campo de las estadísticas
que permiten conocer la distribución de los datos usando modelos
estadísticos y probabilísticos.

 Técnicas basadas en Proximidad: Esta técnica se fundamenta en el

manejo de distancias entre objetos, entre mayor sea la distancia del objeto
respecto a los demás, éste es considerado como un "Outlier". Entre los
principales métodos se encuentra: la distancia de Mahalanobis y la
distancia Euclidiana

 Técnicas basadas en Densidad: Se hace uso de la estimación de

densidad de los objetos, para ello, los objetos localizados en regiones de
baja densidad, y que son relativamente distantes de sus vecinos se
consideran anómalos.

 Agrupamiento (Clustering): El agrupamiento consiste en un proceso que divide

los objetos, de tal forma que los miembros de cada grupo son similares de
acuerdo a alguna métrica, esta técnica de acuerdo a la similitud es una técnica
muy poderosa, la clave para esto es trasladar alguna medida intuitiva de similitud
dentro de una medida cuantitativa.
Las técnicas de Agrupamientos son utilizadas comúnmente para hacer
segmentación y su gran aplicación está en estrategias de mercadeo, mediante
las cuales se determinan conjuntos de clientes que poseen el mismo
comportamiento, para hacer llegar ofertas especialmente diseñadas al perfil de
dichos clientes. Las técnicas de segmentación permiten identificar claramente el
comportamiento de un grupo de casos que difiere de otros grupos o conjuntos,
sin embargo algunos autores plantean que por lo general, los clúster son
resultados difíciles de entender. Algunas veces, se puede utilizar un árbol de
decisión a la salida del clúster, para explicar con precisión el comportamiento o
características de los casos que conforman el clúster.
Los algoritmos de clúster funcionan con una metodología basada en la
construcción inicial de un gran clúster, y luego la subdivisión del mismo hasta
encontrar grupos de muestras muy cercanas, otros por el contrario, parten
asumiendo que cada registro es un clúster, y luego empiezan a agrupar registros

35
 hasta que se consolidan clúster no superpuestos más grandes. Entre los
diferentes tipos de clúster se tienen:

 Clúster bien separados

 Clúster basados en el centro
 Clúster contiguos
 Clúster basados en densidad.
 Clúster de propiedad o Conceptual

3.3.2 Técnicas Predictivas de detección de fraudes

El objetivo de este tipo de técnicas, es clasificar un valor particular de un atributo

basado en otros atributos. El atributo a clasificar es comúnmente llamado "clase" o
variable dependiente, mientras que los atributos usados para hacer la predicción se
llaman variables independientes. Dentro de las principales técnicas encontramos:

 Arboles de decisión: De las técnicas predictivas es las más fácil de aprender y

entender. Un árbol de decisión es un conjunto de condiciones organizadas en una
estructura jerárquica, de tal manera que la decisión final a tomar, se puede
determinar siguiendo las condiciones que se cumplen desde la raíz del árbol
hasta sus hojas. Se utilizan comúnmente cuando se necesitan detectar reglas del
negocio que puedan ser fácilmente traducidas al lenguaje natural o SQL, o en la
construcción de modelos de clasificación. Existen dos tipos de árboles: los de
clasificación, mediante los cuales un registro es asignado a una clase en
particular, reportando una probabilidad de pertenecer a esa clase, y los árboles
de regresión, que permiten estimar el valor de una variable numérica objetivo.

36
 Pedir Monto

Extracción Restar Monto a la Cuenta

Generar Comprobante

Pedir Monto

Tipo de
Depositar Sumar Monto a la Cuenta
Transacción
Si
Generar Comprobante

Transacción
Valida?
Obtener Saldo

Saldo

No Generar Informe

Procesar Mensaje
de Error

Figura 4: Ejemplo de un Árbol de decisión

 Redes Neuronales Artificiales: Las redes neuronales artificiales son un

paradigma de aprendizaje basado en la simulación de la red neuronal cerebral.
Estas redes consisten en la interconexión de una unidad llamada nodo que se
encuentran organizadas en capas. Por lo general son 3 capas; entrada, salida y
ocultas. Para mayor detalle leer el Anexo D que define arquitectura,
funcionamiento entre otras cosas.

 Redes Bayesianas (BN): La Redes Bayesiana es basada en el teorema

estadístico de Bayes, el cual provee un cálculo para la probabilidad a posteriori.
De acuerdo al teorema de Bayes, si H es una hipótesis, tal que, el objeto X
pertenece a la clase C, entonces la probabilidad que la hipótesis ocurra es:

P(Xj H) = (P (XjH) *P (H))/P(X).

Una red Bayesiana (BN) es una representación gráfica de las dependencias entre
un conjunto de atributos. Una red Bayesiana se compone principalmente de dos

37
 elementos:

 Un grafo a cíclico que codifica la dependencia de relaciones entre un

conjunto de variables.

 Una tabla de probabilidad asociada a cada nodo para su nodo padre

inmediato. En una red Bayesiana, para cada nodo X, existe una tabla de
probabilidad condicional, en la cual se especifica la probabilidad
condicional de cada valor de X, para cada posible combinación de los
valores se sus padres (distribución condicional P (xjpadre (x))).La
estructura de la red puede ser definida o ser inferida desde los datos. Para
propósitos de clasificación uno de los nodos puede definirse como nodo
"clase". La red puede calcular la probabilidad de cada alternativa de
"clase".

Figura 5: Ejemplo de una Red Bayesiana

 Máquinas de soporte vectorial: Las máquinas de soporte vectorial (SVM) son

un conjunto de algoritmos para clasificación y regresión propuesta por Vapnik y
su grupo AT&T Bell laboratorios. En simples términos, una SVM es un perceptrón
(como una red neuronal) y es idealmente adecuado para la clasificación binaria

38
 de patrones que son linealmente separables. La idea principal de la SVM es
obtener un único separador de híper planos que maximice el margen entre la
separación de dos clases, como se observa en la Figura 6 La característica de
los vectores que se encuentran en la frontera que separa la definición de este
Margen, en la jerga del álgebra lineal, se denomina "Support Vector"

Figura 6: Ejemplo de separador lineal de SVM

En el modelamiento de patrones de fraude, las SMV se pueden trabajar como un

modelo de clasificación binaria, donde "+1" representa a los clientes sospechosos
de fraude y "-1" Representa a los clientes usuales, para ello se tiene un modelo
en el que dado F = { a1; a2;. . . ak } un conjunto de características de un cierto tipo
de comportamiento de un cliente, obtenidas por algún conocimiento previo.

39
Cuadro de resumen:

Tarea Meta Técnica de minería

Detectar registros con

valores anormales.

Encontrar Datos inusuales Detectar múltiples Análisis de anomalías

ocurrencias de valores.

Detectar relaciones entre

registros.

Determinar perfiles.

Determinar registros
duplicados.
Análisis de Clúster.
Detección de registros con
Identificar relaciones referencias de valores Análisis de Clúster y
inexplicables anormales. anomalías.

Detectar relaciones Análisis de relaciones y

indirectas entre registros. asociaciones.

Detectar registros con

combinaciones de valores
anormales.

Encontrar criterios, tales

Características generales como reglas. Modelos Predictivos
de fraudes Calificación de
transacciones
sospechosas.

Tabla 3: Resumen de técnicas de minerías de datos para la detección de fraudes

40
3.4 Software para detectar Fraudes Financieros

Estos son los principales sistemas que se utilizan hoy en día por las grandes
empresas del rubro financiero algunos destacan por su sencillez otros por su
eficiencia, existe una gran variedad en estas tecnologías:

 Hojas de cálculos: Excel.

 Programas de Bases de Datos: Access, MySQL.

 Programas Estadísticos: SPSS,Minitab.

 Programas de Minerías de Datos: Clementina, Darwin, Enterprise Miner,

Intelligent Miner.

 Programas de Extracción, Análisis de Datos y Detección: IDEA, ACL, Gestor

AUDISIS, DATAS.

 Otros: TOAD, Sistema de Auditoria Seguridad y Control -SAS.

41
4 DEFINICION Y DES ARRO LLO DEL MODELO DE DETECCIÓ N Y
PREVENCIÓN DE FRAUDES

En este capítulo se define y describe el modelo de detección de fraudes que se diseñó,

basado en la técnica descriptiva de minería de datos usando una red neuronal artificial para
detectar comportamientos anómalos del usuario en base a su histórico, para así
discriminar en tiempo real entre una transacción normal y una transacción con posible
riesgo de fraude. Además se define y se describe el modelo de prevención de fraudes a
través de la integración del dispositivo móvil al sistema y la comunicación entre estos sub-
sistemas. Finalmente se describe los software de desarrollo, la instalación de plugins y la
integración entre IDE necesaria para el perfecto desarrollo del proyecto.

4.1 Técnica del Modelo de Detección de Fraude

Como se mencionó en el capítulo anterior las RNA son muy utilizadas cuando se trata
de trabajar en predicciones bajo cualquier contexto dada su eficiencia y robustez,
como por ejemplo en la mención anterior hacía referencia a la predicción del fraude
financiero, sin embargo las RNA también se ocupan y bastante en el ámbito de
reconocimiento de patrones en donde las utilizan hoy en día cientos de ingeniero y
científicos en sus proyectos dados las mismas características que ofrece.
Si bien es cierto la detección de fraudes financieros usando RNA no es nuevo, esto
data del año 1995 con el proyecto Minerva en Europa, no deja de estar obsoleta esta
metodología al día de hoy, es por ello que se eligió en primera instancia para detectar
estos fraudes.

El siguiente esquema representa secuencialmente las etapas del modelo de esta

técnica empezando desde la lectura de los datos hasta la entrega del resultado.

42
 Limpieza de datos

Agrupamiento de datos de usuario

Identificación de patrones de comportamiento

Comparación con Transacción en curso

Evaluación de la Transacción

Entrega de Resultado

Figura 7: Esquema Conceptual Técnica de Detección de Fraude

4.1.1 El Procesamiento de los Datos

 Adquisición de los datos:

La adquisición de los datos es a través de un sistema de gestión de transacciones
que actúa como middleware, estos datos se dividen es 3 grupos:

 Datos de la transacción.

Figura 8: Estándar de transacción creado por el Comité Europeo de

Estándares Bancarios (ECSB)

43
  Datos del Usuario:


Figura 9: Formato de datos del usuario

 Datos del Histórico del usuario:

Figura 10: Formato de datos del Histórico del usuario

 Análisis y exploración de los datos:

El análisis y exploración de los datos es la etapa siguiente a la adquisición de los
datos y corresponde a la evaluación de estos en tiempo real mientras dure cada
transacción, el análisis considera la transacción que se está llevando a cabo y es
comparada en base al comportamiento del historial del usuario.

 Entrega de resultados:
Una vez completado el análisis el sistema entregara el resultado si es o no un
posible fraude, dependiendo del resultado se verá involucrado la intervención del
usuario (confirmación de transacción).

44
 Historial
Cliente

Resultados Transaccion

Figura 11: Cadena de datos del sistema

4.2 Perfil de Comportamiento y Reconocimiento de Patrones de

Comportamiento

4.2.1 Perfil de Comportamiento

Como personas tenemos ciertos comportamientos que son habituales ya que por
naturaleza los desarrollamos desde nuestra infancia, en cada aspecto de nuestra
vida tenemos ciertos hábitos, acostumbramos por ejemplo a cenar en familia, a
escuchar música mientras viajamos o hacemos deportes, a bañarnos en la mañana,
si bien algunas de estas son conductas “estándares” no todos las siguen, existen
quienes prefieren leer un libro en mientras viajan, quienes se duchan por la noche,
y quienes no realizan ningún tipo de deporte, por nombrar algunas cosas. Claro está
que si bien no todos tenemos los mismo comportamientos habituales, todos
tenemos en cierto grado y proporción patrones de conducta.
Dentro del contexto de realizar transacciones también tenemos ciertos hábitos, por
ejemplo acostumbramos a realizar un giro cerca de nuestro hogar o cerca de nuestro
trabajo, acostumbramos a realizar estos giros post días de pagos, y por qué no decir
que inconscientemente realizamos un giro según el saldo que tenemos (relación
monto a girar versus saldo), es decir si analizamos las transacciones de giro de un
cliente en particular podremos ver que tiene algún tipo de hábito ya sea por fecha,

45
 hora, monto o lugar.
Factores para crear el perfil de conducta:

 Monto a girar.
 Fecha de la Transacción.
 Hora de la Transacción.
 Relación Monto/Saldo.
 Lugar de la Transacción.

4.2.2 Reconocimiento de Patrones

No cabe duda de que nos resulta fundamental dentro del sistema la determinación
si una transacción es legitima o es fraude, por otro lado este intervalo de resultado
es poco agradable, pues el margen de error es enorme, para maximizar este
intervalo de resultado (resultados prácticamente booleano) se decidió clasificar las
transacciones según su riesgo, de esta forma enfocarse en aquellas transacciones
que tienes un alto grado de fraude. La clasificación antes mencionada queda
entonces de la siguiente forma:

 Transacción Normal.
 Transacción de Bajo Riesgo.
 Transacción de Mediano Riesgo.
 Transacción de Alto Riesgo.

El reconocimiento de patrones de conducta está dado por una red neuronal artificial
diseñada especialmente para este fin y previamente configurada.

4.2.2.1 Arquitectura de la Red Neuronal Artificial

Cuando mencionamos crear un modelo de red neuronal artificial, debemos definir

primeramente lo que se conoce como arquitectura de la red, que responde al cómo
está estructurado la red neuronal, en términos de componentes y al como estos
componentes se relacionan entre sí, los componentes básicos de una arquitectura
de red son los siguientes:

46
  Números de capas.
 Función de transferencia.
 Número de entradas.
 Número de salidas.

Existen muchos modelos predefinidos de red, para el caso de la implementación

del sistema se utilizará el modelo correspondiente a Perceptrón Multicapa (MLP,
MultiLayer Perceptron). Esta arquitectura viene definida por MATLAB para trabajar
dentro del contexto de reconocimiento de patrones, y es avalada por muchos
ingenieros y científicos, esta es la principal razón de la elección del modelo.
La arquitectura básica de la red queda compuesta de la siguiente manera:

Red Neuronal Artificial

Número de Entrada 5

Número de Salida 1

Número de capas 2
ocultas
Número de 12
neuronas de capa
ocultas

Función de Sigmoide
transferencia

Tabla 4: Representación de la Arquitectura de la red

47
4.2.2.2 Descripción de las entradas de la red:

Entrada Nombre Descripción

Fecha Representa el día en

X1 que se ejecuta la
transacción
Hora Representa la hora en
X2 que se ejecuta la
transacción
Lugar Es el lugar en donde
X3 se está realizando la
transacción
Monto Representa la
X4 cantidad que se está
retirando del cajero.
Monto/Saldo Representa la relación
X5 entre el monto y el
saldo que tiene el
usuario

Tabla 5: Representación de las entradas de la red

4.2.2.3 Configuración de la Red Neuronal Artificial

La configuración describe el tipo de orden de presentación de los patrones y el tipo

de estrategias de aprendizaje y el tipo de algoritmo de aprendizaje que utilizará la
RNA:

 Algoritmo de aprendizaje: Backpropagation.

 Estrategia de aprendizaje: Single Step.
 Orden de presentación: Aleatorio.

48
4.2.3 Entorno de Desarrollo

4.2.3.1 Eclipse

Eclipse es un entorno de desarrollo integrado IDE de código abierto multiplataforma

que permite desarrollar Software en diversos lenguajes de programación mediante
la instalación de plugins correspondiente al lenguaje que se pretende desarrollar,
una de las principales características es la depuración de errores que ofrece, la
integración hacia otros programas de desarrollo y la documentación que dispone, y
por supuesto que resulta atractivo para cualquier desarrollador, estas son unas de
las principales razones por la elección del entorno de desarrollo.
Eclipse por defecto trae el JDT el plugins para Java, lenguaje que por cierto será en
el que se desarrollará el sistema de evaluación de transacción (SET), por otro lado
para el desarrollo de la aplicación de confirmación android es necesario instalar el
plugins más el SDK (Kit de desarrollo de software).

Figura 12: Imagen del Entorno de desarrollo Eclipse

4.2.3.2 MATLAB

49
 Matlab es un entorno de desarrollo integrado ampliamente usado por Ingenieros
para la computación numérica y la visualización de datos, posee una gran
versatilidad y capacidad de resolver problemas en distintas ramas como por
ejemplo; matemáticas aplicadas, física, química, finanzas, ingeniería entre otras.
Este IDE basa sus soluciones en a través de matrices para el análisis de sistemas
de ecuaciones y principalmente está orientado para llevar a cabo proyectos en
donde se encuentren implicados elevados cálculos matemáticos y la visualización
gráfica de los mismos.
El empleo de matrices que utiliza Matlab se debe básicamente a que se pueden
describir y/o representar una infinidad de problemas de una manera muy flexible y
matemáticamente eficiente.

Figura 13: Imagen Entorno de desarrollo Integrado MATLAB

Plataformas
MATLAB está disponible para un amplio número de plataformas: estaciones de
trabajo SUN, Apollo, VAXstation y HP, VAX, MicroVAX, Gould, Apple Macintosh y
PC AT compatibles 80386 o superiores. Opera bajo sistemas operativos UNIX,
Macintosh y Windows.

50
4.2.3.3 Neural Network Toolbox

Neural Network Toolbox es una herramienta de Matlab, que proporciona funciones

para el diseño, inicialización, simulación y entrenamiento de los modelos
neuronales de uso más extendido en la actualidad: perceptrón, redes lineales,
redes de retro propagación, redes de base radial, aprendizaje competitivo y
asociativo, aplicaciones autoorganizativas, aprendizajes de cuantización vectorial.
Mediante la funciones antes mencionadas y procedimientos escritos para Matlab
podemos diseñar complejos modelos de redes neuronales combinando modelos
que ya están proporcionados por defecto en Neural Network así como también
definir nuestras propias funciones de transferencia e inicialización, reglas de
aprendizaje, funciones de entrenamiento y estimación de error (según la
arquitectura de la red).
Neural Network Toolbox divide la estructura de una red en 5 secciones:

 Arquitectura: Define las características básicas de la red neuronal,

número de entradas, capas, conexiones de bias, etc.
 Subobjetos: Contiene referencias a las subestructuras de la red
neuronal, que nos permitirán configurar las propiedades de los
distintos componentes que forman la red (capas, entradas, salidas,
etc.).
 Funciones: Funciones principales de la red neuronal, utilizadas para
ejecutar las operaciones de inicialización, entrenamiento o simulación.
 Parámetros: Configuración de los parámetros asociados a las
funciones seleccionadas en el bloque de funciones.
 Valores: Aquí se definen las matrices con los valores de los pesos de
entrada, conexiones entre capas y bías.

51
 Figura 14: Imagen Neural Network/Data Manager (nntool)

4.2.3.4 Integración de Matlab a la aplicación Java

Como mencionamos anteriormente con MATLAB podemos realizar complejos
cálculos, si bien es cierto estos cálculos podrían realizarse a través de la
programación orientada a objetos utilizando Java resultaría un proceso más
engorroso y tedioso, la simplificación que nos proporciona MATLAB resulta
fundamental en términos de ahorro de tiempo de programación.

4.2.3.5 El proceso de integración de Matlab a una Aplicación Java

 Generar paquete de Java

Lo primero traspasar el modelo de la red neuronal artificial (en este caso) o

cualquiera que sea el código a un fichero de extensión .m a modo de
demostración llamaremos a este fichero “helloWorldClass.m”
Lo siguiente es convertir este código en un código reconocible para Java, para
que pueda ejecutarse, para esto basta con ir al comando “deploytool”.
Nos aparecerá un cuadro de diálogo como lo muestra la siguiente imagen:

52
 Figura 15: Imagen del cuadro de diálogo Deploytool

A modo de recomendación los valores no debieran ser modificados para no

tener ambigüedades o confusiones más adelante, una vez presionado la
opción “OK” aparecerá una ventana como lo ilustra la siguiente imagen, en la
que deberemos indicar las clases que debemos crear y que ficheros de
extensión .m contendrá cada una.

Figura 16: Imagen de ventana Build Java Package

Una vez añadido en fichero en la clase creada le damos la ruta y creamos el

paquete de Java.

53
  Integrando a Eclipse

La integración del paquete Java generado por Matlab a la aplicación de Java

resulta bastante simple, agregamos como librería el paquete generado
recientemente a la aplicación Java a la que queremos integrar el paquete Java,
ubicamos el fichero de extensión .jar que se encuentra en el paquete
generado, y además se debe añadir el fichero javabuilder.jar ubicado en el
mismo paquete.
Una vez realizado esto basta con agregar las siguientes líneas de importación
de librerías:

import com.mathworks.toolbox.javabuilder.*;
import HelloWordlProject.HelloWorldClass;

En este momento, estamos listos para poder ejecutar nuestro código MATLAB
desde Java. Para ello hay que limitarse a crear un objeto de la
clase HelloWordClass y llamar a la función que nos interesa.

4.3 Técnica del Modelo de Prevención de Fraude

Hasta el momento solo se ha mencionado y descrito la forma de detectar un fraude, en el

capítulo anterior se nombraron los principales métodos para detectar un fraude, sin
embargo ningún método para prevenir y la razón es simple hoy no existe forma alguna de
prevenir un fraude más que la prevención que el usuario puede ofrecerse consigo mismo
de cuidar sus tarjetas de créditos y/o débitos y por supuesto de cuidar sus contraseñas,
los bancos por su lado pretenden implementar las tarjetas con chip inteligentes con el
objetivo de reducir el índice de fraudes.
El modelo de prevención de fraudes que se diseñó para el sistema integra al usuario, de
tal forma que el autorice que transacción se ejecute y cual no, utilizando un dispositivo que
hoy por hoy es más que indispensable para la comunicación y la conectividad el dispositivo
móvil conocido como celular.

54
4.3.1 Integración del Dispositivo Móvil en la Prevención de Fraudes
Sin duda hoy en día el celular pasa a ser esencial para estar comunicados y conectados,
y así lo demuestra el incremento de ventas en Chile, la telefonía móvil se ha convertido en
un negocio muy rentable, tanto es así que las cantidades de ventas de dispositivos móviles
han superado a la de computadores y portátiles, superando los 22 millones de usuario de
telefonía celular cifra indicada en 2012 por Subtel.
En lo que telefonía inteligente se refiere 4 son los sistemas operativos más populares hoy
en día en el mercado:

 Android
 BlackBerry
 IOS
 Windows Phone

De estos 4 sistemas operativos en telefonía móvil, Android es el líder indiscutido según el

estudio trimestral IDC Worldwide Quarterly Mobile Phone Tracker, con un aumento en un
16% respecto al estudio pasado, por otro lado BlackBerry y IOS bajan mientras que
Windows Phone gana terreno en este mercado posicionándose en tercer lugar.
Esta es la principal razón de la elección de la plataforma móvil de desarrollo para la
aplicación de confirmación de transacciones.

4.3.2 El Procesamiento de los Datos

La aplicación procesa solo los datos de la cuenta asociada al cliente-usuario
 Nombre de usuario
 Fono de usuario
 Mail de usuario
 Estado de aplicación
 Patrón de Seguridad
 Nivel de protección

4.3.3 Sincronización de Datos

“La sincronización de los datos se refiere al proceso de propagación de los cambios en los datos”

La comunicación entre el sistema de evaluación de transacciones y la aplicación de

confirmación de transacciones está dada por un servicio web a través del protocolo de

55
 comunicación SOAP, podemos entonces afirmar que la sincronización de datos es
fundamental para que el sistema y la aplicación se comuniquen en tiempos de ejecución.
El principal responsable para la sincronización de datos por el lado de la aplicación es un
servicio que corre en segundo plano cuando el estado de la aplicación esta “activado” este
consume el servicio web en intervalos de 0,7 segundos.

Figura 17: Esquema Conceptual Sincronización de Datos

4.3.4 Entorno de Desarrollo

El desarrollo de la aplicación al igual que el sistema de evaluación está bajo el IDE
Eclipse, sin embargo para este desarrollo es necesario la instalación de un plugins ADT.

4.3.4.1 Instalación del Plugins ADT

Como se mencionó anteriormente para el desarrollo de Android bajo el IDE Eclipse
es necesario instalar el plugins ADT y el SDK, a continuación una breve explicación
del cómo se instala:
Ingresamos en Ayuda -> Instalar nuevo software, luego hacemos click en
Agregar e ingresamos la url del autor:

https://dl-ssl.google.com/android/eclipse/

56
 Luego siga los siguientes pasos:
1. Haga clic en Aceptar.
Si tienes algún tipo de problema al adquirir el plugin, utilize el protocolo
HTTP en lugar de HTTPS.
2. En el cuadro de dialogo del software disponible, seleccione la casilla junto
a Herramientas de Desarrollo y haga clic en Siguiente.
3. En la siguiente ventana, verá una lista de las herramientas necesarias
para ser descargado. Haga clic en Siguiente.
4. Lea y acepte los acuerdos de licencia, haga clic en Finalizar.
Si recibe una advertencia de seguridad diciendo acerca de la
autenticidad o validez del software no se puede establecer, haga clic en
Aceptar.
5. Cuando finalice la instalación, reinicie Eclipse.

Figura 18: Imagen de la instalación del Plugins ADT

4.3.4.2 Instalación del SDK

En el icono Android SDK Manager de eclipse podemos descargar e instalar las
distintas versiones del SDK, las versiones de android APIs, google APIs, entre

57
 otros:

Figura 19: Imagen del Android SDK Manager

58
5 ESPECIFICACIÓN DE RE QUERIMIENTOS DE SOFTWARE

Adaptación basada en IEEE Software requirements Specifications Std 830-1998.

5.1 Alcances

El sistema de detección y prevención de fraudes se limita por el color rojo figura

16, el sistema se mantiene en estado oyente a la espera de los datos que proporciona
el gestor de transacciones, una vez proporcionado los datos (paquetes de datos) de
la transacción que se ejecuta en tiempo real, el sistema realiza la evaluación y entrega
el resultado de la transacción en ejecución.
El sistema de detección y prevención de fraudes no modifica los datos del usuario, se
limita solo a evaluar la posibilidad de una transacción fraudulenta. La frontera entre el
sistema y el usuario está dado por la confirmación de la transacción, el usuario sólo
tiene el privilegio de confirmar o rechazar la transacción, no así la modificación de
algún tipo de dato.

Figura 20: Representación conceptual de los alcances de sistema

Tipo de tarjetas que el sistema se limita a evaluar:

 Tarjetas de créditos
 Tarjetas de débitos

Tipo de transacción que el sistema se limita a evaluar:

 Giro

59
5.2 Objetivo del software

El sistema analizará y evaluará la información de cada transacción financiera en

cajeros automáticos en base al comportamiento de cada usuario, solicitando si es
necesario la confirmación del mismo para lograr reducir el índice de fraudes
financieros.

5.3 Descripción Global del Producto

5.3.1 Interfaz de usuario

No existe requerimiento alguno que indique el desarrollo de la Interfaz de usuario.

5.3.2 Interfaz De Hardware

El sistema no interactúa con algún tipo de hardware.

5.3.3 Interfaz Software

Como se mencionó anteriormente el sistema está basado en una arquitectura de
referencia, en la que el sistema interactúa con un gestor de transacciones que actúa
como middleware es decir que es un intermediario entre el sistema de detección y
la base de datos, proporcionando una mejor calidad de servicio y seguridad.

Figura 21: Arquitectura de referencia en la que se basa el sistema

Los grupos de datos que proporciona el gestor de transacciones son los siguientes:

 Datos de la transacción
 Datos del Usuario
 Datos del Histórico del usuario

60
5.3.4 Interfaces de comunicación
Protocolos de comunicación:
 TCP/IP
 SOAP

5.4 Requerimientos Específicos del Sistema Evaluador de Transacción

5.4.1 Requerimientos Funcionales del Sistema

Id Nombre Descripción
Analizar
SIST_01 Requerimiento que evalúa cada transacción y discrimina la posibilidad de un fraude.
Transacción
Actualizar
Requerimiento que permite actualizar un atributo en la base de datos del servicio web,
SIST_02 Transacción en
que indica que hay una transacción en curso.
Curso
Insertar
SIST_03 Requerimiento que inserta una transacción en la base de datos del servicio web.
Transacción
Consulta estado
SIST_04 Requerimiento que permite consultar el estado de una Transacción en curso.
Transacción
Actualiza ultima Requerimiento que actualiza un atributo en la base de datos, que indica la última
SIST_05
Transacción transacción que realizó un determinado usuario.
Requerimiento que limpia los registro de la evaluación anterior y permite empezar una
SIST_06 Limpia Datos
nueva evaluación de una transacción.
SIST_07 Lee Datos Requerimiento que permite leer los datos de entrada al sistema.
SIST_08 Procesa Datos Requerimiento que procesa los datos y los prepara para la evaluación de la transacción.
Entrega
SIST_09 Requerimiento que entrega el resultado final de la evaluación.
Resultado

Tabla 6: Requerimientos funcionales del Sistema Evaluador de Transacción

5.4.2 Requerimientos No Funcionales del Sistema

Id Nombre Descripción
Eficiencia-
SIST_10 Requerimiento que asegura el buen rendimiento y desempeño del sistema.
Rendimiento
Eficiencia-
SIST_11 Requerimiento que asegura la eficiencia en términos de tiempo de respuesta del sistema.
Espacio
SIST_12 Fiabilidad Requerimiento que ofrece seguridad e integridad de los datos del sistema.

Tabla 7: Requerimientos No Funcionales del Sistema Evaluador de Transacción

5.4.3 Interfaces externas de entrada

Cada interfaz de entrada indica todos los grupos de datos que serán ingresados al
sistema independiente del medio de ingreso.

61
 Identificador Nombre del ítem. Detalle de Datos contenidos en ítem

SIST_01 Datos del usuario NUMERO DE CUENTA ,NOMBRE, APELLIDO, RUT, MAIL,TELEFONO

Datos del histórico del PAIS,CODIGO DE PAIS, ENTIDAD, SUCURSAL, DIGITO CONTROL,
SIST_02
usuario NUMERO DE CUENTA,TIPO DE TRANSACCION, MONTO, FECHA, HORA

PAIS,CODIGO DE PAIS, ENTIDAD, SUCURSAL, DIGITO CONTROL,

SIST_03 Datos de la transacción
NUMERO DE CUENTA,TIPO DE TRANSACCION, MONTO, FECHA, HORA

Tabla 8: Interfaces externas de entrada Sistema Evaluador de Transacción

5.4.4 Interfaces externas de Salida

Identificador Nombre del ítem. Detalle de Datos contenidos en ítem Medio Salida

SIST_01 Resultado transacción El sistema entrega el resultado de la transacción Valor Booleano

Tabla 9: Interfaces externas de salida Sistema Evaluador de Transacción

5.5 Requerimientos Específicos de Aplicación de Confirmación de Transacción

5.5.1 Requerimientos Funcionales del Sistema

Id Nombre Descripción
Consulta
Requerimiento que consulta el estado del atributo de transacción en curso que indica si
APP_01 Transacción en
existe una transacción en curso asociada a la cuenta del usuario.
Curso
Actualiza Requerimiento para actualizar el nombre asociado a la cuenta de usuario (base de datos
APP_02
Nombre Aplicación y base de datos servicio web).
Requerimiento para actualizar el fono asociado a la cuenta de usuario (base de datos
APP_03 Actualiza Fono
Aplicación y base de datos servicio web).
Requerimiento para actualizar el mail asociado a la cuenta de usuario (base de datos
APP_04 Actualiza Mail
Aplicación y base de datos servicio web).
Actualiza Nivel Requerimiento para actualizar el nivel de protección asociado a la cuenta de usuario
APP_05
de Protección (base de datos Aplicación y base de datos servicio web).
Actualiza Requerimiento para actualizar el número de cuenta asociado a la cuenta de usuario (base
APP_06
Número Cuenta de datos Aplicación y base de datos servicio web).
Actualiza Patrón Requerimiento para actualizar el patrón de seguridad asociado a la cuenta de usuario
APP_07
de Seguridad (base de datos Aplicación y base de datos servicio web).
Actualiza Estado Requerimiento para actualizar el estado asociado a la cuenta de usuario (base de datos
APP_08
Aplicación Aplicación y base de datos servicio web).
Consulta Monto
APP_09 Requerimiento para consultar el monto de la Transacción que se está llevando a cabo.
Transacción
Consulta Fecha
APP_10 Requerimiento para consultar la Fecha de la Transacción que se está llevando a cabo.
Transacción
Consulta
APP_11 Sucursal Requerimiento para consultar la Sucursal de la Transacción que se está llevando a cabo.
Transacción
Consulta Cajero
APP_12 Requerimiento para consultar el cajero de la Transacción que se está llevando a cabo.
Transacción

62
 Confirmar Requerimiento básico para confirma una transacción catalogada como fraude por el
APP_13
Transacción sistema

Tabla 10: Requerimientos Funcionales de la Aplicación de Confirmación

5.5.2 Requerimientos No Funcionales del Sistema

Id Nombre Descripción
Eficiencia-
APP_14 Requerimiento que asegura el buen rendimiento y desempeño del sistema.
Rendimiento
Eficiencia-
APP_15 Requerimiento que asegura la eficiencia en términos de tiempo de respuesta del sistema.
Espacio
APP_16 Fiabilidad Requerimiento que ofrece seguridad e integridad de los datos del sistema.

Tabla 11: Requerimientos No Funcionales de la Aplicación de Confirmación

5.5.3 Interfaces externas de entrada

Identificador Nombre del ítem. Detalle de Datos contenidos en ítem

APP_01 Consulta Monto MONTO

APP_02 Consulta Fecha FECHA

APP_03 Consulta Sucursal SUCURSAL

APP_04 Consulta Cajero CAJERO

Consulta Transacción en
APP_05 TRANSACCION_EN_CURSO
Curso

Consulta Ultima
APP_06 ULTIMA_TRANSACCION
Transacción

Tabla 12: Interfaces externas de entradas de Aplicación de Confirmación

5.5.4 Interfaces externas de Salida

Identificador Nombre del ítem. Detalle de Datos contenidos en ítem Medio Salida

63
 IS_01 Resultado transacción El sistema entrega el resultado de la transacción Valor Booleano

Tabla 13: Interfaces externas de salida de Aplicación de Confirmación

5.6 Atributos del producto

5.6.1 Funcionalidad
Es el grado en el que el software satisface las necesidades que indican los
siguientes sub-atributos:

 Exactitud: El sistema de evaluación de transacciones cuenta con una

clasificación en el análisis de cada evaluación esto es:

 Transacción Normal.
 Transacción de bajo riesgo.
 Transacción de mediano riesgo.
 Transacción de alto riesgo.

Esta clasificación permite aumentar la exactitud del resultado, según la

configuración de la aplicación una transacción de bajo, mediano y alto riesgo
podría solicitar la confirmación del usuario.

 Seguridad: El sistema maneja los datos mientras se ejecuta la transacción,

estos datos son entregados por el gestor de transacciones son preparados
para la evaluación, una vez entregado el resultado son borrados del sistema
transcurridos 10 segundos de la entrega de resultado, tiempo suficiente para
que se complete la transacción.

5.6.2 Fiabilidad
Es la cantidad de tiempo en que el software está disponible para el siguiente sub-
atributo:

 Tolerancia a fallos: Un fallo en el sistema puede ocasionar una gran pérdida

al usuario, por eso el manejo de estos fallos es primordial, el sistema cuenta

64
 con un método de aborto de transacción que se aplica en las siguientes
situaciones:
 No hay conectividad entre el servicio web y el sistema de
evaluación.
 No hay conectividad entre la aplicación y el servicio web.
 Los paquetes de datos de entradas no están con la estructura
definida.

5.6.3 Usabilidad
Es la facilidad con que se usa el software de acuerdo con el siguiente sub-atributo:

 Operatividad: La aplicación de confirmación de transacciones está diseñado

gráficamente bajo el concepto de Diseño UX (Diseño de experiencia de
usuario) por parte de los desarrolladores oficiales de Android
“AndroidDevelopers”, lo que aumenta considerablemente la operabilidad y la
probabilidad de aceptación de la aplicación por parte del usuario.

5.6.4 Eficiencia
Es el grado en que el software emplea en forma óptima los recursos del sistema.

 Comportamiento en el tiempo: El sistema está diseñado para minimizar el

tiempo de ejecución de la evaluación de la transacción, el límite de tiempo es
20 segundos, es decir una vez recibidos los 3 paquetes de datos existirán 20
segundos como máximo a la entrega del resultado (esperando o no la
confirmación del usuario según sea el caso), en el peor de los casos una
transacción de giro en un cajero automático pude aumentar en 20 segundos.

5.6.5 Portabilidad
Es la facilidad con que se lleva el software de un entorno a otro.

 Adaptabilidad: El sistema está desarrollado bajo un lenguaje de

programación multiplataforma, java al ser un lenguaje interpretado garantiza

65
 la adaptabilidad en un sistema operativo con la única condición de tener la
Máquina Virtual de Java corriendo.

66
6 FACTIBILIDAD

6.1 Factibilidad Operativa

Dentro de los impactos positivos que el Software traería tras una eventual implementación
en una institución financiera seria la reducción del índice de fraudes financiero producto
de la clonación de tarjetas (entre otros factores), esto se traduciría en un impacto positivo
para el usuario-final de la aplicación y la institución financiera que lo implemente. La
institución seria beneficiada con la disminución de pérdidas anuales (estimadas por
institución en el Anexo A) producto de los fraudes financieros y además impactaría
indirectamente sobre la reputación de la organización con respecto a la seguridad que le
ofrece a sus clientes.

El simple objetivo de reducir el índice de fraudes en transacciones de giro es una razón

por la que los usuarios-finales presenten un mayor interés en utilizar y aprender este
software. Otro atributo que aumentaría el interés de los usuarios del sistema, es la
innovación de la integración del dispositivo móvil al proceso de transacciones bancarias.
Estas dos razones motivarían al usuario a aprender a utilizar la aplicación. La importancia
del interés y motivación del usuario-final resulta fundamental para la aceptación del
sistema, el impacto positivo que traería consigo la buena utilización de la aplicación seria
realizar transacciones de giro seguras.

6.2 Factibilidad Técnica

Equipo, Dispositivos y Software disponible del desarrollador:

6.2.1 Equipos

Notebook:
 Disco Duro: 500 GB
 Memoria Ram: 4 GB
 Procesador: Intel Core 5-3210
 Tarjeta de Video: AMD Radeon HD 7550/7650
 Sistema Operativo: Windows 8 x64

67
 PC Escritorio
 Disco Duro: 160 GB
 Memoria Ram: 1 GB
 Procesador: AMD Sempron
 Tarjeta de Video: AMD Radeon HD 5450
 Sistema Operativo: Windows XP

6.2.2 Dispositivos

Disco Duro externo:

 Capacidad: 1 TB
 Interfaz: USB 3.0

Dispositivo Móvil 1
 Marca: LG
 Modelo: P708
 Memoria: 4GB interna y externa MicroSD 4GB
 Pantalla: Touch 4.3" 800x480 pixeles 16.7M colores TFT
 Sistema Operativo: Android 4.0 Ice Cream Sandwich

Dispositivo Móvil 2
 Marca: Samsung
 Modelo: Galaxy Y S5360
 Pantalla: Touch 3" 240x320 píxeles 262k colores.
 Memoria: 126 MB interna y externa MicroSD 4GB.
 Sistema Operativo: Android 2.3.

6.2.3 Software
MATLAB
 Versión: R2013a 8.1.0.604 x64
 Tipo de Licencia: Estudiante.

Obs: Los demás Software que se utilizarán en el desarrollo del proyecto son gratuitos, MATLAB
ofrece la licencia de estudiante a diferencia de los demás.

68
6.3 Factibilidad Económica

La cuantificación del beneficio fue calculada y estimada en el Anexo A.

6.4 Conclusión de Factibilidad

La factibilidad del proyecto es positiva, operativamente, técnicamente y económicamente.

69
7 ANÁLISIS

7.1 Diagrama de casos de uso

7.1.1 Actores

Gestor de transacciones:
 El gestor de transacciones es el encargado de descomponer la información
de la transacción en curso.
 El gestor de transacciones tiene como nivel de privilegio la entrega de
paquetes de datos (datos usuarios, datos historial, datos transacción) al
sistema de detección.

Usuario Cliente:
 El usuario no cumple un rol dentro de la entidad bancaria
 El nivel de conocimiento requerido para utilizar la aplicación es nivel de
usuario y conocimiento básico en aplicaciones móviles.
 El usuario como tiene el privilegio de confirmar aquella transacción que el
sistema califique como transacción de mediano y alto riesgo que requiera la
confirmación de la misma. además el usuario tiene la opción de configurar
su cuenta actualizando su nombre, fono, mail, patrón de seguridad, nivel de
protección (rango de sensibilidad).

7.1.2 Casos de Uso y descripción

El Diagrama de caso de uso es, en esencia, una interacción atípica entre el usuario
y el sistema de cómputo, Para el caso son dos los actores involucrados que
interactúan con el sistema; el Gestor de transacciones y el usuario cliente quién
realiza la transacción.
La interacción por parte del gestor de transacciones esta dada por la entrega de los
paquetes de datos que el sistema requiere para evaluar la transacción en curso y la
consulta del resultado de esta, por otro lado el usuario cliente interactúa
directamente con la aplicación móvil con la única funcionalidad de confirmar
transacción y configurar su cuenta.

70
 System

Entrega de Datos de Transacción Activar/descativar Aplicación

Actualizar Nombre
Entrega de Datos de Usuario

Actualizar Patron de Seguridad

Entrega del Historial del usuario

Actualizar Fono Usuario

Usuario Cliente
Gestor de Transacciones Consulta evaluación de Transacción

Actualizar Mail Usuario

<<include>>

Entrega de Resultado
Actualizar Análisis de sensibilidad

<<include>>
<<extend>>
Evaluar Transacción Confirmar Transacción

Figura 22: Diagrama de casos de usos

7.1.3 Especificación de los Casos de Uso

7.1.3.1 Caso de Uso: <Entrega de Datos de Transacción>

 Descripción: El gestor de transacciones entrega como fichero los datos de la

transacción en curso.
 Pre-Condiciones: El caso de uso se genera una vez que el usuario-cliente
ha ingresado su tarjeta y contraseña en el cajero automático y los datos han
sido verificados y validados por una capa lógica. Y el usuario-cliente ha
solicitado una transacción de giro.
 Flujo de Eventos Básicos:

Gestor de Transacciones El sistema

1) El gestor de transacción recibe la 3) El sistema recibe el fichero
transacción de giro realizada por el enviado por el gestor de
usuario-cliente. transacciones y lee el fichero.

71
 2) El gestor almacena los datos de 4) Cada dato es almacenado en
la transacción en el formato variables de ejecución y son
determinado por el sistema en un preparados para la evaluación.
fichero y lo entrega al sistema de
detección de fraudes.

 Flujo de Eventos Alternativo:

Al actor El sistema
2(a) El gestor no envía los datos de 3(a) El sistema aborta la evaluación
la transacción o se retrasa en de la transacción.
entregar los datos.
2(b) El gestor envía los datos no 3(b) El sistema aborta la evaluación
válidos de la transacción (sin de la transacción.
formato).

 Post-Condiciones: No hay modificaciones en base de datos.

7.1.3.2 Caso de Uso: <Entrega de datos de usuario>

 Descripción: El gestor de transacciones entrega como fichero los datos del

usuario-cliente.
 Pre-Condiciones: El caso de uso se genera una vez que el usuario-cliente
ha ingresado su tarjeta y contraseña en el cajero automático y los datos han
sido verificados y validados por una capa lógica. Y el usuario-cliente ha
solicitado una transacción de giro.
 Flujo de Eventos Básicos:

Gestor de Transacciones El sistema

1) El gestor de transacción recibe la 3) El sistema recibe el fichero
transacción de giro realizada por el enviado por el gestor de
usuario-cliente. transacciones y lee el fichero.
2) El gestor consulta los datos del 4) Cada dato es almacenado en
usuario-cliente, los escribe en el variables de ejecución y son
formato definido por el sistema en preparados para la evaluación.

72
 un fichero y lo entrega al sistema de
detección de fraudes.

 Flujo de Eventos Alternativo:

Gestor de Transacciones El sistema

2(a) El gestor no envía los datos del
usuario o se retrasa en entregar los
datos.
2(b) El gestor envía los datos no
válidos del usuario (sin formato).
3(a) El sistema aborta la evaluación
de la transacción.
3(b) El sistema aborta la evaluación
de la transacción.

 Post-Condiciones: No hay modificaciones en base de datos.

7.1.3.3 Caso de Uso: <Entrega de Historial de usuario>

 Descripción: El gestor de transacciones entrega como fichero los datos del

historial del usuario-cliente.
 Pre-Condiciones: El caso de uso se genera una vez que el usuario-cliente
ha ingresado su tarjeta y contraseña en el cajero automático y los datos han
sido verificados y validados por una capa lógica. Y el usuario-cliente ha
solicitado una transacción de giro.
 Flujo de Eventos Básicos:

Gestor de Transacciones El sistema

1) El gestor de transacción recibe la 3) El sistema recibe el fichero
transacción de giro realizada por el enviado por el gestor de
usuario-cliente. transacciones y lee el fichero.
2) El gestor consulta los datos del 4) Cada dato es almacenado en
historial del usuario-cliente, los variables de ejecución y son
escribe en el formato definido por el preparados para la evaluación.
sistema en un fichero y lo entrega al
sistema de detección de fraudes.

 Flujo de Eventos Alternativo:

73
 Gestor de Transacciones El sistema
2(a) El gestor no envía los datos del 3(a) El sistema aborta la evaluación
historial del usuario o se retrasa en de la transacción.
entregar los datos.
2(b) El gestor envía los datos no 3(b) El sistema aborta la evaluación
válidos del historial del usuario (sin de la transacción.
formato).

 Post-Condiciones: No hay modificaciones en base de datos.

7.1.3.4 Caso de Uso: <Consulta evaluación de la transacción>

 Descripción: El gestor de transacciones consulta el resultado de la

transacción, esta respuesta es un valor booleano escrito en un fichero.
 Pre-Condiciones: El caso de uso se realiza una vez que la evaluación de la
transacción se ha llevado a cabo, y el resultado se encuentra en un fichero.
 Flujo de Eventos Básicos:

Gestor de Transacciones El sistema

1) El gestor consulta por el resultado 2) El sistema envía el fichero con el
de la evaluación de la transacción. resultado de la evaluación de la
transacción.
3) El gestor realiza o rechaza la
transacción dependiendo del
resultado.

 Flujo de Eventos Alternativo:

Gestor de Transacciones
3(a) El gestor ignora el resultado del
sistema de detección.
El sistema
2(a) El sistema no envía el fichero
con el resultado o se demora más
de lo permitido en evaluar la
transacción.

74
  Post-Condiciones: No hay modificaciones en base de datos.

7.1.3.5 Caso de Uso: <Evaluar transacción>

 Descripción: El sistema evalúa la transacción en base a los paquetes de

datos recibidos por parte del gestor de transacciones, discriminando una
transacción en normal (habitual) o anormal (no habitual).
 Pre-Condiciones: Los paquetes de datos se deben haber recibido
correctamente (datos usuarios, datos historial, datos transacción).
 Flujo de Eventos Básicos:

Caso de uso entrega de resultado El sistema

1) El sistema prepara los datos para la
evaluación de la transacción.
3) Entrega el resultado del análisis 2) El sistema evalúa la transacción.
de la transacción en curso.

 Flujo de Eventos Alternativo:

Al actor El sistema

 Post-Condiciones: No hay modificaciones en base de datos.

7.1.3.6 Caso de Uso: <Entrega de resultado>

 Descripción: Caso de usos que entrega el resultado una vez terminada la

evaluación de la transacción.
 Pre-Condiciones: Para la correcta entrega del resultado, la evaluación de la
transacción debe haberse llevado con éxito.
 Flujo de Eventos Básicos:

Caso de uso Consulta evaluación de la El sistema

transacción
1) El Sistema determina si solicita
la confirmación del usuario.

75
 3) Consulta el resultado de la 2) El sistema entrega el resultado
evaluación. de la evaluación de la
transacción en curso.

 Flujo de Eventos Alternativo:

Usuario-cliente El sistema
1a) El sistema solicita la confirmación de
una transacción por parte del usuario-
cliente y este no la confirma
2a) El sistema aborta la transacción y
entrega el resultado.

 Post-Condiciones: No hay modificaciones en base de datos.

7.1.3.7 Caso de Uso: <Confirmar transacción>

 Descripción: Este caso de uso es la relación entre el usuario-cliente y la

aplicación móvil de confirmación, el usuario-cliente confirma o rechaza la
transacción.
 Pre-Condiciones: El caso de uso se genera una vez que el sistema evaluador
de transacciones determina la necesidad de una confirmación de la
transacción en curso por parte del usuario, pues según el resultado la
transacción que se lleva a cabo escapa de lo habitual, en tal caso se ejecuta
el caso de uso.
 Flujo de Eventos Básicos:

Usuario-cliente El sistema
2) El usuario confirma o rechaza la 1) El sistema detecta un posible fraude en
transacción que se esta realizando. la transacción que se evalúa, pide la
confirmación del usuario.
3) El Usuario cliente ingresa el patrón de 4) La respuesta de confirmación del
seguridad. usuario es enviada al gestor de
transacciones.

 Flujo de Eventos Alternativo:

76
 Usuario-cliente El sistema
2(a) El usuario no confirma o no 4(a) El sistema rechaza la
rechaza la transacción en un transacción.
determinado tiempo.
3(b) El usuario ingresa 4(b) El sistema rechaza la
erróneamente el patrón de transacción.
seguridad 4 veces.

 Post-Condiciones: No hay modificaciones en base de datos.

7.1.3.8 Caso de Uso: <Actualizar análisis de sensibilidad>

 Descripción: Caso de uso que permite Actualizar la sensibilidad de

evaluación dado un determinado rango de sensibilidad, por parte del usuario-
cliente.
 Pre-Condiciones: El usuario-cliente debe tener configurada la aplicación con
su cuenta de usuario, para poder actualizar el análisis de sensibilidad.
 Flujo de Eventos Básicos:

Usuario-cliente
1) El usuario selecciona la opción
del menú de configurar cuenta y
cambiar nivel de protección.
3) El usuario selecciona el nivel de
sensibilidad adecuado y confirma la
operación.
El sistema
2) La aplicación del sistema muestra
las opciones de seleccionar un nivel
de protección (Bajo, Medio, Alta).
4) Se almacena la opción escogida
por el usuario en la base de datos
interna de la aplicación (SQLite)

 Flujo de Eventos Alternativo:

Usuario-cliente
3(a) El usuario no selecciona alguna
opción del nivel de sensibilidad y
sale de la aplicación.
El sistema
4(a) La aplicación del sistema
mantiene el último valor registrado
en la configuración del análisis de
sensibilidad.

 Post-Condiciones: El valor de la actualización queda registrado en la base

77
 de datos de la aplicación y en la base de datos del servicio web
(Sincronización de datos).

7.1.3.9 Caso de Uso: <Activar/Desactivar Aplicación>

 Descripción: Caso de uso que permite activar o desactivar la aplicación, por

parte del usuario-cliente.
 Pre-Condiciones: El usuario-cliente debe tener configurada la aplicación con
su cuenta de usuario para poder activar o desactivar la aplicación.
 Flujo de Eventos Básicos:

Usuario-cliente El sistema
1) El usuario selecciona la opción 2) La aplicación del sistema
del menú de activar/desactivar muestra las opciones de activar
aplicación. o desactivar aplicación
3) El usuario selecciona una 4) Se almacena la opción
opción, en caso de desactivar la escogida por el usuario en la
aplicación el usuario-cliente base de datos interna de la
deberá ingresar el patrón de aplicación (SQLite).
seguridad de la aplicación.

 Flujo de Eventos Alternativo:

Usuario-cliente El sistema
3(a) El usuario no selecciona alguna 4(a) La aplicación del sistema
opción y sale de la aplicación. mantiene el último valor registrado
en la activación o desactivación de
la aplicación.
3(b) El usuario-cliente ingresa 4(b) La aplicación del sistema
erróneamente 4 veces el patrón de mantiene se mantiene activa.
seguridad para desactivar la
aplicación.

 Post-Condiciones: Se actualizan el atributo correspondiente al estado de la

aplicación en la base de datos interna de la aplicación y en la base de datos
del servicio web (Sincronización de datos).

78
7.1.3.10 Caso de Uso: <Actualizar Nombre Usuario>

 Descripción: Caso de usos que permite actualizar el nombre asociado a la

cuenta del usuario-cliente a la aplicación
 Pre-Condiciones: El usuario-cliente debe tener configurada la aplicación con
su cuenta de usuario para poder actualizar su nombre.
 Flujo de Eventos Básicos:

Usuario-cliente El sistema
1) El usuario selecciona la opción 2) La aplicación del sistema
de Configurar cuenta y muestra el valor actual.
selecciona cambiar nombre.
3) El usuario llena el campo y 4) La aplicación del sistema valida
confirma la operación. los datos y actualiza el nuevo
dato asociado a la cuenta del
usuario.

 Flujo de Eventos Alternativo:

Usuario-cliente
3(a) El usuario no llena el campos y
confirma la operación
3(b) El usuario antes de confirmar la
operación sale de la aplicación.
El sistema
4(a) La aplicación del sistema no
valida los datos y avisa al usuario de
que el formulario está incompleto.
4(b) La aplicación del sistema
mantiene la última configuración que
se registra.

 Post-Condiciones: La actualización del nombre se registra en la base de

datos interna de la aplicación y en la base de datos del servicio web
(Sincronización de datos).

7.1.3.11 Caso de Uso: <Actualizar Fono Usuario>

 Descripción: Caso de usos que permite actualizar el fono asociado a la

cuenta del usuario-cliente a la aplicación
 Pre-Condiciones: El usuario-cliente debe tener configurada la aplicación con

79
 su cuenta de usuario para poder actualizar su fono.
 Flujo de Eventos Básicos:

Usuario-cliente El sistema
1) El usuario selecciona la opción 2) La aplicación del sistema
de Configurar cuenta y muestra el valor actual.
selecciona cambiar fono.
3) El usuario llena el campo y 4) La aplicación del sistema valida
confirma la operación. los datos y actualiza el nuevo
dato asociado a la cuenta del
usuario.

 Flujo de Eventos Alternativo:

Usuario-cliente
3(a) El usuario no llena el campo y
confirma la operación
3(b) El usuario antes de confirmar la
operación sale de la aplicación.
El sistema
4(a) La aplicación del sistema no
valida los datos y avisa al usuario de
que el formulario está incompleto.
4(b) La aplicación del sistema
mantiene la última configuración que
se registra.

 Post-Condiciones: La actualización del fono se registra en la base de datos

interna de la aplicación y en la base de datos del servicio web (Sincronización
de datos).

7.1.3.12 Caso de Uso: <Actualizar Fono Usuario>

 Descripción: Caso de usos que permite actualizar el patrón de seguridad

asociado a la cuenta del usuario-cliente a la aplicación
 Pre-Condiciones: El usuario-cliente debe tener configurada la aplicación con
su cuenta de usuario para poder actualizar su fono.
 Flujo de Eventos Básicos:

Usuario-cliente El sistema

80
 1) El usuario selecciona la opción
de Configurar cuenta
selecciona cambiar patrón de
seguridad.
3) El usuario llena ingresa el patrón
de seguridad actual y confirma
la operación.
6) El usuario ingresa el nuevo patrón
de seguridad.
8) El usuario ingresa nuevamente el
patrón de seguridad y confirma la
operación.
 Flujo de Eventos Alternativo:
Usuario-cliente
3(a) El usuario no llena el campo y
confirma la operación
3(b) El usuario antes de confirmar la
operación sale de la aplicación.
3(c) El patrón ingresado
corresponde al patrón de seguridad.
6(d) El patrón ingresado no coincide
con el nuevo patrón que se ingresó.
 Post-Condiciones: La actualización del patrón de seguridad se registra en la
base de datos interna de la aplicación y en la base de datos del servicio web
81
2) La aplicación del sistema pide
y ingresar el patrón actual.
4) La aplicación del sistema valida
y verifica el patrón ingresado
sea el correcto.
5) La aplicación del sistema
muestra la pantalla para
ingresar el nuevo patrón de
seguridad.
7) La aplicación del sistema muestra
nuevamente la pantalla para
ingresar y confirma el nuevo patrón
de seguridad.
9) La aplicación valida y verifica que
coincidan los patrones ingresado y
actualiza los valores.
El sistema
4(a) La aplicación del sistema no
valida los datos y avisa al usuario de
que el formulario está incompleto.
4(b) La aplicación del sistema
mantiene la última configuración que
se registra.
no 4(c) La aplicación mantiene el último
patrón de seguridad registrado.
6(d) La aplicación mantiene el último
patrón de seguridad registrado.
 (Sincronización de datos).

7.1.3.13 Caso de Uso: <Actualizar Mail Usuario>

 Descripción: Caso de usos que permite actualizar el mail asociado a la

cuenta del usuario-cliente a la aplicación
 Pre-Condiciones: El usuario-cliente debe tener configurada la aplicación con
su cuenta de usuario para poder actualizar su mail.
 Flujo de Eventos Básicos:

Usuario-cliente El sistema
1) El usuario selecciona la opción 2) La aplicación del sistema
de Configurar cuenta y muestra el valor actual.
selecciona cambiar mail.
3) El usuario llena el campo y 4) La aplicación del sistema valida
confirma la operación. los datos y actualiza el nuevo
dato asociado a la cuenta del
usuario.

 Flujo de Eventos Alternativo:

Usuario-cliente
3(a) El usuario no llena el campo y
confirma la operación
3(b) El usuario antes de confirmar la
operación sale de la aplicación.
El sistema
4(a) La aplicación del sistema no
valida los datos y avisa al usuario de
que el formulario está incompleto.
4(b) La aplicación del sistema
mantiene la última configuración que
se registra.

 Post-Condiciones: La actualización del mail se registra en la base de datos

interna de la aplicación y en la base de datos del servicio web (Sincronización
de datos).

82
7.2 Modelamiento de datos

7.2.1 Diagramas de clases: Sistema evaluador de transacción

Figura 23: Diagrama de Clases Sistema Evaluador paquete principal

Figura 24: Diagrama de Clases Sistema Evaluador paquete entrada y salida de datos

83
 Figura 25: Diagrama de Clases Sistema Evaluador paquete evaluación

Figura 26: Diagrama de Clases Sistema Evaluador paquete comunicación

84
7.2.2 Diagrama de clases: Aplicación de Confirmación

Figura 27: Diagrama de Clases Aplicación de Confirmación paquete principal

85
Figura 28: Diagrama de Clases Aplicación de Confirmación paquete comunicación

86
Figura 29: Diagrama de Clases Aplicación de Confirmación paquete base de datos

87
Figura 30: Diagrama de Clases Aplicación de Confirmación paquete configuración
usuario

88
Figura 31: Diagrama de Clases Aplicación de Confirmación paquete menú lista

Figura 32: Diagrama de Clases Aplicación de Confirmación paquete seguridad

89
7.2.3 Diagrama de clases: Servicio Web

Figura 33: Diagrama de Clases Servicio Web

7.2.4 Modelo Entidad Relación SQLite: Aplicación de Confirmación.

usuario
usu_numero_cuenta Text
usu_nivel Text
usu_nombre Text
usu_fono Text
usu_mail Text
usu_estado Boolean
usu_patron_seguridad Text
usu_patron_respaldo Text

Figura 34: Modelo Entidad Relación Aplicación de Confirmación

7.2.5 Modelo Entidad Relación: Servicio web

Usuario
Transaccion usu_nombre Text
usu_cuenta Text usu_fono Text
tra_monto Text usu_cuenta Text
tra_fecha Date & Time usu_mail Text
tra_sucursal Text usu_estado Boolean
tra_cajero Text realiza usu_transaccion_en_curso Boolean
tra_estado Text usu_patron_seguridad Text
tra_id Text usu_nivel Text
usu_ultima_transaccion Text

Figura 35: Modelo Entidad Relación Aplicación de Confirmación

90
7.3 Diagrama de paquetes

Figura 36: Diagrama de paquetes Sistema Evaluador de Transacción

Figura 37: Diagrama de paquetes Aplicación de Confirmación

91
 Figura 38: Diagrama de paquetes Sistema Global

92
8 DISEÑO

8.1 Diseño de arquitectura funcional

8.1.1 Arquitectura funcional del sistema global

Sistema de
Deteccion y
Prevención de
Fraudes Financieros.

Aplicación de
Sistema Evaluador
Confirmacion de
de Transacciones
Transacción

Figura 39: Arquitectura funcional del Sistema Global

8.1.2 Arquitectura funcional de la aplicación de confirmación de transacción

Aplicacion de
Confirmación de
Transacción

Módulo de Módulo de Módulo de

Módulo de
Confirmar Configurar Cuenta Sincronización de
activar/desactivar
Transacción datos

Confirmar
Cambiar Nombre Activar Aplicación Sincronizar datos
Transacción

Rechazar Desactivar
Cambiar Fono
Transacción Aplicación

Cambia Mail

Cambiar Patron de
Seguridad

Cambiar Nivel
Protección

Figura 40: Arquitectura funcional de la Aplicación de Confirmación

93
8.1.3 Arquitectura funcional del sistema evaluador de transacción

Sistema evaluador
de transacción

Módulo de Módulo de Módulo de

Modulo de
entrada y salida procesamiento evaluacion de
Comunicación
de Datos de Datos Transacción

Lectura de Evaluar Conectar

Verificar Datos
Ficheros Transacción Servicio Web

Escritura de Limpiar y Consumir

Validar Datos
Ficheros eliminar Datos Servicio Web

Preparar Datos

Figura 41: Arquitectura funcional del Sistema Evaluador de Transacción

8.2 Diseño interfaz y navegación

8.2.1 Diseño de interfaz de usuario del Sistema Evaluador de Transacción

Figura 42: Diseño de interfaz usuario sistema de Evaluación de Transacción- Análisis de

Transacción

94
 Figura 43: Diseño de interfaz usuario sistema de evaluación de Transacción- Datos
Clientes

Figura 44: Diseño de interfaz usuario Sistema de Evaluación de Transacción- Historial

Cliente

95
Figura 45: Diseño de Interfaz Usuario Sistema de Evaluación de Transacción- Resultado
Análisis

8.2.2 Diseño de interfaz de usuario de la Aplicación de confirmación de transacción

Figura 46: Diseño de Interfaz Usuario Aplicación de Confirmación de Transacción-Menú

principal

96
Figura 47: Diseño de Interfaz Usuario Aplicación de Confirmación de Transacción-
Configurar cuenta

Figura 48: Diseño de Interfaz Usuario Aplicación de Confirmación de Transacción-

Configurar Sensibilidad

97
Figura 49: Diseño de Interfaz Usuario Aplicación de Confirmación de Transacción-
Activar/Desactivar Aplicación

Figura 50: Diseño de Interfaz Usuario Aplicación de Confirmación de Transacción-

Mensaje de Confirmación

98
 Figura 51: Diseño de Interfaz Usuario Aplicación de Confirmación de Transacción-
Patrón de Seguridad

8.2.3 Menú de Navegación Aplicación de Confirmación

Menú Principal

Activar/Desactivar
Configurar Cuenta Ayuda
Aplicación

Figura 52: Menú de Navegación de Aplicación de Confirmación de Transacción

99
8.3 Diseño Logo Sistema

Figura 53: Diseño logo oficial

Figura 54: Diseño logo aplicación

Figura 55: Diseño segundo logo aplicación

100
9 PRUEBAS

Adaptación basada en IEEE Software Test Documentation Std 829-1998

9.1 Elementos de prueba

Sistema de evaluación de transacciones:

 Módulo de lectura de datos.

 Módulo de entrega de resultado.
 Módulo de evaluación de transacción.

Aplicación de confirmación de transacciones:

 Módulo de configuración de cuenta.

 Módulo de confirmación de transacción

9.2 Especificación de las pruebas

Enfoque
Técnicas para la
Nivel para la
Características Objetivo de la definición de Actividades Criterios de
de definición
a probar Prueba casos de de prueba cumplimiento
prueba de casos
prueba
de prueba
Comprobar
funcionalidad de
los Ingresar Datos
requerimientos Valores límites y aleatorios Cumplimientos
Funcionalidad Módulo Caja Negra
por módulos particiones válidos y no de los requisitos
definidos en válidos.
elementos de
pruebas.
Medir el uso de
Comprobar que
memoria
Comprobar el no exista
Sub- Medición de requeridas en
Rendimiento rendimiento en - variación en el
Sistema Rendimiento. ejecución por
Sub-Sistemas rendimiento de
lapsos de
los sub-Sistemas
tiempo.
Ingresar
Comprobar la
Comprobar la Transacciones
Creación de perfiles funcionalidad en
Funcionalidad Sistema funcionalidad Caja Negra con perfiles de
de usuario su conjunto del
global del sistema usuarios
sistema
creados

9.3 Responsables de las pruebas

El responsable de la totalidad de la prueba:

101
  Esteban Rivera Rodriguez.

9.4 Calendario de pruebas

El periodo de las pruebas de sistema fue de 7 días a partir del 11 de Junio.

9.5 Detalle de las pruebas

9.5.1 Prueba de funcionalidad módulos

9.5.1.1 Módulo de lectura de datos

 Prueba de unidad: Recibe datos usuario

Entrada : Formato definido

Descripción Nu
I Tip Salida
Requerimiento me
d No o Obtenida Criticidad
Funcional Ru Ma Sal ro
mb Cu en caso
t il do Cu
re ent Fracaso
ent
a
a
jua
np Cu
11.
Jua ere ent 22
33 30
Recibe Datos n z@ a 22
1 3.4 00 Datos leídos
Usuario Per mai Cor 22
44- 00
ez l.co rie 22
2
m nte

jua
np Cu
11.
ere ent 22
33 30
Recibe Datos z@ a 22
2 3.4 00 Transacción abortada
Usuario mai Cor 22
44- 00
l.co rie 22
2
m nte

jua
np Cu
11.
Jua ere ent 22
33 30
Recibe Datos n z@ a 22
3 3.4 00 Transacción abortada
Usuario Per mai Cor 22
44- 00
ez l.co rie 22
2
m nte

jua
np Cu
Jua ere ent 22
30
Recibe Datos n z@ a 22
4 00 Transacción abortada
Usuario Per mai Cor 22
00
ez l.co rie 22
m nte

Cu
11.
Jua ent 22
33 30
Recibe Datos n a 22
5 3.4 00 Transacción abortada
Usuario Per Cor 22
44- 00
ez rie 22
2
nte

102
 jua
np
11.
Jua ere 22
33 30
Recibe Datos n z@ 22
6 3.4 00 Transacción abortada
Usuario Per mai 22
44- 00
ez l.co 22
2
m

jua
np Cu
11.
Jua ere ent 22
33
Recibe Datos n z@ a 22
7 3.4 Transacción abortada
Usuario Per mai Cor 22
44-
ez l.co rie 22
2
m nte

jua
np Cu
11.
Jua ere ent 22
33 30
Recibe Datos n z@ a 22
8 3.4 00 Transacción abortada
Usuario Per mai Cor 22
44- 00
ez l.co rie 22
2
m nte

 Prueba de unidad: Recibe datos transacción

Entrada : Formato definido

Tip
Descripción o Fe
I Salida
Requerimiento Ent Su Tra ch Criticidad
d Mo Obtenida
Funcional País ida cur ns a y en caso
nto
d sal ac hor Fracaso
ció a
n
21/
23 13
Recibe Datos 00 Gir 05/
1 chi 4 00 Datos leídos
Transacción 1 o 201
0
3
21/
23 13
Recibe Datos 00 Gir 05/
2 4 00 Transacción abortada
Transacción 1 o 201
0
3
21/
23 13
Recibe Datos Gir 05/
3 chi 4 00 Transacción abortada
Transacción o 201
0
3
21/
13
Recibe Datos 00 Gir 05/
4 chi 00 Transacción abortada
Transacción 1 o 201
0
3
21/
23 13
Recibe Datos 00 05/
5 chi 4 00 Transacción abortada
Transacción 1 201
0
3
21/
23
Recibe Datos 00 Gir 05/
6 chi 4 Transacción abortada
Transacción 1 o 201
3
23 13
Recibe Datos 00 Gir
7 chi 4 00 Transacción abortada
Transacción 1 o
0

103
  Prueba de unidad: Recibe datos Historial

Entrada : Formato definido

Tip
Descripción o Fe
I Salida
Requerimiento Ent Su Tra ch Criticidad
d Mo Obtenida
Funcional País ida cur ns a y en caso
nto
d sal ac hor Fracaso
ció a
n
21/
23 13
Recibe Datos 00 Gir 05/
1 chi 4 00 Datos leídos
Historial 1 o 201
0
3
21/
23 13
Recibe Datos 00 Gir 05/
2 4 00 Transacción abortada
Historial 1 o 201
0
3
21/
23 13
Recibe Datos Gir 05/
3 chi 4 00 Transacción abortada
Historial o 201
0
3
21/
13
Recibe Datos 00 Gir 05/
4 chi 00 Transacción abortada
Historial 1 o 201
0
3
21/
23 13
Recibe Datos 00 05/
5 chi 4 00 Transacción abortada
Historial 1 201
0
3
21/
23
Recibe Datos 00 Gir 05/
6 chi 4 Transacción abortada
Historial 1 o 201
3
23 13
Recibe Datos 00 Gir
7 chi 4 00 Transacción abortada
Historial 1 o
0

9.5.1.2 Módulo de configurar cuenta

 Prueba de unidad: Actualizar Nombre

Entrada
Descripción
I Salida
Requerimiento Criticidad
d Obtenida
Funcional en caso
Nombre
Fracaso

1 Actualizar Nombre Juan Pérez Registro Exitoso

Favor ingrese un
2 Actualizar Nombre
nombre

 Prueba de unidad: Actualizar Fono

I Salida
Entrada
d Obtenida

104
 Descripción Criticidad
Requerimiento en caso
Fono
Funcional Fracaso

1 Actualizar Fono 5555333 Registro Exitoso

2 Actualizar Fono Favor ingrese un fono

 Prueba de unidad: Actualizar Mail

Entrada
Descripción
I Salida
Requerimiento Criticidad
d Obtenida
Funcional en caso
Mail
Fracaso

1 Actualizar Mail juanperez@mail.com Registro Exitoso

Favor ingrese un mail

2 Actualizar Mail

 Prueba de unidad: Actualizar Patrón seguridad

Entrada
Descripción
I Salida
Requerimiento Criticidad
d Obtenida
Funcional Patrón 1 Patrón 2 en caso
Fracaso
Actualizar Patrón
1 001002003 001002003 Registro Exitoso
de seguridad
Favor confirmar el
Actualizar Patrón nuevo patrón de
2 001002003
de seguridad seguridad

Los patrones no
Actualizar Patrón coinciden favor
3 001002003 2
de seguridad intentar de nuevo.

9.5.1.3 Módulo de evaluar transacción

9.5.2 Prueba de Rendimiento:

La prueba de rendimiento consiste básicamente en medir la cantidad de memoria que

utiliza tanto el sistema evaluador de transacciones como la aplicación de confirmación
de transacciones en lapsos de una hora durante su ejecución.
En el caso de la aplicación de confirmación de transacciones, si esta tiene un valor de
verdad en el estado de activación, la aplicación funcionará en backgraund utilizando un

105
 servicio. Caso contrario no existirá un servicio corriendo por lo que no habrá costo en
términos de utilización de memoria en ejecución.

 Sistema Evaluador de Transacción:

 Día 1:

Hora transcurrida Cantidad de memoria Promedio acumulado

utilizada de memoria utilizada
1 35,6 MB 35,6 MB
2 32,7 MB 34,15 MB
3 22,5 MB 32,26 MB
4 22,8 MB 28,4 MB
5 20,0 MB 26,72 MB
6 20,3 MB 25,65 MB
7 20,1 MB 24,85 MB
8 20,2 MB 24,27 MB

Tabla 14: Prueba de rendimiento día 1 Sistema Evaluador de Transacción.

 Día 2:

Hora transcurrida Cantidad de memoria Promedio acumulado

utilizada de memoria utilizada
1 31,7 MB 31,7 MB
2 27,2 MB 29,45 MB
3 28,0 MB 28,96 MB
4 23,5 MB 27,6 MB
5 23,7 MB 26,82 MB
6 24,3 MB 26,4 MB
7 24,4 MB 26,11 MB
8 22,3 MB 25,63 MB

Tabla 15: Prueba de rendimiento día 2 Sistema Evaluador de Transacción.

 Día 3:

106
 Hora transcurrida Cantidad de memoria Promedio acumulado
utilizada de memoria utilizada
1 29,8 MB 29,8 MB
2 27,2 MB 28,5 MB
3 25,6 MB 27,53 MB
4 24,2 MB 26,7 MB
5 24,4 MB 26,24 MB
6 23,7 MB 25,81 MB
7 23,8 MB 25,52 MB
8 24,6 MB 25,41 MB

Tabla 15: Prueba de rendimiento día 3 Sistema Evaluador de Transacción.

Figura 55: Administrador de tareas equipo desarrollador.

 Aplicación de Confirmación de Transacción

 Día 1:

Hora transcurrida Cantidad de memoria Promedio acumulado

utilizada de memoria utilizada
1 4,1 MB 4,1 MB

107
 2 4,2 MB 4,15 MB
4 4,2 MB 4,18 MB
6 4,4 MB 4,23 MB
8 4,3 MB 4,24MB

Tabla 17: Prueba de rendimiento día 1 aplicación de confirmación de transacción.

 Día 2:

Hora transcurrida Cantidad de memoria Promedio acumulado

utilizada de memoria utilizada
1 4,2 MB 4,2 MB
2 4,2 MB 4,2 MB
4 4,4 MB 4,29 MB
6 4,1 MB 4,22 MB
8 4,2 MB 4,21 MB

Tabla 18: Prueba de rendimiento día 2 aplicación de confirmación de transacción.

 Día 3:

Hora transcurrida Cantidad de memoria Promedio acumulado

utilizada de memoria utilizada
1 4,1 MB 4,1 MB
2 4,2 MB 4,15 MB
4 4,4 MB 4,23 MB
6 4,4 MB 4,27 MB
8 4,3 MB 4,28 MB

Tabla 19: Prueba de rendimiento día 3 aplicación de confirmación de transacción.

108
 Figura 56: Simulador Dispositivo Android.

9.6 Conclusiones de Prueba

Los resultados indican que tanto la aplicación de confirmación como el sistema

evaluador de transacciones son estables y su variación es mínima con respecto
a la utilización de memoria, por ende son consistente y estables.

109
10 CONCLUSIONES

Como primera instancia quisiera referirme al modelo de detección de fraudes utilizando una red
neuronal artificial, si bien es cierto que se cumplió el objetivo del detectar un fraude y
demostrando además un comportamiento de acuerdo a lo pensado inicialmente, me gustaría
probar otras alternativas como por ejemplo un modelo probabilístico que puede manejar la
incertidumbre o utilizar una máquina de soporte vectorial que según lo estudiado puede disminuir
el tiempo de respuesta del sistema, todo esto para comprobar la exactitud del sistema y los
tiempo de ejecución con estos cambios. La intención es simple tener el conocimiento y la
experiencia de saber que utilizar dependiendo de la problemática.
Otro punto que quisiera destacar es referente al desarrollo del sistema, para ser más específico
la dificultad que tuve que enfrentar en el desarrollo en los distintos entornos de programación
tanto como Eclipse como MATALB, estos me ocasionaron en más de una vez problemas de
diversas complicaciones debido a la inexperiencia en el desarrollo de MATLAB y la integración
de MATLAB a Eclipse, además tuve que enfrentar dificultades en la comunicación de los sub-
sistemas también por el mismo factor la inexperiencia en el desarrollo de Servicios Web, todas
estas piedras en el camino se tradujeron en un retraso en la planificación inicial, sin ir más lejos
la metodología utilizada fue la apropiada quizás la elección de otra hubiera significado un mayor
retraso en la planificación.
El aprendizaje que obtuve en diferentes ámbitos fue lo más fructífero en el desarrollo del proyecto
ya que utilicé una rama de la Inteligencia Artificial, Comunicación de Datos, Creación y Consumo
de Servicios Web, Desarrollo Móvil en Android, Desarrollo en Java SE y EE, y en menor grado
Base de Datos SQL y SQLite, todo esto aprendí y/o reforcé en el transacurso del proyecto, lo
que me hace más competente como profesional en el mundo laboral.
En lo personal tomo el término de este proyecto como el inicio de una nueva etapa donde tendré
que lidiar quizás no con lo mismo problemas, quizás un tanto más complejos pero con la misma
solución perseverancia y esfuerzo.

110
11 BIBLIOGRAFÍ A

Arévalo González, Christopher Edgardo (2010). Desarrollo de aplicación móvil sobre

plataforma ANDROID en apoyo a visitas médicas.
Asteasuain, Fernando (2009). UML Lenguajes de Modelado Unificado.

Fowler, Martin (1997). UML gota a gota.

H. M. Deitel [2008]. Como programar en java.

H. M. Deitel [2012]. Como programar en java.

Hilera J. R., Martínez V. (2000), Redes Neuronales Artificiales: Fundamentos, modelos y Aplicaciones,

RA-MA Editorial, Madrid.

Izaurieta Fernando Y Saavedra Carlos, Departamento de Física, Universidad de Concepción, Chile,

Redes Neuronales Artificiales.

N. Murata, S. Yoshizawa, and S. Amari. Network information criterion - determining the

number of hidden units for an arti-ficial neural network model. IEEE Trans. on Neural Networks,

5(6):865–872, November 1992.

Pressman, Roger S (2005). Ingeniería del software: un enfoque práctico, Mac Graw Hill.

Rolston, David W (1990). Principios de inteligencia artificial y sistemas expertos.

Russell, Stuart J (2004). Inteligencia artificial: un enfoque moderno.

Sommerville, Ian (2005), Ingeniería del software, Mac Graw Hill.

Stevens, Perdita (2002). Utilización de UML en ingeniería del software con objetos y componentes.

Torres Ortíz, Víctor Hugo (2010). Implementación de una aplicación en la plataforma de desarrollo y

sistema operativo Android y su integración con sistemas de información (DC) 004 T636.

Winston, Patrick Henry (1994). Inteligencia artificial.

ENLACES:

111
http://www.mathworks.com/

http://poncos.wordpress.com/2008/04/14/matlab-toolbox-de-redes-neuronales/

http://hugo-inc.net16.net/RNA/Unidad%206/6.1.html

http://www.cs.umss.edu.bo/doc/material/mat_gral_30/08_AnalisisFuncional.pdf

http://www.naturastock.com/rsdotnet/iic3140/materia/ejemploespecificacion.pdf

http://www.redbanc.cl/portal_redbanc/browse?pagina=portal_redbanc/inicio.htm

http://unalm-construcion2010.wikispaces.com/file/view/N_+ATM.pdf

http://www.bnamericas.com/news/banca/Entrevista_a_Claudio_Figueroa,_gerente_general_de_

NCR

http://hoymeinteresa.wordpress.com/2009/09/25/%C2%BFcuantos-cajeros-automaticos-hay-en-

chile/

http://www.ebanking.cl/columnas/algunas-estadisticas-de-banca-electronica-en-chile-y-nuestras-

hipotesis-007019

http://halweb.uc3m.es/esp/Personal/personas/jmmarin/esp/DM/tema3dm.pdf

http://ocw.uv.es/ingenieria-y-arquitectura/1-2/libro_ocw_libro_de_redes.pdf

http://www.dynamics.unam.edu/DinamicaNoLineal/Articulos/MineriaDatos/Articulo03.pdf

http://www.bdigital.unal.edu.co/3086/1/299742.2010.pdf

http://www.blueliv.com/pdf/sic86_blueliv.pdf

http://www.forsa.es/pdf/PB05.PDF

112
12 ANEXO A: PLANIFICACION INICI AL DEL PROYECTO

12.1 Programa de actividades

Descripción de la
Etapa Actividades
actividad
Estudio sobre los actuales
sistemas de detección de fraudes
Estudio del estado el arte de
en cajeros que existen en la
los sistema de detección de fraudes
actualidad, ventajas y
desventajas.
Investigación Estudio de acerca del
Estudio de Datamining reconocimiento de patrones en
grandes volúmenes de datos.
Estudio sobre las redes
Estudio de redes neuronales neuronales artificiales,
Artificiales arquitectura, funciones y sus
componentes.
Plantear detalladamente los
factores que influyen en el índice
Análisis de la problemática de fraudes financieros en cajeros
automáticos.

Definir en base situación actual, el

alto índice de fraude financiero,
Definición de requerimientos
los requerimientos funcionales y
no funcionales del sistema.

Analizar y definir el ambiente de

Análisis de ingeniería, metodología de
Requerimiento Análisis de las necesidades desarrollo, técnicas y notaciones,
del sistema estándares de documentación y
herramientas de apoyo al
desarrollo del software.

Analizar el sistema en función de

Análisis Sistema solución
la problemática y requerimientos
en conjunto, definir los alcances
del sistema, así como también las
interfaces de entrada y salida del
sistema.

113
 Generar diagramas de flujos de
información del sistema en 3
Diagrama de flujos
niveles de descomposición
(Contexto, superior y detalle).
Diseñar el modelo de datos que
utilizará el sistema, en base a la
cadena de datos (Histórico,
Diseño de datos
transacción, resultado) que
analizará el comportamiento del
cliente.
Diseñar la arquitectura del
sistema a nivel global y sub-
Diseño arquitectónico global
proyecto.
y especifico
Especificar la interrelación de los
Diseño global módulos del sistema.
Diseñar las interfaces de
comunicación para el acceso de
Diseño de interfaz
datos e interfaz gráfica de
usuario.
Traspasar el diseño creado en
Programación código a través de un lenguaje de
Programación programación (Java).
Depuración y verificación de
Depuración del código
errores del código.
Generar pruebas de
funcionalidad de los sub-
Pruebas de sub-proyectos proyectos.
Pruebas de sistema Sistema evaluador y aplicación
de confirmación.
Generar pruebas de
Pruebas global del sistema
funcionalidad del sistema global.
Documentar el proceso de
Documentación del sistema análisis, diseño y desarrollo del
Documentación del sistema.
Software Realizar una revisión de
Revisión de ortografía y formato ortografía y formato del
documento.

114
12.2 Planificación

Etapa Actividades 1 2 3 4 5 6 7

Estudio del estado el arte de

los
X
sistema de detección de
Investigación fraudes
Estudio de la minería de datos X
Estudio de redes neuronales
X
artificiales
Análisis de la problemática X
Definición de requerimientos X
Análisis Análisis de las necesidades del
X
sistema
Análisis Sistema solución X
Diagrama de flujos X
Diseño de datos X
Diseño global Diseño arquitectónico global y
X
especifico
Diseño de interfaz X
Programación X X X X
Programación
Depuración del código X
Implementación Implementación local X

Pruebas de Pruebas de sub-proyectos X

Sistema Pruebas global del sistema X
Documentación del Sistema X X X X X
Documentación
del software Revisión de Ortografía y
X
Formato

115
12.3 Estimación inicial de esfuerzo requerido

La estimación de lo que costará el desarrollo del Software es una de las actividades de

planificación que reviste especial importancia, ya que una de las características que debe
tener un producto de software es que su costo sea adecuado, de lo contrario el proyecto
puede fracasar. Dada la importancia de realizar una buena estimación podemos
determinar el costo, el esfuerzo y el tiempo que se requiere para el desarrollo del proyecto.
El principal objetivo de esta estimación es reducir los costos y aumentar los niveles
de calidad.

12.3.1 Punto caso de uso como metodología de estimación inicial de esfuerzo

12.3.1.1 Punto de casos de uso sin ajustar (UUCP)

UUCP : Puntos de casos de uso sin ajustar.
UAW : Factor de peso de los actores sin ajustar.
UUCW : Factor de peso de los casos de uso sin ajustar.

UUCP = UAW + UUCW

 Factor de peso de los actores sin ajustar

Actor Tipo Actor Factor

Gestor de
Transacciones Medio 2

Usuario Complejo 3

UAW = 5

 Factor de peso de los casos de uso sin ajustar

Caso de uso Tipo de caso de Factor

uso
Entrega de Datos de
Transacción Simple 5

Entrega de Datos de - -
Usuario

116
 Entrega del Historial - -
del Usuario

Consulta evaluación
de Transacción Simple 5

Entrega de
Resultado Simple 5

Evaluar Transacción Medio 10

Activar/ desactivar
Aplicación Medio 10

Actualizar Nombre - -

Actualizar Patrón de
Seguridad - -

Actualizar Fono - -

Actualizar Mail - -

Actualizar Análisis
de sensibilidad - -

Confirmar
Transacción Medio 10

UUCW = 45

UUCP = UAW + UUCW

50 = 5 + 45

Obs: Los casos de usos con guiones en sus ponderaciones no se consideraron dentro de la
estimación pues caen dentro pues poseen funcionalidades que ya están siendo estimadas.

12.3.1.2 Puntos de casos de uso ajustado (UCP)

UCP : Puntos de casos de uso ajustados.
UUCP : Puntos de casos de uso sin ajustar.
TCF : Factores técnicos.
EF : Factores ambientales.
UCP = UUCP x TCF x EF

117
 Factor de complejidad técnica
Factor Relevancia Peso Valor

Sistema distribuido Esencial 2 5

Tiempo de respuesta Esencial 1 5

Eficiencia del usuario final Irrelevante 1 2

Procesamiento interno Medio 1 3

complejo

El código debe ser Irrelevante 1 0

reutilizable

Facilidad de instalación Medio 0.5 3

Facilidad de Uso Medio 0.5 3

Portabilidad Medio 2 4

Facilidad de cambio Irrelevante 1 2

Concurrencia Medio 1 3

Incluye objetivos especiales Medio 1 3

de seguridad

Provee acceso directo a Irrelevante 1 2

terceras partes

Se requiere facilidades
especiales de entrenamiento Irrelevante 1 0
a usuario.

TFactor =
(1*0)+(1*2)+(1*3)+(1*3)+(1*2)+(2*4)+(0.5*3)+(0.5*3)+(1*0)+(1*3)+(1*2)+(1*5)+(2*5)
TFactor = 41

TFactor = Sum (Valor x Peso)

TCF = 0.6 + (0.01 x TFactor)
TCF = 0.6 + (0.01 x 43)
TCF = 1.01

118
119
  Factores ambientales
Factor Relevancia Peso Valor

Familiaridad con el modelo Medio 1.5 4

del proyecto utilizado

Experiencia en la aplicación Medio 0.5 3

Experiencia en la Medio 1 3
orientación a objetos

Capacidad del analista líder Medio 0.5 3

Motivación Medio 1 4

Estabilidad de los Irrelevante 2 2

requerimientos

Personal part-time Irrelevante -1 0

Dificultad del lenguaje de Irrelevante -1 3

programación

EFactor = (-1*2)+(-1*0)+(2*2)+(1*4)+(0.5*3)+(1*3)+(0.5*3)+(1.5*4)
EFactor = 17

EFactor = Sum (Valor x Peso)

EF = 1.4 + (-0.03 x 17)
EF = 0.89

Cálculo Final de punto caso de uso ajustado

UCP = UUCP x TCF x EF

UCP = 50 x 1.01 x 0.89
UCP = 44,945

La cantidad de horas personas (CF) según la tabla de factores ambientales es de 20.

Obs: Existe un factor entre los 6 primeros menor a 3 y entre el factor 7 y 8 existe un valor mayor a 3 de
ese análisis se calcula las hora personas (CF).

120
Cálculo de esfuerzo requerido
E : Esfuerzo estimado en horas-persona.

UCP : Puntos de Casos de Uso ajustados.

CF : Horas-Persona.

E = UCP x CF

E = 44,945 x 20

E = 898,9 Horas Hombres.

Al realizar esta multiplicación, se consigue un esfuerzo estimado que representa una parte total
del esfuerzo de todo el proyecto, en este caso corresponde a un 40 %, este porcentaje se refiere
al esfuerzo total para el desarrollo de las funcionalidades especificas en los casos de uso.
En la siguiente tabla se detalla la distribución de los porcentajes aproximados para el total del
esfuerzo del proyecto.

Actividad Porcentaje

Investigación 7%

Análisis 12%

Diseño 15%

Programación 50%

Pruebas 6%

Documentación 10%

Cálculo total del esfuerzo requerido para el proyecto:

EsfuerzoTotal = (E x 100) /40

EsfuerzoTotal = (898,9 x 100) /50
EsfuerzoTotal = 1797,8 Horas Hombres

12.4 Estimación del Tamaño final del Software

12.4.1 Punto de función como metodología de estimación de tamaño

121
12.4.1.1 Tabla de evaluación de componentes básicos del sistema

Categoría Cantidad Simple Media Compleja Punto Caso

Total X3 X7 X15 Función
Entradas 3 3 - - 9

Salidas 1 - 1 - 7

Interacciones 6 - 6 - 42
con el usuario

Interfaces 1 - 1 - 7
Externas

Archivos 2 - 7 - 14
Utilizados por el
Sistema
79
TOTAL FP (Funtion Points)

12.4.1.2 Tabla de Evaluación de Aspectos Generales del Sistema

N° Factor Ambiental Ranking

1 ¿Se requiere comunicación de datos? 5

2 ¿Existen funciones o procedimientos distribuidos? 5

3 ¿Es crítico el rendimiento? 4

4 ¿Se ejecutará el sistema en un entorno operativo 0

existente y fuertemente utilizado? ¿Hay
restricciones de plataformas?
5 ¿El sistema tendrá una carga transaccional alta o 5
baja?

6 Nivel de Disponibilidad 2

7 Eficiencia del Usuario Final Requerida (Usabilidad)

8 Actualización en Línea 2

122
 9 Complejidad de procesamiento 5

10 ¿El sistema debe estar diseñado e implementado 1

para ser reutilizable?
11 ¿El sistema debe estar diseñado para ser fácil de 3
instalar y de portar?

12 Facilidad de Uso 2

13 ¿El sistema debe soportar múltiples instalaciones 4

en diferentes organizaciones?
14 ¿El sistema debe estar diseñado e implementado 3
para facilitar cambios?
43
TOTAL N

Cálculo CAF (Complexity Adjustment Factor)

CAF = 0,65 + (0,01* N)

CAF = 0,65 + (0,01 *43)
CAF = 1,08

Cálculo de AFP (Adjusted Funtion Points)

AFP = FP * CAF
AFP = 79 * 1,08
AFP = 85,32

Cálculo de SLOC (Source Lines Of Code)

Según el lenguaje de programación y los puntos de función podemos determinar la cantidad

de líneas de códigos necesarias para la totalidad del proyecto

Tabla de evaluación puntos de función según QSM

SLOC = AFP * Factor Lenguaje de programación

SLOC = 67 * 85,32

123
SLOC = 5716

Cálculo Esfuerzo requerido Productividad Hombre-Mes

Productividad Hombre-Mes = Líneas de Código / Meses de Programación
Productividad Hombre-Mes = 5716/ 4
Productividad Hombre-Mes = 1429

12.4.2 Contabilización real del Software en líneas de códigos

Aplicación de Confirmación de Transacciones

Paquete de Datos Líneas de código

Principal 1429

Comunicación 591

Data 350

List-Menú 188

Seguridad 97

Setup User 2017

TOTAL 4602

Sistema de Evaluación de Transacciones

Paquete de Datos Líneas de Código

Principal
1303
Entrada/ Salida 450

Evaluación 256

Comunicación 1469

TOTAL 3478

124
Servicio Web de Comunicación

Clase Líneas de Código

TransaccionWebService 743

Sistema Global

Sub-sistema Líneas de Código

Aplicación de Confirmación 4602

Sistema Evaluador 3478

Servicio Web 743

TOTAL 8823

8823 representa la totalidad de las líneas de códigos en el Software, si bien es cierto que
esta cifra no es del todo exacta pues se contabilizó las líneas de comentarios, líneas en
blanco y se generó líneas de código mediante los Entornos de Desarrollo Integrados
(Eclipse).

Si hacemos el descuento aproximado tenemos lo siguiente:

Líneas de comentario y en Blanco = 300

Líneas de código generado = 1800

Líneas de Código = 8823 – (300+1800)

Líneas de Código = 6923

Cálculo de esfuerzo requerido Productividad Hombre-Mes

Productividad Hombre-Mes = Líneas de Código / Meses de Programación

Productividad Hombre-Mes = 6923 / 4
Productividad Hombre-Mes = 1730

125
Comparación entre Tamaño de Software y Esfuerzo requerido estimado y real

Líneas de Código Esfuerzo Requerido

Hombre-Mes
Estimado 5716 1429

Real 6823 1730

DIFERENCIA 1107 301

126
12.5 Estimación del beneficio del sistema

Hoy en día son 14 Bancos los que operan en chile y son fiscalizados por la
superintendencia de bancos e instituciones financieras, la suma del total de tarjetas
titulares que se utiliza en ATM pertenecientes a estas 14 instituciones es de 14.438.504
esta cifra representa el universo de la estimación, es decir la totalidad de tarjetas que
pueden ser afectadas por clonación, sin embargo el porcentaje de clonación es menor
a esa cifra, en base a la información que se recopiló durante este proceso podemos
decir que cerca del 0,05% de la totalidad de los usuarios son afectados por este ilícito
anualmente. Por otro lado según un estudio hecho por la consultora IDC la plataforma móvil
Android tiene un porcentaje de participación en el mercado de un 68,1%.

Usuarios

Android IOS BlackBerry Windows

En base a estos antecedentes podemos estimar el número de usuario que sería beneficiado por
el sistema:

14.438.504 x 68,1% = 9.832.621 Usuarios del Sistema

Ahora calculamos los beneficiarios del sistema:

9.832.621 x 0.05% = 4917 Beneficiarios Anualmente

127
Calculando el beneficio para los bancos según el monto mínimo y monto máximo permitidos en
una transacción de giro, y suponiendo que por cada clonación de tarjeta existe una transacción
fraudulenta.

Beneficio Mínimo:
4917 x $4.000 = $19.668.000 Anuales
Beneficio Máximo:
4917 x $200.000 = $983.400.000 Anuales

Si bien es cierto es cierto esta estimación está basada en la totalidad de los bancos asociados
a la superintendencia de bancos e instituciones financieras, podemos hacer la misma estimación
para cada banco en particular, pues cada institución es independiente una de la otra y es libre
de manipular sus cajeros y sus sistemas de detección de fraudes.

Institución Tarjetas Usuarios Beneficiarios Beneficio Beneficio Beneficio

ATM Mínimo Máximo Promedio
Banco Bice 79.999 54.479 27 108959 5447.932 2.778.445

Banco BBVA 216.616 147.515 74 295.031 14.751.550 7.523.290

Banco de Chile 2.168.914 1.477.030 739 2.954.061 147.703.043 75.328.552

Banco de 1.549.820 1.055.427 528 2.110.855 105.542.742 53.826.798

Crédito e
Inversiones
Banco del 6.213.755 4.231.567 2116 8.463.134 423.156.716 215.809.925
Estado de Chile
Banco 494.525 336.772 168 673.543 33.677.153 17.175.348
Falabella
Banco 12 8 0 16 817 417
Internacional
Banco Itaú 121.108 82.475 41 164.949 8.247.455 4.206.202
Chile
Banco 3.006.786 2.047.621 1024 4.095.243 204.762.127 104.428.685
Santander-
Chile
Banco Security 63.423 43.191 22 86.382 4.319.106 2202.744
0 0 0 0 0 0
Banco Paris

128
Corpbanca 256.229 174.492 87 348.984 17.449.195 8.899.089

Coopeuch 21.403 14.575 7 29.151 1.457.544 743.348

Scotiabank 236.842 161.289 81 322.579 16.128.940 8.225.760

Chile
Banco 9.072 6.178 3 12.356 617.803 315.080
Consorcio

129
13 ANEXO B: RED DE CAJEROS AUTOM ÁTICOS

13.1 ¿Qué es un Cajero Automático?

Los cajeros automáticos, originalmente llamados ATM (Automatic Teller Machine o

Maquina de cajero Automático) son dispositivos electrónicos que permiten a los
clientes de un banco hacer retiro de efectivo y ver sus estados de cuentas, depositar
efectivos o cheques, transferir dinero de entre diferentes cuentas de bancos,
utilizando tarjeta con chip incorporado o banda magnética, a cualquier hora del día
los 365 días del año, sin necesidad de ir al banco.
Los cajeros automáticos varían dependiendo de la necesidad de cada banco.
Principalmente se dividen en dos tipos: Full y Cash los cajeros automáticos Full son
aquellos que permiten extraer dinero como así también realizar depósitos (mediante
sobres comúnmente). Estos cajeros suelen estar dentro de los bancos ya sea sólo o
con alguno más que pueden ser Full o Cash, pero este suele ser el cajero principal de
la sucursal.

13.2 ¿Cómo funciona?

Un lector de tarjetas captura la tarjeta de crédito o débito y lee la información del

cliente contenida en el chip incorporado o en la banda magnética que está en la parte
trasera. Los datos se envían a una computadora central.
Con la ranura de recibo tiene la opción de imprimir o no el recibo de la operación. La
pantalla informa cada paso del proceso: Algunos ATM usan monitores CRT, otros, una
pantalla LCD. El parlante (algunos lo tienen). Repite instrucciones cuando se aprieta
una tecla y también da informaciones concernientes al banco. Los botones de pantalla
son los que dicen al banco que tipo de transacción se requiere.
El mecanismo que da el efectivo tiene incorporado un sensor que cuenta cada billete
una vez que se solicita la cantidad deseada. Otro sensor evalúa el grosor de cada
papel moneda: si los billetes vienen pegados o rasgados, son retenidos. Este conteo
y los datos de la transacción son grabados en un diario electrónico.

130
13.3 Componentes de un ATM

Los principales componentes de un ATM son:

 Lector de Tarjetas: Captura la tarjeta de crédito o débito y lee la información

del cliente contenida en dicha tarjeta (Banda magnética y/o Chip), estos datos
son enviados a una central de datos.

 Ojo electrónico: Es el mecanismo que da el efectivo, tiene incorporado un

sensor que discrimina cada billete.

 Parlante: Algunos ATM poseen un parlante en donde se escucha

instrucciones cuando se presiona un botón y también la información que está
en pantalla.

 Pantalla: Informa al usuario cada paso del proceso en forma visual. El tipo de
pantalla depende del ATM (LCD o CRT).

 Teclado: Permite escribir el número de identificación personal. Por ley se

requiere que el PIN (Contraseña) sea enviado al procesador central
encriptado.

 Botones de Pantalla: Otorgan al usuario la usabilidad del ATM e informa al

banco el tipo de transacción que se está ejecutando.

 Ranura de Depósito: Algunos ATM cuentan con esta ranura, aquí es donde
se depositan los sobres para generar depósitos.

 Ranura de Efectivo: Es la ranura en donde sale el dinero tras un eventual

giro.

 Ranura de Recibo: Es la ranura donde sale el recibo que imprime los datos
de la transacción, es opcional.

131
 Figura: Ilustración de un Cajero Automático ATM

13.4 Historia

El primer ATM del mundo fue producido por la firma NCR e instalado en Londres el
27 de junio de 1967, por Barclays Bank. La invención se le atribuye a John Shepherd
Barron, Al principio el proceso se tardaba mucho y no requería de una clave especial,
lo que se prestaba al fraude, por eso los cajeros automáticos actuales deben
autentificar a los clientes por medio de una clave numérica llamada PIN.

13.5 Características Técnicas Estándar

 Pantalla TFT color de 15”.

 12 botones laterales de función indicada en pantalla.
 Doble lector motorizado de tickets de cartulina de tamaño ISO (54 x 86mm) con
código de barras.
 Impresora térmica de alta velocidad para escritura tickets
 de salida. Detector de poco papel / sin papel.
 Lector de billetes de 4 billetes por las 4 caras.

132
  Depósito de 500 billetes, con llave.
 SAI para garantizar el correcto funcionamiento incluso con cortes de luz.
 Cerradura mecánica de alta seguridad.
 Puede funcionar de forma autónoma, pero unido al puesto de control mediante
LAN puede controlarse remotamente
 Medidas con peana: 190cm de alto, 90 de ancho, 43 de profundo.
 Alimentación: 220V 1A, máx 1.5A

13.6 Red de ATM en Chile

En chile existe una amplia red de cajeros automáticos, encontramos ATM en

prácticamente todas las ciudades, son alrededor de 9.000 ATM distribuidos a lo largo
del país que pertenecen al consorcio de bancos chilenos y que son regularizados por
la superintendencia de bancos (SBIF).
En la actualidad estas redes de cajeros automáticos se presentan bajo dos tipos de
servicios:

 Red Bancaria Interconectada (RBI).

 Red de Servicios Financieros (RSF).

13.6.1 Red Bancaria Interconectada (RBI)

El principal objetivo de esta red de servicio es facilitar una estructura que permita
reducir costos operacionales de las comunicaciones para la ejecución de
transferencias de fondos e información de bancos, instituciones financieras y
(Sociedad de Apoyo al Giro Bancario) SAGs, así aumentar la calidad del servicio en
una única conexión.

Servicios:

 Transferencia de archivos electrónicos y conversión de protocolos/formatos

(STI).
 Entregar seguridad, encriptación y confidencialidad de la información, y
restringiendo el acceso a ella, sólo al originador y su destinatario.
 Información permanente a los integrantes de la RBI del estado operativo de
la Red.

133
  Servicio seguro por rutas de acceso.
 Monitoreo y administración de recursos técnicos.

Beneficios:

 Disminuye costos operacionales.

 Modelo de seguridad aprobado en conjunto de todos los integrantes de la
RBI.
 Utiliza protocolo de comunicación estándar TCP/IP

13.6.2 Red de Servicios de Financieros (RSF)

La red de Servicios Financieros (RFS) es una infraestructura de comunicaciones
privada que permite conectar las instituciones no bancarias con los bancos,
instituciones financieras o SAGs que participan de la Red Bancaria Interconectada
(RBI), es decir instituciones que proveen servicios de apoyo a la industria financiera
o reciben servicios de apoyo de ésta.

Servicio:
 Provee interoperabilidad entre el Servidor RFS y los partícipes y Servidores
RBI.

Beneficios:
 Disminuye costos operacionales.
 Modelo de seguridad aprobado en conjunto de todos los integrantes de la
RBI.
 Optimiza el uso de los recursos tecnológicos.

13.6.3 Bancos Asociados a la Superintendencia de Bancos e Instituciones

Financieras en Chile

 Banco Bice
 Banco Bilbao Vizcaya Argentaria, Chile(BBVA)
 Banco de Chile
 Banco de Créditos e Inversiones

134
  Banco del Estado de Chile
 Banco Falabella
 Banco Internacional
 Banco Itaú Chile
 Banco Santander-Chile
 Banco Security
 Banco Paris
 CorpBanca
 Coopeuch
 Scotiabank Chile
 Banco Consorcio

13.6.3.1 Número de tarjetas ATM por Emisor para Debito y uso en ATM.

Banco Tarjetas Tarjetas Total Tarjetas

Titulares Adicionales
Banco Bice
79.999 2.859 82.858

Banco Bilbao Vizcaya Argentaria,

Chile 216.616 39.004 255.620

Banco de Chile
2.168.914 181.103 2.350.017

Banco de Crédito e Inversiones

1.549.820 93.058 1.642.878

Banco del Estado De Chile

6.213.755 60.028 6.273.783

Banco Falabella
494.525 1.746 496.271

Banco Internacional
12 1 13

Banco Itaú Chile

121.108 28.431 149.539

Banco Santander-Chile
3.006.786 122.391 3.129.177

Banco Security
63.423 6.397 69.820

Banco Paris - - -
Corpbanca
256.229 18.681 274.910

135
 Scotiabank Chile
21.403 316 21.719

Banco Consorcio
236.842 13.424 250.266

TOTAL 14.438.504 567.439 15.005943

Información referida a Diciembre de 2012

13.6.3.2 Números de Cajeros Automáticos por Institución Financiera por Región

REGIONES Total
Instituciones I II III IV V VI VII VIII IX X XI XII R.M. XIV XV País
Banco Bice - 1 - - - 1 1 5 1 1 - - 11 - - 21
Banco Bilbao Vizcaya
3 19 4 11 54 11 19 30 14 11 3 5 236 5 4 429
Argentaria, Chile

Banco de Chile 36 76 30 59 175 101 55 122 49 75 7 19 1.126 30 16 1.976

Banco de Crédito e
22 72 23 36 139 45 47 84 38 50 13 13 508 14 9 1.113
Inversiones

Banco del Estado de

28 51 33 72 201 77 83 160 87 85 10 33 817 54 21 1.812
Chile

Banco Falabella 3 8 3 5 17 4 9 18 6 7 1 2 99 3 1 186

Banco Internacional - - - - 1 - - - - - - - 4 - - 5
Banco Itaú Chile 1 6 1 - 3 7 1 3 1 3 - 1 21 1 - 49
Banco Santander-Chile 45 76 27 64 217 65 80 243 129 95 6 25 884 34 28 2.018
Banco Security - 2 - - 1 - - 1 1 2 - - 7 - - 14
Banco Sudamericano - - - - - - - - - - - - 2 - - 2
Corpbanca 4 22 19 37 27 19 24 33 24 5 - 9 150 8 1 382
Hsbc Bank (Chile) - - - - - - - - - - - - 15 - - 15
Scotiabank Chile 2 9 3 4 25 9 7 12 5 5 - 1 90 3 3 178
TOTAL REGION 144 342 143 288 860 339 326 711 355 339 40 108 3.970 152 83 8.200

Información referida a Diciembre de 2010

136
14 ANEXO C: MANU AL DE USUARIO

14.1 ¿Qué es AnaliSystem?

Analisystem es un sistema de detección de fraudes que te permite prevenir un fraude con

algún tipo de riesgo asociado, principalmente consiste en dos sub-sistemas, la primera
analiza cada transacción de giro realizada en un cajero y esta se comunica con el otro
sub-sistema que es una aplicación de manera que requerirá una confirmación de aquellas
transacciones que estén fuera de lo habitual.

14.2 Conociendo la interfaz gráfica de usuario

Menú Principal

Activar Protección

137
 Configurar Cuenta

Notificación de Transacción en Curso

Patrón de Seguridad

138
14.3 Requerimientos básicos del dispositivo móvil

La primera versión de AnaliSystem Mobile está diseñada y desarrollada para dispositivos

móviles con sistema operativo Android, esta aplicación corre desde la versión 2,2 Froyo
con conectividad a WiFi.

14.4 Preguntas Frecuentes

14.4.1 ¿Cómo activar la protección?

Muy Simple en el menú principal hay una opción que dice Activar Protección, una vez
presionado saldrá el estado de la aplicación basta con presionar el estado para activar
o desactivar según sea el caso,
Nota: En caso de desactivar la protección se requerirá que ingrese el patrón de seguridad
del sistema.

14.4.2 ¿Cómo configurar mi cuenta?

En el menú principal selecciona la opción configurar cuenta en esta te saldrán las

siguientes opciones:

 Cambiar Nombre: Actualiza tu nombre de pila.

 Cambiar Fono: Actualiza tu número telefónico.
 Cambiar Mail: Actualiza tu correo electrónico de contacto.
 Cambiar Número de cuenta: Este campo requiere que siempre se mantenga en
el número de tu cuenta, no debes cambiarlo.
 Cambiar Nivel de protección: Actualiza el nivel de protección que quieras.
 Cambiar patrón de seguridad: Actualiza el patrón de seguridad, recuerda que el
patrón de seguridad es un mecanismo que seguridad, se te solicita cada vez que
quieras desactivar la protección o confirmar una transacción.
 Estado de aplicación: Corresponde al estado actual de la protección.
 Consultar última Transacción: Te muestra los datos de la última transacción que
analizó el sistema.

139
14.4.3 ¿Qué es el nivel de protección?

El nivel de protección es una forma de asegurar las cuentas de manera personalizada,

en términos prácticos es la sensibilidad del análisis que se realizará.

14.4.4 ¿Puedo rechazar una transacción que no esté realizando yo?

La Finalidad del Sistema es esa, que el usuario tenga el privilegio de rechazar una
transacción y que este pueda reportar a la brevedad una transacción que sea cancelada.

14.4.5 ¿Tengo una cuenta corriente y además en mi familia poseen una cuenta adicional
a la mía, pueden obtener la seguridad del sistema?

La Primera versión de AnaliSystem está diseñada solo para cuentas titulares, las
adicionales de momento no, en una próxima versión AnaliSystem cubrirá la totalidad de
tarjetas de créditos y débitos.

14.4.6 ¿Necesito estar siempre conectado a internet?

Analisystem Mobile está diseñado para que el dispositivo móvil esté conectado en su
totalidad a una red WiFi, pero como es prácticamente imposible que ocurra esto, basta
con activar la aplicación y no se realizará ninguna transacción, salvo que el usuario lo
confirme, en el caso que el usuario no se encuentre conectado a alguna red WiFi el
sistema automáticamente cancelará la transacción para evitar conflictos en un
transacción legitima estarán habilitados puntos de WiFi en los cajeros automáticos.

140
15 ANEXO D: REDES NEURONALES ARTIFICI ALES

15.1 Redes Neuronales Artificiales

15.1.1 Redes Neuronales Artificiales concepto y evolución

Las redes neuronales artificiales (RNA su sigla en Inglés) es un paradigma de

aprendizaje y procesamiento de la información basado en el modelo del sistema
nervioso biológico, especialmente en la forma de funcionamiento del cerebro
humano que es completamente distinto a la forma de procesar de una computadora
convencional. El cerebro humano corresponde a un sistema altamente complejo, no-
lineal y paralelo, en otras palabras se pueden ejecutar simultáneas tareas a
diferencia del computador convencional que es secuencial, es decir realiza una tarea
a la vez.
Los primeros modelos de redes neuronales datan de 1943 por los neurólogos
McCulloch y Pitts. Años más tarde, en 1949, Donald Hebb desarrolló sus ideas sobre
el aprendizaje neuronal, quedando reflejado en la Regla de Hebb. En 1958,
Rosemblatt desarrolló el Perceptrón Simple, y en 1960, Widrow y Hoff desarrollaron
el Adaline, que fue la primera aplicación industrial real.
En los años siguientes, se redujo la investigación, debido a la falta de modelos de
aprendizaje y el estudio de Minsky y Papert sobre las limitaciones del Perceptrón.
Sin embargo, en los años 80, volvieron a resurgir las RNA gracias al desarrollo de
la red de Hopfield, y en especial, al algoritmo de aprendizaje de retropropagación
ideado por Rumelhart y McLellan en 1986 que fue aplicado en el desarrollo de los
perceptrones multicapa.

15.1.2 Componentes y características de una RNA

Una red neuronal artificial consiste en un conjunto de elementos simples de

procesamiento llamados nodos o neuronas interconectados entre sí, por conexiones
que tienen un valor numérico llamado peso (w) que se va modificando el proceso
llamado aprendizaje.
La actividad que una unidad de procesamiento o neurona artificial realiza en un
sistema
de este tipo es simple. Normalmente, consiste en sumar los valores de las entradas
(Inputs) que recibe de otras unidades conectadas a ella, comparar esta cantidad con

141
 el valor umbral y, si lo iguala o supera, enviar activación o salida (output) a las
unidades a las que esté conectada. Tanto las entradas que la unidad recibe como
las salidas que envía dependen a su vez del peso o fuerza de las conexiones por
las cuales se realizan dichas operaciones.
Las características principales de las redes neuronales artificiales son las siguientes:
 Auto-Organización y Adaptabilidad: Utilizan algoritmos de aprendizaje
adaptativo y auto-organización, por lo que ofrecen mejores posibilidades de
procesado robusto y adaptativo.
 Procesado no Lineal: Aumenta la capacidad de la red para aproximar
funciones, clasificar patrones y aumenta su inmunidad frente al ruido.
 Procesado Paralelo: Normalmente se usa un gran número de nodos de
procesado, con alto nivel de interconectividad.

15.1.3 Topología

Una primera clasificación de las redes de neuronas artificiales que se suele hacer
es en función del patrón de conexiones que presenta. Así se definen tres tipos
básicos de redes:
Dos tipos de redes de propagación hacia delante o acíclicas en las que todas las
señales van desde la capa de entrada hacia la salida sin existir ciclos, ni conexiones
entre neuronas de la misma capa de red neuronal y su clasificación.
Monocapa. Ejemplos: perceptrón, Adaline.
Multicapa. Ejemplos: perceptrón multicapa.
Las redes recurrentes que presentan al menos un ciclo cerrado de activación
neuronal. Ejemplos: Elman, Hopfield, máquina de Boltzmann.

15.1.4 Aprendizaje

Una segunda clasificación que se suele hacer es en función del tipo de aprendizaje
de que es capaz (si necesita o no un conjunto de entrenamiento supervisado). Para
cada tipo de aprendizaje encontramos varios modelos propuestos por diferentes
autores:
Aprendizaje supervisado: necesitan un conjunto de datos de entrada previamente
clasificado o cuya respuesta objetivo se conoce. Ejemplos de este tipo de redes son:

142
 el perceptrón simple, la red Adaline, el perceptrón multicapa, red backpropagation,
y la memoria asociativa bidireccional.
Aprendizaje no supervisado o autoorganizado: no necesitan de tal conjunto previo.
Ejemplos de este tipo de redes son: las memorias asociativas, las redes de Hopfield,
la máquina de Boltzmann y la máquina de Cauchy, las redes de aprendizaje
competitivo, las redes de Kohonen o mapas autoorganizados y las redes de
resonancia adaptativa (ART).
Redes híbridas: son un enfoque mixto en el que se utiliza una función de mejora
para facilitar la convergencia. Un ejemplo de este último tipo son las redes de base
radial.
Aprendizaje reforzado: se sitúa a medio camino entre el supervisado y el
autoorganizado.

15.1.5 Tipo de entrada

Finalmente también se pueden clasificar las RNAs según sean capaces de procesar
información de distinto tipo en:
Redes analógicas: procesan datos de entrada con valores continuos y,
habitualmente, acotados. Ejemplos de este tipo de redes son: Hopfield, Kohonen y
las redes de aprendizaje competitivo.
Redes discretas: procesan datos de entrada de naturaleza discreta; habitualmente
valores lógicos booleanos. Ejemplos de este segundo tipo de redes son: las
máquinas de Boltzmann yCauchy, y la red discreta de Hopfield.

15.1.6 Aplicaciones

Las características de las RNA las hacen bastante apropiadas para aplicaciones en
las que no se dispone a priori de un modelo identificable que pueda ser programado,
pero se dispone de un conjunto básico de ejemplos de entrada (previamente
clasificados o no). Asimismo, son altamente robustas tanto al ruido como a la
disfunción de elementos concretos y son fácilmente paralelizables.
Esto incluye problemas de clasificación y reconocimiento de patrones de voz,
imágenes, señales, etc. Asimismo se han utilizado para encontrar patrones de
fraude económico, hacer predicciones en el mercado financiero, hacer predicciones
de tiempo atmosférico, etc.
También se pueden utilizar cuando no existen modelos matemáticos precisos o

143
 algoritmos con complejidad razonable, por ejemplo la red de Kohonen ha sido
aplicada con un éxito más que razonable al clásico problema del viajante (un
problema para el que no se conoce solución algorítmica de complejidad polinómica).
Otro tipo especial de redes neuronales artificiales se ha aplicado en conjunción con
los algoritmos genéticos (AG) para crear controladores para robots. La disciplina que
trata la evolución de redes neuronales mediante algoritmos genéticos se
denomina Robótica Evolutiva. En este tipo de aplicación el genoma del AG lo
constituyen los parámetros de la red (topología, algoritmo de aprendizaje, funciones
de activación, etc.) y la adecuación de la red viene dada por la adecuación del
comportamiento exhibido por el robot controlado (normalmente una simulación de
dicho comportamiento).

144
145