DESARROLLO-DE-GATEWAY-ISO8583

Vista previa del material en texto

INSTITUTO POLITÉCNICO NACIONAL 
UNIDAD PROFESIONAL ZACATENCO 
 
 
 
DESARROLLO DE GATEWAY 
CORRESPONSAL BANCARIO 
ISO8583 
 
REPORTE MEMORIA 
 
QUE PARA OBTENER EL GRADO DE 
INGENIERO EN COMUNICACIONES Y ELECTRÓNICA PRESENTA: 
 
PABLO BENJAMIN NIETO MERCADO 
 
ASESOR : DR. RABINDRANATH RESÉNDIZ VÁZQUEZ 
 
MÉXICO D.F. SEPTIEMBRE 2015
Dedicatoria 
 
 
II 
 
 
 
 
Dedicatoria 
 
A mi Madre María Gricela Mercado Maceda, por su gran valentía 
y amoroso apoyo incondicional. 
 
A mi Padre Enrique Nieto Flores, por su amor y protección. 
 
A mi hermano Irving Enrique Nieto Mercado, por su gran cariño, 
complicidad y resistencia. 
 
A mis ancestros, por lo que me forma. 
 
A mis maestros y amigos, por sus enseñanzas y amistad. 
 
A la vida. 
 Índice 
 
 
III 
 
Índice 
Dedicatoria II 
Índice de Figuras y Tablas VI 
Introducción IX 
Objetivo XI 
Justificación XII 
Capitulo 1.- Corresponsalía bancaria modelo de inclusión financiera en México 1 
Capitulo 2.- Gateway ISO8583 sistema de corresponsalía bancaria 4 
 2.1.- Responsabilidades a cargo dentro del proyecto 6 
 2.2.- Objetivos a perseguir en el desarrollo del proyecto 7 
 2.3.- Observaciones 7 
Capitulo 3.- Fundamentos para el desarrollo de un sistema informático 8 
transaccional de corresponsalía bancaria 
 3.1.- Lenguaje de programación, Visual Basic. Net 9 
 3.2.- Corresponsal Bancario 10 
 3.2.1.- Requisitos para ser corresponsal 11 
 3.2.2.- Actividades que pueden realizar los corresponsales 12 
 3.2.3.- Actividades que no pueden realizar los corresponsales 13 
 3.2.4.- Esquema de operación con cargo al corresponsal 14 
 3.2.5.- Resumen de requerimientos por tipo de operación 15 
 3.3.- Estándar ISO8583 17 
 3.4.- Arquitectura de software 19 
 3.4.1.- Programación por capas 20 
 3.4.2.- Capas o niveles 21 
 3.4.3.- Modelos o vistas 23 
Capitulo 4. Proceso de desarrollo de Gateway ISO8583 corresponsal bancario 25 
 4.1.- Análisis de especificaciones del proyecto 27 
 4.2.- Diseño de arquitectura del sistema Gateway ISO8583 39
 Índice 
 
 
IV 
 
 4.3.- Diagrama de arquitectura 43 
 4.4.- Casos de uso del sistema 44 
 4.5.- Actores del sistema 45 
 4.6.- Flujo Caso de Uso Depósito 47 
 4.7.- Flujo Caso de Uso Reverso 51 
 4.8. Diagramas de Proceso 54 
 4.8.1 Diagrama de Proceso Depósito 55 
 4.8.2 Diagrama de Proceso Reverso 56 
 4.9. Vistas de la Arquitectura 60 
 4.9.1- Vista Lógica 60 
 4.9.2.- Vista Paquetes 61 
 4.9.3.- Vista de Componentes 63 
 4.10.- Mensajería ISO8583 Corresponsal Bancario 65 
 4.10.1.- Definición de mensajería de corresponsalía bancaria 67 
 4.10.2.- Servicio de autorización 68 
 4.10.3.- Servicio de reverso 69 
 4.10.4.- Servicio de echos 70 
 4.10.5.- Estructura de mensajes ISO8583 71 
 4.10.5.1.- Longitud del mensaje 72 
 4.10.5.2.- Header del mensaje 73 
 4.10.5.3.- Mapas de Bits (Bitmaps) 73 
 4.10.5.4.- Campos de mensajería ISO8583 74 
 4.10.6.- Definición de campos de mensajería ISO8583 75 
 4.10.7.- Estructura de mensajes ISO8583 de corresponsalía bancaria 78 
 4.10.8.- Ejemplos de tramas ISO8583 79 
 4.10.8.1.- Ejemplo Trama Depósito 80 
 4.10.8.2.- Ejemplo Trama Reverso 81 
 4.10.8.3.- Ejemplo Trama Echo 82 
 4.11.- Programación de Gateway ISO8583 83 
 4.12.- Probando el funcionamiento de Gateway ISO8583 85 
4.12.1.- Pruebas de comunicación hacia Tiendas X y Banco Y 86 
 Índice 
 
 
V 
 
4.12.2.- Pruebas para validar recepción, contenido y estructura 88 
de los mensajes de Tiendas X 
 4.12.3.- Pruebas de envío de mensajes de Gateway ISO8583 hacia Banco Y 91 
4.12.4.- Pruebas para validar recepción, contenido y estructura 92 
de los mensajes de Banco . 
4.12.5.- Pruebas de envío de mensajes de respuesta de 95 
Gateway ISO8583 hacia Tiendas X 
 4.12.6.- Pruebas masivas de envío y recepción de transacciones 95 
 4.12.7.- Pruebas en ambiente real 96 
 4.12.7.1 Ejemplo de una transacción 96 
 4.12.7.2 Ejemplo una transacción de Reverso 101 
Conclusiones 106 
Bibliografía 107 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Índice de Figuras y Tablas 
 
 
VI 
 
Índice de Figuras y Tablas 
 
Figura Descripción Pagina 
3.1. Principales Actores 10 
3.2.4 Esquema de operación con cargo al corresponsal 14 
3.3 Estructura de un mensaje ISO8583 18 
3.4.1 Distribución física de un sistema de tres capas 20 
4.6 Flujo de información entre entidades 32 
4.7 Conectividad a nivel protocolo entre Tiendas X y Gateway ISO8583 33 
4.8 Conectividad a nivel protocolo entre Gateway ISO8583 y Banco Y 34 
4.9 Canal SSL entre Gateway ISO8583 y Banco Y 35 
4.10 Mensajería ISO8583 entre "Tiendas X" y Gateway ISO8583 36 
4.11 Mensajería ISO8583 entre Gateway ISO8583 y Banco Y 37 
4.15 Diagrama de Arquitectura de tres capas Gateway ISO8583 43 
4.18 Actores y Casos de Uso del sistema 46 
4.19 Diagrama de flujo del caso de uso Depósito 50 
4.20 Diagrama de flujo del caso de uso Reverso 53 
4.22 Diagrama de proceso Depósito 55 
4.23 Diagrama de Validaciones Depósito 56 
4.25 Diagrama de proceso Reverso 58 
4.26 Diagrama de Validaciones Reversos 59 
4.27 Vista lógica de paquetes Gateway ISO8583 60 
4.28 Flujo de intercambio, validación y traducción de mensajes entre entidades 66 
4.30 Flujo Servicio de Autorización 68 
4.31 Flujo Servicio de Reversos 69 
4.32 Flujo Servicio de Echos 70 
4.46 Conectividad y flujo de información entre Tiendas X y Banco Y 86 
4.53 Flujo Depósito 96 
4.58 Flujo Reverso 101 
 Índice de Figuras y Tablas 
 
 
VII 
 
Tabla Descripción Pagina 
3.2.1 Requisitos para ser corresponsal bancario 11 
3.2.2 Actividades que pueden realizar los corresponsales 12 
3.2.3 Actividades que no pueden realizar los corresponsales 13 
3.2.5 Requerimientos Tecnológicos 15 
4.1 Etapas y responsables del proyecto 26 
4.2 Resumen de especificaciones del sistema de Tiendas X 28 
4.3 Resumen de especificaciones del sistema de Banco Y 29 
4.4 Limitantes de Comunicación entre Tiendas X y Banco Y 30 
4.5 Roles de comunicación de entidades 31 
4.12 Esbozo de la arquitectura del sistema 39 
4.13 Descripción y responsabilidades de capas del sistema 40 
4.14 Descripción y responsabilidades de los nodos del sistema 42 
4.16 Descripción de Casos de uso del sistema 45 
4.17 Descripción de Actores del sistema 45 
4.21 Validaciones transacción de Depósito 54 
4.24 Validaciones transacción de Reverso 57 
4.29 Servicios disponibles para Tiendas X y Banco Y 67 
4.33 Estructura de mensaje ISO858370 
4.34 Componentes del header del mensaje 72 
4.35 Ejemplos de Bitmaps y detalle 73 
4.36 Tipos de datos de los campos ISO8583 74 
4.37 Indicadores de longitud de los campos ISO8583 74 
4.38 Definiciones de campos ISO8583 corresponsalía bancaria 75 
4.39 Estructura de mensajes entre Tiendas X y Gateway ISO8583 78 
4.40 Estructura de mensajes entre Gateway ISO8583 y Banco Y 79 
4.41 Ejemplo Trama 0200 Depósito 80 
4.42 Ejemplo Trama 0420 Reverso 81 
4.43 Ejemplo Trama 0800 Echo 82 
4.44 Archivos resultado de la compilación del sistema Gateway ISO8583 83 
4.45 Paquetes codificados por capa 84 
 Índice de Figuras y Tablas 
 
 
VIII 
 
Tabla Descripción Pagina 
4.47 Transacción de deposito estructura completa 89 
4.48 Transacción de deposito estructura incompleta 90 
4.49 Transacción de deposito tipo de dato incorrecto 91 
4.50 Transacción de deposito estructura completa 92 
4.51 Transacción de deposito estructura incompleta 93 
4.52 Transacción de deposito tipo de dato incorrecto 94 
4.54 Mensaje de Depósito de Tiendas X a Gateway ISO8583 97 
4.55 Mensaje de Depósito de Gateway ISO8583 a Banco Y 98 
4.56 Mensaje de respuesta de Depósito de Banco Y a Gateway ISO8583 99 
4.57 Mensaje de respuesta de Depósito de Gateway ISO8583 a Tiendas X 100 
4.59 Mensaje de Reverso de Tiendas X a Gateway ISO8583 102 
4.60 Mensaje de Reverso de Gateway ISO8583 a Banco Y 103 
4.61 Mensaje de respuesta de Reverso de Banco Y a Gateway ISO8583 104 
4.62 Mensaje de respuesta de Reverso de Gateway ISO8583 a Tiendas X. 105 
 
 
 
 
 
 
 
 
 
 
 
 Introducción 
 
