保付加签业务的风险防控
在远期承兑跟单托收（D/A）方式的国际结算中，虽然付款人承兑了汇票，但因其代表的是进口商的商业信用，出口商仍可能对进口商的清偿能力存疑。为解决贸易双方互不信任的问题，保付加签业务应运而生。此类业务是进口商银行以自身信用介入，在经进口商承兑的票据上加注“PER AVAL”或类似字样，并签注担保银行名字，从而构成担保银行的保证责任。
国际商会（ICC）在TA.917的分析中指出，进口代收项下的保付加签是一种票据行为，在《国际商会托收统一规则》（URC522）中并无相关解释，因此更多应参照相关法律规定。这意味着，在涉外商事行为中，其可能会受到不同国家的法律约束，问题或更为复杂。国际商会银行委员会将于2021年秋季讨论并发布最新的国际商会官方意见。在目前准备提交讨论的六则草案中，有两则涉及进口代收保付加签的争议。由于两则草案的背景和争议焦点相近，本文将二者整合在一起，对保付加签项下银行的风险控制进行分析探讨。
案例回放
托收行向代收行邮寄了一套托收单据，单据中包含一个载明“AVALIZED DRAFT（经过保付的汇票）”的汇票。托收指示：D/A远期承兑交单，明确适用于URC522。
数日后，在尚未得到代收行的回复之前，托收行发电要求代收行通过加押电文告知到期日，同时确认承兑经过代收行保付加签。随后，代收行回电称，付款人已承兑汇票，并告知了到期日，但未明确保付加签。在托收行的追问下，代收行以MT999电文确认其已保付加签，电文措辞为“THIS HAS BEEN AVALIZED BY US”。
到期日已过，委托人仍未收到该笔款项。托收行向代收行催收，代收行以托收并非银行付款责任以及确认加签的MT999电文效力不足为由拒绝支付。
案例分析
保付加签常与D/A配套，将商业信用转变为银行信用。其市场接受度高，为流转和融资提供了便利。比如大宗商品的大额交易，通过保付银行信誉的加入，出口商银行会据此进行贴现或福费廷融资。保付加签对银行的专业性和时效性要求都非常高，如果对保付不了解或出现误操作，都会阻碍业务的正常进行，甚至给银行带来风险。通过对本案例的分析，不难发现以下问题。
托收行指示不清晰与代收行回复模糊的风险
根据URC522的4（B）（Ⅶ）款的规定，托收指示应当包括付款及/或承兑的条款和条件、单据的交付条件即付款及/或承兑、其他条款和条件。本案例中，托收行在寄单时并未要求代收行在承兑汇票上保付加签，仅提交了一份载明“AVALIZED DRAFT”的汇票；而根据URC522的4（A）（Ⅱ）款的规定，银行不会为取得指示而审核单据，汇票如此标注并不构成保付加签的托收指示。换言之，托收行对于保付加签的请求并不清晰。
至于托收行之后向代收行发送的“MAKE SURE THAT THE ADVICE OF ACCEPTANCE IS AVALISED BY YOUR GOOD OFFICE（请确认承兑电文已被贵行加具保付）”电文是否构成对托收指示的有效补充，该问题在URC522中并没有规定。国际商会对TA.797REV案例的分析指出，托收行应考虑代收行未查看到托收行减额指示报文的可能性，因而托收行对托收指示修改后并不能理所当然地认为已被代收行接受。但在本案例中，代收行对托收行的上述跟踪电文则做出了“THIS HAS BEEN AVALIZED BY US”的回复。尽管代收行辩解此系对付款人签字承兑的确认，而非对汇票的保付，但ICC认为，此已构成代收行的“AVALIZATION”，其有义务在付款人到期不付时承担付款责任。
代收行违背URC522规定导致的后果
根据URC522的1（B）（C），银行没有义务必须依据托收指示行事。如果银行无论出于何种理由选择不办理所收到的托收，应毫不延误地采用电讯或其他快捷工具通知向其发出托收指示的当事人。
本案例中的代收行是否清楚保付加签的含义不得而知，但代收行不但未对托收行后续要求保付的指示进行澄清，而且还做出了“已由我方保付”的确认，最终被ICC认定为构成代收行保付加签的承诺。
在R605中，托收行面函中要求代收行“请凭付款人的承兑以及贵行的联合承兑（保付）交付单据”；代收行在进口商承兑后便释放了单据，但并未在到期日前告知托收行未保付加签。ICC认为，当代收行凭付款人的承兑放单时，已介入交易，应被认为同意按照托收行的指示行事。
本案例所涉代收行对托收业务的处理与R605中代收行的做法有异曲同工之处，按照托收指示向付款人放单而未提出任何异议，就托收行要求“MAKE SURE THAT THE ADVICE OF ACCEPTANCE IS AVALISED BY YOUR GOOD OFFICE”的电文做了“我方已保付”的回复。显然，该代收行与R605中的代收行一样“已介入交易”。
对MT999电文效力的误解
银行间使用MT999非加押电文是否会导致电文内容失去效力？本案例中代收行对此的理解显然出现了偏差，以为使用了非加押电文，便不存在相关效力，其保付责任就不存在了。《SWIFT报文标准实用手册》所注明的第1类和第8类报文为加押电文，第9和第0类属于非加押电文。SWIFT系统中的报文密押是一道保护银行业务、资金、信息安全的防盗门，使当事方银行免受侵害。虽说银行间的往来电文多使用带密押的电文，但也并不是说非加押电文所陈述的内容是无效的。实务中，因为某些银行间并无密押关系而不得不使用非加押电文；ICC也从未明确规定使用MT999这类非密押电文会导致电文失去效力。案例中托收行认为，像保付这样的重要业务，往来电文应使用MT799这类带有&l