Devbrew logo

Let Routing Agents Fight for Your FX Margin

Increase cross border payments margin by optimizing FX and routing, without rewriting your stack, in 90 days.

9 min read•
Joe Kariuki
Joe KariukiFounder & Principal

Cross border payments have a quiet tax.

It shows up as FX cost, partner fees, and corridor complexity. But the real leak is simpler.

You are making dynamic decisions with static logic.

Banks and payment intermediaries can capture meaningful margin through exchange rate markups and fees, often in the low single digits for many flows. Zoom out and cross border is still expensive to run.

If you are a Series A to C payments company scaling cross border volume, you do not need a prettier dashboard.

You need a decision layer that keeps hunting for a better route, a better FX source, and a safer hedge, payment by payment.

That is what routing and FX agents do.

The mistake: hard coding strategies in a market that moves every minute

Most teams treat routing and FX like configuration.

  • Default rail for corridor X
  • Fallback rail if partner A is down
  • Spread rules that never look at live quotes
  • Hedge later because it is good enough

It works until it does not.

Because best route changes constantly based on:

  • Live spreads and liquidity depth
  • Rail uptime, cutoffs, and settlement windows
  • Fee schedules that vary by partner, method, and amount
  • Failure rates and retry cost
  • Prefunding constraints and treasury position
  • Exposure, hedging rules, and timing

Static rules cannot compete with that. They cannot see. They cannot adapt. They cannot learn.

What routing and FX agents actually do

Routing and FX agents sit above your existing PSPs, banks, and liquidity providers. They do not replace them. They orchestrate them.

For every payment, the agent evaluates:

  • Executable FX quotes across providers
  • Available rails and settlement paths
  • Fees, cutoffs, and expected failure risk
  • Treasury constraints like prefunding and inventory
  • Risk policy, compliance constraints, and exposure limits
  • Optional hedging actions, if treasury and risk allow it

Then it selects the best plan for that specific payment.

Not the cheapest on paper. The cheapest that actually settles, on time, within your rules.

A concrete example: one payment, one decision

A customer sends a cross border payout.

The agent pulls live quotes from two liquidity sources, checks rail uptime and cutoffs, estimates total fees for three route options, and scores expected success based on recent failure rates.

It chooses Route B because it is 9 bps cheaper end to end, still meets settlement SLA, and avoids a rail that is currently degrading.

It logs the full decision trail: inputs, constraints, expected cost breakdown, and reason codes.

If Route B fails, it follows a pre-approved fallback path and flags the incident, without creating double pays or reconciliation chaos.

This is the difference between analytics and a production decision system.

Why this works in the real world

Here is why this is not just a nice idea.

  1. AI driven FX decisions can cut hedging cost

    If you have meaningful FX exposure from cross border flows, better forecasting and hedging decisions can translate directly into margin.

  2. Routing optimization is a cost and speed lever

    Route choice is a product and margin decision, not plumbing. The best path depends on live rates, network availability, fees, and reliability.

  3. New rails can reduce cost, but only if you can orchestrate them

    Tokenized and stablecoin based rails can be cheaper and faster in some corridors. That only matters if your system can safely evaluate them, enforce policy, and fall back cleanly.

Teams already do pieces of this manually. Agents just turn it into a repeatable decision loop.

The core mechanism: treat routing and FX as continuous search

A routing and FX agent is a decision system that runs a loop.

1. Observe

It ingests the live state required to choose a path:

  • Quotes across liquidity sources
  • Rail availability and cutoffs
  • Expected fees per route
  • Recent success rates by rail and corridor
  • Treasury constraints, prefunding, and inventory

2. Decide

It selects an execution plan for this payment.

A plan bundles:

  • Which rail to use
  • Which liquidity source to use
  • Whether to split, net, batch, or delay within policy
  • Whether to hedge, how much, and with what instrument
  • What markup to apply to hit margin targets without killing conversion

3. Execute

It routes the payment, logs the decision, and enforces guardrails.

4. Learn

It captures outcomes and improves the policy over time:

  • Final FX slippage versus expected
  • Actual fees versus quoted
  • Settlement time and failure rates
  • Retries, fallbacks, and customer impact

Static routing can only repeat. Agents can compound.

A practical mental model: shortest path with risk rules