IX 
 
Introducción 
Desde que la humanidad empezó a ser productiva, cazando e implementando técnicas de 
agricultura y artesanía, se ha implementado el comercio e intercambio para conseguir algo 
que uno mismo no produce pero que alguien más sí. Desde hace 100,000 años, la 
humanidad ha creado diferentes tipos de economía y conforme ha pasado el tiempo se ha 
hecho más práctica y especializada, hoy en día se define como un medio admitido por un 
sistema económico. Puede ser monedas, billetes bancarios y otras formas diversas cuya 
característica principal es la de ser un instrumento de cambio y una medida de valor. 
 
La evolución de los medios de pago desde el siglo XIX hasta hoy ha sido enorme, desde un 
punto de vista practico y de control, especialmente a partir de la década de los años 60, 
haciendo uso de las tecnologías de la información y al desarrollo de la actividad financiera 
que vertiginosamente se ha acelerado en los últimos años, se ha permitido la incorporación 
de una diversidad de medios de pago, como los medios de pago electrónico, ceros y unos 
circulando por redes de comunicación, almacenados en medios físicos electrónicos en los 
cuales ahora creemos y respaldamos con la idea, sustitutivos de la moneda y billetes de 
curso legal que hasta hace algunos años tenían un respaldo o equivalente en minerales 
como el oro y la plata. 
 
Los medios de pago electrónicos más usuales son las tarjetas de crédito, débito y las tarjetas 
prepagadas. Con la tarjeta de crédito compras primero y pagas después al banco en la fecha 
pactada. Funciona como un préstamo que recibes del Banco que pagas días después y si te 
demoras pagas intereses. En cambio, con la tarjeta de débito pagas con el dinero que tienes 
en tu cuenta bancaria. Cuando se registra el pago que hiciste con tu tarjeta de débito, el 
banco te lo resta inmediatamente a tu cuenta. Con la tarjeta prepagada pagas antes de usar 
el servicio: por ejemplo, compras crédito para tu celular y después lo utilizas 
 Introducción 
 
X 
 
En el año 2010 en México la Comisión Nacional Bancaria y de Valores CNBV publicó la 
regulación que permite operar corresponsales bancarios1, término que hace referencia a un 
tercero que establece relaciones o vínculos de negocio con una institución de crédito con 
objeto de ofrecer, a nombre y por cuenta de ésta, servicios financieros a sus clientes. Al 
permitir este nuevo canal de distribución, el Gobierno Federal busca facilitar el acceso a 
servicios financieros, a través del incremento de puntos de distribución de servicios 
financieros, reduciendo los costos de transacción para los demandantes y oferentes. 
 
Para que los corresponsales bancarios funcionen como un verdadero canal que promueva la 
Inclusión Financiera, y no sólo como un canal que brinde mayor conveniencia a los clientes 
de los bancos; es necesario que represente una reducción real de los costos, para que 
logren penetrar en las localidades desatendidas, constituidas en su mayoría por municipios 
rurales, en transición y semi-urbanos. 
 
En el futuro próximo el impacto de los medios de pago electrónicos va a seguir aumentando, 
al crecer su uso en todo tipo de transacciones. Seguramente todavía nos queda mucho por 
ver en la evolución que sigan el dinero y las formas de pago electrónico. 
 
 
 
 
 
 
 
 
1 Comisión Nacional Bancaria y de Valores, CMBV, Modelos de Negocio para la Inclusión Financiera 
(2010) 
 Objetivo 
 
XI 
 
Objetivo 
 
 
 
Documentar los procesos llevados a cabo en el diseño de la arquitectura lógica de un 
programa Gateway Corresponsal Bancario ISO8583. El cual tiene como objetivo comunicar 
una entidad Bancaria con las terminales punto de venta de una cadena de tiendas de 
autoservicio, para recibir en ellas transacciones de deposito a tarjeta de crédito y debito, 
bajo la figura de corresponsal bancario. 
 
Objetivos específicos 
 
• Documentar diseño de la arquitectura lógica del sistema Gateway Corresponsal 
Bancario ISO8583. 
 
 
• Comunicar transacciones electrónicas de corresponsalía bancaria con formato 
ISO8583, entre un Banco y una cadena de Tiendas de autoservicio. 
 
 
 Justificación 
 
XII 
 
Justificación 
 
En la actualidad en México, los medios de pago electrónico están presentes en el cotidiano 
de muchas maneras. Tarjetas prepagadas para el consumo de servicios digitales, tarjetas 
para viajar en metro, metrobús o bicicleta, recargas de saldo de telefonía celular sin rascar 
tarjetas, vales de despensa de programas sociales, tarjetas bancarias de debito y crédito. Si 
a este fenómeno le aunamos al crecimiento exponencial de sucursales de tiendas de 
autoservicio, que aparecen día a día en las esquinas de cada colonia, tenemos por resultado 
el escenario perfecto para establecer un modelo de negocios redituablemente lucrativo, 
donde los puntos de venta de dichos comercios pueden volverse receptores de 
transacciones electrónicas de múltiples tipos, entre ellas, las transacciones bancarias de 
deposito y retiro de efectivo, logrando de esta manera acercar dichos servicios bancarios a 
regiones donde las sucursales bancarias anteriormente no llegaban. 
 
Este tema es de gran interés para comprender la importancia que tiene la formación de 
ingenieros, enfocados en el desarrollo de tecnologías de información, al servicio de la 
sociedad de consumo. ¿Podremos aprender de lo que hemos desarrollado y aplicarlo en el 
desarrollo de modelos económicos y sociales, donde los beneficios sean para la sociedad y 
no para los intermediarios de los flujos de información?. 
 
 
1 
 
 
 
 
 
 
CAPITULO 1 
Corresponsalía bancaria, modelo de 
inclusión financiera en México 
 
 
 
 
 
 
 
 
 
 
 
 
Corresponsalía bancaria, modelo de inclusión financiera en México 
 
2 
 
 
En los últimos años, el Gobierno Federal ha diseñado políticas públicas encaminadas a 
promover la Inclusión Financiera. La introducción de la figura de corresponsales bancarios es 
un claro ejemplo de una reciente adecuación a la Regulación para promover el acceso a 
servicios financieros. Desdesu implementación en diciembre de 2009, 12 cadenas 
comerciales ya actúan como corresponsales bancarios proporcionando más de 15 mil 
nuevos puntos de acceso al sistema financiero. 
 
 
Debido al enorme potencial del modelo de corresponsales en México, la Comisión Nacional 
Bancaria y de Valores CNBV elaboró un análisis con el objetivo de valorar la posibilidad de 
utilizar las Redes de Distribución de productos para habilitar comercios independientes como 
distribuidores de servicios financieros (corresponsales bancarios), y así facilitar a los 
oferentes la manera de llegar a las poblaciones con menor acceso a servicios financieros en 
el país. 
 
De acuerdo con la interacción que exista entre la Institución Bancaria y sus corresponsales, 
el modelo de negocio puede realizarse de forma directa o indirecta, es decir, existe la 
posibilidad de que el Banco delegue a una entidad gestora la administración de sus agentes 
(corresponsales). Si las instituciones optan por hacerlo de manera indirecta la 
reglamentación permite la figura del Administrador de Corresponsales.2 
 
Un Administrador de Corresponsales facilita el crecimiento de la red de corresponsales y 
disminuye los costos asociados a la instalación; al mismo tiempo, permite la homologación 
de los sistemas operativos y tecnológicos, entre otras ventajas. 
 
 
Un Administrador de Corresponsales puede realizar varias de las actividades involucradas en 
 
2 V. Comisión Nacional Bancaria y de Valores, CMBV, Modelos de Negocio para la Inclusión 
Financiera, Pág. 15 (2010) 
Corresponsalía bancaria, modelo de inclusión financiera en México 
 
3 
 
 
el modelo de negocios; estas funciones van desde las relacionadas con la apertura de un 
corresponsal, como son la selección de corresponsales o la capacitación; hasta aquellas 
actividades destinadas a mejorar el rendimiento de los mismos, como el desarrollo de 
esquemas de incentivos o la asesoría en mercadotecnia. También realizan actividades que 
aseguren la sustentabilidad del modelo; como son la solución de problemas técnicos, el 
control de riesgos, así como garantizar las necesidades líquidas de los corresponsales. 
 
En mi experiencia profesional he laborado con empresas desarrollando Switches 
transaccionales, nuevos medios de pago electrónico y con otras que fungen el rol de 
intermediarios administradores de transacciones Administrador de Corresponsales. Bajo mi 
responsabilidad ha estado la conceptualización de proyectos, diseño de arquitectura lógica y 
de comunicaciones, generación de especificaciones técnicas, desarrollo de sistemas 
informáticos y canales de comunicación para medios de pago y de consumo electrónico, 
especialmente en sistemas encargados del intercambio de transacciones electrónicas entre 
corresponsales bancarios, cajeros automáticos, comercio electrónico por Internet, 
proveedores de servicios, venta de tiempo aire de telefonía celular, programas sociales, 
estaciones gasolineras, bancos y marcas de tarjetas como VISA, MasterCard y American 
Express. 
 
 
 
 
 
 
4 
 
 
 
 
 
CAPITULO 2 
Gateway ISO8583, 
sistema informático transaccional de 
corresponsalía bancaria 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Gateway ISO8583 Sistema Informático Transaccional de Corresponsalía Bancaria 
5 
 
 
Hemos visto en el capitulo anterior las ventajas practicas que ofrece a comercios, bancos y 
usuarios del sistema financiero la implementación de corresponsales bancarios haciendo uso 
de la infraestructura de comunicaciones y puntos de ventas de cadenas comerciales. 
 
