Contratación de servicio para la implantación y suscripción de una herramienta para realizar la debida diligencia a terceros, y seguimiento transacciona

1. REQUISITOS DE ADMISIBILIDAD
1.1 El oferente deberá cumplir y demostrar el cumplimiento de los siguientes requisitos de admisibilidad, para lo cual el administrador del contrato (AC) se reserva el derecho de verificar y corroborar, a su entera satisfacción, la veracidad de la información aportada mediante la revisión de referencias, contratos, documentación de respaldo, así como cualquier otro medio que resulte pertinente.
1.1.1 El oferente deberá acreditar una experiencia mínima de cuatro (4) años, en la que haya implantado al menos seis (6) proyectos tecnológicos similares al requerido en el objeto contractual, según lo descrito en este pliego.
Dicha experiencia deberá haberse adquirido dentro de los últimos seis (6) años contados a partir de la fecha límite de presentación de ofertas.
Al menos dos (2) de los proyectos deberán haber sido implementados en instituciones bancarias, públicas o privadas, debidamente constituidas y autorizadas para operar como tales.
Para respaldar el cumplimiento de este requisito el oferente debe presentar una declaración jurada en la cual debe adjuntar y completar el siguiente cuadro. Se considerará el requisito cumplido si es posible verificar la información con los datos del contacto.

Institución contratante Fechas de ejecución Nombre detallado del servicio Descripción del servicio Datos de contacto
Correo electrónico / teléfono. En caso de ser contrataciones con el estado
Número del procedimiento de contratación

1.1.2 El oferente deberá demostrar que cuenta con un conjunto maduro de políticas, procesos, herramientas y controles propios de un Sistema de Gestión de Seguridad de la Información (SGSI). Para ello, deberá presentar documentación válida que demuestre que cuenta, por ejemplo, con una certificación vigente ISO/IEC 27001 o similar, o bien con una auditoría reciente, realizada por un tercero, que demuestre y declare que la empresa cuenta con la implementación y operación exitosa de un SGSI.

1.1.3 El oferente deberá aportar una declaración jurada firmada por su representante legal, en la que indique que cuenta con un equipo especializado en atención al cliente con al menos dos (2) años de experiencia prestando servicios de soporte a soluciones tecnológicas como la descrita en el objeto contractual, a saber, la herramienta SaaS ofrecida y los mecanismos de interconexión utilizados para integrarla con los sistemas del Banco.
1.1.4 El oferente deberá aportar una declaración jurada firmada por su representante legal, en la que indique que cuenta con un equipo técnico que será asignado al desarrollo de la presente contratación, el cual, en su conjunto, demuestra un dominio sólido y cubre a satisfacción todos los conocimientos y herramientas descritos en la siguiente tabla:

Para la interconexión entre la herramienta SaaS y el lago de datos del BCCR

Área tecnológica Conocimiento mínimo requerido Alcance esperado Experiencia mínima requerida
SQL Server / Azure SQL Dominio de SQL Server (T-SQL), lectura de datos, joins complejos, vistas y optimización de consultas Capacidad de consumir eficientemente un endpoint SQL Server expuesto por terceros Al menos 3 años trabajando con SQL Server en entornos productivos
Conectividad con el OneLake de Microsoft Fabric en Azure Conexión al OneLake de Microsoft Fabric en Azure mediante un endpoint de SQL u otro tipo de endpoint Integración estable y segura desde la plataforma SaaS hacia Microsoft Fabric Al menos 2 años integrando aplicaciones con bases de datos en Azure o con el OneLake de Microsoft Fabric
Seguridad en bases de datos Autenticación segura (Azure AD o credenciales gestionadas), uso de TLS, principio de mínimo privilegio Garantizar confidencialidad y no exposición indebida de datos Al menos 2 años aplicando controles de seguridad en accesos a BD
Arquitectura SaaS Arquitecturas desacopladas, control de concurrencia, pooling de conexiones Evitar impacto de cargas del SaaS sobre el endpoint de conexión del BCCR Al menos 3 años diseñando o manteniendo soluciones SaaS
Rendimiento y eficiencia Optimización de queries, paginación, filtros por fechas, control de consumo Uso responsable de recursos del lago de datos Al menos 2 años optimizando consultas en ambientes de Big Data
Manejo de errores y resiliencia Manejo de timeouts, reintentos controlados, fallos de red Integración robusta y tolerante a fallos Al menos 2 años implementando mecanismos de resiliencia
Plataforma Microsoft Conocimiento general de Azure y servicios PaaS/IaaS relacionados Comprensión del contexto operativo del endpoint Al menos 1 año trabajando con Azure

Para la interconexión entre la herramienta SaaS y los sistemas de BCCR
Área tecnológica Conocimiento mínimo requerido Alcance esperado Experiencia mínima requerida
Arquitectura API REST Consumo de APIs RESTful sobre HTTP/HTTPS Capacidad de invocar endpoints GET, POST, PUT y DELETE, manejo de códigos HTTP y versionado de APIs Al menos 3 años integrando sistemas empresariales vía API REST
Formato de intercambio JSON (serialización / deserialización) Construcción y validación de payloads JSON, manejo de esquemas y errores de validación Al menos 3 años trabajando con APIs JSON
Seguridad de transporte HTTPS / TLS Establecimiento de canales cifrados, validación de certificados del servidor Al menos 3 años en integraciones seguras
Autenticación por certificados digitales Mutual TLS (mTLS) con certificados de cliente Instalación, almacenamiento seguro y uso de certificados X.509 para autenticación de llamadas Al menos 2 años usando certificados digitales en integraciones B2B o financieras
Plataforma Microsoft Conocimiento de .NET (Core / moderno) Comprensión del stack tecnológico del BCCR, serialización, manejo de errores y compatibilidad Al menos 2 años en ecosistemas Microsoft (.NET)
Gestión de errores y resiliencia Manejo de errores técnicos y funcionales Reintentos controlados, manejo de timeouts, trazabilidad de fallos Al menos 2 años en integraciones críticas
Ambientes y despliegue Separación de ambientes (DEV / QA / PROD) Capacidad de operar en distintos endpoints y certificados por ambiente Al menos 2 años operando soluciones SaaS empresariales
Cumplimiento de seguridad Principios de seguridad institucional No uso de credenciales en texto plano, principio de mínimo privilegio Al menos 2 años en entornos regulados (financiero, gobierno)
Documentación técnica Documentación de integración Manual técnico de consumo de APIs, manejo de certificados y troubleshooting Al menos 6 meses de experiencia documentando integraciones
Pruebas de integración Pruebas funcionales y técnicas Pruebas de consumo, validación de errores, pruebas de regresión Al menos 2 años ejecutando pruebas de integración

1.1.5 Para acreditar el cumplimiento del presente requisito, el oferente debe aportar junto con la declaración jurada:

Curriculum vitae del personal propuesto, que incluya:
• Formación de los conocimientos y herramientas descritos
• Experiencia relevante
• Documentación o referencias laborales que respalden la experiencia indicada.

1.1.6 El cumplimiento de los requisitos podrá acreditarse de forma complementaria entre los miembros del equipo, sin que cada recurso deba cumplir individualmente con la totalidad de la experiencia o conocimientos requeridos.

1.1.7 Los administradores del contrato se reservan el derecho de verificar en cualquier momento la veracidad de la información aportada.

 

REQUERIMIENTOS TÉCNICOS GENERALES:
La presente contratación busca fortalecer la operatividad del Banco Central de Costa Rica, mediante 3 líneas a desarrollar:
2.1 Línea 1: Suscripción a una herramienta tecnológica:
2.1.1 Generalidades técnicas de la línea 1.
2.1.1.1. Junto con la herramienta tecnológica, el contratista deberá proporcionar al Banco un esquema de licenciamiento que le permita a los administradores del contrato asignar los usuarios necesarios para la administración, operación y gestión de la solución tecnológica para al menos 30 funcionarios.
2.1.1.2. Debe permitir la creación de los roles de al menos la siguiente forma:
Rol Descripción Derechos
Administrador del sistema Tiene la capacidad de definir parámetros, controlar accesos, gestionar funcionalidades del sistema y supervisar las acciones realizadas por otros usuarios
Debe poder configurarse más de un perfil con rol de administrador. • Crear, modificar, bloquear y eliminar usuarios.
• Asignar y revocar roles y permisos (un mismo usuario puede tener uno o varios roles).
• Configurar parámetros del sistema (reglas de negocio, flujos de aprobación, perfiles de riesgo, alertas, catálogos y formularios).
• Definir qué información y funcionalidades puede visualizar cada rol.
• Acceder a todos los módulos del sistema
• Consultar bitácoras, registros de auditoría y trazabilidad de acciones.
• Habilitar, deshabilitar o ajustar funcionalidades de la herramienta.
Usuario Operativo Usuario encargado de la gestión operativa de los procesos de debida diligencia, revisión y aprobación de casos, así como del registro y análisis de información relacionada con clientes, proveedores, empleados u otras partes interesadas.
Este rol integra funciones diferenciadas según el perfil asignado por el Administrador del sistema, tanto como funcionarios de la oficialía de cumplimiento, con todos los permisos, como usuarios específicos de áreas como: (Recursos Humanaos, Proveeduría) con funciones específicas. • Registrar y actualizar información (digitación) de formularios, expedientes y datos asociados a la debida diligencia.
• Analizar y revisar la información registrada, incluyendo alertas, perfiles de riesgo y transacciones.
• Aprobar, rechazar o devolver casos para corrección, conforme a los flujos definidos.
• Consultar expedientes, históricos y documentación asociada.
• Generar observaciones, comentarios y justificaciones dentro del sistema.
• Visualizar únicamente la información y módulos autorizados según su perfil específico.

2.1.1.3. La herramienta tecnológica debe poseer disponibilidad para brindar servicio durante las 24 horas del día, en horario de lunes a domingo, los 7 días de la semana.
2.1.1.4. La herramienta tecnológica debe permitir el registro de al menos 1 000 formularios de terceras partes (proveedores, empleados y usuarios (clientes) de la plataforma Central Directo del BCCR) por mes.
2.1.1.5. La herramienta tecnológica debe permitir el registro y análisis de al menos 10 000 transacciones realizados por clientes o inversionistas en Central Directo por mes.
2.1.1.6. Se debe garantizar la continuidad de negocio durante al menos un año, desde la puesta en marcha de la herramienta.
2.1.1.7. El contratista debe contar con un procedimiento que explique y garantice que, una vez finalizada la relación contractual con el Banco, se cuenta con la capacidad de entregar a la institución todos los datos registrados y generados desde sus sistemas en un formato compatible con las capacidades del Banco para leerlo. Los formatos de archivo aceptados por el BCCR serán: archivo de backup de SQL Server 2022 o una versión superior, y archivos Delta Lake (formato Apache Parquet).
2.1.1.8. Bajo el amparo de la correcta implementación de un SGSI (por ejemplo, la norma ISO/IEC 27001), entendiendo que los datos consultados de los sistemas del BCCR son confidenciales, sensibles y propiedad del Banco, el contratista debe garantizar que esta información será accesible solo por personas, procesos y sistemas autorizados.
2.1.1.9. El contratista debe garantizar que, en ningún momento, los datos de la institución fueron o serán compartidos con un tercero, y que, al término de la relación contractual, esos datos serán eliminados de sus sistemas. El contratista deberá garantizar el tratamiento confidencial de la información.

2.1.2 Descripción de los módulos requeridos como parte de la suscripción a la Herramienta:

2.1.2.1. Gestionar la Política “Conozca a su Cliente” a partir de los formularios recabados en la plataforma Central Directo:
2.1.2.1.1 Los formularios de la Política Conozca a su Cliente continuarán completándose por medio de la plataforma Central Directo, propiedad del BCCR (se conserva la forma de captar la información actual por parte del BCCR), por ello, la herramienta debe contar con la capacidad de conectarse mediante una interfaz computacional a dicha plataforma y recibir automáticamente la información del formulario y sus documentos adjuntos (Word, JPG, PDF, Excel) dentro de las 24 horas naturales posteriores al formulario completado por parte del interesado (potencial cliente).
2.1.2.1.2 En caso de ser requerido, debido a eventos inesperados donde la herramienta falle durante un determinado periodo, debe ser posible atender los formularios dentro de la plataforma de Central Directo, de modo que, al solucionarse la falla, la herramienta tenga la capacitad técnica de “sincronizar” la información que fue procesada por medio de Central Directo durante el tiempo sin disponibilidad de la herramienta.
2.1.2.1.3 Asimismo, la herramienta debe poder remitir hacia Central Directo el estatus del formulario, indicando si este fue “aprobado” o “rechazado”, según corresponda, durante el tiempo indisponible de la herramienta.

 

 

 

 

 

 

 

2.1.3 Realizar debida diligencia y debida diligencia ampliada a proveedores, empleados y usuarios (clientes) de Central Directo, clasificados por grupo.

2.1.3.1. Generalidades técnicas
2.1.3.1.1 La herramienta tecnológica debe permitir la realización de consultas automáticas y sistémicas de información disponible en listas restrictivas (nacionales, internacionales y propias de la entidad), fuentes abiertas, tales como: motores de búsqueda, medios de comunicaciones digitales, redes sociales, identificar y alertar sobre coincidencias que puedan llevar a conflictos de intereses entre las relaciones con el Banco (empleados, clientes de Central Directo y proveedores) y otros contenidos públicamente accesibles.
2.1.3.1.2 La debida diligencia realizada por la herramienta debe permitir la identificación de menciones, noticias alertas y señales de riesgo asociadas a las personas sujetas a análisis (clientes de Central Directo, proveedores, empleados)
2.1.3.1.3 La debida diligencia deberá realizarse en dos ocasiones:
2.1.3.1.3.1 En la vinculación inicial (preselección), tanto en el caso de cliente, proveedor, empleado u otra contraparte.
2.1.3.1.3.2 De forma periódica, al menos semestralmente.

2.1.3.1.4 En caso de encontrar coincidencias con alguna alerta, el sistema debe avisar de la coincidencia a los usuarios de la herramienta (funcionarios del BCCR)

2.1.3.2. Realizar debida diligencia y debida diligencia ampliada a usuarios (clientes) de Central Directo:

2.1.3.2.1 Además de la aplicación de lo anteriormente descrito en generalidades técnicas (sección 2.1.3.1), como parte de este proceso de debida diligencia, el sistema debe generar una alerta en el caso de que exista algún cliente de Central Directo con algún tipo de monitoreo transaccional pendiente de atender (justificaciones de movimientos atípicos sin atender) o si con anterioridad el cliente ha presentado detecciones o alertas por monitoreo transaccional y el estatus y tipo de justificación de estos.
2.1.3.2.2 La herramienta tecnológica deberá notificar al analista y bloquear la aprobación de formularios de la Política Conozca a su Cliente (KYC) a los clientes de Central Directo cuando el cliente mantenga pendiente la justificación derivada de un evento de monitoreo, ya sea. (Ver descripción completa en el punto 3.3)

2.1.3.3. Realizar la debida diligencia a proveedores:

2.1.3.3.1 Además de la aplicación de lo anteriormente descrito en generalidades técnicas (sección 2.1.3.1), como parte de este proceso de debida diligencia, en la atención a este proceso, la herramienta debe proveer algún mecanismo que permita la carga de los datos relacionados con la información de proveedores para aplicar la evaluación de perfiles de riesgo y realizar la debida diligencia sobre este segmento de terceras partes.
2.1.3.3.2 El mecanismo debe estar abierto a ajustes en los datos que se suministren de cada proveedor y en el método utilizado para calcular el perfil de riesgo, de modo que se genere un historial de las actualizaciones y los cambios realizados, así como información del usuario que registra la actualización o bitácoras.
2.1.3.3.3 Como parte de este proceso de debida diligencia el sistema debe generar una alerta si el proveedor posee alertas en anteriores aplicaciones de la debida diligencia o debida diligencia ampliada. (Ver descripción completa en el punto 3.3)

 

 

