MT 103 Frequently asked questions

Business Reasons for / Benefits of the MT 103 Why was the MT 103 created? The origins of the MT 103 lie in the SWIFT MT 100 message, the traditional customer payment message, which was developed 25 years ago and is still the most heavily used message on the SWIFT network. The MT 103 introduces more certainty, transparency and automation than the MT 100. Certainty Due to the many differing possibilities and default values in the MT 100, the message is interpreted differently by financial institutions. The clearest example is the charging option field, where you can only indicate BEN or OUR. If no option is identified, the User Handbook says that BEN should be understood. But BEN is processed differently by receivers: sometimes all charges are paid by the beneficiary, sometimes charges are shared. The MT 103 brings clarity by providing three different code words: OUR, BEN and SHA. Furthermore, the charging option field is mandatory in the MT 103, which avoids different interpretations. Transparency Increasingly, transparency is becoming a regulatory requirement. Especially in the European Union (EU), the European Commission and European Parliament are mandating more transparency in cross-border customer transfers. The MT 103 provides the framework to achieve this with a number of new, dedicated fields, for example, instructed currency and amount, regulatory reporting fields, charging fields and exchange rate, etc. Automation Governments are pushing banks to lower the cost and decrease the execution time for cross-border transfers towards the level of domestic payments. The only way to achieve this is to decrease the internal processing costs, that is, to increase automation. Several measures have been taken in the MT 103 to ensure higher STP rates at the receiver's applications, for example, instruction codes in dedicated fields, instead of free text in a free format field.

Why was the MT 103+ created? When the recommendation to change the MT 103 message to General Use was approved by the SWIFT Board, early in 1999, different Euro clearing systems and banking organisations started to define a subset of the message. Their first goal was to define a more structured, tighter message format to improve STP, to reduce processing cost and to enable reduced fees for cross-border Euro transactions. To avoid a proliferation of different versions of the MT 103, all parties (clearing systems, commercial banks, European Central Bank) came together in a sub-committee of the market practice group then known as the Heathrow Group, to list the requirements. The resulting list was used by SWIFT to define the MT 103+ message. Just like the Core MT 103, the MT 103+ can be used worldwide. The MT 103+ was not able to replace the Core MT 103 completely, because there is always a need to be able to instruct a payment when only less automated information is available.

Since the Standards Release 2001, a similar version of the MT 102 Multiple Customer Credit Transfer has been made available, the MT 102+.

What added value does the MT 103 have over the MT 100? The MT 103 offers you more functionality than the MT 100. At the same time, the MT 103 caters for all existing possibilities of the MT 100. The MT 103 transports more structured information, and therefore enables higher STP rates and reduces processing costs. Several modifications have been made compared to the MT 100 to achieve this. The unstructured information of the MT 100 is available in the MT 103 in coded form. The MT 103: - Can identify a third reimbursement institution (Field 55a: Third Reimbursement Institution) - Has a dedicated field to convey an instructed currency and amount (Field 33B: Currency/Instructed Amount) - Has a dedicated field to convey an exchange rate (Field 36: Exchange Rate) - Contains codes to give instructions to the receiver (repetitive Field 23E: Instruction Code) - Allows for the inclusion of BEI (Business Entity Identifier) (Field 50a: Ordering Customer and Field 59a: Beneficiary Customer) The MT 103 provides additional information that cannot be transported in the MT 100. It: Allows identification of SWIFT Service Level Agreements (SLA) (Field 23B: Bank Operation Code) - Has dedicated fields to convey charges information (Field 71A: Details of Charges, Field 71F: Sender's Charges, Field 71G: Receiver's Charges) - Allows transport of regulatory information (Field 26T: Transaction Type Code, Field 77B: Regulatory Reporting) The SWIFT network carries out additional validation on the MT 103. The MT 103: Mandates a charging option - Validates the charges information, depending on the charging option used - Mandates the instructed amount for a number of countries (so-called European validation Click here for the full list of countries) - Enables greater STP by using a restricted set of fields and format options (MT 103+)

Comparison of MT 100 versus MT 103 What are the differences in format specifications between the MT 100 and MT 103? Summary of differences between MT 100 and MT 103 MT 100 Field 20:Transaction Reference Number Field 32A: Value date, Currency Code, Amount Field 70: Details of Payment MT 103 Field 20: Sender's Reference Field 32A: Value date/ Currency/ Interbank Settled Amount Field 70: Remittance Information Field 50a 50A or K: Ordering Customer

Changed field names

Changes to field tags and Field 50: Ordering Customer options

Field 59: Beneficiary Customer

Changes to status New fields

Field 56a A, D: Intermediary Field 57a A, B or D: Account with Institution Field 71A: Details of Charges Optional

Field 59a 59A or 59: no letter option Beneficiary Customer Field 56a A, C or D: Intermediary institution Field 57a A, B, C or D: Account with Institution Field 71A: Details of Charges Mandatory Field 23B: Bank Operation Code Field 23E : Instruction Code (repetitive) Field 26T : Transaction Type Code Field 33B: Currency/Instructed amount Field 36: Exchange Rate Field 51A: Sending Institution Field 55a: Third Reimbursement Institution Field 71F: Sender's Charges (repetitive) Field 71G: Receiver's Charges Field 77B: Regulatory Reporting Field 77T : Envelope Contents