En esta memoria expondré mi trabajo realizado en una empresa que cumple el rol de 
Administrador de Corresponsales, donde desarrolle el análisis y diseño de la arquitectura 
lógica de un sistema Gateway ISO8583 encargado de comunicar, validar y traducir 
transacciones electrónicas de corresponsalía bancaria entre una cadena comercial que para 
fines ilustrativos del reporte llamaremos Tiendas X y un Banco al cual nombrare Banco Y.3 
 
Tiendas X es una cadena comercial de tiendas de autoservicio que extiende su red de puntos 
de venta a nivel nacional operando las 24 horas del día, tomando en cuenta los horarios bajo 
los cuales operan actualmente las sucursales bancarias de Banco Y (9 a.m. – 4 p.m.), 
implementar un modelo de corresponsalía bancaria haciendo uso de la red de puntos de 
venta e infraestructura de Tiendas X ofrece una gran ventaja para los usuarios de Banco Y 
que por razones de tiempo o ubicación no pueden acceder de forma sencilla a una sucursal 
bancaria dentro de su localidad. 
 
Por su lado Banco Y abre la oportunidad a comercios y cadenas comerciales para captar 
operaciones de corresponsalía bancaria, haciendo usos de su infraestructura y puntos de 
venta, obteniendo el comercio intermediario una comisión por cada transacción la cual es 
pagada directamente por el usuario del servicio. 
 
 
 
 
 
 
3 Tiendas X y Banco Y, serán referencias usadas a lo largo del reporte. 
Gateway ISO8583 Sistema Informático Transaccional de Corresponsalía Bancaria 
6 
 
 
Como requisito para que Tiendas X y otros comercios puedan captar transacciones de 
corresponsalía bancaria se hace necesario que estos cumplan con los estándares y normas 
de comunicación establecidas por Banco Y. Siendo esta tarea muchas veces difícil de 
resolver por los comercios, entra la figura de Administrador de Corresponsales, el cual es un 
intermediario tecnológico y comercial encargado de establecer canales de comunicación 
adecuados entre comercios y bancos cumpliendo con los estándares y normas propios de 
cada entidad. 
 
Tiendas X actualmente cuenta con un sistema informático para el switcheo de transacciones 
electrónicas con formato ISO8583 pero este no cumple con las especificaciones establecidas 
por Banco Y, por lo que Tiendas X estableció un vinculo de comunicación mediante un 
Administrador de Corresponsales donde yo colabore en el análisis y desarrollo del proyecto 
Gateway ISO8583, una interfaz de comunicación de transacciones electrónicas de 
corresponsalía bancaria entre Tiendas X y Banco Y. 
 
 
 
2.1.- Responsabilidades a cargo dentro del proyecto 
 
En el desarrollo del proyecto Gateway ISO8583 estuvieron bajo mi cargo las siguientes 
responsabilidad. 
 
• Análisis de requerimientos técnicos para comunicar a Tiendas X con Banco Y. 
• Apoyo en el desarrollo de las aplicaciones que cumplan con los requisitos estipulados. 
• Realizar pruebas locales antes de pasar al proceso de certificación. 
• Realizar proceso de certificación de la aplicación con Banco Y. 
 
 
Gateway ISO8583 Sistema Informático Transaccional de Corresponsalía Bancaria 
7 
 
 
2.2.- Objetivos a perseguir en el desarrollo del proyecto 
 
Dentro de las responsabilidades a cargo los objetivos específicos a perseguir fueron. 
 
• Diseñar la arquitectura lógica del sistema. 
• Diseñar y desarrollar capa de vista. 
• Diseñar y desarrollar clases ISO8583 para capa de control. 
• Diseñar y desarrollar clases de conectividad de sockets cliente - servidor. 
 
 
 
2.3.- Observaciones 
 
Los desarrollos e implementaciones se realizarán siguiendo los siguientes estándares del 
Administrador de Corresponsales: 
 
• Realización de la programación del software usando el lenguaje de programación 
Visual Basic.Net. 
• Utilización del estándar ISO8583 para la comunicación de transacciones. 
 
 
Veamos ahora algunos antecedentes teóricos que nos permiten tener un mayor 
entendimiento del proyecto, comencemos con el lenguaje de programación utilizado para el 
desarrollo del sistema. 
 
 
 
8 
 
 
 
 
 
 
 
 
CAPITULO 3 
Fundamentos para el desarrollo de un 
sistema informático transaccional de 
corresponsalía bancaria 
 
 
 
 
 
Fundamentos para el desarrollo de un 
sistema informático transaccional de corresponsalíabancaria 
9 
 
 
3.1.- Lenguaje de programación, Visual Basic. Net 
 
En el desarrollo del proyecto el lenguaje de programación utilizado por preferencia del 
Administrador de Corresponsales fue Visual Basic .NET. 
 
Visual Basic .NET (VB.NET) es un lenguaje de programación orientado a objetos que se 
puede considerar una evolución de Visual Basic implementada sobre el framework .NET. Su 
introducción resultó muy controvertida, ya que debido a cambios significativos en el lenguaje 
VB.NET no es retrocompatible con Visual Basic, pero el manejo de las instrucciones es 
similar a versiones anteriores de Visual Basic, facilitando así el desarrollo de aplicaciones 
más avanzadas con herramientas modernas. 
 
Visual Basic .NET ofrece numerosas características nuevas y mejoradas, como herencia, 
interfaces y sobrecarga, que lo convierten en un eficaz lenguaje de programación orientado a 
objetos. Como desarrollador de Visual Basic, ahora puede crear aplicaciones multiproceso y 
escalables utilizando subprocesamiento múltiple explícito. Otra característica nueva de Visual 
Basic .NET incluye el control estructurado de excepciones, atributos personalizados y 
compatibilidad con CLS (Common Language Specification, Especificación de lenguajes 
Comunes).También se incluyen el control estructurado de excepciones, delegados y varios 
tipos de datos nuevos. 
 
Veamos mas acerca de los Corresponsales Bancarios y Administradores de Corresponsales. 
 
 
 
 
 
 
Fundamentos para el desarrollo de un 
sistema informático transaccional de corresponsalía bancaria 
10 
 
 
3.2.- Qué es un corresponsal bancario 
 
El corresponsal bancario es un tercero que establece relaciones o vínculos de negocio con 
una institución de crédito con objeto de ofrecer, a nombre y por cuenta de ésta, servicios 
financieros a sus clientes. Un ejemplo son los establecimientos comerciales habilitados para 
prestar servicios financieros ofrecidos por un banco. La Figura 3.1 muestra los principales 
actores que intervienen en el proceso. 
 
 
 Fuente : CNBV 
Figura 3.1. Principales Actores. 
 
 
 
 
 
 
 
 
 
 
Fundamentos para el desarrollo de un 
sistema informático transaccional de corresponsalía bancaria 
11 
 
 
3.2.1.- Requisitos para ser corresponsal 
 
 
Puede habilitarse como corresponsal bancario cualquier persona que, por medio de la 
institución financiera, acredite ante el órgano regulador su experiencia y capacidad técnica 
cumpliendo con los requisitos que se muestran en la Tabla 3.2.1. 
 
 
 
Tabla 3.2.1 Requisitos para ser corresponsal bancario. 
 
¿Quienes pueden ser corresponsales? 
• Personas Morales o físicas con actividad empresarial: 
• Con un establecimiento permanente 
• Que acrediten un giro de negocio propio 
• Con infraestructura necesaria para realizar operaciones 
• Con personal capacitado para operar los dispositivos tecnológicos 
• Con buen historial crediticio y de negocios 
• Que no hayan sido condenados por sentencia (delitos dolosos o patrimoniales) 
 Fuente : CNBV 
 
 
 
 
 
 
Fundamentos para el desarrollo de un 
sistema informático transaccional de corresponsalía bancaria 
12 
 
 
3.2.2.- Actividades que pueden realizar los corresponsales 
 
Los corresponsales bancarios funcionan como una ventanilla entre la institución financiera y 
el cliente; sin embargo, las transacciones se realizan Cliente-Corresponsal Corresponsal-
Banco mediante operaciones de cargo y abono en las cuentas correspondientes, de acuerdo 
a la operación que se esté llevando a cabo. Es importante destacar que, en todo momento, la 
institución financiera es la responsable ante el cliente de todas las operaciones realizadas a 
través de sus corresponsales. En la Tabla 3.2.2 se muestra las actividades que tiene 
permitidas un corresponsal, y las cataloga de acuerdo a si son operaciones con cargo o con 
abono al corresponsal; así mismo distingue aquellas operaciones en las que no existe 
afectación a la cuenta del corresponsal. 
 
 
Tabla 3.2.2 Actividades que pueden realizar los corresponsales. 
 
Operaciones con Cargo al 
Corresponsal 
Operaciones con Abono 
al Corresponsal 
Otras Operaciones 
• Pago de servicios en 
efectivo con tarjetas, o 
con cheques de la 
institución 
• Depósitos en efectivo o 
con cheques de la 
institución 
 
 
• Retiro de efectivo 
 
 
• Consulta de 
saldos y 
movimientos 
• Pago de créditos en 
efectivo, con tarjetas o 
con cheques de cualquier 
institución. 
• Circulación de medios de 
pago 
 
 
• Pago de cheques 
del mismo banco 
 
 
• Remesas 
 Fuente : CNBV 
Fundamentos para el desarrollo de un 
sistema informático transaccional de corresponsalía bancaria 
13 
 
 
3.2.3.- Actividades que no pueden realizar los corresponsales 
 
La Tabla 3.2.3 muestra las actividades que no tiene permitidas un corresponsal. La 
regulación vigente restringe la actividad del corresponsal, para evitar prácticas monopólicas; 
así como para garantizar, en todo momento, que se cumplan los estándares de protección al 
cliente y se proteja la estabilidad del sistema financiero 
 
 
Tabla 3.2.3 Actividades que no pueden realizar los corresponsales. 
 
