Cash & Liquidity ManagementPaymentsSTP & StandardsRecommendations for Harmonised XML Payment Standards

Recommendations for Harmonised XML Payment Standards

The International Standards Team Harmonisation (IST) working group, consisting of representatives from Interactive Financial eXchange (IFX), Treasury Workstation Integration Standards Team (TWIST), Open Applications Froup (OAGi) and SWIFT, started building a common XML payment standard late last September. Its efforts were launched in a session hosted by the Gartner Group and its recommendations have been reported to the banks that sponsored the effort: ABN AMRO, Bank of America, Citigroup, Deutsche Bank, HSBC, JPMorgan Chase, Nordea, Standard Chartered and Wells Fargo. In addition to the sponsor banks, Mizuho Bank in Japan has joined the sponsor banks and endorsed the findings. The nine recommendations cover actual formats, how to use them and governance processes intended to outlive the ad hoc IST effort. The full report, “Final Recommendations of the IST Harmonisation Team” (pdf file 3.2MB), is available and feedback from corporates is welcome; this article provides a summary of the recommendations.

Focused, Inclusive Process

The working group has a very focused mandate to develop a core kernel of payment instruction messages and responses in XML that can be used by themselves or in conjunction with other XML standards.

Three principles drove us:

  • Minimise the development, mapping and testing that both corporates and banks require to support the range of emerging XML business standards.
  • Maximise reusability across standards such that a supply chain can develop standards around the processes it is intimately familiar with while using a banking industry-accepted XML standard.
  • Provide clarity to the software vendor communities (ERP, EAI and treasury workstation), helping them decide what to support within their systems.

Although the selection of the four standards organisations that participated in the working group was based on an analysis of who had complete XML payment messages to leverage, the overall effort was inclusive. The involvement of OAGi brought an ERP-based perspective important to the effort. IFX and TWIST represent a broad spectrum of corporates, banks and vendors. SWIFT had developed XML based payment messages for both the corporate-to-bank and bank-to-bank arenas.

A significant portion of the banking community, not directly represented among the sponsors, was engaged through the SWIFT business validation process that followed initial message development. This process allowed several national banking communities to evaluate the content, comment on it and make modifications.

New XML Formats

The original mandate of the IST working group covered five messages: core credit transfer; core debit transfer; payment initiation status; bank statement; advice. Together these comprise the payment kernel that reflects an end-to-end business process – making a payment – that is common to treasury and commercial payments. The group vetted a business process model, based on the customer-to-bank modelling work SWIFT conducted. The model guided us in the review and creation of kernel component.

The Core Payment Kernel Flow

The core credit transfer initiation component (recommendation 1) can be used for single or multiple transfers. Its key features include:

  • Support for a multiplicity of cross-border and domestic payments, including cheques and drafts.
  • Representation of multiple parties to the payment (accommodating such scenarios as use of a share service centre or payment factory)
  • Presence of a specific end-to-end reconciliation reference that is intended to flow from initiation through reporting for most payment instruments.
  • Ability to report amounts in both the currency of the account of debit and the actual payment
  • Available fields for both intermediary banks and non-bank accounts (such as Building Society accounts in the United Kingdom or a brokerage account).
  • A basic, minimal, remittance capability. Although the kernel’s intent is to be used with other standards, such as supply chain remittance standards, a minimum level was needed where the other standards are not used.
  • A basic central bank reporting capability. This component is likely to evolve over time. Variations in requirements globally make this one of the hardest aspects of creating a common payment format.
  • Withholding tax reporting intended to be used when tax data must accompany a payment.

An early objective of IST effort was agreement upon the elements needed to support credit and debit transfers in a single payment message. The core debit transfer initiation component (recommendation 2) can also be used for single or multiple transfers. All of the structures within the core debit transfer component are the same as those within the core credit transfer component. The group added the few new elements required to support the direct debit transfer with particular help from TWIST, which had already done specific work on this type of message. A separate message for debits has been proposed, allowing both credit and debit transfer files to include multiple payments (ie a single payment or a single debit or credit with multiple credit or debit parties associated with it), because a single structure could not support this scenario.