MT 100 removal date What will happen to the MT 100? After country consultation in June 2000, the SWIFT Board Operations Committee approved the decision to remove the MT 100 from the SWIFT network as of Standards Release 2003, on 15 November 2003. Until that time, the MT 100 is still a valid message type, both for sending and receiving. Since 18 November 2000 however, each user MUST at least be able to receive the MT 103. Maintaining two message types, used for the same purpose, may be an expensive option.

Different version of the MT 103 Core MT 103/MT 103+/MT 103 REMIT - Why are there so many different versions of the MT 103? There is one, and only one MT 103 message, but this MT 103 can be used under three different versions: Core MT 103, MT 103+ and MT 103 REMIT. To be able to cater for different business requirements, the SWIFT user community decided to create these three versions of the MT 103.

These three versions can all be used under two profiles (EU/non EU), resulting in six possible scenarios.

What is the Core MT 103 (commonly called MT 103)? The Core MT 103 is the generic Single Customer Credit Transfer. It allows the exchange of Single Customer Credit Transfers using all MT 103 fields, except Field 77T: Envelope Contents. Based on this version you have two additional versions of the MT 103: MT 103+ MT 103 REMIT The Core MT 103 is a General Use message, that is, no registration in a MUG is necessary to send and receive this message.

What is the MT 103+? The MT 103+ is a subset of the Core MT 103. It limits the number of fields and the number of field options to those that allow STP. This restricted format is validated on the SWIFT network to guarantee the receiver a correct straight through processable message. The fact that the MT 103+ is a subset of the Core MT 103 allows any receiver to process the MT 103+. A receiver does not have to know that the message is identified as a '+' message. However, the message should result in higher STP rates and lower processing time. The most important additional areas of validation, compared to the Core MT 103, are: The MT 103+ is identified with a code "STP" in the user header (block 3, field 119) of the message. For SWIFT this code is the trigger to start the additional validation. Financial Institutions can be identified with a BIC only (Fields 52a: Ordering Institution, 54a: Receiver's Correspondent, 55a: Third Reimbursement Institution, 56a: Intermediary Institution and 57a: Account with Institution may only be used with letter option A). Field 53a: Sender's Correspondent may only be used with option A to identify a financial institution or with option B to identify an account number to be credited/debited. The instruction code list is reduced to codes that can be processed straight through (Field 23E: Instruction Code may only contain codes CORT, INTC and SDVA). The beneficiary's account number is mandatory in order to ensure STP until the credit on the account of the final recipient. (Subfield 1 (Account) of Field 59A/Field 59: Beneficiary Customer is always mandatory). The introduction of IBAN improves the quality of the account number information. The IBAN is mandatory for the intra-European MT 103+ since November 2002. The use of the free format field is reduced. (In Field 72: Sender to Receiver Information, code INS must be followed by a valid BIC, codes REJT/RETN must not be used and ERI information may not be present).

The MT 103+ is a General Use message, that is, no registration in a MUG is necessary to send and receive this message. Just like the Core MT 103, the MT 103+ is available worldwide.

What is the MT 103 REMIT?

The MT 103 REMIT was developed to allow financial institutions to offer their ordering customers the possibility of sending more information to the beneficiary customer than the Core MT 103 allows. The MT 103 Extended Remittance Information MUG allows subscribers to exchange the MT 103 with Field 77T: Envelope Contents, containing extended amounts of remittance information (up to 9000 characters). This remittance information may optionally be exchanged in a non-SWIFT format such as EDIFACT or ANSI-X12. Field 70: Remittance Information, must not be used in the MT 103 REMIT. Core MT 103 and MT 103+ contain Field 70: Remittance Information, to transmit information that the ordering customer wants to forward to the beneficiary customer. Field 70: Remittance Information, may contain up to 4 lines of 35 SWIFT-allowed characters. Field 77T: Envelope Contents, cannot be used in the Core MT 103 /MT 103+. The MT 103 REMIT has been available in the MT 103 Extended Remittance Information Message User Group (MUG) on the SWIFT network since 1997. It will stay in this MUG until further notice. As a sender, you indicate that you want to send an MT 103 REMIT by inserting the code REMIT in field 119 of the User Header (Block 3) of your SWIFT message. Since both sender and receiver have to be registered in the MT 103 Extended Remittance Information MUG, the receiver should be able to receive and process the MT 103 REMIT. SWIFT will negatively acknowledge your MT 103 REMIT if you send it to a receiver who is not registered in this MUG. Using the MT 103 How soon do I need to start sending MT 103s? The MT 100 will be removed from the FIN network on 15 November 2003. Today, on the sending side, you can still use the MT 100. But when the MT 100 is deleted from the network on 15 November 2003, the MT 103 will be the only Single Customer Credit Transfer message available. Several banks have confirmed that updating their applications for the sending and receiving sides at the same time is much more cost efficient than splitting the sending and receiving parts. Postponing the update of the sending applications until the deletion of the MT 100 may result in inefficient use of time and resources.

What does 'General Use of the MT 103' mean as of Standards Release 2000? The Core MT 103 and MT 103+ became General Use with the Standards Release 2000. General Use means that no registration in a Message User Group (MUG) is necessary to send and receive the Core MT 103 and MT 103+. Therefore: Since 18 November 2000, each individual user might receive a Core MT 103 and/or MT 103+ and must be able to process it. On the sending side, any user can choose between the MT 100 Customer Transfer and the MT 103 Single Customer Credit Transfer.

The MT 103 REMIT stays in the MT 103 Extended Remittance Information MUG. Since the MT 103+ is a subset of the Core MT 103, any institution that can receive the Core MT 103, can also receive the MT 103+.

What happened to the Core MT 103 Message User Group (MUG)? The Core MT 103 MUG was automatically removed on 18 November 2000, as every SWIFT user had to be able to receive the Core MT 103/MT 103+.

Can I send an MT 103+ in the MT 103 Extended Remittance Information Message User Group (MUG)? No, since subfield 119 of the user header (block 3) needs to contain the code word STP for the MT 103+, you cannot add the code word REMIT in the same field. Only one of these code words can be used in this field.

What if my correspondent refuses to receive the MT 103? SWIFT's position is very clear and was confirmed in two broadcasts sent on 31 October 2000 and 6 November 2001. Extract of broadcast sent on 31 October 2000: "Adherence to the message standard and address policies is part of the user's contract with SWIFT, as published in the FIN policy volume of the SWIFTStandards User Handbook. All SWIFT users must be able to receive and act upon all of the general use messages associated with their category of membership. To allow the SWIFT user community to fully integrate the MT 103 in their internal banking environment, a migration period of 3 years has been put in place during which the MT 100 is still available. However, a big part of the user community has fully implemented the MT 103. If these users decide to send MT 103/MT 103+ exclusively, they are completely in line with the message standards policy". Extract of broadcast sent on 6 November 2001: "All SWIFT users are reminded of their obligation to adhere to the message standards and address policies as published in the FIN policy volume of the user handbook. Some users have indicated that they will reject incoming MT 103 messages because they are not yet ready to process this new message type. This approach contravenes SWIFT policy. SWIFT takes this opportunity to confirm to its users that as indicated in the liability section of the FIN policy volume (part II Chapter 4.3), if the receiver does not process with appropriate value messages that are validly addressed and interest is lost due to a late payment, the receiver of the SWIFT message is liable". Cost of the MT 103 Will SWIFT charge differently for the MT 103+ and the Core MT 103?

Charging on the SWIFT network is the same for both messages. Costs charged by correspondents or clearing banks for processing the MT 103+ is a commercial decision of those banks and outside SWIFT's scope. However, some financial institutions (especially in Europe) see a benefit in receiving MT 103+ and will actively offer a discount for quality STP messages.

TIPS: How can I control the length of the MT 103? Avoid unnecessary duplication of information Unless otherwise specified by specifications from the RTGS system, there is no need to indicate "cover" parties (Field 53a: Sender's Correspondent and Field 54a: Receiver's Correspondent) when routing a payment through a RTGS system. Avoid unnecessary "hard-coded" information in Field 72: Sender to Receiver Information The basic rule is that Field 72: Sender to Receiver Information, should not contain information already present in other fields. Strings such as /REC/Charges already deducted' are unnecessary. The interbank settled amount in Field 32A: Value Date/Currency/Interbank Settled Amount, should already take into account the charges. Avoid leaving leading zeros in amount field Format of amount fields in 15d (including the decimal comma separator). If the amount is low, there is no need to include leading zeros. Avoid filling zeroes in decimal part of amount If the amount ends without a decimal part, simply end the amount field with the decimal separator (comma) Whenever possible, rationalise the remittance information A series of codes exists to shorten the remittance information (/RFB/, /INV/, /ROC/, /IPI/ ). Depending on the remittance information origin or destination, there is a technical possibility to shorten the field, for example, /INV/ for invoice. Use the appropriate field to specify information Avoid quoting account numbers in Field 72: Sender to Receiver Information. The account number of the beneficiary's customer is to be quoted in Field 59a: Beneficiary Customer.

Impact of Standards Releases on the MT 103 What changed in the MT 103 with Standards Release 2001? Changes were minimal and can be summarized as follows: Addition of optional Field 13C: Time Indication Additional validation is carried out on Field 23E: Instruction Code, to enhance STP: o the relationship between some of the codes in 23E and presence of Field 56a: Intermediary Institution and Field 57a: Account with Institution 1. If Field 56a: Intermediary Institution is not present, no Field 23E: Instruction Code may contain TELI or PHOI.

2. If Field 57a: Account with Institution is not present, no Field 23E: Instruction code, may contain TELE or PHON. the order of the codes: if Field 23E: Instruction Code is used more than once, the codes must appear in the order described in the User Handbook. if Field 23E: Instruction Code is present more than once, the following combinations are not allowed: The same code twice o SDVA with HOLD o SDVA with CHQB o INTC with BONL o INTC with HOLD o INTC with CHQB o CORT with BONL o CORT with HOLD o CORT with CHQB o HOLD with CHQB o PHOB with TELB o PHON with TELE o PHOI with TELI Additional validation is carried out on the financial institution party fields to ensure they do not contain BEIs (Business Entity Identifier), but only SWIFT-registered BICs, either connected or non-connected.

What has changed in the MT 103 with Standards Release 2002? Since 16 November 2002, the following additional rules are validated for the MT 103 and MT 103+: No zero amount is allowed in Field 71G: Receiver's Charges The currency of Field 71G: Receiver's Charges, has to be equal to the currency of Field 32A: Value Date/Currency/Interbank Settled Amount. If the currencies of Field 32A: Value Date/Currency/Interbank Settled Amount and Field 33B: Currency/Instructed Amount are equal, then Field 36: Exchange Rate, is not allowed. For the intra-European MT 103+, the account number line of the beneficiary customer must contain a correct IBAN. The countries affected are: o Andorra (AD) o Austria (AT) o Belgium (BE) o Bouvet Island (BV) o Switzerland (CH) o Germany (DE) o Denmark (DK) o Spain (ES) o Finland (FI) o France (FR) o United Kingdom (GB) o French Guiana (GF)

o o o o o o o o o o o o o o o o o o o o

Gibraltar (GI) Guadeloupe (GP) Greece (GR) Ireland (IE) Iceland (IS) Italy (IT) Liechtenstein (LI) Luxembourg (LU) Monaco (MC) Martinique (MQ) The Netherlands (NL) Norway (NO) Saint Pierre and Miquelon (PM) Portugal (PT) Reunion (RE) Sweden (SE) Svalbard and Jan Mayen Island (SJ) San Marino (SM) French Southern Territories (TF) Holy See Vatican City State (VA)

Full details of these rules can now be found in the final Standards Release Guide 2003 and in the UHB 2003 which was distributed on 12 September 2003. Please also refer to the IBAN chapter of these frequently asked questions. Fields and Rules

Field 23B: Bank Operation Code

What are the SWIFT Service Level Agreements (SLA) you can indicate in the MT 103? SWIFT Service Level Agreements (SLA) are 'transaction standards'. They propose standard, legal and operational frameworks, which enable financial institutions to focus on 'quality of transaction' within communities of correspondents. SLAs help SWIFT members improve the quality of their cross-border payments service by providing certainty and transparency to their customers. Both the MT 103 and the MT 103+ support the three SWIFT Service Levels: Priority, Standard and SWIFTPay. Field 23B: Bank Operation Code provides the possibility of referring to these service levels by using the codes SPAY (SWIFTPay), STTD (Standard) and SPRI (Priority). A Core MT 103/ MT 103+ message exchanged outside a SWIFT Service Level Agreement is identified with the code CRED.

What are the advantages of these SLAs? The Service Level Agreements enable users to improve end-to-end certainty and quality in crossborder payments, thanks to the standardisation of charges, execution time, remittance information integrity and redress procedures in case of processing problems.

What is the Service Level Validation of the Core MT 103/MT 103+? 1. Core MT 103 and Service Level Validation If you send the Core MT 103 under a Service Level (Field 23B: Bank Operation Code contains SPAY, STTD or SPRI), additional validation is applied to ensure the messages meet the requirements of the corresponding service level. Additional party validation Field 23B: Bank Operation Code contains SPAY, SSTD or SPRI Options A, D Field 23B: Bank Operation Code contains CRED Options A, D

Field 52a: Ordering Institution Field 53a: Sender's Correspondent Field 54a: Receiver's Correspondent Field 55a: Third Reimbursement Institution Field 56a: Intermediary Institution Field 57a: Account With Institution Field 59a: Beneficiary Customer

Options A, B (Account Number only) Options A, B, D Option A Option A SPRI-> field 56 not allowed SPAY/SSTD -> Options A, C Options A, C, D (mandatory identifier) Account number line is mandatory Options A, B, D Options A, B, D Options A, C, D Options A, B, C, D Account number line is optional

Additional validation of Field 23E: Instruction Code If Field 23B: Bank Operation Code is ... SPRI SSTD SPAY CRED Field 23E: Instruction Code is Optional. It can only contain SDVA, TELB, PHOB or INTC. Not allowed. Not allowed. Optional. It can contain any codeword.

2. MT 103+ and Service Level Validation If you send the MT 103+ under a Service Level (Field 23B: Bank Operation Code contains SPAY, STTD or SPRI), the MT 103+ will be validated according to the (stricter) validation rules of the MT 103+ and will also be submitted to the corresponding service level validation. MT 103+ Validation Field 52a: Ordering Institution Field 53a: Sender's Option A only Options A, B (Account Number Additional Service Level validation

Correspondent Field 54a:Receiver's Correspondent Field 55a: Third Reimbursement Institution Field 56a: Intermediary Institution

only) Option A only Option A only Option A only If Field 23B: Bank Operation Code contains SPRI, Field 56a: Intermediary Institution is not allowed