¿Qué NO pueden hacer los Corresponsales? 
• Cobrar a los clientes o usuarios tarifas no autorizadas 
• Condicionar alguna venta de otro producto o servicio a la realización de 
alguna operación (Ventas Atadas) 
• Publicitarse o promocionarse en los comprobantes de operación 
• Ceder el contrato total o parcialmente a terceros 
• Pactar exclusividad en el pago de servicios no bancarios así como en el 
pago de tarjetas de crédito 
• Prestar servicios financieros por cuenta propia 
• Realizar cualquier operación de forma distinta a la pactada con la 
institución 
 Fuente : CNBV 
 
 
 
 
Fundamentos para el desarrollo de un 
sistema informático transaccional de corresponsalía bancaria 
14 
 
 
3.2.4.- Esquema de operación con cargo al corresponsal 
 
El la Figura 3.2.4 se muestra un ejemplo de cómo es el proceso para realizar una operación 
con cargo al corresponsal. 
Figura 3.2.4.Esquema de operación con cargo al corresponsal. 
 
 
Fundamentos para el desarrollo de un 
sistema informático transaccional de corresponsalía bancaria 
15 
 
 
3.2.5.- Resumen de requerimientos por tipo de operación 
 
Todas las operaciones deberán llevarse a cabo en tiempo real y contar con mecanismos de 
identificación que permitan verificar, tanto la autenticidad del cliente, como la del operador y 
del equipo. Se deberá generar, además de un registro electrónico de todas las operaciones, 
un comprobante para el cliente. En la Tabla 3.2.5 se muestra, en forma resumida, los 
requerimientos que exige la regulación para la realización de cada una de las operaciones 
bancarias permitidas. 
 
 
Tabla 3.2.5 Requerimientos Tecnológicos. 
 
 
 
Fundamentos para el desarrollo de un 
sistema informático transaccional de corresponsalía bancaria 
16 
 
 
La institución financiera y el corresponsal deberán firmar un contrato de comisión mercantil, 
el cuál debe contener, por lo menos, los siguientes puntos: las actividades permitidas y 
prohibidas para el corresponsal, los procedimientos para la identificación del corresponsal y 
del cliente, la aceptación del corresponsal para recibir visitas de inspección por parte de la 
Comisión Nacional Bancaria y de Valores, los límites de las operaciones (individuales y 
agregados), los requisitos operativo y técnicos, la responsabilidad del corresponsal ante la 
institución de créditos, y por último, los procedimientos para rescindir o suspender el contrato 
en caso de incumplimiento. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Fundamentos para el desarrollo de un 
sistema informático transaccional de corresponsalía bancaria 
17 
 
 
3.3.- Estándar ISO8583 
 
ISO8583 define un estándar de intercambio y un flujo de comunicación para que diferentes 
sistemaspuedan intercambiar transacciones electrónicas. La mayoría de las operaciones 
realizadas en ATM usan ISO8583 en algunos puntos de la cadena de comunicación, así 
como también las transacciones que realiza un cliente que usa una tarjeta para hacer un 
pago en un local. En particular, todas las redes de tarjetas basan sus transacciones en el 
estándar ISO8583. 
 
Las transacciones incluyen compras, extracciones, depósitos, reintegros, reversos, consultas 
de saldo, pagos y transferencias entre cuentas. ISO8583 también define mensajes entre 
sistemas para intercambios seguros de claves, conciliación de totales y otros propósitos 
administrativos. Aunque el ISO8583 define un estándar común, no se usa normalmente en 
forma directa por sistemas o redes. En lugar de eso cada red adapta el estándar para su 
propio uso con campos adaptados a sus necesidades particulares. 
 
 
Para entender que es ISO8583 en una forma práctica y simple, un mensaje ISO8583 es una 
cadena de caracteres conformada por los elementos mostrados en la Figura 3.3. 
 
 
 
 
 
 
 
 
Fundamentos para el desarrollo de un 
sistema informático transaccional de corresponsalía bancaria 
18 
 
 
Figura 3.3 Estructura de un mensaje ISO8583. 
 
Longitud Header MTI Bitmap(s) Campos del Mensaje ETX 
 
 
• Longitud del mensaje; Normalmente se usan 2 bytes para indicar la longitud total del 
mensaje. 
• Header; Puede ser opcional y es usado para enviar datos propios del dueño de la 
mensajería. 
• MTI; Indica el origen y tipo mensaje 
• Bitmap(s); Son usados para enumerar los campos contenidos en el mensaje. 
• Campos del mensaje; Contienen los datos de la transacción. 
• ETX; Es opcional y es usado para indicar el fin de una transacción, se usa un byte. 
 
 
Para cada campo (también llamado bit), existe una definición única y específica de su uso. 
Algunos campos son de largo fijo y otros de largo variable, estos últimos comienzan con un 
indicador de longitud. Un conjunto de definiciones de campos (128 máximo) forma una 
definición de ISO8583. 
 
Es importante tener en cuenta que un mensaje ISO8583 sólo funcionará contra su propia 
definición. Existe una definición estándar de ISO8583, pero en el uso real, muchas empresas 
la modifican y generan su propia definición de ISO8583. Por lo tanto, un mensaje ISO8583 
puede ser válido para una definición pero inválida para otra. 
 
 
Fundamentos para el desarrollo de un 
sistema informático transaccional de corresponsalía bancaria 
19 
 
 
3.4.- Arquitectura de software 
Una Arquitectura Software, también denominada Arquitectura lógica, consiste en un conjunto 
de patrones y abstracciones coherentes que proporcionan el marco de referencia necesario 
para guiar la construcción del software para un sistema de información.4 
 
Una arquitectura software se selecciona y diseña con base en unos objetivos y restricciones. 
Los objetivos son aquellos prefijados para el sistema de información, pero no solamente los 
de tipo funcional, también otros objetivos como la mantenibilidad, auditabilidad, flexibilidad e 
interacción con otros sistemas de información. Las restricciones son aquellas limitaciones 
derivadas de las tecnologías disponibles para implementar sistemas de información. Unas 
arquitecturas son más recomendables de implementar con ciertas tecnologías mientras que 
otras tecnologías no son aptas para determinadas arquitecturas. 
 
La arquitectura software define, de manera abstracta, los componentes que llevan a cabo 
alguna tarea de computación, sus interfaces y la comunicación entre ellos. Toda arquitectura 
software debe ser implementable en una arquitectura física, que consiste simplemente en 
determinar qué computadora tendrá asignada cada tarea. 
 
La arquitectura de software, tiene que ver con el diseño y la implementación de estructuras 
de software de alto nivel. Es el resultado de ensamblar un cierto número de elementos 
arquitectónicos de forma adecuada para satisfacer la mayor funcionalidad y requerimientos 
de desempeño de un sistema, así como requerimientos no funcionales, como la confiabilidad, 
escalabilidad, portabilidad, y disponibilidad.5 
 
4 Booch, Grady. Object-Oriented Analysis and Design. Second Edition. Benjamin/Cummings, 
Redwood: 1994 
5 Kruchten, Philippe. "Architectural Blueprints--The 4+1 View Model of Software Architecture". IEEE 
Software, Institute of Electrical and Electronics Engineers. November 1995, pp. 42-50. 
Fundamentos para el desarrollo de un 
sistema informático transaccional de corresponsalía bancaria 
20 
 
 
3.4.1.- Programación por capas 
 
La programación por capas es un estilo de programación en la que el objetivo primordial es la 
separación de la lógica de negocios de la lógica de diseño, un ejemplo básico de esto es 
separar la capa de datos de la capa de presentación al usuario, la Figura 3.4.1 muestra la 
distribución a nivel infraestructura de un sistema estructurado en 3 capas, capa de vista, 
capa de negocios y capa de datos. 
 
 
 
 Figura 3.4.1 Distribución física de un sistema de tres capas. 
 
 
La ventaja principal de este estilo, es que el desarrollo se puede llevar a cabo en varios 
niveles y en caso de algún cambio sólo se ataca al nivel requerido sin tener que revisar entre 
código mezclado. 
 
 
 
Fundamentos para el desarrollo de un 
sistema informático transaccional de corresponsalía bancaria 
21 
 
 
En la actualidad en el diseño de sistemas informáticos se usa las arquitecturas multinivel o 
programación por capas. En dichas arquitecturas a cada nivel se le confía una misión simple, 
lo que permite el diseño de arquitecturas escalables (que pueden ampliarse con facilidad en 
caso de que las necesidades aumenten) 
 
3.4.2.- Capas o niveles 
 
El término "capa" hace referencia a la forma como una solución informática es segmentada 
desde el punto de vista lógico. Por ejemplo: Presentación / Lógica de Negocio/ Datos. 
 
En cambio, el término "nivel", corresponde a la forma en que las capas lógicas se encuentran 
distribuidas de forma física. Por ejemplo: 
 
• Una solución de tres capas (presentación, lógica, datos) que residen en un sólo 
ordenador (Presentación+lógica+datos). Se dice, que la arquitectura de la solución es 
de tres capas y un nivel. 
 
• Una solución de tres capas (presentación, lógica, datos) que residen en dos 
ordenadores (presentación+lógica, lógica+datos). Se dice que la arquitectura de la 
solución es de tres capas y dos niveles. 
 
• Una solución de tres capas (presentación, lógica, datos) que residen en tres 
ordenadores (presentación, lógica, datos). La arquitectura que la define es: solución 
de tres capas y tres niveles. 
 
 
 
Fundamentos para el desarrollo de un 
sistema informático transaccional de corresponsalía bancaria 
22 
 
 
El diseño de tres capas está conformado por las siguientes capas: 
 
1.- Capa de presentación: es la que ve el usuario, presenta el sistema al usuario, le 
comunica la información y captura la información del usuario dando un mínimo de proceso 
(realiza un filtrado previo para comprobar que no hay errores de formato). Esta capa se 
comunica únicamente con la capa de negocio. 
 
2.- Capa de negocio: es donde residen los programas que se ejecutan, recibiendo las 
peticiones del usuario y enviando las respuestas tras el proceso. Se denomina capa de 
negocio (e incluso de lógica del negocio) pues es aquí donde se establecen todas las reglas 
que deben cumplirse. Esta capa se comunica con la capa de presentación, para recibir las 
solicitudes y presentar los resultados, y con la capa de datos, para solicitar al gestor de base 
de datos para almacenar o recuperar datos de él. 
 
