Behind the build: why X-Weave routes the way it does

X-Weave is the orchestration layer inside Resrv. It decides, for any given cross-border payment, which corridor to use, which currency to convert through, and which regulated partner rail to touch on the way out. It is also the piece I get asked about most often when people are evaluating the platform.

This is a look at how it works and, more usefully, how we decided what it should do. Including the parts of the design we got wrong on the first pass.

The design question we started with

The starting question was not "how do we route payments." It was "what does a payment look like when the person sending it does not have to know anything about the plumbing."

That framing turned out to matter. If you start from "route payments," you build something that looks like a smart wire aggregator, and you end up exposing a lot of routing decisions to the caller. If you start from "make the plumbing invisible to the sender," you build something that has to make many more decisions internally, but the interface stays clean.

We chose the second. The X-Weave API takes a source amount, a destination, and a set of policy preferences (speed, cost tolerance, compliance constraints). Everything else is our problem.

The three routing dimensions

Every payment X-Weave handles gets scored across three dimensions before it executes.

Corridor availability is the first. Is there a legal, licensed path from the source currency to the destination currency at the time of the request? This sounds trivial. It is not. Corridor availability changes with the calendar, with regulatory events, and with the operational status of partner banks. A route that was open at 10am might be closed by 2pm because a partner bank has hit its exposure limit for the day.

Cost is the second. For every open corridor, X-Weave models the total cost of the payment: the FX spread, the on-chain fees, the off-ramp fees, the partner bank fees, and the implicit cost of any settlement delay. This is a per-request calculation, not a lookup, because prices move.

Compliance friction is the third. For any given payment, some routes pass through counterparties or jurisdictions where the compliance overhead is higher than others. That overhead has a real cost, both in time and in probability of a hold. X-Weave does not just check whether a route is compliant; it estimates how much friction the compliance layer will introduce.

The final route is the one that best fits the caller's stated preferences across those three dimensions. Not the cheapest by default. The one that matches what they asked for.

What we got wrong the first time

The first version of X-Weave was too clever. We built a routing engine that could evaluate hundreds of possible paths for every payment and pick the theoretical optimum. It was mathematically elegant and operationally awful.

The problem: some of the exotic routes it picked worked in principle and broke in practice. Small liquidity providers did not always have depth. Compliance approvals we assumed were fast were sometimes slow. Off-ramps that were technically available were operationally clunky. We were computing an optimum in a model that did not quite match reality.

The rewrite was, in some ways, a simplification. The new version has a much smaller set of preferred routes for each corridor, three to five in most cases, that we have operationally validated end to end. The engine is still capable of considering more if the preferred routes are unavailable, but it does not optimize into the long tail unless it has to.

The lesson we took away: in payments, the difference between a route that works in a spreadsheet and a route that works in production is enormous. Optimize for reliability of the routes you use, not for the theoretical elegance of the routes you could use.

The compliance layer is not a filter, it is a partner

One of the design decisions I am most proud of is treating compliance not as a gate but as an integrated participant in routing.

The naive design puts compliance at the end: pick a route, then check if it is allowed. The problem with that design is that if compliance says no, you have wasted time and you have to re-route.

X-Weave puts compliance in the routing loop. Every candidate route is scored for cost, availability, and compliance friction: how likely the payment is to sail through, how likely it is to trigger a hold, how long a hold would likely take. That score feeds into the routing decision, so the route you get is the one most likely to actually complete without a compliance review, rather than the cheapest one that passes the initial filter.

This has a second benefit that we did not fully anticipate. The compliance team ends up seeing fewer edge cases, because the routing engine has already avoided most of them. Their capacity gets spent on genuinely complex reviews rather than clearing routine flows.

What is coming next

A few things we are building in the next quarter that I can talk about.

Better predictive routing. Right now X-Weave picks the best route for the payment as if it were the only payment. In reality, our flow is thousands of payments simultaneously, and the best decision for one payment sometimes is not the best decision for the aggregate. We are moving to a routing model that considers portfolio effects: netting opportunities, liquidity draw effects on partners, that kind of thing.

Explicit customer-visible routing policies. Right now customers give us high-level preferences and we translate. We are building a richer policy layer where a treasurer can express constraints (never route through this jurisdiction, prefer this partner, cap this cost at that spread) directly, and X-Weave respects them.

Deeper failure handling. When something breaks mid-flow, X-Weave already re-routes. We are making that re-routing more transparent to the customer, so they can see what happened, why, and where the payment ended up.

The unglamorous truth

The interesting design decisions in payments infrastructure are almost never the ones that show up in a marketing diagram. They are the small decisions about where the state lives, how a retry gets classified, how a compliance flag propagates. X-Weave is a collection of hundreds of those small decisions, most of which I have barely mentioned here.

What I would say if I had to compress it: the routing engine matters much less than most people assume, and the operational plumbing around the routing engine matters much more. If we have done our job, the plumbing is what you never notice, and the routing is what you never had to think about.

---

X-Weave is Resrv's orchestration layer for cross-border payouts on regulated rails. To learn more about the API or see it in action, get in touch.