Start · Introduction

Introduction to the Large Financial Data Model

The Large Financial Data Model (LFDM) is a family of foundation models trained on regulated financial data. This documentation describes the concept, the Brikz platform architecture, the model lifecycle, and the specification of the agents that operate on the LFDM.

What is a Large Financial Data Model

The LFDM is a class of foundation model specialized for financial data — transactions, receivables, regulatory documents, cash-flow time series, ownership graphs, and recorded human decisions. Unlike language models that treat text as a generic sequence, the LFDM learns the native structure of each financial modality and the relationships between them.

The Brikz platform exposes the LFDM through agents — each agent combines a selection of encoders, tools, parameterized regulation and human handoff protocols to operate a specific regulatory cycle.

Modalities covered

• Document FM — structured multi-modal extraction from fund regulation, indentures, contracts and credit notes.
• Time-series FM — Mamba-2 backbone for aging, PD and cash-flow forecasting over long windows.
• Tabular FM — TabPFN-v2 fine-tuned for contextual scoring over originator, payor and counterparty tables.
• Graph FM — Production-grade GraphSAGE over directed transaction and ownership graphs.

Platform overview

The platform is structured into five core components, all running on Google Cloud in a dedicated São Paulo region:

Google Cloud stack

• Gemini (Vertex AI Model Garden) — Gemini Pro and Flash families via Model Garden, reasoning engine for the agents.
• Gemini Enterprise — enterprise tier of Gemini with data residency, IAM controls and audit logging, applied to regulated client workloads.
• Vertex AI — training, fine-tuning, MLOps and serving for foundation models and per-tenant LoRA adapters.
• TPU v5p / Trillium — accelerators for foundation model pretraining. Complementary support for NVIDIA A100/H100/H200.
• BigQuery — serverless lakehouse, pay-per-query, with native embeddings via BQML.
• BigQuery Graph — graph queries over transactional history and ownership chain inside the warehouse.
• Spanner Graph — operational representation of the originator/payor/UBO graph with strong consistency.
• Document AI — structured multi-modal extraction over fund regulation, indentures, contracts and minutes.
• Cloud Run · GKE — serverless inference and always-warm regional endpoints.
• Pub/Sub · Dataflow — real-time ingestion of payments, cards and settlement events.
• Cloud Storage — datalake in open Iceberg format, partitioned by LoadDate.
• Confidential Compute — cryptographic isolation of the execution environment per tenant.
• Dataplex · IAM — data catalog, lineage and granular access control.

Getting started

Typical adoption flow follows four steps:

1. Connect data sources — transactional, onboarding, documents, registries.
2. Curate the first datasets — temporal partitioning, validation, lineage.
3. Train the institution's adapter — LoRA over the base LFDM.
4. Serve the agent — dedicated endpoint, dashboard and API.

Mode A reaches a first exception queue running in production within four weeks of contract signing. Modes B and C have different timelines described below.

Mode A · Managed platform

Default delivery configuration. Brikz hosts the full infrastructure in a dedicated São Paulo region. The client consumes the product through a web dashboard and API. No model ops, no GPU ops, no pipeline ops.

Responsibilities

Time to production

Default configuration reaches the first exception queue running on the client's real data within four weeks of contract signing.

When to use

Fund managers, fiduciary administrators and custodians who need immediate operations without investing in an AI team.

Mode B · Embedded API

The client integrates the Brikz agent API inside its own digital product, without using the Brikz dashboard. Regulatory decision becomes a capability of the client's product, with optional white-label.

Responsibilities

Integration

REST API with OAuth 2.0 and optional mTLS. Webhooks for decision events. Python and TypeScript SDKs. Endpoint documentation in the API chapter of this guide.

When to use

Credit fintechs, BaaS, securitizers and originators with their own digital product that want to offer regulatory decisioning without operating the AI.

Mode C · Client tenant

Brikz deploys the full stack into the client's own Google Cloud project, via Terraform and Helm. Data, model and inference stay inside the client perimeter. Brikz maintains the model lifecycle via a shared, auditable runbook.

Responsibilities

Provisioned components

• Project, billing, networks and VPC Service Controls on the client's Google Cloud
• Vertex AI Pipelines, Vertex AI Endpoints, Cloud Run, GKE Autopilot
• BigQuery, BigQuery Graph, Spanner Graph, Cloud Storage
• Confidential Compute, Cloud KMS with CMEK
• Dataplex, Cloud IAM, Cloud Audit Logs, Cloud Monitoring

Time to production

Eight to twelve weeks, including infrastructure provisioning, corporate SSO integration, network configuration and security validation by the client team.

When to use

Mid-size and digital banks, large fund managers and institutions with internal requirements for a dedicated tenant of their own, customer-managed encryption keys and mandatory internal audit.

Intellectual property

In every delivery mode, the IP split is identical:

• LFDM foundation models (Document FM, Time-series FM, Tabular FM, Graph FM) remain the intellectual property of Brikz Tecnologia Ltda.
• The LoRA adapter trained on the institution's data is the client's own IP. It remains cryptographically isolated and is exportable on request at any time.
• The raw data of the client is the client's IP. In no delivery mode is one client's data ever used to fine-tune another client's model.

Structured Credit Agent

