Banco Central del Ecuador

Transcripción

1 DESARROLLO DE SOFTWARE DE REINGENIERÍA DEL SISTEMA NACIONAL DE PAGOS (SNP) Banco Central del Ecuador Especificaciones Técnicas del SNP

2 Página ii Contenido 1 INTRODUCCIÓN OBJETIVOS Y EXPECTATIVAS ESTÁNDARES DE LA NUEVA ARQUITECTURADEL SNP ACUERDOS DE CALIDAD DE SERVICIO CAPACIDAD DEL CANAL DE COMUNICACIONES CONECTIVIDAD Pruebas de conectividad SEGURIDAD Pruebas de seguridad MECANISMOS DE RESPUESTA A FALLOS SPI/SSP y SCI/OCP Ventanilla Compartida SPL CONTINGENCIA... 13

3 Página 1 de 15 1 INTRODUCCIÓN El SNP, es un servicio prestado por el Banco Central del Ecuador a los participantes del sector público, sector privado, sector popular y solidario y otras entidades financieras, que permite realizar transacciones directas entre las entidades (pagos, cobros y remesas), como también compensar las transacciones que los diferentes participantes hacen a nombre de sus clientes, y liquidar las posiciones netas como resultado de estas operaciones y las de las cabezas de red participantes en el sistema. Con base en este antecedente se identificó la necesidad de realizar una reingeniería de los módulos (productos) que conforman el Sistema Nacional de pagos hacia una plataforma que soporte interacciones entre aplicaciones de colaboración, basados en estándares mejorados de mensajería XML y servicios web. Adicionalmente, con el fin de fortalecer la inclusión financiera, se definió la construcción de una plataforma de servicios en línea entre el BCE y los partícipes del sistema (a través de redes privadas bancarias o internet), factible de operar con cualquier plataforma que tenga la capacidad de conectarse a través de web services. La solución propuesta consiste en reconstruir el Sistema Nacional de Pagos sobre una arquitectura orientada a servicios (SOA), que permita al BCE, a través de la utilización de servicios web, constituirse en el HUB que integre a las distintas entidades partícipes del sistema financiero, utilizando el estándar ISO como mecanismo de intercambio de información. 1 La información contenida en este documento no es fuente oficial respecto al ISO La fuente exclusiva de material e información actualizada de los estándares, mensajes y Repositorio del ISO20022 es

4 Página 2 de 15 2 OBJETIVOS Y EXPECTATIVAS El objetivo de este documento es mostrar a los partícipes del Sistema Nacional de Pagos del Banco Central del Ecuador la arquitectura sobre la cual está construido el sistema, y por ende los servicios web para la operación en el mismo, así como establecer los niveles de servicio en función de variables como: Tiempos de respuesta. Conectividad. Disponibilidad. Seguridad. Recuperación ante fallos. Con estos antecedentes se pretende brindar un servicio de calidad (con estándares internacionales) mejorando la eficacia de los productos que se ofrecen por medio del Sistema Nacional de Pagos.

