Most established money transfer operators did not choose a patchwork stack. They grew into one. A screening tool was added when the regulator asked. A reconciliation spreadsheet appeared when the bank changed its statement format. An accounting connector was bought when the auditor wanted cleaner books. Each decision was sensible at the time. The result is a business that pays for its tools twice: once on the invoice, and again in the hours spent making them agree with each other.
This article is for COOs, CEOs and CTOs of operators processing real volume who suspect the second bill is larger than the first. It describes the stack operators typically accumulate, the costs that never appear on an invoice, an example total-cost table, what one platform removes and what it does not, and a 30-day audit you can run to get your own numbers.
RemitSo is a white label remittance platform with optional source code ownership, so we are one of the options on the other side of this comparison. We have tried to make the method useful whatever you decide.
What the typical established operator's stack looks like
The details vary, but after a few years of growth most operators run something close to this:
- A core transfer system, often built by an agency or bought years ago, holding customers, recipients and transfers.
- An ID check provider's portal, where documents and selfies are reviewed, separate from the customer record.
- A sanctions screening tool, fed by an integration or, in some cases, by staff uploading lists of names.
- Transaction monitoring in another tool, or in a set of saved queries and spreadsheets owned by compliance.
- Payment gateway and bank dashboards, one per provider, where deposits are checked.
- Payout partner portals, one per partner, where payout statuses are confirmed.
- An accounting package, fed by exports or a connector, plus the reconciliation workbook that sits between it and everything else.
- A shared inbox and a chat channel where alerts, partner emails and customer escalations meet.
That is eight places where the truth about a single transfer can live. When they agree, nobody notices. When they do not, someone has to find out which one is right.
Reconciliation between systems
Every system boundary needs a reconciliation: transfers against deposits, deposits against the bank, payouts against partner reports, all of it against the ledger. Each one is a daily task for someone, and each mismatch is an investigation. The tool licences are on the invoice; the analyst's mornings are not.
Duplicated customer data
The same customer exists in the core system, the ID check portal, the screening tool and possibly the accounting package. When a customer corrects their name or address, it has to be corrected everywhere, or the records drift. Drifted records are what generate false screening hits, failed name matches at payout partners and awkward questions in an audit.
Gaps between tools
The most serious cost is the transfer that was checked in one tool but not another. A recipient added after a form change and never sent for screening. A customer whose totals crossed a document threshold in the core system while the monitoring spreadsheet was a day behind. These gaps are rarely anyone's fault; they live in the joins.
Watch for: any process described as "the integration sends it across". Ask what happens when the integration fails, who is told, and how you would prove afterwards that nothing was missed.
Audit evidence spread across systems
An examiner asks for one customer's file: identity documents, screening results and decisions, monitoring alerts, transfers, refunds, and who approved what. In a patchwork stack that is five exports, a reconciliation of timestamps and a narrative to tie them together. Every request costs hours, and the evidence is only as consistent as the systems that produced it.
Vendor management
Each tool has a contract, a renewal, a security questionnaire, a data processing agreement, an outage process and a support queue. For a regulated business, every vendor also has to be assessed and reviewed. Multiply that by the number of tools and it becomes a meaningful part of someone's job.
Change requests that touch everything
A new corridor, a new payout method or a new document requirement rarely stays in one system. It needs a field in the core, a mapping in the screening integration, a rule in monitoring, an account in the ledger and a column in the reconciliation workbook. The change that should take a day takes weeks because it is really five changes, coordinated across vendors who do not talk to each other.
What the full bill looks like: an example
The table below is an example, not a benchmark. The hours and fees are illustrative, chosen to show how the categories add up, and the staff cost uses an assumed loaded rate of £45 an hour. Replace every figure with your own from the audit in section 06.
| Line item | Where it shows up | Hours per month (example) | Annual cost (example) |
|---|---|---|---|
| Screening tool subscription | Invoice | – | £12,000 |
| Monitoring tool or add-on | Invoice | – | £9,000 |
| Accounting connector and add-ons | Invoice | – | £4,800 |
| Contractor time maintaining integrations | Invoice | – | £15,000 |
| Reconciliation between systems | Staff time | 80 | £43,200 |
| Correcting duplicated customer data | Staff time | 20 | £10,800 |
| Finding and closing gaps between tools | Staff time | 15 | £8,100 |
| Assembling audit evidence | Staff time | 12 | £6,480 |
| Vendor management and reviews | Staff time | 10 | £5,400 |
| Coordinating cross-system change requests | Staff time | 30 | £16,200 |
| Total invoiced | – | – | £40,800 |
| Total hidden | – | 167 | £90,180 |
In this example the hidden cost is more than twice the invoiced cost. That ratio is not a rule, but the direction is typical: tool fees are visible and negotiated every year, while staff time spent between tools is spread across several teams and rarely added up. The table also leaves out the cost of a gap that becomes a regulatory finding, which is hard to price and should be described as a risk rather than forced into a number.
Where one platform removes work
A single platform does not remove work by being clever. It removes the joins. When customer records, compliance checks, money movements and the ledger share one data model, the reconciliations and copies between them stop being necessary. Taking RemitSo as the example, using only what the product does today:
- Screening without an integration to watch. Every sender and recipient is screened against 8 sanctions lists, reloaded every night; when a list changes, the people whose names it could affect are re-screened, staff included. Rulings are kept per person, so a cleared name is not raised again. Our guide to sanctions screening covers the wider practice.
- Monitoring on the same record. 46 ready-made risk indicators, from watched names and high-risk countries to payment details reused across customers, are combined by your compliance team into its own rules. Risky transfers wait for a person; the rest flow.
- AML rules where the transfers are. Limits over a single transfer, 90 days and a year, and the documents asked for as a customer's totals grow, set per route, with a history of changes.
- Deposits matched at source. Deposits are matched to what the customer declared, to the cent; anything unclear is held. See matching deposits to the cent.
- A ledger that is not fed by exports. A double-entry engine records every payment, payout, refund, fee and FX movement as it happens. Click any balance to see the transactions behind it. More in double-entry accounting for remittance.
- One place to look. Scout checks every five minutes and shows what needs a person, and 43 alert events go to the people subscribed to them, so the shared inbox stops being the control room. See running operations by exception.
- One permissions model. 89 permissions grouped into roles, two-step sign-in, and every staff sign-in logged, instead of a separate user list and access review for each tool.
What one platform does not remove
It is worth being precise about the limits, because an inflated case will not survive scrutiny.
- Your partners. You still contract with banks, payment providers, payout partners and an identity check provider. A platform with ready connections reduces the integration work; it does not replace the relationships or their fees.
- Judgement. Screening matches, risky transfers and document reviews still need a person to decide. The platform puts them in one queue; it does not make the decisions.
- Bank-side reconciliation entirely. Matching inside the platform is tighter, but someone still reviews held deposits, chargebacks and bank recalls.
- The rest of the company's books. Many operators keep a general accounting package for payroll, rent and statutory reporting, fed from the platform's ledger.
- Policy work. Writing the AML programme, setting risk appetite and training staff remain your compliance team's job.
Rule of thumb: count only the work that exists because two systems have to agree. That is what a single platform removes. Work that exists because the business is regulated stays.
How to run a 30-day cost audit
One owner, four weeks, and a short time log from each team. The aim is a table like the one above, with your numbers in it.
Week 1: map the stack
List every system that holds customer, compliance or money data, including spreadsheets and shared inboxes. For each, record the annual fee, who uses it, and which other systems it exchanges data with. Draw the joins; each one is a candidate hidden cost.
Week 2: log the time between tools
Ask reconciliation, compliance, operations and finance staff to log, for two weeks, any time spent copying, comparing, correcting or chasing data between systems. Fifteen-minute blocks are precise enough. Ask the people doing the work, not their managers.
Week 3: test the gaps
Take a random sample of 50 completed transfers. For each, confirm that both parties were screened at the time, that monitoring saw it, that the deposit and payout reconcile and that the ledger entry exists. Then run one mock audit request for a full customer file and time it.
Week 4: add it up
Convert the logged hours to a monthly figure and apply a loaded staff rate. Add invoices, contractor time and the vendor management hours. List gap findings separately as risks. Then cost the alternative honestly, including setup, migration and the internal time a move would take.
Takeaway: the audit is useful even if you stay where you are. Knowing which join costs the most tells you which one to fix first.
Scenario: a finance director runs the audit
The figures below are illustrative, chosen to show the method rather than to describe any real operator.
An operator with eleven corridors, two payment providers and four payout partners asks its finance director to run the audit after the screening tool's renewal quote arrives higher than expected.
Week 1 finds nine systems, not the six the leadership team would have named; the three missing ones are the reconciliation workbook, a monitoring spreadsheet compliance built three years ago and a shared inbox nobody had counted. Thirteen joins between them.
Week 2 logs 148 hours a month between tools. The largest block is the reconciliation analyst at 70 hours; the surprise is compliance, at 26 hours, most of it updating customer details in the screening tool to match the core system.
Week 3 finds 1 transfer of the 50 with no recipient screening record, traced to a partner-specific recipient form added last spring. The mock customer file takes five hours and four exports.
Week 4 puts invoiced tools and contractor time at roughly a third of the total; the rest is staff time. The finance director presents three options: renegotiate and keep the stack, fix the two most expensive joins, or evaluate moving to one platform. The board chooses to fix the screening gap immediately, whatever happens, and to evaluate one platform against the cost of the second option. For signs beyond cost, the team also runs our platform diagnostic.
Doing it with RemitSo
RemitSo puts customers, compliance, money movement and the ledger on one platform, in your brand, so the joins that generate hidden cost are not there to begin with.
- Screening built in: 8 sanctions lists reloaded nightly, re-screening when lists change and rulings kept per person, so there is no screening integration to reconcile and fewer repeat hits to clear.
- Your own rules from 46 risk indicators: compliance builds and changes rules without a developer, and risky transfers wait for a person.
- Regulator reports from the transaction record: built from the platform's own data and checked against in-scope transfers (for example, Australia's IFTI-E), so nothing is assembled by hand.
- Deposits matched to the cent and a double-entry ledger: reconciliation becomes reviewing exceptions rather than rebuilding a workbook each morning. See the admin features.
- Scout and 43 alert events: what needs a person is in one place, checked every five minutes, instead of spread across portals and an inbox.
- Named records an auditor can use: login sessions, rate history, screening decisions and KYC decisions sit in the same platform as the transfers they relate to.
- One permissions model: 89 permissions grouped into roles, with two-step sign-in, replacing an access review per tool.
- Room to grow: 100+ corridors and 50+ partner connections, a 99.99% uptime SLA, and the option to own the code. See the enterprise page and source code pricing.
Your team still holds the partner and banking contracts, makes every compliance decision, reviews held deposits and owns the AML programme.
Frequently asked questions
Is a best-of-breed stack ever the better choice?
It can be, if you have the engineering team to own the integrations and a specific need one platform cannot meet. The test is whether you are paying for the joins with dedicated engineering or with staff hours nobody counts.
How accurate does the time log need to be?
Fifteen-minute blocks over two weeks are enough. The goal is the order of magnitude and which join costs most, not a figure to the minute.
Do we lose our ID check or payout partners if we move to one platform?
No. You keep the relationships; the platform connects to partners rather than replacing them. Check that your current partners are among the available connections, or what it takes to add one.
How should we treat screening gaps found during the audit?
As a finding to close straight away, regardless of any platform decision. Record what you found, how you fixed it and how you checked that nothing else was missed.