Alert Routing for Money Transfer Teams: Who Should Hear About What

Most established money transfer businesses have alerts. Fewer have alert routing. The difference shows on a bad day: a payout fails or a sanctions list fails to load, and the message lands in a shared inbox nobody owns, or with someone on leave. The customer finds out first.

Alert routing means deciding, for every event your platform can raise, who hears about it, what they do first and who covers when they are away. It is the cheapest way to make sure problems reach the right person before customers notice.

This guide is for operations, compliance and finance leads at operators with live corridors. It uses RemitSo's Alert Management module as the example: 43 alert events, each switched on or off, each with its own subscribers. RemitSo raises the alert and words it plainly; your team decides who subscribes and what happens next.

Start with the inventory, not the people, or the alerts you forgot will reach nobody. In RemitSo the full list sits on one page in Alert Management: 43 events, each with an on/off setting and a subscriber list. The names are written in plain language, and many tell you what to do. "Payout not sent because of a fault on our side" names whose side the fault was on and whether the partner must be asked before retrying; "Regulatory report ready" says whether every in-scope transfer made it in.

Then sort the events into two kinds. Action events need a person: "Deposit received but matched nothing", "Duplicate payment captured", "Sanction lists could not be loaded". Status events mark a normal step in a transfer's life: "New transaction initiated", "Ready for payout", "Sent to payout partner", "Payout completed successfully". They suit someone watching one corridor during a launch; subscribing every analyst to them is the fastest route to alerts nobody reads.

The useful grouping is not by system but by who fixes the problem. For most established operators that gives seven owners. The groups below use RemitSo's exact event names.

• Payments: "Customer clicked 'I have made payment'", "Payment successfully cleared", "Payment received on closed attempt", "Duplicate payment captured", "Deposit received but matched nothing". The last three mean money has arrived that could not simply be applied, and it is held until a person decides. See matching deposits to the cent.
• Payouts: "Payout attempt failed", "Payout not sent because of a fault on our side", "Payout reversed", plus the status events from "Currency conversion in progress" to "Payout completed successfully".
• Compliance: the sanctions events ("Possible sanction match found", "Sanction match confirmed", "Sanction lists could not be loaded", "Sanction lists out of date"); risk and review ("High customer risk score detected", "Risk assessment in progress", "Transaction under manual review", "Transaction placed on hold"); "Regulatory report ready"; "AML policy asked for a document the corridor cannot collect"; and the KYC events, such as "KYC requires compliance review" and "KYC reset at the provider".
• Pricing: "Exchange rates not moving", "Pricing review due" and, if you use automatic rate feeding (an optional add-on), "Base rate feeder auto-disabled".
• Onboarding: "Sending country not set up for customers", which catches a country where a customer could verify with no name or could not complete proof of identity; and often a copy of "KYC rejected – action needed".
• Finance: "Bank took money back" and "Chargeback raised on a payment", usually alongside payments, because both change what the books say you hold.
• Training: if you run the staff training programme, an optional add-on, "Required training long overdue", "Training completion waiting for sign-off" and "Quiz answers waiting to be marked" go to whoever signs off training.

Two of these matter most for customers. RemitSo tells customers a payout failed only when the partner refused it; a fault on the platform's side or a missing setting leaves the payout in Error for your team to resend. And a reset at the identity provider never undoes an approval on its own: an officer decides. Both protect the customer only if someone is subscribed and acts.

An owner is half the answer; the other half is what they do in the first ten minutes. Write it down, so the person covering on a Sunday does what the usual owner would. Adjust the table below to your own procedures.

New alert events arrive with releases. In RemitSo, a new alert arrives with nobody subscribed and reaches nobody until someone is; new permissions likewise reach nobody until granted. A release never starts messaging people who did not ask, and nobody gets access by accident.

The cost is that someone has to act. Each RemitSo release note states the action needed, including new permissions and alerts. Make it a fixed step: when a release note lists a new alert, the owner of that area decides who subscribes, the same week. Do the same when anyone joins, leaves or changes role, and when a corridor or payout partner goes live. Keep subscriptions tied to roles in your own procedures, so replacing the "payouts shift owner" is a ten-minute job, and remember that subscribing someone to an alert does not give them the permission to act on it (see role-based access control).

