Requerimiento ajuste factoring

ST -  Login Authentication RSA en TLC

Versión V.1

Servicio de Canales Virtuales

Banco de Crédito BCP

03/08/2015

Responsable:

Jhan Pierre Moreno García

Contenido

1.        Situación Actual        

1.1        Situación Actual del Aplicativo / Alcance        

1.2        Fuera del Alcance / Exclusiones        

2.        Objetivos Esperados        

3.        Funcionalidades Esperadas        

4.        Documentación Adicional        

1. Situación Actual

1. Situación Actual del Aplicativo / Alcance

Actualmente en Telecrédito no hay una herramienta que evite un posible fraude, ocasionando que puedan ocurrir fraudes al realizar algunas operaciones monetarias. Además, no se realiza el monitoreo al login por lo que está expuesto a phishing u otros medios de fraude.

El alcance del proyecto será implementar la herramienta que se utiliza actualmente en Home Banking, el RSA Adaptive Authentication, la cual consiste en 3 componentes:

- API

- Motor de riegos

- Módulo BackOffice

Con estos 3 módulos se permite que el sistema (Telecrédito) realice llamadas a los servidores de RSA (API) y este hará un análisis de riesgo y atribuirá un riesgo a la operación mencionada (Motor de riesgos). Con este valor (entre 0-1000) el equipo de Fraudes por medio del Módulo BackOffice puede hacer la creación de políticas para el riesgo, por medio de estas políticas el sistema tomará acciones como denegar el acceso al usuario, retarlo, registrar sus preguntas reto, permitir el acceso.

Las operaciones a las que se realizará el análisis de riesgo son las siguientes:

Operaciones Monetarias

    Transferencias a cuentas propias

    Transferencias a cuentas de terceros 

    Transferencias a otros bancos locales (incluye importación de archivo^[a])

    Transferencias a bancos del exterior (incluye importación de archivo)

    Transferencias a cuentas BCPMiami

    Transferencias con tipo de cambio negociado

    Pago de Servicios

Pagos Masivos

    Pago de haberes

    Pago de proveedores

    Pago de dividendos

Pendientes de Envío

    Bandeja de Pendientes de Envío    

Se debe considerar como base para este requerimientos las fuentes del requerimiento SN000024687 - ST000026590 - TK000046170 - Disposición de efectivo Tarjetas de Crédito por TL^[b]C.

1. Fuera del Alcance / Exclusiones

1. No se puede utilizar el mismo Motor de riesgo de HBK, es necesario crear un nuevo Motor para Telecrédito debido a que el análisis de riesgo es estadístico y podría un sistema perjudicar al otro.
2. No se realizará el análisis de riesgo del Login de la Web de Proveedores.
3. La API de RSA no está optimizada para el concepto de batch transactions (enviar varios registros al mismo tiempo), que es el caso de la bandeja de operaciones Pendientes de Envío. Por ello, para este escenario la solución planteada será hacer varias llamadas a RSA, una para cada operación, en la primera que presente un riesgo se reta al usuario y en las demás ya no se reta si no se crean casos.

Nota: Esta forma de trabajo puede ocasionar muchos casos para revisión en el módulo interno BackOffice y será necesario definir una regla en dicho módulo para que sólo se muestren un porcentaje de casos de riesgos asociados a esta acció^[c]n.

1. Debido a que la API de RSA no está optimizada para batchs transactions, no se enviarán los datos de los abonos de una planilla, sólo se enviará los datos del cargo.                        
2. Sólo se considerarán las operaciones listadas en la sección "Alcance". Si se quiere incluir otra operación debe ingresar como un control de cambio.
3. Las preguntas reto serán definidas por el usuario tomando como input las preguntas proporcionadas por RSA, no se permitirá el ingreso manual de preguntas.

1. Objetivos Esperados

Reducir el nivel de fraude en el canal Telecrédito.

Implementar el monitoreo del login y de las operaciones monetarias en Telecrédito.

1. Funcionalidades Esperadas

Para la implementación de esta nueva funcionalidad, se deberá crear un “parámetro general” desde PABE para controlar la activación / desactivación del servicio RSA en Telecrédito. Este parámetro tendrá 3 estados:

• Activo: Se envía la solicitud a RSA y se espera respuesta para determinar qué acción seguir.
• Inactivo: No se envía solicitud a RSA, la aplicación trabaja como si no existiera comunicación con RSA.
• Asíncrono: Se envía solicitud a RSA y se espera respuesta de forma asíncrona. Este valor será utilizado cuando RSA esté trabajando en modo silencioso (Silent Mode).

Además, se deberán crear los siguientes parámetros que serán administrados desde PABE, con los mismos estados definidos para el “parámetro general” y desde aquí poder administrar de forma independiente los estados por cada funcionalidad que se especifica a continuación:

• Login TLC: Crear parámetro para controlar la activación / desactivación del servicio RSA en el Login de TLC.
• Operaciones monetarias: Crear parámetro particular por cada operación monetaria descrita en la sección “Alcance” para controlar la activación / desactivación del servicio RSA en Telecrédito para esa operación.
• Para la bandeja de operaciones Pendientes de Envío, se debe crear un parámetro el cual tendrá solo 2 estados y se comportará de la siguiente manera:

• Activo: Se debe tomar en cuenta los parámetros de cada operación para el análisis de riesgo.
• Inactivo: No se realizará análisis de riesgo en ninguna de las operaciones de la Bandeja pendientes de envío.

Para todos los casos anteriormente indicados, se deberá validar el parámetro general y los parámetros independientes por cada funcionalidad.

Se deberá crear un utilitario Web (Web Service) que permita:

• Desencriptar la información que se envió encriptada a RSA y visualizar los datos del ID (tarjeta) encriptado.
• Encriptar los datos del cliente para poder realizar búsquedas en el BackOffice de RSA.
• El código de contrato TLC se enviará como un campo genérico.

Este utilitario WEB deberá trabajar de manera similar al utilitario de HBK "hbkutilrsa" el cual permite ser invocado desde el BackOffice de RSA para resolver el ID encriptad^[d]o.

Para TLC se debe considerar como ID de usuario la tarjeta del usuario logueado en el sistema, este ID debe ir encriptado a RSA pero se debe tener en cuenta el tamaño máximo del dato encriptado ya que el API tiene un tamaño límite para este dato.

...