How a remittance dollar can be converted to crypto and quietly rerouted offshore, and why a receiving central bank goes looking.

How Ethiopia’s Central Bank Caught Licensed US Remittance Operators

And What It Means for Anyone Paying Out in Africa

A money transfer operator can hold a perfectly valid license in the United States, charge the card correctly, and run clean KYC on the sender, and still get caught in a compliance failure that has nothing to do with the sending side. The gap is on the other end of the wire, in the country where the money lands. Ethiopia’s central bank worked this out, built a quiet little desk to prove it, and turned what looked like an originating-country licensing question into a receiving-country enforcement problem. The operators they caught were licensed. That was never the issue. The issue was who paid the money out on the ground, and whether that person had any authority to do it.

This matters to anyone building a payout corridor into Africa, because the assumption that a sending-side license covers you is the exact assumption these cases were built to break. Here is how it actually happened, the mechanism the regulator used to detect it, and the lesson that follows for operators routing money into Ghana, Nigeria, Tanzania, Zambia, or anywhere with a central bank that wants its dollars surrendered through official channels.

Why central banks care about the payout, not the license

Before the enforcement story makes sense, you have to understand what a central bank is actually protecting. It is not the license. It is the dollar balance.

When money is remitted into a country like Ethiopia or Ghana, the central bank wants that inflow declared and routed so the foreign currency lands in its own account. Those dollars do not physically sit in the country. They sit in a correspondent bank account in New York, under the Federal Reserve, with a ledger entry that says how much foreign currency the central bank holds. When a remittance comes in through official channels, that ledger entry grows. The country’s reserves go up. The central bank can then issue local currency against it and manage the exchange rate.

When money is paid out off-channel, none of that happens. The recipient gets local currency from a domestic account, the sender’s dollars never get surrendered, and the central bank’s balance does not move. The remittance happened, the recipient was paid, and the country saw no foreign currency for it. From the central bank’s seat, that is leakage. It weakens the official rate, it starves reserves, and it means somebody is running a parallel payout system the regulator never authorized.

That is the thing being protected. Not paperwork. Reserves and rate control.

The rate gap that creates the temptation

The reason off-channel payout exists at all is margin. Official remittance channels have to settle at the central bank’s rate, because the dollars get surrendered. The open market and the parallel rate sit higher. An operator who pays out locally, off the books, can offer recipients a better rate than the official channels and still make money on the spread.

In practice this is why a regulator’s own foreign exchange desk starts hearing complaints. The established players, the Western Unions and the rest, notice that some new operator is consistently beating their rate. Beating it by enough that customers are switching. They flag it to the central bank, often in passing, the way you mention something to a regulator you see regularly. A new name keeps coming up, offering a rate that should not be possible through official channels.

That complaint is the thread the regulator pulls.

Ghost shopping: how the regulator proved it

Ethiopia’s response was the part most operators do not see coming. The central bank set up a small desk inside its foreign exchange department, staffed by a couple of people, with one job: act like ordinary customers and trace the money end to end.

They borrowed a credit card or a bank account from relatives in the US. They went to the suspect operator’s website. They sent a real money transfer to a recipient inside Ethiopia. And then they watched every step of what happened.

On the sending side they learned exactly how the operator ran: what the card charge was, which processor handled it, how the front end worked. All legitimate, all visible. But the revealing part was the receiving side. When the payout hit the recipient’s account inside Ethiopia, it came from a regular domestic account, not from any declared inbound foreign currency transfer. That single fact told them the money had been paid out locally rather than remitted through channels.

From there it unraveled fast. They looked at the account that sent the local payout and saw it was sending money all over the country, to recipient after recipient. They followed those accounts, found more, and worked backward until they had the whole network and the methodology behind it. A central bank doing this is not a small adversary. It has the authority to pull any account it wants.

What the regulator did with the proof

Once Ethiopia had the picture, it moved on three fronts at once.

First, it froze the domestic payout accounts. Every account that had been distributing the local currency, with whatever balance was sitting inside, got locked. If you were a payout agent in that network, your funds stopped.

Second, it wrote to the regulator that had licensed the operators in the US. It did not send a complaint. It sent evidence. The proof of its own ghost-shopped transactions, showing the card was charged legitimately and the money moved correctly on the US side, with the single defect that the payout in Ethiopia was made locally without using a bona fide, authorized payout partner.

Third, it escalated to the US Treasury, to the bank supervisors and FinCEN. The message was precise and hard to argue with. You have an operator sending money correctly from your side, but the money is being received incorrectly on ours. Clean your side so this stops.

The audit chain that catches everyone

The clever part is what the US-side regulator can then do, because this is where a sending-side license stops protecting you.

The state regulator goes to the licensed operator and asks a sequence of questions that any operator should be able to answer and a non-compliant one cannot:

Show me your payout agreement in Ethiopia. Fine, the operator produces one naming a local company.

Show me that the local company is authorized by the Central Bank of Ethiopia to receive and pay out remittances. This is where it breaks. If the payout partner is really just a cousin with a bank account, there is no authorization to show.

Show me the SWIFT transfers or domestic wires you used to push the dollars from the US into that partner’s account in Ethiopia. If the money was paid out locally instead of remitted, there is no wire trail to produce.

That sequence is the whole game. Payout agreement, local authorization, wire proof. Miss any one and the structure collapses under audit. Operators in the original Ethiopia cases were chided, warned, and fined for exactly these gaps. The same pattern then repeated, with more companies caught the same way.

