Managing Treasury in Regulated Payments Businesses

Managing FX exposure

The accumulation problem

Every RPB that facilitates FX transactions accumulates exposure between the moment a trade is confirmed with a client and the moment it is covered in the market. For a firm transacting a handful of trades each day, this risk is manageable through manual oversight. As volume grows across multiple currency pairs, trading channels and client segments, the aggregate open position can build quickly, and even modest adverse rate movements can translate into material P&L impact.

The starting point is real-time visibility: a single, consolidated view of net and gross exposures across every currency pair the firm operates in, updated continuously as new trades flow in. In practice, many RPBs rely on a fragmented set of systems — a trading platform here, a payments system there, a spreadsheet to tie it all together — that make the true aggregate position hard to see at any given moment.

The risk of operating without real-time visibility is not theoretical. A treasury team that cannot see its position cannot manage it, and intraday market moves do not pause to allow end-of-day reconciliation to catch up.

Setting and enforcing limits

Visibility on its own is not sufficient. RPBs need a structured limit framework that defines, in advance, the maximum exposure the firm is prepared to tolerate in each currency, in each tenor bucket and in aggregate. Limits should be calibrated to the firm's risk appetite, its hedging capacity and the liquidity of the currencies it trades. A major pair such as EUR/USD can generally support a higher limit than a thinly traded pair such as USD/KES or EUR/PHP, where covering a position at short notice can be costly.

Often neglected is the governance around limit-setting itself. Markets evolve, volatility regimes shift and client flow patterns change, so a limit that was appropriate twelve months ago may be materially too loose or too tight today. RPBs should build a formal review cadence into their treasury governance, stress-testing limits against historical volatility events and reviewing them at an appropriate level of seniority — at least annually, and immediately on any material change in product mix, client base or market regime.

Auto-cover and hedging logic

For most RPBs, FX exposure is managed through a combination of periodic manual hedging and rule-based automatic hedging, commonly called auto-cover: when a trade, or an aggregate position, takes exposure in a currency to a defined threshold, the system automatically executes a corresponding hedge in the wholesale market. Well-designed auto-cover logic answers four practical questions:

• What triggers a hedge? Notional size alone, or also current market volatility and time of day?
• Cover or net? Should each large trade be covered individually, or several trades netted before going to market to reduce costs?
• What about illiquid sessions? How should auto-cover behave when even normal-sized trades carry elevated gap risk?
• How is it reconciled? How are cover trades tied back to the client trades that generated them, for P&L attribution and audit?

The right answers differ by firm and currency corridor, but documenting, testing and regularly reviewing this logic is non-negotiable. Auto-cover is only as good as its configuration, and a rule set calibrated for one volume profile can quickly become inappropriate as the business grows. Dealers and Risk should be able to see why a trade was auto-covered and reconstruct the decision chain after the fact.

Spread configuration as a risk tool

Treasury spreads — the margin between the mid-market rate and the rate offered to clients — are a source of revenue, but also a primary tool for managing risk. Too tight, and the spread may not cover the cost of hedging, particularly in volatile conditions or in pairs with wide wholesale bid-offer spreads. Too generous, and it damages competitiveness and pushes clients to alternative providers.

Effective spread management starts from the true cost of hedging each pair — the interbank bid-offer, settlement costs and an allowance for market impact on larger trades. Spreads also need monitoring after the fact: persistent slippage between expected and realised spreads in a pair usually means either the calibration is off or value is being lost in the cover process — through a slow LP, a delayed booking or a routing inefficiency — and warrants investigation.

Settlement and liquidity management

The invisible risk

If FX exposure is the most visible risk in an RPB's treasury, settlement liquidity risk is often the least visible — right up until it becomes a crisis. It arises whenever the firm has insufficient funds in a currency account to meet its payment obligations on a given value date. In the worst case, the consequences are failed payments, frustrated clients, regulatory scrutiny and reputational damage that is hard to recover from.

