"Where's My Payment?" Is Your Most Expensive Question

Your customer sends $50K to a supplier in Singapore on Monday. SWIFT confirms it left your bank. By Wednesday, the supplier calls asking where the money is. Your support team opens a ticket, checks three systems, emails the correspondent bank, and waits. The payment lands Thursday afternoon. Four days, two support tickets, one frustrated customer.

Meanwhile, Wise shows a progress bar and a predicted arrival time on every transfer. Your customers notice the gap. The fix is not faster rails. It is visibility. ML models trained on your settlement data can predict when each payment will arrive before you send it, then alert your customers and your team when something deviates.

Why the visibility gap exists

Cross-border payments move faster than most people think. On SWIFT's network, 90% reach the destination bank within one hour.¹

But "reaching the bank" and "landing in the customer's account" are two different things.

The FSB's 2025 progress report found that only 35% of retail cross-border payments actually credit to the end customer within one hour.² The G20 target is 75% by 2027, and the FSB has said it is unlikely to be met.

The delay happens in the last mile. BIS research shows that 80% of total processing time occurs after the payment leaves the SWIFT network.³ Local processing, regulatory checks, correspondent bank handoffs, and beneficiary bank queues. Each step adds hours. Each step is invisible to your customer.

That invisibility is the problem. Your customers do not care which hop is slow. They just want to know when their money arrives.

How predictive payment tracking works

Custom AI trained on your transaction history turns settlement from a black box into a predictable timeline.

1. Ingest historical settlement data. Corridor, correspondent chain, amount bracket, day of week, time of day. Every variable that affects when payments actually land.
2. Train corridor-specific models. Each corridor has its own settlement distribution. US-UK behaves differently from US-India. The model learns each pattern from your data.
3. Predict at initiation. Before each payment is sent, the model estimates a settlement window with confidence intervals. "This payment will arrive in 18-24 hours (90% confidence)." Not an average. A specific prediction for this specific payment.
4. Monitor in real time. Track payment status across correspondent hops. Flag when a payment deviates from its predicted window.
5. Alert proactively. Notify customers and internal teams when payments are delayed, before anyone calls to ask.
6. Learn continuously. Every settled payment feeds back into the model. Predictions get tighter over time.

This is the same prediction approach we explored in The $100K Cost of Unpredictable Settlements, applied to the customer experience instead of treasury optimization.

The mistakes that keep you reactive

Quoting static windows instead of building real tracking. "1-3 business days" is not transparency. It is a hedge. Your customers see it as uncertainty, and uncertainty drives inquiries.

Investigating after the call instead of notifying before it. When a payment is delayed, most teams wait for the customer to complain, then manually trace the payment across systems. By that point, trust is already damaged. Proactive notification flips the dynamic entirely.

Not tracking timestamps across the chain. You cannot predict what you do not measure. Most teams track when a payment was sent and when it was confirmed received. Few track the actual elapsed time at each hop, by corridor, by bank, by day. Without that data, patterns stay hidden and predictions stay impossible.

These are the same blindness patterns that create payment firefighting cycles across your operations team.

What this costs you in real numbers

The direct support cost is the visible part. Every "where's my payment?" inquiry requires a support agent to open a ticket, check multiple systems, and often contact the correspondent bank manually. At scale, this consumes hundreds of hours per month.

But the bigger cost is customer attrition. PwC found that 52% of consumers have stopped using a brand after a bad experience.⁴ For cross-border payments, a delayed transfer with zero communication is exactly that kind of experience.

The competitive pressure is real. McKinsey reports that up to 65% of international P2P transfer value has already shifted to nontraditional providers.⁵ These fintechs win on experience, not on rails. They win because they show customers what is happening.

Based on implementations we have seen, predictive tracking typically drives 40-60% reduction in WISM support volume. Proactive alerts resolve most inquiries before they become tickets.

Why most teams cannot build this internally

The concept is straightforward. The production system is not.

You need multi-bank data aggregation across every corridor you serve. Each correspondent chain has different timing characteristics. Models need to account for day-of-week effects, banking holidays across jurisdictions, amount-based processing thresholds, and regulatory holds that vary by country.

Then there is the infrastructure: real-time monitoring pipelines, anomaly detection for stuck payments, alerting systems that integrate with your customer communication channels, and continuous retraining as banking relationships and routes change.

The hard part is not the algorithm. It is the data pipeline, the production infrastructure, and the operational reliability of keeping it all running as your corridors evolve.

What you can do in the next 90 days

Start building the data foundation that makes prediction possible:

1. Audit your last 90 days of settlements. Calculate actual elapsed time from initiation to credit confirmation for every corridor. Identify where variance is highest.
2. Track the full timestamp chain. Initiation, each correspondent hop, credit confirmation. If you cannot see the hops, start with what you can measure.
3. Map variance by corridor, bank, and day of week. Friday payments take longer. Month-end takes longer. Document the patterns.
4. Identify your top 3 corridors by support volume. Where does "where's my payment?" hit hardest? That is where prediction creates the most CX leverage.
5. Calculate your current WISM cost. Tickets per month, average handle time, resolution time. Know the baseline so you can measure improvement.

These steps quantify the problem. What you will likely find is corridor-specific variance that static estimated windows cannot address.

How Devbrew builds this

At Devbrew, we build predictive payment tracking systems that give your customers Wise-level visibility on every cross-border transfer. Corridor-specific ML models trained on your transaction history, per-payment arrival predictions, real-time anomaly detection for stuck payments, and proactive alerting. We deploy into your existing infrastructure, not a parallel system, so your team operates one stack, not two. Production-ready in 90 days.

See where prediction creates leverage in your stack

If your support team spends hours tracing payments that your customers already expected to arrive, it is worth understanding where AI tracking could change that.

The goal of a conversation is to understand the visibility challenges you are facing, what is at stake if they remain unsolved, and where AI can create meaningful leverage. You will leave with clarity on your options, direction, and whether Devbrew can help.

Book a discovery call or email joe@devbrew.ai.