2.1.3.4. Realizar la debida diligencia a empleados:
2.1.3.4.1 Además de la aplicación de lo anteriormente descrito en generalidades técnicas (sección 2.1.3.1), como parte de este proceso de debida diligencia, en la atención a este proceso, la herramienta debe proveer algún mecanismo que permita la carga de los datos relacionados con la información de empleados para aplicar la evaluación de perfiles de riesgo y realizar la debida diligencia de este segmento de terceras partes.
2.1.3.4.2 El mecanismo debe estar abierto a ajustes en los datos que se suministren de cada empleado y en el método utilizado para calcular el perfil de riesgo, de modo que se genere un historial de las actualizaciones y los cambios realizados, así como información del usuario que registra la actualización y bitácoras.
2.1.3.4.3 Como parte de este proceso de debida diligencia el sistema debe generar una alerta si el empleado posee alertas en anteriores aplicaciones de la debida diligencia o debida diligencia ampliada. (Ver descripción completa en el punto 3.3)

2.1.3.5. Calcular perfiles de riesgo, a partir de matrices:
2.1.3.5.1 El sistema debe permitir a partir de las categorías o segmentos de terceras partes (cliente de Central Directo, proveedor, empleado) definir matrices con variables de riesgo, parametrizables para cada tipo de categoría, y para cada momento requerido (primer ingreso de un cliente, empleado proveedor, al sistema, y en el transcurso de la relación comercial) cada una de estas variables deben permitir la asignación de pesos porcentuales, tanto con una matriz para la primera vinculación como en el mantenimiento de perfiles, cada seis meses.
2.1.3.5.2 De forma automática debe calcular la calificación del riesgo total por cada categoría.
2.1.3.5.3 Generando una escala visual (por colores o signos clasificatorios) parametrizable bajo autorización del usuario con rol de administrador (muy bajo, bajo, medio, alto, muy alto)
2.1.3.5.4 La herramienta debe permitir la actualización automática y dinámica del nivel de riesgo cuando se den cambios en los datos críticos.
2.1.3.5.5 La herramienta debe permitir que uno de los datos por parametrizar en el desarrollo de los perfiles de riesgo, sean los históricos de las ocasiones en que el usuario haya sobrepasado su límite transaccional, cuando se trate de clientes de Central Directo o un empleado o proveedor que haga uso de este servicio.
2.1.3.5.6 La herramienta debe poder identificar y alertar mediante alguna notificación cuando un formulario en proceso de gestión pertenece a una persona ya registrada en algún otro tipo de categoría (cliente de Central Directo, proveedor, empleado)
2.1.3.5.7 La herramienta tecnológica debe mostrar alertas automáticas cuando la persona monitoreada presente riesgos elevados.
2.1.3.5.8 La herramienta tecnológica debe permitir la visualización permanente del perfil de riesgo de cada persona, según su categoría (cliente de Central Directo, proveedor o empleado), en toda consulta, revisión o reporte generado por el sistema, mediante un indicador gráfico (por ejemplo: código de colores y/o señal gráfica).
2.1.3.5.9 La herramienta tecnológica debe integrar como parte de su matriz de riesgo, un indicador que utilice la debida diligencia aplicada en cualquier de sus dos momentos (2.1.3.1.3)), para recalcular el nivel de riesgo de los clientes, proveedores y empleados.

2.1.3.6. Generar el monitoreo de las transacciones realizadas por los clientes de Central Directo.
2.1.3.6.1 La herramienta tecnológica deberá realizar un monitoreo diario y mensual que permita acumular los ingresos de fondos a las cuentas registradas en Central Directo, tanto en colones como en dólares, y generar alertas inmediatas cuando el usuario supere su límite transaccional, ya sea en un día específico o a la hora de superar la suma acumulada mensual, conforme al estimado de operaciones aprobado en la política de Conozca a su Cliente.
2.1.3.6.2 Asimismo, el sistema debe integrar los perfiles de riesgo en la lógica de monitoreo, de manera que, cuando una persona supere su límite transaccional y posea un perfil de riesgo relevante (medio, alto, muy alto) se generen alertas prioritarias, permitiendo al analista una respuesta más oportuna y enfocada.
2.1.3.6.3 Cuando se aplique el monitoreo, la herramienta deberá comunicarse con la plataforma Central Directo de manera que, si un usuario resulta observado o marcado en el proceso de monitoreo, se le comunique que se le otorga un plazo de hasta quince (15) días para justificar la transacción correspondiente.
2.1.3.6.4 En caso de que el usuario no presente la justificación dentro del plazo establecido, la herramienta deberá gestionar automáticamente la comunicación con Central Directo para poner en estado vencido el formulario de la Política Conozca a su Cliente (KYC), conforme a los procedimientos definidos por el Banco Central de Costa Rica.
2.1.3.6.5 Se explica el flujo existente del monitoreo y su relación con los formularios, las reglas de parametrización en el apartado 3.5
2.1.3.6.6 El perfil de riesgo debe estar presente en el reporte del monitoreo, tanto diario como mensual.

2.1.3.7. Realizar reportería.

2.1.3.7.1 La herramienta debe permitir la parametrización de reportes, según lo requerido en el apartado 3.6

2.1.3.8. Mantenimiento y actualización.

2.1.3.8.1 Dentro del costo de la suscripción deberán incluirse los costos de mantenimiento regular de la herramienta tecnológica, asociados a la atención de fallos o anomalías propias de su funcionamiento, así como los procesos de actualización necesarios para su adecuada operativa y funcionalidad requerida.

3. LÍNEA 2: IMPLANTACIÓN E INTEGRACIÓN:

3.1 Especificaciones técnicas generales.

3.1.1 La herramienta debe permitir que el BCCR realice la gestión de accesos y seguridad, a través de usuarios con roles específicos con la potestad de crear, editar y eliminar usuarios.
3.1.2 La herramienta debe poder integrarse con el lago de datos del BCCR que reside en el OneLake de Microsoft Fabric.
3.1.3 Se debe cumplir con los requerimientos de seguridad especificados por las políticas de ciberseguridad del BCCR vigentes que se detallan más adelante en la sección de anexos.
3.1.4 La herramienta debe ser compatible con la infraestructura tecnológica del Banco Central de Costa Rica y con el Portal Central Directo, garantizando su correcta interacción para establecer una comunicación bidireccional que permita recibir y remitir de forma segura y oportuna la información relacionada con la aprobación o rechazo de los formularios correspondientes a la Política de Conozca a su Cliente.
3.1.5 Brindar la posibilidad de personalizar perfiles de riesgo y alertas de acuerdo con los parámetros definidos por el Banco Central de Costa Rica, para determinar el nivel de riesgo de los clientes de Central Directo, proveedores y empleados.
3.1.6 Incorporar criterios de análisis para cada uno de los grupos y establecer un peso y una fórmula que permita generar el nivel de riesgo de acuerdo con una escala de cinco niveles, (Muy bajo, Bajo, Medio, Alto, Muy alto) los cuales deben mostrarse para cada persona física o jurídica incluida monitoreada en la herramienta, con un diseño que gráficamente exponga su nivel de riesgo vigente.
3.1.7 La herramienta deberá permitir recibir e integrar la información completa de los formularios de la Política Conozca a su Cliente (KYC) desde la plataforma de Central Directo, lo cual incluye la posibilidad de cargar todos los documentos asociados que pueden estar formato PDF, Word, Excel, archivos de imagen (.jpg), y otros formatos similares.
3.1.7.1.1 La herramienta debe tener la posibilidad de cargar la información, atributos y variables de riesgo captados por el Banco Central, sobre las terceras partes (clientes, proveedores y empleados) con sus documentos que permitan constatar evidencia, en formatos como PDF, Word, Excel, imágenes (.jpg) y otros similares, para efectos de análisis, gestión y seguimiento.
3.1.8 Además, la herramienta debe permitir clasificar el tipo de tercera parte según la categoría correspondiente: clientes (usuarios de Central Directo) empleados, proveedores, los cuales tendrán como identificador principal su número de identificación, física o jurídica. Esta segmentación debe ser parametrizable por parte de un funcionario del BCCR, pudiendo integrar clasificaciones o segmentaciones adicionales.
3.1.9 La herramienta debe incluir pistas de auditoría o bitácora que permitan mantener la trazabilidad de las acciones realizadas en el sistema (acción realizada, quién la ejecutó, y cuándo se ejecutó).

3.2 Especificaciones técnicas para autenticación y roles.

3.2.1 La herramienta deberá permitir la gestión de roles y permisos por niveles de seguridad, según la función de cada usuario, e incluir un rol de administrador con facultades para crear usuarios, asignar/modificar permisos y parametrizar la debida diligencia.
3.2.2 Debe existir un rol de analista que permita a los usuarios consultar y revisar los expedientes de los usuarios (clientes) de Central Directo, revisar transacciones, aprobar y reprobar transacciones
3.2.3 La herramienta debe contar con un sistema de identificación de usuarios de doble factor que implemente las mejoras prácticas de seguridad para resguardar la información de los usuarios de la herramienta. Los controles de seguridad del BCCR autentican a sus usuarios a través de Microsoft Entra ID, por lo que se recomienda que la herramienta aproveche esta tecnología y permita la integración con los sistemas de seguridad del Banco.

3.3 Especificaciones técnicas para módulo “Debida Diligencia”

3.3.1 La debida diligencia debe poder realizarse de forma regular para todos los clientes o terceros (proveedores, empleados) según clasificación brindada por la Administración; y la debida diligencia ampliada o reforzada en caso de requerirse según el perfil de riesgo del consultado, por lo que la herramienta debe:
3.3.2 Cuando un usuario se inscribe en Central Directo, por medio del “formulario Conozca a su Cliente, se debe poder recibir automáticamente el formulario para estudio en la herramienta tecnológica, 24 horas naturales después de que el interesado lo complete, junto con los demás datos vinculados en el lago de datos, así como los adjuntos que tenga el formulario.
3.3.2.1. Al ingresar el analista al sistema debe de tener una bandeja o pantalla en donde se enlisten los formularios pendientes por revisar, y analizar la información.
3.3.2.2. Permitir digitar o incorporar manualmente un formulario con la información de tercera parte (empleado, proveedor y otro) que requiera formar parte del repositorio de datos.
3.3.2.3. La herramienta debe tener la funcionalidad de realizar y guardar filtros o búsquedas por medio del número de identificación, nombre completo o estatus del formulario en la en la base de datos de las personas con formulario en cualquier tipo de estatus.
3.3.3 La herramienta debe contener un motor de información, que permitir realizar consultas por medio de la cédula de identidad, física, jurídica o DIMEX, de la persona de interés; sobre esta consulta presentar un reporte parametrizable, con, pero no limitado a la siguiente información:
3.3.3.1. Cualquier información relacionada con la Ley 8204 Ley Sobre Estupefacientes, Sustancias Psicotrópicas, Drogas de uso no Autorizado, Actividades Conexas, Legitimación de Capitales y Financiamiento al Terrorismo.
3.3.3.2. Información y alertas de personas expuestas políticamente.
3.3.3.3. Detección en listas restrictivas (internacionales y nacionales), se debe utilizar como referencia la lista del Grupo de acción financiera internacional (GAFI) y cualquier otra que se considere adicional, tales como: listas Oficina de control de activos extranjeros (OFAC), Organización internacional de policía criminal (INTERPOL), Personas expuestas políticamente (PEP´s) nacionales y extranjeros, Administración de control de drogas de Estados Unidos (DEA), entre otras que permitan identificar individuos vinculados con actividades relacionadas al Lavado de Activos / Financiamiento del terrorismo (LA/FT), tanto a la hora de la vinculación como durante el seguimiento.
3.3.3.4. Y listas locales que se entienden como aquella base de datos interna creada y administrada por la Institución, la cual se conforma mediante la inclusión manual de personas físicas o jurídicas que han sido identificadas por la Administración como asociadas a situaciones de riesgo, conflictos, alertas o anomalías relevantes para los procesos de debida diligencia y gestión de cumplimiento.
3.3.4 Se debe realizar un monitoreo a las personas registradas en el sistema con una frecuencia mensual, es decir, una revisión general de los clientes registrados en Central Directo, proveedores y empleados, incluidos en sistema, con el fin de detectar cambios en el comportamiento de estas terceras partes.
3.3.5 La herramienta deberá permitir el monitoreo de usuarios y contrapartes mediante la revisión de medios en internet, a fin de identificar vínculos con noticias o menciones relacionadas con legitimación de capitales, lavado de activos, financiamiento al terrorismo, proliferación de armas de destrucción masiva u otros delitos.

3.3.5.1. En el caso de debida diligencia a clientes de Central Directo:

3.3.5.1.1 Una vez realizada la debida diligencia (revisión de los antecedentes de los usuarios (clientes) que registran el formulario de la “Política Conozca a su Cliente” en Central Directo) se debe poder enviar de forma automática el resultado de la evaluación del formulario, ya sea aprobado o rechazado, al sistema de Central Directo para que sea éste quien remita la notificación al cliente.
3.3.5.1.2 En el caso de ser rechazado, junto con el resultado de la evaluación se debe enviar el motivo del rechazo, mismo que debe ser parametrizable; lo anterior alineado con la lista predeterminada y ya existente en el BCCR, con los motivos de rechazo.
3.3.5.1.3 Cada vez que un usuario (cliente) modifique un formulario rechazado para subsanar lo solicitado, la herramienta deberá recibir la notificación de la modificación y habilitar la revisión de la información actualizada.
3.3.6 La herramienta deberá crear y mantener un expediente por usuario, utilizando como identificador principal único su número de identificación, en el que se registren las transacciones, el historial de formularios KYC (versiones), y, cuando aplique, los motivos de rechazo, la cantidad de intentos de registro y el historial de cambios que ha sufrido ese formulario. Asimismo, deberá asignar la categoría y nivel de riesgo del cliente y detectar usuarios de riesgo alto, mediante la parametrización de variables definidas por el BCCR y buenas prácticas de cumplimiento.
3.3.7 Asimismo, en este expediente deberá registrarse el historial de monitoreo, el estado del monitoreo y deberá ser capaz de recibir adjuntos tales como: justificaciones aportadas, incluyendo correos electrónicos, documentos en formato PDF, imágenes u otros archivos remitidos por el cliente
3.3.8 En el caso de perfiles correspondientes a otras terceras partes, el sistema deberá permitir el registro y la conservación de la información requerida para efectos de la debida diligencia. Asimismo, como parte del proceso de análisis, la solución deberá mostrar de forma gráfica el resultado del perfil de riesgo asociado a la persona evaluada, utilizando una escala de cinco niveles de riesgo: muy bajo, bajo, medio, alto y muy alto.
3.3.9 La solución deberá mantener, en todo momento durante la consulta de personas físicas o jurídicas, la visualización gráfica del perfil de riesgo resultante para cada cliente. Asimismo, deberá permitir la actualización de dicho perfil cuando se modifiquen datos que, conforme a criterios preestablecidos por el BCCR, impliquen un aumento o disminución en el nivel de riesgo.
3.3.10 La solución deberá permitir la construcción, evaluación y mantenimiento de perfiles de riesgo, para lo cual deberá requerir y gestionar, como mínimo, información estructurada y actualizada de las personas físicas o jurídicas objeto de análisis. Dicha información deberá incluir datos de identificación, características del cliente o tercera parte, actividad económica, comportamiento transaccional, relaciones o vínculos relevantes, resultados de consultas a listas restrictivas y cualquier otra variable definida por el BCCR. El sistema deberá procesar estos insumos conforme a los criterios, ponderaciones y metodologías preestablecidas por el Banco, a fin de determinar el nivel de riesgo correspondiente, así como soportar su revisión y actualización cuando se presenten cambios relevantes en la información evaluada.

3.4 Especificaciones técnicas para la creación de perfiles de riesgo.

