Diseño de Una App Multioperable USSD para Billetera Electronica.

DISEO Y ESPECIFICACIN DE UNA BILLETERA ELECTRNICA
MVIL INTEROPERABLE COMO INTEGRACIN CON SPONTIME.
TABLA DE CONTENIDO
Contenido
1.
2.
Motivacin y Antecedentes
Descripcin del problema
3.
4.
Propuesta de solucin
Objetivos del proyecto
4.1.
4.2.
5.
Objetivo General
Objetivos Especficos
Marco Terico y Estado del arte

5.1.
Marco Terico Financiero Negocio
5.1.1. Inclusin Financiera:

5.1.2. Punto de Venta (POS Point of Sale):
5.1.3. Sociedades especializadas en depsitos y pagos electrnicos
(PAD):
5.1.4. Billeteras Mviles (m-wallet):
5.1.5. Contenido de la billetera mvil
5.1.6. Transacciones Persona a Persona (P2P):
5.1.7. Transacciones Persona a Negocio (Consumer to Business C2B):
5.2.
Marco Terico Tcnico
5.2.1. GSM (Global System for Mobile)

5.2.2. SMS (Short Message Service)
5.2.3. SMSC (Short Message Service Center).
5.2.4. USSD (Unstructured Supplementary Service Data)
5.2.5. USSD Gateway
5.2.6. MSISDN (Mobile Station Integrated Services Digital Network)
5.2.7. HTTP (Hypertext Transfer Protocol)
5.2.8. HTTPS (Hypertext Transfer Protocol Secure)
5.2.9. Protocolo SS7
5.3.
Estado del arte
5.3.1. Europa
5.3.2. Asia
5.3.3. Norteamrica
5.3.4. Oceana
5.3.5. Sudamrica
6.
Contribucin del proyecto de grado

6.1.
7.
Metodologa
7.1.
7.2.
7.3.
7.4.
7.5.
8.
Resultados que se esperan obtener

Esquema de trabajo
Fases de desarrollo del proyecto
Anlisis de riesgos y limitaciones
Cronograma del proyecto
Presupuesto
Anlisis Econmico
8.1.
Ecosistema de m-wallet
8.1.1. Stakeholders del sistema

8.2.
Modelos Econmicos
8.2.1. Modelo
8.2.2. Modelo
8.2.3. Modelo
8.2.4. Modelo
8.3.
8.4.
Centrado en el Operador
Centrado en el Banco
Colaborativo
del Proveedor de Servicios Independiente (Peer to Peer)
Comparativo entre los modelos de negocio

Modelo econmico de m-wallet
9. Anlisis Regulatorio y legal

10. Elicitacin de Requerimientos
10.1.
10.2.
Requerimientos del sistema m-wallet

Anlisis de requerimientos m-wallet
10.2.1. Clasificacin Requerimientos

10.2.2. Identificacin de Sistemas, subsistemas y asignacin de
requerimientos
10.2.3. Subespecificacin de los requerimientos funcionales
10.2.4. Asignacin de requerimientos subespecificados a subsistemas
10.3.
Especificacin Casos de Uso
10.3.1. Registrar un usuario al sistema

10.3.2. Autenticar usuario
10.3.3. Transferir dinero a comercio
10.3.4. Transferir dinero a persona natural
10.3.5. Notificar resultado de transaccin.
10.3.6. Consultar Saldo
10.3.7. Consultar historial de transacciones
10.3.8. Comprar tiempo al aire
10.3.9. Cambiar PIN
10.3.10. Depositar dinero
10.3.11. Retirar dinero
10.4.
10.5.
Diagrama de Casos de Uso

Escenarios de QAW
10.5.1.
10.5.2.
10.5.3.
10.5.4.
10.5.5.
10.5.6.
10.5.7.
10.5.8.
Escenario
Escenario
Escenario
Escenario
Escenario
Escenario
Escenario
Escenario
#1
#2
#3
#4
#5
#6
#7
#8
3
10.5.9. Escenario #9
11. Propuesta de modelo del sistema de pagos mviles (Billetera mvil / mWallet)
11.1.
Definiciones generales
11.1.1. Objetivos del sistema de pagos mviles (m-Wallet)

11.1.2. Definicin del producto
11.1.3. Supuestos
11.2.
Planteamiento de la propuesta
11.2.1. Plataforma tecnolgica

11.2.2. Servicios
11.2.3. Flujo de actividades y/o funciones del sistema
12.
Diseo del prototipo del sistema propuesto
12.1.
12.2.
Modelo de datos
Arquitectura del sistema
12.2.1. Nodos de procesamiento

12.2.2. Arquitectura de software
12.2.3. Arquitectura de hardware
13.
14.
15.
16.
Seguridad en el sistema de micropagos

Resultados
Conclusiones
Anexos
16.1.
17.
Anexo 1
Referencias bibliogrficas
RESUMEN
Existen personas en la base de la pirmide que no tienen acceso al sistema
financiero, ya que muchos no poseen el poder adquisitivo ni las herramientas
que les permitan acceder fcilmente a muchos de los servicios y productos
que estos sistemas ofrecen.
Con el fin de ampliar el acceso, Colombia hace parte de los pases de
Latinoamrica que estn sancionando leyes de inclusin financiera en las
cuales permiten la creacin de sociedades especializadas en pagos, ahorros
y depsitos electrnicos (PADE), que abren la posibilidad a las personas de
acceder a servicios financieros de manera fcil, rpida, con tramites
simplificados y a un bajo costo
Lo cual permite la entrada al sistema financiero a empresas de
telecomunicaciones y otros entes con el sistema de distribucin y capital
necesario, con el fin de crear soluciones informticas que brinden a las
personas econmicamente vulnerables mayor acceso a este tipo de
servicios.
Con el objetivo de presentar una solucin a esta problemtica, en este
proyecto de grado se realiza el diseo y la especificacin de una propuesta
de billetera mvil o sistema mvil de mircopagos interoperable dirigido a
personas de la base de la pirmide, que se hacen parte de los estratos uno y
dos.
ABSTRACT
There are people in the BOP (Bottom Of Pyramid) that have not access to the
financial system, because many of them dont have the money or the tools
to access easily to many services and products that these systems offer.
With the purpose to broaden access, Colombia is part of the Latin American
countries that are sanctioning "laws of financial inclusion" for create
"specialized companies in payments, savings and electronic deposits", which
open the possibility to access financial services in an easy and quick way,
with simplified and economic procedures.
This allows telecommunications companies and other entities with the
distribution system and enough capital to get into the financial system, to
create solutions that provide greater access to these services to
economically vulnerable people.
In order to present a solution to this problem, in this project I design and
specify mobile wallet or interoperable mobile payment system aimed at
people from the bottom of the pyramid.
LISTA DE ACRNIMOS
ORM: Operador de Red Mvil.
PPR: Punto de Pagos y Recaudos.
SMS: Short Message Service.
USSD: Unstructured Supplementary Service Data.
GSM: Global System for Global Communications.
POS: Point of Sale.
SMSC: Short Message Service Center.
HTTP: Hypertext Transfer Protocol.
HTTPS: Hypertext Transfer Protocol Secure.
HLR: Home Location Register.
VLR: Visitor Location Register.
MSC: Mobile Switching Center
MSISDN: Mobile Station Integrated Services Digital Network.
WAP: Wireless Application Protocol.
NFC: Near Field Communication.
STK: SIM Application Toolkit.
TCAP: Transaction Capabilities Application Part.
MAP: Mobile Application Part.
NDICE DE ILUSTRACIONES
Ilustracin 1: Proceso de transmisin de un SMS.
Ilustracin 2: Proceso de transmisin usando USSD.
Ilustracin 3: Stakeholders del sistema
Ilustracin 4: Modelos Econmicos del ecosistema de pagos mviles
Ilustracin 5: Escenario de los Stakeholders en el Modelo Centrado en el
ORM
Ilustracin 6: Pros VS Contras Modelo Centrado en el Operador
Banco
Ilustracin 8: Escenario de los Stakeholders en el Modelo Colaborativo
Ilustracin 9: Escenario de los Stakeholders en el Modelo del Proveedor
de Servicios Independiente
Ilustracin 10: Clasificacin de requerimientos de la billetera mvil
propuesta.
Ilustracin 11: Sistemas y susbsistemas identificados de la billetera mvil
Ilustracin 12: Asignacin de los requerimientos funcionales a los
susbsistemas.
Ilustracin 13: Diagrama de casos de uso contextual
Ilustracin 14: Estructura cadena USSD
Ilustracin 15: Proceso de Registrar usuario.
Ilustracin 16: Proceso de Autenticar usuario.
Ilustracin 17: Proceso de Transferir dinero de persona a comercio ORM
iguales.
Ilustracin 18: Proceso de Transferir dinero de persona a comercio ORM
diferentes.
Ilustracin 19: Proceso Transferir dinero de persona a persona ORM
iguales.
iguales.
Ilustracin 21: Proceso de enviar notificaciones.
Ilustracin 22: Proceso de cancelar operacin
Ilustracin 23: Proceso de consultar saldo
Ilustracin 24: Proceso de consultar historial
Ilustracin 25: Proceso de bloquear cuenta
Ilustracin 26: Proceso de comprar tiempo al aire
Ilustracin 27: Proceso de cambiar PIN
Ilustracin 28: Proceso de depositar dinero en la cuenta virtual.
8
Ilustracin
Ilustracin
Ilustracin
Ilustracin
29:
30:
31:
32:
Proceso de retirar dinero de cuenta virtual

Modelo entidad-relacin
Diagrama de deployment
Diagrama de la arquitectura de hardware
NDICE DE TABLAS
Tabla 1: Cronograma Proyecto de grado 1
Tabla 2: Pros VS Contras Modelo Centrado en el Banco
Tabla 3: Pros VS Contras Modelo Colaborativo
Tabla 4: Pros VS Contras Modelo Proveedor de Servicios Independientes
Tabla 5: Comparacin Modelos de negocio de una billetera mvil
Tabla 6: Requerimientos funcionales de la billetera mvil propuesta.
Tabla 7: Subespecificacin de los requerimientos funcionales de la
billetera mvil
Tabla 8: Asignacin de subrequerimientos a los subsistemas.
Tabla 9: CU-1 Registrar un usuario en el sistema.
Tabla 10: CU-2 Autenticar usuario
Tabla 11: CU-3 Transferir dinero a comercio
Tabla 12: CU-4 Transferir dinero a persona natural
Tabla 13: CU-5 Notificar resultado de transaccin.
Tabla 14: CU-6 Consultar Saldo
Tabla 15: CU-7 Consultar historial de transacciones
Tabla 16: CU-8 Comprar tiempo al aire
Tabla 18: CU-10 Depositar dinero
Tabla 19: CU-11 Retirar dinero
Tabla 20: Escenario de QAW #1

Tabla 29: Comparativo de las tecnologas mviles aplicables al sistema
1. Motivacin y Antecedentes
La economa de Colombia no ha logrado brindar adecuados niveles de
acceso a una gama de bienes y servicios que se encuentran directamente
ligados al bienestar de la poblacin. Esta situacin conduce a que exista una
amplia oferta de servicios informales prestados sin el cumplimiento de
estndares, sin un adecuado esquema de proteccin del consumidor y a
elevados costos. (Congreso de la Repblica, 2014, pg. 4)
Una problemtica actual que se deriva de esta situacin es el aumento de la
inequidad social, porque la reduccin de los servicios formales afecta en
mayor proporcin a las personas de bajos recursos. En ese aspecto los
servicios financieros no son la excepcin; por esa falta de cobertura del
sector formal, gran parte de la poblacin afectada recurre a medios
informales como: el uso de efectivo para realizar transacciones, los
prestamistas o gota a gota, el envo de dinero mediante mensajera
informal, entre otras. Esto genera problemas derivados como inseguridad,
altos costos y bajas garantas.
En lo ltimos aos el Gobierno Nacional ha hecho varios esfuerzos
ejecutando planes de ampliacin de la cobertura del sistema financiero, por
ejemplo, el Sistema de Correspondencia Bancaria que el pas comenz a
desarrollar entre los aos 2006 y 2007, cuyo objetivo era llegar a regiones de
difcil acceso para dispersar algunos de los subsidios del Gobierno. Otro de
los esfuerzos fue la emisin del Decreto 4590 de 2008 que reglament las
cuentas de ahorro electrnicas (CAES), dirigidas a las personas de la base de
la pirmide para distribuir, a travs de ellas, los referidos subsidios
(Congreso de la Repblica, 2014, pg. 5).
La situacin cambi con la autorizacin para prestar los servicios financieros
de los establecimientos de crdito y cooperativas con actividad financiera a
10
travs de corresponsales no bancarios (CNB). Este fue un avance en el

desarrollo financiero del pas porque permiti reducir en gran medida los
costos de llevar productos financieros a zonas distanciadas. Sin embargo, a
pesar de los esfuerzos y las iniciativas del gobierno, factores como la falta de
informacin, la regulacin y los altos costos, han impedido alcanzar el
objetivo de una verdadera masificacin de los servicios financieros,
especialmente en los sectores de bajos recursos.
La tecnologa se ha convertido en un instrumento vital para la inclusin
financiera, debido a su potencial para agilizar y reducir el costo de realizar
transacciones financieras, permitiendo a los intermediarios brindar productos
y servicios a sectores de la poblacin donde el establecimiento de canales
tradicionales representa costos operativos muy altos (Tecnologas para la
Inclusin Financiera, 2012). La masificacin de la variedad de servicios
electrnicos que han implementado las entidades bancarias en el pas da fe
de ello. Hoy en da se puede consultar el saldo de las cuentas desde
cualquier dispositivo, se pueden pagar los servicios pblicos, pagar facturas
y realizar compras desde un computador personal o desde un telfono mvil,
es posible realizar giros de manera electrnica y digitalizar el efectivo para
hacerlo portable.
En Colombia y Latinoamrica hay mucho por hacer en lo referente a la
utilizacin de la tecnologa en el sector financiero, y una de las barreras ha
sido la falta de regulacin. No obstante, el Gobierno Colombiano est
interesado en explotar el potencial de la tecnologa en este campo y por eso
el 21 de Octubre de 2014 el Presidente Santos sancion la Ley de Inclusin
Financiera, una norma que espera revolucionar el sector financiero dando
acceso a aproximadamente 20 millones de colombianos utilizando la
tecnologa.
Esta ley tambin atiende el panorama actual del comercio electrnico en
Colombia. Los colombianos hoy en da, sin importar el estrato, estn
haciendo uso de las nuevas tecnologas para realizar sus compras; de
acuerdo con el informe de tendencia y uso de tecnologa del DANE del 2013,
el 37% de los colombianos que se conectan a Internet lo hacen para
comprar/ordenar productos y/o servicios. (MinTIC, 2014)
Aprovechando la masificacin del uso de las nuevas tecnologas en el
comercio electrnico y el inters del gobierno en lograr inclusin financiera
apalancndose de ellas, surge este proyecto, que tiene como objetivo
disear un sistema de pagos mviles inclusivo, para que personas de
estratos 1 y 2 puedan pagar sus compras desde cualquier celular y en
cualquier punto de venta, sin necesidad de acceder a un dispositivo POS
(punto de venta, por sus siglas en ingls) o a conectividad directa a internet.
11
12
2. Descripcin del problema

Existen personas en la base de la pirmide que no tienen acceso al sistema
financiero, ya que muchos no poseen el poder adquisitivo ni las herramientas
que les permitan acceder fcilmente a muchos de los servicios y productos
que estos sistemas ofrecen. (Congreso de la Republica, 2013)
Con el fin de ampliar el acceso, Colombia hace parte de los pases de
Latinoamrica que estn sancionando leyes de inclusin financiera en las
cuales permiten la creacin de sociedades especializadas en pagos, ahorros
y depsitos electrnicos (PADE), que abren la posibilidad a las personas de
acceder a servicios financieros de manera fcil, rpida, con tramites
simplificados y a un bajo costo (Congreso de la Republica, 2013, pg. 16). De
esta manera permiten la entrada de empresas de telecomunicaciones y otros
entes privados al sector financiero. Sin embargo, esta oportunidad no se est
aprovechando porque consideran el desarrollo de la misma como una labor
muy dispendiosa y existe un factor de riesgo alto al tercerizar ese desarrollo
en las fbricas de software a la medida.
3. Propuesta de solucin
Con el fin de dar un aporte para la solucin de la problemtica planteada, el
presente proyecto de grado propone el diseo y especificacin de un sistema
de micropago electrnico mvil, basado en tecnologa USSD y en la red GSM,
para personas de estratos 1 y 2, utilizando al Operador Mvil como
intermediario entre los comercios y el consumidor para la realizacin de
transacciones financieras a bajo costo y de esta manera impulsar la inclusin
financiera.
13
4. Objetivos del proyecto

4.1.
Objetivo General
Disear y especificar la arquitectura de software, hardware e interconexin

de un sistema de transacciones econmicas para dispositivos mviles que le
permita al usuario pagar en establecimientos comerciales sin necesidad de
tener un plan de datos o estar conectado a una red WiFi.
4.2.
Objetivos Especficos
1. Especificar y priorizar los requerimientos

funcionales
y
arquitectnicamente significativos de un sistema de transacciones
econmicas para dispositivos mviles sin acceso a internet.
2. Describir y especificar los la propuesta de un sistema de
transacciones econmicas para dispositivos mviles y los requerimientos y
restricciones no funcionales relacionados con el su cocomponente de
negocio
de un sistema de transacciones econmicas para dispositivos mviles.
3.
4. Describir y especificar los componentes de hardware y
telecomunicaciones de un sistema de transacciones econmicas
para dispositivos mviles.
5.
6.
7. Disear la arquitectura global de un sistema de transacciones
econmicas para dispositivos
requerimientos funcionales y
14
mviles, que cumpla con

no funcionales e incluya
los
las
especificaciones de software, hardware e interconexin.
8.
9.
10. Especificar
y
priorizar
los
requerimientos
funcionales
y
arquitectnicamente significativos de un sistema de transacciones
econmicas para dispositivos mviles sin acceso a internet.
5. Marco Terico y Estado del arte

5.1.
Marco Terico Financiero Negocio

5.1.1. Inclusin Financiera:
La inclusin financiera puede definirse como el "acceso y uso de servicios

financieros de calidad por parte de todos los segmentos de la poblacin
(Graham, 2013). Esto significa que todos los ciudadanos, sin importar su
condicin social y econmica, tengan acceso a un conjunto de productos y
servicios financieros, como por ejemplo: crdito, ahorro, seguros, sistema de
pagos y pensiones, as como educacin financiera y proteccin al
consumidor.
5.1.2. Punto de Venta (POS Point of Sale):

Es el lugar donde una transaccin comercial es completada, es el punto en el
cual un cliente hace el pago del producto o servicio que va a comprar. En el
POS el comerciante calcula la cantidad adeudada por el cliente y le ofrece
opciones de pago.
En ocasiones este trmino se usa para referirse a las herramientas y/o
dispositivos tecnolgicos que se utilizan en los puntos de venta para generar
el pago. Un ejemplo de estos es el datafono u otro ejemplo ms comn, es la
caja registradora.
5.1.3. Sociedades especializadas en depsitos y

pagos electrnicos (PAD):
Las sociedades especializadas en depsitos y pagos electrnicos segn la
Ley No. 1735 del 21 de Octubre de 2014 son instituciones financieras cuyo
15
objetivo es (Congreso de la Republica, 2014):

Captar recursos a travs de los depsitos a los que se refiere el
artculo 2 de la Ley No. 1735.
Hacer pagos y traspasos.
Tomar prstamos dentro y fuera del pas, con las limitaciones
sealadas por las leyes.
Obrar como agente de transferencia de cualquier persona y en
tal carcter recibir y entregar dinero.
Algunos aspectos importantes para tener en cuenta con respecto a las PAD
son los siguientes:
Estas instituciones deben depositar los recursos captados en
depsitos administrados por establecimientos de crdito o en una
cuenta del Banco de la Repblica.
Las sociedades especializadas en depsitos y pagos electrnicos
estarn sujetas a la inspeccin, vigilancia y control de la
Superintendencia Financiera de Colombia.
En ningn caso las sociedades especializadas en depsitos y
pagos electrnicos podrn otorgar crdito o cualquier otro tipo de
financiacin.
5.1.4. Billeteras Mviles (m-wallet):

Es una herramienta que brinda un ambiente virtual cmodo y seguro
para almacenar informacin financiera del usuario como: las cuentas y
las contraseas de tarjetas de crdito y dbito, y el registro de los
movimientos que se realicen con ellas. Es un instrumento electrnico
que ayuda a dejar a un lado el efectivo y solo por medio de un
dispositivo mvil permite pagar servicios, realizar compras, transferir
dinero a otra persona, entre otras funciones. Adems de eso, es
considerado un mecanismo de inclusin que abre la posibilidad de
llegar donde no existen agentes bancarios, solo basta con la seal
telefnica o de internet; ofrece a las personas que nunca han tenido
una cuenta bancaria la oportunidad de tener su dinero bien recaudado,
acceder a prstamos y crditos y brinda mayor seguridad en la
custodia del mismo.
16
5.1.5.
Contenido de la billetera mvil
Una billetera mvil puede tener mltiples usos y puede facilitarle la

vida financiera a las personas de muchas maneras; puede generar,
contener, y facilitar mltiples servicios como (Guerrero Vsquez & Cuji
Dutn, 2014, pgs. 4-6):
5.1.5.1.
Pagos Mviles
Un pago mvil se puede definir como cualquier pago en el cual un

dispositivo mvil es utilizado para iniciar, activar y/o confirmar una
compra de bienes y servicios (Priso, 2006). Estos pagos pueden ser de
dos tipos:
-
Transacciones persona a persona (P2P).

Transacciones Consumidor a Negocio (C2B).
5.1.5.2.
Contenido financiero
- La billetera mvil puede ser usada como un servicio

de banca mvil que permite el acceso a una o varias cuentas
bancarias, permite ver el saldo, el historial de movimientos, pago
de facturas, informacin de cuenta, entre otros.
- Permite realizar transacciones financieras como:
pago de facturas, retiro de dinero, depsito de dinero, envo de
dinero, entre otras.
- Permite almacenar informacin de tarjetas de pago
de mltiples emisores: tarjetas prepago, tarjetas dbito y crdito.
- Puede ser usada tambin como medio para realizar
pagos remotos de bienes y servicios.
5.1.5.3.
Contenido de identificacin
- Puede ser usada como identificacin digital a travs

del telfono mvil.
17
Firma digital: control de acceso y autenticacin.
- Puede almacenar y disponer de tarjetas de

membresa, descuentos, cupones, tarjetas de embarque y/o
licencias de conducir.
5.1.5.4.
Contenido de comercio mvil
Este caso se refiere a que la billetera mvil puede servir como medio
para realizar transferencias relacionadas con propiedades o derechos
de uso de bienes o servicios, que se iniciaron o se completaron usando
el dispositivo mvil. Como por ejemplo:
-
Cupones de descuentos
Tarjetas de fidelidad
Tiquetes de transporte o de consumo de un servicio
Publicidad mvil.
5.1.6. Transacciones Persona a Persona (P2P):

Consisten en envos que se realizan entre dos personas sin necesidad
de que tengan una cuenta bancaria, ya que el dispositivo mvil puede
representar o tener alojada una cuenta virtual. Obviamente la cuenta
de origen debe tener saldo suficiente para realizar la transaccin. Las
personas cargan dinero a su cuenta en diferentes puntos de carga y de
la misma forma la persona que recibe el SMS puede hacer efectivo su
dinero en los mismos o mantenerlo almacenado en esa cuenta virtual.
5.1.7. Transacciones Persona a Negocio (Consumer

to Business C2B):
Consisten en las transacciones que se realizan en los establecimientos
comerciales. Al momento de realizar el pago se escoge la modalidad,
se le enva al encargado un cdigo generado por la billetera mvil,
luego l mismo lo ingresa al terminal de pago y en efecto la cantidad
establecida se debita de la cuenta virtual.
5.2.
Marco Terico Tcnico
A continuacin se expone los conceptos tcnicos inmersos en el

desarrollo del proyecto. Entre ellos la red GSM y sus componentes, las
tecnologas de envo de mensajes que utilizar el sistema y los
componentes fsicos que facilitan su uso, los protocolos de
18
transferencia de informacin en internet y aquellos que utiliza USSD

para conectarse con la red GSM, el mvil y la aplicacin USSD.
5.2.1. GSM (Global System for Mobile)

