1. Histórico del documento.

2. Objetivo

Presentar las prestaciones que se deben prever para disponibilizar el producto tarjetas prepagas Cabal. Estas prestaciones deben ser implementadas permitiendo administrar las tarjetas prepagas en forma segura y ágil en las tablas del Ceibo, sin interferir con las tarjetas de crédito, y que los datos puedan ser consumidos por aplicaciones externas, tanto por una web de Cabal como por otras  aplicaciones (Dimo), tanto para gestión del usuario como para transaccionar con la tarjeta.

Comentario adicional: esta sería la propuesta que tiene como contraparte la opción de modificar el Acceso Cabal para ajustar a visualizar y prever excepciones en los procesos actuales. Esta propuesta se presenta con un diseño de métodos y procedimientos que podrán ser reutilizados desde un webservice. La propuesta es que se deberá contar con las interfaces necesarias para la administración dentro de la procesadora, la autogestión del usuario, y los métodos para que otras aplicaciones puedan interactuar (emitir, transaccionar) con este segmento de tarjetas.

Beneficios adicionales:

•   Suprimir las gestiones y procedimientos manuales auxiliares para la emisión de las tarjetas, que hoy se realiza con las tarjetas de beneficios
•   La emisión de estas tarjetas en forma independiente a las entidades, en corte separado
•   Utilizar el core de Ceibo para autorización sin que impacte en el proceso actual de TC
•   Contar con sus propios microservicios (¿) sin afectar a los procesos actuales

3. Definiciones del producto (definiciones de reglas)

En este apartado se dejan anotadas: las definiciones del producto, las consideraciones para la emisión de una tarjeta prepaga, las funcionalidades transaccionales y de gestión básicas a cubrir, y las consideraciones para la compensación cuando sea interna o con emisores distintos a Cabal.

3.1.                   Sobre el emisor

a)     El emisor a definir para las tarjetas prepagas es independiente a los emisores que hoy emiten tarjetas de crédito. Es un emisor de Cabal (805) y maneja un indicador de emisor pre-pago.

b)     No hay impedimento de manejar varios emisores, con la consideración de que todos entran con el procesador CABAL (805), siendo posible habilitar emisores que emitan tarjetas prepagas para otra entidad.

c)      Los bines deberán ser gestionados en forma independiente a los bines de tarjeta de crédito hoy en uso. Es un bin Cabal y puede ser distinto para cada emisor de prepaga. Sin embargo el proceso actual puede compartir un bin, por ej. de la 120, y cuida la numeración otorgada.

d)     Se anota que una tarjeta prepaga debe poder ser consultada en MiCabal, ej. tarjeta prepaga de comercios. Se anota que una tarjeta prepaga Dimo puede ser consultada exclusivamente por Dimo.

e)     Para cada emisor se dispone de los reportes de monetaria diaria donde se puede controlar contra el cuadro de procesos, el movimiento de los usuarios.

3.2.                     Sobre la tarjeta prepaga: generación y renovación

Las tarjetas prepagas deben poder ser generadas con las siguientes consideraciones:

a)     Pueden emitirse tarjetas:

• relacionadas a un documento, con nombre del usuario
• sin nombre, preemitidas

b)     El alta de una tarjeta prepaga relacionada al documento del usuario  genera una cuenta, y la primera tarjeta para el usuario, la tarjeta virtual.

c)      El alta de una tarjeta prepaga preemitida se genera en una cuenta general no operativa. Se emite sin nombre y sin pin. Se generaría por lotes.

d)     Para el uso de las tarjetas preemitidas, se debe relacionar al usuario identificado por su documento a su cuenta. Si no tiene cuenta, se registra y genera con su documento la nueva cuenta indicando los datos de la tarjeta física, ej. número de tarjeta, cvv, vencimiento.

e)     Un usuario, identificado por su documento, una misma persona, puede tener varias tarjetas prepago en su cuenta, todas con su documento, en un mismo emisor prepago.

f)       Se puede indicar una cantidad máxima de tarjetas por cuenta en el emisor prepago. Esto es parametrizable.

g)     No se habilita la generación de tarjetas adicionales para otro documento, la relación es que todas las tarjetas de una cuenta son de un mismo documento. 

