MT 101 Request for Transfer转账请求
MT 101 Request for Transfer转账请求
注意:使用此电文需要在MUG(电文用户组)注册。
MT101 使用范围
1. 此电文用于由一个代表非金融机构的账户拥有者的金融机构发送给账户服务金融机构或者进一步转发给账户服务机构的代理金融机构。(即非金融机构客户发给账户行或者代理行的电文)
2. 此电文用于由非金融机构账户持有者或账户持有者授权方发送给账户服务金融机构或者进一步转发给账户服务机构的代理金融机构。(即非金融账户持有者发送给账户行或者代理行的电文)
此电文用于转移汇款人在收报行或者账户行的账户或者汇款人明确授权的子账户的资金。
MT101电文能用于指示资金转移:
1. 在汇款人的账户之间或者
2. 支持的第三方,国内或者国际。
在企业对银行之间使用电文,参考www.swift.com网站的公司客户MT电文使用指南。
MT 101格式说明
MT101由两部分组成:
1. A序列总说明是一个单事件强制序列,包含应用于B部分中的所有单个交易详情中的信息。
2. B序列交易详情是一个重要的部分,每个事件都提供单个交易的详细信息。两个序列中出现的域是互斥的。
以下表格中内容/选项描述格式请参考:
SWIFT电文类型及格式:http://www.jianshu.com/p/af66115ed73a
状态 |
域 |
域名 |
中文域名 |
定义 |
内容/选项 |
序号 |
注意事项 |
A序列总体信息 |
|||||||
M |
20 |
Sender's Reference |
发报行参考号 |
发报行生成,唯一标识电文 |
16x |
1 |
不能以“/”开头或者结束,不能出现连续的两个“/” |
O |
21R |
Customer Specified Reference |
客户指定参考号 |
汇款人或者指示方指定的用于 整个电文的参考号 |
16x |
2 |
同序号1 |
M |
28D |
Message Index/Total |
电文索引/总的 |
区分连锁电文的序号和总电文数 |
5n/5n |
3 |
|
O |
50a |
Instructing Party |
指示方 |
标识电文中账户持有者或者账户行授权执行所有交易的客户 |
C or L |
4 |
C:4!a2!a2!c[3!c]非金融机构的BIC L: 35x 标识符 |
O |
50a |
Ordering Customer |
汇款人 |
标识借记账户的持有者信息 |
F, G, or H |
5 |
F: 35x 标识符 G: /34x 账号 金融机构BIC Code H: /34x 账号 |
O |
52a |
Account Servicing Institution |
账户服务机构 |
标识借记账户的账户行信息 |
A or C |
6 |
A:[/1!a][/34x] 标识符 4!a2!a2!c[3!c]金融机构 BIC Code F:/34x |
O |
51A |
Sending Institution |
发报行 |
报文发出行信息 |
[/1!a][/34x]标识符 |
7 |
|
M |
30 |
Requested Execution Date |
请求执行日期 |
账户借记日期 |
6!n |
8 |
YYMMDD |
O |
25 |
Authorisation |
授权 |
附加安全认证、数字签名等 |
35x |
9 |
|
B序列交易详情 |
|||||||
M |
21 |
Transaction Reference |
交易编号 |
16x |
10 |
||
O |
21F |
F/X Deal Reference |
外汇交易编号 |
汇款人和账户行之间 |
16x |
11 |
|
O |
23E |
Instruction Code |
指示代码 |
汇款人和账户行之间 |
4!c[/30x] |
12 |
|
M |
32B |
Currency/Transaction Amount |
币种/交易金额 |
3!a15d |
13 |
||
O |
50a |
Instructing Party |
同A |
C or L |
14 |
||
O |
50a |
Ordering Customer |
同A |
F, G, or H |
15 |
||
O |
52a |
Account Servicing Institution |
同A |
A or C |
16 |
||
O |
56a |
Intermediary |
中间行 |
A, C, or D |
17 |
||
O |
57a |
Account With Institution |
受益人账户行 |
A, C, or D |
18 |
||
M |
59a |
Beneficiary |
受益人 |
No letter option or A |
19 |
||
O |
70 |
Remittance Information |
汇款信息 |
转账所涉及的单笔交易的详情 |
4*35x |
20 |
|
O |
77B |
Regulatory Reporting |
监管报告 |
收报行或者发报行/原客户所在国要求的监管代码 |
3*35x |
21 |
|
O |
33B |
Currency/Original Ordered Amount |
币种/原金额 |
汇款人指定的原币种和金额 |
3!a15d |
22 |
|
M |
71A |
Details of Charges |
费用详情 |
BEN/OUR/SHA |
3!a |
23 |
BEN由受益人承担 OUR由汇款人承担 SHA除汇款人账户账户行的费用外,其他的费用由受益人承担 |
O |
25A |
Charges Account |
费用账号 |
单独指定用于收取费用的汇款人账号 |
/34x |
24 |
|
O |
36 |
Exchange Rate |
汇率 |
原币种和交易币种的汇率 |
12d |
25 |
MT101网络校验规则:
C1:如果36域不为空,则21F也不为空。
TAG 36(汇率) |
TAG 21F(外汇交易编号) |
不为空 |
必输域(Mandatory) |
为空 |
可选项(Optional) |
C2:序列B中单个事件,33B域不为空而且32B域Amount不为0时,36域也不为空。否则36域不可填。
TAG 33B(币种/原金额) |
32B(币种/交易金额) |
TAG 21F(外汇交易编号) |
不为空 |
=0 |
禁填(Not Allowed) |
!=0 |
必输域(Mandatory) |
|
为空 |
NA |
禁填(Not Allowed) |
C3:如果只有一个借记账户,汇款人必须在序列A的50a(F、G、H)域标识。相反的,如果使用了多个借记账户,在B序列的每一个事件都必须在50a(F、G、H)域标识汇款人。
结果,50a(F、G、H)域必须在序列A填写或者在序列B的每一个事件中填写,但是不能同时出现在序列A和序列B中,也不能都没有。
序列A Tag 50a(F、G、H) |
序列B每个交易 Tag 50a(F、G、H) |
为空 |
必输域(Mandatory) |
不为空 |
禁填(Not Allowed) |
C4:50a(C、L)域(Instructing Party)可出现在序列A或者序列B的任意一个或多个交易中,但是不能同时在序列A和B都出现。
序列A Tag 50a(C、L) |
序列B每个交易 Tag 50a(C、L) |
为空 |
可选项(Optional) |
不为空 |
禁填(Not Allowed) |
C5:如果序列B存在33B域,则在同一个事件中,必须与32B域币种代码不同。
例子:
有效: :32B:USD1000,
:33B:CHF1200,
无效: :32B:USD1000,
:33B:USD1200,
C6:52a域可以出现在序列A中或者序列B的一个或多个事件中,但不能同时出现在两个序列中。
序列A Tag 50a |
序列B每个交易 Tag 50a |
为空 |
可选项(Optional) |
不为空 |
禁填(Not Allowed) |
C7:如果56a域不为空,则57域也不为空。
Tag 56a |
Tag 57a |
为空 |
可选项(Optional) |
不为空 |
必输项(Mandatory) |
C8:如果序列A中21R域存在,则在序列B的每一个事件中,32B域的币种代码都不必须相同。
C9:在序列B的每个事件中,33B和21F域的出现依赖32B域和23E域以及域值。
Tag 32B |
Tag 23E |
33B |
21F |
=0 |
存在且代码为EQUI |
必输 |
可选 |
存在且代码不为EQUI |
禁填(Not Allowed) |
禁填(Not Allowed) |
|
为空 |
禁填(Not Allowed) |
禁填(Not Allowed) |
|
!=0 |
NA |
可选 |
可选 |
MT 101使用规则
1. 如果21R域出现在序列A中,并且28D域显示该转账请求指令有多条电文,所有电文的序列B中的事件的32B域的币种代码都必须保持一致。
2. 如果转账数额一样,23E域代码为EQUI,则32B域的交易金额必须为0.
3. 如果清除、置顶、零余额操作,23E域不为空,32B域值为0。
4. 如果28B域显示电文为连锁电文,同一系列的所有电文20域必须有同样的明确的发报行参考编号。
5. 如果28B域显示电文为连锁电文,序列A必须重复,而且属于同一系列的电文都必须相同。
6. 当结算金额为欧元时,必须以所在国币种表明等值面额,适用下列准则:
(1)32B域包含欧元时,由收报行执行。
(2)33B域包含币种和指示金额是所在国币种等值金额时,与32B域相等。
(3)36域(根据校验规则2)包含欧元和所在国币种等值金额之间固定汇率。
(4)21F域(根据校验规则1)包含值“NONREF”。
所有参与主体完整的交易流程图如下:
以上提到的各方不一定是不同的主体,可以相同。以下表中第一列是MT101电文中非必须的主体。第二列指定了可承担第一列中主体不存在时的角色。
如果不存在 |
可承担此功能的角色 |
Instructing party指示方 |
Ordering customer汇款人 |
Account servicing institution账户服务行 |
Receiver收报行 |
Intermediary中间行 |
Account with institution账户行 |
Account with institution账户行 |
Receiver收报行 |
MT101 操作流程
此电文需要按照特殊流程执行,至少由两方协议使用:
1. 在账户服务金额机构和汇款人之间
2. 发报金融机构和汇款人。取决于当地的市场情况,需要附加双边协议,例如:
发报进入机构和收报金金融机构。
账户服务金融机构和指示方。
推荐机构使用MT101操作规则和检查表作为建立协议的指导。双边协议覆盖转账双方的责任和义务以及交易金额限制等。
MT101操作规则及检查表
本部分提供了MT101支付电文的检查表。强烈推荐金融机构将此份指导书作为通过FIN或者FileAct软件用MT101电文进行转移支付时建立转移支付请求业务双边或多边协议的基础。
同时推荐在双边协议或多边协议中覆盖列出的所有条目。为了进一步促进建立这些协议,已经建立了一套通用的程序,如果愿意,也可以修改。
清单不打算提供详尽的项目清单,SWIFT也不要求对其承担任何责任。
双边协议,总览
双边协议1
修改一个收报行和汇款人之间已经存在的协议。
协议规定收报行授权接收电文并根据收到的发报行的汇款人支付请求指令采取行动。负责影响实际资金流动是收报行的义务。
双边协议2
修改一个发报行和汇款人之间已经存在的协议(电子支付链接)
协议必须明确发报行的义务,包括确保从汇款人接收到的消息的完整性,以及监控发送给收报行的电文。
协议还应规定,发报行的责任仅限于及时向Swift网络发送电文。换句话说,发报行对实际支付不负责。
双边协议3
建立金融机构之间转移支付请求电文的互换的双边协议。
如有必要,本协议应该进一步明确要求参与参与转移支付流程请求的金融机构的银行间责任。
双边协议4
建立账户服务金融机构和指示方/汇款人之间的双边协议。
本协议,使用时,允许账户持有者授权账户服务金融机构根据汇款人或者指示方的指示影响转账。
交易金额限制
当金融机构同意定义单笔交易的限制金额,限制金额需要具体到币种。
当协议允许交易超过具体要求的金额时,例如,监管报告要求,这些要求和相关格式也应该在协议中指定。
费用选项和数额
MT101电文定义了三种费用选择方式:OUR、SHA、BEN
这些费用可以是精确的数额或者公式(百分比)。这些费用包括收报行提供给发报行的交易保证和处理,支付给受益人账户的交易,或向受益人账户行执行支付的费用。附带银行-客户服务价格,例如日/周/月报咨询报告,以及随后的收费,可能随着机构的不能价格也不同,不能作为收费的一部分。
收费项 |
每条电文费用 |
每个交易费用 |
格式和确定的价格
日期和时间格式
发报行和收报行应该在收报行需要的能在其所在国执行可接受支付的时间格式达成一致。
在收报行截止时间之前接收的电文,将在预先商定的时间确定,即收到电文后的X天内。因为在收报行截止时间之后收到的电文,结算时间以“收报日+1”为基础。
收报日也是计算请求执行日期的基础,也是汇款人账户借记的日期。
币种1 |
币种2 |
|
收报行截止时间 |
||
结算时间 |
D(+) |
D(+) |
在线支付执行时间(直到资金到受益人账户) |
D(+) |
D(+) |
非在线支付执行时间(直到资金到受益人账户) |
D(+) |
D(+) |
解释:
D=赞同和收到日期,表示收报行在截止日期前已收到电文
或者
D=收到日期,D+1=赞同日期,表示收报行在截止日期之后收到报文
控制级别/检查和接收电文/交易
除非另有协议,金融机构将会作为他们控制/检查所有当前FIN/FileAct软件的安全问题以及MT101电文手册中定义的MT101电文语法和语义的基础。
为了实现MT101电文交换的直通处理,金融机构应该定义检查和控制相关的双边协议条款。
除非另有协议或需求,交易通过检查和控制被视为接收和不可撤回,将会被发至收报行的汇款人账户。在FileAct软件中,收报行发送的正面确认信息表示确认接受接收的电文。在FIN软件中,没有明确的电文需求。
如果交易未通过检查或控制,将会被驳回(见第下面第五部份)。
收报行执行的检查和控制,包括交易执行的优先级错误码:
Checks/Controls |
Yes/No |
Error code |
Transaction amount交易金额 |
||
Requested execution date请求执行日期 |
||
Validity of sending financial institution 发报行正确性 |
||
Account number/validity of ordering customer金额/汇款人正确性 |
||
Currency present 币种 |
||
Account number/identification of beneficiary 账号/受益人身份证 |
||
Remittance data (Length/Code) 汇款资料/(长度/代码) |
||
Instructing code 指令码 |
||
Account balance账户余额 |
||
Credit limit 信用额度 |
||
Other其他 |
驳回/退回电文/交易
由于发报行和收报行之间通信失败引起的电文驳回,适用FIN和FileAct现有规则。
除非另有协议,电文完全地收到但是未通过检查(上面第四部分定义)将会被收报行驳回而不进行后续处理。
FIN中通知交易或者电文被驳回,推荐金融机构使用MT195电文或者SWIFT支付驳回引导的其他电文类型。FileAct中,推荐金融机构使用负面确认信息来通知驳回电文。
驳回通知至少应该包含驳回交易或者电文的编号以及相关错误码。双方应该在收报行通知发报行最长延迟接受时间上达成一致,以及可能涉及的费用。
除非另有协议,退回给发报行的通知免除收报行处理电文。发报行将会在更正后,重新提交交易/电文。
交易驳回
退回给发报行的驳回交易或电文在交易或电文已经发送给收报行的汇款人账户后,将会触发结算。除非另有协议,结算将会遵循以下规则:
(1) 币种与原交易币种一致
(2) 在双方规定的日期执行
(3) 原交易金额保持不变
(4) 通过相同的账户关系中结算
(5) 正常的银行业务生效
所有会员应该遵守在收到MT101电文后在最长工作日内驳回或退回交易或电文,以及相关费用。
以下表格提供了视为交易/电文驳回/退回的详情:
Reject |
Return |
|
收到电文后给予Reject/Return通知给发报行的最常延迟时间 |
||
Reject/Return费用 |
Reject:问题发生在电文或交易未登记,还未记账之前。
Return:问题发生在电文或交易已经登记,已记账之后。
撤销
除非另有协议或者法律需要,电文完整收到并接受被视为不可撤销。以下除外:
无论如何,撤销必须双方同意,必须遵循以下详情:
详情 |
|
可接受的汇款人申请撤销电文的延迟 |
|
可接受的收报行对此请求的接受和回复的延迟 |
|
由于收报行要求产生的费用 |
建议撤销转账请求发送MT192电文,回复发送MT196电文。
MT 101 Request for Transfer转账请求相关推荐
- MT 111 Request for Stop Payment of a Cheque请求止付支票
MT 111 Request for Stop Payment of a Cheque请求止付支票 MT111范围 此单一电文由出票行或者扮演出票行角色的银行发给支付支票的银行(付款银行). 此电文用 ...
- CSRF(Cross-site request forgery)跨站请求伪造
为什么80%的码农都做不了架构师?>>> CSRF 背景与介绍 CSRF(Cross Site Request Forgery, 跨站域请求伪造)是一种网络的攻击方式,它在 2 ...
- python爬虫post请求翻页_python爬虫如何POST request payload形式的请求
python爬虫如何POST request payload形式的请求 1. 背景 最近在爬取某个站点时,发现在POST数据时,使用的数据格式是request payload,有别于之前常见的 POS ...
- CSRF(Cross-site request forgery 跨站请求伪造)
CSRF(Cross-site request forgery 跨站请求伪造,也被称成为"one click attack"或者session riding,通常缩写为CSRF或者 ...
- 通过request对象获取客户端请求信息
一.HttpServletRequest介绍 HttpServletRequest对象代表客户端的请求,当客户端通过HTTP协议访问服务器时,HTTP请求头中的所有信息都封装在这个对象中,通过这个对象 ...
- CSRF(Cross-Site Request Forgery) 跨站请求伪造
一.什么是跨站请求伪造 1. 什么是跨站请求伪造 定义: 跨站点请求伪造(也称为CSRF)是一种Web安全漏洞,允许攻击者诱使用户执行他们不打算执行的操作.它允许攻击者部分绕过同源策略. 危害: 在受 ...
- python提交post请求payload webkit_python爬虫实现POST request payload形式的请求
1. 背景 最近在爬取某个站点时,发现在POST数据时,使用的数据格式是request payload,有别于之前常见的 POST数据格式(Form data).而使用Form data数据的提交方式 ...
- request域对象和请求转发
request的其他功能 request是一个域对象 request对象也是一个存储数据的区域对象,所以也具有如下方法: setAttribute(String name, Object o) get ...
- python 字典字符串转字典——urllib.request.Request发送get,post请求,发送json参数
1.eval方法即可[字典字符串转字典] file_content = eval(file_content) 2.urllib.request.Request发送post请求,发送json参数 fro ...
最新文章
- 【C++】【七】栈的实现
- 06.SQLServer性能优化之---数据库级日记监控
- 算法炒房三月亏20多亿。房地产巨头大翻车:房价水太深,AI根本把握不住
- Android官方培训课程中文版
- 计算机视觉与深度学习 | 基于MATLAB 深度学习工具实现简单的数字分类问题(卷积神经网络)
- Java基础篇:抽象类与接口
- roslyn分析字符串代码_.NET 5 源代码生成器——MediatR——CQRS
- linux 无法mkdir文件夹,linux 不能mkdir了
- Kotlin系列之枚举类
- 由于本机的限制,该操作已被取消。请与系统管理员联系
- Linux 内核第一宏
- 车辆跟踪设备中晶振分类简介
- linux中红帽系统下载地址,Redhat8.3系统下载
- rj45插座尺寸图_详细介绍RJ45模块(附图解)
- 基于51单片机的温度采集系统
- Windows电脑如何访问小米路由器的移动硬盘
- 淘客外卖返利 优惠券 小程序公众号 电影票话费分销淘宝客CPS系统
- 开发谷歌浏览器插件会上瘾,搞了一个JSONViewer,一个页面格式化多条JSON,提升工作效率...
- medini analyze软件下载安装使用试用购买
- C语言基础语法(初学者必看)