FX Risk Management Solutions: What Each Category Can Own, and What Has to Pass Between Them

Search the term and the results describe at least five different businesses. The United States results reviewed for this guide put a bank’s treasury content, a registered swap dealer, a payments company, a treasury platform and two specialist software products on one page, all using the same three words. Each describes a real product. None of them describes the same part of the work.

They are not substitutes. A supplier whose record starts at the deal ticket cannot own the exposure that justified the deal, and a supplier that aggregates exposure does not become the counterparty to the trade. So the question is not which product is best. It is which part of the workflow each category can own, and what evidence has to pass between them.

What the term covers, and the five categories it collapses

FX risk management solutions is a market label rather than a product category. It covers any software or service a company uses to identify currency exposure, decide what to do about it, act on that decision, and produce the accounting and control evidence afterwards. The underlying workflow is stable: capture exposure, forecast it, separate transaction from balance-sheet exposure, net it, apply policy, set the hedge ratio, price against market data, obtain approval, execute, confirm, value, hand the result to accounting, test it against limits, report it and control it.

No single category owns that whole chain by default. The five below divide it. One supplier can appear in more than one row, which is a reason to read the contracted scope rather than a reason to merge the rows.

Automation is worth keeping out of this list. It is a method applied to any of the five, not a sixth family, and the same distinction applies here as in the wider question of where treasury automation stops being a product category.

Exposure capture decides which category can own the programme

Start with where the exposure already exists, because that determines what a product has to reach into before it can claim the programme. Three records behave differently and are often owned by different teams.

Three exposure records, three different owners

Transaction exposure is committed and already in a system: receivables, payables, purchase orders and contracted commitments. It is the easiest to capture and the easiest to over-count, because the same order can appear as a commitment and again as an invoice.

Balance-sheet exposure is the monetary position that gets remeasured or translated at period end. It is an accounting output, not a treasury instruction, and confusing the two is a common source of double hedging. How remeasurement and translation actually work in the ledger sits with the accounting system rather than with any FX product.

Forecast exposure is not yet in a ledger at all. Its quality depends entirely on the forecasting process behind it, which is why a hedge programme built on a forecast produced under stated process controls is testable and one built on a spreadsheet extract is not.

Suppliers state where they start. Kantox describes exposure captured automatically from the ERP, TMS or other company systems, and Kyriba states that its API integrates with major ERP systems and trading platforms including FXall, 360T and Bloomberg. Hedgebook describes software for recording, reporting and independently valuing FX, interest-rate and commodity instruments, with no execution claim on the page. Those are three different starting points, all company-stated, and each implies a different amount of work left with the buyer.

Netting changes the requirement before it changes the product

Netting reduces what has to be hedged, so it belongs before the product decision rather than inside it. Two different operations share the word. Exposure netting offsets opposite positions in the same currency and horizon so a smaller residual is hedged. Settlement netting reduces the number of payments that actually move.

The second can be a banking-structure decision rather than a software one. J.P. Morgan describes virtual accounts for intercompany settlement, stating that netting offsets internal transactions and allows cashless settlement of intercompany balances, with reduced FX exposure and hedging cost among the stated results. Whether that structure is right is closer to the cash-pooling and in-house-bank structure decision than to FX product selection, and it should be settled first, because it changes the residual exposure every later category is sized against.

Policy, limits and hedge ratios stay with the company

The clearest statement of this comes from a bank rather than from a software supplier. Bank of America’s corporate treasury guidance puts the first steps with the company: identify and measure your risk and decide whether you want to mitigate it, then implement measurable policies aligned to business objectives. The bank’s own contribution in that framework is analytics, execution and reporting. The operating policy, appetite, limit and approval chain sits in the treasury risk management framework; this page begins with the category and handoff decisions needed to execute it.

