SWIFTReady Messaging Data Services

(1)

SWIFTReady Messaging Data Services

Messaging Data Services Label – Criteria

--

SWIFTReady

Messaging Data

Services

Label criteria 2008

Version 3 May 2008

(2)

Legal Notices

Copyright

You may copy this publication within your organisation. Any such copy must include these legal notices.

Confidentiality

This publication contains SWIFT or third-party confidential information. Do not disclose this publication outside your organisation without the prior written consent of SWIFT.

Disclaimer

The information in this publication may change from time to time. You must always refer to the latest available version.

Translations

The English version of SWIFT documentation is the only official and binding version.

Trademarks

SWIFT, S.W.I.F.T., the SWIFT logo, Sibos, SWIFTNet, SWIFTAlliance, SWIFTStandards, SWIFTReady, and Accord are trademarks of S.W.I.F.T. SCRL. Other SWIFT-derived service and product names, including SWIFTSolutions, SWIFTWatch, and SWIFTSupport are tradenames of S.W.I.F.T. SCRL.

SWIFT is the trading name of S.W.I.F.T. SCRL.

Other product or company names in this publication are tradenames, trademarks, or registered trademarks of their respective owners.

(3)

1. Introduction

2.1 Purpose

Throughout the years, SWIFT developed SWIFTReady label programme to certify third party

applications and middleware products that support SWIFT messaging systems and standards and that integrate with SWIFTNet using SWIFTAlliance interfaces.

This paper focuses on the SWIFTReady Messaging Data Services (MDS) label, and provides an overview of the criteria that a MDS compliant must comply with to be granted a label from SWIFT. MDS is granted to SOA components that can be deployed within any Financial Institution to validate and translate SWIFT messages.

2.2 Audience

The target audience for this document is both integration technology vendors considering the certification of their Message broker/ transformer engine, as well as SWIFT Users that look after

acquiring validation and transformation engines. The audience should be familiar with SWIFT world from a technical and a business outlook.

2.3 SWIFTReady Programme

The SWIFTReady label programme spans through the whole financial application chain, and includes Trade, Treasury, Payment, ERP, Corporate and Securities applications.

Each SWIFTReady label defines a set of criteria that is reviewed every year to ensure that the software remains aligned with financial market evolution and customer needs.

These criteria are designed to reflect the capability of vendor products to provide message processing automation in a SWIFT context, and to support STP in order to increase customer value, and reduce time to market.

SWIFTReady labels focuses on the specific needs of the financial community, including actors such as banks, brokers, fund mangers, traders, payments and securities market infrastructures and corporate treasury departments.

2.4 Messaging Data Services

The SWIFTReady Messaging Data Services (MDS) Label verifies the capacity of a vendor’s products to support SWIFTStandards, in terms of mapping different data source into SWIFTStandards format, validation against SWIFT syntactical and semantic rules, transformation of the messages between different formats (ISO15022 into ISO20022, for instance), and deployment of run-time SOA messaging component that can be used by interfaces, middleware and financial applications.

MDS maps data coming from business applications into messages and files that are ready to be supplied to any financial counterparty through SWIFT interfaces. Reversely, it parses message payloads transferred from SWIFT, and transform them into formats supported by back-office applications.

The following sections scope the Messaging Data Services in a SOA context before providing an overview of SWIFTStandards, and of the related mapping, validation and transformation processing that the Messaging Data Service should be supporting to be granted the SWIFTReady MDS label.

(5)

2. Messaging Data Services and SOA

Service-oriented architecture (SOA) is an architectural style where functionalities are grouped into atomic services. These services communicate with each other by passing data from one service to another, or by coordinating an activity between one or more services.

SOA can be defined as the practice of segregating the core business functions into independent services that don’t change frequently. It involves not only the manner in which business services and applications are deployed and interact with each other, but also how they interact with data.

In order for SOA to be successful, there must be a direct connection to data middleware. Providing SOA with a data services infrastructure will maintain data consistency through synchronization, data agility through semantic mapping, and data access optimization through caching.

A Service can be defined as a modular piece of software that can be activated by another piece of software (consumer) through well-defined interface. Various classes of services exist in SOA, including infrastructure services (which provide low-level functions, such as messaging, registration and

authentication) and business services (which perform higher-level business functions, such as processing an order).

Data Services capture, aggregate, manipulate, transform, validate, route and reconcile data and semantics. Data Services enable the insulation of applications and business services from the physical implementation of data.

The concept of data services is gaining interest as an approach for ensuring that data integration challenges in SOA are adequately addressed. Data services are recognized by analysts as a critical component for SOA initiatives. Data will be consumed in more and different ways, often crossing boundaries of applications and processes, and constantly changing as new business processes are composed on the fly.

SOA implies a clear separation between the consumers of data and the storage and delivery of data, while enabling the centralized management of policies for data governance. Services that exclusively perform data-oriented tasks at the request of business services, applications and processes should provide this separation, which are the key to meeting the data challenges of SOA.

From a technical implementation perspective, data services support the important principles of service orientation:

□ Modularity. Data services can be called by consumers of various types, including transactional and analytic applications, component business services of composite applications or other data

services. Data services provide greater value via consistency the more they are reused.

□ Clearly defined interfaces: Data service consumers interact with data services through an interface that enables consumers to specify the type of data, format, freshness, delivery mode, latency, quality and other requirements relevant to the context in which the consumer is operating. In essence, these requirements form a service-level agreement (SLA) that, along with available metadata, is used to drive the behavior of the data service.

