Build or buy: choosing a remittance management system

Every remittance platform evaluation we have seen starts with a feature matrix. Customer management, KYC, transaction processing, payout routing, reconciliation, reporting. Every credible vendor ticks every box, the matrix comes back green across the board, and the decision gets made on price and demo quality.

Two years later the same business cannot launch a corridor because their payout partner is not supported, cannot produce a compliance report their regulator now asks for, and is quoted six weeks of vendor work for a change they expected to configure themselves.

Why feature comparisons mislead

A feature matrix asks whether a system can do something. The questions that matter are how quickly, by whom, and at what cost when your requirements change.

Every platform can add a corridor. The useful question is whether that takes four days and a configuration screen, or six weeks and a vendor statement of work. Both answer yes on the matrix.

Every platform can add a corridor. The question is whether it takes four days or six weeks, and the feature matrix cannot tell you which.

The same applies to payout partners, fee structures, compliance reporting and API access. What you are really buying is not a feature set. It is a rate of change.

The third option nobody considers

Most operators frame this as binary: build from scratch or buy a platform. The third option is extending what you already run, and it is frequently cheaper, less risky and faster than either.

It usually looks like this. Build an API layer over the existing system. Identify the two modules causing the most operational pain, which in our experience are almost always reconciliation and corridor configuration. Replace those two independently. Leave the rest alone until it becomes a problem.

Build wins on flexibility and loses on time to market. Buy wins on time to market and loses on flexibility and long-run cost. Extend usually wins on risk-adjusted cost and is skipped because it is the least exciting option in the room.

Extend is not always right. If the existing system has no recoverable data model, or the vendor is exiting the market, it is not viable. But it deserves scoring alongside the other two rather than being dismissed before the evaluation starts.

The four questions that actually decide it

1 · How fast can you add a corridor without vendor involvement?

This is the single most predictive question in the whole evaluation. A remittance business grows by adding corridors. If each one requires a vendor engagement, your growth rate is bounded by their delivery calendar rather than by your market opportunity.

2 · Can you add a payout partner the vendor does not already work with?

Payout cost is a direct margin line. A platform that restricts you to its existing partner network locks your margin at whatever those partners charge, permanently. Ask to see a partner being added, not to be told it is possible.

3 · Can you produce the reports your regulator actually asks for?

Not the reports in the demo. The ones your compliance function currently assembles by hand. Bring one to the evaluation and ask the vendor to produce it from their system.

4 · What does it cost to leave?

Ask this in the first meeting, not the last. Data portability, export format, and whether an exit requires a paid professional services engagement. A vague answer here is itself the answer.

Total cost over five years

Year-one cost comparisons systematically favour buying, because a licence is smaller than a build. Five-year comparisons frequently reverse, and remittance businesses tend to run platforms for longer than five years.

Pay particular attention to the third row. Volume-linked pricing behaves very differently at ten times your current volume, and the whole point of the platform is to support that growth. Model it at your target scale, not at today's.

Ten questions vendors are rarely asked

– How long does adding a corridor take, in elapsed days, and who does the work?

– Can we add a payout partner you do not currently have a relationship with?

– Show us the audit log for a single transaction, end to end.

– What happens to our data if we leave, and what does that cost?

– Which of your customers has migrated away, and can we speak to one?

– What is your pricing at ten times our current volume?

– Can we configure fees per corridor without raising a support ticket?

– Does your API expose transaction state changes as webhooks?

– What compliance reports do you produce out of the box for our markets?

– What is your uptime over the last twelve months, and how is it measured?

The fifth question is the one that produces the most informative silence. A vendor with no churn is either very good or very new. Both are worth knowing.

The eighth matters more than it sounds. Without webhooks on transaction state changes, you cannot build lifecycle messaging or support automation on top of the platform, which means two of the highest-return growth programmes available to you are blocked by an integration decision.

The migration nobody plans for

Whichever option you choose, the migration is where the risk actually sits, and it is consistently underestimated because it is unglamorous.

The pattern that works is staged replacement with parallel running. Build module by module rather than as a single replacement. Run both systems together long enough that reconciliation between them becomes a daily check rather than a final cutover test. Migrate agent counters or branches in small cohorts, resolving each cohort's issues before starting the next.

On one migration we ran, eleven weeks of parallel running felt excessive to everyone involved until the third week, when the two systems started disagreeing. Every discrepancy found in that period was a defect that never reached a sender.

Parallel running is where the cost sits and where the risk is removed. It is the first thing cut when a timeline slips and the last thing you want to have cut.

How to make the decision

Score all three options against weighted criteria rather than comparing two on features. Weight corridor flexibility and commercial risk highest, because those are where regret concentrates. Weight time to market lower than instinct suggests, because it is the criterion that feels most urgent and matters least in year three.

Then apply a simple threshold. A weighted score above four out of five is a clear fit. Between 3.4 and 3.9 is workable if you can name and mitigate the two weakest criteria. Below 2.8 means you are looking at the wrong option, however good the demo was.

And ask the exit question first. A vendor who answers it clearly and in writing is telling you something useful about how the relationship will run.