Every Swift modernisation project starts somewhere different.

A fintech wants to launch cross-border payments. A bank is expanding into a new market and needs an additional BIC. A payments team is drowning in manual investigations. A technology team is questioning why so much effort goes into maintaining connectivity rather than building better payment products.

In each case, Swift is already part of the discussion. The question is how Swift connectivity should support the business going forward.

Connecting to Swift used to be a straightforward infrastructure exercise: select an infrastructure model, such as on-premise hardware or a service bureau, establish the connection, meet security requirements, and exchange messages. Today it is more complex. ISO 20022 is reshaping message standards, payment operations are increasingly interconnected, and institutions are under pressure to deliver greater visibility and automation across the payment lifecycle.

As a result, modernisation projects tend to involve more than replacing infrastructure. They require institutions to define the business outcomes they are trying to achieve, understand how payments move through the organisation, and determine how Swift activity will fit into broader payment operations.

This guide walks through the key decisions financial institutions face when modernising Swift connectivity, from defining the business case through to testing and go-live.

Before reviewing providers or onboarding requirements, ask a simple question: what are you actually trying to achieve through Swift?

This may seem obvious, but different use cases require different banking arrangements, message formats, routing logic, and operational workflows. Mapping these flows early ensures the infrastructure supports the broader commercial strategy.

For many institutions, the primary objective is supporting cross-border payments through the correspondent banking network.

When a UK-based EMI sends a high-value USD payment to Singapore, the instruction may pass through one or more correspondent banks before reaching its destination. Swift provides the communication layer, initiating the payment, confirming processing stages, and relaying status updates between participating institutions.

Critically, banks must explicitly authorise which counterparties can exchange specific message types, a process managed through Swift's Relationship Management Application (RMA). This authorisation is mutual: both institutions must declare each other before messages can be exchanged, meaning connectivity alone does not establish correspondent banking operations.

Institutions often use Swift as a standardised channel to interact with partner banks. This includes exchanging payment instructions, account statements, balance reports, and other cash management messages through a single connection rather than multiple proprietary channels.

Messages such as MT940 and camt.053 allow institutions to receive account statements, balances, and transaction reporting through a single channel rather than multiple banking portals or bespoke integrations. As the number of banking relationships grows, the operational benefits of standardisation become increasingly significant.

Accessing payment schemes does not always require direct participation.

Two institutions can share the same objective but face very different implementation journeys depending on their existing Swift setup.

For organisations building international payment capabilities for the first time, onboarding to Swift is often the first major milestone.

This involves establishing a formal relationship with Swift, obtaining a BIC, completing Know Your Business (KYB) requirements, and selecting a connectivity provider. Multiple stakeholders are typically involved, including Swift, the institution, connectivity providers, correspondent banks, and payment partners.

For newer fintechs and payment institutions, this stage is often as much about defining future operating requirements as it is about completing onboarding tasks. Decisions made here can influence how easily the organisation expands into new markets, launches additional payment products, or adopts future Swift services.

Growth is one of the most common reasons institutions revisit their Swift setup.

Entering a new market, establishing a new legal entity, or supporting additional payment schemes may require an additional BIC. In these situations, the objective is usually to extend existing connectivity rather than replace it.

An institution may choose to keep existing BICs on its current infrastructure while onboarding new entities through a different operating model. This can provide an opportunity to test new approaches without disrupting established payment flows.

Many modernisation programmes begin with an existing Swift environment rather than a new implementation.

Swift connectivity is not a single capability. Most institutions simultaneously send payment instructions, receive account statements, exchange investigation requests, and transfer bulk files across different channels and formats. Mapping these requirements early helps avoid unnecessary complexity later.

Cross-border payment instructions have now largely migrated from traditional MT messaging to ISO 20022-based MX messages, following the end of the coexistence period in November 2025.

However, MT messages have not disappeared entirely. Bank file and message formats such as MT940 account statements continue to be used for treasury operations and account reporting, and some bilateral or domestic use cases may still rely on MT messaging. For this reason, most institutions modernising Swift connectivity need to support both MT and MX formats, even as MX becomes the default for cross-border payment instructions.

Much of the industry's current transformation is centred on richer and more structured payment data.

InterAct and FINplus are used to exchange MX messages, the XML-based formats that underpin initiatives such as Cross-Border Payments and Reporting Plus (CBPR+). The shift introduces more detailed information about parties, accounts, payment purpose, and regulatory requirements.

For operations teams, this can improve transparency and reduce investigation work. For technology teams, it introduces new considerations around data mapping, validation, storage, and downstream system compatibility. Institutions that define their CBPR+ scope early tend to avoid costly integration rework later.

Not every interaction on the Swift network happens message by message.

Joining the Swift network does not automatically enable communication with every participating institution. Institutions also need to establish the relationships, permissions, and settlement arrangements that govern how messages and funds move between counterparties.

Before most operational messages can be exchanged, institutions need permission to communicate with one another.

Relationship Management Application (RMA) permissions provide that control mechanism. They determine which institutions are authorised to exchange specific categories of messages and help prevent unwanted or unauthorised traffic across the network.

This becomes particularly important in correspondent banking environments where institutions maintain multiple banking relationships. A bank may permit one counterparty to exchange payment messages while restricting another to account reporting or liquidity management activities. As banking relationships evolve and payment corridors expand, RMA permissions often need to be reviewed and updated alongside the wider connectivity setup.

Supporting a currency requires more than the ability to exchange messages.