3.- Capa de datos: es donde residen los datos. Está formada por uno o más gestores de 
bases de datos que realiza todo el almacenamiento de datos, reciben solicitudes de 
almacenamiento o recuperaciónde información desde la capa de negocio. 
 
Todas estas capas pueden residir en un único ordenador (no sería lo normal), si bien lo más 
usual es que haya una multitud de ordenadores donde reside la capa de presentación (son 
los clientes de la arquitectura cliente/servidor). Las capas de negocio y de datos pueden 
residir en el mismo ordenador, y si el crecimiento de las necesidades lo aconseja se pueden 
separar en dos o más ordenadores. Así, si el tamaño o complejidad de la base de datos 
aumenta, se puede separar en varios ordenadores los cuales recibirán las peticiones del 
ordenador en que resida la capa de negocio. 
 
 
Fundamentos para el desarrollo de un 
sistema informático transaccional de corresponsalía bancaria 
23 
 
 
Si por el contrario fuese la complejidad en la capa de negocio lo que obligase a la separación, 
esta capa de negocio podría residir en uno o más ordenadores que realizarían solicitudes a 
una única base de datos. En sistemas muy complejos se llega a tener una serie de 
ordenadores sobre los cuales corre la capa de datos, y otra serie de ordenadores sobre los 
cuales corre la base de datos.6 
3.4.3.- Modelos o vistas 
Toda arquitectura software debe describir diversos aspectos del software. Generalmente, 
cada uno de estos aspectos se describe de una manera más comprensible si se utilizan 
distintos modelos o vistas. Es importante destacar que cada uno de ellos constituye una 
descripción parcial de una misma arquitectura y es deseable que exista cierto solapamiento 
entre ellos. Esto es así porque todas las vistas deben ser coherentes entre sí, evidente dado 
que describen la misma cosa. 
 
Cada paradigma de desarrollo exige diferente número y tipo de vistas o modelos para 
describir una arquitectura. No obstante, existen al menos tres vistas absolutamente 
fundamentales en cualquier arquitectura: 
 
• La visión estática: describe qué componentes tiene la arquitectura. 
• La visión funcional: describe qué hace cada componente. 
• La visión dinámica: describe cómo se comportan los componentes a lo largo del 
tiempo y cómo interactúan entre sí. 
 
 
6 Larman, Craig. UML y Patrones, Introducción al análisis y diseño orientado a objetos. México: 
Prentice Hall, 1999 
 
Fundamentos para el desarrollo de un 
sistema informático transaccional de corresponsalía bancaria 
24 
 
 
Las vistas o modelos de una arquitectura pueden expresarse mediante uno o varios 
lenguajes. El más obvio es el lenguaje natural, pero existen otros lenguajes tales como los 
diagramas de estado, los diagramas de flujo de datos, etc. Estos lenguajes son apropiados 
únicamente para un modelo o vista. Afortunadamente existe cierto consenso en adoptar UML 
(Unified Modeling Language, Lenguaje Unificado de Modelado) como lenguaje único para 
todos los modelos o vistas. Sin embargo, un lenguaje generalista corre el peligro de no ser 
capaz de describir determinadas restricciones de un sistema de información (o expresarlas 
de manera incomprensible). 
 
 
 
 
 
 
 
 
 
25 
 
 
 
 
 
CAPITULO 4 
Proceso de desarrollo de Gateway 
ISO8583 corresponsal bancario 
 
 
 
 
 
 
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario 
26 
 
 
El desarrollo del proyecto Gateway Corresponsal Bancario ISO8583 fue dividido en cinco 
etapas, estas se ilustran en la Tabla 4.1 en la cual podemos observar el personal 
responsable de cada una de ellas. 
 
Tabla 4.1 Etapas y responsables del proyecto. 
Etapas del Proyecto Responsable 
1 Análisis de especificaciones del proyecto. Pablo Nieto 
2 Diseño de arquitectura lógica. Pablo Nieto 
3 Desarrollo. Ivan Zapien 
Pablo Nieto 
4 Pruebas. Wendy Lopez 
Pablo Nieto 
5 Producción. Humberto Cardenas 
 
 
A lo largo del presente capitulo describiré las etapas de análisis, diseño de arquitectura lógica 
del proyecto y pruebas, actividades a mi cargo en el desarrollo del proyecto. 
 
Mencionare que en el equipo de trabajo no existía experiencia previa en el tratamiento de 
transacciones electrónicas ISO8583, quedando a mi cargo transmitir a los demás integrantes 
del equipo la teoría y el esbozo rápido del análisis y diseño de la arquitectura del sistema ya 
que se contaba con poco tiempo para tener el sistema final en un ambiente productivo 
 
 
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario 
27 
 
 
4.1.- Análisis de especificaciones del Proyecto 
 
 
Como primer paso en el proceso de análisis estableceremos la premisa bajo la cual gira la 
necesidad del desarrollo del proyecto Gateway Corresponsal bancario ISO8583. 
 
Se requiere de un sistema que sirva de puente para establecer flujo de transaccional de 
corresponsalía bancaria con formato ISO8583 y validación de reglas de negocio entre el 
sistema transaccional de una cadena comercial Tiendas X y el sistema autorizador de 
transacciones de corresponsalía bancaria del Banco Y. 
 
Conociendo la premisa del desarrollo del sistema se hace necesario conocer las limitantes 
que no permiten comunicar de forma directa a Tiendas X con Banco Y, para resolver esta 
cuestión tenemos que conocer las características y especificaciones técnicas de cada uno de 
los sistemas. 
 
Veamos cuales son las características del sistema transaccional de Tiendas X, la Tabla 4.2 
ilustra con un resumen las características y especificaciones importantes del sistema de 
Tiendas X, la primer columna muestra el rubro, la segunda el detalle del rubro y la tercera la 
especificación. 
 
 
 
 
 
 
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario 
28 
 
 
Tabla 4.2 Resumen de especificaciones del sistema de Tiendas X. 
Rubro Detalle Especificación 
Tipo de conexión TCP-IP, establecer una sola conexión permanente 
para el envío y recepción de transacciones. 
Conectividad 
Rol de conexión El sistema se conectara a sistema externo bajo el 
rol de cliente. 
Mensajes de 
autorización 
0200 - 0210 
El sistema enviara mensajes 0200 por cada 
transacción de corresponsalía bancaria y recibirá 
como respuesta un mensaje 0210. 
Mensajes de reverso 
0420 - 0430 
El sistema enviara hasta 3 intentos mensajes 0420 
por cada transacción de corresponsalía bancaria 
no respondida y recibirá como respuesta un 
mensaje 0430. 
Transaccional 
Mensajes de Echo 
0800 - 0810 
 
El sistema enviara mensajes de Echo 0800 cada 
minuto para monitorear el estado de la conexión y 
recibirá como respuesta un mensaje 0810. 
 
 
Veamos ahora cuales son las especificaciones requeridas del sistema transaccional de 
Banco Y para recibir operaciones de corresponsalía bancaria. La Tabla 4.3, ilustra las 
características y especificaciones importantes del sistema de Banco Y, la primer columna 
muestra el rubro, la segunda el detalle del rubro y la tercera la especificación requerida. 
 
 
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario 
29 
 
 
 
Tabla 4.3 Resumen de especificaciones del sistema de Banco Y. 
Rubro Detalle Especificación 
Tipo de conexión TCP-IP, establecer conexión y desconexión por 
cada transacción que se envíe. 
Seguridad de 
conexión 
Establecer canal seguro Socket Secure Layer SSL. 
Conectividad 
Rol de conexión El sistema recibe conexiones del sistema externo 
bajo el rol de servidor. 
Mensajes de 
autorización 
0200 – 0210 
El sistema enviara mensajes 0200 por cada 
transacción de corresponsalía bancaria y recibirá 
como respuesta un mensaje 0210. 
Mensajes de reverso 
0420 – 0430 
El sistema enviara hasta 3 intentos mensajes 0420 
por cada transacción de corresponsalía bancaria 
no respondida y recibirá como respuesta un 
mensaje 0430. 
Transaccional 
Calculo de campo 
MAC 
 
Cada mensaje enviado deberá de incluir en el 
ultimo campo, el campo Message Authentication 
Code (MAC). 
Validación de 
horarios 
Validar horarios permitidos por sucursal. Reglas de 
Negocio 
Validaciónde montos Validar montos máximos y mínimos así como 
montos acumulados por sucursal. 
 
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario 
30 
 
 
Definidas las características y especificaciones de ambos sistemas analicemos cuales de 
ellas difieren e impiden comunicarlos de forma directa, justificando de esta forma la 
existencia de un sistema intermedio para comunicarlos. Para ilustrarlo observemos la 
Tabla 4.4, la primer columna muestra el rubro del requerimiento, la segunda los 
requerimientos del sistema de Banco Y para aceptar transacciones de corresponsalía 
bancaria de un cliente externo y la ultima columna muestra cuales de estas acciones son 
soportadas actualmente por el sistemas de Tiendas X. 
 
Tabla 4.4 Limitantes de Comunicación entre Tiendas X y Banco Y. 
Rubro Banco Y Tiendas X 
TCP. Establecer conexión y 
desconexión por cada envío 
de transacción. 
Siempre conectado, no soporta 
desconexión y reconexión por 
transacción. 
Conectividad 
 
Establecer conexión segura 
mediante Socket Secure Layer 
SSL 
No soportado. 
Aceptar mensajes 
transaccionales 0200, 0210, 
0400, 0420. 
Soportado. Mensajería ISO8583 
Realizar calculo de Mesage 
Authentication Code (MAC) 
por cada transacción. 
No soportado. 
 
