SWIFT报文格式手册
SWIFT_MT103_付款报文格式
SWIFT_MT103_付款报⽂格式MT 103MT 103 - ClearingLine Format SpecificationsMT 103 Customer TransferM = Mandatory O = OptionalStatus Tag Field Name Content/OptionsM 20 Sender's Reference 16 digitsM 23B Bank Operation Code CREDO 23E Instruction Code 4 digitsM 32A Value DateCurrencyInterbank Settled Amount 6 numeric3 alphabetical 15 digitsO 33B Currency/ InstructedAmount 3 alphabetical 15 digitsO 36 Exchange Rate 12 digitsM 50a Ordering Customer:Account numberCode / Identifier (Option F)Name & AddressOption F is preferredOption Option A[/34x] (Account)4!a2!a2!c[3!c] (BIC/BEI) Option K[/34x] (Account)4*35x (Name & Address) Option F35x (Party Identifier)4*35x (Name & Address)O 52A Ordering Institution A or DM 53B Sender's Correspondent /D/10 digitsyour account number O 56A Intermediary Institution A or CC = for Germany only O 57A Account With Institution A, B, C orD C = for Germany onlyStatus Tag Field Name Content/OptionsM 59A Beneficiary Customer:Account number Name and Adress /34 digits4 lines 35 digits eachO 70 Remittance Information 4 lines35 digits each M 71A Details of Charges OURSHABENO 71F Sender's Charges Example:71F EUR8,00 O 71G Receiver's Charges Example:71G EUR5,50O 72 Sender to ReceiverInformation Example:Line 1: /ACC/Branch 2 Lines 2-6: //............ slashes are set by thesystem1. Field 20: Your ReferenceThis field specifies the reference assigned by you to clearly identify the message.This field must not start or end with a slash '/' and must not contain two consecutive slashes '//'This reference will be quoted in any related confirmation or statement, e.g. MT 910 and / or 940, 942, 950.2. Field 23B: Bank Operation CodeThis field identifies the type of operation.Code:CRED – Standard Message3. Field 23E: Instruction CodeThis field specifies an instruction.Codes:Instructions must contain one of the following codes:SDVA Payment must be executed to the beneficiary with same day value.INTC The payment is an intra-company payment, i.e., a payment between two companies belonging to the same group. REPA Payment has a related e-Payments reference.CORT Payment is made in settlement of a trade, e.g., foreign exchange deal,securities transaction.HOLD Beneficiary customer/claimant will call; pay upon identification.CHQB Pay beneficiary customer only by cheque. The optional account number line in field 59 must not be used. PHOB Please advise/contact beneficiary/claimant by phone.TELB Please advise/contact beneficiary/claimant by the most efficient means of telecommunication.PHON Please advise account with institution by phone.TELE Please advise account with institution by the most efficient means oftelecommunication.PHOI Please advise the intermediary institution by phone.TELI Please advise the intermediary institution by the most efficient means of telecommunication.4. Field 32A: Value Date, Currency Code, AmountThis field specifies the value date, currency and amount to be transferred.5. Field 33B: Currency/Instructed Amount (If a conversion was made on your side)This amount is provided for information purposes and will be transported unchanged through the transaction chain.6. Field 36: Exchange RateThis field specifies the exchange rate used to convert the instructed amount specified in field 33B.This field must be present when a currency conversion has been performed on the Sender's side.7. Field 50a: Ordering CustomerThis field specifies the customer ordering the transaction.According to the Money Laundering Act, the complete name & address and account number (Option K), or other identification data (Option F) of the sender must be entered.Since October 29, 2007 the preferred option is FFormat field 50F:In option F the following line formats must be used:Line 1 (subfield Party /34x (Account Number)Identifier)Lines 2-5 (subfield 1!n/33x (Number)(Details)Name & Address)OrLine 1 (subfield Party 4!a/2!a/27x (Code)(Country Code)(Identifier)Identifier)Lines 2-5 (subfield 1!n/33x (Number)(Details)Name & Address)Codes:In option F, when subfield 1 Party Identifier is used with the (Code)(Country Code)(Identifier) format, one of the following codes must be used:ARNU Alien RegistrationNumber The code followed by a slash, '/' must be followed by the ISO country code, a slash, '/' and the Alien Registration NumberCCPT Passport Number The code followed by a slash, '/' must be followed by the ISO countrycode, a slash, '/' and the Passport Number.CUST CustomerIdentificationNumber The code followed by a slash, '/' must be followed by the ISO country code of the issuer of the number, a slash, '/', the issuer of the number, a slash, '/' and the Customer Identification Number.DRLC Driver's LicenseNumber The code followed by a slash, '/' must be followed by the ISO country code of the issuing authority, a slash, '/', the issuing authority, a slash, '/' and the Driver's License Number.EMPL Employer Number The code followed by a slash, '/' must be followed by the ISO countrycode of the registration authority, a slash, '/', the registration authority,a slash, '/' and the Employer Number.NIDN National IdentityNumber The code followed by a slash, '/' must be followed by the ISO country code, a slash, '/' and the National Identity Number.SOSE Social SecurityNumber The code followed by a slash, '/' must be followed by the ISO country code, a slash, '/' and the Social Security Number.TXID Tax IdentificationNumber The code followed by a slash, '/' must be followed by the ISO country code, a slash, '/' and the Tax Identification Number.In option F, each line of subfield 2 Name & Address when present must start with one of the following numbers:1 Name of theorderingcustomer The number followed by a slash, '/' must be followed by the name of the ordering customer (where it is recommended that the surname precedes given name(s)).2 Address Line The number followed by a slash, '/' must be followed by an Address Line(Address Line can be used to provide for example, street name and number,or building name).3 Country andTown The number followed by a slash, '/' must be followed by the ISO country code, a slash '/' and Town (Town can be complemented by postal code (for example zip), country subdivision (for example state, province, or county).4 Date of Birth The number followed by a slash, '/' must be followed by the Date of Birth in theYYYYMMDD format.5 Place of Birth The number followed by a slash, '/' must be followed by the ISO country code,a slash '/' and the Place of Birth.6 CustomerIdentificationNumber The number followed by a slash, '/' must be followed by the ISO country code of the issuer of the number, a slash, '/', the issuer of the number, a slash, '/' and the Customer Identification Number.7 National IdentityNumber The number followed by a slash, '/' must be followed by the ISO country code, a slash, '/' and the National IdentityNumber.8 AdditionalInformation The number followed by a slash, '/' is followed by information completing one of the following:the Identifier provided in subfield 1 (Party Identifier) used with the (Code)(Country Code)(Identifier) format.the Customer Identification Number provided in subfield 2 (Name & Address) with number 6.the National Identity Number provided in subfield 2 (Name & Address) with number 7.NETWORK VALIDATED RULESIdentifier Code must be a registered BIC or BEI.In option F, subfield 1 (Party Identifier) used with the (Code)(Country Code)(Identifier) format: Country Code must be a valid ISO country code.In option F, subfield 2 (Name & Address):The first line must start with number 1.Numbers must appear in numerical order.Number 2 must not be used without number 3.Number 4 must not be used without number 5 and vice versa.Number 4 must be followed by a valid date in the format YYYYMMDD and this date, local to the sender, must not be later than the date on which the message is successfully sent to SWIFT.Numbers 3, 5, 6 and 7 must be followed by a valid ISO country code, a slash '/' and additional Details.Numbers 3, 4, 5, 6, 7 and 8 must not be repeated.The use of number 8 is only allowed in the following instances:o to continue information on the Identifier of the ordering customer provided in subfield 1 (Party Identifier) used with the (Code)(Country Code)(Identifier) format.o to continue information on the Customer Identification Number provided in subfield 2 (Name & Address) following number 6.o to continue information on the National Identity Number provided in subfield 2 (Name & Address) following number 7. USAGE RULESIf the account number of the ordering customer is present, it must be stated in Account.In option F, subfield 2 (Name & Address): Numbers 1 and 2 may be repeated.In option F, subfield 1 (Party Identifier) used with the (Code)(Country Code)(Identifier) format: if additional space is required for providing the Identifier of the ordering customer, one of the following options must be used:1. First option (preferred): Identify the ordering customer with a different identifier wherethe length is not an issue.2. Second option: Continue the information in subfield 2 (Name & Address) usingnumber 8.In option F, subfield 2 (Name & Address): if additional space is required for providing the Customer Identification Number (number 6) or the National Identity Number (number 7) ofthe ordering customer, one of the following options must be used:1. First option (preferred): Identify the ordering customer with a different identifier wherethe length is not an issue.2. Second option: Continue the information in subfield 2 (Name & Address) usingnumber 8.ExamplesOption F - Example 1:50F:/123456781/SMITH JOHN2/299, PARK AVENUE3/US/NEW YORK, NY 10017Option F - Example 2:50F:/BE300012163714111/PHILIPS MARK4/197208305/BE/BRUSSELSOption F - Example 3:50F:DRLC/BE/BRUSSELS/NB09490421/DUPONT JACQUES2/HIGH STREET 6, APT 6C3/BE/BRUSSELSOption F - Example 4:50F:NIDN/DE/1212312343421/MANN GEORG6/DE/ABC BANK/1234578293Option F - Example 5:50F:CUST/DE/ABC BANK/123456789/8-1234561/MANN GEORG2/LOW STREET 73/DE/FRANKFURT8/7890This means that the customer identification number of Mann Georg assigned by ABC Bank is 123456789/8-1234567890. References: SWIFTStandards 8. Field 52a: Ordering InstitutionThis field specifies the ordering institution if other than your Bank.The BIC must be a SWIFT registered address.Option A is the preferred option.Option D should only be used if the ordering financial institution has no BIC.9. Field 53B: Sender's CorrespondentThis field specifies the account to which the payment has to be debited.10. Field 56a: Intermediary InstitutionThis field identifies the correspondent bank of the account with institution if other than VTB Bank.The BIC must be a SWIFT registered address.Option A must be used whenever possible.Option C Party Identifier may be used to indicate a national clearing system code,Important: Option C with clearing code other than DE will be forwarded withoutChecking11. Field 57a: Account with InstitutionThis field identifies the financial institution, if other than VTB Bank, which will pay or credit the beneficiary institution.The BIC must be a SWIFT registered address.Option A must be used whenever possible.Option D must only be used in exceptional circumstances, e.g., if the party cannot be identified by a BIC.Option C Party Identifier may be used to indicate a national clearing system code.Option C with clearing code other than DE will be forwarded withoutchecking.12. Field 59a: Beneficiary CustomerThis field specifies the customer who will be paid.At least the account number, name, full address or the BEI (Business Entity Identifier) of the beneficiary customer is mandatory.13. Field 70: Remittance InformationThis field specifies either the details of the individual transaction or a reference to another message containing the details which are to be transmitted to the beneficiary customer.The information specified in this field is intended only for the beneficiary customer.We do not read its content.14. Field 71A: Details of ChargesThis field specifies which party will bear the charges for the transaction.One of the following codes must be used:BEN/SHA All transaction charges are to be borne by the beneficiary customer.SHA or OUR and /SPLIT/ In Field 72 causes charges will be debited to your account, all the other to the beneficiary‘s account.OUR All transaction charges are to be borne by the ordering customer.15. Field 71F: Sender's ChargesThis repetitive field specifies the currency and amount of the transaction charges deducted by you and by previous banks in the transaction chain.These fields are conveyed for transparency reasons.The net amount after deduction of the Sender's charges will be quoted as the inter-bank settled amount in field 32A. 16. Field 72: Sender to Receiver InformationThis field specifies additional information for the Receiver of the payment order or another party identified in the field. Codes:Please be informed that the usage of this codes (except ‘INS’) will cause Third Bank / REPAIR Charges.ACC Instructions following are for the account with institution.INS The institution which instructed the Sender to execute the transaction.INT Instructions following are for the intermediary institution.REC Instructions following are for the Receiver of the message.Field 72 must in no case be used for information for which another field is intended.Codes must be placed between slashes and at the beginning of a line. Additional explanatory information, which may be continued in the next lines, is preceded by a double slash '//'.16A. Field 72: Special OWHBDEFF Code/SPLIT/ + Field 71A = SHA or OUR = Charges of ordering customer institution to bepaid by ordering customer, all other charges to be paid by beneficiary.No REPAIR Charges will apply.。
SWIFT报文格式手册
2006年度SWIFT报文格式更新手册（2006/11/18起生效）S W I F T M T 7 0 0 / 7 0 1I S S U E O F A D / C开立跟单信用证MT700/701 范围1. 由开证行发送给通知行的报文（注意：收、发报行间必须具有BKE密押关系）；2. 用来列明开证行发报行所开立的信用证条款。
MT700格式（M = Mandatory O = Optional）O44A Loading on Board/Dispatch/Taking in1*65xCharge at / fromO44B For Transportation to...1*65xO44C Latest Date of Shipment6!nO44D Shipment Period6*65xO45A Description of Goods and/or Services100*65xO46A Documents Required100*65xO47A Additional Conditions100*65xO71B Charges6*35xO48Period for Presentation4*35xM49Confirmation Instructions7!xO53a Reimbursing Bank A or D12*65xO78Instructions to the Paying/Accepting/NegotiatingBankO57a"Advise Through" Bank A, B or DO72Sender to Receiver Information6*35xMT701格式（M = Mandatory O = Optional）Status Tag Field Name Content/OptionsM27Sequence of Total1!n/1!nM20Documentary Credit Number16xO45B Description of Goods and/or Services100*65xO46B Documents Required100*65xO47B Additional Conditions100*65xMT700/701 准则除非另外列明，所开立的跟单信用证遵循巴黎国际商会制定的《跟单信用证统一惯例》。
SWIFT报文的结构与报文类型
. . . .. .SWIFT 标准资料（十五）2003年11月实施版SWIFT 标准报文的结构与报文类型2003年11月发布标准2003年标准发布指南－最终版本－2003年2月全国金融标准化技术委员会秘书处对外经济贸易大学金融科技中心2003-08-06SWIFT标准报文SWIFT标准报文（金融服务报文）SWIFT开发的商业标准报文已经成功应用在金融服务领域，而且根据市场的需要在不断发展中。
2003版SWIFT标准扩大了应用范围，规范了具体形式，同时采用了先进的技术成果、可以满足金融服务的需要，包括批量支付、投资基金、证券、信托等方面。
SWIFT标准的下一个版本将在2005年5月发布。
下面表示的是SWIFT标准2003版的发布过程：从2002年8月开始到2003年11月正式实施。
Standards Release 2003Schedule for Standards Release 2003For the Standards Release 2003, the development andimplementation schedule is as follows:16 August 2002 High-Level Information on Standards Release 200315 November 2002 Preliminary Standards Release Guide 2003 Preliminary Message Format Validation Rules 200314 February 2003 Final Standards Release Guide 2003 Final Message Format Validation Rules 200329 March 2003 Vendor Test System12 July 2003 Testing & Training SystemIf necessary, updates to Message Format Validation Rules 200312 September 2003 UHB shipment15 November 2003 Standards Release 2003 Live第一章报文结构和报文类型1.1 SWIFT报文结构所有金融报文必须符合SWIFT标准卷描述的某种报文类型的规则。
(完整版)SWIFT报文定义
SWIFT格式及含义一份SWIFT电文，由报头(Header Block)、正文(Text Block)、报尾(Trailer Block)组成，还会标明发报银行（类似于Correspondents BIC/TID或Sender），和收报银行（Receiver）等。
信用证中开头、结尾的古怪条款就是报头报尾，中间带条款编号（31C、46A之类的）才是正文。
A.外国银行发送MT700/701电文给国内银行，开立信用证。
B.国内银行通知我们，并发送MT730电文给外国银行，确认收妥信用证。
C.如果要修改信用证，根据外商申请，外国银行发送MT707电文给国内银行，告知修改内容。
D.我们出货交单，如果国内银行议付，则发MT754 电文给开证行，并另外快递寄单。
E.开证行收到单证审核无误，发MT732电文给国内银行表示接受。
F.如果有不符点，开证行发MT734给国内银行，拒付。
G.有不符点，国内银行可以发MT750 给开证行，“电提”。
开证行接受的，回复MT752授权议付。
H.国内银行议付的，回过头发送MT742向开证行收钱。
2.电文格式分类: SWIFT电文根据银行的实际运作共划分为十大类:第一类:客户汇款与支票,如:MT101,MT103,MT110等;第二类:银行寸头调拨,如:MT200,MT201等;第三类:外汇买卖,货币市场及衍生工具,如:MT300,MT305;第四类:托收,如:MT400,MT410,MT412等;第五类:证券业务.第六类:银团贷款和贵重金属业务.第七类:跟单信用证和保函,如:MT700/701,MT705等第八类:旅行支票.第九类;银行和客户帐务,如:MT900,MT910等;第0类:SWIFT 系统电报.Swift MT707 信用证修改信用证项下的一种SWIFT格式, 例如所有的信用证都用MT700开出。
Swift MT760（信汇760） Swift MT760 是一种银行对银行的发出的信息，用于为保证乙方在乙银行的利益，由甲银行向乙银行开出的或者被申请开出的银行保函。
swift iso20022 报文标准
swift iso20022 报文标准一、概述SwiftISO20022报文标准是国际银行间通信和交易的重要标准之一，用于规范银行间交易的报文格式和内容。
该标准旨在确保不同金融机构之间的交易信息能够准确、一致地传输和交换。
二、报文结构ISO20022报文主要由报文头、报文体和报文尾三部分组成。
1.报文头：包括报文的标识信息、发送方和接收方的信息、报文的版本号、时间戳等信息。
2.报文体：是实际交易信息的部分，包括交易类型、交易金额、交易币种、交易对手方信息、结算方式等信息。
3.报文尾：包括校验码等信息，用于确保报文的正确性和完整性。
报文结构遵循一定的编码规则和数据类型，以确保不同金融机构之间的互操作性。
三、应用场景ISO20022报文标准广泛应用于国际银行间市场，包括债券、外汇、商品、衍生品等市场的交易。
金融机构之间通过交换ISO20022报文，可以实现快速、高效、准确的交易结算和清算。
四、优势与不足ISO20022报文标准具有以下优势：1.标准化：规范了报文格式和内容，确保不同金融机构之间的互操作性。
2.高效性：简化了交易信息的传输和处理，提高了交易效率。
3.安全性：通过加密和签名等技术，确保交易信息的机密性和完整性。
然而，ISO20022报文标准也存在一些不足：1.复杂性：相对于其他通信标准，ISO20022报文标准的实现较为复杂，需要专业的技术人员进行开发和维护。
2.成本：实施ISO20022报文标准需要投入一定的成本，包括开发成本、测试成本和培训成本等。
五、未来发展随着金融市场的不断发展，ISO20022报文标准仍有很大的发展空间：1.扩展性：未来可以考虑增加更多的交易类型和业务场景，以满足市场的不断变化和需求。
2.标准化接口：可以制定统一的接口规范，方便不同系统之间的集成和互操作。
3.简化开发过程：可以通过引入新的技术和工具，降低ISO20022报文标准的开发难度，提高开发效率。
总之，SwiftISO20022报文标准作为国际银行间通信的重要标准，在未来的发展中仍有很大的潜力和价值。
(完整版)SWIFT报文定义.doc
SWIFT格式及含义一份SWIFT电文，由报头(Header Block)、正文(Text Block)、报尾(Trailer Block)组成，还会标明发报银行（类似于Correspondents BIC/TID 或 Sender），和收报银行（ Receiver）等。
信用证中开头、结尾的古怪条款就是报头报尾，中间带条款编号（31C、 46A 之类的）才是正文。
A.外国银行发送 MT700/701 电文给国内银行，开立信用证。
B.国内银行通知我们，并发送MT730 电文给外国银行，确认收妥信用证。
C.如果要修改信用证，根据外商申请，外国银行发送MT707 电文给国内银行，告知修改内容。
D.我们出货交单，如果国内银行议付，则发MT754 电文给开证行，并另外快递寄单。
E.开证行收到单证审核无误，发MT732 电文给国内银行表示接受。
F.如果有不符点，开证行发MT734 给国内银行，拒付。
G.有不符点，国内银行可以发MT750 给开证行，“电提”。
开证行接受的，回复 MT752 授权议付。
H.国内银行议付的，回过头发送MT742 向开证行收钱。
2.电文格式分类 : SWIFT电文根据银行的实际运作共划分为十大类:第一类 :客户汇款与支票,如 :MT101,MT103,MT110 等 ;第二类 :银行寸头调拨,如 :MT200,MT201 等;第三类 :外汇买卖 ,货币市场及衍生工具,如:MT300,MT305;第四类 :托收 ,如 :MT400,MT410,MT412 等;第五类 :证券业务 .第六类 :银团贷款和贵重金属业务.第七类 :跟单信用证和保函,如 :MT700/701,MT705 等第八类 :旅行支票 .第九类 ;银行和客户帐务,如 :MT900,MT910 等 ;第0 类 :SWIFT 系统电报 .Swift MT707 信用证修改信用证项下的一种SWIFT格式 , 例如所有的信用证都用MT700 开出。
SWIFT报文定义
SWIFT格式及含义一份SWIFT电文，由报头(Header Block)、正文(Text Block)、报尾(Trailer Block)组成，还会标明发报银行（类似于Correspondents BIC/TID或Sender），和收报银行（Receiver）等。
信用证中开头、结尾的古怪条款就是报头报尾，中间带条款编号（31C、46A之类的）才是正文。
A.外国银行发送MT700/701电文给国内银行，开立信用证。
B.国内银行通知我们，并发送MT730电文给外国银行，确认收妥信用证。
C.如果要修改信用证，根据外商申请，外国银行发送MT707电文给国内银行，告知修改内容。
D.我们出货交单，如果国内银行议付，则发MT754电文给开证行，并另外快递寄单。
E.开证行收到单证审核无误，发MT732电文给国内银行表示接受。
F.如果有不符点，开证行发MT734给国内银行，拒付。
G.有不符点，国内银行可以发MT750给开证行，“电提”。
开证行接受的，回复MT752授权议付。
H.国内银行议付的，回过头发送MT742向开证行收钱。
2.电文格式分类:SWIFT电文根据银行的实际运作共划分为十大类:第一类:客户汇款与支票,如:MT101,MT103,MT110等;第二类:银行寸头调拨,如:MT200,MT201等;第三类:外汇买卖,货币市场及衍生工具,如: MT300,MT305;第四类:托收,如:MT400,MT410,MT412等;第五类:证券业务.第六类:银团贷款和贵重金属业务.第七类:跟单信用证和保函,如:MT700/701,MT705等第八类:旅行支票.第九类;银行和客户帐务,如:MT900,MT910等;第0类:SWIFT系统电报.Swift MT707信用证修改信用证项下的一种SWIFT格式,例如所有的信用证都用MT700开出。
Swift MT760（信汇760）Swift MT760是一种银行对银行的发出的信息，用于为保证乙方在乙银行的利益，由甲银行向乙银行开出的或者被申请开出的银行保函。
国际结算SWIFT报文模板
英文函电 一、印鉴密押业务1、国外电开证漏押、国外电开证漏押Re: YOUR L/C NO. FOR DATEDOUR REF.WE ARE IN RECEIPT OF YOUR ABOVE L/C AND HA VE NOTED THAT THE MESSAGE IS NOT TESTED. FOR THE SAKE OF PRECAUTION. PLS AUTHENTICATE IT TO US BY TESTED SWIFT URGENTLY .关于：你信用证号 金额 日期日期我行编号我行编号我行已收到贵行上述电开信用并注意到该电文无押，为防范起见，请立即用加押电证实。
立即用加押电证实。
2、国外电修改漏押、国外电修改漏押RE: AMENDMENT NO. XX TO YOUR L/C NO. FOR DATED OUR REF. WE ACKNOWLEDGE RECEIPT OF YOUR AMENDMENT NO.XXX TO THE ABOVE L/C, AND HA VE NOTED THAT THE MESSAGE IS NOT TESTED. FOR THE SAKE OF ORDER, PLS AUTHENTICATE IT TO US BY TESTED SWIFT.关于：你行XXX 号信用证金额为XX 项下的第XX 次修改次修改 我行编号我行编号我行已收到贵行上述信用证项下的第XX 次修改，并注意到该电文无押，为安全起见，请用加押电证实。
押，为安全起见，请用加押电证实。
＊3、密押不符查询、密押不符查询RE: YOUR REF. FOR DATEDOUR REFWE HA VE RECEIVED THE ABOVE MESSAGE AND FIND THE TEST NO.XX INCORRECT. PLS CHECK YOUR RECORDS AND REPLY ASAP. 关于你行编号 金额 日期日期我行编号我行编号我行已收到上述电文并发现押号有误，请贵行查核档案，并尽快答复。
swift报文标准实用手册
swift报文标准实用手册Swift报文标准实用手册（第二版）
目录：
第一章Swift报文标准概述
1.1 Swift组织与报文标准
1.2 报文标准的发展历程
1.3 Swift报文的组成结构
1.4 Swift报文的特点与优势
第二章Swift报文格式规范
2.1 报文格式概述
2.2 报文段说明
2.3 报文段格式规范
2.4 报文段格式示例
第三章Swift报文业务处理规范
3.1 报文业务处理概述
3.2 报文发送规范
3.3 报文接收规范
3.4 报文确认与反馈规范
第四章Swift报文标准实现技术
4.1 实现技术概述
4.2 Java实现技术
4.3 C#实现技术
4.4 Python实现技术
4.5 Swift报文标准接口规范
第五章Swift报文标准应用案例
5.1 报文标准在银行跨境支付中的应用5.2 报文标准在证券交易中的应用
5.3 报文标准在供应链金融中的应用
5.4 报文标准在电子发票中的应用
5.5 其他应用案例
第六章Swift报文标准未来发展展望
6.1 Swift组织的发展趋势与影响
6.2 Swift报文标准的未来发展动向与挑战6.3 Swift报文标准的未来发展机遇与前景。
SWIFT报文的结构与报文类型
SWIFT报文的结构与报文类型SWIFT报文的结构是由一系列的字段（field）组成，每个字段都有一个固定的长度和特定的含义。
这些字段按照特定的顺序排列，形成了SWIFT报文的整体结构。
SWIFT报文的结构可以分为表头（header）、数据区（body）和尾部（trailer）三个部分。
表头包含了与报文发送和接收有关的信息，如发送方和接收方的BIC （Bank Identifier Code）等。
数据区是报文的核心部分，包含了具体的交易信息，如汇款金额、收款方账号、付款方账号等。
尾部是对整个报文的校验和验证信息，以确保报文的完整性和正确性。
1. MT 1xx：财务电汇串单（Financial Institution Transfers）。
-MT101：客户向银行发出的单笔汇款指令。
-MT103：集群汇款、外汇汇款或协调汇款等的汇款指令。
-MT104：汇给银行的汇款指令。
-MT105：调帐条款通知，用于报告对MT103或MT202报文所做的更正。
2. MT 2xx：协议、注册参与方和市场电汇串单（Financial Institution Transfers）。
-MT202：银行间汇款代理银行的汇款指令。
-MT204：贷款调整的支付指令。
-MT205：贷款承诺/不承诺的通知。
3. MT 3xx：市场交付及确认类报文（Market Practice Trade Capture Reports）。
-MT300：外汇远期/外汇期货合同的零售外汇部分的执行/不执行通知。
-MT302：外汇远期/期货合同（非常关键）的票面交付。
-MT304：非常关键外汇远期/期货合同（非货币兑换关键项目）的票面交付。
-MT306：托管报告的票面交付。
4. MT 9xx：大额支付系统报文（System Messages）。
-MT940：平衡及其他汇总报告。
-MT950：账户状态变更通知。
-MT999：发送方格式错误的报文。
这些报文类型覆盖了银行间和金融机构在电子化交易中常见的需求情景。
(完整版)SWIFT报文格式手册
2006年度SWIFT报文格式更新手册（2006/11/18起生效）S W I F T M T 7 0 0 / 7 0 1I S S U E O F A D / C开立跟单信用证MT700/701 范围1. 由开证行发送给通知行的报文（注意：收、发报行间必须具有BKE密押关系）；2. 用来列明开证行发报行所开立的信用证条款。
MT700/701 准则◆ 除非另外列明，所开立的跟单信用证遵循巴黎国际商会制定的《跟单信用证统一惯例》。
当该信用证遵循此惯例时，通知行（收报行）必须将之通知受益人或是另一家通知行。
◆ 除非另外列明，如果适用，跟单信用证项下的偿付遵循巴黎国际商会制定的《跟单信用证项下银行间偿付的统一规则》。
◆ 当跟单信用证的长度超过一个MT700的容量时，可以用一个或几个（最多三个）MT701报文格式来补充传送信息。
◆ 除非另外列明，根据该报文通知受益人或是另一家通知行的跟单信用证是已生效的信用证。
◆ 对自由议付跟单信用证，如果收报行不再以MT710报文格式转通知，那么该银行必须在信用证上加注：✧ 每次议付时必须提交通知受益人的信用证正本✧ 议付行必须在所通知的信用证正本上标注每一次的议付情况◆ 为了避免可能产生的误解，尽可能使用银行的SWIFT BIC代码来表示银行名称，而不要用“ourselves”、“yourselves”、“us”、“you”这些词。
◆ 通知行应该明确清楚地将跟单信用证的全部内容（包括任何细节）通知受益人。
MT700/701 域使用规则1. 报文中可以出现域39A或39B，但不能同时出现；2. 域42C和42a在被使用时必须同时出现；3. 在使用时，域42C和42a同时出现；或是42M 单独出现；或是42P单独出现，除此之外没有其它组合形式；4. 报文中可以出现域44C或44D，但不能同时出现；5. 用MT700开立的跟单信用证长度不超过10000个字符（包括报头和报尾）。
SWIFT报文结构与报文类型
SWIFT报文结构与报文类型1. Service Identifier：服务标识符，用于标识报文类型的内容，由3位数字组成。
2. Logical Terminal Identifier：逻辑终端标识符，用于标识发送和接收报文的SWIFT终端，通常是一个8或11位的代码。
3. Session Number：会话编号，用于标识报文在会话中的顺序。
4. Sequence Number：序列编号，用于标识报文在特定会话中的唯一性。
5. Message Priority：报文优先级，用于指定报文的处理优先级，分为高、中和低三个级别。
6. Message Type：报文类型，用于标识报文的具体类别，由3位数字组成。
7. Message Input Reference：报文输入参考，用于标识报文的唯一性，并用于连接相关的报文。
8. Receiver's Address：接收方地址，指定报文应该发送到的最终接收方。
9. Message Text：报文正文，包含具体的金融业务信息，如付款指令、汇款通知等。
10. Message Trailer：报文尾部，包含报文的校验和和结束标志，用于确保报文的完整性。
1.MT100：付款指令报文，用于发送银行之间的付款指示。
2.MT101：单笔付款报文，用于发送单笔的国内或国际付款指示。
3.MT102：批量付款报文，用于发送批量的国内或国际付款指示。
4.MT103：即时汇款报文，用于发送即时的国际汇款指示。
5.MT202：银行间头寸报文，用于发送银行之间的头寸调整指示。
6.MT300：外汇远期/即期报文，用于发送外汇远期和即期交易指示。
7.MT320：租赁/租用报文，用于发送租赁和租用交易指示。
8.MT540：保证书/协议报文，用于发送关于保证书和协议的通知。
9.MT541：保证证明报文，用于发送与保证证明相关的通知。
10.MT700：即期信用证报文，用于发送即期信用证开具指示。
SWIFT报文定义
SWIFT格式及含义一份SWIFT电文，由报头(Header Block)、正文(Text Block)、报尾(Trailer Block)组成，还会标明发报银行〔类似于Correspondents BIC/TID或Sender〕，和收报银行〔Receiver〕等。
信用证中开头、结尾的乖僻条款就是报头报尾，中间带条款编号〔31C、46A之类的〕才是正文。
A.外国银行发送MT700/701电文给国内银行，开立信用证。
B.国内银行通知我们，并发送MT730电文给外国银行，确认收妥信用证。
C.如果要修改信用证，根据外商申请，外国银行发送MT707电文给国内银行，告知修改内容。
D.我们出货交单，如果国内银行议付，那么发MT754 电文给开证行，并另外快递寄单。
E.开证行收到单证审核无误，发MT732电文给国内银行表示接受。
F.如果有不符点，开证行发MT734给国内银行，拒付。
G.有不符点，国内银行可以发MT750 给开证行，“电提〞。
开证行接受的，回复MT752授权议付。
H.国内银行议付的，回过头发送MT742向开证行收钱。
2.电文格式分类: SWIFT电文根据银行的实际运作共划分为十大类:第一类:客户汇款与支票,如:MT101,MT103,MT110等;第二类:银行寸头调拨,如:MT200,MT201等;第三类:外汇买卖,货币市场及衍生工具,如:MT300,MT305;第四类:托收,如:MT400,MT410,MT412等;第五类:证券业务.第六类:银团贷款和贵重金属业务.第七类:跟单信用证和保函,如:MT700/701,MT705等第八类:旅行支票.第九类;银行和客户帐务,如:MT900,MT910等;第0类:SWIFT 系统电报.Swift MT707 信用证修改信用证项下的一种SWIFT格式, 例如所有的信用证都用MT700开出。
Swift MT760〔信汇760〕 Swift MT760 是一种银行对银行的发出的信息，用于为保证乙方在乙银行的利益，由甲银行向乙银行开出的或者被申请开出的银行保函。
SWIFT信用证报文详解
SWIFT 信用证及其基本内容国际上各银行开具的信用证没有统一的格式，但无论是以什么方式开具的信用证，其遵循的基本原则和基本内容都是一致的。
在出现了SWIFT组织以后，信用证的形式和条款逐渐规范，并在实际业务中为大多数国家的银行所遵循。
Swift共有十类特点格式化和规范化第一类客户汇款与支票第二类银行头寸调拨第三类外汇买卖和存放款第四类托收第五类证券第六类贵金属与辛迪加第七类跟单信用证和保函第八类旅行支票第九类银行帐务第十类SWIFT系统电报SWIFT电讯的表示方法1、各国货币的表示方法美元USD 人民币CNY 日元JPY 英镑GBP2、数字的表示方法数字不使用分格号，小数点用逗号表示5，152，286.36 表示为5152286，364/5 0，8 5%表示为5 PERCENT日期的表示方法YYMMDD 2007年10月15日表示为071015第七类重点介绍MT700/701 MT707MT700/701开立信用证格式最长不能超过2000个字符，假如超过2000，我们将其分为若干部分，使用一个MT700以及若干个MT701MT700 02 02表示电讯等级代码(普通级)27, 40A , 20 ,31D,50,32B,41M,49为必选项目(MANDA TORY) 其余为选用项目(OPTIONAL) SWIFT信用证是指凡通过SWIFT系统开立或予以通知的信用证。
在国际贸易结算中，SWIFT 信用证是正式的、合法的，被信用证各当事人所接受的、国际通用的信用证。
采用SWIFT 信用证必须遵循SWIFT的规定，也必须使用SWIFT手册规定的代号（TAG），而且信用证必须遵循国际商会1993年修订的《跟单信用证统一惯例》各项条款的规定。
在SWIFT信用证中可省去开证行的承诺条款，但不因此免除银行所应承担的义务。
SWIFT信用证的特点是快速、准确、简明、可靠。
SWIFT报文（TEXT）由一些项目（FIELD）组成，每一种报文格式（MESSAGE TYPE，MT）规定了由那些项目组成，每一个项目又严格规定了由多少字母、多少数字或多少字符组成。
SWIFT报文格式手册
2006年度SWIFT报文格式更新手册（2006/11/18起生效）S W I F T M T 7 0 0 / 7 0 1I S S U E O F A D / C开立跟单信用证MT700/701 范围1. 由开证行发送给通知行的报文（注意：收、发报行间必须具有BKE密押关系）；2. 用来列明开证行发报行所开立的信用证条款。
MT700/701 准则◆ 除非另外列明，所开立的跟单信用证遵循巴黎国际商会制定的《跟单信用证统一惯例》。
当该信用证遵循此惯例时，通知行（收报行）必须将之通知受益人或是另一家通知行。
◆ 除非另外列明，如果适用，跟单信用证项下的偿付遵循巴黎国际商会制定的《跟单信用证项下银行间偿付的统一规则》。
◆ 当跟单信用证的长度超过一个MT700的容量时，可以用一个或几个（最多三个）MT701报文格式来补充传送信息。
◆ 除非另外列明，根据该报文通知受益人或是另一家通知行的跟单信用证是已生效的信用证。
◆ 对自由议付跟单信用证，如果收报行不再以MT710报文格式转通知，那么该银行必须在信用证上加注：✧ 每次议付时必须提交通知受益人的信用证正本✧ 议付行必须在所通知的信用证正本上标注每一次的议付情况◆ 为了避免可能产生的误解，尽可能使用银行的SWIFT BIC代码来表示银行名称，而不要用“ourselves”、“yourselves”、“us”、“you”这些词。
◆ 通知行应该明确清楚地将跟单信用证的全部内容（包括任何细节）通知受益人。
MT700/701 域使用规则1. 报文中可以出现域39A或39B，但不能同时出现；2. 域42C和42a在被使用时必须同时出现；3. 在使用时，域42C和42a同时出现；或是42M 单独出现；或是42P单独出现，除此之外没有其它组合形式；4. 报文中可以出现域44C或44D，但不能同时出现；5. 用MT700开立的跟单信用证长度不超过10000个字符（包括报头和报尾）。
国际汇款报文格式
国际汇款报文格式MT103报文用于个人客户之间的资金划转。
SWIFT标准报文格式手册对于一笔MT103支付报文的格式要求用一张简单表格整理如下：其中，我们看到一些必输栏位和选输栏位。
这意味着，当一笔支付报文的20、23B、32A、50a、59a和71A这些必输的基本栏位已经填妥时，这笔报文就能够通过SWIFT ALLIANCE 系统顺利到达收报行。
我们收到的报文回执就是ACK。
为实现这个ACK，我们第一步需要遵循对于各个栏位制定的规则从而将这些必输栏位填写正确。
其次，更常见情况往往是，仅仅这些基本栏位无法满足我们发出一笔支付报文时想要传达的所有信息。
此时，我们就要用到选填项。
不能小瞧了这些选填栏位，他们对于报文能够走通、能否直通、是否会间接引起退汇等等同样起到了至关重要的作用。
因此，接下来我就最为常用的栏位规则做逐一分析。
20：发报行编号。
必输项。
由发报行自行编写，用以关联支付报文。
第一个和最后一个编码不能用“/”符号占位，中间不能包含“//”。
20栏编号在银行往来报文，例如MT910、MT950或者MT199等报文中，通常在21栏被予以引用。
当该报文以COVER 形式发出MT202 COV报文时，同样在MT202 COV报文的21栏位被引用。
23B：银行运营代码。
最常用的是CRED。
32A：起息日/币种/结算金额。
必输项。
起息日格式为年-月-日。
33B：表示指示金额，即汇款人汇出汇款金额。
通常为非必输项，但是当汇款行在汇出汇款时因汇款币种改变而产生汇率调整时，33B就是必输项。
一旦发报行在发出的报文中显示了33B信息，中间行在转报时需将该信息不做更改传递下去。
没有发生购售汇的情况下，当汇款行、中间行及收款行没有扣减费用时，33B显示金额应等于32A 显示金额；显然当银行扣收费用时，33B显示金额大于32A显示金额。
收款行及收款人可以通过两个金额之间的差额获知银行费用明细。
50a：汇款人信息。
是必填项。
SWIFT-格式说明
KIKI(L.Y.)
41A: Available with.....by.... 指定的有关银行及信用证兑付方式
41D: Available with any bank by Negotiation 自由议付信用证 （41A 和41D .)
KIKI(L.Y.)
71B: Charges 费用负担 48：Period for Presentation 交单期限 49：Confirmation Instructions 保兑指示
KIKI(L.Y.)
53A/D：Reimbursement Bank 偿付行 78:Instruction to the Paying/Accepting/Negotiating Bank 给付行，承兑行或议付行的指示
KIKI(L.Y.)
在 SWIFT 电 文 中 ， 一 些 项 目 是 必 选 项 目 (MANDATORY FIELD) ， 一 些 项 目 是 可 选 项 目 (OPTIONAL FIELD)，必选项目是必须要具备的。 日 期 表 示 方 式 SWIFT 电 文 的 日 期 表 示 为 ： YYMMDD(年月日)如：2007年5月12日，表示为： 070512 ； 2008 年 3 月 15 日 ，表示 为： 080315 ； 2009年12月9日，表示为：091209。 数字表示方式在SWIFT电文中，数字不使用分格号 ，小数点用逗号“，”来表示如：5，152，286.36 表示为：5152286，36； 4/5 表示为：0，8； 5% 表示为：5 PERCENT
KIKI(L.Y.)
开立信用证用的是SWIFT电文的MT700格式。这种格式把信用证 的内容归类成条款，并给与固定编号。比如信用证开给谁（受益 人），条款名称就是“BENEFICIARY”，条款编号是59；信用证 规 定 需 要 哪 些 外 贸 单 证 ， 条 款 名 称 就 是 “ DOCUMENTS REQUIRED”，编号46A。这样固定编号，银行和我们审阅信用证 就方便多了。SWIFT的MT格式规定得非常严格，比如关于信用证 中关于开证申请人的名址条款（条款代码号50），填表的时候就 限定为4行，每行35个字符。如果这个条款实际内容太多，超出了 限制字数，就用另一套电文格式MT701来补充。因此，用于开立 信用证的SWIFT电文实际上有两个格式，MT700和备用的MT701。 这就是我们常常在信用证的开头部分见到的条款“ Sequence of Total : 27 : 1/1”的由来。如果此份信用证完全根据一份MT700电 文来开立，27条款就是1/1，如果是两份以上的电文（一份MT700, 其它的是补充的MT701），此条款就相应表述成1/2、2/2等等了。
SWIFT MT202
MT 202单笔普通金融机构头寸请求在金融机构之间的头寸调拨
例：三井住友东京总行向中国银行总行索汇USD578 347.00，起息日为2007年2月10日。三井住友东京的业务代码为BP5642356。中国银行总行和三井住友东京总行的美元账户都开在花旗银行纽约分行。中国银行总行在花旗银行纽约分行的美元账号为36208129，中国银行总行的业务代码为SHTF55565447。
MT202报文：
注解
报文格式
发报行
BKCHCNBJ (中国银行总行)
报文类型
202
收报行
CITIUS33 (花旗银行关业务编号
21: BP5642356
起息日、币种、金额
32A: 0702010 USD578347
发报行在代理行的账号
53B: /36208129
收款行
58A: SMBCJPJT
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
2006年度SWIFT报文格式更新手册（2006/11/18起生效）S W I F T M T 7 0 0 / 7 0 1I S S U E O F A D / C开立跟单信用证MT700/701 范围1. 由开证行发送给通知行的报文（注意：收、发报行间必须具有BKE密押关系）；2. 用来列明开证行发报行所开立的信用证条款。
MT700/701 准则◆ 除非另外列明，所开立的跟单信用证遵循巴黎国际商会制定的《跟单信用证统一惯例》。
当该信用证遵循此惯例时，通知行（收报行）必须将之通知受益人或是另一家通知行。
◆ 除非另外列明，如果适用，跟单信用证项下的偿付遵循巴黎国际商会制定的《跟单信用证项下银行间偿付的统一规则》。
◆ 当跟单信用证的长度超过一个MT700的容量时，可以用一个或几个（最多三个）MT701报文格式来补充传送信息。
◆ 除非另外列明，根据该报文通知受益人或是另一家通知行的跟单信用证是已生效的信用证。
◆ 对自由议付跟单信用证，如果收报行不再以MT710报文格式转通知，那么该银行必须在信用证上加注：✧ 每次议付时必须提交通知受益人的信用证正本✧ 议付行必须在所通知的信用证正本上标注每一次的议付情况◆ 为了避免可能产生的误解，尽可能使用银行的SWIFT BIC代码来表示银行名称，而不要用“ourselves”、“yourselves”、“us”、“you”这些词。
◆ 通知行应该明确清楚地将跟单信用证的全部内容（包括任何细节）通知受益人。
MT700/701 域使用规则1. 报文中可以出现域39A或39B，但不能同时出现；2. 域42C和42a在被使用时必须同时出现；3. 在使用时，域42C和42a同时出现；或是42M 单独出现；或是42P单独出现，除此之外没有其它组合形式；4. 报文中可以出现域44C或44D，但不能同时出现；5. 用MT700开立的跟单信用证长度不超过10000个字符（包括报头和报尾）。
而收到的MT700的报文长度达10600个字符。
MT700/701 域详述域27：报文页次如果该跟单信用证条款能全部容纳在该MT700报文中，那么该项目内就填入“1/1”。
如果该证由一份MT700报文和MT701报文组成，那么在MT700报文的项目“27”中填入“1/2”，在MT701报文的项目“27”中填入“2/2”。
以此类推。
域40A：跟单信用证的形式域20：跟单信用证编号域23：预先通知的编号当信用证已预先通知，此域应填入代码“PREADV”，后跟“/”和预先通知的编号或日期域31C：开证日期如报文中无此域，则表明开证日期即为发报日期域40E：适用规则表明该信用证所遵循的准则及惯例该项必须使用下述代码中的一个:只有当使用的代码为“OTHR”时，域40E第二部分（即“/35x”）才允许出现域31D：到期日及到期地点表明跟单信用证最迟交单日期及交单地点域51a：开证申请人的银行如果开证行非开证申请人所在银行，则此域用以表明该银行域50：开证申请人域59：受益人域32B：货币币种及金额信用证金额的其他特殊信息将在39A、39B及39C表示域39A：信用证金额允许浮动的范围允许浮动的范围，以百分比表示，格式为2n/2n斜杠前数字表明向上浮动百分比值；斜杠后数字表示向下浮动百分比值如：15/15，表明上下浮动各不超过15%域39B：信用证金额的最高限额该项必须使用以下列出的代码，在代码后跟金额NOT EXCEEDING域39C：附加金额诸如保险费运费利息等域41a：指定有关银行及兑付方式* 如果该信用证为任意银行自由议付信用证，必须使用41D，表示为：“41D：Available With Any bank in （City/Country）；如果该信用证可以由任意地方任意一家银行进行议付，则表示为“41D：Available With Any bank”；如果用41A，则银行名一定要用SWIFT BIC表示。
* 必须使用以下这些短语BY PAYMENTBY ACCEPTANCEBY NEGOTIATIONBY DEF PAYMENTBY MIXED PYMT当报文使用“BY DEF PAYMENT”或“BY MIXED PYMT”时，有关付款的细节将在域42P或42M中表述。
当报文使用“BY PAYMENT”时就意味着“PAYMENT AT SIGHT”（即期付款）。
域42C：汇票付款期限域42a：汇票付款人付款人必须是银行。
如果付款人是开证申请人，那么此项应被作为单据在域46A列示，该域内不能出现帐号。
域42M：混合付款条款列明混合付款跟单信用证项下的付款日期金额及其确定方式域42P：延期付款条款列明延期付款跟单信用证项下的付款日期及其确定方式域43P：分批装运条款列明跟单信用证项下分批装运是否允许域43T：转运条款列明跟单信用证项下货物转运是否允许域44A：装船发运和接受监管的地点域44A：装船发运和接受监管/收到货物的地点该域列明接受监管的地点（如果要求的是多式运输单据）；收货地点（如果要求的是公路、铁路或内河运输单据或专递或快递机构出具证明收到待运货物的单据）；运输单据上列明的装船发运地点域44E：装货港/始发站机场运输单据中列明的装货港/始发站机场域44F：卸货港/目的地机场运输单据中列明的卸货港/目的地机场域44B：货物发送的最终目的地域44B：货物发运的最终目的地/交货地该域列明运输单据中列明的最终目的地或交货地域44C：最迟装运期域44D：装运期限域45a：货物/劳务描述FOB、CIF等价格条款应出现在域45a中为使信用证长度符合规定，一个MT700后最多可跟三个MT701，可是域45a只可以出现在其中一个报文中。
或者是出现在MT700；或者是出现在任意一个MT701中。
这就意味着在任意一个信用证中只有100行，每行65个字符可以被用来对货物或劳务进行描述。
下述为有效组合的实例：✧ MT700包含域45A、46A和47A✧ MT700包含域45A，同时发送的另一个MT701中包含域46B和47B✧ MT700包含域46A，同时发送的另一个MT701中包含域45B和47B✧ MT700包含域46A，同时发送的第一个MT701中包含域45B第二个MT701中包含域47B✧ MT700不含域45A、46A、47A，同时发送的第一个MT701中包含域45B；第二个MT701中包含域46B；第三个MT701中包含域47B下述为无效组合的实例：✧ MT700包含域45A，同时发送的第一个MT701中包含域45B和域46B；第二个MT701中包含域47B。
（无效原因：同时存在两个域45a）✧ MT700包含域45A，同时发送第一个MT701包含域45B；第二个MT701中包含域45B、46B、47B。
（无效原因：同时存在三个域45a）域46a：单据要求如果信用证内规定了运输单据的特定交单日期该日期应与有关单据要求一起列明在46a中对每个新条款的描述应另起一行在行首加上符号“+”域47a：附加条款如果有关信用证遵循的规则（准则或惯例）在域40E中没有短码适用，那么进一步的详细说明应该在信用证的域47a中出现。
不遵循UCP的声明必须在该域中列明。
除了报文本身规定的条款，如开证行需要其遵循UCP的声明，也可以在该域中清楚地表明。
如果可能的话，遵循ISP International Standby Practices的声明可以在该域中列明。
在这种情况下UCP将不再适用。
对每个新条款的描述应另起一行，在行首加上符号“+”。
当一份信用证由一份MT700和一份或几份至多3份MT701报文组成时，域45a、46a和47a必须完整地出现在其中的一个报文。
例如域45a出现在MT700中，那么这个域就不能出现在其他的MT701中。
当域45a、46a和47a的内容过长时，只能完整地表述完一个域才能使用另一个域。
如果报文所剩的字数不够用来表述另一个域，可以用一个新的MT701来补充。
例如：在一份MT700中域45a、46a表述完了，所剩的字数不够用于完整地表述域47a，就可以用一份MT701来完整地表述域47a。
在MT700报文中，45a、46a、47a的代号应分别为45A、46A、47A；在MT701 报文中则分别为45B、46B和47B。
对于遵循eUCP的信用证：如果提示电子文件及纸质文件都被允许的话，那么提示电子文件的地址（也就是提示行为必须向其做出的电子地址）与提示纸质文件的地址都在该域中列明。
如果仅允许电子文件被提示，那么提示电子文件的地址（也就是提示行为必须向其做出的电子地址）必须在该域中列明。
如果（有关电子地址）不是原始信用证内容中的一部分，通知行特别是收报行必须向受益人或另一家通知行提供开证行的电子地址；此外，通知行必须向受益人或另一家通知行提供有关电子地址，并且通知行希望电子文件向该地址提示。
万一电子地址中包含“@”符号，则该符号必须被“AT”代替。
万一电子地址中包含“_”符号，则该符号必须被“（UNDERSCORE）”代替。
例如：**********************应该表示成EUCP(AT)***************************应该表示成EUCP(UNDERSCORE)RECS(AT)域71B：费用该域只能用来表明由受益人承担的费用；如果报文中缺省该域，即表明除了议付费、转让费之外所有费用由开证人承担该项可使用前述代码，在代码后跟金额域48：交单期装运日后多少天内交单。
如果报文缺省此域，即表明交单期为21天。
域49：保兑指示域53a：偿付行开证行授权偿付信用证的银行。
该银行可以是发报行或收报行的分行，或是完全不同的另一家银行。
只有下列情况是例外，即当该信用证是议付信用证，发报行与收报行之间直接开有单一帐户，且该帐户币别与信用证币种一致时，此项缺省表示双方将通过该帐户来进行偿付。
域78：给付款行承兑行或议付行的指示此域列明开证行对付款/承兑/议付行的要求。
可用以要求付款/承兑/议付行预先通知索偿或预先借记通知。
如开证行要求预先通知，则应在此域中列明预先通知的时间段（天数——银行工作日或日历天数）域57a：通知行如果该信用证需通过收报行以外的另一家银行通知或加具保兑后给受益人，此域列明该银行。
域72：附言可选用下列短码PHONBEN 电话通知受益人TELEBEN 以最简便的电讯方式通知受益人S W I F T M T 7 0 5P R E - A D V I C E O F AD O C U ME N T A R Y C R E D I T跟单信用证的预通知MT705 范围1. 由开证行发送给通知行的报文；2. 用来简要通知信用证条款；3. 预先通知的信用证未生效。