境内外币支付系统报文格式实用标准.docx

上传人:b****7 文档编号:11033913 上传时间:2023-02-24 格式:DOCX 页数:155 大小:81.78KB
下载 相关 举报
境内外币支付系统报文格式实用标准.docx_第1页
第1页 / 共155页
境内外币支付系统报文格式实用标准.docx_第2页
第2页 / 共155页
境内外币支付系统报文格式实用标准.docx_第3页
第3页 / 共155页
境内外币支付系统报文格式实用标准.docx_第4页
第4页 / 共155页
境内外币支付系统报文格式实用标准.docx_第5页
第5页 / 共155页
点击查看更多>>
下载资源
资源描述

境内外币支付系统报文格式实用标准.docx

《境内外币支付系统报文格式实用标准.docx》由会员分享,可在线阅读,更多相关《境内外币支付系统报文格式实用标准.docx(155页珍藏版)》请在冰豆网上搜索。

境内外币支付系统报文格式实用标准.docx

境内外币支付系统报文格式实用标准

附件四:

境外币支付系统报文格式标准

 

外币支付系统接口报文格式标准

 

中国人民银行科技司

二〇〇八年四月

内部资料

注意某某

版本修改记录:

版本号

完成日期

简单描述

2007-07-10

[C]提交总行支付司作为需求书报文格式附件

2007-12-10

[M]科技司下发商业银行版本

2007-12-15

[M]X字符集中增加‘’,‘#’。

[M]公共数据更新FMT062公共数据名称字段修改为20g,附言改为可选项。

[M]FMT080的“金融机构代码〞字段由强制项改为可选项。

[M]FMT083的“备注〞字段由30x改为30g。

[M]FMT032的排队业务数目由8!

n改为8n。

[M]正文块中的20栏位〔支付交易序号等〕,16x中要求必须不能出现SP空格字符,否如此报文将被外币支付系统拒绝。

[M]FMT061中发起业务权限数目和接收业务权限数目由3!

n改为3n。

[M]FMT082中〞备注〞由30!

x改为30g。

[M]FMT024报文“数字签名容〞字段修改为73E[78E]0-30。

[M]FMT100/101/102/103/104/200/201/202/203/204中〞52a/53a/54a/55a/56a/57a/58a〞中A的定义中增加[‘/’]。

[M]FMT013中借贷标识增加N。

标识结算的业务为支付清算组织发起的轧差净额业务。

[M]FMT196查复报文“查复容〞字段修改为35g[35g]0-5。

[M]FMT088直接特许参与者行号G51改为发起节点代码A41。

并增加说明项。

[M]FMT089直接特许参与者行号改为发起节点代码。

并增加说明项。

[M]FMT061业务权限报文并不下发给结算银行。

[M]FMT026当为0全部成功时,明细数目可能为0或者大于零,明细容为在FXCC已注销的清算行行号告知结算行。

[M]FMT060增加字段H51“上一工作日需对账币种清单〞,用以在日切时,告知参与节点上一工作日需要对那些币种进展对账。

[M]FMT080字段“地市代码〞由2!

n改为4!

n。

[M]增加变量,用于表示业务参考号、查询书号、支付交易序号等唯一确定一笔业务记录的序号。

此变量要求为16x,但不能含有SP空格字符。

[M]FMT986删除清算类型字段。

[M]FMT060的H51“上一工作日需对账币种清单〞字段,如果当日没有任何币种需要对账,如此应填NUL;

[M]1.2.5.1支付业务子块集增加203,用于日终对账补发203时使用。

[A]FMT199增加21:

相关参考号。

 

2008-1-6

[M]FMT013货币符号清算金额由15d修改为17d。

[M]FMT083字段“地市代码〞由2!

n改为4!

n。

[M]FMT087字段“变更类型〞增加3变更结算银行,当变更结算银行成功后,通过此报文通知所有直接参与行。

[M]FMT062增加“BASERSMX〞根底数据历史保存期。

[M]FMT087增加“币种金额小数位〞。

[M]FMT200增加附言字段’/F85/’30g[35g]0-5。

[M]FMT033和FMT034增加发起节点代码字段,支持结算银行查询在本结算行开户的某个直接参与者的额度信息。

[A]币种增加:

CAD-加拿大元AUD-澳大利亚元GBP-英镑CHF-瑞士法郎

[A]增加币种小数位描述:

加拿大元-2位小数,澳大利亚元-2位小数,英镑-2位小数,瑞士法郎-2位小数。

[A]增加结算银行代码的定义:

8883-加拿大元结算银行代码,8882-澳大利亚元结算银行代码,8881-英镑结算银行代码,8890-瑞士法郎结算银行代码。

