Global Currencies is a Wise product that allows customers to send currencies to countries other than the one they are domestic to. For example, sending US dollars to a person or business in Hong Kong, rather than the USA.
It is quite common, especially for businesses, to operate in USD, GBP or EUR despite being based outside of the respective country of these currencies. In some countries, these bank accounts do not use the standard account details that a domestic account would, for example an account number and sort code in UK. Instead, these accounts are more likely to be addressed using an IBAN.
The Wise Platform API supports this product in version two of the quotes API. The key difference this API provides against version one is the ability to update a quote with a recipient before a transfer is created, using the Quote Update endpoint. If you set the ID of a recipient that represents an account of, for example, a USD recipient with an IBAN (i.e. an account with
"type": "swift_code") then the returned quote will be updated to represent we will not be sending these funds domestically in the USA and as such charge different fees.
Global Currencies are sent through the SWIFT network and will have multiple limitations. Wise has worked hard to reduce these as much as possible, but it's important to know the following:
Unable to Guarantee Full Amount
We cannot guarantee the full amount of the transfer will reach the intended recipient, regardless of the type of instruction (OUR or SHA). There is always a chance that a correspondent will remove a fee.
While the charging mechanism (OUR/SHA/BEN) is included and states the desire/intention of the sending bank, it leaves two issues:
- Intermediary and recipient banks can and may ignore or not support the specific type.
- The instruction can get lost if the transfer ends up moving through a local scheme that doesn't support it.
This issue is a fundamental SWIFT issue. It is also a big part in why Wise exists as a company.
Wise has continuously worked hard to provide the best experience around global currencies that allows partners to properly inform customers as much as possible. The details below highlight how to best create transfers for Global Currencies, when and how we smart-select OUR vs SHA, and how you can override that logic if required.
When offering Global Currencies, you must be sure to display a message to customers that there are potentially additional extra fees for this type of transfer. For example:
There are three cases where we will use the SWIFT network to send a global currency transfer. These will be delineated by the type of recipient and currency of the transfer.
- A USD recipient of type
- A GBP recipient of type
ibanwhere the IBAN does not start with
- A EUR recipient of type
swift_codewhere the IBAN does not start with one of the SEPA country codes (i.e. the transfer is to a non-SEPA country).
To create a global currency transfer, the process is as follows:
Create a Quote for the currencies you wish to send between, e.g. GBP to USD. If using Swift, ensure to set payOut to
SWIFTwhich will give the best estimate on the fees changed for the transfer.
Update the Quote created in step 1 with the ID of the recipient created in step two.
You will now see the
payOutfield of the quote to have updated to be of type
SWIFT_OUR, and the
paymentOptionsarray to have all options updated to also have a
SWIFT_OURand different fees.
At this point, a full quote in a supported global currency with the correct recipient type patched is available. You should ensure that the updated information in the quote is communicated to the user. You should also take note of whether
SWIFT_OUR will be used.
Selecting SHA vs OUR
Wise automatically selects SHA or OUR based on aggregated data, previous transfer experience, and machine learning. This ensures that we accurately deliver the full amount of Global Currencies transfers 93%+ of the time, with only 37% of those being sent through OUR. It also ensures that this consistently gets better over time, and is something we consistently work to improve.
Following the steps above will ensure most transfers will be received in full without sacrificing fees to always push transfers via
In certain cases, partners will want to force the use of OUR with SWIFT. This is possible, however it must be configured by your implementation team, so please reach out if you would like this enabled.
Once configured, you will be able to supply
payOut of type
SWIFT_OUR when creating the quote. This will force the quote to be generated with fees and be processed as