Why Bank Connectivity as a Service is better than traditional software

You can’t be in business without having a relationship with at least one bank. Every corporate has had to solve their bank connectivity, finding a convenient way to send payments to the banks and receive account information from the banks.

Some are using banking portals and tools offered by their banks. And for others, an automated integrated solution such as payment factory suits best their needs. The connections may vary from direct, bank-specific host-to-host solutions to regional standards like EBICS and solutions leveraging SWIFT for global reach.

I have been working in the corporate cash management domain for almost a decade, dealing with international payment traffic, security topics ,and bank and ERP integrations. I have followed closely how digitalization and the development of the SaaS delivery model, for instance, have changed the field of bank connection technology, too. Now, in my opinion, we have reached a state where the corporate-to-bank connectivity has become commoditized business.

Corporates choosing how to connect to the bank can either choose to buy the technology, that is as a piece of software, or they can purchase the bank connectivity as a service. In my expert opinion, the true advantages of the commoditized bank connectivity actualize when bank connections are offered as a service.

Carefully comparing the choices, I believe that most corporates today would benefit from choosing the bank connectivity as a service. Here are some of the reasons why.

You get plug-and-play connectivity

Let’s say a corporate whose payment traffic is very international makes the choice for connectivity via the global SWIFT network. The standard SWIFT Alliance Lite 2 solution ships with a piece of software and tokens, and optionally a VPN solution for connections. As you are clearly buying technology here, your IT department should be involved in order to determine the upfront infrastructure and investment needed for making the setup function, and to resolve for example where to host the setup and how to comply with all the requirements.

The option is to get the connectivity as a service from a certified SWIFT partner. If you go ahead and select an Alliance Lite 2 Business Application for your company’s payment processing or cash management, for instance, you get the SWIFT connection readily embedded with the cloud-based solution. In this case, accessing the global network of banks requires on your part only a few easy steps of joining to SWIFT and enabling your BIC code.

You pay for what you get

The next question is what do you want to pay for. When it comes to bank connection technology, you can either choose to pay the fixed capital expenses (CAPEX) of buying on-premises software or the variable operational expenses (OPEX) of buying the service from the cloud.

To twist the familiar phrase around, when you purchase your banking connections as a service, you “pay for what you get”. The price of your corporate-to-bank connectivity is transparent: the service is paid by the real usage and there are no hidden or major indirect costs.

The alternative is the ballooning costs of purchasing an in-house solution. The license for the connectivity software is just the beginning, as you need to acquire for instance the platform for the software, be prepared for the implementation costs, and also take care of the upgrades and maintenance.

You can stay out of the jungle of technical specifications

In my opinion, one of the biggest differences between the two choices emerges when we start talking about integration. Integrating technical bank control messages and banking protocols to the back office applications remains to be cumbersome. Those who choose connectivity as a service avoid working through a myriad of technical specifications and processes. The service operates on a higher level and hides the underlying complexity behind the contracts that techies like me call interfaces. The customer discussions can focus on payment types and formats needed to support the customer’s business.

You will have future-proof functionality

Now your bank connection software solution is up and running, and it’s time to ask how you are going to arrange the support of the solution. If you are operating in a global environment, the support is needed practically 24/7/365 for your cash flows and business to run smoothly at all times. Do you have the IT resources to monitor the in-house hosted connectivity round-the-clock and to provide application level support?

What about the internal service level agreement between your Finance, Treasury, and IT functions? Does it describe in detail needed availability metrics, disaster recovery, backing up the service, support windows, and ticket resolution, just to name a few? And most importantly, after all this work, do you know if your solution is actually built based on best practices? Are you also committed to keeping up-to-date with the bank regulation and development in technology in this area?

The service level agreement should at the latest get you convinced about the benefits of the modern as-a-service approach of banking connectivity, as all the questions above are answered in a standard package.

You don’t need to build a truck to drive it!

To sum up, think about this analogy for a while. If you needed to transport goods to your customers, would you build your own trucks from scratch by trial-and-failure? Would you maintain the trucks, upgrading to a more powerful engine when needed? And would you, in addition, take care of the development of the truck drivers’ skills according to the changing road regulation, in all the geographical areas you operate in?

I am quite sure that the answer to all of these questions is ‘no’ and that you would have bought all of this as a service – as modern companies tend to favor support processes as services. Why should the conclusion be any different if we switch the manufactured goods in this scenario into payments?