Exchange-proximity deployment, explained

Most consumer trading bots run from a single cloud region the developer happened to be most comfortable with. That is fine for slow swing trades and calamitous for anything aggressive. This post is the simple explanation of why deployment region matters, what an automatic region router actually does, and how to tell whether a platform has one.

The geography of a crypto match engine

Major crypto venues run their matching infrastructure in a small number of cloud regions — typically Tokyo, Singapore, and one US-East zone. Some venues publish the region; others do not, and you can infer it from the latency distribution from various test points around the world. The point is that there is a physical place where the order is actually matched, and the speed of light through fiber sets a floor on how fast you can talk to it.

What a wrong-region deployment costs

Numbers below are illustrative typical RTT measurements, not a specific exchange:

# Illustrative — typical client-to-match-engine RTT
Match engine in Singapore, client in:
  Singapore (same region)        ~15-30 ms     <- target
  Tokyo                          ~70-90 ms
  Mumbai                        ~110-130 ms
  Frankfurt                     ~150-180 ms
  US-East (N. Virginia)         ~200-240 ms
  US-West (Oregon)              ~170-200 ms

Once you are in the wrong region, no amount of code optimisation recovers the speed of light. The fastest client in the world running from US-East to a Singapore match engine is still going to add ~200 ms to every order trip.

What automatic region selection actually does

An order router that “auto-selects the region” should do four concrete things, not one:

1. Continuously measure RTT to each supported exchange from each region the platform has capacity in.
2. Maintain a per-exchange routing table that maps each venue to its current best region, updated on a short cadence.
3. Place each customer's order flow on the region that wins the routing decision for the customer's active venues.
4. Detect a regional incident (network blip, region outage, AZ drain) and shift flow to the next-best region without manual intervention.

The first item is the easy one. The fourth is the one that most platforms quietly skip, because it requires multi-region capacity to be live and warm at all times.

Why “we are in AWS Tokyo” is not enough

A platform that hardcodes a single region is fine until that region has a bad day. AWS, GCP, and Azure all have regional outages every year. A bot that cannot fail over to another region in minutes will simply stop trading for hours when the region is sick — usually at the worst possible moment, because volatility tends to coincide with infrastructure stress. The bot does not lose money on those hours; it just stops being a bot.

What proof of routing should look like

The honest way to demonstrate this is a public table on the platform's proof page:

• One row per supported exchange.
• Columns for median, 95th, and 99th percentile RTT from each region.
• A label indicating which region is currently selected.
• An updated timestamp.

If a platform cannot show this, it does not really have an automatic router — it has a marketing claim. Ours is on /proof, and it refreshes continuously once the live data feed is on.

What the customer can expect

Customers do not pick a region. The router picks. If we add support for a new venue, the routing table grows a row. If a region has a bad hour, flow shifts. None of that requires the customer to file a ticket, restart a bot, or do anything at all. It is the kind of feature that is invisible when it works and obvious as soon as a competing platform turns red.