Automating Payouts, FX and Compliance: What a Licensed MTO Should Automate and What to Keep Human

A licence lets you operate. From the day it goes live, regulators, banks and payout partners stop judging your policies and start judging your execution: whether every transfer followed the same rules, and whether you can show it did. Automation is how a small team does that consistently. The harder question is where to stop, because a platform that moves money without anyone looking is as dangerous as one that needs a person for every step.

This guide is for operations and finance leads at licensed money transfer operators. It takes each stage of the transfer lifecycle, says what to automate fully, what to automate with a human checkpoint and what to keep manual, and explains why.

The aim is not the fewest people; it is that people spend time only where judgement changes the outcome. Three tests sort each step:

• Is the rule fully writable? If you can state it without "it depends", the system should apply it. People apply rules inconsistently, especially at the end of a shift.
• Is the failure safe? When a step cannot decide, does the transfer stop or carry on? Automate freely where the fallback is "hold and ask".
• Does someone need to own the decision? Ruling on a sanctions match or asking a partner to stop a payout are decisions an auditor will ask about by name. Those stay with a person, with the reason recorded.

This is also why fragmented tooling struggles after licensing: when checks, payouts and reporting live in separate systems joined by spreadsheets, nobody can quickly answer a bank's question about why a transfer was approved or delayed.

Treat this as a starting position. Your compliance officer should sign off the final version, and review it whenever you add a corridor or partner.

Matched by hand, small deposit differences slip through, or the same deposit is credited twice. The rule to automate is strict: if the amount received matches what the customer declared, to the cent, the transfer moves on. If it does not, or the reference is unclear, the money does not move and the case is held. Avoid tolerances ("within £1 is fine") unless compliance has approved them; that is how underpayments and misattributed funds creep in.

Keep a person on the held cases: asking for the balance, refunding an overpayment, matching an unreferenced deposit, each with a record. Chargebacks, bank recalls and double payments belong in the same queue, flagged the moment they happen rather than at month end.

Screening and monitoring must cover every customer and every transfer, so they belong in the system. Two design choices decide how much work reaches your team.

Remember rulings. A common name produces possible matches again and again. If the system forgets an analyst's ruling, the queue fills with noise. Keep rulings per person, and rescreen when lists change.

Write rules that separate risk, not volume. Combine checks into rules that reflect your risk assessment: a first large transfer to a new recipient, many senders paying one recipient, a sudden change in pattern. Transfers that trip a rule wait for a person; everything else flows. As a customer sends more, the system should ask for more documents rather than relying on someone to notice.

Manual rates go stale when the person updating them is busy, and one typing error publishes a wrong rate to every customer. A live feed per corridor with your margin applied removes both, provided you guard against the feed itself being wrong. That guard is jump protection: if the rate moves more than a set percentage, reject it, pause the feed and tell the team. A person checks whether the market moved or the feed failed, and decides when to resume. Keep a full rate history so finance can show what applied to any transfer.

Fees are fully writable rules: set by payment method and amount, with minimums and maximums, and no corridor live without them. The human work is the policy and its sign-off. The customer should see the rate, the fee and exactly what arrives before paying.

Once approved, a payout should be locked: what goes to the partner is exactly what was approved. If details must change, ask the partner to stop or return it where they can, and once it is cancelled or returned, create a new one that goes through approval again. That protects against mistakes and tampering.

For failures, keep the decision human and make the evidence automatic. Log every partner call with error message, status, duration and correlation ID, credentials masked, and save every incoming webhook before processing so no update is lost. An operations lead can then tell whether a failure is yours (bad recipient details, expired credentials, an empty prefunded balance) or the partner's (many payouts failing at once), and retry in one click once the cause is fixed. Never retry a timeout until you know whether the partner received the first request.

If finance rebuilds the ledger from statements each month, errors surface weeks late. A double-entry engine recording every payment, payout, refund, fee and FX movement as it happens turns month end into a review. Entries should be reversed, never edited, and bank fees, partner fees and discounts should sit in their own accounts so margin is readable without a spreadsheet.

Most operational misses are not wrong decisions but things nobody looked at: a payout overdue at a partner, a screening hit waiting since Friday. A scheduled check that lists what needs a person, in one place, replaces opening five screens every morning.

The amounts, rate and fee below are illustrative, chosen to show the reasoning rather than to describe any real operator or market rate.

A UK customer sends £500 to a recipient's bank account in Lagos. The corridor's fee for a bank transfer of this size is £3.99. The live feed gives a rate which, after the operator's margin, is 1 GBP = 1,950 NGN.