3.4.1 Al ingresar el formulario de la “Política Conozca a su Cliente/proveedor/empleado” se debe crear un perfil de riesgo de cada persona, para lo cual la herramienta debe permitir establecer variables con su respectivo peso, matrices de riesgo, que posteriormente se ponderarán para obtener una calificación del riesgo asociado a esa persona. Las variables y criterios de evaluación de estas serán definidas por el BCCR. Por ejemplo: incluir como variables de riesgos la profesión y la zona de domicilio de una persona. La profesión en este ejemplo tendrá un peso de 10% y la zona de vivienda tendrá un 5% en la calificación de riesgo.
3.4.2 Permitir para cada una de las terceras partes analizadas (grupo de proveedores, empleados, usuarios (clientes) de CD y cualquier otra clasificación) establecer fórmulas independientes por clasificación, para poder medir cada agrupamiento según las variables, criterios y pesos de estos que se consideren para cada uno de los grupos.
3.4.3 Procesar los datos obtenidos de forma automática y a partir de ellos automatizar, estandarizar y crear el perfil de riesgo de cliente determinado según los criterios considerados por el Banco para cada uno de los grupos de terceras partes clasificados.
3.4.4 Los resultados del nivel de riesgo deben brindarse en una escala con 5 valores: muy bajo, bajo, medio, alto y muy alto, que estará basada en la calificación total que se le puede dar a cada persona. Por ejemplo, una calificación 0 – 20 muy bajo, 21-40 bajo, etc. La escala y los valores de cada intervalo deben ser parametrizables y al inicio del contrato los definirá el Banco Central de Costa Rica para iniciar con la funcionalidad.
3.4.5 La herramienta por contratar deberá permitir la modificación manual de los criterios y variables de las matrices de riesgo y, a partir de dichas modificaciones, realizar la actualización automática, inmediata y consistente de los perfiles de riesgo vigentes de cada persona, conforme a la ponderación definida por el Banco Central de Costa Rica. Esta actualización deberá reflejarse de forma inmediata en el nivel de riesgo asignado, garantizando la trazabilidad, consistencia y alineación del perfil con los parámetros institucionales y con las mejores prácticas en materia de prevención de legitimación de capitales, financiamiento al terrorismo y delitos conexos.

3.5 Especificaciones técnicas para el módulo “Monitoreo Transaccional”.

3.5.1 Objetivo del monitoreo
3.5.1.1. El monitoreo transaccional de los clientes de la plataforma Central Directo, tiene como objetivo identificar de forma continua, automática y oportuna desviaciones, inconsistencias o comportamientos atípicos respecto del perfil transaccional y de riesgo aprobado de las personas sujetas a debida diligencia, con el fin de generar alertas, solicitar y gestionar justificaciones, documentar evidencias, actualizar estados y ajustar perfiles de riesgo, conforme a la normativa interna y los criterios definidos por el Banco Central de Costa Rica (BCCR) de forma diaria y mensual.
3.5.1.2. Para ello la herramienta deberá registrar automáticamente toda nueva transacción que ingrese a las cuentas registradas en Central Directo, tanto en colones como en dólares.

3.5.2 Tipos de monitoreo
3.5.2.1. El monitoreo diario deberá identificar, en modalidad T-1, toda transacción individual o acumulado diario de transacciones que supere el límite transaccional mensual autorizado, a efectos de su análisis y debida diligencia, conforme al proceso descrito en el punto 3.3.5.1.
3.5.2.2. El monitoreo mensual deberá identificar, en modalidad T-1, toda transacción individual o acumulado mensual de transacciones que supere el límite transaccional mensual autorizado, incluyendo aquellas transacciones que hayan sido justificadas durante el monitoreo diario, las cuales deberán señalarse expresamente como justificadas y desplegarse para analizar a detalle por transacción, con el fin de realizar un análisis integral del comportamiento transaccional, conforme al proceso descrito en el punto 3.3.5.1.
3.5.2.3. Ambos tipos de monitoreo deberán operar bajo la misma lógica de análisis, gestión de alertas y control, diferenciándose únicamente por su periodicidad de ejecución.

3.5.3 Ejecución del monitoreo: (únicamente para clientes Central Directo)
La herramienta debe:
3.5.3.1. Obtener el total de fondos frescos ingresados a las cuentas de Central Directo para cada uno de los clientes y dolarizarlos al tipo de cambio del día de la operación.
3.5.3.2. En caso de que el monto total transado sobrepase el perfil transaccional autorizado en el formulario “conozca a su cliente”, la herramienta debe:
3.5.3.2.1 Vincular cada transacción de forma inequívoca al expediente del usuario, utilizando el número de identificación como identificador principal. Analizar cada transacción mediante el motor de reglas y/o algoritmos, evaluando:
3.5.3.2.1.1 El monto individual de la transacción con relación al perfil transaccional.
3.5.3.2.1.2 Los acumulados diarios y mensuales con relación al perfil transaccional.
3.5.3.2.1.3 La comparación contra los límites transaccionales autorizados.
3.5.3.2.1.4 Las variables y reglas asociadas al perfil de riesgo vigente.
3.5.3.2.1.5 Verificar si existe una justificación anticipada o excepción vigente; de no existir, la transacción deberá ser marcada como atípica e incorporada al reporte de monitoreo correspondiente.
3.5.3.2.1.6 El tipo de transacción realizada con los montos ingresados a la cuenta:
3.5.3.2.1.6.1 Instrumento de inversión
3.5.3.2.1.6.2 Compra- venta de divisas
3.5.3.2.1.6.3 Transferencia de fondos

3.5.3.2.2 El reporte de monitoreo debe unificar a todos los clientes que sobrepasan su perfil transaccional, de modo que le permita al analista:
3.5.3.2.2.1 Excluir transacciones del monitoreo por consistencias con el perfil.
3.5.3.2.2.2 Solicitar justificaciones al cliente mediante un correo electrónico parametrizable, (Para el envío de correos desde la herramienta se va a ofrecer un componente en BCCR que pueda ser invocado desde la herramienta SaaS, que reciba el cuerpo del mensaje y demás datos que se pueda comunicar) donde parte de la información a comunicar es:
3.5.3.2.2.2.1 Fecha y hora del evento
3.5.3.2.2.2.2 Fecha límite para presentar la justificación, 15 días naturales (parametrizable por la Administración)
3.5.3.2.2.2.3 Dirección de correo electrónico a la que debe remitir la justificación.
3.5.3.2.2.2.4 Cuerpo del correo parametrizable
3.5.3.2.2.2.5 Resguardar bitácoras completas.

3.5.4 Justificación presentada dentro del plazo: Si el cliente presenta una justificación válida:
3.5.4.1. La herramienta deberá permitir cargar la documentación de respaldo.
3.5.4.2. Registrar el análisis y conclusiones del funcionario.
3.5.4.3. Incorporar el evento al histórico del perfil de riesgo.
3.5.4.4. Establecer períodos de excepción para siguientes transacciones.

3.5.5 Incumplimiento del plazo: Si el cliente no justifica dentro del plazo de los 15 días naturales:
3.5.5.1. El sistema deberá cambiar el estatus del formulario KYC a “aprobado-vencido”.
3.5.5.2. Comunicar automáticamente a Central Directo para: Reflejar el estatus de aprobado-vencido y comunicar a Central Directo para inhabilitar los servicios de compra y venta de dólares y constitución de inversiones.
3.5.5.3. Establecer dentro de la herramienta el estado del cliente, como “Pendiente por monitoreo”.
3.5.5.4. Imposibilitar que se le apruebe un nuevo formulario de la Política Conozca a su cliente, hasta que presente una justificación y el analista “libere” el proceso.
3.5.6 Limitación para la aprobación de formularios (KYC) por justificación de monitoreo pendiente:
3.5.6.1. En aquellos casos en que el cliente no haya atendido o presentado la justificación derivada de un evento de monitoreo (considerándose cliente inhabilitado), el sistema deberá restringir la aprobación de nuevos formularios de la Política Conozca a su Cliente (KYC) para dicho cliente, hasta tanto se haya gestionado y validado la justificación correspondiente. Sin que ello implique el limitar la recepción de los nuevos formularios del Cliente proveniente de Central Directo

3.5.7 Justificaciones posteriores al plazo: en los casos donde el cliente justifique posterior al plazo, la herramienta debe:
3.5.7.1. Mantener el estatus del formulario KYC como “aprobado-vencido”.
3.5.7.2. Liberar el proceso para que el analista pueda aprobar un nuevo formulario de la Política Conozca a su cliente del Cliente
3.5.8 Actualización del perfil de riesgo: Como resultado del monitoreo, la herramienta deberá:
3.5.8.1. Permitir la actualización automática o manual del perfil de riesgo.
3.5.8.2. Registrar el historial de cambios.
3.5.8.3. Generar alertas internas ante cambios relevantes de nivel de riesgo.

3.5.9 Inactivar a un cliente de oficio:
3.5.9.1. En caso de que se detecte un cliente con coincidencias en listas restrictivas o con motivos inaceptables para continuar siendo cliente del BCCR, se debe de generar la alerta inmediata para inhabilitar el formulario de Conozca a su Cliente y cambiar el estatus del formulario a aprobado-vencido de inmediato.
3.5.10 Gestión de excepciones y justificaciones anticipadas
3.5.10.1. La herramienta deberá permitir la creación, gestión y control de justificaciones anticipadas, las cuales deberán:
3.5.10.1.1 Quedar ligadas al identificador principal del cliente.
3.5.10.1.2 Generar un período de excepción en el monitoreo, durante el cual las operaciones justificadas no generen alertas, mientras la justificación esté vigente (tiempo y monto).
3.5.10.1.3 Permitir justificar montos acumulables en varias transacciones diarias o mensuales.
3.5.10.1.4 Vincularse al perfil transaccional y de riesgo.
3.5.10.1.5 Estar disponibles para consulta por los usuarios del BCCR.
3.5.10.1.6 Ser consideradas automáticamente o mediante revisión manual en el análisis de alertas.
3.5.10.1.7 Generar una bitácora histórica de justificaciones y de los funcionarios que las crean o modifican.

3.5.11 Detección y generación de alertas:
3.5.11.1. El algoritmo de la herramienta deberá identificar y alertar sobre patrones inusuales de comportamiento transaccional, entendidos como aquellas operaciones atípicas.
3.5.11.2. Cuando el monitoreo identifique una desviación o condición de riesgo, la herramienta deberá: Generar una alerta automática, asociar la alerta al expediente de la persona correspondiente
3.5.11.3. La herramienta debe generar un reporte, diario y mensual de los usuarios de Central Directo que sobrepasen su perfil transaccional, dicho reporte debe contener al menos siguiente información:
3.5.11.3.1 Periodo del monitoreo
3.5.11.3.2 Identificación de la persona física o jurídica.
3.5.11.3.3 Nombre completo de la persona física o jurídica
3.5.11.3.4 Estado del formulario
3.5.11.3.5 Estimado de Operaciones aprobado en el formulario “Conozca a su Cliente” (KYC)
3.5.11.3.6 Monto de ingresos según el KYC
3.5.11.3.7 Monto mensual/diario transaccionado que sobrepasa el perfil transaccional
3.5.11.3.8 % de variación entre el perfil aprobado y el monto transado.
3.5.11.3.9 Fuente de ingresos según el KYC
3.5.11.3.10 Tipo de persona según el KYC
3.5.11.3.11 Persona políticamente expuesta, según el KYC.
3.5.11.3.12 Nivel de riesgo asociado.

3.5.12 Registro y trazabilidad.
3.5.12.1. Todo el proceso de monitoreo deberá quedar:
3.5.12.1.1 Íntegramente documentado en el expediente digital de la persona.
3.5.12.1.2 Con historial de alertas, estados, notificaciones, justificaciones y decisiones.
3.5.12.1.3 Disponible para consulta, auditoría y generación de reportes.

3.6 Especificaciones técnicas para la generación de reportería.

3.6.1 La solución deberá utilizar el número de identificación de la persona física o jurídica (con estructura numérica y alfanumérica), como identificador principal, para el almacenamiento, gestión y explotación de la información en el repositorio de datos, así como para la generación de reportes y consultas asociadas.
3.6.2 La herramienta deberá generar reportes con estadísticas operativas y de gestión del sistema. Asimismo, deberá permitir la creación de reportes personalizados mediante el uso de filtros parametrizables, a partir de la información que se encuentre incorporada en la herramienta. Los reportes generados deberán ser exportables, al menos en formatos PDF, Excel y Word, utilizando plantillas o diseños predefinidos para cada formato, que aseguren consistencia, legibilidad y uso institucional de la información.
3.6.3 Como ejemplo de los reportes requeridos se detallan los siguientes:
3.6.3.1. Reporte de la política KYC de Central Directo:
3.6.3.1.1 Este reporte deberá presentar la información agregada de los formularios correspondientes a la Política “Conozca a su Cliente” gestionados en Central Directo, incluyendo aquellos que hayan sido aprobados y rechazados, dicho reporte debe contener al menos siguiente información:
o Nombre del reporte
o Fecha y hora de generación
o Usuario que generó el reporte
o Período consultado (año-mes)
o Cantidad mensual de formularios aprobados
o Cantidad mensual de formularios rechazados
o Comparaciones relevantes (mes anterior, promedio histórico)
o Observaciones automáticas se refiere a notas generadas por el sistema, como, por ejemplo:
o “Incremento del 15% respecto al mes anterior”
o Generación de gráfico
3.6.3.2. Reporte de debida diligencia.
3.6.3.2.1 Información agregada para debida diligencia ampliada (seguimiento de operaciones) a clientes de Central Directo:
o Nombre del reporte
o Fecha y hora de generación
o Usuario que generó el reporte
o Período consultado (año-mes)
o Cantidad mensual de clientes a quienes se les aplicó la debida diligencia ampliada
o Comparaciones relevantes (mes anterior, promedio histórico)
o Observaciones automáticas se refiere a notas generadas por el sistema, como por ejemplo:
o “Incremento del 15% respecto al mes anterior”
o Generación de gráfico

3.6.3.3. Reporte de clientes físicos y jurídicos

3.6.3.3.1 Información agregada para la cantidad de clientes físicos y jurídicos activos en Central Directo
o Nombre del reporte
o Fecha y hora de generación
o Usuario que generó el reporte
o Período consultado (año-mes)
o Cantidad total de clientes físicos y jurídicos con estado “activo”

3.6.3.4. Reportes individualizados
3.6.3.4.1 Información historial individual Persona Física o jurídica de formularios de la política conozca a su cliente de Central Directo utilizando como variable el ID del cliente (al reporte debe incluirse todos los campos del formulario en Central Directo):

o Nombre del reporte
o Fecha y hora de generación
o Usuario que generó el reporte
o Nivel de riesgo asociado
o Estado del formulario
o Fecha de revisión
o Número de Cédula del cliente de Central Directo
o Nombre asociado
o Fecha de nacimiento
o Estado civil
o Nacionalidad
o Lugar de nacimiento
o Sexo
o Teléfono 1
o Teléfono 2
o Provincia
o Cantón
o Distrito
o Dirección exacta
o Correo electrónico 1
o Correo electrónico 2
o Políticamente expuesto
o Profesión u ocupación
o Nombre del empleador o actividad independiente
o Puesto
o Rango Ingresos mensuales
o Rango Estimado de operaciones
o Origen de los fondos
o Actividad económica declarada
o Nombre del Patrono
o Dirección del patrono

3.6.3.5. En caso de persona jurídica considerar la siguiente información, más, todos los campos del formulario en Central Directo
3.6.3.5.1 Información sobre el historial individual de persona jurídica de formularios de la política conozca a su cliente de Central Directo utilizando como variable el ID del cliente:
o Nombre del reporte
o Fecha y hora de generación
o Usuario que generó el reporte
o Estado del formulario
o Fecha de revisión
o Número de Cédula jurídica del cliente de Central Directo
o Razón social
o Fecha de constitución
o Descripción de la actividad
o Rango de ingresos
o Estimado de operaciones
o Descripción de otros ingresos
o Nombre representante legal
o Número de Identificación
o Estado civil
o Sexo
o Nacionalidad
o Lugar de nacimiento
o Provincia
o Cantón
o Distrito
o Dirección exacta
o Teléfono 1
o Teléfono 2
o Correo electrónico 1
o Correo electrónico 2

3.6.4 La herramienta deberá enviar alertas y reportes (incluido el análisis y cambios en el nivel de riesgo) al correo electrónico que el BCCR designe, cuando se detecten coincidencias en listas restrictivas nacionales o internacionales, tomando como referencia la lista del GAFI y otras listas aplicables (p. ej., OFAC, INTERPOL, PEP nacionales y extranjeros, DEA, entre otras).
3.6.5 La herramienta deberá generar un reporte tipo mapa de calor con base en la escala de riesgo del BCCR (muy alto, alto, medio, bajo y muy bajo), que muestre la cantidad y el porcentaje de personas en cada nivel. Este reporte deberá ser parametrizable, permitiendo, entre otros, su visualización de acuerdo con la matriz de variables para el perfilamiento de riesgos Contenido del reporte:

