Collective liquidity

1) Why do you need it

Instant liquidity in new clusters. Launch in the region/niche - "mix" the general pool.
Better match and prices. The deep market → less spread, above EPI (improvement in effective price/selection).
Supply/demand shocks. Load overflow between nodes reduces failure and queues.
Economics. Above fill rate and ARPU with moderate cost increases; cross-sell capability.

2) Collective liquidity models

3) Architectural components

Orderbook/catalog: application/offer abstractions, status and versions, SLAs and compatibility attributes.
SOR (Smart Order Routing): rules for selecting a pool/supplier taking into account price/quality/jurisdiction/latency.
Consistency: CDC and event logs, event _ id dedup, compensating transactions.
Attribution and billing: who is the "owner" of the transaction/commission, claim windows, reconciliation.
Quality and reputation: partner ratings/SLAs, penalties, badges.
Privacy and localization: PD masking, geo-pinning, event export rules.

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) Data contracts (minimum fields)

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: rules and pseudocode

• `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: supplier rotation, turnover share quotas, tie-break on reputation and recent winnings.

6) Liquidity metrics

Fill rate = closed applications/all applications (by segment/cluster).
Time-to-match (p50/p95) - time to selection/execution.
Depth - available volume in the specified price/quality range.
Spread/EPI - improving the effective price vs benchmark.
Utilization - loading a sentence (idle% ↓ - good if without SLA failures).
Integrity - proportion of cancellations/folds conversions, discrepancy in reconciliation (<ε).
Fairness - variance of the distribution of sales to suppliers with equal quality.

• 'fill _ rate _ month ≥ 92% 'in a cluster with ≥ N active offers.
• 'p95 _ time _ to _ match ≤ 3s' during peak hours.
• `cancel_rate ≤ 1. 5% 'with vendor SLA' on-time ≥ 98% '.

7) Observability and evidence base

Events: 'request. sent`, `quote. received`, `match. made`, `settled`, `cancelled`, `refund`.
Traces: 'trace _ id' through SOR → pool → provider.
Audit: signatures of webhooks, log of orderbook versions, "screenshot" of quotes.
Reconciliation: bilateral reports, dedup, discrepancies <ε, claims closure SLA.

8) Privacy, compliance, sovereignty

Geo-pinning: sensitive categories/PII do not leave the permitted region.
Pseudonymization: for inter-partner exchange - only pseudo-identifiers.
Retention as code: TTL events, right to delete, Legal Hold.
DPA/webhooks: signature, anti-replay, schema control.

9) Operating model and calculations

Roles: Market Operator (you), Pools/Partners (supply), Channels/Showcases (demand).
Commerce: RevShare/CPA/minimum warranties; "clip" for routing/price improvement.
Credits/penalties: for SLA disruption, false offers, inconsistency of reports.
Settlement: T + N frequency, holds, chargebacks, reporting.

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) Integration patterns

Pull-quote API with time-box (idempotency-key).
Signed Webhooks for 'match. made '/' settled '(retrai with exponent).
Event bus for CDC orderbook and analytics (event versions).
Batch-recon (daily SFTP/Blob + checksums).
Outbox/Inbox on both sides + dedup.
Schema/SDK versioning, compatibility window.

11) Overload and swing control

Anti-congestie: limiters, queues, VIP/complex case prioritization, surge factors.
Anti-arbitrage (toxic): prohibitions of "self-execution" at a low price/quality, monitoring of "ping-pong" requests.
Anti-fraud: device/behavioral signatures, honey-tokens, delayed qualification (cool-off).
Degradation with honor: fallback to local pool, "best-effort" with transparent degradation.

12) Examples of logic (sketches)

12. 1 Jurisdictional and SLO Routing

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 Justice Policy (Rego-idea)

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

12. 3 Orderbook Convergence Test

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) Maturity metrics

Coverage: share of segments/regions where there are ≥ X active offers.
Elasticity: how quickly fill rate recovers at + Δ demand.
EPI/Spread-improvement: benefit from aggregation vs solo pool.
Fair-distribution: deviation of the turnover share from the expected one in terms of quality.
Recon-health: frequency/timing of closure of discrepancies.
Privacy-score: the share of routes without PD removal beyond the policy boundaries.

14) Anti-patterns

Naked federation without SOR and quality rules → fragmentation, cancellation.
"Glass market": open everything to everyone - a splash of fraud and price war.
No attribution and reconciliation → eternal disputes and frozen payments.
Hard synchrony between pools → cascaded latency/failures.
The same rules for different segments → degradation of experience in premium/local niches.
Ignoring TTL offers → deals under "rotten" conditions.
A single encryption key for the entire → market cannot be "erased" point by point.

15) Architect checklist

1. Model (shared pool/federation/hub) and sovereignty constraints defined?
2. Is there a data contract (schemas, versions, TTL, signatures) and a compatibility window?
3. Implemented SOR with fairness and comps, liquidity SLO and dashboards?
4. Billing/attribution, claim windows, credits/fines are registered?
5. Built in anti-congestie/anti-fraud/anti-arbitrage and degradation mode?
6. Reconciliation and artefacts of "evidence of a deal" established?
7. Privacy: pseudonymization, geo-pinning, retention, right to delete?
8. Drill: Demand Stress Peaks/Pool Drop/Orderbook Out of Sync?
9. FinOps: egress budget, routing cost, target EPI?
10. Governance: threshold shares, partner certification, audit.

Conclusion

Collective liquidity is not to "connect another partner," but to design the market: uniform contracts and events, transparent rules of routing and fairness, strong observability and calculations, privacy and jurisdictions "like code." Thus, from disparate sources, a single, deep and sustainable pool of supply and demand is born - with the best experience for users and a predictable economy for the entire ecosystem.