Evaluating Corporate-to-bank Integration Models
The essence of ‘Treasury 3.0’ is to move the treasury department to the next level, creating a state-of-the-art organisation to support strategic business objectives. But chief financial officers (CFOs) are challenging their treasurers to transform treasury operations while reducing costs. This obvious conflict of objectives is hard to manage, let alone achieve. However, recent trends have emerged that are providing direction on how best to achieve this task.
Increasingly, organisations are moving towards centralising finance activities. This is underscored by the fact that 63% of respondents to the Citi Treasury Diagnostics benchmarking analysis have centralised working capital processes into shared service centres (SSCs). This changing role for treasury necessitates increased integration with company-wide working capital and supply chain management activities. More often than not, the treasury team uses a comprehensive treasury management system (TMS) solution to oversee working capital, intercompany funding/lending, and risk management, while the accounts payables (A/P) and receivables (A/R) teams use an enterprise resource planning (ERP) platform for processes involving procure-to-pay (P2P), inventory management, collecting receivables, and meeting payment obligations. Typically the TMS and ERP are provided by different vendors and thus require integration with each other, as well as to external banking partners.
With different technologies being used for treasury and non-treasury functions, the challenge is to find the best methods to integrate disparate corporate systems with banking partners. This article examines four traditional models that corporate treasury can use to integrate with their banks, reviewing the pros and cons of each, including important considerations for current model evaluation and determining next steps.
Before we examine the various models, it’s important to set them within the appropriate strategic context. Corporate-to-bank integration is about more than just connecting with banks. It’s about the ability of treasury to function as a new decision-making unit within the larger organisation and to better anticipate changes in the market and in the business, thereby supporting the objectives of the company as a whole. For example:
Ideally, treasury makes decisions based on the analysis of relevant data, aggregated and presented through appropriate systems and tools. Much, if not most, of this data is sourced from treasury’s banking partners, which treasury can then apply against existing in-house data.
Corporate-to-bank integration is first and foremost about the exchange of data between treasury and its banking partners. It is also about ensuring the exchanged data can be consumed by the receiving system – which is most commonly done by some form of data translation (e.g. converting BAI2 into an MT940).
As we review these models, we should bear in mind that corporate-to-bank integration is a subset of the organisation’s overall business-to-business (B2B) ecosystem. B2B integration is inherently complex, costly, and on-going. From the perspective of treasury, it is also a crowded playing field, as B2B integration invariably competes with other internal functional areas and business units for technology resource allocation and prioritisation. So, rather than taking a ‘do-it-yourself’ approach, treasury organisations may ask: Is there another (better) way? Can newer technologies and capabilities be brought to bear on these tasks? Can treasury integration requirements be met with cloud-based service offerings? What standards can be applied across multiple banking partners? How can I reduce my total cost of ownership (TCO) and improve productivity and efficiency?
With this context in place, we can now examine the four models for integrating with multiple banking partners.
The direct integration model means treasury can take advantage of a distinct means of exchanging data directly with each of its partner banks. For somebanks, this will mean a host-to-host or machine-to-machine information exchange using an agreed upon data communications protocol, such as AS2 or https. For others, an online or mobile bank cash management application may be used. Online banking channels typically provide treasury with some capacity for file upload and download. In some cases, faxes and/or telephone calls may still be used. Along with differing means of exchanging data, the direct integration model often includes a variety of differing data formats. For statement reporting, BAI2 may be received from one bank while MT940s are received from another. One bank may accept an iDOC and another EDIFACT. This traditional model is usually established as a company grows and expands operations in new markets and geographies.
This is an effective model. Data is exchanged with banking partners and treasury decisions and instructions are carried out. However, this models works at a cost. Resources are needed to operate and maintain each individual channel. As regulatory requirements change, new transaction options become available and new services are used. Treasury must oversee accompanying changes to the information security and encryption of their data, as well as changes in formats – even change to a different format. These efforts, combined with the need to apply changes to bank channels on an individual basis, mean some portion of available technology resources are dedicated to the tactical work of daily operations, maintenance, and upgrades. The technology is not available, or as available as it otherwise would be for more strategic projects.
The direct integration model typically results in a higher TCO than other models as the company leverages more and more banking partners. This is due to the resource allocations noted previously, along with the resources needed to integrate these banking information flows into the company’s financial applications. As a result, the direct integration model is most effective where there are relatively few banking partners. The integration cloud, consisting of data transmission and transformation services, is effectively insourced.
A second option is the concentration bank model. This model uses a single, lead bank to concentrate data flows from secondary banks into treasury. The concentration bank forwards payment instructions and collects status information and balance reporting data from the company’s ‘other’ banks and delivers this data to the company. The integration cloud is shifted to the concentration bank.
There is typically a significant implementation lead time to implement this model. The concentration bank must negotiate secure interfaces (often proprietary in nature) and support arrangements with each of thecompany’s other banks on behalf of the client. In addition, the concentration bank may need to prioritise and build new bank interfaces.
The concentration bank model has the advantage of using a single channel for corporate connectivity, resulting in reduced development costs. However, treasury is then fully dependent on a single bank for routing and distribution. The relationship with your concentration bank must be a solid, long-term one. There can be minor or even severe integration challenges (both technologically and operationally) between the concentration and nonconcentration banks.
Lower development costs do not necessarily result in any overall cost savings as the connectivity fees of the non-concentration banks are beingreplaced with increased fees from the concentration bank.
With this model, treasury employs the SWIFT network to exchange standard messages and data with its banking partners, as well as using standard formats for those messages. Integration becomes less about individual bank interactions and more about data integration to internal financial systems.
The SWIFT integration model shifts the cloud to the SWIFT service bureau. With more than 9,700 members, SWIFT can be viewed as a dedicated financial services cloud. Offering both standardised messaging (how data is exchanged) and message formatting (structure of the messages exchanged), SWIFT has registered more than 900 corporate organisations since 2003.
These organisations represent 30% of the Fortune Global 500 (source: SWIFT Corporate Forum 2011). SWIFT organisations no longer represent only the largest global companies. Although 29% have an annual turnover of more than €10bn and 24% have turnover between €1bn and €1bn, more than 47% of the organisations using SWIFT have a turnover of less than €1bn.
The essential argument for SWIFT isthat standardisation offers cost and efficiency gains that outweigh the required initial investment to convert to SWIFT, as well as ongoing TCO advantages when compared with the direct model. SWIFT, however, does not (yet) have a message format or standard for every financial transaction. Domestic payment formats such as US automated clearing house (ACH) or UK BACS do not have a corresponding SWIFT MT or MX message format.
There is still great diversity between banking partners on their ability, and in some cases willingness, to leverage SWIFT as a channel for corporate treasury. Finally, the technology requirements to leverage the SWIFT network can be daunting if attempted in-house, and therefore the largest percentage of corporations connect to SWIFT using an indirect means such as a SWIFT service bureau.
This model attempts to take the best of both the direct integration and SWIFT models by using each where most appropriate. As others have noted, treasury organisations will require one-to-one bank connectivity for some time.
Like the other models, the hybrid model retains the use of human interaction by treasury with a bank’s web portal and/or online banking application. It also includes point-to-point data connectivity between systems such as a treasury workstation (TWS) or TMS and the information reporting or payment initiation solutions of bank partners.
As noted above, SWIFT offers standards for both messaging and formats, and where appropriate and available, can enhance and improve corporate-to-bank integration. Yet because of the multiplicity of standards, banks still have some product/channel limitations and therefore a single integration method will not enable treasury to achieve comprehensive integration with its banks. A typical example is prior day and intraday reporting only being available to treasury in BAI2 format, but not as an MT940 or in XML.
Existing direct connectivity protocols, such as FTPS, SFTP, HTTPS, AS2, AS3, EBICS, etc, are likely less technically daunting for treasury’s IT resources. Finally, given that the overwhelming majority of corporate organisations have multiple banking partners, managing and maintaining the connectivity of this ecosystem needs to be considered. IT resources (in-house or via a service provider) are needed to implement, monitor/support, perform necessary maintenance/upgrades, and resolve issues.
The rapidly changing treasury technology market has created a range of integration options for corporate treasury to leverage. Because every company is at a different stage of its growth progression or centralisation of its treasury function, no specific model may emerge as an absolute best. One way to resolve your integration challenges is by leveraging the potential of both cloud computing service providers and the expertise of your financial service partners.