3.6.5.1. Nombre del reporte: Información del riesgo de la cartera de clientes.
3.6.5.1.1 Objetivo: Generar estadísticas que permitan identificar la composición y comportamiento de la cartera de clientes según su nivel de riesgo de AML (Bajo, Medio, Alto), con el fin de monitorear tendencias, identificar segmentos sensibles y evaluar la efectividad del modelo de perfilamiento
Funcionalidades del reporte:
o Fecha y hora de generación
o Usuario que generó el reporte
o Período consultado (año-mes)
o Total de clientes por nivel de riesgo AML: Bajo / Medio / Alto
o % del portafolio por nivel de riesgo
o Variación mensual del número de clientes por nivel de riesgo
o % de clientes nuevos clasificados como riesgo Alto
o Generación de gráficos

3.6.6 La herramienta deberá crear, administrar y modificar las matrices de riesgo LA/FT/PADM, conforme al perfil de riesgo definido por el BCCR, contemplando tanto el riesgo inherente como el riesgo residual
3.6.7 Generar los reportes requeridos para la debida gestión interna en caso de operaciones atípicas.
3.6.7.1. Como ejemplo de los reportes requeridos se detallan los siguientes:
3.6.7.1.1 Información agregada para debida diligencia ampliada (seguimiento de operaciones) a clientes de Central Directo:
o Nombre del reporte
o Fecha y hora de generación
o Usuario que generó el reporte
o Período consultado (año-mes)
o Cantidad mensual de clientes a quienes se les aplicó la debida diligencia ampliada
o Comparaciones relevantes (mes anterior, promedio histórico)
o Observaciones automáticas se refiere a notas generadas por el sistema, como, por ejemplo:
o “Incremento del 15% respecto al mes anterior”
o Generación de gráfico


3.6.7.1.2 Información individualizada para debida diligencia ampliada (seguimiento de operaciones) a clientes de Central Directo:
o Nombre del reporte
o Fecha y hora de generación
o Usuario que generó el reporte
o Período consultado (año-mes)
o Id cliente en consulta la debida diligencia ampliada
o Nivel de riesgo asociado
o Comparaciones relevantes (mes anterior, promedio histórico)

3.6.8 Generar análisis históricos, estadísticas de comportamiento transaccional, estadísticas generales en función del monitoreo seguimiento transaccional, lo anterior para la totalidad de los clientes o para un cliente en específico cuyo parámetro sea el número de identificación.
3.6.9 Como ejemplo de los reportes requeridos se detallan los siguientes:
3.6.9.1. Información agregada para las estadísticas de transacciones procesadas (compra y venta de dólares e inversiones) de los clientes físicos y jurídico de Central Directo
o Nombre del reporte
o Fecha y hora de generación
o Usuario que generó el reporte
o Período consultado (año-mes)
o Cantidad agregada de transacciones procesadas (compra y venta de dólares e inversiones)
o Monto dólares y colones

3.6.9.2. Información individualizada para las estadísticas de transacciones procesadas (compra y venta de dólares e inversiones) de los clientes físicos y jurídico de Central Directo
o Nombre del reporte
o Fecha y hora de generación
o Usuario que generó el reporte
o Período consultado (año-mes)
o Id del cliente en estudio
o Nivel de riesgo asociado
o Cantidad de transacciones procesadas (compra y venta de dólares e inversiones)
o Monto dólares y colones
3.6.10 Crear un informe de actividad sospechosa o intentada (ROS o ROI) si de detectan comportamientos anormales por parte de los clientes posterior al análisis, este informe deberá ser generado a partir de la plantilla establecida por la Unidad de Inteligencia Financiera (UIF)

 

 

3.7 Especificaciones técnicas para soporte y mantenimiento.

3.7.1 La disponibilidad del sistema debe de ser al menos de un 99%, teniendo en cuenta el mantenimiento de la herramienta, posibles fallos y desarrollos nuevos.
3.7.2 En lo que corresponde a la atención de fallos, el BCCR requiere que el área de soporte del contratista esté disponible 24 horas los 7 días de la semana para problemas categorizados con severidad 1 y 2, y disponible en un horario de lunes a viernes de 8 am a 6 pm para aquellos problemas categorizados con severidad 3 y 4. El detalle las severidades se verá más adelante en el punto 6.1.1.9.2.
3.7.3 Para la atención de incidentes o problemas relacionados con los componentes tecnológicos que permiten la interconexión de la herramienta SaaS y los sistemas del BCCR, se requiere que el equipo técnico del contratista, en su conjunto, cuente con experiencia comprobada y conocimientos prácticos en las tecnologías y herramientas empleadas por el Banco, mismas que se detallan a continuación:
3.7.3.1. Arquitectura API REST
3.7.3.2. JSON como formato para intercambio de datos
3.7.3.3. Uso de HTTPS/TLS para asegurar el canal de transporte
3.7.3.4. Uso de Mutual TLS (mTLS)
3.7.3.5. Programación de componentes utilizando Microsoft .Net Core
3.7.3.6. Microsoft Fabric y SQL Server
3.7.3.7. Autenticación segura a través de Microsoft Entra ID y/o credenciales gestionadas
3.7.3.8. Mantenimiento y soporte de soluciones SaaS
3.7.3.9. Conocimiento general sobre Azure y servicios PaaS/IaaS
3.7.3.10. Uso de plataformas o herramientas que apoyen las labores de diagnóstico durante el soporte y faciliten la observabilidad y monitoreo de soluciones
3.7.4 El contratista debe ofrecer el servicio de soporte y mantenimiento, y las pautas de este servicio, deberán detallarse en los documentos de contratación.
3.7.5 La herramienta contratada debe contar con actualizaciones periódicas por parte de la casa matriz de modo que se cubran posibles vulnerabilidades y mejoras.

3.8 Requerimientos de ciberseguridad
3.8.1 El contratista debe cumplir con las normas de ciberseguridad establecidas por el BCCR y el Departamento de Ciberseguridad de la DST indicadas en su política de seguridad aplicable a servicios contratados de tipo SaaS (servicios en Nube). Estas disposiciones indican que se debe satisfacer al menos lo siguiente:
3.8.1.1. Contar con una certificación vigente ISO/IEC 27001, un informe SOC (Service Organization Controls) 2 Tipo 2, o una auditoría por parte de un tercero (en un marco atinente que promueva las buenas prácticas establecidas en las evaluaciones antes mencionadas) y demostrar la implementación satisfactoria de las políticas y controles de seguridad de información establecidos en el marco seleccionado.
3.8.1.2. Demostrar que los datos del BCCR, tanto en reposo como en tránsito, se encuentran cifrados:
 Todos los datos en reposo deben permanecer cifrados, utilizando algoritmos, llaves y rotación de llaves seguros de acuerdo con lo aceptado por la industria
 Todos los datos en tránsito (incluye las API e interfaces) deben viajar mediante protocolos de comunicaciones cifradas seguros, considerando lo siguiente:
• se deben configurar canales cifrados seguros (sesiones HTTPS, sesiones autenticadas con certificaos digitales en una o dos vías)
• el sitio debe estar asegurado por medio del protocolo TLS 1.2 o superior, con certificados digitales emitidos por una CA de confianza pública reconocida, utilizando algoritmos como SHA-256 o superior e incluyendo en su SAN el nombre de dominio o subdominios que están asegurando

3.8.2 Demostrar que la herramienta y la plataforma del contratista cuentan con controles lógicos que aíslan los datos y acceso a la información del BCCR, de los servicios de otros clientes.
3.8.3 Los usuarios de la herramienta contratada deben utilizar autenticación federada mediante el servicio Microsoft Entra ID, para facilitar la integración con los esquemas de seguridad del BCCR. En aquellos casos excepcionales donde lo anterior no sea posible, se debe contar con facilidades para autenticación multifactorial.
3.8.4 Contar con un esquema de respaldo y recuperación de la información que facilite la disponibilidad de los datos y la continuidad del servicio. Además, este esquema deberá considerar las políticas de retención que defina el Banco y permitir la consulta en el momento que sea requerido.
3.8.5 Ante un incidente de ciberseguridad, la gestión de éste debe considerar al menos lo siguiente:
3.8.5.1. El servicio ofrecido por el oferente debe contar con una política clara donde se contemplen la publicación y remediación de brechas de información para sus clientes
3.8.5.2. En caso de que el sistema sufra una brecha de información que impacte los datos del BCCR, el oferente debe comunicarlo de manera inmediata a las personas administradoras del contrato
3.8.5.3. Se proveerán mecanismos para que el BCCR reporte incidentes de ciberseguridad en el servicio y pueda dar seguimiento a los incidentes que se hayan reportado. Así como las especificaciones o documentación de dichos mecanismos
3.8.5.4. Cuando se haya presentado un evento que comprometa la información del BCCR, el oferente deberá colaborar activamente en la respuesta y/o recuperación según corresponda
3.8.5.5. El oferente debe tener disponible la información acerca de los eventos que se hayan presentado con la información del BCCR, así como sus resultados en el momento que se requiera
3.8.6 El Banco Central de Costa Rica tiene la posibilidad de realizar análisis de vulnerabilidades al contratista. Del mismo modo, la empresa debe contar con un proceso continuo de gestión de vulnerabilidades, y en caso de hallar alguna, comunicarla de inmediato Las personas administradoras de contrato junto con un plan remedial.

3.9 Requerimientos tecnológicos

3.9.1 Se requiere que la herramienta para la debida diligencia ofrecida esté preparada para:
3.9.1.1. Integrarse con el esquema de seguridad que emplea el Banco con sus empleados y aprovecharlo para la gestión de los usuarios del sistema, además de contar con un 2do factor de autenticación.
3.9.1.2. Contar con al menos 1 Terabyte (TB) de espacio disponible para albergar los datos del Banco como parte del esquema de licenciamiento contratado.
3.9.2 Para implementar la solución que habilita a la herramienta para la debida diligencia y configurar su interacción con los sistemas de BCCR, se requiere de procesos de carga y actualización de datos, componentes de software, y otros requerimientos que se describen a continuación:
3.9.2.1. Conexión de la herramienta SaaS con los repositorios de datos de BCCR:

3.9.2.1.1 La herramienta SaaS debe poder consumir un private endpoint de SQL Server (utilizado para conectarse a Microsoft Fabric) expuesto en la plataforma de computación en nube de Microsoft Azure.
3.9.2.1.2 El BCCR limitará el acceso al endpoint a sólo a las IP del contratista
3.9.2.1.3 Para asegurar el acceso al endpoint, se utilizará autenticación robusta a través de Microsoft Entra ID.
3.9.2.1.4 Desde este endpoint, el BCCR ofrecerá acceso al Lakehouse donde reside la información de la Oficialía de Cumplimiento del BCCR, desde donde se podrán consultar tablas y vistas asociadas a las siguientes fuentes de información:
3.9.2.1.4.1 Representantes Legales asociados a cada formulario Conozca a su Cliente
3.9.2.1.4.2 Depósitos a plazo de los inversionistas de Central Directo
3.9.2.1.4.3 Operaciones relacionadas con movimientos de fondos realizados por los inversionistas de Central Directo dentro del Sistema Financiero Nacional
3.9.2.1.4.4 Operaciones de compra y venta de divisas
3.9.2.1.4.5 Movimientos de fondos realizados entre las cuentas de efectivo de cada inversionista registradas dentro de Central Directo y el Sistema Financiero Nacional
3.9.2.1.4.6 Información contenida en los Formularios Conozca a su Cliente y Niveles de riesgo asociados a cada inversionista
3.9.2.1.4.7 Información relacionada con el Monitoreo transaccional automático generado desde Central Directo (datos históricos y verificación del seguimiento) que se realiza sobre los clientes
3.9.3 Las fuentes de datos antes indicadas (tablas y vistas), contienen datos primitivos que pueden ser mapeados a atributos o campos puntuales en la estructura de datos utilizada por la herramienta SaaS, sin embargo, en la fuente Formularios Conozca a su Cliente, existen atributos de tipo XML en cuya estructura se encuentran diversos campos con la información que la herramienta SaaS debe leer para precargar y actualizar los datos de sus propios formularios Conozca a su Cliente.

3.10 Carga inicial de datos hacia la herramienta
3.10.1 El contratista debe ofrecer un mecanismo que permita la carga masiva de datos desde los repositorios de datos en nube del BCCR.

3.10.2 El objetivo de esta carga es precargar la herramienta para la debida diligencia con toda la información histórica relacionada con los formularios Conozca a su Cliente y las operaciones realizadas por aquellos inversionistas a los que la Oficialía de Cumplimiento da seguimiento.

3.11 Especificaciones para completar los datos para los Formularios Conozca a su Cliente
3.11.1 Debido a que parte de la información de los formularios Conozca a su Cliente se encuentra registrada en los sistemas del BCCR en formato XML, para realizar la carga de la información hacia las bases de datos de la herramienta SaaS, se requiere que el proceso de carga sea capaz de:
3.11.1.1. Leer e interpretar datos en formato XML de forma que pueda identificar etiquetas específicas y pueda mapearlas a atributos propios en los formularios de la herramienta.
3.11.1.2. Los datos que se registran para cada reporte se indican a continuación:
• ID del reporte, fecha de registro, fecha de revisión, fecha de vencimiento, estado, nivel de riesgo, motivo del estado (toma relevancia cuando el reporte está rechazado), e información específica para el inversionista: datos personales del inversionista, localización del cliente, fuente de ingresos, datos laborales y estimado de las operaciones a realizar.
• En los casos en los que se trate de una persona jurídica (empresa), se asocia además la siguiente información:
o datos de la empresa y actividad económica, fuente de ingresos, estimado de operaciones, datos sobre el representante legal y localización del cliente.
3.11.2 Además, el BCCR proveerá un servicio web que debe ser consumido por la herramienta para poder cargar y asociar a cada formulario migrado aquellos documentos de evidencia asociados a cada reporte. Estos documentos se relacionan con el identificador de cada reporte, y pueden encontrarse en formato Word, Excel, PDF o archivo de imágenes.

3.12 Carga recurrente de datos hacia la herramienta
3.12.1 Debido a que las distintas fuentes de información expuestas por el BCCR en su Lakehouse pueden sufrir cambios de acuerdo con los distintos flujos de negocio que las afectan, se requiere que los procesos de carga recurrente de datos de la herramienta SaaS se ejecuten de forma diaria los 7 días de la semana y contemplen lo siguiente:

3.12.1.1. Recarga de todos los representantes legales asociados a los formularios Conozca a su Cliente
3.12.1.2. Recarga de todos los depósitos a plazo de los inversionistas
3.12.1.3. Recarga de las operaciones de compra y venta de divisas de los últimos 30 días naturales
3.12.1.4. Recarga de los movimientos de fondos que afectaron las cuentas de efectivo de los inversionistas de Central Directo durante los últimos 30 días naturales
3.12.1.5. Recarga de los movimientos de fondos asociados a los inversionistas de Central Directo realizados dentro del Sistema Financiero Nacional durante los últimos 15 días naturales
3.12.1.6. Recarga de la información registrada en los Formularios Conozca a su Cliente y Niveles de riesgo asociados a cada inversionista de los últimos 15 días naturales
• Se deben considerar solo aquellos formularios con estado Aprobado, Aprobado-por-vencer, y Aprobado-vencido
3.12.1.7. Recarga de la información generada por el proceso de Monitoreo de transacciones automático. La carga de esta información se realizaría el segundo día de cada mes solamente.

3.12.2 Todas las recargas de datos antes indicadas deben considerar el cifrado de los datos mientras viajan de los repositorios de datos en nube del BCCR hacia los repositorios de la herramienta SaaS.
3.12.3 Para cada formulario Conozca a su Cliente nuevo que se cargue, la herramienta SaaS debe consumir un servicio web desarrollado por el BCCR que permite obtener los documentos de evidencia asociados a cada formulario, para que sean cargados junto con él en la herramienta.

3.13 Comunicación e integración entre la herramienta para la debida diligencia y los sistemas de BCCR

