How to Choose and Run Payout Partners for a Money Transfer Business

Customers judge a money transfer business on the last step: the money arriving. That step belongs to your payout partners, the banks, aggregators, mobile wallet providers and cash pickup networks that put funds in the recipient's hands. Choosing them is a commercial decision, but running them is an operational one, and most of the pain comes from the second part.

This guide is for founders, operations leads and treasury teams. It covers how to choose between broad coverage and direct depth, when one partner per corridor stops being enough, how much money to leave sitting with partners, what to do when a payout fails, and which numbers tell you a partner is slipping. We also show where RemitSo's admin panel helps and what your team still owns.

Payout partners fall broadly into two types.

• Aggregators have already connected to many banks, wallets and cash networks. One integration gives you many countries, usually with one funding account. You pay for that convenience in the rate or fee, and you are one step removed from the institution that actually credits the recipient.
• Direct partners are a bank, wallet operator or cash network in the destination country. Pricing is often better and escalation is shorter, but each one means its own due diligence, its own integration, its own contract and its own prefunded balance.

The usual path is sound: launch with an aggregator for breadth, watch where your customers actually send, then add direct partners in the corridors that carry most of your transfers. Keep the aggregator for the long tail and as a fallback.

Whichever type you choose, expect the same onboarding pack from the partner: company registration and licence, ownership and directors with ID, AML and KYC policies, proof of staff training, an independent review of your AML programme, recent financial statements and details of your compliance officer. Have it ready before you start conversations; it is the entry ticket, not a differentiator.

Price and country list are the easy questions. These are the ones that decide how the partnership feels at two in the morning.

1. Delivery methods per country. Bank account, mobile wallet, cash pickup: which are live, which are "coming soon", and which institutions sit behind each one.
2. Recipient data requirements. Which fields are mandatory per method, how names must be split (one, two or three name fields), and what account or wallet formats they validate. Every rejection for bad data is a failed payout you could have prevented at the form.
3. Limits. Per payout, per day and per recipient, by method. A partner limit lower than your own customer limit creates payouts that can never succeed.
4. Status model. What states a payout passes through, which are final, and whether "paid" means credited to the recipient or merely accepted by the partner.
5. Callbacks and status queries. Do they send webhooks, can you query status on demand, and what happens if a callback is lost?
6. Reversals and recalls. How a paid-out transfer can come back, how long that can take, and how you are told.
7. Cut-offs and holidays. When bank payouts stop for the day and which local holidays pause them.
8. Escalation. A named contact, a response time for stuck payouts and a route for urgent cases.
9. Funding mechanics. Currency of the prefunded balance, top-up process, how you see the balance and what happens when it runs out mid-day.

One partner per corridor is simpler: one integration, one balance, one relationship. It is also a single point of failure. When that partner has an outage, a compliance hold or an empty prefunded balance, every transfer on the corridor stops.

A second partner makes sense when any of these is true:

• The corridor carries a large share of your transfers, so an outage is a business problem, not an inconvenience.
• Customers expect speed, and a day's delay produces complaints and refunds.
• The primary partner is weak on one delivery method, such as cash pickup in rural areas.
• You need a negotiating position on price.

The cost is real: a second integration to test, a second balance tying up working capital and a second reconciliation every day. For a corridor with a handful of transfers a week, a documented manual fallback is often enough.

If you run two, decide the routing rule in writing. Common patterns are primary with failover (everything goes to partner A unless it is down), split by method (bank to A, cash to B) and split by amount (larger transfers to the partner with higher limits). Avoid splitting purely on price day to day; it makes failures harder to diagnose and balances harder to forecast.

Most payout partners pay out from a balance you have sent them in advance. Too little and payouts stop; too much and capital sits idle in another country, exposed to that partner's credit risk and to currency moves.

A workable approach:

1. Measure daily payout value per partner over several weeks, including the peaks around paydays and festivals.
2. Cover the gap between top-ups. If a top-up takes two working days to land, the balance must cover at least two peak days plus a weekend where relevant.
3. Add a buffer for unexpected peaks and delayed top-ups. Set a low-water mark that triggers a top-up, not a date.
4. Review monthly, and before known peaks.

