Bastidores e cliente 360

O caminho começa no produto. No BIAN 14, o Position Keeping, de padrão Track, mantém o log das transações postadas em cada produto. A própria ficha diz que transações financeiras reconciliadas são usadas depois para postagem nos sistemas contábeis. Essa frase é pequena, mas muda o desenho.

Posição de produto não é contabilidade, é o registro operacional daquele produto. Financial Accounting, também com padrão Track, recebe fatos financeiros e cria instruções contábeis que atualizam razão geral e razões auxiliares. Account Reconciliation, com padrão Process, concilia. Bank Portfolio Administration consolida e apresenta informação para o book of business do banco. Regulatory Reporting, com padrão Administer, cuida das obrigações de reporte regulatório.

A confusão mais cara que vejo em desenhos bancários é tratar posição do produto como contabilidade. Se o mesmo sistema faz os dois papéis, mudar o plano de contas vira mudar o sistema de conta. O problema não aparece no primeiro release. Ele aparece quando auditoria, regulador, conciliação e produto querem ritmos diferentes de mudança.

Corporate Treasury, com padrão Manage, existe para garantir liquidez do banco, gerir atividades táticas de funding e determinar e publicar taxas de juros e câmbio do banco. Asset And Liability Management, com padrão Direct, define políticas de ativos e passivos. Gap Analysis trabalha com fluxos de caixa projetados para risco de moeda e juros. Liquidity Risk Models cobre modelos de risco de liquidez, incluindo gap de liquidez e Liquidity at Risk.

Aqui o número importa. No Brasil, a Resolução 4.401/2015 está vigente para LCR. O LCR é o estoque de ativos de alta liquidez, HQLA, dividido pelas saídas líquidas de caixa previstas para 30 dias. Ele se aplica a bancos múltiplos, comerciais, de investimento, de câmbio e caixas econômicas com ativo total acima de R$ 100 bilhões, ou integrantes de conglomerado prudencial acima disso. A metodologia está na Circular 3.749/2015. A origem é Basileia III, BCBS, 2013, com mínimo de 100% a partir de 1º de janeiro de 2019.

O erro operacional é calcular indicador de liquidez em vários lugares com regras diferentes. Quando a crise chega, ninguém discute arquitetura conceitual. Discute qual número vale.

Imagine a Marina, fictícia, ligando para a central por causa de uma tarifa. Contact Handler recebe a interação. Party Authentication autentica. Party Routing Profile monitora um pequeno perfil de indicadores chave, com status como conta em atraso e alertas como possível fraude. Session Dialogue conduz a conversa. Customer Position mostra a posição financeira consolidada da cliente, combinando detalhes de produtos e serviços em uso. Customer Event History mostra o que aconteceu. Servicing Order executa o estorno da tarifa.

Há dois jeitos de construir a tela. O primeiro é copiar tudo para um banco com tudo e dono de nada. Ele nasce útil e fica desatualizado no dia seguinte. O segundo é compor. Customer Position, Customer Event History e Party Routing Profile continuam donos das suas leituras. A tela junta o que precisa para aquele atendimento, e a escrita acontece por pedido, como Servicing Order.

LGPD não é rodapé jurídico aqui. A Lei 13.709/2018 exige finalidade e necessidade no art. 6º, I e III, direitos do titular no art. 18, e registro das operações de tratamento no art. 37. Cada leitura de dado pessoal precisa carregar a finalidade. Esse detalhe separa cliente 360 de cópia indiscriminada.