□ Enable Loose Coupling: Data services are not bound to any particular service consumers. Their technical implementation can be modified without affecting service consumers. For data services to operate in accordance with the principles of SOA, they must have access to rich metadata that describes the location, format, quality, freshness and many other aspects of the available data. Developers, applications and business services can leverage metadata about data services (for example, via a services repository) to select specific data services based on these same types of parameters.

Data Services provides the low-level building blocks of data integration, which have been summarized by Gartner as follows:

(6)

□ Data access — providing connectivity and the creating, mapping, reading, updating and deleting operations for a range of database types

□ Data movement — providing Content-based routing of data from one data store to another to address data consistency requirements or improve efficiency through optimized data placement. □ Data transformation — providing rich data manipulation capabilities for changing the format and

structure of data, including data type conversions, aggregation and splitting operations, summarizations and resolution of language-based issues (including addressing Unicode requirements and conversions between writing systems)

□ Data validation — providing checking capabilities to verify syntax and semantic of data against industry standards, including look-up functions against reference data, and reporting mechanisms for error detection and correction

□ Data monitoring — providing the profiling and auditing of data residing in and moving through the environment, and using the results of these operations to update metadata and BAM in an ongoing and dynamic manner

□ Data governance — providing data quality operations and ensuring conformance of data to business rules (such as integrity constraints), as well as enforcing authentication and access rights to data

□ Data packaging — providing the delivery of data to other services in a variety of ways, such as federated views for consumption by business services or as sets of rows for bulk load to physical databases

□ Metadata management — providing information about the location, context and usage of data for architects and developers involved in the development of service-oriented applications, and for resolving semantic inconsistencies and related source-mapping issues.

These low-level data services should be combined in various ways to establish composite data services that accomplish complex data integration and manipulation tasks to support such requirements as master data management, data cleansing and enrichment, using market and reference data such as BIC and IBAN. To achieve this, data services should interact with each other in a layered fashion (similar to how business services will interact with data services), driven by metadata and SLAs that define the requirements and result of the interactions.

Messaging Data Services consists of composite data services, which focus on structured financial data that need to be transformed, validated and routed.

Messaging data services can be provided by different type of products, ranging from messaging broker, web service, transformation engine, EAI, messaging library, up to component of back-office application, SWIFT interface, ESB .

The MDS engine is typically composed of:

□ a design tool, allowing to map format and define mapping rules

□ a run-time module , which can be deployed in different environments, and possibly run independently of the design tool.

The MDS engine is typically a stateless machine. It processes a financial message, but is not aware of the historic chain of messages that compose the business transaction. A payment transaction is typically composed of a payment initiation message, followed by a confirmation, settlement, plus other optional status report, exception, update or cancellation messages. All these messages are subjected to be treated as independent units by MDS, which does not store individual messages nor reconciliation data, such as ACK, NACK and Delivery Notifications.

In 2008, the SWIFTReady Messaging Data Services will focus on the capacity of a Vendor product to:

- Access, map and validate messages against SWIFTStandards

- Translate messages from one SWIFT supported format to another (ISO15022, ISO20022) - Deploy a run-time version of the product as an SOA component to be accessed by third

(7)

3. Supported Standards

SWIFT develops business standards to support transactions in every financial market. SWIFT MT messages have progressively been complemented by XML-based messages, which enable the transfer of richer data for complex transactions.

The Messaging Data Services should support all existing MT and MX for all existing categories, as described in SWIFT User Handbook (UHB). Standards support implies the capacity to generate business payload using technical adapters to applications, messaging and file systems and databases (such as ODBC/JDBC, JMS, MQ), to wrap them within SWIFTNet FIN, InterAct or FileAct envelopes and validate them against the SWIFTStandards and SWIFTSolutions rules books.

3.1 MT

The FIN messages convey business payload named Message Type (MT). Each of the 240+ MT is defined by a three-digit number and holds a specific business meaning. MT are categorised as follows:

Category Category Name Number of Messages

1 Customer Payments & Cheques 18

2 Financial Institution Transfers 17

3 Treasury Markets – Foreign Exchange, Money _{Markets & Derivatives (FXMM)} 27

4 Collections & Cash Letters 18

5 Securities 66

6 Treasury Markets – Precious Metals & Syndications 20 7 Documentary Credits & Guarantees 29

8 Travellers Cheques 18

9 Cash Management & Customer Status 29

MT Messages are gathered into Business Transactions, such as Payment, Trading, Settlement, Forex. For instance, a Trading Transaction includes Order to Buy (MT502), Trade Confirmation (MT515, MT518), or Statement messages (MT576).

Dealing with Business Transactions implies state-conscious engine. This feature is not expected from MDS, which typically behaves like a stateless machine.

MDS should be able to parse the 240+ MT messages (SRG2007), generated by back-office applications, or received trough a FIN Interface.

MDS should validate financial messages against SWIFTStandards.

3.2 ISO15022

ISO 15022 de-couples business elements from physical representation, and ensure that business items are always represented the same way, irrespective of the message contents. It provides the tools to define MT standards used in the Securities industry. These tools consist of a set of syntax and message design rules, a dictionary of Data Fields and a Catalogue of MT Messages using these Data Fields and rules.

Business Elements (such as Net Cash Amount, Cut-off Time, and Beneficiary) belongs to Business Classes (such as Amount, Party, Date/Time). Business elements are reused across MT messages, bearing the same syntax, tag and business rules.

(8)

The Messaging Data Services should support the ISO 15022 data dictionary. In particular, each Data Field element and related qualifiers should be centrally managed, so that each data field update percolate up to all MT messages that use this data field.