So the requirement is not that a product sets policy. It is that a product can hold the policy as data and act on it: exposure types in scope, entities and currency pairs covered, horizon, authorised instruments, approval thresholds and limits. The hedge ratio is an output of that policy, and no product should select it silently during configuration. The system records the designated ratio, applies it consistently, and shows every instance where actual coverage departed from it with the approval attached.

Test this directly. Ask a supplier to show a limit breach: the rule as written, the exposure that triggered it, who was alerted, who approved the exception and what the position looked like before and after. A product that can only display current utilisation is a reporting tool, not a control.

Market data and valuation: who owns the curve and who owns the mark

Two separate questions hide behind the word valuation. The first is which rates and curves the company treats as authoritative, and the second is who produces the mark on an open position.

Suppliers document both. ION states that Reval provides market data covering more than 900 curves, delivered cleansed and validated daily. Kyriba describes independent mark-to-market valuations supported by integrated market data. Hedgebook positions its valuations as independent as well. The word independent is doing real work in those claims: it distinguishes a mark produced by the risk system from a mark supplied by the institution that sold the trade.

The buyer decision is a control decision, not a preference. Name one source of record for each curve, fix the valuation time, and require that the system store the inputs used for each mark rather than only the result. If a valuation cannot be reproduced from stored inputs six months later, the accounting built on it cannot be defended either.

Approvals, execution and confirmation evidence

This is where the categories separate most sharply, because execution carries a legal identity that software does not.

StoneX describes hedge strategy advisory alongside FX forwards, options and structured products, and discloses that StoneX Markets, LLC is a National Futures Association member provisionally registered with the CFTC as a swap dealer. Xe presents forward contracts, limit orders and structured options products for business customers under an NMLS identifier. Those are counterparty and payment-provider identities, and the positions they hold are the positions done with them.

A risk platform sits on the other side of that line. Kantox describes connecting to a company’s own preferred liquidity partners and multi-dealer platforms such as 360T, FXGO and FXall rather than becoming the dealer. MillTech describes multi-bank ISDA set-up and agency execution through its platform, which is a third position again: the execution is carried out for the client rather than by the client or against the provider’s own book.

Read that as a coverage question. A platform that is also the counterparty shows the whole programme only when the whole programme is traded with it. A platform that routes to the company’s existing banks can hold the whole programme but depends on those banks for confirmations, credit and settlement. Either way the trail has to arrive back in a usable form, which makes the bank-connectivity states a confirmation has to survive part of the FX requirement rather than a separate project.

The accounting handoff

Hedge accounting is a distinct category with its own product decision, and this guide does not attempt it. What belongs here is the handoff: what the FX side has to produce so that the accounting side can do its work.

That package is specific. The hedged item identifier, the designation date and documentation, the designated ratio, the effectiveness method, the executed trade with its economic terms, the valuation with its inputs, and any de-designation or rebalancing event. If the exposure system and the accounting system hold different identifiers for the same hedged item, the designation cannot be evidenced later without manual reconciliation.

The applicable rule set also changes what has to be produced. IFRS 9 has applied to annual periods beginning on or after 1 January 2018, and the IFRS Foundation records that an entity may choose as an accounting policy either to apply the IFRS 9 hedge accounting requirements or to continue applying those in IAS 39. Settle that choice before evaluating anything, then take the designation, effectiveness and journal evidence a hedge-accounting system produces as a separate requirement with its own product map.

Reporting, controls and the audit trail

Reporting for this workflow has one demanding property: a reviewer should be able to replay a decision. That means reconstructing the exposure as it stood at the time, the rule that applied, the approval given, the trade executed, the confirmation received and the mark used, without asking anyone to remember anything.

Suppliers state parts of this. Ripple Treasury, which the product pages now show as the current identity of GTreasury, states built-in audit trails and transparent reporting across FX, interest-rate and credit risk. A statement of that kind is a starting point for a demonstration, not a substitute for one. Ask for the replay on a real month, including a trade that was amended and one that was cancelled, because exceptions are where most trails break.

