Lecciones de construir una plataforma de trading para una empresa de energía: seguridad, tiempo real y backoffice

Participé, como Forward Deployed Engineer y junto a un equipo, en la construcción de una plataforma de inversiones y trading para una empresa del sector energía, incluyendo su backoffice de operaciones. Trabajar en un sistema donde cada operación tiene implicancias regulatorias, financieras y de auditoría me obligó a pensar distinto que en una app de gestión de pedidos. En este artículo cuento los aprendizajes de arquitectura y de proceso que me llevé. No incluye código ni información interna del cliente, pero sí los principios y decisiones que pueden servirle a otros equipos en una situación parecida.

Lo que exige una plataforma de inversiones: seguridad, auditoría y tiempo real

Cuando el proyecto involucra trading e inversiones, hay tres requisitos que aparecen desde el primer día y que no son negociables.

Seguridad. No me refiero solo a autenticación y autorización, aunque eso es la base. Se trata de diseñar asumiendo que cada componente puede ser un vector de exposición: quién puede ver qué posición, quién puede ejecutar qué operación, y cómo se segrega el acceso entre roles operativos y roles de supervisión. En una plataforma que maneja capital real, el principio de menor privilegio no es una buena práctica opcional: es un requisito de diseño desde la primera reunión de arquitectura.

Auditoría. Todo lo que pasa en una plataforma de trading tiene que poder reconstruirse después: quién hizo qué, cuándo, con qué datos de mercado disponibles en ese momento, y qué decisión tomó el sistema o el usuario. Esto cambia la forma de diseñar los flujos: cada operación necesita un rastro completo, inmutable y consultable, no como un agregado posterior sino como parte del modelo de datos desde el inicio. Diseñar la auditoría "después" suele terminar siendo más caro y más frágil que incorporarla desde el principio.

Tiempo real. Los mercados no esperan. Una plataforma de inversiones necesita reflejar precios, posiciones y estados de operación con una latencia que el usuario no perciba como tal. Esto impacta en las decisiones de arquitectura: qué se sincroniza en vivo, qué se puede procesar de forma asíncrona, y dónde conviene aceptar eventual consistency y dónde no hay margen para eso. La tensión entre "todo en tiempo real" y "todo consistente" es una de las discusiones de diseño más recurrentes en estos sistemas, y no tiene una respuesta única: depende de qué parte del flujo se esté mirando.

Estos tres requisitos no viven en compartimentos separados. Una decisión de seguridad afecta la auditoría, y una decisión de tiempo real afecta la seguridad. Diseñar para los tres al mismo tiempo, desde el principio, es lo que distingue a una plataforma financiera robusta de un prototipo que funciona en la demo pero no sobrevive a producción.

El backoffice de operaciones y la conciliación

Si el frontend de trading es la parte visible del iceberg, el backoffice de operaciones es lo que sostiene esa visibilidad. Una parte central del trabajo en este proyecto fue justamente ese backoffice: el conjunto de herramientas y procesos que permiten que las operaciones ejecutadas se registren, se validen y se concilien contra las fuentes de verdad correspondientes.

La conciliación es, en mi experiencia, uno de los problemas más subestimados en fintech. No es vistosa ni aparece en las demos, pero es donde se detectan los errores que importan: una operación que no coincide, un estado que quedó inconsistente entre sistemas, una diferencia que hay que explicar. Diseñar bien esta capa implica pensar en:

• Trazabilidad de extremo a extremo, para poder seguir una operación desde que se origina hasta que se liquida, sin zonas grises.
• Procesos de reconciliación periódicos y también bajo demanda, porque los problemas no siempre se detectan en el ciclo automático.
• Alertas claras y accionables cuando algo no concilia, dirigidas a quien realmente puede resolverlo, no a un log que nadie revisa.

El backoffice no es un módulo secundario: muchas veces es el que determina si la plataforma es confiable a largo plazo. Un frontend de trading impecable con un backoffice débil es una promesa que, tarde o temprano, se rompe.

Cómo trabajar con equipos del cliente y proveedores

La arquitectura técnica es solo una mitad del trabajo. La otra mitad, igual de determinante, es cómo se coordina el trabajo entre el equipo de desarrollo, los equipos internos del cliente y los proveedores externos del ecosistema (datos de mercado, custodia, infraestructura, entre otros).

Algunos aprendizajes de proceso que me quedaron:

Entender el dominio antes de proponer soluciones. En un proyecto financiero para una empresa de energía hay reglas de negocio, restricciones regulatorias y procesos internos que no están en ningún documento técnico. La primera etapa productiva no es escribir código: es escuchar a los equipos que conocen esas reglas y traducirlas en requisitos claros.

Alinear expectativas de integración con cada proveedor por separado. Cada proveedor tiene sus propios SLA, formatos de datos y ventanas de disponibilidad. Parte del trabajo de un Forward Deployed Engineer es mapear esas particularidades temprano, para que no se conviertan en sorpresas cuando el sistema ya está en producción.

Comunicación frecuente y verificable. En proyectos con múltiples partes interesadas, la ambigüedad es el enemigo silencioso. Documentar decisiones, confirmar entendimientos por escrito y validar supuestos con quienes tienen el contexto de negocio evita retrabajos más adelante.

Diseñar para el cambio. Los requisitos regulatorios y de negocio en un entorno financiero evolucionan. La arquitectura tiene que poder absorber esos cambios sin que cada ajuste implique reescribir medio sistema.

Trabajar en la intersección entre lo técnico y lo organizacional es probablemente la parte del rol de Forward Deployed Engineer que más valoro: no se trata solo de resolver problemas de ingeniería, sino de resolverlos dentro de un contexto humano y de negocio real.

Qué me llevo

• En fintech, la arquitectura técnica y el proceso de trabajo con las personas son inseparables.
• Seguridad, auditoría y tiempo real se diseñan juntos desde el inicio, porque cada decisión afecta a las otras dos.
• El backoffice y la conciliación merecen la misma atención que el frontend visible.
• Escuchar al equipo que conoce el dominio viene antes que escribir código.
• Documentar decisiones y confirmar supuestos por escrito evita muchos retrabajos.

Si estás trabajando en algo parecido o tu equipo enfrenta desafíos similares, me interesa intercambiar experiencias: podés escribirme por LinkedIn. Y si querés conocer más de mi trabajo como Forward Deployed Engineer, lo cuento en mi portfolio: https://estebanburgos.com.ar/portfolio.