This logical link can be implemented in various forms as long as the user can find the corresponding business data in related messages. This implementation leads to data mapping in the following two logical steps:

□ Identify the business meaning of every field in the incoming message

□ Generate automatically the corresponding business message including these business elements. The Messaging Data Services should be able to map financial data into a syntax neutral representation using a central dictionary approach based on ISO15022 standards

3.3 MX

Leveraging the emergence of XML as de facto standards for inter-systems communication, SWIFT uses the UNIFI (ISO20022) methodology to design standards, based on business processing modelling. The UNIFI methodology uses a central data dictionary containing reusable business elements to build XML standards, named MX, that are used in business transactions and provide interoperability across financial services.

At the end, the whole financial community will move to MX, but adoption will vary by business area, depending on the drivers. SWIFT intends to provide translation rules to support interoperability in business areas where coexistence of MT and MX is necessary.

The 250+ available MX messages, available in the UHB, are structured according to market segments.

Market Segment _{Messages (Q1 2008)}Number of

Payment initiation 5

Payments Clearing and Settlement 7 Exceptions and Investigations 14 Payments

Invoice Financing Requests 3

Cash Management Cash Reporting 31

Trade Trade Service Utility 50

Trade 18 Settlement 11 Data Reference 3 Management 7 Cash Forecast 6 Pre-trade 44 Investments 23

Transaction Regulatory Reporting 4 Securities Proxy Voting 8 Non-deliverable Forwards 7 Currency Options 4 FXMM and Derivatives Generic 4

(9)

MX supports XML features, such as the facets on simple data type (pattern, min and max length, numerical limits, enumeration, max digit and decimal numbers). MX also supports complex data types to gather common characteristics that are inherited by XML schemas and XML instances.

Schema validation involves syntax checking against well-formed XML rules (single-rooted paired elements, opening and closing tags). In addition the XML instance must be validated against its corresponding XML Schema Definition (XSD), including allowed character set, format, cardinality, enumeration, and

mandatory/optional presence. XSD are available in deployment packages on www.swift.com/support (download centre), and in the UHB.

Extended validation ensures that the message is validated against the MX rule Book. It involves cross-element (if field A is present then field B must take value X or Y), intra-cross-element (the fractional part of an amount is checked against the currency), calculations (check digit of IBAN code) and external table look-up (BIC, IBAN, Country or Currency Code). Extended Validation rules for MX are listed in 4.2 MX messages are often complex structures that should be presented to the user in the MDS design tool, in a form that makes them easy to work with. The structure of the message should be easy to visualise and important characteristics of each element should be available for reference. The XML schemas that are delivered to define MX messages include much of this information, but not all. The definition should make it easy to visualise the hierarchical structure of the message and refer to individual elements and attributes.

The SWIFTReady MDS product should be able to parse and validate any XML message against its XML schema (XSD). It should be able to support Extended Validation for the generic fields present in most MX.

The underlying MX semantic should be fully rendered in the MDS design engine.

3.4 ISO20022

ISO 20022 provides the financial industry with a common platform for the development of messages in a standardized XML syntax, using:

□ a modelling methodology, based on UML to capture financial business models, business transactions and associated message flows into syntax-independent data dictionary □ a set of XML design rules to convert the messages described in UML into XML schemas

SWIFT applies the ISO 20022 definitions to structure SWIFTStandards XML (MX) message types. Any MX artefact (XML element, simple or complex type, attribute) has a corresponding business artefact definition (message component, element, data type). MX and business artefacts are both represented in UML.

The ISO20022 Financial Dictionary contains reusable items, which can be categorised into Business concepts (association, component, rule, actor and role), Data Types and Message Concepts (message element and rule). Non-reusable artefacts (Business Processes, Information flows, MX messages, and technical message elements) are found in the SWIFTStandards Reference Guide and in the UHB. The ISO2022 Data Dictionary is available in electronic format on www.swift.com. A downloadable version of the whole dictionary is currently being prepared.

The SWIFTReady MDS product should support the ISO 20022 data dictionary, i.e. all reusable business elements and components, as a basis for mapping, and validation of MX messages and associated rules.

(10)

3.5 FpML

The Financial products Mark-up Language (FpML) is an XML message standards developed for the OTC Derivatives industry. SWIFT created an FpML Closed User Group (CUG) linking buy-side with asset-servicing institutions, to transport FpML messages related to trade notification process for interest rate and credit derivatives. FpML 1.0 enables the transport of contract notification messages between buy-side and custodians. FpML2.0 has been delivered in Mach 2008 and includes cancellation of post-trade events and confirmation messages. SWIFT central services will validate FpML 2.0 messages against

- Syntactical rules (FpML schema validation)

- ISO references (Country, Currency codes and BIC)

- Semantic rules (cross field validation rules available for products Type = IRS, CDS, CDX or CXT).

The FpML schemas are released by the International Swaps and Derivatives Association (ISDA) on www.fpml.org.

The Messaging Data Services should be able to validate FpML syntax against its FpML schema. FpML R2.0 semantic validation is not mandated for 2008, but will be recognised as an optional feature.

4. Message Validation

4.1 MT Message Validation

SWIFTNet FIN Central Services validate every FIN message against syntactic and semantic rules. Messages that do not pass validation are rejected by the system, incurring substantial cost for SWIFT Users. To avoid this, a Messaging Data Services should provide the same level of validation as SWIFT Central Services does.

FIN messages are composed of different blocks (headers, body, and trailer). The message body should be a valid MT.