The direct debit message was proposed as a provisional standard. One of our key participants, SWIFT, needed to wait for feedback from European efforts to define a regional direct debit scheme. The group felt the work being done by organisations like the European Payments Council (EPC) was more likely to process aspects such as mandates then change the actual data elements required for the transaction. SWIFT is now ready to begin its work on direct debits and the provisional standard will be reviewed. We expect the provisional debit standard to be confirmed although it is possible there will be some modification.

A payment initiation status message (recommendation 3) was also developed, using the work SWIFT had prepared in its customer-to-bank modelling efforts. This initiation status message can be used at a variety of points in the payment process, depending on the implementation by each bank and/or customer. It allows both a standard set of status codes and the ability to include a proprietary set.

Detailed work on an advice and bank statement standard was placed into a second phase of IST effort (recommendation 7). It may require additional subject matter experts and we did not want to delay publishing the work already completed. SWIFT will coordinate this new effort with the IST group in the second half of 2004. As with the first three messages, IST will benefit from leveraging SWIFT’s Global Business Validation Group process to gain broad banking input.

Implementation Guidance

The success of any standards effort is measured directly by its implementation in the real world. Implementation by software vendors such as ERPs, treasury workstations and EAI products was a very high concern. Awareness of this challenge was high throughout our meetings.

The need for implementation guides (or MIGs as many know them in the EDIFACT world) that help the implementation processes of banks, software vendors and corporates was considered critical. It has been set as a Phase 2 objective (recommendation 8). Publication of the actual message elements was necessary before proceeding. When work starts, it will leverage the implementation guide work already done through the bank group supporting the RosettaNet payment pilot.

Easy to implement schemas were also important. Several suggestions were made on how to represent them. Most importantly, the group recommended that each standard using the payment kernel be able to annotate the schema using wording or the names associated with the rest of their standard. Maintaining the annotated schema and testing against the ISO schema, to insure compliance, becomes the responsibility of each group that produces one (recommendation 5).

Payment Kernel Inside…

One of our driving goals was creating a payment kernel that could either be embedded into or extended by other standards, while maintaining the kernel itself as a standard. We wanted it to be useful to supply chain efforts, for example, which need a payment as part of their overall standards. A common message or payment instruction component could reduce the development time required by these organisations. It also reduces the mapping, coding and testing time needed by banks and corporates. Most important for banks, it creates a consistent payment instruction format without interfering with the development of other business messages for that supply chain.

Using namespace, an XML-based concept that places clear boundaries around data elements, let us accomplish this goal (recommendation 4). The elements that represent the payment instruction reside in a specific name-space, have a specific order and specific name tags.

Several scenarios were discussed before the group established guidelines for using the payment kernel name-space. The kernel can be used as a whole or embedded part of an overall message with, for example, remittance data, appearing after it in a different namespace.

Example 1: Using The Kernel

In some very specific cases, the working group allowed for inclusion of additional name-spaces other then the payment kernel name-space within it. The two conditions in which this might be allowed are: efficiency of processing a file that contains multiple payments and multiple remittances and the creation of new country-specific requirements that are not part of the kernel but mandated for making a payment.

Example 2: Using The Kernel

Another important conclusion of the group was that standards organisations may present the schema for the payment kernel the way they see easiest to implement (recommendation 5). The resulting payment instruction, from each of these schemas, must be exactly the same and validation can be performed against the official ISO schema to ensure this.

Building the Kernel, Bringing Related Bank Groups Together and ISO

While the IST bank group was meeting, a second group of nearly the same bankers was meeting to create implementation guides and develop STP guidance for the RosettaNet community’s Payment Milestone Program. The Payment Milestone Program uses SWIFT XML formats which will in their next release include the payment kernel. Rather than have one group drive implementation guides and another drive common formats, we combined the groups under a new name, The Corporate STP Bank Group, to ensure we worked consistently (recommendation 9).

To ensure that the independent and global nature of the payment kernel remains protected, the group recommended that it be both ISO-compliant and an ISO 20022 standard which is publicly available. The other standards that use the kernel, however, do not need to be ISO-compliant.

SWIFT will help its colleague IST standards organisations join ISO and we have encouraged them to gain representation through the national organisations from which ISO membership is driven.

Next Steps

The new Corporate STP Bank Group will continue the work initiated by each ad hoc effort. Completion of the message components, implementation guides and publicising the effort have been set as key priorities.

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