This is the TWIST release version 3.1 Recommendation for review by the public and by TWIST members and working groups. This specification is
considered stable and has been reviewed by the TWIST technical committee. TWIST encourages any reviewers to provide feedback as early as possible.
Comments can be sent by email to info@twiststandards.org.
Copyright 2008. All rights reserved.

The suite of TWIST messages and elements have been divided into several
schema files.

• TWIST3.0.TWISTCore.Twist.xsd – top level of the schema hierarchy, contains the root Twist element definition
• TWIST3.0.TWISTCore.TwistMsg.xsd – contains elements relating to message framework structure and workflow
• TWIST3.0.TWISTCore.TwistShared.xsd – contains elements common to two or more schemas
• TWIST3.0.Billing.TWISTMsgElectronicBilling.200606.xsd – defines the message for electronic billing of bank services defined by the Billing Of Bank Services Working Group
• TWIST3.0.FinancialSupplyChain.TWISTMsgSupplyChain.200606.xsd – defines the messages for supply chain finance (e.g. Invoice, Invoice Dispute, Purchase Order) defined by the Financial Supply Chain Working Group
• TWIST3.0.Payment.TWISTMsgPayment.200606.xsd – defines the messages for payments (e.g. Remittance Advice) according to the specification of the Payment Working Group
• TWIST3.0.WholesaleTrade.TwistMsgCredit.200606.xsd
• TWIST3.0.WholesaleTrade.TwistMsgPricing.200606.xsd
• TWIST3.0.WholesaleTrade.TwistMsgStreaming.200606.xsd
• TWIST3.0.WholesaleTrade.TwistMsgTrade.200606.xsd
• TWIST3.0.WholesaleTrade.TwistTradeComponent.200606.xsd
• TWIST3.0.WholesaleTrade.TwistTradeDoc.200606.xsd
• $pain.001.001.01.xsd
• $pain.001.001.01-directdebit.xsd
• xmldsig-core-schema.xsd

TWIST has achieved effective harmonization with SWIFT, IFX and OAGi with the delivery of the IST Payments kernel under the ISO 20022 umbrella. The International Standards Team (IST) for Harmonisation has delivered a standard XML core payment kernel for corporate-to-bank payment initiation and status messages. The core payment kernel consists of an agreed set of key financial data components required for a payment message in any currency. The payment kernel can be processed by any bank irrespective of location and can be issued by any corporation irrespective of business line.

TWIST Document Types TWIST supports the use of Message documents. A message is a document containing a message header and data elements specific to the given message. All TWIST messages are a more specific type of the broader definition of a TWIST Message.

TWIST is focused on delivering a comprehensive set of interoperable standards with the aim of enabling straight through processing.
When considering implementing TWIST messages one must consider the following questions:

• Which areas of TWIST schemas will be used?
• Are there definitions of the existing work-flows and how do they compare to the ones defined by TWIST?
• Will the messages be used by one or several organizations?
• Will there need to be any local extensions to the TWIST definitions?
• Are there any other XML schemas that will be involved?

The Twist element forms the root of all TWIST messages (instance documents). The root element contains attributes that define the documents namespace (and therefore version of TWIST), the schema location and the type of message using the xsi:type attribute.

This section describes a set of complex xml types and elements that comprise a simple message framework (aligned with FpML) that is used as the basis for defining business messages suitable for ‘Straight Through Processing’ (STP) via either ‘Business-to-Business’ (B2B) or ‘Application-to-Application’ (A2A)
communications processes.

Achieving the efficiency benefits in the financial supply chain and corporate to corporate to bank communication can only be achieved through greater and the use of electronic messaging (i.e. with as little human interaction as possible). In order to achieve this all the parties involved must agree on four
things, namely:

• Representation: There must be a common representation of a transaction, product or other reference data item that is accepted by all the parties. The core TWIST grammar defines a standard vocabulary a broad base of business transactions that form the basis of a messaging standard. As new messaging applications are considered the scope of the core grammar will need to expand to encompass the additional types of data referenced in these messages.
• Semantics: All the parties must have the same interpretation of the information expressed by the representation. The respective working groups in conjunction with the technical committee ensure that a message definition conforms to the best practices in industry today. The TWIST standard definition set will expand and evolve over time as new message types are added to the grammar.
• Business Process: All the parties must follow aligned business processes and respond appropriately to any communication they receive. The TWIST working groups are made up of industry experts to define best practice as well as minimum acceptable business flow standards to shows how they could be implemented as message exchanges.
• Transport: The parties must agree on the communications transport used to interconnect their businesses. TWIST does not endorse any particular
• messaging transport for communication.

In order to create the messages and business processes defined by TWIST some design assumptions had to be made. They are:

• Message exchanges will be carried by an asynchronous exchange of messages over a guaranteed transport (‘Fire and Forget’).
• Some of the business processes are ‘long-running’ in that once initiated they may remain active for a considerable time before completing. During this time the process may generate periodic notifications to relevant parties. Such notifications will appear in the message stream set to a participant intermixed between other messages. An implication of such transactions is that the ‘service provider’ will contain a complex ‘state’. The service should make suitable provisions to persistently record its state so that in the event of a software or hardware failure it can recover transparently without its clients having to re-send any information.

