报文结构

报文结构
报文结构

报文结构

1.以太网的报文结构

DA SA TYPE DATA CRC

6 6 2 46-1500 4(单位:

Bytes) DA:目的Mac地址

SA:源Mac地址

Type:指示Mac层的上层协议类型

DATA:数据字段

CRC:校验字段

Vlan的帧格式

DA SA Tag TYPE DATE CRC

6 6 4 2 46-150

0 4(单位:Bytes)

Tag:包括TPID(Tag Protocol Identifier--是IEEE定义的新的类型,表明这是一个加了802.1Q标签的帧)和TCI(含帧的控制信息,包括Priority-优先级;CFI-值为0说明是规范格式,1为非规范格式;Vlan ID)

2.HUB解决的问题

共享带宽的设备,可以实现多台电脑同时使用一条数据总线来上网或组成局域网

3.交换机接的的问题

HUB产生的广播问题

4.Vlan解决的问题

Vlan是为解决以太网的广播问题和安全性而提出的,它在以太网帧的基础上增加了Vlan头,用Vlan ID把用户划分为更小的工作组,限制不同工作组间的用户二层互访,每个工作组就是一个虚拟的局域网。虚拟局域网的好处是可以限制广播范围,并能够形成虚拟工作组,攻台管理网络

5.路由器和二层交换机的区别

路由工作在第三层,交换机工作在第二层

路由有包交换过滤功能。所有端口分别属于不同的广播和冲突域

交换机没有包交换和过滤功能。所有端口共享一个广播域,每个端口是一个冲突域

6.OSPF的几种报文

HELLO:周期性发送,用来发现和维持OSPF 的邻居关系

DD:描述了本地LSDB的摘要信息,用于两台路由器进行数据同步

LSR:向对方请求所需的LSA,只有在双方成功交换DD报文后才会向对方发出LSR报文

LSU:向对方发送其所需的LSA

LSAck:用来对收到的LSA进行确认

7.OSPF的几种LSA

Router LSA:(Type=1)每个路由器都会产生,描述了路由器的链路状态和花费,在所属区域内传播

Network LSA:(Type=2)由DR产生,描述本网段的链路状态,在所属区域内传播

Network Summary:(Type=3)由ABR产生,描述区域内某个网段的路由,并通告给其他区域ASBR Summary:(Type=4)由ABR产生,描述到ASBR的路由,通告给相关区域

AS External LSA:(Type=5)由ASBR产生,描述到AS外部的路由,通告给除了STUB区域和NSSA区域的所有区域

NSSA LSA(Type=7)由ASBR产生,描述到AS外部的路由,仅在NSSA区域内传播

8.OSPF为什么划分区域

如果一个区域的路由器太多,会造成LSDB过大,从而对路由器资源提出了更高的要求并会延缓了收敛的时间。同时一旦出现路由动荡,会造成大规模的SPF重新计算,造成路由器符合过

重引发更大规模的网络问题。

划分区域为了减少OSPF资源的要求和屏蔽网络的动荡

9.STUB区域和NSSA区域的区别

NSSA取消了STUB关于ASE(自制系统外部路由)的双向传播的限制,改为单向限制。STUB区域不能存在ASBR,即自制系统外部路由不能引入区域内。

10.OSPF路由选择策略

区域内路由

区域间路由

第一类外部路由(IGP)

第二类外部路由(EGP)

11.影响OSPF邻居关系的几个因素

1 两个邻居路由器Hello时间dead时间必须一致,不一致无法建立邻居关系

2 OSPF网络的Area ID,Area ID不一致无法建立邻居关系

3 两个邻居关系建立时双方配置的Password 是否一致,不一致无法建立邻居关系

4 OSPF网络中的特殊区域的标识。(NSSA,STUB...)区域标识必须一致

