Payments
The objective of this review of the business processes around processing of commercial payments and working capital financing is the improvement of the overall efficiency and flexibility of commercial payments processing and related activities. Resulting from this review, TWIST has defined the requirements for a complete range of standard XML messages that will automate the processing by banks and their clients of commercial payments and working capital financing and allows for interoperable delivery of services.
Involvement of Key Market Players: Universal Applicability and Critical Mass
Seven banks, ABN-Amro, Bank of America, Citigroup, Deutsche Bank, HSBC, J.P. Morgan Chase and Standard Chartered Bank, have worked together with PeopleSoft, VISA, Mastercard and other industry experts that are members of TWIST to ensure universal applicability of the requirements.
Apart from ensuring universal applicability of proposed solutions, their involvement has been instrumental in ensuring the speed and thoroughness of the analysis, the neutrality of the design, and the critical mass that ensures the necessary implementation effort in the near future. This collaborative effort has further benefited from the knowledgeable input of various experts from professional services firms, software providers and corporations. The TWIST task force led by Ernst & Young and Shell aims at driving for one single, open and non-proprietary standard that can be implemented by any corporate and bank, irrespective of size, location or market position.
Requirements for New, Universal Standards
The payments workgroup was instigated as a response to many requests TWIST has received from corporates in the past two years. Multiple standards have emerged over the years, adding to the already existing complexity of multiple payment systems and processes across countries, payment types, banks and their branches, and corporations. In this context, TWIST was asked to focus attention on the manual processing and inefficiencies around payments processing between a corporate’s Accounts Payable and Accounts Receivable departments and the banks. TWIST obtained the support of corporates, banks, card service providers, ERP-system providers, cash management system providers and professional services firms to drive for universal solutions that are consistent with and can build on TWIST’s and other standard group’s activities.
The task force has investigated the root causes of today’s inefficiencies, reviewing existing payment standards and identifying additional messages that can be used to remedy the inefficiencies. By presenting the efforts in the form of requirements for standards, the taskforce explicitly solicits feedback and further input from other market players and standard organisations on process design, requirements and implementation issues. This ensures the universal applicability and essential neutrality of the open standards that can be defined as a result. It also allows for other standard organisations with which TWIST already has established an active relationship in the past half a year (SWIFT, CRG/Edifact, IFX, RosettaNet) to further embrace the drive for convergence and incorporate the updated requirements in the design of their own standards.
Current Situation: The Need for Improved Processes
In today’s environment, this process is not as efficient as could be and lacks transparency for those involved in the various process steps. Whereas payment processing is the processing of large quantities of messages involving highly standardised data, current practice is that across countries, across payment types, across banks and bank branches and across their clients the processes are not standardised. Multiple standards for payment formats exist which are implemented in various flavours. Apart from payment initiation messages and reporting bank statements currently few complementary standard messages exist that can support an automated communication of all processing between payment remitters, banks, payment beneficiaries and the relevant service providers involved.
Coverage
The requirements for the standards concerned span the following sub-processes:
- exchange of static data
- invoice handling (including disputes)
- issue remittance advice
- issue corporate payment instruction (electronic, direct debit, cheque, card)
- cancellations
- investigations and claims
- working capital financing
- service level management
- payment status information updates
- payment rejections
- payment repairs
- bank statements reporting
- debit and credit advices
The material aims to cover both domestic and cross-border payments.
The requirements for standards are intended to support multi-entity and multi-payment methods. This allows corporates to use the same payment process for financial and commercial transactions.
The requirements incorporate multiple payment methods, allowing corporates and banks to use the same process for the issuance of payments via electronic transfer, cheque issuance, direct debit, or settlement of payments via credit or debit cards.
The scope of TWIST’s efforts include guidance for implementation, including translation of existing formats into the new format as well as recommendations for using unique payment reference numbers when sending payments through inter-bank clearing channels. The group is also working on high-level requirements for security, authentication and authorization, intending to provide corporates with a minimum level of guidance with the application of existing market solutions.
Interoperability
TWIST believes strongly in the concept of standardisation to achieve effective straight through processing (STP) and interoperability. Interoperability means a process design, where multiple players can provide multiple services to their clients, depending on supply and demand for situations concerned.
Clients may need to depend on multiple service providers like banks to fulfill their needs. Clients would like to be able to obtain services from multiple sources if a single service provider fails to deliver.
As a consequence, multiple banks can offer solutions to clients with different scope (each bank offering the services they excel in, with the possibility to incorporate ‘white label’ excellent services from other suppliers as a seamless solution) which requires standards for effective communication, including a payment standard, to allow all service providers to provide the information they can offer and to allow all clients to obtain the information they need.
This does not automatically mean that all service providers should be able to provide all the data concerned. This solely depends on the individual service arrangements between clients and their banks and other service providers. This raises the need for standard messages that can be delivered by multiple providers.
Feedback
Version 1.0 of the requirements document was published on June 4th, 2003 with the objective of receiving input from the financial community. Over 60 banks, system and solution providers as well as consultancy firms requested the detailed material and many provided feedback. Version 1.1 of the requirements document incorporated this feedback, together with further elaborations on a number of issues.
Furthermore, an XML schema was created for the messages described in the document. This schema, in conjunction with the business requirements, is used as a basis for discussion with other standards organisations focused on convergence of standards for corporate payments and working capital financing.
In version 1.2, we have added the debit and credit advice message, the remittance advice message and the bank statement message to the schema. As these messages reuse data elements from the payment message, only the highest level of these messages is included.
In version 1.3, we have included invoice handling (invoice receipt, invoice dispute management) and we have expanded the sections on direct debits. We have revised the process flow diagrams to demonstrate the relationship between action and message.
Version 2.0 has only been released after a rigorous upgrade of the XML schema to achieve alignment with all other TWIST components (wholesale financial markets, bank charges) and even more relevant the outcome of the IST harmonisation project with IFX, SWIFT and OAGi with respect to the payment initiation and status messages. Besides adapting the schema, the level of granularity of the schema including attributes of and annotations to data elements has been increased.
Banks, corporations, software providers and consultants are invited to provide additional feedback on the material. The feedback can be given by sending an email to Tom Buschman at Shell or Steven Hartjes at Ernst & Young or Leonard Schwartz at ABN AMRO.The complete set of updated requirements and resulting standards will be published on this website.
TWIST Commercial Payments and Working Capital Financing Approach
TWIST has decided to use a business process approach to identify the subsequent steps in the workflow, determine the communication between parties involved in various steps, verify the availability of well accepted standards (such as EDIFACT- and SWIFT-messages) and identify the opportunities for additional messages in conjunction with multiple distribution concepts for some messages.
TWIST does not intend to prepare a detailed description of processes within a corporate, within a bank or between banks. The focus is on the key business issues and the communication between corporate and bank.
In many cases, a more detailed analysis of processes will identify exceptions to standard processes. TWIST endeavours to capture the variable elements in the message and does not intend to document the entire workflow.
TWIST has determined the following generic starting points:
- Whenever possible, standard format fields should be used to enable automated processing of the contents of a data field; free format text fields should be avoided as much as possible.
- A very restricted set of qualifiers common to all industries should be used to enable standardization across the industry.
- There should be no up front restrictions on size of data fields; whenever a data field is considered necessary, the size required needs to be determined per data field.
- Messages should be designed irrespective of the fact that there might not yet be a process to use these data fields. Supplying the data fields in the messages can also trigger the creation of additional or revised processes.
Current Limitations
In today’s environment, the processing of commercial payments is not as efficient as could be and the process is not transparent end-to-end. Where payment processing in fact is the processing of large quantities of messages involving highly standardised data, current practice is that across countries, across payment types, across banks and bank branches and across their clients, the processes are not standardised. Multiple standards for payment formats exist which are implemented in various flavours. Apart from payment initiation messages and reporting bank statements there are few complementary standard messages that can support an automated communication of all processing between payment remitters, banks, payment beneficiaries and the relevant service providers involved.
Apart from a highly dispersed development of payment process practices over the years, the root cause for limited efficiency for those who initiate payments and those who are the beneficiaries of these payments is the fact that in most cases payments have to be processed through legacy systems of several banks and clearing houses which has put limitations on the size of data that can be processed. This poses limitations on the information that can be sent together with the payment to the beneficiary and the information about the processing itself that involves multiple entities. To create some flexibility in the data that can be transmitted, free format fields are used.
The downside of free format fields is that they can not be properly used in automated processes as the content is not the same for every transaction. Typically, the information that uniquely identifies a payment for a company is not included in a standard format data field. As a consequence, the process of reconciling incoming payments to accounts receivable can often not be fully automated, thus creating additional cost for obtaining, interpreting and processing additional information.
The processing of payment transactions crosses various parties involved, both on the corporate and the bank side. At least three parties (two corporates that have the same bank), but in most cases four or more parties (each corporate and it’s own bank as well as clearing houses and sometimes forwarding agents and in several cases payment factories or in house banks on the corporate side) are involved in the transaction processing. Each process step can take time, certainly when payments can not be processed fully automatically. At present, the process between the moment of issuing the payment by the payer to the ultimate reception of the payment by the beneficiary/payee is not transparent for the corporates.
Finally, although the main components are the same, the payment process is implemented in various different ways using various software systems. Even within the same bank, multiple interfaces (both packages and bespoke customer-to-bank interfaces) are used, thus causing additional cost for investment and maintenance. In many cases, corporates and banks interface through bespoke software. This limits the possibilities for the corporate to change banks as the change-over cost are too high. It also limits the ability for a corporate to use those banks that are best at specific services. Although this might be regarded as positive by the bank from a defensive point of view, the banks are facing the downside of such practices as well. They themselves are facing (1) the extremely high costs of the lack of standardisation, (2) the inability to provide proper information to their customers about payments that are initiated with other banks and (3) their inability to provide specialised, value adding, services to customers of other banks. The awareness increases that providing excellent service levels and innovative solutions is more relevant and could put the bank into a better competitive position than attempting to lock in customers through expensive dedicated interfaces. A proper networking approach almost by default is the most efficient solution for a process that by its nature will always involve multiple customers and multiple service providers.
High-Level Solutions
The existing legacy infrastructure has posed limitations. Few companies have been willing to invest in standardized interfaces based on the EDIFACT standards. However, employing new technology such as XML increases the number of companies that become able and are willing to invest in redesigned processes as XML does not require the purchase of additional specialized software as it uses browsers and e-mail that are readily available on most computers as well as XML protocols that are becoming increasingly available for open communication between applications.
XML allows for secure and standardised transfer of data with both the sending and receiving system understanding clearly what data is transferred, what is expected to deal with it and what to do if it can not process this data.
With the cost of sending and receiving data significantly reduced, standards can be designed that incorporate several additional data fields. In XML all the possibly relevant data fields can be clearly defined as well as their interrelationships. This means that a message standard can incorporate all possible datafields very clearly and unequivocally. It can also describe how groups of data can be used for certain situations, leaving it to the individual situation which part of the standard is used. By reusing existing standards such as EDIFACT that have very clearly described data fields, while resolving some implementation issues such as the use of free format data fields, the transparency and consistency of interfaces can be improved. The ability to include a unique (corporate) transaction reference throughout the entire chain, by making optimal use of the data space available in a standardized format, largely enhances the transparency and efficiency of the payment process. By allowing multiple service providers to be involved in the process and making these an integral part of an inclusive design, the market will be able to offer the most efficient and fit for purpose solution for every situation. An example is the ability to send remittance information via multiple channels (e.g. fax, email, portal) and including in the payment message not only a reference to the remittance information message, but also how it has been sent and where it can be found.
The efficiency can be further improved by adding additional automated messages for specific situations such as rejects, repairs and cancellations. Tracking a payment through the processing chain and reporting on its status increases transparency. The choice between multiple date fields (e.g. requested execution date versus beneficiary bank due date) can help to increase the transparency of processing through the chain, without prescribing how remitters or beneficiaries should deal with their own banks.
By creating standardized interfaces between corporates and banking service providers (banks, clearing houses or card companies), over time, a limited number of software solutions can be used and the change over cost to move to a better performing service provider can be substantially lowered. Having a single global data format for the payment message agreed upon and supported by all banks and clearing houses/card companies will open the opportunity to have software vendors adapt their interfaces to the bank’s standard rather than the bank creating interfaces to support various software packages that have become a de facto standard in certain countries. By incorporating processing of electronic payments as well as payments via cheques and direct debits, the choice of payment method has been disconnected from the standardisation of payments and related processing data, reporting data and remittance information.
Implementation guidelines will be issued to avoid pitfalls of standards in the past that failed to provide the desired result at the moment of implementation by different banks and their clients.