Pular para o conteúdo
Solução · Dados

Oitenta feeds entram, um esquema sai —
e cada campo lembra de onde veio.

80+ feeds de custodiantes, corretoras e mercado entram. Um esquema normalizado sai — para o seu PMS, o seu OMS e o seu reporte. Cada campo guarda a fonte e o horário. Cada feed concilia no mesmo dia. Os seus sistemas param de se importar de onde o dado veio.

Feeds conectados
80+
Instituições
30+
Atraso de conciliação
T+0
Mercados
7
— Conectados hoje

Já normalizando feeds de 30+ instituições

Custodiantes, corretoras e provedores de dados de mercado no Chile, no México, no Peru e nos mercados globais — cada um mapeado para o mesmo esquema, conciliado no mesmo dia.

O que é

Uma camada de agregação de dados é a parte do stack que recolhe dados de cada custodiante, corretora e fonte de mercado que uma gestora usa e os transforma em um formato consistente que o resto dos sistemas consegue consumir. A camada de agregação da finnerve faz isso sobre 80+ feeds — normalizando para um esquema único, conciliando uns contra os outros no mesmo dia e guardando proveniência completa em cada campo, para que qualquer número possa ser rastreado até a fonte exata de onde veio.

A diferença é que aqui proveniência e conciliação são o produto, não o subproduto. Onde a maioria das camadas de integração te entrega um arquivo mesclado e torce, esta camada carrega uma hierarquia explícita de prevalência — o custodiante é a fonte da verdade para posição, a fonte de preço é a fonte da verdade para preço — e mostra o trabalho: qual feed preencheu cada campo, quando e o que sobrescreveu. Como ela é a camada de origem de todo o stack da finnerve, a conciliação é feita uma vez, lá em cima, em vez de seis vezes em seis sistemas que leem o custodiante cada um de um jeito.

Para quem é

A camada de agregação roda em produção onde chegam dados de mais fontes do que qualquer sistema sozinho deveria ter de ler — da gestora que concilia quatro custodiantes na mão à plataforma que atende mil investidores finais em cima de uma camada só.

  • Administradores fiduciários — dezenas de veículos em vários custodiantes, colapsados em um registro normalizado de posições e transações.
  • Asset managers e fundos multicustodiante — livros espalhados por 4+ custodiantes que não deveriam ser conciliados na mão toda manhã.
  • Wealth managers — uma camada de dados consistente por trás de cada ferramenta de cliente e de reporte.
  • Family offices e multi-family offices — posições globais fragmentadas entre custodiantes e classes de ativo trazidas para um esquema único.
  • Plataformas de wealth-tech e times de BI — uma superfície REST/GraphQL documentada para construir em cima, em vez de parsers de custodiante escritos à mão que quebram a cada mudança de formato.

O que cobre

A camada de agregação é dona da camada de origem: conectar os feeds, homogeneizar, conciliar e expor uma superfície limpa.

  • 80+ conectores de fonte — feeds de custódia, corretoras, mercado e bancos; feeds sob medida adicionados sob demanda e generalizados para a biblioteca assim que o padrão se repete.
  • Normalização em um esquema, com proveniência — cada feed mapeado para um modelo único, guardando a fonte, o feed e o horário em cada campo.
  • Conciliação no mesmo dia, com hierarquia de prevalência — detecção automática de quebras entre feeds; o custodiante ganha em posição, a fonte de preço ganha em preço, e a resolução fica registrada.
  • Entrega em REST + GraphQL — uma superfície de API moderna para todo sistema a jusante, com versionamento de esquema retrocompatível — nenhuma mudança quebra nada em um upgrade.
  • Observabilidade operacional — visão ao vivo da saúde dos feeds, latência, quebras e aderência ao SLA, com alertas que disparam antes de um sistema a jusante perceber.

Como encaixa no seu stack

A camada de agregação é a camada de origem — a primeira coisa que o dado encontra e o último lugar em que um formato de custodiante é lido. Os feeds entram de custodiantes, corretoras e provedores de dados de mercado; a camada normaliza para um esquema, concilia no mesmo dia com proveniência preservada em cada campo, e serve essa camada única para tudo o que vem depois. Adote sozinha, embaixo de um stack existente, ou como a fundação sobre a qual o resto da camada operacional da finnerve é construído.

FONTES · 80+ FEEDS CAMADA DE ORIGEM CONSUMIDORES observabilidade saúde dos feeds · quebras · SLA feeds de custodiantes feeds de corretoras feeds de dados de mercado CAMADA DE ORIGEM agregação normalizar · conciliar · servir PMS OMS reporte e BI AML / KYC

Dias até um feed que a biblioteca já conhece