5 两个邻居关系建立需要双方接口下的MTU 值匹配。(默认MTU=1500,可以在MTU 值低的一方接口下执行 R1(config-if )# ip ospf mtu-ignore 忽略MTU 值在OSPF 邻居关系中的作用

6 MA 网络中建立OSPF 邻居路由器接口的子网掩码必须一致。如果不一致,会在OSPF 的2类LSA 中无法正确的描出MA 网络 12.OSPF 邻居状态机 13.IS-IS 状态机

Down Init UP

14.BGP 状态机

DOWN

Atte Init

2-wa

ExSt Exch

Full

Load

Idle :空闲 Connect :连接 Active :活跃

Conne

Estab

Activ

Open-Co

Open-

Tcp 连

Tcp 连

连接Tcp 连

发现

无错

确认

Tcp 连

Open-sent:打开消息已发送

Open-Confirm:打开消息确认

Established:连接已建立

15.NSAP结构

网络服务接入点。有两个服务接入点地址字段,初始域部分IDP(Initial Domain Part)和域特定部分DSP(Domain Specific Part)IDP相当于IP地址中的主网络号,DSP相当于IP地址中的子网号和主机地址。

IDP部分由ISO规定,由AFI(Authority and Format Identifier)与IDI(Initial Domain Identifier)组成,IDI用来标识域。

DSP由HODSP,SystemID和SEL组成。HODSP 用来分割区域,SystemID用来区分主机,SEL 指示服务类型。

IDP和DSP的长度都是可变的,NSAP总长最多是20个字节,最少8个字节。

区域地址:IDP和DSP中的HODSP一起,即能够标识路由域,也能够标识路由域中的区域,因此,他们一起被称为区域地址(Area Address)System ID:用来在区域内唯一标识主机或路由器。(6Bytes)

SEL :类似IP 中的“协议标识符”,不同德传输协议对应补用的SEL 。在IP 上SEL 均为00。(1Byte ) AFI :(1Byte ) IDI :(1Byte ) HODSP :(1--12Bytes )

https://www.360docs.net/doc/059531341.html, 和NSAP 的关系区别

网络实体名称NET (Network Entity Title )指示的是IS 本身的网络层信息,不包括传输层信息

I D P

I D I A F I H i g h O r d e r D s p S y s t e m I D

N S E L

D S P

变长的区域地址空间

6字节1字节

(SEL=0),可以看作是一类特殊的NSAP。因此,NET的长度与NSAP的相同,最多为20个字节,最少为8个字节。在路由器上配置IS-IS 时,只需要考虑NET即可,NSAP可不必去关注。

通常情况下,一台路由器配置一个NET即可,当区域需要重新划分时,例如将多个区域合并,或者将一个区域划分为多个区域,这种情况下配置多个NET可以在重新配置时仍然能够保证路由的正确性。由于一台路由器在一个IS-IS进程中区域地址最多可配置3个,所以NET最多也只能配3个。在配置多个NET时,必须保证它们的System ID都相同。

17.IS-IS和OSPF

1.协议标准的最初起源和设计目的不同

2.协议报文封装方式及所能支持的网络类型不同

3.路由器与区域的关系及链路状态数据库组织方式不同

4.对于骨干区域的定义不同

5.Hello协议的复杂程度和形成邻居关系的要求不同

6.数据库中的LSP(LSA)老化方式不用

7.广播网络上的DR选举方式不同

8.对于不同模型的网络类型支持方式不同

9.对于链路层metric 的区分能力及所能支持的最大metric 不同

比较点

IS-IS OSPF 是否最早为IP 设计的否

是是否是链路状态的IGP 是是是否直接运行在链路层上

是否是否有区域概念

是是是否适合层次性大型网络是是是否有指定路由器

是是DR 的选举是否是可确定的是否是否产生LSP 来描述网络结构是是是否支持IP

是是是否支持非IP 协议

18.DIS 和DR 的区别

IS-IS 的DIS 身份是允许自动抢占,无备份。 OSPF 的DR 不允许自动抢占,有备份。

比较点IS-IS

OSPF

适用范围

一般用在大型ISP 中

在企业网和ISP 中普遍使用

复杂度产生更少的LSPs ,而且一般使用一个区域产生更多的LSAs ,一般配置多个区域可扩展性

可以支持相当大的单个区域

比较大的网络一般划分为多个区域

对流量工程的支持扩展支持扩展支持可调节性

非常好

19.IS-IS的几种报文

链路状态报文LSP

IS-IS Hello报文

完全序列号报文CSNP

部分序列号报文PSNP

20.IS-IS路由渗透的作用,配置

使Level-2路由器可以将己知的其他Level-1区域以及Level-2区域的路由信息通报给指定的Level-1区域。

执行命令import-route isis level-2 into level-1 [ filter-policy {acl-number| ip-prefix ip-prefix-name| route-policy route-policy-name } ] [ tag tag],使能IS-IS路由渗透。

21.OSPF虚连接

虚连接是指在两台ABR之间通过一个非骨干区域而建立的一条逻辑上的连接通道。

配置在2台ABR之间,穿过一个非骨干区域

22.BGP的几种报文

Open:打招呼“你好,跟我交个朋友吧”KeepAlive:我还活着,别不理我

Update:有新闻

Notification:我不跟你玩了

23.BGP的通告原则

BGP 的路由通告原则:

多条路径时,BGP Speaker只选最优的给自己使用;

BGP Speaker只把自己使用的路由通告给相邻体;

BGP Speaker从EBGP获得的路由会向它所有BGP相邻体通告(包括EBGP和IBGP);BGP Speaker从IBGP获得的路由不向它的IBGP相邻体通告;

BGP Speaker从IBGP获得的路由是否通告给它的EBGP相邻体要依IGP和BGP同步的情况来决定;

连接一建立,BGP Speaker将把自己所有BGP 路由通告给新相邻体。

24.BGP的属性

类型代码属性名必遵/可选过渡/非过渡

1 Origin 必遵过渡

2 AS-Path 必遵过渡

3 Next-hop 必遵过渡

4 MED 可选非过渡

5 Local-preference 可选非过渡

8 Community 可选过渡

BGP属性可以扩展到256种

25.AS-Path属性的两种子属性

AS-Set 在UPDate消息中的路由经过的AS的无序集

AS-Sequence 在UPDate消息中的路由经过的AS的有序集

26.NE80E槽位

22个槽位,16个LPU槽位,4块交换网版,1+1冗余备份

27.MPLS标签分配和管理

标签分发方式:DOD(downstream-on-demand)和DU(downstream unsolicited)

DOD:上游LSR向下游LSR发送标签请求消息(包含FEC的描述信息),下游LSR为此FEC分配标签,并将绑定的标签通过标签映射消息反馈给上游LSR

DU:下游LSR在LDP会话建立陈宫,主动

向其上游LSR发布标签映射消息,上游路由器保存标签,存放到标签映射表中

标签控制方式:有序和独立

有序:只有受到它的下游返回的标签映射消息后才向其上游发送标签映射消息

独立:不管有没有受到它的下游返回的标签映射消息都立即向其上游发送标签映射消息

标签保持方式:保守和自由

保守:只保留来自夏一跳邻居的标签,丢弃所有非吓一跳邻居的标签。优点是节省内存和标签空间,缺点是当IP路由收敛、下一跳改变时,LSR收敛慢

自由:保留来自邻居的所有发送来的标签。优点是党IP路由收敛、下一跳改变时减少LSP 收敛时间,缺点是需要更多的内存和标签空间28.MPLS协议中LDP的邻居状态机和几种LDP消息(报文)

华为机密,未经许可不得扩散

文档密级:内部公开

NON EXISTENT

INITIALIZED

OPENREC

OPENSENT

OPERATIONAL

接收到Init 以外消息或超时

会话连接建立

发送Init 消息(主动方)

收到可接受的Init 消息;发送Init 消息发送Keep Alive 消息(被动方)

接收到Shutdown 消息

或超时;发送Shutdown 消息

其他LDP 消息

接收到Keep Alive 消息

接收到Keep Alive 以外消息或超时;发送

接收到可接收的Init 消息;发送Keep Alive 消息

接收到Init 以外消息或超时;

LDP 会话建立的状态迁移图

LDP 邻居状态机

LDP 消息:

发现(Discovery )消息,用于通告和维护网络中LSR 的存在

会话(Session )消息,用于建立维护和结束LDP 对等实体之间的会话连接

通告(Advertisement )消息,用于创建、改变和删除特定FEC-标记绑定

通知(Notification )消息,用于提供建议性的消息和差错通知

29.BGP/MPLS VPN 中的RT ,RD 和MPLS 的作用

MPLS 为实现VPN 提供了一种灵活的并且具有

可扩展性的技术基础

RD在骨干网中保持唯一性,是Site的标识。不会造成地址空间的冲突

RT是BGP的一种扩展团体属性

30.IP报文结构

版本号首部长度服务类型总长度标识标记TTL 协议号首部校验和

源IP地址目的IP地址选项

31.TCP报文结构

IP首部TCP TCP数据源端口号目的端口号序列号确认序列号首部长度

保留URG ACK PSH SYN FIN 窗口大小校验和紧急指南

32.OSPF报文头

Nersion OSPF 版本号

Type 报文类型

Packet length 报文总长度

AuType 验证类型

Authentication 数值视验证类型而定

33.TCP报文中SYN,FIN,RST,ACK,PSH,HRG的意思

SYN:同步标志,同步序号用来发起一个连接

FIN:结束标志,TCP首部中的结束标志,标志此报文发起方希望关闭连接。发送方在发送此报文后将进入半关闭状态,即不再通过此连接发送数据。

RST:复位标志,重建连接,当RST=1的时候通知重新建立TCP连接

ACK:确认标志,确认序列号有效

PSH:急迫标志,接收方尽快将这个报文交给应用层

URG:紧急标志,TCP的紧急方式是发送端向另一端发送紧急数据的一种方式

34.简述65交换机和93交换机在配置普通QINQ命令的不同点

63 Lim-type access

Vlan-vpn enable

93 QINQ enable

35.93交换机灵活QINQ的配置方法

建立配置任务

配置接口类型

配置匹配报文规则

配置叠加后的外出呢个Vlan Tag

配置流策略

使能流策略

检查配置结果

1、建立配置任务

应用环境

为了让用户跨越运营商网络进行通信,需要添加外层VLAN Tag。

前置任务

数据准备

在配置基于流的灵活QinQ 之前,需要准备以下数据。

序号数据

1 配置灵活QinQ 功能的接口的编号

2 内层VLAN Tag 的VLAN 编号

3 外层VLAN Tag 的VLAN 编号

2、配置接口类型

背景信息

请在需要配置灵活QinQ 的S9300 上进行以下配置。

操作步骤

步骤1 执行命令system-view,进入系统视图。

SWIFT报文的结构与报文类型

SWIFT 标准资料(十五)2003年11月实施版 SWIFT 标准 报文的结构与报文类型 2003年11月发布标准 2003年标准发布指南-最终版本-2003年2月 全国金融标准化技术委员会秘书处 对外经济贸易大学金融科技中心 2003-08-06

SWIFT标准报文 SWIFT标准报文(金融服务报文) SWIFT开发的商业标准报文已经成功应用在金融服务领域,而且根据市场的需要在不断发展中。2003版SWIFT标准扩大了应用范围,规范了具体形式,同时采用了先进的技术成果、可以满足金融服务的需要,包括批量支付、投资基金、证券、信托等方面。SWIFT标准的下一个版本将在2005年5月发布。 下面表示的是SWIFT标准2003版的发布过程:从2002年8月开始到2003年11月 正式实施。 Schedule for Standards Release 2003 For implementation schedule is as follows: High-Level Release 2003 Preliminary Standards Release Guide 2003 Preliminary Message Format Validation Rules 2003 Final Standards Release Guide 2003 Final Message Format Validation Rules 2003 Vendor Test System Testing & Training System If necessary Rules 2003

第一章报文结构和报文类型 1.1 SWIFT报文结构 所有金融报文必须符合SWIFT标准卷描述的某种报文类型的规则。 报文类型由三个数字组成,一般定义为: 类目通常在一般程度上描述报文的基础商业功能,如类目1=客户支付和支票。 分组描述某一特定类目中的报文功能,如11n=类目1的支票支付报文。 类型描述具体功能,如112=支票止付请求的状态。 因此,通过报文类型(位于报文标题),报文接收方可以帮助决定报文的内容和功能,以及其组成内容细节。 本节提供报文类型的一般规则。属于单个报文的详细说明可以在相关类目卷查找到。 1.2 SWIFT报文类型 下方表格列出SWIFT标准卷中定义的所有报文类型,在2002年十月标准版本中有效。 对于每个报文类型,均存在简述、报文类型需要认证标识(Y或N)、最大报文长度(2,000或10,000)以及使用报文是否需要在SWIFT注册(Y或N)。 注意:MUG,出于本书目的,是自愿同意支持特定报文类型并且在SWIFT注册发送或接收特定报文的使用者群组。下方表格中的“MUG”列标出了这些报文。(关于MUG的更多信息在表后

SWIFT报文格式手册

S W I F T报文格式手册 Revised by Petrel at 2021

2006年度SWIFT报文格式更新手册(2006/11/18起生效)

S WIFT MT700/701 I SSUEOFA D/C 开立跟单信用证 MT700/701范围 1.由开证行发送给通知行的报文(注意:收、发报行间必须具有BKE密押关系); 2.用来列明开证行发报行所开立的信用证条款。

除非另外列明,所开立的跟单信用证遵循巴黎国际商会制定的《跟单信用证统一惯例》。当该信用证遵循此惯例时,通知行(收报行)必须将之通知受益人或是另一家通知行。 除非另外列明,如果适用,跟单信用证项下的偿付遵循巴黎国际商会制定的《跟单信用证项下银行间偿付的统一规则》。 当跟单信用证的长度超过一个MT700的容量时,可以用一个或几个(最多三个)MT701报文格式来补充传送信息。 除非另外列明,根据该报文通知受益人或是另一家通知行的跟单信用证是已生效的信用证。 对自由议付跟单信用证,如果收报行不再以MT710报文格式转通知,那么该银行必须在信用证上加注: 每次议付时必须提交通知受益人的信用证正本 议付行必须在所通知的信用证正本上标注每一次的议付情况 为了避免可能产生的误解,尽可能使用银行的SWIFTBIC代码来表示银行名称,而不要用 “ourselves”、“yourselves”、“us”、“you”这些词。 通知行应该明确清楚地将跟单信用证的全部内容(包括任何细节)通知受益人。MT700/701域使用规则 1.报文中可以出现域39A或39B,但不能同时出现; 2.域42C和42a在被使用时必须同时出现;

SWIFT报文格式手册

2006年度SWIFT报文格式更新手册(2006/11/18起生效)

S W I F T M T 7 0 0 / 7 0 1 I 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 in 1*65x Charge at / from O44B For Transportation to...1*65x O44C Latest Date of Shipment6!n O44D Shipment Period6*65x O45A Description of Goods and/or Services100*65x O46A Documents Required100*65x O47A Additional Conditions100*65x O71B Charges6*35x O48Period for Presentation4*35x M49Confirmation Instructions7!x O53a Reimbursing Bank A or D 12*65x O78Instructions to the Paying/Accepting/Negotiating Bank O57a"Advise Through" Bank A, B or D O72Sender to Receiver Information6*35x MT701格式(M = Mandatory O = Optional) Status Tag Field Name Content/Options M27Sequence of Total1!n/1!n M20Documentary Credit Number16x O45B Description of Goods and/or Services100*65x O46B Documents Required100*65x O47B Additional Conditions100*65x MT700/701 准则 除非另外列明,所开立的跟单信用证遵循巴黎国际商会制定的《跟单信用证统一惯例》。当该信用证遵循此惯例时,通知行(收报行)必须将之通知受益人或是另一家通知行。 除非另外列明,如果适用,跟单信用证项下的偿付遵循巴黎国际商会制定的《跟单信用证项下银行间偿付的统一规则》。 当跟单信用证的长度超过一个MT700的容量时,可以用一个或几个(最多三个)MT701报文格式来补充传送信息。 除非另外列明,根据该报文通知受益人或是另一家通知行的跟单信用证是已生效的信用证。 对自由议付跟单信用证,如果收报行不再以MT710报文格式转通知,那么该银行必须在信用证上加注: 每次议付时必须提交通知受益人的信用证正本 议付行必须在所通知的信用证正本上标注每一次的议付情况 为了避免可能产生的误解,尽可能使用银行的SWIFT BIC代码来表示银行名称,而不要用

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 是一种银行对银行的发出的信息,用于为保证乙方在乙银行的利益,由甲银行向乙银行开出的或者被申请开出的银行保函。根据MT760开出的保证,对甲银行的资金,封存并用做担保风险。 MT760 是经对相关单证的检验,确认,查证并发送到你方后产生的一种付款责任。如果它不符合你方标准,那么钱就不会进入你方的账户。钱不可能转出账户直到证件完全符合你方所在银行的标准。但是你必须有足够的钱作为保证金,或者你必须与银行机构有良好的关系(如果没有存款或者保证金的情况),才能用某种MT(信汇)来转账。此做法是避免此保函的受益人乙方风险的最佳途径。 SWIFT MT799/RWA 其实包含三个意思。 MT799是电文中银行文本的格式编号,不一定就是说资金证明,使用MT799只要银行愿意,发送任何内容的东西都可以。在国际贸易中MT799其实是相对MT999来说的,这两种电文格式是使用最多的普通格式,只是799是密文,999是明文。贸易还有一种使用得多的是MT760,这是一种专用格式电文,一般发送LC,BG。MT799, MT999和MT760的最重要的区别是前两者是一种单向电文,也就是送达到了就OK了,MT760是双向电文,必须由接收方确认。 RWA是银行安慰信(Bank Comfort Letter)的一种,全称是Letter of Ready,Willing (and financial) Able。一般这个是在使用银行金融工具时候银行在出具银行工具文本MT760之前确认银行客户具有出具银行工具的能力的时候使用的。国际贸易中LC也算是银行工具的一种,但

SWIFT清算系统功能说明书

1.子系统描述 SWIFT清算子系统采用最新的数据大集中体系结构,由操作前台、中间处理两部分组成,全行的SWIFT电文数据集中在总行的数据服务器,提高了系统的运行效率、安全性和可维护性。 前台为业务处理的操作界面,处理电文的录入、读取,检查、撮合、下划、资料的维护等操作。 中台为业务处理部分,业务规则和数据检查、日初、日终、对前台传送的数据进行相应的处理,生成传票,对帐务进行处理,报文自动分发等操作。并与ALLANCE系统相连,自动接收,发送报文。 外汇清算系统与国际结算系统、SWIFT ALLIANCE系统和记帐核心系统紧密相联,处理的业务内容包括行外来电的清分与转发、分行发往行外电文的转发、汇入款项的下划、分行每日付款总头寸统计、汇出款项的扣帐、所有汇入汇出款项的勾对核销、存放境外同业帐户余额的核对、退汇业务等,以及以上业务的帐务处理,并提供各种查询功能和清算业务量统计表。 2.系统参数设置 ●SWIFT清算窗口时间设置(由整个系统考虑) 由清算系统设置SWIFT清算窗口时间,在该时间范围之外的SWIFT报文将全部后台等待。 ●清算分支机构维护(由整个系统考虑) 维护内容加入SWIFT号码、机构英文名称等内容。

●头寸报文条件设置 系统根据此条件来判断报文是否为头寸报文,具体的参数设置为; ●报文所属分行条件设置 系统根据下列条件设置,根据报文类型以及报文中内容来判断报文的所属分行。 ●报文所属外围系统条件设置 对于由清算系统转发至各外围系统的报文,在此参数设置中配置:

●SWIFT清算系统用户设置(由整个系统考虑) ●黑名单维护 由下载的文本文件自动导入,可以通过界面进行增、删、改。 ●四角号码库维护 ●SWIFT参与行维护 由SWIFT网站下载FI.DAT文件,系统自动导入。 ●报文模版设置(该模板将用于手工生成报文)

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 是一种银行对银行的发出的信息,用于为保证乙方在乙银行的利益,由甲银行向乙银行开出的或者被申请开出的银行保函。根据MT760开出的保证,对甲银行的资金,封存并用做担保风险。 MT760 是经对相关单证的检验,确认,查证并发送到你方后产生的一种付款责任。如果它不符合你方标准,那么钱就不会进入你方的账户。钱不可能转出账户直到证件完全符合你方所在银行的标准。但是你必须有足够的钱作为保证金,或者你必须与银行机构有良好的关系(如果没有存款或者保证金的情况),才能用某种MT(信汇)来转账。此做法是避免此保函的受益人乙方风险的最佳途径。 SWIFT MT799/RWA 其实包含三个意思。 MT799是电文中银行文本的格式编号,不一定就是说资金证明,使用MT799只要银行愿意,发送任何内容的东西都可以。在国际贸易中MT799其实是相对MT999来说的,这两种电文格式是使用最多的普通格式,只是799是密文,999是明文。贸易还有一种使用得多的是

SWIFT 报文(MT 700)中的代号及栏目名称

SWIFT 报文(MT 700)中的代号及栏目名称 SWIFT 报文(MT 700)中的代号及栏目名称 M/O 代号(Tag)栏目名称(Field Name) M 27 报文页数(Sequence of Total) M 40A 跟单信用证类别(Form of Documentary Credit) M 20 信用证编号(Documentary Credit Number) O 23 预先通知编号(Reference to Pre-Advice) O 31C 开证日期(Date of Issue) M 31D 到期日及到期地点(Date and Place of Expiry) O 51A 开证申请人的银行(Applicant Bank) M 50 申请人(Applicant) M 59 受益人(Beneficiary) M 32B 信用证的货币及金额(Currency Code, Amount) O 39A 信用证金额允许浮动的范围(Percentage Credit Amount Tolerance) O 39C 信用证金额最高限额(Maximum Credit Amount) O 41A 指定的有关银行及信用证的兑付方式(Available with … by …) M 42C 汇票付款期限(Draft at) O 42A 汇票付款人(Drawee) O 42M 混合付款条款(Mixed Payment Details) O 42P 迟期付款条款(Deferred Payment Details) O 43P 分批装运条款(Partial Shipments) O 43T 转运条款(Transshipment) O 44A 装船、发运和接受监督地点(Loading on Board/Dispatch/Taking in Charge at (from)) O 44B 货物发送最终目的地(For Transportation to …) O 44C 最迟装运日期(Latest Date of Shipment) O 44D 装运期(Shipment Period) O 45A 货物/劳务描述(Description of Goods and/or Services) O 46A 单据要求(Documents Required) O 47A 附加条款(Additional Conditions) O 71B 费用负担(Charges) O 48 交单期限(Period of Presentation) M 49 保兑指示(Confirmation Instructions) O 53A 偿付行(Reimbursing Bank) O 78 给付款行、承兑行或议付行的指示(Instructions to the Paying/Accepting/Negotiating Bank) O 57A 通知行(Advising Through Bank) O 72 附言(Sender to Receiver Information) 以上表格中的“M”为“Mandatory”,指电文中该项目的内容必须填写;“O”为“Optional”,指电文中该项目的内容可以选择不填写。

SWIFT报文地结构与报文类型

实用标准 SWIFT 标准资料(十五)2003年11月实施版 SWIFT 标准 报文的结构与报文类型 2003年11月发布标准 2003年标准发布指南-最终版本-2003年2月

全国金融标准化技术委员会秘书处对外经济贸易大学金融科技中心 2003-08-06

SWIFT标准报文 SWIFT标准报文(金融服务报文) SWIFT开发的商业标准报文已经成功应用在金融服务领域,而且根据市场的需要在不断发展中。2003版SWIFT标准扩大了应用范围,规范了具体形式,同时采用了先进的技术成果、可以满足金融服务的需要,包括批量支付、投资基金、证券、信托等方面。SWIFT标准的下一个版本将在2005年5月发布。 下面表示的是SWIFT标准2003版的发布过程:从2002年8月开始到2003年11 月正式实施。

Standards Release 2003 Schedule for Standards Release 2003 For the Standards Release 2003, the development and implementation schedule is as follows: 16 August 2002 High-Level Information on Standards Release 2003 15 November 2002 Preliminary Standards Release Guide 2003 Preliminary Message Format Validation Rules 2003 14 February 2003 Final Standards Release Guide 2003 Final Message Format Validation Rules 2003 29 March 2003 Vendor Test System 12 July 2003 Testing & Training System If necessary, updates to Message Format Validation Rules 2003 12 September 2003 UHB shipment 15 November 2003 Standards Release 2003 Live

SWIFT报文的结构与报文类型

. . . .. . SWIFT 标准资料(十五)2003年11月实施版 SWIFT 标准 报文的结构与报文类型 2003年11月发布标准 2003年标准发布指南-最终版本-2003年2月 全国金融标准化技术委员会秘书处 对外经济贸易大学金融科技中心 2003-08-06

SWIFT标准报文 SWIFT标准报文(金融服务报文) SWIFT开发的商业标准报文已经成功应用在金融服务领域,而且根据市场的需要在不断发展中。2003版SWIFT标准扩大了应用范围,规范了具体形式,同时采用了先进的技术成果、可以满足金融服务的需要,包括批量支付、投资基金、证券、信托等方面。SWIFT标准的下一个版本将在2005年5月发布。 下面表示的是SWIFT标准2003版的发布过程:从2002年8月开始到2003年11月 正式实施。 Standards Release 2003 Schedule for Standards Release 2003 For the Standards Release 2003, the development and implementation schedule is as follows: 16 August 2002 High-Level Information on Standards Release 2003 15 November 2002 Preliminary Standards Release Guide 2003 Preliminary Message Format Validation Rules 2003 14 February 2003 Final Standards Release Guide 2003 Final Message Format Validation Rules 2003 29 March 2003 Vendor T est System 12 July 2003 Testing & Training System If necessary, updates to Message Format Validation Rules 2003 12 September 2003 UHB shipment 15 November 2003 Standards Release 2003 Live

SWIFT报文的结构和报文类型

下载可编辑 SWIFT 标准资料(十五)2003年11月实施版 SWIFT 标准 报文的结构与报文类型 2003年11月发布标准 2003年标准发布指南-最终版本-2003年2月 全国金融标准化技术委员会秘书处 对外经济贸易大学金融科技中心 2003-08-06

SWIFT标准报文 SWIFT标准报文(金融服务报文) SWIFT开发的商业标准报文已经成功应用在金融服务领域,而且根据市场的需要在不断发展中。2003版SWIFT标准扩大了应用范围,规范了具体形式,同时采用了先进的技术成果、可以满足金融服务的需要,包括批量支付、投资基金、证券、信托等方面。SWIFT标准的下一个版本将在2005年5月发布。 下面表示的是SWIFT标准2003版的发布过程:从2002年8月开始到2003年11月 正式实施。 Schedule for Standards Release 2003 For implementation schedule is as follows: High-Level Release 2003 Preliminary Standards Release Guide 2003 Preliminary Message Format Validation Rules 2003 Final Standards Release Guide 2003 Final Message Format Validation Rules 2003 Vendor Test System Testing & Training System If necessary Rules 2003

SWIFT_MT103_付款报文格式

MT 103 MT 103 - ClearingLine Format Specifications MT 103 Customer Transfer M = Mandatory O = Optional Status Tag Field Name Content/Options M 20 Sender's Reference 16 digits M 23B Bank Operation Code CRED O 23E Instruction Code 4 digits M 32A Value Date Currency Interbank Settled Amount 6 numeric 3 alphabetical 15 digits O 33B Currency/ Instructed Amount 3 alphabetical 15 digits O 36 Exchange Rate 12 digits M 50a Ordering Customer: Account number Code / Identifier (Option F) Name & Address Option F is preferred Option Option A [/34x] (Account) 4!a2!a2!c[3!c] (BIC/BEI) Option K [/34x] (Account) 4*35x (Name & Address) Option F 35x (Party Identifier) 4*35x (Name & Address) O 52A Ordering Institution A or D M 53B Sender's Correspondent /D/10 digits your account number O 56A Intermediary Institution A or C C = for Germany only O 57A Account With Institution A, B, C or D C = for Germany only

SWIFT信用证报文详解

S W I F T信用证报文详解-CAL-FENGHAI-(2020YEAR-YICAI)_JINGBIAN

SWIFT 信用证及其基本内容 国际上各银行开具的信用证没有统一的格式,但无论是以什么方式开具的信用证,其遵循的基本原则和基本内容都是一致的。在出现了SWIFT组织以后,信用证的形式和条款逐渐规范,并在实际业务中为大多数国家的银行所遵循。Swift共有十类特点格式化和规范化 第一类客户汇款与支票 第二类银行头寸调拨 第三类外汇买卖和存放款 第四类托收 第五类证券 第六类贵金属与辛迪加 第七类跟单信用证和保函 第八类旅行支票 第九类银行帐务 第十类 SWIFT系统电报 SWIFT电讯的表示方法 1、各国货币的表示方法 美元 USD 人民币 CNY 日元 JPY 英镑 GBP 2、数字的表示方法数字不使用分格号,小数点用逗号表示 5,152,286.36 表示为 5152286,36 4/5 0,8 5%表示为 5 PERCENT 日期的表示方法 YYMMDD 2007年10月15日表示为071015 第七类重点介绍MT700/701 MT707 MT700/701开立信用证格式 最长不能超过2000个字符,假如超过2000,我们将其分为若干部分,使用一个MT700以及若干个MT701 MT700 02 02表示电讯等级代码(普通级) 27, 40A , 20 ,31D,50,32B,41M,49为必选项目(MANDATORY) 其余为选用项目(OPTIONAL) SWIFT信用证是指凡通过SWIFT系统开立或予以通知的信用证。在国际贸易结算中,SWIFT信用证是正式的、合法的,被信用证各当事人所接受的、国际通用的信用证。采用SWIFT信用证必须遵循SWIFT的规定,也必须使用SWIFT手册规定的代号(TAG),而且信用证必须遵循国际商会1993年修订的《跟单信用证统一惯例》各项条款的规定。在SWIFT信用证中可省去开证行的承诺条款,但不因此免除银行所应承担的义务。SWIFT信用证的特点是快速、准确、简明、可靠。 SWIFT报文(TEXT)由一些项目(FIELD)组成,每一种报文格式(MESSAGE TYPE,MT)规定了由那些项目组成,每一个项目又严格规定了由多少字母、多少数字或多少字符组成。这些规定的表示方法及含义如下: n:只表示数字;a:只表示字母;Q:表示数字或字母;x表示SWIFT电讯中允许出现的任何一个字符(包括10个数字、26个字母、有关标点符号、空格键、回车键和跳行键); *:行数。

汇出行制作电汇项下SWIFT报文

汇出行制作电汇项下SWIFT报文 工作项目 陈艾前后有两次汇款。第一次是汇30%的货款汇到DAYCO公司在HSBC, MIAMI的账户,这笔业务的汇款申请书在前面已经完成。HSBC, MIAMI与中国银行浙江省分行有来往账户,无需中转行。 第二次陈艾要汇70%的货款汇给DAYCO公司。这次对方要求汇到它们在WACHOVIA BANK, NA(Griswold St, No. 24, MIAMI, FL)的账户(A/C NO. 765922894)。WACHOVIA BANK,NA(BIC: PNBPUS3MXXX)中国银行浙江省分行(BIC:BKCHCNBJ910)的代理行,有密押交换,但没有往来账户。这种情况下双方可以通过SWIFT互发信息但不能直接调拨资金。陈艾没有拖家带口转行,所以中国银行浙江省分行指定CITI BANK, NEW YORK (BIC: CITIUS33EUC)作为中转行来完成汇款,CITIBANK, NEW YORK刚好有中国银行浙江省分行和W ACHOVIA BANK, NA的账户。第二次汇款申请书如下: 境外汇款申请书 APPLICATION FOR FUNDS TRANSFERS (OVERSEAS) 致:中国银行日期:

两笔款项都从金苑公司的现汇账户(No. 78954321)转出。陈艾将所汇款款项及所需费用交中国银行浙江省分行,取得电汇回执。 两次汇款业务都由中国银行浙江省分行国际结算部门的工作人员赵宾经手,他要审核汇款

申请书及有效凭证和商业单据,主要有合同、发票、报关单等。经查无误后根据汇款申请书内容以SWIFT方式向汇入行发出解付指示。第一次发送MT103的业务编号为OR2008123741;第二次发送MT103的业务编号为OR2008123765,MT202的业务编号为OR2008123732. 赵宾的工作项目主要有: 工作项目1:读懂两份外汇申请书的各项内容,分清两次汇款路线及发报方式。 工作项目2:明确SWIFT报文MT103的内容和填写要求,根据第一次汇款的申请书制作MT103; 工作项目3:明确SWIFT报文MT202的内容和填写要求,根据第二次汇款的申请书制作MT103和MT102. 适用于汇款的SWIFT报文种类和格式

SWIFT信用证报文详解

SWIFT 信用证及其基本内容 国际上各银行开具的信用证没有统一的格式,但无论是以什么方式开具的信用证,其遵循的基本原则和基本内容都是一致的。在出现了SWIFT组织以后,信用证的形式和条款逐渐规范,并在实际业务中为大多数国家的银行所遵循。 Swift共有十类特点格式化和规范化 第一类客户汇款与支票 第二类银行头寸调拨 第三类外汇买卖和存放款 第四类托收 第五类证券 第六类贵金属与辛迪加 第七类跟单信用证和保函 第八类旅行支票 第九类银行帐务 第十类SWIFT系统电报 SWIFT电讯的表示方法 1、各国货币的表示方法 美元USD 人民币CNY 日元JPY 英镑GBP 2、数字的表示方法数字不使用分格号,小数点用逗号表示 5,152,286.36 表示为5152286,36 4/5 0,8 5%表示为5 PERCENT 日期的表示方法YYMMDD 2007年10月15日表示为071015 第七类重点介绍MT700/701 MT707 MT700/701开立信用证格式 最长不能超过2000个字符,假如超过2000,我们将其分为若干部分,使用一个MT700以及若干个MT701 MT700 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)规定了由那些项目组成,每一个项目又严格规定了由多少字母、多少数字或多少字符组成。这些规定的表示方法及含义如下: n:只表示数字;a:只表示字母;Q:表示数字或字母;x表示SWIFT电讯中允许出现的任何一个字符(包括10个数字、26个字母、有关标点符号、空格键、回车键和跳行键);*:行数。 例如,2 n表示最多填入2位数字;3 a表示最多填入3个字母;4*35x表示所填入的内容最多是4行,每行最多35个字符。 在一份SWIFT报文中,有些规定项目是必不可少的,称为必选项目(MANDATORY FIELD,M);有些规定项目可以由操作员根据业务需要确定是否可以选用,这些项目称为可选项目

2011最新版swift报文标准第N类报文更新

Standards Category n - Common Group Messages For Standards MT November 2011 Message Reference Guide Standards Release Guide This reference guide contains the category n message text standards, including a detailed description of the scope, the format specifications, the rules, the guidelines, and the field specifications of each message type. 17 December 2010

Table of Contents Introduction (3) Summary of Changes (3) Category n Message Types (4) Euro - Impact on Category Message Standards (6) MT n90 Advice of Charges, Interest and Other Adjustments (7) MT n90 Scope (7) MT n90 Format Specifications (7) MT n90 Network Validated Rules (7) MT n90 Field Specifications (7) MT n91 Request for Payment of Charges, Interest and Other Expenses (13) MT n91 Scope (13) MT n91 Format Specifications (13) MT n91 Network Validated Rules (13) MT n91 Market Practice Rules (13) MT n91 Field Specifications (13) MT n92 Request for Cancellation (19) MT n95 Queries (20) MT n96 Answers (21) MT n98 Proprietary Message (22) MT n99 Free Format Message (23) Legal Notices............................................................................................................................................ 24 Category n - Common Group Messages for Standards MT November 2011 2Message Reference Guide - Standards Release Guide

SWIFT信用证报文详解上课讲义

S W I F T信用证报文详 解

SWIFT 信用证及其基本内容 国际上各银行开具的信用证没有统一的格式,但无论是以什么方式开具的信用证,其遵循的基本原则和基本内容都是一致的。在出现了SWIFT组织以后,信用证的形式和条款逐渐规范,并在实际业务中为大多数国家的银行所遵循。Swift共有十类特点格式化和规范化 第一类客户汇款与支票 第二类银行头寸调拨 第三类外汇买卖和存放款 第四类托收 第五类证券 第六类贵金属与辛迪加 第七类跟单信用证和保函 第八类旅行支票 第九类银行帐务 第十类 SWIFT系统电报 SWIFT电讯的表示方法 1、各国货币的表示方法 美元 USD 人民币 CNY 日元 JPY 英镑 GBP 2、数字的表示方法数字不使用分格号,小数点用逗号表示 5,152,286.36 表示为 5152286,36 4/5 0,8 5%表示为 5 PERCENT 日期的表示方法 YYMMDD 2007年10月15日表示为071015

第七类重点介绍MT700/701 MT707 MT700/701开立信用证格式 最长不能超过2000个字符,假如超过2000,我们将其分为若干部分,使用一个MT700以及若干个MT701 MT700 02 02表示电讯等级代码(普通级) 27, 40A , 20 ,31D,50,32B,41M,49为必选项目(MANDATORY) 其余为选用项目(OPTIONAL) SWIFT信用证是指凡通过SWIFT系统开立或予以通知的信用证。在国际贸易结算中,SWIFT信用证是正式的、合法的,被信用证各当事人所接受的、国际通用的信用证。采用SWIFT信用证必须遵循SWIFT的规定,也必须使用SWIFT手册规定的代号(TAG),而且信用证必须遵循国际商会1993年修订的《跟单信用证统一惯例》各项条款的规定。在SWIFT信用证中可省去开证行的承诺条款,但不因此免除银行所应承担的义务。SWIFT信用证的特点是快速、准确、简明、可靠。 SWIFT报文(TEXT)由一些项目(FIELD)组成,每一种报文格式(MESSAGE TYPE,MT)规定了由那些项目组成,每一个项目又严格规定了由多少字母、多少数字或多少字符组成。这些规定的表示方法及含义如下:n:只表示数字;a:只表示字母;Q:表示数字或字母;x表示SWIFT电讯中允许出现的任何一个字符(包括10个数字、26个字母、有关标点符号、空格键、回车键和跳行键); *:行数。 例如,2 n表示最多填入2位数字;3 a表示最多填入3个字母;4*35x表示所填入的内容最多是4行,每行最多35个字符。

SWIFT报文格式手册

2006年度SWIFT报文格式更新手册(2006/11/18起生效)

S W I F T M T 7 0 0 / 7 0 1 I S S U E O F A D / C 开立跟单信用证 MT700/701 范围 1、由开证行发送给通知行得报文(注意:收、发报行间必须具有BKE密押关系); 2、用来列明开证行发报行所开立得信用证条款。

◆ 除非另外列明,所开立得跟单信用证遵循巴黎国际商会制定得《跟单信用证统一惯例》。当该信用证遵循此惯例时,通知行(收报行)必须将之通知受益人或就是另一家通知行。 ◆ 除非另外列明,如果适用,跟单信用证项下得偿付遵循巴黎国际商会制定得《跟单信用证项下银行间偿付得统一规则》。 ◆ 当跟单信用证得长度超过一个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”。以此类推。

相关文档
最新文档