Início · Introdução

Introdução ao Large Financial Data Model

O Large Financial Data Model (LFDM) é uma família de modelos fundacionais treinados sobre dados financeiros regulados. A documentação a seguir descreve o conceito, a arquitetura da plataforma Brikz, o ciclo de vida dos modelos e a especificação dos agentes que operam o LFDM.

O que é um Large Financial Data Model

O LFDM é uma classe de modelo fundacional especializado em dados financeiros — transações, recebíveis, documentos regulatórios, séries temporais de fluxo de caixa, vínculos societários e decisões humanas registradas. Diferente de modelos de linguagem, que tratam texto como uma sequência genérica, o LFDM aprende a estrutura nativa de cada modalidade financeira e a relação entre elas.

A plataforma Brikz expõe o LFDM através de agentes — cada agente combina uma seleção de encoders, ferramentas, regulamento parametrizado e protocolos de handoff humano para operar um ciclo regulatório específico.

Modalidades cobertas

• Document FM — extração estruturada multi-modal de regulamento de fundo, escritura, contrato e CCB.
• Time-series FM — backbone Mamba-2 para forecast de aging, PD e fluxo de caixa em janelas longas.
• Tabular FM — TabPFN-v2 fine-tuned para scoring contextual sobre cedente, sacado e contraparte.
• Graph FM — GraphSAGE produtivo sobre grafo direcionado de transações e cadeia societária.

Visão geral da plataforma

A plataforma é estruturada em cinco componentes principais, todos rodando sobre Google Cloud em região São Paulo dedicada:

Stack Google Cloud

• Gemini (Vertex AI Model Garden) — família Gemini Pro e Flash via Model Garden, motor de raciocínio dos agentes.
• Gemini Enterprise — tier corporativo do Gemini com data residency, controles IAM e auditoria, aplicável a agentes em workloads de cliente regulado.
• Vertex AI — treino, fine-tuning, MLOps e serving de foundation models e adapters LoRA por tenant.
• TPU v5p / Trillium — aceleradores para pré-treino dos foundation models. Suporte complementar a NVIDIA A100/H100/H200.
• BigQuery — warehouse serverless, pay-per-query, com embeddings nativos via BQML.
• BigQuery Graph — queries de grafo sobre o histórico transacional e a cadeia societária no próprio warehouse.
• Spanner Graph — representação operacional do grafo de cedente, sacado, UBO e partes relacionadas com consistência forte.
• Document AI — extração estruturada multi-modal sobre regulamento, escritura, contrato, CCB e ata.
• Cloud Run · GKE — inferência serverless e endpoints regionais sempre quentes.
• Pub/Sub · Dataflow — ingestão em tempo real de Pix, TED, cartões e eventos de liquidação.
• Cloud Storage — datalake em formato aberto Iceberg, particionado por LoadDate.
• Confidential Compute — isolamento criptográfico do ambiente de execução por tenant.
• Dataplex · IAM — catálogo de dado, lineage e controle de acesso granular.

Primeiros passos

O fluxo típico de adoção segue quatro etapas:

1. Conectar fontes de dado — transacional, cadastral, documental, registradoras.
2. Curar os primeiros datasets — particionamento temporal, validação e linhagem.
3. Treinar o adapter da instituição — LoRA sobre o LFDM base.
4. Servir o agente — endpoint dedicado, dashboard e API.

O Modo A leva quatro semanas em configuração padrão para a primeira fila de exceções rodar em produção. Modos B e C têm prazos distintos descritos abaixo.

Modo A · Plataforma gerenciada

Configuração padrão de entrega. A Brikz hospeda toda a infraestrutura em região São Paulo dedicada. O cliente acessa o produto por dashboard web e API. Não opera modelo, não opera GPU, não opera pipeline de dado.

Responsabilidades

Time-to-produção

Configuração padrão atinge a primeira fila de exceções rodando sobre dado real do cliente em quatro semanas após o contrato.

Quando usar

Gestoras, administradores fiduciários e custodiantes que precisam de operação imediata sem investir em time de IA.

Modo B · API embarcada

O cliente integra a API dos agentes Brikz dentro do próprio produto digital, sem usar o dashboard Brikz. A decisão regulatória vira capacidade do produto do cliente, com white-label opcional.

Responsabilidades

Integração

