Teaching a machine what BRL looks like
A price is not just a number. It is a venue, a timestamp, a size, a liquidity condition and a settlement path.
Before an agent can reason about FX, it needs to understand what a price actually means.
A price is not just a number. It is a venue, a timestamp, a size, a liquidity condition and a settlement path. Most systems — human or machine — collapse all of that into a single float and call it "the rate." That collapse is where most reasoning errors about markets begin.
Four kinds of price, not one
Before a machine can reason about BRL, it has to be able to tell these apart, because they answer different questions and are frequently confused with each other:
Core distinctions REFERENCE PRICE — a published benchmark, useful for comparison, not necessarily tradable.
MARKET PRICE — what venues are currently quoting, before size or settlement are considered.
EXECUTABLE PRICE — what you could actually transact at, for a given size, right now.
CLIENT PRICE — what a specific counterparty actually charges a specific client, including their margin.
A model that answers "what's the USDBRL rate" without knowing which of these four it's being asked for isn't wrong so much as it's answering a different question than the one that was meant.
A market observation is a structured object, not a number
To reason correctly, a machine needs a market observation to carry enough structure to answer follow-up questions honestly. At minimum, that means holding all of the following together, not just the number that gets displayed:
instrument venue bid ask mid depth size timestamp timezone reference_usdbrl stablecoin_usd_price market_session settlement_context source freshness
Drop any one of these and you lose the ability to answer a question that will eventually get asked: was this quote from a venue with real depth, or a thin one? Was it fresh, or stale by the time it was used? Was it comparable to the reference rate, or was the reference rate itself from a different session?
Derived objects — where the actual insight lives
The raw observation is the input. The objects worth reasoning about are derived from it:
Derived objects STABLECOIN PREMIUM — the gap between a stablecoin's traded USD price and its peg.
BRL DIGITAL BASIS — the spread between the on-chain USDT/BRL-implied rate and the reference USDBRL rate.
EXECUTABLE SPREAD — the realistic bid/ask a given size could actually clear at, not the headline spread.
ROUTE COST — the full cost of a specific path from currency A to currency B, of which the spread is one term.
None of these derived objects can be computed correctly from a single number. Each one requires the underlying observation to still be intact — the venue, the size, the timestamp, the settlement context — which is the entire argument for treating a price as a structured object from the moment it's captured, not after the fact.
Why this matters before an agent trades anything
An agent that's asked to reason about a route, compare two quotes, or flag a stale price is really being asked to operate correctly across reference, market, executable, and client price simultaneously — and to know which one it's looking at at any given moment. Teaching that distinction first, before any trading logic, is what separates a system that understands markets from one that's pattern-matching on a number.
Before teaching a machine to trade, I want to teach it what a market is. BRL is a good place to start.
Related reading
The database is not the operating system — on why data infrastructure needs to behave like an operating system, not just a database.
What does it actually cost to move $10 million through Brazil? — a CFO framework for measuring what a cross-border route actually costs, not just its headline FX spread.
Follow the money through Brazil.
ONCHAIN FX covers markets, capital, stablecoins, technology, infrastructure and the systems behind moving serious money. Get the next note in your inbox.
Moving meaningful volume through Brazil? Talk to us.
