SISTEMA TRANSACCIONAL DE PAGOS Y TRANSFERENCIAS …

SISTEMA TRANSACCIONAL DE PAGOS Y TRANSFERENCIAS MÓVILES

JUAN JOSÉ OTERO CLAROS

BOGOTÁ D.C. UNIVERSIDAD DE LOS ANDES

DICIEMBRE DE 2005

1

SISTEMA TRANSACCIONAL DE PAGOS Y TRANSFERENCIAS MÓVILES

JUAN JOSÉ OTERO CLAROS CODIGO 200021927

CICLO TERMINAL 2

Tesis de grado presentada al profesor Harold Cruz

BOGOTÁ D.C. UNIVERSIDAD DE LOS ANDES

DICIEMBRE DE 2005

2

TABLA DE CONTENIDO

1. INTRODUCCIÓN. 1.1.1. Estructura del documento 1.1.2. Enfoque del documento 1.1.3. Metodología

2. TIPOS DE TRANSACCIONES MÓVILES 2.1.1. Transacciones móviles remotas 2.1.2. Transacciones móviles locales

3. EJEMPLOS DE TRANSACCIONES MÓVILES

3.1.1. Compras en sitios WEB o WAP 3.1.2. Compra de artículos en comercios 3.1.3. Máquinas de venta automática 3.1.4. Pagos o transferencias de dinero entre personas 3.1.5. Compra de tiquetes para el transporte público

4. REQUERIMIENTOS FUNCIONALES GENERALES 4.1.1. Usuario 4.1.2. Comercio

5. REQUERIMIENTOS NO FUNCIONALES GENERALES

5.1.1. Usuario 5.1.2. Requerimientos del modelo de negocio 5.1.3. Requerimientos técnicos

6. ANALISIS DE TECNOLOGIAS

6.1.1. JAVA™ 2 PLATFORM, MICRO EDITION (J2ME)

6.1.1.1.1. Ejemplo: realizar un pago 6.1.1.1.2. Facilidad de uso 6.1.1.1.3. Costo 6.1.1.1.4. Seguridad 6.1.1.1.5. Interoperabilidad 6.1.1.1.6. Rendimiento 6.1.1.1.7. Análisis

3

6.1.2. SMS (SHORT MESSAGE SERVICE) 6.1.2.1.1. Ejemplo: realizar un pago 6.1.2.1.2. Facilidad de uso 6.1.2.1.3. Costo 6.1.2.1.4. Seguridad 6.1.2.1.5. Interoperabilidad 6.1.2.1.6. Rendimiento 6.1.2.1.7. Análisis

6.1.3. SAT (SIM APPLICATION TOOLKIT)


6.1.4. VOICEXML E IVR


6.1.5. WAP (WIRELESS APPLICATION PROTOCOL)


7. SOLUCIONES EXISTENTES EN EL MUNDO 8. INFRAESTRUCTURA BANCARIA EN COLOMBIA 9. POSIBLE SOLUCION EN COLOMBIA – MOBILE BANKING

9.1.1. MODELO DE NEGOCIO

9.1.1.1.1. Introducción 9.1.1.1.2. Modelo actual con tarjetas de crédito y débito 9.1.1.1.3. Modelo con sistema SMS

4

9.1.1.1.4. Enfoque del nicho de mercado 9.1.1.1.5. Costos estimados

9.1.1.1.5.1.1. Costos para el establecimiento 9.1.1.1.5.1.2. Costos para la persona natural (usuario final)

9.1.1.1.6. Conclusiones

9.1.2. ANALISIS Y DESCRIPCION DE CASOS DE USO

9.1.2.1.1. Requerimientos funcionales

9.1.2.1.1.1.1. Establecimiento 9.1.2.1.1.1.2. Persona 9.1.2.1.1.1.3. Administrador transaccional

9.1.3. DISEÑO DE LA APLICACIÓN

9.1.4. ASPECTOS CRITICOS

9.1.5. CONCLUSIONES DE LA APLICACION

10. CONCLUSIONES GENERALES

11. BIBLIOGRAFÍA

5

Introducción

Tarde o temprano el móvil se convertirá en un método de pago adicional a los sistemas electrónicos actuales independientemente de si se asocia a una cuenta bancaria o si se implementa como un servicio de billetera electrónica. El objetivo de esta tesis es describir detalladamente los requerimientos funcionales y no funcionales de una solución de transacciones móviles, analizar las tecnologías actualmente disponibles en el mercado móvil y proponer una posible arquitectura de implementación en el entorno colombiano. Esta tesis no solo contiene este documento que explica toda la teoría acerca de las transacciones móviles, sino que incluye un prototipo funcional (escrito en JAVA1, con interfaz Web en JSP’s diseñada para correr sobre un servidor JBOSS) basado en SMS capaz de realizar consultas, transferencias y pagos.

Estructura del documento

El documento se dividió en tres grandes partes: la primera inicia describiendo los tipos de transacciones móviles y algunos ejemplos interesantes. Más adelante, en el segundo capítulo se describen los requerimientos funcionales y no funcionales que debe soportar la solución. La segunda parte del documento es una de las más importantes e inicia en el tercer capítulo analizando J2ME2, SMS3, WAP4, VoiceXML 5y SAT 6como posibles tecnologías para el usuario final utilizando como punto de partida los requerimientos más importantes del segundo capítulo. Por último, la tercera parte del documento describe soluciones existentes en el mercado, la infraestructura bancaria en Colombia y propone una arquitectura para la implementación de la solución. En esta sección, se hará todo un proceso de análisis para el desarrollo del prototipo basado en SMS, que incluye el modelo de negocio, el análisis, el diseño y seguridad de la aplicación.

Enfoque del documento

Aunque las transacciones móviles se pueden categorizar utilizando múltiples criterios, para efectos prácticos de este documento se dividirá en 2 grandes grupos: micro/macropagos y remotas/locales. Los micropagos comprenden valores menores a $30.000 pesos (USD 13) mientras que los macropagos comprenden cualquier valor mayor a este. Por otro lado, la diferencia entre una transacción local

1 Java technology: Para más información, ver http://java.sun.com/ 2 Java 2 Platform – Micro Edition: Para más información ver http://java.sun.com/j2me/ 3 Short Message Service: Servicio que prestan los operadores celulares mediante el cual es posible enviar mensajes de texto desde y hacia teléfonos móviles. 4 Wireless Application Protocol: Protocolo mediante el cual es posible acceder a Internet desde un teléfono móvil. Requiere del servicio del operador. 5 Tecnología que facilita una interfaz de voz donde el usuario puede interactuar con su voz o las teclas numéricas del teléfono. Para más información, ver http://www.voicexml.org/ 6 Sim Application Toolkit: Para más información, ver http://www.gemplus.com/techno/stk/

6

y remota es que la primera requiere contacto entre las partes mientras que la segunda no. El siguiente diagrama explica la relación entre los tipos de de transacciones móviles.

Existe un gran campo de investigación en las transacciones que comprenden micropagos, especialmente en el de transacciones locales. Sin embargo, esta tesis se enfocará en analizar las posibles tecnologías que aplican para los macropagos utilizando la actual infraestructura bancaria en Colombia. La solución se puede implementar asociando el móvil a una cuenta bancaria, desarrollando un servicio de billetera electrónica, utilizando un sistema prepago, etc. Aunque en este documento analizaremos superficialmente algunas de estas soluciones en el entorno colombiano, se requiere un mayor estudio en esta área y se deja como inquietud para futuras investigaciones. Para el caso del prototipo que se desarrollará, más adelante se vera el porque se decidió hacerlo a manera de sistema prepago, donde la entidad financiera es la responsable de manejar dichas cuentas prepagadas.

Metodología

El proceso inició con la recolección de importante información tomada de Internet y personas que se encuentran en constante contacto con el medio. La información se analizó y se filtró utilizando como criterio de selección únicamente las lecturas que aplicaban para nuestro enfoque. Después se procedió a realizar el documento que se complementó con nueva documentación y entrevistas con personas del sector financiero y de los operadores celulares.

Remotos Locales M

icro

pago

s M

acro

pago

s

-Bajo volumen, gran potencial. -Billeteras basadas en servidor. -Autenticación WIM o PIN

-Emergente con gran potencial. -Tecnología bluetooth o RFID.

-Existente pero aún con potencial. -Autenticación MSISDN.-Premium SMS / WAP Push

-Emergente, con gran potencial -Tecnología RFID.

Figura 1. Relación entre los tipos de transacciones móviles.

7

Las entrevistas con las personas del sector financiero, más específicamente con las personas encargadas del área de tarjetas de crédito serán fundamentales para darle el enfoque correcto al prototipo, que de en adelante en este documento, será referido como “Mobile Banking”. Se espera que este documento se vuelva esencial en la implementación de soluciones móviles en el sector financiero y que promueva el uso de este servicio. Con el prototipo, se espera ilustrar el mecanismo de funcionamiento de una de las posibles formas de implementar micro o macropagos.

Tipos de transacciones móviles

Aunque las transacciones móviles se pueden categorizar utilizando múltiples criterios, para efectos prácticos de este documento las dividiremos en 2 grandes grupos: micro/macropagos y remotas/locales. Los micropagos comprenden valores menores a $30.000 pesos (USD 13) mientras que los macropagos comprenden cualquier valor mayor a este. La diferencia entre una transacción local y remota es que la primera requiere contacto entre las partes mientras que la segunda no. A continuación se describe con más detalle las transacciones locales/remotas. Para el caso del prototipo incluido en esta tesis, éste manejara tanto transacciones móviles remotas como locales.

Transacciones móviles remotas

Se definen como la capacidad de realizar transferencias de dinero entre personas y/o negocios utilizando el móvil sin necesidad de que las partes se encuentren en el mismo lugar en el momento de la transacción. El rango de posibilidades para esta tecnología es muy amplio, desde la compra de tonos y logos que se envían al móvil hasta la adquisición de bienes, servicios y contenido. SMS constituye la mayoría de transacciones móviles actuales para la adquisición de contenido. El cobro lo realiza directamente el operador y traslada el porcentaje correspondiente al proveedor del contenido una vez hecho el recaudo. La aceptación de WAP y otras tecnologías emergentes han permitido independizar el cobro de los operadores y trasladarlo a las entidades financieras pertinentes. Sin embargo, se necesita un sistema realista y flexible para el pago con tarjetas crédito o un sistema similar.

Transacciones móviles locales

Se definen como la capacidad de realizar transferencias de dinero entre personas y/o negocios utilizando dispositivos móviles. La restricción es que las partes se deben

8

encontrar en el mismo lugar en el momento de la transacción. Es muy posible que el móvil termine por convertirse en la próxima billetera digital. Se han desarrollado módulos RFID 7independientes que se adhieren al móvil sin una conexión al sistema electrónico del mismo. Este tipo de implementaciones se ha probado en prototipos y en algunos casos comerciales. Se espera que los próximos módulos tengan acceso a los recursos del teléfono mejorando la interacción del usuario y expandiendo las posibles aplicaciones. Bluetooth tiene el potencial de ser usado en transacciones locales que requieran grandes transferencias de información en ambas direcciones. Sin embargo, transacciones críticas en tiempo no pueden ser implementadas ya que la configuración y la conexión inicial entre los dispositivos es muy lenta para los requerimientos no funcionales de la solución. En el área de los pagos móviles basados en tarjetas de pago expedidas por bancos internacionales, EVM móvil8 (especificación actual para tarjetas de crédito aplicado a los móviles) se ve como un posible concepto a futuro, especialmente en el área de pagos móviles locales. Una serie de requerimientos fundamentales se necesitan cumplir en el EMV móvil para que las implementaciones tengan sentido. Específicamente:

• La necesidad por el concepto a nivel global. • La especificación actual de EMV se debe desarrollar para que tenga en cuenta

requerimientos especiales para dispositivos móviles. o El rol de los sistemas móviles se debe aclarar. o Los requerimientos en seguridad para los dispositivos móviles se deben

evaluar detalladamente. • La certificación de los móviles debe ser expedida por las mismas industrias que

crean los móviles. Ejemplos de transacciones móviles

Existen innumerables ejemplos que aplican para los sistemas de transacciones móviles tanto remotas como locales. Los ejemplos que describiremos son los siguientes:

• Compras en sitios WEB o WAP. • Compra de una artículo en una tienda. • Maquinas de venta automática. • Pagos o transferencias de dinero entre personas. • Tiquetes para transporte público.