Field 57a: Account with Institution Field 59a: Beneficiary Customer

Option A only

Field 59a: Beneficiary Customer Account number line is mandatory Field 59a : 23E Instruction Can only contain If Field 23B: Bank Operation Code CORT, INTC, SDVA Code contains CRED : CORT, INTC, SDVA SPRI : SDVA or INTC only SPAY : Field 23E: Instruction Code not allowed SSTD : Field 23E: Instruction Code not allowed Field 72: Sender to Receiver Codes /REJT/ or /RETN/ must information not be used in this field

Field 23E: Instruction Code

Does SWIFT validate Field 23E: Instruction Code? Since Standards Release 2001 SWIFT performs additional validation on Field 23E: Instruction Code to enhance STP: The relationship between some of the codes in Field 23E: Instruction Code and presence of Field 56: Intermediary Institution and Field 57a: Account With Institution: 1. If Field 56a: Intermediary Institution is not present, no Field 23E: Instruction Code may contain TELI or PHOI. 2. If Field 57a: Account With Institution is not present, no Field 23E: Instruction Code may contain TELE or PHON. The order of the codes: if Field 23E: Instruction Code is used more than once, the codes must appear in the order described in the User Handbook. If Field 23E: Instruction Code is present more than once, the following combinations are not allowed: The same code twice o SDVA with HOLD o SDVA with CHQB o INTC with BONL o INTC with HOLD o INTC with CHQB o CORT with BONL o CORT with HOLD