3.13.1 Se requiere que la herramienta SaaS cuente con un mecanismo que le permita comunicarse, de forma segura mediante el uso de certificados digitales, con los servicios REST que ofrecerá el BCCR. Lo anterior con el fin de poder ejecutar acciones que promuevan cambios en los datos de los formularios Conozca a su Cliente, en los accesos a los servicios financieros a los cuales tiene acceso cada inversionista de Central Directo, y en los datos específicos de cada inversionista.
3.13.2 Por su parte, el BCCR expondrá los siguientes servicios:
3.13.2.1. Un servicio web de tipo API REST para promover los siguientes cambios hacia los formularios Conozca a su Cliente registrados en Central Directo:
3.13.2.1.1 Aprobar formularios
3.13.2.1.2 Rechazar formularios, junto con la justificación para esta acción (motivo de rechazo)
3.13.2.1.3 Modificar la fecha de vencimiento de un formulario
3.13.2.1.4 Modificar el estado de un formulario, para que pueda pasar de:
3.13.2.1.4.1 Aprobado a Aprobado-por-vencer o Aprobado-vencido
3.13.2.1.4.2 Aprobado-por-vencer a Aprobado o Aprobado-vencido
3.13.3 Un servicio web de tipo API REST para promover cambios a los inversionistas:
3.13.3.1. Permitir la activación e inactivación de inversionistas en Central Directo, de acuerdo con indicaciones generadas desde la herramienta SaaS
3.13.4 Un servicio web de tipo API REST para exponer archivos (que pueden ser Word, Excel, PDF e imágenes) para que sean asociados con los formularios Conozca a su Cliente cargados durante el día.
3.13.5 Un servicio web de tipo API REST que ofrece funcionalidad para que la herramienta SaaS solicite el envío de correos específicos desde los sistemas de BCCR.

3.14 Sobre la interacción esperada entre los sistemas
3.14.1 Los servicios web descritos en la sección anterior serán utilizados cada vez que el analista ejecute alguno de los siguientes flujos de negocio (casos de uso):
3.14.2 Cada vez que, desde la herramienta para la debida diligencia se apruebe un reporte Conozca a su Cliente, se debe informar a Central Directo para que éste actualice el estado del reporte ingresado originalmente por el inversionista.
3.14.3 Cada vez que, desde la herramienta para la debida diligencia se rechace un reporte Conozca a su Cliente, se debe informar a Central Directo para que éste actualice el estado del reporte ingresado originalmente por el inversionista. Como parte del rechazo, desde la herramienta se debe enviar a Central Directo una descripción del motivo de rechazo del reporte.
3.14.4 Cada vez que, desde la herramienta para la debida diligencia, como resultado de un monitoreo transaccional, se determine una anomalía y sea necesario que el inversionista justifique alguna operación o saldo en su cuenta de inversión, en el momento que se “notifique” el incumplimiento del perfil transaccional, se debe instruir a Central Directo para que realice alguna de las siguientes acciones:
3.14.4.1. Cambiar la fecha de vencimiento del formulario Conozca a su Cliente asociado al inversionista para que venza 15 días naturales a partir de la fecha de la instrucción, lo que implica cambiar su estado de Aprobado a Aprobado-por-vencer

3.14.5 Cada vez que, desde la herramienta para la debida diligencia, como resultado de la gestión y seguimiento de un monitoreo transaccional previo, se determine que el inversionista justificó a satisfacción la anomalía reportada dentro del plazo de los 15 días naturales, en el momento en que se acepta la justificación, se debe instruir a Central Directo para que realice alguna de las siguientes acciones:
3.14.5.1. Reestablecer la fecha de vencimiento del formulario Conozca a su Cliente a la fecha original de vencimiento, lo que implica cambiar su estado de Aprobado-por-vencer a Aprobado
3.14.6 Cada vez que, desde la herramienta para la debida diligencia, como resultado de la gestión y seguimiento de un monitoreo transaccional previo, se justifique posterior al plazo dado de 15 días naturales, se debe instruir a Central Directo para que realice alguna de las siguientes acciones:
3.14.6.1. Actualizar el estado del formulario Conozca a su Cliente de Aprobado-por-vencer a Aprobado-vencido.

3.14.7 Cambiar de oficio el estado de un inversionista
3.14.7.1. Inactivar a un inversionista, que implica modificar el estado del formulario asociado de Aprobado a Aprobado-vencido
3.14.7.2. Reactivar a un inversionista, que implica modificar el estado del formulario asociado de Aprobado-vencido a Aprobado
3.14.8 Cada vez que en la herramienta para la debida diligencia se carguen formularios Conozca a su Cliente “nuevos” desde los sistemas del BCCR, ésta debe obtener y cargar también a la herramienta aquellos documentos de evidencia relacionados con cada reporte y asociarlos al registro interno que se tendrá del formulario, utilizando para ello, el identificador único de cada reporte.

3.15 Consideraciones generales sobre los servicios web ofrecidos:
3.15.1 Todos servicios web que desarrollará el BCCR serán de tipo API REST, en formato JSON, y utilizarán certificados digitales para cifrar la comunicación con su contraparte. Estos componentes de software utilizarán versiones del framework Microsoft .Net que se encuentren vigentes, soportadas oficialmente por Microsoft y clasificadas como Long Term Support (LTS) al momento de la implementación. El contratista debe poder consumir servicios desarrollados con estas tecnologías.
3.15.2 La herramienta SaaS, que reside en la nube del oferente, además de poder conectarse a la plataforma de servicios en nube de Microsoft utilizada por el BCCR, para leer información de los reportes Conozca a su Cliente y las operaciones que estén asociados a ellos, debe poder consumir y utilizar los servicios web ofrecidos por el Banco expuestos en sus servidores DMZ (que existen en su plataforma en tierra) con conectividad a Internet.

3.16 Confidencialidad de la información
3.16.1 La siguiente disposición de confidencialidad se aplica entre el BCCR y el contratista:
3.16.1.1. Para efectos de la presente contratación, y en concordancia con los estándares aplicables al Banco Central de Costa Rica, toda información suministrada o generada en la prestación de servicios relacionados con la prevención de la legitimación de capitales y el financiamiento al terrorismo se considerará Información Confidencial.
3.16.1.2. Este concepto abarca, sin limitarse a ello, información no pública relativa a clientes, cuentas, operaciones, productos, servicios, perfiles transaccionales, análisis de riesgo, reportes internos, metodologías, procedimientos operativos y cualquier otro dato sensible cuyo manejo esté sujeto a obligaciones de reserva por parte del Banco Central de Costa Rica.
3.16.1.3. Asimismo, se entenderá como Información Confidencial todo know‑how, documentación técnica, criterios metodológicos, modelos analíticos, herramientas de evaluación y cualquier secreto empresarial del contratista o del Banco Central de Costa Rica, independientemente de la forma en que la información sea designada o del hecho de que, por su naturaleza, una persona razonable deba reconocerla como confidencial.
3.16.1.4. La información entregada o generada en la ejecución del servicio deberá utilizarse exclusivamente para los fines estrictamente necesarios para el cumplimiento del contrato, quedando prohibida su divulgación a terceros.

3.17 Tratamiento de la Información Confidencial.
3.17.1 En General. Con sujeción de los demás términos de este anexo, cada una de las partes acepta que:
3.17.1.1. No revelará la información confidencial de la otra a terceros.
3.17.1.2. Utilizará y revelará la Información Confidencial de la otra solo para fines derivados de la relación comercial entre las partes.
3.17.2 Precauciones de seguridad. Con sujeción a los demás términos de este contrato cada una de las partes aceptan que:
3.17.2.1. Realizará los pasos necesarios para proteger la información confidencial de la otra parte, debiendo ser estos pasos, como mínimo, tan protectores como lo que realice la parte para proteger su propia información confidencial.
3.17.2.2. Notificará de inmediato, nada más sea descubierto, cualquier uso o revelación de información confidencial.
3.17.2.3. Cooperará con la otra parte para ayudarla a recuperar el control de la información confidencial y prevenir el uso o revelación adicional o no autorizado.

 

4. Línea 3: HORAS CONSUMIBLES:
4.1 Estas horas corresponde al tiempo de desarrollo técnico que el AC podrá solicitar al contratista para la ejecución de labores específicas asociadas a los distintos paquetes de trabajo, tal como ajustes a la herramienta con desarrollos no considerados originalmente, siempre alineados con el mismo objeto contractual pero que surjan por causa de cambios normativos o necesidades técnicas nuevas en la operativa de la funcionalidad de la herramienta, que no sean producto de actualizaciones propias del sistema y la funcionalidad contratada.
4.2 Estas horas se calculan según las necesidades institucionales y solo se utilizarán bajo este concepto, estableciendo la cantidad máxima anual en 100 horas, consumibles bajo requerimiento directo del administrador del contrato, sin que ello genere derechos de resarcimiento ni asegure un volumen mínimo de contratación. Su propósito es brindar flexibilidad operativa, permitiendo a la Administración atender requerimientos puntuales conforme se presenten durante la ejecución de los servicios.

4.3 El contratista deberá cumplir con los siguientes requerimientos:

4.3.1 Especificar el periodo de garantía ofrecido para el desarrollo de mejoras, mismo que no podrá ser menor a tres meses contados a partir de la recepción del servicio a entera satisfacción por parte del AC.
4.3.2 En la etapa de ejecución, el contratista deberá remitir, en un plazo máximo de tres (3) días hábiles, una estimación técnica del esfuerzo requerido, expresada en horas profesionales, para la mejora solicitada por las personas Administradoras del Contrato (AC). Una vez presentada dicha estimación, el AC determinará la conveniencia de implementar o no la mejora. En caso de identificarse trabajos adicionales no contemplados en la estimación presentada, el contratista deberá informarlo de previo, a fin de que estos sean valorados y aprobados por el AC.
4.3.3 Al finalizar el desarrollo de la mejora, se debe detallar los trabajos realizados e indicar la cantidad de horas ejecutadas, esto para realizar la verificación y ejecución del pago correspondiente. Los pagos se realizarán según las horas consumidas.
4.3.4 El total de horas a consumir por una mejora no podrá sobrepasar el monto máximo anual definido en el presupuesto para esta contratación (100 horas).
4.3.5 Las mejoras deberán atenderse e implementarse mediante el mecanismo que resulte necesario según la naturaleza del requerimiento, y deberán ser ejecutadas por un equipo que en su conjunto cumpla al menos con lo establecido en el apartado 1.1.4 de la sección Requisitos de Admisibilidad. La información correspondiente será verificada durante la ejecución contractual.

4.3.6 Todo desarrollo que incorpore nueva funcionalidad a la herramienta realizado bajo el marco de estas horas deberá quedar a disposición del Banco Central de Costa Rica para su uso institucional. En este sentido, el Contratista no podrá reutilizar o comercializar dicha mejora para terceros sin contar previamente con la autorización expresa del AC. Asimismo, el Contratista deberá proporcionar la documentación técnica que acompaña la nueva funcionalidad, junto con los manuales de operación e información relevante para asegurar el adecuado uso, mantenimiento y eventual evolución de dichas funcionalidades. Igualmente se debe ofrecer la capacitación correspondiente cuando proceda.

 

5. CONDICIONES ESPECÍFICAS
5.1 Garantía de la implementación y mejoras efectuadas
5.1.1 El Administrador del Contrato entiende como implementación de mejoras o cambios (mantenimiento evolutivo) todas aquellas actividades de desarrollo, pruebas o configuración y pruebas que requiera la herramienta y que amplíen su funcionalidad mediante la incorporación de nuevas funcionalidades.
5.1.2 El contratista debe brindar garantía de implementación y mejoras según las siguientes condiciones:
5.1.2.1. La garantía debe ser extendida únicamente por el Contratista, no resultando válida la indicación de otra persona física o jurídica que no sea parte legitimada en la negociación.
5.1.2.2. La garantía de la configuración inicial de los módulos de la herramienta debe ser por un período mínimo de un (1) año a partir de la puesta en marcha y la aceptación formal de las personas administradoras del contrato una vez que la solución se encuentre estable en la plataforma del fabricante.
5.1.2.3. Durante todo el período de garantía, el contratista deberá brindar soporte técnico sin costo adicional, que incluirá como mínimo:
5.1.2.3.1 el ambiente de pruebas
5.1.2.3.2 atención de incidencias
5.1.2.3.3 consultas técnicas relacionadas con la implementación y mejoras,
5.1.2.3.4 análisis de comportamiento de las funcionalidades,
5.1.2.3.5 incidencias derivadas de ajustes o desarrollos entregados,
5.1.2.3.6 dudas operativas relacionadas directamente con las mejoras implementadas.
5.1.2.3.7 Niveles mínimos de servicio

5.1.2.4. El contratista deberá cumplir los niveles mínimos de servicio definidos por la Administración, tales como:
5.1.2.4.1 tiempo de respuesta inicial,
5.1.2.4.2 tiempo de análisis,
5.1.2.4.3 tiempo de solución según criticidad,
5.1.2.4.4 comunicación continua del estado de la incidencia.
5.1.2.5. Registro de soporte: El contratista deberá mantener un registro detallado de:
5.1.2.5.1 todas las incidencias reportadas,
5.1.2.5.2 acciones tomadas,
5.1.2.5.3 tiempos de respuesta y de solución,
5.1.2.5.4 aceptación por parte de la Administración.
5.1.2.6. Cuando el Administrador del Contrato así lo solicite, el contratista deberá realizar las actividades necesarias que determinen la causa raíz de los problemas encontrados, así como la ejecución de la solución correspondiente.

5.1.2.7. Como parte de la garantía, el contratista se compromete a cumplir con lo siguiente:
5.1.2.7.1 Ejecutar las labores requeridas que garanticen el diagnóstico y resolución de cualquier situación que afecte la operación de la herramienta. En todos los casos el contratista coordinará con el BCCR la participación del personal de tecnologías de la Institución para realizar las labores de prevención y corrección de errores.
5.1.2.8. Garantizar que no se verán afectados los servicios, producto de la aplicación de las tareas inherentes o propias del mantenimiento preventivo y correctivo que la herramienta periódicamente requiera. Esto puede implicar que estas labores se deban programar en horarios no hábiles para que no se afecte a los usuarios del servicio

5.2 Atención de reportes de averías durante el período de garantía.
5.2.1 El contratista se compromete a suministrar y mantener actualizado los medios de contacto (por ejemplo: Contact Center, teléfono del personal en servicio) que permitan al BCCR ingresar una solicitud de atención de incidentes, falla o problema durante el período de garantía.
5.2.2 Estos medios de contacto deben estar disponibles 24 horas los 7 días de la semana para incidencias de severidad 1 y 2, y para incidencias de severidad 3 y 4 aplicará el horario de lunes a viernes de 8:00a.m. a 6: 00p.m. según se detallan en el siguiente cuadro:

Severidad del incidente Descripción
Severidad 1 Significa que la herramienta se encuentra en una condición que no permite su operación en el ambiente de producción y no existe una solución alternativa disponible.
Severidad 2 Significa una situación donde el software puede operar, pero está severamente restringido.
Severidad 3 Significa una situación de bajo impacto, con la mayoría de las funciones de la herramienta en condiciones de uso; en algunos casos, puede ser que se requiera realizar pasos adicionales para ejecutar algunas funciones en la herramienta.
Severidad 4 Significa un problema o cuestión menor que no afecta el funcionamiento de la herramienta. También se aplica para un error en la documentación del producto que no tenga efecto significativo en las operaciones o una sugerencia de nuevas funciones o mejoras del producto.

5.2.3 La atención de los reportes de incidentes deberá al menos cumplir con los siguientes tiempos de acuerdo con su severidad:
Grado de Severidad Tiempo reacción Tiempo de solución temporal Tiempo de solución definitiva
Severidad 1 1 hora 8 horas 20 horas
Severidad 2 1 hora 16 horas 36 horas
Severidad 3 1 hora 24 horas 40 horas
Severidad 4 3 horas 32 horas 56 horas

5.2.4 Si el contratista prevé que le tomará más tiempo del estipulado en la tabla de severidad, deberá comunicar al Administrador del Contrato las razones por las que no podrá cumplir con el plazo, así como el tiempo de prórroga que requiere para completarlo; el Administrador del Contrato evaluará las razones y basado en ellas podría aceptar o no la prórroga. Dicha solicitud debe realizarse dentro del periodo comprendido entre el tiempo de solución temporal y tiempo de solución definitiva y solo podrá solicitarse por una única vez para cada evento.

