As the world moves towards a more global way of doing business, banks and financial institutions need the capability to move money around efficiently, transparently and in a cost effective manner and in doing so, ensuring that liquidity doesn’t get locked away. Cross-border payments however have historically been the opposite of this - with single payments costing upwards of $40 per transaction and taking five to seven days to settle. To meet the needs of today, payments need to be instant and much cheaper.

The benefits of SWIFT gpi

One way that banks are addressing the challenges associated with cross-border payments is by adopting the SWIFT gpi standard on the basis that they can make payments from one central location, rather than spreading liquidity among various correspondent banks across different countries. This central view gives banks a much more transparent view of their liquidity.

Additionally, by using gpi, payments that would typically have taken up to a week to settle can now be credited to end beneficiaries within as little as 30 minutes, and at a fraction of the cost of traditional cross-border payments. This is good news for corporates who make hundreds or even thousands of payments and transactions a day.

According to the SWIFT website, hundreds of the world’s leading cash management banks send over $300 billion via gpi every day, with thousands more pledged to implement the standard. However, adoption of gpi is not straight forward and there are many different routes to take, with pros and cons to each option.

The build argument

The first option for banks and corporates looking to use SWIFT gpi is to build their own internal system to handle gpi messages. The benefit to this of course is complete ownership and transparency of payment messages. However, it does come with a very real set of challenges.

If building in-house, it does not simply involve the integration between internal systems and SWIFT - there is the application of business rules and processes to consider as well. It is imperative to have an understanding of the collection of gpi messages - of which there are over 20 - and an awareness of an additional 10 or more statuses which indicate where a payment is in its lifecycle. Additionally, systems must be updated every year to comply with the annual SWIFT standards release. Then there is the challenge of migrating all gpi messages to ISO 20022 by the end of 2020. And last but not least, connectivity from legacy systems to the SWIFT network do not come without significant cost.

Another perhaps unintended consequence of the build option is yet more siloed systems. And, with the on-going drive to eliminate silos within banks there is a general consensus that having a central, unified payments system should be the way forward.

The buy argument

With the buy option, banks have the ability to purchase a SWIFT gpi solution ready to integrate into their own legacy systems. This eliminates some of the challenges associated with building in-house, but again there are some serious considerations to take into account before taking this route.

The main challenge with the buy option is centred around the integration with existing legacy systems, which can be very complex and time consuming. Once the integration is complete, firms must still contend with the on-going maintenance issues that are present with the build option, around updating changing messaging standards and connectivity costs to the SWIFT network.

Outsourcing 

At the other end of the spectrum is the option to outsource completely to a third party. The main benefit to this option is the reduction in manual intervention and back office processes, as the third party will take care of message reconciliation, only sending back the final message.

The first downside to this option is that it is often very costly, so it becomes an option only for tier one banks with very high volumes. Additionally, the rules of engagement can change. There have been cases in the market in which externalised services have changed the way they do business, causing a bank to quickly rethink how they operate. Given banks want to retain as much control over their own payments and processes as possible, this is certainly not ideal.

Collaborating with fintechs

A second option to fully outsourcing payments is to work with a technology provider to augment legacy systems with a “plug and play” solution. This provides a fast, cost efficient way to insulate existing systems, while also giving the organisation control and transparency over the payments processes. Another benefit to this option is the reduction in costs of on-going maintenance, as any updates and migrations are handled by the technology partner.

Questions to consider

Before deciding which option is right for your organisation, it’s important to ask a few key questions:

How will you handle the integration? It’s imperative that you or the supplier you choose really understands the dark art of integration. They must be flexible and have the ability to quickly integrate with your existing systems.

Can integration be done quickly? If the solution deploys an ecosystem of payments services built on modern technologies such as APIs, then deployment should be fast, as the technology will be agile and modern. 

How will you deploy the system? If you have chosen to build or buy your solution, it’s a good idea to consider cloud deployment, either your own or as a service from a technology provider.

Does the system offer additional capabilities? It’s important to look for technology that not only solves the immediate SWIFT gpi challenge, but that will also expand into other future forms of payment schemes and processes. The current pace of change is intense - with changing standards, migrations, new payment schemes being introduced... A system needs to respond quickly to allow you to take advantage of future payments innovation.

By answering these questions and having a clear understanding of your organisation’s needs, you should be in a good position to choose the right SWIFT gpi solution for you.