O nascimento do BCBS 239
Este blog examina os princípios do BCBS 239 estritamente pela perspectiva da tecnologia e como o NoSQL é relevante no mundo da conformidade no setor financeiro.
Mas antes de nos aprofundarmos nesse assunto, aqui está um histórico da conformidade regulatória e por que ela se tornou tão importante.
Qualquer pessoa que tenha vivido a crise financeira de 2007/2008 e visto seus portfólios de 401k chegarem ao fundo do poço e suas casas serem avaliadas pelo preço de um saco de pipoca já sabe do que estou falando e conhece a história por trás das regras de conformidade regulatória às quais os bancos têm de aderir e o escrutínio a que estão sendo continuamente submetidos. Acredita-se que a crise financeira de 2007/2008 ocorreu porque os bancos não foram capazes de relatar os riscos de forma eficaz, causando um grande colapso que levou à crise. O BCBS 239 é um conjunto de princípios estabelecidos pelas agências governamentais para fortalecer as práticas de agregação e divulgação de riscos dos bancos.
As autoridades acreditavam que
- A incapacidade da infraestrutura de TI e da arquitetura de dados de dar suporte ao gerenciamento e à governança de riscos levou à crise. Muitos bancos não conseguiram gerenciar os riscos devido à baixa agregação de riscos, o que limitou severamente sua capacidade de relatar com precisão e em tempo hábil as informações sobre a exposição ao risco
- Que, ao melhorar as capacidades de tomada de decisão por meio do aprimoramento do gerenciamento de informações entre entidades jurídicas, a crise pode ser evitada. Isso inclui a capacidade de Melhorar a velocidade com que as informações estão disponíveis
- Esses princípios complementariam outros esforços para melhorar a eficácia do gerenciamento de riscos e avaliar a adequação do capital.
Este artigo não se aprofunda nos meandros dos princípios estabelecidos no BCBS 239; o objetivo é realmente focar em como a tecnologia desempenha um papel importante para que esse esforço seja bem-sucedido.
Então, por que os bancos não conseguem gerenciar com eficiência os relatórios de risco?
Se você observar a forma como qualquer empresa funciona hoje em dia, novas mesas de negociação surgem com frequência e os bancos estão sob enorme pressão para se adaptarem rapidamente a essas novas entidades jurídicas. Portanto, não há tempo para implementar esses sistemas da maneira correta, ou seja, ter um armazenamento de dados centralizado que tenha uma única versão da verdade, em que os aprimoramentos e/ou as alterações sejam bem deliberados antes de serem executados. Portanto, diante desse cenário, as unidades de negócios de suporte simplesmente criam armazenamentos de dados independentes, extraem os dados e criam seu próprio repositório para não atrapalhar as outras unidades de negócios.
Elas não podem simplesmente esperar que a infraestrutura de TI ideal esteja instalada antes de introduzir um novo produto ou unidade de negócios. E no mundo atual de fusões e aquisições, não há tempo para realmente integrar totalmente os sistemas. Portanto, os silos vieram para ficar. Qualquer esforço para integrar dados é um esforço plurianual e multimilionário, o que é uma missão impossível, para dizer de forma educada.
A perspectiva da TI
Quando você olha para esse problema do outro lado da cerca, ou seja, da perspectiva da TI, espera-se que ela se mova na velocidade dos negócios e produza resultados. A TI não recebe crédito pela criação de um belo sistema de engenharia que integre perfeitamente os dados e tenha painéis atualizados com as melhores e mais recentes informações. Não há tempo para aderir ao SDLC e à metodologia de desenvolvimento em cascata. AGILE é a nova maneira de desenvolver sistemas, pois eles têm os negócios em suas costas para ver rapidamente o valor de cada centavo gasto em projetos de TI.
A pressão sobre a TI é imensa e ela é a espinha dorsal dessa investida regulatória. A integração e a unificação de dados não é uma tarefa que se faz da noite para o dia e geralmente envolve meses/anos de planejamento, portanto, mesmo que haja orçamento disponível para isso, o sucesso de um projeto desse tipo é muito incerto.
Algumas verificações da realidade.....
Algumas coisas com as quais temos de lidar é o fato de que os silos de dados vieram para ficar e qualquer estratégia que usarmos terá de contornar isso. Felizmente, graças aos avanços tecnológicos e à forma como eles aproveitam o HW e o SW, há seções desse problema que podem ser resolvidas de forma fácil e eficaz
A arquitetura típica de qualquer empresa é semelhante a esta. Não estou representando as entidades ou os ônibus dentro de um banco; tudo o que quero representar, de forma muito vaga, é como os dados fluem entre os diferentes sistemas e como são transformados e consumidos. Cada caixa com vários bancos de dados representa dados pertencentes a uma unidade de negócios ou função dentro de uma empresa. Essa é uma visão muito simplista; na vida real, o fluxo de dados parece mais complicado do que uma teia de aranha intrincadamente tecida. Os consumidores dos dados representados no círculo externo podem selecionar qualquer fatia de dados de qualquer estágio do ciclo de vida da transformação de dados e criar seu próprio repositório para geração de relatórios. Portanto, dependendo do usuário a quem você pergunta, a mesma pergunta pode gerar respostas diferentes/conflitantes. E esse é realmente o ponto crucial da questão.
O ponto que estou tentando transmitir com essa imagem excessivamente simplificada é que
- Os dados estão espalhados por todos os lados e cada banco de dados tem sua própria estrutura exclusiva criada para oferecer o máximo de desempenho e flexibilidade aos seus usuários. Portanto, algo pode ir de arquivos brutos a 3NF, a modelos dimensionais (estrela e floco de neve) e voltar ao formato desnormalizado para facilitar o uso.
- Quando alguém inicia uma nova iniciativa. Ele prefere extrair os dados dos sistemas existentes e criar seu próprio repositório de dados para brincar, de modo a não prejudicar ninguém.
- Há várias cópias redundantes/descontroladas de dados que residem em diferentes áreas e cada cópia é uma versão diferente da cópia original, o que dificulta muito a comparação e a correção dos dados.
- A veracidade de qualquer relatório não pode ser verificada porque, dependendo de sua origem, as informações podem ser conflitantes.
A abordagem centrada no data mart permite que a TI se mova na velocidade dos negócios. Poderíamos ficar acordados a noite toda e apresentar milhões de razões para explicar por que tudo precisa ser integrado e como ter uma única cópia dos dados é a melhor maneira de fazer isso.
Alguns ganhos rápidos com o Couchbase
Conforme declarado na primeira seção, muitas mudanças precisam ocorrer para que os bancos possam avaliar a adequação do capital e mitigar os riscos.
Se eu fosse resumir rapidamente esse assunto, as duas principais coisas que me vêm à mente é que esse problema específico é principalmente
- Um problema de dados estruturados (Obrigado, Deus!), mas o esquema ainda precisa tolerar muitas alterações e reagir rapidamente.
- Problema de integração de dados pois ele precisa ser agregado e disponibilizado de forma rápida e altamente disponível
Algumas vantagens mais fáceis de serem aproveitadas para ajudar no processo geral de mitigação de riscos e sem fazer grandes mudanças disruptivas na captura de dados e nos aplicativos responsáveis por fornecer essas informações
Integração de dados: O servidor Couchbase pode ser usado como a plataforma de escolha para reunir os dados de diferentes silos em uma empresa e agregá-los rapidamente no servidor. Normalmente, a quantidade de dados que precisa ser agregada não está na faixa dos petabytes. A maioria está na faixa de GB e os consumidores desses dados costumam rastrear o comportamento do último mês para entender a exposição ao risco em um determinado dia.
Qualidade dos relatórios de risco: Embora o servidor Couchbase não seja uma ferramenta de avaliação da qualidade dos dados, seu esquema flexível facilita a correção de erros detectados por ferramentas de qualidade de dados e processos de controle de qualidade que, de outra forma, seriam limitados devido à rigidez do esquema. Por exemplo: se você se esqueceu de incluir uma coluna ou se algo está quebrando por causa de uma alteração no tipo de dados, é possível voltar a funcionar muito rapidamente com uma solução como o Couchbase
Disponibilidade de relatórios de risco: O servidor Couchbase é centrado na memória, com recursos de disponibilidade integrados que garantem que os dados estejam sempre disponíveis
Painéis: O requisito para os painéis de controle é que eles estejam disponíveis 24 horas por dia, 7 dias por semana, 365 dias por ano para acompanhar o sol, oferecer suporte a uma ampla variedade de ferramentas de relatórios e fornecer uma visão consistente e confiável da situação. Embora ter um sistema robusto e altamente disponível não resolva os problemas de qualidade dos dados, ter algo disponível 24 horas por dia, 7 dias por semana e resiliente a mudanças ajudará a detectar qualquer vazamento de tubulação para que seja visível e corrigido rapidamente. Ter os painéis de controle em uma única plataforma também é muito útil.
O servidor Couchbase é muito versátil e tem uma grande variedade de usos na empresa. Consulte meu artigo anterior sobre a identificação de aplicativos adequados aos bancos de dados NoSQL https://www.couchbase.com/blog/immediate-or-eventual-persistence/
Para entender melhor a arquitetura do Couchbase Server, consulte o seguinte link https://www.couchbase.com/nosql-databases/couchbase-serve/r
_____________________________________________________________________________________
Este artigo foi escrito por Sandhya Krishnamurthy, engenheira de soluções sênior da Couchbaseum dos principais fornecedores de bancos de dados NoSQL.
Entre em contato com o autor em sandhya.krishnamurthy@couchbase.com
- Fale conosco nos fóruns
- Siga-nos @couchbasedev e @couchbase
Visite os sites abaixo para saber mais sobre os produtos Couchbase, para fazer downloads gratuitos de produtos e treinamento gratuito
https://www.couchbase.com/nosql-databases/downloads/
https://training.couchbase.com/online