Two partners in one corridor roughly doubles the idle money unless you size each for its share of traffic rather than the whole corridor.

The numbers are illustrative, not drawn from any real operator.

An operator sends around 120 transfers a day on its busiest corridor, with an average payout of 400 in the destination currency, so about 48,000 a day. Fridays run at roughly 1.5 times normal, about 72,000. Top-ups take two working days to arrive.

• Cover between top-ups: two peak days, 144,000.
• Weekend cover: payouts continue on Saturday and Sunday at normal levels, but top-ups do not move, adding 96,000.
• Buffer: 20 per cent of the above, about 48,000.
• Target balance: roughly 288,000, with a top-up triggered when it falls below 150,000.

The operator adds a second partner for the same corridor and routes 80 per cent to the primary and 20 per cent to the secondary. Sized by share, the secondary needs about a fifth of the target, not the full amount.

On a Tuesday, the primary partner starts timing out. Thirty payouts go unanswered in an hour. Operations confirm from the partner's own errors that the fault is on the partner's side, pause new payouts to it, and move the corridor's new transfers to the secondary. The thirty already sent are not resent: the team asks the partner what happened to each before anything is retried, because a timed-out payout may still have been paid.

The secondary's balance, sized for 20 per cent of traffic, now carries 100 per cent. It will last about a day. Treasury tops it up the same morning.

Payout problems come in four shapes, and each needs a different response.

Three rules keep this safe. First, establish whose side the fault is on before acting. Second, never resend a payout whose outcome is unknown. Third, never edit an approved payout's details to make it go through; ask the partner to stop or return it where they can, and send the corrected one through approval once the first is cancelled or returned, so the record shows what happened.

Tell the customer early and in plain words. A short, honest message that the payout is delayed and you are on it prevents more tickets than a perfect explanation two days later. For a deeper walk-through of reading the logs, see when a payout partner fails and how to identify failed payouts before they become customer problems.

Review these monthly per partner and per delivery method, and weekly for your top corridors.

• Success rate at first attempt. The share of payouts paid without a retry, correction or refund.
• Rejection reasons. Grouped by cause. Data errors point at your forms; limits and compliance holds point at the partner or your corridor settings.
• Time to paid. From your send to the partner's confirmation, by method. Watch the slowest tenth, not just the average.
• Stuck payouts. How many sat without a final status beyond your expected time, and how long they took to resolve.
• Reversals. Count and reason; a rise often signals a problem at one receiving bank.
• Technical failure rate. Timeouts and errors on calls to the partner, separate from business rejections.
• Escalation response. How long the partner takes to answer a stuck-payout query.
• Cost per payout, including partner fees and the cost of idle prefunding.

Bring the numbers to a quarterly partner review. A partner shown its own rejection reasons usually fixes more than one asked vaguely to "improve reliability". See also corridor margin versus volume.

RemitSo's admin panel handles the configuration and visibility around payout partners. See the admin features.

• 50+ connections across payment, payout, ID check and other partners: add coverage without building each integration yourself.
• Payout channels by currency and country, with limits, routing rules and the recipient details each one requires, validated at entry: fewer payouts rejected for bad data, and limits that match the partner's.
• Delivery options and payout institutions set per channel, with one, two or three name fields and beneficiary name validation: the customer's form matches what the partner expects.
• Defined payout states, an error state, and payouts locked once approved: what goes out is exactly what was approved, and approved payouts are never edited.
• Outbound API log and webhook logs: every call to a partner with payloads, status, errors and duration, keys masked; every incoming message saved before processing, retried in one click.
• Plain-language alerts such as "Payout not sent because of a fault on our side", "Payout attempt failed" and "Payout reversed": the alert says whose side the fault is on and whether the partner must be asked before retrying.
• Scout's "payouts needing action", measured every 5 minutes alongside partners failing calls: overdue and stuck payouts in one place.
• Third-party integrations page showing which providers are set up and which are missing something: catch a gap before a corridor goes live.

Your team still chooses and contracts the partners, sizes and tops up prefunded balances, reconciles partner statements and decides each retry, repayment or refund.

Read the release notes, or book a demo to walk through payout channels with your own corridors in mind.