Benjamin AvrahamCEOThe API call is the easy part
A customer-facing hedging product can look remarkably simple. A platform sends the details of a future transaction, receives a price, presents the protection to the customer and confirms the action. From the outside, the product can appear to be an API problem.
But the API is only the visible moment. The real product depends on what happens before the quote, after the quote and when the underlying transaction changes. Pricing has to connect to liquidity. Liquidity has to connect to executable instruments. Execution has to connect to settlement. Settlement has to connect back to the transaction state. Cancellations, timing changes, limits and exceptions have to be handled without breaking the customer experience.
That is the difference between exposing a hedge and operating an embedded hedging product.
Start with the economic event being protected
Embedded hedging begins with a real customer transaction, not with the hedge itself. The transaction may be a travel booking, an installment, a marketplace purchase, a supplier payment or another commitment where the commercial value is agreed now and settlement happens later.
The first infrastructure question is therefore not simply, “Which currency pair?” It is: what event creates the exposure, when does that exposure become economically real, how long does it remain open, and what must be true at settlement for the customer proposition to hold?
Consider an illustrative travel example. A platform confirms a hotel booking today, but settlement with the supplier will happen months later in another currency. If the platform promises the economics of the booking at today’s point of sale, the hedge must remain connected to the booking amount, currency, timing and final settlement. If the booking is amended or cancelled, the financial position changes with it.
The infrastructure has to understand the financial relationship, not only the FX pair.
Pricing is only useful when it can become execution
A competitive quote is valuable only if it represents a price the product can actually execute under the required conditions.
Embedded products may need streaming prices, request-for-quote flows, API quotes or a combination. The correct model depends on transaction size, currency, tenor, market liquidity, operating hours and the customer experience being designed.
The same is true for instruments. Some flows may use spot. Others may require forwards, swaps, non-deliverable forwards or a combination. The requirement should come from the underlying customer exposure and settlement profile, not from whichever instrument is easiest for one provider to expose.
This is why evaluating an infrastructure partner only on displayed pricing can be misleading. The deeper question is whether pricing, executable liquidity and the required financial instrument remain connected as one operating flow.
Transaction-level hedging changes the operating model
Traditional corporate hedging often works with larger aggregated exposures reviewed on a defined cycle. Embedded hedging can behave very differently. A platform may generate many small customer transactions throughout the day, each creating a new piece of economic exposure.
That creates a design choice. Should each transaction be hedged individually? Should exposures be aggregated before execution? Should the system use a combination, preserving transaction-level state while executing aggregated market positions?
There is no universal answer. The right design depends on transaction count, average size, currency liquidity, spread economics, timing, cancellation behavior, credit capacity and the product promise made to the end customer.
What matters is that the infrastructure can preserve the connection between the customer transaction and the financial protection even when the execution model underneath is optimized differently.
Cancellations and amendments are part of the product
The original transaction rarely stays perfectly static. Travel bookings are cancelled. Marketplace orders change. Installment schedules move. Settlement dates shift. Refunds occur. A customer may settle early.
Each of those events can change the hedge requirement. A position that was correct at the moment of booking can become too large, too small or incorrectly timed later.
An embedded hedging system therefore needs a defined response to change. It must know what happened to the underlying transaction, whether the existing protection still matches it, which action is permitted by policy, and whether an adjustment should be executed automatically or raised as an exception.
This is where product reliability is won. The customer should experience a coherent service even when the financial state underneath becomes more complex.
Currencies and corridors expose infrastructure depth
It is relatively easy to make a product look complete when it operates only in the most liquid currency pairs and simplest settlement routes. The harder test appears when customers need additional currencies, emerging-market exposure or less standardized corridors.
Coverage then depends on more than adding another symbol to an API. The provider may need appropriate liquidity sources, local market access, the correct instrument, settlement capability, operating-hour coverage, funding arrangements and reconciliation for that currency or corridor.
A fintech expanding internationally should therefore ask not only, “Do you support this currency?” but also: how is it priced, what instruments are available, how is it executed, how does it settle, what funding or credit is required, and what happens when the normal path fails?
Those questions reveal whether currency coverage is a product label or a real operating capability.
Settlement is where the promise becomes real
A hedge is not complete because the price was accepted. The financial outcome still has to move through execution and settlement correctly.
Different flows may require T+0, T+1, T+2 or another settlement pattern. Some currencies or counterparties may require prefunding. Others may depend on credit limits. The source and destination of funds, settlement currencies, payment corridors and legal entities all affect the operating design.
For a customer-facing product, these details should remain behind the experience. But they cannot remain undefined behind the infrastructure. The platform needs clear responsibility for funding, execution status, settlement, failures and reconciliation.
If pricing is connected to execution but execution is disconnected from settlement, the product still has an operational gap.
Controls and reconciliation have to travel with the transaction
Embedded finance becomes fragile when the front end moves faster than the controls underneath it.
Every hedge should remain connected to the relevant transaction, customer, currency, amount, tenor, status and execution record. The system needs a reliable audit trail. Limits and permissions need to apply at the correct point in the flow. Exceptions need to be visible. Reconciliation needs to establish what was quoted, executed, settled, amended and completed.
This becomes increasingly important at scale. A product processing a high volume of small transactions cannot depend on teams manually reconstructing the financial position from provider portals, emails and spreadsheets.
The infrastructure should keep the state current so operational teams handle genuine exceptions instead of rebuilding ordinary transactions.
A practical infrastructure checklist
Before choosing the financial infrastructure underneath an embedded hedging product, define the operating requirements across the full lifecycle, not only the quote.
The core questions are straightforward: What customer transaction creates the exposure? What currencies and corridors matter? What is the typical time between quote and settlement? Which instruments are required? Is exposure hedged transaction by transaction, aggregated, or both? How material are cancellations and amendments? How is pricing delivered? How is execution performed? What settlement cycles apply? Is prefunding or credit required? How are failures, reporting and reconciliation handled?
If those answers are clear, the infrastructure scope becomes much easier to evaluate. If they are not, comparing providers on price alone is premature.
The best embedded product hides the depth without losing it
The end customer should not need to understand liquidity providers, forwards, settlement cycles or reconciliation. The experience should stay simple: a transaction is protected, the economics are clear, and the product behaves correctly when the underlying transaction reaches completion.
The fintech or platform should remain in front. It owns the customer experience, the product logic and the distribution. The financial infrastructure underneath should provide the depth required to make that promise operationally real.
Okoora is built for that underlying layer. It connects FX pricing, liquidity, execution, settlement, payments, accounts, controls and financial state so financial capabilities can operate inside the product rather than beside it.
Embedded hedging is not a pricing API. It is a financial operating system behind a very simple customer promise.
NEXT STEP Explore how Okoora can provide the financial infrastructure behind embedded FX and hedging products.
Explore how Okoora can provide the financial infrastructure behind embedded FX and hedging products.
Related reading: Why FX Pricing Alone Is Not Enough for Embedded Hedging.
