Solver Rules & Logic

Overall aims:

Minimize net interest payments and transaction costs
Avoid speculation: Don't do anything that create unneeded FX risks (losses or gains from moving FX rates)
Avoid exceeding borrowing limits per bank

The 12 Corporate Treasury Guidelines

Same Currency-Netting

Example
Surplus EUR on one account and overdraft EUR on another account.
1
Do transfer between same-currency accounts freely.
Does not create FX risk.
2
Do transfer between same-currency accounts before performing any FX trades.
Prioritizes cost-free liquidity over market transactions.

Structural Surpluses or Deficits

Example
Accumulated a positive foreign currency balance (for example PLN) we don't need due consistent positive future cash flow in that currency.
3
Do not hold a surplus foreign currency balance just to earn a high interest rate.
Maintains risk that the foreign currency decreases in value.
4
Do sell surplus foreign currency to cover structural deficits in other foreign currencies.
Minimizes net exposure across the portfolio.
5
Or, do sell surplus foreign currency to repay debt in the home currency.
Minimizes risk and reduces interest expense.
Example
Accumulated a negative foreign currency balance (for example SEK) that we don't think we will cover by a positive future foreign currency cash flow.
6
Do not keep a foreign currency balance negative just because it is 'cheap funding.'
Maintains risk that the foreign currency increases in value.
7
Do buy foreign currency using structural surpluses in other foreign currencies.
Uses existing liquidity to neutralize risk.
8
Or, do buy foreign currency using home currency.
Minimizes risk on foreign currencies.

Timing Mismatches Based on a Forecast

Example
Borrowing in NOK but expect an incoming NOK payment in 5 days covering the borrowing. Have positive USD cash in the period, but expect an equivalently large payment in USD in 5 days. In reality, this is a very rare scenario.
9
Do not perform a spot trade to cover a temporary gap if you must reverse the trade later.
Bets that the FX rate won't move; by the second transaction, the market may have moved against you.
10
Do use an FX Swap to bridge a forecasted gap, matching the swap duration to the cash flow.
Covers the liquidity hole without creating a position exposed to moving FX rates.
Example
Borrowing in NOK but expect an incoming NOK payment in 5 days covering the borrowing. Don't have 'timing mismatch' positive balances in other foreign currencies.
11
Do not use an FX swap between two foreign currencies unless there is a matching timing mismatch in both.
Swapping two foreign currencies without matching offsets creates unnecessary secondary risk.

Carry Trade

Example
Borrowing rate in DKK is 3%, deposit rate in PLN is 5%.
12
Do not trade to take advantage of interest rate differentials; trade only for actual operational needs.
This is pure speculation; a small move in the FX rate can wipe out an entire year of interest earnings.

How the Solver Covers These Rules

Cost Minimization (Rules 1, 2, 4, 5, 7, 8)

The solver’s objective function minimises the total net financial cost: interest paid − interest earned + transaction costs + FX spreads + RCF costs + speculation penalties. This naturally drives the solver towards cost-optimal decisions.

Same-currency netting is always preferred because its variable cost (Variable_Cost_Same_CCY) is orders of magnitude lower than the FX spread (FX_Spread_Percentage). The solver will exhaust all same-currency netting opportunities before turning to FX trades.

Interest rates are modelled exactly per account, using Risk_Free_Rate + Borrowing_Margin for overdrafts and Risk_Free_Rate − Deposit_Margin for surpluses. This ensures the solver never moves money to a worse-rate account just to “balance” positions.

Example: Acc_Low earns 5% on deposits, Acc_High earns only 1%. Even though both are in the same currency, the solver correctly decides not to transfer surplus from Low to High, because it would destroy 4% of interest income.

Horizon edge effect: On the final day, all interest expressions are multiplied by Terminal_Penalty_Multiplier to approximate carry beyond the forecast. This prevents the solver from leaving offsetting positions in the same currency (e.g. −9M NOK in one account, +9M NOK in another) — they would net to zero in base currency but quietly bleed the borrow/deposit spread forever.