Implementors attempting to construct software based on these protocols using a non queuing transport (e.g. WebServices, DCOM, CORBA) will need to implement a reliable message layer to encapsulate the current message sequences (e.g. a get/put message interface using sequence numbers to detect lost or duplicated messages and positive/negative acknowledgements). The W3C site contains links to proposals for such extensions for use with WebServices.

TWIST incorporates two commonly used message styles for electronic communication.

• Request/Response A style of exchange in which one party sends a message to the other to asking it to perform a function. An appropriate response is then generated returned to the sending party.
• Notification A style of exchange in which a system sends a message describing a business event that has occurred. The receipt of any TWIST message may result in additional messages being generated as part of the business processes. For example to obtain further information from another system to be able to respond to a Request message.

The TWIST message architecture is independent of transport protocols as well as authentication and authorization mechanisms. TWIST messages include a standard message header that is contained within the document itself. This ensures that this information will persist regardless of physical transport and enables more flexible use of other features such as digital signatures.

For effective communication, the receiver need to be able to readily determine the nature or purpose of a given message. As part of the TWIST’s harmonization effort with FpML The TWIST message framework is based on type substitution as it gives the greatest control over validation while allowing easy extension of the message elements. TWIST uses three methods to identify a message’s purpose.

Namespace

The receiver can look at the namespace from which the element definitions have been drawn and determine the message function.

• <Twist xmlns=”http://www.twiststandards.org/3.0/ElectronicBilling”
• xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”>
  • <header> messageHeader</header>
  • Messge Data
• </Twist>

Using namespaces it would be possible to create a highly extendable framework for FpML but it could lead to documents having to have every FpML element prefixed with a suitable namespace abbreviation although it may be possible to mitigate this by having the ‘core’ sub-schemas use no namespaces in their definition and take on the namespace of the one they are including into. There may be further issues with related XML standards such as XPath as the namespace of the same included elements may not be consistent between documents.

messageType Element Value

The receiver can look at the name associated with an optional element ‘messageType’ within the message to determine the function requested.

• <Twist xmlns=”http://www.twiststandards.org/3.0/Payments”
• xmlns:isth=”urn:swift:xsd:$pain.001.001.01″
• xmlns:isthdd=”urn:swift:xsd:$pain.001.001.01.dd”
• xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”>
  • <header>
    • <messageType>RemittanceAdvice</messageType>
  • </header>
  • Message Data
• </Twist>

Element Type

The receiver can look at the xsi:type attribute associated with the root element within the message:

• <Twist xmlns=”TWIST3.0.FinancialSupplyChain.TWISTMsgSupplyChain.200606.xsd”
• xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xsi:type=”Invoice”>
  • <header>
    • message header
  • </header>
  • Message Data
• </Twist>

An XML schema based instance document may use type substitution to replace the content model of any element with another providing that the replacement is derived from the original. Given a framework that provides the appropriate extension points any number of new types can be derived within the name or different namespaces as necessary. In addition through inheritance the message types can be associated with an appropriate message header content model.

The TWIST message framework was designed to align with the schema architecture implemented by FpML 4.0. As such the structure of the TWIST message framework is the same as the structure of FpML 4.0 message framework.

Base Document

The XML schema for TWIST defines the type of the root Twist element to be ‘Document’, an abstract type with an empty content model. The Document type serves as the base type in an inheritance scheme that provides the content model definitions for actual message types.

Base Message

Two core definitions within the schema establish two abstract base classes, ‘Message’ and ‘MessageHeader’ from which all the other definitions are
derived.

The ‘Message’ type contains one element ‘header’ that holds the identification and delivery data defined by the abstract ‘MessageHeader’ Type. The ‘Message” types inherits coding schemes by extending the base ‘Document’ type. The elements contained in ‘MessageHeader’ are a superset of elements for the three supported message types, Response, Request and Notification.

The role of each element in the ‘MessageHeader’ superset is as follows:

• conversationId allows a message sender to create a common context for a number of separate message exchanges.
• messageId contains the senders unique identifier for a message.
• inReplyTo contains the unique identifier for the request message that is being responded to.
• sentBy identifies the party sending a message.
• sendTo identifies the parties who will receive a message and should act upon it.
• copyTo identities other parties who will receive a message but who do not have to act upon it.
• creationTimestamp describes the time when the sender created the message.
• expiryTimestamp defines a time after which the sender will consider the message expired.
• dsig:Signature allows the inclusion of W3C digital signatures within the message.

Message Types (Request, Response & Notification)

TWIST schemas derive three abstract style types from the base message types by restriction. As the base ‘MessageType’ is a superset of elements, each of the style types may not contain all of the same elements. For example a Notification message does not require an inReplyTo element where a Response message does.
The following diagram shows an example of one of the style message types, ResponseMessage

Schema Entry Points

TWIST messages represent a broad and diverse base of business areas. As such many interested parties are only concerned with one particular message
set in the TWIST schemas. To accommodate this, TWIST releases bundles of messages related in business function. Each of these bundles represent an ‘entry point’ to the TWIST xml schemas for validation. Taking advantage of a ‘chameleon approach’ where the ‘core’ sub-schemas use no namespaces in their definition and take on the namespace of the one they are including into TWIST is able to segregate each message area by namespace while maintaining a central set of elements and message framework definitions. The following diagram illustrates the TWIST entry point and schema hierarchy. The message hierarchy in the TWIST design helps to minimize the amount of processing required by the parsers on a given system.