o CORT with CHQB o HOLD with CHQB o PHOB with TELB o PHON with TELE o PHOI with TELI Since Standards Release 2002, if 23E is present more than once, the following additional combinations will not be allowed: - REPA with HOLD - REPA with CHQB - REPA with BONL - REPA with CORT

What is the code REPA? The code REPA stands for Related E-Payment Reference. It is available since the Standards Release 2002. The REPA code links the original e' payment instruction message to the related FIN payment instruction.

Field 33B: Currency/Instructed Amount

When do I have to use field 33B: Currency/Instructed Amount? The use of Field 33B: Currency/Instructed Amount is conditional. It must be used: if Field 71F: Sender's Charges or Field 71G: Receiver's Charges are present in the MT 103 For transfers within Europe , that is, if the Sender's and Receiver's BIC have a country code within the following list: AD, AT, BE, BV, CH, DE, DK, ES, FI, FR, GB, GF, GI, GP, GR, IE, IS, IT, LI, LU, MC, MQ, NL, NO, PM, PT, RE, SE, SJ, SM, TF and VA.

Do charges impact Field 33B:Currency/Instructed Amount? Yes, for transparency reasons, whenever Field 71F: Sender's Charges or Field 71G: Receiver's Charges is used, Field 33B: Currency/Instructed Amount becomes mandatory. The amount in Field 33B : Currency/Instructed Amount remains unchanged. Charges amounts only impact the settlement amount in Field 32A: Value Date/Currency/Interbank Settled Amount.

