1)

Todo participante que utilice el acceso basado en internet debe conectarse al MIC de TARGET2 utilizando un cliente local, un sistema operativo y un navegador de internet conforme a lo especificado en el anexo de las especificaciones funcionales detalladas para los usuarios (UDFS) titulado “Internet-based participation-System requirements for Internet access”, con los ajustes en él definidos. La cuenta del módulo de pagos de cada participante se identificará mediante un BIC de ocho u once dígitos. Además, cada participante pasará una serie de pruebas que demuestren su capacidad técnica y operativa antes de poder participar en TARGET2-[insértese la referencia al BC/país].

2)

Para cursar órdenes de pago e intercambiar mensajes de pago en el módulo de pagos se utilizará como remitente/receptor del mensaje la plataforma BIC de TARGET2, TRGTXEPMLVP. Las órdenes de pago cursadas a un participante que utilice el acceso basado en internet deben identificar a este participante receptor en el campo de la institución beneficiaria. Las órdenes de pago cursadas por un participante que utilice el acceso basado en internet identificarán a este participante como la institución ordenante.

3)

Los participantes que utilicen el acceso basado en internet utilizarán los servicios de infraestructura de clave pública especificados en el “User Manual: Internet Access for the public-key certification service”.

1)

Los participantes que utilicen el acceso basado en internet podrán hacer los siguientes tipos de pagos:

Además, los participantes que utilicen el acceso a una cuenta del módulo de pagos basado en internet podrán recibir órdenes de adeudo directo.

2)

Los participantes respetarán las especificaciones sobre los campos de los mensajes establecidas en el libro 1 del capítulo 9.1.2.2 de las especificaciones funcionales detalladas para los usuarios (UDFS).

3)

El contenido de los campos de los mensajes se validará a nivel de TARGET2-[insértese la referencia al BC/país] de acuerdo con los requisitos de las UDFS. Los participantes podrán concertar entre sí reglas específicas sobre el contenido de los campos de los mensajes. Sin embargo, TARGET2-[insértese la referencia al BC/país] no hará comprobaciones específicas sobre si los participantes cumplen esas reglas.

4)

Los participantes que utilicen el acceso basado en internet podrán realizar por medio de TARGET2 pagos de cobertura, es decir, pagos efectuados por los bancos corresponsales para liquidar (cubrir) los mensajes de las transferencias que se presenten al banco de un cliente por otro medio más directo. Los datos sobre el cliente contenidos en esos pagos de cobertura no se mostrarán en el MIC.

1)

Toda orden de pago será objeto de una comprobación contra entradas duplicadas, cuyo fin es rechazar las órdenes de pago que se hayan cursado más de una vez por error.

2)

Se comprobarán los siguientes campos de los tipos de mensajes:

3)

Se devolverá una nueva orden de pago si todos los campos descritos en el punto 2 a ella referidos coinciden con los referidos a una orden de pago validada anteriormente.

1)

Para órdenes de pago con indicador del momento inicial de adeudo, se utilizará la palabra clave “/FROTIME/”.

2)

Para órdenes de pago con indicador del momento límite de adeudo, se dispondrá de la opción siguiente:

a)   palabra clave “/REJTIME/”: la orden de pago se devolverá si no puede liquidarse a más tardar en el momento predeterminado de adeudo;

b)   palabra clave “/TILTIME/”: la orden de pago no se devolverá, sino que se mantendrá en espera en la cola pertinente, si no puede liquidarse a más tardar en el momento predeterminado de adeudo.

En ambos casos, si una orden de pago con indicador del momento límite de adeudo no se ha liquidado 15 minutos antes del momento predeterminado, se enviará automáticamente una notificación por medio del MIC.

3)

Si se utiliza la palabra clave “/CLSTIME/”, la orden de pago se tratará igual que la orden de pago a que se refiere la letra b) del punto 2.

1)

A fin de facilitar una liquidación bruta rápida que ahorre liquidez, las órdenes de pago disponibles para la liquidación se someterán a procedimientos de compensación y, en su caso, procedimientos de compensación ampliados (términos que se definen en los puntos 2 y 3.

2)

El procedimiento de compensación determinará si las órdenes de pago del beneficiario situadas al principio de la cola de las órdenes muy urgentes o, en su caso, urgentes, pueden compensarse con la orden de pago del pagador (en lo sucesivo, “órdenes de pago compensables”). Si una orden de pago compensable no ofrece fondos suficientes para la orden de pago del pagador respectivo disponible para la liquidación, se determinará si hay suficiente liquidez disponible en la cuenta del módulo de pagos del pagador.

3)

Si el procedimiento de compensación da resultado negativo, [insértese el nombre del BC] podrá aplicar un procedimiento de compensación ampliado. El procedimiento de compensación ampliado determina si hay órdenes de pago compensables en cualquiera de las colas de espera del beneficiario, con independencia del momento en que se hayan colocado en espera. Sin embargo, si en la cola de espera del beneficiario hay órdenes de pago de mayor prioridad dirigidas a otros participantes en TARGET2, el principio FIFO solo podrá contravenirse si la liquidación de la orden de pago compensable supone un incremento de liquidez para el beneficiario.

