BankingCorporate to Bank RelationshipsBank-to-corporate Connectivity: The Next Stage

Bank-to-corporate Connectivity: The Next Stage

Bank-to-corporate connectivity has often proven to be the biggest hurdle in enabling straight-through processing (STP) in treasury and cash management across organisational boundaries. All too often there are manual processes involved in getting payment instructions to the bank as well as in updating the cash position with information from the bank. Communicating with banks is a technical issue and, as a result, it is often not well understood by professionals in treasury or cash management departments.

Structure of Communication

When considering sending payment instructions to banks electronically and receiving bank statements in an electronic form, there are two basic aspects to consider:

  1. The format of the messages.
  2. The physical delivery of the messages.

Additional aspects to consider are the encryption and signing of the data, especially the payment instructions.

Message Formats

For a system to interpret the data being sent or received, it has to use certain formats for this data. Most of the principles in this area are national formats that follow country-specific requirements and rules often set by the national clearing houses. This does create complexity for larger corporates who are likely to have bank accounts in many countries and therefore have to produce many different formats depending on the location of the bank account.

There have been attempts to create international and universal standards such as EDIFACT. These are used to a certain extent but so far so no other international format has been established. SWIFT’s FIN messages are perhaps the most common format used internationally even though it is a SWIFT proprietary format.

Even when international standards are used, they are often not implemented in a consistent way. Banks implement these messages in their own way to enable them to provide extra services for their corporate customers. In addition, national requirements concerning content of payments have also led to a pollution of standards. Consequently, corporates using an international standard find that they still have to implement different variations depending on country and banking partner.

In the last few years, a number of initiatives, such as TWIST and CAST, have been started by different groups to solve these problems and regulate formats. The latest example of an attempt to create an international format for bank communication is ISO 20022. There are high hopes for this standard within the industry due to its use of XML to carry the information, which most systems already support. This is also the choice for the single euro payments area (SEPA) format for euro payments. SEPA payments instruments will use a subset of ISO 20022 that should encourage wider use of this format.

When systems first started to generate payment formats and read electronic bank statements, they were hard coded within the software, which is why it was difficult and expensive to make changes. Now most data goes through customisable mapping tools on the way in or out of the system. This makes it easier to change or amend formats as well as other functions, such as adding extra information in a text field or free format field.

Bank Connectivity

When it comes to electronic connectivity, various alternatives are available including:

  • Single bank workstation in the company.
  • Service bureau.
  • Direct communication with bank via FTP server, HTTP server or VPN connection.
  • Internet banking portal (which is the modern version of the single bank workstation).
  • SWIFTNet access via the SWIFT Alliance Access or SWIFT Alliance Gateway.

Even with one of the methods described above in place, communication with banks often involves manual intervention. Payment files are frequently produced in the ERP system or treasury workstation. They are then saved in a directory before being manually loaded into the bank workstation in order to be sent off, which is still not true STP.

With the use of FTP server, HTTP server or VPN connection for example, there is the possibility of communicating directly between the corporate’s ERP system or treasury workstation of the bank, without manual intervention. These are still not easy or cheap to implement and maintain because a separate interface is needed for each bank, which increases cost and complexity.

More recently it has become possible to communicate directly with a bank’s Internet portal, which has opened a simpler and cheaper way of achieving true STP for bank communication. However, this still doesn’t solve the problem of having to implement many interfaces when there are several banks concerned. As a result, many banks offer the service of acting as a hub for the sending and receiving of payment files and bank statements to and from other banks.

The same effect of single connectivity can be achieved through the use of a service bureau, which has the ability to connect to multiple banks. These solutions offer connectivity to many banks through one central installation. These products may offer a number of extra features including the ability to sign the payment files and encrypt the data.

Latest Developments

The biggest recent change on the communication side is SWIFT’s decision to further open access to SWIFTNet for corporates. In 1999, corporates were given access to SWIFTNet for exchanging confirmations with their banks in a programme called Treasury Counterparties (TR-CO).

In 2002, access was enhanced through the Member Administrated Closed User Group (MA-CUG), where a corporate could join SWIFTNet if a member bank sponsored it. The communication was limited to the sponsoring bank, but there were no limits on the messages that the corporate could exchange with the sponsoring bank. It was possible for the corporate to join several MA-CUGs and so use SWIFTNet for communicating with many banks. It was, however, expensive and cumbersome to agree with banks so the MA-CUG did not live up to the expectations at the time.

Since the beginning of 2007, most large corporates have had a new legal model for accessing SWIFTNet: Standardised CORporate Environment (SCORE). (The technical requirements to join all three access models are the same, although the legal model is different.)

Using the SCORE model, a corporate can access all participating banks with only one agreement in place. Furthermore, SCORE also lays down rules for the messages that can be sent within the SCORE framework. The exception to that rule is for FileAct messages, where the body of a FileAct message can contain any type of messages such as an EDIFACT or ISO 20022 format message.

There are high expectations that the introduction of SCORE will make it easier, cheaper and less risky for corporates to switch between banks because there should be no technical or format changes needed in switching banks. Also, SWIFT is now promoting corporate connectivity to SWIFTNet more than ever.

Conclusion

In the future, bank connectivity will not only be possible via SWIFT, as this will still be the domain of larger corporates. New alternative methods will be used for communication that use the Internet more, for example automatic up-and-download using a bank’s existing Internet web portal. This will lead to a decline in the usage of both the direct connectivity channels and the single bank workstation. The service bureau model will also be an important factor in the future. Many service bureaus will themselves use SWIFTNet for connectivity but take the hassle out of connectivity for corporate clients.

The use of the new ISO 20022 XML format promises one common format but whether this will become a reality remains to be seen. Already now, before SEPA starts, there are talks about local implementation of the SEPA format in different countries in Europe to fulfill local requirements for tax payments or regulatory reporting. This does not look promising for a common format for all banks and countries.

Many banks now openly admit that they no longer consider formats and connectivity as a competitive space but instead want to co-operate in this space, and use standards to reduce costs for their customers as well as themselves. The competition will instead be in the value-added services that banks sell to customers. The issue is that extra services often require additional information. The question is also whether banks can live with one standard format that doesn’t leave room for bank-specific enhancements.

Easier access to SWIFTNet for corporates is definitely a good sign that banks are serious about making corporate-to-bank communication easier. Time will tell whether these good intentions will also win on the format side. Even with SCORE there is room for special agreements between banks and corporates that can lead to a dilution of the formats used and, as discussed earlier, it does not look like that the SEPA format will be one common format for all European countries.

On the other hand, the requirement to handle multiple formats is now less of a burden for corporates. The mapping tools now available are high quality and that makes it easy to adapt formats to the needs and services offered by individual banks.

Comments are closed.

Subscribe to get your daily business insights

Whitepapers & Resources

2021 Transaction Banking Services Survey
Banking

2021 Transaction Banking Services Survey

2y
CGI Transaction Banking Survey 2020

CGI Transaction Banking Survey 2020

4y
TIS Sanction Screening Survey Report
Payments

TIS Sanction Screening Survey Report

5y
Enhancing your strategic position: Digitalization in Treasury
Payments

Enhancing your strategic position: Digitalization in Treasury

5y
Netting: An Immersive Guide to Global Reconciliation

Netting: An Immersive Guide to Global Reconciliation

5y