Can an AI Payment Router Save on Fees While Tying Up More Cash?

An AI payment router can make a transaction look cheaper while making the business harder to fund. The fee falls, the payment goes through, and the dashboard records an improvement. Meanwhile, more money sits in a currency balance that cannot pay tomorrow’s supplier. The transaction has been optimised; the business has acquired another cash constraint. 

As payment systems become more automated, this distinction deserves more attention. A route is not cheap simply because its quoted charge is low. Its value depends on when money must be available, where it must be held, and what the business can do with it afterwards. 

My experience building SharPay, and previously working in trading and brokerage, has made liquidity a practical business concern for me. Delayed settlements, disconnected providers and jurisdictional restrictions can separate receiving money from being able to use it. That separation should influence what we ask payment automation to achieve. 

The question is straightforward: can an AI router explain the cash consequences of the route it recommends? 

The fee is only part of the decision 

Consider an illustrative business paying suppliers in several currencies. One provider offers a lower transaction fee but requires a funded balance before execution. Another charges more but allows the business to fund the payment closer to the moment it is needed. Choosing the first provider may be sensible, especially if the balance is already available. 

But if that choice requires moving additional cash into a separate account, the comparison changes. The business may lose access to money it needs elsewhere, incur another conversion, or arrange funding earlier than planned. A saving on the payment can become an additional demand on the treasury. 

Prefunding itself is not an expense. The money remains an asset, and treating the entire balance as a cost would distort the decision. What matters is the incremental funding requirement, the time that cash is unavailable for other uses, and any financing or conversion costs the decision creates. 

That calculation also depends on what happens next. A funded balance that supports several scheduled payments is different from a balance left idle after one transaction. An intelligent recommendation needs to understand that difference before describing either route as the better deal. 

Look at the payment schedule, not just the transaction 

The harder problem is that payments rarely exist in isolation. A company can make a series of individually reasonable decisions and still end the week with too much cash in one currency and too little in another. The cheapest option for the next payment may increase the funding needed across the whole schedule. 

For an operator, this means looking beyond transaction scores. What balances will remain after the proposed payments? Which obligations fall due before incoming funds become usable? Will the recommendation require a transfer between providers that carries its own cost or timing uncertainty? 

These are ordinary commercial questions. AI should help answer them using reliable information about balances, expected receipts and provider conditions. Where that information is incomplete, a recommendation should show the uncertainty instead of presenting an apparently precise saving. 

The available choices must also be genuinely executable. A route with an attractive funding profile is irrelevant if it cannot serve the recipient, currency or jurisdiction. Those conditions belong in the comparison from the start. Otherwise, the system is ranking theoretical alternatives while the business still has to find a workable payment path for itself. 

Routing cannot rewrite the funding model 

Recent infrastructure work reinforces why the funding model belongs in this discussion. The BIS’s 2026 Annual Economic Report identifies reduced prefunding needs as a potential benefit of programmable settlement platforms. That is an infrastructure improvement; a router choosing between existing providers must still account for the funding conditions those providers impose. 

Businesses therefore need to distinguish what automation can improve through selection from what requires changes to the underlying payment arrangements. A better recommendation cannot remove a provider’s funding requirement simply by predicting transactions more accurately. 

Measure what happens to the cash 

I would want a payment recommendation to show three things together: the execution cost, the additional cash required, and the expected time until the resulting funds are usable. None is sufficient alone. Together, they give the person responsible for cash a decision they can assess. 

That does not mean every payment needs manual approval. It means the business should decide the boundaries before delegating execution. A route might be acceptable within an existing balance but require review when it calls for additional funding or leaves an important obligation exposed. 

The test should extend beyond whether the model selected the cheapest available transaction. Over a meaningful operating period, did the business meet its obligations with less unnecessary funding? Did it avoid accumulating unusable balances? Were the reported savings still present after conversion and funding costs? 

Those measures will not always produce a spectacular headline. Sometimes the better outcome is simply that a company can make the same payments while keeping more of its cash available. For a growing business, that can matter more than another small reduction in a quoted fee. 

AI earns its place in payments when it improves the decisions behind the movement of money. A lower fee is useful. A lower fee that quietly makes the business harder to fund is a result we should question.