Swift explores cross-border payments using phone-number aliases

Lengthy bank details create friction before money even moves. On 28 September 2026, Swift introduced a pay-by-alias initiative exploring international transfers with familiar identifiers such as phone numbers and email addresses. Domestic approaches include Bizum, PayID and Pix. The work is a proof of concept.

The most visible part of the transfer

The customer idea is simple: find the recipient in a familiar way rather than transcribing banking fields. Behind that short identifier, however, the product needs an unambiguous answer about the destination. Matching the contact to the intended recipient becomes an important component of trust.

Imagine someone sending money to a relative overseas. They know the telephone number but not the bank behind it. A useful interface should help them establish that the right person has been found before they confirm the amount. Easier entry and confidence in the destination need to arrive together.

A simpler address is one part of the route

Removing fields from a screen does not remove the sender's need for a total price and a clear delivery promise. Recipient identification, currency conversion, checks and crediting serve different purposes. An improvement at the first stage should not automatically be attributed to every later stage.

A bank has a specific opportunity to measure the effect: how many customers abandon a transfer while entering details, and how often those details need correction. Those are more precise measures of an addressing innovation than crediting it with the full speed of international settlement.

Identifier lifecycle also matters. Telephone numbers change, saved contacts become stale and people may choose a different receiving account. The product needs a way to communicate those changes and confirm the destination without recreating the full burden of traditional bank details.

For now, the announcement describes a shared concept test. Everyday use will require defined available routes and terms. The meaningful development is that international-payment design is reaching the first click, where customers often encounter the complexity in the first place. The addressing layer is becoming a product problem in its own right.

What it means for banks and PSPs

For banks and payment providers handling consumer cross-border transfers, the idea touches several processes at once: the interface, recipient confirmation, fraud controls and support. Moving to an identifier such as a phone number raises the bar for how recipient details are displayed and protected against substitution.

• Measure today's share of transfers abandoned at the detail-entry stage and the number of returns caused by errors; that is the baseline for any later comparison.
• Check how the interface confirms the recipient and what the customer sees when a name does not match.
• Think through fraud scenarios: sending to a phone number is convenient for social engineering too.
• Ask partners how stale or reassigned identifiers will be handled.
• Decide which recipient details can be shown to the sender, given data-protection requirements.

What to watch next

The next meaningful step is the move from concept testing to participation terms: which routes, which domestic systems and which rules apply to errors and returns. Until then it is premature to build a product plan on the initiative, but funnel metrics and recipient-confirmation scenarios can be prepared now. That way, any effect of simplified addressing can be measured on your own data.

For smaller PSPs and fintech apps, the practical conclusion is not to build their own identifier directories now, but to follow which participants will offer this kind of addressing and what connection requirements emerge.