REST API com OAuth 2.0 + mTLS opcional. Webhooks para eventos de decisão. SDK Python e TypeScript. Documentação de cada endpoint no capítulo API deste guia.

Quando usar

Fintechs de crédito, BaaS, securitizadoras e originadoras com produto digital próprio que querem oferecer decisão regulatória sem operar a IA.

Modo C · Tenant do cliente

A Brikz deploya a stack completa no projeto Google Cloud do próprio cliente, via Terraform e Helm. Dado, modelo e inferência permanecem dentro do perímetro do cliente. A Brikz mantém o ciclo de vida dos modelos via runbook auditável compartilhado.

Responsabilidades

Componentes provisionados

• Project, billing, redes e VPC Service Controls no Google Cloud do cliente
• Vertex AI Pipelines, Vertex AI Endpoints, Cloud Run, GKE Autopilot
• BigQuery, BigQuery Graph, Spanner Graph, Cloud Storage
• Confidential Compute, Cloud KMS com CMEK
• Dataplex, Cloud IAM, Cloud Audit Logs, Cloud Monitoring

Time-to-produção

Oito a doze semanas, incluindo provisionamento de infraestrutura, integração com SSO corporativo, configuração de rede e validação de segurança pelo time do cliente.

Quando usar

Bancos médios e digitais, grandes gestoras e instituições com exigência interna de tenant dedicado próprio, controle de chave criptográfica e auditoria interna obrigatória.

Propriedade intelectual

Em qualquer modo de entrega, a divisão de IP é a mesma:

• Os foundation models do LFDM (Document FM, Time-series FM, Tabular FM, Graph FM) permanecem como propriedade intelectual da Brikz Tecnologia Ltda.
• O adapter LoRA treinado sobre o dado da instituição é IP do próprio cliente. Permanece criptograficamente isolado e é exportável a qualquer momento sob solicitação do cliente.
• O dado bruto do cliente é IP do cliente. Em nenhum modo, dado de um cliente é usado para fine-tuning de outro cliente.

Agente FIDC

O agente brikz/agent-fidc opera o ciclo previsto pela CVM 175 para fundos de investimento em direitos creditórios. Cada decisão acompanha dossiê auditável com rationale, snapshot do regulamento aplicado e versão de modelo.

Etapas operadas

Endpoint

POST /v1/agents/fidc/decide
{
  "fund_id": "FIDC-2025-0042",
  "receivable_batch": "s3://...",
  "event": "assignment"
}

8 camadas operacionais do Agente FIDC

O Agente FIDC executa o ciclo CVM 175 em oito camadas conectadas. Cada camada tem responsabilidade declarada, modelo fundacional dedicado, produto Google Cloud associado e saída intermediária consumível pelas camadas seguintes. A trilha auditável é construída camada por camada — toda decisão da camada L8 carrega rastreabilidade até a evidência bruta na camada L1.

Garantia de rastreabilidade

Toda decisão da camada L8 inclui:

• ID da execução do agente e timestamp UTC
• Versão do foundation model em uso por camada
• Versão do adapter LoRA do cliente
• Snapshot do regulamento aplicado, incluindo cláusulas exatas
• Ponteiros para a evidência bruta consumida (documento PDF, registro CERC, entrada CNAB)

Agente PLD/FT

O agente brikz/agent-pld opera o ciclo previsto pela CVM 50 para prevenção à lavagem de dinheiro e financiamento ao terrorismo. O foco operacional é priorização sob orçamento de inspeção — concentrar ilícito nas posições de maior risco do ranking.

Pipeline em duas fases

• Fase 1 — Ranking transacional: construção de grafo direcionado, encoding por GraphSAGE, decodificação por MLP em probabilidade por aresta.
• Fase 2 — Casos investigáveis: extração do top-k%, indução de subgrafo, decomposição em componentes conectadas (n_min = 3), subgrafo contextual para a fila de exceções.

Métricas operacionais

Agente Vida Financeira

O agente brikz/agent-life constrói representação contínua de cada cliente PF/PJ a partir de transações, contratos, vínculos e séries de fluxo de caixa. Produz um vetor denso por cliente, consumível por casos de uso de crédito, scoring, fraude e recomendação. A dimensão do vetor é parâmetro de configuração por instituição.