Field 36: Exchange Rate

When do I have to use Field 36: Exchange Rate? The use of Field 36: Exchange Rate is conditional.

It must be present for information purposes if Field 33B: Currency/Instructed Amount is present and the currency code in Field 33B: Currency/Instructed Amount is different from the currency code in Field 32A: Value Date/Currency/Interbank Settled Amount. In all other cases, Field 36: Exchange Rate is not allowed.

Field 13C: Time Indication

What is Field 13C: Time Indication? When should it be used? The Field 13C: Time Indication, specifies one or several time indication(s) related to the processing of the payment instruction. Three codes may be used in this field: /CLSTIME/ - Time by which funding payment must be credited, with confirmation, to the CLS Bank's account at the central bank, expressed in CET. /RNCTIME/ - Time at which a TARGET payment has been credited at the receiving central bank, expressed in CET. /SNDTIME/ - Time at which a TARGET payment has been debited at the sending central bank, expressed in CET. RNCTIME and SNDTIME may be used in payments exchanged in the framework of the Target system. These codes have been created to allow the banks to handle their liquidity management when using Euro RTGS systems. To enable the receiving commercial bank to determine whether the received payment is late, and consequently whether compensation guidelines possibly apply, it needs to determine whether the received payment is late, that is, it needs to know the debit time at the sending National Central Bank (SNDTIME). The same mechanism is applied to indicate the credit time on the account of the receiving commercial bank at the receiving National Central Bank (RNCTIME).

Field 70: Remittance Information