Anti-Speculation Penalty (Rules 3, 6, 12)

Holding a non-safe currency position is FX risk: the balance’s value in your base currency moves with the exchange rate. The solver charges Anti_Speculation_Penalty_Rate per day on the portion of any position it builds on top of what the forecast already shows. The charge is symmetric — a positive balance (long the currency) and an overdraft (short the currency) are treated the same way. On the last day of the horizon the charge is scaled by Terminal_Penalty_Multiplier so the solver cannot leave open positions sitting at the end.

What “baseline balance” means. The baseline balance is the balance your account would have each day if the solver made no transactions — the opening balance with the forecast’s receipts and payments applied as they fall due. It’s one number per day, not a single value for the whole horizon, and it naturally carries any starting position forward until a flow changes it.

For example, a NOK account that opens at +5M and has a 15M NOK payment scheduled on Day 5 has this baseline:

Day 0: +5M Day 1: +5M … Day 4: +5M Day 5: −10M Day 6: −10M … Day 14: −10M

The rule: keep only what’s offset, never build on it. An existing position is exempt only as far as a future flow in the same currency will naturally close it. Two independent checks, one for each side:

• Long side. A positive baseline is exempt up to the amount future outflows will draw it down. A “future outflow” here means the baseline dipping below its current level. If nothing in the forecast consumes the position, it’s an open FX bet and must be liquidated. Pre-funding (buying more than the baseline already shows) is always blocked.

• Short side. A negative baseline (overdraft) is exempt up to the amount future inflows will close it. If the forecast doesn’t show the baseline rising back, the overdraft isn’t offset and must be cleared. Pre-selling (deepening the overdraft beyond the baseline) is always blocked.

Concretely, for each day t the solver compares that day’s baseline against the lowest and highest baseline values on any day from t onward:

long ceiling(t) = max(0, baseline(t) − max(0, min future baseline from t))
short ceiling(t) = max(0, −baseline(t) − max(0, −max future baseline from t))

In words: the long ceiling is how much of today’s positive balance gets eaten by future dips; the short ceiling is how much of today’s overdraft gets erased by future rises. Anything the solver holds beyond those ceilings is speculative and charged the daily rate.

Other specifics.

• Safe currencies (marked Is_Safe in currency settings) are exempt entirely. This covers your base currency (the risk-free anchor) and any hub currencies you designate as safe.

• FX swaps are ignored when judging speculation. A swap’s cash flows reverse within its own term, so only the permanent, non-swap component of a position is assessed.

Example — existing balance offset by future outflow. NOK baseline is +5M on Day 0, stepping down to −10M on Day 5 after a 15M payment. On Day 0 the baseline is +5M and the min future baseline is −10M — the +5M will be fully consumed, so the long ceiling is 5M and holding the +5M is exempt. On Day 5 the baseline is −10M and the max future baseline is −10M (flat); short ceiling is 10M, overdraft exempt.

Example — existing balance with no offset. NOK baseline is +5M flat across the horizon (no future outflows). On every day the long ceiling is max(0, 5M − 5M) = 0. Holding the +5M is penalised as a standing FX long — the solver should sell it back to base currency.

Example — pre-funding blocked. A 15M NOK payment is due on Day 5; baseline is 0 today. On Day 0 the baseline is 0, so the long ceiling is 0. Buying 15M NOK on Day 0 creates a +15M position entirely above the ceiling — penalised for five days. The solver waits and converts on Day 5, when the −15M baseline is itself exempt as an overdraft.

Example — pre-selling blocked. A 15M NOK inflow lands on Day 5; baseline is 0 today. Going −15M NOK on Day 0 would be a manufactured overdraft above the 0 short ceiling — penalised. The solver waits for the inflow.

Example — overshoot. GBP runs at −12M throughout the horizon. Converting DKK to bring GBP to 0 is fine. Converting further to +3M GBP puts a +3M long on top of a 0 long ceiling (baseline is negative, not positive) — the +3M is penalised as speculation.

