The decision that sets your launch date
Choosing a payout provider is the single decision that most often determines when a money transfer business actually goes live. Software configuration is measured in days. Provider approval is measured in weeks, and occasionally months. An operator who starts payout conversations on day one launches materially sooner than one who waits until the platform is ready.
This guide covers how to choose, what to ask, and where the traps are. It assumes you already hold, or are applying for, the authorisation you need — the provider will ask about it early.
The four payout models
Almost every payout arrangement falls into one of four shapes, and they carry different costs, coverage and operational burdens.
1. Direct bank relationships
You hold an account with a bank in the destination market and push payments through it. Coverage is deep in that one market and zero elsewhere. Costs can be low per transaction, but you carry the account relationship, the local compliance expectations and the pre-funding. Practical for an operator serving one corridor at volume; impractical as a way to reach ten markets.
2. Aggregators and payout hubs
A single integration reaches many destination markets because the aggregator holds the local relationships on your behalf. This is how most operators reach breadth quickly. You trade some margin for coverage and for not having to negotiate market by market. The trade-off worth examining is that your customer experience in any given market is only as good as that aggregator's local connection.
3. Mobile money specialists
In markets where wallets are the dominant way people receive money, a specialist connection often outperforms a general-purpose one on both speed and success rate. Many operators run a specialist for their two or three most important corridors and an aggregator for the long tail.
4. Cash payout networks
Agent and branch networks for recipients who want physical cash. Still essential in several corridors and still commercially significant, but operationally heavier: reconciliation, agent liquidity and fraud controls all become your problem in a way that bank and wallet payouts do not.
What to actually ask a payout provider
Most vendor conversations drift toward coverage maps. The questions that predict how your launch will go are less glamorous.
- Which of my specific corridors are live in production today, and for which delivery methods? Coverage is usually quoted at country level, but a country with only bank deposit is a different product from one with bank, wallet and cash.
- What does your onboarding actually require, and how long has it taken for firms like mine? Ask for a range, not a best case.
- What are your pre-funding requirements? This is a working-capital question disguised as an operational one. Pre-funding several corridors ties up cash you may need elsewhere.
- What is the settlement cycle, and when do I bear FX risk? The gap between taking a customer's money and settling the payout is where operators are most often surprised.
- What happens when a payout fails? Ask about reversal timelines, who bears the cost, and how a failure is reported back to your platform.
- What are the failure and rejection rates on my corridors? A provider who tracks this and will discuss it is a better sign than one quoting only uptime.
Why most operators end up with more than one
It is tempting to look for a single provider covering everything. In practice very few operators stay on one. Corridors differ, a provider strong in West Africa is rarely the strongest in South Asia, and concentration on a single partner is itself a risk your regulator may raise under operational resilience expectations.
A common shape is one aggregator for breadth, one or two specialists for the corridors that carry the volume, and the ability to route each corridor and delivery method independently. If your platform cannot route per corridor, that shape is not available to you — which is worth checking before you commit to software.
Pre-funding and working capital
Most payout arrangements require funds in place before payouts are released. That is a real constraint on a young business: money sitting in provider accounts is money not spent on acquisition. Model it before you sign, using your expected daily volume rather than your monthly total, and ask each provider how quickly funds can be topped up and returned.
Common mistakes
- Choosing on headline rate alone. The rate matters less than the total of rate, FX margin, failure handling and pre-funding cost.
- Leaving provider conversations until the software is ready. This is the most common cause of a delayed launch, and it is entirely avoidable.
- Assuming coverage means the delivery method you need. Confirm method by method, corridor by corridor.
- Building on one provider with no route to a second. Both a commercial and a resilience risk.
How this connects to your platform
Whichever providers you choose, your platform has to connect to them, route by corridor and delivery method, reconcile what was sent against what was paid, and give your compliance team a record of it. If a provider you want already has a production-tested connector, that connection is configuration. If it does not, it is a development project with a timeline attached — which is a fair question to ask any software vendor before you sign with either party.
Frequently Asked Questions
Where Remitz fits
Remitz is software. We do not provide banking, payout, KYC, payment gateway or licensing services — you hold each of those relationships directly. What we provide is a white-label platform with production-tested connectors to providers like the ones described above, so connecting the partners you choose is configuration rather than a development project.