Settlement obligations are not always predictable. Client flow can be lumpy, correspondent bank cut-off times are unforgiving, and inbound receipts do not always line up with outbound payments. Managing this demands both forward visibility and operational discipline.

Building the settlement ladder

The most important tool is a multi-day settlement ladder: a currency-by-currency, date-by-date view of all confirmed payables and receivables for at least the next three to five business days. It gives the treasury team advance sight of where shortfalls may arise, so they can act early — drawing on a credit line, accelerating an inbound payment or adjusting pre-funding — before a problem materialises.

The ladder needs to distinguish between value dates (T+0, T+1 and T+2 being the most common) and should include cut-off times for each currency corridor. USD payments through CHIPS and Fedwire, GBP payments through CHAPS, and EUR payments through T2 (the ECB platform that replaced TARGET2) each have specific intraday windows that decide whether a payment settles on the intended value date. Missing a cut-off pushes a payment to the next business day, with knock-on effects for client expectations and the firm's own liquidity planning.

Scenario capability is also valuable. Running these regularly builds a culture of proactive liquidity management rather than reactive firefighting:

Nostro management and pre-funding

For most RPBs, settlement obligations are met through a network of nostro accounts held with correspondent banks in each currency the firm operates in. Managing them well is both an art and a science.

The optimal approach sets minimum balance thresholds for each nostro based on expected daily settlement needs, with a buffer for intraday volatility, and a clear process for sweeping surplus balances back to a central treasury currency regularly. Firms with strong correspondent relationships can also negotiate intraday credit facilities as a safety valve, though these should be a backstop, not a substitute for sound pre-funding discipline.

Safeguarding: the regulatory dimension

For most RPBs, settlement liquidity management carries an extra regulatory dimension: client fund safeguarding. The specifics vary by jurisdiction, but the principle is consistent across major regimes. A firm holding client money for payment or e-money services must keep those funds separate from its own working capital, and be able to show at all times that safeguarded balances are enough to meet outstanding client obligations.

The common operational requirement

Across all of these regimes, regulated RPBs must:

• Segregate client funds from their own money
• Hold them in designated accounts or qualifying liquid investments
• Reconcile regularly, typically daily, to confirm the safeguarded amount matches outstanding client obligations

This places a structural constraint on how an RPB can use client balances. Unlike a bank, which can deploy customer deposits as part of its own balance sheet, an RPB must ring-fence client funds and keep clear documentation of the safeguarding calculation at all times. Errors here — even administrative oversights rather than deliberate misuse — can be regulatory breaches with material consequences.

For firms operating across several jurisdictions, the challenge multiplies. A global RPB may face overlapping but non-identical requirements in each market, with different definitions of client money, of a qualifying safeguarding arrangement, and of how reconciliation evidence must be documented. The operating model should be designed to meet the strictest applicable requirement in each currency and entity, not the most convenient one.

Treasury, finance and compliance have to work together

Firms that treat safeguarding as a compliance exercise rather than an operational discipline tend to accumulate timing gaps, rounding errors and undocumented edge cases that become significant issues under regulatory scrutiny.

Building the right foundation

Across both FX exposure and settlement liquidity, effective treasury management in an RPB is only as good as the systems, processes and governance behind it.

For growing RPBs, the temptation is to defer investment in treasury infrastructure until the business is larger. The risk is that by the time the volume justifies it, the operational and regulatory exposure from inadequate controls has already built up. The firms that manage treasury best build the framework early, scale it deliberately, and treat it as a competitive advantage rather than a cost centre.

Equally important is the choice of technology partner. The right platform turns treasury from a reactive function into a strategic capability — surfacing exposures in real time, enforcing limits consistently, and converting settlement data into actionable intelligence for day-to-day operations and longer-term commercial decisions. The wrong one creates brittle workflows, manual workarounds and blind spots that compound as the business grows. Selecting a partner with deep domain expertise in FX and payments operations, a proven track record at scale, and a roadmap aligned with the firm's own growth is one of the most consequential decisions a treasury function will make.

Frequently asked questions