A well-formed MT is composed of [sequences of] fields. A valid field is made of field tags (2 digits 01 to 99), optional letter (A..Z) and Component ([string of] characters) with optional Qualifier. Fields are characterised by their presence in a message (optional, mandatory), their cardinality (allowed number of occurrence), and allowed values.

Several MT rule layers have been added during the years. Most are checked by SWIFT Central Services.

MT Rule Name SWIFT User

Compliance SWIFTAlliance Access Validation SWIFTNet Validation MDS Support MT Message Format

Validation Rules (MFVR) Mandatory Partial set and Syntax) (character validation) Yes (full Mandatory

MT Usage Rules Mandatory No No Mandatory

STP or Msg Guidelines Optional No No Optional

Market Practices

(SMPG/ PMPG) Optional No No Optional

(11)

The Network Validation rules are defined in the Message Format Validation Rules (MFVR) in SWIFT UHB. MFVR is updated on regular basis, following the SWIFTStandards Release cycle. The Messaging Data Services should follow the MFVR evolution.

Validation Purpose Code Examples

Character

Set Valid character set; message, field and sequence length Mxx SWIFT defined 3 character set (X, Y, Z) depending on usage Syntax Field and component format;

mandatory fields and sequence

Txx T13 : field tag is not expected at this location _{T27: BIC incorrectly formatted or invalid.}

Code Word Valid code word usage Kxx

T0x

Code word: ‘D’ for Debit, ‘C’ for Credit

T05 - Code word error in Field 68B, subfield 4, in MT 609

Semantic Cross-field validation (conditional)

Over 300 rules are defined across the 200 MT

Cxx to Exx

C02: The currency code should be the same for all currency occurrences in the entire message. C05 - BIC should NOT be a BEI, BEID or TRCO C18 -If fields 32B and 71B are present, field 33 should be present.

MUG Message User Group (24 rules) Gxx G07 CLS : in an MT300 eligible for the FIN-Copy _{service CLS or CLT, any Field 53 in sequence B} should be used with the letter option “A”. VAS Value-Added Service related (5

rules) Bxx

B01: PAC Trailer used for non-FIN Copy service message.

4.1.2 MT Usage Rules

Usage Rules are best practices recommendations. They are not validated on the network, and do not generate error code. Usage Rules are nevertheless mandatory for the correct usage of MT field in a given business context. The Messaging Data Services should be able to validate SWIFT Usage Rules and return warning message in case of invalidation.

Some Usage Rules examples in MT103

- Field 33B Currency: used when currency and amount are different from field 32B values - Field 36 Exchange Rate: should be present when a currency conversion or an exchange has

been performed on the Sender's side.

- Field 77T can only be used if both Sender and Receiver of the message have subscribed to the Extended Remittance Information MUG. If the field is used, the Sender should set the validation flag to REMIT in field 119 of the user header of the message.

4.1.3 STP or Messaging Guidelines

STP Guidelines are not validated on the network and are not mandatory for the correct usage of the message. They concern best practices. Guidelines affect more than one field in the message, or more than one SWIFT message. Guidelines identify specific issues, and provide clarification and examples, with the aim to improve straight-through processing. They a re published in the UHB, with MT definition. This includes generic principles, such as avoiding the use of full name and address for a financial institution. More and more, banks are charging for non-STP compliance, and MDS should optionally be able to detect guidelines which apply to the fields of a nuclear message, and return warning or error messages, depending on user requirements.

4.1.4 Market Practices

Market Practices are defined by Industry groups to globally harmonise market practices to enhance STP at an industry level. The Securities Market Practices (http://smpg.webexone.com ) is a global securities industry group setup in 1998. SMPG objective includes the harmonisation of non-regulated geographical differences as well as the consistent implementation of ISO150022 messaging standards by securities

(12)

industry participants for processing within and across all markets. SMPG are currently active in more than 30 countries and are made up of the different players in the securities markets (custodians, fund managers, broker-dealers, IMIs etc). Discussions focus on automation and end-to-end processing throughout the securities life cycle.

Market practice rules and STP guidelines are not checked by the network, but they do represent best practice and in some market contexts compliance is mandatory (or failure to comply can incur a charge). Users need to be able to check compliance and decide what to do with non-compliant messages (repair, return to originating system, etc.).

Market practices include country-specific settlement rules for MT53x and 54x messages .They cope with common specialisations such as making certain qualifiers Mandatory, for example /PSET/, and BICs become mandatory. Market practices are currently being investigated for the Payment market. However, in 2008, PMPG will have no impact on message validation, and will not be part of the Messaging Data Services validation.

Market practices can be seen as an instance of a FIN message where some optional fields / keyword become mandatory for a specific country, or a specific market.

More recently, the Payments Market Practice Group (PMPG) has been introduced to provide market practice recommendation for implementation and use of payment messages, as related to financial instrument transactions inclusive of instruction, confirmation and status messages between investment managers, custodians and subcustodians. PMPG is not mandated yet for 2008.

The SWIFTReady MDS product should support FIN (SRG 2007) and return proper error message (containing error codes and error lines) whenever a MFVR rule is transgressed.

MDS should also demonstrate passive support for Usage Rules and Generic Securities Market Practices and should be able to return warning or error messages (depending on customer needs) whenever transgressed.

The MDS should display the capacity to support additional local Market Practices and STP Guidelines with marginal cost and marginal implementation effort.

4.2 MX Message Validation

MX messages should be validated against relevant XML schema and against Extended Validation Rules that are provided in the MX rule books (SWIFTSolutions Service Description).

Extended validation goes beyond schema validation, adding:

• Algorithmic rules (scoped to an element, for example: BIC, Country or Currency validity, number of decimal places for Currency)

• Cross-element rules (for example, if Reference X appears in Group Header it should NOT appear in Transaction).

The solution should be able to perform this validation for all MX message types.

The error codes reported for validation failures should be as documented in the SWIFT Solution documentation set.

The element responsible for the failure should be clearly identified.

Extended Validation Rules should be applied on the following generic MX fields:

• XML elements of type BIC (Datatype: BICIdentifier) should be checked against existence in the BIC directory (ISO 9362)

• XML elements of type BEI (Datatype: BEIIdentifier) should be checked against existence in the BEI list on SWIFTNet

(13)

ISO 4217, and against the number of digits of the amount as specified by ISO 4217 for that specific currency

• Country codes (Data Type: CountryCode)should be checked for existence against ISO 3166 • IBAN identifiers (Data Type: IBANIdentifier) should be validated against IBAN structure as

provided by ISO 13616 (Country Code, check digits and a basic bank account number) • XML elements of type BICorBEI (Data Type: AnyBICIdentifier) should be checked against

existence in the BIC list on SWIFTNet

• XML elements of type ActiveCurrency (Data Type: ActiveCurrencyCode) should be checked against existence in the currency list on SWIFTNet

• XML elements of type ActiveOrHistoricCurrency (Data Type: ActiveOrHistoricCurrencyCode) should be checked against existence in the currency list on SWIFTNet

Other rules may apply for particular SWIFTSolutions. The support of these additional rules is optional for the MDS label.

The XSD for the following solutions should be supported by default in the MDS: - Cash Management Push and Cash Reporting R3.0

- Funds R4.0

- Exceptions and Investigations R1.1 - Proxy Voting R1.0

These XSD are available on www.swift.com/support > Download Centre > SWIFTAlliance SWIFTStandards Packages.

SWIFTSolutions support will be recognised as optional features of MDS. To support a

SWIFTSolution, the SWIFTReady MDS product should support the complete rule book provided with every SWIFTSolution Service Description and provide the name of at least one customer using the MDS for this purpose.

(14)

5. Reference Data

5.1 BIC Integration

The BIC Directory is a database containing the exhaustive list of institutions connected on the SWIFT network.

The Messaging Data Services should provide access to these directories both for message validation and as look-up function in the message creation and message repair stations.

The BIC Directory is downloadable from www.swift.com in full or delta versions. It should either be copied into the MDS repository system, or stored in back-office for access by the MDS through defined interface (Api, ODBC/JDBC, web service, ..)

5.2 BICPlusIBAN

SWIFT introduced the BICPlusIBAN Directory, allowing financial institutions to seamlessly switch between beneficiaries BIC and corresponding Bank National Codes. It also allows deriving the BIC from the International Bank Account Number (IBAN) in outgoing SEPA payments over 31 countries, or validating that both IBA and IBAN belong to the same institution.

Furthermore, the BICPlusIBAN provide look-up facilities for bank/branch/clearing codes against the BIC beneficiary BIC. It also contains banks participation in RTGS systems and other bank details.

The directory can be downloaded from www.swift.com on the BIC Downloads page. BICPlusIBAN supersedes the BIC+ Directory that is being removed from the market.

The Messaging Data Services should be able to validate the BICPlusIBAN against specific MT and MX messages, which are:

□ MT102 (STP or not) field tags 52A and 57A (plus 52C and 57C for MT102_not_STP)

□ MT103 (STP or not) field tags 52A, 56A, 57A (plus 52D, 56D, 56C, 57C&D for MT103_not_STP) □ Pacs MX messages

In MT message, the IBAN of the beneficiary customer is contained in field 59A (preferably) or 59. IBAN code should be validated for pacs messages used in SEPA. In particular:

a) the IBAN checksum should be checked with Modulo 97 formula, ISO standard 13616,

b) the country specific IBAN format, should be checked against the IBAN registry format (downloadable from http://www.swift.com/index.cfm?item_id=61332),

c) the national bank identifier in payment messages should be checked against the IBAN d) the BIC issued in payment message should be checked for existence,