A camada de agregação é infraestrutura gerenciada — você consome a camada, a finnerve opera o pipeline que a mantém limpa. Não há parser para manter, não há job de conciliação para vigiar, e não há escala de plantão por causa de um custodiante que mudou o formato do arquivo de madrugada.

As implantações são conduzidas por operadores e aceleradas por ativos nossos: conectores prontos para os custodiantes dominantes da região e para as fontes globais de dados de mercado, um motor de normalização que mapeia um feed novo para o esquema compartilhado em vez de escrever um parser do zero, e agentes de detecção de quebras que limpam as exceções rotineiras de conciliação e escalam só as que precisam de uma pessoa. Essa é a divisão de propósito — a máquina concilia o fluxo limpo e traz à tona as quebras de verdade; o time de operações da finnerve responde pela saúde dos feeds e pelos SLAs; o seu time consome um esquema por REST ou GraphQL e constrói funcionalidade em vez de pipeline. Um feed que a biblioteca já conhece entra no ar em dias; uma fonte genuinamente nova é adicionada sob demanda e generalizada para a biblioteca assim que o padrão se repete. Traga dois dos seus custodiantes e montamos uma camada de amostra para você consultar.

Perguntas frequentes

Já temos integração com os nossos custodiantes. Por que somar uma camada?

Porque você mantém essa integração seis vezes, uma por sistema que lê um custodiante — e cada um lê o formato de um jeito ligeiramente diferente, que é exatamente onde os números param de bater. A camada de agregação faz a leitura, a normalização e a conciliação uma vez, lá em cima, e serve um esquema para tudo o que vem depois. O seu PMS, o seu OMS e o seu BI param de carregar cada um a sua lógica de custodiante, e no dia em que um custodiante mudar o arquivo, um time corrige uma vez. Traga os seus dois feeds mais bagunçados e mostramos uma camada normalizada única sobre os dois em uma sessão de trabalho.

O nosso custodiante não está entre os 80+. E aí?

Ele entra — esse é o caso normal, não a exceção. Um feed novo é mapeado para o esquema compartilhado sob demanda e, depois que o padrão é generalizado, vai para a biblioteca de conectores, de forma que a próxima gestora naquele custodiante já herda pronto. Você não paga para construir um parser sob medida que só você vai usar.

"Proveniência em cada campo" soa bonito — o que isso compra numa auditoria?

Significa que qualquer número em qualquer relatório a jusante pode ser rastreado até a fonte, o feed e o horário exatos de onde veio, e que você consegue mostrar o que ele sobrescreveu e por quê. Quando o examinador perguntar de onde saiu uma posição ou um preço, você responde pelo registro em vez de reconstruir a história em seis sistemas depois do fato. É a diferença entre um arquivo mesclado no qual você tem de confiar e uma camada conciliada que mostra o trabalho. Puxamos a proveniência completa de um campo na frente do seu líder de compliance em uma demo.

Uma mudança de esquema não vai quebrar os sistemas que construímos em cima?

Não — o versionamento de esquema é retrocompatível por desenho, então um upgrade adiciona sem remover e os consumidores existentes seguem funcionando sem tocar em nada. É regra dura, não esforço de melhor tentativa: sistemas a jusante não quebram em release da camada de agregação. É por isso que plataformas ficam confortáveis construindo apps de investidor e BI direto sobre a superfície GraphQL.

Quem opera isso — o pipeline é nosso?

Não é. A camada de agregação é infraestrutura gerenciada: a finnerve opera as conexões de feed, a conciliação e os SLAs, e o seu time consome uma camada limpa por REST ou GraphQL. Os agentes de detecção de quebras limpam as exceções rotineiras de conciliação automaticamente e escalam só as quebras de verdade para o nosso time de operações — então ninguém do seu lado fica de plantão por um custodiante que mudou de formato às 2 da manhã. Mostramos o dashboard de observabilidade e o modelo de SLA em uma sessão de trabalho.

Como saberíamos que um feed atrasou ou quebrou antes dos nossos clientes?

É exatamente para isso que existe a camada de observabilidade: ela acompanha ao vivo a saúde dos feeds, a latência, as quebras e a aderência ao SLA, e alerta antes de um sistema a jusante — ou um investidor — notar qualquer coisa. Um arquivo de custodiante que não chegou vira alerta com a quebra anexada, e não um número errado no relatório do cliente. Você fica sabendo primeiro, e fica sabendo com o contexto para agir. Traga um feed real e mostramos a visão de saúde e o alerta em uma demo.

Uma camada embaixo de tudo — consulte você mesmo.

Sessão de trabalho de 30 minutos. Traga dois dos seus custodiantes e montamos uma camada normalizada de amostra sobre os dois — você consulta e vê a proveniência em cada campo.