1)

El tratamiento de las órdenes de pago en espera dependerá de la calificación de prioridad que el participante ordenante les haya asignado.

2)

Las órdenes de pago en espera urgentes y muy urgentes se liquidarán aplicando los procedimientos de compensación descritos en el apartado 6, comenzando por la orden de pago situada al principio de la cola en los casos en que haya un incremento de liquidez o una intervención en la cola (cambio de posición en la cola, momento de liquidación o prioridad, o revocación de la orden de pago).

3)

Las órdenes de pago en espera normales se liquidarán de forma continua sin perjuicio de todas las órdenes de pago urgentes y muy urgentes que aún no se hayan liquidado. Se utilizan diversos mecanismos de optimización (algoritmos). Si un algoritmo da resultado, las órdenes de pago en él incluidas se liquidarán; si falla, las órdenes se mantendrán en espera. Se aplicarán tres algoritmos (1 a 3) para compensar los flujos de pagos. Conforme al algoritmo 4, se dispondrá del procedimiento de liquidación 5 (definido en el capítulo 2.8.1 de las UDFS) para la liquidación de las instrucciones de pago de los sistemas vinculados. Para optimizar la liquidación de las operaciones muy urgentes de los sistemas vinculados en las subcuentas de los participantes se utilizará un algoritmo especial (el algoritmo 5).

4)

Las órdenes de pago disponibles para la liquidación después de iniciarse uno de los algoritmos 1 a 4 podrán no obstante liquidarse inmediatamente si las posiciones y límites de las cuentas del módulo de pagos de los participantes en TARGET2 implicados son compatibles tanto con la liquidación de esas órdenes de pago como con la liquidación de las órdenes de pago incluidas en el procedimiento de optimización en uso. Sin embargo, no se aplicarán simultáneamente dos algoritmos.

5)

En la fase de procesamiento diurno los algoritmos se aplicarán sucesivamente. Mientras no esté pendiente la liquidación multilateral simultánea de un sistema vinculado, la secuencia será la siguiente:

Si está pendiente la liquidación multilateral simultánea (“procedimiento 5”) respecto de un sistema vinculado, se aplicará el algoritmo 4.

6)

Los algoritmos se aplicarán de modo flexible mediante la fijación de un desfase temporal predefinido en su aplicación sucesiva que asegure un intervalo mínimo entre el uso de dos algoritmos. La secuencia temporal se controlará automáticamente, pero será posible la intervención manual.

7)

Mientras estén incluidas en un algoritmo en uso, las órdenes de pago no se reordenarán (no cambiarán de posición en la cola) ni revocarán. Las solicitudes de reordenación o revocación de esas órdenes de pago se colocarán en espera hasta que concluya el algoritmo. Si esas órdenes de pago se liquidan mientras el algoritmo está en uso, se rechazarán las solicitudes de reordenación o revocación; si no se liquidan, las solicitudes de los participantes se tendrán en cuenta inmediatamente.

1)

El MIC podrá utilizarse para introducir órdenes de pago.

2)

El MIC podrá utilizarse para obtener información y gestionar la liquidez.

3)

Salvo por lo que respecta a las órdenes de pago almacenadas y a los datos estáticos, solo podrán consultarse por medio del MIC datos relativos al día hábil en curso. Las pantallas estarán exclusivamente en inglés.

4)

La información se facilitará en la modalidad “pull” (“a requerimiento”), es decir, cada participante tendrá que solicitar que se le facilite la información. Los participantes comprobarán el MIC periódicamente durante el día hábil por si hubiera mensajes importantes.

5)

Para los participantes que utilicen el acceso basado en internet solo estará disponible la modalidad usuario-aplicación (U2A). La modalidad U2A permite la comunicación directa entre un participante y el MIC. La información se muestra en un navegador basado en un sistema de PC. Pueden consultarse más detalles en el manual del usuario del MIC.

6)

Todo participante dispondrá de al menos un lugar de trabajo con acceso a internet para acceder al MIC por el modo U2A.

7)

Los derechos de acceso al MIC se concederán mediante certificados, la utilización de los cuales se describe en detalle en los apartados 10 a 13.

8)

Los participantes también podrán utilizar el MIC para traspasar liquidez:

1)

El participante solicitará de [insértese el nombre del BC] la expedición de certificados que le den acceso a TARGET2 [insértese la referencia al BC/país] utilizando el acceso basado en internet.

2)

El participante solicitará de [insértese el nombre del BC] la suspensión y reactivación de los certificados, así como su revocación y renovación, cuando su titular ya no desee tener acceso a TARGET2 o si el participante cesa su actividad en TARGET2-[insértese la referencia al BC/país] (por ejemplo como resultado de una fusión o adquisición).

3)

El participante tomará todas las precauciones y medidas organizativas que aseguren que los certificados solo se utilizan de conformidad con las Condiciones uniformes.

4)

El participante notificará sin demora a [insértese el nombre del BC] todo cambio sustantivo en cualquiera de los datos contenidos en los formularios presentados a [insértese el nombre del BC] en relación con la expedición de los certificados.

