If you operate across Latin America, you already know this: the FX line in your model is rarely what shows up in reality.

Currencies gap on headlines. Local rules change mid‑quarter. Parallel markets appear. “Tomorrow’s rate” can be a different world from “today’s rate”—and sometimes “this afternoon’s.” For businesses funding from USD and touching BRL, MXN, COP, ARS and others, FX can be a structural risk.

At alfred, we sit in the middle of those flows. Our job is to move value between USD, USDC, and local currencies using the right combination of rails—SWIFT, ACH, instant systems like Pix and SPEI, and stablecoins—without creating FX surprises for customers.

This piece lays out how we think about FX in that environment: the principles that shape our approach to hedging, where and when we actually convert, and the internal controls we treat as non‑negotiable. We’ll stay high level; no trading algorithms or pricing formulas. But the mental model is the important part.

The FX reality in LATAM

Calling these markets merely “volatile”  is—to put it quite frankly—polite. The real picture includes:

• Sudden repricings and gaps.
  Central bank comments, elections, policy announcements, or credit events can move BRL, MXN, COP, ARS in minutes. Markets don’t always walk from Point A to Point B; they jump.
• Controls and administrative FX.
  Some markets impose capital controls, mandatory conversion rules, or specific documentation for FX access. The “headline” rate and the rate you can actually achieve on a compliant, in‑market basis are not always the same.
• Fragmented liquidity.
  Liquidity can vanish outside local hours or during stress. Pricing that looks fine on a screen at 11 a.m. São Paulo time may be meaningless on a Friday afternoon in New York.

For our customers, this shows up as:

• Landed amounts that differ from what internal models assume.
• Difficulty explaining FX variance to controllers, boards, and auditors.
• Tension between trying to “optimize” every tick and simply getting reliable outcomes.

Against that backdrop, our view is simple: you manage FX in LATAM by designing for predictability, not by chasing every possible point of theoretical improvement.

Core principles for FX at alfred

A few ideas anchor everything we do around FX:

Predictable beats perfect.
A rate that is fair, explainable, and repeatable is more valuable than a best‑ever print that can’t be relied on. Customers need to close books, quote prices, and hold themselves accountable. They can’t do that if FX behaves like a slot machine.

Operational reality is the constraint.
Cut‑off times, local market hours, liquidity pockets, documentation rules, and corridor‑specific quirks matter. FX design that ignores those constraints looks cleaner in a spreadsheet than in production.

Ownership of risk must be explicit.
For every flow, there should be a clear answer to: who is exposed to FX risk, over what time window, and to which currency pair? Hand‑waving around this is where disagreements—and losses—start.

Simple, auditable rules beat cleverness.
Anything we do on FX has to be explainable to a corporate treasury team, an auditor, or a regulator in plain language. “Why did this customer get this rate at this moment?” should have a straightforward answer.

Those principles shape how we think about hedging, timing, and controls.

Hedging: what we cover, what you control

There are two broad layers of FX in most cross‑border businesses:

1. Operational FX: the short‑dated exposure tied directly to payments—payroll, supplier payouts, collections that need to be centralized, intercompany flows.
2. Strategic FX: longer‑dated views on currency risk in a market or portfolio (e.g., “how much MXN/BRL/COP risk do we want to hold this year?”).

alfred sits squarely in the operational layer.

We care about the risk between:

• When a customer commits to a transaction (or set of transactions).
• When the corresponding FX conversions and settlements actually complete along the rails.

The question is: for that window, how do we make sure the customer gets something close to what they expected?

Our approach has a few components:

• Natural hedging where possible.
  In corridors with both inflows and outflows, we look for ways to match flows in the same currency before going out to the broader market. That reduces the amount that needs to be converted and can lower costs.
• Simple instruments over exotic structures.
  Where external hedging is required beyond natural offsets, we lean on straightforward tools (forwards, NDFs, or spot executed with clear timing rules) rather than complex options or structured products. The goal is to manage risk, not to embed opaque payoff profiles into a payment product.
• Clear allocation of risk.
  In product design, we aim to surface:  
  • When a rate is a firm, locked rate vs. indicative.
  • How long that rate is valid.
  • Whether the customer or alfred absorbs deviations if execution differs within defined bands.

We do not:

• Take large directional bets on where BRL, MXN, COP, ARS or others will trade over months or years.
• Run a speculative trading book using customer flows as fuel.
• Bundle speculative behavior into customers’ pricing.

Instead, we build mechanisms to narrow and control the operational risk window around real payment flows, and let corporate treasury teams handle broader strategic hedging according to their own policies.

Timing: where FX happens in the flow

Timing is as important as rate. In a typical international payment, several conversion points are possible:

• At the origin: converting funding currency (often USD) into an intermediate asset like USDC or into the destination currency before movement.
• At the cross‑border leg: converting during or after the move between jurisdictions.
• At the destination: converting close to the time of local payout.

With alfred, a simplified flow might look like:

1. Customer funds in USD from a US bank.
2. Funds are converted to USDC (if that rail is used) at a quoted, timestamped rate.
3. USDC moves across a blockchain rail to a local partner.
4. USDC is converted into the local currency (BRL, MXN, COP, etc.) based on corridor‑specific rules.
5. Local rails like Pix, SPEI, or Bre‑B deliver funds to the end beneficiary.