e) the IBAN and the BIC should be checked as belonging to the same institution.

For c), d) and e) one needs SWIFT's BICPlusIBAN Directory available on swift.com. d) can also be checked against the SWIFT BIC Directory.

As of 2008, Messaging Data Services should use the BICPlusIBAN directory to validate the IBAN-BIC combinations, translate IBAN-BIC into national bank/ clearing codes, and to derive the IBAN-BIC from the IBAN.

In addition, the MDS shall optionally repair payment messages for which the issued BIC and IBAN do not match, or derive BIC from IBAN when the BIC is missing.

(15)

5.3 SEPA Routing Directory

With the SEPA Routing Directory, banks sending SEPA payments can verify whether the operational BICs of their correspondent are SEPA-adherent and operationally ready for SEPA, and which channel (SEPA-ready Automated Clearing Houses) they can use for payments routing. In other words, the SEPA Routing Directory provides the operational information necessary to exchange SEPA payments with the institutions listed in the EPC Register of Participants.

The SEPA Routing directory specifications and samples can be downloaded on BIC Downloads page or on SWIFTCommunity (https://www.swiftcommunity.net/), Registered Vendors community.

The SEPA Routing Directory contains:

• The BICs and names of the financial institutions that have signed the SEPA Credit Transfer adherence agreement with the EPC (and later on the Direct Debit agreement).

• The operational BICs of these institutions which are able to process the SEPA payments. • The channels (SEPA-ready ACH or other Clearing and Settlement Mechanisms-CSM) through

which the financial institutions can receive the SEPA payments, and the preference for using these channels.

• At a later stage it will contain the SEPA Direct Debit Scheme information as well.

In 2008, The MDS should be able to use this SEPA Routing Directory to validate pacs messages against the Scheme to be used for a given correspondent BIC before sending a SEPA credit transfer payment instruction.

The Messaging Data Services should optionally implement the following logic for SEPA related pacs

messages to be sent to SWIFT:

□ Split the target correspondent BIC into a BIC Code (8 characters) and a Branch Code (3 characters). If the branch code is empty, substitute it with XXX.

□ Search the SEPA Directory with the BIC code, the branch Code, the Service Level (for example, SEPA), and the Scheme Instrument (for example, SCT for pacs.008 message and SDD for pacs.003 messages)

□ If no record is found for a specific branch code, then repeat the search with XXX in the branch code. □ If at least one record is found with an operational readiness date older then the current date and

with an active validity period, then the BIC is ready to accept payment instructions for the service level/scheme instrument and can receive payment instructions through the payment channel, and the message is validated.

□ If no record is found, the message should be routed to manual investigation to validate that the counterpart bank is ready to accept SEPA payment instructions.

5.4 MX / MT Directories

SWIFT intends to provide directory services to identify who uses MT and who uses MX in areas where coexistence of MT and MX is necessary. This is not mandated in 2008.

MDS should support directory look-up and validation for the BICPlusIBAN and SEPA Routing directories on all concerned pacs messages used in SEPA.

(16)

6. Message

Processing

6.1 Message Creation

The Messaging Data Services should be able to extract business data from back-office applications and databases, and map this data into MX, MT, FpML or other accepted SWIFT formats. A graphical design tool should provide the field mapping and data transformation rules from application format (IDoc, CopyBook, files, RDBMS tables, or others) into MX and MT fields. For MX, the XML payload should be generated using the XSD supplied on SWIFT download centre.

Message header should be added according to data transmitted by back-office applications, possibly enriched with correspondent profile data maintained in the MDS Repository. Messages should be validated prior to be routed to SWIFT interfaces.

When creating the Message RequestControl header, the MDS should provide a value for the ProductList fields.

The ProductList should contain the identification of all products and vendors that are involved in the generation of the message. Vendors should not override existing values, but should add new

occurrence if some already exists. This information is logged within SWIFTNet, and is not forwarded to the Responder.

The VendorName within the ProductList should be the Partner

Identifier Code (PIC) of the Solution Partner as provided by SWIFT. Details are provided in SWIFTNet Service Design Guide.

The ApplicationName is a short identifier of the application package and is chosen by the Vendor. The ProductVersion identifies the version of the application according to the versioning of the Solution Partner.

6.2 Content-based Routing

Business messages should be routed from back-office applications to the correct SWIFT Interface (SAA or SAG) and reversely. The rule engine should allow to route messages according to:

- Message header content: sender, receiver, and request and service type - Message payload content.

For instance:

If payment amount is larger than Threshold, then route it to exception handling. 6.3 Message Bulking

Rule Engine should also allow bulking payloads together, prior to wrap it into FIN, InterAct or FileAct envelopes, and unbulk incoming transactions. Additional processing, such as message transformation, local security management, and storage, should also be available.

By introspection of a message, different actions can be performed like writing a log to a file or database, triggering a workflow within an external application or sending a message to a third party, such as a BAM.

6.4 Data Enrichment

Incoming or outgoing messages may be enriched using MDS pre-defined functions. Enrichment may also be performed by using Database lookups or by invoking external programs or user exits.

(17)

6.5 Message Archiving

MDS should allowMessages to be persisted to a Relational Database (RDBMS) or new messages can be created by querying an RDBMS.

6.6 Reception from SWIFT

Messages received from SWIFT can include several MT messages. The Messaging Data Services should open up and parse the message into separate payloads and individual business messages (MT/MX). Message Validation is not necessary on incoming messages, but MT messages should be parsed into business objects and stored as such in the MDS repository. Depending on target

application, Data transformation and other processing may be required.

The SWIFTReady MDS should be able to cope with message creation, archiving, content-based routing, and reception form SWIFT interfaces. MDS should also maintain meta-data dictionary based on ISO15022 and ISO20022 models.

7. Message

Transformation

SWIFT supports different standards, including FIN (MT), ISO20022 (MX), and FpML. These standards co-exist with a large variety of industry, local and proprietary formats. SWIFT Users have large needs to convert from one format to another one, especially in the framework of large migration projects, such as ISO15002 to IS2002 or Euroclear Common Communication Interface (CCI).

7.1 ISO 150022 and ISO2002

The SWIFT community has agreed that MT and MX will coexist, and will both be transported over the SWIFT network for some period of time. During the period of transition many members will be required to process MT and the equivalent MX messages simultaneously, using applications that may offer native support for only one format or the other, or neither.

To support this coexistence period, SWIFT has developed translation rules in both human and machine readable forms. Translation rules are currently available for Credit Transfer Messages (103 Core and STP to pacs MX) and Investment Funds (502 and 515 REDM/SUBS NEWM to setr MX).

The purpose of message translation is to ease as much as possible at operating in this mixed environment.

The rules are provided for those MT and MX where equivalence is established and where the community of users has a need for translation support.

The SWIFTStandards Translation Guide available on www.swift.com/standards provides all the

necessary information and rules to translate a particular MT or MX source message to its equivalent MX or MT target message. The machine readable rules are available on request.

At present, the translation rules are available for translation for the following Messages: Credit Transfer Messages

□ MT 103 Core to MX pacs.008.001.01 □ MT 103 STP+ to MX pacs.008.001.01 □ MT 202 to MX pacs.009.001.01 □ MX pacs.008.001.01 to MT 103 Core □ MX pacs.009.001.01 to MT 202 Investment Fund Messages

□ MT 502 (REDM NEWM) to MX setr.004.001.03 □ MT 502 (SUBS NEWM) to MX setr.010.001.03

(18)

□ MT 515 (REDM NEWM) to MX setr.006.001.03 □ MT 515 (SUBS NEWM) to MX setr.012.001.03 □ MX setr.004.001.03 to MT 502 (REDM NEWM) □ MX setr.006.001.03 to MT 515 (REDM NEWM) □ MX setr.010.001.03 to MT 502 (SUBS NEWM) □ MX setr.012.001.03 to MT 515 (SUBS NEWM) 7.2 Human-readable translation rules.

These are currently provided in the form of a spreadsheet, specifying for each elements in the source message, a series of rules and operations for populating the equivalent element in the target message. The operations are either a straight copy of the content of a source element to a target element, or a reference to a function which does some work on the source element to convert it into the form required by the target.

The functions are documented separately; each function is described in text and given a formal

definition expressed in a proprietary formal language. Human-readable format and formal language may change in the future.

7.3 Machine readable format

Creating software to capture and execute the translation rules, and export the rules in the form of XSLT

1_{+ Java (machine readable).}

XSLT only operates on XML. At design time the translation software presents MT messages to the user in a hierarchical format derived from a SWIFT-proprietary meta-model of MT. The same meta-model is used to define an XML schema for the MT message. The XSLT, which is the output of the software, operates on an MT message which is expressed as an instance of the MT schema (MT-XML). To translate an MT message at runtime it is first necessary to transform it into MT-XML.

Similarly, a translated MX message needs to be transformed from MT-XML to MT format before it is recognizable as an MT. A ‘translation toolkit’ comprising MT-XML schemas, XSLT style-sheets containing references to Java code, the Java code itself and documentation, is available as well on request. The toolkits do not include the component that converts between MT and MT-XML.

The MDS should support all standard translation rules, as published by SWIFT. All rule operations should be fully supported, including those that require lookups to reference data, such as MT_To_MXBICorBEI).