5)

El participante podrá tener un máximo de cinco certificados activos por cada cuenta del módulo de pagos. Previa solicitud, [insértese el nombre del BC] podrá discrecionalmente solicitar de las autoridades certificadoras la expedición de más certificados.

1)

El participante velará por la custodia de todos los certificados y adoptará estrictas medidas organizativas y técnicas para evitar perjuicios a terceros y velar por que cada certificado lo utilice exclusivamente el titular para quien fue expedido.

2)

El participante facilitará sin demora toda la información que solicite [insértese el nombre del BC] y garantizará su veracidad. Los participantes responderán plenamente y en todo momento de que se mantenga la exactitud de toda la información facilitada a [insértese el nombre del BC] en relación con la expedición de los certificados.

3)

El participante responderá plenamente de garantizar que todos sus titulares de certificados mantengan los certificados que les hayan sido asignados separados de sus códigos secretos PIN y PUK.

4)

El participante responderá plenamente de garantizar que todos sus titulares de certificados no utilicen los certificados para funciones o finalidades distintas de aquellas para las que se expidieron.

5)

El participante informará inmediatamente a [insértese el nombre del BC] de toda solicitud de suspensión, reactivación, revocación o renovación de los certificados, así como de sus motivos.

6)

El participante solicitará inmediatamente de [insértese el nombre del BC] la suspensión de todo certificado, o de las claves que contenga, que esté defectuoso o ya no esté en poder de su titular.

7)

El participante notificará inmediatamente a [insértese el nombre del BC] toda pérdida o sustracción de los certificados.

1)

El sistema informático que el participante utilice para acceder a TARGET2 por medio del acceso basado en internet se encontrará en un local del cual el participante sea propietario o arrendatario. El acceso a TARGET2-[insértese la referencia al BC/país] solo se permitirá desde ese local; es decir, no se permitirá el acceso remoto.

2)

El participante utilizará todos los programas informáticos en sistemas informáticos instalados y adaptados con arreglo a las normas internacionales vigentes de seguridad de la tecnología de la información, que comprenderán al menos los requisitos que se detallan en los puntos 3 del apartado 12 y 4 del apartado 13. El participante adoptará medidas apropiadas, como son, en particular, la protección contra virus y malware, las medidas anti-phishing, y los procedimientos de hardening y de gestión de parches. El participante actualizará periódicamente todas estas medidas y procedimientos.

3)

El participante establecerá un enlace cifrado de comunicación con TARGET2-[insértese la referencia al BC/país] para el acceso mediante internet.

4)

Las cuentas de usuario de los lugares de trabajo del participante no tendrán privilegios administrativos. Los privilegios se asignarán conforme al principio del menor privilegio.

5)

Los participantes protegerán en todo momento como se indica a continuación los sistemas informáticos utilizados para acceder mediante internet a TARGET2-[insértese la referencia al BC/país]:

6)

El participante velará por que sus titulares de certificados sigan en todo momento prácticas de navegación seguras, como son:

7)

El participante mantendrá en todo momento los siguientes principios de gestión a fin de mitigar los riesgos para su sistema:

1)

El participante velará en todo momento, por medios organizativos o técnicos apropiados, por que las identidades de los usuarios reveladas con el fin de controlar los derechos de acceso (revisión de los derechos de acceso) no se utilicen indebidamente, y, en particular, por que no se conozcan por personas no autorizadas.

2)

El participante dispondrá de un proceso de administración de usuarios que garantice la supresión inmediata y permanente de la identidad del usuario pertinente en caso de que un empleado u otro usuario de un sistema del local de un participante deje el organismo del participante.

3)

El participante dispondrá de un proceso de administración de usuarios y bloqueará inmediata y permanentemente las identidades de usuarios que estén en situación comprometida, como en los casos de certificados perdidos o sustraídos o de contraseñas objeto de phishing.

4)

Si por tres veces un participante no es capaz de eliminar un fallo relacionado con la seguridad o un error de configuración (por ejemplo causado por sistemas infectados por malware), los BC proveedores de la plataforma compartida única podrán bloquear permanentemente todas las identidades de usuarios del participante.

1.

La comisión mensual para participantes directos por el procesamiento de órdenes de pago en TARGET2-[insértese la referencia al BC/país] será de 70 EUR por el acceso basado en internet a cada cuenta del módulo de pagos, más 100 EUR por cada cuenta del módulo de pagos, más una comisión fija de 0,80 EUR por operación (asiento de adeudo).

2.

Los participantes directos que no deseen que el BIC de su cuenta se publique en el directorio de TARGET2 pagarán una comisión mensual adicional de 30 EUR por cuenta.

3.

A los participantes directos se les aplicarán las siguientes normas de facturación. El participante directo recibirá en los cinco primeros días hábiles de cada mes la factura del mes anterior, con especificación de las comisiones a pagar. El pago se efectuará en los diez primeros días hábiles de ese mes, en la cuenta que especifique [insértese el nombre del BC], y se adeudará en la cuenta del módulo de pagos de ese participante.