Routing is graph search.

  • Nodes: rails, banks, liquidity venues, tokenized settlement legs
  • Edges: fees, spreads, latency, failure risk, compliance constraints
  • Objective: minimize total cost while meeting SLA and risk requirements

Your risk rules become hard boundaries:

  • Sanctioned entities and jurisdictions are blocked
  • Certain rails are limited to specific use cases
  • Max slippage per corridor
  • Max time to settle
  • Required audit fields for every decision

If you cannot explain why a payment was routed a certain way, you will not get this into production.

That is the idea. Now here is what it needs to look like in production.

What you should demand from an agent in production

Deterministic guardrails

Models can propose. Policy gates execution.

Auditability

Every decision needs a replayable trail: inputs, constraints, chosen path, expected cost breakdown, and reason codes.

Outcome based measurement

Track what actually moves the business:

  • Savings per payment and per corridor
  • Margin lift by corridor
  • Settlement time reduction, especially p95 and tail latency
  • Failure rate reduction and retry cost reduction
  • Corridor launch time reduction

Controlled rollout

Start in shadow mode first, then gradually turn on execution with tight limits.

The business impact: why this matters in dollars

For growing payments companies, the upside is tangible:

  • Higher margin per transaction
  • Better pricing flexibility against competitors
  • Faster corridor launches without rewriting rules every time
  • Less operational firefighting when rails degrade

A simple gut check makes this real.

If you process 100Mpermonthincrossbordervolume,then20bpsofsavingsis100M per month in cross border volume, then 20 bps of savings is 200k per month. That is $2.4M per year, from one improvement loop.

A sane rollout plan in 90 days

Days 1 to 21: build the decision substrate

  • Normalize quotes, fees, and rail status into one schema
  • Define policy as code, not tribal knowledge
  • Build a replay simulator for historical flows
  • Agree on a baseline total cost per payment model you trust

Days 22 to 45: launch in shadow mode

  • Pick two to three corridors with obvious margin leakage
  • Recommend routes without executing them
  • Compare against your current baseline, assumptions stated

Days 46 to 70: turn on execution with tight limits

  • Cap volume, amount bands, and allowed rails
  • Require approval for new corridor behavior
  • Monitor daily deltas, savings, failures, and settlement performance

Days 71 to 90: expand and harden

  • Expand corridor coverage gradually
  • Add hedging hooks if you have exposure and risk sign off
  • Lock in observability, audit logs, rollback controls, and incident runbooks

Why most teams struggle to implement this internally

The hard part is not picking the best route.

The hard part is building a production decision system that finance and risk will sign off on.

Teams usually get stuck on:

  • Normalizing quotes, fees, and rail status into one decision view
  • Building replay so changes can be tested safely
  • Encoding risk policy in a strict, auditable way
  • Handling fallbacks without double pays, stuck payments, or reconciliation chaos
  • Proving lift with clean measurement, not vibes
  • Getting the control surfaces right, approvals, limits, reason codes, rollback

This is where a good idea turns into a real system, or quietly dies.

Where Devbrew fits

You probably already have the ingredients scattered across your stack: PSP integrations, bank partners, treasury workflows, risk rules, and a routing configuration nobody wants to touch.

Devbrew works with payments teams to build routing and FX optimization agents that integrate with your PSPs and banking partners.

The focus is practical and measurable:

  • Savings per payment
  • Margin lift by corridor
  • Faster corridor launches
  • Controlled risk, with auditability

Corridor margin leak review

If you want to pressure test this idea, start with one corridor.

You share the last 30 days of flows for that corridor. Redacted is fine. At minimum:

  • Timestamp, corridor, send amount, payout amount
  • FX rate applied, fees charged, provider or rail used
  • Outcome, settlement time, and any failures or retries
  • Any constraints you already enforce, amount bands, cutoffs, approved rails

We return:

  • A corridor cost stack: spread, fees, failures, time, ops overhead
  • A savings estimate range, with constraints stated
  • A 90 day build plan, plus the metrics that prove impact

If the numbers make sense, we can scope a pilot corridor and ship the decision layer with guardrails.

If you want us to run it with you, reach out via the Devbrew contact page

Sources

LinkedinShare on LinkedInXShare on X

Let’s explore your AI roadmap

We help payments teams build production AI that reduces losses, improves speed, and strengthens margins. Reach out and we can help you get started.