← Insights
Enterprise software3 min

Why African fintechs pay twice for foreign treasury software

The licence is quoted in dollars. The second payment is the one nobody budgets for: a support queue eight hours away, and a roadmap set on another continent.

Ziklag Software Services·26 August 2026

A Nigerian bank buying a treasury management system pays for it twice. The first payment is visible: a licence quoted in dollars, renewed annually, revalued every time the naira moves. The second payment is spread across the years that follow, and no procurement process captures it.

The first invoice is the honest one

Foreign enterprise platforms price in the currency of the vendor's cost base, which is reasonable from the vendor's side and ruinous from the buyer's. A licence agreed at one exchange rate is renewed at another. The finance team budgets in naira; the contract settles in dollars; the gap between them is absorbed by whichever department is least able to argue.

That much is at least legible. It appears on a line item, it can be forecast badly, and someone owns it.

The second invoice is paid in time

The costs that do not appear on the contract are the ones that accumulate. Support arrives from a timezone where the working day begins as yours ends, so a Tuesday incident becomes a Wednesday resolution. Configuration that should take an afternoon takes a change request, a queue position, and a professional-services rate.

More expensive still is the roadmap. A local regulatory change, a new instrument, an unusual approval chain — these are edge cases to a vendor serving thirty countries, and they are the whole business to you. You wait, or you build a workaround beside the system you already paid for.

Every workaround is a decision to maintain two systems while paying for one.

What has to be true for a local alternative

Price is not an argument on its own. A locally built platform has to match the incumbent on capability before cost enters the conversation at all, and in treasury that bar is specific: SWIFT MT and MX, configurable approval workflows, fine-grained access control, full audit trails, end-of-day processing that completes inside the operational window.

When we built Falcon Treasury Suite with Aristack, none of those were features to be phased. They were the price of being considered. The workflow engine had to let an institution model its own approval chain rather than adopt ours. SWIFT message rules had to be editable by the business, not by a template file and a redeployment. The end-of-day engine had to run a systemwide valuation in under ten minutes because the operational window does not stretch.

Ownership is the part that compounds

The argument for building locally is not that local engineers are cheaper. It is that the distance between the people who use a system and the people who can change it collapses to nothing. A question asked in the morning is answered in the morning. A regulatory change is a sprint, not a roadmap submission.

That only holds if capability transfers with the software. Aristack's engineers now maintain, extend and sell Falcon Treasury Suite as SaaS to banks and financial institutions across West Africa. We spent a little over a year making that true, and it is the only outcome that makes the first argument durable.

The question to ask before the renewal

Not "what does this licence cost" but "what does it cost us to change this system". If the answer is a change request, a queue and a dollar rate, you already know which invoice is larger.

Enterprise software