Best Practices. Usage Guideline Editor. Standards. For MyStandards
|
|
- Jennifer Price
- 6 years ago
- Views:
Transcription
1 Standards Usage Guideline Editor For MyStandards Best Practices This document provides best practice recommendations for users of the MyStandards Usage Guideline Editor defining their message usage guidelines. 20 June 2012
2 Usage Guideline Editor for MyStandards Table of Contents Table of Contents... 2 Preface Introduction Naming Conventions Introduction Collection Name Examples Usage Guidelines Examples Usage Guideline Editor Conventions Introduction Must not Be Used (Remove) Make Mandatory Reduce Multiplicity Ignore Rules (and Guidelines) Text Rule or Guideline Conditional Rule Fixed Value Comment Annotation Example Example Example Change Datatype Redefine a Text or Narrative Field as a Code List Redefine a Narrative Field as Structured Lines of Text (MT) Create Extension (MX Only) Scenario 1: Fixed Value Scenario 2: Fixed Value and Code List Synonyms Collections and Usage Guidelines Legal Notices Best Practices
3 Preface Preface Purpose of the document Audience This document provides best practice recommendations for users of the MyStandards Usage Guideline Editor defining their message usage guidelines. This document is for the following audience: Users of the MyStandards Usage Guideline Editor Significant changes The following tables list all significant changes to the content of the MyStandards Best Practices since the 27 April 2012 edition. These tables do not include editorial changes that SWIFT makes to improve the usability and comprehension of the document. New information New section on collections and usage guidelines Location 4 Collections and Usage Guidelines Updated information Changes to naming conventions for collections and usage guidelines Location 2.2 Collection Name 2.3 Usage Guidelines Related documentation MyStandards Service Description MyStandards Best Practices 20 June
4 Usage Guideline Editor for MyStandards 1 Introduction This document describes naming conventions and recommended approaches when specifying restrictions on message fields. It is important to have a convention when naming collections and guideline definitions so that there is a level of consistency with names and to support the easy searching of guideline definitions. The driving principle behind having best practices is to push users to formalise as much as possible. The more formal a usage guideline definition is, then the more semantic value it has and so the more meaningful any automated or manual analysis can be. This document is intended for those users that already have a good knowledge of the MyStandards Usage Guideline Editor. It is not a user manual. In most cases, the best practice principals used are the same or similar for both MT and MX. Where illustrations are used, MX (XML) messages has been used. 4 Best Practices
5 Naming Conventions 2 Naming Conventions 2.1 Introduction The naming conventions described below for collections and usage guidelines functionality are valid, although practically, there may be variants. 2.2 Collection Name A collection is a container of logical set of guideline definitions which the user must analyse and manage. The table below gives an overview of how to build up the collection name. Parameter Description Example 1 Organisational Entity - SMPG, NMPG, RMPG, CGI, PMPG 2 [Locale or initiative -] Global, IT, GB, FR, Almus 3 Business area - CA, TIC, SR, IF, Payments, FX, Derivatives, Commodities 4 Business process - 5 Version - V1, V2, V3 6 Status_ DRAFT, FINAL, WIP Events, Order & Confirmation, Block Trade, Order Status & Confirmation, Transfers, Price Reporting, High Value Payments CA = Corporate Actions TIC = Trade Initiation & Confirmation SR = Settlement & Reconciliation IF = Investment Funds WIP = Work in progress CGI = Common Global Implementation Versioning Warning Optional parameters are indicated by square brackets []. MyStandards has its own convention for versioning and will apply Version 1 to the first time a collection is uploaded, and increment the version number of subsequent uploads. This is a technical version number and is distinct from the "true" version number of a collection. For example, V1 of the IF-Orders, Status and Confirmations collection may have been updated several times as several iterations of a "work-in-progress" version are posted. Thus Version 1 of the IF Orders and Confirmations collection may have, for example, an internal MyStandards version number of 5. Therefore, there is a need for a "business version number" Examples SMPG NMPG The spaces in the following example collection names are present for readability, they do not have to be present in the actual collection name, it is up to the user. # Collection Name 1 SMPG - Global - TIC - Order & Confirmation - V1 FINAL_ 2 SMPG - Global - SR Block Trades - V1 FINAL_ 3 SMPG - Global - CA - Events - V2 DRAFT_ 4 SMPG - Global - IF - Order Status & Confirmations - V1 DRAFT_ # Collection Name 20 June
6 Usage Guideline Editor for MyStandards 1 NMPG - FR - IF - Order & Confirmation - V1 FINAL_ 2 NMPG - DE - IF - Price Reporting - V1 FINAL_ 3 NMPG - DE - IF - Statements - V3 DRAFT_ 4 NMPG - US TIC - Trade Initiation & Confirmation - V1 DRAFT_ RMPG # Collection Name 1 RMPG ALMUS - IF - Order & Confirmation - V1 FINAL_ 2 RMPG - AFAC - IF - Order & Confirmation - V1 FINAL_ 3 RMPG - FINDEL - IF - Order & Confirmation - V2 FINAL_ 4 RMPG - FINDEL - IF - Transfer - V1 DRAFT_ 5 RMPG - SHARP - IF - Order & Confirmation - V1 FINAL_ CGI # Collection Name 1 CGI - Global - Payments -Corporate to Bank - V1 FINAL_ PMPG # Collection Name 1 PMPG - Global - Payments -PACS High Value Payments - V1 FINAL_ 2.3 Usage Guidelines A usage guideline represents a message definition which has been restricted by the user. The table below gives an overview of how to build up the usage guideline name for the MX or ISO XML messages: Parameter Description Example 1 Message Name & Identifier 2 [ Additional optional parameter - ] Subscription Order_ setr Subscription Leg, Redemption Leg The table below gives an overview of how to build up the usage guideline name for the MT: Parameter Description Example 1 Message Identifier & Message Name - 541_ Receive Against Payment 2 [For MT: SR year - ] SR2011, SR [ Additional optional parameter - ] Bonus Issue Warning Optional parameters are indicated by square brackets [] Examples The spaces in the following examples of collection and usage guideline names are present for readability, they do not have to be present in the actual collection name, it is up to the user. 6 Best Practices
7 Naming Conventions SMPG # Usage Guideline Name 1 541_Receive Against Payment 2 502_Order To Buy Or Sell - SR Subscription Leg 3 Subscription Order_setr Institutional 4 Subscription Order_setr CGI # Usage Guideline Name 1 Customer Credit Transfer Initiation_pain ACH Domestic & International 2 Customer Credit Transfer Initiation_pain Wires Domestic & International 3 Customer Credit Transfer Initiation _pain Cheques / Drafts PMPG # Usage Guideline Name 1 FI To FI Customer Credit Transfer_pacs IG 2 Financial Institution Credit Transfer_pacs IG General 3 Financial Institution Credit Transfer_pacs IG Cover Other, for example, commodities # Usage Guideline Name 1 600_Commodity Trade Confirmation Note When a message is added to a collection, the name of the collection is automatically appended in front of the message name. The collection name should be deleted from the message name. 20 June
8 Usage Guideline Editor for MyStandards 3 Usage Guideline Editor Conventions 3.1 Introduction The Usage Guideline Editor makes it very easy for a user to accurately and unambiguously describe their specific usage of a message. It allows a user to easily apply additional restrictions on top of the base message definition. Note A "restriction" is an additional limitation defined by the user on the base message definition which an implementer would need to follow in order to be compliant with the guideline. In some contexts the term "rule" would be used instead of "restriction". The list below describes the different restriction types that may be applied: # Restriction Type Description 1 Must not be used (Remove) An optional field or element must not be populated. 2 Make Mandatory An optional field or element must be populated. 3 Reduce Multiplicity A repeating field or element must repeat fewer times. 4 Ignore A field or element could be populated but is ignored by the receiver. 5 Text Rule A mandatory, unstructured, rule. 6 Conditional Rule A mandatory, if-then-else, rule. 7 Fixed Value A field or element must contain a given value. 8 Comment 9 Annotation 10 Change Datatype Information which cannot be expressed in a more structured way. A user-defined structure if a built in restriction is insufficient. A user-defined datatype replaces an existing simple datatype. 11 Create Extension A user-defined extension - MX specific. 12 Synonym A field or element has another name. The first four basic restriction types are very easy to set up in the message usage editor in an unambiguous way. The other more advanced restriction types, such as rules, comments and annotations require more thought before their use. It s possible to confuse their distinct functionality and the next sections attempts to define when it is appropriate to use each kind of functionality. 3.2 Must not Be Used (Remove) Indicating a field must not be used (removed), means that in order to be compliant with the userdefined guideline, a particular field must not be populated. If the sender of a message does populate the "removed" field, then the message will not be viewed as being compliant to the usage guideline. As a result, the receiver of the message may stop any processing and end the business transaction. Care must be taken when using this functionality since its implementation may be costly to the sender, if the sender has already implemented the message. An alternative solution that minimises the impact on a message already implemented by the sender is "Ignore" in other words, a field or element may be populated by the sender but it is ignored by the receiver. 8 Best Practices
9 Usage Guideline Editor Conventions 3.3 Make Mandatory Making an optional field mandatory, means that in order to be compliant with the user-defined guideline, a particular field must be populated. If the sender of a message does not populate the "mandatory" field, then the message will not be viewed as being compliant to the usage guideline. As a result, the receiver of the message may stop any processing and end the business transaction. 3.4 Reduce Multiplicity Some fields are defined in the base message as being repeatable. The user-defined guideline could contain a restriction which reduces the amount of times a field can be repeated. If the sender of a message repeats a field more times than is allowed in the usage guideline, then the message will not be viewed as being compliant. As a result, the receiver of the message may stop any processing and end the business transaction. It is not possible to increase the multiplicity of a field or element. 20 June
10 Usage Guideline Editor for MyStandards 3.5 Ignore Indicating a field must be ignored, means that in order to be compliant with the user-defined guideline, a particular field may or may not be populated. If the sender of a message does populate the "ignored" field, then the message is still viewed as being compliant to the usage guideline. However, the receiver of the message will not use the data in any way. In other words, the data in the field will not influence either the processing or the business transaction. 3.6 Rules (and Guidelines) Over and above restrictions such as "must not use" (remove), "must be used", "use only once" and "ignore", additional rules may be added to a field, which means that in order to be compliant with the user-defined guideline, the rule must be followed. If the sender of a message does not follow the additional rule on a field, then the message will not be viewed as being compliant to the usage guideline. As a result, the receiver of the message may stop any processing and end the business transaction. 1. A rule should contain a single constraint. If more than one rule constraint is necessary on a single field, these should be added in additional, separate rules. 2. The rule should be given a meaningful name. It is sensible to differentiate message usage rules or guidelines from the rules and guidelines actually present in the message standard. Prefixing the rule name with something like "ITNMPG" will help with this differentiation. Each rule should end in the word "Rule". 3. If a text rule (see below) is to be considered a guideline rather than a rule, then the rule name should end in the word "guideline". 4. Where possible, it is recommended to use the "Conditional Rule" format, over the "Text Rule" format as it increases interpretation clarity. 5. A rule should not be added if it is already part of, or conflicts with, the base message standard definition. 10 Best Practices
11 Usage Guideline Editor Conventions 6. Do not use punctuation, spaces or underscore types of characters. Follow the camel case convention. These restrictions are to allow for potential future functionality. 7. The cross element rule checkbox should be used as necessary. Differentiation between a Rule and a Guideline. Type Description Example Guideline Rule Text Rule or Guideline Compliance is recommended and so often contains the word "may". Compliance is mandatory and so contain the word "must". "The use of an ISIN is recommended." "The field may be used to quote the reference of the account opening instruction." "The field must contain the reference of the account opening instruction." This is a simple usage rule which is described in a plain text paragraph. It will require the user to interpret the rule carefully. So, it is recommended that the rule is concise and precise language is used. Example 1 text rule Example 2 guideline Conditional Rule 1. The rule is added to the first element (as referenced in <element>) of the conditional rule. 2. It is recommended that the rule definition is empty. In most cases the "if-then-else" text fields should be sufficient to describe the rule. 20 June
12 Usage Guideline Editor for MyStandards 3. When referring to other fields in the rule, then the XML tag or field name must be used. In some cases, it may be necessary to include some "path" information (see example below). Path information may also be needed in those cases where the same element name is used in different parts of the message. 4. Recommended structures of the "if", "then" and "else" text boxes is: <element> <logic> [ <value> ] - <element> represents the element or field being referenced. - <logic> represents the operator - <value> optional value to which relates to the content in <element> Example usage would be: <element> <logic> <value> <element> <logic> <value> <element> <logic> <value> If Currency is equal to If OrdrTp/ST AF is presen t EUR Then Amount must not contain decimals Then StafClntBrkdwn/OrdrBrkdwnTp/ NSPN must be present Else Amount may contain decimals 12 Best Practices
13 Usage Guideline Editor Conventions Example 1 20 June
14 Usage Guideline Editor for MyStandards Example Fixed Value Setting a fixed value for a field, means that in order to be compliant with the user-defined guideline, a particular field, when present, must be populated with the specified fixed value. If the sender of a message does not populate the field with the fixed value, then the message will not be viewed as being compliant to the usage guideline. As a result, the receiver of the message may stop any processing and end the business transaction. A fixed value may only be used on fields containing simple types, for example, Max35Text or Extended350Code. Examples of fixed field values are a user-defined code word, or a specific currency code. 14 Best Practices
15 Usage Guideline Editor Conventions The fixed value is entered in the "Fixed value" text field. If the fixed value is a code, then the definition of the code should be specified in the associated comment box. Note that a separate definition box for fixed value has been requested. 3.8 Comment A comment can only be used to contain information which cannot be expressed using more structured restriction types, like "make mandatory" or "must not be used". So, it should only be populated if a more restrictive restriction type cannot be used. It is "for information only". Don t use a comment for the following: To redefine the semantic of a field. To create a local language definition. To redefine the base message standard definition. To state the field is "recommended". If a field is recommended, this is better expressed as a guideline, using the "Add rule" functionality. To specify a fixed value. This is to be expressed using the Fixed Value box. However, the comment box is used to give the definition of the fixed value when it is a code word, until the Fixed Value has its own definition box. 20 June
16 Usage Guideline Editor for MyStandards Example 3.9 Annotation The built-in restriction types may not cover all the scenarios which a user may need to apply in their usage guideline. The annotation mechanism allows the user to create a re-usable restriction type to cover its particular requirement. So, annotations should only be used when it is not possible to express the message usage information through one of the "normal" mechanisms. For example, do not use an annotation to define a rule or to or to express a fixed value. Note The MyStandards platform has no knowledge of the semantics of annotations there is no impact on the generated schema. An annotation appears in the generated spreadsheet in the Annotation column. 16 Best Practices
17 Usage Guideline Editor Conventions Annotations should be given meaningful names and definitions: Example 1 The IT NMPG, for example, has the need to attach change request information to a field. An annotation function can be defined for such usage: 20 June
18 Usage Guideline Editor for MyStandards Example 2 The IT NMPG, for example, has the need to redefine the semantic of an element for local use. An annotation function can be defined for such usage: Example 3 The IT NMPG, for example, has the need to include definitions in Italian: 18 Best Practices
19 Usage Guideline Editor Conventions 3.10 Change Datatype Some fields are defined in the base message as being "simple data types", such as text, a number, a date. The user may choose to redefine a field's simple datatype to a more restrictive existing datatype, which is already available in the repository, or to use a newly created datatype. It is recommended to re-use existing datatypes Redefine a Text or Narrative Field as a Code List A user may redefine a text field as a code list, to enable a more formal way of specifying that, for example, "this field may contain the values SPEC and XPEC". This involves two steps, first, the setting up of the new code list and, secondly, redefining the type of the relevant field to use the new code list. When setting up the new code list, care must be taken to give the code list datatype a meaningful name: A definition at this level is probably not necessary. 20 June
20 Usage Guideline Editor for MyStandards The individual codes must be entered, and each code must be given a code word and a definition: Redefine a Narrative Field as Structured Lines of Text (MT) Example A user may redefine a narrative field, for example, 6 * 35x, so that it is more structured. This involves two or three steps, depending on the requirements. First, the new complex type is set up. And second, the relevant field is typed by the new complex type. When setting up the new complex datatype, care must be taken to make sure it and all its subfields have relevant names and, if necessary, meaningful definitions. And for the subfields, multiplicity must be set to override the default multiplicity proposed by the usage guideline editor. In turn, each of the subfields can each have their own datatype. In this scenario, in a usage guideline for the MT 502, field 70E (10*35X) TPRO in sequence B ORDRDET, is re-defined in the following way: Original definition in MT New definition Data Type 10 * 35x Line 1 Subfield 1 Code list with values NEAM and GRAM and GRPE Line 2 Subfield 2 3!a currency code Line 3 Subfield 3 15d 20 Best Practices
21 Usage Guideline Editor Conventions 3.11 Create Extension (MX Only) Because the investment funds order messages have not been maintained for some considerable time, many markets have defined the use of the Extension sequence for additional functionality, pending the maintenance. Extension sequence Scenario 1: Fixed Value There is a requirement to be able to optionally specify an SLA Reference in the Charge Details sequence of a message. The NMPG has agreed that this should be specified in an Extension sequence. An iteration of an Extension sequence is inserted in the Charge Details sequence. Following the addition of a new Extension sequence, give it a meaningful name and definition: 20 June
22 Usage Guideline Editor for MyStandards For each of the elements of the Extension sequence, you need to define the contents (1): 22 Best Practices
23 Usage Guideline Editor Conventions For each of the elements of the Extension sequence, you need to define the contents (2): 20 June
24 Usage Guideline Editor for MyStandards Scenario 2: Fixed Value and Code List There is a requirement to be able to optionally specify information about "order sequencing" in the message. The order sequencing can be either FIST (first) or FIILW (additional order). The NMPG has agreed that this should be specified in an Extension sequence. An iteration of an Extension sequence is inserted in the Individual Order Details sequence. Following the addition of a new Extension sequence, give it a meaningful name and definition: 24 Best Practices
25 Usage Guideline Editor Conventions For each of the elements of the Extension sequence, you need to define the contents (1): 20 June
26 Usage Guideline Editor for MyStandards The first element will be defined with "Fixed value" and this will be the XML path. A comment for the fixed value is entered. For each of the elements of the Extension sequence, you need to define the contents (2): 26 Best Practices
27 Usage Guideline Editor Conventions In this example, the second element (Text: Max350Text) can be one of two codes and therefore a code list has been created and the element Text has been typed by it (See Redefine a Text or Narrative Field as a Code List) Synonyms Every field in a base message has a specific name with associated meaning. A user-defined guideline may link another name, from a different context, to the given field. Examples: A back-office system may use another, proprietary, format. This proprietary format also has fields which match fields in the base message. A synonym can then be used to link the base message field to the proprietary format field. A non-english speaking country may want to use the base message, however the fact that all base messages are in English means adoption is hampered. A synonym can then be used to link the base message field to the translation of that field which should ease adoption. 20 June
28 Usage Guideline Editor for MyStandards 4 Collections and Usage Guidelines A collection is a container of logical set of guideline definitions which the user must analyse and manage. Typically, a "collection" will be for a specific business process and contain usage guidelines for messages that support the business process. Example There will be cases where a collection contains a single message. Publishers of usage guidelines, market practices, implementation guidelines, etc., on MyStandards should try to organise their work so that it s published as a logical collection. 28 Best Practices
29 Legal Notices Legal Notices Copyright SWIFT All rights reserved. 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 on SWIFT Standards Intellectual Property Rights (IPR) Policy - End-User License Agreement SWIFT Standards are licensed subject to the terms and conditions of the SWIFT Standards IPR Policy - End-User License Agreement, available at > About SWIFT > Legal > SWIFT Standards IPR Policy. Translations The English version of SWIFT documentation is the only official and binding version. Trademarks SWIFT is the trade name of S.W.I.F.T. SCRL. The following are registered trademarks of SWIFT: SWIFT, the SWIFT logo, the Standards Forum logo, 3SKey, Innotribe, Sibos, SWIFTNet, SWIFTReady, and Accord. Other product, service, or company names in this publication are trade names, trademarks, or registered trademarks of their respective owners. 20 June
Version and Release Management for ISO Messages. Best Practices. 2 December 2016
2 December 2016 Table of Contents Table of Contents Preface... 3 1 Introduction... 4 2... 5 2.1 Categorisation into Three Types of Change... 5 2.2 Determining the Type of Change... 7 2.3 Frequency of Changes...
More informationStandards Release Guide
Standards Standards MT November 2016 Standards Release Guide Updates to the Standards Release Guide This document describes updates to the Standards Release Guide (SRG) that have been identified since
More informationSR 2018 Business Highlights
This document provides summarised, high level, business information related to the changes made to FIN (MT) messages as part of Standards Release 2018 (SR 2018). 17 November 2017 Table of Contents Table
More informationConsultancy for Trade and Supply Chain Finance Track Criteria
Consultancy for Trade and Supply Chain Finance Track Criteria This document introduces the framework of the SWIFT Certified Specialist programme in the scope of consultancy for trade and supply chain finance.
More informationService Description MA-CUG. Solutions. For SWIFT for Corporates
Solutions MA-CUG For SWIFT for Corporates Service Description This service description describes the Member-Administered Closed User Group (MA-CUG) service. The information in this document includes the
More informationASX - AU - Austraclear SWIFT Messaging - V1 - DRAFT_900_Confirmation of Debit (Response to inward MT103/MT202 Message)
ASX - AU - Austraclear SWIFT Messaging - V1 - DRAFT_900_Confirmation of Debit (Response to inward MT103/MT202 Message) ASX - AU - Austraclear SWIFT Messaging - 2015 This document describes a usage guideline
More informationPreface Entity Identifiers Directory Publication BIC Usage...7
This document provides specific guidelines for the use of BICs by SWIFT users, in particular as identifiers and addresses within the SWIFT messaging services. 25 August 2017 Table of Contents Table of
More informationCorporate-to-Bank Guidelines
Applications Trade Services Utility 2.0 Corporate-to-Bank Guidelines This document presents the general principles and guidelines of the TSU corporate-to-bank (TSU C2B) project. 31 August 2011 Trade Service
More informationSWIFT Certified Applications RTGS. Technical validation Guide Version 1.1
SWIFT Certified Applications RTGS Technical validation Guide 2018 Version 1.1 February 2018 Legal notices Copyright SWIFT 2018. All rights reserved. You may copy this publication within your organisation.
More informationSR 2019 Business Highlights
This document provides summarised, high level, business information related to the changes made to FIN (MT) messages as part of Standards release 2019 (SR 2019). 16 November 2018 Table of Contents Table
More informationCSDs and Securities Market Infrastructures
Label Criteria 2017 This document explains the criteria required to obtain the SWIFT Certified Application - CSDs and Securities Market Infrastructures 2017 label for your business application. 27 January
More informationPublication Schedule and Distribution Information
Publication Schedule and Distribution Information This document describes the publication schedule for all SWIFTRef Directories, including important information about the publication and the distribution
More informationStandards Release 2017 (SR 2017): Frequently Asked Questions related to the SWIFT global payment innovation (gpi) service
Standards Release 2017 (SR 2017): Frequently Asked Questions related to the SWIFT global payment innovation (gpi) service Frequently Asked Questions This document describes Frequently Asked Questions (FAQs)
More informationCorporates Cash Management
SWIFT Certified Applications Corporates Cash Management Technical validation Guide 2017 Version 1.1 February 2017 Legal notices Copyright SWIFT 2017. All rights reserved. You may copy this publication
More informationError Codes - ADVANCE INFORMATION
This document provides advance information on changes to the FIN error codes related to SWIFT gpi and also as part of the Standards Release 2018. This document is an extract of the FIN Error Codes manual
More informationUser Guide. Bankers World Online
This guide explains how to use the Bankers World Online service. The guide describes the different tools and how to use them. This document is for users of Bankers World Online. 10 March 2017 Table of
More informationSWIFT Certified Applications. Corporate Actions. Technical validation Guide Version 1.1
SWIFT Certified Applications Corporate Actions Technical validation Guide 2018 Version 1.1 February 2018 Legal Notices Copyright SWIFT 2018. All rights reserved. You may copy this publication within your
More informationOperations Guide - ADVANCE INFORMATION
Operations Guide - ADVANCE INFORMATION This document provides advance information on changes to the X character set, block structure, and user header in FIN sections as part of the Standards Release 2018.
More informationRTGS Application. SWIFT Certified Application. Label Criteria 2018
Label Criteria 2018 This document explains the business criteria required to obtain the SWIFT Certified Application 2018 label for RTGS applications. 26 January 2018 Table of Contents Table of Contents
More informationUser Guide. MyStandards
This user guide explains how to access and use the MyStandards web platform. This document is for users of the MyStandards web platform. 02 February 2018 Table of Contents Table of Contents Preface...
More informationMT - MX Conversion Module
MT - Conversion Module 1 Overview With the increasing usage of XML based ISO 20022 () messages, financial organizations face the problem that their back office applications are not (yet) capable of processing
More informationSWIFT Certified Application Exceptions and Investigations
SWIFT Certified Application Exceptions and Investigations Technical validation Guide 2016 Version 1 February 2016 Legal notices Copyright SWIFT 2016. All rights reserved. You may copy this publication
More informationSWIFT Certified Applications. Trade Finance. Technical validation Guide Version 1.1
SWIFT Certified Applications Trade Finance Technical validation Guide 2017 Version 1.1 February 2017 Legal Notices Copyright SWIFT 2017. All rights reserved. You may copy this publication within your organisation.
More informationCategory 9 - Cash Management and Customer Status
Standards Category 9 - Cash Management and Customer Status For Standards MT November 2018 Message Reference Guide Standards Release Guide This reference guide contains the category 9 message text standards,
More informationSWIFT Certified Applications. Reconciliation. Technical validation Guide Version 1.1
SWIFT Certified Applications Reconciliation Technical validation Guide 2018 Version 1.1 February 2018 Legal notices Copyright SWIFT 2018. All rights reserved. You may copy this publication within your
More informationSWIFT Certified Applications. Trade Finance. Technical validation Guide Version 1.3
SWIFT Certified Applications Trade Finance Technical validation Guide 2018 Version 1.3 May 2018 Legal Notices Copyright SWIFT 2018. All rights reserved. You may copy this publication within your organisation.
More informationCollateral Management
SWIFT Certified Applications Collateral Management Technical validation Guide 2018 Version 1.1 February 2018 Legal notices Copyright SWIFT 2018. All rights reserved. You may copy this publication within
More informationHigh-Level Information
This document describes the requested changes for the next Standards MT Release. These requests must still be validated by a maintenance working group and some may be modified or rejected. Country user
More informationCorporates Trade and Supply Chain Finance
SWIFT Certified Applications Corporates Trade and Supply Chain Finance Technical validation Guide 2018 Version 1.1 February 2018 Legal Notices Copyright SWIFT 2018. All rights reserved. You may copy this
More informationGeneral Information. Standards MT November 2016
This document provides information about all Standards MT (Message Type) categories, and explains the general rules, conventions, and principles for the Standards MTs. The document explains the organisation
More informationHigh-Level Information
This document describes the requested changes for the next Standards MT Release. These requests must still be validated by a maintenance working group and some may be modified or rejected. Country user
More informationSWIFT gpi How payment market infrastructures can support gpi payments
How payment market infrastructures can support gpi payments SWIFT gpi an introduction 3 The role of payment market infrastructures in gpi payments 4 Sending a payment over a local payment market infrastructure
More informationCustomer Security Programme (CSP)
Customer Security Programme (CSP) ACSDA General Assembly Overview Thomas Trépanier April - 2017 Legal Notices: COPYRIGHT SWIFT 2017 - All rights reserved. You may copy this document within your organisation.
More informationEBAM for Corporates. SWIFT Certified Application. Label Criteria 2018
Label Criteria This document explains the business criteria required to obtain the SWIFT Certified Application for Corporates - EBAM label, which is aimed at corporate applications. 26 January Table of
More informationCorporates Trade and Supply Chain Finance
SWIFT Certified Applications Corporates Trade and Supply Chain Finance Technical validation Guide 2019 Version 1 February 2019 Legal Notices Copyright SWIFT 2019. All rights reserved. You may copy this
More informationGeneral Information for Service Bureau
SWIFTNet Connectivity Service Bureau General Information for Service Bureau This document provides an overview of how to establish and use a SWIFT Service Bureau. 12 October 2006 Service Bureau Legal Notices
More informationInterface Certification for a RMA Interface
Title Page Interface Certification for a RMA Interface CGI RMA Conformance Statement Table of Contents Title Page... 1 1 General Information... 3 1.1 Supplier... 3 1.2 Product Information... 3 1.3 Operational
More informationCategory 2 Financial Institution Transfers
SWIFTStandards Category 2 Financial Institution Transfers November 2003 Standards Release 1 Legal Notices Legal Notices IMPORTANT NOTE: You may install and use this publication only if you have entered
More informationUpdated High-Level Information
This document is an updated version of the High-Level Information document that was published on www.swift.com in July 2017. All the expected or requested changes described in that document were validated
More informationPhase 1 ISO Preparation for Fedwire Funds Service (FAIM 4.0) Intermediate Webinar
Phase 1 ISO 20022 Preparation for Fedwire Funds Service (FAIM 4.0) Intermediate Webinar Federal Reserve Banks November 9, 2017 (Revised December 13, 2017) Logistics Dial-In: 1-888-625-5230 Participant
More informationInterface Certification for a Real-time FileAct Messaging Interface
Title Page Interface Certification for a Real-time FileAct Messaging Interface Axway Financial Exchange (Gateway) Conformance Statement Table of Contents Title Page... 1 1 General Information... 3 1.1
More informationInterface Certification for a FIN Interface
Title Page Interface Certification for a FIN Interface BALI400 Conformance Statement Table of Contents Title Page... 1 1 General Information... 3 1.1 Supplier... 3 1.2 Product Information... 3 1.3 Operational
More informationInterface Certification for a FIN Interface
Title Page Interface Certification for a FIN Interface FASTWIRE Open Conformance Statement Table of Contents Title Page... 1 1 General Information... 3 1.1 Supplier... 3 1.2 Product Information... 3 1.3
More informationInfo Paper ISO for Financial Institutions
Info Paper ISO 20022 for Financial Institutions Best Practice for Successful Implementation Contents Executive summary 3 The ISO 20022 standard 3 Growth of ISO 20022 adoption 4 Adoption approaches taken
More informationUpdated High-Level Information
This document is an updated version of the High-Level Information document that was published on www.swift.com on 20 July 2018. All the expected or requested changes described in that document were validated
More informationCMS Messaging Service Service Description & On-boarding Guide v5
CMS Messaging Service Service Description & On-boarding Guide v5 CONTENTS Introduction... 4 The CMS application... 5 Environments... 5 Fees... 5 Availability... 5 Assistance... 5 Accounts... 6 User Access
More informationInterface Certification for a Real-time FileAct Messaging Interface
Title Page Interface Certification for a Real-time FileAct Messaging Interface Connecteur RAHA FileAct Conformance Statement Table of Contents Title Page... 1 1 General Information... 3 1.1 Supplier...
More informationelements) and on the structure and representation of the information (i.e. the message format).
Introduction to MDMI The global financial industry exchanges huge amounts of electronic information. Differences in understanding and interpretation of exchanged electronic information form an important
More informationIslamic Finance. SWIFT Certified Application. Label Criteria 2017
Islamic Finance Label Criteria 2017 This document explains the business criteria required to obtain the SWIFT Certified Application - Islamic Finance 2017 label. 27 January 2017 Islamic Finance Table of
More informationCategory 9 Cash Management & Customer Status
SWIFTStandards Category 9 Cash Management & Customer Status November 2003 Standards Release 1 Legal Notices Legal Notices IMPORTANT NOTE: You may install and use this publication only if you have entered
More informationStandards MT Release 2018 and 2019: Mandatory changes in category 7 and MT 798 Trade Guidelines
Version 2.1 Standards MT Release 2018 and 2019: Mandatory changes in category 7 and MT 798 Trade Guidelines Frequently Asked questions This document describes Frequently Asked Questions (FAQs) about mandatory
More informationINTRODUCTION TO THE ISO AFT USAGE GUIDELINES
INTRODUCTION TO THE ISO 20022 AFT USAGE GUIDELINES INTRODUCTION 1.0 Scope This document outlines the specifications related to the formatting of CPA ISO 20022 Automated Funds Transfer (AFT) payment messages
More informationInterface Certification for a Store-andforward FileAct Messaging Interface
Title Page Interface Certification for a Store-andforward FileAct Messaging Interface AvantGard Trax SWIFT Gateway Conformance Statement Table of Contents Title Page... 1 1 General Information... 3 1.1
More informationInterface Certification for a Real-time FileAct Messaging Interface
Title Page Interface Certification for a Real-time FileAct Messaging Interface IBM Sterling B2B Integrator SWIFTNet MEFG Server Conformance Statement Table of Contents Title Page... 1 1 General Information...
More informationTechnical Reporting Instructions MiFIR Transaction Reporting
Technical Reporting Instructions MiFIR Transaction Reporting 17 July 2017 ESMA/2016/1521 Change History: Version Date Author Comments 1.1 26/10/2016 ESMA Version 1 for publication. 1.4 17/07/2017 ESMA
More informationMessage Reference Guide. Category 2 - Financial Institution Transfers. Standards. For Standards MT November 2017
Standards Category 2 - Financial Institution Transfers For Standards MT November 2017 Message Reference Guide This reference guide contains the category 2 message text standards, including a detailed description
More informationInterface Certification for a Store-andforward InterAct Messaging Interface
Title Page Interface Certification for a Store-andforward InterAct Messaging Interface Total Messaging / IGTplus Conformance Statement Table of Contents Title Page... 1 1 General Information... 3 1.1 Supplier...
More informationBuilding your ISO implementation roadmap
for ISO 20022 Building your ISO 20022 implementation roadmap Kris Vanholst SWIFT 9 June 2015 Agenda ISO 20022 adoption trends Industry harmonisation Implementation considerations Building an ISO 20022
More informationCreating International Wire Transfer Payments Reference Guide
Creating International Wire Transfer Payments Reference Guide Table of Contents Creating and Working with International Wire Transfers 3 Overview 3 Creating a Freeform Payment or Template 3 Approving or
More informationWire & Internal Transfers
Wire & Internal Transfers USER GUIDE Transfer funds easily and securely. Convenience. Transfer money between accounts at Union Bank and different banks domestically and internationally. Ease. Say goodbye
More informationSWIFT FIN MT103. Format Description
SWIFT FIN MT103 Format Description June 2018 Contents 1. SWIFT FIN MT103: SINGLE CUSTOMER CREDIT TRANSFER 3 1.1 Introduction 3 1.2 General information 3 1.3 Format Specification 3 2. TECHNICAL DESCRIPTION
More informationING Format Description MT940 & MT942 Structured NL (V.4)
ING Format MT940 & MT942 Structured NL (V.4) InsideBusiness Connect SwiftNet FIN SwiftNet FileAct EBICS The Netherlands Document version history Version Date Changes 1.0 20-11-2013 First version 2.0 14-02-2014
More informationBANKING CIRCLE WEB BULK UPLOAD
18109 Training Manual - BULK UPLOAD_Layout 1 11/05/2016 10:06 Page 1 Freedom to BANKING CIRCLE WEB BULK UPLOAD SAXO PAYMENTS INTERNET BANKING WHAT IS A BULK PAYMENT? A bulk payment is defined as a payment
More informationALERT BROKER/DEALER DIRECT
ALERT BROKER/DEALER DIRECT MESSAGE SPECIFICATION VERSION 4.1 FEBRUARY 28, 2018 Copyright 2018 DTCC. All rights reserved. This work (including, without limitation, all text, images, logos, compilation and
More informationOracle FLEXCUBE Direct Banking
Oracle FLEXCUBE Direct Banking Corporate Transfer and Payment User Manual Release 12.0.3.0.0 Part No. E52543-01 April 2014 Corporate Transfer and Payment User Manual April 2014 Oracle Financial Services
More informationFIX Orchestra: The Full Stop at the End of FIX
FIX Orchestra: The Full Stop at the End of FIX June 2017 John Greenan, CEO Alignment Systems FIX Orchestra Working Group http://twitter.com/alignmentsys http://blog.alignment-systems.com FIX Orchestra
More informationThe Bank of Russia Standard FINANCIAL MESSAGES IN THE NPS
The Bank of Russia Standard STO BR NPS-1.0-2017 FINANCIAL MESSAGES IN THE NPS GENERAL TERMS Introduction date: 2017-03-20 Official publication Moscow 2017 Preamble 1. ACCEPTED AND ENACTED by The Bank of
More informationOracle FLEXCUBE Direct Banking
Oracle FLEXCUBE Direct Banking Java Application Based Plain Mobile Banking User Manual Release 12.0.2.0.0 Part No. E50108-01 September 2013 Java Application Based Plain Mobile Banking User Manual September
More informationAlliance Monitoring Add-On
Label Criteria 2018 This document provides a structured and detailed view of the criteria that an add-on application must fulfil to obtain the SWIFT Certified Application - Alliance Add-on 2018 label.
More informationBUSINESS JUSTIFICATION
BUSINESS JUSTIFICATION FOR THE DEVELOPMENT OF NEW ISO 20022 FINANCIAL REPOSITORY ITEMS A. Name of the request: Cash aaccount reporting request and Notification messages B. Submitting organization: SWIFT
More informationBankline. Import file layout guide SWIFT MT101 format
Bankline Import file layout guide SWIFT MT101 format Contents 1. Introduction to Bankline SWIFT MT101 import...2 1.1 What is Bankline SWIFT import?...2 1.2 Payment Type Derivation...2 1.3 SWIFT Character
More informationING Format Description
ING Format Structured MT940 & MT942 (Version 4) Strategic InsideBusiness Connect InsideBusiness Payments CEE SwiftNet FIN SwiftNet FileAct Telelink@Isabel EBICS Document version history Version Date Changes
More informationDeutsche Postbank AG. Format Descriptions for Eurogiro Euro Settlement Service ESSP. ESSP Format Descriptions. Page 1.
Deutsche Postbank AG Format Descriptions for Eurogiro Euro Settlement Service ESSP Version, Feb 2009 Deckblatt Format Description Page 1 Contents page Abbreviations... 3 MT202 Settlement Instruction...
More informationStructured ordering and beneficiary customer data in payments
Structured ordering and beneficiary customer data in payments Whitepaper Note: The Payments Market Practice Group (PMPG) is an independent body of payments subject matter experts from Asia Pacific, EMEA
More informationISO Technical Committee Meeting. 26 June 2018
ISO 20022 Technical Committee Meeting 26 June 2018 Joining by webinar Please note that ASX is now using the GoToWebinar platform for this meeting. Details provided by email. Once you have registered and
More informationInternational Securities Association For Institutional Trade Communication
International Securities Association For Institutional Trade Communication MT103 Single Customer Credit Transfer Market Practice Guideline Presented by the United States Settlements/Cash/Treasury Working
More informationSWIFT Adapter User s Guide. Version 10g Release 3 (10.3)
SWIFT Adapter User s Guide Version 10g Release 3 (10.3) SWIFT... 4 TERMINOLOGY... 5 SWIFT CONFIGURATION... 6 SWIFT MESSAGE LIBRARY... 6 CUSTOM SWIFT MESSAGES... 7 CREATING A SWIFT FORMAT... 8 CREATING
More informationDeployment Profile Template Version 1.0 for WS-Reliability 1.1
Deployment Profile Template Version 1.0 for WS-Reliability 1.1 Committee Draft 11 April 2007 URIs: This Version: http://docs.oasis-open.org/wsrm/profile/wsr-deployment-profile-template-cd.pdf Latest Version:
More informationInterface Certification for a Store-andforward FileAct Messaging Interface
Title Page Interface Certification for a Store-andforward FileAct Messaging Interface BOX Messaging Hub (formerly known as BOX For SWIFTNet) Conformance Statement Table of Contents Title Page... 1 1 General
More informationOracle FLEXCUBE Direct Banking
Oracle FLEXCUBE Direct Banking Retail Customer Services User Manual Release 12.0.3.0.0 Part No. E52543-01 April 2014 Retail Customer Services User Manual April 2014 Oracle Financial Services Software Limited
More informationCollateral Management
Collateral Management Label Criteria 2017 This document explains the criteria required to obtain the SWIFT Certified Application - Collateral Management 2017 label. 27 January 2017 Collateral Management
More informationInterface Certification for a Communication Interface
Title Page Interface Certification for a Communication Interface DS_SNL-Gateway Conformance Statement Table of Contents Title Page... 1 1 General Information... 3 1.1 Supplier... 3 1.2 Product Information...
More informationIntroduction to ISO ACG Seminar Colombo, May Alexandre Kech Head of Securities Market Infrastructures & Standards SWIFT APAC
Introduction to ISO 20022 ACG Seminar Colombo, May 2015 Alexandre Kech Head of Securities Market Infrastructures & Standards SWIFT APAC Agenda Introduction What is ISO 20022? Who is driving the adoption?
More informationCorporate Gateway. Mail and Telephone Order Payment Service (Hosted Call Centre) Guide
Corporate Gateway Mail and Telephone Order Payment Service (Hosted Call Centre) Guide V4.2 April 2017 Mail and Telephone Order Payment Service (Hosted Call Centre) Guide > Contents Contents 1 Introduction
More informationUBS Implementation Guidelines
UBS Implementation Guidelines DFÜ Agreement of Deutsche Kreditwirtschaft for Cash Management Reports camt.052.001.02 - DK Version 3.0 UBS Version 1.0 March 2017 Table of Contents 1. Cash Management Reports
More informationSwedish Common Interpretation of ISO Payment Messages Readers Guide
Swedish Common Interpretation of ISO 20022 Payment Messages Readers Guide 1 (2) Version Date Changes 0.1 2013-12-11 Initial version 1.0 2014-02-10 Updates after external review Page 4: Code BD changed
More informationALERT SETTLEMENT INSTRUCTION (SI) SCAN UPLOAD GUIDE FEBRUARY 27, 2018
ALERT SETTLEMENT INSTRUCTION (SI) SCAN UPLOAD GUIDE FEBRUARY 27, 2018 Copyright 2018 DTCC. All rights reserved. This work (including, without limitation, all text, images, logos, compilation and design)
More informationISO Adoption Global trends
ISO 20022 Adoption Global trends Margaux Monforti, ISO 20022 Business Development, SWIFT Wednesday, 28 October 2015, Bucharest ISO 20022 adoption Market Infrastructures Market Infrastructures Financial
More informationCashPro Online. CashPro Online Quick Reference Guide Global Payments Using Bank-Defined Import File Formats
CashPro Online CashPro Online Quick Reference Guide Global Payments Using Bank-Defined Import File Formats CashPro Online Table of Contents About this Guide...3 Global Payments Comma-Separated Value Format...5
More informationStandards MT November High-Level Information. Standards
Standards Standards MT November 2016 High-Level Information This document describes the requested changes for the next Standards Release. These requests must still be validated by a maintenance working
More informationGuide to the Core Components Dictionary. ebxml Core Components
1 2 3 4 5 6 7 8 9 10 11 12 13 14 Guide to the Core Components Dictionary ebxml Core Components 10 May 2001 Version 1.04 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 1 Status of this Document This
More informationBankline. Import file layout guide SWIFT MT101 format
Bankline Import file layout guide SWIFT MT101 format Contents 1. Introduction to Bankline SWIFT MT101 import...2 1.1 What is Bankline SWIFT import?...2 1.2 Payment Type Derivation...2 1.3 SWIFT Character
More informationCERTIFIED MAIL LABELS TERMS OF USE and PRIVACY POLICY Agreement
CERTIFIED MAIL LABELS TERMS OF USE and PRIVACY POLICY Agreement Welcome to Certified Mail Envelopes and Certified Mail Labels web sites (the Site ) a website, trademark and business name owned and operated
More informationImport File Specifications
ScotiaConnect Wire Payments Trademark of The Bank of Nova Scotia. The Bank of Nova Scotia, 2003. No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical,
More information1. Where can I obtain more information about the changes to Category 7 and MT 798 Standards?
1. Where can I obtain more information about the changes to Category 7 and MT 798 Standards? On the SWIFT Web site under Standards releases Page 1 Cat 7 Frequently Asked Questions Common 2. What are the
More informationModel Driven Data Interoperability (MDMI)
Model Driven Data Interoperability (MDMI) An OMG Finance Domain task Force Presentation 12/11/2008 By Mark Eisner, co chair 11/27/06 Slide 1 Some of the problem The current messaging environment inhibits
More informationBKT KOSOVA BUSINESS E-BANKING USER MANUAL
BKT KOSOVA BUSINESS E-BANKING USER MANUAL Copyright BKT 2017. All rights reserved No part of this publication may be reproduced, translated, adapted, arranged or in any way altered, distributed, communicated,
More informationOracle Banking Digital Experience
Oracle Banking Digital Experience Corporate File Upload User Manual Release 18.2.0.0.0 Part No. E97823-01 June 2018 Corporate File Upload User Manual June 2018 Oracle Financial Services Software Limited
More informationSELF ASSESSMENT OF SEPA COMPLIANCE November, 2013
SELF ASSESSMENT OF SEPA COMPLIANCE November, 2013 Bucharest, November 2013 This document constitutes the self-assessment of TRANSFOND`s system SENT against the Eurosystem s SEPA-compliance criteria. The
More informationQR Code Specification for Payment Systems (EMV QRCPS)
EMV QR Code Specification for Payment Systems (EMV QRCPS) Merchant-Presented Mode Version 1.0 July 2017 Legal Notice The EMV Specifications are provided AS IS without warranties of any kind, and EMVCo
More information