Rate Alerts That Bring Senders Back Without Teaching Them to Wait

Rate alerts are one of the few retention features customers actively ask for. They are also one of the few that can quietly work against you. Built carelessly, they teach senders that the right move is to wait for a better number, and a sender who is waiting is a sender who has not sent. Built well, they bring people back at the moment they were going to send anyway, and give them a reason to send with you rather than compare three apps first.

This guide is for growth and pricing leads at money transfer businesses.

RemitSo is one platform that supports this: its customer app offers a daily rate update or a notification when a target is hit, and its admin panel holds the rates, rules and offers behind them, with automatic rate feeding and promo codes available as optional add-ons. Your team still decides the pricing policy and reads the results; the platform carries it out.

Most remittances are driven by need rather than by the rate. Rent, school fees, a family member's monthly allowance: the money is going to move, and usually within a fairly predictable window. An alert does not create that need. What it can do is change when the need is met and where.

That is where the risk sits. Three patterns are worth knowing before you switch alerts on.

• Anchoring on a target. A customer who sets a target has just told themselves that today's rate is not good enough. If it is not reached, some will keep waiting past the point they would normally have sent.
• Comparison at the moment of sending. A customer primed to think about the rate is more likely to check other providers before sending. Alerts that only ever talk about the rate invite exactly that comparison.
• Learning that waiting pays. If customers notice that rates or offers improve just after they subscribe, or every month-end, they learn to hold off. That lesson is hard to unlearn.

None of this means alerts are a bad idea. It means the design goal is not "more alerts opened" but "transfers that would not otherwise have happened with you, at a margin you chose".

The two alert types do different jobs and attract different customers. Treat them as separate products.

Daily snapshots

A daily rate update is a habit and brand reminder. It keeps your name and your rate in front of the customer on the days they are deciding when to send, without asking them to name a number. Because it carries no target, it does not set up a sense of loss if the rate drifts.

The weakness is fatigue. Keep it short, show the rate the customer would actually get rather than a market reference, and make the next step obvious: send again to a saved recipient in a couple of taps.

Target alerts

A target alert tells the customer when the rate reaches a level they chose. It suits customers sending larger, less frequent amounts, who have more flexibility on timing and more reason to care about a small movement. It is also the type most likely to cause delay.

Three design points reduce that risk:

• Quote the customer's rate, not the market's. If the alert compares a target with a market rate the customer can never get, it will fire and then disappoint at checkout. The number in the alert should be the number on the payment screen, alongside the fee and the total to pay.
• Show where today's rate sits. When a customer sets a target, showing today's rate next to it helps them pick something realistic. A target far above anything recent is in practice a request never to be contacted.
• Make sending easy when it fires. The alert is only valuable if the transfer follows.

The core discipline is simple: the alert reports your price; it never decides it.

Put the floor in the rules, not in people's heads

A margin floor that lives in a spreadsheet will be broken the first busy week someone wants to hit a growth target. Express it in the exchange rate rules instead: the standard margin for each corridor, a better rate for the groups you have chosen to reward, and amount bands that give larger transfers a better rate. Whether a rule is fixed or moves with the standard rate is itself a pricing decision: a fixed rate is easy to communicate but can drift out of line with the market, while a rule that moves with the standard rate keeps the margin constant.

Do not chase every movement

Rates move every hour. Repricing by hand on every movement is expensive and makes your own alerts erratic: a target fires, the customer opens the app, and the rate has moved again. Decide in advance how often you review margins, and let the feed and the rules do the rest between reviews.

Protect alerts from bad data

An alert is a promise that the rate is real. If a faulty feed publishes a wildly wrong rate, target alerts fire to every subscriber at once, and some of them will try to send at a rate you cannot honour. Feed validation is therefore part of alert design: a sudden jump should be stopped and investigated before it becomes a published rate. Equally, a feed that has stopped updating means daily snapshots go out with a stale number and targets never fire. Both need to reach a person quickly.

Alerts that talk only about the market rate leave you competing on the one thing you control least. Pairing them with things you do control gives the customer a reason to send now, and with you.

Group rates

Exchange rate rules by customer group let you give loyal or high-value senders a consistently better rate than the standard one. When those customers receive a daily snapshot, the rate they see already reflects their group. That advantage is there every day, so it gives no reason to wait.

Time-boxed offers

