Signs Your Money Transfer Platform Is Holding You Back

Ageing platforms rarely fail in one dramatic moment. They fail by accumulation: a workaround here, a spreadsheet there, a change request queued for three weeks, a compliance check in a separate tool because the core could not be extended. Each is tolerable. Together they set the pace of the business, and it is usually slower than the market.

This diagnostic is for the COO, CEO or CTO of an operator already processing real volume. It sets out twelve signs, grouped by area, each with a way to measure it in the next thirty days. The aim is not to conclude that you must replace your platform, but to know with evidence what it is costing you, so the decision to patch or move rests on facts rather than frustration.

RemitSo is a white label remittance platform with optional source code ownership, so we have a view; we keep it to the section that is explicitly about us.

Pick one owner who sits between operations and technology, and give them four weeks. For each sign, they collect one number or artefact: a ticket count, hours from a timesheet, a list of systems. Score each sign 0 (not present), 1 (present but contained) or 2 (present and growing), from what was counted, not from opinion. Ask the people who do the work: the analyst who rebuilds the reconciliation file every morning knows how long it takes; their manager often does not.

1. A developer is needed for every rate or fee change

If changing a corridor margin, a rate band or a card fee goes through a developer, your pricing moves at the speed of your engineering queue.

Measure it: list every pricing change made in the last 90 days. For each, record who made it and the time from decision to live. Anything over a day for a simple change is a sign.

2. Change requests take weeks, and most of them are small

If most items in your change backlog are configuration in disguise (a new field on a recipient form, a different limit for one route, a wording change in a notification), the platform is treating settings as code.

Measure it: count open change requests, their median age, and how many would be a setting in a modern system.

3. A new corridor is a project, not a decision

Opening a corridor should be mostly commercial and compliance work. If it also needs a build and a release, you will open fewer corridors than your strategy calls for.

Measure it: for the last corridor you launched, split the elapsed time into commercial, compliance and technical. If technical was the longest part, note it.

4. Screening lives in a separate tool

When screening runs outside the core platform, someone has to make sure every sender and recipient reached it, that results came back, and that a cleared name is not raised again next week. Gaps appear where data is copied, and stay hidden until an examiner asks.

Measure it: take a random sample of 50 completed transfers and confirm a screening record exists for both parties at the time of the transfer. Note how long proof took.

5. Your compliance team cannot change its own rules

Monitoring thresholds, document requirements as a customer's totals grow, and which transfers wait for a person should be owned by compliance. If changing them needs a developer, policy and system drift apart.

Measure it: list the last three policy changes and check whether the system matched the policy on the day it took effect.

6. An audit request is answered from five systems

If "show me everything about this customer" means exports from the core platform, the screening tool, the ID check portal, the ledger and a shared inbox, every audit is a small project and a chance to miss something.

Measure it: run a mock request for one customer's full file. Count the systems touched and the hours taken. Our guide to a first regulatory audit lists what is usually asked for.

7. Customers tell you about failed payouts before the system does

If the first sign of a stuck payout is a support ticket, the platform is not watching the partner for you.

Measure it: for every payout exception last month, record who noticed first: the system, the team or the customer.

8. Statuses are updated by hand

Staff marking deposits received or payouts paid because the integration is unreliable is a workaround that has become a process, and it creates records nobody fully trusts.

Measure it: count manual status changes in a typical week, and ask the team why each one was needed.

9. Reconciliation runs on spreadsheets

A daily file matching bank statements against transfers, maintained by one analyst with formulas only they understand, is the most common sign of all. It works until volume grows or the analyst is on leave.

Measure it: hours per week spent on reconciliation, number of unmatched items carried over at month end, and days to close. Our month-end close guide shows what a ledger-led close looks like.

10. Corrections overwrite history

If a wrong entry can be edited in place, or a refund leaves no trace of the original, your books cannot explain themselves. Auditors notice.

Measure it: pick three corrections from last quarter and check whether the original and the correction are both still visible.

11. Customer requests wait behind platform limits

Repeat transfers at today's rate, a clear total before paying, push updates at every step, an app in the customer's language: if these wait because the platform cannot support them, customers are comparing you with operators who already have them.

Measure it: list the five most common feature requests in support tickets and app reviews, and the earliest date each could ship.

12. Access depends on people, not roles

Shared admin logins, staff with more access than their job needs, nobody sure who changed a setting last week.

Measure it: list every admin user, what they can do, and whether two-step sign-in is enforced. Count the shared accounts.

Use this as the working document for the month; the cost column is where the business case starts.

