Cash & Liquidity ManagementPaymentsSTP & StandardsTowards a Single Standard in Financial EDI

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.

Emerging Standards Initiatives in XML

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:

  • UN/CEFACT TBG5 started a modelling exercise (never finished due to death of project leader Mike Adcock)
  • SWIFT entered the corporate-to-bank space with the new C2B message (first release published June 2003)
  • In the US, both IFX and the Open Applications Group developed new XML messages

    TWIST (the Shell-backed initiative, initially focused on FX and trade) entered the arena of commercial payments, specified requirements and modelled XML messages.

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.

Legacy Constraints

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:

  • new optional elements allowing the payer’s bank to offer an optional service
  • name and address and other text fields in local language characters
  • a specific value date for debit
  • various identifications of persons and organisations
  • payment in a foreign currency, amount specified in local currency
  • support for payment to a final party not being the account owner
  • support for payment on behalf of a party not being the account owner
  • cheque handling, delivery and cashing options
  • Withholding Tax information and certificate issuance
  • extension in size of existing data elements which can be truncated if necessary
  • increased space for name and address details
  • increased space for remittance details
  • increased size for identifications

In the implementation guides it will be made clear how compatibility with current systems can be realised.

End-to-End: Closing the Information Loop

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 payer sends a remittance advice: by mail, fax, e-mail or EDI (RosettaNet)
  • The payer’s bank generates and delivers a remittance advice based on the full details present in the payment order (global banks such as Bank of America, Citibank)
  • The payer uses a service organisation to generate and deliver a remittance advice based on a copy of the payment order containing full details (Philips)
  • The new payment messages support these scenarios by including delivery method and (electronic) address and a unique reference linking the payment order to the remittance information separately sent. As clearing houses and beneficiary banks will not be able in the near future to support forwarding and delivery of massive remittance details, inclusion of limited details is the basic solution. Only if the payer’s bank supports handling extensive details there is no limitation in the message.

Scope of Payment Messages

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.

Implementation Planning

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.

A Question of Timing

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.

Related Articles

Slow payment transformation risks shrinking margins further

Banking Slow payment transformation risks shrinking margins further

15h Jay Ashar
Access to funding the top priority for corporate treasurers today

Banking Access to funding the top priority for corporate treasurers today

7d Jay Ashar
Virtual Cards for Business Payments: What’s the Hold Up?

Payment Cards Virtual Cards for Business Payments: What’s the Hold Up?

1w Pat Bermingham
Removing friction in cross-border payments

Payments Removing friction in cross-border payments

2w Olivier Miet and Didier Balland
Mark Carney proposes a digital reserve currency

Blockchain Mark Carney proposes a digital reserve currency

3w Jay Ashar
EBA responds to issues raised by EBA API Working Group

Banking EBA responds to issues raised by EBA API Working Group

4w Jay Ashar
eBAM: the foundation for a successful finance team

Corporate to Bank Relationships eBAM: the foundation for a successful finance team

4w Austin Clark
SWIFT: The reality of real-time payment development

Payments SWIFT: The reality of real-time payment development

4w Austin Clark

Whitepapers & Resources

Are You Ready to Implement your GRC Solution?

Are You Ready to Implement your GRC Solution?

5m
TIS Sanction Screening Survey Report

Payments TIS Sanction Screening Survey Report

2m
The Challenges of Regulatory Reporting

Brexit The Challenges of Regulatory Reporting

8m
Mitigating Costs and Exposure - A Multilateral Netting White Paper

Mitigating Costs and Exposure - A Multilateral Netting White Paper

7m