[D]删除＜ＢIC5＞变量的定义。
［Ｍ]ＦMＴ089报文的明细中的“数字证书DN号”修改为“数字证书CN”,“数字证书参考号”修改为“数字证书SN”。
［M］ＦＭＴ013增加可以给特许参与者发送的说明，增加对清算金额的说明。
修改“清算行行号A０６”为“直接（特许）参与者行号A０1”。
[M]FMT016修改处理状态:
“４0FＸＣＣ日终退回”为“4０ FXCＣ退回”。
[M]1.１.1增加说明2:
本系统使用“┛”（0XＡ9BＦ）作为用户输入的回车字符。
[M]FMT073增加说明⑤,说明补发的往帐支付报文的报文第1、2块填写规则。
１．３
20０8-2－２3
[Ｍ]FMT０2１增加说明8、９,修改Ａ10名称“被计费清算行行号”为“被计费节点”，类型“”为“”支持对结算银行计费功能。
1.4
200８-4-18
[M]修正４附录 TAG与域名一览表的内容和报文正文内容一致，并删除其中未使用的TAG定义。
说明：
[C]-创建；[M]－修改报文；[A]-增加报文;[Ｄ]-删除报文；
1报文标准概述
1.1概述
1.1.1属性符号ﻩ
n
表示0至9的数字
a
表示大写字母
x
表示X字符集中的任意字符
c
表示大写字母、０至9的数字
ｈ
表示十六进制数，即数字０－9,大写字母A-Ｆ;
d
表示数值，即0-9，小数点符（使用逗号）‘,’;整数部分必须出现,至少有一位数字组成，可以出现前导0；如果没有小数部分，小数点符也必须提供。
Ｇ
表示汉字编码字符集（GB１8０３０编码）
g
表示X字符集与汉字编码字符集（GB1803０编码）
E
表示ＢAＳE64编码;
说明1:
对于特定的域,如账号，在数字与字母混合使用时，不得大小写混用，不得使用字母O和o,I和ｉ,以避免与数字0和１混淆。
说明２:
对于ＦＭＴ１95（:
7５:
查询内容）、FMT196（：
76:
查复内容）、ＦMT199（:
79:
/F8９/内容）几个字段,当用户需要在内容中输入回车时，本系统使用“┛”（0XA9BF） 作为用户输入的回车字符。
1.1.2Ｘ字符集
外币支付系统X字符集使用AＳCII编码，由以下7８个字符组成:
0
１
２
3
4
５
６
7
8
９
A
B
C
D
E
F
0
LF
ＣR
1
2
SＰ
＃
（
）
+
,
-
.
/
3
0
1
２
3
4
５
6
7
８
9
:
；
?
4
@
A
B
C
Ｄ
E
F
G
Ｈ
I
J
K
L
M
N
O
5
P
Ｑ
R
Ｓ
T
U
V
W
Ｘ
Y
Ｚ
_
6
a
b
C
d
e
ｆ
ｇ
h
i
j
k
ｌ
m
ｎ
o
7
ｐ
q
r
S
ｔ
u
v
ｗ
x
y
z
{
｝
说明：
上述字符集中，:
／{｝ 四个字符保留为报文块的定界符，报文域值（业务数据）中不能使用此四字符,否则报文将被外币支付系统拒绝。
正文块中的2０栏位,16x中要求必须不能出现ＳＰ空格字符，否则报文将被外币支付系统拒绝。
1.1.3英文简称命名规范
首词首字母小写其余词首字母大写,当长度超过８个字符时，使用缩写，缩写原则为四个或三个字母。
1.1.4报文结构
外币支付系统报文由多个报文块构成,报文块使用左花括号‘{’开始,使用右花括号‘}’结束，紧接着左花括号使用一位数字标识块的类型，其后使用冒号‘:
’将块标识与块内容分开。
外币支付系统使用以下报文块:
Ø基本头块：
{1:
BASICHＥADERBＬOCK｝；
Ø应用头块:
｛2:
APPLICAＴＩOＮ HEADＥＲ BLOCK};
Ø用户头块：
{3：
ＵSＥRＨEADERBLOCＫ};
Ø用户正文块:
{4：
ＴEXTBＬOＣK｝
Ø附加正文块:
{5：
APPENＤTEXTＢLOCK}
Ø签名块:
{６:
MACＢＬOCK｝
Ø报尾块：
{7:
TRＡIL BＬOCK}
其中第１块（基本头）、第2块（应用头）分别记录发起方、接收方信息,可以被系统修改;第3（用户头）、４（用户正文）两块记录业务数据,由发起方赋值,其他节点只能读取，均不能修改;第5块（附加正文）记录业务相关的其他数据,任何节点均可以添加或修改业务相关的处理数据;第6块（签名）记录对第３、4块内容加编数字签名后的签名串内容;第7块（报尾）记录对第1、2、5、6做特殊算法处理后的身份验证串内容。
基本头、应用头、用户头、用户正文和报尾块都是必选的,而附加正文块和签名块是可选的。
基本头块、应用头块和报尾是定长格式的，用户头、用户正文块、附加正文块和签名块是变长格式的,可以包含子块。
附加正文块在发起方不用添加，其他节点对发起方的业务进行处理后需要附加的信息字段添加到附加正文块中。
目前定义附加正文块由FXCC（外币支付系统业务处理中心）对支付类报文清算后将清算相关信息添加进附加正文块，并转发到业务接收方。
附件正文块是可选的。
支付业务发起方此块不出现在报文中,FXＣC处理后会添加此块进报文中,支付业务的接收方此块是必选的。
签名块包含报文的数字签名,由发起方添加,其他各节点仅检查值合法性,均不能修改其值。
签名块是可选的。
需要加编数字签名的报文此块为必选。
1.2报文块格式
1.2.1基本头块
基本头块对输入、输出消息格式相同。
如果是输入消息，则本块内容与发送者相关;如果是输出消息,则本块内容与接收者相关（注意:
输入、输出是相对外币支付系统的FXＣC而言。
其格式如下:
{1:
（a）
F
（b）
0１
（c）
ＢＡＮKBＥBBＡXXX
（d）
2222
（e）
12345６
（f）
｝
（g）
说明：
（a）基本头块前缀与标识；
（b）应用标识（AppｌicatｉonIdeｎtｉfieｒ）：
１位字母，标识发送或接收消息的应用程序。
F-FIN,所有user-ｔo-usｅr消息、ＦＩN系统消息和FIN服务消息;G－GRＡ,大多数GPA系统消息和GPA服务消息;L－GRＡ，部分GPＡ服务消息，如：
ＬOGIN、ＬＡKs、ABORT。
外币支付系统固定使用Ｆ。
（c）服务类型（ＳerviｃｅＩdentifieｒ）:
2位数字，标识消息的类型，主要包含系统消息、用户消息、服务消息等。
用户主要关心的是“01”，即消息是GPＡ系统消息、ＦIN系统消息或uｓer-ｔo-uｓｅr消息。
其他如“21”表示ACＫ/NAK，UAK/UＮＫ，“03”表示SELECＴ命令等等。
外币支付系统固定使用01。
（d）逻辑终端地址（LTIdenｔifｉer）：
标识消息发起或接收的终端地址。
外币支付系统中为发送方（输入消息或往账）或接收方（输出消息或来账）的１1位行号加上1位的LT号（加在第9位）。
此处的发起方接收方一定为直接参与机构。
说明1：
11位行号－发送方或接收方如果是直接参与机构，则为该机构的11位BIC码；如果是FXＣC、结算银行、共享前置机,则此项为<4位机构代码>XＸXXXXX。
说明2：
发起方和接收方的ＬT号固定填“A”，
例1:
Ａ银行（ＢIC:
BNKACNSHXXX）发起一笔报文给B银行（BIC：
BＮKBCNBＪＸXX）,则发起方的LT为:
BＮKＡCNSHＡXXX，接收方的LT为:
ＢNKＢＣNBJAXXX；
例２：
Ａ银行（BIC:
BNKAＣNSHXXX）发起一笔报文给美元结算银行（代码为:
8887），则发起方的LT为:
BNＫＡＣNＳHAXXX，接收方的LＴ为:
8887ＸＸXXＡXXX;
例3：
FＸＣC（代码为８８8８）发起一笔报文给A银行（ＢIC：
BNＫＡCNSHＸＸＸ），则发起方的ＬT为：
8888XXXXAXＸX，接收方的LT为:
BＮKACNＳHＡＸＸX。
（e）任务号（SesｓionＮｕmber）:
4位数字,标识消息的任务号。
由发起方统一编号和（f）唯一标识一个报文。
（f）序列号（SequｅnceNｕｍｂer（ISNorOSN））：
6位数字,标识消息的顺序号。
由发起方统一编号,和（ｅ）唯一标识一个报文。
（g）基本头块结束符。
1.2.2应用头块
应用头块提供了消息本身的信息。
●输入消息应用头
输入消息应用头描述消息的类型、地址和发送方式。
FIN输入消息的应用头格式如下:
{２:
（a）
I
（b）
103
（ｃ）
BANKDEFFAＸＸX
（d）
N
（e）
（ｆ）
９９9}
（g）
说明:
（a）应用头块标识;
（b）输入输出标识:
I-输入消息，O-输出消息；
（c）消息类型号：
３位数字，即MT编号；
（d）接收逻辑终端地址：
１2位字母,标识消息接收的终端地址。
外币支付系统中为输入消息或往账的接收方的11位的行号加上1位的LT号（加在第9位）,LT号固定填“A”。
此处的接收方一定为直接参与机构。
请参考基本头块中的（ｄ）逻辑终端地址（LTIｄenｔifier）说明。
（e）消息优先级:
1位字母,该字符仅用于ＦＩN 消息,指定消息的优先级,可能的值包括：
S= 系统;U =紧急;N=正常。
“Ｓ”必须被用于ｕser-to－ｓystem消息。
useｒ-ｔo-useｒ消息，可以使用“U”或“N”。
如果没有指定交付规则，则系统消息总是最先交付,然后是紧急消息，最后才是正常消息。
外币支付系统目前忽略此项设置。
固定填N。
（f）交付监控：
该选项仅用于ＦINuser-to－uｓｅr消息，允许消息发送者请求:
一旦消息被交付，自动发出MT０11交付通知，或在失效时间内没有交付,自动发出ＭT 010未交付警告,或对于上述两项都有或都没有。
交付监控的可能值包括:
1 =未交付警告,２= 交付通知,３ =未交付警告和交付通知。
如果消息优先级为“Ｕ”，那么用户必须请求交付监控选项“1”或“3”，如果消息优先级为“N”，那么用户可以请求交付监控选项“２”，或者设置该参数为空格,没有交付监控。
外币支付系统目前忽略此项设置。
固定填１个空格。
（g）失效时间：
由三位数字构成（单位为５分钟），如果在失效时间之后FINuｓer-to-usｅr消息才被交付，系统会在消息中加入延迟标志（DLＭ）。
对于紧急消息,如果在失效时间内消息没有交付，系统会产生未交付警告。
对于紧急消息，失效时间为003（15分钟）,对于正常消息失效时间为020（100分钟）。
失效时间只
升级会员 