5.2.5 En caso de que las personas administradoras evalúen algún aspecto como irregular o deficiente, deberá indicar puntualmente los casos que se presentaron durante el período que no cumplieron con las expectativas del BCCR e indicar los aspectos que en su criterio se deben mejorar.
5.3 DISCRECIONALIDAD:
5.3.1 El contratista, y todos los trabajadores que éste designe para realizar el servicio objeto de la presente contratación, deberán comprometerse a manipular toda la documentación e información del BCCR que esté a su alcance ya sea en forma directa o indirecta, así mismo no podrá utilizar la misma para fines más allá del trabajo asignado en esta contratación.
5.3.2 El contratista, y su personal deben hacer uso autorizado y no fraudulento de los contenidos intercambiados con el BCCR (archivos, información, materiales, software, equipo y demás). No podrá utilizar la información para fines comerciales, privados, ilícitos o para fines diferentes a los necesarios para la operación del servicio, objeto de esta contratación, su uso será exclusivamente para los fines de esta contratación, dentro de un ámbito de discreción e integridad, de acuerdo con las políticas de control y seguridad institucionales.
5.3.3 Se prohíbe todo acto que de cualquier forma puedan dañar, inutilizar, sobrecargar, deteriorar o impedir la normal utilización de los servicios, los equipos informáticos o los documentos, archivos y toda clase de contenidos almacenados en cualquier equipo informático del Banco Central.
5.3.4 La utilización indebida o negligente de la información o los recursos institucionales o residuales, derivados de prácticas imputables al contratista o su personal, serán consideradas factores de incumplimiento a la contratación y objeto de las sanciones administrativas y penales correspondientes.
5.4 Planificación de la implantación:

5.4.1 En caso de ser requerido, elcontratista deberá garantizar la disponibilidad de una persona que asegure la adecuada comunicación en idioma español con el Administrador del contrato o a quien este designe, para la atención de cualquier aspecto relacionado con la herramienta.

5.4.2 El contratista deberá ejecutar las siguientes fases:
Fase Actividad Entregables
1. Planeación Definir y planificar las actividades necesarias para la implantación de la herramienta. 1. Plan del proyecto
2. Cronograma detallado de actividades.
3. Definición de hitos y responsables.
4. Definición de perfiles.
2. Configuración y desarrollo Configurar la herramienta conforme a los requerimientos funcionales (debida diligencia, perfiles de riesgo, monitoreo transaccional) y realizar las integraciones con los sistemas internos del BCCR (Portal Central Directo, bases de datos y servicios web).
Entrega de manuales funcionales y técnicos. 5. Herramienta configurada.
6. Módulos funcionales habilitados
7. Integraciones técnicas implementadas.
8. Manuales de usuario y manual técnico.
3. Pruebas Ejecutar el plan de pruebas Resultado del plan de pruebas.
4. Capacitación Elaborar el plan de capacitación.

Ejecutar el plan de capacitación. Plan de capacitación

Actividades de capacitación (cursos)
5. Puesta en producción (Liberación) Planear actividades de liberación.

Ejecutar actividades de liberación. Plan de liberación.

Liberación del sitio en ambiente productivo.
5.4.3 El contratista debe entregar los manuales de usuario y técnicos sobre la funcionalidad de la herramienta y cualquier otro que sea necesario en medio electrónico.
5.4.4 El contratista debe capacitar a los usuarios en la operativa de la solución (especificaciones funcionales como administrador del sistema, Usuario Operativo) y al usuario en temas tecnológicos (especificaciones técnicas y de programación). El personal que realizará la capacitación deberá ser experto en la solución con capacidades demostradas en el sistema tanto de las especificaciones funcionales como de las técnicas.
5.4.5 Se deben llevar a cabo reuniones al menos una vez por semana para evaluar el avance del proyecto y elaborar minutas con los acuerdos tomados. Estas reuniones son responsabilidad del Líder del Proyecto por parte del contratista y deberán ser consideradas en la elaboración del Plan del Proyecto. En estas reuniones debe presentar un informe con el avance del proyecto a la fecha.
5.4.6 El Administrador del Contrato se reserva el derecho de solicitar el reemplazo de cualquier funcionario que el contratista haya asignado al proyecto que no cumpla con los requisitos mínimos razonables de productividad, responsabilidad, seriedad y calidad en los trabajos desarrollados. Para tal efecto, se comunicará formalmente el caso con las justificantes correspondientes. Esto será condición suficiente para iniciar el proceso de reemplazo que se regirá por las mismas condiciones mencionadas en el párrafo anterior.
5.4.7 El contratista, debe ajustarse al horario laboral del BCCR, en la actualidad el horario laboral del BCCR es de 09:00 a.m. a 05:00 p.m. de lunes a viernes.

 

5.5 PLAZO DE ENTREGA:
Posterior a la adjudicación y una vez que el contrato se encuentre notificado en SICOP, se realizará una reunión inicial dentro de los cinco (5) días hábiles siguientes, con el propósito de planificar la primera fase del proyecto, correspondiente a la definición y programación de las actividades necesarias para la implantación de la herramienta.
Como resultado de dicha reunión, el contratista deberá elaborar un cronograma detallado de trabajo, en un plazo acordado por las partes, el cual deberá ser revisado y aprobado por las personas administradoras del contrato. Este cronograma deberá contemplar todas las fases de la implantación, así como sus respectivos hitos y entregables.
La fecha límite para la finalización de todas las etapas de la contratación será definida en el cronograma aprobado; dentro de los siguientes nueve (9) meses contados a partir de la notificación del contrato en SICOP, sin embargo, en ningún caso podrá exceder el 05 de diciembre de 2027.

 

6. CONSIDERACIONES IMPORTANTES
6.1 De conformidad con el artículo 78 de la LGCP, el artículo 214 del RLGCP, y el artículo 3 del RRRP, aquellas contrataciones cuyos servicios se encuentren regulados por aranceles obligatorios, no deben presentar la Estructura del Precio, ni el Presupuesto Detallado.
6.2 De acuerdo con lo dispuesto en los artículos 42 de la LGCP y 102 del RLGCP, el oferente está obligado a presentar la estructura del precio en términos absolutos y porcentuales, requisito aplicable para contratos de servicios y obra pública. En consecuencia, la presentación de la Estructura del Precio no es exigible para la adquisición de bienes destinados a una única entrega.
6.3 De acuerdo con el artículo 44 del RRRP, excepcionalmente, en contrataciones de bienes y servicios con una única entrega, no será requerido presentar el cronograma y en sustitución se utilizarán para el cálculo de la revisión de precios los valores de los índices del mes calendario de la presentación de la oferta y del mes calendario de la fecha pactada en la contratación.
6.4 De conformidad con los artículos 42 de la LGCP y 102 del RLGCP, en los contratos de servicios y obra pública resulta obligatoria la inclusión del desglose de la estructura del precio, contemplando como mínimo los costos directos, costos indirectos, utilidad e imprevistos. El rubro de imprevistos tiene como finalidad cubrir eventualidades inherentes a la ejecución contractual derivadas del riesgo y ventura asumidos por el contratista, evitando que situaciones extraordinarias afecten la correcta ejecución del contrato.
7. ÍNDICES DE PRECIOS
7.1 En los contratos en los que procede la aplicación del reajuste o la revisión de precios, de conformidad con lo regulado en el artículo 43 de la LGCP y los artículos 107, 108 y 109 del RLGCP, el oferente deberá aportar en la oferta la información de todos los índices de precios oficiales, ya sean específicos o similares, de los costos directos e indirectos de la estructura de precio, los cuales deberán estar estrechamente vinculados con la variación de los costos que desea medir.
7.1.1 Para ello el oferente deberá considerar el siguiente orden de aplicación:
Primero, propondrá un índice de precios específico asociado al costo, para el que se desee medir dichas variaciones.
En segundo lugar, en su ausencia o inexistencia, propondrá un índice de precios similar. En este caso deberá aportar en la oferta la justificación técnica correspondiente de dicha decisión.
7.2 Para lo anterior los oferentes deberán presentar una declaración jurada en donde acrediten la veracidad de la información aportada, indicando al menos los aspectos regulados en los artículos 9 y/o 12 del RRRP, según corresponda.
7.3 Dichos índices deberán ser elaborados y emitidos por una entidad oficial del país donde el oferente proyecta adquirir los bienes y servicios, dichos índices deberán ser concordantes con la moneda en que se presentó el precio de la oferta, y los valores absolutos de su estructura, de conformidad con lo establecido en el artículo 107 del RLGCP.

8. ÍNDICES DE PRECIOS OFICIALES PARA LOS COSTOS OFERTADOS EN MONEDA NACIONAL:
8.1 Para aquellos costos directos e indirectos de la estructura de precio que están expresados en la oferta en colones costarricenses, el oferente deberá aportar en su oferta información acerca de los índices de precios nacionales, para lo cual deberá completar el siguiente cuadro:

País de origen Unidad monetaria de los costos Nombre del índice Nivel Código La periodicidad con que se determina el valor de cada índice Nombre del ente competente que publica el índice Enlace del sitio web del ente competente

8.2 Los índices de precios nacionales serán emitidos y publicados por el Instituto Nacional de Estadística y Censos de Costa Rica (en adelante INEC), el BCCR y cualquier otro ente público competente en materia de índices de precios que disponga el ordenamiento jurídico.

9. ÍNDICES DE PRECIOS OFICIALES PARA LOS COSTOS OFERTADOS EN MONEDA EXTRANJERA:
9.1 Para aquellos costos directos e indirectos de la estructura de precio expresados en la oferta en una moneda de un país extranjero, el oferente deberá completar el siguiente cuadro:
País de origen Unidad monetaria de los costos Nombre del índice Nivel Código La periodicidad con que se determina el valor de cada índice Nombre del ente competente que publica el índice Enlace del sitio web del ente competente

9.2 En caso de que la información se encuentre en un idioma distinto al español, se requerirá que el oferente bajo su responsabilidad aporte una traducción libre al español, dicha traducción únicamente para corroborar la información aportada por el oferente.

10. PERTINENCIA DE LOS DE ÍNDICES DE PRECIOS:
10.1 A efecto de acreditar la pertinencia de los índices de precios, la información aportada de los índices propuestos en la oferta deberá ser conforme con lo establecido en el artículo 9 y/o el artículo 12 del RRRP, según corresponda.
10.2 La pertinencia de un índice de precios se determinará con base en la estrecha relación que existe entre el costo que será reajustado o revisado y el índice de precios a utilizar, así como la concordancia entre el índice de precio y la moneda del costo ofertado.
10.3 Posteriormente, el adjudicatario deberá presentar en el presupuesto detallado, la vinculación del índice de precios aportado en su oferta asociándolo a cada uno de los costos directos e indirectos de dicho presupuesto, lo anterior de conformidad con el artículo 42 de la LGCP y el artículo 103 del RLGCP.
10.4 Una vez verificado lo regulado anteriormente, la Administración deberá emitir la "no objeción" a la pertinencia de los índices de precios, posterior a la suscripción de la formalización contractual o documento equivalente y previo a otorgarse la orden de inicio de la ejecución contractual.
10.5 Excepcionalmente, en caso de que la Administración no emita la "no objeción" a la pertinencia de los índices de precios por motivos atribuibles al contratista, ello impedirá la aplicación del mecanismo de reajuste y de revisión de precios regulado en este reglamento. En tal caso el contratista podrá interponer el reclamo administrativo para garantizar el equilibrio económico del contrato.

11. AUSENCIA DE ÍNDICES DE PRECIOS:
11.1 Cuando no exista un índice de precios, específico oficial o uno similar, que represente las variaciones de un determinado costo directo, el oferente deberá advertirlo así en su oferta, y se podrá aplicar el método analítico-documental, de conformidad con lo regulado en el artículo 14 del RRRP y en concordancia con lo establecido en los artículos 102, 107, 108 y 109 del RLGCP.
11.2 En aquellos casos en que no exista un índice de precios del costo directo, debido a que dicho costo fue ofertado en una moneda distinta a la unidad monetaria legalmente establecida en el país de origen del citado costo, ello por motivos de exigencias del proveedor del insumo o servicio, el oferente deberá aportar en la oferta, la prueba pertinente y suficiente que acredite tal exigencia.
11.3 Cuando no exista un índice de precios oficial, específico o uno similar, que represente las variaciones de un determinado costo indirecto, el oferente deberá advertirlo así en su oferta y podrá proponer como índice general el Índice de Precios al Consumidor (IPC) del país de origen del costo. Excepcionalmente, en el caso de que tampoco exista el IPC se podrá aplicar el método analítico-documental, de conformidad con lo regulado en el artículo 14 del RRRP y en concordancia con lo establecido en los artículos 102, 107, 108 y 109 del RLGCP.
11.4 La revisión de precios mediante el método analítico-documental se aplicará únicamente cuando haya ausencia de índices de precios de un determinado costo, según lo regulado en el artículo 14 del RRRP; para ello el oferente deberá advertir en la oferta la ausencia de los índices de precios y aportar la documentación probatoria pertinente (factura proforma o documento equivalente). Asimismo, los oferentes deberán presentar en la oferta una declaración jurada en donde se acredite la veracidad de la información que debe aportar conforme a lo regulado en el artículo 58 del RRRP.
11.5 La factura proforma o documento equivalente, deberá contar con al menos la siguiente información:
a) Fecha de la emisión de la factura proforma.
b) Vigencia del o los precios de la factura proforma, la cual no podrá ser inferior a la fecha de la presentación de la oferta.
c) Nombre y razón social del proveedor y del comprador.
d) Información de contacto del proveedor.
e) País del proveedor del insumo o servicio.
f) Descripción y características principales del insumo o servicio.
g) Precio unitario concordante con la moneda con la que se presenta el precio ofertado.
h) Costos desagregados, tales como, pero no limitados a transporte, flete, seguros e impuestos.
En caso de que la información se encuentre en un idioma distinto al español, se requerirá que el oferente bajo su responsabilidad aporte una traducción libre al español.
12. ÍNDICES DE REFERENCIA DEL BCCR:
12.1 El BCCR propone a disposición una variedad de índices y referencias económicas fundamentales para el seguimiento y análisis de los precios, la inflación y otros aspectos relacionados con la economía nacional. A continuación, se presentan algunos de los índices más relevantes:
ÍNDICE DESCRIPCIÓN
Índice de Precios al Consumidor (IPC) Evolución de los precios de bienes y servicios que adquieren los hogares, clave para medir la inflación.
Indicadores de Inflación Subyacente (IIS) Reflejan la tendencia de la inflación excluyendo componentes volátiles.
Índice de Precios al Productor de la Manufactura (IPP-MAN) Evalúa la variación de precios de los productos manufacturados a nivel de productor.
Índice de Precios al Productor de Servicios (IPP-S) Permite conocer el comportamiento de los precios de los servicios ofrecidos por los productores.
Índice de Precios de Insumos para la Construcción (IPi-CTR) Evolución de los costos de insumos utilizados en la actividad constructiva.
Índice de Precios de Insumos para el Transporte Público (IPi-TRP) Variaciones en los precios de insumos vinculados al transporte público.
Índice de Precios Internacionales de Materias Primas Importadas (IP-MPi) Comportamiento de los precios de materias primas importadas utilizadas en diferentes sectores productivos.
Índice de Salarios Mínimos Nominales (ISMN) y Reales (ISMR) Evolución de los salarios mínimos tanto en valores nominales como ajustados por inflación.
* Fuente: https://www.bccr.fi.cr/indicadores-economicos/%C3%ADndices-de-precios