[M]FMT044可用额度预警应答报文中的可用额度预警值改为强制项

[M]FMT083删除生效日期字段

[M]调用CFCA的签名函数得到的签名串在放入FMT024的“数字签名容〞F90字段前必须将签名串最后的去掉后才能放入F90字段。

[M]FMT100报文中的“收款人开户行号〞改为,“付款人开户行号〞改为

 

2008-1-29

[M]FMT044可用额度预警应答报文中的可用额度预警值改为可选项。

[M]FMT023中查询清算行行号由F15改为A15,查复清算行行号由F20修改为A20。

FMT024中的查复清算行行号由F20修改为A20。

[M]1.2.3.4退汇业务子块集中增加F91退汇原因字段。

[M]FMT194中的“退汇应答〞字段:

0—表述由“已退汇〞改为“同意退汇〞。

[M]FMT100中的“收款人开户行号〞改为“收款人开户行〞,“付款人开户行号〞改为“付款人开户行〞格式由原来的修改为35g[35g]0-3,银行可以根据具体情况输入开户行的行号或者名称。

[D]删除变量的定义。

[M]FMT089报文的明细中的“数字证书DN号〞修改为“数字证书〞,“数字证书参考号〞修改为“数字证书SN〞。

[M]FMT013增加可以给特许参与者发送的说明,增加对清算金额的说明。

修改“清算行行号A06〞为“直接〔特许〕参与者行号A01〞。

[M]FMT016修改处理状态:

“40FXCC日终退回〞为“40FXCC退回〞。

[M]1.1.1增加说明2:

本系统使用“┛〞〔0XA9BF〕作为用户输入的回车字符。

[M]FMT073增加说明⑤,说明补发的往帐支付报文的报文第1、2块填写规如此。

2008-2-23

[M]FMT021增加说明8、9,修改A10名称“被计费清算行行号〞为“被计费节点〞,类型“〞为“〞支持对结算银行计费功能。

2008-4-18

[M]修正4附录TAG与域名一览表的容和报文正文容一致,并删除其中未使用的TAG定义。

说明:

[C]-创建;[M]-修改报文;[A]-增加报文;[D]-删除报文;

1报文标准概述

1.1概述

1.1.1属性符号

n

表示0至9的数字

a

表示大写字母

x

表示X字符集中的任意字符

c

表示大写字母、0至9的数字

h

表示十六进制数,即数字0-9,大写字母A-F;

d

表示数值,即0-9,小数点符〔使用逗号〕‘,’;整数局部必须出现,至少有一位数字组成,可以出现前导0;如果没有小数局部,小数点符也必须提供。

G

表示汉字编码字符集〔GB18030编码〕

g

表示X字符集与汉字编码字符集〔GB18030编码〕

E

表示BASE64编码;

说明1:

对于特定的域,如账号,在数字与字母混合使用时,不得大小写混用,不得使用字母O和o,I和i,以防止与数字0和1混淆。

说明2:

对于FMT195〔:

75:

查询容〕、FMT196〔:

76:

查复容〕、FMT199〔:

79:

/F89/容〕几个字段,当用户需要在容中输入回车时,本系统使用“┛〞〔0XA9BF〕作为用户输入的回车字符。

1.1.2X字符集

外币支付系统X字符集使用ASCII编码,由以下78个字符组成:

0

1

2

3

4

5

6

7

8

9

A

B

C

D

E

F

0

LF

CR

1

2

SP

#

+

-

.

/

3

0

1

2

3

4

5

6

7

8

9

:

;

?

4

A

B

C

D

E

F

G

H

I

J

K

L

M

N

O

5

P

Q

R

S

T

U

V

W

X

Y

Z

_

6

a

b

C

d

e

f

g

h

i

j

k

l

m

n

o

7

p

q

r

S

t

u

v

w

x

y

z

{

}

说明:

上述字符集中,:

/{}四个字符保存为报文块的定界符,报文域值〔业务数据〕中不能使用此四字符,否如此报文将被外币支付系统拒绝。

正文块中的20栏位,16x中要求必须不能出现SP空格字符,否如此报文将被外币支付系统拒绝。

1.1.3英文简称命名规

首词首字母小写其余词首字母大写,当长度超过8个字符时,使用缩写,缩写原如此为四个或三个字母。

1.1.4报文结构

外币支付系统报文由多个报文块构成,报文块使用左花括号‘{’开始,使用右花括号‘}’完毕,紧接着左花括号使用一位数字标识块的类型,其后使用冒号‘:

’将块标识与块容分开。