5 Página 3 de 15 3 ESTÁNDARES DE LA NUEVA ARQUITECTURADEL SNP En las especificaciones técnicas entregadas a los participes del programa piloto con anterioridad se describe la funcionalidad y el intercambio de mensajes para cada producto de la nueva arquitectura. En esta sección se describen los estándares utilizados para la arquitectura de software del sistema SNP. Los diagramas usados para la descripción de la interacción entre los participantes están diseñados como procesos colaborativos B2B 2 en el estándar BPMN definido por la OMG 4. Para más información sobre el estándar BPMN 2.0, pueden referirse a la página web Los mensajes usados en los procesos colaborativos de los Servicios Bancarios del BCE y del SNP, se basan en los estándares de mensajería definidos en la norma ISO 20022, la cual se conoce como la norma más completa de todas las normas financieras y es la que se utiliza actualmente a nivel mundial dentro del sector financiero, permitiendo la interacción entre sistemas B2B de una forma más fácil, eficiente y rápida. El ISO describe los mensajes utilizando sintaxis XML, lenguaje que permite estructurar la información contenida en los mensajes, tener mayor cantidad de información, facilitar la integración entre sistemas e incrementar la funcionalidad y la adaptabilidad de los sistemas a los cambios futuros. La norma ISO 20022, define los esquemas de comunicación de los mensajes que son intercambiados en la integración de los sistemas, en formatos XSD. Para la revisión del catálogo de mensajes ISO 20022, pueden referirse a la página web La arquitectura usada para la comunicación, es una composición de servicios web de dos vías, es decir, cada partícipe debe estar en capacidad de consumir los servicios web expuestos por el sistema y también de construir y publicar servicios web a partir de un archivo WSDL versión 1.1 definido para el producto. El intercambio de mensajes para este producto se realiza de manera asincrónica (el sistema envía un mensaje a su contraparte una vez ha sido terminada una operación interna). Lo anterior implica una conexión permanente y confiable a Internet, por lo cual es altamente sugerido contar con al menos dos proveedores del canal de comunicaciones. La comunicación se hará mediante el protocolo SOAP 1.1 sobre HTTPS utilizando pares de certificados X509, (clave pública - clave privada) como mecanismo de autenticación. Por esta 2 B2B Business to Business 3 BPMN Business Process Model and Notation 4 OMG Object Management Group

6 Página 4 de 15 razón se debe contar con certificado digital X.509 Versión 3 y anexar el certificado público de la entidad certificadora (CA 5 ). 5CA Certification Authority

7 Página 5 de 15 4 ACUERDOS DE CALIDAD DE SERVICIO Como parte fundamental de la certificación de cada entidad como partícipe del nuevo sistema nacional de pagos, se debe firmar un acuerdo de calidad de servicio o acuerdo de nivel de servicio. El objetivo de este acuerdo es establecer los niveles mínimos de calidad de servicio que debe proveer cada partícipe (con el BCE incluido), para que la ciudadanía sea atendida por los partícipes a través del sistema nacional de pagos con oportunidad y eficiencia. Los acuerdos de nivel de servicio serán analizados e instrumentados para cada participe, aunque existen métricas comunes para los diferentes sectores. En principio, existen múltiples características de calidad que pueden ser medidas y controladas. Para este marco de acuerdo se tomarán en cuenta las características citadas a continuación, por su importancia estratégica y por la capacidad que tiene el BCE de medir efectivamente su cumplimiento: Precisión: La precisión de la información enviada o generada en el participe hacia el BCE debe ser total, es decir, no existe nivel de tolerancia para errores en los cálculos ni en general para cualquier información intercambiada en el sistema. La precisión decimal exigida es de 4 posiciones para cálculos y 2 para presentación con redondeo half-even. Disponibilidad: El sistema nacional de pagos funciona en horario continuo, 7x24x365. Sin embargo, es un hecho que los sistemas de información pueden tener tiempos fuera de línea tanto programados como incidentales, que afectan directamente la calidad del servicio. El acuerdo de nivel de servicio para cada partícipe implica que el sistema del partícipe debe estar disponible para atender las solicitudes de otros partícipes y enviar las solicitudes de sus propios clientes al menos el tiempo necesario en cada corte por producto certificado para procesar las transacciones entrantes y enviar las salientes procesando su correspondiente confirmación, a fin de que no se complete un corte del producto sin respuesta a las solicitudes. El tiempo total fuera de línea será monitoreado estrictamente por el BCE. Capacidad: El sistema del partícipe debe poder atender un número concurrente de peticiones acorde a su transaccionalidad histórica, teniendo en cuenta los picos pronosticados. Es un trabajo conjunto del partícipe y el BCE establecer los mínimos transaccionales necesarios para cada caso, según el tipo de producto y atendiendo a su comportamiento estadístico. Es importante recalcar que la posibilidad de transaccionar con respuestas en línea debe promover el uso eficiente de los recursos por parte de los partícipes y efectivamente distribuir de manera uniforme las transacciones a medida que son recibidas en el corte. Sin embargo, los partícipes deben estar preparados para recibir mensajes con múltiples transacciones o concentrados en ciertos momentos específicos de cada corte. Como medida de referencia, la arquitectura de software implementada por el BCE está diseñada para soportar más de 1000 TPS 6, y en promedio cada participe debería soportar alrededor de 5 TPS. Este número, de nuevo, varía 6 Transacciones Por Segundo

