The conversation in African payments almost always starts with cost - fees, FX spreads, transfer charges. I want to talk about something the industry rarely measures: what happens to your payment after you send it, when nobody can tell you where it is.

When I started building Jenzy, I thought the hard problems would be licensing, FX access, and banking relationships. They are hard. But the problem that kept surfacing - the one that made customers genuinely frustrated, that strained supplier relationships and stalled shipments - was not cost. It was uncertainty.

Not payments that bounced cleanly. Payments that went somewhere and stayed there.

On African trade corridors - Nigeria to China, Kenya to India, Ghana to the UAE - a meaningful proportion of transactions do not complete on time. They get caught in compliance screening at a correspondent bank, flagged by an intermediary's AML system, or held pending documentation that nobody told the sender they would need. The money leaves the sender's account. It does not reach the recipient. And it is not clear to anyone in the chain exactly where it is or when it will move.

A clean failure is actually easier to manage. You know quickly, you can retry, you can communicate with your supplier. A stalled payment is operationally brutal - because you cannot escalate something you cannot locate, and you cannot give your supplier a timeline when you do not have one yourself.

A clean failure you can manage. A stalled payment leaves you chasing ghosts across three time zones while your shipment sits at the port.

The businesses dealing with this have adapted, in the way that businesses always adapt to persistent pain: they build in buffer time on every supplier deadline, maintain larger cash reserves than they should need, and dedicate operational resource to payment recovery that should be going elsewhere. The cost is real. It just does not appear in any fee schedule.

The correspondent banking model was not built for African trade corridors. It was designed for liquid, stable currency pairs between developed markets - and it tolerates African corridors rather than serving them. When you route a payment from Nigeria to China, you are typically going through at least two correspondent banks, each running their own compliance screening, each with their own processing windows, each with different risk tolerances for the currencies and counterparties involved.

Any one of them can introduce a hold. And when they do, the information rarely flows back cleanly to the originating bank, let alone to the business that sent the payment.

Compliance is the invisible driver of payment stalls on African corridors. Transactions do not stall because of technical failure - they stall because a correspondent bank's screening system flags something it was not expecting, and resolution requires manual intervention across institutions that have no direct relationship with each other. The payment is fine. The infrastructure around it is not.

Add FX controls, local banking infrastructure constraints, and the fact that liquidity availability on certain corridors varies significantly by time of day and day of week - and you have a reliability problem that is genuinely complex. It is not random. The patterns are real and learnable. But they are not static, and they do not yield to a single fixed solution.

Jenzy did not start as a payment orchestration company. We started by building multi-currency accounts - giving African businesses USD, EUR, and GBP accounts so they could hold balances and make payments from a single place. It was a sensible product hypothesis.

What we discovered, fairly quickly, was that our customers were not actually holding balances. They were not using the accounts as treasury. They were using them as a conduit - move money in, move money out, as fast as possible. The account infrastructure was overhead they did not want to manage. What they wanted was for the payment to arrive.

That insight sounds simple in retrospect. But it changed everything about what we built. Our customers did not have a treasury problem. They had a delivery problem. And delivery is an infrastructure question, not an account question.

So we stopped building accounts and started building the layer underneath them - the routing logic, the corridor intelligence, the Regulated Partner network that determines which path gives a given transaction the highest probability of completing on time. That pivot is why Jenzy looks the way it does today: not a neobank, not a multi-currency account, but an orchestration layer that sits between the business and the rails and makes sure the payment actually gets where it is going.

Reliability on African corridors is a dynamic problem. At any given moment, across any given corridor, some rails are performing better than others. Liquidity positions shift. Compliance windows open and close. A payment path that worked well yesterday may have a higher stall probability today.

Single-rail solutions - commit to one bank, one PSP, one pathway - cannot solve this because they treat routing as a fixed decision. When the rail has a bad day, your payment has a bad day. The only answer is routing that responds to conditions in real time: scoring available paths, selecting the one most likely to complete, and learning from every transaction to make the next one sharper.

That is what our sub-2% failure rate is built on. Not better luck on the corridors we operate. Not a single superior banking relationship. Real-time routing optimisation informed by the corridor intelligence that accumulates from every transaction we process. Every payment makes the model better. Every corridor we go deeper on compounds the advantage.

Most businesses moving money across African trade corridors can tell you exactly what their transfer fees are. Very few can tell you what percentage of their transactions stall, how long those stalls average, and what the downstream operational cost of each one is.

That second set of numbers is usually larger than the first. And unlike fees, it is largely avoidable.

I am not suggesting cost does not matter - it does, and we are competitive on it. But I would ask any business evaluating payment infrastructure to add one question to the list: not just what does it cost to send, but what happens when it stalls - and how often does it stall?

That question tends to change the conversation.