Conocido en espaol como Sistema Global para las Comunicaciones
Mviles, este es un sistema estndar, libre de regalas, de telefona
mvil digital.
GSM es un sistema desarrollado a partir de 1982, el cual se considera,
por su velocidad de transmisin y otras caractersticas, un estndar de
segunda generacin (2G). Su extensin a 3G se denomina UMTS y
difiere en su mayor velocidad de transmisin.
Este sistema permite conectarse a travs de un telfono mvil con el
computador y enviar y recibir mensajes por correo electrnico, faxes,
navegar por Internet, acceder con seguridad a la red informtica de
una compaa (red local/Intranet), as como utilizar otras funciones
digitales de transmisin de datos, incluyendo el servicio de mensajes
cortos (SMS) o mensajes de texto.
Utilizando los servicios y la conectividad de esta red de telefona
mediante USSD, el sistema propuesto pretende conectarse con los
dispositivos mviles de los usuarios para realizar las transferencias
electrnicamente. Esto es posible ya que USSD es una tecnologa
unida a la red GSM que transmite la informacin por los canales de
sealizacin de las redes GSM.
La red GSM tiene un conjunto variado de componentes que permiten la
conexin de telefona mvil y la prestacin de los diferentes y
mltiples servicios de la red. Para esta seccin se tendrn en cuenta
los siguientes componentes: HLR, VLR, MSC, debido a que son los
componentes de la red GSM utilizados por USSD.
5.2.1.1.
HLR (Home Location Register)
El registro de abonados locales (como se conoce en espaol) es una base de

datos que contiene informacin relativa a los abonados de la red. Una red
puede tener varias de estas bases, segn la capacidad de las mquinas, la
fiabilidad u otros criterios de explotacin elegidos por el operador. En esta
base de datos, un registro por cada uno de los abonados describe con detalle
las opciones contratadas y los servicios suplementarios a los que tiene
acceso el abonado. A esta informacin esttica del abonado est asociada
otra informacin dinmica adicional, como la ltima localizacin conocida del
19
abonado, el estado de su terminal (puede ser: en servicio, en comunicacin,

en reposo, fuera de servicio, entre otros). Cuando un abonado utiliza un
servicio de red, una parte de la informacin contenida en esta tarjeta se
transmite a su base de datos HLR que reconoce al abonado, de esta manera,
la red distingue las dos entidades, abonado y terminal.
La informacin dinmica relativa al estado y a la localizacin de un abonado
se actualiza constantemente, as, los mensajes que se deben enviar al
abonado, el nmero de telfono en caso de un reenvo temporal se
memorizan en el HLR. La informacin dinmica es muy til cuando la red
encamina una llamada hacia el abonado. Como primera medida, la red
empieza por consultar su HLR para conocer la ltima localizacin conocida,
el ltimo estado del terminal de abonado y la fecha de esos datos. (Tisal,
1999, pg. 47).
5.2.1.2.
VLR (Visitor Location Register)
El registro de localizacin de visitantes es una base de datos asociada a un

conmutador MSC. Su misin es almacenar la informacin dinmica relativa a
los abonados de paso por la red. Esta gestin es muy importante, ya que en
cada instante la red debe conocer la localizacin de todos los abonados
presentes en ella, es decir, debe saber en qu clula se encuentra cada uno
de ellos. En el VLR un abonado se describe, en particular, por un
identificativo y una localizacin. La red debe conocer esa informacin, que es
fundamental para estar en condiciones de encaminar una llamada hacia un
abonado o para establecer una comunicacin requerida por un abonado
visitante con destino a otro abonado. Dado que la caracterstica de los
abonados GSM es la movilidad, es necesario tener localizados
permanentemente a todos los abonados presentes en la red y seguir su
desplazamiento. Para cada cambio de clula de un abonado, la red debe
actualizar el VLR de la red visitada y el HLR del abonado, de ah que se
produzca un dilogo constante entre las bases de datos de la red (Tisal,
1999, pg. 49).
5.2.1.3.
MSC (Mobile Switching Center)
El MSC o Conmutador se encarga de interconectar la red de radiotelefona

con la red telefnica pblica. Para ello tiene en cuenta las eventualidades
introducidas por la movilidad, la transferencia intercelular y la gestin de los
abonados visitantes, que son los abonados de otras redes en trnsito por la
suya. El conmutador es un nodo muy importante, y proporciona acceso hacia
el centro de autenticacin que verifica los derechos de los abonados y, por
tanto, en su localizacin en la red, pero tambin en el suministro de todos los
20
teleservicios ofrecidos por la red: vocales, suplementarios y mensajera

(Tisal, 1999, pg. 47).
Este componente es el que se encarga de conectarse con el HLR y el VLR
para conocer el estado y la posicin del usuario y luego direccionar los
mensajes USSD (las transacciones) hacia los terminales mviles o desde
ellos hacia la aplicacin USSD que hace parte del sistema de pagos.
5.2.2. SMS (Short Message Service)

Es un servicio de mensajes cortos, servicio de mensajes simples o SMS.
Est disponible en los telfonos mviles que permiten el envo de
mensajes cortos (o mensajes de texto, como se conoce
coloquialmente) entre telfonos mviles. Inventado por el finlands
Matti Makkonen junto al GMS en 1985. (Fundacin Wikimedia, s.f.)
Se dise originalmente como parte del estndar de telefona mvil
digital GSM y actualmente est disponible en prcticamente todas las
redes incluyendo la red 4G, adems, hoy en da todos los celulares
incluyen esta tecnologa
por defecto.
Un SMS consiste en una cadena alfanumrica compuesta de 140 o 170
caracteres de 7 bits, con una serie de elementos en su encabezado.
Estos mensajes son procesados por un centro de servicios de mensajes
cortos, SMSC (Short Message Service Center). El SMSC se encarga de
almacenar los mensajes hasta que son enviados al destino e
igualmente es responsable de conectarlos a la red GSM.
En la siguiente figura se muestra ejemplificado el proceso de envo de
un SMS:
21
Ilustracin 1: Proceso de transmisin de un SMS.

Fuente: Anlisis de la factibilidad para la implementacin de la billetera mvil en la
ciudad de Cuenca. Pag 39. Cuenca, Ecuador, 2014.
Esta tecnologa es muy importante para el sistema de micropagos

propuesto, debido a que por medio de este se van a enviar las
notificaciones de consulta o de resultado de las transacciones del
sistema al usuario. Tambin se podra llegar a utilizar como canal
alterno para realizar las transacciones en caso de que USSD falle por
alguna razn.
5.2.3. SMSC (Short Message Service Center).

Un centro de servicios de mensajes cortos (SMSC, sus siglas en ingls)
recibe, almacena y enva mensajes cortos en una red de
telecomunicacin inalmbrica. Usando un SMSC un proveedor de red
de telecomunicaciones es capaz de proporcionar teleservicios valiosos
como, por ejemplo, paginacin alfanumrica, mensajes informativos y
mensajes de programa. (USA Patente n US6263212 B1, 2001)
5.2.4. USSD (Unstructured Supplementary Service

Data)
En espaol conocido como Servicio Suplementario de Datos no
Estructurados. Es un servicio para el envo de datos a travs de
mviles GSM, al igual que el SMS.
A diferencia de SMS, USSD no permite el almacenamiento y envo. Es
un servicio orientado a sesin tal que cuando un usuario accede a
22
algn servicio USSD, se establece una sesin y la conexin de radio

permanece abierta hasta que el usuario, la aplicacin o el paso del
tiempo la libera.
USSD es un protocolo de transmisin de mensajes que forma parte del
sistema de telefona GSM. Se trata bsicamente, de una utilizada
basada en sesiones transaccionales en las que no existe riesgo ni
prdidas ni duplicidades y, adems, la transmisin se realiza en tiempo
real.
Los servicios ofrecidos por USSD son introducidos dentro del estndar
GSM para soportar telfonos mviles antiguos y servicios especficos
de operadores, el mecanismo contenedor de USSD fue introducido
dentro del estndar GSM. Estas son las fases soportadas por este
protocolo de transporte de datos (Nacimba Chanataxi , pg. 54):
Fase 1 de USSD
En esta primera fase, las operaciones iniciadas por la red no son
soportadas, es decir notificaciones o acciones tipo push, solo son
soportadas operaciones iniciadas por el mvil, notificaciones so
acciones tipo pull. No existe un mecnaismo de dialogo
Fase 2 de USSD
Este es el estado actual del estndar. En esta fase son soportadas
tanto las operaciones iniciadas por el mvil como por la red, es decir,
soporta notificaciones o acciones tipo push y pull. Mltiples
operaciones USSD pueden ser enviadas dentro del dialogo.
Esta tecnologa es la base del sistema de micropagos propuesto en
este proyecto. Por medio de este se espera que el usuario realice y
reciba pagos a un bajo costo y desde cualquier telfono que soporte la
red GSM.
5.2.4.1.
Funcionamiento de USSD
La funcin USSD es una capacidad bsica de todos los mviles GMS.

Utiliza canales de sealizacin para transmitir informaciones
bidireccionales entre el mvil y la aplicacin definida por el operador.
(SYSMOV, pg. 2).
Los mensajes USSD son importantes para notificar, suministrar mens,
activar un servicio mvil o para realizar configuraciones del servicio de
23
telefona. Por el tamao que ocupan, se descarta un problema de

trfico y aunque los requerimientos de ancho de banda son menores
que para el servicio WAP, es mayor que en los SMS, asemejndose al
de una llamada. (Guerrero Vsquez & Cuji Dutn, 2014, pg. 53)
En la siguiente figura se muestra ejemplificado el proceso de una
conexin USSD para realizar una consulta:
Ilustracin 2: Proceso de transmisin usando USSD.

Fuente: Anlisis de la factibilidad para la implementacin de la billetera mvil en la
ciudad de Cuenca. Pag 43. Cuenca, Ecuador, 2014.
El terminal mvil establece una conexin con la aplicacin a travs de

una peticin USSD a la red de telefona GSM (conectndose con el
MSC, el HLR y el VLR y mediante protocolos SS7), a travs de la red la
peticin llega al Gateway USSD, el cual se encarga de direccionar la
peticin hacia el servidor de la aplicacin USSD, que a su vez puede
recibir informacin de proveedores de contenidos externos para
procesar las peticiones y realizar la lgica necesaria para enviar la
respuesta de nuevo al terminal mvil del usuario
5.2.5. USSD Gateway

Conjunto de software y hardware que se encarga de direccionar los
mensajes USSD desde la ruta de sealizacin a una aplicacin de
servicio y de regreso, este elemento tambin es llamado USSD Center.
Un USSD Gateway se basa en la capacidad del agente de entrega o de
la fuente para enviar y recibir mensajes USSD. Estos mensajes viajan
sobre canales de sealizacin GSM y se utilizan para consultar los
24
servicios de informacin y de activacin.

La diferencia entre un USSD Gateway y los otros tipos de Gateways es
que este mantiene una nica sesin interactiva una vez se haya
establecido la conexin.
5.2.6. MSISDN (Mobile Station Integrated Services

Digital Network)
En espaol conocida como Estacin Mvil de la Red Digital de Servicios
Integrados (RDSI). Es un nmero que identifica de manera nica una
tarjeta SIM en un telfono UMTS o GSM. En otras palabras es el nmero
de la tarjeta SIM, es decir lo que se conoce como le nmero celular
(Guiarticle, s.f.).
El MSISDN suele ir formado por el cdigo del pas seguido, del nmero
de abonado a la red del telfono. Su longitud es de mximo 15 dgitos.
Para la solucin propuesta en este proyecto, el MSIDN se va a utilizar
como identificador del usuario, usado como uno de los datos
paratoken de la autenticacin, con el fin deautenticacin para poder
ingresar al sistema y utilizar el servicio. Es decir, este hara la funcin
de un nombre de usuario.
5.2.7. HTTP (Hypertext Transfer Protocol)

En espaol conocido como Protocolo de Transferencia de Hipertexto. Es
el mtodo ms comn de intercambio de informacin en la world wide
web, el mtodo mediante el cual se transfieren las pginas web a un
ordenador. HTTP fue desarrollado por el World Wide Web Consortium y
la Internet Engineering Task Force en 1999. Este protocolo define la
sintaxis y la semntica que utilizan los elementos de software de la
arquitectura web (clientes, servidores, proxies) para comunicarse.
Es un protocolo orientado a transacciones y sigue el esquema peticinrespuesta entre un cliente y un servidor, en donde un cliente HTTP (por
ejemplo, un navegador) abre una conexin y realiza una solicitud al
servidor. Este responde la peticin con un recurso (pueden ser texto,
grficos, entre otros) o un mensaje de error (ALEGSA, s.f.).
HTTP es un protocolo sin estado, es decir, que no guarda ninguna
informacin sobre conexiones anteriores. El desarrollo de aplicaciones
web necesita frecuentemente mantener estado. Para esto se usan las
25
cookies, que es informacin que un servidor puede almacenar en el

sistema cliente (W3C).
El protocolo HTTP generalmente utiliza el puerto 80.
5.2.8. HTTPS (Hypertext Transfer Protocol Secure)

En espaol conocido como Protocolo Seguro de Transferencia de
Hipertexto. Es un protocolo de aplicacin basado en protocolo HTTP, en
pocas palabras, es la versin segura de HTTP.
HTTP es un protocolo inseguro ya que est sujeto a diferentes ataques
informticos que pueden permitirle al atacante obtener acceso a
cuentas de un sitio web e informacin confidencial. HTTPS est
diseado para resistir esos ataques y ser ms seguro.
HTTPS es utilizado principalmente por entidades bancarias, tiendas en
lnea, y cualquier tipo de servicio que requiera el envo de datos
personales o contraseas.
En trminos tcnicos, HTTPS utiliza un cifrado basado en SSL/LTS para
crear un canal seguro, ms apropiado para el trfico de informacin
sensible que el protocolo HTTP.
Algunas de las diferencias entre el protocolo HTTP y HTTPS son las
siguientes: Las URLS en HTTP comienzan de la siguiente manera,
http:// y su puerto por defecto es el 80, en cambio las URLS de HTTPS
comienzan as: https:// y su puerto por defecto es el 443.
Este protocolo de navegacin junto con el HTTP son los utilizados por
las aplicaciones web de los pagos y recargos, los servidores del banco
y el ORM para consumir los servicios web expuestos por el sistema de
micropagos propuesto.
5.2.9. Protocolo SS7

El sistema de sealizacin SS7 es un medio que utilizan los elementos
de la red de conmutacin para intercambiar informacin. Esta
informacin se transporta en forma de mensajes. Los mensajes SS7
transportan informacin relativa a establecimiento y liberacin de
llamadas. Adems, en las redes de telefona mvil tambin transportan
informacin de localizacin del usuario en la red, as como mensajes
26
de texto SMS y USSD.

