Liquidez colectiva

1) Por qué es necesario

Liquidez instantánea en nuevos clústeres. Se ejecuta en una región/nicho - «agitar» la piscina común.
Mejor cumplimiento y precios. El mercado profundo → menos «spread», por encima del EPI (mejora del precio efectivo/selección).
Shocks de oferta/demanda. El flujo de carga entre nodos reduce la falla y las colas.
La economía. Mayor tasa de archivo y ARPU con un aumento moderado de los costos; posibilidad de cross-sell.

2) Modelos de liquidez colectiva

3) Componentes arquitectónicos

Orderbook/catálogo: abstracciones aplicación/offer, estado y versiones, SLAs y atributos de compatibilidad.
SOR (Smart Order Routing): reglas para seleccionar un grupo/proveedor teniendo en cuenta el precio/calidad/jurisdicción/latencia.
Consistencia: CDC y registros de eventos, dedoup por 'event _ id', compensando las transacciones.
Atribución y facturación: quién es el «propietario» de la transacción/comisión, ventanas de reclamaciones, reconciliation.
Calidad y reputación: calificaciones/SLA del socio, multas, insignias.
Privacidad y localización: enmascaramiento de PD, geo-pinning, reglas de exportación de eventos.

mermaid flowchart LR
U [Demand] --> GW [Routing Gateway]
P1 [Pool A] --- GW
P2 [Pool B] --- GW
P3 [Partner C] --- GW
GW --> SB[Settlement/Billing]
GW --> OBS[Observability/SLO]

4) Contratos de datos (mínimo de campos)

yaml offer. v1:
id: uuid kind: product    slot    capacity price: {amount: decimal, currency: ISO4217}
quality: {rating: 0..5, sla_ttm_ms: int}
geo: {region: "EU", city: "Tallinn"}
vendor: {id: "partner-123", tier: "gold"}
terms: {ttl_s: 60, cancellation: "window:15m"}
version: 7 request. v1:
id: uuid constraints: {geo, time, price_ceiling, compliance}
qos: {max_ttm_ms: 500, min_rating: 4. 0}
trace_id: uuid consent: {...}

5) SOR: reglas y pseudocódigo

• `score = w_priceprice_improvement + w_slattm_slo + w_qquality + w_geodistance_penalty + w_riskvendor_risk_penalty`

python def route(request, pools):
candidates = []
for pool in pools:
if not compliant(request, pool):
continue quotes = pool. quote (request) # timebox, idempotent for q in quotes:
s = score(q, request)
candidates. append((s, pool, q))
ordered = sorted(candidates, key=lambda x: -x[0])
return best_feasible(ordered, fairness=request. fairness)

Fairness (equidad): rotación de proveedores, cuotas de facturación, tie-break por reputación y ganancias recientes.

6) Métricas de liquidez

Tasa de archivo = solicitudes cerradas/todas las solicitudes (por segmento/clúster).
Tiempo-a-match (p50/p95) - tiempo antes de la selección/ejecución.
Depth es el volumen disponible en un rango de precio/calidad determinado.
Spread/EPI - mejorar el precio efectivo vs referencia.
Utilidad - descarga de la oferta (idle% ↓ - bien si sin fallas de SLA).
Integrity - Proporción de cancelaciones/conversiones de folios, discrepancia en reconciliation (<ε).
Fairness: varianza de la distribución del volumen de negocios por proveedor a igual calidad.

• 'fill _ rate _ month ≥ 92%' en un clúster con ≥ N offers activos.
• 'p95 _ time _ to _ match ≤ 3s' en horas punta.
• `cancel_rate ≤ 1. 5% 'con SLA del proveedor' on-time ≥ 98% '.

7) Observabilidad y base de pruebas

Eventos: 'request. sent`, `quote. received`, `match. made`, `settled`, `cancelled`, `refund`.
Seguimiento: 'trace _ id' de extremo a extremo a través de SOR → grupo → proveedor.
Auditoría: firmas de webhooks, registro de versiones del orderbuk, «captura de pantalla» de cotizaciones.
Reconciliation: informes bilaterales, dedoup, discrepancias <ε, SLA de cierre de reclamaciones.

8) Privacidad, cumplimiento, soberanía

Geo-pinning: categorías sensibles/PII no salen de la región permitida.
Seudonimización: para el intercambio interpartneriano, sólo pseudo-identificadores.
Retention como código: TTL eventos, derecho de eliminación, Legal Hold.
DPA/webhooks: firma, anti-replay, control de circuitos.

9) Modelo operativo y cálculos