Wash Trade Protection (Rule 9)

A sliding window constraint prevents the solver from moving money in one direction between two accounts and then reversing it within Wash_Trade_Window_Days days. This applies to all movement types: FX Spots, FX Swap legs, and same-currency transfers.

How it works: For every pair of accounts (A, B), if any movement A→B occurs on day t, then all movements B→A are blocked on days [t, t + window]. The reverse also applies: B→A on day t blocks A→B for the same window.

Swap Exception: A swap’s own reversal leg is excluded from the window check. If a swap sends PLN→EUR on Day 0 and reverses EUR→PLN on Day 11, the far leg is not blocked by the near leg — they are part of the same trade.

Example — Blocked: With a 4-day window: the solver sells 5M SEK→DKK on Day 0. It cannot buy SEK back (DKK→SEK) until Day 5 at the earliest. This prevents pointless round-tripping that wastes transaction costs.

Example — Allowed: Sell SEK→DKK on Day 0, then buy SEK (DKK→SEK) on Day 7. The 4-day window has passed, so a new trade in the reverse direction is permitted.

FX Swaps & Overlapping Trade Ban (Rule 10)

FX Swaps bridge short-term timing mismatches by temporarily exchanging one currency for another and reversing on a future date. The solver models this with a Near Leg (Day t) and a Far Leg (Day t+k), where k is the swap tenor in days.

Directional Overlap Ban: While a newly proposed FX Swap is active for a non-safe account, the solver is blocked from initiating contradictory positions in that same currency. Specifically, you cannot sell a currency that you have bought via a new swap for the duration of that swap (and vice versa).

Solver-Proposed ONLY: This restriction applies strictly to new transactions proposed by the solver. It does not prevent the solver from proposing a spot to “correct” an Existing FX Swap if the underlying forecast has changed since that trade was confirmed.

Example — Blocked: The solver proposes a EUR⇔NOK swap starting on Day 0. It cannot also propose a NOK→SEK spot on Day 0 or Day 7, because that would be “selling” the NOK it just “bought” via the swap.

Example — Allowed: You have an active NOK⇔EUR swap booked in Deals. The solver sees that NOK is now over-hedged due to a forecast drop. It is permitted to propose a new NOK→SEK spot to offset the existing position.

RCF Integration & Funding

Revolving Credit Facilities (RCFs) are fully integrated as an alternative funding source. The solver can draw from RCFs to cover deficits, and the cost is modelled as Risk_Free_Rate + Interest_Margin on drawn amounts, plus a Commitment_Fee on the undrawn portion of the facility.

Constraints: RCF draws are subject to a Limit Amount (maximum outstanding at any time) and Max Utilisations (maximum number of active tranches simultaneously). The solver automatically rolls over maturing RCF tranches when beneficial.

Settlement: RCF draws settle into the designated Settlement Account for each facility. The solver chooses between RCF drawdowns and FX trades purely based on which minimises total cost.

Example: On Day 3, a 215M DKK RCF tranche matures. The solver repays it and immediately re-draws 542M DKK at the same rate, rolling the facility to cover the upcoming cash needs. This is cheaper than selling foreign currency and paying FX spreads.

Example: The solver needs 50M EUR. It compares: (a) draw from the DKK RCF at 4.85% and convert DKK→EUR, vs. (b) leave the EUR overdraft at 3.9%. If the RCF route’s interest + FX spread exceeds the overdraft cost, it chooses the overdraft.

Overdraft Funding Restrictions (Rule 11)

The solver is explicitly banned from opening FX Spots or FX Swaps if the source account is in overdraft, unless the source currency is marked Is_Safe. This prevents the solver from funding speculative FX trades by deepening an overdraft in a volatile currency.

How it works: For each FX trade, the solver checks if the source account has a negative balance on that day. If it does, the trade is blocked. Technically, this is enforced by constraining the overdraft component (neg_bal) to be zero whenever a trade binary is active: neg_bal ≤ M × (1 − trade_binary).