A promo code with a clear end date gives a reason to act within a window rather than hold out for a target. Money off or a better rate, limited to one use per customer and to specific dates, converts the decision from "is the rate good enough?" to "do I use this before it ends?".

Two cautions apply. First, predictable offers create their own waiting: if every month-end brings a rate boost, customers learn to wait for month-end. Vary timing and do not run offers on a fixed calendar. Second, an offer layered on a group rate and an amount band can stack into a rate below your floor. Check the combined effect for your best-priced customer, not the average one, before you publish the code.

The obvious metric, transfers sent shortly after an alert, is misleading on its own. Many of those transfers would have happened anyway; the alert only got the credit. To know whether alerts add anything, you need to look at behaviour over a longer window and compare it with a group that did not receive them.

The cleanest method is a holdout: a randomly chosen share of eligible customers who are not offered alerts for a period. Compare the two groups on the measures below over at least a few of their normal sending cycles.

If transfers per customer rise while the gap between transfers stays steady, alerts are adding activity. If they stay flat while timing clusters around alerts and offers, alerts are moving transfers you already had, often at a lower margin.

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

An operator sends from the UK to India. The base rate from its feed is 110.20 INR to the pound. Its standard customer rate, after margin, is 108.90. An exchange rate rule gives a "regular sender" group 109.20, and an amount band gives transfers of £1,000 or more 109.30.

Step 1: look at the targets customers have set

The pricing lead reviews the target alerts. Most targets cluster between 109.00 and 109.50, which sit within the operator's own pricing range. A smaller group has set targets of 110.50 and above: higher than the base rate itself. Those customers would need the market to rise noticeably before their alert could ever fire at the standard margin.

Step 2: refuse the tempting fix

Someone suggests a short-term rate of 110.50 to "clear" those targets. That would mean pricing above the base rate: a loss on every transfer, and a lesson to every subscriber that targets get met if you wait. The lead declines. The margin floor stays where the rules put it.

Step 3: use the levers the operator controls

Instead, the team does three things:

1. Customers in the 109.00 to 109.50 cluster who qualify for the regular sender group already get 109.20. The daily snapshot for those customers now shows their group rate, so many of them see a number at or near their target without anyone changing the price.
2. A promo code giving a better rate of 0.20 is created for one weekend, one use per customer, for customers who have not sent in 60 days. The combined rate for the best-priced customer, band plus group plus code, is checked against the floor before the code is published.
3. The far-out targets are left alone. Those customers still get the daily snapshot, which shows today's rate next to their target, so they can decide for themselves.

Step 4: read the results honestly

After two sending cycles, the team compares subscribers with the holdout. Lapsed customers who used the weekend code sent again at a higher rate than lapsed customers in the holdout: a real gain. Regular senders' transfer counts barely changed, but their gap between transfers did not lengthen either, so the daily snapshot is retaining rather than delaying. The 110.50 group has a slightly higher lapse rate. The team decides to show a range of recent rates when customers set a target, so fewer people choose a number they are unlikely to see.

RemitSo provides the alerts and the pricing controls behind them. Your team still sets the margin policy, chooses the offers and judges the results.

• Rate alerts in the customer app (May 2026): customers subscribe to a daily rate update, or set a target and are notified in the app when it is hit, so you can offer both alert types described above. See the customer app features.
• Rate, fee and total to pay before paying: the customer sees exactly what arrives, so an alert does not turn into a surprise at checkout. Send again at today's rate in a couple of taps keeps the path from alert to transfer short.
• Live rate feed per corridor, with your margin or spread: rates update hourly; a fetched rate that moves beyond the guardrail you configure is not written, the feeder switches itself off and the "Base rate feeder auto-disabled" alert goes to its subscribers, so a bad tick does not become a published rate.
• "Exchange rates not moving" and "Pricing review due" alerts: a stalled feed reaches the right people, and fees that have not been reviewed for three months are flagged, so pricing reviews happen on a schedule rather than when someone remembers.
• Exchange rate rules and amount slabs: different rates by customer group, platform, payment route, payout method or partner, fixed or moving with the standard rate, with better rates for larger amounts, so the margin floor sits in the system. See the admin features.
• Promo codes: money off or a better rate, with limits, dates and uses per customer. Coupons are never deleted, only retired by ending their window, so you can always see which offers ran when you analyse results.
• Full rate history: every rate is kept, so you can line up transfers against the rates customers saw when you measure alert performance.

For what changed and when, read the release notes, or book a demo to see the pricing controls on your own corridors.