Multi-exchange execution with unified state
- Problem
- Execution across multiple exchanges resulted in inconsistent positions. The firm could not trust its own position numbers without manual checks, and drift was often caught only at end-of-day reconciliation — after losses had accumulated.
- Constraint
- Different APIs, latency differences, partial fills. Reconnections produced duplicate events. Fills arrived out of order. Each venue reported position in its own format, its own timing, its own truth.
- Decision
- Centralized execution layer with state reconciliation. A unified state store as internal source of truth. Per-venue connectors translate events into the internal model with deduplication. A reconciliation service runs continuously against each venue's reported position.
- Trade-off
- Higher architectural complexity vs guaranteed consistency. The centralized layer becomes a critical path — but every position figure is traceable back to the venue fill that produced it.
- Architecture
- exchange connectors → event normalizer → unified state store ← reconciliation service ← venue position feeds
- Result
- Stable position tracking across all exchanges. Drift detected in seconds, not hours. Duplicate events absorbed without corrupting state. Manual checks replaced by continuous reconciliation.
Settlement reconciliation across fiat and crypto rails
- Context
- A platform moving value between fiat rails (banking partners) and crypto rails (custodians, on-chain addresses), with users initiating transfers from either side.
- Problem
- Fiat settlement can take days. Crypto settlement is near-instant but can fail or get stuck in mempool. The platform's internal ledger shows completed transfers while the underlying rails are still in flight, exposing the platform to reversal risk.
- Solution
- Separation of internal state into three ledgers: intent, in-flight, and settled. A transfer only moves to settled after rail-specific confirmation. A reconciliation service compares internal state against each rail and emits drift events when they diverge.
- Architecture
- transfer intent → validation → rail adapter (bank / custodian / on-chain) → confirmation listener → ledger writer → reconciliation service
- Outcome
- The platform never shows a user a completed transfer that has not actually settled. Reversal risk is isolated to the in-flight ledger, which has explicit limits. Operations can see exactly which transfers are stuck and where.
Risk layer spanning hot and cold paths
- Context
- An automated trading system with strategies running hot-path execution, where the firm needs enforced risk limits without giving up the latency the strategies depend on.
- Problem
- Pre-trade checks in the hot path add latency and still miss systemic risk — exposure that builds across strategies, venues, and time windows. Post-trade checks catch violations after the fact, when the damage is done.
- Solution
- A two-tier risk layer. The hot-path tier holds a cached, conservative view of limits and fails fast on obvious violations. The cold-path tier maintains the authoritative view of exposure and pushes updated limits back to the hot path. When the hot path loses sync, it fails closed.
- Architecture
- signal → hot-path risk gate → execution ↔ fill feedback → cold-path exposure engine → limit updater → hot-path risk gate (closed loop)
- Outcome
- Strategies keep their latency profile. Systemic risk is enforced continuously, not at checkpoints. A stalled cold path does not silently weaken protection — it tightens it.
Tokenized asset issuance with off-chain control plane
- Context
- A protocol issuing tokenized representations of off-chain assets (real-world assets, structured positions, access rights), where transfers must respect both on-chain rules and off-chain constraints.
- Problem
- On-chain smart contracts cannot enforce constraints that depend on off-chain state (jurisdiction, accreditation, KYC status). Encoding them on-chain creates a maintenance burden and leaks sensitive data.
- Solution
- A control-plane service signs transfer authorizations off-chain after checking off-chain state. The on-chain contract verifies the signature and the validity window but remains unaware of the underlying constraints. Token state stays on-chain. Permission logic stays off-chain.
- Architecture
- transfer request → off-chain control plane (policy + signature) → on-chain contract (verification + state change) → indexer → reporting
- Outcome
- The token contract stays simple and upgrade-free. Policy can change without contract changes. Sensitive data stays off-chain. The on-chain footprint is verifiable and auditable.
Ignacio Montoya is a systems architect specializing in algorithmic trading infrastructure, financial systems, and digital asset platforms. These patterns describe the class of problems engagements focus on.
Recognize your system in one of these? You already have the first half of the email. Send it.
Engagement model