Validar horarios permitidos. No soportado. Reglas de negocio 
Validar montos máximos y 
mínimos, así como montos 
acumulados por sucursal. 
No soportado 
 
 
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario 
31 
 
 
Como podemos observar en la Tabla 4.4 el sistema de Tiendas X no soporta varios de los 
requisitos establecidos por Banco Y, por lo que se hace necesario establecer un puente entre 
los dos sistemas el cuál será Gateway Corresponsal bancario ISO8583, este deberá 
comunicar a ambos sistemas de forma transparente, por un lado estará diseñado para actuar 
como servidor recibiendo transacciones ISO8583 provenientes de Tiendas X, internamente 
realizara el calculo del campo MAC, validara reglas de negocio, traducirá la transacción para 
ser enviada a Banco Y conectándose a su sistema como cliente por una conexión segura 
SSL, al recibir respuesta cerrara la conexión con Banco Y, finalmente retornara la respuesta 
de la transacción transformada al formato requerido por Tiendas X. 
 
 
Veamos ahora que roles de comunicación cumplen cada uno de los sistemas inmersos 
dentro del intercambio de transacciones, la Tabla 4.5 ilustra los roles de comunicación que 
cumple Tiendas X, Gateway ISO8583 y Banco Y. 
 
Tabla 4.5 Roles de comunicación de entidades. 
Tiendas X Gateway ISO8583 Banco Y 
Cliente Servidor - Cliente Servidor 
 
 
 
Como observamos en la Tabla 4.5 Gateway ISO8583 actuara como servidor por un extremo 
recibiendo transacciones de Tiendas X, por el otro extremo se conectara como cliente 
enviando las transacciones y recibiendo la respuesta de Banco Y. 
 
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario 
32 
 
 
Conociendo los roles de comunicación que cumple cada uno de los sistemas, mostraremos a 
detalle cuales son los requerimientos específicos que Gateway ISO8583 deberá cumplir. 
 
1. Diseñar y desarrollar un sistema intermedio (Gateway) para comunicar, traducir y validar 
de forma bidireccional transacciones electrónicas de corresponsalía bancaria entre 
Tiendas X y Banco Y usando el protocolo ISO8583. 
 
La Figura 4.6 muestra el flujo de información entre las entidades Tiendas X, 
Gateway ISO8583 y Banco Y en una abstracción del sistema. 
 
 
 
 
Figura 4.6 Flujo de información entre entidades. 
 
 
 
 
GATEWAY 
ISO8583 
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario 
33 
 
 
2. La conectividad entre Tiendas X - Gateway ISO8583 - Banco Y será punto a punto 
mediante el protocolo TCP/IP, teniendo las siguientes características entre entidades : 
 
• Comunicación a nivel protocolo entre Tiendas X y Gateway ISO8583, se tendrán las 
siguientes características ilustradas en la Figura 4.7: 
 
1. Gateway ISO8583 actuará como servidor exponiendo socket y puerto. 
2. Tiendas X se conecta como cliente al socket y puerto expuesto por Getaway 
ISO8583. 
 
 
Figura 4.7 Conectividad a nivel protocolo entre Tiendas X y Gateway ISO8583. 
 
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario 
34 
 
 
◦ Comunicación a nivel protocolo entre Gateway ISO8583 y Banco Y, se tendrán las 
siguientes características ilustradas en la Figura 4.8. 
 
1. Gateway ISO8583 se conecta a Banco Y como cliente. 
2. Por cada envío de mensajes se deberá de abrir y cerrar la sesión TCP/IP. 
3. No existe intercambio de mensajes de Echo. 
 
 
 
 
 
Figura 4.8 Conectividad a nivel protocolo entre Gateway ISO8583 y Banco Y. 
 
 
 
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario 
35 
 
 
3. La conexión entre Gateway ISO8583 y Banco Y debe utilizar canal encriptado Secure 
Sockets Layer SSL con las siguientes especificaciones, ilustradas en la Figura 4.9: 
 
 
 
1. Validar certificados de seguridad Verisign7 de ambos lados. 
2. Algoritmos de encripción: AES - Advanced Encryption Standard (192 bit keys)8. 
3. Hash algorithm: Secure Hash Standard. 
4. Método de autenticación: Pre-Shared Key. 
 
 
 
Figura 4.9 Canal SSL entre Gateway ISO8583 y Banco Y. 
 
 
7 Verisign, entidad emisora de los certificados de seguridad. 
8 Advanced Encryption Standard (AES), Esquema simétrico de cifrado por bloques. 
 
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario 
36 
 
 
 
4. La estructura de las transacciones entre entidades estarán conformadas de la siguiente 
manera: 
 
1. Entre Tiendas X y Gateway ISO8583; La mensajería a intercambiar usará el 
estándar ISO8583 definido por Tiendas X, como se ilustra en la Figura 4.10. 
 
1. Deberá existir intercambio de mensajes de echo 0800 indicando con ello que 
está listo para recibir las transacciones de Tiendas X (0200, 0420, 0421) . 
2. Se deberá de estar enviando un mensaje de echo 0800 para verificar qué 
Gateway ISO8583 está activo y puede recibir transacciones. 
 
Figura 4.10 Mensajería ISO8583 entre "Tiendas X" y Gateway ISO8583. 
 
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario 
37 
 
 
2. Entre Gateway ISO8583 y Banco Y; La mensajería a intercambiar usará el 
estándar ISO8583 definido por Banco Y teniendo en cuenta las particularidades 
ilustradas en la Figura 4.11: 
 
1. Padeo: Cuando no es divisible entre ocho los datos se rellenan de ceros 
a la izquierda del bloque. 
2. Incluir el campo MAC. 
3. Informar campo MAC: Debe de ir en el último campo (64), si hay más de 
64 campos debe de ir en el campo (128). 
4. Se cierra y abre conexión por mensaje, no existen mensajes de echo. 
 
 
Figura 4.11 Mensajería ISO8583 entre Gateway ISO8583 y Banco Y. 
 
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario 
38 
 
 
5. Las transacciones electrónicas de corresponsalía bancaria que se realizarán son: 
 
1. Depósito a Tarjeta de Débito. 
2. Reversos de transacciones. 
 
6. Todas las transacciones deben registrarse en la pista de auditoría. 
 
7. Toda la comunicación deberá realizarse a través de enlaces dedicados seguros. 
 
8. El sistema deberá de ser configurable a través de archivos de configuración para: 
 
1. Configuración general de la aplicación, puertos de escucha, llaves criptográficas, 
direcciones de aplicaciones remotas, formato general de mensajes. 
 
2. Esquema de configuración de mensajería de transacciones entre Tiendas X. 
 
3. Esquema de configuración de mensajería de transacciones entre Banco Y. 
 
 
Teniendo el análisis de los requerimiento y las especificaciones propias del sistema pasemos 
a diseñar la arquitectura del Gateway ISO8583 en el cual usaremos un modelo de 
arquitectura de tres capas con la intención de facilitar el mantenimiento del sistema y 
tratamiento de datos en un futuro.Proceso de desarrollo de Gateway ISO8583 corresponsal bancario 
39 
 
 
4.2.- Diseño de arquitectura del sistema Gateway ISO8583 
 
En el diseño de la arquitectura del sistema usaremos un modelo de tres capas, con la 
finalidad de lograr una arquitectura modular y escalable que permita tener el control preciso 
de los componentes y los procesos. 
 
La Tabla 4.2 muestra un esbozo de las tres capas constituirán el esqueleto de la arquitectura 
del sistema. 
 
Tabla 4.12 Esbozo de la arquitectura del sistema. 
 
 
 
Arquitectura del sistema 
Capa de Vista Capa de Control Capa de Datos 
 
 
Definidas cuales serán las capas que conformaran el sistema, definamos sus 
responsabilidades dentro del funcionamiento del sistema. 
 
 
Sabemos que el sistema requiere comunicar mensajes de forma bidireccional a dos 
entidades externas actuando de un lado como servidor y del otro como cliente, por lo que las 
funciones que permitan realizar estas acciones las ubicaremos dentro de la capa de vista ya 
que esta es la capa que tiene contacto con el exterior. 
 
 
Dentro de la capa de control se encontraran todas las funciones que permitan interpretar la 
estructura ISO8583 de los mensajes transaccionales así como las validaciones de reglas de 
negocio y transformaciones de formato. 
 
 
 
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario 
40 
 
 
Finalmente dentro de la capa de datos se situaran todas las operaciones que permitan tener 
acceso a las bases de datos del modelo de domino y registros de transacciones del sistema. 
 
 
En la Tabla 4.13 se muestra un resumen con la descripción y responsabilidades que cada 
capa tendrá dentro del sistema. 
 
 
 
Tabla 4.13 Descripción y responsabilidades de capas del sistema. 
 
Capa Descripción Responsabilidad 
Vista 
Capa que contiene los servicios que 
son expuestos como cliente/servidor 
de socket y la representación en 
código de cada caso de uso. 
Administra peticiones de cliente Tienda X y 
direccionar al servidor de aplicaciones del 
Banco Y 
Control 
Capa que contiene la lógica de 
negocio, definición para el parseo y 
generación de mensajes en formato 
ISO8583 
Controlar reglas de negocio e 
interpretación de mensajes ISO8583. 
Datos 
Capa que contiene todas las 
operaciones hacia los datos, también 
contiene el modelo de dominio de la 
aplicación así como los mapeos 
necesarios para persistir las 
instancias del modelo. 
Almacenamiento y lógica de tratamiento de 
datos de configuración y transacciones. 
 
 
 
Teniendo claras las atribuciones de cada una de las capas es necesario establecer los nodos 
de intercambio de información del sistema con el exterior, para realizar esta operación 
recordemos el flujo de la transacción observando la Figura 4.6. 
 
 
 
 
 
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario 
41 
 
 
Encontramos que el primer nodo con el exterior esta representado por el sistema de 
Tiendas X que se conectara a Gateway ISO8583 como cliente para el envío y recepción de 
transacciones. 
 
 
El segundo nodo lo encontramos dentro de Gateway ISO8583 este expondrá un servidor 
TCP-IP para recibir y responde las transacciones provenientes de Tiendas X, este nodo se 
situara dentro de la capa de vista. 
 
 
El tercer nodo estará dado por un cliente TCP-IP dentro de Gateway ISO8583 que permite 
conectarse al sistema de Banco Y para envío y recepción de transacciones, este nodo se 
situara de igual forma dentro de la capa de vista. 
 
 
El cuarto nodo estará representado por el sistema externo de Banco Y el cual expondrá un 
servidor TCP-IP que permite recibir y responder transacciones. 
 
 
Finalmente el quinto nodo estará situado dentro de Gateway ISO8583 el cual permite 
comunicar al sistema con una base de datos externa para almacenar los registro de actividad 
del sistema, este nodo se situara dentro de la capa de datos. 
 
 
 
 
 
 
 
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario 
42 
 
 
En la Tabla 4.14 podemos observar un resumen que muestra en la primer columna el 
nombre del nodo, en la segunda columna la descripción del nodo y la tercer columna las 
responsabilidades de cada nodo. 
 
 
 
