BCBS 239 y bases de datos NoSQL

El nacimiento de BCBS 239

Este blog examina los principios del BCBS 239 estrictamente a través de la perspectiva tecnológica y cómo NoSQL es relevante en el mundo del cumplimiento en la industria financiera y.

Pero antes de entrar en materia, veamos la historia del cumplimiento de la normativa y por qué se ha vuelto tan importante.

Cualquiera que haya vivido la crisis financiera de 2007/2008 y haya visto cómo sus carteras 401k se hundían hasta tocar fondo y cómo sus viviendas se valoraban al precio de una bolsa de palomitas de maíz ya sabe de lo que estoy hablando y conoce la historia que hay detrás de las normas de cumplimiento regulatorio que deben cumplir los bancos y el escrutinio al que están sometidos continuamente. Se cree que la crisis financiera de 2007/2008 se produjo porque los bancos no fueron capaces de informar eficazmente sobre los riesgos, lo que provocó un enorme colapso que condujo a la crisis. El BCBS 239 es un conjunto de principios establecidos por los organismos gubernamentales para reforzar las prácticas de agregación e información de riesgos de los bancos.

El poder creía que

  1. La incapacidad de la infraestructura informática y la arquitectura de datos para apoyar la gestión y gobernanza del riesgo condujeron a la crisis. Muchos bancos fueron incapaces de gestionar los riesgos debido a una deficiente agregación de los mismos, lo que limitó gravemente su capacidad para comunicar con exactitud la información sobre la exposición al riesgo en el momento oportuno.
  2. Mejorar la capacidad de toma de decisiones mediante la mejora de la gestión de la información en todas las entidades jurídicas para evitar que la crisis se repita. Esto incluye la capacidad de Mejorar la velocidad a la que la información está disponible
  3. Estos principios complementarían otros esfuerzos por mejorar la eficacia de la gestión de riesgos y evaluar la adecuación del capital.

Este artículo no se adentra en los entresijos de los principios enunciados en el BCBS 239, sino que se centra en el enorme papel que desempeña la tecnología en el éxito de este esfuerzo.

¿Por qué los bancos no pueden gestionar eficazmente los informes de riesgo?

Si nos fijamos en la forma en que funciona cualquier negocio hoy en día, las nuevas mesas de negociación surgen con frecuencia y los bancos están bajo una tremenda presión para ponerse rápidamente en marcha con estas nuevas entidades jurídicas. Por lo tanto, no hay tiempo para implantar estos sistemas de la forma correcta: es decir, con un almacén de datos centralizado que tenga una única versión de la verdad en la que las mejoras y/o los cambios se analicen detenidamente antes de ejecutarlos. Por lo tanto, en este escenario, las unidades de negocio de apoyo simplemente crean almacenes de datos independientes, extraen los datos y construyen su propio repositorio para no perturbar a otras unidades de negocio.

No pueden limitarse a esperar a tener la infraestructura informática ideal antes de introducir un nuevo producto o unidad de negocio. Y en el mundo actual de fusiones y adquisiciones no hay tiempo para integrar plenamente los sistemas. Así que los silos están aquí para quedarse. Cualquier esfuerzo por integrar los datos requiere varios años y millones de dólares, lo que, por decirlo educadamente, es una misión imposible.

La perspectiva informática

Cuando se mira este problema desde el otro lado de la valla, es decir, desde la perspectiva de TI, se espera que se mueva a la velocidad del negocio y ofrezca resultados. El departamento de TI no se lleva el mérito de crear un sistema de ingeniería atractivo que integre a la perfección los datos y actualice los cuadros de mando con la información más reciente. No hay tiempo para adherirse al SDLC y a la metodología de desarrollo en cascada. AGILE es la nueva forma de desarrollar sistemas, ya que tienen el negocio a sus espaldas para ver rápidamente el valor de cada centavo gastado en proyectos de TI.

La presión sobre los informáticos es inmensa y son la columna vertebral de esta embestida normativa. La integración y unificación de datos no es una tarea que se haga de la noche a la mañana y suele requerir meses o años de planificación, por lo que, aunque se disponga de presupuesto para ello, el éxito de un proyecto de este tipo está muy abierto.

Algunas comprobaciones de la realidad.....

Algunas de las cosas con las que tenemos que lidiar es el hecho de que los silos de datos están aquí para quedarse y cualquier estrategia que utilicemos tiene que trabajar en torno a ellos. Afortunadamente, gracias a los avances tecnológicos y a la forma en que se aprovechan el hardware y el software, hay partes de este problema que pueden resolverse fácil y eficazmente.

La arquitectura típica de cualquier empresa tiene este aspecto. No estoy representando las entidades o Bus dentro de un banco todo lo que quiero representar muy vagamente es cómo los datos fluyen entre los diferentes sistemas y cómo se transforman y consumen. Cada caja con múltiples bases de datos representa datos pertenecientes a una unidad de negocio o función dentro de una empresa. Esta es una visión muy simplista; en la vida real el flujo de datos parece más complicado que una intrincada tela de araña. Los consumidores de los datos representados en el círculo exterior pueden seleccionar cualquier porción de datos de cualquier etapa del ciclo de vida de la transformación de datos y crear su propio repositorio para la elaboración de informes. Así que, según a qué usuario se le pregunte, la misma pregunta puede dar lugar a respuestas diferentes o contradictorias. Y este es realmente el quid de la cuestión.