customer_embedding = LFDM.encode(
  transactions = stream("pix", "ted", "card"),
  documents    = ["payroll.pdf", "contracts/"],
  graph        = relationship_graph(cpf),
  timeseries   = cashflow_history(36_months),
  context      = open_finance_consent()
)

O embedding é atualizado em streaming e exposto via endpoint dedicado. Casos de uso comuns: principalidade dinâmica, Next Best Action, stress financeiro precoce.

Conectores

A plataforma oferece conectores nativos para as fontes de dado mais comuns no mercado brasileiro:

• Registradoras de recebíveis — CERC, B3, TAG, CIP.
• Pix, TED, boleto e cartões — via ERP, core bancário ou agregador.
• Open Finance — via API de iniciador autorizado.
• Documentos — escritura, regulamento, contratos, CCB, comprovantes.
• Cadastrais — Receita Federal, Bacen, OFAC, sanções e PEP.

Datasets

Datasets são versionados em formato Iceberg ou Delta, com particionamento por data de carga e linhagem auditável. Cada dataset carrega esquema declarado, qualidade observada e snapshot de regulamento associado quando aplicável.

Ingestão e qualidade

A ingestão suporta batch e streaming. Validações de qualidade incluem reconciliação contábil, detecção de duplicidade, completude de campos obrigatórios e consistência referencial. Eventos de qualidade alimentam o painel de governança e podem disparar bloqueio automático de uso para treino ou inferência.

Treinamento

O treinamento dos modelos fundacionais combina pré-treino self-supervised sobre grandes volumes de dado não rotulado e pós-treino supervisionado sobre tarefas específicas. A execução acontece no Vertex AI, com pools de TPU v5p e Trillium para pré-treino e NVIDIA A100/H100/H200 para tarefas específicas e fine-tuning.

Configuração observada

Adaptação por cliente

Cada instituição recebe um adapter dedicado treinado por LoRA, QLoRA ou DoRA sobre o LFDM base. O adapter captura particularidades do dado e da política da instituição sem expor o dado de treino a outros tenants. Versionamento, registro e promoção entre ambientes pelo Model Registry do Vertex AI, com lineage integrado ao Dataplex.

Benchmark

A plataforma mantém um benchmark interno para comparar arquiteturas e checkpoints. Métricas reportadas incluem AUC-ROC, Average Precision, Recall@k, Lift@k e IPI@k para tarefas de priorização; AUC-ROC e KS para tarefas de scoring; e métricas de cobertura e pureza para tarefas de extração de caso.

Inferência

Inferência é servida em endpoints serverless pay-per-query, sempre quentes, sobre Cloud Run, GKE e Vertex AI Endpoints. O runtime usa vLLM ou SGLang para modelos generativos, TensorRT-LLM para casos de alta vazão, e containers customizados para GraphSAGE e modelos tabulares.

Performance observada

• Ranking transacional (PLD): 740K edges/segundo em NVIDIA A100 80GB, medido sobre AMLSim 124M transações.
• Demais métricas de latência e vazão por agente são reportadas no benchmark interno e disponibilizadas mediante solicitação técnica para cada modo de entrega.

API

A API segue padrão REST com autenticação OAuth 2.0 e mTLS opcional. Todas as chamadas retornam o ID da decisão e o ponteiro para o dossiê auditável correspondente.

curl -X POST https://api.brikz.io/v1/agents/fidc/decide \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"fund_id":"FIDC-2025-0042","event":"assignment"}'

Trilha auditável

Cada decisão da plataforma é registrada com rationale gerado, versão de modelo, versão de adapter, snapshot do regulamento aplicado, identificador da execução e identidade do solicitante. Trilha exportável em formato compatível com auditoria interna e externa.

Segurança e isolamento

Dados ficam em região São Paulo dedicada no Google Cloud. Confidential Compute isola o ambiente de execução de cada tenant criptograficamente. Acesso controlado por Cloud IAM granular com auditoria de cada operação no Cloud Audit Logs. Criptografia em trânsito e em repouso por padrão, com CMEK opcional.

Regulação aplicável

• CVM 175 — operação de FIDCs, obrigações de elegibilidade, lastro e monitoramento.
• CVM 50 — prevenção à lavagem de dinheiro e financiamento ao terrorismo.
• BCB 119 — gestão de risco e cibersegurança para instituições financeiras.
• LGPD — proteção de dados pessoais.
• COAF — comunicação de operações atípicas em até 24h.

Glossário