How to Choose Remittance Software: A Buyer's Guide for Established Operators

An established money transfer operator does not choose software the way a start-up does. You already have customers, corridors, partner banks, a compliance programme and years of transaction history. The question is not whether a platform can send money. It is whether it can carry the business you already run, prove it to your regulator and auditors, and cost less to change than what you have now.

This guide is for the leadership team running a selection. It gives weighted criteria, the questions that separate a real capability from a demo, red flags and a six-week evaluation plan. Where RemitSo is relevant we say what it provides; everywhere else, the point is a question to put to any vendor, including us.

Demos show what a platform does well. Without your own requirements, you end up scoring the vendor's strengths rather than your needs. Before the first call, write down how your business runs today.

• Your corridors and payout methods. Every sending and receiving country, and whether each pays out to bank accounts, cash pickup or mobile wallets.
• Your compliance programme. Sanctions lists, risk rules, limits, document tiers and the reports your regulator expects.
• Your pain points. The three things that cost you most time or risk on the current system. These are what the new platform must fix, not just match.

Turn this into a short list of test cases to run in each shortlisted platform's staging environment. For a broader feature inventory, see the remittance platform features checklist.

Agree the weights before any vendor is scored. Weights set after the demos drift towards whichever vendor the room liked. These are a starting point; adjust them to your risks, keeping the total at 100.

Score each criterion from 0 to 5 against your test cases, multiply by the weight and divide by 5; a perfect platform scores 100. Below 3 on compliance depth or finance should disqualify a vendor regardless of total.

Compliance is your programme; a platform either lets you run it or forces workarounds. Bring three or four anonymised cases from your own history and ask the vendor to run them in staging.

• A near-match on a sanctions list. Who sees it, what is recorded when it is cleared, and is the same name flagged again next week?
• A customer approaching a limit. Are limits counted per transfer and over rolling periods? Does the platform ask for documents as the total grows, or does someone have to notice?
• A pattern, not a single transfer. Frequent transfers to the same recipient, or several customers sharing payment details. Can your team combine indicators into a rule themselves?
• A regulatory report. Ask to see the report your regulator expects, built from the platform's own transaction record, and how the platform shows it is complete.

Ask too whether existing customers are re-screened when lists change. See sanctions screening for remittance companies for what a sound screening process includes.

Follow one transfer end to end, from payment to payout confirmation to the books. Then break it on purpose.

1. Underpay. Send a deposit that differs from what the customer declared. A well-designed platform holds it rather than guessing.
2. Pay twice. Does the platform flag the duplicate the moment it lands, and how is the refund recorded?
3. Fail a payout. Does the alert say whose side the fault was on, and whether the partner must be asked before a retry?
4. Close the month. Ask finance to open the ledger and trace one partner balance back to its transactions. If they cannot, your month-end will stay in spreadsheets.

Ask how exchange rates are protected: you want a guardrail that refuses an implausible feed rate and tells someone, plus a full rate history. Our guide to payment reconciliation covers the finance side in more depth.

Your partner banks and regulator will ask where customer data sits and who can see it.

• Hosting. Which cloud, which region, and is your instance dedicated or shared with other operators? Who holds the hosting account and who pays for it?
• Certifications. Ask for the certificates themselves and their scope, not a logo on a slide.
• Access control. How fine-grained are staff permissions? Can you separate reading the ledger from posting to it, or seeing a watch list from exporting it?
• Evidence. Which records exist: sign-in history with two-step status, rate history, screening and KYC decisions? A general promise of an "audit trail" is not an answer. See audit trails in remittance systems.
• Releases. Are updates tested on your staging first, and published?

For an established operator, migration is the riskiest part of the decision. Ask each vendor to describe its process in writing, and be wary of answers more precise than they can be before anyone has seen your data.

The questions that matter are simple. Who migrates the data, including customer records, recipients, documents and transaction history? How do you trial the new platform before customers use it? Can you run the old and new systems side by side if you want to? Can you move customers in stages rather than all at once?