外币支付系统使用以下报文块:

Ø根本头块:

{1:

BASICHEADERBLOCK};

Ø应用头块:

{2:

APPLICATIONHEADERBLOCK};

Ø用户头块:

{3:

USERHEADERBLOCK};

Ø用户正文块:

{4:

TEXTBLOCK}

Ø附加正文块:

{5:

APPENDTEXTBLOCK}

Ø签名块:

{6:

MACBLOCK}

Ø报尾块:

{7:

TRAILBLOCK}

其中第1块〔根本头〕、第2块〔应用头〕分别记录发起方、接收方信息,可以被系统修改;第3〔用户头〕、4〔用户正文〕两块记录业务数据,由发起方赋值,其他节点只能读取,均不能修改;第5块〔附加正文〕记录业务相关的其他数据,任何节点均可以添加或修改业务相关的处理数据;第6块〔签名〕记录对第3、4块容加编数字签名后的签名串容;第7块〔报尾〕记录对第1、2、5、6做特殊算法处理后的身份验证串容。

根本头、应用头、用户头、用户正文和报尾块都是必选的,而附加正文块和签名块是可选的。

根本头块、应用头块和报尾是定长格式的,用户头、用户正文块、附加正文块和签名块是变长格式的,可以包含子块。

附加正文块在发起方不用添加,其他节点对发起方的业务进展处理后需要附加的信息字段添加到附加正文块中。

目前定义附加正文块由FXCC〔外币支付系统业务处理中心〕对支付类报文清算后将清算相关信息添加进附加正文块,并转发到业务接收方。

附件正文块是可选的。

支付业务发起方此块不出现在报文中,FXCC处理后会添加此块进报文中,支付业务的接收方此块是必选的。

签名块包含报文的数字签名,由发起方添加,其他各节点仅检查值合法性,均不能修改其值。

签名块是可选的。

需要加编数字签名的报文此块为必选。

1.2报文块格式

1.2.1根本头块

根本头块对输入、输出消息格式一样。

如果是输入消息,如此本块容与发送者相关;如果是输出消息,如此本块容与接收者相关〔注意:

输入、输出是相对外币支付系统的FXCC而言。

其格式如下:

{1:

(a)

F

(b)

01

(c)

BANKBEBBAXXX

(d)

2222

(e)

123456

(f)

}

(g)

说明:

(a)根本头块前缀与标识;

(b)应用标识(ApplicationIdentifier):

1位字母,标识发送或接收消息的应用程序。

F-FIN,所有user-to-user消息、FIN系统消息和FIN服务消息;G-GRA,大多数GPA系统消息和GPA服务消息;L-GRA,局部GPA服务消息,如:

LOGIN、LAKs、ABORT。

外币支付系统固定使用F。

(c)服务类型〔ServiceIdentifier〕:

2位数字,标识消息的类型,主要包含系统消息、用户消息、服务消息等。

用户主要关心的是“01〞,即消息是GPA系统消息、FIN系统消息或user-to-user消息。

其他如“21〞表示ACK/NAK,UAK/UNK,“03〞表示SELECT命令等等。

外币支付系统固定使用01。

(d)逻辑终端地址〔LTIdentifier〕:

标识消息发起或接收的终端地址。

外币支付系统中为发送方〔输入消息或往账〕或接收方〔输出消息或来账〕的11位行号加上1位的LT号〔加在第9位〕。

此处的发起方接收方一定为直接参与机构。

说明1:

11位行号-发送方或接收方如果是直接参与机构,如此为该机构的11位BIC码;如果是FXCC、结算银行、共享前置机,如此此项为<4位机构代码>XXXXXXX。

说明2:

发起方和接收方的LT号固定填“A〞,

例1:

A银行(BIC:

BNKASHXXX)发起一笔报文给B银行(BIC:

BNKBBJXXX),如此发起方的LT为:

BNKASHAXXX,接收方的LT为:

BNKBBJAXXX;

例2:

A银行(BIC:

BNKASHXXX)发起一笔报文给美元结算银行(代码为:

8887),如此发起方的LT为:

BNKASHAXXX,接收方的LT为:

8887XXXXAXXX;

例3:

FXCC〔代码为8888〕发起一笔报文给A银行(BIC:

BNKASHXXX),如此发起方的LT为:

8888XXXXAXXX,接收方的LT为:

BNKASHAXXX。

(e)任务号〔SessionNumber〕:

4位数字,标识消息的任务号。

由发起方统一编号和〔f〕唯一标识一个报文。

(f)序列号〔SequenceNumber(ISNorOSN)〕:

6位数字,标识消息的顺序号。

由发起方统一编号,和〔e〕唯一标识一个报文。

(g)根本头块完毕符。

1.2.2应用头块

应用头块提供了消息本身的信息。

●输入消息应用头

输入消息应用头描述消息的类型、地址和发送方式。

FIN输入消息的应用头格式如下:

{2:

(a)

I

(b)

103

(c)

BANKDEFFAXXX

(d)

N

(e)

(f)

999}

(g)

说明:

(a)应用头块标识;

(b)输入输出标识:

I-输入消息,O-输出消息;

(c)消息类型号:

3位数字,即MT编号;

(d)接收逻辑终端地址:

12位字母,标识消息接收的终端地址。

外币支付系统中为输入消息或往账的接收方的11位的行号加上1位的LT号〔加在第9位〕,LT号固定填“A〞。

此处的接收方一定为直接参与机构。

请参考根本头块中的〔d〕逻辑终端地址〔LTIdentifier〕说明。

(e)消息优先级:

1位字母,该字符仅用于FIN消息,指定消息的优先级,可能的值包括:

S=系统;U=紧急;N=正常。

“S〞必须被用于user-to-system消息。

user-to-user消息,可以使用“U〞或“N〞。

如果没有指定交付规如此,如此系统消息总是最先交付,然后是紧急消息,最后才是正常消息。

外币支付系统目前忽略此项设置。

固定填N。

(f)交付监控:

该选项仅用于FINuser-to-user消息,允许消息发送者请求:

一旦消息被交付,自动发出MT011交付通知,或在失效时间没有交付,自动发出MT010未交付警告,或对于上述两项都有或都没有。

交付监控的可能值包括:

1=未交付警告,2=交付通知,3=未交付警告和交付通知。

如果消息优先级为“U〞,那么用户必须请求交付监控选项“1〞或“3〞,如果消息优先级为“N〞,那么用户可以请求交付监控选项“2〞,或者设置该参数为空格,没有交付监控。

外币支付系统目前忽略此项设置。

固定填1个空格。

(g)失效时间:

由三位数字构成〔单位为5分钟〕,如果在失效时间之后FINuser-to-user消息才被交付,系统会在消息中参加延迟标志〔DLM〕。

对于紧急消息,如果在失效时间消息没有交付,系统会产生未交付警告。

对于紧急消息,失效时间为003〔15分钟〕,对于正常消息失效时间为020〔100分钟〕。

失效时间只能在交付监控被设置〔对于紧急消息选择1或3,对于正常消息为2〕的情况下设置,否如此该消息会被标记H25错误。

外币支付系统目前忽略此项设置。

固定填999。

●输出消息应用头

输出消息应用头描述消息的类型、发送者与发送时间、交付时间。

FIN输出消息的应用头格式如下:

{2:

(a)

O

(b)

103

(c)

1200

(d)

010103BANKBEBBAXXX2222123456

(e)

010103

(f)

1201

(g)

N}

(h)

说明:

(a)应用头块标识;

(b)输入输出标识:

I-输入消息,O-输出消息;

(c)消息类型号:

3位数字,即MT编号;

(d)输入时间:

格式为HHMM,消息发送者的本地时间。

如果是系统消息,如此该时间为系统产生消息的时间〔格林威治时间GMT〕;

外币支付系统此项填写FXCC受理此报文的系统时间。

(e)MIR:

每个输出消息都有一个唯一的MIR。

MIR由28个字符构成,第1-6位是消息发送者的本地日期,外币支付系统此项填写FXCC受理此报文的系统工作日,第7-18位是消息发送者的逻辑终端地址,即报文发起方的LT:

11位的行号加上1位的LT号〔加在第9位〕,LT号固定填“A〞。

此处的发起方一定为直接参与机构。

请参考根本头块中的〔d〕逻辑终端地址〔LTIdentifier〕说明,第19-22位是发送者的任务号〔SessionNumber〕,第23-28位是发送者的序列号〔ISN〕,外币支付系统的发送者的任务号和序列号同根本头块中的发送者的任务号和序列号;

(f)输出日期:

接收者收到消息的本地日期,外币支付系统使用FXCC转发此报文的系统工作日期;

(g)输出时间:

格式为HHMM,接收者收到消息的本地时间,外币支付系统使用FXCC转发此报文的系统工作日期;

(h)消息优先级:

同输入消息。

1.2.3用户头块

用户头用于用户和用户间传递的信息。

本块只能被消息发送者赋值,并自动复制到输出消息中。

本块由子块构成,外币支付系统用户头块目前包含FMT子块集、转汇业务子块集、退汇业务子块集。

