Swift SCORE Plus: Does the Case for it Stack Up for the Corporate Community?

As businesses globally assess what impact the changes to Swift’s cross-border payment transaction methods will have, Zanders’ Mark Sutton, Senior Manager Corporate Treasury Advisory, and Eliane Eysackers, Director, set out the history of the service and examine its pros and cons.

As the Swift MT-MX^[1] co-existence phase came to a soft ending in November 2025, ISO 20022 (MX) messaging became the main standard for cross-border payment instructions between FIs. The migration will see the majority of cross-border payments moving from the legacy Swift FIN network to the Swift InterAct (FINplus^[2]) network, with Swift providing an extension to the translation services where an FI has still not completed the migration to MX payment messages.

Furthermore, last year, Swift started a pilot that would also allow the corporate community to access the FINplus network under a new Standardised Corporate Environment (SCORE) Plus model^[3]. This article aims to demystify SCORE Plus as a possible additional or replacement Swift for corporates service and considers the key question – does it make sense for the corporate community to adopt?

Evolution of Swift for Corporates

The corporate community first gained access to Swift back in 1997 through the treasury counterparty model. This enabled corporates to receive the MT300 series messages covering FX confirmations. In 2001, corporate access evolved through the Member-Administered Closed User Group (MA-CUG) model. This enabled the corporate community to access the Swift FIN network covering the traditional MT-based messages in addition to the new Swift FileAct network, which supported file-based flows.

However, given the bank proprietary/bilateral nature of the MA-CUG model, this logically evolved into the SCORE model in 2006. SCORE offered the corporate community a more standardised and simplified implementation of the multi-banking model with access to both Swift FIN and FileAct networks.

Corporate adoption of Swift

From a corporate perspective, we have seen two primary adoption models:

• Swift FileAct only: under this corporate adoption model, vendor urgent and non-urgent payments, tax payments, treasury transactions, and in some cases payroll transactions are all sent to the cash management partner banks via FileAct. This standardised and secure file-based model simplified the corporate technology integration stack, with the flexibility to support both industry and bank proprietary payment, status reporting and balance and transaction reporting file formats. Importantly, performance wise, there was no material delay in the banking community processing urgent treasury payments under a file-based model, when compared with a separate Swift FIN network connection, with FileAct typically offering much richer file and transaction level status monitoring through the use of the ISO 20022 XML payment status report.
• Swift FIN and FileAct: this second corporate adoption model was typically linked to corporates that operated a TMS that only generated the Swift MT101 payment message. Individual treasury payments would be sent via the Swift FIN network, with vendor payments, tax payments, and possibly payroll transactions being generated within the ERP system and sent as a file using the Swift FileAct network. This adoption model required the corporate to subscribe to both the Swift FIN and FileAct networks.

Corporate adoption of XML messaging

An important point to underline at this stage is the corporate adoption of ISO 20022 XML messaging. A combination of the 2009 ISO standards maintenance release – commonly referred to as XML version 3, the underlying corporate motivation to simplify and standardise banking integration and finally the global industry collaboration – the common global implementation market practice group (CGI-MP^[4]), which published a series of implementation guidelines.

These factors all contributed to XML payment messaging going mainstream in the corporate to banking domain. As the XML payment message (pain.001) could support almost any payment method globally, the corporate community embraced XML messaging for vendor payments, payroll, urgent payments, tax payments, and treasury transactions.

XML messaging enabled the corporate community to at least standardise the file format for making payments across the multi-banking environment, with the associated benefit of richer file and transaction status reporting.

Introduction of SCORE Plus

SCORE Plus, which came on-stream last year, is being labelled as an enhanced Swift for corporates adoption model, which provides more detailed and structured data for payments and reporting, combined with real-time transaction tracking and management, offering corporates improved visibility into their payment life cycle.

However, this reference to improved data is directly linked to the corporate migration onto ISO 20022 XML standard from the legacy MT101 FIN message. As noted above, the corporate community adoption of ISO 20022 XML messaging is already mainstream – globally. Second, taking the current cross-border payment services into account, payment tracking is already available today through the Swift Gpi service^[5] which enables the tracking through to the beneficiary bank account being credited.

The table below (fig. 1) seeks to highlight some of the key differences between SCORE (FileAct) and the enhanced SCORE Plus solutions from a corporate community perspective.

FIG 1

What is the impact to the corporate community?

While the below table provides a simple overview of the key differences, it’s important to understand what this means in practice to the corporate community, as there are some significant considerations:

• XML Version 9 payment message: first and foremost, any corporate looking to adopt SCORE Plus will have to develop the new XML version 9 payment message (pain.001.001.09), which was introduced as part of the ISO 2019 annual standards maintenance release. While this SCORE Plus development will permit other domestic payment methods, which can be defined through use of the service level code, users are limited to sending just one transaction per file. This single transaction limitation follows the same logic as the legacy FIN MT101 payment message, despite the richness and flexibility of the underlying XML V09 payment message, which has almost 1,000 XML data tags.
• Business Application Header: in addition to developing the new XML V09 payment message, there is an additional Swift requirement to also include the Business Application Header (BAH), which contains sender and receiver information. The BAH is not required where the XML V09 payment message is sent under the traditional FileAct connection.
• Swift network validation: strict network messaging validation will apply to all SCORE Plus messages. While this might sound like a benefit, migrating to the new XML V09 message will logically and ultimately embrace the other payment methods that can be sent in bulk – so domestic non-urgent, instant, domestic urgent, tax, and potentially payroll transactions that will be sent via Swift FileAct. A key guiding principle of the CGI-MP group was data over-population, which both simplified the design and development of XML payment messaging, and also enabled a core multi-banking XML template to be agreed with core banking partners. This approach is particularly beneficial where a corporate maintains a global master vendor record, which typically contains both domestic clearing and international bank routing codes in addition to full address information. This approach allows more information to be provided in the XML payment message as part of an agreed template, with the originating banking partner accepting and ignoring any surplus data that is not relevant for the requested payment method. Although there does appear to be some flexibility under the SCORE Plus model, this is an area that needs to be carefully considered as part of any adoption decision in order to ensure messages that contain data over-population will not be rejected by the Swift network. This means the corporate community will need to closely review the published Cross-Border Payments and Reporting Plus (CBPR+) industry guidelines^[6] to determine any possible friction points.
• Remittance Information: SCORE Plus will support up to 9,000 characters of payment remittance information, however this can only be provided in either the structured or unstructured xml tags. Users are not permitted to use both structured and unstructured within the same payment message. This is in contrast to the Swift FileAct model, which will allow the corporate community to populate both structured and unstructured xml tags within the same payment instruction.
• Message Design: when the XML payment message was designed, it provided flexibility for the corporate community to decide whether to specify elements such as the payment method, ultimate debtor, and charge bearer code at batch or individual transaction level. This flexibility allowed for a more efficient payment message design as a file containing 10,000 non-urgent payments could be defined once using the service level code NURG at the batch level as opposed to 10,000 times at a transaction level. Now while SCORE Plus is crystal clear that only single transactions can be sent within each file, which removes any issue, this does mean the corporate community will need to design a completely different XML V09 message for the Swift FileAct flows adding additional complexity and cost.
• Status Monitoring: in terms of the status monitoring and tracking capabilities, SCORE Plus provides options, which translate into additional development. The first option is to use the new XML V10 payment status report, which, subject to partner bank capabilities, will incorporate the Swift Gpi end-to-end tracking for cross-border payments. Alternatively, or in addition to the payment status report, Swift will be introducing the new TRCK.004 payment tracking message, which will provide improved end-to-end visibility around cross-border payments. The new tracking message will be released as part of the November 2026 standards release (SR2026). Although this initially sounds positive, it’s important to remember that the Swift Gpi service enables tracking through the intermediate banking partners through to the beneficiary bank account being credited. Furthermore, the new XML V10 payment status report will still be required for the Swift FileAct flows whenever the corporate decision is taken to migrate to the XML V09 payment message. Ultimately, this could mean two types of status and tracking messages will have to be developed, contributing to the overall cost and time taken to complete any development.

Key questions corporates should be asking themselves

The first question is what is the reason behind considering SCORE Plus? If a business is currently sending the MT101 message via Swift FIN, there is currently no industry-agreed end date to the corporate community sending the MT101 payment message to partner banks. However, given the November 2026 end date for providing the unstructured postal address, this might require some fine tuning in the form of adopting Tag 59 option F. This Swift-agreed industry workaround permits the corporate community to send structured postal address data, subject to specific formatting rules. The Tag59F approach provides a light-touch way of achieving compliance as the actual development is limited to a field-level change in addition to some master data address clean-up work. And full compliance means providing the minimum mandatory postal address data requirements^[7] – city/town name and ISO country code.

Alternatively, the reason might be to replace the existing Swift FIN network connection with the new SCORE Plus network. If this is the case, it is important to consider whether there is an existing Swift FileAct connection to send payment messages. The benefit of potentially extending the use of the existing FileAct connection to also make cross border payments is twofold.

1. It removes the immediate requirement to develop the new XML V09 payment message, BAH and associated new tracking messages.
2. It now allows the consolidation of Swift services to just a Swift FileAct service and thereby reducing overall Swift membership costs.

Conclusion

SCORE Plus has been designed as a replacement for the legacy Swift FIN network. While the benefits are mainly associated with a corporate migration from the MT101 message to the new XML V09 payment message, this does not recognise that XML messaging is already mainstream within the corporate community – with Swift FileAct typically supporting a multi-banked file-based interface.

There are also alternative approaches to address the forthcoming November 2026 compliance deadline – both a light touch for MT101 users, while existing XML V03 (version 3) message users can add cross-border payments as a new payment method and configure either the hybrid address or full structured address and continue to send via Swift FileAct or bank proprietary host-to-host connection.

An additional material risk is the pending decision on whether corporates that adopt SCORE Plus will also have a mandatory requirement to keep aligned to the latest version of the XML payment message. Discussions are planned for December 2025, but if the decision is taken to force corporate users to align to the annual ISO standards maintenance release, this will create a significant cost overhead on corporate users, with questionable benefits.

It’s also important to note that the associated XML V08 bank statement (camt.053.001.08) is currently in pilot-only mode and is subject to release later this month. As the SCORE Plus network has a bandwidth limit of just 100Kb, this translates to approximately 250 transactions that can be reported per bank statement message. This limitation does not exist under the FileAct network.

So, recognising the typical cost pressures within the corporate domain, further internal questions must be asked before formalising a plan to adopt SCORE Plus. It’s important that an informed decision is made around this key architectural change, as it impacts the connectivity, messaging, and associated payments workflow.

Does the commercial business case really stack up, or is now the time to think about if and when rationalising the current Swift for corporates services makes sense?.