Introduction

Most payment infrastructure routes a transaction from A to B and stops there. The routing decision is made, the payment settles, and nothing is learned.

We built RIVR's routing engine on a different principle: every transaction should make the next one better. The routing intelligence should improve continuously, not through product releases or engineering sprints, but automatically, as a property of processing payments at scale.

This post explains how that works in practice: the architecture behind the routing engine, the data it captures, the protections that make it reliable at institutional scale, and why the advantage it creates compounds over time.

The Problem With Single-Venue Routing

The default architecture for most payment infrastructure is single-venue routing: a payment is directed to a specific liquidity source - a single OTC desk, a single DEX, a specific correspondent bank and executed there. The execution quality depends entirely on that venue's current pricing and depth.

For major currency pairs, single-venue routing is adequate. EUR/USD liquidity is deep enough that any reasonable institutional transaction executes at essentially the same rate regardless of which of several major venues handles it.

For emerging market currency pairs, single-venue routing produces systematically worse execution. EUR/TRY, EUR/NGN, USD/PKR — these markets are not deep, unified pools. They are collections of disconnected liquidity pockets: different banks active at different times of day, OTC desks with varying depth at different transaction sizes, DEX venues with pool depth that fluctuates with liquidity provider behaviour.

A payment that routes to the wrong venue at the wrong time on an EM corridor might receive a rate 200–300bps worse than the best available execution across the full set of venues even if all venues are nominally quoting competitive rates. This is because FX is not just a pricing problem. It is a liquidity problem. The 'best rate' at a given moment is the best rate available across all integrated sources, not the best rate available at one.

Multi-Venue Liquidity Aggregation

RIVR's routing engine integrates multiple liquidity sources simultaneously and evaluates them in real time at the moment of each transaction.

For stablecoin pairs (EURC/USDC on Base), the primary execution venue is Aerodrome, a DEX operating on Coinbase's Base blockchain with ve(3,3) tokenomics that create deep, incentivised liquidity pools. Aerodrome processes EURC/USDC at 3–5 basis points with sub-second execution. For large transactions where DEX execution would produce significant market impact, the routing engine shifts to institutional Request for Quote (RFQ) routing directly to market makers including Wintermute, B2C2, and Cumberland, who provide committed prices for the full transaction size.

For the local currency legs converting USDC to TRY, NGN, INR, or BRL the routing engine evaluates available licensed PSP partners by current pricing, operational reliability, and settlement speed, selecting the optimal path based on the combination of those factors at that moment.

The routing decision is not made by a fixed rule. It is made by evaluating the live state of all integrated sources against a set of configurable constraints: maximum slippage tolerance (default 0.1% on stablecoin pairs), minimum execution speed requirement, required compliance characteristics, and maximum acceptable fee. The engine finds the path that satisfies all constraints at the lowest total cost.

Multi-Oracle Price Verification

Any routing engine that executes financial transactions on behalf of institutional clients needs to manage price risk, specifically, the risk that the price feed used for execution is corrupted, stale, or manipulated.

RIVR's routing engine cross-references three independent price sources before any execution:

Chainlink provides the primary decentralised oracle feed. Its network of 31+ independent data providers for major stablecoin pairs requires a threshold of agreement before publishing a price, a single corrupted data source cannot influence the output. Chainlink currently secures over $93 billion in DeFi protocols.

Pyth Network provides institutional-grade price feeds sourced directly from primary market makers like Jane Street, CBOE and Binance with sub-second update rates. These are not secondary data aggregations. They are primary market quotes from institutions with real position exposure.

On-chain TWAP (Time-Weighted Average Price) from Uniswap V3 provides a third reference point derived from actual on-chain trading activity, a price that cannot be fabricated without executing real trades.

Before any transaction executes, the routing engine compares all three sources. If they diverge by more than a configured threshold (default 0.1%), the engine triggers a circuit breaker: the transaction pauses, the discrepancy is logged, and the system waits for price sources to converge before proceeding. This converts a potential adverse execution risk into a temporary delay, a much more manageable outcome than settling at a manipulated price at institutional scale.

MEV Protection: Eliminating the Front-Running Problem

Any payment infrastructure that executes transactions on public blockchain infrastructure faces a specific risk that does not exist in traditional finance: Maximal Extractable Value (MEV).

MEV refers to the value that can be extracted by controlling the order in which transactions are processed. Sophisticated actors like MEV bots monitor the public mempool (the pool of pending transactions waiting to be included in a block) and insert their own transactions to profit from the price movements that other transactions will create. A sandwich attack works like this: an MEV bot sees a large pending USDC/TRY swap, inserts a buy transaction immediately before it (pushing the price up), lets the target transaction execute at the worse price, then sells into the price recovery.