Safe Currency Exemption: Any currency marked Is_Safe in your settings is exempt. It is acceptable for the solver to run an overdraft in your base currency to fund an FX spot, because there is no FX risk on the base currency.

Example — Blocked: An account in a non-safe currency has a negative balance. The solver cannot initiate an FX swap from this account because it would be funding FX exposure with borrowed foreign currency, creating double risk (FX + interest).

Example — Allowed: An account in your base currency has a negative balance. The solver can still initiate an FX spot from it because the base currency carries no FX risk — the overdraft is funded at the known bank rate.

Structural Account Restrictions

Non-hub accounts (those with currencies not marked Is_Safe) are constrained to be either strict Receivers or strict Senders of FX Spots over the entire horizon. The solver creates a binary variable per account that locks its FX direction for all days.

Why: Without this rule, the solver could use non-hub accounts as intermediary hubs — buying FX into a foreign currency from one source and selling it to another. This creates unnecessary FX exposure and transaction costs that a senior treasurer would never approve.

Hub Exemption: Accounts in currencies marked Is_Safe are exempt because they naturally act as liquidity concentrators — they receive from some accounts and distribute to others.

FX Swaps: While swaps are generally exempt from the multi-day directional lock (allowing an account to both receive and send currency over time), they are strictly subject to the Overlapping Trade Ban (Rule 10) to prevent simultaneous contradictory trades.

Example — Blocked: A non-safe currency account receives an FX Spot inflow. The same account cannot also execute an FX Spot outflow at any point in the horizon. It must remain a “Receiver” of FX Spots for the entire period.

Example — Allowed: An account in a safe currency receives FX from one currency and sends FX to another. Safe-currency accounts can act as concentrators freely.

Baseline Surplus Validation

Prevents “buy-and-swap” patterns where foreign currency is purchased solely to route it through a swap for profit, rather than to cover a genuine operational need. It uses the baseline forecast (before any solver decisions) to determine whether a non-safe currency has genuine surplus:

FX Spot Outflows: Blocked entirely if the minimum future baseline balance for the currency (from day t to the end of the horizon) is negative. If the currency is forecasted to go into deficit at any point in the future, no permanent FX outflows are allowed — the solver should hold the balance to cover the coming deficit, not sell it.

FX Swap Near Legs: Unlike spots, swaps are temporary and self-reversing. A swap is exempt from this validation if the baseline balance stays non-negative during the active days of the swap tenure (from near leg up to, but not including, the far leg). This means a genuine temporary surplus can be deployed via a short-term swap. However, the swap volume is capped at the minimum baseline balance during the active tenure — you can only swap what you genuinely have, preventing a trivially positive baseline (e.g. +1 unit) from unlocking a full-size swap.

Example — Blocked: A non-safe currency baseline is always negative. The solver cannot buy that currency via spot and immediately route it through an FX swap, because the baseline never supports outflows.

Example — Allowed: A non-safe currency has a genuine +5M surplus for 7 days before turning negative. A 5-day swap deploying up to 5M is allowed because the baseline stays positive during the entire swap tenure.

Weekend & Settlement Restrictions

The solver respects standard banking settlement conventions. No new transactions (transfers, FX spots, FX swaps, or RCF draws) can be initiated on Saturdays or Sundays. All decision variables for weekend days are forced to zero.

This means a deficit that arises on a Friday can only be addressed on the preceding Friday or the following Monday. The solver accounts for this automatically when planning across the horizon.

Transaction Size Limits

Every transaction proposed by the solver is subject to a minimum (Min_Transaction_Amount) and maximum (Max_Transaction_Amount) size, both configured in your settings and denominated in the base currency. These apply to same-currency transfers, FX spots, FX swaps, and RCF draws alike.

Practical effect: Netting opportunities or funding gaps smaller than the minimum will be left untouched — the solver considers them too small to justify the operational overhead of executing a transaction. Similarly, very large movements are split or capped at the maximum to reflect real-world settlement limits.