Skip to content

Release Notes

This section contains the current and historic changelogs for all Prowide library artifacts within the SRU2025-10.3.x distribution branch.

Notice this information is public, however, the Prowide Integrator artifacts are not open source, thus download and usage is restricted to licensed customers.


Versions compatibility

To keep the libraries up-to-date and compatible with the latest technologies and frameworks, we started the migration to Java 11 and Jakarta EE 10. To give all users time to migrate their systems, the existing versions will also be maintained.

The following table summarizes versioning for current releases, and the corresponding SRU and Java/Jakarta EE versions.

SRU Version ISO 20022 / SDK MX model Java Jakarta EE Status
2025 10.3.x 10.4.x SRU2026 11 10 Production until 12 June 2027
2025 9.6.x 9.6.x SRU2025 8 Jaxb 2 Production until 12 June 2027
2026 10.4.x 10.4.x SRU2026 11 10 Available around May 2027, live 12 June 2027
2026 9.7.x 9.7.x SRU2026 8 Jaxb 2 Available around May 2027, live 12 June 2027

The Version column applies to Prowide Core and the Prowide Integrator modules. The ISO 20022 / SDK column shows the Prowide ISO 20022 library and Prowide Integrator SDK versions, which on SRU2025 differ from the rest of the distribution.

Note

SWIFT postponed the SRU2026 go-live to 12 June 2027, but some market infrastructures and clearings, such as Target2, adopt the SRU2026 message versions in November 2026. To support them, Prowide ISO 20022 and the Prowide Integrator SDK SRU2025-10.4.x already carry the SRU2026 MX model and schemas, while Prowide Core, the other Integrator modules and the MT standards remain SRU2025. SRU2025-10.4.x and SRU2026-10.4.x are separate releases: the SRU prefix is always part of the version. See SRU2026 postponement.

SRU stands for the SWIFT Standards Release Update. It reflects the messaging standard the libraries are compatible with. Notice the middle version is normally updated along a SRU change. Check the Versioning page for further details.

As for the migration to Jakarta, overall, the migration process involves replacing the Java EE packages in your source code (javax) with their Jakarta EE counterparts (jakarta) and updating your application's dependencies to their Jakarta EE versions. The exact steps and level of effort required will depend on the specifics of your application and its dependencies. We believe that the benefits of these updates far outweigh any temporary inconvenience.