The aggregator variant, and why it shifts the problem without solving it

Operators are not stupid, so the next move was predictable. Instead of having the US company sign payout agreements in every country directly, which means separate due diligence, counterparty contracts, AML risk assessment, pre-funding, API integration and weeks of onboarding per country, they route through an aggregator.

The US operator sends money to a single licensed aggregator, say one based in Canada, and that aggregator already holds payout agreements across all the target countries. One relationship instead of a dozen. Cleaner, faster, and genuinely valid as a structure.

Valid, that is, until the regulator asks to see the aggregator relationship. And here the requirement is softer but still real. The US regulator can usually only demand transaction detail up to the next licensed provider in the chain, which is the aggregator. What the aggregator does downstream is between the aggregator, its own regulator, and the receiving country’s central bank. So the US operator shows that it raised the funds, shows the wire pushing those funds to the aggregator, and that is the border of its responsibility.

But the receiving country does not stop there. The central bank can still go to the local payout company and ask it to prove it received the specific funds the chain claims it sent. The audit just moves one link down. The aggregator has to be able to show an obfuscated but verifiable agreement proving its downstream partner is licensed and authorized. You can black out the commercial terms. You cannot black out the existence of a real, authorized payout partner.

So the aggregator model genuinely reduces the operator’s onboarding burden. It does not make the underlying compliance question disappear. Somewhere in the chain, a licensed and authorized local entity has to have actually received the money, and that has to survive an audit.

The lesson for operators building payout corridors

In my experience the mistake is almost always the same, and it is a mental one. Operators treat the sending-side license as the finish line. They get authorized in the US, the UK, or Canada, they build clean sender KYC, and they consider the compliance work done. The payout is treated as an operational detail, a relationship with someone local who can move the money.

The Ethiopia cases show that the payout is the compliance event, not the detail. A central bank that wants its reserves protected will trace the money to the recipient’s account and ask one question: did this arrive through an authorized channel or not. If the answer is no, your clean sending-side license becomes the thing that hangs you, because it is the license the receiving country uses to pull your regulator into the audit.

Build the structure so it survives that audit from day one. The payout partner must be genuinely licensed and authorized in the receiving country. The wire trail from your account to that partner must exist and be producible. If you use an aggregator, the aggregator must be able to prove its downstream authorization, even with commercials redacted. None of this is exotic. It is just the part operators skip because it lives in a country they are not standing in.

Frequently asked questions

What is ghost shopping in remittance enforcement?

Ghost shopping is when a regulator poses as an ordinary customer, sends a real money transfer through a suspect operator, and traces every step to see how the money is actually received. Ethiopia’s central bank used borrowed US cards and accounts to send transfers to recipients inside the country, then watched whether the payout came through an authorized inbound channel or from a domestic account, which revealed off-channel payouts instantly.

Can a US-licensed money transfer operator get in trouble for how money is paid out abroad?

Yes. A valid US license covers how you collect and send funds, but it does not exempt you from how the money is received in the destination country. If the receiving central bank finds that payouts happened locally without an authorized partner, it can present evidence to your US regulator, who can then audit your payout agreements, your partner’s local authorization, and your wire records.

What documents does a regulator ask for in a payout audit?

Three things, in sequence: the payout agreement with your local partner, proof that the partner is authorized by the receiving country’s central bank to handle remittances, and the SWIFT or domestic wire records showing you actually transferred the dollars to that partner. A non-compliant structure usually fails at the authorization step or the wire-proof step.

Does using an aggregator solve the payout compliance problem?

It reduces the operational burden by replacing many country-by-country payout agreements with one relationship, but it does not eliminate the compliance requirement. The audit simply moves one link down the chain. The aggregator must be able to prove its downstream payout partner is licensed and authorized, even if commercial terms are redacted.

Why do central banks insist that remittances come through official channels?

Because foreign currency reserves are held in correspondent accounts abroad, and only officially declared inflows increase the central bank’s balance. Off-channel payouts mean the recipient gets paid but the country’s dollar reserves never grow, which weakens reserves and undermines the central bank’s control of the exchange rate.

Conclusion

Three things to take away. First, the payout side is where remittance compliance is won or lost, not the sending side, and a clean license abroad is exactly what a receiving central bank uses to reach back to your regulator. Second, the detection methods are more sophisticated than most operators assume, and a determined central bank can trace a single transfer to your whole network. Third, the aggregator model is a legitimate way to reduce onboarding friction, but it relocates the compliance question rather than answering it, and somewhere in the chain an authorized local partner still has to hold up under audit.

If you are building a payout corridor into any African market, structure the payout leg to survive an audit before you send your first transaction. If you want that structure reviewed before a regulator does it for you, that is the kind of work worth doing early.

About Faisal Khan

Faisal Khan is the CEO of Faisal Khan LLC and has spent years working in the cross-border payments, banking, licensing, remittance, and fintech infrastructure space. His work focuses on helping companies navigate banking access, money transmission licensing, crypto infrastructure, compliance, payout corridors, and international financial operations.

He is also the founder of DealHarbor, a marketplace focused on regulated financial services opportunities, and MoneyWiki, a growing knowledge platform covering banking, payments, licensing, and financial systems globally.

https://faisalkhan.com https://dealharbor.app