Wise moved $243 billion last year. Seven million of those customers had never sent money with them before.

Why this company, and why this number

Wise reported 19 million active customers, up 21%, moving $243.5 billion across borders, up 31%. Card spend reached $43.6 billion and customer balances $39 billion. Roughly half of net revenue now comes from things other than the first transfer: interest on balances, card interchange, and other services.

Read those two facts together and a strategy appears. The business is deliberately moving from transfer fees to resident money. Interest and interchange only pay if the customer keeps a balance and uses the card, which means the goal is no longer "get the transfer." It is "get the second transfer, then the balance, then the card."

Now put the 7 million next to it. More than a third of their active base sent money with Wise for the first time this year. Every one of those people is sitting at the exact moment where lifecycle marketing decides the outcome: they either form a habit, or they go quiet and the acquisition cost is written off.

Where I would expect the money to leak

Cross-border transfer has a structural problem most products do not: the trigger is an event, not a habit. Someone pays tuition, moves country, buys a flat, sends money home. The event ends, and the reason to open the app ends with it. Unless something replaces that reason, the customer becomes dormant while still counting as "acquired."

Three leaks follow from that, in the order they cost money:

1. First to second transfer. The single most predictive event in a transactional product is the second transaction. Until it happens, nothing has been established.
2. Transfer to balance. A sender moves money through Wise. A balance holder keeps money in Wise. The second is worth far more, and it is a behaviour change, not a feature announcement.
3. Seasonal dormancy. Tuition is quarterly, rent is monthly, family remittance is often monthly, contractor invoices are irregular. Anyone whose real cadence is periodic looks dormant between events, and generic win-back messaging will annoy them rather than reactivate them.

Three journeys I would build, in priority order

Each one below has the segment written as I would actually query it, the journey as I would actually build it, and the measurement design that decides whether it worked.

-- Overdue against each customer’s own rhythm, not a fixed window
WITH gaps AS (
  SELECT customer_id, transfer_id, settled_at,
         DATEDIFF(settled_at, LAG(settled_at) OVER (
           PARTITION BY customer_id ORDER BY settled_at)) AS gap_days
  FROM   fact_transfers
  WHERE  status = 'SETTLED'
),
rhythm AS (
  SELECT customer_id,
         PERCENTILE_APPROX(gap_days, 0.5) AS median_gap,
         COUNT(*) AS transfers,
         MAX(settled_at) AS last_settled
  FROM   gaps
  WHERE  gap_days IS NOT NULL
  GROUP BY customer_id
  HAVING COUNT(*) >= 2          -- needs a rhythm to be off-rhythm
)
SELECT r.customer_id, r.median_gap, r.transfers,
       DATEDIFF(CURRENT_DATE, r.last_settled) AS days_since
FROM   rhythm r
JOIN   dim_customer c USING (customer_id)
WHERE  DATEDIFF(CURRENT_DATE, r.last_settled) > r.median_gap * 1.5
  AND  DATEDIFF(CURRENT_DATE, r.last_settled) < 365   -- quiet, not gone
  AND  c.marketing_consent = TRUE
ORDER BY r.transfers DESC;

How I would prove any of it worked

Every journey above ships with a randomised hold-out from the start, not added later. That is not process theatre. Transactional products have strong natural repeat behaviour, which means a before-and-after chart will show a lift that would have happened anyway. Without a control group you cannot tell marketing from seasonality, and you will end up defending a number you cannot substantiate.

• Primary metric per journey, decided before launch, not chosen afterwards from whatever moved.
• A hold-out large enough to detect the effect you actually expect, rather than a token 5%.
• Opt-out rate as a guardrail metric. A reactivation campaign that lifts transfers 3% while raising unsubscribes 20% has destroyed value, and it will not show up in a revenue chart for months.
• One variable per test. Timing, channel, or offer. Not all three, however tempting.

Why I am confident about this shape of problem

Because I have already run it. At Maya, a fintech app used by millions of small businesses in the Philippines, the same structure appeared in a different product.

That work brought back 245 dormant borrowers, worth ₱19.18M in new lending and ₱1.26M in service-fee revenue, roughly €310K and €20K. Small numbers next to Wise's, and that is fine: the mechanism is what transfers, not the scale. Give me a larger base and the same loop produces a larger number.

What I would need to check whether I am wrong

Everything above is inference from public reporting, so it should be treated as a set of hypotheses, not conclusions. Four things would confirm or kill them within a week:

• Second-transfer rate within 60 days of first settlement, split by corridor and acquisition channel.
• Distribution of gap-days between transfers, so I can see whether "periodic" is a real cluster or my assumption.
• What share of two-plus-transfer customers currently hold any balance, and how that share has moved.
• Current lifecycle message volume per user per month, and the opt-out rate by journey.

If the second-transfer rate is already high, hypothesis one is wrong and I would move straight to the balance journey. That is the point of writing the prediction down first.

Read teardown No 2: Figma, and the 675,000 customers nobody can call →