El sistema SS7 es un sistema de sealizacin de canal comn. Esto
quiere decir que hay un canal que se utiliza slo para enviar
informacin de sealizacin, independientemente de si el sistema
tiene un canal portador o mltiples canales portadores. Fue necesario
crear un nuevo protocolo (MAP) para aadirle las funcionalidades
requeridas por las redes GSM, tales como consulta a registros de
usuarios.
Basndose
en
estas
nuevas
funcionalidades
se
implementaron los servicios SMS y USSD.
Estos protocolos son muy importantes para este proyecto, ya que
mediante su utilizacin el sistema pretende intercambiar informacin a
travs de USSD entre el usuario y la aplicacin que aloja la lgica de la
aplicacin.
5.2.9.1.
TCAP
Application Part)
(Transaction
Capabilities
Este protocolo surge de la necesidad de disponer de un mecanismo de

comunicaciones entre nodos de conmutacin orientados a la toma de
circuitos de voz. Este protocolo introduce el concepto de transaccin,
de forma que ofrece al nivel superior el control de comunicaciones
basada en instrucciones y respuestas, relacionadas entre s.
TCAP no soporta ms funcionalidad aparte de la correlacin entre
rdenes y respuestas. Es un protocolo de transporte de instrucciones
entre nodos de conmutacin.
Un mensaje TCAP est estructurado como un elemento de informacin
de constructor nico que consta de lo siguiente: Parte de transaccin,
que contiene elementos de informacin utilizados por el subnivel de
transaccin; una Parte de componente, que contiene elementos de
informacin utilizados por el subnivel de Componente y relacionado
con los componentes y, opcionalmente, la Parte de dilogo, que
contiene el Contexto de la aplicacin e informacin de usuario, que no
son componentes, cada componente es un elemento de informacin
constructor. (Nacimba Chanataxi , pg. 24)
Los tipos de paquetes TCAP son los siguientes;
Unidireccional
Consulta con permiso
27
Consulta sin permiso

Respuesta
Conversacin con permiso
Conversacin sin permiso
Abortar
5.2.9.2.
MAP (Mobile Application Part)
El protocolo MAP se utiliza en las redes de telefona mvil para

intercambiar informacin de gestin de la movilidad de los usuarios,
controlar el traspaso de llamadas (handover) entre centrales y para
enviar mensajes de texto SMS y USSD.
MAP especfica una serie de flujos de informacin y servicios que
posibilitan que un usuario pueda engancharse a cualquier MSC que le
d cobertura, y de esta manera pueda acceder a todos sus servicios
independientemente de su localizacin. Adems, MAP define
mecanismos de autenticacin de usuarios y terminales, derivados del
acceso radio de los usuarios.
Adicionalmente, se implement en el protocolo MAP el servicio de
envo de mensajes de texto de 160 caracteres (SMS) entre los usuarios
de las redes GSM, as como el envo de sealizacin no estructurada de
usuario (USSD).
La especificacin para las operaciones USSD es la siguiente:
MAP_PROCESS_UNESTRUCTURED_SS_REQ
MAP_UNESTRUCTURED_SS_REQUEST_REQ
MAP_UNESTRUCTURED_SS_REQUEST_CNF
MAP_PROCESS_UNESTRUCTURED_SS_REQUEST_CNF
5.3.
Estado del arte
El comercio mvil se ha convertido en el tipo de comercio electrnico

ms popular en los ltimos aos a nivel mundial, es una manera
cmoda para adquirir lo que se necesita; comprar sin mayores
complicaciones, sin salir de la casa, sin necesidad de cargar dinero en
efectivo, todo mediante el dispositivo mvil. Es una modalidad que ha
cambiado la manera en que los comercios se comunican con sus
clientes, ha cambiado la forma en que los empresas dirigen sus
esfuerzos de mercadotecnia y sus estrategias de ventas, ha sido un
28
modelo que ha ampliado sus lmites y ha expandido su tamao de

mercado a lugares inimaginables y ha incluido en sus estrategias a
clientes potenciales a los que jams hubiera podido acceder mediante
los medios tradicionales.
As mismo, el sector de la telefona mvil presenta actualmente un
panorama prspero. Amrica Latina representa en la actualidad el 10%
del mercado mvil mundial por ingresos. Su crecimiento interanual del
9% en 2012 convirti a la regin en el segundo mercado de ms rpido
crecimiento en todo el mundo. El mercado mvil de Latinoamrica est
entrando ahora en una fase nueva de su desarrollo, caracterizada por
su creciente madurez y la ralentizacin del crecimiento de los ingresos
y los suscriptores. La industria mvil ya es una piedra angular de la
economa latinoamericana. En 2012, gener el 3.7% del PIB de la
regin e hizo importantes contribuciones al empleo y a las arcas
pblicas. (GSMA, s.f.).
Debido a esta masificacin de la telefona mvil y el comercio
electrnico surgen nuevas tendencias de interaccin digital entre
cliente y comercio, entre estas tendencias se encuentran los pagos
mviles, los cuales se han convertido hoy en da en un complejo
sistema en el que intervienen varios actores como: el operador de red
mvil, usuario, cliente, comerciantes, instituciones financieras
(bancos), proveedores de software, emisores de tarjetas, entre otros.
Los pagos mviles se han convertido en una realidad y gracias a los
avances y la aceptacin de las Tecnologas de la Informacin y las
Comunicaciones (TIC), se prospectan como un servicio que
revolucionar el sector financiero, electrnico y comercial de todo el
mundo. Y es que desde hace unos aos ya se han venido
implementando propuestas por parte de los gobiernos, las instituciones
privadas, bancos, empresarios y emprendedores a nivel global, para
crear billeteras mviles y servicios de pagos electrnicos que hagan
parte de esta tendencia. Actualmente existen aproximadamente 95
plataformas que prestan servicios de billetera mvil en el mundo
(Davidson & McCarty). A continuacin los principales ejemplos de
algunas de estas implementaciones:
5.3.1. Europa
Esta industria es una de las ms avanzadas y que se encuentra a la
vanguardia de los servicios de pagos mviles a nivel mundial. No solo
ha incursionado en nuevas tecnologas y tendencias, tambin ha
29
adaptado tecnologa de antao y evolucionado ms all de la

prestacin de servicios y datos bsicos.
5.3.1.1.
Alemania
En este pas se destacan dos soluciones: MyWallet (MyWallet, s.f.) que

utiliza tecnologa NFC especialmente diseada para smartphones y
permite diferentes tipos de pago en variados establecimientos. Y
Paybox (Konrad, Zavagli, & Schuba, pgs. 11,12), el cual es un sistema
que permite pagos desde el dispositivo mvil a minoristas de mvil,
tiendas de internet, entre otros.
(GSMA, 2014)
5.3.1.2.
Reino Unido
En Reino Unido el primer servicio de pago utilizando el telfono mvil

fue lanzado en mayo de 2011, el sistema es conocido como Quick Tap
de Orange. El operador mvil Telefnica del mismo modo lanz su
servicio O2 Wallet en Octubre del 2012. El banco Barclays de igual
manera posee una aplicacin conocida como Pingit que permite la
transaccin de dinero utilizando el telfono mvil. Adems de los
mencionados, se tienen ms soluciones como: Moneto, Currency Cloud
CurrencyFair y Cashflows.
5.3.1.3.
Francia
En Francia existe la billetera mvil Orange Cash lanzada por Orange,

Wirecard y Vise Europe. Usa tecnologa NFC y sirve para hacer pagos,
consultas de saldo y transferencias (Cuji Dutan & Guerrero Vasquz ,
2014, pg. 11).
5.3.1.4.
Espaa
Espaa cuenta principalmente con una solucin llamada Vodafone

Wallet la cual presta multi-servicios financieros solo compatibles con
celulares de alta gama. (Konrad, Zavagli, & Schuba, pgs. 11,12).
5.3.1.5.
Rumania
Netopia mobilPay es el servicio lder en Rumania en lo referente a

pagos a travs de telfono celular, segn estadsticas ms del 90% de
tiendas en internet usa mobilPay. Vodafone y Cosmote. Utiliza el envo
de mensajes de texto como medio para realizar las transacciones.
30
5.3.2. Asia
La industria mvil asitica es una de las industrias que ha estado ms
a la vanguardia de la tecnologa y la revolucin financiera y desde los
aos 90 comenz con sus sistemas de pagos mviles utilizando
mtodos sin contacto (por ejemplo, como NFC). Es importante resaltar
que este tipo de tecnologas son para celulares de gama alta por ende
no se relaciona directamente con la solucin propuesta, sin embargo
vale la pena resaltarlos ya que los pases de asiticos han adoptado
una cultura sobresaliente con relacin al dinero virtual y los pagos
mviles.
5.3.2.1.
Japn
En Japn existen dos sistemas lderes en la materia: Osaifui-Keitai, que

hace uso de tarjetas IC FeliCa, desarrollado por el gigante Sony,
permite realizar pagos de pequeas cantidades de dinero. Y JCB Mobile
Wallet (JCB, 2012), que usa NFC como tecnologa base.
5.3.2.2.
Corea del Sur
En este pas existen dos soluciones mviles importantes, SK Smart

Mobile Wallet y KT Moca. Ambas aplicaciones permiten que el servicio
se pueda utilizar tickets de transporte, cine, cupones de descuento,
tarjetas de valor almacenado. El funcionamiento de la primera se basa
en lectura de cdigos de barra y QR, y la segunda se basa en NFC.
5.3.2.3.
Singapur
Existen dos servicios de pagos mviles ampliamente usados en

Singapur: mWallet y M1 NFC Service, ambos permiten almacenar
tarjetas Mastercard, Visa y E-Link para realizar pagos y transferencias.
5.3.2.4.
Hong Kong
- 3 Citi Wallet: Entre sus caractersticas estn que el

usuario recibe ofertas en cualquier lugar y tiempo, recepcin de
mensajes SMS cuando se realiza una compra y revisin del
historial de transacciones. (Boden, 2013). A pesar de su xito, el
servicio fue descontinuado el 15 de Febrero del 2015 (Citibank,
s.f.)
5.3.2.5.
Afghanistn
31
En Afghanistn, M-PAISA es el encargado de prestar el servicio de

pagos y transferencias mviles. Este servicio constituye una pieza
fundamental para el desarrollo de la economa de este pas, ya que es
un medio impulsor de la inclusin financiera en un territorio donde la
mayora de la poblacin no est bancarizada (97%), de esta manera
est ayudando a eliminar barreras econmicas en diferentes zonas
remotas y marginadas del pas. (IFC - International Finance
Corporation, pg. 1)
Este servicio de transferencia de dinero mvil es lanzado en el 2008
por Roshan, el lder de la telefona mvil en Afghanistn, en conjunto
con Vodafone. Los servicios que ofrece son:
Union.
Transferencias de dinero persona a persona.

Compras de tiempo aire.
Pago de facturas.
Permite hacer desembolsos.
Permite recibir salarios.
Permite recibir dinero del extranjero por medio de Western
La manera en que se hace la transferencia usando el mvil es a travs

de SMS (Servicios de Mensajes Cortos) y un sistema de respuesta de
voz interactiva (IVR), lo cual permite que tenga un mayor alcance de
usuarios potenciales ya que no es necesario que el celular sea de
gama alta.
5.3.3. Norteamrica
5.3.3.1.
Estados Unidos
Estados Unidos siempre ha sido potencia en lo referente a tecnologa y

siempre ha estado a la vanguardia de los ltimos avances en este
campo. Actualmente es uno de los escenarios principales para pagos
mviles y billeteras mviles y/o electrnicas y uno de los referentes de
mayor potencial de expansin en el mundo. En este pas existen
numerosas empresas representativas que prestan los servicios de
billetera mvil, las cuales usan tecnologa de punta y trabajan en
sinergia con las grandes empresas de telefona y las entidades
bancarias ms confiables. Sin embargo la mayora no desarrollan sus
servicios mediante la implementacin de las tecnologas propuestas en
este proyecto y sus modelos econmicos tambin difieren un poco. A
paser de ello, vale la pena mencionarlos ya que son las ms
32
importantes en uno de los mercados de mayor crecimiento y

representatividad como lo es el norteamericano.
ISIS Mobile Wallet (Cuji Dutan & Guerrero Vasquz , pg. 22) y Google
Wallet (Google Inc) son dos sistemas de pago mvil implementados por
gigantes de la industria como AT&T Mobility y Google Inc. Ambas
permiten vincular tus tarjetas de crdito y dbito para realizar los
pagos desde tu mvil y usan la tecnologa NFC, de la misma manera
funciona Blaze Mobile Walet, otra alternativa muy comn en el
mercado. La seguridad de estas soluciones es manejada mediante PIN
de proteccin para salvaguardar los datos. Una alternativa diferente
que se puede encontrar en EEUU es Vanitiv Mobile Wallet que brinda
servicios de pagos mviles a empresas y no a particulares, a travs del
uso de cdigos QR y computacin en la nube, tecnologas usadas
tambin por otra solucin muy similar: FIS Mobile Suite.
A pesar de la gran cantidad de alternativas existentes que utilizan
modernas tecnologas dirigidas para smartphones,
tambin hay
algunas opciones dirigidas a usuarios con celulares de baja gama que
son especficamente los que se relacionan de manera directa con la
propuesta de este proyecto. Entre ellas se encuentra Cat Mobile
Wallet, una billetera mvil que permite realizar pagos mviles gracias a
una cuenta virtual prepago y ofrece servicios que pueden ser
acoplados a gran variedad de interfaces como USSD, J2ME, SMS, STK.
(Cat Mobile Wallet).
Por ltimo, est
YellowPepper, una de las empresas de pagos
electrnicos ms representativas tanto en Norteamrica como en
Amrica Latina. Su mercado principal es Latinoamrica y ofrece
soluciones de pagos mviles y banca mvil para personas naturales,
negocios y otros emisores. Provee tercerizacin de servicios financieros
enfocados a usuarios finales en Latinoamrica, al igual que integracin
con POS y ATMs (Cajeros electrnicos) adems de plataformas
completas de USSD y NFC como servicios para instituciones bancarias
u otros. Esta es una de las pocas soluciones que ofrece servicios
utilizando tecnologas interoperables como USSD.
5.3.4. Canad
Canad es otro de los pases que est participando en la globalizacin
y desarrollo tecnolgico de los pagos mviles. No al mismo ritmo de
Estados Unidos, sin embargo tiene ya algunas empresas que estn
brindando el servicio de billetera mvil alrededor del pas. Algunos de
estos son: Omnego Mobile Wallet, PayMobile y Rogers Mobile Wallet.
33
5.3.5. Oceana
Este continente que en su mayora est compuesto por islas, solo
contiene dos pases industrializados que muestran grandes avances
tecnolgicos, estos son: Australia y Nueva Zelanda. Estos pases se
sustentan en el desarrollo de la innovacin tecnolgica y se han
convertido en grandes generadores de avances tecnolgicos, de esta
manera en los ltimos aos han hecho un importante aporte a los
pagos mviles.
5.3.5.1.
Australia
- mHITs Wallet: Es una alternativa que se lanz

inicialmente en el 2004 como una plataforma para la entrega de
vales de recarga para mviles usando SMS. En el 2006 fue
relanzada como una billetera mvil, centrndose en las
transacciones de persona a persona, sin embargo tambin realiz
un despliegue para ser aceptada como medio de pago en varios
locales comerciales en Sdney. Su modelo se basa en la tecnologa
SMS para realizar transacciones, esto quiere decir que puede ser
usada desde cualquier telfono, sin necesidad de ser un
Smartphone. Para usar este servicio no es necesario tener una
cuenta bancaria o tarjeta dbito o crdito, sin embargo, si se puede
transferir dinero desde una cuenta bancaria a una cuenta de mHITs.
Para realizar una transaccin es obligatoria la autorizacin del
propietario de la cuenta, lo que asegura el control total de la cuenta
y la confidencialidad de la informacin evitando de esta manera un
posible fraude o violacin de seguridad (Cuji Dutan & Guerrero
Vasquz , 2014, pg. 35).
5.3.5.2.
Nueva Zelanda
Nueva Zelanda a pesar de ser un pas pequeo ha desarrollado y

generado tecnologa importante para el crecimiento econmico de su
territorio. Es un pas que se encuentra a la vanguardia de los pagos
mviles, no obstante, actualmente no ha desarrollado un modelo de
billetera mvil propio, pero a arado un terreno ptimo para que
grandes empresas como Telecom, Vodafone y 2degrees oferten e
instalen sus servicios de pagos mviles. Adems se encuentra ansiosa
por explotar esa oportunidad en el mercado de los pagos mviles y por
ello, Paymark uni fuerzas con las empresas anteriormente
mencionadas para llevar a la realidad un sistema de billetera mvil
34
basado en tecnologa de NFC.
5.3.6. Sudamrica
Debido a la condicin socio-econmica en la que se encuentran la
mayora de los pases de esta parte del continente, caracterizados por
el subdesarrollo y en ocasiones las condiciones de extrema pobreza, su
aporte a la innovacin es reducido. Sin embargo esto est en
tendencia a cambiar en los ltimos aos, debido a la globalizacin y
democratizacin de las nuevas tecnologas y su participacin activa en
el emprendimiento TIC. Adems, Sudamrica se perfila como un
escenario ideal para el desarrollo de los pagos mviles y esto es
debido a su necesidad de impulsar la inclusin financiera, la mayora
de personas no tiene acceso a servicios bancarios. As que el concepto
de billetera mvil supone una alternativa considerable para el acceso
de los sectores ms pobres a los servicios financieros, ya que casi el
total de la poblacin cuenta con un telfono mvil. Actualmente no
existen muchas empresas Sudamericanas con una alternativa de
billetera mvil propia, sin embargo hay varias empresas extranjeras
presentes evaluando sus propuestas y otras de esta zona, que se
encuentran realizando estudios e implementando prototipos previos a
futuros lanzamientos.
Para el desarrollo del sistema de micropagos propuesto en este
proyecto, se debe tener muy en cuenta las soluciones de esta zona del
planeta, ya que utiliza la tecnologa en la que se basa la propuesta y
esto es debido a lo que se mencion anteriormente, la necesidad de
impulsar la inclusin financiera porque esta tecnologa reduce
considerablemente los costos de las transacciones.
A continuacin se presenta la situacin de algunas de ellas:
5.3.6.1.
Brasil
La principal caractersticas de los servicios de billetera mvil en este

pas es que nacen de la asociacin entre las entidades financieras y las
operadoras mviles.
- Oi Cartera: Esta alternativa nace de la alianza entre el
Banco de Brasil y la red electrnica de pagos mviles Cielo. Es
modelo permite:
o Realizar recargas para telefona mvil.
35
o Transferencias de dinero entre clientes.

o Extraer recargas desde terminales de Banco
Brasil.
o Realizar compras en ms de un milln de
comercios afiliados a Cielo.
Este servicio se basa en SMS y utiliza la tecnologa S@t Push que
permite encriptar los mensajes enviados y no almacena informacin
en el dispositivo para su mayor seguridad. La tarifa mensual para
este servicio es de aproximadamente de 3 dlares (Falcioni).
- Zuum: Telefnica en alianza con MasterCard, lanzaron una

alternativa de billetera mvil, ofreciendo sus servicios a los clientes
de Vivo (Telefnica en Brazil). Se prev que este proyecto beneficie
a ms de 65 millones de personas en este pas ya que son
aproximadamente el nmero de habitantes no bancarizados en
Brazil. A ellos, les permitira realizar pagos mediantes sus telfonos
mviles; transferir fondos, pagar cuentas y hacer compras en lnea.
La tecnologa en la que se basa este servicio es el USSD. La manera
de utilizarla es tan sencilla como enviar un mensaje de texto, pero
sin el costo. La inscripcin al servicio es gratuito y se hace todo
marcando * 789 # desde un telfono mvil. Luego, los clientes
podrn entonces empezar a utilizar la cuenta.
5.3.6.2.
Argentina
- Wanda Mvil: Esta billetera mvil nace de la alianza entre

Movistar y MasterCard. Los servicios que ofrece Wanda Mvil son:
o Depsito de efectivo con agentes autorizados
o Retiro de efectivo con agentes autorizados
o Envo y recepcin de dinero entre clientes
registrados en el servicio
o Recargas de celular
o Pagos en comercios afiliados (habilitado para
algunas provincias)
Este modelo es exclusivo para suscriptores de Movistar y se puede
acceder a l sin necesidad de Smartphone. El mtodo para prestar
el servicio es SMS. En cuanto a la seguridad, tiene un sistema de
autenticacin por PIN que se dispara cada vez que se va a realizar
una transaccin, esto con el fin de evitar que personas ajenas usen
el servicio en caso de robo o extravo. Adems, existe una lnea de
atencin al cliente, disponible las 24 horas, para pedir el bloqueo de
36
la cuenta. (Telefonica).
- Naranja MO: Naranja MO fue lanzada por la empresa de
servicios financieros Tarjeta Naranja que cuenta con ms de 25 aos
de experiencia. Este servicio puede ser habilitado por cualquier
persona, sea o no cliente de Tarjeta Naranja. Para habilitarlo se
debe enviar un SMS al 123469 con la palabra ALTA. Este es un
servicio de compra prepago. El proceso de compra se realiza
mediante SMS y consiste en enviar un mensaje con la palabra
COMPRA al 12369, se debe recibir un mensaje con un cdigo que
debe ser informado al vendedor y finalmente se firma el ticket (Cuji
Dutan & Guerrero Vasquz , 2014, pgs. 29-30).
5.3.6.3.
Paraguay
La situacin de Paraguay es muy favorable como escenario idneo

para los pagos mviles, ya que es el tercer pas ms pobre de
Sudamrica, lo cual implica que tiene un porcentaje considerable de
habitantes no bancarizados, sin embargo la cantidad de celulares ha
alcanzado el 100% de la poblacin.
- Tigo Money: Es un modelo de billetera enfocado
principalmente en el envo y recepcin de dinero a cualquier parte
del territorio nacional utilizando tecnologa USSD. Sus principales
servicios son:
o Giros Tigo, envo de dinero de manera rpida,
eficaz y segura.
o Pagos de facturas Tigo.
o Mini recargas.
o Retro de dinero.
o Pago en comerciales asociados a Tigo Money.
Para este servicio no es necesario el uso de un Smartphone. Y
garantiza la seguridad ya que es necesario el ingreso de una
contrasea propia del cliente para la realizacin de cada
transaccin (Tigo).
- Personal: Esta billetera mvil desarrollada por la empresa
de telecomunicaciones Personal, permite el pago y transferencia de
dinero desde y hacia el mvil; almacena el dinero de manera segura
y cuenta con el respaldo de entidades financieras reconocidas y
confiables como: Banco Atlas, Banco Continental y Financiera el
Comercio. La tecnologa de este modelo es USSD, lo cual permite
37
que pueda ser utilizada desde cualquier terminal mvil. Para la

seguridad de la informacin cada usuario cuenta con una
contrasea de cuatro dgitos que debe ser utilizada en cada
transaccin y se recomienda que se cambie peridicamente.
5.3.6.4.
Chile
Chile se presenta como un escenario ideal para desarrollar los pagos

mviles debido a su alta cuota de penetracin de celulares. Sin
embargo las empresas nacionales no han dado con una propuesta
firme que involucre tanto a las empresas de telecomunicaciones como
a las entidades financieras. No obstante, existen algunas empresas
extranjeras que encuentran en este pas un lugar idneo para
desarrollar este tipo de servicios.
5.3.6.5.
Uruguay
La caracterstica fundamental de este pas con respecto al desarrollo

de los pagos mviles es que cuenta con un apoyo total de las
instituciones financieras.
-
Bit$
La alianza de la empresa de telecomunicaciones Antel, el Banco

Repblica y VISA, dio como fruto este modelo de billetera mvil. La
tecnologa usada es USSD y por ende se puede utilizar en cualquier
tipo de dispositivo celular. Sin embargo, tambin se ha desarrollado un
app en Android para comodidad de los usuarios con Smartphone, como
medida de seguridad esta app solo puede funcionar con conexin a
Internet mediante plan de datos y no usando red WiFi. Este modelo
tambin integra tecnologa SMS para la confirmacin de la identidad
del cliente. Como se puede apreciar, este modelo mezcla tres
tecnologas diferentes (USSD, SMS y la Nube) para prestar un conjunto
de servicios financieros, los cules son: comprar mediante el celular,
realizar giras nacionales, recargas de tarjetas de crdito AlfaBrou,
entre otros (Antel).
5.3.6.6.
Venezuela
Venezuela es un pas que se encuentra en una etapa de conocimiento,

investigacin e introduccin a lo referente a los pagos mviles. Este
pas presenta un alto ndice de penetracin en el mercado de la
telefona celular, lo cual indica que es un escenario idneo para
38
desarrollar modelos de billeteras mviles.

- Vippo: La empresa de pagos mviles Pago Mvil, CA
desarrolla este modelo de billetera mvil desde la localidad de
Caracas. Este modelo pretende usar la tecnologa SMS para quebrar
las barreras que establecen los celulares inteligentes. Este sistema
se visiona como el ecosistema de pagos mviles ms seguro y
confiable de Latinoamrica. Actualmente sigue en desarrollo y no
existe informacin adicional al respecto.
5.3.6.7.
Bolivia
En Bolivia el inters por entrar al ecosistema de los pagos mviles

surgi por la necesidad de distribuir el bono (subsidio) a las personas y
familias necesitadas. Gracias a los servicios que ofrecen las billeteras
mviles, se podran realizar transferencias directas hacia los
beneficiados evitando la necesidad de hacer largas filas en
instituciones financieras. Adems, se podra hacer un monitoreo de los
hbitos de consumo y saber si los recursos se estn direccionando de
la manera ms equitativa y adecuada. No obstante, existe un problema
grande para el desarrollo y despliegue de estos servicios: las personas
objetivo viven en sectores muy pobres en los cuales la infraestructura
es precaria y no soporta los requerimientos de un sistema de pagos
persona a persona o persona a negocio o negocio a persona, elevando
de esta manera los costos de implementacin. (Guerrero Vsquez &
Cuji Dutn, 2014, pg. 33)
- Tigo Money: Este servicio es el mismo que est
disponible en Paraguay, el cual se convierte, en el 2013, en el
primer servicio de pagos mviles en Bolivia. Su caracterstica o
funcin principal es el giro de dinero entre personas, aunque
tambin permite hacer consultas de saldo, mini recargas y pagos de
facturas. Este servicio est disponible para cualquier cliente de
TIGO, sin importar el tipo de dispositivo que utilice, esto gracias a
que usa tecnologa USSD. Para la seguridad, usa un mtodo de
validacin por PIN para cada transaccin que se realice (Tigo).
5.3.6.8.
Colombia
Hoy en da Colombia a pesar de ser un pas azotado por la violencia y

que en cierto sectores se encuentra sumergido en la pobreza, es un
pas con un alto crecimiento y desarrollo tecnolgico, como se ha
39
mencionado anteriormente, es un pas en el cul hay una penetracin

bastante considerable de telefonas mviles y adems existe un inters
latente por parte del gobierno de generar inclusin financiera en el
pas, as que el marco legal no sera un problema para implementar
ese tipo de servicios en el territorio colombiano; esto, sumado a las
buenas relaciones que tiene Colombia con los Estados Unidos, hace de
este pas un escenario ideal para la implementacin y masificacin de
billeteras mviles. Actualmente, existen algunos modelos que se
encuentran implementados y que da a da aumentan usuarios
considerablemente, y otros que se encuentran en desarrollo y
validacin.
- Daviplata: Este modelo de billetera mvil es desarrollado
por el banco Davivienda, cuyo objetivo es realizar transacciones
mviles con el uso de una SIM Card. Actualmente, cuenta con
aproximadamente 40000 usuarios y sigue creciendo. Sin necesidad
de una cuenta bancaria, este servicio permite:
o
o
o
o
Realizar transacciones.
Pagar servicios pblicos.
Hacer retiros de dinero.
Recargar minutos al celular.
Este servicio est disponible para cualquier celular sin importar la

operadora, puede ser Claro, Tigo, Movistar o Uff. La tecnologa que
usa es SMS, lo que hace que sea un servicio multiplataforma
(Davivienda).
GetPay: Es la billetera mvil desarrollada por el Grupo
Online, liderada por el emprendedor lvaro Arango. Su servicio
incluye: la digitalizacin de tarjetas fsicas con bonos de descuento,
que podr ver el cliente con respecto a su geolocalizacin;
almacenamiento de tarjetas de crdito y dbito; pagos de persona a
persona, persona a comercios y comercio a comercio; adems,
podr realizar compras y ventas web y micro pagos en puntos de
ventas autorizados por medio de la tecnologa NFC. Su ncleo
tecnolgico son los mensajes SMS. La aplicacin es desarrollada
para dispositivos Android y se podr integrar con servicios web. A
pesar de su gran variedad de funcionalidades y su potencial
expectativa, el servicio fue anunciado en el 2011 y hasta la fecha
todava sigue en desarrollo sin conocimiento an de una fecha
tentativa de lanzamiento (Dinero, 2011).
-
SmartWallet: SmartWallet es una billetera mvil que

40
surgi de la alianza de Credibanco y YellowPepper, la cual contar

con todo el apoyo de varias empresas del sector financiero.
Actualmente son seis instituciones financieras las que estn
trabajando con en la plataforma una de ellas Colpatria, con la cual
ya se hicieron pruebas piloto. Lo que tienen en mente con esta
propuesta es que supla a las tarjetas fsicas (dbito y crdito) que
actualmente se utilizan para realizar compras, sacar dinero, entre
otras transacciones. La tecnologa que utilizar ser NFC y para
garantizar la seguridad cada transaccin tendr un OTP (One Time
Password) que tiene una duracin en el tiempo (Parada Llanes ,
2015).
Segn informes de Gustavo Leao, presidente de Credibanco, se
espera que esta billetera salga al mercado a finales del ao 2015.
Luego de haber consultado y analizado ms de 50 propuestas de billetera
mvil de 23 pases distintos en 5 continentes, se puede concluir que la
problemtica de inclusin financiera no es solo de Colombia y Latinomerica,
sino de todo el mundo. Adems, los pagos mviles son una realidad que cada
da coge ms fuerza, con miras a convertirse en un hbito y tendencia
mundial, como lo es hoy en da el correo electrnico o las redes sociales.
Desde el punto de vista de la solucin se puede observar que la mayora de
las propuestas son modelo orientados a la operadora mvil o a la institucin
financiera o en algunos casos una mezcla de ambas, pero muy pocos estn
construidas con el objetivo de impulsar la inclusin financiera alejndose de
la bancarizacin. As como lo que este proyecto busca, un sistema
interoperable que pueda ser aplicado por diferentes instituciones financieras
y que una poblacin marginada de estratos bajos no tenga que depender de
un banco para disfrutar de los beneficios de este tipo de servicios.
Desde el punto de vista tecnolgico, se puede ver que la mayora de
sistemas usan el NFC y el SMS como tecnologa base, algunos usan el Cloud
Computing que son especialmente diseados para telfonos inteligente y
otros modelos deben tener hardware o un componente adicional como
terminal de pago. No son muchos, pero existen algunos que usan la
tecnologa USSD para abarcar el total de la poblacin, para que el sistema
pueda ser usado por medio de celulares flecha y Smartphones, el cual es uno
de los propsitos del proyecto e igualmente es una de las tecnologas en las
que se basa la propuesta.
6. Contribucin del proyecto de grado
41
El proyecto de grado tiene principalmente tres contribuciones a la solucin

de la problemtica:
- Un acotado anlisis de carcter legal de la situacin en
Colombia y relacionada con los pagos mviles.
- Un corto anlisis de los modelos econmicos relacionados
con los sistemas de pagos mviles
Propuesta de una herramienta tecnolgica sostenible, interoperable
y rentable, capaz de facilitar el acceso a ms personas al sistema
financiero.
- El diseo y la especificacin tcnica de un modelo de
billetera mvil econmico y seguro, que puede abrir el camino para
futuras implementaciones de otros modelos de billeteras mviles.
6.1.
Resultados que se esperan obtener
Al finalizar la realizacin de este proyecto se esperan obtener los siguientes

documentos entregables:
Especificacin y anlisis de los requerimientos del sistema.
Anlisis econmico y regulatorio de la implementacin de la
billetera mvil en Colombia.
Descripcin y especificacin tcnica y funcional del diseo de la
billetera mvil.
Conjunto de diagramas y documentacin que componen el
diseo de los procesos y la arquitectura de software de la billetera
mvil.
Consideraciones y manejo de la seguridad de la informacin del
sistema.
- Documento general con la explicacin de la solucin
propuesta.
- Documento con los requerimientos funcionales y su
42
clasificacin
- Documento con los requerimientos no funcionales, con su
clasificacin y priorizacin.
- Escenarios de QAW
- Anlisis tcnico de la implementacin de la billetera mvil
(viabilidad tcnica)
Anlisis econmico y regulatorio (legal) en Colombia del
desarrollo de la billetera mvil.
- Identificacin y caracterizacin de los stakeholders.
- Documento de casos de uso o historias de usuario.
- Especificacin de cada flujo de proceso. (Diagramas de
actividades)
- Modelo relacional de la base de datos
- Modelo Entidad relacin de la base de datos
- Diagrama de deployment del sistema (primera versin)
- Documento con las consideraciones tcnicas para la
implementacin del sistema.
- Documento con la especificacin de los posibles riesgos del
sistema y sus estrategias de mitigacin
- Documento con la especificacin de la poltica de
seguridad del sistema (como se garantiza la seguridad)
7. Metodologa
7.1.
Esquema de trabajo
El esquema de trabajo propuesto para el desarrollo del proyecto es el

siguiente:
A finales del ao 2014 (Noviembre-Diciembre) y a lo largo del
primer semestre de 2015, se trabajar en la realizacin de las
actividades del cronograma de este proyecto, las cuales a medida que
el estudiante las realice sern enviadas al tutor para su revisin.
El estudiante le dedicar un promedio de 12 horas de trabajo
semanal. A excepcin de la semana santa, en la cual se duplicara el
nmero de horas dedicadas al proyecto.
Se llevaran a cabo reuniones con el jefe de departamento lvaro
Pachn para tener asesoras con respecto al desarrollo del documento
y el estado del proyecto. Estas se harn por demanda.
43
7.2.
Fases de desarrollo del proyecto
El desarrollo de este proyecto de grado se dividi en cuatro fases:

1.
Fase de investigacin e ideacin:
Esta fase del proceso comprende las actividades de investigacin relacionadas

con la problemtica del proyecto. Actividades como: investigar la situacin
actual en nuestro pas referente a los pagos mviles; la importancia y
extensin a nivel nacional de la problemtica; el impacto y viabilidad de la
solucin propuesta. Al igual que actividades que tienen que ver con el desarrollo
del documento y definicin de alcance. El objetivo de esta fase es recopilar la
mayor cantidad de informacin con respecto a la problemtica tanto en
aspectos tcnicos como de negocio y de igual forma generar y validar ideas
para la consolidacin de la primera versin de la solucin propuesta.
2.
Fase de anlisis y especificacin:
En esta fase se realizar un anlisis detallado de los resultados obtenidos en la

etapa anterior. Con respecto a esta informacin, se trabajarn todas las
actividades relacionadas con el alcance del objetivo nmero dos, es decir, la
elicitacin y especificacin de los requerimientos del sistema.
3.
Fase de diseo arquitectnico y funcional
Esta fase comprende todas las actividades de diseo del sistema. En esta fase
se usarn los anlisis hechos en la fase anterior y se disear el sistema en su
totalidad. Durante esta fase se irn consolidando igualmente las primeras
versiones de los documentos de diseo.
4.
Fase de validacin y documentacin
En esta ltima fase se harn todas las pruebas y validaciones correspondientes

a los diseos y documentos resultantes de las dos fases anteriores. Tambin se
realizar y se consolidar toda la documentacin del sistema diseado. Se
revisar la escritura del documento (coherencia y cohesin, puntuacin y
acentuacin) y se harn las correcciones pertinentes con respecto a los
comentarios del tutor.
7.3.
Anlisis de riesgos y limitaciones
Los riesgos y/o limitaciones que se pueden presentar en el transcurso del

desarrollo del proyecto son:
44
A. Demasiada carga acadmica/laboral.

Mitigacin y contingencia:
Hacer una planeacin general muy
completa para poder tener un diagrama de red de toda la
secuenciacin de las actividades y los tiempos requeridos para
realizarlas, de esta forma se podr organizar mejor el tiempo.
Revisar el alcance y con respecto a ello y
al tiempo que se tiene, considerar no sobrecargarse de
responsabilidades para el semestre 2015-1.
Realizar ajustes en el cronograma inicial
para cumplir con las tareas pendientes.
B. Se presentan emergencias que impiden la asistencia a una
reunin o retrasan la revisin de los avances, sea por parte del
desarrollador del proyecto o del tutor.
Mitigacin y contingencia:
Tener planeadas actividades futuras que
no dependan del avance que se necesita revisar, para poderlas
adelantar mientras se da la revisin.
Inmediatamente despus de la fecha de
revisin que no se cumpli, cuadrar un horario o fecha lmite
para reasignarla.
Asignar ms horas de trabajo semanales
al desarrollo del proyecto.
Realizar a ms tardar en un periodo de
dos das las correcciones entregadas por el tutor, cuando se ha
presentado algn inconveniente que ha retrasado la revisin.
7.4.
Cronograma del proyecto

Entregable
Fecha de entrega
martes,
24
de
marzo de 2015
los
Especificacin
y anlisis
de
requerimientos del sistema.
Anlisis econmico y regulatorio de la domingo, 05 de abril de 2015
implementacin de la billetera mvil en
Colombia.
Descripcin y especificacin tcnica y domingo 19 de abril de 2015
funcional del diseo de la billetera
mvil
45
Conjunto
de
diagramas
y domingo, 26 de abril de 2015
documentacin que componen el
diseo de los procesos y la arquitectura
de software de la billetera mvil.
Consideraciones y manejo de la jueves, 30 de abril de 2015
seguridad de la informacin del
sistema.
Tabla 1: Cronograma Proyecto de grado 1
Fuente: AutorCronograma adjuntado en un archivo de Microsoft
Project.
7.5.
Presupuesto
En este caso, el proyecto de grado no necesita un presupuesto especfico

ya que no se van a necesitar licencias de software, ni herramientas o
dispositivos para su desarrollo, la implementacin de la solucin no hace
parte del alcance del proyecto.
8. Anlisis Econmico
8.1.
Ecosistema de m-wallet
Actualmente los servicios de pagos mviles requieren la participacin de mltiples

actores los cuales estn involucrados, de manera directa o indirecta, con el
sistema, estos son conocidos como stakeholders. Dentro del ecosistema en el
que se ve inmersa la propuesta de pagos mviles o billetera mvil expuesta en
este proyecto (m-wallet), se deben considerar otros aspectos adems de los
actores como:
- Los modelos de negocio actuales de la competencia y de los actores
involucrados.
- La infraestructura tcnica en el ecosistema.
- Los aspectos de seguridad.
- La Infraestructura legal.
46
8.1.1. Stakeholders del sistema
Ilustracin 3: Stakeholders del sistema
8.1.1.1.
Bancos - Instituciones Financieras
Los bancos u otras instituciones financieras son actores muy importantes

dentro del ecosistema de las billeteras mviles ya que son las entidades
principales en el manejo y prestacin de servicios financieros, por su
experiencia y antigedad tienen la confianza de las personas, adems
tienen la infraestructura, el capital y el conocimiento para brindar
servicios seguros y confiables, con mnimos mrgenes de error y fraude, y
pueden aportar nuevos mtodos de pagos adaptados a las nuevas
tecnologas.
Sin embargo, para la solucin propuesta en este proyecto, los bancos no
son los principales actores ya que el objetivo es empoderar a las
empresas con capacidad econmica y logstica, como por ejemplo las
empresas de telecomunicaciones, para que puedan prestar servicios
financieros a personas de la base de la pirmide que no tienen las
facilidades para acceder a los servicios que prestan las grandes entidades
47
financieras como los bancos.
8.1.1.2.
Fabricantes de dispositivos
El rol principal de estos actores es que su participacin recae

principalmente en que tienen el control del hardware de los dispositivos,
lo cual influye en la implementacin de la propuesta ya que se debe tener
en cuenta que estos dispositivos estn diseados para soportar el sistema
y si no lo estn, se debe estar en la capacidad de adaptar la solucin para
su funcionamiento, adems se debe garantizar que las funcionalidades
ofrecidas que estn integradas al dispositivo ofrezcan una excelente
experiencia al usuario.
8.1.1.3.
Comercios
Su rol en el ecosistema de esta solucin es de vital importancia, de su

compromiso y participacin depende el xito de la propuesta. Esto se
debe a que el comercio es quin est dispuesto a aceptar nuevas formas
de pago, diferentes a las tradicionales como el efectivo o las tarjetas de
crdito y dbito. Se deben tener muy en cuenta sus intereses, ya que
estn a la expectativa de tener costos menores por transaccin, mayor
seguridad, simplicidad de uso, desean poder utilizar el servicio en
cualquier lugar donde se encuentre su punto de venta y claramente,
aumentar su cuota de mercado.
8.1.1.4.
ORM
Las Operadoras de Red Mvil, cumplen una funcin vital en un ecosistema

de billetera mvil, ya que son las encargadas de gestionar los servicios de
comunicacin mvil de sus clientes, controlan la red, la tarjeta SIM y
tienen la capacidad de poner aplicaciones y funcionalidades en los
dispositivos mviles a travs de la SIM.
Adems, para m-wallet tienen un rol an ms importante ya que parte de
su modelo gira entorno a ellas, es decir, la propuesta busca empoderar a
las ORMs y convertirlas en Sociedades Especializadas en Pagos y
Depsitos Electrnicos (PAD) apalancndose de la solucin tecnolgica
que esta billetera mvil ofrece. Una caracterstica importante de las ORMs
que facilitara este modelo es que poseen una extensa red de distribucin,
sin embargo la mayora de las operadoras de telefona mvil tienen poca
experiencia en la industria de los pagos mviles en comparacin con otros
actores, lo cual es lo que se espera aprovechar y cambiar con la
propuesta de este proyecto.
48
8.1.1.5.
Proveedores de Software
Este actor tambin es muy importante para el ecosistema, ya que tiene

que ver con el factor tecnolgico de la propuesta. Su importancia radica
en que uno de los elementos fundamentales de la billetera mvil es el
software que la compone, por ejemplo las licencias de los programas que
se utilizan para su desarrollo, los lenguajes de programacin, los
frameworks, entre otros; al igual que el sistema operativo de los
dispositivos mviles en los cuales se utilizar la billetera, este tiene una
particular importancia ya que es la interfaz que tiene el usuario para
interactuar con el servicio y debe de permitirle una experiencia
agradable.
8.1.1.6.
Gobierno
El gobierno tiene una importancia radical en la planeacin,

implementacin y comercializacin de una billetera mvil, su influencia
parte del punto de vista legal y regulatorio. El funcionamiento de una
billetera mvil en cada pas en el que se implemente depende de un gran
porcentaje de las regulaciones existentes en cada uno de los gobiernos.
En este caso, para m-wallet como escenario inicial se utiliza la Repblica
de Colombia, el cual tiene legislaciones que favorecen el desarrollo de
este tipo soluciones tecnolgicas con el fin de impulsar la inclusin
financiera en el pas. Este tema se tratar con mayor detalle ms
adelante en el documento.
8.1.1.7.
Usuarios
Los usuarios son los actores vitales de este ecosistema, son la parte ms
importante de la billetera mvil, puesto que son ellos quienes adquieren
los dispositivos mviles y utilizan el servicio. Cabe mencionar que dentro
de esta categora se encuentran tambin los Comercios ya que ellos
tambin se convierten en usuarios del servicio al recibir los pagos. Se
debe tener muy en cuenta las consideraciones de los usuarios y ms an
los pertenecientes al mercado objetivo, en este caso, las personas de la
base de la pirmide, de estratos 1 y 2. Sin embargo, tampoco se debe de
olvidar los otros posibles usuarios ya que hacen parte tambin del
ecosistema, y de su participacin y su satisfaccin tambin depende los
beneficios de los usuarios objetivo y el crecimiento del alcance del
sistema.
Algunas de las expectativas de estos usuarios que se recolectaron por
medio de encuestas y el anlisis del estado del arte son:
49
o Obtener un servicio seguro y confiable.

o Disponibilidad del servicio en cualquier lugar y momento.
o Obtener una experiencia de usuario agradable, que el
servicio sea fcil de utilizar.
o El costo del servicio sea bajo.
o Capacidad de realizar micro pagos.
8.2.
Modelos Econmicos
A continuacin se presentan los cuatro modelos existentes sobre los pagos

mviles que se han implementado alrededor del mundo, esto basado en el
estudio hecho por Smart Card Alliance Contactless Payment Council Mobile
Payments Work Group publicado en el ao 2008. (Smart Card Alliance, 2008).
Estos modelos son:
-
Modelo
Modelo
Modelo
Modelo
centrado en el Operador
centrado en el Banco
Colaborativo
del Proveedor de Servicios Independiente (PSI)
Ilustracin 4: Modelos Econmicos del ecosistema de pagos mviles
50
8.2.1. Modelo Centrado en el Operador

El Operador de Red Mvil (ORM) de manera independiente desarrolla el
servicio de pagos mviles y es el responsable de llevar a cabo todas las
operaciones de la transaccin. No es un modelo totalmente excluyente para
los bancos ya que estos pueden participar pero de manera secundaria.
El proceso funciona de la siguiente manera:
1. El ORM se encarga de distribuir la aplicacin en los dispositivos
mviles de los usuarios e igualmente a los puntos de venta autorizados
(POS).
2. Los usuarios pueden realizar compras o recibir pagos mediante
su dispositivo mvil.
3. El ORM descuenta el valor de la transaccin, de la cuenta
prepago que tiene el usuario.
4. Despus de estar realizada la compra, la cantidad de dinero
transferida es actualizada en la cuenta prepago del usuario.

ORM
Fuente: Smart Card Alliance (2008). Proximity Mobile Payments Business Scenarios:
Research Report on Stakeholder Perspectives (p 10).
51
8.2.1.1.
Pros y Contras para los Stakeholders
principales
Stakehol
der
Operador
de Red
Mvil
Pros
Control sobre la mayor parte del
flujo de ingresos
Apalancamiento de la
infraestructura existente para
facturar a los clientes y para
pagar a los comercios
Lealtad de los clientes/usuarios
Banco
Ninguno
Reduce el costo del manejo de
efectivo, minimizando el riesgo
de robo y los cargos de los
depsitos en efectivo
Comercio
Aumento de la eficiencia, la
continuidad y la conveniencia
Existe un potencial para

aumentar gastos impulsivos
Conveniencia del usuario
Usuario
Consumid Oportunidad de acceder a
or
servicios financieros
Contras
Adjudicacin del riesgo del
crdito adicional de los clientes
Responsabilizacin del costo
del robo y fraude
Probabilidad de que se
presente una baja aceptacin
del comercio frente al nuevo
enfoque de pago y resistencia
a adoptar un nuevo
mecanismo de POS.
Poca participacin en la
cadena de valor del
ecosistema de pagos mviles
Cobro de tasa por pagos de
bajo valor
Posibles retrasos en los pagos
porque depende de cada
operador
Inversin requerida para el
nuevo mecanismo de pago
Complejidad de facturacin
Riesgo en la seguridad
Ilustracin 6: Pros VS Contras Modelo Centrado en el Operador

Fuente: Basado en: Table 2: Pros and Cons for each Operator-Centric Model Stakeholder. Smart Card
Alliance (2008). Proximity Mobile Payments Business Scenarios: Research Report on Stakeholder
Perspectives (p. 12).
8.2.2. Modelo Centrado en el Banco

Este modelo destaca el banco entre todos los actores involucrados ya que
52
posee la funcin principal. El banco del emisor o banco consumidor es el

responsable de desplegar la aplicacin en los telfonos mviles de los
usuarios, en cambio el banco del receptor (comercio) o banco adquiriente es
el encargado de proveer al comercio el dispositivo de terminal de POS.
El proceso funciona de la siguiente manera:
1. Los bancos proveen los dispositivos de terminal de POS a los
comercios y la aplicacin instalada a los usuarios compradores.
2. Los usuarios utilizan la aplicacin instalada en sus dispositivos
para realizar las compras, interactuando con el dispositivo POS de los
comercios.
3. Despus de la compra, el banco emisor (del usuario) reduce el
saldo de la cuenta del consumidor por el monto de la transferencia
realizada.
4. El comercio entrega el producto o servicio al consumidor, e
inmediatamente despus comienza el proceso de transferencia del dinero
a la cuenta del vendedor.
5. Los bancos, tanto del consumidor como del comercio, acuerdan
el proceso de transferencia, garantizando que la cantidad de dinero
transferida de la cuenta del emisor sea igual a la depositada en la cuenta
del comercio, con lo cual se da por terminado el proceso de compra/pago.

Banco
Fuente: Smart Card Alliance (2008). Proximity Mobile Payments Business Scenarios:
Research Report on Stakeholder Perspectives (p 14).
53
8.2.2.1.
principales
Stakehold
er
Operador
de Red
Mvil
Pros
Posible aumento en el volumen
de transacciones y por ende
aumento en los ingresos
Potenciales honorarios de
incentivos por la introduccin de
nuevos clientes
Flujo de ingresos por los micro
pagos
Banco
Reduccin en el manejo de
cheques y efectivo
Potencial adquisicin de nuevos
clientes
Aumento del valor de la relacin
con el cliente y la tasa de
retencin
Oportunidad potencial para
agregar publicidad de valor a los
minoristas por una tarifa
Comercio
Usuario
Consumid
or
Contras
Posible exclusin de la
cadena de valor de los pagos
mviles
Potencial para el pago de
renta por parte delos
operadores. Posible
dependencia hacia estos ya
que pueden bloquear su uso
Limitada experiencia en la
distribucin de aplicaciones y
el manejo de la tecnologa
Costo adicional por el
mantenimiento de
aplicaciones mviles para
mltiples operadores y
modelos de celulares.
Reduce el costo del manejo de

efectivo, minimizando el riesgo de
robo y los cargos de los depsitos
Comisiones y/o cargos por
en efectivo
transacciones de bajo valor
Aumento en la eficiencia y
rendimiento de los cajeros y la
reduccin de filas.
Resistencia a aumentar las
Incremento de gastos impulsivos
transacciones por tarjeta
Pago rpido y directo
debido al intercambio.
Limitado a un banco
Velocidad y conveniencia
especfico que ofrece el
Brinda mayor seguridad y
servicio
confianza.
54
Alternativa a los costosos cargos

de los cajeros automticos
Tabla 2: Pros VS Contras Modelo Centrado en el Banco
Fuente: Basado en: Table 3: Pros and Cons for each Bank-Centric Model Stakeholder. Smart Card
8.2.3. Modelo Colaborativo

Este modelo es una mezcla o fusin entre los dos modelos anteriores,
involucra una colaboracin directa entre los bancos y los operadores de red,
y la participacin de una tercera parte que genera el lazo de conexin entre
ambos actores. Para este modelo se presentan dos escenarios:
- Escenario 1: El ORM y el banco se puede asociar para que el operador
proporcione la plataforma de pago mvil de un banco especfico.
- Escenario 2: El ORM y el banco usan la plataforma tecnolgica de un
tercer actor para prestar el servicio en su nombre.
El proceso funcionara de la siguiente manera:
1. Se genera una asociacin entre los bancos y el ORM para prestar
el servicio.
2. El ORM o un proveedor de servicios despliega la infraestructura
tecnolgica, la cual es elegida por el ORM y el banco y cada uno recibe un
procentaje de las transacciones efectuadas.
3. Los usuarios utilizan el servicio mediante su dispositivo mvil y el
terminal del POS para realizar la compra.
4. Despus de realizar la compra, el banco y el ORM cobran una
cuota por la transaccin. Para este caso, el banco reduce la cuenta del
consumidor y el operador reduce el valor de la cuenta prepago.
5. Una vez entregado el producto o servicio, comienza la
transferencia del dinero de la cuenta del emisor al receptor.
6. Los bancos, tanto del consumidor como del comercio, acuerdan
el proceso de transferencia, garantizando que la cantidad de dinero
transferida de la cuenta del emisor sea igual a la depositada en la cuenta
del comercio, con lo cual se da por terminado el proceso de compra/pago.
55
Ilustracin 8: Escenario de los Stakeholders en el Modelo Colaborativo

Fuente: Smart Card Alliance (2008). Proximity Mobile Payments Business Scenarios: Research
Report on Stakeholder Perspectives (p 24).
8.2.3.1.
principales
Stakehold
er
Operador
de Red
Mvil
Banco
Pros
Concentracin en
competencia bsica
Potencial adquisicin de
nuevos clientes
Ingresos por las
transacciones y la
transmisin de datos
Canal alternativo de
comunicacin
Oportunidad para la
adquisicin de nuevos
clientes al asociarse con el
operador mvil
56
Contras
Complejidad con respecto al
costo y tiempo de la
negociacin con los bancos
y/o aliados
Disminuye la necesidad de los
clientes de usar los ATM por
ende los ingresos por este
medio resultan rebajados
Ingresos adicionales por

transacciones
Comercio
Usuario
Consumid
or
Proveedo
r del
servicio
Tiempos de transacciones
ms rpidos
Reuccin en los costos del
manejo, de efectivo
Satisfaccin del cliente
Mercado segmentado
Servicios bancarios
disponibles desde su banco
de preferencia
Reduccin del tiempo de
espera
Aumento de las inversiones,

por la creacin de alicaciones
y establecimiento de nuevas
normas
Los gastos por procentaje de

transaccin en vez de efectivo
Es necesario obtener y activar

la aplicacin de un banco
especfico en el dispositivo
Se asume el riesgo de la
Potencial de tener un nuevo
gestin de la informacin
modelo de negocio basado
confidencial de los clientes y
en transacciones
la autenticacin
Oportunidad para ofrecer
Falta de experiencia en la
contenido de valor
implementacin e integracin
agregado
del servicio
Tabla 3: Pros VS Contras Modelo Colaborativo

Fuente: Basado en: Table 5: Pros and Cons for each Collaboration Model Stakeholder. Smart Card
8.2.4.
Modelo del Proveedor
Independiente (Peer to Peer)
de
Servicios
En este modelo la funcin principal la toma un tercer actor, el Proveedor de

servicios, de esta forma el rol que tenan en los anteriores modelos el banco
y el operador pasan a un segundo plano.
1. El proveedor de servicios es el encargado del despliegue de la
infraestructura tecnolgica para brindar el servicio de pagos mviles
tanto en los dispositivos de los usuarios como en los POS de los
comercios.
57
2. Luego, los usuarios y los comercios deben abrir una cuenta en el

sistema del proveedor de servicios para que de esta forma se puedan
procesar los pagos.
3. Lo usuarios realizan compras en el POS mediante el portal del
proveedor de servicios.
4. El proveedor de servicios solicita al banco del consumidor
procesar la transferencia.
5. El banco realiza sus respectivos procesos de verificacin, para
luego realizar la transferencia.
6. El proveedor de servicios recibe el dinero del banco y realiza una
transferencia a la cuota del comercio.
7. El proveedor de servicios realiza el cobro de una comisin por la
transferencia.
Ilustracin 9: Escenario de los Stakeholders en el Modelo del Proveedor

de Servicios Independiente
Fuente: Smart Card Alliance (2008). Proximity Mobile Payments Business Scenarios: Research
Report on Stakeholder Perspectives (p 19).
8.2.4.1.
principales
Stakehol
Pros
Contras
58
der
Posible aumento en el
volumen de transacciones
Operador de datos
de Red
Oportunidad para
Mvil
asociarse con el proveedor
de servicios
Oportunidad para formar
sociedades
Banco
Acceso a un conjunto ms
amplio de clientes del
proveedor de servicios
Flujo de ingresos por las
tarifas de procesamiento
Posible de la cadena de valor de

los pagos mviles
Problemas de servicio al cliente,
ya que pueden llamar a quejarse
por problemas del proveedor de
servicios
Posibilidad de exclusin de la
cadena de valor si el proveedor
de servicios elige otro banco
(diferente a los participantes)
como procesador de pagos
Falta de visibilidad de las
transacciones de los clientes
Certificacin de seguridad de los
dispositivos
Comisiones al proveedor de
servicios para transacciones de
bajo monto
Riesgo adjudicado en caso de
perdida, litigio o fraude
Reduccin del coste de

manejo de efectivo
Acceso a programas de
fidelizacin
Comercio
Mayor velocidad de
procesamiento, pagos ms Proveedor de servicios nuevo, con
rpidos.
limitada reputacin en el
mercado
Potencial aumento del
nmero de transacciones
Necesidad de transferir fondos al
Usuario
Potencial para opcin de
Necesidad de gestionar nuevos
Consumi
pago menos costosa
proyectos de ley
dor
Dificultad en la gestin de
conflictos
Captura de ingresos por
las comisiones de las
Responsabilizacin del riesgo por
transacciones
robo o fraude
Proveed
Oportunidades de venta
Altos costos de entrada para
or del
cruzadas para otros
ganar una amplia aceptacin por
servicio
productos o servicios de
parte de los comerciantes y
su portafolio
consumidores
Ingresos por mercadeo
Bajo uso hasta la fecha
59
Tabla 4: Pros VS Contras Modelo Proveedor de Servicios Independientes

Fuente: Basado en: Table 4: Pros and Cons for each Peer-to-Peer Model Stakeholder Smart Card Alliance
(2008). Proximity Mobile Payments Business Scenarios: Research Report on Stakeholder
8.3.
Modelo
Comparativo entre los modelos de negocio

Actor
Banco
ORM
Centrado
en el
Banco
Usuario
Consumi
dor
Comercio
Colaborativ
o
Centrado
en el
Operador
Beneficios
Nuevas fuentes de
ingresos por
transacciones realizadas
Incremento en el trfico
de datos por la red, por
ende se genera un
aumento en los ingresos.
Tienen a disposicin una
manera rpida y
confortable de realizar
compras
Se reducen los riesgos
por manejo de dinero en
efectivo
Banco
No tiene responsabilidad en
el despliegue del servicio
ORM
Nuevas fuentes de ingresos

por transacciones
realizadas
Usuario
Consumid
or
Poseen varias opciones de

realizar un pago
Comercio
Aumento en la satisfaccin
de los usuarios
Banco
No posee beneficios
60
Inconvenientes
Asume los costos por
despliegue
No participan en los
ingresos por
transacciones realizadas.
No tiene capacidad de
eleccin, ya que la
plataforma es
dependiente del banco
Cargos pro transaccin
realizadas, cobradas por
los bancos
Los ingresos por las
transacciones son
compartidos con el ORM
Existen inconvenientes
mientras se establecen
estndares para los
servicios
Incremento en las tarifas
por transaccin ya que
existe una tercera parte
involucrada
Requieren estar dotas de un
terminal POS sea hardware
o software
Exclusin completa de la
cadena de valor de los
pagos mviles
ORM
Usuario
Consumi
dor
Comercio
Banco
Proveedor
de
Servicios
Independie
nte (PSI)
ORM
Posee autoridad en el
proceso completo y
puede maximizar sus
beneficios
Menos problemas y
probablemente mejor
servicio al cliente ya que
el servicio es prestado
directamente por el ORM
Brinda una atraccin a
clientes que estn
dispuestos a
experimentar una nueva
forma de pagos
Nuevas oportunidades de
adquirir usuarios
mediante alianzas
Incremento en el trfico
de datos, por ende es
probable que aumente
sus flujo de ingresos
Usuario
Consumi
dor
Tasas de traccin
reducidas
Comercio
Incremento en el nmero
de transacciones, por
ende incremento en las
ventas
PSI
Posee mayor control

sobre los canales de
ingresos
Incremento de riesgos
por la seguridad debido a
la ausencia del banco
Incremento de riesgos
por la seguridad debido a
la ausencia del banco
El ORM es quin impone
la tasa por las
transacciones realizadas
Se reducen los ingresos
en comparacin con otros
modelos
No participa de las
ganancias por las
transacciones de dinero
Se requiere una cuenta,
la cual es administrada
por el proveedor de
servicios
Las cuotas por
transacciones son
cobradas por el
Se requiere una inversin
alta por el
establecimiento de
infraestructura
Tabla 5: Comparacin Modelos de negocio de una billetera mvil

Fuente: Basado en: Figura 3.7 Comparacin de los modelos de negocio. Cuji Dutan Diego Andres
& Guerrero Vsquez Luis Fernando (2014). Universidad Politcnica Salesiana. Anlisis de la
factibilidad para la implementacin de la billetera mvil en la ciudad de Cuenca (p. 75).
8.4.
Modelo econmico de m-wallet
61
Con respecto al anlisis realizado de los modelos econmicos existentes para

las billeteras mviles, el modelo econmico que mejor se adapta a la solucin
propuesta en este proyecto es el Modelo Colaborativo, haciendo referencia al
escenario 2, donde no solo estn involucrados el banco y la ORM, sino tambin
un tercer actor, que vendra siendo el Proveedor de Servicio, en este caso, el
proveedor de m-wallet. Sin embargo tambin se presentan algunas variantes y
consideraciones especiales:
- El banco no es un actor principal del modelo, es un actor secundario y
se usa como opcin adicional para el procesamiento de los pagos.
- El actor principal del modelo es el Operador Mvil quien despliega la
plataforma tecnolgica (m-wallet) de un tercero y se encarga de procesar los
pagos.
- La Operadora de red mvil es la que se encarga de comunicarse con
los bancos del consumidor y el comercio (o emisor y receptor) para debitar y
acreditar el monto de las transacciones.
1. La ORM se asocia con el proveedor de servicios (proveedor de mwallet) para desplegar toda la plataforma tecnolgica en los dispositivos de
los usuarios abonados, tanto en el consumidor como en los terminales POS.
2. Los usuarios (consumidores y comercios) deben activar su cuenta en la
billetera o sus permisos para usar el servicio, esto mediante un portal web o
acercndose a una sucursal de sus respectivas ORM.
3. Los usuarios realizan compras, transfieren dinero y reciben pagos
mediante el servicio de la billetera mvil.
4. Dependiendo de las preferencias y condiciones especificadas por el
usuario el ORM realiza acuerdos con los bancos para procesar el pago de la
transferencia.
5. Cuando el producto o servicio ha sido entregado, el ORM se dispone a
reducir y aumentar los montos transferidos en las cuentas de sus usuarios.
6. El proveedor de servicios cobra una comisin sobre el monto de la
transferencia realizada.
9. Anlisis Regulatorio y legal

El marco regulatorio y legislativo que cubre el ecosistema del sistema de pagos
mviles propuesto es un aspecto primordial para su implementacin y futura
comercializacin. Con este se pretende que los servicios que brinda m-wallet estn
62
disponibles a bajos precios y accesibles a la poblacin de la base de la pirmide

mediante poca o nula bancarizacin.
De acuerdo a lo estipulado por el CGAP (Consultatitive Group to Assist the Group)
se han identificado los siguientes aspectos crticos relacionados con polticas y
regulaciones que se deben tener en cuenta (Branchless Banking Diagnostic
Template):
1. Uso de agentes: Autorizacin para permitir que otras entidades que
no sean bancarias puedan servir como puntos de retiro y depsito de
efectivo u otros servicios financieros.
2. Regulacin Anti-lavado de dinero y lucha contra la financiacin
del terrorismo (AML/CFT): Desarrollo de reglas acerca del anti-lavado de
activos y contra el financiamiento al terrorismo, esto es aplicable a todas las
transacciones.
3. Dinero electrnico: Espacio regulatorio apropiado para la emisin de
dinero electrnico, en especial cuando los emisores no son entidades
financieras.
a. Para el caso de Colombia
i. No se encuentran reguladas las monedas
electrnicas, tales como bitcoin u otras que no dependan de
banco central. Sin embargo, todo dinero que tenga movimiento
por medio de medios electrnicos, necesita ser refrendado 1:1 en
el fondo nacional de garantas financieras Fogafin.
4. Proteccin al consumidor: Es necesario una proteccin eficaz de los
consumidores para hacer frente a los riesgos involucrados en los pagos
mviles.
5. Inclusin social: Se requiere una regulacin que promueva la
inclusin social a los sistemas de pagos mviles.
i. Dentro de las bases del Plan Nacional de
Desarrollo, recogido mediante la Ley 1450 de 2011, se establece
que uno de los apoyos transversales a la competitividad del pas
ser el acceso a los servicios financieros para lo cual el Gobierno
propone adoptar medidas tendientes a conseguir que los
servicios financieros mviles sean ofrecidos a la poblacin
desatendida por el sistema financiero
63
ii. Se estipula dentro de la ley 1735 de 2014, en

el artculo 9 la generacin y diseo de programas para el
desarrollo de competencias bsicas en educacin econmica y
financiera, y dentro de estas, la inclusin y capacitacin en el
uso de esta clase de sistemas. De acuerdo con lo establecido por
la ley 115 de 1994
6. Competencia: Se requieren polticas que promuevan la competencia
entre proveedores de los servicios de pago mviles.
i. Se estipula dentro de la ley 1341 del 30 de julio
de 2009, en el artculo 2, que el estado Colombiano propiciar
escenarios de libre y leal competencia que incentiven la
inversin actual y futura en el sector de las TIC y que permitan la
concurrencia al mercado, con observancia del rgimen de
competencia, bajo precios de mercado y en condiciones de
igualdad. Sin prejuicio de lo anterior, el estado no puede fijar
condiciones distintas ni privilegios a favor de unos competidores
en situaciones similares a las de otros. Incluyendo el uso
eficiente de la infraestructura, para la provisin de todas las
redes de telecomunicaciones y los servicios que sobre ellas se
puedan prestar.
7. Regulacin prudencial: Los actores no bancarizados pueden estar
sujetos a estrictas regulaciones en trminos de cumplimientos regulatorios,
de calidad y de seguridad, tanto de informacin como financiera.
i. Las propuestas de inclusin financiera son
reguladas por la ley 1735 de octubre de 2014 y por el estatuto
orgnico del sistema financiero, ya sea como Sociedades
especializadas en depsitos y pagos electrnicos o bajo la figura
de Integradores tecnolgicos.
ii. Las sociedades especializadas pueden tranzar
por s mismas, sin necesidad de una entidad financiera que los
apoye
iii. Los integradores tecnolgicos solo pueden
servir de proveedores de servicio en torno a una organizacin
64
que posea la figura de sociedad especializada en depsitos y

pagos electrnicos
8. Privacidad de datos: Se requieren polticas o legislaciones que
ayuden a garantizar la privacidad de la informacin de los usuarios.
i. La ley estatutaria 1581 de 2012 desarrolla y
obliga al cumplimiento del derecho constitucional a conocer,
actualizar y rectificar las informaciones que se hayan recogido de
ellos en bases de datos, archivos y otros medios de informacin.
ii. El usuario debe dar su autorizacin para el
tratamiento de archivos por parte de terceros.
iii. El tratamiento de los datos debe obedecer a
finalidades legtimas, solo puede ejercerse con consentimiento
previo expreso e informado, y deben existir formas
estandarizadas de acceso, consulta, reclamo y procedibilidad.
iv. Es deber del responsable del tratamiento de los
datos
1. Garantizar al Titular, en todo
tiempo, el pleno y efectivo ejercicio del derecho de hbeas
data;
2. Solicitar y conservar, en las
condiciones previstas en la presente ley, copia de la
respectiva autorizacin otorgada por el Titular;
3. Informar debidamente al Titular
sobre la finalidad de la recoleccin y los derechos que le
asisten por virtud de la autorizacin otorgada;
4. Conservar la informacin bajo las
condiciones de seguridad necesarias para impedir su
adulteracin, prdida, consulta, uso o acceso no autorizado
o fraudulento;
5. Garantizar que la informacin que
se suministre al Encargado del Tratamiento sea veraz,
completa,
exacta,
actualizada,
comprobable
y
comprensible;
6. Actualizar
la
informacin,
comunicando de forma oportuna al Encargado del
Tratamiento, todas las novedades respecto de los datos
que previamente le haya suministrado y adoptar las dems
65
medidas necesarias para que la informacin suministrada a

este se mantenga actualizada;
7. Rectificar la informacin cuando
sea incorrecta y comunicar lo pertinente al Encargado del
Tratamiento;
8. Suministrar al Encargado
del
Tratamiento, segn el caso, nicamente datos cuyo
Tratamiento est previamente autorizado de conformidad
con lo previsto en la presente ley;
9. Exigir al Encargado del Tratamiento
en todo momento, el respeto a las condiciones de
seguridad y privacidad de la informacin del Titular;
10.
Tramitar las consultas y
reclamos formulados en los trminos sealados en la
presente ley;
11.
Adoptar un manual interno
de polticas y procedimientos para garantizar el adecuado
cumplimiento de la ley 1581 de 2012 y en especial, para la
atencin de consultas y reclamos;
12.
Informar al Encargado del
Tratamiento cuando determinada informacin se encuentra
en discusin por parte del Titular, una vez se haya
presentado la reclamacin y no haya finalizado el trmite
respectivo;
13.
Informar
Titular sobre el uso dado a sus datos;
solicitud
del
14.
Informar a la autoridad de
proteccin de datos cuando se presenten violaciones a los
cdigos de seguridad y existan riesgos en la administracin
de la informacin de los Titulares.
15.
Cumplir las instrucciones y
requerimientos que imparta la Superintendencia de
Industria y Comercio
v. Es deber de los encargados del tratamiento de
datos:
1. Garantizar al Titular, en todo
tiempo, el pleno y efectivo ejercicio del derecho de hbeas
data;
66
2. Conservar la informacin bajo las

condiciones de seguridad necesarias para impedir su
adulteracin, prdida, consulta, uso o acceso no autorizado
o fraudulento;
3. Realizar
oportunamente
la
actualizacin, rectificacin o supresin de los datos en los
trminos de la presente ley;
4. Actualizar la informacin reportada
por los Responsables del Tratamiento dentro de los cinco
(5) das hbiles contados a partir de su recibo;
5. Tramitar las consultas y los
reclamos formulados por los Titulares en los trminos
sealados en la presente ley;
6. Adoptar un manual interno de
polticas y procedimientos para garantizar el adecuado
cumplimiento de la presente ley y, en especial, para la
atencin de consultas y reclamos por parte de los Titulares;
7. Registrar en la base de datos las
leyenda reclamo en trmite en la forma en que se regula
en la presente ley;
8. Insertar en la base de datos la
leyenda informacin en discusin judicial una vez
notificado por parte de la autoridad competente sobre
procesos judiciales relacionados con la calidad del dato
personal;
9. Abstenerse de circular informacin
que est siendo controvertida por el Titular y cuyo bloqueo
haya sido ordenado por la Superintendencia de Industria y
Comercio;
10.
Permitir el acceso a la
informacin nicamente a las personas que pueden tener
acceso a ella;
11.
Informar
a
la
Superintendencia de Industria y Comercio cuando se
presenten violaciones a los cdigos de seguridad y existan
riesgos en la administracin de la informacin de los
Titulares;
12.
Cumplir las instrucciones y
requerimientos que imparta la Superintendencia de
Industria y Comercio.
67
9. Comercio y seguridad electrnica: Deberan existir regulaciones

para las actividades relacionadas con el comercio electrnico y el manejo de
la seguridad de la informacin a travs de estos servicios.
10.
Regulacin del Operador Mvil: Deben existir regulaciones
que permitan igualdad de condiciones de acceso tecnolgico, de
infraestructura y de servicios para fomentar la libre competencia, con el
objeto de conseguir que los servicios financieros mviles sean ofrecidos a la
poblacin desatendida por el sistema financiero, fortaleciendo directamente
a los intermediarios y a las entidades financieras, o permitiendo la creacin
de nuevos instrumentos que ayuden a cerrar la brecha de inclusin.
i. Resolucin 4458 de 2014 por la cual se
modifican las resoluciones CRC 3066, 6496, 3500 y 3501 de
2011 y se dictan otras disposiciones en la cual se definen los
precios y la igualdad de condiciones en trminos de acceso a
infraestructura tecnolgica por parte de terceros.
11.
Regulacin en los impuestos.
10. Elicitacin de Requerimientos

A continuacin se listarn los requerimientos funcionales y no funcionales del
sistema de micropagos propuesto. El origen de esta elicitacin no surgi de un
cliente especficamente como se acostumbra en este tipo de procesos. Los
requerimientos que se mencionarn en seguida surgen del anlisis de las
soluciones, que se mencionaron en el Estado del arte, relacionadas con los pagos
mviles. Igualmente se tuvo en cuenta las principales funcionalidades que debe
tener un sistema clsico de pagos y los resultados de un encuesta aplicada 80
personas de diferentes estratos (1-6) realizada como insumo de un anlisis de
mercado que se hizo previamente a la realizacin de este proyecto de grado (los
resultados se pueden ver en el Anexo 1).
10.1.
Requerimientos del sistema m-wallet
R01. El sistema debe permitir al usuario registrarse con el fin de estar habilitado
para usar la billetera.
68
R02. El sistema debe garantizar que los usuarios que van a realizar una
transaccin estn autorizados para realizarla.
R03. El sistema debe permitir al usuario usar el servicio para recibir el pago de un
comprador sin necesidad de estar conectados a una red WiFi o un plan de datos, el
cual debe ser actualizado en su cuenta.
R04. El sistema debe permitir al usuario transferir dinero otra persona natural,
usando como soporte financiero la operadora mvil, sin necesidad de estar
conectados a una red WiFi o un plan de datos.
R05. El sistema debe permitir que el servicio sea compatible con el 90% de los
dispositivos del mercado.
R06. El sistema debe permitir la realizacin de los pagos mediante tecnologa
USSD.
R07. Las notificaciones desde el proveedor a los usuarios deben de hacerse
mediante SMS.
R08. El sistema debe ser interoperable, permitiendo la interconexin entre los
diferentes operadores.
R09. El sistema de permitir al usuario consultar la informacin de sus movimientos
financieros en el dispositivo mvil.
R10. El sistema debe garantizar autenticidad, confidencialidad e integridad de la
informacin para cada una de las transacciones.
R11. El sistema debe garantizar que si la transaccin no se efecta exitosamente
se notificar a los usuarios y se reenviar la informacin en menos de 10
segundos.
R12. El sistema debe garantizar la disponibilidad del servicio al menos en un 98%
del tiempo.
R13. El sistema debe ser adaptable al uso de NFC, SMS y Cloud para la realizacin
de las transacciones.
R14. El sistema debe tener mens interactivos para que los usuarios seleccionen
la actividad a realizar e ingresen informacin.
R15. El sistema debe notificar por SMS que la transaccin se realiz con xito.
69
R16. El sistema debe cancelar la operacin completa si se present algn error en

la transaccin.
R17. Si se present un problema en la m-wallet, el sistema debe de enviar un
mensaje con el detalle del error por SMS.
R18. El sistema debe permitir que el usuario cambie el PIN de autenticacin.
R19. El sistema debe permitir al usuario poder comprar tiempo al aire desde el
dispositivo mvil.
R20. El sistema debe permitir al usuario, a travs un punto de pago y recaudo,
depositar dinero en su billetera mvil, su saldo aumentar en su cuenta.
R21. El sistema debe permitir al usuario, a travs un punto de pago y recaudo,
retirar dinero de su billetera mvil, su saldo se reducir en su cuenta.
10.2.
Anlisis de requerimientos m-wallet
A continuacin se especifica el anlisis realizado a los requerimientos funcionales y

no funcionales del sistema de pagos mviles propuesto, m-wallet. El anlisis de
requerimientos funcionales se hace usando el mtodo de Dorfman.
10.2.1.
Clasificacin Requerimientos
70
Ilustracin 10: Clasificacin de requerimientos de la billetera mvil

propuesta.
10.2.1.1.
Cdigo
Requerimie
nto
R01
R02
R03
Requerimientos Funcionales
Requerimiento
El sistema debe permitir al usuario registrarse

con el fin de estar habilitado para usar la
billetera.
El sistema debe garantizar que los usuarios
que van a realizar una transaccin estn
autorizados para realizarla.
El sistema debe permitir al usuario usar el
servicio para transferir dinero a un
establecimiento fsico o comercio sin
necesidad de estar conectados a una red WiFi
o un plan de datos, el cual debe ser
71
actualizado en su cuenta.
R04
R9
R15
R16
R17
R18
R19
R20
R21
Tabla 6:
propuesta.
El sistema debe permitir al usuario transferir

dinero otra persona natural, usando como
soporte financiero la operadora mvil, sin
necesidad de estar conectados a una red WiFi
o un plan de datos.
El sistema de permitir al usuario consultar la
informacin de sus movimientos financieros
en el dispositivo mvil.
El sistema debe notificar por SMS que la
transaccin se realiz con xito.
El sistema debe cancelar la operacin
completa si se present algn error en la
transaccin.
Si se present un problema en la m-wallet, el
sistema debe de enviar un mensaje con el
detalle del error por SMS.
El sistema debe permitir que el usuario
cambie el PIN de autenticacin.
El sistema debe permitir al usuario poder
comprar tiempo al aire desde el dispositivo
mvil
El sistema debe permitir al usuario, a travs
un punto de pago y recaudo, depositar dinero
en su billetera mvil, su saldo aumentar en
su cuenta.
El sistema debe permitir al usuario, a travs
un punto de pago y recaudo, retirar dinero de
su billetera mvil, su saldo se reducir en su
cuenta.
Requerimientos funcionales de la billetera mvil
72
10.2.2.
Identificacin de Sistemas, subsistemas
y asignacin de requerimientos
10.2.2.1.
subsistemas
Identificacin
de
sistemas
Teniendo en cuenta la informacin recopilada de los requerimientos se pudo

identificar los sistemas y susbsistemas detallados en la Figura 8.
Ilustracin 11: Sistemas y susbsistemas identificados de la billetera

mvil
Luego de esto, se asignaron los requerimientos funcionales a cada uno de los
subsistemas identificados, como se muestra en la Figura 9.
73
10.2.2.2.
subsistemas
Asignacin
de
requerimientos
Ilustracin 12: Asignacin de los requerimientos funcionales a los

susbsistemas.
Como se puede evidenciar en la asignacin, para satisfacer los requerimientos
funcionales en el desarrollo del sistema debe participar ms de un subsistema, lo
que implica una particin y sub-especificacin de estos requerimientos para tener
una referencia ms detallada y as facilitar su diseo e implementacin. La
subespecificacin mencionada se evidencia en la Tabla 7.
10.2.3.
funcionales
Cdigo
Requerimie
nto
Subespecificacin de los requerimientos
Requerimiento
74
Subrequerimiento
R01
El sistema debe permitir al

usuario registrarse, a
travs de un punto de pago
y recaudo, con el fin de
estar habilitado para usar
la billetera.
R02
El sistema debe garantizar

que los usuarios que van a
realizar una transaccin
estn autorizados para
realizarla.
R03

usuario usar el servicio
para transferir dinero a un
establecimiento fsico o
comercio sin necesidad de
estar conectados a una red
WiFi o un plan de datos, el
cual debe ser actualizado
en su cuenta.
75
R1.1 El sistema a travs de un

portal web debe permitir que el PPR
(Punto de Pagos y Recaudos)
ingrese la informacin de registro
del usuario.
R1.2 El sistema debe validar que los
datos ingresados para el registro
sean aceptables, es decir, cumplan
con el formato indicado y no estn
repetidos en la base de datos.
R1.3 El sistema debe activar un
usuario cuando este sea registrado
para utilizar el sistema.
R1.4 El sistema debe enviar un
mensaje al usuario y al PPR,
notificando que el registro ha sido
exitoso o ha sido infructuoso.
R2.1 El sistema antes de cada
transaccin y consulta, debe pedir
al usuario ingresar el PIN de
autenticacin.
R2.2 El sistema debe validar que el
PIN es correcto.
R3.1 El sistema debe permitir al
punto de pago seleccionar del men
la opcin "Recibir Pago".
R3.2 El sistema debe mostrar en
pantalla una opcin para ingresar el
identificador del comprador.
R3.3 El sistema debe validar el
identificador del comprador.
R3.4 Es sistema debe validar el
saldo del comprador.
R3.5 El sistema debe generar un PIN
de aceptacin y debe enviarlo al
comprador.
pantalla una opcin para ingresar el
PIN.
R3.7 El sistema debe validar el PIN.
mensaje de verificacin de compra
y debe desplegarlo en pantalla.
comprador enviar la aceptacin de
compra.
R3.10 El sistema debe de realizar la
transaccin del dinero.
R3.11 El sistema debe actualizar los
saldos.
R3.12 El sistema debe guardar el
historial de transaccin.
R3.13 El sistema debe generar un
nmero de compra nico.

R3.14 El sistema debe enviar
mensaje de confirmacin con el
nmero de compra al punto de pago
y al comprador.
R04

usuario transferir dinero
otra persona natural,
usando como soporte
financiero la operadora
mvil, sin necesidad de
estar conectados a una red
WiFi o un plan de datos.
76

usuario que va a transferir el dinero
seleccionar del men la opcin
"Enviar dinero".
pantalla la opcin para ingresar el
identificador del usuario receptor de
la transaccin.
identificador del receptor.
saldo del emisor.
R4.5 El sistema debe de enviar un
mensaje de confirmacin de la
transaccin al receptor y
desplegarlo en pantalla.
R4.6 El sistema debe de permitir
que el receptor envi la
confirmacin de la transaccin.
R4.7 El sistema debe de realizar la
transaccin del dinero.
saldos.
R09
El sistema de permitir al
usuario consultar la
informacin de sus
movimientos financieros en
el dispositivo mvil.
R15
El sistema debe notificar

por SMS que la transaccin
se realiz con xito.
R16
El sistema debe cancelar la

operacin completa si se
present algn error en la
transaccin.
77
R4.9 El sistema debe guardar

R4.10 El sistema debe generar un
nmero de transaccin nico.
R4.11 El sistema debe enviar
mensaje de confirmacin con el
nmero de la transaccin al emisor
y receptor.
usuario seleccionar del men la
opcin "Consultar Saldo".
R9.2 El sistema debe mostrarle al
usuario su saldo actual en la
billetera (sea el cupo o salo cargado
disponible).
usuario seleccionar del men la
opcin "Ver ltimos movimientos".
R9.4 El sistema debe enviar al
usuario un SMS con la informacin
de las ltimas 5 transacciones
realizadas.
mensaje al emisor de la transaccin
con la siguiente informacin:
- Identificador de la transaccin.
- Identificador del receptor.
- Monto de la transaccin.
mensaje al receptor de la
transaccin con la siguiente
informacin:
- Identificador del emisor.
- Monto de la transaccin.
error de la transaccin y detener el
proceso.
R16.2 El sistema debe cambiar los
valores del emisor y receptor de la
transaccin, de la ORM y los bancos
al estado inicial antes de realizar la
transaccin.
R16.3 El sistema debe cancelar el
proceso completo y registrar el
error.
R17
Si se present un problema
en la m-wallet, el sistema
debe de enviar un mensaje
con el detalle del error por
SMS.
R18
El sistema debe permitir

que el usuario cambie el
PIN de autenticacin.
R19

usuario poder comprar
tiempo al aire desde el
dispositivo mvil
78
R17.1 El sistema debe consultar el

registro de errores y contruir el
mensaje de error.
R17.2 El sistema debe envar un
mensaje al emisor de la transaccin
(si lo conoce) con la siguiente
informacin:
- Identificador del receptor.
- Mensaje de error.
- Saldo o cupo actual.
R17.3 El sistema debe envar un
mensaje al receptor de la
transaccin (si lo conoce) con la
siguiente informacin:
- Identificador del emisor.
- Mensaje de error.
- Saldo o cupo actual.
usuario seleccionar en pantalla la
opcin "Cambia PIN".
R18.2 El sistema debe mostrar una
opcin para que el usuario ingrese
el nuevo PIN.
nuevo PIN y actualizar los datos.
R18.4 El sistema se debe sincronizar
con la ORM para actualizar datos.
usuario seleccionar en la pantalla la
opcin "Comprar tiempo al aire".
R19.2 El sistema debe mostrar una
opcin para que el usuario ingrese
el monto de tiempo al aire que
desea cargar.
usuario disponga del saldo
necesario para la transferencia.
mensaje de confirmacin al usuario.
R19.5 El sistema debe sincronizarse
con la ORM para realizar la
transaccin.
saldos.
R19.7 El sistema debe guardar el
mensaje al usuario notificando si la
compra fue exitosa o infructuosa.
R20
R21

usuario, a travs un punto
de pago y recaudo,
depositar dinero en su
billetera mvil, su saldo
aumentar en su cuenta.

usuario, a travs un punto
de pago y recaudo, retirar
dinero de su billetera
mvil, su saldo se reducir
en su cuenta.
79

ingrese los datos para realizar el
depsito:
- Identificacin de cuenta (nmero
celular)
- Cdula
- Monto del depsito
R20.2 El sistema debe validar que la
identificacin y la cdula
pertenezcan a un usuario vlido y
activo.
R20.3 El sistema debe enviar una
notificacin al usuario con un
nmero de confirmacin que deber
ser ingresado por el PPR.
PPR ingresar el nmero de
confirmacin a travs del portal
web.
nmero de confirmacin.
datos luego de realizada la
transaccin.
R20.7 El sistema debe confirmar al
PPR que el depsito fue realizado
con xito.
usuario que el depsito fue
realizado con xito.
ingrese los datos para realizar el
retiro:
- Identificacin de cuenta (nmero
celular)
- Cdula
- Monto del retiro
R21.2 El sistema debe validar que la
identificacin y la cdula
pertenezcan a un usuario vlido y
activo.
usuario tenga saldo disponible de
acuerdo al indicado para realizar el
retiro.
R21.4 El sistema debe enviar una
notificacin al usuario con un
nmero de confirmacin que deber
ser ingresado por el PPR.

PPR ingresar el nmero de
confirmacin a travs del portal
web.
nmero de confirmacin.
datos luego de realizada la
transaccin.
PPR que el retiro fue realizado con
xito.
usuario que el retiro fue realizado
con xito.
Tabla 7: Subespecificacin de los requerimientos funcionales de la

billetera mvil
10.2.4.
Asignacin
de
subespecificados a subsistemas
requerimientos
Con la particin y sub-especificacin realizada de los requerimientos funcionales,

es posible realizar nuevamente la asignacin de los sub-requerimientos resultantes
a cada uno de los subsistemas, como se muestra en la Tabla 8, con el fin de tener
mayor detalle de cmo sera el funcionamiento del sistema propuesto, lo cual
facilita el modelado de la interaccin del usuario (o los usuarios) con dicho
sistema. Lo anterior se evidencia en los casos de uso que se presentarn en la
siguiente seccin de este documento.
80
81
ORM
SMS
Gatewa
y
SMS
Center
Banco
Base de
datos
Contr
ol
R1.2
R1.3
USSD
Gateway
Contr
ol
Sistema Central
Notificacio
nes
Celular
Contr
ol
Base de
datos
R1.2
R1.2
R1.2
R1.3
R1.3
R1.3
GUI
Contr
ol
R1.1
R0
1
R1.4
R1.4
R1.2
R1.4
R2.1
R1.4
R2.1
R3.1
R3.1
R3.1
R3.2
R3.2
R2.1
R0
2
R2.2
R3.3
R3.4
R3.4
R3.4
R3.4
R3.5
R3.5
R3.7
R0
3
R3.8
R2.2
R3.3
R3.3
R3.4
R3.4
R3.5
R3.5
R3.7
R3.7
R3.8
R3.3
R3.6
R3.7
R3.8
R3.9
R3.14
R3.10
R3.10
R3.10
R3.10
R3.10
R3.11
R3.11
R3.11
R3.11
R3.11
R3.12
R3.12
R3.13
R3.13
R3.14
R3.14
R4.4
R4.4
R4.1
R4.2
R4.2
R4.11
R0
9
R4.4
R4.4
R4.5
R0
4
R3.14
R4.1
R4.3
R4.3
R4.3
R4.4
R4.4
R4.5
R4.7
R4.7
R4.7
R4.7
R4.7
R4.8
R4.8
R4.8
R4.8
R4.8
R4.11
R3.9
R4.9
R4.9
R4.10
R4.10
R4.1
R4.3
R4.5
R4.5
R4.6
R4.6
R4.11
R4.11
R9.1
R9.1
R9.1
R9.1
R9.2
R9.2
R9.2
R9.3
R9.2
R9.3
82
R1
5
R9.4
R9.4
R9.4
R9.4
R15.1
R15.1
R15.1
R15.1
R15.2
R15.2
R15.2
R15.2
R1
6
R1
7
R16.2
R9.4
R16.1
R16.1
R16.2
R16.2
R16.2
R16.2
R16.3
R16.3
R16.3
R17.1
R17.2
R17.2
R17.2
R17.2
R17.3
R17.3
R17.3
R17.3
R17.1
R18.1
R18.1
R18.2
R1
8
R18.3
R18.4
R18.3
R18.4
R19.1
R19.1
R19.1
R19.2
R19.2
R19.2
R19.4
R19.4
R19.4
R19.5
R19.6
R19.6
R19.8
R19.8
R19.8
R20.3
R20.3
R20.3
R2
0
R20.6
R20.6
R20.7
R20.7
R20.7
R20.8
R20.8
R20.8
R21.3
R19.3
R19.4
R19.5
R19.6
R18.3
R18.4
R19.3
R1
9
R18.3
R21.3
R19.6
R19.6
R19.7
R19.7
R20.2
R20.2
R20.5
R20.5
R20.6
R20.6
R20.8
R21.2
R21.2
R21.5
R21.5
R21.6
R21.6
R21.3
R2
1
R21.6
R21.6
R21.7
R21.7
R21.7
R21.8
R21.8
R21.8
Tabla 8: Asignacin de subrequerimientos a los subsistemas.
83
R21.8
84
10.3.
Especificacin Casos de Uso
En esta seccin, se detallan los casos de uso que describen la interaccin entre los
usuarios y el sistema con el fin de cumplir con los requerimientos elicitados. Se
debe tener en cuenta que cada caso de uso no corresponde a un requerimiento
especfico, un caso de uso puede dar cumplimiento a varios requerimientos y
subrequerimientos.
10.3.1.
Registrar un usuario al sistema
CU-1: Registrar un usuario al sistema

Actor: Usuario - ORM - Sistema
Contexto: Un usuario se dispone a registrarse para utilizar el
sistema.
Precondicin:
Usuario
Sistema
1. El usuario se acerca a su ORM e
ingresa los datos de registro en el
portal web
2. Registra los datos del usuario.
3. Si los datos estn correctos, activa
el servicio
4. Le entrega al usuario un PIN de
autenticacin (puede ser el RMSI u
otro)
5. Se sincroniza con la ORM y
actualiza sus datos.
6. Envia un mensaje al usuario
notificando el resultado del registro
Escenarios de excepciones:
E01: Los datos no tienen el formato esperado, se notifica para su correccin
E02: Los datosde registro estn incompletos, el sistema no permite continuar
hasta completarlos, para ello notifica la incosistencia, espera el reproceso.
85
E03: Se presenta un error en la sincronizacin entre la ORM y el Sistema, este

queda suspendido hasta que se reanude la sincronizacin, despus de 10
segundos se detiene el proceso, se notifica el error.
Tabla 9: CU-1 Registrar un usuario en el sistema.
10.3.2.
Autenticar usuario
CU-2: Autenticar usuario

Actor: Usuario - Sistema
Contexto: Un usuario debe autenticarse para utilizar el sistema.
Precondicin: El usuario est habilitado (registrado) para usar el
sistema
Usuario
Sistema
1. Ingresa PIN antes de hacer la
peticin.
2. Valida el PIN.
3. Si el PIN es vlido, da acceso al
usuario a la funcionalidad requerida.
Escenarios de excepciones:
E01: El PIN de autenticacin es invlido, si es el primer o segundo intento, se
vuelve a pedir el PIN.
E02: La cuenta se bloquea temporalmente despus de tres intentos fllidos
en la autenticacin mediante el PIN.
E03: Se presenta un fallo en la conexin entre el sistema y los usuarios. El
sistema se pausa y espera mximo 10 segundos a que se reestablezca la
conexin, de lo contrario da como terminado el proceso, se registra el error y
se notifica a los usuarios.
Tabla 10: CU-2 Autenticar usuario
10.3.3.
Transferir dinero a comercio
CU-3: Transferir dinero a comercio
86
Actores principales : Comercio - Sistema

Actores Secundarios: Persona natural - ORM
Contexto: Un usuario como persona natural transfiere dinero a un
usuario como comercio
Precondicin: Usuarios registrados
Receptor Comercio
Sistema
1. Selecciona del men la opcin
"Recibir pago"
2. Se autentica (CU-02)
3. Ingresa al sistema los datos de
la compra:
*Nmero celular
*Nombre
*Valor de la compra
*Producto
4. Valida si el emisor tiene saldo.
5. El sistema enva al emisor un PIN de
aceptacin (el cul se elimina a los 10
segundos de ser entregado).
6. Ingresa el PIN de aceptacin
7. Valida PIN de aceptacin
8. Enva mensaje de confirmacin exitosa
del PIN
9. Enva
compra
la
aceptacin
de
la
10. Sincronizar con ORM
11. Solicita aprobacin de la ORM para
autorizar la transaccin.
12. Actualiza saldos y movimientos
13. Guarda historial de la transaccin
14. Genera un nmero de compra nico
E01: Los datos ingresados en 3 estn incompletos. Se muestra un mensaje de

error y se le pide al receptor de nuevo los datos.
E02: Los datos ingresados en 3 son inconsistentes. Se muestra un mensaje de
87
E03: El emisor no tiene fondos suficientes. Se notifica la excepcin y se da por

terminada la transaccin.
E04: El PIN de aceptacin es invlido. Si es el primer intento, se vuelve a pedir.
De lo contrario, se da por terminado el proceso, se registra el error y se notifica
a los usuarios.
E05: Problema de conexin entre la ORM y el sistema. Se congela el proceso y
se espera hasta 10 segundos a que se restaure la conexin, de lo contrario el
proceso se da por terminado, se restauran los valores iniciales, se registra el
error y se notifica a los usuarios.
conexin, de lo contrario da como terminado el proceso, se registra el error y se
notifica a los usuarios.
E07: Se presenta un error en la actualizacin de la transaccin (11-12), se
pausa el proceso durante 10 segundos, se reprocesa la actualizacin, si nos e
soluciona, el proceso se da por terminado y se notifica a los usuarios.
Tabla 11: CU-3 Transferir dinero a comercio
10.3.4.
Transferir dinero a persona natural
CU-4: Transferir dinero a persona natural

Actor: Emisor - Receptor - Sistema
Contexto: Un usuario como persona natural transfiere dinero a otro
usuario como persona natural
Emisor Persona
Receptor
Sistema
Natural
Persona Natural
1.
Selecciona
del
men
la
opcin
"Enviar dinero"
2. Se autentica (CU02)
3. Ingresa al sistema
el identificador del
receptor
4. Valida el identificador del
receptor
5. Valida si el emisor tiene saldo.
88
6. Enva mensaje de confirmacin

de la transaccin al receptor.
7. Enva la
confirmacin de la
transaccin
8. Sincronizar con ORM
9. Solicita aprobacin de la ORM
para autorizar la transaccin.
10.
Actualiza
saldos
y
movimientos
11. Guarda historial de la
transaccin
12. Genera un nmero de compra
nico
E01: Los datos ingresados en 3 estn incompletos. Se muestra un mensaje de
E02: Los datos ingresados en 3 son inconsistentes. Se muestra un mensaje de
E03: El emisor no tiene fondos suficientes. Se notifica la excepcin y se da por
terminada la transaccin.
E04: El identificador del receptor es invlido. Se vuelve a pedir el identificador.
Si es el tercer intento se da por terminado el proceso, se registra el error y se
E05: Problema de conexin entre la ORM y el sistema. Se congela el proceso y
se espera hasta 10 segundos a que se restaure la conexin, de lo contrario el
proceso se da por terminado, se restauran los valores iniciales, se registra el
conexin, de lo contrario da como terminado el proceso, se registra el error y se
E07: Se presenta un error en la actualizacin de la transaccin (9-10), se
pausa el proceso durante 10 segundos, se reprocesa la actualizacin, si no se
soluciona, el proceso se da por terminado y se notifica a los usuarios.
Tabla 12: CU-4 Transferir dinero a persona natural
10.3.5.
Notificar resultado de transaccin.
CU-5: Notificar resultado de transaccin.

Actor: Usuario (Emisor y Receptor) - Sistema
89
Contexto: El usuario desea que el sistema le

notifique los resultados de una transaccin.
Precondicin: Se ejecut algn proceso de
transaccin
Usuario
Sistema
1. Valida estado de la
transaccin.
2. Construye el mensaje de la
transaccin.
3. Enva mensaje de
resultado de la transaccin al
emisor
4. Enva mensaje de
resultado de la transaccin al
receptor
5. Enva mensaje de
confirmacin de la
transaccin al emisor.
6. Recibe el mensaje
E01: Se presenta un fallo en la conexin entre el
sistema y los usuarios. El sistema se pausa y espera
mximo 10 segundos a que se reestablezca la
conexin, de lo contrario da como terminado el
proceso, se registra el error y se notifica a los
usuarios.
Tabla 13: CU-5 Notificar resultado de transaccin.
10.3.6.
Consultar Saldo
CU-6: Consultar Saldo

Contexto: El usuario desea consultar el saldo actual
de su billetera
Usuario
Sistema
1. Selecciona del men la
opcin "Consultar dinero"
3. Procesa la solicitud y
despliega en pantalla el saldo
90
del usuario
E01: Se presenta un fallo en la conexin entre el sistema y
los usuarios. El sistema se pausa y espera mximo 10
segundos a que se reestablezca la conexin, de lo contrario
da como terminado el proceso, se registra el error y se
notifica al usuario.
Tabla 14: CU-6 Consultar Saldo
10.3.7.
Consultar historial de transacciones
CU-7: Consultar historial de transacciones

Contexto: El usuario desea consultar su historial de
transacciones
Usuario
Sistema
opcin
"Ver
ltimos
movimientos"
3. El sistema consulta los
ltimos 5 movimientos
realizados por el usuario.
4. El sistema construye el
mensaje con la siguiente
informacin:
*Fecha de movimiento
*Nombre emisor
*Nombre receptor
*Tipo transferencia
*Monto de transaccin
E01: Se presenta un fallo en la conexin entre el sistema y los
usuarios. El sistema se pausa y espera mximo 10 segundos a
que se reestablezca la conexin, de lo contrario da como
terminado el proceso, se registra el error y se notifica al
usuario.
Tabla 15: CU-7 Consultar historial de transacciones
10.3.8.
Comprar tiempo al aire
91
CU-8: Comprar tiempo al aire

Contexto: El usuario desea consultar su historial de
transacciones
Precondicin: Usuarios autenticados
Usuario
Sistema
1. Selecciona del men
la
opcin
"Comprar
tiempo al aire".
3. Ingresa el monto de
tiempo al aire que desea
cargar.
4. Valida que el usuario disponga de
saldo necesario para la transferencia.
5. Enva mensaje de confirmacin al
usuario.
6. Se sincroniza con la ORM para
realizar la transaccin.
7. Actualiza saldos.
8. Guarda historial de la transaccin.
9. Enva un mensaje al usuario
notificando resultado de la compra.
terminado el proceso, se registra el error y se notifica al usuario.
E02: El usuario no tiene saldo para realizar la compra. Se notifica
el error y se da por terminado el proceso.
E03: Problema de conexin entre la ORM y el sistema. Se
congela el proceso y se espera hasta 10 segundos a que se
restaure la conexin, de lo contrario el proceso se da por
terminado, se restauran los valores iniciales, se registra el error y
se notifica a los usuarios.
10.3.9.
Cambiar PIN
CU-09: Cambiar PIN
92

Contexto: El usuario desea cambiar el PIN de
autenticacin de su cuenta
Usuario
Sistema
opcin "Cambiar PIN"
3. Valida el formato del nuevo PIN.
4. Actualiza el PIN
5. Se sincroniza con la ORM para
actualizar datos
terminado el proceso, se registra el error y se notifica al usuario.
E02: Problema de conexin entre la ORM y el sistema. Se congela
el proceso y se espera hasta 10 segundos a que se restaure la
conexin, de lo contrario el proceso se da por terminado, se
restauran los valores inciales, se registra el error y se notifica a
los usuarios.
E03: El formato del PIN no corresponde al establecido por las
polticas de la billetera. El sistema vuelve a pedir el nuevo PIN. Si
es el tercer intento se da por terminado el proceso, se registra el
10.3.10.
Depositar dinero
CU-10: Depositar dinero

Actor: PPR - Sistema
Contexto: El usuario desea a depositar dinero a travs
del Punto de Pagos y Recaudos (PPR)
Precondicin: El PPR tiene activado el portal web
PPR
Sistema
1. Ingresa al sistema los datos
para realizar el depsito:
- Identificador de cuenta
(nmero celular).
- Cdula.
- Monto del depsito
93
2. Valida que el identificador y

la cdula pertenezcan a un
usuario vlido y activo
3. Enva mensaje de
confirmacin al usuario
4. Ingresa al sistema el
nmero de confirmacin que
fue enviado al usuario
5. Valida que el nmero de
confirmacin sea correcto.
6. Actualiza los datos luego de
realizada la transaccin.
7. Enva un mensaje notificando
el resultado del depsito al
usuario y al PPR.
terminado el proceso, se registra el error y se notifica al
usuario.
E02: Los datos ingresados en 1 son inconsistentes. Se muestra
un mensaje de error y se le pide al receptor de nuevo los datos.
E03: Los datos ingresados en 1 estn incompletos. Se muestra
un mensaje de error y se le pide al receptor de nuevo los datos.
E04: El nmero de confirmacin es invlido. Si es el primer
intento, se vuelve a pedir. De lo contrario, se da por terminado
el proceso, se registra el error y se notifica a los usuarios.
E05: Se presenta un error en 7 y la transaccin no se realiza
con xito. El sistema da por terminado el proceso, registra el
error y notifica al usuario y al PPR.
Tabla 18: CU-10 Depositar dinero
10.3.11.
Retirar dinero
CU-11: Retirar dinero

Actor: PPR - Sistema
Contexto: El usuario desea a retirar dinero a travs del Punto de
Pagos y Recaudos (PPR)
94
Precondicin: El PPR tiene activado el portal web

PPR
1. Ingresa al sistema los datos para
realizar el retiro:
- Identificador de cuenta (nmero
celular).
- Cdula.
- Monto del retiro
Sistema
2. Valida que el identificador y la

cdula pertenezcan a un usuario
vlido y activo
3. Enva mensaje de confirmacin al
usuario
4. Valida que el usuario tiene saldo
disponibles de acuerdo al indicado
para realizar el retiro
5. Ingresa al sistema el nmero de
confirmacin que fue enviado al
usuario
6. Valida que el nmero de
confirmacin sea correcto.
7. Actualiza los datos luego de
realizada la transaccin.
8. Enva un mensaje notificando el
resultado del retiro al usuario y al
PPR.
conexin, de lo contrario da como terminado el proceso, se registra el
error y se notifica al usuario.
E02: Los datos ingresados en 1 son inconsistentes. Se muestra un
mensaje de error y se le pide al receptor de nuevo los datos.
E03: Los datos ingresados en 1 estn incompletos. Se muestra un
mensaje de error y se le pide al receptor de nuevo los datos.
E04: El nmero de confirmacin es invlido. Si es el primer intento, se
vuelve a pedir. De lo contrario, se da por terminado el proceso, se registra
el error y se notifica a los usuarios.
E05: Se presenta un error en 7 y la transaccin no se realiza con xito. El
sistema da por terminado el proceso, registra el error y notifica al usuario
y al PPR.
Tabla 19: CU-11 Retirar dinero
95
10.4.
Diagrama de Casos de Uso
El siguiente diagrama se realiza con la finalidad de tener una vista ms general, en

la cual se evidencie la interaccin de cada uno de los roles de los usuarios con el
sistema. Adems, complementa la informacin que provee la especificacin de los
casos de uso, que brinda de manera precisa y detallada la descripcin de esa
interaccin.
Ilustracin 13: Diagrama de casos de uso contextual

Fuente: Autor
El anterior diagrama a pesar de evidenciar de manera ms general y funcional las
necesidades del sistema de micro pagos propuesta, que deberan ser abordadas en
realizacin de un prototipo, no refleja las preocupaciones de los principales
Stakeholders (interesados del sistema) relacionadas con la disponibilidad del
96
sistema, la seguridad, la adaptabilidad y continuidad del mismo a travs del

tiempo. Debido a esto, en la siguiente seccin se especificarn los escenarios QAW
(Quality Attribute Workshop) ms importantes y priorizados, con el fin de
especificar y mostrar los atributos de calidad que evidencian las preocupaciones
en el diseo del sistema.
10.5.
Escenarios de QAW
As como el tratamiento y especificacin adecuada de los requerimientos

funcionales son indispensables para cumplir con los objetivos del sistema, los
requerimientos relacionados con los atributos de calidad (no funcionales) son de
vital importancia para alcanzar el propsito del sistema y por ende se deben tener
en cuenta en el diseo del mismo, como lo dice Barbacci, M., Ellison, R., Lattanze,
A., Stafford, J., Weinstock, C., & Wood, W (2003) El cumplimiento de los atributos
de calidad es un factor crtico para el xito del sistema... Igualmente mencionan
que Los atributos de calidad por s mismos, definitivamente no son suficientes
para el diseo o la evaluacin, deben ser ms concretos (Barbacci, y otros, 2003).
Por tal motivo, a continuacin, se realiza el anlisis de estos atributos de calidad
que reflejan las preocupaciones de los interesados, mediante la especificacin de
los escenarios de QAW.
La estructura de los escenarios desarrollados es la siguiente:
Escenario y contexto: Son las condiciones que influyen en el
desarrollo del escenario.
Objetivo del negocio: Son los propsitos del negocio que se ven
impactados.
QAS Relevantes: Son los atributos de calidad que se desarrollan en
el escenario.
Estmulo: Condiciones o razones por las cules por las cules se ve
afectado el sistema.
Fuente de Estmulo: Entidad interna o externa del sistema que
genera el estmulo.
Artefacto(s): Componente del sistema que recibe el estmulo.
Respuesta: Actividad resultante de la generacin del estmulo.
97
Medida de Respuesta: Medida que se utilizar para evaluar el

impacto del estmulo.
Preguntas Relevantes: Interrogantes que se deben responder para
poder tratar el escenario.
Otros Aspectos: Aspectos que se deben tener en cuenta para
analizar el escenario.
A continuacin, se especifican los escenarios de QAW que reflejan las
preocupaciones de los principales Stakeholders del sistema con respecto a los
objetivos del negocio. A partir de estos, se identificaran atributos de calidad
relevantes para el sistema que se debern considerar en el diseo del mismo:
10.5.1.
Proyecto
Escenario y
contexto
Objetivo del
negocio
QAS Relevantes
Estimulo
Fuente de
Estimulo
Sistema de pagos mviles (m-wallet)

Nueve de cada diez personas (9/10) que cambien de dispositivo
mvil sin importar la gama pueden utilizar nuevamente el sistema.
Aumentar la cuota de mercado y los beneficios de los usuarios.
Compatibilidad
El usuario cambia de terminal mvil. El terminal mvil actualiza su
software. Entran nuevos modelos de celulares al mercado.
Telfono mvil
Componente de control del celular, componente control del
sistema.
El usuario puede activar sus sesin en el terminal
Artefacto(s)
Respuesta
Medida de
Respuesta
Preguntas
Relevantes
Otros Aspectos
Inmediata
Qu dificultades presentara el sistema para no ser compatible
con un modelo?
Qu caractersticas tienen los modelos no compatibles con el
sistema?
Cules son los modelos no compatibles?
Tipo de Software y hardware del nuevo dispositivo mvil.
10.5.2.
Proyecto
Escenario #1
Escenario #2
98
Escenario y
contexto
Cuando se use el sistema para realizar un pago esta debe

realizar la comunicacin mediante mensajes USSD.
Objetivo del
negocio
QAS
Relevantes
Disminuir costos y aumentar cuota de mercado

Portabilidad, Compatibilidad
Estimulo
Cantidad considerable de terminales que no son

inteligentes.
Fuente de
Estimulo
Telfono mvil
Artefacto(s)
Respuesta
Componente de comunicacin de la mquina,

Administrador remoto
El cdigo USSD se ejecuta correctamente
Medida de
Respuesta
1 - 5 segundos
Preguntas
Relevantes
La tecnologa USSD debe estar habilitada para todos los

terminales?
En caso de que el terminal sea smartphone, se puede usar
otra tecnologa?
Cules son las principales dificultades de usar USSD?
Otros
Aspectos
10.5.3.
Escenario #3
Proyecto
Escenario y
contexto

Cuando se envi una notificacin al usuario, debe ser
enviada mediante SMS.
Objetivo del
negocio
Fidelizar y mejorar la relacin con el usuario/cliente

Mejorar la satisfaccin del cliente.
Ahorrar en costos y tiempo de respuesta.
QAS
Relevantes
Rendimiento y Disponibilidad
Estimulo
Mensaje eficiente y disponible para el usuario en

cualquier momento
Fuente de
Estimulo
Sistema, Telfono Mvil
Artefacto(s)
Respuesta
Componente SMSC, componente Gateway SMS,

componente de control del Celular, componente de
notificaciones del Sistema.
El cdigo USSD se ejecuta correctamente
99
Medida de
Respuesta
5 - 15 segundos
Preguntas
Relevantes
Cmo se puede garantizar la integridad y

confidencialidad de la informacin enviada en el
mensaje?
Otros
Aspectos
10.5.4.
Proyecto
Escenario y
contexto
Objetivo del
negocio
QAS
Relevantes
Escenario #4

Cuando un usuario enve una solicitud (realice un pago o
cobro) a un usuario de otra operadora mvil distinta a la
suya, esta debe poder realizarse el 99% de los casos.
Mejorar la satisfaccin del cliente.
Aumentar el campo e accin.
Interoperabilidad
Estimulo
El usuario desea realizar un pago o cobro a un usuario de

otra ORM
Fuente de
Estimulo
Telfono mvil
Artefacto(s)
Respuesta
Medida de
Respuesta
Componente USSD Gateway, componente de control del

Banco componente de control del Sistema, componente
de Control de la ORM
La transaccin se realiza exitosamente
1 - 7 segundos
Preguntas
Relevantes
Cules son las operadoras mviles soportadas por el

sistema?
Qu implicaciones tcnicas tiene agregar otra operadora
mvil?
Todas las ORM del mercado soportan la tecnologa?
Otros
Aspectos
En la primera fase, la tecnologa base es USSD.

10.5.5.
Proyecto
Escenario #5
100
Escenario y
contexto
El sistema deber contar con los mecanismos de

seguridad que garanticen la confidencialidad,
integridad y autenticidad de la informacin, en
el acceso del servicio.
Objetivo del
negocio
Mantener la credibilidad por parte del cliente.

Respaldar los intereses del usuario.
Mantener la confidencialidad de la informacin
de los clientes y los usuarios.
QAS
Relevantes
Seguridad
Estimulo
El acceso a cualquiera de los servicios a travs

de cualquiera de los dispositivos soportados por
el sistema
Fuente de
Estimulo
Cualquier persona o mquina que intente

acceder a los servicios del sistema
Artefacto(s)
Componente USSD Gateway, componente de

control del Banco componente de control del
Sistema, componente de Control de la ORM.
Respuesta
La informacin es denegada para personas no

autorizadas.
Medida de
Respuesta
Preguntas
Relevantes
Otros
Aspectos
Ms del 99% de la informacin es confiable,

integra y confidencial.
Cul es el costo que implica mantener la
seguridad con respecto al aumento de usuarios
y transacciones?
Cmo se garantiza que la informacin no se
pierda si ocurre una falla en el sistema?
Se debe tener en cuenta la seguridad no solo a
nivel de software, sino tambin de hardware
10.5.6.
Proyecto
Escenario y
contexto
Objetivo del
negocio
QAS
Relevantes
Estimulo
Escenario #6
Cuando una transaccin falle, el 99% de
los reportes del fallo deben ser enviados a
los usuarios.
Mantener informado al usuario del estado
de su transaccin.
Confiabilidad
Error en alguna de las transacciones del
101
sistema
Fuente de
Estimulo
Artefacto(s)
Respuesta
Medida de
Respuesta
Preguntas
Relevantes
Sistema Central
Componente USSD Gateway, componente
de control del Banco, componente de
control del Sistema, componente de
Control de la ORM, componente de
notificaciones del Sistema, SMSC.
El mensaje de error ha llegado a los
usuarios
Mnimo el 98% de los reportes de error han
sido notificados
Cul es la media diaria, semanal y
mensual de fallos en el sistema?
Cunto es el tiempo que demora el
sistema en identificar y procesar las fallas?
Otros
Aspectos
10.5.7.
Escenario #7
Proyecto
Escenario y
contexto

Cuando el sistema falle, restablecer la
informacin en el menor tiempo posible.
Objetivo del
negocio
QAS
Relevantes
Mantener la informacin del usuario

integra y disponible.
Disponibilidad, seguridad.
Estimulo
Error en alguna de las transacciones del

sistema
Fuente de
Estimulo
Sistema Central
Artefacto(s)
Respuesta
Medida de
Respuesta
Componente USSD Gateway,

componente de control del Banco,
componente de control del Sistema,
componente de Control de la ORM.
La informacin ha sido restaurada o
recuperada.
tiempo de respuesta >= 10 s
102
Preguntas
Relevantes
Cul es la estrategia para salvar o

recuperar informacin que se pueda
perder o alterar?
Cules son las implicaciones tcnicas si
es necesario un reproceso?
Otros
Aspectos
10.5.8.
Proyecto
Escenario y
contexto
Objetivo del
negocio
Escenario #8
Sistema de pagos mviles (mwallet)
Se genera trfico en la red por la
cantidad elevada de transacciones y
el sistema falla
Garantizar la mxima disponibilidad
de transacciones (maximizacin de
beneficios)
QAS
Relevantes
Disponibilidad, Escalabilidad
Estimulo
Las transacciones se demoran en

completar o no se completan con
xito
Fuente de
Estimulo
Telfono mvil y sistema central
Artefacto(s)

componente de control del Banco,
Respuesta
Medida de
Respuesta
Se deben establecer canales y

mtodos que garanticen el soporte a
la cantidad de solicitudes
*Tiempo disponible/tiempo total
98%
*Cantidad de transacciones por
segundo <= limite esperado de
transacciones que el servidor puede
soportar.
103
Cul es el costo de implementar

mecanismos de comunicacin
paralelos?
Qu tan frecuentemente se
congestiona la red?
Cuntas peticiones
simultneamente soportan los
Preguntas
servidores?
Relevantes
Cul es el promedio de peticiones
diarias?
Cul es el horario en que los
procesos presentan los picos ms
elevados de actividad?
Los picos de peticiones son
predecibles?
Otros
Se debe tener en cuenta CPU, SO y
Aspectos
Ancho de banda
10.5.9.
Escenario #9
Proyecto
Sistema de pagos mviles (mwallet)
Escenario
y
contexto
Un usuario pierde su celular y una

persona no autorizada accede a el para
realizar una transaccin
Objetivo
del
negocio

Mantener la confidencialidad de la
informacin de los clientes y los
usuarios.
QAS
Relevant
es
Seguridad
El acceso a cualquiera de los servicios a

travs de cualquiera de los dispositivos
soportados por el sistema
Cualquier persona o mquina que
Fuente de
intente acceder a los servicios del
Estimulo
sistema
Estimulo
Artefacto
(s)

104
Respuest
a
La informacin es denegada para

personas no autorizadas.
Medida
de
Respuest
a
Ms del 99% de la informacin es

confiable, integra y confidencial.
Pregunta
s
Relevant
es
Otros
Aspectos
Cul es el costo que implica mantener

la seguridad con respecto al aumento de
usuarios y transacciones?
Cmo se garantiza que la informacin
no se pierda si ocurre una falla en el
sistema?
Se debe tener en cuenta la seguridad
tambin depende del cuidado del usuario
105
11. Propuesta de modelo del sistema de pagos mviles

(Billetera mvil / m-Wallet)
Luego de haber mencionado los diferentes tipos de sistemas de pagos mviles que
hay en el mundo, los Stakeholders del sistema propuesto, los modelos de negocio
que existen y el que se espera adoptar por esta propuesta, adems de la
especificacin y anlisis de los requerimientos del sistema, tanto funcionales como
no funcionales; a continuacin, se explicar desde un punto de vista tcnico el
sistema de pagos mviles que se propone en este proyecto de grado, mediante un
anlisis de las tecnologas que usan las soluciones que actualmente estn en el
mercado, los servicios que se esperan ofrecer y los supuestos que se declaran con
respecto a los roles y acciones que deben considerar los Stakeholders.
11.1.
Definiciones generales
11.1.1.
(m-Wallet)
Objetivos del sistema de pagos mviles
El objetivo general de un sistema de pagos mviles es crear un servicio estndar,

desde el punto de vista tecnolgico, capaz de integrar a los diferentes actores del
proceso de pago mediante una plataforma que permita al usuario pagar de manera
electrnica independientemente del soporte tcnico que utilice, ya sea desde el
mvil o travs del tradicional terminal POS.
En el caso de la plataforma de pagos mviles propuesta los objetivos que esperan
alcanzar con su implementacin y despliegue a futuro estn alineados con el
anterior objetivo, junto con el propsito de llegar a dar otra serie de beneficios
sociales y comerciales. Estos objetivos son:
106
Generar inclusin financiera a las personas no bancarizadas en el

territorio Colombiano.
Brindar un medio que permita el flujo eficaz y seguro del dinero.
Reducir los costos de las transferencias para que ms personas de
estratos bajos pueden beneficiarse de los servicios financieros y las
operadoras de red mvil mejoren en la calidad de servicio y generen
ingresos adicionales.
11.1.2.
Definicin del producto
El sistema de pagos mviles de bajo costo que se propone en este proyecto de

grado se puede definir como: una solucin de modelo de plataforma como servicio
(PaaS, en sus siglas en ingls) que provee un sistema integrador que permite
generar transacciones monetarias de persona a persona, y de personas a
comercios de forma segura, econmica y regulada, a travs de la red de telefona
celular, unificando de esta manera instrumentos fsicos de cobros y pagos en un
dispositivo mvil sin necesidad de disponer de una red WiFi o un plan de datos.
11.1.3.
Supuestos
Para la realizacin del diseo y la especificacin del sistema de micro pagos

mviles propuesto, se definieron los siguientes supuestos con relacin a la posicin
y las acciones que debe adoptar el ORM, uno de los Stakeholders principales, que
desde un punto de vista comercial tiene el rol de cliente. Adems se deben tener
en cuenta ciertos aspectos relacionados con el contexto cultural y social que
envuelve el ecosistema de accin de la propuesta.
El operador de red mvil tiene un sistema de distribucin
constituido de puntos de pago y recaudo que le brinde al usuario la
alternativa de realizar el depsito y retiro del dinero fsico que fluye a
travs del sistema de micro pagos.
El ORM est en la disposicin de brindar servicios de prepago
para los usuarios que no tengan un plan dentro de la empresa, con el fin
de poder prestar el servicio que brinda el sistema.
El ORM est en la disposicin de desarrollar un servicio de
consignacin a las cuentas bancarias de las personas que prefieran
utilizarla para recibir el dinero que les envan a travs del sistema. En
caso contrario, el sistema podr proveer dicho servicio, si as el ORM lo
107
desea, por este motivo el Banco se incluye no solo como Stakeholder, sino
tambin como parte de un sistema en el diseo arquitectnico, sin
embargo este servicio no hace parte del alcance del proyecto.
Un usuario podra tener una cuenta de tipo postpago en el
sistema, que estara directamente relacionada con la cuenta postpago
que tiene en el ORM. Los gastos en los que incurra utilizando el sistema
estarn incluidos en la factura mensual que el ORM le enva al usuario por
los otros servicios consumidos.
11.2.
Planteamiento de la propuesta
11.2.1.
Plataforma tecnolgica
Para la eleccin de la tecnologa que se utilizar en este sistema de micropagos, se

tuvo en cuenta las diferentes soluciones tecnolgicas que actualmente existen, y
se realiz un anlisis comparativo basado en el estudio realizado por Cuji Dutan, D.
A., & Guerrero Vasquz (2014) en su tesis Anlisis de la factibilidad para la
implementacin de la billetera mvil en la ciudad de Cuenca:
Tecnologa
SMS (Short
Message
Service)
USSD
(Unstructured
Supplementary
Service Data
WAP (Wireless
Application
Protocol)
STK (SIM
Application
ToolKit)
NFC (Near Field
Communication
)
Facilidad
de Uso
Segurid
ad
Costo
por
transacci
n
Alta
Alta
Medio
Medio / Alto
Media /
Alta
Media /
Alta
Gratuito /
Bajo
Alto
Alta
Alta
Gratuito /
Bajo
Medio
Alta
Media
Medio /
Alto
Medio / Bajo
Alta
Media
Gratuito /
Bajo
Medio / Bajo
Acceso segn el
estrato socioeconmico
Tabla 29: Comparativo de las tecnologas mviles aplicables al sistema

Fuente: Basado en: Figura 3.6: Comparacin entre tecnologas. Anlisis de
la factibilidad para la implementacin de la billetera mvil en la ciudad de
Cuenca. Pag 74. Cuenca, Ecuador, 2014.
108
Como se observa en la Tabla 29, los cinco tipos de tecnologas no difieren mucho
en sus caractersticas, sin embargo se debe tener en cuenta los objetivos del
sistema de micropagos y su finalidad, para as poder seleccionar los aspectos ms
relevantes de las tecnologas y escoger aquella que sea determinante para
alcanzar dichos objetivos. En este caso, los dos aspectos ms relevantes son: el
costo por transaccin y el acceso segn el estrato socio-econmico. Teniendo en
cuenta esto, la tecnologa en la que se basa la propuesta del sistema es USSD para
realizar las transacciones de dinero, y SMS para el envo de notificaciones.
En la siguiente seccin se especificar con mayor detalle las razones por las cuales
se escoge esta tecnologa, los beneficios y ventajas y su funcionamiento.
11.2.1.1.
Por qu USSD es ideal para la
implementacin de este sistema?
Como ya se ha mencionado en secciones anteriores, USSD al igual que SMS son
medios para transmitir informacin o instrucciones a travs de una red de telefona
GSM. Siendo SMS el servicio de mensajera celular ms utilizado y ms popular
entre los usuarios, Por qu no elegirlo para la implementacin de la plataforma
propuesta? Para dar respuesta a este interrogante se realiza una comparacin de
estos dos servicios de la red GSM para as evidenciar que a pesar de su similitud
son servicios diferentes y sus caractersticas propician roles diferentes en el
sistema de micropagos propuesto.
USSD vs SMS
USSD no genera cargos de roaming. Roaming significa que
el telfono est usando una red celular que no pertenece a tu operador
celular para enviar y recibir datos (Microsoft).
USSD, a diferencia de SMS, permite a las empresas que lo
implementen un dialogo directo con sus clientes.
Los tiempos de respuesta de USSD son muchos ms cortos
que los de SMS, debido a que es un servicio basado en sesiones y no
basado en almacenamiento y envo. Segn Nokia, USSD puede ser
hasta siete veces ms rpido para realizar las transacciones en ambos
sentidos que SMS (Nacimba Chanataxi , pg. 98).
La usabilidad de un servicio utilizando USSD es muy buena,
un poco mejor que la de SMS, ya que los usuarios no deben de ir a
ninguna aplicacin o men particular del telfono, para acceder a este
lo pueden hacer a travs de la pantalla inicial del mvil.
Los mensajes USSD pueden superar los 182 caracteres de
longitud.
109
USSD no necesita un equipo SMSC (Short Message Service

Center) como en el caso de SMS. Lo cual hace que la comunicacin
sea mucho ms fluida y rpida. Esto se debe a que el servidor (o
Gateway) USSD abre una sesin por un canal de comunicacin entre
las partes y no necesita guardar los mensajes antes de enviarlos al
destinatario, la comunicacin es directa (Guerrero Vsquez & Cuji
Dutn, pg. 43).
11.2.1.2.
SerCaracterizacin USSD
Como se mencion en el Marco Terico del proyecto de grado, USSD es un

protocolo de envo de mensajes cortos que funciona sobre redes GSM.
Probablemente a las usuarios de esta telefona no les suene conocida esta
tecnologa, al menos no como el SMS, o mucho menos la hayan utilizado, sin
embargo, seguramente si han pedido el saldo disponible en la cuenta prepaga o la
cantidad de tiempo al aire que les queda escribiendo un cdigo del tipo *
<<cadena de caracteres alfanumricos>> # en el marcador del celular, sin
darse cuenta han usado USSD.
Una de las caractersticas ms representativas de USSD es que es empleado por
las operadoras mviles para ofrecer servicios especficos de GSM, debido a que es
un medio ideal para ofrecer servicios que requieren dialogo. Adems de esto, USSD
presenta un conjunto de caractersticas especficas, que lo hace muy llamativo
para ofrecer servicios a travs de redes mviles, en este caso servicios de pago y
cobro (Nacimba Chanataxi , pg. 93):
No se requiere almacenamiento de mensajes en el telfono mvil, esto
lo hace ms seguro.
El tiempo de respuesta es menor ya que no es un servicio de
almacenamiento y envo.
Los mensajes en USSD alcanzan hasta los 182 caracteres de longitud.
USSD es un complemento para SMS no un elemento sustituto.
Los requerimientos de ancho de banda son mucho ms bajos que los
de WAP (Wireless Application Protocol).
USSD presenta costos ms bajos. La red que se visita no presenta
ningn cargo econmico a la red.
Ha sido extensamente especificado en el estndar UMTS y muchos
conceptos y procesos de aplicacin en redes GSM son fcilmente extensibles
a este estndar (Evolucin de GSM).
La mayora de los terminales mviles soportan la red GSM.
No requiere mens especficos, como se mencionaba anteriormente. El
usuario puede invocar comandos USSD desde la pantalla inicial del celular.
Las cadenas USSD a pesar de su complejidad y que pueden ser
110
difcilmente recordadas por los usuarios, pueden ser almacenadas en la

agenda del telfono para ser usados cuando se requiere.
11.2.1.3.
Estructura de las cadenas USSD
Las cadenas USSD tienen la siguiente estructura (Nacimba Chanataxi , pg. 92):
Ilustracin 14: Estructura cadena USSD

Fuente: Basado en: Estudio del protocolo USSD como
plataforma para birndar servicios de comercio
transacciones financieras. Pag 92. Ecuador. 2008.
mvil
otras
a. Indicador de inicio: Compuesto por dos o tres

caracteres luego del asterisco (*).
b. Cdigo de servicio: Compuesto por dos o tres cifras,
es asignado por el Operador y sirve para identificar el tipo de
servicio desarrollado. Cuando este cdigo est entre 100 y 149 se
procesa por la red del usuario, mientras que entre 150 y 999
utilizara la red visitada.
c. Informacin suplementaria: Est compuesto de la
informacin que se desea enviar, donde est implcito el protocolo,
un conjunto de parmetros del servicio, se enva tambin en este
tramo de informacin el MSISDN del abonado, pudindose utilizar
como parmetro adicional, o para comprobar si ese usuario est
autorizado o tiene habilitado el uso de determinado servicio.
d. Asterisco (*): Usado como separador de los trminos
E. Indicador de fin: Compuesto por un numeral (#) para
indicar la finalizacin del mensaje.
11.2.2.
Servicios
111
El sistema de micropagos mviles propuesto ofrece los siguientes servicios:
11.2.2.1.
Compra de tiempo al aire
Cada usuario del sistema puede comprar tiempo al aire (minutos) a su ORM
con fondos de sus billetera utilizando el mvil, y este ser transmitido a su
nmero celular.
11.2.2.2.
Transferencias
(Consumidor a Consumidor)
de
persona
persona
El usuario puede utilizar el sistema para enviar dinero a otra persona que
tenga activado el servicio, siempre y cuando su operadora mvil tenga
implementado el sistema.
11.2.2.3.
Transferencias de persona a comercio
Un comercio que sea usuario del sistema puede a travs de un dispositivo

celular recibir pagos de consumidores que tengan activado el sistema en sus
celulares, esto sin necesidad de tener un dispositivo o hardware adicional
como POS.
11.2.2.4.
Depsito de efectivo
El sistema permitira a los usuarios realizar depsitos de efectivo en su

billetera mvil (cargar la cuenta), esto se realizara por medio de Puntos de
Pago y Recaudo (PPR) autorizados por el ORM, gestionado a travs de un
portal web.
11.2.2.5.
Retiro de efectivo
El sistema permitira a los usuarios retirar efectivo de su billetera mvil, esto

se realizara por medio de Puntos de Pago y Recaudo (PPR) autorizados por el
ORM, gestionado a travs de un portal web.
11.2.2.6.
Consulta
de
saldos
historial
de
transacciones
El sistema tendr la capacidad de generar reportes del historial
transacciones que sern enviados al usuario por medio de SMS cuando lo
solicite. Adems el usuario podr a travs de la plataforma consultar el saldo
disponible en su cuenta.
112
11.2.3.
sistema
Flujo de actividades y/o funciones del
A continuacin se presentarn los flujos de las actividades o funciones principales

del sistema de micropagos propuestos a travs de diagramas de actividades, esto
con el fin de entender mucho mejor el funcionamiento general del sistema para su
futura implementacin.
11.2.3.1.
Registrar Usuario
113
Ilustracin 15: Proceso de Registrar usuario.
114
11.2.3.2.
Autenticar Usuario
Ilustracin 16: Proceso de Autenticar usuario.
115
11.2.3.3.
Transferir dinero de persona a comercio
con ORM iguales
Ilustracin 17: Proceso de Transferir dinero de persona a comercio ORM iguales.
116
11.2.3.4.
Transferir dinero de persona a comercio
con ORM diferentes.
Ilustracin 18: Proceso de Transferir dinero de persona a comercio

ORM diferentes.
117
11.2.3.5.
Transferir dinero de persona a persona
ORM iguales.
118

iguales.
119
120
11.2.3.6.
Transferir dinero de persona a persona
ORM diferentes.
121

iguales.
11.2.3.7.
Enviar notificaciones
Ilustracin 21: Proceso de enviar notificaciones.

122
11.2.3.8.
Cancelar operacin
123
Ilustracin 22: Proceso de cancelar operacin
124
11.2.3.9.
Consultar Saldo
Il
ustracin 23: Proceso de consultar saldo
125
11.2.3.10.
Consultar historial
Il
ustracin 24: Proceso de consultar historial
11.2.3.11.
Bloquear cuenta
126
Ilustracin 25: Proceso de bloquear cuenta
127
128
11.2.3.12.
Comprar tiempo al aire
129
Ilustracin 26: Proceso de comprar tiempo al aire

130
11.2.3.13.
Cambiar PIN
Ilustracin 27: Proceso de cambiar PIN
131
11.2.3.14.
Depositar dinero
132
Ilustracin 28: Proceso de depositar dinero en la cuenta virtual.
133
134
11.2.3.15.
Retirar dinero
Ilustracin 29: Proceso de retirar dinero de cuenta virtual

135
136
12. Diseo del prototipo del sistema propuesto

En esta seccin se evidenciara el diseo de hardware y software del sistema de
micropagos propuesto en este proyecto.
12.1.
Modelo de datos
Con el siguiente modelo entidad-relacin se pretende comprender mejor los

conceptos que intervienen en este sistema y la manera como se relacionan. Este
modelo se presenta a travs de un diagrama UML que muestra las entidades del
dominio, los atributos y las relaciones que se tienen unas con otras.
Ilustracin 30: Modelo entidad-relacin

137
La Ilustracin 30 representa las entidades que interactan en el sistema de

micropagos (m-wallet) para cumplir con los requerimientos funcionales y as poder
brindar los servicios y cumplir con los objetivos establecidos anteriormente.
Se muestra que un usuario puede ser o no un punto de venta (establecidos por los
comercios para recibir los pagos), o puede ser o no un consumidor. Un punto de
venta tiene que pertenecer a un comercio, y este puede tener muchos puntos de
venta. El usuario puede o no tener una cuenta, sea crdito o dbito, en un banco
determinado a donde se le puede depositar el dinero si l lo desea. El usuario
puede tener uno o muchos terminales mviles, identificados por el nmero celular,
y cada uno debe pertenecer a una Operadora de Red Mvil. Cada ORM puede tener
muchos Puntos de Pagos y Recaudos (PPR), que son los establecimientos donde el
usuario puede ir a hacer el retiro o depsito del dinero en efectivo. El usuario
puede ser titular de una o varias cuentas, pero cada cuenta est asociada a un
solo terminal mvil. Cada usuario genera o recibe una transaccin, la cual puede
ser realizada o no en un PPR.
12.2.
Arquitectura del sistema

12.2.1.
Nodos de procesamiento
A continuacin se describirn los nodos de procesamiento que se evidenciarn en

el diseo de la arquitectura:
Servidor de base de datos: Nodo que alojar la base de datos del
sistema de micropagos.
Backup BD: Servidor que alojar una copia de seguridad de la
informacin sensible del sistema.
Nodo Banco: Nodo que permite la comunicacin con el banco del
usuario.
Nodo ORM: Alojar los componentes propios del ORM, que permitirn
la comunicacin con el sistema y el banco, permitiendo actualizaciones y
autorizaciones.
SMSC: Servidor de SMS que permite el envo y almacenamiento de los
mensajes.
Gateway USSD: Componente que permite el direccionamiento de los
mensajes va USSD.
Nodo PPR: Representa los puntos de pagos y recaudos que se
comunican con el sistema a travs de un portal web para permitir al usuario
los depsitos y los retiros.
Servidor web: Alojar la aplicacin web que consume los servicios
138
expuestos por el servidor de la aplicacin y permite la comunicacin con la

ORM y lo PPR.
Nodo Celular: Representa el dispositivo mvil del usuario y es la
interfaz de salida.
Servidor de aplicacin Sistema Central: Aloja las entidades del
modelo y toda la lgica de la aplicacin USSD.
139
12.2.2.
Arquitectura de software
En la siguiente ilustracin, se evidencia el diseo de la arquitectura de software del

sistema, conocido como diagrama de deployment, para cumplir con los
requerimientos funcionales mediante la exposicin de los componentes y nodos
del sistema y sus relaciones.
Ilustracin 31: Diagrama de deployment
12.2.3.
Arquitectura de hardware
En la siguiente Ilustracin, se evidencia la arquitectura de hardware del sistema de

micropagos a travs de un diagrama que expone los componentes fsicos del
sistema y de la red GSM y los protocolos de comunicacin entre ellos.
140
Ilustracin 32: Diagrama de la arquitectura de hardware
141
13.
Seguridad en el sistema de micropagos
En general un sistema de pagos (o micropagos) seguro debe tener en cuenta

estos aspectos fundamentales (Nacimba Chanataxi , 2008, pg. 127):
Privacidad: Garantiza que el contenido del mensaje slo pueda ser
ledo por el emisor y el destinatario del mensaje.
Autenticidad: Garantiza que todos los actores involucrados en la
comunicacin (transaccin) sean quien dicen ser.
Integridad: Asegura la deteccin de cualquier cambio en el contenido
del mensaje, desde el instante de envo hasta su recepcin.
En el caso de este sistema, estas garantas se logran mediante el uso del protocolo
SSL Secure Socket Layer, capa de seguridad entre los protocolos de aplicacin, la
cual estar entre la comunicacin del servidor web del sistema, los servidores del
ORM y las aplicaciones web de los PPR que consuman los servicios. Adems del
uso de certificados digitales y la firma digital.
Para este caso, el uso de la arquitectura GSM tiene ventajas importantes a
diferencia de otras tecnologas. La tarjeta SIM, que identifica al abonado frente al
ORM, es un buen medio de almacenamiento para albergar claves privadas y dado
que estas no pueden salir de la tarjeta, hace que este sistema, de entrada, cumpla
con los requisitos de prestacin servicios seguros.
No obstante, es importante tener en cuenta que dado que los usuarios efectuarn
los diferentes tipos de transacciones a travs del terminal mvil, deben existir
mecanismos de seguridad en el terminal, ya que el portador USSD no tiene
mtodos de cifrado y la seguridad de las redes GSM a pesar de ser elevada posee
las siguientes fallas:
El IMSI (identificador nico de usuario) se transmite en claro muchas
veces, revelando la presencia de un determinado usuario en una ubicacin, y
permitiendo identificar sus comunicaciones y actividades (Prez, Pic, &
Siles).
El algoritmo
de cifrado que se utiliza tanto para proteger la
confidencialidad de voz y mensajes, llamado A/5 puede ser vulnerado, ya
que se ha evidenciado que ya han podido romperlo.
Los dispositivos estn obligados a soportar el algoritmo de cifrado
llamado A5/0, que en realidad consiste en la ausencia de cifrado. Es decir,
estn obligados a aceptar transmitir y recibir en claro, si la red as se lo
indica.
142
Por este motivo es necesario implementar funciones y algoritmos criptogrficos, es

decir, cifrado y/o firma digital, para poder garantizar que la informacin no pueda
ser reconocida si la seguridad de la red es vulnerada. Aplicaciones de este tipo
para el terminal mvil pueden ser desarrolladas utilizando otros desarrollos
definidos en las libreras Java Card de Sun o en el API de Windows for Smart Card,
de Microsoft.
Un escenario importante que se tiene en cuenta en el sistema de micropagos
propuesto es: el robo del terminal mvil. En este caso el usuario puede estar
tranquilo, debido a que solo debe reportar al ORM la prdida del dispositivo para
que bloqueen la lnea, como se hace usualmente, y automticamente la cuenta en
la billetera mvil quedar bloqueada ya que est amarrada a la lnea telefnica del
abonado y el sistema se conecta con la red GSM que se encarga de actualizar el
estado de los abonados. De esta manera se congelan inmediatamente todos los
datos sensibles del usuario en el sistema de micropagos.
Se debe tener claridad que el uso de USSD brinda una capa de seguridad
significativa en el sistema, ya que por medio de este se establece una sesin
permanente con el terminal mvil durante toda la comunicacin, es decir, que la
comunicacin se mantiene en tiempo real y sin almacenamiento ni reenvo de
datos, como es el caso de SMS, evitando as la duplicidad y la perdida de
informacin durante la transaccin.
De acuerdo a lo anterior, el sistema de micropagos propuesto
someramente los aspectos fundamentales de seguridad mencionados:
cumple
Privacidad: La informacin en el terminal mvil estar cifrada, al igual

que la informacin que se almacena en los servidores del sistema. Adems la
sesin USSD se establece solamente entre la SIM del usuario y un nodo de la
red GSM, por este motivo el establecimiento o comercio que se encuentra
implicado en la transaccin no tiene accesos a la informacin que suministra
el usuario.
Autenticidad: Antes de realizar cada una de las transacciones se pide
la autenticacin del usuario y luego de que se establece la comunicacin
entre el emisor y el receptor, siempre se pide autorizacin adicional de los
implicados para realizar el movimiento. Adems, la comunicacin USSD se
establece de manera nica con la SIM insertada en el mvil del usuario, lo
cual permite identificar que se trata de un usuario vlido y que es el mismo.
Integridad: Al utilizar protocolos de comunicacin seguros (por
ejemplo SSL) se garantiza que la informacin no ser modificada a lo largo
de la comunicacin. Adems, al establecerse dicha comunicacin con el
143
terminal mvil utilizando USSD, est ser en tiempo real y sin

almacenamiento, lo cual impide que se genere algn cambio en el contenido
de la transaccin.
14. Resultados
Con la elaboracin de este proyecto de grado, se realizaron varios
anlisis desde el punto de vista econmico y tcnico referentes al diseo y la
implementacin de un sistema mviles de micropagos, se construy un
anlisis de los diferentes tipos de modelos econmicos, un anlisis del marco
regulatorio colombiano para este tipo de sistemas, un anlisis corto de la
seguridad del sistema de pagos mviles propuesto, entre otros. Cumpliendo
as con el objetivo especfico nmero 2.
Se dise la arquitectura de hardware y de software del sistema de
micropagos propuesto cumpliendo as con el objetivo especfico nmero 4.
Se realiza la especificacin y anlisis detallado de los requerimientos
funcionales y no funcionales de un sistema mvil de micropagos para
personas de la base de la pirmide. Cumpliendo de esta manera con el
objetivo especfico nmero 1.
Se realiza la especificacin clara de los componentes que hacen parte
de la arquitectura de hardware del sistema. Cumpliendo as con el objetivo
especfico 2.
144
Se logr aplicar un conjunto grande de conocimientos y prcticas

enseadas durante toda la carrera para la realizacin del diseo y
especificacin de sistemas de informacin complejos.
Los conocimientos adquiridos durante la carrera de Ingeniera de Sistemas
fueron de vital importancia para el diseo y la especificacin del sistema y
lograr poder realizar una propuesta posiblemente viable que tiene la
capacidad de generar un impacto positivo en la sociedad marginada de la
Republica de Colombia.
15. Conclusiones
El resultado de la realizacin de este proyecto de grado evidencia que
este sistema sera una novedosa solucin en Colombia no solo para la gente
de la base de la pirmide (estratos 1 y 2) sino tambin para todo usuario de
145
telefona mvil, ya que cuenta con grandes ventajas con respecto al

comercio mvil tradicional: es ms seguro, la penetracin mvil cada da va
en ascenso y es mayor a la de los computadores personales, adems es una
alternativa muy rpida y sencilla de usar.
A pesar de que existen varios modelos econmicos (o de negocio) que
pueden ser adoptados en el diseo e implementacin de un sistema mvil de
pagos o micropagos, es aconsejable utilizar el Modelo Colaborativo, el cual
es el que se propone usar en el sistema m-wallet, ya que evita el control
absoluto de las transacciones por un solo Stakeholder y se reparte en todos
los actores que intervienen. Esto de alguna manera puede disminuir el
fraude o desfalco por parte de la empresa que este a la cabeza del servicio o
que posea el mayor control.
Con el fin de lograr el correcto funcionamiento de un sistema mvil de
micropagos y de impulsar la inclusin financiera en el territorio colombiano
es indispensable plantear alianzas entre los diferentes actores del sistema,
esto con el objetivo de reducir cada vez ms las barreras que limitan este
tipo de servicios, como los elevados costos, el acceso a los servicios, la
plataforma tecnolgica, entre otros. Adecuadas asociaciones entre los
actores permitira expandir este tipo de servicios y as brindar no solo
beneficios para los menos favorecidos, sino tambin para todos los usuarios
que hacen parte del crculo de consumo.
La razn de ser o propsito de este proyecto de grado es crear un
sistema de micropagos inclusivo, que le permita a las personas de la base de
la pirmide (estratos 1 y 2) acceder a servicios financieros a un bajo costo.
No obstante para ello es necesario que el sistema sea expandible y pueda
acoger toda la escala socioeconmica, esta es la verdadera inclusin. Lo
anterior es posible en esta propuesta ya que se utiliza una tecnologa
totalmente interoperable, lo que hace al sistema adaptable para ser usado,
desde telfonos celulares bsicos sin conexin a internet hasta telfonos
inteligentes.
El desarrollo de un marco regulatorio adecuado en la regin debe ser
considerado como uno de los factores principales y el primer paso que se
debe dar antes de intentar lanzar este tipo de sistemas. En Colombia y
Latinoamrica hay mucho por hacer en lo referente a la utilizacin de la
tecnologa en el sector financiero impulsada por la falta de regulacin. No
obstante, el Gobierno Colombiano est interesado en explotar el potencial de
la tecnologa en este campo con leyes como la Ley de Inclusin Financiera, la
Ley 1450 de 2011, que apoya el acceso a servicios financieros como parte de
la competitividad del pas, entre otras.
146
USSD se perfila como un protocolo idneo para la implementacin de

sistemas mviles de pago como herramientas para impulsar la inclusin
financiera, esto debido a sus grandes ventajas como: es de bajo costo, casi
gratuito; es una tecnologa suficientemente robusta, segura y accesible
debido al gran desarrollo a nivel mundial de las redes GSM; aumenta la
seguridad en los sistemas de pago, ya que no es necesario tener tarjetas ni
efectivo para realizar los pagos y no requiere almacenamiento en el terminal
mvil; es sencillo; es rpido (hasta siete veces ms veloz que SMS), permite
el envo de ms informacin ya que sus cadenas constan de 182 caracteres y
brinda un valor agregado a la soluciones de micropagos mviles (como la
propuesta planteada) ya que permite que las transacciones financieras que
soporta el sistema se puedan llevar a cabo en lugares remotos, como el
campo, o las veredas o municipios alejados de la zona urbana, que son
locaciones regularmente habitadas por personas de estratos bajos (1 y 2 ).
147
16. Anexos
16.1.
Anexo 1
Este anexo presenta los resultados de una encuesta que se realiz a

aproximadamente 80 personas de diferentes estrato socioeconmicos con el fin de
validar el mercado y la propuesta de valor, adems de tener una idea adicional de
lo que desean y no desean las personas de un sistema de micropagos.
1. Durante el ltimo mes, cuantas veces aproximadamente se ha
quedado sin dinero cuando necesita pagar en efectivo?
148
2. Qu ha hecho para solucionar este problema?
3. Realiza usted pagos o transacciones de dinero por internet?
149
4. Qu tipo de pagos realiza?
5. Con cuanta frecuencia realiza transacciones en Internet?
150
6. Qu medio utiliza para efectuar estas transacciones?
7. Cules son las razones por las cuales no realiza pagos en internet?
151
8. Cules cree que son los principales limitantes de los pagos en

internet?
9. Si se le permitiera pagar directamente desde su celular de manera

segura, confiable y rpida en cualquier establecimiento, estara dispuesto
a no utilizar el papel moneda?
152
10. Utilizara una plataforma electrnica que le permita enviar dinero a

otras personas de manera segura, confiable y rpida mediante su
telfono mvil?
11. Utilizara una plataforma electrnica que le permita realizar

transacciones financieras sin tener necesariamente una tarjeta dbito o
crdito?
153
12. Pagara por los servicios que le brinda esa plataforma?
13. Usted prefiere que el cobro de la transaccin se por medio de:
154
14. Usa o ha usado alguna plataforma o empresa que le brinde

servicios similares a los mencionados anteriormente?
15. Conoce alguna plataforma o empresa que le brinde servicios

similares a los mencionados anteriormente?
155
17. Referencias bibliogrficas

ALEGSA. (s.f.). Diccionario de Informtica y tecnologa. Obtenido de
ALEGSA.com.ar: http://www.alegsa.com.ar/Dic/http.php
Antel. (s.f.). Bit$ La billetera mvil de los uruguayos. Obtenido de
http://www.antel.com.uy/bits/productos/recarga-de-saldos
Barbacci, M. R., Ellison, R., Lattanze, A. J., Stafford, J. A., Weinstock, C. B., & Wood,
W. G. (2003). Quality Attribute Workshos (QAW), Third Edition. Carnegie
Mellon Software Engineering Institute. Pittsburgh: . Obtenido de
http://www.sei.cmu.edu/reports/03tr016.pdf
Boden, R. (1 de Noviembre de 2013). NFC World. Obtenido de
http://www.nfcworld.com/2013/11/01/326652/citibank-3-launch-nfc-mobilewallet-hong-kong/
156
Cat Mobile Wallet. (s.f.). Obtenido de Cat Mobile Wallet: http://catwallet.com/see-itin-action/vea-cat-en-accion/

Cipriani, J. (22 de Abril de 2014). Review: Loop mobile wallet. Fortune News.
Obtenido de http://fortune.com/2014/04/22/review-loop-mobile-wallet/
Citibank. (s.f.). 3 CITI WALLET MOBILE APPLICATION. Obtenido de citibank:
https://www.citibank.com.hk/english/ways-to-bank/3citiwallet-mobileapp.htm
Congreso de la Republica. (2013). http://www.fenalco.com.co/. Recuperado el 21 de
11 de 2014, de
http://www.fenalco.com.co/sites/default/files/fenalcojuridica_337.pdf
Congreso de la Repblica. (2014). EXPOSICION DE MOTIVOS AL PROYECTO DE LEY
Por la cual se dictan medidas tendientes a promover el acceso a los
servicios financieros transaccionales y se dictan otras disposiciones..
Colombia.
Congreso de la Republica. (21 de Octubre de 2014). Ley No. 1735. Bogota D.C,
Colombia.
Consultative Group to Assist the Poor (CGAP). (s.f.). Branchless Banking Diagnostic
Template. Obtenido de http://www.cgap.org/sites/default/files/CGAPBranchless-Banking-Diagnostic-Template-Feb-2010.pdf
Cuji Dutan, D. A., & Guerrero Vasquz , L. F. (Julio de 2014). Anlisis de la
factibilidad para la implementacin de la billetera mvil en la ciudad de
Cuenca. Cuenca, Ecuador.
Davidson, N., & McCarty, M. (s.f.). Money Mobile for the Unbanked. Fomentar el
Uso del Dinero Mvil para Personas No. Obtenido de
http://www.gsma.com/connectedwomen/wpcontent/uploads/2012/03/customeractivation_spanishfinal.pdf
Davivienda. (s.f.). daviplata. Obtenido de https://daviplata.com/todohacerlanding.php
Dinero. (2011). La nueva billetera mvil del pas. Dinero .
El porta de ISO 27000. (s.f.). Obtenido de http://www.iso27000.es/sgsi.html
El portal de ISO 27000. (s.f.). Obtenido de http://www.iso27000.es/sgsi.html
157
Falcioni, N. (s.f.). Movilion. Obtenido de http://www.movilion.com/oi-carterabilletera-movil-banco-de-brasil-y-cielo/

Fon Wallet. (s.f.). Obtenido de FonConnex: http://www.fonwallet.com/#about
Fundacin Wikimedia. (s.f.). Wikipedia La Enciclopedia Libre. Obtenido de
http://es.wikipedia.org/wiki/Servicio_de_mensajes_cortos
gfgdf. (s.f.).
Google Inc. (s.f.). Google Wallet. Obtenido de https://www.google.com/wallet/
Graham, O. (11 de 10 de 2013). esan Graduate School of Business . Recuperado el
21 de 12 de 2014, de
http://www.esan.edu.pe/conexion/actualidad/2013/10/11/inclusionfinanciera/#nota1
GSMA. (2014). www.gsma.com. Obtenido de
http://www.gsma.com/digitalcommerce/wp-content/uploads/2013/10/MOBILEWALLET-CASE-STUDY-TURKCELL-V3.PDF
GSMA. (s.f.). GSMA Mobile Economy Latinoamerica. Obtenido de GSMA Mobile
Economy Latinoamerica:
http://www.gsmamobileeconomylatinamerica.com/SPA_LatAmME_v6_WEB_FI
NAL.pdf
Guerrero Vsquez, L. F., & Cuji Dutn, D. A. (Julio de 2014). Tsis previa a la
obtencin del ttulo de Ingeniero Electrnico. Anlisis de la factibilidad para
la implementacin de la billetera mvil en la ciudad de Cuenca. Cuenca,
Ecuador.
Guiarticle. (s.f.). guiartic.com. Obtenido de http://guiartic.com/electronica/article110.html
IFC - International Finance Corporation. (s.f.). M-Money Channel Distribution Case
Afghanistan. Obtenido de
http://www.ifc.org/wps/wcm/connect/cad6888049585efe9e8abf19583b6d16/T
ool%2B6.9.%2BCase%2BStudy%2B-%2BM-Paisa%2BAfghanistan.pdf?
MOD=AJPERES
JCB. (6 de Noviembre de 2012). Newsroom . Obtenido de JCBs leading-edge
corporate activity: http://www.jcbcorporate.com/english/news/seq_0300.html
Kelion, L. (15 de Enero de 2014). BBC News Technology. Obtenido de
158
http://www.bbc.com/news/technology-25727333
Konrad, W., Zavagli, G., & Schuba, M. (s.f.). Mobile Payments - State of the Art and
Open Problems. Ericsson Research,, Tokyo - Herzogenrath.
Microsoft. (s.f.). Windows Phone . Obtenido de http://www.windowsphone.com/esco/how-to/wp8/connectivity/whats-data-roaming
MinTIC. (22 de Octubre de 2014). Presidente Santos sancion Ley de Inclusin
Financiera que dar acceso a 20 millones de colombianos gracias a las TIC.
Obtenido de MINTIC: http://www.mintic.gov.co/portal/604/w3-article7367.html
Moneto. (s.f.). moneto. Obtenido de http://www.moneto.co.uk/what-is-moneto/
MyWallet. (s.f.). MyWallet. Obtenido de http://www.my-wallet.com/index-en.php
Nacimba Chanataxi , M. V. (Enero de 2008). Proyecto previo a la obtencin del
titulo de Ingeniero en Electrnica y Telecomunicaciones. Estudio del
protocolo USSD como plataforma para birndar servicios de comercio mvil y
otras transacciones financieras. Ecuador. Obtenido de
http://bibdigital.epn.edu.ec/bitstream/15000/759/1/CD-1217.pdf
Pachn De la Cruz, A. (s.f.). Evolucin de los sistemas mviles celulares GSM. Cali,
Colombia: Departamento Redes y Telecomunicaciones Universidad Icesi-i2T.
Parada Llanes , M. (2015). Credibanco ya trabaja con seis instituciones para
implementar su billetera virtual. La Republica.
Prez, D., Pic, J., & Siles, R. (s.f.). criptored. Obtenido de
http://www.criptored.upm.es/crypt4you/temas/privacidadproteccion/leccion4/leccion4.html
Priso, G. E. (2006). Mobile payments : what we can learn from the past. Mobile
payments : what we can learn from the past. Boston: Massachusetts Institute
of Technology, Sloan School of Managemen. Obtenido de
http://dspace.mit.edu/handle/1721.1/37234
Smart Card Alliance. (Julio de 2008). Proximity Mobile Payments Business
Scenarios: Research Report on Stakeholder Perspectives. (CPC-08001).
Stashluk, Jr, E., & Ross, F. (2001). USA Patente n US6263212 B1.
SYSMOV. (s.f.). sysmov. Obtenido de
159
http://www.sysmov.net/presentacion/MensajeriaPDF.pdf
Tecnologas para la Inclusin Financiera. (2012). Siete ideas para la inclusin
financiera., (pg. 3). Washington, D.C.
Telefonica. (s.f.). Telefonica Innovation Hub. Obtenido de
blog.digital.telefonica.com:
http://blog.digital.telefonica.com/2012/05/10/wanda-turning-your-phone-intoa-modern-day-bank-account/
Tigo. (s.f.). Tigo Money . Obtenido de http://www.tigo.com.py/tigo-money/que-estigo-money
Tigo. (s.f.). Tigo Money Bolivia. Obtenido de http://www.tigo.com.bo/tigo-money
Tisal, J. (1999). La Red GSM. Paris: Paraninfo Thomson Learning.
Turkcell. (s.f.). www.turkcell.com.tr. Obtenido de
www.turkcell.com.tr/servisler/turkcell-cuzdan
US Bank . (s.f.). US Bank Mobile Banking. Obtenido de
https://www.usbank.com/mobile/index.html
W3C. (s.f.). W3C Architecture domain. Obtenido de HTTP - Hypertext Transfer
Protocol: http://www.w3.org/Protocols/
ETSI: Digital cellular telecommunications system (Phase 2+). Unstructured
Supplementary Service Data (USSD). Stage 1 (GSM 02.90 version 7.0.0 Release
1998).
1998).
1998).
160

Diseño de Una App Multioperable USSD para Billetera Electronica.

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Diseño de Una App Multioperable USSD para Billetera Electronica.

Uploaded by

Copyright:

Available Formats

DISEO Y ESPECIFICACIN DE UNA BILLETERA ELECTRNICA

MVIL INTEROPERABLE COMO INTEGRACIN CON SPONTIME.

Marco Terico y Estado del arte

Marco Terico Financiero Negocio

5.1.1. Inclusin Financiera:

Marco Terico Tcnico

5.2.1. GSM (Global System for Mobile)

Estado del arte

Contribucin del proyecto de grado

Resultados que se esperan obtener

8.1.1. Stakeholders del sistema

Comparativo entre los modelos de negocio

9. Anlisis Regulatorio y legal

Requerimientos del sistema m-wallet

10.2.1. Clasificacin Requerimientos

Especificacin Casos de Uso

10.3.1. Registrar un usuario al sistema

Diagrama de Casos de Uso

11.1.1. Objetivos del sistema de pagos mviles (m-Wallet)

11.2.1. Plataforma tecnolgica

Diseo del prototipo del sistema propuesto

12.2.1. Nodos de procesamiento

Seguridad en el sistema de micropagos

ORM: Operador de Red Mvil.

PPR: Punto de Pagos y Recaudos.

SMS: Short Message Service.

USSD: Unstructured Supplementary Service Data.

GSM: Global System for Global Communications.

POS: Point of Sale.

SMSC: Short Message Service Center.

HTTP: Hypertext Transfer Protocol.

HTTPS: Hypertext Transfer Protocol Secure.

HLR: Home Location Register.

VLR: Visitor Location Register.

MSC: Mobile Switching Center

MSISDN: Mobile Station Integrated Services Digital Network.

WAP: Wireless Application Protocol.

NFC: Near Field Communication.

STK: SIM Application Toolkit.

TCAP: Transaction Capabilities Application Part.

MAP: Mobile Application Part.

Proceso de retirar dinero de cuenta virtual

Tabla 28: Escenario de QAW #9

travs de corresponsales no bancarios (CNB). Este fue un avance en el

2. Descripcin del problema

4. Objetivos del proyecto

Disear y especificar la arquitectura de software, hardware e interconexin

1. Especificar y priorizar los requerimientos

mviles, que cumpla con

especificaciones de software, hardware e interconexin.

5. Marco Terico y Estado del arte

Marco Terico Financiero Negocio

La inclusin financiera puede definirse como el "acceso y uso de servicios

5.1.2. Punto de Venta (POS Point of Sale):

5.1.3. Sociedades especializadas en depsitos y

objetivo es (Congreso de la Republica, 2014):

5.1.4. Billeteras Mviles (m-wallet):

Contenido de la billetera mvil

Una billetera mvil puede tener mltiples usos y puede facilitarle la

Un pago mvil se puede definir como cualquier pago en el cual un

Transacciones persona a persona (P2P).

- La billetera mvil puede ser usada como un servicio

- Puede ser usada como identificacin digital a travs