Qué es
Una data-aggregation layer es la parte del stack que recolecta datos de cada custodio, broker y fuente de mercado que usa un gestor y los convierte en un formato consistente que el resto de los sistemas puede consumir. La aggregation layer de finnerve lo hace a través de 80+ feeds — normalizándolos a un solo schema, conciliándolos entre sí el mismo día, y conservando provenance completa en cada campo para que cualquier número pueda rastrearse hasta la fuente exacta de donde vino.
La diferencia es que la aggregation layer trata la provenance y la conciliación como el producto, no como el subproducto. Donde la mayoría de las capas de integración te entregan un archivo fusionado y cruzan los dedos, la aggregation layer lleva una jerarquía de override explícita — el custodio es la fuente de verdad para una posición, la fuente de precios es la fuente de verdad para un precio — y muestra su trabajo: qué feed fijó cada campo, cuándo, y qué sobrescribió. Como es la source layer de todo el stack de finnerve, la conciliación se hace una sola vez, upstream, en lugar de seis veces en seis sistemas que cada uno parsea al custodio de forma un poco distinta.
Para quién es
La aggregation layer corre en producción donde sea que los datos llegan de más fuentes de las que un solo sistema debería tener que parsear — desde un gestor conciliando cuatro custodios a mano hasta una plataforma que sirve a mil inversionistas finales desde una sola capa.
- Fund administrators — decenas de vehículos entre muchos custodios, colapsados en un solo registro normalizado de posiciones y transacciones.
- Gestores de activos y fondos multicustodio — libros repartidos entre 4+ custodios que no deberían conciliarse a mano cada mañana.
- Wealth managers — una capa de datos consistente detrás de cada herramienta de cara al cliente y de reporting.
- Family offices y multi-family offices — tenencias globales fragmentadas entre custodios y clases de activo, llevadas a un solo schema.
- Plataformas wealth-tech y equipos de BI — una superficie REST/GraphQL documentada sobre la cual construir, en lugar de parsers de custodios escritos a mano que se rompen con cada cambio de formato.
Qué cubre
La aggregation layer es dueña de la source layer: conectar los feeds, homogeneizarlos, conciliarlos, y exponer una sola superficie limpia.
- 80+ conectores de fuentes — feeds de custodia, broker, mercado y banca; feeds a medida agregados on demand y generalizados en la librería una vez que el patrón se repite.
- Normalización a un solo schema, con provenance — cada feed mapeado a un solo modelo, conservando la fuente, el feed y el timestamp en cada campo.
- Conciliación el mismo día con jerarquía de override — detección automática de quiebres entre feeds; el custodio gana la posición, la fuente de precios gana el precio, y la resolución queda registrada.
- Entrega REST + GraphQL — una superficie de API moderna para cada sistema downstream, con versionado de schema retrocompatible — sin breaking changes en una actualización.
- Observabilidad operacional — una vista en vivo de la salud de los feeds, latencia, quiebres y cumplimiento de SLA, con alertas que se disparan antes de que un sistema downstream lo note.
Cómo encaja en tu stack
La aggregation layer es la source layer upstream — lo primero que los datos golpean y el último lugar donde un formato de custodio se parsea. Los feeds entran desde custodios, brokers y proveedores de market data; la aggregation layer los normaliza a un solo schema, los concilia el mismo día conservando provenance en cada campo, y sirve esa única capa a todo lo que sigue. Adóptala por sí sola bajo un stack existente, o como el cimiento sobre el que se construye el resto de la capa operativa de finnerve.
Días para un feed que la librería conoce
La aggregation layer es infraestructura gestionada — tú consumes la capa, finnerve opera el pipeline que la mantiene limpia. No hay parser que mantener, ni job de conciliación que cuidar, ni turno de on-call por un custodio que cambió su formato de archivo de la noche a la mañana.
Las implementaciones las lideran operadores y las aceleran nuestros propios assets: conectores pre-construidos para los custodios regionales dominantes y las fuentes globales de market data, un motor de normalización que mapea un feed nuevo al schema compartido en lugar de escribir un parser desde cero, y agentes de detección de quiebres que resuelven las excepciones de conciliación rutinarias y escalan solo las que necesitan una persona. Esa es la división deliberada — la máquina concilia el flujo limpio y expone los quiebres genuinos; el equipo de operaciones de finnerve es dueño de la salud de los feeds y de los SLA; tu equipo consume un solo schema vía REST o GraphQL y construye features en lugar de pipelines. Un feed que la librería ya conoce puede estar en vivo en días; una fuente genuinamente nueva se agrega on demand y se generaliza en la librería una vez que el patrón se repite. Tráenos dos de tus custodios y levantamos una capa de muestra para que la puedas consultar.
Preguntas frecuentes
Ya tenemos integraciones a nuestros custodios. ¿Por qué agregar una capa?
Porque estás manteniendo esa integración seis veces, una por cada sistema que lee un custodio — y cada uno parsea el formato un poco distinto, que es donde los números dejan de coincidir. La aggregation layer hace el parsing, la normalización y la conciliación una sola vez, upstream, y sirve un solo schema a todo lo que sigue. Tu PMS, OMS y BI dejan de cargar cada uno su propia lógica de custodios, y el día que un custodio cambia su archivo, un solo equipo lo arregla una vez. Tráenos tus dos feeds más desordenados y te mostramos una única capa normalizada sobre ambos en una sesión de trabajo.
Nuestro custodio no está en tus 80+. ¿Y entonces?
Se agrega — ese es el caso normal, no la excepción. Un feed nuevo se mapea al schema compartido on demand, y una vez que el patrón se generaliza entra en la librería de conectores, de modo que el próximo gestor con ese custodio lo hereda. No estás pagando por construir un parser a medida que solo tú vas a usar.
"Provenance en cada campo" suena bien — ¿qué nos da realmente en una auditoría?
Significa que cualquier número en cualquier reporte downstream puede rastrearse hasta la fuente, el feed y el timestamp exactos de donde vino, y puedes mostrar qué sobrescribió y por qué. Cuando un examinador pregunta de dónde salió una posición o un precio, respondes desde el registro en lugar de reconstruirlo desde seis sistemas después del hecho. Esa es la diferencia entre un archivo fusionado en el que tienes que confiar y una capa conciliada que muestra su trabajo. Sacamos la provenance completa de un campo frente a tu líder de compliance en una demo.
¿Un cambio de schema no romperá los sistemas que construimos encima?
No — el versionado de schema es retrocompatible por diseño, así que una actualización agrega sin quitar y los consumidores existentes siguen funcionando sin tocarse. Esa es una regla dura, no un mejor esfuerzo: los sistemas downstream no se rompen en un release de la aggregation layer. Por eso las plataformas construyen investor apps y BI directamente sobre la superficie GraphQL con tranquilidad.
¿Quién opera esto — corremos nosotros el pipeline?
No lo corres tú. La aggregation layer es infraestructura gestionada: finnerve opera las conexiones de feeds, la conciliación y los SLA, y tu equipo consume una sola capa limpia vía REST o GraphQL. Los agentes de detección de quiebres resuelven las excepciones de conciliación rutinarias automáticamente y escalan solo los quiebres genuinos a nuestro equipo de operaciones — así nadie de tu lado está de on-call por un custodio que cambió su formato a las 2am. Te mostramos el dashboard de observabilidad y el modelo de SLA en una sesión de trabajo.
¿Cómo sabríamos que un feed está atrasado o roto antes que nuestros clientes?
Para eso es exactamente la capa de observabilidad: rastrea la salud de los feeds, la latencia, los quiebres y el cumplimiento de SLA en vivo, y alerta antes de que un sistema downstream — o un inversionista — note algo. Un archivo de custodio faltante aparece como una alerta con el quiebre adjunto, no como un número equivocado en un reporte a cliente. Te enteras primero, y te enteras con el contexto para actuar. Tráenos un feed real y te mostramos la vista de salud y el alerting en una demo.