One of the most common questions I am asked in my role as head of the Treasury Consultancy Service at AccessPay is, “Should we invest in a treasury management system (TMS) that includes bank connectivity, or keep the TMS and connectivity separate?”
There is no single starting point for these conversations. Some organisations already have a TMS handling connectivity, but the service is poor; some are evaluating TMS options for the first time; others want bank connectivity first but are concerned about the long-term implications if they need a TMS further down the line.
In this piece, I explain why bank connectivity is important, explore common customer scenarios when considering connectivity, and present the case for why a hybrid model that treats the TMS and bank connectivity as distinct layers is often the best approach, regardless of the starting point.
What is bank connectivity, and why is it important?
Bank connectivity is a reliable, automated connection between the TMS, other payment-generating systems, such as enterprise resource planning (ERP) systems or payroll systems, and the organisation’s banking estate. It enables the routing of clean, structured payment data and bank statement information.
Often, it is assumed that connectivity is provided as standard within a TMS. In reality, in-built TMS connectivity is typically limited, and long, custom extension projects are required to integrate the TMS with banks and other systems. In contrast, a specialist connectivity solution treats bank integration as a separate, standalone layer within the architecture. It is system-agnostic, and full multi-bank connectivity can be established in a matter of 4 – 12 weeks.
Three common customer scenarios
For any treasury team evaluating TMSs and/or reviewing their connectivity strategy, a key decision is whether to opt for a TMS including connectivity or adopt a decoupled approach, keeping treasury infrastructure and bank connectivity separate.
The starting point for this decision naturally varies depending on the organisation’s existing architecture and treasury priorities. However, across customer and prospect conversations, we most commonly encounter three scenarios.
Scenario one: Organisation with a TMS, including some connectivity
These are typically larger organisations that have extended their TMS to connect to their banks. However, the embedded connectivity is limited, and each request to add a new bank, entity, payment scheme, or system triggers a new integration project.
Often, the high costs and extended time-to-value associated with these integration projects mean they don’t always receive approval, and treasury teams consequently end up running parallel payment processes that blend automation and manual steps. They also spend significant time acting as a support function for the Accounts Payable team or Shared Service Centre (SSC) to troubleshoot payment issues.
Scenario two: Organisations evaluating TMS offerings for the first time
These are businesses that are just on the threshold of requiring a TMS. At this stage, the TMS needs to meet core functionality requirements, but it doesn’t require all the bells and whistles a larger enterprise might need. Connectivity, however, is a must to support payments and statements for the SSC. The treasurer’s dilemma is whether to get a TMS that can do both things or to keep the TMS and connectivity separate.
On paper, the bundled option looks more attractive because it reduces the number of suppliers, appears to keep things simple, and is assumed to be less expensive. Yet, as scenario one demonstrates, the bundled approach presents long-term challenges for scaling businesses; not least, it makes it difficult to add new banks, payment types, and other systems to the infrastructure without triggering costly integration projects.
Scenario three: Organisations not ready for a TMS, but evaluating connectivity
These are typically medium-sized businesses that recognise the benefits of bank connectivity solutions within their current infrastructure but are concerned that adopting connectivity first might cause problems when the business reaches the stage at which a TMS is required.
The benefits of a hybrid model
In each of these scenarios, adopting a hybrid architecture that treats the TMS and connectivity separately is the best approach.
Firstly, each element can focus on the job for which it was designed. The TMS handles key treasury functions, including cash forecasting, FX management, risk management, investments, debt, and accounting, as well as initiating high-value treasury payments, which are passed to the bank via the bank connectivity layer.
The connectivity layer, for its part, manages the banks, providing payment routing, statement retrieval, format normalisation, ISO 20022 complexity handling, and connection maintenance. As a result, the business has a platform built for operational payment volumes, rather than a treasury system stretched to accommodate them.
Secondly, the hybrid model is significantly more flexible than embedded connectivity in the TMS. If a new bank, payment scheme, or entity needs to be added, it can be done easily through the connectivity layer, using prebuilt bank connections. Where a prebuilt connection is not available, the expertise is in place to create a custom connection.
Additionally, if the organisation changes ERP, TMS, or any other system provider, the connectivity layer ensures that only the relevant system is affected and the connections between systems and banks remain live, eliminating the risk of vendor lock-in or loss of automation. This flexibility pays dividends in each of the scenarios above and should particularly provide reassurance to treasurers in scenario three.
The hybrid model in action
AccessPay’s work with global multimedia company ITV and international glass manufacturer NSG Group demonstrates the efficacy of the hybrid model.
For NSG Group, adopting bank connectivity as a standalone layer initially enabled the treasury function to automate payment and statement feeds and later underpinned the development of a payments factory. Such was the success of the hybrid model: NSG saved thousands of hours automating payments and statements, and the group no longer had to invest in a second building at its SSC in Poland because the existing team could absorb the work without adding headcount.
Meanwhile, as head of treasury operations at ITV during AccessPay’s implementation, I had direct experience of how treating bank connectivity as a separate layer transformed treasury workflows and reaped significant time savings. It allowed ITV to centralise several finance functions, including payroll, supplier payments, treasury payments, and cash management, and, in doing so, meant finance and treasury saved 25 hours a week just by cutting out manual payment and bank statement processing.
Making the case for decoupling connectivity
Three different starting points, all with the same answer. When each system does what it was built for, the TMS for treasury processes and bank connectivity for secure routing of payment and bank statement information, treasury leaders have a platform that scales, freeing up operational capacity and providing the ultimate flexibility with treasury architecture.