Segregation matters as much as content. Whoever captures the exposure, approves the hedge and confirms the trade should be distinguishable in the record, and where an advisory or managed-service provider performs one of those roles, the record has to show whose decision each one was.

Integrations: the evidence that has to move

Once the categories are separated, integration stops being a technical checkbox and becomes a list of records with required fields. This is the part of the requirement most worth writing before any demonstration, and it fits the wider pattern of how finance systems hand records to each other.

Product map by category, based on official documentation checked 26 August 2026

The map below records documented scope from official supplier pages opened on 26 August 2026. It classifies scope, not quality, and one supplier can appear in more than one category. Official pages establish what a company states about its own product. They do not establish contracted modules, bank or geographic coverage, control effectiveness, price or fit.

These entries are not a ranking, a shortlist or a recommendation. One change is worth noting for anyone working from older material: GTreasury product pages now resolve to Ripple Treasury and carry that identity, checked 26 August 2026. The wider question of whether to buy a suite module or a specialist product is the same one set out in the suite-versus-specialist boundary test.

UK differences that change the buying decision

Most of the workflow above is jurisdiction-neutral. Four differences are not, and each changes either which supplier can be bought or what evidence the systems must produce.

Reporting responsibility differs. Under UK EMIR the FCA states that a financial counterparty is solely responsible and legally liable for reporting on behalf of both counterparties for OTC derivative contracts concluded with a non-financial counterparty not subject to the clearing obligation, with the non-financial counterparty required to supply the data. Reporting requirements for new and modified trades changed on 30 September 2024. In the United States the Treasury determination published on 20 November 2012 exempted FX swaps and forwards from the swap definition, and the determination records that trade-reporting requirements, business conduct standards and anti-evasion requirements continue to apply. A UK corporate is often supplying data to a counterparty who reports; a US corporate is more often looking at reporting obligations attached to the instrument.

Instrument classification differs. The FCA’s guidance sets out when an FX forward is not a MiFID financial instrument: broadly, where it is a means of payment facilitating identifiable goods, services or direct investment, is physically settled, is not traded on a trading venue, and at least one party is not a financial counterparty. The same guidance fixes the spot boundary at two trading days for major currency pairs. That test sits behind which providers may offer which contracts to a UK buyer.

Instrument scope of the US exemption is narrower than it first appears. The determination covers FX swaps and forwards only. The CFTC records that foreign currency options, non-deliverable forwards, currency swaps and cross-currency swaps remain subject to the Commodity Exchange Act. If a programme moves beyond plain forwards, the reporting evidence requirement moves with it.

The accounting rule set differs for non-IFRS UK entities. UK companies reporting under FRS 102 rather than IFRS are inside the Financial Reporting Council’s Periodic Review 2024, which the FRC states is effective in most cases for accounting periods beginning on or after 1 January 2026, with the revised Section 12 hedge accounting requirements built on an IFRS 9 basis. Combined with the IFRS 9 policy choice noted earlier, three regimes are live at once. Confirm which one applies to each reporting entity before asking any supplier what it supports.

How to run the evaluation

The sequence matters more than the scorecard, because most of these decisions are made irreversibly during configuration rather than during selection.

1. Write the exposure inventory first: entity, currency pair, exposure type, source system, current owner and current method. Do this before contacting any supplier.
2. Decide which category owns each step of the workflow, and write the answer down. Where two categories could own a step, name the authority.
3. Write the handoff table from the section above as a requirement, with fields, frequency and direction.
4. Settle the accounting rule set and the netting or in-house-bank structure, since both change the residual exposure and the evidence required.
5. Only then shortlist, and score against demonstrated evidence rather than stated capability.

Three demonstration scripts separate documentation from behaviour. Ask for a net exposure decomposed to its source documents, including one excluded and one disputed item. Ask for a limit breach replayed end to end with the approval attached. Ask for a valuation reproduced from stored inputs on a past date. If the wider platform question is also open, what a treasury management system is expected to own sets the scope those demonstrations should be measured against.