h)     Los saldos siempre son administrados por cuenta y se debe poder definir un límite de consumo por cada tarjeta y que el usuario puede parametrizar.

i)        El plazo de vigencia es diferencial (5 años). Esto es parametrizable. La vigencia se aplica a la tarjeta virtual y su correspondiente tarjeta física (plástico).

j)        Se debe poder aplicar cargos en la emisión. El cargo de emisión se aplica por cada tarjeta de una cuenta. Esto es parametrizable.

k)     Se debe poder aplicar cargos en la renovación. El cargo de renovación se aplica por cada tarjeta de una cuenta. Esto es parametrizable.

l)        El cargo por la emisión y el cargo de renovación pueden aplicarse en los distintos pasos de la generación de la tarjeta y con montos parametrizables. Los pasos donde pueden aplicarse son actualmente:

• Al momento de generar la tarjeta por un alta, ó
• Al activar la tarjeta

Si no hay parametrización de monto entonces no se aplica el cargo.

Sobre la aplicación del cargo en la emisión referenciar el ítem 3.5. Sobre la aplicación de los cargos y la facturación de los mismos .

m) La tarjeta que nace con la cuenta es la tarjeta virtual. Esta tarjeta virtual puede ser activada por el usuario o puede estar Operativa al generarse, se manejará por un parámetro esta condición. Debe poder transaccionar en forma inmediata. No se condiciona la activación de la tarjeta virtual al embozado de la misma.

n)     Las tarjetas virtuales (no impresa) no pueden realizar transacciones con lectura de banda, plástico presente.

o)     El embozado (impresión del plástico) es opcional en la generación. Debe quedar un indicador que la tarjeta no tiene plástico.

p)     Cuando el usuario solicita su plástico (pide la impresión de su tarjeta virtual),  se debe controlar que la tarjeta física no pueda operar hasta que el usuario haya recibido el plástico y lo haya ‘activado’.

q)     La impresión de un plástico puede aplicar un cargo por la impresión y se puede parametrizar desde que impresión se aplica y el importe.

r)       La solicitud de PIN es opcional e independiente. El procedimiento de seguridad para la entrega correspondiente se controla en la aplicación por la que ingresa la solicitud (ej, la app Dimo). Debe quedar un indicador de que la tarjeta no solicitó la generación del PIN. Estas tarjetas no podrán realizar transacciones que solicitan PIN (ATM’s u otra forma de adquirencia que implementa uso de PIN).

s)      El proceso de embozado y el proceso de solicitud de PIN no deben depender de los procesos  actuales y deben poder responder a una solicitud en línea en el menor tiempo posible.

t)       A diferencia de los procesos actuales que tienen impresión de acuse de recibo del plástico y recibo de pin, se  debe prever que las impresiones sean independientes, procediéndose a las mismas solo donde el procedimiento indique que sea necesario, ej.: no se imprimen acuse ni recibo de pin en lotes de tarjetas preemitidas, tampoco se imprime acuse de recibo del plástico ni recibo de pin cuando la generación es desde la web o la app.

u)     Si el usuario solicita embozar la tarjeta se debe establecer el procedimiento de seguridad para la entrega correspondiente. De este procedimiento se deben determinar las opciones para la trazabilidad del estado de la entrega. La trazabilidad del estado de entrega del plástico debe poder ser consultada por el usuario. Ejemplos de estado de la entrega son: A embozar, A entregar, Con el delivery, Entregada.

v)     Las tarjetas prepagas pueden tener los siguientes estados:

• Operativa
• Bloqueo a pedido del usuario
• Bloqueo a pedido de la entidad
• Robada/Perdida
• Vencida
• No activada
• Anulada a pedido del usuario
• Anulada a pedido de la entidad

Para los bloqueos y anulación, debe poder indicarse el detalle del motivo del mismo.

w)   La renovación de una tarjeta prepaga es automática y consiste en la ampliación de la vigencia según el plazo parametrizado.

x)     Cuando una tarjeta prepaga es renovada el estado debe considerar las siguientes situaciones:

• Para la tarjeta virtual queda como Operativa, permitiendo al usuario seguir utilizando su tarjeta.
• La tarjeta física queda como ‘No activada’ y el usuario debe proceder a solicitar la impresión y activarla al recibirla.