所有的报文必填的子块为FMT子块。

格式定义如下:

{3:

(a)

{FMT:

xxx}

(b)

}

(c)

说明:

(a)用户头块标识;

(b)子块容:

外币支付系统FMT编号有三位数字组成,具体容参清单;

(c)用户头块完毕符。

对于支付类报文、退汇报文等还需要填写其他的子块,具体的子块定义如下。

1.2.3.1FMT子块集〔适用所有报文〕

FMT子块集的格式定义:

序号

子块名称

强制/可选〔M/O〕

子块名

业务属性

示例

1

FMT号

M

FMT

3!

n

{FMT:

103}

说明:

所有外币支付系统报文,FMT子块集必须出现在用户头块中。

1.2.3.2优先级子块集〔FMT100/101/102/103/104/200/201/202/203/204〕

优先级子块集的格式定义:

序号

子块名称

强制/可选〔M/O〕

子块名

业务属性

示例

1

优先级别

M

E37

1!

n

{E37:

1}

说明:

当为100/101/102/103/104/200/201/202/203/204报文时,优先级子块集中的子块必须出现在用户头块中。

优先级别:

1-紧急,2-普通。

1.2.3.3转汇业务子块集(FMT101/102/104/201/202)

转汇业务子块集适用于FMT101/102/104/201/202报文,格式定义如下:

序号

子块名称

强制/可选〔M/O〕

子块名

业务属性

示例

1.

发起清算行行号

M

A11

{A11:

BAKASHXXX}

2.

接收清算行行号

M

A12

{A12:

BAKBSHXXX}

3.

发起行行号

M

A30

{A30:

BAKASH001}

4.

接收行行号

M

A31

{A31:

BAKBSH001}

5.

委托日期

M

B00

{B00:

20070808}

6.

支付交易序号

M

D50

{D50:

BBBBBB0000000001}

说明:

当为FMT101/102/104/201/202报文时,转汇业务子块集中的子块必须出现在用户头块中。

1.2.3.4退汇业务子块集(FMT103/204)

退汇业务子块集适用于FMT103/204报文,格式定义如下:

序号

子块名称

强制/可选〔M/O〕

子块名

业务属性

示例

1.

原委托日期

M

B90

{B90:

20070808}

2.

原支付交易序号

M

D90

{D90:

BANKAB0000000001}

3.

原FMT号

M

F31

3!

n

{F31:

101}

4.

退汇原因

O

F91

60g

{F91:

户名不符}

说明:

当为FMT103/204报文时,退汇业务子块集中的子块必须出现在用户头块中。

并且如果要退汇的原业务是转汇业务〔FMT101/102/201/202〕时,用户头块中还必须出现要退汇的原业务的转汇业务子块集。

以FMT101汇出业务的退汇报文FMT103〔要退汇的原业务FMT为101〕为例,如此用户头块组织如下:

{3:

{FMT:

103}{E37:

2}{B90:

20070808}{D90:

BANKAB0000000001}{F31:

101}{A11:

BAKASHXXX}{A12:

BAKBSHXXX}{A30:

BAKASH001}{A31:

BAKBSH001}{B00:

20070808}{D50:

BBBBBB0000000001}}

说明:

(a)用户头块用{3:

作为前缀符;

(b)FMT子块必须出现;

(c)优先级别为普通。

(d)转汇业务子块集中为原FMT101报文用户头块中的转汇业务子块集容;

(e)退汇业务子块集中为FMT103报文的子块容;

(f)使用}完毕用户头块。

1.2.4正文块

外币支付系统使用正文块传输发起方的消息容,由正文块前缀符{4:

打头,块完毕符}完毕,其间的各个报文域使用TAG码分隔。

外币支付系统正文块具有两种组织格式,非MT198格式和MT198格式,非MT198格式报文通过MT报文号区分,MT198报文通过FMT号〔子报文号〕区分。

正文块由多个定长或者变长且有序的报文域组成,报文域容中可能还含有子域,子域中可能还含有明细域。

1.2.4.1报文域

正文块报文域的组织应符合以下规如此:

1除标明可重复的报文域外,每个报文域只会在正文体中出现一次。

所有报文域在正文体出现的顺序必须严格符合报文格式标准的定义;

2报文域有的是强制项〔Mandatory〕,有的是可选项〔Optional〕;必选项必须出现在正文体中,可选项如此根据业务数据实际情况,可能出现,也可能不出现;

3在→和--|之间的报文域为可以重复的报文域,除标明可重复的报文域外,每个报文域只会在正文体中出现一次;

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 高等教育 > 历史学

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1