What is the code IPI? The code IPI stands for International Payment Instruction. It is available since the Standards Release 2002. It can be used in the remittance information field to indicate that a unique reference identifying a related International Payment Instruction follows the code. Neither the format nor the content of the reference is validated by SWIFT. More information on the IPI can be found on the www.ecbs.org website. Validation What is the European validation? Who composed the list of European countries? The specific European validation which applies to Field 33B: Currency/Instructed Amount, and to the IBAN as of Standards Release 2002 is the following: When the BICs of both the sender and the receiver of an MT 103 have a country code within the following list, the instructed currency and amount (Field 33B: Currency/Instructed Amount) is mandatory: AD, AT, BE, BV, CH, DE, DK, ES, FI, FR, GB, GF, GI, GP, GR, IE, IS, IT, LI, LU, MC, MQ, NL,

NO, PM, PT, RE, SE, SJ, SM, TF and VA. The European validation will also apply to the mandatory presence of IBAN in Field 59a: Beneficiary Customer of the MT 103+ and MT 102+. For full details, please refer to SRG 2003 and UHB 2003 or to the IBAN section of the FAQ. SWIFT's Standards Department has asked for feedback from all User Group Chairpersons about: the European countries that have overseas territories with dedicated country codes the EEA (European Economic Area) countries, since some of them agreed to apply the EC-Directive voluntarily the city states (or their representing User Group Chairperson) within Europe. The User Group Chairpersons of these countries have confirmed or denied that their country should be in the list to which the validation applies. Several User Group Chairpersons ask that SWIFT should clarify that this validation does not mean that a country is legally obliged to apply the EC Directive. CC AD AT BE BV CH DE DK ES FI FR GB GF GI GP GR IE IS IT LI LU MC MQ NL NO PM PT Country Andorra Austria Belgium Bouvet Island Reason why the validation is applied City State within the EU, voluntarily applying the EC Directive EU Member State, legally obliged to apply the EC Directive EU Member State, legally obliged to apply the EC Directive Norwegian overseas territory, voluntarily applying the EC Directive Switzerland EFTA Member State, partly applying the EC Directive Germany EU Member State, legally obliged to apply the EC Directive Denmark EU Member State, legally obliged to apply the EC Directive Spain EU Member State, legally obliged to apply the EC Directive Finland EU Member State, legally obliged to apply the EC Directive France EU Member State, legally obliged to apply the EC Directive United Kingdom EU Member State, legally obliged to apply the EC Directive French Guiana French overseas territory, legally obliged to apply the EC Directive Gibraltar British overseas territory, voluntarily applying the EC Directive Guadeloupe French overseas territory, legally obliged to apply the EC Directive Greece EU Member State, legally obliged to apply the EC Directive Ireland EU Member State, legally obliged to apply the EC Directive Iceland EEA Member State, voluntarily applying the EC Directive Italy EU Member State, legally obliged to apply the EC Directive Liechtenstein EEA Member State, voluntarily applying the EC Directive Luxembourg EU Member State, legally obliged to apply the EC Directive Monaco City State within the EU, voluntarily applying the EC Directive Martinique French overseas territory, legally obliged to apply the EC Directive The Netherlands EU Member State, legally obliged to apply the EC Directive Norway EEA Member State, voluntarily applying the EC Directive Saint Pierre and Miquelon French overseas territory, legally obliged to apply the EC Directive Portugal EU Member State, legally obliged to apply the EC Directive

RE SE SJ

Reunion

Sweden Svalbard and Jan Mayen Islands SM San Marino TF French Southern Territories VA Vatican City

French overseas territory, legally obliged to apply the EC Directive EU Member State, legally obliged to apply the EC Directive Norwegian overseas territory, voluntarily applying the EC Directive City State within the EU, voluntarily applying the EC Directive French overseas territory, legally obliged to apply the EC Directive City State within the EU, voluntarily applying the EC Directive

Remarks: The UGCs confirmed that the validation should not be applied for several other overseas territories (Guernsey, Jersey, Isle of Man, Mayotte, ...)

Does SWIFT validate the amount-related fields? SWIFT will validate the presence of the amount-related Fields (32A: Value Date/Currency/Interbank Settled Amount, 33B: Currency/Instructed Amount, 36: Exchange Rate, 71A: Details of Charges, 71F: Sender's Charges and 71G: Receiver's Charges) according to the network-validated rules as published in Standards Release Guide 2003 and the User Handbook 2003 (which is available since 12 September 2003). SWIFT also validates the format of those fields, for example, currency codes, amount and exchange rate structure. SWIFT does not re-calculate the content of those fields, that is, re-calculate field 32A based on the information in Fields 33B: Currency/Instructed Amount, 36: Exchange Rate, 71A: Details of Charges and 71F :Sender's Charges:/71G :Receiver's Charges: . Fields 33B: Currency/Instructed Amount, 36: Exchange Rate, 71F: Sender's Charges are transmitted for information purposes only and should consequently be handled by the Receiver accordingly. Since the exchange rate only applies to the instructed amount in Field 33B: Currency/Instructed Amount (and not to the charges), and since the sender's charges may be quoted in any existing ISO currency, it may furthermore sometimes not be possible to re-calculate the amount in Field 32A: Value Date/Currency/Interbank Settled Amount. Charges Where can I find the charges of my correspondent? If you use option OUR, Field 71G: Receiver's Charges is optional. In order to promote STP and transparency, and to meet requirements of regulatory bodies (such as the EC Directive on cross-border transfers), this field should be completed if charges are known. Transaction charges can be: stipulated under the conditions you have agreed upon with your correspondent stored either electronically or paper-based in your institution