The brikz/agent-fidc agent operates the cycle prescribed by CVM 175 for credit fund operations. Every decision ships with an auditable dossier — rationale, applied regulation snapshot, and model version.

Stages operated

Endpoint

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

8 operational layers of the Structured Credit Agent

The Structured Credit Agent runs the CVM 175 cycle across eight connected layers. Each layer has a declared responsibility, a dedicated foundation model, an associated Google Cloud product and an intermediate output consumable by the layers above. The audit trail is built layer by layer — every decision in layer L8 carries traceability down to the raw evidence in layer L1.

Traceability guarantee

Every decision at layer L8 includes:

• Agent execution ID and UTC timestamp
• Foundation model version in use per layer
• Client LoRA adapter version
• Applied regulation snapshot, including exact clauses
• Pointers to the raw evidence consumed (PDF document, registry entry, CNAB record)

AML Agent

The brikz/agent-aml agent operates the AML cycle prescribed by CVM 50. Operational focus is prioritization under an inspection budget — concentrating illicit activity at the top of the risk ranking.

Two-phase pipeline

• Phase 1 — Transaction ranking: directed graph construction, GraphSAGE encoding, MLP decoder producing per-edge probability.
• Phase 2 — Investigable cases: top-k% extraction, subgraph induction, decomposition into connected components (n_min = 3), contextual subgraph for the exception queue.

Operational metrics

Customer Life Agent

The brikz/agent-life agent builds a continuous representation of each retail and business client from transactions, contracts, ownership links and cash-flow series. It produces a dense per-client vector consumable by credit, scoring, fraud and recommendation use cases. Vector dimensionality is a configuration parameter per institution.

customer_embedding = LFDM.encode(
  transactions = stream("payments", "cards"),
  documents    = ["payroll.pdf", "contracts/"],
  graph        = relationship_graph(entity_id),
  timeseries   = cashflow_history(36_months),
  context      = open_finance_consent()
)

The embedding is updated in streaming and exposed via a dedicated endpoint. Common use cases: dynamic primacy, Next Best Action, early financial stress.

Connectors

The platform ships native connectors for common data sources in the Brazilian market:

• Receivables registries — CERC, B3, TAG, CIP.
• Real-time payments, wire transfers, bills, cards — via ERP, core banking or aggregator.
• Open Finance — via authorized initiator API.
• Documents — indentures, fund regulation, contracts, credit notes, receipts.
• Onboarding — Federal Revenue, Central Bank, OFAC, sanctions and PEP.

Datasets

Datasets are versioned in Iceberg or Delta format, partitioned by load date, with auditable lineage. Each dataset carries a declared schema, observed quality and the regulation snapshot associated with it when applicable.

Ingestion & quality

Ingestion supports batch and streaming. Quality checks include accounting reconciliation, duplicate detection, mandatory-field completeness and referential consistency. Quality events feed the governance dashboard and can automatically block use for training or inference.

Training

Foundation model training combines self-supervised pretraining on large volumes of unlabeled data and supervised post-training on specific tasks. Execution runs on Vertex AI, with TPU v5p and Trillium pools for pretraining and NVIDIA A100/H100/H200 for fine-tuning and specific tasks.

Observed configurations

Per-client adaptation

Each institution receives a dedicated adapter trained via LoRA, QLoRA or DoRA on top of the base LFDM. The adapter captures the particularities of the data and institutional policy without exposing training data to other tenants. Versioning, registration and environment promotion via Vertex AI Model Registry, with lineage integrated to Dataplex.

Benchmark

The platform maintains an internal benchmark for comparing architectures and checkpoints. Reported metrics include AUC-ROC, Average Precision, Recall@k, Lift@k and IPI@k for ranking tasks; AUC-ROC and KS for scoring tasks; coverage and purity for case extraction.

Inference

Inference is served on serverless pay-per-query endpoints, always warm, over Cloud Run, GKE and Vertex AI Endpoints. The runtime uses vLLM or SGLang for generative models, TensorRT-LLM for high-throughput cases, and custom containers for GraphSAGE and tabular models.

Observed performance

• Transaction ranking (AML): 740K edges/second on NVIDIA A100 80GB, measured on AMLSim 124M transactions.
• Other latency and throughput metrics per agent are reported in the internal benchmark and made available on technical request for each delivery mode.

API

REST API with OAuth 2.0 authentication and optional mTLS. All calls return a decision ID and a pointer to the corresponding auditable dossier.

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

Audit trail

Every platform decision is recorded with generated rationale, model version, adapter version, applied regulation snapshot, execution identifier and requester identity. Trail is exportable in a format compatible with internal and external audit.

Security & isolation

Data resides in the dedicated São Paulo region on Google Cloud. Confidential Compute isolates each tenant's execution environment cryptographically. Access controlled by Cloud IAM with per-operation auditing in Cloud Audit Logs. Encryption in transit and at rest by default, with optional CMEK.

Applicable regulation

• CVM 175 — credit fund operations, eligibility, collateral and monitoring duties.
• CVM 50 — anti-money laundering and counter-terrorism financing.
• BCB 119 — risk management and cybersecurity for financial institutions.
• LGPD — Brazilian general data protection law.
• COAF — atypical operations communication within 24h.

Glossary