7 RFID (siglas de Radio Frequency IDentification, en español Identificación por radiofrecuencia) es un método de almacenamiento y recuperación de datos remoto que usa dispositivos denominados etiquetas o tags RFID. Una etiqueta RFID es un dispositivo pequeño, como una pegatina, que puede ser adherida o incorporada a un producto, animal o persona . Las etiquetas RFID contienen antenas para permitirles recibir y responder a peticiones por radiofrecuencia desde un emisor-receptor RFID. Las etiquetas pasivas no necesitan alimentación eléctrica interna, mientras que las activas sí lo requieren. Recuperado el 19 de Junio de 2005, de http://es.wikipedia.org/wiki/RFID 8 Para más información acerca de EMV, ver http://www.fnmt.es/es/html/tage/lc_ta_pr.asp

9

Compras en sitios WEB o WAP

Este escenario describe la situación el la cual una persona ha ingresado a un portal WEB o WAP, decide realizar una compra y va a utilizar su dispositivo móvil como medio de pago. La secuencia de eventos, según la arquitectura que se utilice, puede variar ampliamente. Por ejemplo, al realizar el pago en el sitio WEB/WAP utilizando el móvil como medio de pago, el usuario podría ingresar en el portal su MSISDN 9(número de móvil) o automáticamente el mismo móvil reconocería la compra (en el caso de un portal WAP). Se inicia inmediatamente una sesión inalámbrica con el portal donde el usuario deberá autenticarse (manual o automáticamente) en el móvil y la transacción termina con un mensaje de confirmación en el móvil del usuario. Las ventajas sobre los pagos que actualmente se hacen con tarjeta de crédito en portales son evidentes. La transacción es mucho más segura ya que la autenticación y la confirmación se hace directamente en el móvil. La única forma de fraude sería si otra persona toma el móvil, confirma la transacción y conoce el PIN.

Compra de artículos en comercios

Este caso aplica para tiendas, restaurantes, etc. y cualquier pago que se haga cara a cara utilizando el móvil en comercios establecidos. El comercio inicia la transacción desde un POS o un sistema WEB ingresando o reconociendo el dispositivo del móvil (vía RFID, Bluetooth10, etc.) e ingresa el valor a pagar. Se inicia una sesión inalámbrica entre el sistema del comercio y el móvil. El usuario se autentica en el móvil y la transacción termina con un mensaje de confirmación para ambas partes.

Maquinas de venta automática

Este escenario describe cómo se podría utilizar el móvil como medio de pago para una maquina de venta automática. Existen diferentes implementaciones para iniciar la transacción: el usuario podría ingresar en su móvil el código de la maquina y el artículo deseado, podría ingresar a un pequeño portal de la maquina y seleccionar el artículo o ingresar su móvil en la máquina y el artículo deseado. Una vez se ha iniciado la transacción se establece una sesión inalámbrica entre la máquina y el móvil, el usuario se autentica y la transacción termina con la entrega del producto o un mensaje de error (el usuario puede no tener fondos o la maquina no tiene disponible el producto seleccionado).

9 Formato usado Internacionalmente para referirse al número del teléfono móvil.

10 Bluetooth es la norma que define un estándar global de comunicación inalámbrica, que posibilita la transmisión de voz y datos entre diferentes equipos mediante un enlace por radiofrecuencia. Los principales objetivos que se pretende conseguir con esta norma son: - Facilitar las comunicaciones entre equipos móviles y fijos - Eliminar cables y conectores entre éstos - Ofrecer la posibilidad de crear pequeñas redes inalámbricas y facilitar la sincronización de datos entre nuestros equipos personales. Recuperado el 20 de Junio de 2005, de http://es.wikipedia.org/wiki/Bluetooth

10

Pagos o transferencias de dinero entre personas

Este ejemplo describe como hacer transferencias entre personas utilizando el móvil, de forma segura y sin necesidad de revelar información personal o de cuentas bancarias. El usuario se autentica en su móvil, ingresa el móvil u otra forma de identificación de la otra parte y el monto a transferir. Un mensaje de confirmación llega a al móvil del usuario que recibe la transacción para que se autentique y la transacción termina con un mensaje de confirmación en ambas partes.

Compra de tiquetes para el transporte público

Este escenario describe una forma de compra y autenticación en las entradas en sistemas como el Transmilenio y otros sistemas de transporte públicos que se organizarán en el país. También puede aplicar para tiquetes aéreos, en tren, etc. Las implementaciones para la compra del tiquete pueden variar ampliamente. Lo importante es que el tiquete permanece en el teléfono virtualmente evitando otra tarjeta o comprobante en el momento del ingreso. La compra del tiquete puede ser cara a cara utilizando el móvil como medio de pago o a través de un portal donde se utilice el teléfono como medio de pago. Al momento de ingresar al sistema de transporte, el usuario podría acercar su teléfono al sistema de recolección de tiquetes, oprimir un botón para activar la función de tiquetes o seleccionar un sistema que generaría un PIN para el ingreso.

Describiremos los requerimientos funcionales y no funcionales que debe soportar la solución y analizaremos la aplicabilidad de estos requerimientos en cada una de las tecnologías móviles. Por último analizaremos una posible implementación aplicado al entorno colombiano.

Requerimientos funcionales generales

Usuario

Para efectos prácticos de este documento, los requerimientos funcionales para el usuario excluyen el inicio del proceso que condujo hasta la transacción. Se enfocan en el momento en el que el usuario va a hacer el pago o la transferencia de dinero independientemente del motivo (pago en un restaurante, transferencia de dinero entre personas, compra de un artículo en una tienda virtual, etc.).

11

Autenticación El usuario debe poder autenticarse contra el sistema de transacciones móviles. La forma de autenticación puede variar, puede ser por hardware o por software, ingresando un PIN o automáticamente utilizando el MSISDN del móvil o un certificado emitido por la entidad financiera.

Realizar transferencia

Este caso de uso lo utiliza el usuario cuando va a hacer un pago o va a hacer una transferencia entre cuentas. Debe seleccionar la cuenta origen, la cuenta destino y la cantidad.

Confirmar transferencia

Cuando el usuario realiza el pago de algún bien, servicio o contenido, el comercio es el encargado de iniciar la transacción. El usuario únicamente recibirá una confirmación que deberá aceptar o rechazar. Por otro lado, si es un usuario que está recibiendo una transferencia (por ejemplo, otra persona está transfiriéndole dinero) también recibirá una confirmación que deberá aceptar o rechazar.

Comercio

Autenticación El comercio debe poder autenticarse con el sistema de transacciones móviles. La forma de autenticación puede variar, puede ser por hardware o por software,

12

ingresando un nombre de usuario y contraseña o por un certificado emitido por la entidad financiera.

Iniciar transacción

El comercio debe tener la capacidad de iniciar una transacción. El inicio de la transacción puede variar ampliamente, puede ser utilizando un POS, un sistema WEB o cualquier otra forma que permita iniciar la transacción. Deberá ingresar la cantidad y la identificación del usuario. Para la identificación se han utilizado sistemas RFID en los celulares, códigos de barra, el MSISDN, bluetooth o tarjetas inteligentes.

Confirmar transacción

Una vez se ha ingresado la información el comercio podrá aceptar o cancelar la transacción.

Requerimientos no funcionales generales

Usuario

Rapidez Según el Mobey Forum11, las transacciones no deben tomar más de 30 segundos excluyendo los ingresos que deba hacer el usuario. Por ejemplo, en una transacción remota, cuando el usuario selecciona “comprar”, no deben pasar más de 5 segundos para que reciba las posibles formas de pago. Una vez se ha seleccionado la forma de pago y los detalles de autenticación validados (esto no debe demorar más de 10 segundos), un mensaje de transacción exitosa no debe demorar más de 15 segundos después de ingresar el PIN. Las transacciones locales deben estar sujetas a tiempos parecidos.

Facilidad para el usuario

Es el requerimiento más importante ya que define la aceptación que pueda tener la solución. Debe ser fácil de utilizar (en comparación con los sistemas actuales) y se debe reducir el impacto cultural demostrando la facilidad para hacer las transacciones y motivar su uso con descuentos y promociones.

Precio

Si el precio de cada transacción es muy alto respecto al beneficio que brinda la solución, no se cambiaran los sistemas actuales de pago. Se deben dar incentivos a los comercios y a los consumidores para crear hábito.

Independencia bancaria, de operador celular y de móvil

Los usuarios deben tener la posibilidad de cambiar operador celular o su móvil sin tener que hacer cambios en los servicios de pago.

Alta aceptación en comercios

Si los comercios no aceptan la solución los usuarios tampoco lo harán. Es importante motivar a los comercios con bajos porcentajes de comisión y la posibilidad de financiarles cualquier sistema adicional que deban adquirir.

11 Mobey Forum: Recuperado el 6 de Mayo de 2005, de http://www.mobeyforum.org

13

Bajo impacto en la tecnología

Se debe comenzar utilizando tecnología existente como SMS y WAP ya que son tecnologías conocidas y aceptadas por los usuarios. A medida que los usuarios encuentren valor en la solución se puede implementar en tecnologías emergentes que ofrezcan mayor valor.

Seguridad

La solución debe ser segura. Deben existir mecanismos contra fraudes e intento de intrusión en los sistemas y las comunicaciones. Los usuarios deben saber y estar seguros que el destino de la transacción es el que ellos esperan. La información debe estar lo suficientemente cifrada para garantizar que no habrá acceso de terceros a la información.

Privacidad

La información del usuario se debe mantener con la mayor confidencialidad y no debe ser distribuida a terceros.

Requerimientos del modelo del negocio

Autenticación flexible Dependiendo del monto y tipo de la transacción se deben poder utilizar diferentes niveles de autenticación. Para pagos de bienes y servicios se puede utilizar autenticación basada en certificados y PKI móvil. Para micro-pagos, autenticación basada en MSISDN y PIN.

Seguridad

La transición de la información entre el móvil y los participantes debe estar lo suficientemente cifrada para evitar el acceso de terceros a esta información. Por otro lado, los negocios deben estar protegidos contra fraudes garantizando el correcto pago por el bien, servicio o contenido que prestaron. La autenticación debe ser lo suficientemente robusta para evitar que la identidad de las personas o los negocios pueda ser imitada.

Valor para todos los participantes

Todos los participantes en el modelo de negocio deben percibir valor: entidades financieras, operadores móviles, proveedores de tecnología, comercios y usuarios. Se ha encontrado gran valor para cada uno de los participantes exceptuando los comercios. Estos son vitales para la aceptación de la solución y se debe minimizar el impacto que exista en la infraestructura existente (muchos comercios cuentan actualmente con por lo menos un POS).

Mantener procesos independientes

Los procesos de cada participante se deben mantener independientes. Las entidades financieras y los comercios no deben realizar acuerdos con los operadores ni depender de ellos para prestar el servicio.

Escalabilidad

Se deben poder implementar otros servicios financieros y la solución debe permitir diferentes métodos de pago. Por otro lado, debe soportar diferentes

14

modelos de negocio como interoperabilidad entre bancos o intermediarios privados.

Promoción de marcas

Las marcas deben ser visibles para el usuario permitiendo que exista la competencia natural en el negocio y que los diferentes participantes puedan presentar la solución como valor agregado para sus usuarios.

Requerimientos técnicos

Tecnologías abiertas y estándares

Se deben utilizar tecnologías abiertas para evitar la inversión de grandes sumas de dinero y la interoperabilidad entre bancos, operadores y móviles. Por otro lado se debe intentar utilizar y/o adaptar los servicios electrónicos y tecnologías existentes como EMV, ISO-858312, etc. para las entidades bancarias y SMS, WAP, etc. para los usuarios.

Independencia tecnológica

Las soluciones en tecnología deben ser independientes entre bancos, operadores, móviles y comercios aunque todas deben estar soportadas bajo los mismos protocolos.

Seguridad

Comprende la autenticación del usuario, del comercio, la autorización del usuario para realizar la transacción y la integridad de la información. La solución debe garantizar los tres conceptos y debe proponer diferentes alternativas en cada uno de ellos.

ANALISIS DE TECNOLOGIAS Java™ 2 Platform, Micro Edition (J2ME)