International payment flows rely on correspondent banking relationships that provide settlement capabilities, liquidity arrangements, and access to specific currencies. A payment institution may have Swift connectivity in place, but without a correspondent capable of settling USD transactions, it cannot offer USD payments to customers.

When institutions modernise Swift connectivity, they often review these relationships at the same time. Expanding into new markets, supporting additional currencies, or launching new payment products can all require changes to the banking network that sits behind the messaging layer.

Once settlement relationships are established, counterparties need a consistent way to communicate where funds should ultimately be settled.

For many years, Swift connectivity was largely about message exchange. Over time, payment operations teams needed better visibility into transaction status, faster ways to resolve issues, and more consistent information across banking partners. Swift's Value-Added Services were introduced to address these challenges.

The question is not simply whether these services are available. It is how they fit into day-to-day workflows and whether teams are equipped to make use of the information they provide.

Few questions generate more operational effort than: Where is the payment?

Swift GPI was introduced to improve visibility across correspondent banking networks. By assigning a Unique End-to-End Transaction Reference (UETR) to each payment, participating institutions can track its progress as it moves through the network.

For operations teams, this can reduce the time spent investigating delayed payments. For customer-facing teams, it can significantly improve the customer experience, particularly when a payment is delayed, by enabling clear, proactive updates rather than vague reassurances. The value, however, depends on how that information is surfaced internally. Tracking data is most useful when it is available within operational systems and workflows rather than requiring teams to search for updates manually.

Payment investigations are a routine part of international payments, but the way they have historically been handled has rarely been consistent. Beneficiary details may be incomplete, a sanctions query may require clarification, or a receiving institution may request additional information before funds can be released. Without a common framework, these interactions typically relied on a mixture of messages, emails, and phone calls.

Swift's Case Management service introduces a structured approach to investigations and exception handling. This is becoming a compliance requirement as much as an operational improvement. From November 2026, institutions will need to exchange cancellation requests through Stop and Recall and receive structured investigation requests through Case Management, with full enforcement following in November 2027 as legacy MT-based investigation messages are retired.

Given this timeline, institutions need to think beyond compliance and consider how investigation workflows will be managed, tracked, and integrated into day-to-day operations.

With connectivity in place, banking relationships established, and Value-Added Services enabled, the next consideration is how Swift activity connects to the rest of the organisation.

Messages entering and leaving the Swift network interact with customer channels, internal ledgers, compliance systems, reconciliation processes, liquidity management tools, and operational teams. The challenge is ensuring that information can be used effectively once it arrives.

Customers rarely interact directly with a Swift message, but the journey that leads to one involves multiple systems and decision points.

Payment instructions typically originate in a banking application, treasury platform, or ERP system before being validated, enriched, and transformed into the appropriate message format. The more automated this process becomes, the easier it is to maintain consistency across payment types, currencies, and banking relationships.

Visibility does not end once a payment is submitted, and for operations teams supporting multiple correspondent banks and currencies simultaneously, that ongoing visibility matters considerably.

Information such as UETRs, status updates, and investigation responses can help create a clearer picture of where payments sit within the lifecycle, provided that information is surfaced through operational systems rather than remaining within the messaging layer.

Every payment environment generates exceptions.

Messages can be rejected, information may be missing, and counterparties can raise investigation requests. As payment volumes increase, processes that rely on email chains, spreadsheets, and manual intervention become increasingly difficult to scale.

By the time an implementation reaches testing, most major decisions have already been made. The focus shifts to validation: ensuring that people, processes, and systems behave as expected once real transactions begin flowing.

Successful testing goes beyond confirming that messages can be sent and received. Institutions need to validate that payment instructions are generated correctly, responses are received as expected, downstream systems react appropriately, and operational teams respond correctly when exceptions occur. Testing these scenarios early surfaces issues that are not visible when looking at connectivity alone.

Correspondent banks, sponsor banks, payment schemes, and market infrastructures may each have their own validation requirements before production traffic can begin. This process, known as homologation, confirms that message structures, routing arrangements, permissions, and operational procedures work correctly across all participating organisations. This stage often takes longer than institutions initially expect, with coordination across multiple parties required before final approval is granted.

Technology readiness is only part of the equation. Teams need to understand how payments will be monitored, how investigations will be managed, how reconciliation will be performed, and how incidents will be escalated. The first payment investigation or reconciliation break should not be the moment a team encounters a process for the first time.

For institutions migrating an existing BIC or replacing legacy infrastructure, cutover planning is critical. Some organisations take a phased approach, moving payment flows gradually while monitoring performance. Others execute a defined cutover window. Regardless of approach, most institutions run controlled production testing with small-value transactions before moving significant volumes, validating routing, settlement, permissions, and operational monitoring before full production activity begins.

Modernising Swift connectivity is rarely a single infrastructure decision. Whether the journey begins with joining the network for the first time, migrating away from legacy infrastructure, or expanding into new markets, connectivity quickly becomes one part of a broader discussion involving banking relationships, message formats, operational workflows, exception handling, and reporting.

As a certified Swift Business Connect enabler, Mambu Payments supports financial institutions throughout this process, including Swift Alliance Cloud onboarding, migration planning, and fully-managed access to Swift connectivity. Swift activity can also be integrated into the wider Mambu Payments Hub, helping institutions manage cross-border and domestic payment operations through a single orchestration layer.

If you are evaluating your Swift modernisation strategy, explore our technical documentation to learn more about the onboarding process, supported communication channels, and implementation options.

Alternatively, start a conversation with one of our payments experts to discuss how Swift connectivity fits into your broader strategy.