y)     En caso de denunciar una tarjeta prepaga por robo o pérdida, se requerirá anular la denunciada y volver a generar un nuevo número de tarjeta, con todo el proceso de emisión como se definió.

3.3.                   Flujo emisión de una tarjeta prepaga y circuito de vida

El proceso de emisión de una tarjeta prepaga es un proceso en línea y culmina dejando disponible la tarjeta en forma inmediata.

Los pasos opcionales, que como el embozado y o la entrega del PIN, también se gestionan en línea, pudiendo solicitarse al emitir la tarjeta o a demanda, a requerimiento del usuario.

El proceso de emisión de una tarjeta prepaga se puede visualizar en el siguiente diagrama:

El ciclo de vida de una tarjeta prepaga es básicamente definido en la secuencia:

1. Emisión –> [embozado/PIN opcional] [+ generación de cargos por emisión (generación de factura para el usuario / remisión a la set al cerrar el periodo)]  –> cambio de PIN] –>

2. Transacciones –> registro del pago –> compras [+ generación de cargos por operaciones (generación de facturas para el usuario / remisión a la set al cerrar el periodo)] –> consulta de saldos –>

3. Cierre mensual –> Generación de estado de cuenta [+ cargos anuales: mantenimiento  (generación de facturas para el usuario / remisión a la set al cerrar el periodo)] –> [emisión de extractos] –>

4. Renovación [+ generación de cargos por renovación (generación de factura para el usuario / remisión a la set al cerrar el periodo)] –> [embozado opcional] [+ generación de cargos por embozado (generación de factura para el usuario / remisión a la set al cerrar el periodo)] 

Comentario adicional: para los cargos anuales si la cuenta no tiene saldo se recurrirá a un procedimiento que reintenta la aplicación en forma diaria, pudiéndose aplicar cuando la cuenta tenga crédito.

3.4.                   Sobre las transacciones y cargos en las transacciones

Se dejan aquí definiciones sobre las transacciones que deben poder realizar las tarjetas prepagas, así como los cargos que pueden aplicar (o no) por las transacciones:

a)     Una tarjeta prepaga Cabal puede realizar compras en todos los comercios de la red Cabal, por todos los medios de adquirencia disponibilizados por Cabal.

b)     Para las compras en comercios el único plan habilitado es contado. Las autorizaciones siempre van contra el saldo (crédito disponible) del usuario, no se manejan los límites de tarjeta de crédito.

c)      Una tarjeta prepaga Cabal puede realizar extracciones en cajeros de los adquirientes habilitados en Cabal siempre que cuenten con su PIN.

d)     Para las extracciones de efectivo solo se habilita contado. Las transacciones de extracción son equivalentes a un adelanto de efectivo y van contra el saldo (crédito disponible) del usuario.

e)     Una tarjeta prepaga Cabal puede realizar extracciones de su saldo en cualquiera de los medios disponibilizados por Cabal: actualmente ATM, y en tiempo cercano por boca de cobranza y las ventanillas de las entidades emisoras.

f)       Las transacciones de acreditación habilitan en línea el saldo. Estas transacciones son procesadas como créditos al usuario.

g)     Para las transacciones se debe poder definir la aplicación de cargos, y la posibilidad de indicar si se aplica al tarjetahabiente originante o al destinatario.

h)     Cuando la transacción aplica un cargo al tarjetahabiente originante, la autorización se deben aprobar si se cubre el monto indicado más el cargo.

i)        Cuando la transacción aplica un cargo al tarjetahabiente destinatario y se le deba aplicar un cargo, se realizará el registro de la transacción y el cargo en línea. El cargo debe poder ser cubierto.

j)        En caso de reversos de una transacción, estos deben ser aplicados a los cargos generados en relación a la transacción reversada.

k)     Los consumos y las extracciones de los usuarios de tarjetas prepagas son procesadas como cualquier otro cupón y se reportan en el cuadro de la monetaria diaria del emisor prepago correspondiente.

3.5.                   Sobre la aplicación de los cargos y la facturación de los mismos

Los cargos se aplican por transacción, o en forma programada (mensual, anual). Los cargos deben ser facturados a los usuarios.

La aplicación de cargos prevé las siguientes condiciones:

a)     Los cargos generados por transacciones deben facturarse en línea al usuario que cubre el cargo, aplicando el impuesto correspondiente.

b)     Al aplicar un cargo en la emisión, cuando la tarjeta aún no realizó una acreditación, este cargo se registra como programado y se debe administrar de forma que se impute en forma inmediata al registro de la primera acreditación.

c)      Los cargos aplicados generados deben facturarse con la fecha de la transacción.

d)     Las facturas son generadas al cierre del mes.

e)     Cuando un cargo es reversado se tienen las siguiente situaciones:

• Es dentro del periodo: no se factura (cargo neteado)
• Ya fue facturado: se debe emitir la correspondiente nota de crédito.

f)       Las tarjetas prepaga deben cerrarse al mes, que corresponderá al periodo, pero puede definirse el rango de fecha correspondiente (del 25 al 24, por ej.).

g)     El cierre disponibiliza un estado de cuenta al último día del periodo para el usuario, e incluye los detalles de las facturas emitidas en el mismo.

h)     Las facturas deben emitirse al usuario por documento o RUC.

i)        Se deben parametrizar los datos para la emisión de la factura a usuarios del correspondiente emisor.

j)        Se genera el libro venta para la SET, tal como se genera para las tarjetas de crédito, y debe ser remitido la SET por el emisor (Cabal o el que corresponda).

k)     Se deben prever cargos programados que deben ingresar en el periodo, como por ej.: costo de mantenimiento anual, y el correspondiente impuesto.

l)        Cuando un cargo programado no se puede imputar por falta de disponible, se debe prever que se vuelva a reintentar la imputación hasta poder aplicar el cargo. Se debe prever un máximo de reintentos.

m) Los cargos aplicados en una fecha se reportan en el cuadro de monetaria diaria del emisor prepago correspondiente.

n)     Los cargos programados que no se aplicaron por falta de disponible se deben disponibilizar en consultas, y deben poder ser expuestos en el detalle para el usuario.

o)     Los consumos, depósitos, extracciones, cargos aplicados en la fecha se visualizan el reporte de monetaria diaria del emisor de la tarjeta prepaga.

3.6.                   Sobre la liquidación a comercios y acreditación en una tarjeta prepaga

Para la  liquidación y acreditación de los comercios, se sigue el mismo proceso hoy utilizado.

Para utilizar una tarjeta prepaga para acreditación a comercios se anotan los siguientes puntos:

a)     Se debe crear un pagador que corresponda a las acreditaciones por tarjeta prepaga.

b)     A los comercios se le asigna la cuenta de la tarjeta prepaga. La liquidación se realiza en forma normal, respetando los porcentajes de comisión establecidos.

c)      Los créditos a los comercios son procesados en la liquidación diaria, aplicando los porcentajes de comisión establecidos.

d)     En los reportes de créditos a comercios se incluye al pagador de tarjetas prepagas, como los demás pagadores.

e)     Para la acreditación de las compras de tarjetas prepagas, el procedimiento es el realizado actualmente: acreditación a la cuenta del comercio a través de la entidad pagadora (o cheque).

f)       Para la acreditación de las compras de un comercio en su cuenta prepaga, se sigue el procedimiento realizado actualmente y se agrega la prestación de la carga de los crédito por ajustes que pueden procesarse con las siguientes consideraciones:

• Si el emisor de la tarjeta prepaga para la acreditación es Cabal, el proceso de carga es automatizado. El saldo de las tarjetas prepagas se actualizará en línea en la fecha de acreditación indicada.
• Si el emisor de la tarjeta prepaga no fuera Cabal, se generará un archivo de ajustes masivos equivalente a un archivo pagador para el emisor correspondiente. El saldo de las tarjetas prepagas se actualizará en línea en la fecha de acreditación indicada siempre que se encuentre procesado el ajuste correspondiente.

Comentario adicional: Con esta misma solución se puede habilitar como un pagador para comercios PANAL, de forma que reciban la acreditación en una tarjeta prepaga Cabal. Siendo PANAL el procesador se le debe remitir el archivo del pagador (ajustes créditos) y Cabal procesa como una entidad pagadora, dado que las cuentas son de tarjetas prepaga Cabal.