Tabla 4.14 Descripción y responsabilidades de los nodos del sistema. 
 
Nodo Descripción Responsabilidad 
Cliente 
Sistema externo representado 
por Tiendas X que se conecta a 
Gateway ISO8583 como cliente 
a través de un socket 
Envía mensajes transaccionales en 
formato ISO 8583 y recibe respuesta a 
ellos 
Servidor 
Es componente de Gateway 
ISO8583 que expone un servidor 
de sockets 
Administra peticiones de Cliente, válida 
reglas de negocio y direcciona al Cliente 
Banco. 
Cliente Banco 
Es componente de Gateway 
ISO8583 que se conecta al 
Banco a través de un socket 
Envía mensajes transaccionales en 
formato ISO 8583 y recibe respuesta a 
ellos 
Banco 
Sistema externo representado 
por Banco Y al cual Gateway 
ISO8583 se conecta como 
cliente a través de un socket 
Recibir y autorizar transacciones de 
corresponsalía bancaria provenientes de 
Tiendas X. 
DataBase Es el recurso de base de datos Administra los datos de todas las aplicaciones conectadas a ella 
 
 
 
 
 
 
 
 
 
 
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario 
43 
 
 
4.3.- Diagrama de Arquitectura 
 
Anteriormente definimos los roles de comunicación, responsabilidades de capas y nodos que 
conformaran el sistema Gateway ISO8583 pasaremos a diagramar la arquitectura del 
sistema con estos elementos. 
 
La Figura 4.15 muestra el diagrama de arquitectura propuesto para el desarrollo del 
Gateway ISO8583, en este se puede observar cómo están organizadas las capas para 
comunicarse entre si, así como las responsabilidad de cada una y su conexión con los nodos 
del sistema. 
 
 
Figura 4.15 Diagrama de Arquitectura de tres capas Gateway ISO8583. 
 
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario 
44 
 
 
En la Capa de Vista del diagrama podemos observar una interfaz la cual tiene como 
responsabilidad exponer los nodos Servidor y Cliente Banco, el primero encargado de recibir 
y responder las transacciones provenientes del sistema de Tiendas X representado por el 
nodo externo Cliente y el nodo Cliente Banco que permite comunicar las transacciones 
recibidas al sistema de Banco Y representado por el nodo externo Banco, al mismo tiempo la 
Capa de Vista se comunica con la Capa de Control en donde encontramos el componente 
Control de Mensajes el cual tiene como finalidad realizar las validaciones de la estructura del 
mensaje transaccional ISO8583, reglas internas y de negocio, esta capa se comunica con la 
Capa de Datos la cual se conecta con el nodo externo Database el cual representa la base 
de datos de donde se obtienen los datos propios para la validación de los mensajes y se 
almacenan las transacciones procesadas con la finalidad de tener un registro de la actividad 
del sistema para futuras aclaraciones y conciliación entre entidades. 
 
Teniendo presente la funcionalidad y relación de los componentes que conforman el 
diagrama de la arquitectura del sistema Gateway ISO8583 definamos ahora cuales son los 
casos de usos que el sistema presentara. 
 
 
4.4.- Casos de uso del sistema 
 
El sistema Gateway ISO8583 requiere procesar dos tipos de transacciones de 
corresponsalía bancaria provenientes de Tiendas X: 
 
1. Depósitos a tarjeta de crédito o débito. 
2. Reversos de depósitos a tarjeta de crédito o débito. 
 
 
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario 
45 
 
 
Visto lo anterior definiremos dos casos de uso, al primero lo llamaremos Depósito y estará 
encargado de procesar transacciones de Depósitos a tarjeta de crédito o débito y el segundo 
caso lo nombraremos Reverso encargado de procesar transacciones de Reversos de 
depósitos a tarjeta de crédito o débito, la Tabla 4.16 muestra la descripción de cada casode 
uso. 
 
Tabla 4.16 Descripción de Casos de uso del sistema. 
ID Nombre Descripción 
UC1 Depósito Este caso de uso contiene la lógica para realizar un depósito a tarjeta de crédito o débito. 
UC2 Reverso 
Este caso de uso contiene la lógica para realizar un reverso 
de depósito a tarjeta de crédito o débito. 
 
 
Definidos los casos de uso definamos ahora los actores del sistema. 
 
 
4.5.- Actores del sistema 
 
Los personajes o entidades que participarán en un caso de uso se denominan actores. La 
Tabla 4.17 describe los actores que intervienen en los casos de uso del sistema. 
 
Tabla 4.17 Descripción de Actores del sistema. 
Nombre Descripción 
Cliente Este actor es un sistema que usa los servicios de Gateway ISO8583. 
 
 
 
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario 
46 
 
 
 
En la Figura 4.18 podemos observar como el actor Cliente con origen en Tiendas X puede 
acceder a los dos casos de uso del sistema, Deposito y Reverso, ambos casos internamente 
pasan por la validación de reglas de negocio y finalmente al envío y recepción del mensaje al 
Banco Y. 
 
 
 
 
Figura 4.18 Actores y Casos de Uso del sistema. 
 
 
 
 
Definidos los casos de uso y actores del sistema definamos ahora el flujo de las operaciones 
que internamente se realizaran para cada uno de los casos de uso Depósito y Reverso. 
 
 
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario 
47 
 
 
4.6.- Flujo Caso de Uso Depósito 
 
1.- Descripción; Este caso de uso describe el comportamiento general para realizar un 
depósito a tarjeta de crédito o débito. 
 
2.- Actores; Cliente. 
 
3.- Disparador; El cliente envía una petición 0200 al servidor con la especificación ISO8583. 
 
4.-Precondiciones; Los datos enviados en la petición deben estar de acuerdo al layout del 
mensaje 0200 de la especificación ISO8583. 
 
5.-Flujo Principal 
 
1. El sistema recibe una cadena de bytes del Cliente y al detectar que es un mensaje del 
tipo depósito 0200 continúa con el flujo mostrado en la Figura 4.19. 
 
2. Se valida la estructura y campos ISO8583 del mensaje de deposito 0200. 
 
3. Se valida usuario y se obtienen las cadenas asociadas. 
 
4. Se procesan las reglas de negocio validación de montos y horarios. 
 
5. Se guarda la petición en la bitácora de transacciones. 
 
6. Se genera mensaje de petición ISO8583 0200 con el formato requerido por Banco Y. 
 
7. Se establece conexión con el Banco Y y se envía el mensaje 0200. 
 
8. Se recibe el mensaje de respuesta del Banco Y 0210 y se cierra la conexión con el 
Banco. 
 
9. Se obtiene el listado de mensajes contenidos en la respuesta 0210. 
 
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario 
48 
 
 
10. Se parsea el mensaje de respuesta 0210 para obtener los campos que le 
conforman. 
 
11. Se valida la estructura y campos del mensaje ISO8583 de respuesta 0210. 
 
12. Se actualiza el valor de respuesta en la base de datos. 
 
13. Se guarda respuesta en bitácora de transacciones. 
 
14. Se genera mensaje de respuesta ISO8583 0210 con el formato de Tiendas X. 
 
15. Finalmente se envía el mensaje de respuesta a Tiendas X 
 
 
El diagrama de la Figura 4.19 ilustra gráficamente el flujo que sigue una transacción de 
depósito a tarjeta de crédito o débito. 
 
 
 
 
 
 
 
 
 
 
 
 
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario 
49 
 
 
 
Figura 4.19 Diagrama de flujo del caso de uso Depósito. 
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario 
50 
 
 
4.7.- Flujo Caso de Uso Reverso 
 
1.- Descripción; Este caso de uso describe el comportamiento general para realizar un 
reverso a depósito a tarjeta de crédito o débito. 
 
2.- Actores; Cliente. 
 
3.- Disparador; El cliente envía una petición 0420 al servidor con la especificación ISO8583. 
 
4.- Precondiciones; Los datos enviados en la petición deben estar de acuerdo al layout del 
mensaje 0420 de la especificación ISO8583. 
 
5.-Flujo Principal 
 
1. El sistema recibe cadena de bytes del cliente desde el flujo inicial al detectar que es un 
mensaje del tipo reverso continua con el flujo mostrado en la Figura 4.20. 
 
2. Se valida la estructura y campos ISO8583 del mensaje de reverso 0420. 
 
3. Se valida usuario y se obtienen las cadenas asociadas. 
 
4. Se procesan las reglas de negocio validación de montos y horarios. 
 
5. Se guarda la petición en la bitácora de transacciones. 
 
6. Se genera mensaje de petición ISO8583 0420 con el formato requerido por Banco Y. 
 
7. Se establece conexión con el Banco Y y se envía el mensaje 0420. 
 
8. Se recibe el mensaje de respuesta del Banco Y 0430 y se cierra la conexión con el 
Banco. 
 
9. Se obtiene el listado de mensajes contenidos en la respuesta 0430. 
 
 
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario 
51 
 
 
10. Se parsea el mensaje de respuesta 0430 para obtener los campos que le 
conforman. 
 
11. Se valida la estructura y campos del mensaje ISO8583 de respuesta 0430. 
 
12. Se actualiza el valor de respuesta en la base de datos. 
 
13. Se guarda respuesta en bitácora de transacciones. 
 
14. Se genera mensaje de respuesta ISO8583 0430 con el formato de Tiendas X. 
 
15. Finalmente se envía el mensaje de respuesta a Tiendas X 
 
 
 
El diagrama de la Figura 4.20 ilustra gráficamente el flujo que sigue una transacción de 
reverso de depósito a tarjeta de crédito o débito. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario 
52 
 
 
 