At each step, we have to decide:

• Convert early or late?
  Converting early can give the customer a rate that’s known at the moment they hit “send,” which is easier to explain and reconcile. Waiting might sometimes pick up marginally better pricing, but at the cost of uncertainty.
• One conversion or multiple?
  Some corridors naturally involve more than one leg (e.g., USD → USDC → BRL). Others can be collapsed (USD → BRL in a single step). Extra legs increase operational complexity and potential slippage; we only keep them if there’s a structural reason.
• Aligning FX timestamps with accounting reality.
  We care about being able to say, “This is the rate applied to this payment at this time,” and having that line up with what shows on bank statements, chain explorers (if relevant), and internal ledgers. That matters for both customers’ reconciliation and our own.

In design trade‑offs, “theoretical best rate if everything goes perfectly” usually loses to “firm rate at the moment of customer action that we can defend and reproduce.” Customers need to run their businesses, not reverse‑engineer every micro‑move we made in FX.

Internal controls: keeping FX boring (in a good way)

When currencies are noisy, the control framework around FX has to be quiet and predictable. Internally, we focus on three areas: governance, guardrails, and observability.

Governance: who can change what

• FX behavior—how and when we convert, which counterparties we use, corridor‑specific rules—is treated as a controlled configuration, not something that changes casually.
• Changes go through documented review, with clear owners, approvals, and testing requirements.
• We avoid “hero tweaks” in production. If a corridor needs a structural change, we do it with eyes wide open, not via ad‑hoc overrides.

Guardrails: limits and sanity checks

• We track exposure windows and notional limits by currency and corridor.
• We set thresholds for deviations between indicative pricing and executed pricing.
• Alerts and circuit‑breakers exist for:
  • Unusual rate moves.
  • Gaps between expected and actual landed amounts.
  • Counterparty or market issues.

The aim is not to eliminate volatility—that’s impossible—but to prevent local anomalies from turning into systemic problems.

Observability: data on every transaction

For each payment touching FX, we care about:

• The currencies involved and direction of conversion.
• The rate applied and its timestamp.
• The source of that rate (e.g., which liquidity provider or internal book).
• How that shows up in the customer’s reporting.

We use this data internally to:

• Validate that our routing and execution behave as intended.
• Measure slippage and spread.
• Provide customers with enough detail to reconcile and explain FX internally.

None of this is glamorous. That’s the point. Good FX infrastructure should feel unexciting from a risk perspective, even when markets are jumping around.

How this shows up for customers

All of the above is under the hood. From a customer’s vantage point, FX should be transparent and unsurprising.

When you interact with alfred, you should see:

• Clear, up‑front information about:
  • What currencies you can send and receive.
  • Where a rate is indicative vs. locked.
  • How long a quote is valid, if we present one.
• Stable corridor behavior.
  If you run the same type of payment through the same corridor under similar conditions, you should not see wildly different FX outcomes from day to day, barring major market moves.
• No “mystery fees.”
  We aim to avoid the classic experience where a payment lands short by some number of local units with no clear line item explaining why. If there are FX spreads or fees, they should be attributable and documented.

A couple of simplified examples:

• USD → BRL supplier payment:
  You fund in USD, see a rate and BRL target amount at initiation, and the supplier receives that BRL figure via Pix. If the environment changes materially between initiation and execution, our product behavior is defined in advance; you’re not discovering it incidentally in your reconciliation.
• COP collections → USDC treasury:
  Your Colombian entity collects locally in COP; alfred helps design the flow so the right tax and FX documentation is present. Once funds are inside the system, you can choose if and when to convert COP to USDC and then to USD or another currency, with FX points that line up with your internal treasury policy.

The underlying question we ask ourselves is simple: if a customer’s controller, CFO, or auditor asks “Why did we get this rate on this day for this flow?”, can we give them a clear answer in a short conversation?

What we won’t do

A few boundaries are intentional:

• We don’t try to run a speculative FX trading business off the back of customer flows.
• We don’t design opaque, highly structured FX products that are hard to value or explain.
• We don’t promise to “beat the market” in every scenario.

Instead, we focus on:

• Reducing operational FX noise for customers’ day‑to‑day flows.
• Making it easy to align corridor behavior with customers’ own treasury policies.
• Providing the data and control surfaces needed for customers to do their own strategic hedging.

In a region where currencies often ignore your plans, the role of an infrastructure provider is not to outguess the market. It’s to make sure that when money moves, the FX component behaves in a way you can understand, plan around, and defend.

Where we’re investing

Without going into proprietary detail, a few areas matter to us going forward:

• Routing and liquidity.
  Expanding and diversifying counterparties, improving how we choose execution paths per corridor and time of day.
• Deeper local integrations.
  Working closely with banks and licensed partners to align FX behavior with local payment rails, controls, and tax regimes instead of treating FX as separate from the payment stack.
• More transparency to customers.
  Exposing FX data and behavior more directly in our products and APIs, so treasury and finance teams can tune flows to match their own risk and accounting frameworks.

If your current experience of LATAM FX is a mix of surprises, unexplained shortfalls, and difficult month‑ends, you’re not alone. Our goal at alfred is to make that part of the world feel more like the rest of your stack: consistent, observable, and something you can design around, even when the currencies themselves refuse to sit still.