In 2025, $289.76 million was extracted via sandwich attacks alone, with 38% targeting stablecoin swaps. For institutional transactions at scale, MEV is not a nuisance. A 10 basis point sandwich attack on a $5 million transaction costs $5,000. Across 100 institutional transactions per month, that is $500,000 per year in invisible extraction.

RIVR's routing engine uses a two-layer MEV protection architecture. For transactions that route through DEX venues, partnered protocol's batch auction mechanism processes orders without ever submitting them to the public mempool. Sixteen independent solvers compete to fill each batch, but because the batch never enters the public mempool, MEV bots have nothing to front-run. This provides architectural immunity, not probabilistic risk reduction, but elimination of the attack surface.

For transactions that do require mempool interaction, Flashbots Protect routes them through a private RPC endpoint that submits directly to block builders without broadcasting to the public mempool, substantially reducing visibility to MEV bots.

The Data Flywheel: Why Every Transaction Makes the Next One Better

The routing engine captures granular execution data from every transaction it processes. This is where the learning mechanism lives.

Every transaction generates data across four dimensions:

Execution latency: how long did each step take - on-ramp processing, stablecoin swap execution, off-ramp local delivery across each integrated venue and partner, at each time of day and day of week? Latency patterns vary with network congestion, partner operational load, and domestic rail availability. Accumulated latency data builds a predictive model of expected settlement time per routing path per time window.

Price impact: how did the execution of this transaction size affect the rate achieved on each integrated venue? Price impact is a function of liquidity depth which varies continuously. Accumulated price impact data builds a model of effective execution cost per venue per transaction size per corridor, allowing the routing engine to pre-estimate market impact before choosing a venue rather than discovering it during execution.

Liquidity depth: how much volume was available on each integrated venue at each price level at the time of execution? A venue can show a competitive quoted price but have insufficient depth to fill a large transaction without significant market impact. Accumulated depth data allows the routing engine to predict available depth before execution.

Partner reliability: what is the operational success rate of each licensed local PSP, by corridor, by time of day, by transaction size? Reliability patterns allow the routing engine to weight available paths by expected operational success and route around partners showing elevated failure rates in real time.

This data trains a routing model that improves with every transaction. The model does not just learn stable patterns, it learns dynamic ones. How EUR/TRY liquidity behaves around Turkish market close. How NGN delivery reliability varies by time of day. How large transaction price impact differs across DEX pools as liquidity provider balances shift.

A competitor entering the market after RIVR has processed significant transaction volume faces not just a feature gap but an information asymmetry gap. They do not know what the routing engine knows about how these markets actually behave in practice. Closing that gap requires processing the same transaction history, which means starting behind and accumulating data while the incumbent's model continues to improve. Traditional banks cannot build this at all, because their fixed correspondent routing relationships prevent the data collection that multi-venue execution enables.

Compliance as a Pipeline Stage, Not an Optional Call

Routing intelligence is only as good as the compliance architecture surrounding it. An engine that finds the cheapest, fastest path but allows non-compliant transactions to execute is not institutional-grade infrastructure.

RIVR's compliance layer is embedded as a mandatory stage in the settlement pipeline, not an optional API call that clients can choose to invoke. Every transaction passes through Chainalysis sanctions screening and Elliptic transaction monitoring before entering the settlement channel. The screening is not configurable to be skipped. It is a property of the infrastructure, not of the client's implementation.

This distinction matters for institutional adoption. A regulated financial institution evaluating RIVR as an infrastructure partner needs to know that compliance quality is guaranteed by the infrastructure architecture, not dependent on the client's own implementation choices. Mandatory embedded compliance converts the compliance question from 'does the client call the right APIs?' to 'does the infrastructure guarantee screening?' The answer to the second question is simpler and more credible.

Key Takeaway

The routing engine is not a component of RIVR's infrastructure. It is the core of what RIVR does. Everything else - the on-ramp integrations, the PSP partnerships, the compliance pipeline etc.. enables the routing engine to do its job: finding the optimal path for every payment, and improving that capability with every payment processed.

The compounding data advantage this creates is not a feature that can be replicated quickly by a competitor. It is a structural property of a routing engine that has processed real institutional volume on real EM corridors under real market conditions. The moat widens with every transaction.

If you are building payment infrastructure and want to discuss how multi-venue routing and execution data accumulation apply to your specific corridor set, we would be glad to go deeper.