g)     Los movimientos de crédito correspondientes a liquidaciones de comercio se identificaran con rubro de ajuste específico y se reporta en el cuadro de la monetaria diaria del emisor prepago correspondiente.

3.7.                   Sobre la compensación de tarjetas prepaga

Para la  compensación de las tarjetas prepagas, se sigue el mismo proceso hoy utilizado. Si el emisor es Cabal, la compensación es interna. Si el emisor es otra entidad, el circuito permite realizar la compensación. Por tanto en la compensación se tiene:

a)     Los consumos de las tarjetas prepago se visualizan reporte de procesos del día del emisor de tarjetas prepaga Cabal, en el cuadro ‘Débito’.

b)     Los créditos a comercios que deben cubrirse con tarjetas prepagas se visualizan en el reporte de procesos del día del emisor de tarjetas prepaga Cabal, en el cuadro ‘Crédito’.

c)      El reporte de datos para la compensación incluye los consumos de las tarjetas prepagas en la posición emisora y los créditos a comercios que cobran con una tarjeta prepaga en la posición pagadora, siempre para el emisor de tarjetas prepaga al que correspondan.

Comentario adicional: Si existen comercios de Panal cuyo pagador sea Cabal a través de sus tarjetas prepagas, esto no se incluye en el circuito de liquidación y compensación de Cabal, ya que estos consumos corresponden a tarjetas Panal en comercios Panal y no son compensados en CABAL, pero deben ser requeridos a CU. Para poder realizar la compensación en el reporte  de ‘Datos para la Compensación’ debe reportarse por separado el crédito que debe realizarse a las tarjetas prepagas de dichos comercios. Este detalle permitirá que se incluya un registro en la planilla de la compensación para le incluya en el cálculo del neto a solicitar a CU.

d)     La definición de las cuentas para los movimientos actualmente se maneja en la planilla de compensación, por tanto se podrán parametrizar según se defina separar las operaciones de tarjetas prepagas en una cuenta corriente independiente a la actual.

Anexos.

1.    Parámetros y cargos generales pre-existentes.

Se enumeran en este apartado los parámetros de gestión disponibles actualmente. Para aquellos parámetros de cargos que no se desea aplicar, se definen con cero en los importes o cantidad. Los parámetros y cargos se definen a nivel de emisor.

1.1.                      Calendario de periodos.

Se define la fecha de inicio y fin de cada periodo.  Se tiene por defecto definido del 1 del  mes al último día del mes correspondiente.

Al finalizar el periodo se genera el estado de cuenta en medio digital y se  emiten las facturas generadas durante el mismo, también en formato digital.

Por cada periodo se inicializan los acumulados mensuales o contadores. 

1.2.                      Parametrización del BIN.

Se define por cada emisor el bin a ser utilizado para la generación de las tarjetas.

1.3.                      Cargo por emisión de tarjeta.

Se puede indicar si aplica un cargo al generar una tarjeta. El importe del cargo se puede aplicar al generar la tarjeta o al activarla.

1.4.                      Cargo por renovación de tarjeta.

Al igual que en la emisión, al llegar al vencimiento de la tarjeta y renovarse, se puede indicar si aplica un cargo por renovación. El importe del cargo se puede aplicar al generar la tarjeta o al activarla.

1.5.                      Cargo por mantenimiento anual.

Se puede indicar si se aplica un cargo de mantenimiento anual a la tarjeta en base a su fecha de emisión. Este  cargo no se aplica cuando la tarjeta alcanza la fecha de vencimiento.

1.6.                      Cargo por gastos administrativos mensuales.

Se puede indicar si se aplica un cargo de gastos administrativos mensuales a la tarjeta.

1.7.                      Indicador de cálculo de impuesto por cargo.

Para cada cargo aplicado se indica si aplica impuesto (IVA), seleccionando el porcentaje correspondiente.

1.8.                      Plazo de vigencia de la tarjeta prepaga.

Se debe indicar el plazo de vigencia en meses para la tarjeta prepago. La tarjeta virtual y la tarjeta física tienen la misma vigencia.

1.9.                      Parámetros de datos de tributación.

Se deben registrar los datos de contribuyente del emisor para la emisión de las facturas por cargos aplicados.

2.    Parámetros y cargos transaccionales pre-existentes.