Which charging option shall I use? Field 71A: Details of Charges, defines which party should bear the charges:

BEN: All transaction charges are to be borne by the beneficiary customer OUR: All transaction charges are to borne by the ordering customer SHA: Transaction charges on the Sender's side are to be borne by the ordering customer, transaction charges on the Receiver's side are to be borne by the beneficiary customer

How do I calculate the charges? In case of an OUR option, field 71G (Receiver's Charges) is to be used once. In this case, field 32A (Value Date/Currency/ Interbank Settled Amount) will be the sum of field 33B (Currency/Instructed Amount), taking into account the exchange rate if currencies in fields 33B and 32A are different, and field 71G. In case of a BEN option, field 71F (Sender's Charges), can be repeated. In this case, along the chain, field 32A (Value Date/Currency/Interbank Settled Amount), will be the difference between field 33B (Currency/Instructed Amount) and the sum of all fields 71F. Charges should be indicated in the order in which they have been deducted from the transaction amount, that is, the first occurrence of this field specifies the charges of the first bank in the transaction chain that deducted charges; the last occurrence always gives the last Sender's charges. In case of a SHA scenario, the original Sender, and potentially the financial institution acting on behalf of the Sender, will claim his/their charges directly from the Ordering Customer. Therefore, field 71G (Receiver's Charges) is not allowed. All other charges, that is Intermediaries charges, will be paid by the Beneficiary Customer and thus be deducted along the chain and mentioned in field(s) 71F. Field 32A (Value Date/Currency/Interbank Settled Amount), will logically be the difference between field 33B (Currency/Instructed Amount) and the sum of all fields 71F (Sender's charges). Charges should be indicated in the order in which they have been deducted from the transaction amount, that is, the first occurrence of this field specifies the charges of the first intermediary bank in the transaction chain that deducted charges.

How many times can Field 71F: Sender's Charges, be repeated? SWIFT will not validate the number of times Field 71F: Sender's Charges is repeated. However, each party that is entitled to quote and deduct its charges in the transaction chain should only use the field once. Charges should be indicated in the order in which they have been deducted from the transaction amount. This means the first occurrence of this field specifies the charges of the first bank in the transaction chain that deducted charges; last occurrence always gives the charges of the sender of the last MT 103 in the chain. Guidelines on how to use Field 71F: Sender's Charges in a serial payment: If the charging option is BEN in the MT 103 that you receive, Field 71F: Sender's Charges may already be present. You use another occurrence of Field 71F: Sender's Charges to quote your own charges and deduct your charges from the amount in Field 32A: Value Date/Currency Code/Interbank Settled Amount, when sending your MT 103 to the next party in the chain.

If charges in Field 71G: Receiver's Charges are insufficient, can the receiver claim the difference from the sender? If yes, how should this be done?

Yes, depending on the account relationship that exists between the sender and the receiver, the receiver can either send an MT 190 (Advice of Charges, Interest and Other Adjustments) or an MT 191 (Request for Payment of Charges, Interest and Other Expenses) to the sender of the MT 103. The MT190 is used to advise payment of charges, interest and/or other expenses which are previously unknown to the receiver or which were not catered for sufficiently by the sender. In this case, the receiver has debited the charges from the sender's account. The MT191 is used to request payment of such charges. It is used when there is no account of the sender in the books of the receiver or when there is no agreement or mandate for the receiver to debit this account. IBAN What is an IBAN? The IBAN, the International Bank Account Number, is defined in the official ISO13616 Standard. It provides a unique and automatically processable identification of a customer's account serviced by a bank. The mandatory presence of the IBAN in the MT 103+/102+ since Standards Release 2002 is a European initiative, requested by the Banks to allow Straight Through Processing (STP) and to adhere to European Market Practice. Therefore, the IBAN must be present when Sender and Receiver (and Account with Institution, if present) have a BIC code whose country code falls within the European validation list of countries (Click here for the full list of countries). The IBAN ISO format is 2!a2!n30c. This format follows the ISO convention for data element representation where "a" represents letters (alphabetical characters a-z and A-Z only). Example: BE62510007547061 (BE: ISO Country Code 62: check digits 510007547061: bank, branch and account number identification, up to 30 characters, and nationally defined)

Where can I get an IBAN? The account-servicing bank is responsible for calculating the IBAN and for providing it to its customers, upon request.

Can I use any character set to fill in the IBAN? No, for the domestically defined part of the IBAN (30c'), you must use the characters that fall under SWIFT 'c' character, that is, alphanumeric characters of the SWIFT character set. This means that only alphabetic characters (upper case) and digits are accepted. Therefore, characters such as slashes, blank spaces and dots are prohibited. Wrongly formatted IBANs will result in nack'ed messages.

Is the IBAN Mandatory in an MT 103+? The IBAN is mandatory in Field 59a: Beneficiary Customer, of the MT 103+ and MT 102+ since the Standards Release 2002 for the intra-European countries. (Click here for the full list of countries). For full details on the validation, please refer to SRG 2003 and UHB 2003.

Will SWIFT validate the IBAN? The IBAN can be used in any account number field or in the optional party identifier line of the party fields, wherever an account number can be present today. The most abused Straight Through Processing rule is the absence of the ordering and beneficiary parties' identification. Therefore, it is felt that IBANs will first appear in SWIFT messages to identify the non-financial institution customers' accounts. In Field 59a: Beneficiary Customer, of the MT 103+ and MT 102+, the IBAN has been mandatory since the Standards Release 2002 for the intra-European countries The account servicing institution must still be identified in the appropriate field, even if an IBAN is specified for the beneficiary customer. In principle, as an IBAN identifies the account servicing institution as well, the latter would no longer have to be specified explicitly in the appropriate field. However, the Payments Maintenance Working Group decided not to change the existing SWIFT message formatting rules. For routing purposes, they continue to recommend the identification of the account servicing institution with its BIC. If you quote the IBAN of the ordering customer, and the sender is not the financial institution of the ordering customer, the ordering customer's institution should be identified as well in Field 52a: Ordering Institution. No special indication will be used to distinguish IBANs from other account numbers. Any IBAN is recognizable by the receiver because it starts with an ISO country code, followed by a two-position numeric check digit. The IBAN standard specifies that the sender is responsible for the correct formatting and validation of the IBAN. In Field 59a: Beneficiary Customer of the MT 103+/MT 102+, for the European-validation countries SWIFT will mandate the presence of the IBAN, check the format and re-calculate the check digits of the IBAN. Common mistakes What are the most common mistakes found in the MT 103?

Misuse of Field 50a: Ordering Customer

Wrong structure of name and address of the ordering customer

Contains branch of ordering customer's bank Misuse of Field 59a: Beneficiary Customer
Missing IBAN Wrong IBAN Format

Wrong structure of name and address of the beneficiary customer Misuse of Field 70: Remittance Information
Incorrect use of code word /RFB/, Incorrect use of code word /INV/,

Misuse of Field 72: Sender to Receiver Information

Incorrect use of /REC/ Use of IBAN

Miscellaneous Can the MT 202 be used to cover an MT 103? Of course. The MT 103 caters for all the business scenarios that are covered by the MT 100. The MT 103 can be used within a serial transaction, that is, you send your MT 103 to the next party in the transaction chain, or within a covered transaction , that is, you send your MT 103 to the party closest to the beneficiary and cover the instruction via your correspondent by sending an MT 202. Mapping of information between an MT 103 and the cover MT 202 remains exactly the same as for the MT100. Below are the mapping rules between MT 103 and MT 202. Scenario 1 (MT 103 contains Field 53a: Sender's Correspondent only - sender and receiver share the same correspondent) MT 103 - Sender - Receiver - Field 20:Sender's Reference - Field 32A:Value Date, Currency, Interbank Settled Amount Field 53a:Sender's Correspondent - Scenario 2 (MT 103 contains Field 53a: Sender's Correspondent and Field 54a: Receiver's Correspondent - sender and receiver use a different correspondent) MT 103 - Sender - Receiver - Field 20:Sender's Reference - Field 21:Related Reference Field 58a:Beneficiary Institution Sender MT 202 Field 32A:Value date, Currency, Amount - Receiver Field 21:Related Reference Field 58a:Beneficiary Institution Sender MT 202

Field 32A:Value Date/Currency/Interbank Settled Amount Field 53a:Sender's Correspondent

Field 32A:Value date/Currency/ Amount - Receiver - Field 57a:Account with Institution

Field 54a:Receiver's Correspondent

- Scenario 3 (MT 103 contains Field 53a: Sender's Correspondent, Field 54a: Receiver's Correspondent and Field 55a: Third Reimbursement Institution - there are three reimbursement institutions between sender and receiver) MT 103 MT 202 - Sender Sender - Receiver 58a:Beneficiary Institution - Field 20: Sender's Reference Field 21:Related Reference - Field 32A:Value Date/Currency/Interbank Field 32A:Value date, Currency Code, Settled Amount Amount - Field 53a:Sender's Correspondent Receiver - Field 54a:Receiver's Correspondent Field 56a:Intermediary - 55a: Third Reimbursement Inst. 57a:Account with Institution -

Should I wait for the cover before executing the MT 103? In case of a cover payment, SWIFT would advise you to wait for a confirmation of the cover before paying the beneficiary customer. This is not a usage rule: it is the bank's final decision and responsibility to do so or not, depending on the relationship with the other banks in the transaction, the beneficiary customer and the amount to be paid.

What will happen to the MT 102? Since November 2001, both MT 103 and MT 102 are similar and can be handled by the same applications in the banks. Furthermore, SWIFT introduced an MT 102+ on the SWIFT network. The principles used to design the MT 102+ are exactly the same as for the MT 103+. The MT 102+ has been available since Standards Release 2001.