Payday Peaks and Partner Outages: How to Judge a Remittance Platform's Reliability

A remittance platform is rarely tested on a quiet Tuesday. It is tested on payday, when a month's worth of senders arrive in a few hours, and on the afternoon a payout partner stops answering. This guide is for operations heads, CTOs and founders of established money transfer operators judging whether a platform, their own or a provider's, will hold up on those days.

It works through both scenarios, sets out what to ask a provider and what a good answer looks like, and is plain about what your own team still has to own. Figures are illustrative.

The payday peak. An operator that normally handles 600 transfers a day sees 2,400 on the last Friday of the month, with 40% of them between 5pm and 8pm. Every one needs a quote, a payment, sanctions screening, risk checks and a payout. Nothing new is happening; there is just four times as much of it, at once.

The partner outage. At 6:15pm on that same Friday, the payout partner for one busy corridor starts timing out. Some instructions reach it, some do not, and replies stop coming back. The platform is up, the app works, customers keep paying, and payouts on that corridor are now uncertain.

The second scenario is the harder one. A platform can be "available" by any uptime measure while one partner integration is failing. Reliability, for an operator, means what happens to money in flight when one piece breaks.

• Your own AWS account. Each operator runs in a dedicated AWS account in its own region, billed by AWS to the operator. You are not sharing servers with another operator's payday.
• Scout, every five minutes. Scout measures what needs an operator in one place: transfers, payouts and payments needing action, compliance decisions waiting, and system health (job queue, provider messages never applied, partners failing calls, rate feeds stopped, maintenance windows). Each group is granted by role.
• Payouts that wait safely. A timeout or unreadable answer stops a payout in Error with the reason and whose side it is on; the customer is not told it failed. Where the partner may already hold it, Retry asks the operator to confirm with the partner first. A payout the partner stops answering about appears on Scout and is never cancelled automatically.
• Nothing lost on the way in. Every incoming webhook is saved before processing, with the raw message and the reason it failed one click away, and a one-click retry. Every outbound call is logged with status, duration, error and correlation ID, keys masked.
• 43 alert events in plain language, each with its own subscribers, such as "Payout not sent because of a fault on our side" and "Exchange rates not moving".
• Maintenance without taking the platform down. A maintenance window pauses only what the work needs; money in flight carries on, and the window holds until your team lifts it. Transaction processing can also be paused and resumed during an incident.
• Releases tested on staging first. Every release says plainly whether it needs downtime; each environment shows which release it runs. Releases 2026.10.1 to 2026.10.11 needed none.
• For auditors: a software bill of materials (CycloneDX) ready to download, and ISO 27001:2022 certification.

Your team still owns incident decisions, partner escalation, customer messages and the regulator relationship. See maintenance without downtime and partner failures and API and webhook logs.

What did not happen: no customer was told their transfer had failed when it had not, no payout was sent twice, and no incoming partner message was dropped. That is the bar to test any platform against.

• Know your peak. Pull the busiest three hours of each of the last twelve months. Plan for the worst of them, plus growth.
• Find the manual steps. A review queue that takes two people fifteen minutes a case is fine at 600 transfers and a backlog at 2,400. Check how many transfers stop for a person on a normal day, and multiply.
• Check document tiers. Payday pushes customers over limits. Customers asked for documents at checkout are fine; customers asked for documents their country cannot provide are a support queue.
• Check rates are moving. A stuck rate on a busy evening is a pricing problem. Make sure someone is subscribed to the alert that says so.
• Do not release on payday. Even with releases that need no downtime, schedule changes away from your peak.

No platform runs an operation for you. Before your next peak, make sure you have:

• a named person on shift for the busiest hours, with authority to pause a corridor;
• a partner contact list with out-of-hours numbers, and an agreed way to get a list of what the partner holds;
• support scripts for a delayed corridor, written in advance;
• alerts subscribed by the right people, not by everyone;
• a next-day reconciliation routine for any incident window.

Reliability also sits inside your compliance obligations. The FATF Recommendations cover money or value transfer services directly, including the duty to report suspicious transactions, so controls cannot pause when volume rises. See the compliance and risk management guide and catching payout problems early.

• FATF, International Standards on Combating Money Laundering and the Financing of Terrorism and Proliferation: The FATF Recommendations (updated February 2025): Recommendations 14, 16 and 20.
• FATF, Guidance for a Risk-Based Approach: Money or Value Transfer Services.

Checked October 2026. Regulations change; confirm current requirements with the regulator or your adviser.