1 / 19

Sistema de Alarmas de Mercado Aspectos Tecnológicos

Sistema de Alarmas de Mercado Aspectos Tecnológicos. X Reunión Responsables de Sistemas de Información La Antigua, Guatemala Setiembre 2008. Agenda. Objetivos del sistema Alcance del sistema Estrategia de implementación Definición y validación de arquitectura. Objetivo General.

javen
Download Presentation

Sistema de Alarmas de Mercado Aspectos Tecnológicos

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Sistema de Alarmas de Mercado Aspectos Tecnológicos X Reunión Responsables de Sistemas de Información La Antigua, Guatemala Setiembre 2008

  2. Agenda • Objetivos del sistema • Alcance del sistema • Estrategia de implementación • Definición y validación de arquitectura

  3. Objetivo General • Brindar al Área de Análisis de Riesgos y Operaciones una herramienta de detección y seguimiento de alarmas bursátiles, que le permita la identificación temprana de transacciones que se alejan de las condiciones normales de negociación

  4. Objetivos específicos • Permitir el registro de criterios sobre los cuales se pueda determinar la existencia o no de una anomalía (Indicadores). • Generar alarmas con base en dichos indicadores que alerten a los analistas responsables en el momento que se detecte una operación dentro de los parámetros que se establezcan para esos criterios. • Permitir a los analistas y otro personal involucrado, el seguimiento de las alarmas generadas. • Proveer a los analistas de herramientas (reportes) para complementar el análisis de una determinada alarma.

  5. Modelo conceptual

  6. Monitorear información • Ejecuta los indicadores en el momento adecuado • Tres tipos de ejecución: • Cada vez que se “carga” información (ej. Web Service provisto por BNV) • Al finalizar la sesión bursátil • A petición de usuario • Almacena la información específica de las alarmas generadas • Notifica a los analistas las alarmas generadas • El analista tiene un cliente para notificaciones inmediatas y también recibe un correo electrónico con las alarmas no atendidas. • Desde las notificaciones los analistas pueden acceder el detalle de la alarma

  7. Consultar Alarmas • Acceso a las alarmas del día o históricas (consulta, analistas y supervisores). • Detalles como comentarios realizados, tiempo restante para generar niveles de atención • Herramientas de apoyo al análisis de las alarmas • Actualización automática en tiempo real

  8. Administrar Alarmas • Visualiza el detalle de la alarma: datos almacenados al generarse • Permite ingresar al módulo de análisis y comentarios • Visualización por parte de los usuarios de consulta • Revisión por parte del usuarios supervisor • Invocar los reportes asociados al indicador

  9. Administrar Alarmas • Enviar correos con base en la alarma generada, incluyendo datos del detalle así como una liga al detalle de la alarma en el sistema • Notifica alarmas no atendidas por día a los analistas y supervisores.

  10. Generar Reportes • Permite visualizar dos tipos de reportes: • Los reportes del uso e información del sistema (bitácoras de uso del sistema, listado de alarmas generadas vs. atendidas y demás datos de uso del sistema) • Reportes de apoyo para el análisis de una alarma que se han definido para cada indicador, los cuales son tanto listados de información como gráficos: • Estos están a disposición del analista una vez que cualquier alarma haya sido generada • Reciben parámetros de la alarma generada • Pueden ser invocados independientemente de la alarma (el usuario ingresa los parámetros)

  11. Administrar Usuarios • Permite agregar usuarios al sistema (analistas, supervisores, usuarios de consulta y administradores) • Reasignación temporal y definitiva de indicadores • Reasignación de alarmas no atendidas • Creación de niveles de atención

  12. Administrar indicadores • Permite listar todos los indicadores definidos en el sistema y modificar sus propiedades y parámetros. • Permite administrar datos del sistema como por ejemplo emisiones que forman la curva soberana, hora de finalización de sesión y otros datos generales • Auditable: se registrar en una bitácora todo cambio que se haga

  13. Estrategia de desarrollo • Desarrollar un prototipo para probar y afinar la arquitectura base y contar con tiempos estimados de desarrollo más objetivos • Desarrollo y puesta en producción de una primera versión del sistema con 9 indicadores en el primer semestre del 2007 • Desarrollo y puesta en producción de una segunda versión del sistema con 14 indicadores para setiembre 2007 • Desarrollo y puesta en producción de la tercera versión del sistema con 23 indicadores en enero del 2008

  14. Objetivos del prototipo • Diseñar y validar la arquitectura base • Tener una mejor visibilidad de las tareas y tiempos necesarios para el desarrollo de cada indicador

  15. Elementos del Prototipo Usuarios del Sistema 11 / 28 Alarmas Generadas 7 / 23 Motor de Análisis (Indicadores) Sugeval

  16. Aspectos importantes incluidos en la arquitectura del prototipo • Conexión con el sistema de carga de la BNV • Verificación en tiempo real de las operaciones ingresadas • Generación inmediata de la alarma e implementación de un mecanismo de persistencia para posteriormente realizar su comunicación y administración • Prueba de componentes matemáticos adquiridos y desarrollados • Precálculos parametrizados para agilizar tiempo de respuesta. • Generación de reportes y gráficos (componente de graficación adquirido) • Reportes parametrizables e invocación desde .Net. Ej: puesto de bolsa involucrado, emisión involucrada, etc. • No traslapar el cálculo de indicadores entre una carga de información y otra.

  17. Principales lecciones aprendidas • La implementación del indicador no es la actividad más compleja. La generación de datos de prueba reales, su revisión, validación de casos excepcionales y refinamiento consumen el mismo o más tiempo que dicha implementación. • Las pruebas de los indicadores no deben ser acumuladas para el final, sino que deben ser efectuadas incrementalmente

  18. Sistema de Alarmas de Mercado Aspectos Tecnológicos X Reunión Responsables de Sistemas de Información La Antigua, Guatemala Setiembre 2008

More Related