Roles: Market Operator (usted), Pools/Partners (supply), Canales/Vitrinas (demand).
Comercio: RevShare/CPA/garantías mínimas; «clip» por enrutamiento/mejora del precio.
Créditos/multas: por la interrupción de SLA, falsos offers, informes incoherentes.
Settlement: periodicidad T + N, retenciones, chargebacks, informes.

yaml partner_id: "pool-A"
sla:
fill_rate: ">= 90%"
on_time: ">= 98%"
quote_ttl_s: 2 limits:
rps: 200 region: ["EU","TR"]
commercials:
model: "revshare: 20% of net"
security:
webhook_signature: "Ed25519"

10) Patrones de integración

Pull-quote API con caja de tiempo (idempotency-key).
Webhooks firmados para 'match. made '/' settled '(retrés con exponente).
bus de eventos para CDC orderbuk y análisis (versiones de eventos).
Batch-recon (SFTP/Blob + sumas de comprobación diarias).
Outbox/Inbox en ambos lados + dedoup.
Versionar esquemas/SDK, ventana de compatibilidad.

11) Control de sobrecarga y oscilación

Anti-congestión: límites, colas, priorización de casos VIP/complejos, coeficientes de surge.
Anti-arbitraje (tóxico): prohibiciones de «auto-cumplimiento» a un precio/calidad subestimados, monitoreo de solicitudes de «ping-pong».
Anti-Frod: firmas de dispositivo/comportamiento, honey-tokens, calificación diferida (cool-off).
Degradación con honor: fallback a pool local, «best-effort» con deterioro transparente.

12) Ejemplos de lógica (sketches)

12. 1 Routing sujeto a jurisdicción y SLO

python def compliant(req, pool):
return (req. constraints. geo in pool. regions and pool. sla. quote_ttl_s <= 2 and pool. vendor_tier in {"gold","silver"})

12. 2 Política de Justicia (Rego-idea)

rego package fairness deny["overexposed vendor"] {
usage. share[input. vendor] > 0. 45 input. vendor. tier == "silver"
}

12. 3 Prueba de convergencia del orderbuk

sql
SELECT offer_id, MAX(version)-MIN(version) AS drift
FROM orderbook_events
WHERE ts >= now() - interval '5 minutes'
GROUP BY 1
HAVING MAX(version)-MIN(version) > 1; -- fragmentation signal

13) Métricas de madurez

Coverage: proporción de segmentos/regiones donde hay ≥ X offers activos.
Elasticity: ¿qué tan rápido se recupera la tasa de archivo con + Δ demanda.
EPI/Spread-improvement: beneficio de la agregación vs solo-pool.
Fair-distribution: desviar la cuota de facturación de la esperada en calidad.
Recon-health: frecuencia/fecha de cierre de discrepancias.
Privacy-score: proporción de rutas sin llevar el PD más allá de los límites de la política.

14) Anti-patrones

Una federación desnuda sin SOR y reglas de calidad → fragmentación, cancelación.
«Mercado de vidrio»: abre todo a todo el mundo - un estallido de frod y guerra de precios.
No hay atribución y reconciliación → disputas eternas y pagos congelados.
Sincronismo rígido entre grupos → latencia en cascada/fallas.
Las mismas reglas para diferentes segmentos → la degradación de la experiencia en nichos premium/locales.
Ignorar el TTL de los offers → las transacciones bajo condiciones «perdidas».
La clave única de cifrado en todo el mercado de → no puede «borrar» los datos de forma puntual.

15) Check-list del arquitecto

1. ¿Se definen el modelo (grupo/federación/hub común) y las limitaciones de soberanía?
2. ¿Hay un contrato de datos (esquemas, versiones, TTL, firmas) y una ventana de compatibilidad?
3. Implementado por SOR con fairness y macrops, SLO de liquidez y dashboards?
4. ¿La facturación/atribución, las ventanas de reclamaciones, los créditos/las multas están prescritos?
5. ¿Incorporado anti-congestión/anti-frod/anti-arbitraje y modo de degradación?
6. ¿Se ha establecido la reconciliación y los artefactos de «prueba de transacción»?
7. Privacidad: seudonimización, geo-pinning, Retenshen, derecho de eliminación?
8. Enseñanzas: picos de estrés de la demanda/caída de la piscina/resincronización del orderbuk?
9. FinOps: egress presupuesto, costo de enrutamiento, objetivo EPI?
10. Gobierno: cuotas de umbral, certificación de socios, auditoría.

Conclusión

La liquidez colectiva no es «conectar un socio más», sino diseñar un mercado: contratos y eventos únicos, reglas transparentes de enrutamiento y equidad, fuerte observabilidad y cálculos, privacidad y jurisdicciones «como código». Así, de fuentes dispares nace una única, profunda y sostenible cuenca de oferta y demanda -con la mejor experiencia para los usuarios y una economía predecible para todo el ecosistema.