8 Página 6 de 15 considerablemente para cada partícipe y debe ser analizado según las estadísticas actuales y proyectadas de uso. Latencia: Es importante diferenciar dos tipos de métricas que se aplicarán para la latencia de las respuestas en el sistema. Para las transacciones síncronas 7, el tiempo de respuesta (ACK 8 ) de las solicitudes se establece en < 1sg en promedio por operación (como función del tamaño del mensaje), pero el tiempo límite (time out) se establecerá según estándares de servicios web en 15 segundos. Por otro lado, para las transacciones asíncronas 9, el tiempo que pasa entre la solicitud y la respuesta tendrá una meta establecida de no superar los 20 segundos en total (round trip). Sin embargo, es entendible que algunos partícipes puedan no alcanzar este nivel de servicio para la capacidad requerida según su transaccionalidad, por lo que se evaluará cada acuerdo por separado. En cualquier caso, ninguna solicitud individual dentro de la capacidad estimada por partícipe (en función del número de clientes y transacciones del mismo) puede ser respondida en un tiempo superior a 1 minuto. Garantía de envío de mensajes (Reliable Messaging): El sistema nacional de pagos realizará todos los esfuerzos técnicamente razonables para enviar cada uno de los mensajes que impliquen las transacciones iniciadas por sus clientes. En este sentido, es importante recalcar que un partícipe puede recibir un mismo mensaje (identificado de manera unívoca) más de una vez (ver sección 9 de este mismo documento: Mecanismos de Respuesta a Fallos). Esto implica que los sistemas de los partícipes deben prepararse para ignorar los mensajes repetidos que puedan recibir. 7 Una transacción síncrona bloquea al ordenante hasta recibir una respuesta. 8 ACK Acknowledge Acuse de Recibo 9 Una transacción asíncrona retorna un ACK y libera al ordenante. La respuesta se envía en diferido mediante un Web Service publicado por el ordenante.

9 Página 7 de 15 5 CAPACIDAD DEL CANAL DE COMUNICACIONES Como se mencionó con anterioridad, el mecanismo fundamental de transporte de información del sistema nacional de pagos es la red pública o privada de internet. Como primera medida y teniendo en mente la disponibilidad definida para el sistema, se recomienda que los partícipes puedan tener conexiones redundantes a internet con diferentes proveedores. Las instituciones que posean ya una conexión privada (enlace dedicado) con el BCE pueden seguir utilizando esta conexión, sin embargo, el uso de la red pública es una opción igualmente válida dados los mecanismos de seguridad establecidos. La capacidad del canal que se requiere varía en función de si se mantiene enlace dedicado o no, y sobre todo de la transaccionalita esperada por cada partícipe. Para establecer una medida de referencia, se ha estimado que cada transacción enviada al sistema en formato ISO20022, promediando el peso del encabezado uniformemente, tiene un tamaño de 4KB. Este número puede dar una idea clara del tamaño del canal de subida (para el volumen pronosticado de transacciones salientes) y de bajada (para el volumen pronosticado de transacciones entrantes). En particular una institución promedio debería contar con enlaces de entre 1 y 5 MBPS 10, pero de nuevo, este valor puede variar considerablemente dependiendo del partícipe. 10 Mega Bits Por Segundo

10 Página 8 de 15 6 CONECTIVIDAD La conectividad será evaluada por medio de la comunicación efectiva entre el Partícipe y el BCE y viceversa, a través del consumo de servicios web implementados tanto en el Partícipe como en el BCE. 6.1 Pruebas de conectividad Las pruebas de conectividad se realizarán tanto desde el Partícipe hacia el BCE o viceversa. Desde el Partícipe hacia el BCE.El Partícipe desarrollará un cliente de servicio web que consume el servicio web implementado por el Banco Central del Ecuador, para esto, cada partícipe recibirá la definición de los servicios web mediante un archivo o el URL correspondiente al Web Service Definition Language (WSDL por su sigla en inglés).cuando al BCE llegue la información suministrada en el servicio por el partícipe y así mismo al partícipe llegue la información de respuesta entregada por el BCE, se dará por culminada satisfactoriamente la prueba. Desde el BCE hacia el Partícipe.El Partícipe implementará el servicio web de acuerdo a la especificación suministrada (WSDL). Por su parte el BCE implementará el cliente de servicio web para consumir la funcionalidad de lo implementado por el Partícipe. Cuando al Partícipe llegue la información enviada por el cliente de servicio web del BCE y así mismo al BCE llegue la información de respuesta entregada por el Partícipe, se dará por culminada satisfactoriamente la prueba.