13. ESTRUCTURA DE PRECIO
13.1 Conforme al artículo 15 del RRRP, el artículo 42 de la LGCP y el artículo 102 del RLGCP, en los contratos de obra pública y servicios, así como cualquier otro objeto contractual según se establezca en el pliego de condiciones, el oferente deberá presentar la estructura de precio de su oferta tanto en valores absolutos como porcentuales.
13.2 La estructura de precio es una desagregación del precio para cada renglón de pago o línea y para el precio total, en costos directos, indirectos, utilidad e imprevistos, reflejado en valores absolutos y porcentuales, la cual resume la cuantificación efectuada por el oferente o contratista, según corresponda, acerca de los costos y recursos requeridos para cumplir con un determinado objeto contractual. La estructura de precio deberá ser concordante con la o las monedas en que se proyecta comprar o adquirir los bienes y servicios (origen de los costos).
13.3 En caso de existir discrepancias entre la estructura de precio y el presupuesto detallado, se establece que prevalecerán los valores absolutos definidos en la estructura de precio. Por lo tanto, el presupuesto deberá ajustarse y corresponder a dichos valores, asegurando así la coherencia entre ambos documentos.
13.4 La estructura de precio de la oferta deberá presentarse, tanto para el precio total ofertado, como para cada uno de los precios unitarios de las líneas o los renglones de pago que conforman el objeto contractual.
13.5 En aquellos casos que el precio ofertado sea en más de una moneda, el oferente deberá presentar la estructura de precio correspondiente a cada moneda.
13.6 La estructura de precio de la oferta estará compuesta por al menos el desglose de los siguientes componentes:
TIPO DEL COSTO DETALLE CONSIDERE COMO MÍNIMO:
COSTOS DIRECTOS Son los costos en los que incurre el contratista para materializar el objeto contractual. -Mano de obra
-Insumos
-Subcontrataciones (si corresponde)
COSTOS INDIRECTOS Son los costos generales en que incurre el contratista para la Administración del objeto contractual, en sus oficinas matrices y/o en el sitio de la ejecución del contrato, no atribuibles a una actividad contractual en particular, pero necesarios para la ejecución del contrato. -Mano de obra
-Insumos
UTILIDAD Beneficio que persigue lograr el contratista al celebrar un contrato administrativo, calculado considerando tipo de trabajo, esfuerzo, riesgo intrínseco y la inversión a realizar.
*IMPREVISTOS El rubro de imprevistos tiene como finalidad cubrir eventualidades inherentes a la ejecución contractual derivadas del riesgo y ventura asumidos por el contratista, evitando que situaciones extraordinarias afecten la correcta ejecución del contrato.
*Nota: En los contratos cuyo objeto corresponda a la adquisición de bienes, el rubro de imprevistos no constituye un componente obligatorio. No obstante, en caso de que la Administración Contratante requiera su inclusión, deberá justificar técnicamente la necesidad de incorporar dicho rubro en atención a la naturaleza, complejidad o riesgos asociados al objeto contractual, así como definir expresamente su estructura y forma de aplicación dentro del pliego de condiciones.
De esta forma se tiene que la estructura de precio en valores absolutos para cada moneda ofertada es:

13.7 A partir de la estructura de precio en valores absolutos, se establecerán las ponderaciones en valores porcentuales de los costos directos e indirectos, así como los valores porcentuales de la utilidad e imprevistos.
13.8 Dichos valores porcentuales se determinarán dividiendo cada valor absoluto entre el precio total o unitario, según corresponda, de conformidad con la moneda en que se presentó dicho precio, cuya sumatoria deberá resultar en cien por ciento (100%).
13.9 De esta forma se tiene que la estructura de precio en valores porcentuales, en concordancia con cada moneda en que se presentó el precio, es:

Para la presentación del DESGLOSE DE LA ESTRUCTURA DE PRECIO, se requiere que el oferente complete y presente la siguiente tabla:
Componente Valores absolutos
(en concordancia con la moneda en que se presentó el precio). Sumatoria de las ponderaciones en valores porcentuales
% Índice para eventual reajuste o revisión de precios
Costos directos de la mano de obra 0,00 XX% *Indicar el índice respectivo
Costos directos de los insumos 0,00 XX% *Indicar el índice respectivo
Costos por las subcontrataciones (si aplica) 0,00 XX% *Indicar el índice respectivo
Costos indirectos de la mano de obra 0,00 XX% *Indicar el índice respectivo
Costos indirectos de los insumos 0,00 XX% *Indicar el índice respectivo
*Costos de insumos y/o servicios (si aplica) 0,00 XX% Que serán reajustados o revisados mediante el Método analítico documental
Utilidad 0,00 XX% No aplica
Imprevistos 0,00 XX% No aplica
SUBTOTAL SIN IVA O REMESA 0,00 100% No aplica
DETALLE DEL IVA O REMESA 0,00 2%, 13%, o el porcentaje que corresponda. REMESA EN CASO DE APLICAR No aplica
TOTAL CON IVA O REMESA 0,00 No aplica No aplica

*Nota para los *Costos de insumos y/o servicios (si aplica): Cuando no exista un índice de precios, específico oficial o uno similar, que represente las variaciones de un determinado costo directo o indirecto, el oferente deberá advertirlo así en su oferta, y se podrá aplicar el método analítico-documental, de conformidad con lo regulado en el artículo 14 del RRRP y en concordancia con lo establecido en los artículos 102, 107, 108 y 109 del RLGCP.
14. PRESUPUESTO DETALLADO
14.1 El presupuesto detallado corresponde a la memoria de cálculo elaborada por el adjudicatario o el contratista, según corresponda, que sustenta cada estructura y precio de las líneas o renglones de pago del contrato, la cual conforme al objeto contractual desglosará los costos directos e indirectos y demás componentes del precio, de manera que se puedan conocer con precisión al menos el detalle de los costos directos de los recursos materiales, equipos, maquinaria, subcontrataciones, mano de obra, las cargas sociales respectivas, así como sus costos indirectos, su utilidad e imprevistos. Todo de conformidad con el artículo 42 de la LGCP y los artículos 102, 103 y 104 del RLGCP.
14.2 El presupuesto detallado de la obra, bien o servicio contratado deberá ser presentado únicamente por el adjudicatario dentro del plazo de ocho días hábiles posteriores a la firmeza de la adjudicación y antes de la suscripción del contrato. Si no se entrega en ese plazo, el Administrador del contrato declarará insubsistente la adjudicación y actuará según el artículo 52 de la LGCP.
14.3 El presupuesto detallado debe ser concordante con la estructura de precio de la oferta, tanto en valores absolutos como en la o las monedas en que cotizó su precio. En caso de presentarse discrepancias entre la estructura de precio y el presupuesto detallado, prevalecerán los valores absolutos de la estructura de precio, para ello el adjudicatario deberá ajustar el presupuesto a dichos valores.
14.4 El adjudicatario deberá indicar en el presupuesto detallado la vinculación de los índices de precios y/o la documentación probatoria aportada en su oferta, asociada a cada uno de los costos directos e indirectos de dicho presupuesto.
14.5 El presupuesto detallado desglosará los componentes de cada actividad o unidad de la obra, unidad del bien, o unidad de servicio, según corresponda, indicando al menos sus costos directos, que considere como mínimo los recursos de materiales, mano de obra con el detalle de cargas sociales, equipos y maquinaria e identificación de los subcontratos, sus costos indirectos, su utilidad e imprevistos.
14.6 Para la presentación del Presupuesto Detallado, el adjudicatario debe ajustarse al siguiente formato y completar el siguiente cuadro:
DETALLE DEL PRESUPUESTO DETALLADO
DETALLE DE LOS COSTOS DIRECTOS
Componentes mínimos Cantidad Precio unitario Precio total Indicar vinculación con el índice de precios
Mano de obra directa con el detalle de las cargas sociales.
Insumos directos
Equipos y maquinaria
Subcontratos
TOTAL DE COSTOS DIRECTOS =sumatoria de precio total
COSTOS INDIRECTOS
Componentes mínimos Cantidad Precio unitario Precio total Indicar vinculación con el índice de precios
Mano de obra indirecta
Insumos indirectos
TOTAL DE COSTOS INDIRECTOS =sumatoria de precio total
UTILIDAD 0,00
IMPREVISTOS 0,00
SUBTOTAL SIN IVA 0,00
MONTO DEL IVA 0,00
TOTAL CON IVA 0,00

Nota: En cuanto a los componentes de los costos se indican como mínimos, pero el adjudicatario puede ampliar o incluir otros componentes según sea el giro de su negocio.
Como referencia se presenta un cuadro resumen de los componentes mínimos respecto a las Cargas Sociales relacionadas con la mano de obra que debe incluirse en el presupuesto detallado:
CCSS PATRONO
SEM 9,25%
IVM 5,42%
TOTAL 14,67%
OTRAS INSTITUCIONES PATRONO
BANCO POPULAR 0,25%
ASIGNACIONES FAMILIARES 5,00%
IMAS 0,50%
INA 1,50%
TOTAL 7,25%
LEY DE PROTECCION AL TRABAJADOR PATRONO
BANCO POPULAR 0,25%
FONDO DE CAPITALIZACION LABORAL 1,50%
OPERADORA DE PENSIONES COMPLEMENTARIA 2,00%
INS 1,00%
TOTAL 4,75%
RESUMEN PATRONO
PORCENTAJES TOTALES 26,67%

*Nota: La póliza de riesgo será definida a discrecionalidad de cada oferente.

15. REVISIÓN DE PRECIOS EN BIENES Y SERVICIOS
15.1 EXCLUSIONES DE LA APLICACIÓN DEL RRRP.
En caso de que el oferente decida voluntariamente presentar su oferta en una moneda distinta a la moneda de origen de los costos (*), ello imposibilita la aplicación del reajuste o la revisión de precios regulado en este reglamento, debido a la ausencia de información concordante entre la moneda de origen de los costos y de la moneda ofertada. No obstante, se podrá interponer el reclamo administrativo cuando el contratista demuestre variaciones sobrevinientes en los costos directos e indirectos, siempre y cuando no sean atribuibles a la variación del tipo de cambio de la moneda ofertada con relación al colón como unidad monetaria de Costa Rica.
(*) origen de los costos debe entenderse como el país donde se generan económicamente los gastos asociados a cada componente de la estructura de precios del objeto ofertado).
15.2 INFORMACIÓN REQUERIDA PARA LA APLICACIÓN DE LA REVISIÓN DE PRECIOS EN LA EJECUCIÓN CONTRACTUAL:
A efectos de la aplicación del mecanismo de revisión de precios, regulado en el RRRP, el Administrador del contrato deberá verificar y documentar que, al momento de emitirse la orden de inicio de la ejecución contractual, posee al menos, la siguiente información:
a) La "no objeción" de la pertinencia de los índices de precios.
b) La "no objeción" del cronograma con las fechas acordadas entre las partes.
c) Concordancia entre el presupuesto detallado y la estructura de precio.
d) Determinación del monto del pago anticipado para su otorgamiento, si procede.
e) La "no objeción" de pertinencia de la documentación probatoria para aplicar el método analítico-documental, si procede.
f) Las fórmulas matemáticas de la revisión de precios regulados en el RRRP, acordes con la o las estructuras de precios de las líneas o los renglones de pago.

16. CRONOGRAMA CON LAS FECHAS ACORDADAS POR LAS PARTES:
16.1 El cronograma con las fechas acordadas por las partes se constituye en la herramienta de control oficial en la que se establece la planificación de las entregas de los bienes y la prestación de los servicios de un contrato, el cual deberá tener un nivel de detalle que permita dimensionar los esfuerzos necesarios para controlar el avance de las entregas de los bienes o la prestación de los servicios.

16.2 El adjudicatario presentará el cronograma preliminar propuesto con sus documentos anexos, el cual deberá incluir duraciones, holguras, dependencias, secuencia lógica, hitos, ruta crítica, según corresponda, y demás información de planificación, dentro de los ocho días hábiles posteriores a la firmeza de la adjudicación. En un máximo de cinco días hábiles a partir de su presentación, el Administrador del contrato deberá revisar y resolver acerca de la pertinencia o no del cronograma propuesto y sus documentos anexos, de conformidad con los términos establecidos en el pliego de condiciones y en el RRRP.

16.3 Si la Administración no requiere de aclaraciones por parte del adjudicatario o modificaciones del cronograma preliminar ni de sus documentos anexos, es decir, cumple cabalmente con los términos contractuales y del presente reglamento, la Administración emitirá mediante acto motivado la "no objeción" a dicho cronograma, por medio del cual se oficializará éste. Caso contrario, la Administración devolverá al adjudicatario el cronograma propuesto y sus documentos anexos, con las indicaciones de los términos contractuales y del presente reglamento que no se cumplen, para que el adjudicatario proceda con las correcciones pertinentes.

16.4 El adjudicatario presentará el cronograma preliminar con sus documentos anexos debidamente corregido y/o ajustado en un plazo no mayor a tres días hábiles, a partir del momento de su devolución por parte de la Administración. La Administración tendrá tres días hábiles para posteriormente emitir su "no objeción" a dicho cronograma.

16.5 El incumplimiento del requisito de la "no objeción" del cronograma, cuando este atraso sea por única y exclusiva responsabilidad del contratista, impedirá la emisión de la orden de inicio del contrato. Todo ello sin detrimento de las multas y demás sanciones que procedan según lo dispuesto en el pliego de condiciones, la oferta, la adjudicación, la formalización contractual y el contrato o documento equivalente.

16.6 En los tres días hábiles posteriores a la notificación oficial de la orden de inicio, el contratista deberá entregar al Administrador del contrato de contrato el cronograma inicial con sus documentos anexos, el cual corresponde a la presentación del cronograma preliminar previamente oficializado por el Administrador del contrato con la incorporación de las fechas de inicio y finalización de la entrega de los bienes o prestación de los servicios, así como la inclusión de cualquier otro ajuste necesario y debidamente justificado, todo conforme con la fecha notificada del inicio de la ejecución contractual.

16.7 En un máximo de tres días hábiles a partir de su presentación, la Administración deberá revisar y resolver acerca de la pertinencia o no del cronograma inicial y sus documentos anexos. Si la Administración no requiere de aclaraciones por parte del contratista o modificaciones, es decir, el cronograma inicial cumple cabalmente con los términos contractuales y del presente reglamento, la Administración emitirá mediante acto motivado la "no objeción" a dicho cronograma, por medio del cual se oficializará éste para todos los efectos contractuales.
16.8 Caso contrario, la Administración devolverá al contratista la propuesta del cronograma inicial y sus documentos anexos, con las indicaciones de los términos contractuales y del presente reglamento que no se cumplen, para que el contratista proceda con las correcciones pertinentes. El contratista presentará el cronograma inicial con sus documentos anexos debidamente corregido y/o ajustado en un plazo no mayor a tres días hábiles, a partir del momento de su devolución por la Administración. La Administración tendrá tres días hábiles para posteriormente emitir su "no objeción" a dicho cronograma.

16.9 Para las contrataciones de entrega según demanda, conforme a lo dispuesto en el artículo 74 de la LGCP y el artículo 195 del RLGCP, en donde el Administración adquiere determinados bienes y servicios según sus necesidades, el contratista deberá aportar el cronograma con la incorporación de las fechas de entrega de los bienes o la prestación de servicios, todo conforme a lo establecido en el pliego de condiciones y las órdenes de pedido o documento equivalente específico que se emita, ello a más tardar dentro de los tres días hábiles posteriores a su notificación y el Administrador del contrato contará con igual plazo para emitir mediante acto motivado la "no objeción" de dicho cronograma, siempre y cuando cumpla con las condiciones contractuales y lo regulado en el RRRP.

16.10 Caso contrario, el Administrador del contrato devolverá al contratista el cronograma propuesto y sus documentos anexos, con las indicaciones de los términos contractuales y del RRRP que no se cumplen, para que el contratista proceda con las correcciones pertinentes. El contratista deberá entregar el cronograma debidamente corregido y/o ajustado en un plazo no mayor a dos días hábiles, a partir del momento de su devolución por parte del Administrador del contrato, y ésta contará con igual plazo para emitir su "no objeción".

16.11 El adjudicatario y/o contratista, según corresponda, de previo a la finalización de los plazos otorgados, y en casos excepcionales, podrá requerir al Administrador del contrato la ampliación de dichos plazos, cuando cuente con la debida fundamentación para ello, en virtud de la complejidad del asunto, lo cual deberá ser resuelto por el Administrador del contrato, la que podrá ampliar los plazos citados hasta por un término de quince días hábiles, dejando constancia en el expediente respectivo.

El Administrador del contrato, en casos excepcionales en virtud de la complejidad del análisis, podrá ampliar los plazos establecidos para resolver, hasta por un término de quince días hábiles, contando para ello con la debida fundamentación, dejando constancia en el expediente respectivo.

