core v.26.10.10-26.10.12
client v.26.10.6-26.10.7
New Features
Integrations
Convera prefund payments. Outgoing payments via Convera now support a prefund model with automated rail selection, including SEPA Instant for euro transactions and local rails for USD and GBP. A dynamic payment form adjusts the required fields to the destination corridor, such as mandatory purpose codes for AED transfers, with real-time status updates and automated refund processing.
Compliance
Travel Rule transfer emails. A new email template covers incoming transfers, and the outgoing transfer template is updated to give clearer transaction details for Sumsub Travel Rule verification. The incoming email shows the amount, asset, date and hash, while the outgoing email states the transfer direction. Both display the verification link expiration period set in the system configuration.
Improvements
Transfers
Nium beneficiary address requirements
-
International transfers paid out through Nium now always require the beneficiary's address, city and postcode, in line with Nium's requirement effective 22 October 2026.
-
The beneficiary city is a mandatory field on the transfer form for accounts that use this rail, and a transfer missing any of the three fields is declined before it is sent to the provider.
-
API integrations that submit such transfers without beneficiaryCity receive a validation error (422) and must start sending the field.
-
Batch upload templates for this method gain a mandatory city column.
-
Action required after deployment and before 22 October 2026: beneficiaries already stored at Nium without a city must be completed with the console command rbk-payments:transfer:nium:beneficiary-address, using the values provided by the white label.
Fixes
Transfers
SWIFT batch template purpose. The universal SWIFT batch transfer template now includes a purpose column, resolving validation failures for transfers to regions where a purpose code is required, such as the United Arab Emirates. Download the updated template so batch SWIFT payments are processed correctly.
ClearBank recalls and refunds. Inbound recall and refund requests from ClearBank and the core provider are now processed correctly, with the transaction direction aligned to the original payment. Users can resolve these requests through the interface, and any resolution issue shows a specific error message instead of a generic system failure.
Unlimit payee verification message. When Unlimit has no suggested beneficiary name, the web interface now shows the correct Verification of Payee (VOP) message instead of an incorrect name mismatch warning. Users are told the name could not be verified and are prompted to review payment details before proceeding.
OpenPayd sweep transactions. Internal sweep transactions for OpenPayd virtual accounts are now filtered out of the transaction history. Only primary incoming or outgoing payments and their fees are visible.
LITAS SEPA transaction parameters
-
The transaction parameter structure is now unified for LITAS SEPA Credit and Instant flows, giving a consistent data contract for recalls, returns and status reports.
-
Reason codes, additional information and originator details are stored in standardized fields across both payment types.
-
Transaction descriptions for incoming transfers now display specific payment references.
-
Existing transaction data is migrated automatically to the new format.
-
Empty parameters no longer appear in the transaction details.
Integrations
iFast FX internal transfers. Internal transfers between accounts using the iFast FX (iGB) integration no longer create duplicate credit transactions. Incoming webhooks for these transfers are now recognized as mirrors of existing transactions.
EqualsMoney integration
-
Provider fees are now correctly linked to their parent transactions.
-
All monetary amounts are processed with high precision.
-
Incoming webhooks from the provider now require HMAC SHA-256 signature verification.
iFast GBP SWIFT correspondent bank. For GBP SWIFT transfers through iFast Global Bank, users must now select a correspondent bank from a validated list, replacing the previous automatic bank assignment. Existing payment templates or automated requests for GBP SWIFT via this provider must be updated to include the correspondent bank.
CurrencyCloud duplicate refunds. Duplicate refunds are no longer processed for CurrencyCloud payments that were never completed or were already declined. Customer balances are no longer credited for failed transactions.
Compliance
Sumsub long transaction hashes. Long transaction hashes from Sumsub no longer cause background processing failures that prevented some transactions from completing. Extended transaction ID formats for various blockchains are now supported, improving stability and data synchronization.