The map is not the territory
On a pitch deck, remittance looks like one market with one feature: send money from A to B. In production it is dozens of corridors, and each one behaves like a product of its own. London to Nairobi wants mobile money on the receiving end. Sydney to Harare wants cash pickup. New York to Lagos wants a bank deposit, quoted at a rate that moved twice this morning.
Each corridor carries its own currency pair, its own rate dynamics, its own payout partners, its own collection habits, and its own regulatory posture. The sender should never feel any of this. That is the entire difficulty.
Where corridor-by-corridor building fails
The tempting approach is to build the first corridor, then copy it for the second. By the fifth copy the platform is five products wearing one logo: five rate integrations, five payout implementations, five reconciliation paths, and a release process that touches all of them every time one changes. Growth gets slower with every market added, which is the opposite of what expansion is for.
Corridors as configuration
The platform we engineered for Remit60 takes the other path: one transfer engine that treats corridors, rates, and payout rails as configuration. Seven send markets flow into ten-plus African receive countries through the same core, with bank deposit, mobile money, and cash pickup as first-class payout options per corridor.
Under that architecture, a new market is an integration project, not a rebuild: connect the payout network, configure the pair, test the flow. The engine, the sender experience, and the operational tooling stay one product. For a remittance operator, the speed of that loop is the business model.