A list of the operations currently defined for translation and rules for Payments and Funds can be found on swift.com: http://www.swift.com/index.cfm?item_id=62616

Although it is foreseen that users will wish to modify translation behavior, a clear separation should be maintained between delivered ‘standard’ rules and user modifications.

Smart Test Messages have been defined to test the translation. These are available from the UHB on https://www2.swift.com/uhbonline/books/hub/index.htm.

SWIFT estimates that some 100 messages will require transformation over the next 5 years. 7.3 Design and run-time version

The MDS should provide both a run-time version of the MT-MX translation, together with a design environment allowing business analysts to refine the translation rules to cater for dedicated business requirements.

The mapping rule language can be a proprietary language, but the formalism should be human-readable as to allow business analysts to understand the rules and to refine it to cope with their particular needs.

The design tool should include the ability to visually manage the messaging libraries, to refine the vendor provided models, and to show the impacts of SWIFTStandards updates on existing models and transformation definitions. It should include version control and change tracking capabilities. It should cater for test instances creation against established models.

(19)

The MDS should be able to convert back and forth MT to MX messages for the Credit Transfer and Investment Funds messages according to the full messaging scope of available translation rules.

The transformer engine should automate translation by either parsing the human-readable rules, or by processing the nominally machine-readable XSLT + Java.

