Una misma transacción es una compra para una parte y una venta para la otra. Puede tener una fecha de orden, una fecha de negociación, una fecha de valorización, una fecha de visualización y una fecha de liquidación… y cada una puede ser correcta para un propósito distinto. Un modelo de datos simplista intentaría resolver esas aparentes contradicciones. En los mercados privados, así es simplemente como funciona el dominio.
Solemos llamar a esto casos límite: el producto que se valoriza semanalmente en lugar de diariamente, el broker que necesita ver una operación exhibida como del lunes mientras su fecha de precio sigue siendo el viernes, el cliente cuyo proceso de compliance exige confirmaciones adicionales dentro del flujo de la orden, los sistemas externos que nombran todo de manera distinta a la nuestra. Pero cuando se construye la infraestructura que sostiene a los mercados privados, se aprende rápido que estas no son excepciones alrededor del producto. Son el producto. La variación es el dominio.
La pregunta de ingeniería no es cómo eliminar esa complejidad. Es dónde y cómo dejarla vivir.
Donde la interpretación se convierte en ejecución
La parte más difícil de mi trabajo ocurre antes de que alguien escriba una sola línea de código.
Una misma transacción es vista de forma distinta por cada persona que interactúa con ella. El equipo de Integraciones ve campos, mensajes y restricciones de sistemas. Capital Markets ve un ciclo de vida financiero. Operations ve lo que tiene que conciliar al cierre del día. Sales ve el contexto comercial y lo que espera el cliente. El cliente describe todo en el lenguaje de sus propios sistemas. Ninguno está equivocado. Pero el software no puede ejecutar cinco interpretaciones a la vez.
Entonces, antes de que pueda existir una regla, esas cinco perspectivas tienen que convertirse en una sola. Ese trabajo no es escribir las reglas; es lograr que todos acuerden una definición compartida de lo que el negocio realmente significa. Los mercados privados hacen esto inusualmente difícil. La industria cuenta con estándares parciales (plantillas de reporting, documentos modelo, formatos de disclosure) pero no ofrecen un lenguaje operativo único y de punta a punta para describir una transacción desde la solicitud hasta la liquidación.¹ Las cosas se llaman de manera distinta en cada sistema. Buena parte del conocimiento todavía vive en documentos, cadenas de email y conversaciones. No hay un diccionario compartido para heredar; la mayoría de las veces, uno mismo lo está escribiendo.
Una regla de negocio es significado negociado, vuelto ejecutable. El trabajo de ingeniería comienza antes de la implementación: convertir terminología ambigua, perspectivas en conflicto y sistemas que nunca fueron diseñados para hablar entre sí en un solo modelo lo suficientemente preciso y rico como para funcionar.
Variedad necesaria, no configurabilidad ilimitada
Una vez que se asume que la variación es el dominio, aparece una conclusión tentadora: hacer que todo sea configurable. Convertir cada regla en un ajuste, cada diferencia en un toggle, y dejar que el mercado haga lo que quiera.
Esa es la lección equivocada, y vale la pena ser precisos sobre por qué.
El cibernético W. Ross Ashby nos dio la ley de la variedad requerida: solo la variedad puede destruir la variedad. Para regular un sistema, un controlador debe poseer suficiente variedad interna como para igualar la variedad que enfrenta.² Variedad requerida significa igualar las diferencias que importan: no fabricar opciones por sí mismas.
Con muy poca variedad, el sistema no puede representar las diferencias que son reales: obliga a un mercado desordenado a fingir que es uniforme, y se rompe la primera vez que no lo es. Por el contrario, una plataforma que hace todo configurable no ha absorbido la complejidad; se ha rendido ante ella y la ha redistribuido. Cada nuevo ajuste crea una forma más en que dos partes del sistema pueden discrepar sobre cuál es la verdad.
La configurabilidad suele presentarse como un fin en sí mismo. Ese es el objetivo equivocado. La meta no es la máxima flexibilidad. Es dar lugar a las diferencias que son reales sin permitir que las garantías centrales del sistema (identidad, estado, conciliación, auditabilidad) se fragmenten en una docena de versiones de la realidad. La pregunta real siempre es dónde trazar la línea entre lo que puede variar y lo que no debe hacerlo.
La cintura angosta de los mercados privados
El modelo más útil que conozco para trazar esa línea viene de la arquitectura de Internet.
Internet soporta una enorme variedad por encima (¡cada aplicación jamás escrita!) y por debajo (fibra, celular, satelital, wifi). Es ancho en ambos extremos y angosto en el medio, como un reloj de arena. En esa cintura angosta se ubica una única capa estable: el Protocolo de Internet. Esa cintura angosta permite que las capas de arriba y de abajo evolucionen de manera independiente.³ Si se vuelve el centro rico y configurable, cada participante hereda más requisitos, y el cambio coordinado se vuelve más difícil.
La infraestructura de los mercados privados necesita la misma forma. Por encima de la cintura: productos, experiencias de cliente, reporting, flujos de trabajo de cada cliente. Por debajo: los sistemas operados por brokers, custodios y administradores, conectados mediante archivos y APIs. En la cintura se ubica un único modelo canónico de transacción: identidad, un modelo de estados explícito, cálculos determinísticos y versionados, conciliación, y un registro de quién hizo qué y cuándo. El centro no elimina la flexibilidad. La vuelve segura.
Mecanismo y política
Aquí es donde un principio clásico de sistemas demuestra su valor: la separación entre mecanismo y política.⁴ El mecanismo es la maquinaria estable que preserva las garantías del sistema: identidad canónica, transiciones de ciclo de vida explícitas y auditables, evaluación consistente de políticas, conciliación. La política es lo que puede variar: ventanas de negociación, cutoffs, mínimos de producto, visibilidad broker-producto, convenciones de visualización de fechas. La separación nunca es perfectamente limpia; el juicio arquitectónico consiste en trazar ese límite y negarse a que se difumine. El matiz importa: una capacidad de override controlada y auditable pertenece al mecanismo; quién puede hacer ese override, y bajo qué condiciones, es política.
Esta separación importa porque las políticas cambian con más frecuencia que los mecanismos que las hacen cumplir, o que las garantías que esos mecanismos preservan. Un nuevo cliente, producto o jurisdicción puede introducir un cutoff, un modelo de permisos o una convención de visualización distintos. Eso no debería requerir reconstruir la maquinaria responsable de la identidad, la validación, la auditabilidad o la conciliación. Distintas políticas deberían poder atravesar los mismos mecanismos confiables.
Trazar el límite demasiado hacia un lado vuelve rígida a la plataforma. Trazarlo demasiado hacia el otro hace que la plataforma no garantice casi nada: cada cliente debe entender, configurar y compensar las garantías que el núcleo se negó a ofrecer. La misma complejidad, ahora pagada en cada punta.
La verdadera medida
Si se toma distancia, el patrón tiene un nombre. Traducir muchas perspectivas en un solo modelo, igualar la variedad sin multiplicarla, mantener angosta la cintura y separar el mecanismo de la política: en ingeniería de software, todos estos son actos de abstracción y encapsulamiento.
La abstracción define el significado compartido en el que la plataforma puede apoyarse: qué es fundamentalmente una transacción, a través de todas las formas distintas en que los participantes la describen. El encapsulamiento contiene detrás de ella las reglas que varían, de modo que un cálculo de fecha o una regla de un cliente puedan cambiar sin obligar al resto de la plataforma a cambiar con ellas. Esto resuena con el principio de ocultamiento de información de David Parnas: un cambio en una decisión no debería propagarse por todo el sistema.⁵
Juntos, responden la pregunta planteada al inicio: no cómo eliminar la variedad, sino dónde y cómo dejarla vivir.
Una buena abstracción se comporta como un contrato. Es lo suficientemente completa como para poder confiar en ella y lo suficientemente laxa como para poder reimplementarse; lo suficientemente precisa como para eliminar la ambigüedad, pero no tan detallada como para fijar decisiones que todavía nadie tuvo que tomar.
Cuando ese contrato está bien logrado, sucede algo silencioso y valioso. Cada nueva integración reutiliza más del modelo que ya existe. Una nueva contraparte se convierte en un mapeo sobre el modelo canónico de transacción, en lugar de requerir automáticamente un nuevo fork de la plataforma. El valor de esa arquitectura se acumula; la plataforma puede comprender más del mercado sin producir más versiones de la verdad.
Esa es la verdadera medida de la infraestructura en esta industria, y va a contramano de lo que el mercado suele celebrar. La plataforma más sólida no es la que tiene más ajustes. Es la que puede absorber más mercado (más productos, más participantes, más formas de nombrar y hacer las cosas) sin perder su control sobre una única verdad compartida.
Las excepciones no son ruido alrededor del producto. Son el producto. El trabajo consiste en construir un lenguaje lo bastante preciso como para contenerlas a todas.
Tribuna elaborada por Milena Brum — Engineering Manager, LYNK Markets
Notas
¹ La estandarización en los mercados privados es significativa, pero parcial. ILPA provee estándares de reporting, performance, capital calls y documentos modelo, mientras que los análisis de la industria identifican una fragmentación de datos persistente, la ausencia de identificadores estandarizados y silos tecnológicos. Ver ILPA, Templates, Standards & Model Documents; y BlackRock, «Scaling Private Markets with Data Standardization.»
² W. Ross Ashby, An Introduction to Cybernetics (1956), sobre la Ley de la Variedad Requerida.
³ Micah Beck, «On the Hourglass Model,» Communications of the ACM 62, no. 7 (2019).
⁴ Separación entre mecanismo y política: ver Per Brinch Hansen, «The Nucleus of a Multiprogramming System» (1970), y R. Levin et al., «Policy/Mechanism Separation in HYDRA» (1975).
⁵ David Parnas, «On the Criteria To Be Used in Decomposing Systems into Modules,» Communications of the ACM 15, no. 12 (1972).
This document is for informational and educational purposes only and should not be construed as investment, legal, tax or other professional advice. The information herein reflects public data, academic research and industry reports considered reliable at the time of writing; however, accuracy and completeness cannot be guaranteed. Any opinions expressed are those of the author and are subject to change without notice. Investing in private markets and alternative assets involves risks, including loss of principal, illiquidity, valuation uncertainties and manager selection risk. Past performance is not indicative of future results. Investors should consult their own advisors before making investment decisions.
Este documento es únicamente para fines informativos y educativos y no debe interpretarse como asesoramiento de inversión, legal, fiscal ni de ningún otro tipo profesional. La información contenida en el presente se basa en datos públicos, investigación académica e informes de la industria considerados fiables en el momento de su elaboración; sin embargo, no se puede garantizar su exactitud ni integridad. Cualquier opinión expresada corresponde al autor y está sujeta a cambios sin previo aviso. La inversión en mercados privados y activos alternativos conlleva riesgos, incluida la pérdida de capital, la falta de liquidez, incertidumbres en la valoración y riesgos en la selección de gestores. El rendimiento pasado no es indicativo de resultados futuros. Los inversores deben consultar a sus propios asesores antes de tomar decisiones de inversión.