1. Quote (automatic). The app shows the rate, the £3.99 fee, a total to pay of £503.99 and 975,000 NGN to arrive. The customer confirms.
2. Deposit (held, then a person). £500.00 arrives; the customer forgot the fee. The amount does not match, so the case is held. An analyst contacts the customer, who sends the remaining £3.99, and the transfer proceeds. Nobody had to spot the shortfall; somebody did have to resolve it.
3. Screening (a person, once). The recipient's name is a possible match on a sanctions list. The compliance analyst compares date of birth and location, rules it a false match and records the reason. The ruling is kept against that recipient, so the customer's next transfer to them is not flagged again unless the lists change.
4. Risk rules (automatic). The transfer is within the customer's per-transfer, 90-day and annual limits, and trips none of the operator's rules. It does not wait for review.
5. Rate tripwire (a person, separately). An hour later the feed returns an NGN rate beyond the configured guardrail from the current one. It is not written, the feeder switches itself off and the team is emailed. The treasury lead confirms it was a feed error and resumes the feed. This transfer was already quoted and was not repriced.
6. Payout (automatic, then a person on failure). The payout is approved and locked. The partner returns a fast 503 on this and several other bank payouts. The operations lead sends the partner the time window and correlation IDs; when they confirm recovery and that nothing was processed, she retries from the log in one click.
7. Accounting (automatic). The customer payment, the fee, the FX movement and the payout to the partner are posted as double entries without anyone typing them. Finance sees the £3.99 fee in its own account the same day.
8. Exceptions (automatic surfacing). The held deposit, the screening hit and the failing partner calls appeared on one list, and dropped off as they were resolved.

Across eight stages, people made four decisions, each a judgement call with a recorded outcome. Everything else ran on rules.

1. Compliance has signed off which stages are fully automatic and which have a checkpoint.
2. Deposit matching has no tolerances you have not approved, and held cases have a named owner.
3. Risk rules map to your written risk assessment, and you know roughly what share they will send for review.
4. Screening rulings are kept per person and rescreening runs when lists change.
5. Limits are set per route and per app over the periods your regulator expects.
6. Every corridor has a rate source, a margin, a jump threshold and someone who is alerted when the feed pauses.
7. No corridor can go live without fees set.
8. Approved payouts are locked and never edited.
9. Partner calls and webhooks are logged in a form operations staff can read.
10. Accounting entries post automatically and cannot be edited, only reversed.
11. Alerts for failed payouts and chargebacks go to named roles, not a shared inbox.
12. Every override and ruling records who made it and why.

RemitSo puts each stage above in one admin panel. Your team still sets the policy, rules on hits, resolves held deposits, manages partners and owns every hold agreed with a partner and every override.

• Deposits: matched to what the customer declared, to the cent; anything unclear is held, and if the amount does not match the money does not move. Chargebacks, bank recalls and double payments are flagged the moment they happen.
• Screening: every sender and recipient against 8 lists, reloaded every night; everyone rescreened when lists change, staff included; rulings kept per person.
• Risk checks: 46 ready-made risk indicators you combine into your own rules. Risky transfers wait for a person; everything else flows. Limits per transfer, over 90 days and over a year, set per route and per app.
• Rates: one Exchange Rates page with full history, and, as an optional add-on, a live feed per corridor (hourly) with your margin or spread. A fetched rate that moves beyond the guardrail you configure is not written; the feeder switches itself off and subscribers get the "Base rate feeder auto-disabled" alert. Full rate history.
• Fees: flat, percentage, minimum and maximum, by payment method and amount. No corridor goes live until its fees are set.
• Payouts: locked once approved and never edited; a hold agreed with the partner is recorded with a required reason.
• Failures: an outbound API log with error message, status, duration and correlation ID, keys masked; webhook logs that save every message before processing, with the raw message and failure reason one click away and retry in one click.
• Accounting: a double-entry engine posting every payment, payout, refund, fee and FX movement automatically; entries reversed, never edited.
• Scout: checks everything every 5 minutes and shows documents required, payouts overdue at a partner, screening hits to rule on, partners failing calls and system health in one place.
• Control: roles built from permissions and a searchable, plain-language audit log of who changed what, and when.

See the full list on the admin features page, what customers see before they pay on the customer app features page, and recent changes in the release notes. If you are moving from an existing system, read about migration for established operators, or book a demo to walk through your own corridors.