Currently only relevant to clients based in Singapore.
This guide details important updates to the data required for payers and beneficiaries. These changes are being implemented to enhance data quality, ensure platform consistency, and meet evolving regulatory requirements.
This guide describes breaking changes. Action is required to prevent service disruption. Please review the detailed changes and implementation timeline carefully to ensure your integration is updated correctly and on time.
As these changes are being rolled out in a phased approach, our Payment Guides do not yet reflect the new requirements. If you have been informed that you’re in-scope for these changes then the details provided in this article represent the accurate and applicable guidance for your account.
Implementation Timeline
Key Dates
| Date | Event |
|---|---|
| 13 April 2026 | All Payer & Beneficiary changes are available in the Demo environment for testing purposes. |
| 17 June 2026 | DEADLINE: All Payer & Beneficiary data changes become mandatory in Production. |
Detailed Chronological Breakdown
Now
- [Available] Payer: Address field changes are available for use.
- [Available] Beneficiary: Address field changes are available.
- [Available] Payer: A new field for Payer Account Number is available. Mandatory for clients on our Correspondent service model who pass payer details when making a payment.
13 April 2026
- [DEMO]: All payer and beneficiary changes are available in our Demo environment for testing. Please contact your Account Manager if you would like to be able to test the mandatory data changes in your demo environment.
17 June 2026 - ⚠️ MANDATORY ENFORCEMENT
-
[PRODUCTION]: The following rules will be enforced for all Payer and Beneficiary records when used in payments within the Production environment:
- Address fields become mandatory (where applicable).
- Stricter validation for character sets and field lengths.
- Unsupported fields will be rejected on specific payment routes.
Changes in Detail
The way you submit payment and beneficiary data is not changing. Requests will continue to be sent to the existing API endpoints, no URL or routing changes are required on your side. The changes affects only the data that must be provided, as detailed below.
1 New Fields
A new field for the payer’s account number has been introduced that should only be used by clients on our Correspondent service model who pass payer details when making a payment. It should be populated with the payer's payment account number, which is the unique identifier of the payment account from which the payment is made.
The field is available now.
| Field | API Endpoints | API Parameter Name | Description | Mandatory |
|---|---|---|---|---|
| Payer account number | v2/payments/create v2/payments/update v2/payments/validate | payer_ultimate_account_number | This is the payer's payment account number | Mandatory for clients on our Correspondent service model who pass payer details when making a payment. |
2 Changes to Existing Fields
2.1 Beneficiary and payer addresses
These changes are available now and will be mandatory from 17 June 2026.
| Field | API Parameter Name | Change | Notes |
|---|---|---|---|
| Beneficiary Address | beneficiary_address | This field should be used for the first line of the address only. |
Use the other address fields for the remainder of the address:
|
| Payer Address | payer_address | This field should be used for the first line of the address only. |
Use the other address fields for the remainder of the address: |
2.2 New character restrictions
The fields below will be transliterated to the Latin alphabet. You can start sending data in this format now, it will be strictly validated after the June deadline.
| Field Name | New Permitted Character Sets |
|---|---|
| Payer First Name | [a-zA-Z\/:().,'\r\n -] |
| Payer Last Name | [a-zA-Z\/:().,'\r\n -] |
| Payer Company Name | [a-zA-Z0-9\/:().,'\r\n -] |
| Payer Account Number | [a-zA-Z0-9-] |
| Payer Address | [a-zA-Z0-9\/:().,'\r\n -] |
| Payer City | [a-zA-Z0-9\/:().,'\r\n -] |
| Payer Postcode | [a-zA-Z0-9- ] |
| Payer State Or Province | [a-zA-Z0-9\/:().,'\r\n -] |
| Payer Identification Value | [a-zA-Z0-9\/:().,'\r\n -] |
| Beneficiary Company Name | [a-zA-Z0-9\/:().,'\r\n -] |
| Beneficiary First Name | [a-zA-Z\/:().,'\r\n -] |
| Beneficiary Last Name | [a-zA-Z\/:().,'\r\n -] |
| Beneficiary Bank Account Holder Name | [a-zA-Z0-9\/:().,'\r\n -] |
| Beneficiary Address | [a-zA-Z0-9\/:().,'\r\n -] |
| Beneficiary City | [a-zA-Z0-9\/:().,'\r\n -] |
| Beneficiary Postcode | [a-zA-Z0-9- ] |
| Beneficiary State Or Province | [a-zA-Z0-9\/:().,'\r\n -] |
| Beneficiary Identification Value | [a-zA-Z0-9\/:().,'\r\n -] |
| Beneficiary Nickame | [a-zA-Z0-9\/:().,'\r\n -] |
2.3 New field length limitations
From 17 June 2026, the fields listed below will be restricted to the length limits indicated.
| Field | Local (Regular) Routes | Swift (Priority) Routes |
|---|---|---|
| Payer First Name | 35 | 69 |
| Payer Last Name | 35 | 70 |
| Payer Company Name | 70 | 140 |
| Payer Account Number | 34 | 35 |
| Payer Address | 70 | 70 |
| Payer City | 35 | 35 |
| Payer Postcode | 9 | 12 |
| Payer Country | 2 | 2 |
| Payer State or Province | 25 | 35 |
| Payer Identification Value | 35 | 35 |
| Beneficiary First Name | 35 | 69 |
| Beneficiary Last Name | 35 | 70 |
| Beneficiary Company Name | 70 | 140 |
| Beneficiary Bank Account Holder Name | 70 | 140 |
| BIC Swift | 11 | 11 |
| Beneficiary Account Number | 34 | 34 |
| Beneficiary IBAN | 34 | 34 |
| Beneficiary Address | 70 | 70 |
| Beneficiary Country | 2 | 2 |
| Beneficiary City | 35 | 35 |
| Beneficiary Postcode | 9 | 12 |
| Beneficiary State or Province | 25 | 35 |
| Beneficiary Identification Value | 34 | 35 |
| Beneficiary Nickname | 70 | 70 |
2.4 New mandatory field requirement
From 17 June 2026, the following payer address fields will become mandatory for clients on our Correspondent service model who pass payer information when creating a payment.
- Payer account number
- Payer address
- Payer city
- Payer state or province (see note below)
- Payer postcode / zip code (see note below)
- Payer country
Payer state or province
The following countries require state or province as part of a valid postal address. The payer state or province field must be populated for these countries:
- Australia
- Brazil
- Canada
- China
- India
- Malaysia
- Mexico
- US
Payer postcode / zip code
Payer postcode / zip code is mandatory where postcode or zip code is used as part of the standard postal address format in the payer’s country. The countries below do not use a postcode or zip code as part of the standard address system. The payer postcode field is optional for these countries and may be left blank.
- Antigua and Barbuda
- Angola
- Antarctica
- Aruba
- Bouvet Island
- Benin
- Bolivia
- Bahamas
- Botswana
- Belize
- Central African Republic
- Chad
- Comoros
- Congo (Republic of the Congo / Congo Brazzaville)
- Côte d’Ivoire
- Cook Islands
- Cameroon
- Curaçao
- Djibouti
- Dominica
- Equatorial Guinea
- Eritrea
- Fiji
- Gabon
- Grenada
- Gambia
- Guinea
- Guinea Bissau
- Guyana
- Hong Kong
- Jamaica
- Macau
- Mauritania
- Qatar
- Rwanda
- Solomon Islands
- Seychelles
- Sudan
- Sierra Leone
- Somalia
- Suriname
- São Tomé and Príncipe
- Sint Maarten
- French Southern Territories
- Togo
- Tokelau
- Timor Leste
- Tonga
- Tuvalu
- United Arab Emirates
2.5 Rejection of unsupported fields for payment route
From 17 June 2026, we will only be accepting fields that are supported for the payment route being used. This change ensures that only the fields that are relevant to a given payment route are submitted to our network partners, improving data quality and reducing processing errors. The table below shows which fields will not be accepted.
3 Notification Messages
Payment notification messages currently use the Bank Account Holder Name as the beneficiary name. From June, routes that support Bank Account Holder Name will continue to use this field. Routes where Bank Account Holder Name is not supported will use Beneficiary First Name, Beneficiary Last Name and Beneficiary Company Name.
4 API Reference Documentation
The API reference documentation has been updated to incorporate these changes, including new error responses for cases where submitted data does not satisfy the new requirements.