Towards a Single Standard in Financial EDI
The realisation that Internet-based technologies can provide a platform for the development of a single standard for communication between banks and corporates has helped create a new impetus in the field of financial EDI. A once neglected area is now crowded with new initiatives, so much so that banks have sat up and taken notice, even to the extent of encouraging co-ordination between standard-setting groups. This article will look at the practical benefits that the new financial EDI initiatives offer the corporate treasurer and examines the work that must be undertaken on all sides before the promises can be realised.
Across many fields, commercial or otherwise, XML (eXtensible Mark-up Language) has provided an opportunity to create flexible but standardised data transfer formats over the Internet. In the payments sphere, a number of groups grasped this opportunity with a view to setting standards for Straight Through Processing, including the automated processing of collections and receipts:
Most initiatives were heavily supported by the banking community, less so by corporates. In the sub-working groups of UN/CEFACT TBG5, (the banking and finance group within TBG, the International Trade & Business Procedures Group) corporates – including IKEA, IBM, Ericsson, Shell, Norsk Hydro, P&ONedLloyd, Philips – analysed existing bottlenecks in the processing of payments (the so-called Future Group) and refined Message Implementation Guides (MIGs) in order to reduce the different implementation variances (in the Corporate Reference Group). The results of these analyses have been used in the improvement of the new payment messages in those standards groups where corporate representatives were involved.
As it became clear that these separate message development initiatives would not lead to a single standard, major banks put pressure on the organisations involved to combine their efforts. The result is the International Standards Team, where representatives of SWIFT, IFX, OAG and TWIST have worked together to come to a ‘harmonised’, global payment message standard. The outcome of the IST’s deliberations will be adopted by SWIFT to produce and publish the final standard, create the XML messages based on the ISO-approved repository and produce the required documentation (MIGs). All other standards organisations will include the SWIFT-approved results in their standards portfolio.
Definition of new data fields – but also extending the size of existing fields – is limited by the capabilities of the banks that have to process these data elements. If an extension is only to be processed by the first bank, this bank can decide to extend its processing capability as an extra service offering. But if the extension has to be processed by clearing houses or beneficiary’s banks, the consequence of an extension is too far reaching (in time and effort).
The IST has proposed the introduction of a number of extensions:
In the implementation guides it will be made clear how compatibility with current systems can be realised.
Most initiatives have focused on STP from payer to beneficiary, including information for the reconciliation processes in both Accounts Payable and Accounts Receivable. In practice, different scenarios are already in use to forward the remittance data / specification to the beneficiary:
The new payment messages support all payment types: both commercial and treasury payments; through low and high value clearing; domestic and cross-border; cheque variants; and electronic funds transfer. In the message implementation guides, it will be clarified which elements are applicable or required for which situation. Payments can be grouped (as in single debit, multiple credit transactions) or submitted as individual transactions. IST will also develop direct debits as a derivative of the payment message. Status messages provide detailed feedback to the payer on progress and reason to reject. These status messages refer to an unique transaction identification. Advice messages will be developed to provide detailed information on the transactions debited and credited to the bank account, assisting in the automatic reconciliation of payments and receivables with open invoices. Defining a message format is only half the work; clear MIGs are absolutely required to prevent implementation variances.
Messages are a means of communication. It is no use sending a message in a new format while the receiver is not equipped to receive and process the message. So both corporates and banks must agree on a plan when the new messages can be used. For both sides, a clear business case is required to spend time and money for this change.
For corporates, the main advantage will be the use of XML, which is easier to implement and cheaper to maintain than EDIFACT. The new messages support new services when offered by banks and higher STP rates. For banks the situation might be more complex, as making full use of the capabilities may require upgrading or even replacing legacy systems. But banks have made it clear that they want to get rid of the current different ‘standard’ messages and want to offer and support a single interface. Receiving and interpreting the new messages is a first step, which requires translation to existing internal file formats. A next step will be the support of new functionalities, offering new services to customers. Centralised settlement systems (ACH, PE-ACH, TARGET2) can also play an important role in the first step, by implementing the new message interface and acting as a gateway.
But demand will be built by clients asking their banks to facilitate access to the new interface. Industry-groups like RosettaNet will ask banks to implement the new XML message standards. ERP vendors like SAP and PeopleSoft will implement the new standard in new releases, enabling their customers to employ a single XML interface with their banks without conversion tools. Banks capable of processing the new messages should be in a favourable position!
Most large corporates already have XML capabilities in-house. Introduction of a new message format replacing EDIFACT is not a big effort for these firms. But a change without proven added value will difficult to be approved. As we have seen, the capabilities of the new messages being supported by the banks can add the value, thus stimulating the change to the new message standard. Once the new message standard is widely implemented, savings can be obtained by eliminating bank-specific interfaces.
As a result of the work of the International Standards Team, the new payment, status and advice messages will be freely available mid-2004, inclusive implementation documentation. Software vendors, banks and corporates will need time and money to develop the interfaces. Budgets must be allocated for these projects. So in practice the first implementations will be in the last quarter of 2004, but more realistically early 2005 should be seen as an achievable target.