J2ME provee un ambiente de desarrollo robusto y flexible para aplicaciones que se ejecutan en dispositivos de consumo como móviles, PDA´s, teléfonos, etc. Igual que J2EE13, J2SE y JavaCard, J2ME cuenta con su propia máquina virtual y una serie de API´s estándar definidos en el Java Community Process14 (JPC). Aunque J2ME comprende un gran rango de configuraciones y perfiles según las capacidades de los dispositivos, esta sección asume que se utilizarán móviles con la configuración CLDC y el perfil MIDP15. El objetivo es analizar las ventajas de desventajas de utilizar J2ME como aplicación cliente en la solución de transacciones móviles. Iniciaremos con un ejemplo de cómo

12 Para más información, ver http://www.iso.ch/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=15871 13 Java 2 Platform, Enterprise Edition. Para más información, ver http://java.sun.com/j2ee/index.jsp 14 Para más información, ver http://jcp.org/en/home/index 15 CLDC: Connected Limited Device Configuration. MIDP: Mobile Information Device Profile. Para más información, consultar http://searchmobilecomputing.techtarget.com/sDefinition/0,290660,sid40_gci511735,00.html. Recuperado el 5 de Febrero de 2005.

15

se realizaría una transacción utilizando J2ME y analizaremos los requerimientos más importantes.

Ejemplo: realizar un pago

Este ejemplo enumera la secuencia de eventos que suceden en el escenario donde un usuario va a pagar por un bien, servicio o contenido remota o localmente con su móvil utilizando J2ME.

1. El usuario inicia la aplicación J2ME. 2. Se inicia una sesión inalámbrica entre las partes. Puede ser iniciada por el

usuario (en caso de transferencias y pagos) o por el comercio (en caso de pagos).

3. El usuario selecciona el método de pago (tarjeta de crédito, billetera virtual, etc.).

4. La aplicación solicita la autenticación del usuario que puede ser a través de una identificación y un PIN o un certificado en la aplicación o SIM.

5. La aplicación solicita la confirmación del usuario y la transacción es realizada.

Independientemente de quien inicie la sesión, el usuario debe ejecutar la aplicación J2ME y seleccionar el pago a realizar o esperar un mensaje (SMS/WAP Push16) que inicia la transacción. Esto se debe a que la especificación no soporta un método de ejecución automático de la aplicación. Ahora analizaremos los requerimientos más importantes aplicados a J2ME.

Facilidad de uso

Este requerimiento comprende la facilidad en la descarga de la aplicación y la ejecución de la transacción. Existen diferentes formas para instalar la aplicación aunque la más conveniente es enviar un mensaje (SMS/WAP Push) al móvil del usuario para que descargue e instale la aplicación. El mensaje puede contener parámetros específicos de modo que el servidor personalice el JAD e incluya información adicional del usuario y la llave privada o el certificado digital. La facilidad de uso en el momento de la transacción es el factor más importante para el usuario. Los MIDlets17, a diferencia de SMS, proveen una avanzada interfaz gráfica que brinda una ventaja evidente siempre y cuando la navegación sea sencilla, rápida e intuitiva. Sin embargo, J2ME presenta un problema: independientemente de quién inicie la transacción, el usuario deberá ejecutar la aplicación manualmente. La especificación no soporta la ejecución automática de las aplicaciones. Adicionalmente, MIDP 1.0 no soporta WMA y no es viable incluir la librería ya que su funcionamiento depende del móvil. Con MIDP 2.0 esta limitante no existe.

16 Consiste de un mensaje SMS que contiene un URL para acceder directamente a ella. Para más información, ver http://www.ihub.com/WAP%20Push.htm 17 Aplicaciones diseñadas para correr en dispositivos móviles como celulares o PDA’s.

16

Costo

El único costo adicional en el que incurriría el usuario sería el tiempo al aire al descargar la aplicación y al realizar la transacción. Este tiempo es mucho menor que en WAP y en muchos casos puede llegar a ser más económico que SMS dependiendo del número de mensajes que se deban intercambiar. Por otro lado, los precios en los planes de datos de los operadores cada vez son menores y se espera que continúen bajando.

Seguridad

La solución debe proveer comunicación segura desde el móvil al servidor transaccional para toda información confidencial que se deba transmitir. Debe implementar mecanismos de autenticación o verificación para identificar al usuario.

Criptografía

MIDP 1.0 no provee librerías oficiales de criptografía, sin embargo existe el JSR 177 (Java Specification Request 177) – Security and Trusted Services for J2ME (SATSA) que fue incluido en MIDP 2.0 aunque se puede incluir opcionalmente en MIDP 1.0. El objetivo de SATSA es incluir una serie de librerías que proveen servicios de seguridad y confianza integrando un elemento de seguridad (ES) en el móvil. Un ES es un componente en el dispositivo J2ME que provee los siguientes beneficios:

− Almacenamiento seguro para proteger información sensible como la llave privada del usuario, llave pública, certificados digitales, información personal, información de autenticación, etc.

− Operaciones criptográficas para soportar protocolos de pagos, integridad y confidencialidad de la información.

− Un ambiente de ejecución seguro para implementar características de seguridad adicionales. Las aplicaciones J2ME se pueden utilizar estas características para implementar servicios de valor: autenticación y autorización, servicios bancarios, pagos, etc.

Por otro lado, Sun Microsystems adicionó soporte no oficial para HTTPS 18(kssl) como parte de la RI (Reference Implementation) de MIDP 1.0.3. Esto no es obligatorio en los dispositivos pero si los manufacturadores lo implementan, en teoría debería funcionar. En MIDP 2.0 el soporte para HTTPS es obligatorio utilizando alguna de las siguientes especificaciones: HTTP sobre TLS, SSL v3, WTLS o TLS.

18 Versión segura del protocolo HTTP. El sistema HTTPS utiliza un cifrado basado en las Secure Socket Layers (SSL) para crear un canal cifrado (cuyo nivel de cifrado depende del servidor remoto y del navegador utilizado por el cliente) más apropiado para el tráfico de información sensible que el protocolo HTTP.

Es utilizado principalmente por entidades bancarias, tiendas en línea, y cualquier tipo de servicio que requiera el envío de datos personales o contraseñas.

El puerto estándar para este protocolo es el 443. Recuperado el 5 de Febrero de 2005, de http://es.wikipedia.org/wiki/HTTPS

17

Existe una iniciativa llamada Bouncy Castle que provee una librería de criptografía para dispositivos J2ME. Es una adaptación de JCA (Java Cryptography Architechture) y JCE (Java Cryptography Extenssion) para configuraciones CDC y CLDC de J2ME. Provee las siguientes herramientas:

- Los motores de criptografía más aceptados (DES, TripleDES; RSA, etc). - Los motores de generación de valores de HASH (MD5 y SHA-1). - Soporte para generación de MAC (Message Authentication Code). - Soporte para la generación e intercambio de llaves (RSA, Diffie-Helman,

etc). - Soporte para la escritura y lectura de certificados digitales (x509, X.9.62,

PKCS#12, etc).

Autenticación

Existen diversas formas de autenticación que se pueden implementar en J2ME. La más recomendable es la utilización del PIN, La información adicional del usuario que se requiera para la autenticación puede estar contenida en la aplicación que se descarga. Otra forma de lograr la autenticación es utilizando verificación y las facilidades de almacenamiento de J2ME. Se mantiene la llave privada para firmar digitalmente cualquier información que se envíe. Por otro lado, el MIDlet también podría proveer servicios de verificación utilizando la llave pública de la entidad.

Interoperabilidad

Debido a la diversidad de móviles que existen en el mercado, la interoperabilidad es un requerimiento fundamental para el sistema de transacciones móviles. J2ME tiene la ventaja que cuenta con una máquina virtual que, independientemente del sistema operativo del móvil, garantiza la ejecución de la aplicación. Sin embargo, si el móvil no soporta J2ME evidentemente la aplicación no funcionará. Desafortunadamente, muy pocos móviles soportan J2ME (cerca del 15%), aunque esta cifra va en ascenso. En cuanto a la comunicación, MIDP soporta conexiones HTTP 1.1 sobre TCP/IP o cualquier pila de protocolos como WAP, i-Mode, etc. MIDP 2.0 soporta la librería de mensajería llamada Wireless Messaging API (WMA) que permite enviar y recibir mensajes utilizando SMS o Cell Broadcast Service (CBS) en redes GSM. La librería se puede incluir en móviles que soportan MIDP 1.0 aunque su funcionamiento depende de las capacidades del móvil. Existen liberías para Bluetooth, Infrarrojo y Wifi aunque su funcionamiento depende de las capacidades del móvil y las características de la librería. Ninguna es requerida en la especificación.

Rendimiento

J2ME, en comparación con WAP, presenta un alto rendimiento ya que las aplicaciones se ejecutan en el móvil evitando el acceso continuo e ineficiente con el

18

servidor y reduciendo las necesidades de ancho de banda ya que la única información que se transmite son los datos. Los procesos que requieren criptografía podrían deteriorar el rendimiento aunque se han realizado pruebas que demuestran que el tiempo necesario es imperceptible para el usuario.

Análisis

Las ventajas más importantes de J2ME son:

− La interfaz gráfica que facilita la interacción con el usuario. − Alto rendimiento a nivel de comunicación y procesamiento ya que reduce el

intercambio de información con el servidor. − La capacidad propia de almacenamiento permite implementar sistemas de

seguridad y criptografía avanzados. − Las aplicaciones funcionan en cualquier móvil que soporte J2ME. − Java es una tecnología altamente aceptada.

Las desventajas son:

− La aplicación y sus actualizaciones se deben descargar al móvil. Este proceso puede ser engorroso para el usuario.

− El inicio de la transacción y el establecimiento de la sesión con el comercio o la contraparte no es sencillo ya que no existe un método eficiente para enviar información al móvil. Se debe complementar con otras tecnologías como SMS.

− La aceptación de la tecnología aun no es total, de hecho, la mayoría de móviles no soportan J2ME.

SMS (Short Message Service)

SMS es un servicio prestado por todos los operadores de telefonía móvil que permite la transmisión de mensajes de texto simples compuestos de máximo 160 caracteres sobre una plataforma de ancho de banda reducido desde y hacia dispositivos inalámbricos. Utiliza un SMSC (Short Message Service Center) que actúa como un sistema de almacenamiento y enrutamiento de los mensajes para garantizar la entrega de los mismos a través de la red móvil del operador. Al igual que con otras tecnologías que estamos analizando, iniciaremos con un ejemplo de cómo se realizaría una transacción utilizando SMS y después analizaremos los requerimientos más importantes sobre la tecnología. Ejemplo: realizar un pago

Este ejemplo describe el escenario en el cual una persona va a pagar en un comercio por un bien, servicio o contenido con su móvil utilizando SMS.

1. El comercio inicia la transacción identificando al móvil e ingresando el valor

que el usuario debe pagar. La identificación del móvil puede variar ampliamente. Se puede utilizar código de barras, el MSISDN, etc.

19

2. El usuario recibe un mensaje en su móvil con las características del pago: establecimiento, valor a pagar, etc. Adicionalmente en el mensaje se le pide devolver el PIN.

3. El usuario responde el mensaje ingresando su PIN para confirmar la transacción.

4. La transacción es realizada y tanto el comercio como el usuario reciben una confirmación.

Para facilidad en el sistema, el usuario deberá seleccionar previamente el método de pago que desea utilizar cuando haga transacciones con su móvil. Esto se puede hacer directamente en la entidad bancaria o a través de una interfaz WEB.

Facilidad de uso

Como se puede ver en el ejemplo, realizar un pago es un proceso muy simple para el usuario. Sin embargo este proceso se hace más complicado cuando el usuario inicia alguna operación transaccional debido a los comandos que debe ingresar en el mensaje para que el servidor transaccional entienda la operación. Por ejemplo, cuando el usuario desee transferir dinero a otra persona deberá ingresar la identificación del tercero (por ejemplo su MSISDN) y el monto a transferir. Esta operación se podría ver reflejada en el siguiente comando: 3158546598 15000 3158546598 MSISDN del tercero. 15000 valor a transferir. Este tipo de comandos podría ser dificultar la aceptación por parte de los usuarios aunque su impacto se puede reducir con campañas que muestren como realizar cada transacción.

Costo

El único costo adicional en el que incurriría el usuario utilizando SMS son los mensajes que se intercambien que podrían ser de 3 a 6 dependiendo del tipo de la transacción. Sin embargo, también existe la opción de que la entidad financiera asuma los costos de los mensajes ya que muy probablemente se los cobre al usuario en su cuota de manejo.

Seguridad

La seguridad en SMS comprende la transmisión segura de la información entre el móvil y el servidor transaccional, la autenticación y el ocultamiento de la información confidencial del usuario en el móvil y el operador.

Criptografía

SMS utiliza las redes GSM o CMDA como medio de transporte entre los móviles y el SMSC. El riesgo de que la información sea interceptada por terceros es mínima debido a la dificultad de decodificar la información en este tipo de redes.

20

Adicionalmente, la comunicación entre el operador y el servidor transaccional se puede hacer utilizando un canal seguro o VPN.

Autenticación

Cuando un usuario conduce una transacción a través de SMS deberá autenticarse para completarla. Aunque la autenticación se podría hacer utilizando un certificado digital o alguna otra forma de verificación, lo más común será utilizar un PIN, que en conjunto con el MSISDN proporcionarán las credenciales necesarias para autenticar al usuario. El problema de este método es que el mensaje puede quedar guardado en el móvil y en caso de que sea robado, esta información podría estar disponible a terceros que únicamente podrían realizar las transacciones desde el móvil del verdadero usuario ya que simular ser otro móvil no es soportado por SMS. Por otro lado existe un riesgo asociado a los operadores ya que los mensajes quedan guardados en los registros del SMSC19. Existen varios métodos para solucionar estos problemas que pueden ser utilizados conjuntamente. Adicionalmente, la plataforma transaccional deberá restringir la cantidad de dinero que se puede gastar en un determinado lapso de tiempo para evitar grandes fraudes. PIN parcial

La idea es que la plataforma transaccional solicite al usuario en el mensaje parte de su PIN indicando el ingreso de ciertos dígitos de forma aleatoria. Por ejemplo, “por favor ingrese los dígitos 1, 3 y 5”. Cada vez los dígitos requeridos cambiarían. Esto ocultaría parte del PIN y haría más difícil su descubrimiento a terceros. Sobrescribiendo el “mensaje de solicitud” Una vez que el usuario ingresa su PIN recibirá una confirmación de la plataforma transaccional notificándolo del éxito o fracaso de la transacción. Este mensaje de notificación se puede configurar para que sobrescriba el mensaje de solicitud del PIN que se envío anteriormente ocultando los dígitos que se solicitaron al ingreso. Nota: esta característica es opcional del móvil / SIM y no siempre está disponible. Sin embargo, se encuentra en la mayoría de móviles modernos. En caso de que el móvil sea robado será mucho más difícil para el tercero descubrir la combinación correcta del PIN y adicionalmente, la plataforma transaccional podría deshabilitar la cuenta después de un número determinado de ingresos incorrectos.

19 SMS Center: Nodo de los operadores encargado del envío y recepción de todos los mensajes de textos que pasan por su red

21

USSD

Una solución muy efectiva es el uso de GSM USSD como método de interacción con el usuario. USSD 20(Unstructured Supplementary Service Data) es un canal de datos disponible en las redes de los operadores que permite iniciar sesiones con un servidor USSD y provee un mecanismo de “request - response” basado en mensajes que es mucho más efectivo que SMS ya que efectivamente establece una sesión con el usuario. La desventaja potencial de esta solución es que el operador de telefonía móvil deberá soportar la tecnología. Aplicaciones USSD se han implementando con gran éxito en países como Japón pero en Colombia esta tecnología no está aun disponible.

WAP Push / SMS

WAP Push se puede emplear como mecanismo de autenticación. El usuario interactuaría con el sistema por medio de SMS pero en el momento de la autenticación se establecería una sesión WAP Push para solicitar el PIN. La ventaja de este método es que no se deja rastro en el móvil ya que se utiliza WAP como método de comunicación. Sin embargo, existe la desventaja que el servicio estaría limitado a móviles que soporten WAP Push y no sería tan interoperable como SMS.

Interoperabilidad

Debido a la diversidad de móviles que existen actualmente en el mercado, la interoperabilidad es un requerimiento fundamental para el sistema de transacciones móviles. SMS tiene la ventaja que es soportado por todos los operadores y por el 99% de los móviles actualmente en el mercado.

Rendimiento

SMS es un sistema de comunicación muy eficiente aunque depende del SMSC y del servidor transaccional. A diferencia de J2ME, donde parte del procesamiento se puede hacer en el móvil, SMS es únicamente un canal de comunicación y todo el procesamiento se debe hacer en el servidor aumentando la carga del mismo. Hasta hace poco en Colombia los operadores no mantenían una buena calidad del servicio en sus SMSC ya que estaban totalmente concentrados en los servicios de voz. Sin embargo, con la llegada de los servicios interactivos a través de SMS, los operadores se han visto obligados a mejorar sus servidores y prestar un mejor servicio.

Análisis

Las ventajas más importantes de SMS son:

- Todos los operadores lo soportan.

20 Tecnología similar a SMS. Usado en Mobipay (Ver soluciones existentes en el mundo de este documento para más información).

22

- El 99% de los móviles lo soportan. - El impacto de la tecnología es muy bajo ya que SMS es un servicio

altamente aceptado. - El establecimiento de la sesión entre las partes (usuarios y comercios) es

muy sencillo ya que SMS es un medio eficaz de comunicación con los móviles.


- Existe un mayor riesgo en la seguridad a menos de que se utilicen medios alternativos que limitan la utilización del servicio.

- La interfaz no es fácil de manejar en ciertos escenarios como transferencias de fondos.

- El valor de cada mensaje es alto aunque los precios tienden a bajar. SAT (Sim Application Toolkit)

Cualquier móvil GSM o UMTS funciona utilizando una tarjeta inteligente llamada SIM con las siguientes características:

• Provee un ambiente seguro para almacenar información confidencial. • Administra la información necesaria para identificarse y autenticarse con el

operador. • Almacena números celulares y mensajes de texto. • Facilita los servicios de “roaming”. • Habilita servicios de valor agregado y comercio móvil. • La interfaz entre la SIM y los móviles está estandarizada.

SAT es un estándar que permite implementar servicios de valor agregado y financieros en móviles GSM extendiendo la funcionalidad de la SIM. Es una tecnología emergente aunque con gran potencial. Su arquitectura incorpora servicios de seguridad que brindan una excelente plataforma para servicios transaccionales. Desafortunadamente las implementaciones de SAT no están estandarizadas entre los proveedores de tarjetas y las aplicaciones no son portables. Adicionalmente, la tarjeta tiene memoria limitada que normalmente oscila entre 16k y 32k.

Al igual que con otras tecnologías que estamos analizando, iniciaremos con un ejemplo de cómo se realizaría una transacción utilizando SAT y después analizaremos los requerimientos más importantes para esta tecnología.


Este ejemplo describe el escenario en el cual una persona va a pagar en un comercio por un bien, servicio o contenido con su móvil utilizando SAT.

1. El comercio inicia la transacción identificando el móvil e ingresando el valor

que el usuario debe pagar. La identificación del móvil puede variar ampliamente. Se puede utilizar código de barras, el MSISDN, etc.

2. La aplicación SAT se inicia automáticamente y le muestra al usuario las características de pago: establecimiento, valor a pagar, etc. Adicionalmente le solicita al usuario el método de pago.

23

3. El usuario ingresa el método de pago y su PIN. 4. La transacción es finalizada y un mensaje de confirmación es enviado tanto

al usuario como al establecimiento.

SMS se utiliza como método de transmisión de la información entre los móviles y el servidor transaccional. La ventaja de SAT respecto a SMS es la seguridad que implementa y la facilidad de uso para el usuario en el momento de la transacción.

Facilidad de uso

Teniendo en cuenta que SAT es una aplicación que se instala en el móvil, este requerimiento se debe dividir en dos aspectos fundamentales: la descarga de la aplicación (o actualizaciones) y la ejecución de la transacción. Existen diferentes alternativas para instalar SAT en los móviles aunque la más conveniente y la única que se puede implementar de forma remota es a través de SMS o CBS. Adicionalmente, la aplicación podría estar instalada cuando el usuario compra el móvil aunque esto requiere de un acuerdo entre el proveedor de la solución y los operadores celulares. La facilidad de uso en el momento de realizar la transacción es uno de los aspectos más importantes para el usuario. Entre todas las tecnologías analizadas, SAT tiene la mayor ventaja ya que utiliza SMS como medio de transmisión pero mejora la interacción del usuario con el servidor transaccional utilizando una interfaz gráfica con características similares a WAP. A diferencia de J2ME, donde el usuario debe iniciar la aplicación manualmente, la aplicación SAT se inicia automáticamente con la llegada del mensaje.

Costo

El único costo adicional en el que incurriría el usuario utilizando SAT son los mensajes SMS que se intercambien. Podrían ser de 3 a 6 dependiendo del tipo de la transacción. Sin embargo, también existe la opción de que la entidad financiera asuma los costos de los mensajes ya que muy probablemente se los cobre al usuario en su cuota de manejo.

Seguridad

SAT soluciona algunos problemas de seguridad que puede existir en WAP utilizando la tarjeta SIM. La información en la tarjeta está protegida de accesos no autorizados y de posibles cambios permitiendo que las aplicaciones se ejecuten en un ambiente seguro. Por otro lado, el estándar SAT provee mecanismos para garantizar la confiabilidad y la integridad de la información por medio del PIN y algoritmos criptográficos. Criptografía

SAT soporta diferentes estándares criptográficos incluyendo triple DES. El proveedor del servicio instala la llave criptográfica antes de entregar el móvil al

24

usuario garantizando que la llave nunca se transmitirá por la red. La integridad de la información se hace utilizando SHA o MDS 521. Cada mensaje que viaja por la red es dividido en paquetes individualmente codificados utilizando encabezados de seguridad. La especificación de seguridad está a cargo de la organización 3GPP en el documento TS 03.48 y queda fuera del alcance de este documento. Existen variaciones en la implementación de cada proveedor de tarjetas y las aplicaciones también pueden adicionar elementos de seguridad adicionales no estandarizados. La siguiente figura tomada de la especificación muestra el sistema de seguridad utilizado en SAT.

SendingApplication

SendingEntity

TransportMech.

ReceivingEntity

ReceivingApplication

Secu

rity

Secu

rity

Information flow

(e.g. a bank) (e.g. SMS-SC) (e.g. USSD, SMS) (e.g. SIM)

(e.g. SIMresidentapplication)

(e.g. SIMresidentapplication)

(e.g. SIM) (e.g. SMS-SC) (e.g. a bankresidentapplication)

22

Autenticación

Existen diversas formas de autenticación que se pueden implementar en SAT. La más recomendable es la utilización del PIN que junto al MSISDN o certificado digital proporcionarán las credenciales necesarias para autenticar al usuario.

Interoperabilidad

Hasta el momento SAT provee las mayores ventajas respecto a otras tecnologías analizadas. Sin embargo, SAT es una tecnología emergente y por lo tanto no está completamente estandarizada entre los proveedores de tarjetas. Esto implica que la aplicación que se escriba para un proveedor no será compatible en las tarjetas de otro proveedor.

21 Algoritmos de cifrado que generan una llave para verificar integridad. 22 Diagrama recuperado el 20 de Agosto de 2005, de http://www.langamers.it/ttt/ing/avvenuti/m-commerceSecurity.pdf

25

Por otro lado, SAT depende de las redes GSM y actualmente en Colombia también contamos con una red CMDA 2000 proveída por Movistar aunque es muy probable que esta compañía migre su plataforma a GSM.

Rendimiento

SAT, así como J2ME, provee un alto rendimiento ya que las aplicaciones se ejecutan en el móvil evitando el acceso continuo e ineficiente con el servidor. Sin embargo, la transmisión de información entre los móviles y el servidor transaccional se hace utilizando SMS que aunque es un método muy eficiente depende de el SMSC y el servidor transaccional.

Análisis

Las ventajas más importantes de SAT son:

• El diseño de SAT provee un gran componente de seguridad ideal para las

operaciones transaccionales. • Provee una interfaz gráfica que facilita la interacción con el usuario. • Se utiliza SMS como método de transmisión de datos. • A diferencia de J2ME, las aplicaciones se pueden ejecutar con la llegada de

un mensaje lo que facilita el inicio de la sesión entre el móvil y el servidor transaccional.


• Es una tecnología emergente y las aplicaciones no son portables entre

tarjetas de diferentes proveedores. • La utilización del PIN del celular y el PIN que deberá ingresar en el sistema

transaccional puede ser confuso para el usuario. • Únicamente existe soporte para redes GSM. • Existe una estrecha relación entre el proveedor de la solución y los

operadores. • La memoria de la SIM es limitada y normalmente oscila entre 16k y 32k.

VoiceXML e IVR

VoiceXML permite que personas comunes y corrientes accedan a Internet desde cualquier teléfono, solo marcando un número. La interacción del usuario con la aplicación web es por medio del habla, la cual no esta limitada para reconocer determinadas frases sino que el usuario puede hablar normalmente. IVR funciona de manera similar a VXML solo que es mucho mas limitado. Con IVR, el usuario esta limitado a interactuar únicamente con los botones numéricos del teléfono. Cabe notar, que todo lo que se pueda hacer con IVR, también se puede hacer con VXML.

26

Para que una aplicación VXML sea puesta en producción, es necesario montarla en una plataforma especializada. Existen varios proveedores de esta plataforma, como lo son VOXEO23, INTERVOICE, VOICEGENIE, VOXPILOT, etc. El objetivo es analizar las ventajas y desventajas de utilizar VXML como tecnología en la solución de transacciones móviles. Iniciaremos con un ejemplo de cómo se realizaría una transacción utilizando VXML y analizaremos los requerimientos más importantes.


Este ejemplo enumera la secuencia de eventos que suceden en el escenario donde un usuario va a pagar por un bien, servicio o contenido remota o localmente con su móvil utilizando VXML.

1. El usuario decide realizar la compra 2. El establecimiento inicia la transacción con el número del móvil del

usuario. 3. El usuario recibe una llamada telefónica a su móvil de la aplicación. 4. La aplicación solicita la autenticación del usuario que puede ser a través

de una contraseña hablada o un PIN numérico. 5. La aplicación valida la información del usuario y se realiza la transacción.

En este ejemplo, también sería válido que el usuario iniciara la transacción haciendo la llamada directamente él, pero sería necesario entonces introducir algún código o identificación del establecimiento. Tal como esta en el ejemplo, la transacción tendría un costo adicional que sería la llamada echa al móvil. Ahora analizaremos los requerimientos más importantes aplicados a VXML.

Facilidad de uso

Este requerimiento comprende la facilidad del uso de la aplicación una vez iniciada la transacción. Este requerimiento es muy importante ya que el usuario no cuenta con ningún tipo de interfaz visual para guiarse mejor. La facilidad de uso de esta tecnología depende de que tan clara es la explicación dada al usuario y la duración de la llamada, entre mas corta y menos tenga que hacer el usuario, mejor. Tiene una gran ventaja sobre SMS, J2ME, WAP, etc. y es que debido a que el IVR existe hace mucho tiempo, es mucho más natural para las personas interactuar de esta forma con su teléfono. Sin embargo, VXML presenta un problema. Es posible que hayan personas a las que se les dificulte más la pronunciación correcta de las palabras para que estas puedan ser reconocidas por el traductor.

23 Para más información acerca de esta plataforma, ver http://www.voxeo.com/

27

Costo

Es evidente que esta es la solución más barata posible ya que el único gasto en el que incurriría el usuario (Si es que es él quien inicia la transacción), sería una llamada telefónica que duraría muy pocos minutos. El valor de esta llamada dependería de las entidades bancarias y del integrador. Si comparamos este costo con el costo de una solución echa en WAP por ejemplo, la diferencia es enorme.

Seguridad PLATAFORMA Este aspecto de seguridad es un poco delicado ya que depende básicamente de la plataforma donde este puesta la aplicación. Entonces a continuación se analizará la seguridad de una plataforma específica. Se tomará como ejemplo la plataforma de VOXEO. Primero que todo, hay que tener en cuenta que la plataforma VOXEO provee una interfaz al cliente por medio de una llamada telefónica. Cada llamada representa una instancia única (similar al comportamiento de un browser web). Para cada instancia, se pueden configurar “cookies” o manejar sesiones agregándole parámetros al URL. Además, la plataforma VOXEO asigna un único ID de sesión a cada llamada. A continuación, un ejemplo de cómo seria el manejo de sesiones de una manera segura: http://www.myphoneapp.com/app.jsp? session.callerid=14075551212&session.calledid=18005558888&session.sessio nid=a7b4f6g3d912de9ba0c9d6a3b...24 Una vez el manejo de sesiones este listo, es posible añadir otra seguridad adicional, por medio de un PIN, para controlar el acceso a la aplicación. Lo más aconsejable, es manejar ambas seguridades, la de manejo de sesiones y la autenticación por PIN. En VoiceXML y CallXML, cada sesión SSL es también única a la instancia del browser del que fue iniciada. Lo mismo ocurre en CCXML. Adicionalmente a SSL, VOXEO también soporta conectividad a través de IPSEC VPN. En esta capa, la información no maneja seguridad por medio de sesiones, por lo cual es recomendable combinarla con cifrado de sesiones para un mayor grado de seguridad. Interoperabilidad

24 Recuperado el 3 de Septiembre de 2005, de http://www.vxml.org/frame.jsp?page=security.htm

28

Debido a la diversidad de móviles que existen en el mercado, la interoperabilidad es un requerimiento fundamental para el sistema de transacciones móviles. VXML tiene la ventaja que es compatible con el 100% de los teléfonos móviles. Esta es la ventaja más grande que tiene VXML.

Rendimiento

El rendimiento depende de la plataforma en la que se monte la aplicación. En teoría, si la plataforma es robusta, la solución debería funcionar muy bien. Un problema es que como los comandos del usuario son hablados, es posible que a veces el sistema no reconozca el comando de voz del usuario y a este le toque repetirlo al menos unas 2 veces. Además, la información que recibe el usuario de la aplicación es hablada, lo que hace que sea un poco demorado el proceso. En términos generales, el rendimiento es bueno siempre y cuando se tenga una plataforma robusta. Con VOXEO por ejemplo, no habría problema.

Análisis

Las ventajas más importantes de VXML son:

− Alto rendimiento a nivel de comunicación y procesamiento de la información que viaja entre cliente y servidor. El tráfico de VOZ es muy liviano.

− Provee alto nivel de seguridad. − Las aplicaciones funcionan en cualquier móvil. − Es muy sencillo de usar. − Para la mayoría de la gente, es una tecnología mucho más natural que SMS,

J2ME y WAP. − El inicio de la transacción es muy simple. Sólo consiste en una llamada

telefónica.

Las desventajas son: − No existe interfaz gráfica. − El reconocimiento de voz puede fallar y volverse tedioso para el usuario

final. Wireless Application Protocol (WAP)

WAP es una especificación de un conjunto de protocolos de comunicación con el fin de estandarizar la forma en que dispositivos móviles se conecten a Internet. En el pasado, el acceso a Internet se limitaba a los computadores, pero con este nuevo protocolo (WAP), es posible acceder a Internet desde un teléfono celular. Los operadores celulares brindan esta posibilidad de acceso a Internet desde sus redes hace algunos años en Colombia. Las redes GPRS y CDMA de datos brindan velocidades cercanas a los 140 kbps lo cual es bastante rápido. Si lo comparamos con el acceso telefónico, este vendría siendo unas 4 veces más rápido.

29

WAP nació gracias a las siguientes compañías: Ericsson, Motorola, Nokia, y Unwired Planet (ahora Phone.com). El Wireless Markup Language (WML) es usado para crear páginas que pueden ser vistas a través de WAP. El objetivo es analizar las ventajas y desventajas de utilizar WAP como interfaz en la solución de transacciones móviles. Iniciaremos con un ejemplo de cómo se realizaría una transacción utilizando WAP y analizaremos los requerimientos más importantes.

Ejemplo: Consulta de saldo

Este ejemplo enumera la secuencia de eventos que suceden en el escenario donde un usuario va a consultar el saldo de su cuenta bancaria de cualquier entidad. Para este ejemplo, asumiremos que el usuario tiene contratado un plan de datos con su operador celular.

1. El usuario inicia sesión WAP en su teléfono celular. 2. El usuario debe ingresar al portal WAP donde realizará la consulta. 3. El usuario ingresa su nombre de usuario y contraseña con el fin de

autenticarse. 4. Ya el usuario tiene acceso a su información bancaria. 5. Ahora el usuario solo debe seleccionar la cuenta para que le despliegue

su saldo. También se puede tener acceso a otros servicios tales como transferencias bancarias, eso depende de la aplicación.

En este ejemplo, el cliente es responsable de iniciar la consulta ya que es un requerimiento que él esta solicitando. Ahora analizaremos los requerimientos más importantes aplicados a WAP.

Facilidad de uso

Este requerimiento comprende la facilidad en el uso del teléfono celular mediante el cual se esta accediendo a la página a través de WAP. La facilidad de uso en el momento de la transacción es el factor más importante para el usuario. Las paginas WML, a diferencia de SMS, proveen una avanzada interfaz gráfica que brinda una ventaja evidente siempre y cuando la navegación sea sencilla, rápida e intuitiva. WAP provee una ventaja sobre J2ME, y es que sin que el usuario inicie una sesión, esta se puede iniciar automáticamente usando WAP PUSH. WAP PUSH es básicamente el envío de un mensaje SMS con una dirección de Internet para que el usuario ingrese. Esta ventaja se hace evidente al momento de hacer una compra, donde el usuario no tiene que ingresar a ningún portal sino que por medio de WAP PUSH se le indica que debe hacer y todo se hace más simple. El problema con este requerimiento es que solo el 5% de los teléfonos celulares en Colombia tienen acceso a WAP entonces la mayoría de la gente desconoce como funciona este servicio.

30

Costo

El costo de esta implementación a través de WAP puede llegar a ser costoso ya que a diferencia de J2ME, con WAP no existe nada corriendo en el celular y todo debe ser traído a través de Internet. El precio promedio de los operadores en Colombia, por KB transmitido es de 15 pesos. Por otro lado, los operadores brindan planes de datos donde el KB sale más económico. La parte buena de esto es que los precios de datos son cada vez más baratos y se espera que continúen bajando.

Seguridad

La solución debe proveer comunicación segura desde el móvil al servidor transaccional para toda información confidencial que se deba transmitir. Debe implementar mecanismos de autenticación o verificación para identificar al usuario. SSL Y WTLS Secure Sockets Layer (SSL) es usado en Internet masivamente y también puede aplicarse al ambiente WAP. SSL es usado únicamente entre el servidor web y el “Gateway” WAP. Entre el “Gateway” WAP y el dispositivo móvil se usa otro protocolo llamado Wireless Transaction Layer Security (WTLS). WTLS es especializado para ambientes inalámbricos. SSL no es compatible directamente con WTLS, entonces el “Gateway” debe descifrar la información que viene en SSl para luego volverla a cifrar usando WTLS y así podérsela pasar al dispositivo móvil. Por lo tanto, al interior del “Gateway”, la información queda desprotegida. El siguiente diagrama muestra el modelo antes mencionado: | | [WAP device]------------[WAP gateway]-----------[Content server] <---WTLS--->{unprotected}<---SLL---> | | (Firewall) | | (Firewall)25 Con base al modelo anterior, se puede ver que la información es segura en todo momento menos en el Gateway WAP. Los operadores celulares son los dueños de este Gateway y por ende ellos serian los responsables de cualquier manipulación de la información que pase por su Gateway. Por otro lado, los operadores celulares pueden ser victimas a ataques que podrían comprometer la información dentro del Gateway. A continuación, se ve un modelo que brinda seguridad desde ambos extremos de la transacción (Movil – Servidor):

25 Recuperado el 4 de Septiembre de 2005, de http://www.123wapinfo.com/faqs/security/Default.asp?4

31

| | [WAP device]------------------------------------["WAP server" (acting as WAP gateway)] <---------------WTLS---------------> | | (Firewall) | | (Firewall)26

El problema con este modelo es que el Gateway ya no hace parte del operador celular y si el usuario requiere de algún otro servicio que no sea simulado por el servidor, seria necesario una reconfiguracion en su teléfono celular. En algunos modelos de teléfonos esta configuración es sencilla, pero en otros es muy complicada. El problema ya esta resuelto pero sería mejor si se pudiera hacer de otra forma. Una solucion alternativa seria la siguiente: "Passthrough mode" | | [WAP device]------------[WAP gateway]-----------["WAP server"] <---------------WTLS---------------> | | (Firewall) | | (Firewall)27 Con este modelo, el Gateway solo tendría que pasar la información de un lado al otro sin modificarla. Esto NO esta implementado todavía pero sería la solución óptima. Autenticación

La forma más simple de autenticación en WAP es con un nombre de usuario y contraseña. Con el modelo anterior esta forma de autenticación no tendría problema ya que la información viajaría siempre cifrada.

Interoperabilidad

Debido a la diversidad de móviles que existen en el mercado, la interoperabilidad es un requerimiento fundamental para el sistema de transacciones móviles. WAP tiene la ventaja de que funciona independientemente del sistema operativo del dispositivo móvil. Sin embargo, si el móvil no soporta WAP o el cliente no tiene servicio de datos activado, evidentemente tendrá acceso a la aplicación transaccional. Desafortunadamente, sólo el 5% de los móviles en el mercado soportan WAP y muy pocos usuarios lo saben utilizar.



32

En cuanto al contenido de las páginas WML, es necesario que sean soportadas por el 100% de los teléfonos celulares con WAP. Por experiencias vividas, sabemos que esto es complicado de lograr porque los simuladores WAP son muy distintos al comportamiento real de un teléfono celular.

Rendimiento

El rendimiento depende básicamente de la velocidad de navegación que ofrezca el operador celular. En Colombia, Comcel acaba de montar la tecnología EDGE la cual brinda un ancho de banda de 140 kbps, Movistar cuenta con CDMA que brinda un ancho de banda de 153 kbps y OLA tiene GPRS que brinda un ancho de banda de 54 kbps. Con estas velocidades se puede trabajar sin problema para realizar transacciones pero sigue siendo mucho mas lento que a través de SMS o usando J2ME. El problema de usar WAP reside en que toda la información debe viajar y se hace muy pesado, lo cual afecta directamente al rendimiento de la solución. Los procesos que requieren criptografía podrían deteriorar el rendimiento auque esta es la forma en la que se debe hacer y no se puede modificar.

Análisis

Las ventajas más importantes de WAP son:

− La interfaz gráfica que facilita la interacción con el usuario. − WAP PUSH facilita el inicio de una transacción automáticamente. − Las aplicaciones funcionan en cualquier móvil que soporte WAP.

Las desventajas son: − Todo el contenido viaja a través de Internet y compromete el rendimiento. − El inicio de la transacción y el establecimiento de la sesión con el comercio o

la contraparte no es sencillo ya que no existe un método eficiente para enviar información al móvil. Se debe complementar con otras tecnologías como SMS.

− La aceptación de la tecnología aun no es total, de hecho, la mayoría de móviles no soportan WAP.

− La cultura colombiana no esta adaptada al uso de WAP.

SOLUCIONES YA EXISTENTES EN EL MUNDO

A continuación, se expondrá un caso exitoso de la implementación de una solución de pagos móviles en España. El sistema se llama Mobipay 28y es la solución pionera a nivel mundial de este tipo de transacciones. Su inicio fue a mediados del año 2002. Mobipay es un sistema de pagos a través del móvil promovido de forma conjunta por la mayor parte de las entidades financieras españolas, las tres compañías de

28 Sistema implementado en España. Para más información, ver http://www.mobipay.es

33

telefonía móvil y los procesadores de medios de pago financieros. Actualmente, Mobipay tiene convenios con más de 92 entidades financieras. El sistema Mobipay esta integrado y promovido por Mobipay España SA, sociedad en la que participan como accionistas, en un 48% del capital social, hasta un total de 92 entidades financieras; los tres operadores de telefonía móvil de España: Amena, Vodafone y Movistar. A través de este medio, es posible que cualquier persona con un teléfono celular, consulte saldos, realice transferencia de fondos, haga pagos en establecimientos públicos, taxis, parqueaderos, etc. En la actualidad, todos los celulares son vendidos con el sistema listo de manera que sea solo decisión del usuario activarlo con su entidad financiera. Este sistema funciona como una billetera virtual, es decir, las personas inscriben unas tarjetas débito o crédito y de estas sacan plata que es abonada a su billetera virtual. Incluso, es posible cargar la billetera virtual desde el celular. Como funciona El funcionamiento de este sistema es algo complejo ya que NO cuenta con ningún tipo de interfaz. El usuario debe iniciar cualquier tipo de requerimiento con un código asociado. Esto puede resultar tedioso en un principio, pero estadísticas muestran que una vez el usuario memoriza los códigos más frecuentes, el uso es muy sencillo. Ejemplo: A continuación se muestra como seria la consulta del saldo.

• El usuario ingresa en su móvil: *148*1# [SEND] • El usuario ingresa su NIP: ****** [SEND] • El usuario recibe de vuelta un mensaje SMS con la información de su saldo.

Como se mencionó anteriormente, existen diversos códigos para realizar todo tipo de pagos, como parqueaderos, maquinas dispensadoras, taxis, etc. Seguridad La seguridad de este sistema esta basada en el NIP del usuario. Mobipay garantiza que sin este numero de identificación personal, es imposible que haya fraude en una transacción. En caso que el usuario pierda o le sea hurtado su móvil, no existe riesgo debido a que toda transacción requiere del NIP. Además, si se bloquea el servicio del celular, este quedará totalmente inservible para hacer cualquier llamada, lo que de antemano descarta cualquier posibilidad de uso de Mobipay. Ventajas

• Fácil de usar • Permite realizar cualquier tipo de compra que se pueda hacer con tarjeta

débito o crédito. • Es muy cómodo de usar. • Es gratis. • Está basado en tecnología de mensajes (utilizando tecnología USSD) y por

tanto es más evolucionado que otros sistemas como VXML y SMS.

34

• USSD brinda una muy alta cobertura. • Tiempo de respuesta: Tiempo real

Desventajas

• USSD solo soporta redes GSM • No permite realizar transacciones de alto volumen de dinero • Alta curva de aprendizaje.

En conclusión, es alentador ver que un sistema tan completo y tan complejo sea sencillo de utilizar y tenga gran acogida en un país como España. Evidentemente, esto no significa que esta solución sea trasladable a Colombia, pero si es una esperanza de que acá se puede implementar algo parecido y tiene gran futuro.

INFRAESTRUCTURA BANCARIA EN COLOMBIA

Es necesario investigar un poco sobre como es la red bancaria en Colombia para poder analizar posibles implementaciones en nuestro país. Es vital conocer como funcionan las transacciones actualmente para poder analizar un sistema de pagos móviles viable en Colombia. Para conocer un poco más a fondo de este tema, nos reunimos con la persona encargada de la parte transaccional de una de las entidades financieras más grandes de Colombia. 29 En términos generales, los bancos colombianos están interconectados por una “red de redes”. En Colombia existen dos redes que interconectan bancos y que a su vez están interconectadas entre sí, estas son REDEBAN y ASCREDIBANCO. Por su puesto, para transacciones Internacionales, estas redes están conectadas con otras redes a nivel mundial. Existe otra red en Colombia que comunica algunos bancos pero no maneja ningún establecimiento. ATH es otra red que cumple funciones similares a REDEBAN pero sin manejar compras o pagos en establecimientos. ATH es la red que tiene la información de las facturas de los servicios públicos. Estas bases de datos son las que se consultan para cualquier pago electrónico de servicios públicos. En este documento, vamos a enfocarnos en las transacciones nacionales únicamente, ya que la idea es plantear una solución móvil viable en Colombia. A continuación, se ilustra como los bancos están interconectados a través de REDEBAN o ASCREDIBANCO. Cada transacción, sin importar su tipo, necesariamente pasa por REDEBAN, a menos que sea una transferencia de fondos entre cuentas de la misma entidad.

29 Director de Tarjetas de crédito de dicha entidad

35

Veamos como serían algunas transacciones: 1. Compra en un establecimiento nacional.

Cuando el usuario se acerca a una tienda y va a pagar con su tarjeta débito, esta pasa por un datafono, el cual se conecta (a través de REDEBAN) a la entidad bancaria donde el cliente tiene su cuenta. Esta comunicación entre REDEBAN y la entidad bancaria se hace a través de una conexión BASE24. Cuando la transacción es aprobada, al cliente se le debita de su cuenta el monto de la transacción y se le acredita al establecimiento. Existen casos donde puede que la transacción se interrumpa por fallas de conexión o porque el banco se encuentra fuera de línea. Pero estos casos están bajo control gracias a los planes de contingencia con los que se cuentan. Al final de cada día, existe un proceso de sincronización en el cual se verifican las transacciones del día y se valida que las que no hayan sido exitosas se rectifiquen para que el usuario no sea cobrado dos veces o para que al usuario no se le cobre algo que no compró. En este ejemplo, la entidad bancaria es la misma autorizadora de la transacción.

2. Pago servicios públicos por Internet

El usuario ingresa al portal Web de su entidad bancaria y se autentica mediante un “login” y una contraseña. Una vez adentro, se supone que toda la información enviada desde su computador hacia Internet esta cifrada por motivos de seguridad. Cuando el usuario consulta el valor de su factura, lo que en realidad esta haciendo es conectándose con ATH (via TCP/IP) y consultando en su base de datos el estado de su factura.

REDEBAN

36

Una vez hecho esto, el usuario puede pagarla. Cuando el usuario decide pagar su factura, ATH se conecta con REDEBAN y ejecuta el pago.

3. Recarga de tarjetas prepago a celulares

Actualmente, existe un convenio entre algunos operadores móviles y algunos bancos lo cual le permite a los usuarios recargar su celular prepago debitando directamente de su cuenta de ahorros o corriente. Este convenio entre operador y banco se maneja de una forma establecida por ellos donde REDEBAN o ninguna otra red interviene en la transacción.

En la actualidad, se esta trabajando para que TODAS las conexiones entre REDEBAN, los bancos y entidades autorizadoras como Mastercard sea a través de TCP/IP. Algunos podrían pensar que este protocolo es muy inseguro para manejar transacciones bancarias pero la verdad es que la seguridad de esto esta en el cifrado de los datos. Cada banco cuenta con unas cajas (HW físico) que se encargan de cifrar los datos a un nivel de seguridad demasiado alto y prácticamente imposible de descifrar. Todas estas regulaciones de seguridad están especificadas en la circular 002 de 1998 expedida por la Superintendencia Bancaria.

POSIBLE SOLUCION EN COLOMBIA – MOBILE BANKING

Ya se ha analizado una serie de factores decisivos que nos permiten lanzar una propuesta a una posible implementación de una solución móvil en el mercado Colombiano. Con el análisis hecho de la infraestructura Colombiana, es claro que la solución debe implementarla una red como REDEBAN y no solo unos pocos bancos. La idea es que la solución este disponible a nivel nacional y con cubrimiento del 100% de las entidades bancarias. Antes de proponer una solución que consideramos viable, vamos a recopilar los factores más importantes a tener en cuenta: 1. Colombia es un país que a penas esta despegando en cuanto a la penetración

de celulares. 2. El costo de la transacción debe ser muy bajo o gratis. 3. Debe ser muy fácil de usar debido a que la cultura colombiana en cuanto a

celulares lo exige. 4. Debe ser MUY seguro. 5. La solución debe ser soportada por la mayoría de los teléfonos móviles del

mercado.

37

Considerando estos requerimientos, y tomando en cuenta el análisis hecho de cada una de las tecnologías antes mencionadas (SMS, WAP, J2ME, VXML, etc), se concluye que la tecnología SMS es la candidata inicial perfecta para esta solución. La aplicación que se desarrollará consiste en una aplicación que desarrollaría un banco para manejar cuentas prepagadas de usuarios y cuentas de establecimientos. Brinda interfaz Web tanto para el administrador del sistema del banco como para cada establecimiento. Las personas naturales podrán realizar transferencias a otros usuarios del sistema y podrán consultar su saldo.

MODELO DE NEGOCIO

Introducción

Los teléfonos móviles llegaron a Colombia hace pocos años y han venido creciendo a un ritmo impresionante. La penetración del celular ya supera el 20% y se espera que siga creciendo en los próximos años. Hoy en día, los celulares ofrecen una serie de servicios de valor agregado muy interesantes que han venido cogiendo fuerza en el mercado Colombiano. El caso de la mensajería de texto es un excelente ejemplo para ilustrar este progreso. En algunos países Europeos, la tecnología en cuanto a redes celulares esta un poco más avanzada que en Colombia, aunque es evidente que hacia allá estamos apuntando. Estos países han desarrollado unas soluciones muy interesantes en cuanto a pagos móviles usando el celular como medio. El éxito de estos proyectos hacen de esta posibilidad una idea muy atractiva para el mercado Colombiano. Esta idea de pagos y transacciones a través de dispositivos móviles (el celular en este caso), requiere de un cambio cultural que lleva algún tiempo mientras la gente le toma confianza al nuevo sistema. Vale la pena aclarar que este sistema NO pretende sustituir NINGÚN otro, sino que se presenta como una solución más a la hora de realizar una transacción. Dicho lo anterior, veamos un poco más a fondo en que consiste este nuevo sistema, cuales son sus ventajas y desventajas, que implicaciones tiene su implementación en Colombia y una aproximación a los costos que tendría tanto para el usuario, como para el banco y los administradores del sistema.

Modelo actual con tarjetas de crédito y débito

En la actualidad, el modelo de las compras con tarjetas débito o crédito funciona de la siguiente manera:

38

El modelo funciona igual para compras con tarjeta débito y crédito. Para el caso de las tarjetas de crédito, el banco emisor asigna un cupo a sus clientes y les entrega el plástico. Una vez la persona tiene su tarjeta, el proceso de compra es muy sencillo para el, pero toda la infraestructura que está detrás es bastante compleja. Existen 2 redes principales en Colombia, una es REDEBAN y la otra es ASCREDIBANCO. Estas redes interconectan todos los bancos y permite realizar transacciones entre ellos. Los establecimientos deben estar afiliados a la red para poder realizar recaudos a través de esta. Este proceso de afiliación se hace a través de un banco quien será el encargado de recibir los recaudos del establecimiento. Una vez se tenga esto, se procede a pedir un código único para el establecimiento. Este código lo expide Incocrédito y es necesario para poder dar inicio al servicio. Ahora veamos como es el proceso de una compra desde el momento en que se pasa el plástico por el datafono hasta que el establecimiento recibe el pago por parte del banco con el que tiene el convenio de recaudo: Cuando una persona se dirige a un establecimiento a realizar una compra, este pasa su tarjeta al cajero. La tarjeta es pasada por un datafono el cual se conecta, a través de la red, al banco emisor para verificar si tiene cupo disponible para hacer la compra. Una vez se autoriza la compra del cliente, se realiza una transacción que consiste en lo siguiente: El banco adquirente genera un cobro al banco emisor por el valor de la compra. A su vez, el banco adquirente abona a la cuenta del establecimiento el valor de la compra. Finalmente, el banco emisor, genera una cuenta por cobrar al cliente.

Modelo con sistema SMS

Establecimiento Datafono Red

Banco adquirente Banco emisor

39

Una vez visto como es el sistema de pagos con plástico en Colombia, veamos una nueva alternativa que complementaría el sistema actual, introduciendo una nueva forma de pago a través del teléfono móvil de las personas. El modelo propuesto es el siguiente:

Este modelo es muy distinto al de las tarjetas débito y crédito por varias razones que las veremos a continuación. Primero que todo, hay que aclarar que este sistema no va a dar crédito a ninguna persona, es decir, la persona tiene que tener plata en una cuenta para poder realizar compras; esto con el fin de evitar el problema de cartera. El sistema transaccional que se ve en la figura anterior, es el que se propone implementar y será el encargado del flujo de información entre el la persona que desea comprar, el banco y el establecimiento. Los administradores de ese sistema, necesitarían realizar convenios con establecimientos y bancos.

El proceso que se debe seguir para poder realizar una compra es el siguiente: 1. La persona interesada en el servicio, debe crear una cuenta en nuestro sistema transaccional. 2. Se debe abonar plata a la cuenta creada en nuestro sistema a través de un sistema de recaudo del banco. (Internet, Consignación, Tarjeta de crédito, etc.). 3. Dirigirse a un establecimiento que tenga convenio con nuestro sistema transaccional SMS. 4. Dar su número celular al momento de pagar. 5. El establecimiento debe ingresar los datos de la compra en un computador con Internet, el cual se conectará con el sistema transaccional y dará inicio a la transacción. 6. El cliente recibirá un mensaje de texto con los datos de la compra que va a realizar.

Establecimiento PC con InternetSistema transaccional

Banco adquirente

Operador celular

40

7. El cliente debe confirmar con una contraseña la compra, a través de un mensaje SMS. 8. La compra se debita de la cuenta prepagada del cliente. Se acredita al establecimiento el valor de la compra a una cuenta de un banco. A diferencia del sistema transaccional con tarjetas débito y crédito, este, no permite la interconexión entre varios bancos. Transacciones entre usuarios del sistema. El sistema transaccional SMS, permitirá que personas afiliadas a este, realicen transacciones entre sí. Es decir, un padre podrá transferirle fondos a la cuenta de su hijo a través de un mensaje de texto.

Enfoque del nicho de mercado El mercado al que este sistema le apunta son aquellos establecimientos que no tienen datafono y sólo reciben efectivo en pagos. Evidentemente, aquellos establecimientos que tengan datafonos, también podrán adquirir este sistema de pagos que funcione de manera paralela con el que tengan actualmente. También está dirigido a las personas que no tienen tarjetas ni débito ni crédito; o personas que por algún motivo tengan problemas de cartera y no tengan crédito con ningún banco. Hay muchos jóvenes menores de 20 años que NO cuentan con tarjetas ni débito ni crédito pero si con celular. Nuestro sistema brinda la posibilidad a estas personas de realizar pagos con su celular así no tengan efectivo en el bolsillo. Es importante ver que la única infraestructura necesaria para trabajar con este sistema, es un PC con Internet y una afiliación con los administradores. Esto hace que sea muy sencillo adquirir el sistema, por lo que potencialmente, cualquier establecimiento podría adquirirlo. Existe otro mercado objetivo muy importante y es el de las máquinas dispensadoras, ya que hay mucha gente que no puede comprar en estas por no tener monedas en su bolsillo. Estas máquinas requerirían de una adaptación al nuevo sistema y conexión a Internet.

Costos estimados

Veamos ahora, una comparación de costos entre el sistema con tarjetas débito y crédito y el sistema propuesto. COSTOS PARA EL ESTABLECIMIENTO

41

Tarjeta débito Tarjeta crédito

Sistema SMS

Costo afiliación 120.000 - 350000

120.000 - 350.000

50.000

Costo por transacción

2% - 3% 3.15% - 6.8% 3%

Mensualidad 0 0 0* Tabla basada en valores estimados, estos varían dependiendo del banco.

COSTOS PARA LA PERSONA NATURAL Tarjeta débito Tarjeta

crédito Sistema SMS

Costo afiliación 0 0 0Costo por transacción

0 0 250

Mensualidad 2.500 – 5.000 10.000 – 15.000

0

* Tabla basada en valores estimados, estos varían dependiendo del banco.

Con las tablas anteriores, podemos ver que el sistema SMS es mucho más barato tanto para el establecimiento como para la persona natural. Una persona, en promedio realiza unas 4 compras con su tarjeta débito o crédito. Si realizara las mismas compras usando el sistema SMS, le costaría 4 X 250 = 1.000 pesos. Obviamente, el sistema SMS es mucho más limitado que una tarjeta ya que la ventaja principal de la tarjeta es que se puede sacar plata de un cajero.

Conclusiones

Veamos ahora conclusiones importantes tras haber hecho el análisis anterior. Primero que todo, es importante ratificar que el sistema transaccional SMS NO pretende bajo ninguna circunstancia reemplazar o montarle competencia al sistema de tarjetas débito y crédito. Ambos sistemas prestan el mismo servicio básico que es el poder realizar una compra usando un medio alterno al efectivo, pero los modelo de negocio de estos sistemas son muy distintos, y en lugar de competir, serían una forma de auto complementarse. Es muy importante tener en cuenta que el sistema SMS requiere de una aceptación cultural que es difícil de adquirir debido a las costumbre de las personas. Una persona esta acostumbrada a usar su celular como artefacto de comunicación únicamente.

42

Para que alguien llegue a realizar una compra con su celular, primero debe entender como funciona el sistema y debe tenerle confianza, ya que los temas monetarios siempre generan prevención por parte de la gente. Como antecedente alentador, veamos Internet. En un principio, la gente desconfiaba de los pagos a través de este medio, pero con el tiempo la gente se va acostumbrando. Este medio ha cogido mucha fuerza y hoy en día se realizan muchas transacciones. Sin embargo, se considera viable el proyecto debido a los bajos costos en los que incurriría tanto el establecimiento como el cliente.

Análisis y descripción casos de uso

Actores: Establecimiento, Persona y Administrador Transaccional Requerimientos funcionales. ESTABLECIMIENTO El establecimiento cuenta con un usuario y una contraseña para ingresar al sistema. Habrá una persona encargada de manejar el sistema y esta será la responsable de su uso.

Persona Sistema transaccional

Banco adquirente

Operador celular

Establecimiento PC con Internet

43

1. Iniciar Compra Al momento de realizar una venta, un establecimiento debe iniciar la transacción. Para esto, es necesario pedirle al cliente su número celular e ingresarlo al sistema. Este dato es lo único que se necesita para dar inicio a la transacción. En este momento, se envía un mensaje de texto al cliente con todos los datos de la compra. 2. Cancelar compra Si por alguna razón, el cliente se arrepiente de la compra, antes de que esta termine, el establecimiento deberá cancelarla independientemente de la etapa en la que se encuentre. 3. Deshacer Compra Si por alguna razón, el cliente se arrepiente de haber hecho la compra y decide devolver la mercancía comprada, el establecimiento debe estar en capacidad de recibirla y deshacer la transacción, abonándole al cliente lo descontado y descontándole al establecimiento lo abonado. PERSONA La persona es cualquier persona natural que tenga un celular de cualquier operador. Además la persona debe adquirir el servicio con el banco, quien será el administrador del sistema transaccional.

44

1. Aceptar compra Después de haber dado su número celular al establecimiento, la persona recibirá un mensaje de texto con la descripción y el valor total de su compra. Este debe devolver el mensaje de texto con una clave personal indicando que acepta la transacción. En este momento, se le descontará el valor de la compra al cliente y se le acreditará a la cuenta del establecimiento. 2. Rechazar compra Después de haber dado su número celular al establecimiento, la persona recibirá un mensaje de texto con la descripción y el valor total de su compra. Si la persona desea rechazar la compra porque están mal los datos o por la razón que sea, debe devolver un mensaje de texto con la palabra NO o simplemente no enviar su clave, eventualmente la compra se cancelará. 3. Realizar transferencia a otra persona Una persona puede hacer una transferencia a otra persona que también esté afiliado al servicio. Para hacerlo, debe mandar un mensaje de texto con el número celular de la persona a la que desea enviarle los fondos, seguido del valor (sin ningún símbolo distinto a números). Luego ambas personas recibirán un mensaje de confirmación o negación. 4. Deshacer transferencia hecha Si por alguna razón, la persona se da cuenta que cometió un error en la transferencia, esta tendrá 10 minutos para deshacerla desde su celular mandando un mensaje de texto con la palabra “UNDO”. Esto deshace la última transferencia hecha. Si desea deshacer otras transferencias o si se le cumple el tiempo de espera la persona debe acercarse al administrador transaccional para que sea éste quien la deshaga. 5. Consulta de saldo En cualquier momento, un usuario registrado podrá consultar su saldo enviando la palabra “BALANCE” como mensaje de texto. De regresó recibirá un mensaje con lo solicitado. ADMINISTRADOR TRANSACCIONAL El administrador transaccional es una persona del banco que adquirió la solución de pagos móviles. Esta persona es responsable del manejo tanto del sistema como de

45

los movimientos hechos internamente en las cuentas de sus clientes al momento de modificar saldos en ambas partes.

1. Crear cuenta personal Al crear una cuenta, se ingresan todos los datos personales de la persona que se está inscribiendo. Así mismo, se debe ingresar un valor que será el saldo disponible para realizar compras y transferencias. Por esta razón, al momento de asignar un saldo, el banco debe descontar el mismo montó de la cuenta (del banco) o de la tarjeta de crédito de su cliente. 2. Crear cuenta corporativa Cada vez que un establecimiento firma contrato con el banco para implementar el sistema en su tienda o negocio, se debe crear una cuenta a donde se le abonará la plata que reciba por las ventas hechas por este medio. Se ingresan todos los datos de la empresa al sistema y se genera una contraseña para el ingreso al sistema por parte del establecimiento. 3. Modificar cuenta

a. Personal Se modifican los datos personales del cliente. El cambio más importante es si por alguna razón, el cliente cambia de operador celular. Este cambio, será transparente para el cliente.

b. Corporativa Se modifican los datos del establecimiento.

c. Saldo Al modificar el saldo, se puede incrementar disminuir. En caso de aumentarlo, el banco debe descontar el mismo montó de la cuenta (del banco) o de la tarjeta de crédito de su cliente. Si el cliente decide reducir su saldo, el banco deberá abonar a la cuenta (del banco) del cliente el mismo monto. El saldo de una cuenta corporativa se modifica en el momento que se hace el pago. En este momento se le consigna al establecimiento el monto de su saldo y en el sistema transaccional, el saldo vuelve a cero.

4. Eliminar cuenta personal

46

Al eliminar una cuenta, toda la información del cliente desaparece del sistema. De igual forma, el banco debe acreditarle a la cuenta (del banco) del cliente el saldo que tenía a su favor. 5. Eliminar cuenta corporativa Al eliminar una cuenta corporativa, toda la información del establecimiento desaparece del sistema. El banco deberá cancelar el saldo pendiente al establecimiento. 6. Suspender cuenta personal Si un cliente desea suspender temporalmente el servicio, deberá contactarse con el administrador del sistema transaccional para realizar la suspensión. Si al cliente le roban su celular, deberá suspender su cuenta para evitar posibles fraudes. 7. Deshacer compra Una compra que no pueda ser deshecha por el establecimiento deberá ser deshecha por el administrador del sistema transaccional. Al deshacer la compra, al cliente se le acreditará el valor de la compra y al establecimiento se le descontará el mismo valor. Diseño de la aplicación Ver la documentación incluida en el CD para el diagrama de la lógica de la aplicación. Ver la documentación incluida en el CD para el diagrama del diseño de la base de datos. Para el código fuente y JavaDoc de la aplicación, referirse al CD anexo a esta tesis. Aspectos críticos de la aplicación La aplicación consiste de un sistema transaccional básico que tiene implementadas las propiedades básicas de seguridad. Por parte del operador, la red de este brinda un medio seguro de transmisión de datos desde el móvil hasta la central del operador. El medio de transmisión de datos entre el operador y la aplicación pasa por medio de una empresa integradora colombiana (élibom Technologies Ltda.)30 la cual me ofreció una conexión gratuita para efectos de esta investigación. Esta empresa tiene conexión con todos los operadores pero para efectos de esta tesis, la aplicación trabaja solamente con Movistar. Una vez élibom recibe el mensaje del operador, lo envía mediante un HTTP GET a la aplicación. La misma manera de comunicación se emplea en la otra vía (es decir, para enviar el mensaje al móvil). Élibom asignó una cuenta temporal durante un año que permite el envío y recepción de mensajes a través de Movistar para realizar pruebas en este proyecto.

30 http://www.elibom.com -> Empresa Colombiana fundada en Agosto de 2003 para proveer servicios corporativos de mensajería de texto. Los dueños de esta empresa somos cuatro estudiantes de Ingeniería de Sistemas de la Universidad de los Andes: Juan José Otero, Gerardo Aristizabal, Nicolas Acosta y Germán Escobar.

47

El sistema transaccional de la aplicación esta montado en una base de datos MySQL la cual implementa las propiedades ACID para asegurar la integridad de la información.

Atomicidad

Una transacción o bien se confirma o se anula. Si se confirma una transacción, permanecen todos sus efectos. Si se anula, se deshacen todos sus efectos. Por ejemplo, al cambiar el nombre de un objeto se crea el nuevo nombre y se elimina el anterior (confirmación) o no cambia nada (anulación).

Coherencia

Una transacción es una transformación correcta del estado del sistema. Mantiene las constantes de estado. Por ejemplo, al agregar un elemento a una lista doblemente vinculada, se actualizan los cuatro punteros hacia delante y hacia atrás.

Aislamiento (Isolation)

Las transacciones simultáneas se aíslan de las actualizaciones de otras transacciones incompletas. Estas actualizaciones no constituyen un estado coherente. Esta propiedad se denomina con frecuencia serializabilidad. Por ejemplo, una segunda transacción que recorre la lista doblemente vinculada mencionada anteriormente en el ejemplo de coherencia verá la lista antes o después de la inserción, pero sólo verá los cambios completados.

Durabilidad

Una vez que se confirma una transacción, sus efectos continuarán aunque haya errores en el sistema. Por ejemplo, después del cambio de nombre en el ejemplo de atomicidad, el objeto tendrá el nuevo nombre incluso aunque se produzca un error en el sistema y se reinicie justo después de que se complete la confirmación.31 Conclusiones de la aplicación Una vez finalizada la aplicación, se puede concluir que un sistema transaccional es demasiado complejo y requiere de mucho desarrollo y sobre todo publicidad. Las entidades bancarias serían las personas adecuadas para realizar este desarrollo y se debe notar que la oportunidad de negocio consiste en brindarle a las entidades financieras el canal de comunicación, en este caso la conexión con los operadores móviles a través de SMS. La implementación realizada no pretende bajo ninguna circunstancia ser una aplicación comercial. Su propósito, el cual es ampliamente logrado, es mostrar un ambiente real de cómo funcionaría el sistema si fuera implementado de forma comercial.

31 Tomado de Microsoft TechNet Latinoamérica. Recuperado el 15 de Noviembre de 2005, de http://www.microsoft.com/latam/technet/articulos/200005/art22/

48

Para una aplicación de este tipo, es evidente que los requerimientos no funcionales son muchísimo más importante que los funcionales. CONCLUSIONES GENERALES

Tras haber analizado una serie de aspectos, se llega a la conclusión que una solución móvil en Colombia es una gran oportunidad de negocio siempre y cuando se haga de una forma adecuada. Colombia es un país que se encuentra en pleno crecimiento de líneas móviles y esto hace que sea el momento indicado para incursionar en este mercado. Dadas las condiciones culturales, donde las personas tienen la mentalidad del celular únicamente como herramienta telefónica, es necesario ingresar al mercado con una aplicación muy simple que vaya generando confianza en las personas poco a poco. Como se explico anteriormente, la tecnología que mejor se adapta para el lanzamiento de una solución móvil, es SMS. Sin embargo, VXML sería la segundo mejor opción por su sencillez de uso para el usuario. Hay que ser concientes que el SMS esta creciendo a grandes escalas y esta sería sin duda, la tecnología que se presta para iniciar un proyecto de este tipo. Tecnologías como WAP y J2ME no se ven muy viables debido a su complejidad y escasez de móviles que las soportan. WAP es una tecnología que hace unos años fue lanzada sin mucho éxito pero que ha venido cogiendo fuerza poco a poco. Esta tecnología la vemos como una opción viable para una solución móvil a mediano plazo. J2ME si esta algo lejos de ser una tecnología viable para la implementación de una solución móvil transaccional. Esta tecnología presenta muchos inconvenientes que no parecen tener solución. Es muy alentador ver como soluciones de este estilo han sido implementadas en otros países de manera exitosa. Esto sin duda, muestra que el futuro de los pagos móviles en Colombia esta muy cerca. Con respecto a la infraestructura colombiana, es evidente que es muy viable la implementación de una solución de pagos móviles debido a que existen redes que ya interconectan los bancos y esto hace que sea más fácil centralizar la aplicación.

49

BIBLIOGRAFIA [1] Wikipedia, la enciclopedia libre. http://es.wikipedia.org/ [2] WhatIs.com. http://www.whatis.com [3] Entrevistas a: 32

• Efraín Otero, Presidente. Banco de Occidente.

• Maria Inés Uribe, Gerente de soporte de operaciones. Banco de Occidente

• Roberto Bojacá, Gerente de tarjetas de crédito. Banco de Occidente.

• Ángela María Gaviria, Directora de canales. Banco de Occidente.

• Rodolfo Vélez, Vicepresidente de tecnología. Banco AVVillas Bibliografía J2ME

[4] Java 2 Platform. Recuperado de http://java.sun.com/j2me/

[5] Datasheet: Java™ 2 Platform, Micro Edition. Recuperado el 4 de Febrero de 2005,

de http://java.sun.com/j2me/j2me-ds.pdf

[6] C. Anders, IT University of Copenhagen, (2002) Analysis of J2ME™ for developing

Mobile Payment Systems. Recuperado el 10 de Febrero de 2005, de

http://www.microjava.com/articles/techtalk/mpayment?content_id=3734

[7] Security and Trust Services API v 1.0 (JSR-177). Recuperado el 10 de Febrero de

2005, de http://developers.sun.com/techtopics/mobility/apis/articles/satsa2/

[8] Mobile Information Device Profile (MIDP) v 1.0 (JSR-37). Recuperado el 11 de

Febrero de 2005, de http://java.sun.com/products/midp/index.jsp

Bibliografía SMS

[9] The International Engineering Consortium: SMS. Recuperado de

http://www.iec.org/

[10] Network 365: SMS Transaction Security. Recuperado de

32 Estas entrevistas fueron realizadas en Septiembre de 2005 y sirvieron como base para la elaboración del modelo de negocio del prototipo Mobile Banking

50

http://www.network365.com

[11] Elibom Technologies Ltda. Entrevista con socios :

• Nicolás Acosta Amador

• Gerardo Aristizabal Peraza

• Germán David Escobar Cardoso

Bibliografía SAT

[12] S., Nambiar, C. Lu, & R. Lily. Analysis of Payment Transaction Security in Mobile

Commerce. Recuperado el 20 de Agosto de 2005, de

http://www.langamers.it/ttt/ing/avvenuti/m-commerceSecurity.pdf

[13] Interoperable SIM Application Management: Copenhagen Business Seminar Slide

Presentation – Septiembre 14 de 2004. Recuperado de

http://list.3gpp.org/scripts/wa.exe?A2=ind0408&L=scp_technical&T=0&F=&S=

&P=2709

[14] Partners in Payment Strategic: Gemplus / Valista. Artículo anónimo, recuperado

el 15 de Septiembre de 2005, de

http://www.gemplus.com/press/archives/2004/telecom/04-05-2004-

Valista.html

[15] GSM Technical specification 11.14. (1996) Recuperado el 15 de Septiembre de

2005, de http://www.ttfn.net/techno/smartcards/GSM11-14V5-2-0.pdf

[16] Implementation Guidelines for Mobile Payments: European Committee for Banking

Standards. (2005). Recuperado el 20 de Septiembre de 2005, de

http://www.ecbs.org/Download/ig606%20v1.pdf

[17] K. Markus. Mobile Payments: Helsinki University of Technology. Recuperado

el 5 de Octubre de 2005, de http://www.tml.tkk.fi/Opinnot/T-

109.551/2005/reports/Mobile_payments.doc

51

[18] C. Joseph L. Secure, Open and Interoperable Mobile Payments – One step

closer to a wireless future. Recuperado el 5 de Octubre de 2005, de

http://bbriefings.com/download.cfm?fileID=694

[19] An introduction to JavaCard Technology in SIM Cards: Gemplus white paper.

Recuperado el 10 de Octubre de 2005, de

http://www.gemplus.com/techno/opencard/whitepapers/ctst2000/paper/

Bibliografía WAP

[20] How secure is WAP with SSL and WTLS? Recuperado el 26 de Octubre de 2005,

de http://www.123wapinfo.com/faqs/security/Default.asp?4

[21] Comcel anuncia Internet de alta velocidad desde el celular. (2005) Recuperado

el 5 de Noviembre de 2005, de http://enter.terra.com.co/ente_secc/

ente_actu/noticias/ARTICULO-WEB-1001940-2049787.html

[22] Manual de WAP, WML. Recuperado el 5 de Noviembre de 2005, de

http://www.webestilo.com/wml/

Bibliografía VXML

[23] VoiceXML Forum. Recuperado de http://www.voicexml.org

[24] IVR Hosting / IVR Platforms / IVR Development. Recuperado de

http://www.voxeo.com

SISTEMA TRANSACCIONAL DE PAGOS Y TRANSFERENCIAS …

Documents

Transcript of SISTEMA TRANSACCIONAL DE PAGOS Y TRANSFERENCIAS …