As a rule of thumb, 0 to 6 suggests a platform mostly serving you; 7 to 14, real signs that may be fixable in place; above 14, you are probably paying more to stand still than to move. A single 2 on screening coverage can matter more than several 1s elsewhere.

Replacing a platform is not always right. Patching is the better choice when:

• The signs cluster in one area. If everything scores 0 except reconciliation, fix reconciliation.
• Your platform is still actively developed and your vendor has a credible, dated plan for the gaps you found.
• You have a licence application, an examination or a major partner change in the next few months. Plan the platform change for afterwards.
• Your own engineering team owns the code and has capacity. If the backlog is long because of priorities rather than architecture, reprioritising may be enough.

Patching stops making sense when each fix creates a new workaround, the vendor no longer supports the product, or last year's fixed signs return.

Put the current state and the alternative in the same four units.

1. Hours. Convert reconciliation, manual statuses, audit assembly and change coordination into staff hours per month. Usually the largest, most defensible number.
2. Elapsed time. Days to reprice, weeks to change a rule, months to open a corridor. Tie each to a commercial plan the board has already agreed.
3. Risk. Screening coverage gaps, overwritten corrections and shared logins. Describe them as findings an examiner could raise, not as costs.
4. Direct spend. Licence and support fees for every tool in the stack, plus engineering time on maintenance rather than new work.

Then cost the move honestly: setup, migration, any period running two systems, training and testing time. A case that ignores the cost of moving should not survive a sceptical board.

The most common board objection is risk to customers during the switch. Answer it with a plan: a trial run before any customer moves, an optional parallel run of your own if your board wants one, and a staged transfer that starts with a small, focused group of customers before the rest follow. See migrating without losing customers and the data migration checklist. For the wider build, buy or white label question, see the true costs of build versus white label.

The figures below are illustrative, chosen to show the method rather than to describe any real operator.

An operator with eight corridors, a compliance team of three and an agency-built platform runs the diagnostic, owned by its operations director.

What they counted

• Pricing: 14 rate or fee changes in 90 days, all made by the agency, median four working days each. Score 2.
• Change requests: 31 open, median age seven weeks; 19 of them are settings in disguise. Score 2.
• Screening: separate tool. The sample of 50 found 2 transfers with no recipient screening record at the time of transfer, both after a form change. Proving the other 48 took a day. Score 2.
• Audit: the mock customer file touched five systems and took six hours. Score 2.
• Payouts: customers noticed first on 40% of exceptions. Score 1.
• Reconciliation: 22 analyst hours a week; close takes eight working days. Score 2.
• Access: two shared admin logins, no two-step sign-in for the agency. Score 2.

The remaining five signs scored 1, 1, 0, 1 and 1. Total: 17.

What they concluded

The signs span every area, the agency has no plan for most, and two cannot be patched without rebuilding the data model. The case to the board converted about 160 staff hours a month into a cost line, tied the pricing delay to a corridor launch already in the plan, and listed the screening gap and shared logins as findings to close regardless. It also budgeted for a trial run, a parallel run of its own design, and a quarter of an analyst's time on testing. The board approved an evaluation, not a migration: the right next step.

If your scores point to a move, RemitSo is built for operators who want one platform to scale on rather than another round of patches.

• Pricing your team controls: uploads or typed rates on one Exchange Rates page, a live rate feed per corridor with your margin as an optional add-on, amount bands and rate rules by customer group, platform or payout method, so repricing does not wait for a developer.
• Corridors as settings: 100+ corridors ready to switch on, and no corridor goes live until its fees are set, so a launch is a decision with a guardrail, not a build.
• Compliance in the same platform: every sender and recipient screened against 8 sanctions lists reloaded nightly, with rulings kept per person, and 46 risk indicators your compliance team combines into its own rules. See the admin features.
• AML rules with a change history: limits and document tiers per route, showing who last changed each rule, so policy and system stay in step.
• Books that explain themselves: a double-entry engine records every payment, payout, refund, fee and FX movement; mistakes are reversed, never edited; deposits are matched to the cent.
• Problems before customers: Scout checks every five minutes and shows what needs a person, and 43 alert events reach the people subscribed to them.
• Access by role: 89 permissions grouped into roles, two-step sign-in, and every sign-in logged.
• A migration designed for live operators: RemitSo migrates your data, you do a trial run (and your own parallel run if you want one), then customers move in stages, a focused group first and the rest after. See the enterprise page, and source code pricing if you want to own the code.

Your team still owns the policies, the partner and banking relationships, the trial run and any parallel run, and the decision on when each group of customers moves.