返回题库

跨市场套利检测

Cross Venue Arbiter

专题
General / 综合
难度
L4
来源
MyntBit

题目详情

在碎片化市场中识别跨市场套利机会需要考虑网络延迟以减轻单边风险，即部分成交将理论利润变为实际损失的情况。跨市场套利系统必须实时比较多个交易所的订单簿，同时将执行风险纳入考量。

任务：设计一个跨市场套利检测引擎。

英文原题

Identifying cross-venue arbitrage opportunities in fragmented markets requires accounting for network latency to mitigate leg risk, where partial fills turn theoretical profits into realized losses. Building a latency-aware execution simulator allows quantitative researchers to backtest high-frequency trading strategies against historical order book updates and evaluate true profitability under realistic market conditions.
Task
Build a latency-aware cross-venue arbitrage detector and execution

解析

问题分析

跨市场套利需要在多个交易所之间发现价格差异，同时考虑网络延迟以避免"单边成交风险"（leg risk）——即一个市场的订单成交而另一个市场的对冲订单未成交，导致裸头寸。

核心设计

struct ArbitrageOpportunity {
    std::string buy_venue, sell_venue;
    double buy_price, sell_price;
    int quantity;
    double net_profit;  // after fees, latency cost
    std::chrono::microseconds max_latency;
};

class CrossVenueArbiter {
    std::unordered_map<std::string, MarketSnapshot> order_books_;
public:
    std::vector<ArbitrageOpportunity> scan() {
        std::vector<ArbitrageOpportunity> opps;
        for (auto& [v1, book1] : order_books_) {
            for (auto& [v2, book2] : order_books_) {
                if (v1 == v2) continue;
                auto latency = getLatency(v1, v2);
                auto best = computeBestSpread(book1, book2, latency);
                if (best.net_profit > 0) opps.push_back(best);
            }
        }
        std::sort(opps.begin(), opps.end(), 
            [] (auto &a, auto &b) { return a.net_profit > b.net_profit; });
        return opps;
    }
};

关键考虑

  1. 网络延迟建模：必须使用实际测量的延迟（而非估计值）来计算可行套利窗口。
  2. 费用结构：扣除交易费、清算费和市场数据费后的净利润才是真实套利空间。
  3. 抢先交易风险：其他套利者可能抢先执行，导致仅有部分成交。
  4. 时间复杂度：对 N 个市场，套利扫描为 O(N²)。每个市场对计算最优价差为 O(depth)。

英文解析

Analysis

Cross-venue arbitrage requires detecting price discrepancies across multiple exchanges while accounting for network latency to avoid "leg risk" — the scenario where one market's order fills but the hedging order on another market does not, resulting in a naked position.

Solution

struct ArbitrageOpportunity {
    std::string buy_venue, sell_venue;
    double buy_price, sell_price;
    int quantity;
    double net_profit;  // after fees, latency cost
    std::chrono::microseconds max_latency;
};

class CrossVenueArbiter {
    std::unordered_map<std::string, MarketSnapshot> order_books_;
public:
    std::vector<ArbitrageOpportunity> scan() {
        std::vector<ArbitrageOpportunity> opps;
        for (auto& [v1, book1] : order_books_) {
            for (auto& [v2, book2] : order_books_) {
                if (v1 == v2) continue;
                auto latency = getLatency(v1, v2);
                auto best = computeBestSpread(book1, book2, latency);
                if (best.net_profit > 0) opps.push_back(best);
            }
        }
        std::sort(opps.begin(), opps.end(), 
            [] (auto &a, auto &b) { return a.net_profit > b.net_profit; });
        return opps;
    }
};

Complexity & Edge Cases

  • Time complexity: O(V) per venue for price comparison; O(V log V) for sorted venue selection
  • Space complexity: O(V) for venue price array
  • Edge cases: (1) Venues returning stale quotes produce phantom arbitrage. (2) Network latency differential between venues invalidates theoretical spread. (3) Fee and commission structure varies per venue, reducing net profit.

Key Considerations

  1. Network latency modeling: Must use measured latencies (not estimates) to compute viable arbitrage windows.
  2. Fee structure: Net profit after trading fees, clearing fees, and market data fees represents the true arbitrage space.
  3. Front-running risk: Other arbitrageurs may execute first, resulting in only partial fills.
  4. Time complexity: For N venues, arbitrage scan is O(N\u00b2). Each venue pair computes optimal spread in O(depth).