Alert fatigue is a routing problem. When people receive messages that need nothing from them, they stop reading the ones that do.

• Route status events narrowly, to someone with a reason to watch them, such as a launch lead on a new corridor, and remove them when the reason ends.
• Use copies sparingly. Finance needs chargebacks; the management team does not need every payout failure.
• Switch off what nobody acts on, rather than ignoring it.
• Plan for known bursts, and staff them.

The first sanctions re-screen

The best-known burst is sanctions. In RemitSo, sanction lists are loaded every night, and after each load the people whose names the changes could affect are re-screened: customers, recipients, account holders and staff. For an established book moving onto the platform, the first full screening can raise a wave of "Possible sanction match found" alerts, mostly common names that are not the listed person.

Two facts make this manageable. Nothing is blocked by a possible match on its own; a person decides, so the wave is a workload, not an outage. And rulings are kept per person: once an officer rules "not this person", the ruling stays unless revoked, so the same name is not flagged again at the next load. The first wave is the largest.

Plan the first wave as a project: agree who works the "Awaiting decision" filter, which shows hits nobody has ruled on, and tell the wider team the volume that week is expected. See sanctions screening for remittance companies.

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

An established operator with 20 staff moves onto RemitSo. During setup, someone subscribes the whole operations team of six to every payout and payment event "to be safe". Each of the six soon receives several hundred alerts a day, almost all status events. One Thursday, a missing setting on one payout route leaves 9 payouts in Error, each with "Payout not sent because of a fault on our side". All six see the alerts; each assumes another is dealing with it. Two customers contact support the next morning asking why their money has not arrived.

What changed

1. Status events removed from the team, except for a launch lead watching one new corridor for four weeks.
2. Two named owners for each payout action event, one per shift, with a third as cover.
3. Payments and finance split. Payments owns unmatched deposits and duplicate captures; finance receives a copy of chargebacks and bank recalls only.
4. A written first action for every action event, taken from the table above.

The result

Each payout owner now receives a few dozen alerts a day, each asking for something. The next time a route setting is missed, the shift owner sees 3 payouts in Error within the hour, fixes the setting and resends them. The customers were never told their payout failed, the money arrives the same day, and nobody contacts support.

Alerts push a single event to the people subscribed to it. They are good at interrupting someone about something new and poor at answering "what is still open?": an alert that arrived at 3am and was not read is easy to miss.

RemitSo's Scout answers that question. Every five minutes it measures what needs an operator: transfers, payouts and payments needing action, compliance decisions waiting, and system health such as partners failing calls and rate feeds stopped. Each group is granted by role.

The alert gets the right person moving quickly. Scout is where the shift lead checks, at handover, that nothing an alert announced is still sitting there. A payout the partner stops answering about appears on Scout and is never cancelled automatically, so even if an alert was missed, the item is still waiting for a person. For the wider practice, see running remittance operations by exception.

Alert Management gives you the events, the wording and the subscriber lists; see the admin features.

• 43 alert events in plain language: each says what happened, and for payouts whose side the fault was on, so your team can act without decoding a status code.
• Subscribers per alert: your team hears only about what it owns, and your customers are not left waiting while a shared inbox decides who acts.
• Each event switched on or off: unused events are turned off, so the rest stay worth reading for your team.
• New alerts reach nobody until subscribed: a release never starts messaging people who did not ask, so your team controls who hears about what.
• Payout faults on your side stay with you: the payout waits in Error for your team to resend and the customer is not told it failed, so your customers see a delivered transfer rather than a false failure, and your team gets a clear task.
• Sanctions rulings kept per person: a cleared name is not flagged again at the next load, so your compliance team rules on each name once rather than at every nightly load.
• Scout alongside alerts: everything still open, checked every five minutes and granted by role, so your team can confirm at handover that nothing an alert announced was missed.

What your team still does: decide who subscribes, write the first action for each alert, act on what arrives and keep the routing up to date as people and corridors change.

To see Alert Management in your own setting, book a demo.