11 Página 9 de 15 7 SEGURIDAD La comunicación con servicios web será asegurada con el uso de certificados SSL (Secure Sockets Layer) utilizando pares de certificados X.509 (clave pública y clave privada), como mecanismo de autenticación. Por esta razón se debe contar con certificado digital X.509 Versión 3 y anexar el certificado público de la entidad certificadora (CA). Los certificados SSL serán emitidos por la Entidad de Certificación de Información del BCE; para mayor información visite Pruebas de seguridad Las pruebas de seguridad se realizarán tanto desde el Partícipe hacia el BCE como desde el BCE hacia el Partícipe luego de haber superado las pruebas de conectividad. Desde el Partícipe hacia el BCE. El Partícipe procederá a consumir el servicio web a través de un canal seguro utilizando certificados digitales. El Partícipe deberá implementar la seguridad del cliente de servicio web por medio de la estrategia Mutual Certificate definida en el WSDL con seguridad. Cuando al BCE llegue la información suministrada por el Partícipe en el servicio web y así mismo al Partícipe llegue la información de respuesta entregada por el BCE, se dará por culminada satisfactoriamente la prueba. Desde el BCE hacia el Partícipe. Desde el BCE se procederá a consumir el servicio web a través de un canal seguro utilizando certificados digitales. El Partícipe deberá implementar la seguridad del servicio web por medio de la estrategia Mutual Certificate definida en el WSDL con seguridad. Cuando al Partícipe llegue la información suministrada en el servicio web por el BCE y así mismo al BCE llegue la información de respuesta entregada por el Partícipe, se dará por culminada satisfactoriamente la prueba.

12 Página 10 de 15 8 MECANISMOS DE RESPUESTA A FALLOS Teniendo en cuenta que ningún sistema puede considerarse infalible, en caso de presentarse fallas en los servicios se considera el siguiente mecanismo de reversa. 8.1 SPI/SSP y SCI/OCP. Es un proceso asíncrono donde participan los actores: Ordenante (quién inicia la transacción), el SNP (Sistema Nacional de Pagos) y el Receptor (para quién va dirigida la transacción); se identifican los escenarios siguientes: Fig. 1 Escenarios de error productos SPI/SSP y SCI/OCP. Caso 1 (SPI1): El Ordenante envía una solicitud de pago al SNP y no recibe acuse de recibo (ACK). En este caso el Ordenante deberá consultar el servicio web de consulta, suministrado por el BCE, que responde con un reporte de las transacciones que se encuentran en el SNP (con su respectivo estado). Si la transacción no se encuentra en el reporte, el Ordenante deberá reintentar el envío de la solicitud de pago. Caso 2 (SPI2): El SNP envía la solicitud de pago al Receptor y no recibe respuesta. Dado que el SNP desconoce si la solicitud de pago fue recibida por el Receptor, el SNP intentará el envío de la solicitud de pago durante todo el día; si hasta el cierre de operaciones del SNP la solicitud no fue recibida por el Receptor, el SNP procede a: rechazar las transacciones involucradas en esa solicitud, envía la reversa de la solicitud al Receptor y genera el mensaje de respuesta (SPI4) al Ordenante con estado Rechazado. Caso 3 (SPI3): El Receptor envía el resultado de procesamiento de la solicitud al SNP y no recibe respuesta. En este caso el Receptor dispone de un servicio web de consulta que responde con un reporte de las transacciones que se encuentran en el SNP (con su respectivo estado). Si la transacción no se encuentra en el reporte, el Receptor deberá reintentar el envío del resultado hacia el SNP. Caso 4 (SPI4): El SNP envía el resultado al Ordenante y no recibe respuesta. Dado que el SNP desconoce si el resultado fue recibido por el Ordenante, el SNP reintenta el envío del resultado, si no recibe acuse de recibo satisfactorio la transacción queda en firme y es irrevocable en este punto.