Figura 4.20 Diagrama de flujo del caso de uso Reverso. 
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario 
53 
 
 
4.8. Diagramas de Proceso 
 
El diagrama de proceso es una forma gráfica de presentar las actividades involucradas en el 
flujo de cada uno servicios terminados. 
 
Veamos a continuación los diagramas de proceso que ilustran las validaciones de reglas de 
negocio definidas para los servicios de Depósito y Reverso. 
 
 
4.8.1 Diagrama de Proceso Depósito 
 
Una transacción de Depósito tiene que ser evaluada antes de ser enviada al Banco Y, por 
dicho motivo se realizan las validaciones mostradas en la Tabla 4.21. 
 
Tabla 4.21 Validaciones transacción de Depósito. 
Validación Descripción 
Aplicación Valida que la aplicación sea la correcta. 
Comercio Valida que el comercio exista y esté activo. 
Punto de venta Valida que el punto de venta exista y esté activo. 
Cuenta Valida formato de tarjeta, que esté activa y pertenezca a Banco Y. 
Tipo Transacción Valida que la transacción exista y esté activa. 
Horario Valida que la transacción esté dentro del horario de operación. 
Limites Valida limites por transacción y comercio. 
 
 
 
 
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario 
54 
 
 
El diagrama de la Figura 4.22 muestra las validaciones de reglas de negocio y procesos por 
los que tiene que pasar una transacción de Depósito a tarjeta de crédito o débito proveniente 
de Tiendas X antes de ser enviada a Banco Y, asegurando así la integridad de los datos 
enviados. Al cumplir con todas las validaciones la transacción es enviada a Banco Y, 
esperando recibir la respuesta la cual posteriormente es procesada como se ilustra en la el 
diagrama de proceso. 
 Figura 4.22 Diagrama de proceso Depósito. 
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario 
55 
 
 
El diagrama de la Figura 4.23 muestra las validaciones realizadas al recibir la respuesta de 
una transacción de Depósito a tarjeta de crédito o débito. 
 
 
 
Figura 4.23 Diagrama de Validaciones Depósito. 
 
 
 
 
 
 
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario 
56 
 
 
4.8.2 Diagrama de Proceso Reverso 
 
Una transacción de Reverso tiene que ser evaluada antes de ser enviada al Banco Y, por 
dicho motivo se realizan las validaciones mostradas en la Tabla 4.24. 
 
Tabla 4.24 Validaciones transacción de Reverso. 
Validación Descripción 
AplicaciónValida que la aplicación sea la correcta. 
Comercio Valida que el comercio exista y esté activo. 
Punto de venta Valida que el punto de venta exista y esté activo. 
Cuenta Valida formato de tarjeta, que esté activa y pertenezca a Banco Y. 
 
 
El diagrama de la Figura 4.25 muestra las validaciones de reglas de negocio y procesos por 
los que tiene que pasar una transacción de Reverso a tarjeta de crédito o débito proveniente 
de Tiendas X antes de ser enviada a Banco Y, asegurando así la integridad de los datos 
enviados. 
 
 
Al cumplir con todas las validaciones la transacción es enviada a Banco Y, esperando recibir 
la respuesta la cual posteriormente es procesada como se ilustra en la el diagrama de 
proceso de la Figura 4.26. 
 
 
 
 
 
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario 
57 
 
 
 
 
Figura 4.25 Diagrama de proceso Reversos. 
. 
 
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario 
58 
 
 
 
 
Figura 4.26 Diagrama de Validaciones Reversos. 
 
 
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario 
59 
 
 
4.9. Vistas de la Arquitectura 
 
Las vistas de la arquitectura muestran diferentes perspectivas que pueden ayudar a 
documentar las decisiones estructurales. 
 
4.9.1- Vista Lógica 
 
Esta vista describe los comportamientos y estructuras significativas del sistema. Se ha 
descompuesto esta vista en varios apartados para su descripción. La Figura 4.27 muestra la 
estructura lógica de los paquetes que conforman Gateway ISO8583. 
Figura 4.27 Vista lógica de paquetes Gateway ISO8583. 
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario 
60 
 
 
4.9.2.- Vista Paquetes 
 
Esta vista permite comprender la función de los paquetes que conforman las capas de datos, 
control y vista, a continuación se enuncian los paquetes y su función. 
 
• Data.domain: Este paquete perteneciente al componente Data, contiene las clases 
que definen el modelo de dominio y archivos de mapeo. 
 
• Data.persistence: Este paquete perteneciente al componente Data, contiene clases 
concretas que permiten tener acceso a los datos así como persistirlos. La persistencia 
se realiza utilizando un Framework a la medida, denominado persistence. 
 
• Data.messages: Este paquete contiene las clases usadas para la definición de 
mensajes ISO8583. 
 
• Data.messages.exceptions: Este paquete contiene las clases para el manejo de 
excepciones generadas al tener algún error en la estructura de los mensajes. 
 
• Data.messages.gbTripleDES: Este paquete contiene las clases necesarias para la 
encripcion 3DES. 
 
• Data.messages.isoFactory: Este paquete contiene las clases necesarias para el 
parseo y la formación de mensajes ISO8583 y sus respectivas validaciones de formato. 
 
 
• Data.util: Este paquete contiene utilidades de ayuda para el manejo del acceso a 
datos. 
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario 
61 
 
 
• Control.businessLogic: Este paquete contiene servicios de lógica de negocios. 
 
• Control.businessLogic.loaders: Este paquete contiene cargadores de datos relativos 
a la transacción, tales como el arreglo de comisiones asociadas a una entidad. 
 
• Control.businessLogic.validators: Este paquete contiene el conjunto de validadores 
de reglas de negocios. 
 
• Control.exceptions: Este paquete contiene el conjunto de excepciones para el 
manejo de reglas de negocios, así como las clases necesarias para el control de 
errores los servicios. 
 
• Control.transform: Este paquete contiene las clases necesarias para la traducción de 
códigos de error entre entidades. 
 
• Control.util: Contiene clases que facilitan el manejo del control de flujo al 
programador. 
 
• Gateway ISO8583: Contiene clases utilizadas para generar un servidor y cliente de 
sockets TCP-IP. 
 
• Server.Exceptions: Este paquete contiene las clases para el manejo de excepciones 
de la capa de vista. 
 
• Server.ssl: Este paquete contiene las clases necesarias para el manejo de la capa de 
seguridad en la aplicación. 
 
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario 
62 
 
 
4.9.3.- Vista de Componentes 
 
Esta vista permite observar la agrupación en componentes de los distintos paquetes 
descritos en el apartado 4.9.2 para las capas de datos, vista y control. 
 
• Componente capa de Datos: Este componente contiene los paquetes de la capa de 
datos: 
 
• Data.domain 
• Data.persistence 
• Data.messages 
• Data.messages.exceptions 
• Data.messages.gbTripleDES 
• Data.messages.isoFactory 
• Data.exceptions 
• Data.util 
 
 
• Componente capa de Vista: Este componente contiene los paquetes de la capa de 
vista: 
 
• Gateway ISO8583 
• Server.exceptions 
• Server.ssl 
 
 
 
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario 
63 
 
 
• Componentes de capa de Control: Este componente contiene los paquetes de la 
capa de control: 
 
• Control.businessLogic 
• Control.businessLogic.loaders 
• Control.businessLogic.validators 
• Control.exceptions 
• Control.transform 
• Control.util 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario 
64 
 
 
4.10.- Mensajería ISO8583 Corresponsal Bancario 
 
Banco Y cuenta con una plataforma transaccional ISO8583 encargada de procesar y 
administrar transacciones electrónicas, dicha plataforma define la conectividad y lógica de los 
mensajes utilizados para recibir y responder transacciones de corresponsalía bancaria. 
 
 
Por su lado Tiendas X es capaz de generar y procesar mensajes transaccionales con formato 
ISO8583 teniendo la limitante de no poder realizar el calculo del campo 
Mesage Authentication Code (MAC) requerido por Banco Y. 
 
 
Gateway ISO8583 como intermediario entre ambas entidades tiene por responsabilidad 
interpretar, validar, agregar el campo MAC transformando los mensajes recibidos de 
Tiendas X al formato requerido por Banco Y. 
 
 
La Figura 4.28 ilustra el flujo de una transacción originada por Tiendas X, esta viaja al 
servidor expuesto por Gateway ISO8583 donde internamente es interpretada por el interprete 
que entiende el formato de Tiendas X, posteriormente es traducida y completada con el 
formato ISO8583 requerido de Banco Y, la nueva petición es enviada a Banco Y, este la 
recibe y responde a Gateway ISO8583, este interpreta la respuesta de Banco Y, la 
transforma al formato de Tiendas X y finalmente envía la respuesta a Tiendas X. 
 
 
 
 
 
 
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario 
65 
 
 
 
Figura 4.28 Flujo de intercambio, validación y traducción de mensajes entre entidades. 
 
 
 
A continuación se muestra los servicios disponibles para cada una de las entidades y el 
formato de mensajería definida por Banco Y para el esquema de corresponsalía bancaria con 
la cual se realizará el desarrollo del Gateway ISO8583 para establecer el diálogo con 
Tiendas X. 
 
 
 
 
 
 
 
 
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario 
66 
 
 
4.10.1.- Definición de mensajería de corresponsalía bancaria 
 
Veamos ahora la definición de la mensajería de cada uno de los servicios disponibles para el 
proyecto de corresponsalía bancaria. 
 
Por el lado de Tiendas X existen tres clases de servicios disponibles, autorización, reverso y 
echo. De lado de Banco Y en cambio existen solo dos clases de servicios disponibles, 
autorización y reversos. 
 
 
En la Tabla 4.29 podemos observar los servicios de mensajería IS08583 disponibles para 
Tiendas X y Banco Y. 
 
 
 
Tabla 4.29 Servicios disponibles para Tiendas X y Banco Y. 
 
Servicio Descripción Tiendas X Banco Y 
0200 / 0210 Servicio de autorización. Disponible Disponible 
0420 / 0430 Servicio de reverso de la autorización previa. 
Disponible Disponible 
0800 / 0810 Servicio de echos. Disponible No disponible 
 
 
 
A continuación se describe