The conversation in African payments almost always starts with cost - fees, FX spreads, transfer charges. I want to talk about something the industry rarely measures: what happens to your payment after you send it, when nobody can tell you where it is.

When I started building Jenzy, I thought the hard problems would be licensing, FX access, and banking relationships. They are hard. But the problem that kept surfacing - the one that made customers genuinely frustrated, that strained supplier relationships and stalled shipments - was not cost. It was uncertainty.

Not payments that bounced cleanly. Payments that went somewhere and stayed there.

On African trade corridors - Nigeria to China, Kenya to India, Ghana to the UAE - a meaningful proportion of transactions do not complete on time. They get caught in compliance screening at a correspondent bank, flagged by an intermediary's AML system, or held pending documentation that nobody told the sender they would need. The money leaves the sender's account. It does not reach the recipient. And it is not clear to anyone in the chain exactly where it is or when it will move.

A clean failure is actually easier to manage. You know quickly, you can retry, you can communicate with your supplier. A stalled payment is operationally brutal - because you cannot escalate something you cannot locate, and you cannot give your supplier a timeline when you do not have one yourself.

A clean failure you can manage. A stalled payment leaves you chasing ghosts across three time zones while your shipment sits at the port.

The businesses dealing with this have adapted, in the way that businesses always adapt to persistent pain: they build in buffer time on every supplier deadline, maintain larger cash reserves than they should need, and dedicate operational resource to payment recovery that should be going elsewhere. The cost is real. It just does not appear in any fee schedule.

The correspondent banking model was not built for African trade corridors. It was designed for liquid, stable currency pairs between developed markets - and it tolerates African corridors rather than serving them. When you route a payment from Nigeria to China, you are typically going through at least two correspondent banks, each running their own compliance screening, each with their own processing windows, each with different risk tolerances for the currencies and counterparties involved.

Any one of them can introduce a hold. And when they do, the information rarely flows back cleanly to the originating bank, let alone to the business that sent the payment.

Compliance is the invisible driver of payment stalls on African corridors. Transactions do not stall because of technical failure - they stall because a correspondent bank's screening system flags something it was not expecting, and resolution requires manual intervention across institutions that have no direct relationship with each other. The payment is fine. The infrastructure around it is not.

Add FX controls, local banking infrastructure constraints, and the fact that liquidity availability on certain corridors varies significantly by time of day and day of week - and you have a reliability problem that is genuinely complex. It is not random. The patterns are real and learnable. But they are not static, and they do not yield to a single fixed solution.

Jenzy did not start as a payment orchestration company. We started by building multi-currency accounts - giving African businesses USD, EUR, and GBP accounts so they could hold balances and make payments from a single place. It was a sensible product hypothesis.

What we discovered, fairly quickly, was that our customers were not actually holding balances. They were not using the accounts as treasury. They were using them as a conduit - move money in, move money out, as fast as possible. The account infrastructure was overhead they did not want to manage. What they wanted was for the payment to arrive.

That insight sounds simple in retrospect. But it changed everything about what we built. Our customers did not have a treasury problem. They had a delivery problem. And delivery is an infrastructure question, not an account question.

So we stopped building accounts and started building the layer underneath them - the routing logic, the corridor intelligence, the Regulated Partner network that determines which path gives a given transaction the highest probability of completing on time. That pivot is why Jenzy looks the way it does today: not a neobank, not a multi-currency account, but an orchestration layer that sits between the business and the rails and makes sure the payment actually gets where it is going.

Reliability on African corridors is a dynamic problem. At any given moment, across any given corridor, some rails are performing better than others. Liquidity positions shift. Compliance windows open and close. A payment path that worked well yesterday may have a higher stall probability today.

Single-rail solutions - commit to one bank, one PSP, one pathway - cannot solve this because they treat routing as a fixed decision. When the rail has a bad day, your payment has a bad day. The only answer is routing that responds to conditions in real time: scoring available paths, selecting the one most likely to complete, and learning from every transaction to make the next one sharper.

That is what our sub-2% failure rate is built on. Not better luck on the corridors we operate. Not a single superior banking relationship. Real-time routing optimisation informed by the corridor intelligence that accumulates from every transaction we process. Every payment makes the model better. Every corridor we go deeper on compounds the advantage.

Most businesses moving money across African trade corridors can tell you exactly what their transfer fees are. Very few can tell you what percentage of their transactions stall, how long those stalls average, and what the downstream operational cost of each one is.

That second set of numbers is usually larger than the first. And unlike fees, it is largely avoidable.

I am not suggesting cost does not matter - it does, and we are competitive on it. But I would ask any business evaluating payment infrastructure to add one question to the list: not just what does it cost to send, but what happens when it stalls - and how often does it stall?

That question tends to change the conversation.