17. DOCUMENTOS ANEXOS DEL CRONOGRAMA PARA CONTRATOS DE BIENES Y SERVICIOS:
Para efectos de la determinación de la revisión de precios y para la correcta trazabilidad de la ejecución contractual, todo cronograma elaborado por el contratista deberá acompañarse de un informe de apoyo que incluya, cuando corresponda, al menos lo siguiente:
a) Las jornadas laborales diarias (diurnas, nocturnas, mixta u otras que el ordenamiento jurídico faculte) y semanales de trabajo que prevé adoptar el contratista, conforme a las regulaciones del pliego de condiciones y el contrato o documento equivalente.
b) Recursos y costos asignados por entrega de bienes y prestación de servicios, tales como cantidades y tipo de personal, maquinaria y equipo a utilizar y sus respectivos rendimientos.
c) Una descripción general de los procedimientos operativos que prevé adoptar el contratista para la ejecución del contrato.
d) Descripción de las actividades planificadas para la entrega de los bienes o prestación de los servicios, vinculadas a las líneas o los renglones de pago del contrato. Cada actividad debe especificar la línea o el renglón de pago asociado, identificando su respectivo código, todo ello con el fin de dar trazabilidad a la determinación objetiva del pago y de la revisión de los precios.
e) Cantidades planificadas de la entrega de los bienes o la prestación de los servicios en cada mes calendario, especificando la línea o el renglón de pago contractual asociado a dicha entrega o prestación, todo de conformidad con el cronograma.
f) Avance físico proyectado por mes calendario, tanto del objeto contractual como de las entregas de los bienes o la prestación de servicios.
g) Programa de los desembolsos de los pagos proyectados por mes calendario que determinará la línea base del avance financiero del contrato, en función a las cantidades planificadas de la entrega de los bienes o la prestación de los servicios.

18. ACTUALIZACIÓN DEL CRONOGRAMA VIGENTE:
Para efectos de la determinación de la revisión de precios, el Administrador del contrato deberá exigir al contratista que mantenga actualizado el cronograma vigente, así como sus documentos anexos, desde el inicio hasta la finalización del plazo de vigencia del contrato.
A solicitud del contratista, o en virtud de la gestión del Administrador del contrato, se podrá emitir la "no objeción" a la actualización del cronograma vigente, en caso de proceder ésta, por los siguientes motivos:
a) Prórrogas al plazo de ejecución del contrato.
a) Suspensiones del plazo del contrato por motivos de caso fortuito o fuerza mayor.
b) Modificaciones unilaterales ordinarias y excepcionales del objeto del contrato que modifiquen el plazo original del contrato.
c) Incorporación de un nuevo renglón de pago durante la ejecución contractual, que no se haya podido prever al momento de iniciar la contratación, por corresponder a una modificación unilateral del contrato.
d) Afectaciones del cronograma vigente, debido a demoras ocasionadas por el Administrador del contrato o causas ajenas al contratista originadas por caso fortuito o fuerza mayor.
En un máximo de cinco días hábiles a partir de la presentación de la solicitud por parte del contratista o en virtud de la gestión del Administrador del contrato para la actualización del cronograma y sus documentos anexos, el Administrador del contrato deberá revisar y resolver acerca de la pertinencia o no de dicha actualización propuesta. Si el Administrador del contrato no requiere de aclaraciones por parte del contratista o modificaciones de la propuesta de actualización, pues esta resulta concordante con los motivos señalados en este artículo y cumple cabalmente con el pliego de condiciones, el contrato y el RRRP, el Administrador del contrato emitirá mediante acto motivado la "no objeción" a la actualización del cronograma.
Caso contrario, el Administrador del contrato devolverá al contratista la propuesta de actualización con las indicaciones respectivas, para que el contratista proceda con las correcciones y/o ajustes pertinentes. En un plazo no mayor a tres días hábiles, a partir del momento de su devolución por parte del Administrador del contrato, el contratista deberá entregar la propuesta debidamente corregida y/o ajustada, y el Administrador del contrato contará con un plazo igual para emitir mediante acto motivado la "no objeción" de la actualización del cronograma.
El contratista, de previo a la finalización de los plazos otorgados, y en casos excepcionales, podrá requerir al Administrador del contrato la ampliación de dichos plazos, cuando cuente con la debida fundamentación para ello, en virtud de la complejidad del asunto, lo cual deberá ser resuelto por el Administrador del contrato, la que podrá ampliar los plazos citados hasta por un término de quince días hábiles, dejando constancia en el expediente respectivo.
El Administrador del contrato, en casos excepcionales, podrá ampliar los plazos citados hasta por un término de quince días hábiles, contando con la debida fundamentación para ello en virtud de la complejidad del análisis, dejando constancia en el expediente respectivo.

19. DECLARACIONES JURADAS DEL OFERENTE
En cumplimiento de lo dispuesto por la LGCP en sus artículos 18, 24, 28 y 29, así como por el Reglamento a dicha ley en sus artículos 31 y 32, y actuando en calidad de oferente o subcontratista para este procedimiento de contratación pública, el oferente, según corresponda, debe considerar lo indicado en el Anexo 1 o Anexo 2, adjunto a este pliego de condiciones.

20. SOBRE PATENTE COMERCIAL O INSTRUMENTAL
20.1 En atención al análisis efectuado respecto al objeto contractual del presente procedimiento, se estima que la patente municipal constituye un requisito sustantivo, en tanto se encuentra íntimamente vinculada con el objeto contractual y con la idoneidad del oferente para ejecutarlo desde el inicio. En efecto, el objeto contractual refiere a una actividad que requiere contar con la debida autorización municipal para operar legalmente desde el primer día de ejecución. La ausencia de dicha autorización no solo afectaría la legalidad del contrato, sino que podría dar lugar a sanciones administrativas, suspensión de actividades, o imposibilidad fáctica de cumplir con la obligación contractual.
20.2 Por consiguiente, se justifica que la patente municipal sea exigida como requisito sustantivo, de manera que el oferente nacional debe adjuntar la copia de la patente a la oferta, en aras de garantizar que cuenta con la habilitación legal necesaria para ejecutar el contrato y prevenir riesgos de incumplimiento o clausura.

21. RANGOS DE TOLERANCIA
21.1 En seguimiento a lo dispuesto en el artículo 44 RLGCP, durante la etapa de análisis de ofertas y como parte de la razonabilidad del precio, conforme a lo indagado en el banco de precios, estudio de mercado, y fuentes confiables la Administración se reserva el derecho de aplicar las siguientes bandas de tolerancia:
21.1.1 Para la línea 1 suscripción, se define una banda de tolerancia banda de tolerancia del veinte por ciento (20%) como margen inferior y del veinte por ciento (20%) como margen superior.
21.1.2 Para la línea 2 implementación, se define una banda de tolerancia banda de tolerancia del veinte por ciento (20%) como margen inferior y del diez por ciento (10%) como margen superior.
21.1.3 Para la línea 3 implementación, se define una banda de tolerancia banda de tolerancia del veinte por ciento (20%) como margen inferior y del cuarenta por ciento (40%) como margen superior.

21.1.4 El oferente que aun conociendo el precio de referencia y las bandas de tolerancia fijadas cotiza un precio por encima o debajo de ellas, deberá presentar en su oferta una justificación para análisis del Administrador del Contrato, en la que se detallen esas razones.

En caso de que un oferente cotice fuera de dichas bandas, el Administrador del contrato procederá de conformidad a lo estipulado en el artículo 106 del RLGCP.

22. CONTENIDO PRESUPUESTARIO:
Según lo previsto en el artículo 87 RLGCP el administrador del contrato acredita que, contará con los recursos presupuestarios suficientes para enfrentar la erogación respectiva al correspondiente ejercicio presupuestario. Adicionalmente para atender lo estipulado en el artículo 8 del Reglamento Interno de Contratación Pública del BCCR-ODM y según el oficio BCCR-JD-GRC-OFC-0029-2026 se estará incluyendo en la formulación presupuestaria 2027 los recursos necesarios para atender el pago correspondiente. El presupuesto plurianual necesario para los periodos restantes será incluido en los siguientes ejercicios presupuestarios.

 

 

23. FORMA DE PAGO POR RESULTADOS
De conformidad a lo indicado en el artículo 18 del RLGCP el Administración utilizará para cancelar sus obligaciones, el pago por resultados, una vez que haya recibido a satisfacción los servicios, así como la satisfacción de indicadores previamente pactados y sea presentada la factura conforme a derecho.
23.1 Forma de pago
El pago se realizará de conformidad con el cronograma de trabajo acordado entre las partes y en función de las horas efectivamente consumidas en la prestación de los servicios, según las líneas de servicio definidas en el presente documento.
23.1.1 El pago se realizará para los derechos de uso de la herramienta habilitados y recibidos que hayan sido aceptados a entera satisfacción por los Administradores del Contrato, quien se reserva el derecho de aprobar o solicitar modificaciones en concordancia con el objeto del presente contrato.
23.1.2 Reglón 1: de la suscripción, se realizará el pago una vez implantada y puesta en marcha la herramienta en los sistemas del Banco y posteriormente de forma anual.
23.1.3 Reglón 2: se pagará conforme cada entregable haya sido aceptado a satisfacción por el Administrador del Contrato, quien se reserva el derecho de aprobar o solicitar modificaciones en concordancia con el objeto del presente contrato.
23.1.3.1. Se pagará el 10% cuando se haya recibido a entera satisfacción por parte del Administrador del Contrato la fase 1
23.1.3.2. Se pagará el 35% cuando se haya recibido a entera satisfacción por parte del Administrador del Contrato los entregables de la fase 2.
23.1.3.3. Se pagará el 15% cuando se haya recibido a entera satisfacción por parte del Administrador del Contrato los entregables de la fase 3 y 4
23.1.3.4. Se pagará el 40% restante al concluir la fase 5

Fase Actividad Entregables Porcentaje de pago
1. Planeación Definir y planificar las actividades necesarias para la implantación de la herramienta. 1. Plan del proyecto
2. Cronograma detallado de actividades.
3. Definición de hitos y responsables.
4. Definición de perfiles. 10%
2. Construcción y desarrollo Configurar la herramienta conforme a los requerimientos funcionales (debida diligencia, perfiles de riesgo, monitoreo transaccional) y realizar las integraciones con los sistemas internos del BCCR (Portal Central Directo, bases de datos y servicios web).
Entrega de manuales funcionales y técnicos. 5. Herramienta configurada.
6. Módulos funcionales habilitados
7. Integraciones técnicas implementadas.
8. Manuales de usuario y manual técnico. 35%
3. Pruebas Ejecutar el plan de pruebas Resultado del plan de pruebas. 15%
4. Capacitación Elaborar el plan de capacitación.

Ejecutar el plan de capacitación. Plan de capacitación

Actividades de capacitación (cursos)
5. Puesta en producción (Liberación) Planear actividades de liberación.

Ejecutar actividades de liberación. Plan de liberación.

Liberación del sitio en ambiente productivo. 40%

23.1.4 El reglón 3: Horas consumibles, se cancelarán según se vayan empleando hasta alcanzar el máximo anual presupuestado (100 horas máximo), conforme el requerimiento y el entregable haya sido aceptado a satisfacción por el Administrador del Contrato, quien se reserva el derecho de aprobar o solicitar modificaciones en concordancia con el objeto del presente contrato.

24. CONDICIONES PARTICULARES PARA OFERENTES EXTRANJEROS
La oferta económica debe incluir todos los costos en que incurra la empresa. No se reconocerá ningún monto adicional no incluido en la oferta inicial. Debe incluir el costo de las remesas que corresponde a un 25%.

 

25. REMESAS APLICABLES A OFERENTES NO DOMICILIADOS EN COSTA RICA:
En el caso de que un oferente no domiciliado en Costa Rica resulte adjudicado, el BCCR procederá a realizarle las retenciones aplicables por concepto de remesas al exterior, estipuladas en los artículos del 52 al 58 de la Ley del Impuesto sobre la Renta (ley 7092) y su Reglamento. Asimismo, y para evitar una doble imposición, tales retenciones se harán conforme con lo establecido en los convenios internacionales aprobados por el Gobierno de Costa Rica, así como dentro de lo dispuesto por la demás normativa tributaria vigente al momento de realizar el (los) pago (s).
26. DOCUMENTOS APOSTILLADOS:
De conformidad con la resolución de la Contraloría General de la República número R-DCA-SICOP-00559-2023 y el criterio emitido al BCCR por parte de la Dirección de Contratación Pública del Ministerio de Hacienda número MH-DCoP-OF-0393-2024, esta Administración destaca y motiva que para el presente procedimiento de contratación se ha considerado que, en apego a los principios de celeridad, eficiencia, eficacia y simplicidad, se estarán solicitando únicamente apostillados y hasta en etapa de ejecución contractual (en caso de requerirse documentos de carácter público), los documentos que establece el artículo 1 de la Ley N°8923 “Convención para la Eliminación del Requisito de Legalización para los Documentos Públicos Extranjeros (Convención de la APOSTILLA)”, que serían:
• Documentos provenientes de una autoridad o un oficial conectado con las cortes o tribunales del Estado, incluyendo aquellos provenientes de un fiscal, un escribano de la corte o un notificador ("huissier de justice");
• Documentos administrativos;
• Actas notariales;
• Certificados oficiales puestos en documentos firmados por personas en su calidad privada, tales como certificados oficiales que consignan el registro de un documento o el hecho de que era existente en determinada fecha y autenticaciones oficiales y notariales de firmas.
Lo anterior producto de que esta Administración ha determinado otras vías o documentos para confirmar los requisitos de cumplimiento descritos en el pliego, y es la forma en que se ha determinado como idónea de acreditarla, basado en lo que indica el artículo 94 del Reglamento a la Ley General de Contratación Pública.
Por lo tanto, propiamente para este procedimiento de contratación no se requiere ningún documento con el requisito de apostilla.

27. PROCEDIMIENTO DE FORMALIZACIÓN CONTRACTUAL
En caso de licitación mayor o licitación menor, el contrato será suscrito por el funcionario legalmente facultado para tales efectos en la Administración y por el representante legal del contratista en SICOP.

28. DEFINICIÓN DE LOS PARÁMETROS PARA CONSTATAR LA CALIDAD DEL BIEN O SERVICIO QUE SE LLEGUE A CONTRATAR
De acuerdo con la selección de criterios, los criterios a evaluar en la fase pos licitatoria son los siguientes:
28.1.1 La implantación y entrega de la suscripción debe realizarse dentro del plazo y forma acordada, la comprobación del buen funcionamiento del objeto contractual, la suscripción debe cumplir con todas las normativas y regulaciones aplicables y el servicio proporcionado debe cumplir con los estándares de calidad específicos.

29. PRINCIPIO DE CALIFICACIÓN ÚNICA

De conformidad a lo descrito en el artículo 134 del RLGCP en la etapa de revisión de ofertas solo se permite un subsane/aclaración por oferta, por lo tanto, se les solicita a los oferentes presentar su oferta en el mismo orden en que está descrito el pliego de condiciones y adjuntar la prueba documentaria en los casos que así se haya solicitado.

30. OBLIGACIONES DEL CONTRATISTA
El contratista estará obligado a ejecutar el objeto contractual en estricto apego a las condiciones establecidas en el contrato, el presente pliego de condiciones, sus anexos, la oferta adjudicada y la normativa vigente aplicable en materia de contratación pública. Debido a que el contratista, y su equipo de trabajo deberán efectuar el servicio con información del BCCR, deberá coordinar de previo con las personas administradoras, suministro de la información de modo que no se afecten las funciones del BCCR, ni se ocasionen demoras en lo contratado.

31. FINIQUITO DEL CONTRATO.
Dentro del plazo de seis meses, contados a partir de la recepción definitiva del objeto contractual, conforme a lo previsto por el artículo 291 del Reglamento a la Ley General de Contratación Pública, las personas administradoras en coordinación con el contratista, y la Asesoría Jurídica, realizarán las gestiones pertinentes para formalizar dicho acto.

32. ADMINISTRADOR DEL CONTRATO:
Con el objeto de supervisar esta contratación, gestionar, facilitar la coordinación de todos los aspectos técnicos y administrativos que se requieran, formalizar mediante minutas o actas los alcances interpretativos que se produzcan durante la ejecución contractual, regular todo lo relativo a la correcta ejecución de la misma, y velar por el perfecto cumplimiento de cada una de las obligaciones indicadas en el pliego de condiciones y en el contrato, el BCCR ha designado como administradores del contrato a los siguientes funcionarios: Adriana Corrales Rojas correo corralesra@bccr.fi.cr, teléfono 2243-3643 y William Mauricio Lewis Álvarez, correo lewisaw@bccr.fi.cr, teléfono 2243-3678.