It should demonstrate flexibility in refining models, and presenting visually both off-the-shelf libraries and impact of SWIFTStandards updates.

8. MDS

Deployment

The MDS should be deployable as a SOA component, allowing any SWIFT interface, Enterprise Application Integration (EAI), and back-office applications to call the MDS for message validation, transformation and content-based routing.

The MDS should be deployable on various platforms including .NET and any J2EE compliant application servers - the primary platforms used to host Web Services.

It should be deployable as a SOA component on a variety of message processing platforms like message brokers (e.g. IBM WebSphere, Microsoft BizTalk), application servers (e.g. BEA WebLogic, IBM WebSphere, Oracle 9iAS, JBOSS)) and Enterprise Service Bus (ESB).

The MDS run-time should be made available as modular reusable services using open API’s and technology standards such as XPath and XQuery for data access, transformation, validation and packaging.

It should run at least on UNIX (HP, Solaris, Linux) or Windows platforms.

The MDS can optionally provide adapters to various Messaging Queuing, Databases, Files and Communication systems, Business applications and Utilities to extract and map data into MT and MX messages.

Non-exhaustive lists of optional adapters that may be considered for support:

- Message Queuing: BEA MessageQ, IBM WS MQSeries, Microsoft MSMQ, Oracle AQ, Tibco Rendez-Vous

- Database: Oracle, DB2, Microsoft SQL Server, and any ODBC/JDBC compliant RDBMS - Communication: COM, CORBA, FTP(S), HTTP(s), SOAP, Socket, EDI VAN

- Business Application: Siebel, SAP, PeopleSoft, Oracle and other CRM / ERP / Treasury applications. - Utilities: Archive (ZIP/TAR), Batch, File *, GZIP/ZLIB, LDAP, MIME, SNMP, XML* )