13 Página 11 de 15 El reintento del envío de solicitudes de transacciones puede ocasionar múltiples registros en el Ordenante, el Receptor o en el SNP; para mitigar este inconveniente todas las partes deben validar el identificador único de la solicitud para no procesar más de una vez las transacciones por reintentos, así se ignorarán las solicitudes con igual identificador. 8.2 Ventanilla Compartida. Es un proceso síncrono donde participan los actores: Ordenante (quién inicia la transacción), el SRR (Sistema Red de Redes) y el Receptor (para quién va dirigida la transacción). Los escenarios identificados en este proceso son: Fig. 2 Escenarios de error productos ventanilla compartida Caso 1: El Ordenante envía la solicitud al SRR y se genera un timeout 11. Para este caso el Ordenante genera la reversa automática de la solicitud. Caso 2: El SRR envía la solicitud al Receptor y se genera un timeout. El SRR genera la reversa automática y la envía al Receptor, asimismo el SRR reversa su operación y envía la respuesta al Ordenante (rechazada por falta de conexión en el Receptor). Caso 3: El Receptor no puede enviar la respuesta al SRR (Error I/O, implica que se generó un timeout en el SRR). El Receptor reversa la operación y el SRR actúa conforme al Caso 2, es decir genera la reversa automática y la envía al Receptor, asimismo el SRR reversa su operación y envía la respuesta al Ordenante (rechazada por falta de conexión en el Receptor). Caso 4: El SRR no puede enviar la respuesta al Ordenante (Error I/O, implica que se generó un timeout en el Ordenante). El SRR genera la reversa automática y la envía al Receptor para que este asimismo reverse la operación y el SRR reversa su operación. 11 Tiempo límite de espera de respuesta.

14 Página 12 de SPL. SLP es un proceso asíncrono donde participan los actores: Ordenante (quien inicia la transacción) y el SNP (Sistema Nacional de Pagos). Los posibles escenarios de falla son: Fig. 3 Escenarios de error producto SPL Caso 1: El Ordenante envía la solicitud al SNP y se genera un timeout. El Ordenante debe enviar el reverso automático de su solicitud. Caso 2: El SNP no puede enviar la respuesta de recepción de la solicitud al Ordenante (Error I/O, implica que se generó un timeout en el Ordenante). El SNP reversa su proceso, el Ordenante se le presenta un timeout por lo que deberá reversar asimismo su operación. Caso 3: El SNP no puede enviar la respuesta de procesamiento de la solicitud al Ordenante (Error I/O, implica que se generó un timeout en el Ordenante). El SNP reintenta el envío del resultado, si no recibe acuse de recibo satisfactorio la transacción queda en firme y es irrevocable en este punto. Para todos los casos el Partícipe (Ordenante o Receptor) dispone de un reporte para conciliar las transacciones tanto enviadas como recibidas.

15 Página 13 de 15 9 CONTINGENCIA Este elemento básico garantiza el servicio del SNP, está representado y respaldado por un traductor cuyas funciones son: Dado un archivo de texto con el formato actual, transformar su contenido a sintaxis XML (conforme la norma ISO 20022) para su procesamiento en el Sistema Nacional de Pagos. Dado un documento XML (norma ISO 20022), transformar su contenido al formato actual (archivo de texto) para la comunicación con el Partícipe. Su utilización estará presente: Cuando, a través del SNP, un Partícipe que tiene implementados servicios web (según lineamientos del BCE) quiere comunicarse con otro que continúa manejando el esquema actual (archivos de texto). Cuando, a través del SNP, un Partícipe que no tiene implementados servicios web quiere comunicarse con otros que si tienen implementados servicios web (según lineamientos del BCE). Cuando dos Partícipes que no tienen implementados servicios web quieren comunicarse a través del SNP. Cuando por fuerza mayor se requiera de un mecanismo de contingencia para seguir proveyendo los servicios del SNP con total normalidad.