Contract
Servicio bancario de adquirencia y pasarela de pago para el sistema de gestión comercial online de Transports de Barcelona, SA, Projectes i Serveis de Mobilitat, SA y Transports Metropolitans de Barcelona, SL
Pliego de condiciones técnicas Junio 2022
Versión 1.1
WEB-APP-PLEC-Contractación PSP y Adquirencia
TABLA DE CONTENIDOS
3 Funcionamiento del servicio 7
4 Requisitos funcionales de usuario final 8
7 Requisitos de protección contra el fraude (“listas negras”) 12
8 Requisitos sobre responsabilidad y gestión del fraude 13
9 Requisitos de gestión de la información e informes 14
10 Requisitos para la integración de la información 16
11 Requisitos de implantación y gobernanza del proyecto 17
12 Requisitos de disponibilidad (según los SLA) 19
13 Penalizaciones por incumplimiento de los SLA 20
14 Requisitos de operación del servicio 22
15 Características del servicio 25
Página 2 de 31
Historial de modificaciones
Fecha | Autor | Comentarios | Versió n |
08/06/2022 | Versión inicial | 1.0 | |
29/06/2022 | Revisión final | 1.1 | |
Aprobación
Nombre | Fecha | Firma |
Xxxxx Xxxxx | 13/07/2022 |
Distribución
Interno | Externo |
Página 3 de 31
1 Objetivo
Objetivos del documento
El objetivo de este documento es establecer el pliego de condiciones completo para la contratación del servicio bancario de adquirencia y pasarela de pago para el sistema existente de gestión comercial online (web y app) de Transports de Barcelona, SA, Projectes i Serveis de Mobilitat, SA y Transports Metropolitans de Barcelona, SL (en adelante, "TMB").
Diccionario y acrónimos
En este apartado se recogen los términos específicos y acrónimos empleados a lo largo del documento:
• TMB: Las 3 sociedades indicadas en este documento: Transports de Barcelona, SA, Projectes i Serveis de Mobilitat, SA y Transports Metropolitans de Barcelona, SL.
• AMB: Área Metropolitana de Barcelona.
• ATM: Autoridad del Transporte Metropolitano.
• PCP: Pliego de Cláusulas Particulares.
• CC: Cuadro de Características.
• API: Application programming interface (interfaz de programación de aplicaciones).
• SI: Sistema de información.
• SIE: Sistema de información embarcado.
• SLA: Service level agreement (acuerdo de nivel de servicio).
• ANS: Acuerdo de nivel de servicio.
• PAN: Personal account number (número de cuenta personal).
• GDPR: General Data Protection Regulation (Reglamento General de Protección de Datos).
• Ticket: Un sistema de ticketing o de seguimiento de incidencias sirve para crear, gestionar y realizar un seguimiento de las incidencias o peticiones.
• PCI: Payment card industry.
2 Alcance del proyecto
2.1 Contexto
TMB posee un sistema para la venta de distintos productos a través de sus canales online, tanto por web como por app. Para poder dar continuidad a este servicio es necesario la contratación de un servicio de pasarela de pago que contemple todos los requisitos funcionales y técnicos especificados en este pliego de contratación con el fin de que el cliente pueda pagar sus compras con diferentes medios de pago.
2.2 Objetivo y alcance del proyecto
Se establecen los siguientes objetivos básicos de este proyecto:
• Implantación, configuración y administración de la pasarela de pago.
• Operación de la pasarela de pago y servicio de adquirencia con sistema de tokenización.
• Apoyo a la integración de los productos tecnológicos basados en Android e iOS, y otros de especial relevancia mundial para entornos móviles y web.
• Parametrización, activación y aplicación de las reglas de fraude, tanto las propias del servicio como las de TMB.
• Implantación de los procesos de integración de información.
• Información y gestión operativa de todas las operaciones de este servicio (devoluciones, alegaciones y fraude, etc.).
• Validación del cumplimiento de las normativas de seguridad.
• Habilitación de entorno test y productivo, testeo de todos los procesos.
• Apoyo al desarrollo del servicio.
Por tanto, este pliego hace referencia a la contratación de un servicio de pasarela de pagos y de adquirencia bancaria con las tecnologías y funcionalidades que permitan el cumplimiento de los requisitos expresados en este pliego.
2.3 Canales actuales y futuros
Los servicios contratados en la actual licitación podrán ser ampliables y extensibles a otros servicios o canales comerciales de la compañía en un futuro.
2.4 Fuera de alcance
Quedan fuera del alcance del proyecto los desarrollos referentes a los productos tecnológicos que deben integrarse con servicio de adquirencia y plataforma de pago.
3 Funcionamiento del servicio
3.1 Arquitectura de la solución
En el siguiente diagrama se muestra la arquitectura de la solución a modo de referencia:
Tabla 1. Arquitectura de la solución
Este proyecto hace referencia exclusivamente al desarrollo del componente de la arquitectura Back-End Canal Venta Online, la pasarela de pago y el servicio bancario de adquirencia.
Para que se entienda la arquitectura de la solución, a continuación se describe, a un nivel muy alto, el flujo de información básica de un proceso de venta:
1. A través del sitio web o la app de TMB, el usuario consulta los productos disponibles. Estos productos se obtienen del Back-End Canal Venta Online.
2. El cliente, a través del sitio web o la app, ejecuta una orden de compra con el proceso de pago asociado (pasarela de pago). Esta se envía, se valida y se registra en el Back-End Canal Venta Online. Este devuelve toda la información asociada a su ejecución: justificantes, vouchers, facturas… También ejecuta las acciones de comunicación, como correos electrónicos de confirmación de compra o notificaciones en la app.
3. El Back-End Canal Venta Online comunica la información de la venta al sistema de información de gestión comercial de forma no transaccional (en diferido).
4. La pasarela de pago integra los pagos y la información asociada al servicio de adquirencia.
Por tanto, el componente Back-End Canal Venta Online tiene toda la lógica de negocio referente al proceso de compra.
El back-office de validación de venta y facturación tendrá que ser compatible con el sistema del banco adquirente, la pasarela y el sistema de información corporativo de TMB en cada una de las interacciones que se produzcan para poder prestar los servicios solicitados.
4 Requisitos funcionales de usuario final
Para sus operaciones diarias, TMB necesitará poder ejecutar las siguientes funcionalidades de los distintos medios de pago.
Los requisitos se refieren tanto a la pasarela como al servicio de adquirencia. Los medios de pago necesarios deben definirse de acuerdo con las necesidades de los consumidores.
Requisito | Descripción | Obligatorio |
1. | Debe permitir el pago con todos los siguientes emisores de medios de pago de tarjeta bancaria: • Visa • MasterCard • American Express • UPI • Diners • JCB | Sí |
2. | Debe permitir la operación con los siguientes servicios de pago online: • Apple Pay • Google Pay | Sí |
3. | Debe permitir la integración con los siguientes |
servicios de transferencias digitales: • Bizum • Sofort • Trustly | ||
4. | Cobros tarjeta de crédito: debe disponer de las dos posibilidades de cobro en el entorno de tarjeta de crédito: • Captura directa • Autorización más captura | Sí |
5. | Devoluciones: Debe permitir devoluciones totales o parciales por el medio de pago original de la transacción. | Sí |
6. | Posibilidad de realizar pagos recurrentes o suscripciones. Y esto implica necesariamente la posibilidad de: • En tarjetas de crédito, procesar transacciones sin el CVV • Disponer de algún gestor o herramienta o comunicación para poder planificar y ejecutar transacciones recurrentes. | Sí |
7. | Debe permitir el almacenamiento de tarjetas de los clientes mediante un sistema de tokenización en el cual TMB no tenga que capturar y almacenar los datos de tarjeta de crédito. Este servicio debe ofrecer la custodia y el almacenamiento de los datos de pago de los clientes. | Sí |
8. | Las operativas de gestión que permitirán realizar operaciones sobre los tokens con la pasarela serán, como mínimo: • Alta de datos de un nuevo registro • Modificación de los datos sobre un registro existente • Modificación automática de fecha de caducidad • Consulta de la validez del PAN • Descarga de datos En todas las operativas de gestión, la recepción de la confirmación puede recibirse en un cliente diferente al cliente desde el que se ha realizado la operación. | Sí |
9. | Las operativas de cobro que el sistema debe implementar, como mínimo, son las siguientes: • Transacciones de preautorización • Transacciones de pago • Transacciones de devolución • Anulación de un pago • Anulación de una devolución • Test de saldo | Sí |
10. | La pasarela deberá gestionar más de un comercio y más de una empresa bajo la marca TMB. | Sí |
11. | La pasarela deberá poder gestionar más de un adquirente una vez finalizado este contrato. | Sí |
12. | Las operativas de cobro con token posteriores a la primera operación podrán realizarse sin tener que ejecutar el pago seguro. | Sí |
13. | Debe permitir el pago seguro en todos los medios de pago y en todos los entornos. | Sí |
14. | Debe estar preparado para la ejecución de transferencias instantáneas según PSD2. | |
15. | Los diferentes puntos de interacción con el usuario final: pantallas, textos, mensajes, etc., deben ser multiidioma. Deben estar al menos en: Catalán, castellano, inglés, alemán, italiano y francés. | Sí |
5 Requisitos normativos
A continuación se presentan los requisitos que deben cumplirse en materia de normativa aplicada al procesamiento de transacciones económicas en el ámbito digital.
Requisito | Descripción | Obligatorio |
1. | Cumplimiento de la normativa de procesamiento de la tarjeta de crédito: última versión de la certificación PCI DSS Xxxxx 0. | Sí |
2. | Cumplimiento de la normativa PSD2. | Sí |
3. | Cumplimiento de normativas xx xxxxx de protección de datos de carácter personal (GDPR). | Sí |
4. | Las infraestructuras informáticas deben estar ubicadas en territorio europeo. | Sí |
5. | Cumplimiento de cualquier otra normativa que durante la vigencia del contrato pueda surgir en esta materia y que sea de obligado cumplimiento. | Sí |
6 Requisitos tecnológicos
A continuación se presentan los requisitos que deben cumplirse a nivel tecnológico:
Requisito | Descripción | Obligatorio |
1. | CPD en categoría Tier III, según la clasificación de Uptime Institute | Sí |
2. | CPD en arquitectura Multi Availability Zone (Multi AZ) | Sí |
3. | El servicio de pasarela debe ofrecerse en formato SaaS (software as a service), es decir, no se instalará ningún elemento de hardware de servidores en las instalaciones de TMB. | Sí |
4. | Disponer de librerías nativas de integración en las plataformas móviles (SDK): • Apple iOS: versión mínima 9 • Google Android: versión mínima 4.4 | Sí |
5. | Disponer de librerías JavaScript para su integración en entornos web. | Sí |
6. | Disponer de maquetaciones responsive, adaptables según el tamaño de la pantalla, por las soluciones web embebidas en los sitios web de TMB. | Sí |
7. | Disponer de API de integración con tecnologías JSON sobre protocolos HTTPS. | Sí |
8. | Back-office accesible desde internet mediante tecnologías web modernas y multidispositivo (responsive) y navegador (IE Explorer, Edge, Chrome, Firefox y Safari). | Sí |
9. | Posibilidad técnica de trabajar con múltiples bancos adquirientes. | Sí |
7 Requisitos de protección contra el fraude (“listas negras”)
A continuación se recogen los requisitos que deben cumplirse en cuanto a las funcionalidades para la protección del fraude:
Requisito | Descripción | Obligatorio |
1. | Pago seguro en todos los canales y por todos los medios de pago con protocolos de seguridad que sean liability shift: • 3DSecure por tarjeta de crédito, por ejemplo: VISA. Verified by VISA, MASTERCARD. Secure Code, AMEX. SafeKey (si procede) • Por los otros medios de pago: Que tengan protocolos de liability shift (la responsabilidad no recae en el comercio). Por ejemplo: - PayPal. En el caso de PayPal, la protección del comercio - Apple Pay. No Fraud CBs Policy. | Sí |
2. | API abierta de integración para gestionar automáticamente las listas de excepción de tarjetas. La recepción de esta información deberá ser sistemática y lo más ágil posible. | Sí |
3. | Tratamiento automatizado de listas negras por tarjeta de crédito según los siguientes criterios mínimos: • Nacionalidad IP • Nacionalidad Tarjeta • Bloquear transacciones para usuario a partir de N transacciones en X horas. • Bloquear transacciones para tarjeta a partir de N transacciones en X horas. • Bloquear transacciones para IP a partir de N transacciones en X horas. | Sí |
4. | Posibilidad de bloquear operativas de acuerdo a patrones de comportamiento fraudulento. | Sí |
5. | Limitar operaciones por: • Importe • Número de operaciones en X horas con la misma tarjeta o cliente • Por producto. | Sí |
6. | Todas las configuraciones de fraude podrán ser administrables por TMB mediante interfaz abierta. | Sí |
8 Requisitos sobre responsabilidad y gestión del fraude
A continuación se presentan los requisitos que deben cumplirse en la gestión del fraude, ya sea por parte de la pasarela o por parte del banco adquirente:
Requisito | Descripción | Obligatorio |
1. | Disponer de un sistema de indicadores y comunicación para el seguimiento del fraude y su gestión. | Sí |
2. | Poder aplicar devoluciones de forma manual, tanto parciales como totales. | Sí |
3. | Poder realizar la gestión y control de disputas. | Sí |
4. | Consulta de operaciones individuales. | Sí |
5. | Recepción y notificación de notificaciones de operativa fraudulenta. | Sí |
6. | Recepción y notificación de contracargos. | Sí |
7. | Disputar contracargos si TMB cree que el titular de la tarjeta no tiene razón o va en contra de las condiciones de compra. | Sí |
8. | Poder acceder a las herramientas de gestión del fraude con distintos permisos y con control de acceso a las diferentes funciones. |
9 Requisitos de gestión de la información e informes
A continuación se presentan los requisitos que deben cumplirse a nivel tecnológico:
Requisito | Descripción | Obligatorio |
1. | Acceso al listado de transacciones individuales | Sí |
2. | Acceso diferenciado por comercio y global | Sí |
3. | Poder aplicar filtros sobre las transacciones por distintos criterios | Sí |
4. | Poder exportar los datos a los formatos: MS Excel y CSV | Sí |
5. | Los informes deben proveer como mínimo la siguiente información: • Importe de la transacción • Identificador de la transacción o código de aceptación • Orden de venta —del back-end de TMB— y número de identificación del comercio. • ID del medio de pago • Token del medio de pago (en su caso) • Identificador del usuario —del back- end de TMB— • Identificador del voucher —del back- end de TMB— • Tipo de operación (venta o devolución) • Estado de la transacción (aceptada/denegada) • Explicación del motivo de la denegación (si procede) • Fecha y hora de la transacción —del back-end de TMB— | Sí |
• Moneda (siempre euros y, si procede, otra divisa) • IP nacionalidad país • IP nacionalidad medio de pago (si procede) | ||
6. | Por el servicio de adquirencia, la entidad enviará diariamente, una vez cerradas las sesiones de los comercios de forma automatizada (proceso nocturno), el fichero de operaciones realizadas, mediante la conexión SFTP indicada por TMB, que debe incluir necesariamente una referencia unívoca respecto al cobro de la transacción efectuada en la pasarela. El archivo deberá incluir como mínimo la siguiente información: • Sesión • Terminal • Fecha y hora de la operación • Fecha y hora del procesamiento • Número de autorización • Pan • Importe de la operación • Descuento aplicado (tipo e importe) • Código de la divisa • Referencia de la operación (unívoca con la pasarela) • Operaciones multidivisa • Bonificación multidivisa (si procede) • Crédito/débito • Marca de la tarjeta (Visa, MasterCard, American Express, etc.) • Tipología con detalle de la tarjeta utilizada (nacional, UE, no UE, empresa, etc.) • Marca del servicio de pago si no es por tarjeta (Apple, Google, PayPal, Bizum, etc.) • Información de pago seguro, verificado o recurrente • País del método de pago | Sí |
7. | Notificación de las liquidaciones por parte de la plataforma de pagos |
10 Requisitos para la integración de la información
A continuación se presentan los requisitos que deben cumplir a nivel tecnológico las API de integración con sistemas informáticos de TMB:
Requisito | Descripción | Obligatorio |
1. | Descarga de la información de las transacciones detalladas. | Sí |
2. | Ejecución de transacciones y toda la operativa común de venta. | Sí |
3. | Ejecución de devoluciones y toda la operativa de gestión de las devoluciones. | Sí |
4. | Implementación de todos los procesos de gestión y operación de los tokens descritos en el apartado de requisitos funcionales de usuario final. | Sí |
5. | Obtención de información del usuario/cliente. | Sí |
6. | Ejecución, programación y administración de pagos recurrentes. | Sí |
7. | Habilitación de callbacks para la notificación de transacciones y otros eventos. | Sí |
8. | Los servicios tendrán que ser accesibles tanto desde las infraestructuras tecnológicas de TMB como las de otros proveedores cloud de tecnología, como puede ser AWS. | Sí |
9. | Habrá que implementar todas las arquitecturas de integración requeridas en el apartado de requisitos de usuario. Básicamente, arquitecturas web (aplicación web en servidor y aplicación en una sola página) y arquitecturas móviles. | Sí |
10. | El proveedor deberá proporcionar, aparte del entorno productivo, un entorno de preproducción para poder realizar pruebas. | Sí |
11 Requisitos de implantación y gobernanza del proyecto
El licitador deberá ejecutar el proyecto según la oferta presentada en el plazo de concurso teniendo en cuenta la gestión completa de los siguientes puntos:
• Estructuración de las etapas, dependencia entre ellas y metas concretas.
• Cronología de las etapas y metas de la fase test y de la implantación final.
• Equipo de trabajo asignado: personas, perfiles y estructura.
• Servicio de soporte después de la implantación.
• Metodología que se utilizará durante el proyecto de implantación
• Programa de identificación y gestión del riesgo
• Formación y comunicación a los usuarios financieros y tecnológicos de TMB sobre los servicios licitados.
TMB nombrará a un director de proyecto que será el interlocutor con el director de proyecto que el banco adjudicatario de la licitación indique. Este director de TMB estará apoyado por dos técnicos, uno financiero (tesorería TMB) y otro tecnológico.
El director nombrado por el adjudicatario deberá tener un perfil tecnológico y será el único interlocutor válido reconocido por TMB. Sus funciones, entre otras, serán las siguientes:
• Velar por la consecución de los objetivos del proyecto, según planificación.
• Ejecutar y realizar el seguimiento del proyecto y del plan de trabajo (tareas, plazos, recursos, etc.), generando la correspondiente documentación: actas, planificación, informes, planes, etc.
• Gestionar y ejecutar el plan de comunicación del proyecto. En particular, periódicamente, deberá comunicar al jefe de proyecto de TMB el estado de avance de los proyectos, con la periodicidad que TMB establezca en cada momento, incluyendo un breve informe de seguimiento y la actualización de la planificación prevista.
• Realizar reuniones de seguimiento de proyecto con la periodicidad que TMB establezca en cada momento.
• Gestionar y valorar las peticiones de cambio en el proyecto junto con TMB.
• Gestionar y supervisar los riesgos del proyecto.
• Gestionar y valorar los riesgos del proyecto y ejecutar las actuaciones previstas.
• Atender puntualmente las peticiones que reciba del interlocutor designado por TMB.
• Realizar el seguimiento del cumplimiento de todos los requisitos de este pliego técnico con la periodicidad que TMB establezca en cada momento.
TMB también nombrará un comité de dirección de proyectos, en el que habrá representantes de las unidades afectadas por el servicio.
El Comité de Dirección velará por que el enfoque de los servicios y sistemas proporcionados se corresponda con el alcance y los objetivos previstos.
El Comité de Dirección también podrá ser requerido en procedimientos administrativos relacionados con la aceptación del proyecto o la aplicación de las sanciones previstas en el ámbito del presente Contrato de suministro y servicios.
12 Requisitos de disponibilidad (según los SLA)
Las incidencias se catalogarán en cuatro niveles en función de la afectación al servicio del portal web:
• Crítica: pérdida completa o falta de disponibilidad total del servicio.
• Alta: pérdida o falta de disponibilidad parcial del servicio. Por ejemplo, existen dos nodos que dan servicio, y uno está fallando y el otro está dando servicio.
• Media: pérdida menor del servicio, como errores puntuales o problemas de rendimiento.
• Baja: incidencia que no tiene impacto en el servicio.
Categoría de la incidencia | Tiempo de respuesta | Tiempo de resolución objetivo |
Crítica | 30 minutos en 24x7 | 60 minutos en 24x7 |
Alta | 45 minutos en 24x7 | 90 minutos en 24x7 |
Media | 1 hora en 10x5 | 120 minutos en 24x7 |
Baja | 1 hora en 10x5 | 240 minutos en 24x7 |
Se establecen las siguientes definiciones:
• Tiempo de respuesta: se define el tiempo de respuesta como el tiempo en que el adjudicatario registra la incidencia en el sistema de gestión de tickets y esta comunica a los destinatarios, mediante el workflow y los canales establecidos del código, su definición y tipificación de gravedad. Las fuentes mediante las cuales se pueden notificar incidencias son:
o Sistemas de monitorización automatizados
o Llamada o comunicación por parte de alguna persona de TMB o subcontratada de TMB.
• Tiempo de resolución: es el tiempo que pasa desde el inicio de la incidencia (y no desde el tiempo de respuesta), hasta el restablecimiento completo del servicio, es decir, hasta que las alarmas y los sistemas de monitorización vuelvan a notificar que el servicio es correcto.
13 Penalizaciones por incumplimiento de los SLA
En las siguientes tablas se muestran las penalizaciones. El importe será el porcentaje aplicado sobre la facturación mensual del servicio bancario de adquirencia y pasarela de pago, que sean imputables directamente a este servicio.
Las penalizaciones son acumulables hasta un máximo del 10 % sobre el importe mensual a facturar.
13.1.1 Penalizaciones sobre el tiempo de respuesta
La penalización se aplica por cada incidencia.
Categoría de la incidencia | Tiempo de respuesta Objetivo | Tiempo de respuesta real | Penalización |
Crítica | 30 minutos en 24x7 | Más de 45 minutos | 1 % |
Entre 30 minutos y 45 minutos | 0,5 % | ||
Menos de 30 minutos | 0 % | ||
Alta | 45 minutos en 24x7 | Más de 60 minutos | 1 % |
Entre 45 minutos y 60 minutos | 0,5 % | ||
Menos de 45 minutos | 0 % |
13.1.2 Penalizaciones sobre el tiempo de resolución
La penalización se aplica por cada incidencia.
Categoría de la incidencia | Tiempo de resolución Objetivo | Tiempo de resolución real | Penalización |
Crítica | 60 minutos en 24x7 | Más de 90 minutos | 3 % |
Entre 60 minutos y 90 minutos | 2 % | ||
Menos de 60 minutos | 0 % | ||
Alta | 90 minutos en 24x7 | Más de 120 minutos | 3 % |
Entre 90 minutos y 120 minutos | 2 % | ||
Menos de 90 minutos | 0 % |
13.1.3 Penalizaciones sobre cómputos mensuales
La penalización se aplicará sobre el cómputo mensual sumando todos los valores de todas las incidencias detectadas.
Definición | Valor | Penalización |
Una disponibilidad del sistema por debajo del X % en cómputo mensual como consecuencia directa de la incidencia tipo Crítica | 99,9 % (0,744 horas/mes máximo de no disponibilidad) | 5 % |
X actuaciones que impliquen el paro del servicio y no se hayan notificado ni registrado en el sistema de ticketing. | 2 | 5 % |
13.2 Penalizaciones sobre la implantación y puesta en marcha
El servicio de pasarela de pago y adquirencia es crítico para TMB. Cualquier retraso parcial o total en la puesta en marcha de la pasarela implica un coste de operación que no puede asumirse. Por tanto, se aplicarán las siguientes penalizaciones en los atrasos en la puesta en marcha e inicio del servicio:
• 100.000 € por el retraso de la puesta en marcha.
• 50.000 € por mes adicional (hasta un máximo de tres) de retraso posterior de la puesta en marcha.
13.3 Condiciones de las penalizaciones
Las penalizaciones se facturarán al proveedor una vez aprobadas por el órgano de contratación según consta en las cláusulas administrativas generales.
14 Requisitos de operación del servicio
Desarrollará tareas destinadas a detectar proactivamente incidentes con afectación a la disponibilidad o puntos de mejora en el funcionamiento de los servicios de pago online, realizará el tratamiento, gestión y resolución de las incidencias, ya sean detectadas por la monitorización o reportadas directamente por TMB.
Dentro de las tareas por realizar se han identificado inicialmente las siguientes:
14.1 Monitorización continua
Se monitorizarán en tiempo real los componentes externos necesarios para el funcionamiento del servicio de pago electrónico.
14.2 Escalado y notificación de incidencias detectadas
TMB dispone internamente del Centro de Apoyo Tecnológico (CAT), que en horario 24x7 realiza tareas de monitorización y operación básicas de los sistemas internos de TMB. Este centro recibe las incidencias reportadas por los usuarios y por los propios sistemas de monitorización.
Si las incidencias detectadas afectan a la disponibilidad de los servicios de pago online, será necesario notificar las incidencias al CAT y a los responsables del servicio de TMB.
14.3 Gestión de intervenciones programadas
En caso de que deban realizarse intervenciones programadas, ya sea para aplicar un parche de seguridad o para actualizar los sistemas, ampliar recursos u otras actuaciones similares, deberá notificarse siempre previamente a TMB mediante la creación del ticket correspondiente y con una anticipación de al menos 24 horas.
En caso de que la actuación comporte un paro del servicio, deberá haberse pactado previamente la hora y duración exacta de la intervención.
14.4 Comunicación
Se requieren los siguientes canales de comunicación mínimos para la gestión de incidencias:
• Entorno web
• Correo electrónico
• Teléfono
Todas las comunicaciones TMB-adjudicatario o adjudicatario-TMB tendrán que hacer referencia a un ticket de la herramienta de gestión central de tickets definida más adelante en este documento.
14.5 Herramienta de gestión de tickets (incidencias)
Se solicita que el proveedor ponga a disposición de TMB una herramienta de gestión de tickets que implemente las siguientes funcionalidades y requisitos básicos:
• Herramienta web accesible a través de navegador desde internet
• Acceso nominal y con roles determinados
• Gestión de tickets con identificador único
• Visualización del estado del ticket: nuevo, abierto, pendiente, cerrado…
• Visualización de quién tiene asignado el ticket
• Notificación mediante correo electrónico de los cambios en los tickets
• Gestión de grupos de notificaciones
• Posibilidad de añadir comentarios a los tickets
Esta herramienta de gestión de tickets servirá como único elemento documental válido para la resolución de discrepancias en el servicio y para la medición de su calidad.
Cualquier alarma de monitorización que se considere importante también tendrá que registrar automáticamente un ticket en esta herramienta.
14.6 Horario del servicio
El entorno de producción en horario de 24x7 y entornos que no sean de producción en horario de 10x5.
14.7 Servicio de mantenimiento evolutivo básico
Desarrollará tareas relacionadas con peticiones de cambios solicitadas por TMB respecto a los diferentes servicios que puedan añadirse durante la vigencia del contrato.
14.8 Bolsa de jornadas de apoyo
El contrato incluirá también una bolsa de jornadas destinadas a la realización de otras tareas no incluidas en los puntos anteriores y al soporte posproducción y al desarrollo de las integraciones, el licitador deberá incluir en el precio ofrecido un mínimo de 25 horas.
El consumo de la bolsa se realizará a partir de una petición por parte de los técnicos de TMB, el proveedor deberá realizar una estimación de las horas necesarias y su planificación.
Estimamos esta bolsa en 100 horas anuales.
14.9 Informes de cumplimiento de ANS
Se solicita que de forma mensual (en formato documental) o mediante una herramienta online web se pueda realizar el seguimiento del cumplimiento de los ANS establecidos.
14.10 Servicio de gestión de seguridad
El adjudicatario deberá disponer de un servicio de gestión de la seguridad informática que cubra principalmente las siguientes acciones:
• Servicio de alerta y notificación de vulnerabilidades detectadas
• Servicio de aplicación de actualizaciones de seguridad en las distintas capas de software
TMB contratará de otra licitación un servicio de auditoría de seguridad que analizará y escaneará los distintos servicios expuestos a través de internet para detectar vulnerabilidades de seguridad. Este servicio permitirá poder disponer del conocimiento del estado en que se encuentra este entorno en todo momento para evitar los siguientes problemas de seguridad:
• Ataques (D)DOS
• Acceder y modificar el contenido de la web
• Asegurar la confidencialidad de los datos de cliente
• Evitar autenticaciones no autorizadas
• Securización de formularios de consulta
• ...
Se deberán tener en cuenta los CIS Critical Security Controls - Version 6.0 (xxxx://xxx.xxxx.xxx/xxxxxxxx-xxxxxxxx-xxxxxxxx) que son aplicables en este proyecto.
En este servicio se analizarán las siguientes capas:
• Análisis de la información pública
• Análisis de seguridad de red
• Análisis de seguridad de sistemas
• Análisis de seguridad de aplicaciones
• Análisis de los sistemas de seguridad
Se utilizarán los siguientes ámbitos metodológicos x xxxxxx de referencia para llevar a cabo este análisis:
• OWASP 🡪 Obligatoria
• OSSTMM 🡪 Opcional
• CobIT🡪 Opcional
15 Características del servicio
15.1 Modalidad de contratación
La modalidad de contratación de este proyecto está en modalidad de SERVICIO, es decir, el proveedor facturará el resultado del coste del servicio según oferta presentada.
15.2 Lugar de realización de los trabajos
Las tareas correspondientes al proyecto se podrán realizar en las dependencias de TMB o en las del proveedor. En caso de optar por las dependencias del proveedor deberá asegurar una comunicación fluida asignando de forma permanente un teléfono y un sistema de mensajería instantánea, así como videoconferencia, cuando pueda ser requerida.
TMB se reserva el derecho de solicitar la prestación del servicio en sus dependencias cuando resulte necesario para la prestación del servicio.
15.3 Infraestructura y entorno tecnológico
Todos los recursos de infraestructura tecnológica necesarios para la realización del proyecto correrán a cargo del proveedor en la infraestructura del proveedor.
15.4 Metodología
El adjudicatario de los servicios se compromete a seguir el marco metodológico de gestión de proyectos TIC de TMB, actualmente ITIL.
15.4.1 Seguimiento y control
El adjudicatario entregará informes semanales en formato digital en el que se describirá el grado de avance del proyecto. En estos informes se incluirán, entre otros, los siguientes aspectos:
• Resumen de las tareas realizadas durante la semana
• Actividades previstas para la siguiente
• Riesgos y desviaciones
• Estado actual de la planificación
15.4.2 Estructura y nomenclatura de las entregas
El adjudicatario deberá seguir y respetar la estructura y nomenclatura por todas las entregas, ya sean documentos o software, que proponga TMB.
15.4.3 Documentación
El nombre de los documentos seguirá un patrón determinado, de modo que pueda identificarse la siguiente información respecto al documento:
• Proyecto
• Ámbito (informe, análisis, diseño…)
• Proveedor, en el caso de las ofertas
• Nombre descriptivo del contenido del documento
• Extensión del archivo Esta información se compondrá formando un nombre del archivo de la siguiente manera:
• PXXXXX. NombreProyecto-ÁMBITO-PROVEEDOR-Nombre del Archivo.ext Los valores del campo "ámbito" pueden ser:
o INFO: Informe
o XXX: Análisis
o DIS: Diseño
x XXXXXX: Pliego de condiciones
o OFER: Oferta
o MAN: Manual
o PRES: Presentación
o PLAN: Planificación
o PLAN: Plan de pruebas, plan de formación
o ACT: Acta
o SEG: Seguimiento
La versión del documento NO debe formar parte del mismo nombre del archivo ni del documento, sino que esta información se deberá gestionar mediante el apartado correspondiente dentro del documento.
15.5 Planificación
Todas las tareas de implantación tendrán que completarse según la planificación establecida, pero nunca podrán superar la fecha límite de 3 meses desde el inicio del contrato. Tanto la planificación, en duración y fecha de inicio, como la priorización las realizarán conjuntamente TMB y el adjudicatario.
15.6 Garantía de software
N/A.
15.7 Seguridad y confidencialidad
15.7.1 Confidencialidad y publicidad del servicio
El adjudicatario está obligado a guardar secreto respecto a los datos o la información previa que, sin ser públicos o notorios, estén relacionados con el objeto del contrato.
Cualquier comunicado de prensa o de inserción en los medios de comunicación que el proveedor realice referente al servicio que presta a TMB deberá aprobarlo previamente el cliente.
15.7.2 Propiedad intelectual
TMB adquirirá en exclusiva la propiedad intelectual de todo el material que elabore el adjudicatario en ejecución del contrato y, en particular, de todos los derechos de propiedad intelectual patrimonial, industrial y de imagen que deriven de este, incluida la explotación en cualquier modalidad y bajo cualquier formato, para todo el mundo, del trabajo elaborado por el adjudicatario o sus empleados en ejecución del contrato, y TMB se reservará cualquier otra facultad anexa al derecho de propiedad intelectual o industrial.
Será propiedad de TMB el resultado de los servicios los materiales y documentos que se realicen en cumplimiento del contrato.
TMB será titular de todos los derechos referidos en el párrafo anterior por el plazo máximo legal permitido y la única organización que para tal concepto podrá explotar y comerciar con el trabajo desarrollado en ejecución del Contrato, antes o después de su finalización, y a sus autores materiales les corresponderán únicamente los derechos xxxxxxx que les reconoce la legislación vigente en materia de propiedad intelectual.
A los efectos previstos en los dos párrafos anteriores, el adjudicatario se compromete a la entrega de toda la documentación funcional y técnica, así como materiales y entregables generados durante la prestación del servicio y en el proceso de análisis, diseño, desarrollo, implantación y pruebas de las mismas. Toda la documentación elaborada y los resultados obtenidos por el adjudicatario en ejecución del contrato serán propiedad de TMB, en cuyo poder quedarán a la finalización del contrato, y el adjudicatario no podrá utilizarla para otras personas, entidades o empresas.
El adjudicatario responderá del ejercicio pacífico de TMB en la utilización del software y otros derechos proporcionados por el adjudicatario con motivo del contrato, será responsable de toda reclamación que pueda presentar un tercero por estos conceptos contra TMB y deberá indemnizar a TMB por todos los
daños y perjuicios que esta pueda sufrir por esta causa. En todo caso, las relaciones jurídicas derivadas del contrato se establecerán entre TMB y el adjudicatario. TMB no estará contractualmente vinculada con personas diferentes del adjudicatario.
15.7.3 Seguridad y protección de datos
El adjudicatario de los servicios se compromete a cumplir los requisitos de seguridad y de continuidad aplicables al objeto del contrato especificados en:
• La legislación vigente en general y, en particular, cuando se traten datos de carácter personal, el Reglamento de Seguridad del Real Decreto 994/1999 de la Ley Orgánica de Protección de Datos de Carácter Personal (LOPD).
Adicionalmente, el adjudicatario se compromete a:
• Cumplir con las directivas tecnológicas, de seguridad y de calidad que establezca el cliente.
• Implementar las medidas, los procesos y los requerimientos que el cliente solicite a tal fin, y le propondrá los que considere necesarios para mejorar las soluciones.
• Facilitar toda aquella información que el cliente requiera para que pueda dar cumplimiento a la legislación y normativa referida en este apartado.
El incumplimiento de las cláusulas relacionadas en este epígrafe relativas a la seguridad y protección de datos en general constituye una falta grave y motivo suficiente para la resolución unilateral del contrato.
TMB se reserva el derecho a llevar a cabo las auditorías necesarias para comprobar el cumplimiento de las medidas de seguridad descritas en este pliego.
15.8 Compartición de recursos
Por motivos de garantizar la seguridad, cualquier compartición de recursos técnicos (infraestructura, hardware, etc.) utilizados en el marco de la ejecución del contrato será previamente justificada al cliente con un informe de análisis de beneficios y de riesgos, que este deberá aprobar.
Los adjudicatarios utilizarán la red, el hardware o el software propiedad de TMB exclusivamente para el uso o el beneficio de TMB.
15.9 Rescisión del contrato
TMB estará facultado para proceder a la resolución del contrato o acordar la continuidad de la ejecución con imposición de nuevas penalizaciones si se cumple una de las cuatro condiciones:
• El órgano de contratación podrá acordar la resolución anticipada del contrato tres o más meses después de la puesta en marcha, respecto de la fecha de puesta en marcha (inicio del contrato).
• Las penalizaciones por demora alcanzan un múltiplo del 5 por 100 del precio del contrato.
• El adjudicatario no proporciona uno o más de uno de los servicios solicitados en los puntos de operación del servicio o de cumplimiento de normativas aplicadas en este ámbito.
• Las penalizaciones por incumplimiento del servicio (según los SLA) alcanzan un 10 % mensual durante 3 meses.
La imposición de penalizaciones no excluye la indemnización a la que pueda tener derecho TMB por los daños y perjuicios ocasionados por el retraso o actuación imputable al licitador.
15.10 Transición del servicio
El adjudicatario debe presentar en la oferta un plan de transición del servicio para que, en el caso de que en el siguiente concurso no sea ganador, se pueda realizar el traspaso del servicio a la nueva empresa.
Es necesario que incluya:
• Listado de tareas en las que se ofrecerá soporte
• Estimación temporal en que se ofrecerá soporte (horas/persona o temporal)
15.11 Otras condiciones
El conjunto de herramientas utilizadas por el adjudicatario para la realización del proyecto no debe implicar la adquisición de licencias complementarias a las eventualmente necesarias en forma operativa. TMB requiere una documentación de todas las herramientas utilizadas para el desarrollo en formato digital. Además, se requiere la producción y entrega de la documentación técnica relativa a la implementación.