Staging matters most. Moving a small, focused group of customers first lets you find problems with real transfers while the stakes are low, before the bulk of your customer base moves. Read migrating without losing customers for how to plan the customer side, and when to migrate if you are still deciding whether to move at all.

Pricing comes as setup plus a monthly fee by volume, a per-transfer fee, a share of revenue, or a source code licence. Model each on your completed transfers today and at twice today's volume.

• Revenue share grows with your margin, not with the vendor's cost. As you scale or raise prices, you pay more for the same software.
• Volume tiers make cost per transfer fall as you grow. Check where the tier boundaries sit against your monthly numbers.
• Hosting is often left out of quotes. Ask who pays.
• Source code ownership gives independence from the vendor's roadmap. Ask what it costs.
• Support. Ask the hourly rate and whether you pay only for time logged.

For a fuller treatment of build versus buy economics, see the true costs of building versus white label and patchwork versus one platform.

Six weeks is enough to test two or three shortlisted platforms properly. It assumes a working group of compliance, operations, finance and technology leads, with one owner.

1. Week 1: requirements and weights. Write your requirements and test cases, agree the weights and knock-outs, and send each vendor the questions from the table for written answers.
2. Week 2: demos on your terms. Each vendor demonstrates your test cases, not their standard script. Score provisionally and drop anyone who fails a knock-out.
3. Week 3: compliance in staging. Your compliance lead runs the screening, limits, rule and reporting cases in each vendor's staging environment.
4. Week 4: money and ledger in staging. Operations and finance follow transfers end to end, break them on purpose and trace balances in the ledger.
5. Week 5: security, migration and references. Technology reviews hosting, certifications, permissions and the software list. Each vendor walks through its migration process against a sample of your data structure.
6. Week 6: commercials and decision. Model costs on your volumes, finalise scores, list the conditions for signing and take a recommendation to the board.

The operator, vendors and numbers are illustrative. An operator with eight corridors is replacing a platform its developer no longer supports. After week 2, two vendors remain: Vendor A, a shared platform with a polished app, and Vendor B, a dedicated instance in the operator's region.

Vendor A won the room in week 2. But in week 4, finance could not trace a partner balance to its transactions: the "ledger" was a report. That scored 2, below the knock-out of 3 agreed in week 1. Vendor A also took a share of revenue, the most expensive option at twice today's volume.

Vendor B scored 3 on migration because the operator's non-standard document archive needed extra mapping. That became a condition of signing: a written plan for moving and checking those records in the trial run.

RemitSo is a white label remittance platform with optional source code ownership. Score it against your test cases like any other vendor.

• Screening against 8 sanctions lists, reloaded nightly, with everyone re-screened when lists change: rulings are kept per person, so a cleared name is not flagged again.
• 46 risk indicators your team combines into its own rules: risky transfers wait for a person and everything else flows, with limits counted per transfer, over 90 days and over a year.
• Regulator reports built from transfer data, with a check that nothing in scope was left out (for example, Australia's IFTI-E report).
• A double-entry ledger written automatically: entries are never edited, and any balance opens to the transactions behind it, so month-end leaves the spreadsheets.
• Deposits matched to the cent and payouts locked once approved: if the amount does not match, the money does not move, and what goes out is exactly what was approved.
• Scout and 43 plain-language alerts: what needs a person is checked every 5 minutes and shown in one place, and every partner call and webhook is logged.
• A dedicated AWS account in your region, billed to you, with ISO 27001:2022 and ISO 9001:2015 certification, 89 staff permissions and a software bill of materials for your auditors.
• Published pricing with no revenue share: a one-off setup fee and a monthly fee by completed transfers, with the option to buy the source code. See white label pricing and source code pricing.

On migration, RemitSo migrates your data; you then do a trial run, and can run your own parallel run if you want; then customers move in stages, a new focused group first and the rest after. Read more on the enterprise page.

Your team still owns your licence, your compliance decisions, your partner relationships and the trial run itself. See the admin features, or book a demo and bring your test cases.