Se enumeran en este apartado los parámetros relativos a transacciones disponibles actualmente. Estos parámetros se definen por emisor.

2.1.                      Indicador de uso de ATM.

Se debe indicar si el emisor permite el acceso a ATM’s.

Si este indicador está habilitado se puede generar PIN a las tarjetas, en caso contrario no permite la generación de PIN.

2.2.                      Cargo por uso de ATM.

Se puede definir un costo por transacción en ATM.

Este costo se puede indicar aplicar para consultas o para extracciones, o para ambas.

Se puede indicar una cantidad de transacciones libres. Al superar esta cantidad se aplica el costo definido. El contador de cantidad de transacciones en ATM se reinicia en el periodo.

2.3.                      Restricción de consumos por ramo de comercio.

Se puede indicar el o los ramos donde las tarjetas del emisor no pueden consumir.

2.4.                      Tope de consumo por tarjeta (Límite por tarjeta).

El usuario puede definir el tope mensual que puede consumir por tarjeta.

Una vez que la tarjeta alcanzó el tope de consumo ya no podrá realizar transacciones de débito, solo de crédito.

El tope se inicializa en cada periodo.

3.    Parámetros para tarjeta prepaga incorporados.

En este apartado se indican los parámetros de gestión, los límites y los  costos operacionales que se requiere incorporar para las tarjetas prepagas. Estos parámetros se deben definir por emisor.

3.1.                      Indicador de emisor de tarjetas prepagas.

Se debe registrar al emisor como emisor de tarjetas prepagas.

3.2.                      Indicador de estado de una tarjeta virtual a su generación.

Se puede indicar si la tarjeta virtual queda en estado operativa al ser generada o si debe activarse a solicitud del usuario.

3.3.                      Indicador de cantidad máxima de tarjetas por documento.

Se puede indicar la cantidad máxima de tarjetas prepagas vigentes que puede tener un usuario.

3.4.                      Depósito inicial mínimo.

Se puede indicar un importe mínimo para la primera recarga de dinero posterior a la activación de la tarjeta. Sobre dicho importe se aplican los cargos de emisión y la impresión de la tarjeta física.

3.5.                      Costo de impresión de tarjeta física (plástico).

Se puede indicar un importe a aplicar por costo de impresión de una tarjeta física, pudiéndose aplicar desde la primera impresión o desde la que se indique.

3.6.                      Plazo máximo de inactividad / Cargo por inactividad.

Se puede indicar plazo máximo en días para inactividad de la tarjeta prepaga. Pasado el plazo indicado se puede aplicar un importe por cargo por inactividad a ser aplicado por cada periodo de inactividad hasta que la tarjeta realice una operación.

El costo por inactividad se aplica al cierre del periodo si la tarjeta cuenta con saldo, en caso contrario queda programado para ser aplicado cuando cuente con saldo.

3.7.                      Indicador cantidad máxima de reintentos de aplicación de cargos programados no aplicados.

Se puede indicar un plazo máximo en días que se puede reintentar aplicar los cargos programados (mensuales, anuales) que no se aplicaron en la fecha correspondiente por falta de disponible .

3.8.                      Límites de importes mínimos y máximos, diarios y mensuales.

Se puede indicar cantidades e importes mínimos y máximos por tipo de operaciones. Se indican los siguientes:

•   Límite máximo de recarga diaria / mensual, en importe.

•   Límite diario de compras, en importe.

•   Límite de extracciones diario, cantidad e importe máximo por operación.

•   Límite de pagos diario / mensual, en importe.

•   Límite máximo de recarga desde tarjetas de crédito diario / mensual, en importe.

3.9.                      Costos operacionales a aplicar por tipo de transacción.

Se define un % o un importe a aplicar a las tarjetas prepagas por tipo de transacción, pudiéndose indicar un rango de importe mínimo y máximo de la transacción para ser aplicado.

Para cada transacción se puede indicar si el cargo se aplica siendo la tarjeta la originante o la destinataria.

Las transacciones indicadas son las siguientes:

• Carga de saldo (Depósito/Acreditación)
• Compras
• Extracciones
• Pago de extracto de TC
• Pago de Servicios Cooperativos
• Pago de Servicios Otros Facturadores

Fin del documento.