The MDS should be deployable as a SOA accessible via open API’s and standard data access technology on at least one of the .NET or J2EE application servers.

It should run at least on one UNIX or Windows platform.

9. MDS Customers

The MDS should be able to demonstrate some customers already running the engine in test or production modes in a SWIFT context.

The MDS should run in a SWIFT environment for at least 5 customers, exhibiting at least one of the required features.

(20)

Annex A – MT Messages to support

The list of MT messages that will be target of the qualification is as follows:

MT Description

101 Request For Transfer

102 and 102+ Multiple Customer Credit Transfer 103 and 103+ Single Customer Credit Transfer

104 Direct Debit and Request for Debit Transfer Message

105 EDIFACT Envelope

110 Advice of Cheque(s)

111 Advises or confirms the issuance of a cheque to the drawee bank 112 Status of a Request for Stop Payment of a Cheque

190 Advice of Charges, Interest and Other Adjustments

191 Request for Payment of Charges, Interest and Other Expenses 192 Request for Cancellation

195 Queries 196 Answers

198 Proprietary Message

199 Free Format Message

200 Financial Institution Transfer for its Own Account 201 Multiple Financial Institution Transfer for its Own Account 202 General Financial Institution Transfer

203 Multiple General Financial Institution Transfer 204 Financial Markets Direct Debit Message 205 Financial Institution Transfer Execution

210 Notice to Receive

290 Advice of Charges, Interest and Other Adjustments 292 Request for Cancellation

295 Queries 296 Answers

299 Free Format Message

300 Foreign Exchange Confirmation 304 Advice/Instruction of a Third Party Deal 305 Foreign Currency Option Confirmation 320 Fixed Loan/Deposit Confirmation

321 Instruction to Settle a Third Party Loan/Deposit 330 Call/Notice Loan/Deposit Confirmation

340 Forward Rate Agreement Confirmation

341 Forward Rate Agreement Settlement Confirmation 350 Advice of Loan/Deposit Interest Payment

360 Single Currency Interest Rate Derivative Confirmation 361 Cross Currency Interest Rate Swap Confirmation

362 Interest Rate Reset/ Advice of Payment

380 Foreign Exchange Order

392 Request for Cancellation 395 Queries

(21)

MT Description

400 Advice of Payment

410 Acknowledgement

412 Advice of Acceptance

420 Tracer

422 Advice of Fate and Request for Instructions 450 Cash Letter Credit Advice

456 Advice of Dishonour

490 Advice of Charges, Interest and Other Adjustments

500 Instruction to Register 502 Order to Buy or Sell

508 Intra-Position Advice

509 Trade Status Message

513 Client Advice of Execution

515 Client Confirmation of Purchase or Sale 517 Trade Confirmation Affirmation

518 Market-Side Securities Trade Confirmation 527 Triparty Collateral Instruction

535 Statement of Holdings 536 Statement of Transactions

537 Statement of Pending Transactions 538 Statement of Intra-Position Advices

540 Receive Free

541 Receive Against Payment

542 Deliver Free

543 Deliver Against Payment

544 Receive Free Confirmation

545 Receive Against Payment Confirmation 546 Deliver Free Confirmation

547 Deliver Against Payment Confirmation 548 Settlement Status and Processing Advice 558 Triparty Collateral Status and Processing Advice

559 Paying Agent's Claim

564 Corporate Action Notification 565 Corporate Action Instruction 566 Corporate Action Confirmation

567 Corporate Action Status and Processing Advice 568 Corporate Action Narrative

576 Statement of Open Orders

578 Settlement Allegement

586 Statement of Settlement Allegements

590 Advice of Charges, Interest and Other Adjustments 595 Queries

596 Answers

600 Precious Metal Trade Confirmation 601 Precious Metal Option Confirmation 604 Precious Metal Transfer/Delivery Order 605 Precious Metal Notice to Receive 606 Precious Metal Debit Advice 607 Precious Metal Credit Advice 608 Statement of a Metal Account 700 Issue of a Documentary Credit 701 Issue of a Documentary Credit 705 Pre-Advice of a Documentary Credit 707 Amendment to a Documentary Credit

(22)

MT Description

710 Advice of a Third Bank's or a Non-Bank's Documentary Credit 711 Advice of a Third Bank's Documentary Credit

720 Transfer of a Documentary Credit 730 Acknowledgement

732 Advice of Discharge

734 Advice of Refusal

740 Authorisation to Reimburse

742 Re-imbursement Claim

747 Amendment to an Authorisation to Reimburse

750 Advice of Discrepancy

752 Authorisation to Pay, Accept or Negotiate 754 Advice of Payment/Acceptance/Negotiation 756 Advice of Re-imbursement or Payment 760 Guarantee

767 Guarantee Amendment

768 Acknowledgement of a Guarantee Message 769 Advice of Reduction or Release

791 Request for Payment of Charges, Interest and Other Expenses 795 Queries

800 T/C Sales and Settlement Advice [Single] 801 T/C Multiple Sales Advice

802 T/C Settlement Advice

900 Confirmation of Debit 910 Confirmation of Credit

920 Request Message

935 Rate Change Advice

940 Customer Statement Message

941 Balance Report

942 Interim Transaction Report

950 Statement Message

960 Request for Service Initiation Message 961 Initiation Response Message

962 Key Service Message

963 Key Acknowledgement Message

964 Error Message

970 Netting Statement

971 Netting Balance Report

972 Netting Interim Statement

973 Netting Request Message

991 Request for Payment of Charges, Interest and Other Expenses 995 Queries

996 Answers

SWIFTReady Messaging Data Services