Lo que intento transmitir con esta imagen excesivamente simplificada es que

  1. Los datos están repartidos por todas partes y cada base de datos tiene su propia estructura, creada para ofrecer el máximo rendimiento y flexibilidad a sus usuarios. Así, algo puede pasar de archivos en bruto a 3NF, a modelos dimensionales (estrella y copo de nieve) y de nuevo al formato desnormalizado para facilitar su uso.
  2. Cuando alguien pone en marcha una nueva iniciativa. Preferirá sacar los datos de los sistemas existentes y crear su propio repositorio de datos con el que jugar para no pisar a nadie.
  3. Existen varias copias redundantes/no controladas de los datos que residen en diferentes áreas y cada copia es una versión diferente de la copia original, lo que dificulta enormemente la comparación y corrección de los datos.
  4. No se puede comprobar la veracidad de ningún informe porque, según de dónde proceda, la información puede ser contradictoria.

El enfoque centrado en el mercado de datos permite a TI moverse a la velocidad del negocio. Podríamos quedarnos despiertos toda la noche e inventar millones de razones sobre por qué es necesario integrar todo y cómo tener una única copia de los datos es la mejor manera de hacerlo, por desgracia los datos-silos equivalen a moverse con la velocidad del negocio.

Algunas victorias rápidas con Couchbase

Como se indica en la primera sección, deben producirse muchos cambios para que los bancos puedan evaluar la adecuación del capital y mitigar el riesgo.

Si tuviera que resumir esto rápidamente, las dos cosas clave que se me ocurren son que este problema específico es sobre todo

  1. Un problema de datos estructurados (Gracias DiosSin embargo, el esquema debe tolerar muchos cambios y reaccionar con rapidez.
  2. Problema de integración de datos ya que debe agregarse y servirse de forma rápida y altamente disponible.

Algunos frutos al alcance de la mano para ayudar en el proceso general de mitigación de riesgos y sin realizar grandes cambios perturbadores en la captura de datos y las aplicaciones responsables de proporcionar esta información.

Integración de datos: El servidor Couchbase podría utilizarse como plataforma de elección para obtener los datos de diferentes silos de una empresa y agregarlos rápidamente en el servidor. Normalmente, la cantidad de datos que hay que agregar no se sitúa en el rango de los petabytes. Suelen estar en el rango de los GB y los consumidores de estos datos suelen hacer un seguimiento del comportamiento durante el último mes para comprender la exposición al riesgo en un día determinado.

Calidad de la información sobre riesgos: Aunque el servidor Couchbase no es una herramienta de evaluación de la calidad de los datos, su esquema flexible facilita la corrección de errores detectados por herramientas de calidad de datos y procesos de control de calidad que, de otro modo, estarían limitados por la rigidez del esquema. Por ejemplo, si te olvidaste de incluir una columna o algo se rompe debido a un cambio en el tipo de datos, puedes volver a ponerlo en marcha muy rápidamente con una solución como Couchbase.

Disponibilidad de informes sobre riesgos: El servidor Couchbase se centra en la memoria y cuenta con funciones de disponibilidad integradas que garantizan que los datos estén siempre disponibles.

Cuadros de mando: El requisito para los cuadros de mando es que tienen que estar disponibles 24/7/365 para seguir al sol, soportar una amplia variedad de herramientas de información, proporcionar una visión consistente y fiable del estado de las cosas. Aunque tener un cuadro de mando robusto y altamente disponible no resuelve los problemas de calidad de los datos, tener algo disponible 24/7 y resistente a los cambios ayudará a detectar cualquier fuga de tuberías para que sea visible y se corrija rápidamente. Disponer de los cuadros de mando desde una única plataforma también es muy útil.

El servidor Couchbase es muy versátil y tiene una gran variedad de usos en la empresa. Consulta mi artículo anterior sobre la identificación de aplicaciones adecuadas para bases de datos NoSQL. https://www.couchbase.com/blog/immediate-or-eventual-persistence/

Para una mejor comprensión de la arquitectura de Couchbase Server consulte el siguiente enlace http://www.couchbase.com/nosql-databases/couchbase-serve/r

_____________________________________________________________________________________

Este artículo ha sido escrito por Sandhya Krishnamurthy, Ingeniera Superior de Soluciones de Couchbaseproveedor líder de bases de datos NoSQL.

Póngase en contacto con el autor en sandhya.krishnamurthy@couchbase.com

Visite los siguientes sitios para obtener más información sobre los productos Couchbase, descargas gratuitas de productos y formación gratuita

www.couchbase.com

http://www.couchbase.com/nosql-databases/downloads/

http://training.couchbase.com/online

Comparte este artículo
Recibe actualizaciones del blog de Couchbase en tu bandeja de entrada
Este campo es obligatorio.

Autor

Publicado por Sandhya Krishnamurthy, Ingeniera Superior de Soluciones, Couchbase

Sandhya Krishnamurthy es una tecnóloga con una sólida formación en desarrollo de bases de datos y experiencia en preventa. Es artista a tiempo parcial, cantante a tiempo parcial y madre a tiempo completo.

Deja un comentario

¿Listo para empezar con Couchbase Capella?

Empezar a construir

Consulte nuestro portal para desarrolladores para explorar NoSQL, buscar recursos y empezar con tutoriales.

Utilizar Capella gratis

Ponte manos a la obra con Couchbase en unos pocos clics. Capella DBaaS es la forma más fácil y rápida de empezar.

Póngase en contacto

¿Quieres saber más sobre las ofertas de Couchbase? Permítanos ayudarle.